2020-06-01 02:59:35 <Ariadne> org.kde.pim.akonadiserver: DATABASE ERROR while PREPARING QUERY:
2020-06-01 02:59:35 <Ariadne> org.kde.pim.akonadiserver:   DB error:  "MySQL server has gone away"
2020-06-01 02:59:35 <Ariadne> org.kde.pim.akonadiserver:   Error code: "2006"
2020-06-01 02:59:40 <Ariadne> humm
2020-06-01 07:03:36 <ncopa> good morning!
2020-06-01 07:04:30 <ncopa> I hope everyone had a nice weekend. I surely did
2020-06-01 07:06:31 <Cogitri> Morning
2020-06-01 07:06:32 <Cogitri> Nice :)
2020-06-01 07:07:50 <ncopa> go 1.14 was pushed. nice!
2020-06-01 07:08:00 <ncopa> too bad it missed the 3.12 release
2020-06-01 07:08:57 <ncopa> i suppose backporting it to 3.12 is a bad idea now? and rebuild every go package?
2020-06-01 07:09:25 <ncopa> I think we should update the description on distrowatch: https://www.reddit.com/r/linux/comments/gt16a2/alpine_linux_3120_released/fsa9aut/
2020-06-01 07:09:26 <alpine-meetbot> [REDDIT] Alpine Linux 3.12.0 released (https://alpinelinux.org/posts/Alpine-3.12.0-released.html) to r/linux | 100 points (93.0%) | 57 comments | Posted by LeoFromAlpineLinux | Created at 2020-05-29 - 20:58:15UTC
2020-06-01 07:10:08 <ncopa> https://distrowatch.com/table.php?distribution=alpine
2020-06-01 07:10:23 <ncopa> It says: Desktop: Xfce
2020-06-01 07:10:37 <ncopa> Category: Firewall, From RAM, Raspberry Pi, Server, Security, Telephony
2020-06-01 07:10:55 <ncopa> Alpine Linux is a community developed operating system designed for routers, firewalls, VPNs, VoIP boxes and servers. It was designed with security in mind; it has proactive security features like PaX and SSP that prevent security holes in the software to be exploited. The C library used is musl and the base tools are all in BusyBox. Those are
2020-06-01 07:10:55 <ncopa> normally found in embedded systems and are smaller than the tools found in GNU/Linux systems.
2020-06-01 07:14:30 <[[sroracle]]> repology now tracks CVE information for packages, but there are ofc lots of false positives because it currently doesn't know about what is patched and what isn't
2020-06-01 07:14:52 <[[sroracle]]> can probably update the handler for it to look at alpine-secdb
2020-06-01 07:14:57 <[[sroracle]]> https://github.com/repology/repology-updater/issues/1045
2020-06-01 07:15:33 <[[sroracle]]> https://repology.org/projects/?inrepo=alpine_edge&vulnerable=1
2020-06-01 07:17:21 <mps> ncopa: rephrase in on alpinelinux.org => Alpine Linux - Universal OS
2020-06-01 07:19:01 <mps> rebooting to 5.7.0 :)
2020-06-01 07:22:33 <mps> ncopa: good news, yesterday I boot mainline kernel 5.6.14 on RPi zero W
2020-06-01 07:22:43 <mps> without any patches
2020-06-01 07:22:57 <ncopa> mps: awesome
2020-06-01 07:23:30 <ikke> We still have an issue with go on arm{v7,hf}
2020-06-01 07:23:55 <ncopa> ok
2020-06-01 07:24:06 <mps> and noticed that you didn't made uboot tarballs armhf for 3.11 and 3.12 releases. is that your intention or you forgot
2020-06-01 07:25:01 <ncopa> because we have no kernel for armhf
2020-06-01 07:25:22 <ncopa> only rpi kernel
2020-06-01 07:25:22 <mps> thought so. ok
2020-06-01 07:25:42 <ncopa> but that means that we can get rid of the linux-rpi, right?
2020-06-01 07:25:53 <mps> I hope so
2020-06-01 07:26:13 <mps> but we will need to test it for some time
2020-06-01 07:27:36 <mps> I will try add config-egde.armhf to linux-edge this week
2020-06-01 08:28:39 <clandmeter> i dont think you can get rid of linux-rpi
2020-06-01 08:29:03 <clandmeter> else the whole patch makes no sense.
2020-06-01 08:40:42 <nmeum> ncopa: I wouldn't backport go 1.14 to 3.12, no
2020-06-01 08:40:50 <nmeum> though I have a fix for the arm{v7,hf} issue
2020-06-01 08:41:00 <ikke> nmeum: ok, nice
2020-06-01 08:41:03 <nmeum> will push this now
2020-06-01 08:41:06 <nmeum> !8672
2020-06-01 08:41:15 <nmeum> it worked on the ci, let's hope it works on the builders as well
2020-06-01 08:41:22 <ikke> nmeum: did you add the getrlimit fix as well?
2020-06-01 08:41:29 <nmeum> yes
2020-06-01 08:41:45 <ikke> ok, good
2020-06-01 08:42:49 <nmeum> pushed, let's see how it goes
2020-06-01 08:52:32 <artok> mps had tough time configuring the kernel?
2020-06-01 09:03:38 <nmeum> go 1.14 seems to have passed on arm{v7,hf} finally
2020-06-01 09:04:17 <nmeum> I still need to make the testsuite work on x86 and debug the cgo_test which hangs for some reason
2020-06-01 09:13:40 <mps> artok: not much, used config-edge.armv7 from testing/linux-edge and disabled thumb2, and in arch submenu enable armv6
2020-06-01 10:11:55 <nmeum> Cogitri: is telepathy-logger still being used in telepathy? there hasn't been a commit in the repository since 2016 and it's the only telepathy-* packages which doesn't build with python3
2020-06-01 10:12:32 <nmeum> I am asking because if it is still being used I would probably go ahead and write a patchset for making it work with python3
2020-06-01 10:12:40 <Cogitri> It's still a hard requirement by polari unfortunately
2020-06-01 10:12:41 <Cogitri> That'd be nice
2020-06-01 10:13:10 <Cogitri> I tried removing it earlier, but that breaks Polari which has a runtime dep on it
2020-06-01 10:13:16 <Cogitri> And FWIW the GNOME Shell Telepathy integration needs it too, but the integration is broken on Alpine right now for some reason
2020-06-01 10:13:42 <Cogitri> https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2733
2020-06-01 10:13:48 <Cogitri> Thanks for working on that, nmeum! :)
2020-06-01 10:46:16 <nmeum> Cogitri: !8687 (seems to pass locally at least)
2020-06-01 10:47:56 <Cogitri> I'll test in a bit, thanks
2020-06-01 10:48:26 <nmeum> ok, great
2020-06-01 10:49:43 <nmeum> if that's merged my python2 list only includes software that too complicated to patch on our own (e.g. webbrowsers)
2020-06-01 10:50:58 <afontain_> In anbox case, it's actually a outdated transitive dependency
2020-06-01 10:51:20 <afontain_> but it's patched enough to make it hard to upgrade
2020-06-01 10:51:57 <afontain_> *anbox's
2020-06-01 10:53:16 <nmeum> yeah, already reported this upstream https://github.com/anbox/anbox/issues/1478
2020-06-01 10:53:32 <afontain_> I saw
2020-06-01 13:22:13 <mps> hmm, to build proper armhf kernel apk it must be built in armhf lxc, chroot or native environment. right?
2020-06-01 13:23:02 <mps> or, maybe trick somehow armv7 lxc?
2020-06-01 15:09:21 <Ariadne> FYI: automatic $builddir determination does not work in bootstrap APKBUILDs (it needs to be overridden as the bootstrap APKs are called xyz-bootstrap)
2020-06-01 15:09:58 <Ariadne> please do not remove builddir declarations from any APKBUILD mentioned in bootstrap.sh
2020-06-01 15:10:00 <Ariadne> thank you
2020-06-01 15:10:05 <Ariadne> i am having to put them back on some
2020-06-01 15:11:27 <Ariadne> community/go is presently blocked on mips because i have to rebootstrap it, which i have to fix up these APKBUILDs to do
2020-06-01 15:15:25 <Cogitri> Ariadne: Maybe add that to the APKBUILDs as comment, otherwise someone will trip over that at some point
2020-06-01 15:15:28 <nmeum> Ariadne: re $builddir, I think we need to document that somewhere otherwise it will just get lost in the irc backlog
2020-06-01 15:15:36 <Ariadne> yes, probably
2020-06-01 15:15:45 <maxice8> I can add the packages as exceptions in atools
2020-06-01 15:16:01 <Cogitri> Maybe we can just autodetect bootstrap pkgs?
2020-06-01 15:16:02 <Ariadne> that would be helpful
2020-06-01 15:16:10 <Cogitri> Do those always have _host depends?
2020-06-01 15:16:42 <maxice8> i'll just sync from scripts/bootstrap every once in a while
2020-06-01 15:19:23 <nmeum> shouldn't it also be possible to simply fix abuild's default $builddir value when bootstraping?
2020-06-01 15:22:45 <Ariadne> in theory, but problem is $pkgname changes
2020-06-01 16:06:51 <maxice8> atools 19.3.2 should fix it
2020-06-01 16:29:09 <Cogitri> ikke: Could you make https://gitlab.alpinelinux.org/odidev/ghc-bootstrap-aarch64 public for a bit just so I don't have to download it and then re-upload it to my aarch64 builder with my slow internet connection?
2020-06-01 16:29:47 <ikke> I can do it later tonight
2020-06-01 16:30:14 <Cogitri> Thanks :)
2020-06-01 16:31:35 <ikke> As itz related to alpine, it should not be an issue to keep it public
2020-06-01 16:32:12 <Cogitri> Ah okie
2020-06-01 16:34:09 <Cogitri> nmeum: Unfortunately I can't test the libvirt MR right now due to #11602 , can we maybe wait with the polkit move for a bit?
2020-06-01 16:43:58 <nmeum> Cogitri: yeah sure
2020-06-01 16:54:08 <Ariadne> sad trombone
2020-06-01 16:54:17 <Ariadne> cross go 1.14.3 -> rebuild 1.14.3 deadlocks
2020-06-01 16:55:05 <Cogitri> F
2020-06-01 16:56:47 <Ariadne> jwh (from abyss and one of my employees) is on the builder trying to debug it right now
2020-06-01 16:58:12 <Ariadne> so far the conclusion is "definitely fucked"
2020-06-01 16:59:36 <ikke> Sadface
2020-06-01 17:01:11 <Ariadne> he's going to try to reproduce it in his lab environment
2020-06-01 17:01:16 <Ariadne> i'm disabling mips64 go for now
2020-06-01 17:01:40 <dalias> congrats on the release btw
2020-06-01 17:09:29 <Ariadne> here's one for you
2020-06-01 17:09:40 <Ariadne> it does not deadlock when building on octeon2 machine
2020-06-01 17:09:52 <Ariadne> i am thinking perhaps something is wrong with kernel
2020-06-01 17:17:54 <Hello71> anybody try on qemu yet?
2020-06-01 18:08:20 <ikke> Cogitri: done
2020-06-01 18:17:37 <Cogitri> 👍
2020-06-01 22:14:15 <maxice8> mps: ping
2020-06-01 22:17:41 <mps> maxice8: pong (while preparing for bed)
2020-06-01 22:17:51 <maxice8> Do you use ax from my dotfiles ?
2020-06-01 22:18:30 <mps> I use some things, yes, but didn't used ax for some time
2020-06-02 06:37:44 <ncopa> morning!
2020-06-02 06:38:17 <mps> o/
2020-06-02 06:38:20 <Cogitri> 👋
2020-06-02 07:02:12 <ikke> \o
2020-06-02 09:55:17 <PureTryOut[m]> Are there examples for packaging Rust programs?
2020-06-02 09:56:19 <ikke> https://git.alpinelinux.org/aports/tree/community/ripgrep/APKBUILD ?
2020-06-02 09:58:33 <PureTryOut[m]> Cool, thanks. Where does it get the deps it requires from though?
2020-06-02 09:58:52 <ikke> similar to how go does it
2020-06-02 09:58:56 <ikke> from cargo
2020-06-02 10:00:08 <ikke> all dependencies are built along
2020-06-02 10:02:13 <PureTryOut[m]> So requires net access to download those then?
2020-06-02 10:02:23 <ikke> yes
2020-06-02 10:03:29 <PureTryOut[m]> Darn
2020-06-02 10:03:47 <ikke> welcome to the modern world of dependency management :)
2020-06-02 10:04:16 <PureTryOut[m]> It sucks 😭
2020-06-02 10:04:28 <mps> (world of idiots^W)
2020-06-02 10:04:55 <mps> ohm, sorry, hipsters :)
2020-06-02 10:10:54 <ikke> it's a difficult situation, because the other approach is less and less working as well (see how we hardly can pacakge python / ruby apps due to conflicting dependencies)
2020-06-02 10:12:48 <mps> perl managed to keep sane, well ... mostly
2020-06-02 10:13:04 <ikke> It requires discipline
2020-06-02 10:13:36 <mps> ah, nice word (and mostly forgotten nowadays)
2020-06-02 10:14:08 <mps> actually, I would call it 'self discipline'
2020-06-02 10:15:25 <mps> all serious works require effort and discipline
2020-06-02 10:16:29 <afontain_> on the other hand, there is no such problem with C and C++
2020-06-02 10:17:03 <afontain_> well, sometimes people bundle their dependencies, which is bad too, but at least it doesn't break
2020-06-02 10:17:26 <ikke> My theory is that those projects are older and more stable
2020-06-02 10:17:39 <Cogitri> Well, since you don't have a language package manager and can't pin deps people don't break their API every second day
2020-06-02 10:17:45 <ikke> nod
2020-06-02 10:17:48 <ikke> that as well
2020-06-02 10:17:58 <Cogitri> It's really annoying in Rust land how people just break API at will because you "can always just use the older version"
2020-06-02 10:18:49 <Cogitri> At least binaries aren't *that* big in Rust thanks to tons of optimizations and LTO
2020-06-02 10:18:53 <Cogitri> But it sure isn't pretty
2020-06-02 10:20:17 <Cogitri> But I can see why they're doing it, getting my package into the most relevant 5 distros already is a royal pain and a language package manager makes that relatively painless
2020-06-02 10:21:18 <mps> could be aspiration to keep control in 'one hands' (corporations/foundations)
2020-06-02 10:22:58 <mps> i.e. don't allow communities to do things differently
2020-06-02 10:54:36 <Cogitri> Well, to be honest, it is very annoying when things break because some distro decided to do things differently again
2020-06-02 10:54:56 <Cogitri> See e.g. the XScreensaver thingie
2020-06-02 10:55:26 <Cogitri> Where the author was so annoyed by Debian that he just added a warning to the software so people stop using it on Debian and Debian just patched it out then
2020-06-02 11:01:05 <HRio> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961907 seems to be needed to get older curl versions to work at lease on Debian
2020-06-02 11:02:02 <HRio> i.e. curl versions linked against openssl 1.0
2020-06-02 11:04:12 <HRio> seems "mozilla/AddTrust_External_Root.crt" must be '!'out in the client /etc/ca-certificates.conf
2020-06-02 11:05:39 <HRio> or you will get "certificate has expired"
2020-06-02 11:06:53 <HRio> I guess we should also remove this expired cert from our ca-certificates package
2020-06-02 11:10:23 <HRio> https://salsa.debian.org/debian/ca-certificates/-/commit/9d6c5602343d2ba4c2e7dfdcad5be8f777929b81
2020-06-02 11:22:03 <ikke> HRio: could you create an issue for it?
2020-06-02 11:23:54 <HRio> sure
2020-06-02 11:27:23 <HRio> #11607
2020-06-02 11:27:33 <ikke> thanks
2020-06-02 11:27:39 <mps> yes, this is also issue on alpine
2020-06-02 11:46:56 <ikke> TIL: apk search -q to get a list of all package names without version :)
2020-06-02 11:47:13 <ikke> comm -23 <(cat /etc/apk/world) <(apk search -q | sort -u) to find packages you installed which are no longer available
2020-06-02 11:51:39 <Cogitri> 🤯
2020-06-02 11:53:33 <ikke> What is that smiley conveying?
2020-06-02 11:55:43 <ikke> I think we should somehow fix these issues with removed packages somehow btw
2020-06-02 11:56:18 <afontain_> oh, -q is something I wanted for some time
2020-06-02 11:57:43 <ikke> I wasn't aware either, but was looking at the help output and hoping that would do what I expected and it gladfully did
2020-06-02 12:17:22 <Cogitri> ikke: That that's quite the nice command
2020-06-02 12:17:44 <Cogitri> Maybe even a bit nicer than purging all packages and installing them again :P
2020-06-02 12:18:07 <ikke> yup, and safer :)
2020-06-02 12:18:16 <Cogitri> A bit ^^
2020-06-02 12:18:29 <Cogitri> And yes, I hope apk will handle removed packages soon
2020-06-02 14:01:14 <maxice8> Going to merge nettle-3.6 soon
2020-06-02 14:01:22 <maxice8> !8754
2020-06-02 14:02:12 <ikke> maxice8: what is the impact?
2020-06-02 14:02:23 <maxice8> lots of rebuilds
2020-06-02 14:17:17 <ikke> ncopa: did you purge latest-stable? Some users report bad-signatures
2020-06-02 14:33:22 <maxice8> nettle merge at 12 AM BRT
2020-06-02 14:33:28 <maxice8> midday*
2020-06-02 15:15:32 <ncopa> ikke: i did
2020-06-02 15:18:06 <Cogitri> ncopa: Can you take a look at #11607 ? Seems like HTTPS is breaking for users due to it :/
2020-06-02 15:33:49 <ncopa> oh
2020-06-02 15:36:24 <ncopa> is there a testcase?
2020-06-02 15:37:14 <mps> quick fix is comment out mozilla/AddTrust_External_Root.crt and run update-ca-certificates, I had to do that
2020-06-02 15:39:04 <Cogitri> The debian bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961907) mentions some sites which experience issues
2020-06-02 15:39:34 <Hello71> alpine curl uses openssl 1.1, so try gnutls-cli mirror.sinavps.ch or somesuch
2020-06-02 15:39:59 <ncopa> Hello71: thanks!
2020-06-02 15:40:13 <ncopa> *** PKI verification of server certificate failed...
2020-06-02 15:40:13 <ncopa> *** Fatal error: Error in the certificate.
2020-06-02 15:42:25 <ncopa> seems like upstream mozilla has not yet removed it
2020-06-02 15:44:25 <Hello71> I think it is in nss 3.53
2020-06-02 15:45:01 <ncopa> in here? https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt
2020-06-02 15:45:07 <Hello71> hm, not sure
2020-06-02 15:47:50 <Hello71> my mistake, it wasn't removed. I was confused because nss was also updated recently, but I think it is unrelated
2020-06-02 15:48:25 <Hello71> gnutls-cli mirror.sinavps.ch still fails for me on arch with nss and cacerts 3.53
2020-06-02 15:49:23 <ncopa> it also faled for me after i updated to current https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt but I was not sure i installed it properly or if there were some old certs leftovers on my system
2020-06-02 15:53:28 <Hello71> I think we should not patch this downstream in Alpine. I think we already do not have openssl 1.0, and our curl is openssl, not gnutls
2020-06-02 15:54:11 <Hello71> openssl was upgraded to 1.1 in 3.9, and 3.8 is already out of support
2020-06-02 15:55:42 <ncopa> gnutls-cli is broken though
2020-06-02 15:56:09 <ncopa> removing the expired AddTrust_External_Root.crt fixes it
2020-06-02 15:56:27 <ncopa> https://tpaste.us/WRqM
2020-06-02 15:58:28 <ncopa> but um...
2020-06-02 15:58:32 <Hello71> yes. imo it's best to follow upstream/other distros here though
2020-06-02 15:58:41 <ncopa> wouldnt it be better to fix the bug in gnutls?
2020-06-02 15:59:08 <Hello71> apparently they didn't make a fixed release yet. at least there is no release since march on https://www.gnutls.org/
2020-06-02 15:59:27 <Hello71> I assume they are working on it?
2020-06-02 16:02:45 <ncopa> its fixed already
2020-06-02 16:03:00 <ncopa> https://gitlab.com/gnutls/gnutls/-/merge_requests/1271
2020-06-02 16:03:43 <ncopa> but no new release
2020-06-02 16:03:46 <ncopa> yet
2020-06-02 17:00:24 <maxice8> :D i made a small script that gives a dialog(1) interface for cherry-picking commits
2020-06-02 17:23:15 <reveller> Hi!  When a new release is dropped, do older releases (say 3.11, 3.10, etc) continue to get patch releases in the future?  In other words, will there ever be a 3.11.7 release?
2020-06-02 17:23:55 <Hello71> http://google.com/search?q=alpine+linux+release+support+cycle
2020-06-02 17:26:48 <Ariadne> reveller: yes, a 3.11.7 release will eventually happen, but it depends on some sort of high magnitude event
2020-06-02 17:28:03 <reveller> Ariadne thanks
2020-06-02 18:09:33 <nmeum> Cogitri: Just FYI: Restarted the telegraph-logger build for you https://gitlab.alpinelinux.org/nmeum/aports/-/jobs/133083
2020-06-02 18:27:08 <ikke> Isn't this contradictary? "There is no fixed release cycle but rather every 6 month we make a snapshot of edge and make a release."
2020-06-02 18:33:13 <Hello71> yes
2020-06-02 18:37:21 <maxice8> it sounds
2020-06-02 18:37:51 <maxice8> "We aim to make a snapshot of edge and release it every 6 months but that can vary as problems and solutions arise"
2020-06-02 18:38:31 <Cogitri> nmeum: thanks, will test tomorrow :)
2020-06-02 18:39:36 <ikke> I would s/but rather/but typically/
2020-06-02 18:40:17 <nmeum> Cogitri: alright, just make sure you download it before it expires again :)
2020-06-02 18:49:20 <Cogitri> I think it's 24h
2020-06-02 19:16:40 <mps> Cogitri: firefox 77.0 should be 'backported' to 3.12-stable?
2020-06-02 19:35:31 <Cogitri> I already made a MR
2020-06-02 19:37:51 <Cogitri> !8770
2020-06-02 19:38:21 <Cogitri> Will merge once the edge builders are happy with it
2020-06-02 19:41:06 <mps> thanks
2020-06-02 20:14:48 <Cogitri> Might take a little because the edge builders are still busy with chromium
2020-06-02 20:14:53 <Cogitri> It sure takes forever to build
2020-06-02 20:19:25 <nmeum> roughly 6 hours last time I checked
2020-06-02 20:20:12 <ikke> RIP
2020-06-02 20:21:04 <nmeum> > >>> chromium: Build complete at Tue, 19 May 2020 02:02:12 +0000 elapsed time 7h 23m 23s
2020-06-02 20:21:15 <nmeum> from the last build-edge-x86_64 chromium build
2020-06-02 20:21:26 <ikke> :o
2020-06-02 20:32:43 <Hello71> turn on lto, that'll fix it
2020-06-02 21:01:06 <Cogitri> jumbo building might actually "fix" it
2020-06-02 21:01:30 <Cogitri> But I'm pretty sure I won't be able to build it with a measly 64GB of RAM with 32 build jobs :^)
2020-06-02 21:01:49 <ikke> lol
2020-06-02 21:03:16 <ikke> 640k ought to be enough for everyone
2020-06-02 21:18:08 <Cogitri> I guess I'll have to go for something rack mounted instead of miniITX next time do I can throw enough hardware at the problem :D
2020-06-02 22:21:10 <maxice8> armv7 chromium failed with segfault error
2020-06-02 22:21:14 <maxice8> clang-10: error: unable to execute command: Segmentation fault
2020-06-02 22:35:59 <artok> out of memory-segfault ?
2020-06-03 05:34:12 <Cogitri> Maybe we should add a note to a.o about the current situation python2 situation
2020-06-03 05:34:38 <Cogitri> There were like 3 or 4 people complaining on the aports issue tracker already, wondering why their python2 stopped working
2020-06-03 05:35:19 <ikke> yeah
2020-06-03 05:35:46 <ikke> python2 is still there, but many modules no longer
2020-06-03 05:36:29 <Cogitri> Yup
2020-06-03 05:37:33 <ikke> And we did say python2 would be removed in 3.12 :)
2020-06-03 05:37:44 <ikke> but we did not repeat that in the 3.12 notes
2020-06-03 05:48:24 <Cogitri> Yeah, I guess that's part of the problem
2020-06-03 05:49:53 <ikke> And I feel we should have added a proper provides / replaces for 'python'
2020-06-03 05:51:31 <ikke> but for many modules that is difficult
2020-06-03 06:02:19 <Cogitri> Hm, I think not having an unversioned python was by design
2020-06-03 06:02:32 <Cogitri> So it doesn't break everyone's setup when we switch major versions
2020-06-03 06:03:38 <ncopa> morning
2020-06-03 06:05:05 <Cogitri> Morning
2020-06-03 07:02:16 <nmeum> maybe we should also add "removal of many python2 packages" to the 3.12 changelog as available on the website
2020-06-03 07:03:05 <Cogitri> Yup
2020-06-03 07:03:56 <nmeum> maybe also add some upgrade notes on how this should be handeled during the upgrade process
2020-06-03 07:07:08 <Cogitri> Hm, what would those notes contain other than "please upgrade everything to py3 ASAP" ?
2020-06-03 07:07:25 <Cogitri> And maybe a link to the py3 guide the python foundation has?
2020-06-03 07:09:01 <nmeum> haven't look into this in depth but some people reported upgrading issues https://gitlab.alpinelinux.org/alpine/aports/-/issues/11605
2020-06-03 07:13:02 <Cogitri> Right, that should be handled
2020-06-03 07:13:22 <Cogitri> Although best case apk would do that for them instead of us putting that in the release notes where people will probably miss it
2020-06-03 12:26:27 <ncopa> I think we should try avoid things like this: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11605#note_93204
2020-06-03 12:27:25 <Cogitri> You mean the reply?
2020-06-03 12:28:34 <ncopa> try avoid breaking things for users
2020-06-03 12:28:41 <ncopa> when they upgrade
2020-06-03 12:29:09 <ncopa> hum
2020-06-03 12:29:17 <ncopa> but i guess its difficult to avoid
2020-06-03 12:29:22 <Cogitri> Ah yes, but what would we do about that?
2020-06-03 12:29:27 <ncopa> exactly
2020-06-03 12:29:35 <ncopa> the real problem is https://trac.edgewall.org/ticket/12130
2020-06-03 12:30:17 <Cogitri> I mean we should've mentioned more clearly that python2 is largely removed from 3.12 in the release notes, yes
2020-06-03 12:30:29 <mps> yes, it is not easy to break things when you have nearly fixed release time
2020-06-03 12:30:51 <mps> not easy to not break*
2020-06-03 12:42:38 <ncopa> helped another user the other day, who is using ansible
2020-06-03 12:42:42 <ncopa> with lxc
2020-06-03 12:43:12 <ncopa> the lxc ansible module is python version agnostic, works with both python2 or python3
2020-06-03 12:44:08 <ncopa> but the problem was that they use the same ansible playbooks for different versions of alpine. they previously did `apk add python` but that no longer works
2020-06-03 12:45:03 <ncopa> he ended up doing a hack in the lxc install script that would detect 'python' and replace it with 'python3'
2020-06-03 12:45:37 <ncopa> the real problem is that python2 -> python3 is a big mess, in general
2020-06-03 12:47:20 <Cogitri> Yup, it really is
2020-06-03 13:07:28 <tehcloud> the real problem is that python is a big mess, in general
2020-06-03 13:10:50 <mps> that is what I learned long ago, i.o.w. I told self 'don't touch python if you want sane life'
2020-06-03 13:11:48 <mps> though I could rephrase it it 'don't touch programming if you want sane life'
2020-06-03 13:12:13 <tehcloud> yes, I still find myself yelling sometimes when I touch C++ codebases
2020-06-03 13:12:46 <tehcloud> those late 90s era Microsoft Visual C++ programmers sure brought some bad habits with them into the future... :P
2020-06-03 13:13:23 <mps> :)
2020-06-03 15:35:57 <maxice8> There is something driving me mad
2020-06-03 15:36:02 <maxice8> in secfixes:
2020-06-03 15:36:08 <maxice8> should newer versions be at the top or the bottom ?
2020-06-03 15:36:18 <maxice8> i add new secfixes entries always at the top
2020-06-03 15:39:36 <mps> I do same, looks like this is established behaviour
2020-06-03 15:40:37 <maxice8> well some people do differently and i want to know if it is
2020-06-03 15:40:40 <maxice8> 1. Should be put at the top
2020-06-03 15:40:45 <maxice8> 2. should be put at the bottom
2020-06-03 15:40:46 <maxice8> 3. either is fine
2020-06-03 15:41:33 <Cogitri> At the top I think
2020-06-03 15:43:40 <mps> if you look git log usually at the top
2020-06-03 16:49:53 <ncopa> are there many that has them at the bottom?
2020-06-03 16:50:22 <maxice8> testing/grafana
2020-06-03 16:50:35 <ncopa> I'd say add them at the top unless it means we need to modify lots of them
2020-06-03 16:50:56 <ncopa> what we really need is a doc with that info
2020-06-03 16:51:40 <maxice8> secdb has no 3.12
2020-06-03 16:52:17 <ncopa> i am working on that
2020-06-03 16:52:30 <ncopa> https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10672
2020-06-03 16:52:47 <maxice8> ah good, ty
2020-06-03 21:23:48 <opal> "alpinelinux-4.1.2(unknown,charybdis-4.1.2)." is an odd branding for alpine's chary package
2020-06-03 21:24:08 <opal> highly doubt im running ircd-alpinelinux
2020-06-03 22:07:38 <wsinatra> Anyone mind looking over MR !8842?
2020-06-03 22:08:07 <wsinatra> Finally got official support for musl libc in SBCL! And it builds on aarch64 now too!
2020-06-03 22:08:42 <mps> wsinatra: nice
2020-06-03 22:09:51 <wsinatra> Thanks :) I'm excited, sbcl on pinephone in my future haha
2020-06-03 22:20:20 <superduck> Are merge requests discussed here, or only in GitLab?
2020-06-03 22:21:22 <wsinatra> Lots of both
2020-06-03 22:21:24 <ikke> No, it's fine to discuss them here as well
2020-06-03 22:21:58 <ikke> Sometimes it's easier to just discuss certain things over chat then lots of back-and-forth over an MR
2020-06-03 22:22:38 <wsinatra> speaking of discussing things, what should a maintainer do when one of their packages gets mangled by the build systems?
2020-06-03 22:22:51 <ikke> mangled?
2020-06-03 22:23:38 <wsinatra> Yeah something really strange happened to Fennel when I bumped it to 0.4.1, the package that's available through apk throws some weird error about indexing lua5.3-source incorrectly
2020-06-03 22:23:52 <wsinatra> but I can build it just fine manually and through my CI/CD
2020-06-03 22:24:40 <wsinatra> I think the package just needs to be rebuilt? But I'm not certain if I should submit a MR and bump the pkgrel to get that done or something else
2020-06-03 22:25:35 <ikke> step 1 would be to find out what is going wrong in the first place
2020-06-03 22:27:21 <wsinatra> A fair point there, I haven't checked outside of rebuilding it myself. I'll spin up some vms and poke around
2020-06-03 22:27:41 <ikke> "ua5.3: Parse error in unknown:32: can't start multisym segment with a digit: lua5.3-source"
2020-06-03 22:28:47 <wsinatra> Ah no the package itself is broken
2020-06-03 22:28:52 <ikke> ok
2020-06-03 22:28:55 <wsinatra> I had a local version installed with luarocks
2020-06-03 22:29:26 <wsinatra> excuse my confusion there, glad it's not the packaging system, just the package maintainer haha
2020-06-03 22:30:16 <ikke> The other option would have been a missing dependency that you have installed locally
2020-06-03 22:32:39 <superduck> My merge requests are spitting warnings from the linter because of fakeroot and alpine-baselayout being non-conformant, is that typical?
2020-06-03 22:33:18 <wsinatra> thanks for the suggestions ikke!
2020-06-03 22:35:07 <ikke> superduck: yes
2020-06-04 00:20:43 <superduck> Can someone explain why this build failed? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8845
2020-06-04 00:21:45 <superduck> nevermind, I see that alpine-baselayout has a services file that's tied to it's version number....
2020-06-04 08:22:54 <ncopa> morning
2020-06-04 08:23:11 <ncopa> commits like this is normally not acceptable for stable branches: 67e86c8287be5fc0527d19ef13d6a9bc8ddb51ce
2020-06-04 08:23:42 <ncopa> but since it was so close to the 3.12-stable branching, the .0 release, its okish
2020-06-04 08:24:12 <ncopa> reason is that if you use a stable branch, you should be able to run apk ugprade  from a cronjob and be confident that nothing breaks as a result
2020-06-04 08:24:41 <ncopa> meaning, that users should not need to make any manual changes after an apk upgrade in a stable branch
2020-06-04 08:26:00 <ncopa> if you had set up a system (or docker image) that did `apk add lttng-ust` and then used the tools, an apk upgrade would remove the tools from the setup
2020-06-04 08:26:17 <ncopa> fix would be a manual change: apk add lttnd-ust-tools
2020-06-04 08:26:40 <ncopa> that is acceptable for edge, but not for stable branches
2020-06-04 08:27:00 <ncopa> I dont think many users was affected in this case, so its okish
2020-06-04 08:30:52 <mps> yes, we should keep consistency as principle
2020-06-04 08:31:17 <mps> how it is called, 'least surprise'?
2020-06-04 08:31:29 <ikke> yes, principle of least surprise
2020-06-04 08:32:22 <mps> I understand that it is not possible always, but whenever is possible we should follow this principle
2020-06-04 08:34:04 <ncopa> in think in this case it was acceptable, but thats only because 3.12 is so fresh, so it is unlikely that anyone is affected
2020-06-04 08:35:24 <mps> not sure, we should follow some rules, or go to chaotic distro
2020-06-04 08:36:39 <mps> (as we are not already enough chaotic)
2020-06-04 08:45:44 <nmeum> PureTryOut[m]: should I just revert the snapcast changes?
2020-06-04 08:46:01 <nmeum> splitting the services into an -openrc doesn't really work as that will be pre-installed anyhow
2020-06-04 08:46:15 <PureTryOut[m]> Or just fix the init script 😛
2020-06-04 08:46:35 <nmeum> but what user should be used by the initscript then?
2020-06-04 08:48:14 <PureTryOut[m]> Why not just the default, root?
2020-06-04 08:49:01 <nmeum> I think that's a bad idea, we should make as few services as possible run as root by default
2020-06-04 08:50:51 <ikke> nodejs on 3.9 fails to build
2020-06-04 08:58:36 <PureTryOut[m]> nmeum: in that case just undo the changes yes
2020-06-04 09:25:18 <nmeum> PureTryOut[m]: ok then
2020-06-04 09:28:08 <nmeum> done, sorry for the fuckup
2020-06-04 09:28:55 <ikke> nmeum: typically for revert commits I move the "revert" part after the repo/package name
2020-06-04 09:29:10 <ikke> community/snapcast: revert ...
2020-06-04 09:29:33 <nmeum> ok
2020-06-04 10:47:39 <ikke> maxice8: #11610 can be closed, right?
2020-06-04 11:57:52 <andypost[m]> Used to fix build of php 7.4 last night in !2421 but stuck on x86 math failures, maybe it's clang related?
2020-06-04 12:03:03 <markand> hey
2020-06-04 12:03:13 <markand> since my upgrade to 3.12 I'm unable to build packages by hand:
2020-06-04 12:03:16 <markand> >>> ERROR: caps: builddeps failed
2020-06-04 12:03:16 <markand> >>> caps: Uninstalling dependencies...
2020-06-04 12:03:35 <markand> I don't even have dependencies listed in this APKBUILD
2020-06-04 12:22:33 <Cogitri> Can you paste the entire abuild output, markand ?
2020-06-04 12:45:17 <markand_> ttps://pastebin.com/G5gW9Z0t Cogitri
2020-06-04 13:04:29 <clandmeter> markand_: does apk return error?
2020-06-04 13:41:10 <maxice8> @ikke yes #11610 should be closed, i though i managed to do it via commits
2020-06-04 14:27:39 <wsinatra> leo: thanks for the merge!
2020-06-04 14:27:50 <maxice8> welcome
2020-06-04 14:39:40 <markand_> someone for !8495
2020-06-04 14:39:43 <markand_> ?
2020-06-04 14:55:19 <markand> thanks ncopa <3
2020-06-04 14:57:21 <ncopa> 10 years ago I dreamed about running ardour on alpine
2020-06-04 14:58:39 <mps> you are musician? :)
2020-06-04 15:01:51 <ncopa> i was
2020-06-04 15:04:09 <markand> me, yes
2020-06-04 15:04:24 <markand> someone aborted the automatic merge
2020-06-04 15:04:55 <maxice8> I think automatic merges are stopped if someone else merges in the meantime
2020-06-04 15:04:56 <mps> my son used ardour for some things he made, and I think his works/songs are still on some music sites but can't remember where
2020-06-04 15:05:02 <ikke> markand: anything else being merged would do that
2020-06-04 15:05:03 <markand> arf
2020-06-04 15:07:03 <markand> ncopa, I can tell you that Ardour works fine on Alpine :)
2020-06-04 15:07:20 <markand> using it with my focusrite 4i4
2020-06-04 15:09:53 <mps> actually, when I was young I built some electronic music instrument, tried to imitatr Krafwerk :)
2020-06-04 15:10:03 <mps> imitate*
2020-06-04 15:11:01 <mps> hmm, instruments*
2020-06-04 15:12:45 <mps> hmm, hmmm, Kraftwerk (I'm blind or tired)
2020-06-04 15:17:04 <markand> Qt 4 was removed from 3.12 (or before) right?
2020-06-04 15:18:10 <Cogitri> Seems like it's gone for a long time already
2020-06-04 15:19:42 <markand> oh nvm, hydrogen 1.0.0 will be based on Qt 5 instead, just wait for it
2020-06-04 15:19:58 <asmik> hello to everyone
2020-06-04 15:20:58 <asmik> Is this a good chat to ask questions about package management?
2020-06-04 15:26:35 <wsinatra> yep it is
2020-06-04 15:26:58 <wsinatra> speaking of, would anyone take a look at MR !8866, got the Fennel package fixed finally
2020-06-04 15:31:53 <asmik> I've created APKBUILD's for bup and cryfs for my personal use. I want to contribute them to community. Can I read somewhere on the process of package contribution?
2020-06-04 15:34:14 <Cogitri> asmik: https://wiki.alpinelinux.org/wiki/Creating_patches#Submitting_patches_via_Gitlab
2020-06-04 15:38:35 <ikke> Note that new packages start in testing
2020-06-04 15:45:17 <ncopa> I'm working on replacing  https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases with a yaml:  https://tpaste.us/JxlV
2020-06-04 15:45:35 <ncopa> the idea is to generate everything from there
2020-06-04 15:46:11 <asmik> Is there also some kind of linter for packages? like deblint in Debian?
2020-06-04 15:47:42 <mps> yes, apkbuild-lint
2020-06-04 15:47:50 <mps> apk add atools
2020-06-04 15:47:56 <asmik> great, thanks!
2020-06-04 15:53:25 <ikke> ncopa: sounds like a good plan :)
2020-06-04 15:54:34 <asmik> erm. sorry to ask, but I think either this linter does not work or my package is perfect. I'm launching it with `apkbuild-lint .` in a dir with APKBUILD. It just silently exits.
2020-06-04 15:54:59 <ikke> asmik: you need to specify the APKBUILD file
2020-06-04 15:55:08 <asmik> nope. `apkbuild-lint APKBUILD`
2020-06-04 15:55:36 <asmik> ikke: yep. launching it with dot resulted in error
2020-06-04 15:55:54 <ikke> It takes a list of APKBUILD files to check
2020-06-04 15:56:19 <asmik> and if it's ok it outputs nothing?
2020-06-04 15:57:09 <ikke> yes
2020-06-04 16:09:13 <asmik> well.. I guess it's ok then
2020-06-04 16:12:25 <ikke> Note that our CI also runs shellcheck and abuild sanitycheck
2020-06-04 16:16:48 <asmik> Yeah. I do understand that. I just wanted to test packages locally as thoughout as I could
2020-06-04 16:17:01 <asmik> *throughout
2020-06-04 16:35:30 <ikke> asmik: understood, just wanted to prepare you that CI might give more warnings
2020-06-04 17:16:20 <asmik> ikke: that's great. I'm expecting that, thanks!
2020-06-04 19:20:55 <telmich> ncopa: are you around?
2020-06-04 19:24:20 <telmich> ncopa: Re https://gitlab.alpinelinux.org/alpine/aports/-/issues/10237: The easiest way is to test on a v4 only host: get an IPv6 VPN (if you give me a wireguard public key, I'll create one with a /48 network for you), then create a new bridge (bripv6 for instance), add an IPv6 address from a /64 to the bridge, setup radvd to send router announcements with RDNSS setup on the bridge; then just start qemu with the nic
2020-06-04 19:24:20 <telmich> attached to the bridge. I can help with all steps, if you / anyone else needs support in this direction
2020-06-04 20:34:31 <Hello71_> why do you need a publicly routable address for this?
2020-06-04 20:35:35 <Hello71_> probably the kernel is not a problem here, so imo all you need is netns
2020-06-04 20:36:00 <Hello71_> set up three containers: one "server", one "router", one alpine "client"
2020-06-04 20:36:16 <Hello71_> connect with veth and routing rules
2020-06-05 02:48:57 <Terror> Hi team, trying to send a Merge request via gitlab (my first time on gitlab, have used gihub in the past) but can't get the linter to work. I get the following error: $ git fetch -nq $CI_MERGE_REQUEST_PROJECT_URL +refs/heads/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME:refs/heads/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME
2020-06-05 02:49:08 <Terror> fatal: could not read Username for 'https://gitlab.alpinelinux.org': No such device or address
2020-06-05 05:18:39 <voltagex> hey, how is the minirootfs image created?
2020-06-05 05:21:43 <voltagex> aha https://git.alpinelinux.org/aports/tree/scripts/mkimg.minirootfs.sh
2020-06-05 05:22:02 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/scripts
2020-06-05 05:22:04 <ikke> yea
2020-06-05 06:01:02 <ncopa> ikke: do you know if we can set up a ipv6 vpn?
2020-06-05 06:18:54 <Ariadne> ncopa: do you have any objection on enabling CONFIG_VHOST_CROSS_ENDIAN_LEGACY at next kernel bump for ppc64le and aarch64?
2020-06-05 06:24:43 <mps> Ariadne: 'Since it adds some overhead, it is disabled by default.', from Kconfig. But, I'm not sure, maybe it could be useful in some cases
2020-06-05 06:26:46 <Ariadne> the overhead is minimal
2020-06-05 06:26:59 <Ariadne> it is literally an extra branch
2020-06-05 06:27:31 <Ariadne> if vm_is_other_endian() { swap_endian(); } ...
2020-06-05 06:29:02 <Ariadne> so, more accurately, if the endianness matches, it is minimal overhead
2020-06-05 06:29:11 <Ariadne> if swapping is needed well obviously that is going to add overhead
2020-06-05 06:29:13 <Ariadne> but
2020-06-05 06:29:25 <Ariadne> the overhead would be there anyway
2020-06-05 06:29:36 <mps> yes, true
2020-06-05 06:33:16 <Ariadne> it would help me tremendously in preparing ppc64 (for smoketesting the ppc64spe port)/ppc64spe (for networking equipment) ports of alpine if i can run VMs on my power9 machine ;)
2020-06-05 06:36:03 <mps> ppc64 for networking (low level) device? or I misunderstand?
2020-06-05 06:42:22 <Ariadne> ppc64spe (freescale e5500 core, which is ppc64 without altivec) is commonly used in networking equipment
2020-06-05 06:42:50 <Ariadne> octeon (now arm-based as octeon tx/octeon tx2, instead of mips) is the main competitor
2020-06-05 06:45:42 <mps> ah, didn't know for ppc64spe. thanks for explanation
2020-06-05 06:52:49 <Cogitri> BTW, what was the plan for moving to GCC10?
2020-06-05 06:52:54 <Ariadne> damn
2020-06-05 06:53:21 <Ariadne> this vendor bsp kernel does not support kvm
2020-06-05 06:53:33 <Ariadne> i had a cursed idea on how to solve go on mips
2020-06-05 06:53:38 <Ariadne> run bsp kernel
2020-06-05 06:53:42 <Ariadne> kvm real kernel
2020-06-05 06:53:45 <Ariadne> hahahahaha
2020-06-05 06:53:56 <mps> Cogitri: not sure which should be first, gcc or musl
2020-06-05 06:54:27 <Ariadne> i think, musl 1.2
2020-06-05 06:55:05 <mps> I think soon will be musl 1.2.1, with mallocng
2020-06-05 06:55:40 <Cogitri> I'd look into GCC10 once my exams are done, so in ~4weeks the earliest anyway, so no rush
2020-06-05 06:56:00 <mps> and I also think musl upgrade is first in queue for upgrade
2020-06-05 06:57:00 <Ariadne> well in reality, we do not have to rebuild everything for musl 1.2
2020-06-05 06:57:05 <Ariadne> we can just upgrade
2020-06-05 06:57:20 <Ariadne> it is ABI-compatible even on 32-bit
2020-06-05 06:57:27 <mps> also, this is my thinking
2020-06-05 06:58:18 <mps> I talked about this on #musl few weeks ago, and dalias confirmed that
2020-06-05 06:59:33 <Cogitri> Ah, I thought 32-bit things need patches though?
2020-06-05 07:00:22 <mps> some programs will need fix because of time64, but not much of them
2020-06-05 07:00:37 <mps> on 32bit, I mean
2020-06-05 07:01:07 <Cogitri> Okie, nice
2020-06-05 07:01:42 <mps> and kernel have 32 bit time compatibility option which must be 'Y'
2020-06-05 07:02:12 <Ariadne> have we verified our kernels have that set to Y on 32-bit archs ?
2020-06-05 07:02:42 <mps> well, 'must', nothing is must but without it problems will happen
2020-06-05 07:02:50 <mps> Ariadne: I think, yes
2020-06-05 07:02:57 <Ariadne> ok
2020-06-05 07:03:03 <Ariadne> i'm going to prepare this as an MR
2020-06-05 07:03:12 <Ariadne> and then check to make sure the 32-bit kernels are good
2020-06-05 07:03:25 <Ariadne> in meantime, people can upgrade from the repository built in the MR
2020-06-05 07:03:28 <Ariadne> to test :)
2020-06-05 07:04:28 <mps> CONFIG_COMPAT_32BIT_TIME=y
2020-06-05 07:05:28 <mps> we have it already on linux-lts, and linux-edge ofc :)
2020-06-05 07:06:09 <Ariadne> ok
2020-06-05 07:06:10 <Ariadne> great
2020-06-05 07:06:26 <Ariadne> still going to put it up as MR
2020-06-05 07:06:29 <Ariadne> so people can test
2020-06-05 07:07:16 <mps> only package I know (from the head) which probably will not work is bdb (berkly db)
2020-06-05 07:07:26 <mps> but I didn't tested it
2020-06-05 07:08:19 <Ariadne> oh that is frustrating
2020-06-05 07:08:26 <Ariadne> gitlab won't let me just make a branch on aports.git
2020-06-05 07:08:29 <Ariadne> i have to fork it
2020-06-05 07:08:43 <Ariadne> well no biggie
2020-06-05 07:15:31 <afontain_> mps or Adriadne: could you explain a bit why CONFIG_COMPAT_32BIT_TIME=y is needed for the time64 update? Or maybe send a link that explains it?
2020-06-05 07:16:47 <Cogitri> Ariadne: why would you want to work directly on aports?
2020-06-05 07:17:12 <Cogitri> I think the protection is in place so people forking from aports don't have to fetch random changes from devs and we don't sync them to g.a.o
2020-06-05 07:17:25 <Ariadne> Cogitri: yes, i understand the rationale behind it
2020-06-05 07:17:52 <afontain_> (or maybe I just assumed it was related to time64)
2020-06-05 07:18:17 <Ariadne> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8895
2020-06-05 07:18:29 <Ariadne> please test the libc packages on this MR
2020-06-05 07:18:31 <mps> afontain_: only what I can tell, read the #musl IRC log few weeks ago
2020-06-05 07:22:04 <afontain_> I'll try to find it there, thanks for the pointer
2020-06-05 07:23:38 <ncopa> Ariadne: i guess CONFIG_VHOST_CROSS_ENDIAN_LEGACY is useful. lets enable it
2020-06-05 07:32:12 <ikke> ncopa: ipv6 tunneled over ipv6, or native ipv6 VPN?
2020-06-05 07:32:45 <ncopa> ipv6 tunneled over ipv4
2020-06-05 07:32:58 <ncopa> i dont have ipv6 here so i cannot test ipv6 only installs
2020-06-05 07:33:13 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/10237
2020-06-05 07:33:39 <ncopa> what telmich is suggesting here above
2020-06-05 07:35:28 <clandmeter> ncopa: you can spin a linode vm if you like
2020-06-05 07:41:11 <ikke> Tunneling ipv6 over OpenVPN is possible, I do that for my personal vpn
2020-06-05 07:41:27 <ikke> And also quite easy
2020-06-05 07:41:54 <ncopa> ok
2020-06-05 07:42:15 <ncopa> good to know. I will try set that up later
2020-06-05 07:42:43 <ikke> You don't even need NAT
2020-06-05 07:42:48 <Ariadne> looks like
2020-06-05 07:43:01 <Ariadne> musl 1.2 works fine on an x86-32 VM i just spun up
2020-06-05 07:43:20 <ikke> You just tell OpenVPN the provide a publicaly routable ip
2020-06-05 07:43:23 <Ariadne> so i think it is ok
2020-06-05 07:44:07 <Ariadne> would be nice to see armv7 tested too
2020-06-05 07:44:16 <Ariadne> mps: can you test it?  i dont have any armv7 device
2020-06-05 07:44:39 <Ariadne> for GCC 10, i want to do a test rebuild with -fno-common first
2020-06-05 07:44:55 <Ariadne> i suspect we are going to have a lot of fallout
2020-06-05 07:45:04 <ncopa> Ariadne: the problem with musl 1.2 is if libraries has time_t in any public interface
2020-06-05 07:45:24 <Ariadne> ncopa: yes, i know, we are just testing the ABI compat atm
2020-06-05 07:45:33 <ncopa> the moment you rebuild that lib you'll have to rebuild evertying
2020-06-05 07:45:42 <Ariadne> hmm
2020-06-05 07:45:48 <Ariadne> good point
2020-06-05 07:46:10 <ncopa> so im thinking it may meke sense to set up a new edge builder, and just build everythign from scratch
2020-06-05 07:46:18 <ncopa> and replace the current
2020-06-05 07:46:29 <Ariadne> yes, seems reasonable
2020-06-05 07:46:37 <Cogitri> Ariadne: Yes, there's quite the fallout with GCC10
2020-06-05 07:47:01 <Ariadne> ncopa: well i have the updated package prepared in an MR
2020-06-05 07:47:19 <Ariadne> so, if we want to do a rebuild, that may be the way to go
2020-06-05 07:47:52 <Ariadne> i have a couple of 32-bit ports that i am working on that will be "edge only"
2020-06-05 07:48:12 <Ariadne> so i would like to do musl 1.2 sooner rather than later so i don't have to rebuild a bunch of ports :P
2020-06-05 07:49:01 <ncopa> makes sense
2020-06-05 07:49:42 <ncopa> let me finish up my work on https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10672 and I'll try set up a new builder next week
2020-06-05 07:49:56 <Ariadne> sounds good to me
2020-06-05 07:50:08 <ncopa> part of the problem is that we need to do x86, armhf and armv7 in parallel
2020-06-05 07:50:10 <ncopa> at the same time
2020-06-05 07:50:58 <ncopa> and im not we have diskspace for both armhf and armv7 currently
2020-06-05 07:56:20 <mps> Ariadne: this is what I'm planed to do (but had to work on other things and didn't had enough time), but if you are already built it you saved me some time. thanks :)
2020-06-05 07:57:01 <Ariadne> what spec is the armhf builder
2020-06-05 07:57:13 <Ariadne> we can probably set up a new armhf builder
2020-06-05 07:57:36 <Ariadne> mps: traditionally, me and fabled have been the ones dealing with musl maintenance soooo :)
2020-06-05 08:00:00 <mps> Ariadne: traditions changes (especially in these modern times ;) ), but I'm with your and fabled works
2020-06-05 08:01:01 <mps> actually for any musl commit/change I always asked fabled or ncopa to review them, though didn't know you are also involved
2020-06-05 08:02:15 <Ariadne> i was the person who originally packaged musl when we were on uclibc for most archs :p
2020-06-05 08:03:00 <mps> ah, (children, please sit down and listen, time for old story :) )
2020-06-05 08:08:27 <markand> is the non-POSIX ${var/x/y} subtitution allowed in APKBUILDs?
2020-06-05 08:08:33 <mps> nice !8895 passed on all CIs
2020-06-05 08:09:30 <Ariadne> why wouldn't it ??
2020-06-05 08:10:36 <mps> well, rhetorical note actually
2020-06-05 08:10:51 <mps> I didn't expected it will fail
2020-06-05 08:13:42 <mps> markand: !8883
2020-06-05 08:13:54 <mps> it is already in community
2020-06-05 08:14:03 <markand> what
2020-06-05 08:14:14 <markand> haha
2020-06-05 08:14:34 <markand> excellent
2020-06-05 08:14:48 <markand> let's update it to beta2 instead
2020-06-05 08:15:35 <mps> before introducing new aport it is good idea to run some 'grep -r ....' in aports, will save some time :)
2020-06-05 08:15:44 <mps> and conflicts
2020-06-05 08:16:05 <mps> please do not use betas if they are not essentially needed
2020-06-05 08:16:18 <markand> I've setup a list of MAO software to package and definitely that one missed my check if already existing
2020-06-05 08:16:37 <mps> in alpine preferred are stable releases of pkgs
2020-06-05 08:17:23 <markand> yes but the last stable depends on Qt 4 which isn't available
2020-06-05 08:18:02 <Cogitri> It's already on beta1 right now, isn't it?
2020-06-05 08:18:42 <markand> yes
2020-06-05 08:19:07 <markand> the beta1 was released in 2018 and beta2 hasn't changed that much so 1.0.0 should be almost the same as beta2
2020-06-05 08:21:06 <mps> if it need qt5 then it is ok to upgrade to beta
2020-06-05 08:23:41 <markand> it is *already* in beta
2020-06-05 08:24:29 <Ariadne> yes, just update hydrogen to beta2
2020-06-05 08:24:34 <Ariadne> but it works fine at present
2020-06-05 08:24:37 <markand> doing it at the moment
2020-06-05 08:33:46 <markand> could be nice if we move ladspa from testing to community because hydrogen can make use of it
2020-06-05 08:35:58 <Ariadne> sure
2020-06-05 09:00:21 <markand> there it is !8900
2020-06-05 10:12:12 <PureTryOut[m]> Why is https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/non-free/py-flask-pymongo/APKBUILD in the non-free directory? The license variable lists it as some form of BSD
2020-06-05 10:14:00 <Cogitri> I guess because mongo-db is unfree?
2020-06-05 10:14:56 <PureTryOut[m]> Oh woops you're right, I missed that
2020-06-05 10:21:47 <ncopa> i am discovering that I made a couple of silent release in january 2020
2020-06-05 10:21:57 <ncopa> no release notes
2020-06-05 10:22:42 <mps> Ariadne: (and all interested): Linux localhost 5.6.14-0-edge #1-Alpine SMP PREEMPT Wed, 20 May 2020 15:59:37 UTC armv7l GNU/Linux
2020-06-05 10:22:50 <mps> so armv7
2020-06-05 10:23:11 <mps> apk version musl => musl-1.2.0-r0                           > 1.1.24-r8
2020-06-05 10:23:35 <mps> everything works fine, real box not qemu or container
2020-06-05 10:24:43 <mps> (I think I can go and make coffee after that :) )
2020-06-05 10:25:38 <Cogitri> I'll test once I'm done setting up my new /, currently moving to a new SSD so I have enough space to not run out of it when I compile electron :D
2020-06-05 10:26:09 <mps> uhmm, electron :D
2020-06-05 10:38:39 <andypost[m]> Any idea why https://pkgs.alpinelinux.org/package/edge/main/ppc64le/nghttp2 is not yet upgraded? It blocks security bump for nodejs_current
2020-06-05 10:39:04 <andypost[m]> Only ppl64le using old version
2020-06-05 10:40:30 <Cogitri> ppc64le is still stuck on openjdk14
2020-06-05 10:40:40 <Cogitri> And no one got around to killing that yet apparently
2020-06-05 10:40:40 <ikke> looking at it in a sec
2020-06-05 10:41:07 <Cogitri> 👍️
2020-06-05 10:42:57 <andypost[m]> Thanks! Looks it stuck long ago because it main but stuck in testing
2020-06-05 10:43:40 <Cogitri> It has been stuck for a few days now
2020-06-05 10:44:13 <ikke> killed the test
2020-06-05 10:44:47 <Cogitri> Thanks
2020-06-05 10:45:17 <ikke> apparently that's not fatal for the build
2020-06-05 10:45:43 <Cogitri> That's a bit concerning :D
2020-06-05 10:47:00 <ikke> it probably kills the dead-lock that is holding it stuck
2020-06-05 10:47:04 <ikke> I see it more often
2020-06-05 10:57:04 <Cogitri> ikke: Can I move files from a container I got from infra to d.a.o directly?
2020-06-05 10:57:57 <ikke> only through ssh
2020-06-05 10:57:59 <ikke> they are different hosts
2020-06-05 10:59:14 <Cogitri> Okie
2020-06-05 11:57:54 <mps> ikke: are you contacted curl upstream regarding !7346
2020-06-05 11:58:18 <ikke> mps: no I have not yet
2020-06-05 11:58:50 <mps> ok, np
2020-06-05 11:59:16 <mps> but if you don't have time or some other reason, I could do that
2020-06-05 11:59:38 <ikke> Feel free
2020-06-05 12:00:03 <mps> ok
2020-06-05 12:00:13 <mps> do we need !8891 in alpine
2020-06-05 12:00:37 <mps> afaik, it is outdated, but I could be wrong
2020-06-05 12:34:22 <afontain_> About musl 1.2, do you know if kernel support is required?
2020-06-05 12:34:32 <afontain_> `CONFIG_64BIT_TIME`
2020-06-05 12:35:19 <afontain_> *CONFIG_64BIT_TIME, specifically
2020-06-05 12:42:34 <markand> someone has an idea how can I fix a package that fails to build with: https://pastebin.com/nqALinc0
2020-06-05 12:44:50 <markand> nvm their CMake build works instead
2020-06-05 13:44:28 <ikke> claws-mail failed due to checksum failure
2020-06-05 14:08:12 <superduck> when adding a new aport, does the contributor automatically become the maintainer, or do we need to peddle for an existing maintainer to pick up our new aport for mainternship?
2020-06-05 14:08:34 <maxice8> you become the maintainer unless you can get someone to maintain
2020-06-05 14:09:16 <ikke> We don't require some existing developor to sponsor the package
2020-06-05 14:47:12 <Cogitri> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11615#note_94113 huh, I don't really know our Docker stuff to well, but is that something you'd usually do?
2020-06-05 14:55:23 <ikke> What exactly are you referring to?
2020-06-05 14:57:27 <Cogitri> The adding fixed versions of packages to get security patches
2020-06-05 14:57:46 <Cogitri> I guess you wouldn't want `apk upgrade` because that'd bloat your image due to layering?
2020-06-05 14:58:09 <dalias> ariadne, mps, re: CONFIG_COMPAT_32BIT_TIME=y it's the default. non-default setting here will break all userspace (not just new musl)
2020-06-05 15:22:31 <mps> dalias: thanks for confirmation. I remember that you explained this on #musl
2020-06-05 15:23:02 <mps> and I told this here, about 9:00 CET this morning
2020-06-05 15:43:03 <mps> dalias: btw, I installed musl 1.2.0 in armv7 with alpine 3.12/edge, works without any noticable problem
2020-06-05 15:44:05 <mps> 
ACTION wonders why all not upstream software is not in similar shape

2020-06-05 15:44:31 <mps> uhmm, should rewrite after coffe :)
2020-06-05 15:45:54 <mps> 
ACTION wonders why not most upstream software is in similar good shape as musl

2020-06-05 15:46:24 <mps> (hope it is better now :) )
2020-06-05 15:51:00 <andypost[m]> Locales should be better, most wanted from 1.2 - php using lots of hacks
2020-06-05 15:52:38 <mps> later today/tonight I will try to upgrade musl to 1.2.0 on aarch64 machine
2020-06-05 15:53:34 <mps> to test Xorg and other gui tools and programs
2020-06-05 15:53:43 <mps> especially firefox
2020-06-05 15:54:00 <Cogitri> I'll give it a go on my x86_64 system
2020-06-05 15:54:12 <Cogitri> I only set this up today, let's hope I don't immediately break it :D
2020-06-05 15:55:04 <mps> for such tests I have separate disk or mmc cards
2020-06-05 15:55:27 <Cogitri> Right, I could do a btrFS snapshot
2020-06-05 15:57:38 <mps> looking how much fixes are pushed for btrfs in kernel git log I don't dare still to use it
2020-06-05 15:58:53 <Cogitri> I guess it's fine for basic use now, but I still use ZFS in my NAS where data loss would be pretty uncomfortable
2020-06-05 15:59:03 <Cogitri> I use it in my laptop & desktop
2020-06-05 15:59:37 <mps> yes, also ext4 had some fixes today
2020-06-05 15:59:56 <mps> so, good backup is best FS :)
2020-06-05 16:00:19 <superduck> I'm looking forward to bcachefs making btrFS look like a waste of time
2020-06-05 16:01:07 <Cogitri> I'm not too enthusiastic about bcachefs when it has basically only one dev working at it
2020-06-05 16:01:33 <superduck> Better code quality in my estimation.
2020-06-05 16:21:28 <dalias> anyone else find that the abiword package spins at huge cpu load and rapidly flashes the cursor?
2020-06-05 16:21:47 <dalias> it's in a poll loop with 3ms timeout for some reason
2020-06-05 16:22:21 <dalias> is this just brokenness everywhere or something alpine/musl -specific ?
2020-06-05 16:30:51 <Hello71> never heard of that. I did have a similar experience with knot on freebsd where urcu spun due to missing futex, but that's probably unrelated
2020-06-05 16:32:48 <ncopa> mips64 is finally added to downloads (minirotfs only) https://wwwtest.alpinelinux.org/downloads/
2020-06-05 16:36:23 <mps> heh, Linux zarya 5.7.0-1-gru #2 SMP PREEMPT Mon Jun 1 06:50:13 UTC 2020 aarch64 GNU/Linux
2020-06-05 16:36:37 <mps> apk version musl => musl-1.2.0-r0
2020-06-05 16:37:57 <mps> Xorg is up, wifi works, firefox browsing
2020-06-05 16:38:09 <mps> everything looks fine
2020-06-05 16:42:39 <superduck> I'm getting this error from a python app I'm trying to package a new aport for when it does the egg-info copying:
2020-06-05 16:43:21 <dalias> mps, on 32-bit?
2020-06-05 16:43:33 <superduck> I'm invoking standard python3 build steps, so I'm curious how/why that's failing.
2020-06-05 16:43:35 <dalias> of course everything will work fine unless/until you get a mismatched mix of 3rd-party libs
2020-06-05 16:43:49 <mps> dalias: no, aarch64
2020-06-05 16:44:01 <dalias> ahhh
2020-06-05 16:44:05 <mps> today I tested on 32bit, armv7
2020-06-05 16:44:09 <dalias> well on 64-bit it's not going to make any difference at all
2020-06-05 16:44:46 <mps> yes, and in my tests on armv7 everything is good
2020-06-05 16:45:04 <mps> though I use kernel 5.6 series
2020-06-05 16:45:20 <dalias> kernel shouldnt matter either
2020-06-05 16:45:57 <mps> yes, you told this earlier, I remember. but noted to give more info
2020-06-05 16:46:00 <dalias> unless you're setting system time to post-jan-2038, the kernel facilities used aren't any different
2020-06-05 16:46:06 <dalias> :)
2020-06-05 16:46:17 <dalias> (well except for a very small number of them)
2020-06-05 16:46:35 <mps> will the world survive till then :)
2020-06-05 16:47:47 <mps> well, world will for sure but humans, I'm not sure by reading news
2020-06-05 16:50:14 <mps> hmm, with musl 1.2.0 'free -m' => Mem:           3808        1002        2163         244         642        2516
2020-06-05 16:50:30 <mps> firefox run with 8 tabs
2020-06-05 16:50:43 <mps> dalias: congrats :)
2020-06-05 16:50:50 <dalias> hm?
2020-06-05 17:01:46 <ncopa> seems like chromium is getting worse. it hangs more often than before
2020-06-05 17:01:53 <ncopa> deadlock i think
2020-06-05 17:02:26 <Cogitri> Oof
2020-06-05 17:03:07 <dalias> ncopa, any obvious things like seccomp violations?
2020-06-05 17:06:31 <ncopa> no
2020-06-05 17:06:44 <ncopa> it has for several months been like that
2020-06-05 17:06:53 <ncopa> but it does not happen often
2020-06-05 17:07:13 <ncopa> but with latest release 83, it does happen more frequent
2020-06-05 17:07:28 <ncopa> i am having problems with using gmail and jira :-/
2020-06-05 17:08:17 <ncopa> now its weekend. hopefully i will have time to debug it next week
2020-06-05 17:10:31 <dalias> i just abandoned chromium a long time ago. too many anti-features and it never seemed stable on musl
2020-06-05 17:40:06 <Cogitri> I use FF since that tends to just work and is pretty fast since that quantum thingie too
2020-06-05 18:57:51 <Cogitri> Do we need/want a bot for gitlab to do things like automatically ticking the "Allow commits from contributors" box or auto pinging maintainers?
2020-06-05 18:58:07 <Cogitri> I have a severe case of no side project right now :D
2020-06-05 19:01:32 <maxice8> I need one that report changes from ABI laboratories
2020-06-05 19:01:47 <maxice8> Or that show files added or removed
2020-06-05 19:06:35 <Cogitri> That's actually a pretty neat idea
2020-06-05 19:06:46 <Cogitri> So it'd just comment on the MR once CI is done?
2020-06-05 19:14:07 <maxice8> Basically yeah
2020-06-05 19:18:25 <Cogitri> Sounds good
2020-06-05 19:19:00 <ikke> Doesn't checkpkg already do that?
2020-06-05 19:25:34 <Cogitri> It's not as visible though (you always have to remember to click on CI for that)
2020-06-05 19:25:49 <Cogitri> And doesn't do ABI checking other than soname differences, or does it?
2020-06-05 19:29:25 <Hello71> shouldn't that be integrated in checkpkg then
2020-06-05 19:29:59 <Hello71> seems like these tasks should be/are already in checkpkg, but maybe it would be good to have something that tries to extract relevant lines from CI output, similar to rust bot
2020-06-05 19:33:58 <Cogitri> Yes, that's what I had in mind too
2020-06-05 19:55:04 <Ariadne> so the deal with go on mips is that the kernel is too old
2020-06-05 19:55:26 <Ariadne> the good news is that the reverse-engineered NIC driver is almost ready :)
2020-06-05 19:58:57 <ikke> yay
2020-06-05 20:29:49 <Ariadne> kicked off rebuild of main/community/testing on ppc64le with -fno-common
2020-06-05 20:30:04 <Ariadne> Cogitri: ^
2020-06-05 20:33:12 <Cogitri> Nice
2020-06-05 20:38:28 <Hello71> gcc 9 or 10?
2020-06-05 21:16:55 <mps> ikke: curl is fixed in my lxc, Daniel (curl author) posted patch to me
2020-06-05 21:17:35 <mps> tomorrow I will prepare all and will need your help to update current MR for it
2020-06-05 21:22:19 <ikke> OK, nice
2020-06-05 21:22:27 <ikke> Just ping ne
2020-06-05 21:22:39 <mps> be assured :)
2020-06-05 21:22:49 <mps> and good night
2020-06-05 21:23:14 <ikke> You too
2020-06-05 21:51:16 <ikke> Bagder tweeted about it apperently :-)
2020-06-05 21:52:27 <ikke> https://twitter.com/bagder/statuses/1269019290671472640
2020-06-05 21:53:53 <ikke> At least, I assume thats what it was about
2020-06-05 21:59:19 <mps> 
ACTION pretends to sleep and don't see this :)

2020-06-05 21:59:28 <mps> yes, that is
2020-06-05 22:00:52 <ikke> :)
2020-06-05 22:03:36 <mps> he is very fine, I communicated with him earlier (not related to alpine) and he helped me a lot with curl
2020-06-05 22:04:12 <mps> fine and kind
2020-06-05 22:04:22 <ikke> yeah, following him on twitter, got the same feeling from there
2020-06-05 22:30:13 <[[sroracle]]> fwiw with adelie i've worked on integrating libabigail into checkapk
2020-06-05 22:30:35 <[[sroracle]]> works ok but it can be finnicky with the filenames of the .so
2020-06-05 23:49:05 <doggone> ncopa: I've noticed a regression in libvirt, I think due to https://git.alpinelinux.org/aports/commit/?id=25038632803727b7b8afee2cc844aa48ba37a29e
2020-06-05 23:50:03 <doggone> on a clean install of Alpine 3.12, add libvirt-qemu, qemu-img and qemu-system-x86_64, start the libvirtd service and run "virsh list" and it will hang indefinitely
2020-06-05 23:50:37 <doggone> upgrading Alpine 3.11 -> 3.12 will also not add this "qemu" user, adding to the problem
2020-06-05 23:53:09 <doggone> I can see some dirs being made, /var/lib/libvirt/qemu/domain-* owned by root. this always happens when I start my VMs from a local.d/ script. when I start them from the shell (as user root) they are created as owned by qemu:kvm
2020-06-05 23:53:51 <doggone> I think the root:root ownerships are what's hanging libvirtd
2020-06-06 00:00:48 <doggone> since I needed to rm those, zap+kill and start libvirtd to get it working again
2020-06-06 00:54:04 <kaniini> doggone: can you open a bug about this?  that way it doesn't fall through the cracks
2020-06-06 05:43:04 <clandmeter> mps: Nice! And nice tweet 👌
2020-06-06 05:50:46 <mps> clandmeter: :)
2020-06-06 05:50:56 <mps> and, goede morgen
2020-06-06 07:47:48 <Cogitri> Is it just me or is https://lists.alpinelinux.org/ down?
2020-06-06 07:49:36 <ikke> Works for me
2020-06-06 07:50:39 <Cogitri> Huh, seems like my DNS is busted
2020-06-06 07:53:06 <Cogitri> Ah, somehow I only got a IPv6 on my desktop
2020-06-06 08:13:49 <Ariadne> so far, -fno-common seems less bad than expected
2020-06-06 08:13:56 <Ariadne> only a few packages in main so far fail to build
2020-06-06 08:16:23 <mps> reading some bits around about gcc10 I have feeling that the -fno-common should be default for alpine
2020-06-06 08:19:11 <mps> how can I push changes to someone else MR from local git clone?
2020-06-06 08:20:27 <mps> I want to fix !7346 by adding patch which fixes failed test on armv7
2020-06-06 08:21:54 <mps> btw, testing this I see 'env: can't execute 'python': No such file or directory' in build log
2020-06-06 08:22:36 <mps> this is because there is not /usr/bin/python when python3 is installed
2020-06-06 08:23:37 <artok> patching shebangs to python -> python3 enough?
2020-06-06 08:25:25 <ikke> If the application is expecting / compatible with python3, then yes
2020-06-06 08:25:32 <mps> removing python2 is right solution
2020-06-06 08:26:23 <mps> hmm, removing python* :D
2020-06-06 08:26:25 <artok> removing python2 has been correct thing more than year now =)
2020-06-06 08:26:50 <ikke> mps: the user needs to enable it. If so you can add their repo as a remote, fetch and checkout that spe ific branch, add commits and push.
2020-06-06 08:27:02 <artok> actually after python 3.5 it's been right thing to do
2020-06-06 08:28:48 <mps> ikke: this sounds like a much and complicated work, is there some simpler method? - merge commit, it will fail on builders, add fixes and then 'git push origin'?
2020-06-06 08:34:09 <mps> or, get MR locally on top of the current clone of aports, fix, git commit, and 'git push origin'
2020-06-06 08:44:23 <mps> except this is not possible to do by me, I don't have rights to push to main :(
2020-06-06 08:44:59 <mps> our workflow in not good, really
2020-06-06 08:47:37 <mps> I hunted for bug, found problem, communicated with upstream, tested it and at the end I can't finish work :\
2020-06-06 09:02:32 <ikke> You certainly can
2020-06-06 09:20:57 <ikke> In the afternoon I can guide you through the process
2020-06-06 09:49:46 <mps> ikke: thanks, and thanks for your patience and kindness
2020-06-06 09:50:27 <russkel> hey mps, you play around with Raspberry pi's correct?
2020-06-06 09:52:09 <asmik> Hello, everyone! Can I ask someone to review my MR on cryfs? I've got it working, but I'm still confused jobs make flag
2020-06-06 09:52:22 <mps> russkel: yes, but not much. I'm trying to make alpine to use upstream kernels on RPis
2020-06-06 09:52:56 <russkel> could you take a quick look over an issue I am having and tell me if you've seen it before?
2020-06-06 09:53:11 <russkel> ubuntu-arm raspi kernel 20.04 however
2020-06-06 09:53:42 <mps> kernel 20.04?
2020-06-06 09:53:47 <russkel> correct
2020-06-06 09:53:52 <russkel> err
2020-06-06 09:54:07 <mps> or you mean ubuntu release
2020-06-06 09:54:25 <russkel> yeah release, I think it's 5.2.11
2020-06-06 09:54:34 <russkel> it's compiling otherwise I would tell you
2020-06-06 09:54:58 <mps> afaik, debian/ubuntu use heavily patched kernels
2020-06-06 09:55:59 <mps> russkel: what is the issue number
2020-06-06 09:56:10 <russkel> I have two usb devices plugged in, and after I spin up a program that connects to both of them (usb serial) the rpi shortly goes unresponsive
2020-06-06 09:56:15 <russkel> https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1880388
2020-06-06 09:57:09 <mps> 
ACTION looking

2020-06-06 09:57:59 <russkel> I believe it goes unresponsive because the mmc0 device stops responding and the whole thing stops working after that
2020-06-06 09:58:49 <russkel> but I have no idea what I'm talking about
2020-06-06 09:59:55 <mps> you are using u-boot as bootloader and not default RPi bootloader?
2020-06-06 10:00:29 <russkel> apparently so. I flashed whatever is provided by the ubuntu rpi image
2020-06-06 10:01:18 <russkel> ah it's 5.4.0 sorry
2020-06-06 10:01:57 <mps> I don't see in log it loads any dtb
2020-06-06 10:03:33 <russkel> doesn't seem very verbose does it
2020-06-06 10:04:41 <mps> and, yes, you are right probably, mmc driver doesn't work well
2020-06-06 10:05:43 <Cogitri> Hum, what creates the initial /etc/localtime symlink?
2020-06-06 10:07:32 <mps> Cogitri: setup-timezone
2020-06-06 10:07:51 <russkel> mps, I see. thanks for taking a look over
2020-06-06 10:08:09 <russkel> is the mmc driver in the kernel or dtb?
2020-06-06 10:08:41 <mps> russkel: could you try to run alpine 3.12 on board, maybe we then can help more
2020-06-06 10:09:17 <russkel> yeah would love to. problem is everything ROS2 is ubuntu. I did put some effort in adding alpine support some months back
2020-06-06 10:09:18 <mps> driver is in kernel, ofc, but parameters for speed (etc) are usually in dtb
2020-06-06 10:09:39 <mps> russkel: yes, I remember your effort
2020-06-06 10:09:55 <russkel> I should dust that off and get it merged into ROS2 actually
2020-06-06 10:10:53 <Cogitri> mps: Hmm...I somehow had that symlink even without running that
2020-06-06 10:12:23 <mps> Cogitri: I remember that when i installed alpine 'by hand' /etc/localtime didn't exists
2020-06-06 10:12:47 <mps> I had to create it manually
2020-06-06 10:13:39 <mps> russkel: these days I working on using upstream vanilla kernels on RPis
2020-06-06 10:13:55 <mps> ofc, when I find free time
2020-06-06 10:14:09 <mps> but I have only RPi zero w
2020-06-06 10:14:59 <russkel> ah I see. bit old that one haha
2020-06-06 10:15:39 <mps> for now it boots with linux-edge 5.6.14 and most things works, except I have to find which drivers need to be in initramfs/modloop or to make it 'in-kernel' and not as modules
2020-06-06 10:16:28 <russkel> If I can dig up a spare 3b+ would you be interested in it?
2020-06-06 10:16:41 <russkel> not sure if I could send it to you for less than one could buy it though
2020-06-06 10:16:48 <mps> actually I dislike RPis, they are worst of arm boards on the market, too much closed
2020-06-06 10:17:35 <russkel> yeah does seem fairly closed
2020-06-06 10:18:00 <russkel> what about the nanopi's?
2020-06-06 10:18:10 <mps> I prefer Allwinner and (nowadays) rockchip
2020-06-06 10:18:39 <russkel> Allwinner don't do anything haha!
2020-06-06 10:18:50 <russkel> rockchip, I see
2020-06-06 10:18:52 <mps> not that they are perfect but a lot easier to get info
2020-06-06 10:19:35 <mps> I have few different allwinner based boards, all works quite fine
2020-06-06 10:19:49 <russkel> I have an orangepi zero 2+
2020-06-06 10:19:57 <russkel> and it has been a nightmare haha
2020-06-06 10:21:09 <mps> didn't used any orange board yet
2020-06-06 10:21:27 <russkel> I can't sing their praises, I had to solder on a mosfet to get the thing to clock properly
2020-06-06 10:21:31 <russkel> 
ACTION facepalm

2020-06-06 10:24:39 <mps> yes, most if not all of the arm boards (and not only arm), have some design bugs
2020-06-06 10:25:52 <mps> if I have to make (again) mission critical and life risk devices I would use old 6502 8bit CPU
2020-06-06 10:27:03 <mps> and would use assembly and forth languages, not even C
2020-06-06 10:27:46 <russkel> not C? because of the UB?
2020-06-06 10:29:16 <mps> well, I don't know what compiler author put in it, i.e. did s/he had 'cleaver' ideas :)
2020-06-06 10:29:45 <russkel> what about the assembler :o
2020-06-06 10:30:11 <mps> actually, I would use RTX2000 CPU where forth is the assembler :)
2020-06-06 10:30:21 <detha> 6502 with its funny 256-byte zero page? If you're looking at that era,least grab a 6809 or Z80
2020-06-06 10:30:29 <mps> in assembler you know what you do
2020-06-06 10:31:15 <russkel> yep bloody rpi crashed again
2020-06-06 10:31:28 <russkel> only one usb device plugged in
2020-06-06 10:31:33 <mps> detha: no, I worked with both, z80 and 6502 (and learned 6809) but 6502 is most practical for me
2020-06-06 10:32:42 <russkel> what about compiling and then inspecting the disassembly ?
2020-06-06 10:33:40 <mps> easier and more safe to make assembly from beginning, you know what you do and what you mean
2020-06-06 10:34:58 <detha> z80 had kludged-on instructions with index registers, but 6809 wasn't a bad CPU
2020-06-06 10:35:17 <mps> programming in assembly is not hard as modern programmers think, especially those who introduced to programming by python or java/javascript/php.......
2020-06-06 10:35:47 <mps> detha: agree
2020-06-06 10:36:15 <detha> actually, I want a 68000. Nice, and almost completely orthogonal
2020-06-06 10:37:18 <russkel> mps, I've started learning it so I can read ghidra output
2020-06-06 10:37:20 <russkel> :D
2020-06-06 10:38:15 <mps> detha: wasn't 6809 that which have 'SEX' instruction ?
2020-06-06 10:38:20 <mps> :)
2020-06-06 10:38:35 <russkel> 
ACTION giggles

2020-06-06 10:38:46 <mps> sign extended
2020-06-06 10:40:13 <detha> it did
2020-06-06 10:40:27 <mps> russkel: try alpine on you RPi, it worked out-of-the-box for me
2020-06-06 10:40:45 <mps> and see if you hardware issue
2020-06-06 10:40:54 <russkel> I have tried on multiple rpis
2020-06-06 10:41:06 <russkel> we have a whole bunch of these turtlebot3s at work
2020-06-06 10:41:27 <russkel> and the manufacturer claims others are having this issue as well
2020-06-06 10:41:46 <mps> aha, then my experience is useless for you
2020-06-06 10:41:52 <russkel> thanks anyway
2020-06-06 10:42:02 <mps> np
2020-06-06 10:42:25 <russkel> and ROS is so dependent on ubuntu to get it running anywhere else is a nightmare
2020-06-06 10:43:18 <mps> sign of bad design, if it depends on it, I must to add. sorry
2020-06-06 10:43:38 <russkel> it's because of dependency hell
2020-06-06 10:45:09 <russkel> I mean you can compile it on anything, you just don't get to use their tools to do so
2020-06-06 13:38:22 <russkel> so lets say I wanted to create a bunch of alpine packages for ROS2
2020-06-06 13:38:41 <russkel> they provide package.xml files for each package that look like this:
2020-06-06 13:39:06 <russkel> https://github.com/ros2/rviz/blob/ros2/rviz2/package.xml
2020-06-06 13:40:22 <russkel> would I create a tool that fills out a APKBUILD template using those details? and then use ROS2 build tools to create the binaries
2020-06-06 13:41:00 <ikke> I guess so
2020-06-06 13:41:43 <russkel> righto then.
2020-06-06 13:43:09 <russkel> I wonder if I can host the packages on github. Has anyone hosted an apk repo on github before?
2020-06-06 13:43:52 <ikke> I haven't seen any hosting an actual repo (rather than the source) on github
2020-06-06 13:44:42 <russkel> the nvidia guys do it for their nvidia docker image files, pretty sneaky
2020-06-06 13:45:20 <russkel> https://github.com/NVIDIA/nvidia-docker/tree/gh-pages
2020-06-06 13:46:56 <russkel> I could probably get all the compiling working on github actions too, so it's an entirely automated thing
2020-06-06 13:47:00 <clandmeter> i have done it ones
2020-06-06 13:47:28 <russkel> clandmeter, yeah? Using github pages?
2020-06-06 13:47:37 <clandmeter> i think so
2020-06-06 13:47:41 <clandmeter> it is long time ago
2020-06-06 13:48:17 <russkel> did it work well?
2020-06-06 13:48:53 <clandmeter> it was just some test, i dont think it was really suitable but i dont remember anymore.
2020-06-06 13:49:24 <russkel> np
2020-06-06 14:04:39 <clandmeter> russkel: you could simply just try it. its free :)
2020-06-06 14:04:47 <russkel> I intend to ;)
2020-06-06 14:05:06 <russkel> I have a bit of other work to complete before I get to that point though
2020-06-06 14:20:33 <oneinsect> devs
2020-06-06 14:20:46 <oneinsect> https://git.alpinelinux.org/aports/tree/main/alpine-baselayout/APKBUILD
2020-06-06 14:20:56 <oneinsect> line 29
2020-06-06 14:21:07 <oneinsect> services-$pkgver-$pkgrel::https://salsa.debian.org/md/netbase/-/raw/v6.1/etc/services
2020-06-06 14:21:11 <oneinsect> throws an error?
2020-06-06 14:21:15 <oneinsect> while building?
2020-06-06 14:22:17 <oneinsect> mv cannot stat 'services-3.2.0-7' no such file or directory
2020-06-06 14:22:22 <oneinsect> prepare failed
2020-06-06 14:23:34 <Cogitri> That's https://git.alpinelinux.org/aports/tree/main/alpine-baselayout/APKBUILD#n35
2020-06-06 14:23:48 <Cogitri> I guess maybe it's missing a "$srcdir"/ in front of the filename?
2020-06-06 14:24:02 <oneinsect> correct
2020-06-06 14:24:18 <oneinsect> i mean does this instruction download a file
2020-06-06 14:24:19 <oneinsect> services-$pkgver-$pkgrel::https://salsa.debian.org/md/netbase/-/raw/v6.1/etc/services
2020-06-06 14:24:23 <oneinsect> ?
2020-06-06 14:24:41 <oneinsect> aah yes
2020-06-06 14:24:44 <oneinsect> it does download
2020-06-06 14:24:52 <oneinsect> missing a srcdir
2020-06-06 14:26:24 <oneinsect> prepare should have this line then
2020-06-06 14:27:15 <oneinsect> mv "$srcdir"/services-$pkgver-$pkgrel "$srcdir"/services
2020-06-06 14:27:29 <oneinsect> can you please correct it Cogitri:
2020-06-06 14:52:25 <u0jQx9gPyrYg> russkel: i would do this automatic building from github, if some of my pkgs would not trip the time limit of the CI instances (some pkgs take longer than 1h to build and thus the whole build is cancelled), but you can check it out here: https://github.com/jirutka/user-aports#how-to-setup-your-own-repository
2020-06-06 14:52:50 <u0jQx9gPyrYg> that is the original link and doc, not my repo btw
2020-06-06 14:54:40 <russkel> ah thanks, that's usedfu u0jQx9gPyrYg
2020-06-06 14:54:57 <russkel> what packages are taking you so long to build?
2020-06-06 14:55:02 <russkel> out of curiosity
2020-06-06 14:57:44 <u0jQx9gPyrYg> i'm not sure, i think it is cgal
2020-06-06 15:00:35 <russkel> isn't that in alpine already?
2020-06-06 15:14:22 <u0jQx9gPyrYg> it is
2020-06-06 16:09:52 <oneinsect> Cogitri: are you here
2020-06-06 16:10:02 <oneinsect> did you correct that line?
2020-06-06 16:11:28 <Cogitri> Currently busy studying, could you maybe make a MR for that?
2020-06-06 16:12:22 <oneinsect> aaah
2020-06-06 16:12:24 <oneinsect> alrite
2020-06-06 17:34:59 <mps> ikke: ping
2020-06-06 17:40:54 <ikke> pong
2020-06-06 17:41:47 <mps> you told me that you will help me afternoon with curl MR
2020-06-06 17:41:55 <mps> do you have time?
2020-06-06 17:42:31 <mps> if you don't, nvm
2020-06-06 17:49:37 <ikke> sure
2020-06-06 17:50:13 <mps> ?
2020-06-06 17:50:22 <ikke> I have time now
2020-06-06 17:51:48 <mps> ok, what is your idea about this
2020-06-06 17:52:12 <ikke> You want to contribute to the MR, right?
2020-06-06 17:52:54 <oneinsect> cogitri asked to make a MR request as well but i dont have infrastructure with me at the moment
2020-06-06 17:53:04 <oneinsect> let me see if i can do it from a friend's computer
2020-06-06 17:53:09 <mps> uhm, not sure. as you told author must allow this
2020-06-06 17:53:16 <ikke> what's the MR?
2020-06-06 17:53:29 <oneinsect> https://git.alpinelinux.org/aports/tree/main/alpine-baselayout/APKBUILD#n35
2020-06-06 17:53:33 <mps> !7346
2020-06-06 17:53:46 <oneinsect> should be
2020-06-06 17:53:48 <oneinsect> mv "$srcdir"/services-$pkgver-$pkgrel "$srcdir"/services
2020-06-06 17:53:55 <oneinsect> missing srcdir
2020-06-06 17:53:57 <ikke> mps: it is allowed
2020-06-06 17:54:36 <mps> ok
2020-06-06 17:55:21 <mps> how I should continue? create local branch and somehow pull this MR, or whole fork?
2020-06-06 17:55:51 <ikke> git remote add j0wi git@gitlab.alpinelinux.org:J0WI/aports.git && git fetch j0wi curl
2020-06-06 17:56:13 <ikke> git checkout curl
2020-06-06 17:56:21 <mps> ok, lets try and pray
2020-06-06 17:59:02 <ikke> Once you did that, you are on their branch, you can add the patch
2020-06-06 18:00:12 <mps> aha, and when finish 'git push j0wi' ?
2020-06-06 18:00:24 <ikke> yeah
2020-06-06 18:00:28 <mps> ok
2020-06-06 18:00:32 <ikke> easy, right?
2020-06-06 18:02:17 <mps> btw, do I need need to bump pkgrel
2020-06-06 18:04:29 <ikke> no
2020-06-06 18:04:50 <ikke> CI doesn't care about the version
2020-06-06 18:05:20 <mps> huh, lets see
2020-06-06 18:06:04 <mps> I pushed it, if you are interested to review
2020-06-06 18:07:27 <ikke> Looks good
2020-06-06 18:08:05 <mps> I tested in x86_64 and armv7 lxc locally
2020-06-06 18:08:44 <mps> only not satisfied with my commit message, anyone are free to reword it
2020-06-06 18:17:01 <mps> ikke: it passed on all CIs
2020-06-06 18:18:55 <ikke> good
2020-06-06 18:28:50 <mps> only one thing left, how can I remove j0wi remote from my git repo
2020-06-06 18:36:50 <superduck> I'm hoping to get feedback/discussion on this alpine-baselayout MR - https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8845
2020-06-06 18:44:36 <mps> is the 'git remote remove <name>' enough to clean my local repo from all traces of remote
2020-06-06 18:45:41 <ikke> yes
2020-06-06 18:45:56 <ikke> the curl branch remains though
2020-06-06 18:45:59 <ikke> until you remove that
2020-06-06 18:46:14 <mps> already removed it
2020-06-06 18:46:50 <mps> ikke: thanks for help
2020-06-06 18:47:29 <ikke> no worry
2020-06-06 18:48:00 <mps> but I still think this workflow is complicated, not that I have anything better
2020-06-06 18:48:29 <mps> so, we have to live with it :)
2020-06-06 18:49:30 <Hello71> you can use the web interface to suggest or make changes
2020-06-06 18:50:16 <ikke> mps: you can even directly fetch it into a local branch
2020-06-06 18:50:23 <ikke> no remote required
2020-06-06 18:50:33 <ikke> You just need to use the full url every time
2020-06-06 18:51:00 <ikke> git fetch <url> refs/heads/curl:refs/heads/curl
2020-06-06 18:51:32 <mps> Hello71: web, no thanks :)
2020-06-06 18:52:35 <mps> ikke: so 'git checkout -b curl && git fetch <url> refs/heads/curl:refs/heads/curl'
2020-06-06 18:53:48 <ikke> without the checkout
2020-06-06 18:54:02 <ikke> the fetch will create the branch
2020-06-06 18:54:15 <mps> aha, thanks for explanation
2020-06-06 18:54:34 <mps> but ...
2020-06-06 18:54:57 <mps> 
ACTION will try to resist urge to fix bugs introduced by other

2020-06-06 18:56:35 <mps> and actually I do, but can't left important pkgs in 'bad' state
2020-06-06 18:59:40 <superduck> Is Label "type:feauture" the word feature in another language or a portmanteau of feature and future?
2020-06-06 19:00:08 <ikke> heh :|
2020-06-06 19:07:28 <oneinsect> how do i submit my MR
2020-06-06 19:07:31 <oneinsect> https://gitlab.alpinelinux.org/atlury/aports/-/merge_requests/1
2020-06-06 19:07:58 <ikke> You need to change the target branch to alpine/aports master
2020-06-06 19:13:23 <oneinsect> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8930
2020-06-06 19:13:28 <oneinsect> Ask someone with write access to this repository to merge this request
2020-06-06 19:15:01 <ikke> Now you have to have patience :)
2020-06-06 19:15:08 <oneinsect> :D
2020-06-06 19:17:06 <oneinsect> btw AMD 3900x with 32GB Ram takes just 10 minutes to bootstrap where on i7-9750H laptop it took around 2 hours
2020-06-06 19:17:24 <oneinsect> bootstrap alpine*
2020-06-06 19:17:40 <oneinsect> intel is dying
2020-06-06 19:30:07 <Hello71> >laptop
2020-06-06 19:32:07 <Cogitri> I ran Exherbo (so source based) on a 8705G CPU on a 2-in-1 for some time, that was fun :D
2020-06-06 20:45:10 <maxice8> @Cogitri a bot that told users to make a proper commit title would be awesome
2020-06-06 20:46:31 <ikke> good documentation would be a start..
2020-06-06 20:50:53 <mps> maxice8: yes
2020-06-06 20:52:45 <Cogitri> Generally a QA bot would be neat
2020-06-06 20:53:15 <mps> Quality Assurance?
2020-06-06 20:54:11 <Cogitri> Yup
2020-06-06 20:55:07 <Cogitri> I think users usually don't check CI, especially not the linter pipeline
2020-06-06 20:55:17 <mps> agree
2020-06-06 23:19:38 <tru_tru> https://gist.github.com/truatpasteurdotfr/1638e84aaa020527b1d94c9a7b81d31e <- any reason why this would build under 3.11 but not on 3.12 ?
2020-06-06 23:28:48 <Cogitri> > Found non-PIE files that has SUID
2020-06-06 23:28:48 <Cogitri> Sounds likely
2020-06-06 23:29:28 <Cogitri> I think GOFLAGS default to buildmode=pie now, maybe you need to update your /etc/abuild.conf
2020-06-06 23:30:09 <tru_tru> nevermind, alpine 3.11 with go1.13.10 linux/amd64 produces an ET_DYN excutable, while on alpine 3.12 and go1.13.11 it is an ET_EXEC binary
2020-06-06 23:30:31 <tru_tru> oh! thanks @Cogitri
2020-06-06 23:32:18 <tru_tru> Cogitri: can I overload the /etc/abuild.conf GOFLAGS=buildmode=pie from the APKBUILD file ?
2020-06-06 23:33:30 <tru_tru> ie revert to the 3.11 behaviour only for this package
2020-06-06 23:33:43 <Cogitri> It's just a normal shell variable, you can do GOFLAGS="$GOFLAGS <newvalues>`
2020-06-06 23:34:00 <Cogitri> Ah, that's probably something you can't switch off (for good reason)
2020-06-06 23:34:30 <Cogitri> Just set buildmode=pie in your GOFLAGS, then it should be built with PIE and build will stop complaining (and you'll have a more secure binary)
2020-06-06 23:37:16 <tru_tru> ok thanks
2020-06-07 04:48:00 <russkel> are there tools for auto incrementing APKBUILDs and committing ?
2020-06-07 04:48:12 <[[sroracle]]> abump & apkgrel
2020-06-07 04:48:28 <[[sroracle]]> they're part of abuild pkg
2020-06-07 04:48:29 <russkel> come with the abuild toolset?
2020-06-07 04:48:33 <[[sroracle]]> yes
2020-06-07 04:48:34 <russkel> ah thanks [[sroracle]]
2020-06-07 04:54:14 <oneinsect> Cogitri:
2020-06-07 04:54:17 <oneinsect> are you awake
2020-06-07 04:54:25 <maxice8> No
2020-06-07 04:54:44 <oneinsect> lol
2020-06-07 04:54:59 <oneinsect> what does this mean "Please use the usual commit layout for alpine:" for the MR
2020-06-07 04:55:03 <oneinsect> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8930#note_94257
2020-06-07 04:55:33 <maxice8> he literally gave you an example below that sentence
2020-06-07 04:55:50 <maxice8> "<repository>/<package>: <summary>"
2020-06-07 04:56:29 <russkel> oneinsect, the commit message formatting
2020-06-07 04:57:04 <oneinsect> i did it via web editor, i do not have a proper linux, git setup at the moment with me
2020-06-07 04:57:17 <oneinsect> let me try to reformat it
2020-06-07 04:57:34 <russkel> you'll probably have to get one set up then in order to amend the commit messages
2020-06-07 04:57:52 <oneinsect> aaaah
2020-06-07 04:58:35 <russkel> that's my guess, web editors don't really have sophisticated features
2020-06-07 04:58:46 <oneinsect> yes correct
2020-06-07 04:59:15 <oneinsect> i mean i used the web ide available at gitlab of alpinelinux.org
2020-06-07 05:00:22 <russkel> yeah I assumed so
2020-06-07 07:34:31 <mps> s390x CI is stuck
2020-06-07 07:35:14 <ikke> kille one job that was running for 4h
2020-06-07 07:35:22 <ikke> (and doing nothing)
2020-06-07 07:36:50 <ikke> mps: you could just cancel the job and restart it
2020-06-07 07:37:26 <mps> ok
2020-06-07 09:13:24 <russkel> wait so is MIPS part of CI?
2020-06-07 09:13:53 <russkel> the gitlabs pipes CI, that is
2020-06-07 09:14:26 <Cogitri> Not yet because Go doesn't work on mips yet I think
2020-06-07 09:14:30 <Cogitri> And gitlab-runner needs Go
2020-06-07 09:16:05 <russkel> if I don't have anything to deal with MIPS failures in APKBUILD will it cause an issue somewhere?
2020-06-07 09:17:38 <Cogitri> If it fails on the builders we'll notice
2020-06-07 09:17:54 <Cogitri> The situation on that is a bit meh right now unfortunately
2020-06-07 09:18:05 <russkel> but it wont cause anything to light on fire?
2020-06-07 09:18:11 <russkel> just wont get a package for that arch
2020-06-07 09:18:49 <Cogitri> Well, we'll either fix it if it's an easy fix or just disable it on mips
2020-06-07 09:19:33 <russkel> can I also see builder logs?
2020-06-07 09:20:04 <Cogitri> https://build.alpinelinux.org/
2020-06-07 09:21:39 <russkel> thankya
2020-06-07 09:22:15 <russkel> I'm on the ROS2 war path again - more packages to add/modify :/
2020-06-07 09:28:56 <artok> russkel: what what
2020-06-07 09:29:16 <russkel> "whatwhat" what mate?
2020-06-07 09:29:17 <artok> doing ROS stuff?
2020-06-07 09:29:22 <russkel> yeah
2020-06-07 09:29:29 <artok> for what arch ?
2020-06-07 09:29:34 <artok> or "every" ?
2020-06-07 09:29:37 <russkel> https://github.com/russkel/rosdistro/issues/3
2020-06-07 09:29:42 <russkel> every
2020-06-07 09:29:51 <artok> well now
2020-06-07 09:30:04 <asriel> i actually do get this issue, but it's gone after i do a zap
2020-06-07 09:30:16 <asriel> whoops, sorry for that message ^ forwarded message to the wrong channel
2020-06-07 09:30:24 <asriel> stupid riot.im :)
2020-06-07 09:30:26 <artok> I just cross compiled opencv for alpine aarch64
2020-06-07 09:30:40 <russkel> poor soul
2020-06-07 09:30:51 <russkel> I have an APKGBUILD that will do that
2020-06-07 09:31:09 <russkel> it's a MR that has been closed because I never got to the bottom of test failures
2020-06-07 09:31:17 <artok> but wouldn't mind having that on again on apkbuild
2020-06-07 09:31:42 <russkel> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/2973
2020-06-07 09:32:31 <artok> and since now my x86_64 builder can run s390x, armv7l and ppc64le stuff, gonna get back to "native" build possibility and abuild
2020-06-07 09:32:44 <artok> (aarch64 ofcoz also target)
2020-06-07 09:33:46 <russkel> opencv is a beast
2020-06-07 09:34:30 <russkel> Cogitri, with that one, should be just disable checks and get it merged? I think everything works except for the tests itself haha
2020-06-07 09:34:37 <russkel> should we/I*
2020-06-07 09:34:55 <mps> first problem after upgrade to musl 1.2.0, one terminal hang-up, couldn't close with window manager
2020-06-07 09:36:04 <russkel> artok, are you a ROS-man/woman yourself?
2020-06-07 09:36:12 <russkel> ROS-person
2020-06-07 09:36:19 <artok> =D
2020-06-07 09:36:36 <artok> man having rpi4 that should do SLAM stuf
2020-06-07 09:37:00 <russkel> artok, I'm stuck with a bunch of turtlebot3s that keep crashing the RPI3b+ on ubuntu 20.04 :/
2020-06-07 09:37:59 <artok> 2 AVR boards, one is going to do sensor reading and another is going to drive motors
2020-06-07 09:38:12 <russkel> your own robot I take it?
2020-06-07 09:38:34 <artok> just building one
2020-06-07 09:38:42 <russkel> same here, personal project
2020-06-07 09:38:54 <russkel> I've got a bluepill stm32 for that purpose hehe
2020-06-07 09:39:10 <russkel> might even try get micro-ROS on it :o
2020-06-07 09:39:47 <artok> having small test platform, but the actual beast would be bigger, driven by wheelchair motors or something like that
2020-06-07 09:40:02 <russkel> I'm trying to get everything in place to build ros_base on alpine, if you didn't check out the github issue
2020-06-07 09:40:22 <russkel> end goal being an apk repo with all ros2 packages
2020-06-07 09:40:31 <artok> I did check that, might as well start digging that out rather than building all deps by myself
2020-06-07 09:40:39 <russkel> apk add ros-foxy-base
2020-06-07 09:40:42 <russkel> ;)
2020-06-07 09:41:17 <russkel> artok, you can switch to my rosdep rosdistro repo and then rosdep will bring in deps via apk
2020-06-07 09:41:30 <russkel> until I merge it into rosdistro proper
2020-06-07 09:41:44 <russkel> until it gets merged*
2020-06-07 09:41:56 <artok> my initial skeleton for dependency building cmake (yeah Cogitri, might be translating the main project to meson soon) is quite hassle
2020-06-07 09:42:40 <russkel> anything beyond ros_base isn't huge concern at the moment seeing as I don't intend to use alpine as a desktop
2020-06-07 09:42:45 <Cogitri> Good good, meson is nice :D
2020-06-07 09:42:46 <russkel> rather headless robots running alpine ;)
2020-06-07 09:44:15 <russkel> artok, what's the concept behind your robot?
2020-06-07 09:49:10 <artok> just to be powerful enough, to kill lawnmower robots that run with 35W ;)
2020-06-07 09:50:31 <russkel> 35W?
2020-06-07 09:51:01 <artok> I was reading that some Husqwarna lawnmower robots use 35W power while cutting the grass
2020-06-07 09:52:50 <russkel> ahh 35W
2020-06-07 09:52:54 <russkel> watt watt
2020-06-07 09:53:01 <ikke> 35 what?
2020-06-07 09:53:10 <ikke> :)
2020-06-07 09:53:21 <artok> whatt steam engine
2020-06-07 09:53:25 <russkel> why do you want to go around killing robots minding their own bizness?
2020-06-07 09:53:51 <artok> building it just for fun, might have application for it later
2020-06-07 09:53:58 <russkel> ;)
2020-06-07 09:57:02 <russkel> mine is a little RC car with a way over specced motor
2020-06-07 09:57:09 <russkel> which is probably > 35W
2020-06-07 09:57:12 <russkel> haha
2020-06-07 10:00:53 <artok> oh they have released new LTS
2020-06-07 10:01:08 <russkel> 
ACTION pokes Cogitri 

2020-06-07 10:01:15 <russkel> could you pls answer the above
2020-06-07 10:02:45 <Cogitri> Hm?
2020-06-07 10:03:10 <russkel> <russkel> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/2973
2020-06-07 10:03:16 <russkel> <russkel> Cogitri, with that one, should be just disable checks and get it merged? I think everything works except for the tests itself haha
2020-06-07 10:03:16 <russkel> <russkel> should we/I*
2020-06-07 10:03:37 <ikke> russkel: are you sure it's just the tests that are failing?
2020-06-07 10:04:03 <russkel> it compiles fine, and the issues seem to relate to memory
2020-06-07 10:04:13 <Cogitri> We have opencv with working tests now I think: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/opencv
2020-06-07 10:04:33 <russkel> am I sure? no way. but I've gotten no help from anyone incl. opencv on it and I don't have the hardware to test it
2020-06-07 10:04:37 <Cogitri> Ah nevermind
2020-06-07 10:04:42 <Cogitri> > options="!check" # Tests require human interaction
2020-06-07 10:05:00 <russkel> wait someone already merged opencv?
2020-06-07 10:05:53 <russkel> oh look at that
2020-06-07 10:07:02 <russkel> hmm he built with qt and vtk apparently..
2020-06-07 10:07:17 <russkel> I opted against that because it's more useful as a library than tools
2020-06-07 10:10:14 <russkel> and if you install it now, you bring in the graphical stack, presumably, incl x11 blah blah
2020-06-07 10:10:43 <Cogitri> Hm, can we split that out?
2020-06-07 10:11:03 <russkel> probably
2020-06-07 10:11:12 <russkel> more than happy to fix it when I get to that stage
2020-06-07 10:11:17 <artok> -tools -libs pleas
2020-06-07 10:12:04 <russkel> what's the rules on subpackages?
2020-06-07 10:12:12 <russkel> I would like to split out the video libs too
2020-06-07 10:12:19 <russkel> because they bring in a LOT
2020-06-07 10:14:33 <artok> why I can't see the APKBUILD on that merge request?
2020-06-07 10:15:14 <Cogitri> I think Gitlab likes to corrupt MRs during upgrades?
2020-06-07 10:15:23 <Cogitri> russkel: Split where it makes sense, I guess
2020-06-07 10:16:42 <artok> ok so that new 4.3.0 is x86_64 only
2020-06-07 10:16:58 <artok> russkel: get your APKBUILD somewhere so I can also check that =D
2020-06-07 10:17:06 <artok> meantime.. lunch
2020-06-07 10:19:04 <ikke> hmmmm, what's for lunch?
2020-06-07 10:37:40 <artok> baked potatoes with creamy salmon filling
2020-06-07 10:38:35 <ikke> not bad
2020-06-07 10:39:49 <mps> yes, salmon is always good
2020-06-07 10:41:02 <artok> scandinavian salmon
2020-06-07 10:41:29 <mps> eh, wild caught or from fish farm
2020-06-07 10:42:55 <mps> I like mackerel but nowadays is hard to find ones of good quality
2020-06-07 10:44:02 <artok> wild if available, but normally basic food stores have only farmed.. you can see that in price
2020-06-07 10:44:39 <mps> yes, right :-(
2020-06-07 10:49:29 <mps> time to invent time-machine, doesn't need to work for future, just few decades back :)
2020-06-07 10:51:16 <artok> I'd get to the point where that guy ate bat for dinner and kick his nuts
2020-06-07 10:52:28 <mps> heh, I read that they eat them for millennia
2020-06-07 10:53:34 <mps> so, this story about virus is doubtful
2020-06-07 11:15:59 <russkel> artok, yeah mate just a second
2020-06-07 11:17:19 <russkel> damn it really does corrupt it
2020-06-07 11:18:42 <russkel> artok, https://gitlab.alpinelinux.org/russkel/aports/-/blob/2344ab0c6aa9ee51cebf61e836231ec9ffd65679/testing/opencv/APKBUILD
2020-06-07 11:18:54 <ikke> corrupt, how?
2020-06-07 11:19:15 <russkel> ikke, loses the link to the original file
2020-06-07 11:19:43 <russkel> check out the MR I linked to half an hour ago, and then try and view the files in it
2020-06-07 11:19:58 <russkel> an hour ago*
2020-06-07 11:21:56 <ikke> hmm, I see
2020-06-07 11:22:27 <russkel> but it's still there, my branch is still on gitlab
2020-06-07 11:22:49 <ikke> Right, I guess it's not present in the parent project anymore
2020-06-07 11:22:53 <ikke> for some reason
2020-06-07 11:52:57 <russkel> hmm where is my babeltrace package rebuild?
2020-06-07 11:53:03 <russkel> the builders look idle
2020-06-07 11:56:06 <ikke> for most arches it's already built
2020-06-07 11:56:12 <Cogitri> https://pkgs.alpinelinux.org/packages?name=babeltrace&branch=edge seems like it already got built
2020-06-07 11:56:15 <ikke> except mips and x86_64, who are stuck
2020-06-07 11:56:36 <ikke> cloudi is blocking x86_64
2020-06-07 11:56:51 <maxice8> THere is an MR
2020-06-07 11:56:58 <maxice8> a mr*
2020-06-07 11:57:36 <ikke> It's still an mr
2020-06-07 11:57:46 <ikke> an "em ar"
2020-06-07 11:57:48 <russkel> oh oops I had the filter on x86_64
2020-06-07 11:57:58 <russkel> that's why it didn't show /me palmface
2020-06-07 11:59:13 <russkel> and now the build status is showing the edge builders doing something
2020-06-07 11:59:19 <russkel> sorry for crying wolf
2020-06-07 12:00:01 <ikke> fyi, you can also join #alpine-commits to see what is happening
2020-06-07 12:00:13 <ikke> though, it doesn't show what the builders are actively doing
2020-06-07 12:00:26 <ikke> just when they finished or fail
2020-06-07 12:00:49 <russkel> thanks, added to autojoin
2020-06-07 12:02:15 <Cogitri> Could someone give !8919 a lookover?
2020-06-07 12:03:14 <ikke> Looks good, nothing special
2020-06-07 12:10:35 <Cogitri> Hm, should the output of adduser be redirected to /dev/null?
2020-06-07 12:10:40 <Cogitri> So it doesn't show `adduser: user 'qemu' in use` during upgrades
2020-06-07 12:11:34 <ikke> Most install scripts seem to do that
2020-06-07 13:17:24 <artok> russkel, going to work on opencv now ?
2020-06-07 13:17:39 <russkel> artok, not super soon
2020-06-07 13:17:53 <russkel> once I get ROS2 building, probably
2020-06-07 13:18:01 <russkel> wont be this weekend though
2020-06-07 13:18:19 <russkel> the APKBUILD I linked you to is pretty decent
2020-06-07 13:19:28 <artok> seems so, will take that and start running builders on that and tests
2020-06-07 13:22:04 <artok> just needs libtbb to be enabled for others than x86_64 and x86
2020-06-07 13:22:39 <artok> ..or not
2020-06-07 13:23:02 <artok> using openmp ther
2020-06-07 13:23:16 <z3ntu> `ERROR: gtk4.0-3.98.5-r0: trying to overwrite usr/lib/girepository-1.0/Pango-1.0.typelib owned by pango-1.44.7-r2.`
2020-06-07 13:23:19 <artok> I'll get coffee and go to roof
2020-06-07 13:23:30 <artok> back later evening
2020-06-07 13:23:32 <ikke> okeuday: ping
2020-06-07 13:25:32 <Cogitri> z3ntu: Oof
2020-06-07 13:26:33 <z3ntu> uhm also seemingly every gtk package is depending on gtk4.0 now on my install?
2020-06-07 13:26:34 <Cogitri> gtk4 now builds its own pango version because it needs pango >= 1.45, I'll go ahead and remove the GIR files since it should only need the static lib I think
2020-06-07 13:26:41 <Cogitri> Huh
2020-06-07 13:26:55 <z3ntu> World updated, but the following packages are not removed due to:
2020-06-07 13:26:55 <z3ntu>   gtk4.0: gst-plugins-base gst-plugins-bad qt5-qtmultimedia qt5-qtspeech knotifications kio knewstuff konsole kparts knotifyconfig kwallet ktextwidgets sway postmarketos-ui-sway gtk+3.0
2020-06-07 13:26:55 <z3ntu>           libcanberra-gtk3 pavucontrol chromium waybar gtk-layer-shell gtkmm3 librsvg gnome-themes-extra lightdm adwaita-gtk2-theme adwaita-icon-theme gimp gegl gtk+2.0 pangomm
2020-06-07 13:27:17 <z3ntu> maybe because gtk4.0 is providing pango and apk thinks gtk4.0 is a good provider for pango?
2020-06-07 13:27:26 <Cogitri> Possibly
2020-06-07 13:28:08 <z3ntu> https://pastebin.com/raw/FPMvSX0x
2020-06-07 13:28:12 <z3ntu> apk upgrade log
2020-06-07 13:28:30 <z3ntu> > (31/31) Purging pango (1.44.7-r2)
2020-06-07 13:28:32 <z3ntu> well...
2020-06-07 14:14:28 <russkel> ppc64 on gitlab runner is MIA
2020-06-07 14:22:30 <Cogitri> z3ntu: Sorry for the breakage, I think I'll just revert the bump...
2020-06-07 14:22:41 <Cogitri> Pango static linking is very broken apparently, so I can't just do that
2020-06-07 14:26:15 <Cogitri> Error relocating /usr/bin/gtk4-demo: : symbol not found
2020-06-07 14:26:15 <Cogitri> Error relocating /usr/bin/gtk4-demo: /�X: symbol not found
2020-06-07 14:26:33 <Cogitri> OK then, symbol "" and "/�X" not found :D
2020-06-07 14:27:50 <nmeum> currently trying to upgrade community/rethinkdb to eventually allow building it with python3. it builds its own ancient version of nodejs and fails somewhere down the line while doing so m)
2020-06-07 14:28:01 <Cogitri> Oof
2020-06-07 14:31:51 <Cogitri> z3ntu: Reverted the gtk4 upgrade, I hope apk just lets you downgrade with `apk upgrade -a` once the builders are done
2020-06-07 14:32:30 <Cogitri> Erm, do I need a pkgrel bump on a downgrade so the builders do stuff?
2020-06-07 14:32:54 <nmeum> for reverts? yes probably
2020-06-07 14:33:53 <Cogitri> Seems like half of the builders picked it up and the other half didnt :D
2020-06-07 14:34:10 <Cogitri> Ah nevermind, gtk4 is disabled on those :)
2020-06-07 14:34:18 <Cogitri> So a pkgrel bump isn't required apparently
2020-06-07 14:36:23 <nmeum> this rethinkdb aport is a mess, unless somebody wants to actually maintain it I would just vouch for removing it
2020-06-07 14:37:23 <nmeum> the person in the maintainer comment has just one commit from 2016 and that's the commit which added this aport
2020-06-07 14:45:30 <Cogitri> I wouldn't mind removing it
2020-06-07 14:45:46 <Cogitri> A version from 2016 probably isn't useful anyway
2020-06-07 14:49:08 <mps> imo, there are more candidates for removal or move to unmaintained
2020-06-07 14:50:14 <Cogitri> Yup
2020-06-07 14:50:25 <ikke> russkel: It happens from time to time on s390x that the job gets stuck on some initialization
2020-06-07 14:50:33 <ikke> jobs should be running now
2020-06-07 14:50:45 <russkel> thanks ikke, yeah I have witnessed this before
2020-06-07 14:55:46 <hjaekel> Cogitri, do you think !8218 and !8568 can be merged or do you see open points?
2020-06-07 15:08:01 <z3ntu> Cogitri: worked!
2020-06-07 15:08:03 <z3ntu> (1/29) Installing pango (1.44.7-r2)
2020-06-07 15:08:08 <z3ntu> (3/29) Purging gtk4.0 (3.98.5-r0)
2020-06-07 15:11:54 <Cogitri> Good :)
2020-06-07 15:12:08 <Cogitri> hjaekel: I can take a look later
2020-06-07 15:12:49 <hjaekel> thanks Cogitri
2020-06-07 15:52:04 <ikke> FYI, in 10 minutes I will be upgrading our gitlab instance
2020-06-07 16:00:39 <ikke> restarting gitlab now
2020-06-07 16:04:30 <ikke> Started again, nice
2020-06-07 16:04:59 <Cogitri> Nice and quick :)
2020-06-07 16:05:35 <ikke> Yup
2020-06-07 16:21:05 <artok> what broke now ? ;)
2020-06-07 16:22:49 <ikke> Did anything broke?
2020-06-07 16:22:57 <ikke> break*
2020-06-07 16:25:02 <artok> full reload of page helped, static stuff was not loading, css etc lost
2020-06-07 16:25:40 <ikke> aha, ok. We just upgraded gitlab
2020-06-07 16:25:51 <ikke> But I haven't seen that behaviour before
2020-06-07 20:35:23 <okeuday> ikke: pong
2020-06-07 20:35:41 <ikke> okeuday: Was regarding cloudi
2020-06-07 20:36:16 <ikke> I was trying to understand the situation with those tests
2020-06-07 20:37:21 <okeuday> ikke: my understanding is that Erlang/OTP has trouble running in containers, but 23.0 is able to use the CPU quota set to create its default schedulers, which makes Erlang/OTP not have major problems getting access to the cpus
2020-06-07 20:39:30 <okeuday> ikke: so, the LXC containers should be setting CPU quotas, if they are using limits.cpu config.  The problem appears as a timeout in the CloudI test because the test isn't getting CPU while time elapses (as seen by clock_gettime CLOCK_MONOTONIC) in the Erlang/OTP code
2020-06-07 20:42:48 <okeuday> I set the timeout value to be extra large, as 10 minutes instead of the 10 seconds on bare-metal, but that didn't avoid the problem, so it should be a container config thing, I don't think setting the number of Erlang/OTP schedulers to 1 would avoid the problem too
2020-06-07 20:42:58 <okeuday> but it might cause the problem to happen less often
2020-06-07 20:43:54 <ikke> We are not using any quotas / limits for our containers though
2020-06-07 20:44:39 <okeuday> ikke: if you did add a cpu quota, that should fix the problem and that may be helpful for other builds too, if they are time dependent stuff
2020-06-07 20:46:04 <ikke> but that would mean we would slow down things just to fix these tests, not?
2020-06-07 20:46:41 <okeuday> ikke: it shouldn't slow down things to add the cpu quota, the cpu quota is only being specific about what executes where
2020-06-07 20:47:21 <okeuday> at least that is my expectation, I haven't tested that
2020-06-07 20:48:12 <ikke> We want these build containers to be able to use all the available resources / cores
2020-06-07 20:48:52 <okeuday> ikke: the problem is when something is building and it sees more cores than it is able to use, so it can get stuck when trying to use cores it isn't allowed to
2020-06-07 20:49:08 <ikke> What do you mean, is not allowed to..
2020-06-07 20:49:20 <ikke> by what?
2020-06-07 20:49:35 <okeuday> ikke: because other builds are using the cores it wants to use, and it can't see that the cores are taken unless there is a cpu quota set
2020-06-07 20:49:59 <ikke> okeuday: that's just something the kernel scheduler handles
2020-06-07 20:50:35 <okeuday> ikke: it handles it, but slowly, so the time elapsed can impact testing, it doesn't matter when things don't depend on time
2020-06-07 20:51:11 <ikke> so I guess erlang relies on being able to use dedicated cores, but we don't want to dedicate cores to builders, because that would severly limit our throughput
2020-06-07 20:51:58 <okeuday> ikke: yeah, Erlang generally wants to dominate the cores it has access to, so it is probably best to keep the CloudI tests disabled
2020-06-07 20:52:08 <ikke> But the strange thing is, if it relies on what other jobs there are running, it should be much more 'flaky'
2020-06-07 20:52:17 <ikke> Most of the time, there is just a single build running
2020-06-07 20:52:54 <ikke> so I would not expect these tests to fail reliably
2020-06-07 20:53:34 <ikke> I just ran it in my personal LXC container (now with tests), and they just succeeded
2020-06-07 20:53:46 <okeuday> ikke: it is a random problem that would depend on where the Erlang schedulers are running, it was able to pass for the merge, but it can fail after the merge, I don't want the tests to be a pain for other changes
2020-06-07 20:54:19 <ikke> okeuday: understood
2020-06-07 20:54:26 <ikke> but it failed every time on the builders
2020-06-07 20:54:39 <ikke> It's not that it failed one or two times, and then succeeded
2020-06-07 20:54:46 <okeuday> ikke: I don't understand why that is the case, I thought it was random there too
2020-06-07 20:54:57 <ikke> So something is not adding up :)
2020-06-07 20:55:30 <ikke> My suspicion is that something else is going on
2020-06-07 20:56:03 <okeuday> ikke: the test that fails is just Erlang code executing stuff in batch inside, so it matters that it is time dependent but it shouldn't be a slow filesystem or something like that, unless it is the load of applications possibly from the filesystem
2020-06-07 20:56:33 <okeuday> if the filesystem was a problem, I wouldn't expect that test to fail
2020-06-07 20:57:22 <ikke> Might be hardware related perhaps
2020-06-07 20:58:10 <ikke> and strange thing is that it only seemed to fail on x86_64
2020-06-07 20:58:50 <okeuday> ikke: then hopefully it is something related to that machine, like the hard drive, that would make more sense
2020-06-07 21:00:43 <okeuday> ikke: oh, if the clocksource was set in a weird way that would cause problems
2020-06-07 21:01:37 <okeuday> (cat /sys/devices/system/clocksource/clocksource0/current_clocksource)
2020-06-07 21:02:18 <ikke> tsc
2020-06-07 21:02:42 <okeuday> ikke: that is the normal default, so that isn't unusual
2020-06-08 08:25:26 <Ariadne_> did my team maintenance proposal make sense?  i think its pretty straightforward
2020-06-08 08:33:53 <[[sroracle]]> sounds good to me
2020-06-08 08:34:21 <[[sroracle]]> this is tangential to it but i wonder if it would make sense to also transition to using gitlab usernames for maintainer fields in general
2020-06-08 08:34:36 <[[sroracle]]> would make it easier to tag people in the future
2020-06-08 08:34:49 <Cogitri> As long as it's not mandatory to be in a team to be permitted touch an APKBUILD it's fine by me
2020-06-08 08:35:59 <Cogitri> I just don't want to have the mentality of "That's _MY_ APKBUILD, how dare you make changes to it" which some other distros have. I mean asking maintainers for major changes to an APKBUILD certainly makes sense, but I don't feel like asking the maintainer for permission for every minor change
2020-06-08 08:36:50 <Cogitri> [[sroracle]]: If you do `@$REALNAME` in Gitlab it'll show you the nickname
2020-06-08 08:37:12 <Cogitri> E.g. if you start typing @Rasmus in Gitlab it'll shoe you `Cogitri Rasmus Thomsen` so you could ping me without knowing my username
2020-06-08 08:41:00 <mps> I dislike idea about 'teams for particular package/s'
2020-06-08 08:41:49 <mps> and every pkg in alpine is separate, there are no pkg groups
2020-06-08 08:46:35 <[[sroracle]]> Cogitri: it's more about centralizing development on gitlab than discoverability, sorry if that wasn't clear
2020-06-08 08:47:08 <[[sroracle]]> i got emailed a few weeks ago about a package because of this
2020-06-08 08:47:47 <Cogitri> Oh, fair, I sometimes get mails too when Gitlab issues would be a better place for that
2020-06-08 08:58:26 <russkel> oh my shell completions have to be moved
2020-06-08 09:03:24 <russkel> that's a lot of boilerplate APKBUILD for shell completion scripts
2020-06-08 09:03:30 <russkel> https://git.alpinelinux.org/aports/tree/community/ripgrep/APKBUILD
2020-06-08 09:03:44 <Cogitri> No need to do that anymore
2020-06-08 09:03:53 <Cogitri> Just declare the subpkgs and abuild will do everything for you
2020-06-08 09:04:20 <russkel> bless you Cogitri, bless you
2020-06-08 09:04:36 <russkel> +usr/share/vcstool-completion/vcs.tcsh
2020-06-08 09:04:39 <russkel> what about this one?
2020-06-08 09:06:14 <russkel> I'll rm it, doesn't seem to be any tcsh completion packages in the pkg list
2020-06-08 09:10:09 <mps> russkel: we are trying to preserve upstream files as much as possible and makes sense, though not strict rule
2020-06-08 09:12:38 <mps> upstreams usually aren't happy to see their packages 'crippled' in distros
2020-06-08 09:14:57 <russkel> hmm, apparently I have to move the file because abuild errored
2020-06-08 09:15:11 <russkel> https://gitlab.alpinelinux.org/russkel/aports/-/jobs/137749#L416
2020-06-08 09:15:38 <russkel> mps, so I manually create the tcsh subpkg?
2020-06-08 09:22:07 <mps> I don't know for this particular case what should be done, I'm talking in general
2020-06-08 09:22:40 <mps> but when similar things arises I try to fix it 'manually'
2020-06-08 09:25:49 <russkel> hmm okay
2020-06-08 09:31:30 <russkel> I don't even know where it goes
2020-06-08 09:32:24 <mps> $pkgname-tcsh-completion, maybe
2020-06-08 09:33:08 <russkel> oh yeah I get that, but the location
2020-06-08 09:33:21 <mps> or, $pkgname-tcsh-complete, to follow tcsh naming
2020-06-08 09:33:44 <russkel> I can't find the tcsh complete folder
2020-06-08 09:33:49 <russkel> directory path
2020-06-08 09:34:00 <mps> though we don't have any tcsh-complete package
2020-06-08 09:36:40 <mps> maybe /usr/share/tcsh-completion or /usr/share/tcsh-completion/completions
2020-06-08 09:38:16 <mps> I have tcsh completion files around, maybe I should create pkg and push
2020-06-08 09:39:34 <mps> will look later today how it is done in some other distros
2020-06-08 09:39:38 <russkel> used the latter suggestion
2020-06-08 09:44:58 <mps> hmm, debian have only this /usr/share/doc/tcsh/examples/complete.tcsh.gz
2020-06-08 09:46:31 <mps> arch linux (looks like) /etc/profile.d/tcsh-complete
2020-06-08 09:48:02 <mps> this need to be consolidated
2020-06-08 09:54:00 <russkel> I'll just go with earlier suggestion, someone else can deal with obscure shells haha
2020-06-08 09:57:40 <mps> this shell is default on macOS
2020-06-08 10:01:19 <russkel> I have macOS and I'm fairly sure it's bash?
2020-06-08 10:01:45 <Cogitri> I think macOS recently switched to ZSH as default
2020-06-08 10:01:56 <russkel> wutwutwut
2020-06-08 10:03:42 <russkel> but the default for new accounts became bash as of 10.3 then zsh as of 10.15.
2020-06-08 10:10:06 <mps> interesting, they switched to GPL licensed shell to be defualt. Didn't know because I do not use macOS
2020-06-08 10:16:42 <russkel> that was a paste from the wiki
2020-06-08 10:16:54 <russkel> I switched to zsh the minute I can fire up a term haha
2020-06-08 10:23:10 <artok> heh
2020-06-08 10:24:04 <artok> zsh is good indeed
2020-06-08 10:27:17 <artok> russkel: was there some reason that you had opencv 4.2.0 , not opencv 4.3.0 ?
2020-06-08 10:27:32 <russkel> when I was doing it 4.2.0 was the latest
2020-06-08 10:27:43 <artok> reason good enough
2020-06-08 10:27:59 <russkel> can't git pull from the future, mate!
2020-06-08 10:28:00 <russkel> ;)
2020-06-08 11:15:16 <artok> qt vs gtk ..
2020-06-08 11:34:04 <Cogitri> artok: Hmmm?
2020-06-08 12:25:50 <russkel> artok, I like how complete Qt is
2020-06-08 12:25:54 <russkel> but I haven't done much with it
2020-06-08 12:28:03 <russkel> I think I will create some handy python tools that have a wizard interface
2020-06-08 12:29:57 <Cogitri> GTK's nice because you can use it in loads of langs, instead of only C++/Python, but I guess this is getting a bit offtopic :)
2020-06-08 12:40:28 <russkel> I only noticed I was in the commit credits of the past few releases of alpine
2020-06-08 12:40:34 <russkel> was surprised to see my name in the list haha
2020-06-08 12:49:05 <wsinatra> Anyone mind merging !8913 it should be good to go
2020-06-08 13:15:23 <artok> Cogitri: well there is just that enable gtk stuff or qt stuff or both for opencv
2020-06-08 13:15:40 <russkel> ohhh
2020-06-08 13:15:41 <artok> ...still trying to keep the runtime libs as small as possible
2020-06-08 13:15:50 <russkel> doesn't matter then
2020-06-08 13:15:57 <russkel> I disabled both
2020-06-08 13:16:11 <russkel> don't really care for their apps
2020-06-08 13:16:20 <russkel> or know what they do
2020-06-08 13:16:32 <artok> and I enabled opencl and vulkan stuff and so on...
2020-06-08 13:16:50 <Cogitri> Maybe we can split that stuff into subpkgs?
2020-06-08 13:17:01 <russkel> does that work on all archs?
2020-06-08 13:17:09 <artok> yah, that's what I'm planning
2020-06-08 13:17:33 <artok> just build first as much as possible and then check how to split things =)
2020-06-08 13:19:08 <russkel> tbh I don't know how it actually works.. if the libraries bring in those deps, if they work if you don't have vulkan etc etc
2020-06-08 13:19:23 <russkel> it's all very complicated
2020-06-08 15:13:00 <markand> looks like libexecinfo is broken on Alpine
2020-06-08 15:13:14 <markand> at least, in Ardour it really crashes the program
2020-06-08 15:16:37 <Cogitri> #10896 ?
2020-06-08 15:16:54 <Cogitri> The V language creator apparently hit something like that too
2020-06-08 15:17:02 <Cogitri> But I don't really know such lowlevel stuff, so dunno :)
2020-06-08 15:33:15 <ncopa> markand: yeah libexcinfo is broken
2020-06-08 15:33:37 <ncopa> i think it may work if packages using it is built with the right compile flags
2020-06-08 15:33:39 <markand> I disabled it for Ardour for now
2020-06-08 15:33:46 <ncopa> sounds good
2020-06-08 15:33:50 <ncopa> how does Ardour use it?
2020-06-08 15:34:03 <ncopa> to generate backtraces in case of a segfault?
2020-06-08 15:34:17 <markand> yes I think, but it's optional
2020-06-08 15:34:54 <markand> now when there is a critical error it just reports that the system does not have backtrace support but no longer crashes
2020-06-08 15:34:57 <ncopa> it is generally a bad idea to do so from security perspective
2020-06-08 15:35:48 <ncopa> i mean try to recoer from a crash and print backtrace in an undefined state
2020-06-08 15:35:52 <ncopa> recover*
2020-06-08 15:35:55 <markand> yes
2020-06-08 15:35:59 <markand> I fully agree
2020-06-08 15:36:16 <ncopa> much better to crash and generate a coredump
2020-06-08 15:49:28 <Cogitri> Anyone wants to push something? I want to merge the chromium update, but that'll block the builders for a while
2020-06-08 15:53:19 <mps> Cogitri: there is old saying "who first come to girl, girl is his" :)
2020-06-08 15:53:29 <mps> so, do it
2020-06-08 15:56:01 <artok> "...unless it's Arto and the girl runs away"
2020-06-08 15:56:23 <artok> don't forget the last part of the saying
2020-06-08 15:56:51 <mps> hmm, who is Arto?
2020-06-08 15:57:11 <ikke> Arto K?
2020-06-08 15:57:42 <mps> I guessed so :D
2020-06-08 15:57:45 <artok> =)
2020-06-08 16:02:20 <TBB> daamn. I'm a finn and I always thought of Artok as a Russian name.
2020-06-08 16:02:39 <artok> self-deprecation humour works
2020-06-08 16:03:19 <artok> hah =D
2020-06-08 16:33:31 <oneinsect> so is artok russian or not
2020-06-08 16:33:50 <artok> no, finnish jaloviina drinker
2020-06-08 16:33:51 <oneinsect> conclusion?
2020-06-08 16:33:55 <oneinsect> lol
2020-06-08 16:42:44 <kaey> there is no such name in russian
2020-06-08 16:51:44 <artok> https://termbin.com/lqdn  ..opencv splitted, library that depends on qt splitted out and tools as own..
2020-06-08 16:52:01 <Cogitri> 👍️
2020-06-08 17:11:30 <artok> whee !9011
2020-06-08 17:13:15 <artok> needs to test on all archs
2020-06-08 18:39:07 <artok> which linter commands CI had?
2020-06-08 18:39:42 <ikke> sorry?
2020-06-08 18:40:11 <artok> shellcheck etc?
2020-06-08 18:40:34 <ikke> abuild checkpkg, shellcheck and apkbuild-lint from atools
2020-06-08 18:40:43 <ikke> s/checkpkg/sanitycheck
2020-06-08 18:40:43 <alpine-meetbot> ikke meant to say: abuild sanitycheck, shellcheck and apkbuild-lint from atools
2020-06-08 18:41:03 <artok> yahs
2020-06-08 18:42:05 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/apkbuild-lint-tools
2020-06-08 18:42:14 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/apkbuild-lint-tools/-/blob/master/overlay/usr/local/bin/lint
2020-06-08 20:10:47 <mps> kaey: Artjom, name in Russia? similar to Arto
2020-06-09 08:32:41 <mps> are PCMCIA drivers needed in current kernels?
2020-06-09 08:32:55 <ncopa> i guess not
2020-06-09 08:34:23 <mps> I didn't used PCMCIA devices in last 15 years, at least
2020-06-09 08:34:28 <mps> maybe more
2020-06-09 08:35:21 <mps> and most of VGA old drivers
2020-06-09 08:43:41 <ncopa> lets disable them
2020-06-09 08:43:50 <ncopa> we should start with a releases notes for 3.13
2020-06-09 08:44:37 <mps> yes, and maybe create issue on gitlab.a.o
2020-06-09 08:45:27 <mps> what maxice8 did on wiki is good but maybe gitlab would be more active
2020-06-09 08:45:43 <Cogitri> I think the wiki is better since anyone can edit those
2020-06-09 08:46:15 <Cogitri> On Gitlab you'd just add a comment for each new item which will become confusing quickly
2020-06-09 08:46:25 <ncopa> indeed
2020-06-09 08:46:33 <ncopa> isnt there a wiki in gitlab too?
2020-06-09 08:46:51 <ikke> It's backed by a git repository
2020-06-09 08:46:54 <mps> heh, this is what I wanted to propose to use
2020-06-09 08:47:11 <ikke> Although you can use the webinterface to edit it
2020-06-09 08:48:05 <mps> Cogitri: wiki cannot edit anyone, only registered users
2020-06-09 08:48:17 <Cogitri> mps: Well, registering an account isn't hard
2020-06-09 08:48:20 <mps> same is with gitlab
2020-06-09 08:48:29 <Cogitri> And without that our Wiki would probably be one kind of a spam board :D
2020-06-09 08:48:40 <Cogitri> Right, the Gitlab wiki could work too
2020-06-09 08:49:13 <mps> and, I'm not sure that anyone should have rights to edit release notes
2020-06-09 08:49:17 <ncopa> i think we should have an issue category "localizatin" or similar
2020-06-09 08:53:00 <Cogitri> Hum, what for?
2020-06-09 08:53:05 <Cogitri> And by category you mean a label?
2020-06-09 08:55:55 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/labels/289/edit :)
2020-06-09 08:56:03 <ikke> Feel free to add a proper description
2020-06-09 09:19:26 <nmeum> afontain_: just FYI https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9037
2020-06-09 09:22:47 <afontain_> thanks, acknowledged
2020-06-09 09:39:05 <ncopa> maxice8: since you removed the `python` (5ad0ec7da1064361cc74d56edf7524960f49ef9b),  would you like to respond on this? https://github.com/alpinelinux/docker-alpine/issues/83#issuecomment-637701763
2020-06-09 09:59:16 <ncopa> Cogitri: thanks!
2020-06-09 09:59:39 <Cogitri> :)
2020-06-09 09:59:55 <Cogitri> Did we have that in the relase notes? If not, we should probably add it
2020-06-09 10:09:25 <ncopa> yes. it should be added
2020-06-09 10:10:08 <ncopa> https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests
2020-06-09 10:10:39 <Cogitri> Oh, it's a git repo, neat
2020-06-09 10:10:59 <nmeum> maybe we should start gathering important changelog items earlier to make sure we don't forget them when it's time to create the release notes
2020-06-09 10:11:16 <ikke> nmeum: That already happened with 3.12
2020-06-09 10:11:20 <nmeum> ah
2020-06-09 10:11:34 <nmeum> right, there was this wiki page
2020-06-09 10:11:45 <ikke> It's kind of my fault that it's missing
2020-06-09 10:14:38 <ncopa> lets add it
2020-06-09 10:15:17 <ncopa> (I am slightly busy now though...)
2020-06-09 10:15:52 <ikke> I can add it during lunch
2020-06-09 10:20:48 <ncopa> awesome. thanks!
2020-06-09 10:52:22 <ikke> Does this look good? https://tpaste.us/Z0vl
2020-06-09 10:58:43 <Cogitri> LGTM
2020-06-09 11:04:32 <artok> Cogitri: I seem to take a quite project to work with.. as opencv unittests seem to fail quite heavily =D
2020-06-09 11:05:51 <artok> going to be helluva lot more submodules to keep things lean for those who just want basic object detection and camera calibration
2020-06-09 11:06:04 <artok> but eh, just more work
2020-06-09 11:29:41 <nmeum> did we come to consensus yet on #11324, just going through my old MRs and as announced in the issue I would go ahead and remove dns-root-hints from unbound soonish unless there are objections. not sure about the other packages though
2020-06-09 11:30:02 <russkel> artok, not too heavily
2020-06-09 11:30:14 <russkel> it's only the video and NN tests from what I remember
2020-06-09 11:30:40 <russkel> the former being weird memory issues on 32b platforms
2020-06-09 11:31:15 <artok> have you checked out the contrib directory? =)
2020-06-09 11:31:42 <artok> sfm modules etc..
2020-06-09 11:32:34 <artok> more reading their cmake files ->
2020-06-09 11:32:57 <russkel> did I try and compile contrib?
2020-06-09 11:33:17 <russkel> I don't remember
2020-06-09 11:33:43 <russkel> tbh that's life getting things working on alpine
2020-06-09 11:44:00 <artok> actually opencv is the one that gives more pain than the target distro =)
2020-06-09 11:53:42 <russkel> yeah but a lot of stuff is like that
2020-06-09 11:53:56 <russkel> works on ubuntu and who cares about anything else ;)
2020-06-09 12:14:49 <ikke> ncopa: https://wwwtest.alpinelinux.org/posts/Alpine-3.12.0-released.html
2020-06-09 12:16:00 <ncopa> looks good. push it to production
2020-06-09 12:16:05 <ncopa> thanks!
2020-06-09 12:16:07 <ikke> ok
2020-06-09 13:03:40 <AinNero> Eighth_Doctor: i feel like there is some roleplaying going on somewhere
2020-06-09 13:03:44 <AinNero> im interested.
2020-06-09 13:03:52 <Eighth_Doctor> 😆
2020-06-09 13:04:21 <Eighth_Doctor> nothing quite so exciting... I switched nicks to trigger some bot actions and switched back after
2020-06-09 13:04:37 <Eighth_Doctor> though I have done something of the sort before on IRC for fun :)
2020-06-09 13:06:47 <Eighth_Doctor> last weekend someone complained about me being the Eighth Doctor, so I I regenerated :)
2020-06-09 13:07:00 <Eighth_Doctor> like now
2020-06-09 13:07:03 <Eighth_Doctor> 
ACTION regenerates

2020-06-09 13:07:39 <ikke> lol
2020-06-09 13:08:01 <Eleventh_Doctor> fezzes are cool :)
2020-06-09 14:08:33 <ncopa>  I have started the rebuild of the world for build-edge-{armhf,armv7,x86} with musl-1.2
2020-06-09 14:08:41 <ncopa> well, started with build-base so far
2020-06-09 14:11:55 <mps> huh, so we will have in next few days bugs hunting and fixing 'party'
2020-06-09 14:12:18 <ncopa> hopefully not that much needs fixing
2020-06-09 14:12:23 <ncopa> its not too long ago we did 3.12
2020-06-09 14:13:33 <ncopa> i thikn im gonna build main and maybe community then i replace the edge builders with those new
2020-06-09 14:13:39 <mps> maybe [[sroracle]] have some list of pkgs which need to be fixed
2020-06-09 14:13:53 <ncopa> i dont think there are too manu
2020-06-09 14:14:33 <mps> yes, we already upgraded most which was problem when the musl 1.2.0 released
2020-06-09 14:14:33 <ncopa> maybe i'll just replace the builders after main is built
2020-06-09 14:15:09 <ncopa> meaning i'll just purge our current community and edge for those arches
2020-06-09 14:15:19 <ncopa> and let the builders build it
2020-06-09 14:15:26 <mps> iirc, db is one which will need fix
2020-06-09 14:15:35 <ncopa> ok?
2020-06-09 14:15:47 <mps> ok for me
2020-06-09 14:25:16 <mps> reading https://www.phoronix.com/scan.php?page=news_item&px=June-2020-Spec-Fixes
2020-06-09 14:25:43 <mps> Google Engineer Uncovers Holes In Linux's Speculative Execution Mitigations
2020-06-09 14:26:27 <Cogitri> Hm, is that time_t stuff uncovered during build time or only during runtime?
2020-06-09 14:27:39 <mps> in some cases yes, but I don't know full story
2020-06-09 15:05:31 <ncopa> >>> py3-py: Analyzing dependencies...
2020-06-09 15:05:31 <ncopa> ERROR: unsatisfiable constraints:
2020-06-09 15:05:31 <ncopa>   py3-setuptools (missing):
2020-06-09 15:05:42 <ncopa> sounds like circular deps
2020-06-09 15:14:28 <ncopa> same with py3-atomicwrites and py3-pytest
2020-06-09 15:45:57 <ncopa>  /home/buildozer/aports/main/busybox/src/busybox-1.31.1/libbb/time.c:260:14: error: '__NR_clock_gettime' undeclared (first use in this function); did you mean 'clock_gettime'?
2020-06-09 15:47:28 <ncopa> dalias what was the fix for raw syscalls? use clock_gettime()?
2020-06-09 16:07:30 <dalias> ncopa, yes. it's upstream in busybox but they haven't made a release since early oct
2020-06-09 16:07:52 <dalias> commit be5a505d771a77c640acc35ceaa470c80e62f954
2020-06-09 16:08:11 <dalias> you should be able to just grab that commit and apply it as a patch
2020-06-09 16:08:22 <ikke> https://git.buildroot.org/busybox/commit/libbb?id=be5a505d771a77c640acc35ceaa470c80e62f954
2020-06-09 16:09:15 <dalias> ikke, that's incomplete
2020-06-09 16:09:19 <dalias> it only shows libbb dir
2020-06-09 16:09:24 <dalias> correct link is https://git.buildroot.org/busybox/commit?id=be5a505d771a77c640acc35ceaa470c80e62f954
2020-06-09 16:09:32 <ikke> https://git.buildroot.org/busybox/commit/?id=be5a505d771a77c640acc35ceaa470c80e62f954
2020-06-09 16:09:38 <ikke> I just searched for the commit hash
2020-06-09 16:09:44 <ikke> that was what showed up
2020-06-09 16:10:04 <dalias> and there may be an earlier commit this depends on that fixed it partially in coreutils/date
2020-06-09 16:10:15 <dalias> since there was existing wrong time64 support there
2020-06-09 16:12:19 <dalias> it might make sense to ask vda if busybox could make a release
2020-06-09 16:17:54 <mps> iirc, I tried this but found that something else is missing
2020-06-09 16:23:04 <mps> the latest stable is more than 6 months old, and asking for new release makes senswe
2020-06-09 16:23:12 <mps> sense*
2020-06-09 16:27:04 <mps> heh, https://busybox.net/downloads/snapshots/busybox-snapshot.tar.bz2
2020-06-09 16:40:50 <mps> busybox snapshot builds with musl-1.2.0
2020-06-09 16:48:55 <mps> 'pkg/busybox/bin/busybox date' => Tue Jun  9 18:47:16 CEST 2020
2020-06-09 16:49:25 <mps> armv7 with musl 1.2.0, busybox snapshot
2020-06-09 16:50:37 <mps> maybe pick these two files with '__NR_clock_gettime' from snapshot, and create patch
2020-06-09 16:52:06 <mps> 'grep -r __NR_clock_gettime src/' shows no traces
2020-06-09 18:39:23 <HRio> review please !9066 (security fix)
2020-06-09 18:41:18 <ikke> HRio: not a lot to review :P
2020-06-09 18:41:39 <HRio> according to the XEN XSA today, other users can "sample" RDRAND / RDSEED reads done on other cores.
2020-06-09 18:42:16 <ikke> That sounds bad
2020-06-09 18:42:33 <ikke> Should there be a secfix entry for that?
2020-06-09 18:42:54 <ikke> and should stable branches be fixed as well?
2020-06-09 18:43:47 <HRio> I only have the related XEN CVE
2020-06-09 18:43:58 <HRio> I will backport
2020-06-09 18:47:35 <HRio> will try to to the XEN patches for this tommorow, but the microcode is the important part for protection
2020-06-09 18:48:37 <maxice8> using XSAs is also valid in secfixes
2020-06-09 18:49:30 <HRio> yes for the xen package, but for the intel-ucode package I do not know what CVE Intel have got assigned (if any)
2020-06-09 19:29:51 <u0jQx9gPyrYg> >  In particular, our end-to-end exploit can leak the entire private key of a secure enclave running on a separate CPU core after only a single digital signature operation.
2020-06-09 19:29:57 <u0jQx9gPyrYg> src: http://offcoresitleaks.info/
2020-06-09 19:31:16 <u0jQx9gPyrYg> additional this embargo was also lifted today: https://cacheoutattack.com/ - they were able to extract the private EPID keys, which breaches SGX attestation
2020-06-09 19:31:34 <ikke> HRio is already working on the ucode updates
2020-06-09 19:31:50 <u0jQx9gPyrYg> just giving the missing info, better sources than xen cves...
2020-06-09 19:32:07 <ikke> u0jQx9gPyrYg: thanks
2020-06-09 19:32:15 <hrio[m]> Fixes merged as far back as v3.10
2020-06-09 19:32:15 <u0jQx9gPyrYg> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0543
2020-06-09 19:32:19 <u0jQx9gPyrYg> the cve ^^^^
2020-06-09 19:33:14 <u0jQx9gPyrYg> and for cacheout: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0549
2020-06-09 19:34:57 <HRio> Ah the XEN one was CVE-2020-0543
2020-06-09 19:35:16 <ikke> Apparently nothing too serious: "ah, no, wait, we don’t have a logo," :P
2020-06-09 19:35:33 <Hello71> dalias: why does it seem to me that they should have been doing it the proper way the whole time, given that it saves 10 bytes
2020-06-09 19:35:52 <HRio> u0jQx9gPyrYg thanks for the refs
2020-06-09 19:36:40 <u0jQx9gPyrYg> yw
2020-06-09 19:55:05 <ncopa> dalias: thanks for the busybox link!
2020-06-09 19:55:16 <ncopa> will follow up tomorrow
2020-06-09 19:57:12 <dalias> hello71, historically glibc had clock_gettime in librt
2020-06-09 19:57:18 <dalias> and librt.so depends on libpthread.so
2020-06-09 19:57:23 <dalias> which is entirely idiotic
2020-06-09 19:57:35 <dalias> so if you dynamic-linked busybox with -lrt you'd also get -lpthread
2020-06-09 19:57:58 <dalias> and associated increased memory usage, locking in places it's not needed, etc.
2020-06-09 19:58:22 <dalias> busybox did these awful direct-syscall hacks to work around glibc
2020-06-09 20:03:06 <mps> ncopa: there is another patch which is needed besides one above which dalias posted, but also I'm tired now to look and test
2020-06-09 20:08:26 <dalias> which file does thaat patch have conflicts in?
2020-06-09 20:08:59 <mps> coreutils/date.c
2020-06-09 20:09:05 <dalias> commit b7b7452f292f03eefafa6fd1da9bcfc933dee15a
2020-06-09 20:09:32 <dalias> this was the wrong initial fix
2020-06-09 20:10:17 <mps> be5a505d771a77c640acc35ceaa470c80e62f954 removes __NR_clock_gettime
2020-06-09 20:11:07 <dalias> right
2020-06-09 20:11:21 <mps> but I think it conflicts with b7b7452f292f03eefafa6fd1da9bcfc933dee15a
2020-06-09 20:11:28 <dalias> you need commit b7b7452f292f03eefafa6fd1da9bcfc933dee15a before that, since it builds on the wrong change made in this earlier commit
2020-06-09 20:11:42 <mps> yes, that is what I think
2020-06-09 20:11:42 <dalias> you can flatten them to a single patch if you want, without the wrong intermediate change
2020-06-09 20:12:20 <mps> good idea, will be better for alpine patch
2020-06-09 20:12:34 <mps> I thought to pick both :)
2020-06-09 20:13:18 <mps> but I hope ncopa will do this tomorrow :)
2020-06-09 20:14:11 <mps> and I think this one will be needed be5a505d771a77c640acc35ceaa470c80e62f954 for runit/runsv.c
2020-06-09 20:14:48 <mps> hmm, we don't build runit utils from busybox?
2020-06-09 20:27:35 <[[sroracle]]> RE time64
2020-06-09 20:28:34 <[[sroracle]]> this has most of the info http://wiki.adelielinux.org/wiki/Project:Time64
2020-06-09 20:29:23 <[[sroracle]]> i recently had to patch Firefox seccomp filter to support it also. chromium probably has the same problem (i believe firefox takes its seccomp stuff from chromium)
2020-06-09 20:30:22 <[[sroracle]]> php is broken on time64 for 32-bit arches because zend passes time_t everywhere as long
2020-06-09 20:30:49 <[[sroracle]]> i looked into fixing it but it would be a great deal of effort and it is unclear whether upstream is interested or not
2020-06-09 20:31:30 <mps> [[sroracle]]: thanks for info
2020-06-09 20:32:09 <[[sroracle]]> i also recently discovered while looking through python ctypes usage for breakage that (unrelated) g-ir-scanner hardcodes time_t as glong
2020-06-09 20:32:29 <mps> (I din't know what will need fixes but I know who knows :) )
2020-06-09 20:32:36 <[[sroracle]]> that will need fixing too but since it has so many rdeps i think it needs world rebuild...
2020-06-09 20:34:11 <[[sroracle]]> i'll let you know if i think of anything else. That's off the top of my head
2020-06-09 20:36:43 <mps> very nice, thanks again
2020-06-09 20:45:43 <Hello71> dalias: so it's still bad on glibc, but nobody cares anymore? or is it fixed with --as-needed
2020-06-09 21:28:54 <dalias> [[sroracle]], re: "because zend passes time_t everywhere as long", this is not necessarily "broken on time64", it just means it will break in 2038
2020-06-09 21:29:18 <dalias> as long as there aren't linkage bugs using long where the actual argument type is supposed to be time_t, it should work now
2020-06-09 21:29:38 <dalias> [[sroracle]], what is g-ir-scanner ?
2020-06-09 21:30:00 <dalias> hello71, it's fixed because glibc moved clock_gettime into libc.so where it belongs
2020-06-09 22:15:03 <[[sroracle]]> dalias: Cogitri is more qualified to speak about what it is than i am, aiui it's some gnome thing that translates C header files into XML representation
2020-06-09 22:16:06 <[[sroracle]]> dalias: as for php i think it was doing the equivalent of (long*)&time_t_value which breaks regardless of what the value is; i'd have to double check though
2020-06-09 23:06:23 <dalias> [[sroracle]], indeed if that's what it's doing it's absolutely broken and must be fixed
2020-06-09 23:07:22 <[[sroracle]]> the problem is it's low enough in the stack that it would be quite invasive to change
2020-06-09 23:08:16 <[[sroracle]]> i'll have to think about it more but as it stands now it would be akin to introducing a new core type
2020-06-09 23:08:46 <dalias> why?
2020-06-09 23:08:58 <dalias> it should just be glonglong or s64
2020-06-09 23:09:01 <[[sroracle]]> the way php is written is kinda bonkers
2020-06-09 23:09:15 <dalias> oh i was talking about the GIR thing
2020-06-09 23:09:22 <[[sroracle]]> ah
2020-06-09 23:09:30 <dalias> python should be much easier i think
2020-06-09 23:09:31 <[[sroracle]]> yes that definitely needs to be fixed, and should be easy
2020-06-09 23:09:34 <dalias> because it's not FFI types hell
2020-06-09 23:09:45 <[[sroracle]]> it will just be hard to find where it's broken downstream
2020-06-09 23:09:46 <dalias> erm
2020-06-09 23:09:48 <dalias> i meant php
2020-06-09 23:09:54 <dalias> dunno why i said python
2020-06-09 23:10:02 <[[sroracle]]> php is going to be hard
2020-06-09 23:10:09 <dalias> why?
2020-06-09 23:10:34 <[[sroracle]]> the way it's written, php functions are written in c but don't use c function arguments - they pass a context like thing and then decode the php arguments from that
2020-06-09 23:10:55 <dalias> and?
2020-06-09 23:11:03 <[[sroracle]]> that's where it's broken - the zend argument parser doesn't know about time_t, only long - so everywhere that uses time_t passes it as long
2020-06-09 23:11:15 <[[sroracle]]> i'm not sure it even knows about long long right now
2020-06-09 23:11:20 <dalias> then the api for these functions is just that they take longs not time_t
2020-06-09 23:11:29 <dalias> i don't see how that's a problem except that it breaks in 2038
2020-06-09 23:11:53 <dalias> (which is php's problem not our problem)
2020-06-09 23:12:23 <[[sroracle]]> well as i said it doesn't cast the value, it casts the address (if i remember correctly)
2020-06-09 23:12:40 <[[sroracle]]> and this leads to weird corner cases where they call a c function and pass that around to php functions
2020-06-09 23:12:55 <[[sroracle]]> completely clobbering the value
2020-06-09 23:13:43 <[[sroracle]]> i will need to look at the test failure that led to me finding this in the first place
2020-06-09 23:14:10 <[[sroracle]]> it's been a few months since i was knee deep in this nightmare :p
2020-06-09 23:15:15 <dalias> do you have any notes i could look at?
2020-06-09 23:15:38 <dalias> i really can't imagine this being any worse than a search-and-replace type fix since it's not a FFI boundary
2020-06-09 23:15:58 <[[sroracle]]> let me go back through logs and i'll ping you in #musl
2020-06-09 23:16:08 <dalias> ok
2020-06-09 23:28:20 <dalias> does php automatically make linkage for the php_* functions to some jit hell?
2020-06-09 23:29:49 <dalias> wow php is a trashfire ecosystem...
2020-06-10 02:41:48 <terror_> Hi team, trying to merge a new aport with Gitlab but completely stuck
2020-06-10 02:41:55 <terror_> I've done this in the past with GitHub
2020-06-10 02:42:07 <terror_> Can anyone help with that?
2020-06-10 02:42:28 <terror_> The repo is: https://gitlab.alpinelinux.org/mterron/aports
2020-06-10 02:42:47 <terror_> Not sure how to request it is merged back to the source repo
2020-06-10 02:43:01 <maxice8> did you push your changes to a branch in your repo ?
2020-06-10 02:52:41 <terror_> Yes
2020-06-10 02:52:48 <terror_> And the tests run and succeed
2020-06-10 02:57:48 <terror_> I think I messed up by clicking a big green button that said merge to master
2020-06-10 03:00:44 <terror_> I'll start over
2020-06-10 03:08:50 <maxice8> You should go to gitlab.a.o/alpine/aports and open a merge request that that wants to merge mterron:$BRANCH into alpine:master
2020-06-10 03:40:36 <terror_> Now seems to be sorted: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9084
2020-06-10 05:16:10 <Ariadne> i'm legitimately confused on why testing/debconf is a thing, since it is tightly integrated with dpkg
2020-06-10 05:16:52 <ikke> main/dpkg is also a thing
2020-06-10 05:18:19 <Ariadne> yes, that one i understand
2020-06-10 05:18:29 <Ariadne> because you need dpkg for debootstrap
2020-06-10 05:18:53 <Ariadne> but debconf seems entirely useless on an alpine system
2020-06-10 05:19:21 <Ariadne> maybe its for containers idk
2020-06-10 05:20:41 <ikke> ask TBK[m] :)
2020-06-10 05:37:04 <Cogitri> [[sroracle]] dalias: the problem with changing something in GIR is that have to rebuild all bindings that use is consequently
2020-06-10 05:37:11 <Cogitri> I'll go ask upstream about it
2020-06-10 05:37:18 <[[sroracle]]> right. thank you
2020-06-10 09:34:02 <ncopa> hunm
2020-06-10 09:34:12 <ncopa> this time64 thing is a box of worms
2020-06-10 09:34:51 <ncopa> according http://wiki.adelielinux.org/wiki/Project:Time64 we also need to set export enable_libstdcxx_time=rt when compiling gcc  https://code.foxkit.us/adelie/packages/blob/master/system/gcc/APKBUILD#L287
2020-06-10 09:35:03 <ncopa> but changing that seems to break the ABI
2020-06-10 09:35:16 <ncopa> meaning, that we may need to rebuild everything on all achitectures...
2020-06-10 09:35:34 <ncopa> at least everything that uses c++
2020-06-10 09:35:43 <Cogitri> The GIR thing seems annoying too as that could potentially break all non C GTK applications
2020-06-10 09:36:08 <ncopa> even if we rebuild everything from scratch?
2020-06-10 09:36:33 <ncopa> and also on non 32 bit architectures?
2020-06-10 09:37:11 <ncopa> perl-yaml-syck testsuite fails. need to investigate: $ abuild -rk 2>&1 | tpaste
2020-06-10 09:37:11 <ncopa> https://tpaste.us/yZ4p
2020-06-10 09:37:14 <Cogitri> Yes, apparently g-ir-scanner (the thing that generates the GIR XML from which bindings are generated) hardcodes time_t to the current 32-bit value
2020-06-10 09:37:47 <Cogitri> It won't break on 64-bit arches and applications which don't assume that time_t on 32-bit == 32-bit integer
2020-06-10 09:38:11 <ncopa> so that needs to be fixed before we start build anything using g-it-scanner
2020-06-10 09:38:27 <ncopa> as a separate patch on top of musl-1.2 update
2020-06-10 09:38:47 <Cogitri> The problem is that some bindings aren't generated by us (e.g. gtk-rs is generated from Ubuntu GIR files), so Rust GTK applications will probably just have to be disabled on 32-bit if they don't work
2020-06-10 09:39:20 <Cogitri> I think for Python and Vala GTK stuff it should probably be alright once g-ir-scanner is fixed because the bindings for that should be generated locally during build
2020-06-10 09:39:33 <Cogitri> Anyway, I'll try to ask the GIR folks about that later today
2020-06-10 09:39:44 <ncopa> should be reported upstream
2020-06-10 09:39:46 <ncopa> also
2020-06-10 09:39:53 <ncopa> how does that work on things like openbsd?
2020-06-10 09:40:04 <ncopa> isnt time_t 64bit on openbsd already?
2020-06-10 09:41:47 <Cogitri> Dunno about that
2020-06-10 09:41:56 <Cogitri> Yes, certainly something that has to be supported upstream
2020-06-10 09:42:15 <ncopa> https://www.openbsd.org/55.html#:~:text=time_t%20is%20now%2064%20bits,to%20support%2064%2Dbit%20time_t.
2020-06-10 09:51:42 <mps> I told yesterday that you started bug hunting and fixing 'party', but this was inevitable anyway
2020-06-10 10:02:21 <mps> I asked on busybox channel will the release soon new point release
2020-06-10 13:55:37 <russkel> can someone please check out https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8952 - I have dealt with the requested changes
2020-06-10 13:55:43 <russkel> and https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8967
2020-06-10 13:56:08 <russkel> and this was fixing my previous MR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8974
2020-06-10 14:01:59 <russkel> gratzie
2020-06-10 14:58:31 <dne> could someone merge? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8553
2020-06-10 14:59:04 <dne> (backport of change that's already in 3.12 and edge)
2020-06-10 14:59:35 <Cogitri> We'll try to get to it soon
2020-06-10 15:01:28 <dne> cool
2020-06-10 15:02:11 <Cogitri> Sorry for the waiting time, right now many devs are busy with other things :/
2020-06-10 15:02:30 <Hello71> doesn't this time64 affect glibc too? or are they doing some time64_t _LARGE_TIME_SUPPORT nonsense
2020-06-10 15:04:23 <mps> Hello71: afaik, latest glibc is also fixed (musl was first, I think)
2020-06-10 15:04:41 <mps> but I don't follow glibc, so not sure
2020-06-10 15:04:50 <Hello71> so then can't alpine just copy other distro's patches?
2020-06-10 15:05:04 <mps> yes, it they exist
2020-06-10 15:05:25 <mps> and I think even pre 5.6 kernels needs patches
2020-06-10 15:06:43 <mps> I know that some upstream already have fixes in their stable releases, alsa, openssh for example
2020-06-10 16:19:01 <program247365> Is it possible to patch Alpine with PREEMPT_RT https://lwn.net/Articles/146861/, or is it already part of the distro and can be enabled?
2020-06-10 16:36:19 <Hello71> clearly a real time user
2020-06-10 16:38:53 <mps> yes, disappeared in RT :)
2020-06-10 16:45:56 <ikke> I guess they were preempted
2020-06-10 16:46:25 <program2_> Sorry, dang webchat irc. Now on a good client. My question still stands. :)
2020-06-10 16:47:04 <program2_> PREEMPT_RT a thing in Alpine, or can be compiled with it?
2020-06-10 16:49:37 <Hello71> that article is 15 years old
2020-06-10 16:52:26 <mps> PREEMPT_RT is in new kernels, but not yet ready to be enabled by default
2020-06-10 16:53:28 <mps> but anyone can rebuild kernels enabling this option if it is needed for their use cases
2020-06-10 16:54:23 <Cogitri> Doesn't it reduce throughput quite a bit?
2020-06-10 16:54:44 <program2_> @mps Awesome, thank you for the info.
2020-06-10 16:55:20 <mps> I mean, linux-edge not linux-lts kernels
2020-06-10 16:55:59 <program2_> @hello71 Yes.
2020-06-10 16:56:12 <mps> Cogitri: according to kernel devs it will need some more works, but could be used for some cases
2020-06-10 16:57:02 <program2_> @Cogitri I believe it might, but increases determinism? I'm new but that's my understanding. Digging into "Linux Kernel Development" book right now.
2020-06-10 16:58:08 <mps> yes, determinism more than throughput
2020-06-10 17:00:16 <program2_> :nods: After seeing the AMA from the SpaceX engineers on Reddit about their setup for Dragon and other spacecraft I was interested in trying this. And Alpine seemed like a nice thin one to try.
2020-06-10 17:01:31 <mps> yes, they use musl libc but no reference to alpine
2020-06-10 17:03:18 <mps> program2_: you are building spacecraft? :)
2020-06-10 17:04:24 <mps> not sure if still, but debian had RT kernel as separate package for long time
2020-06-10 17:05:50 <Cogitri> Yes, you usually only need it in some applications (e.g. music production) and on servers you'd prefer the higher throughput over RT usually
2020-06-10 17:06:53 <mps> and machinery control mostly
2020-06-10 17:20:31 <detha> machinery control still most often runs its own RTOS, with linux as a low-prio task
2020-06-10 17:51:54 <program2_> @mps I want to build spacecraft! But just toying around to see if I could get a proof of concept that resembles what I know those vehicles setup to be like. :)
2020-06-10 17:57:43 <program2_> @detha That's super cool. Learning a lot about task prioritization in OSes, this is neat to know what the use cases are.
2020-06-10 18:03:07 <detha> program2_: modern linux kernels are most likely good enough for 'soft real-time', for whatever definition of soft real-time you want to apply
2020-06-10 18:22:49 <program2_> :nods: Anyone know of any good articles about PREEMPT_RT? I've not done a deep search just yet. I'd like to understand the the thinking behind it more, and how it works.
2020-06-10 18:27:26 <program2_> https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/preemptrt_setup this seems helpful
2020-06-10 18:30:18 <program2_> Ahh this seems good- https://wiki.alpinelinux.org/wiki/Custom_Kernel
2020-06-10 19:07:11 <ikke> armhf/thrift: "3 failures are detected in the test module "TServerIntegrationTest""
2020-06-10 19:12:01 <Cogitri> Time to disable it I guess, it's a bit unfortunate we don't have CI for it
2020-06-11 04:47:32 <ikke> tomcat9 fails due to 404 on the src. It appears only the latest version 9.0.36 is available.  Besides that. I'm wondering why they use a binary archive rather than a source archivev.
2020-06-11 04:52:57 <dalias> ?
2020-06-11 04:53:27 <ikke> The source url: https://downloads.apache.org/tomcat/tomcat-9/v$pkgver/bin/apache-tomcat-$pkgver.tar.gz
2020-06-11 04:53:30 <dalias> btw does alpine keep archives of the source files pulled somewhere? even if not online, it seems like htis would be useful
2020-06-11 04:53:32 <ikke> notice the /bin/ in there
2020-06-11 04:53:55 <ikke> http://distfiles.alpinelinux.org/distfiles/
2020-06-11 04:53:57 <dalias> is it a jar binary nobody wants to build?
2020-06-11 04:54:04 <ikke> dalias: most likely, yes
2020-06-11 04:54:31 <dalias> tomcat is one of the most awful pieces of software i've ever encountered
2020-06-11 04:54:50 <dalias> i saw bringing up a cms on a beefy server take like 3+ minutes
2020-06-11 07:45:45 <Cogitri> Can I make hidden issue visible to someone who's not on the dev team?
2020-06-11 07:46:36 <mps> why would you do that?
2020-06-11 07:46:53 <mps> breaking laws :)
2020-06-11 07:47:51 <Cogitri> Someone who is not in the dev team discovered a possible vulnerability in something
2020-06-11 07:49:01 <mps> though I think hiding vulnerability is not solution, then again breaking alpine rules is not good idea
2020-06-11 07:51:11 <mps> (I can post mail to someone in sec team (any project) pretending I discovered important vulnerability and naive member of team give me access? )
2020-06-11 07:51:46 <mps> like we had incident few weeks ago with tor
2020-06-11 07:54:01 <afontain_> I don't know for the other tools, but I believe you can open an issue that isn't open for anyone (for reporter access IIRC), even if you are not member of the team
2020-06-11 07:54:08 <afontain_> on Gitlab
2020-06-11 07:58:39 <mps> though I think 'computer sec' is ridiculous theater, I would advise anyone interested in working in this field to read Kevin Mitnicks 'art of deception' first (besides all other important books in the field) and contmeplate a little about it
2020-06-11 08:01:21 <mps> when I talk about this, classic is Sun Tse 'the art of war' and Machiaveli 'The Prince'
2020-06-11 08:22:38 <Ariadne> Cogitri: yes, mark it as private and then involve them in the bug somehow (mention)
2020-06-11 08:27:35 <Cogitri> Ah nice, didn't expect it to be that simple :)
2020-06-11 09:15:55 <ncopa> i think i have figured out the perl and the time64 problem
2020-06-11 09:16:05 <ncopa> perl needs to be built with -DBIG_TIME
2020-06-11 09:16:16 <ncopa> it time_t is 64bit
2020-06-11 09:16:18 <ncopa> fi*
2020-06-11 09:16:20 <ncopa> if*
2020-06-11 09:16:29 <ikke> I feel there is a pun in there somewhere :)
2020-06-11 09:17:35 <mps> s/time_t ts/long ts/
2020-06-11 09:17:44 <mps> sed
2020-06-11 09:18:00 <mps> as dalias proposed for php
2020-06-11 09:18:13 <ncopa> php is different animal with different problems
2020-06-11 09:18:25 <mps> yes
2020-06-11 09:18:42 <mps> I'm just kidding a little in morning
2020-06-11 09:19:17 <mps> looks like -DBIG_TIME is ok for perl
2020-06-11 09:20:33 <ncopa> question is if it is ok even on 64bit?
2020-06-11 09:20:38 <ncopa> i guess it is
2020-06-11 09:21:02 <mps> I think so
2020-06-11 09:23:10 <mps> when you finish change you can post to me and I can try to build on aarch64 with musl-dev 1.2.0
2020-06-11 09:25:17 <mps> or maybe is enough for me to add this build flag to perl in APKBUILD and try?
2020-06-11 09:27:17 <afontain_> mps: about that, does it still work if you rollback to musl 1.1.x?
2020-06-11 09:28:13 <ncopa> no
2020-06-11 09:28:24 <mps> afontain_: didn't tried, but I think it will not work
2020-06-11 09:28:26 <afontain_> I'm not too surprised if it is backward compatible, but I'd be seriously impressed if they also made it forward compatible
2020-06-11 09:28:58 <ncopa> im thinking of something like this: https://tpaste.us/Qnj0
2020-06-11 09:29:30 <ncopa> so it will build perl correctly
2020-06-11 09:30:07 <mps> afontain_: I mean, program built with musl 1.2.0 will not work if rollback to 1.1.x
2020-06-11 09:30:47 <afontain_> that's how I understood it
2020-06-11 09:30:50 <afontain_> Yeah, so adding packages from edge in top of stable will likely break
2020-06-11 09:31:09 <mps> ncopa: ok, will try and test after breakfast (and yet another coffee, today I'm somewhat sleepy(
2020-06-11 09:31:26 <mps> bad and heave weather around
2020-06-11 09:31:37 <mps> heavy*
2020-06-11 09:34:54 <Ariadne> afontain_: we can solve that by bumping SONAME i think
2020-06-11 09:35:34 <Ariadne> however, mixing edge and stable is not recommended anyway.
2020-06-11 09:36:22 <ncopa> afontain_: correct. mixing edge with 3.12 on 32 bit architectures will cause breakages
2020-06-11 10:50:16 <mps> ncopa: perl passed with build with your patch, 'abuild -r' worked
2020-06-11 10:53:17 <ncopa> im not sure that my patch was the fix
2020-06-11 10:53:23 <ncopa> but it may be needed anyway
2020-06-11 10:53:31 <mps> and, as bonus I noticed that we have miniperl built :)
2020-06-11 10:54:49 <mps> I can install this new built perl but not sure how I can test it
2020-06-11 10:55:08 <mps> I mean on aarch64, test will be useless
2020-06-11 10:55:22 <mps> but it builds fine on aarch64
2020-06-11 10:55:35 <mps> that was my intention to check
2020-06-11 10:55:46 <ncopa> well, I guess its nice to verify that it does not unintentionally break anything
2020-06-11 10:57:27 <mps> did you built gcc
2020-06-11 10:57:36 <mps> with musl 1.2.0 I mean
2020-06-11 11:00:23 <ncopa> yes
2020-06-11 11:07:23 <mps> oh, it is  9.3.0-r3 and I have gcc-9.3.0-r2 installed, so I didn't built perl with 9.3.0-r3
2020-06-11 11:58:48 <markand> hello
2020-06-11 11:58:58 <markand> on my machine I don't have problem building !9123
2020-06-11 11:59:15 <markand> I don't understand why it shows a bash-completion error only on the build machine
2020-06-11 12:01:47 <Cogitri> Maybe different abuild versions?
2020-06-11 12:02:26 <Cogitri> Are you building in a container or on your system? Maybe it finds an additional dep in your system that's not installed via abuild
2020-06-11 12:03:19 <markand> no directly from my user
2020-06-11 12:04:03 <Cogitri> I guess it might be missing a dep in the APKBUILD then
2020-06-11 12:05:13 <markand> I've checked debconf which also has bash-completion but does not much more than my package
2020-06-11 12:05:16 <markand> weird
2020-06-11 12:31:05 <Cogitri> [[sroracle]]: Do you have more info on that GIR x time_t thingie? Can't find it on Adelie's time_t wiki page
2020-06-11 13:52:31 <[[sroracle]]> Cogitri: https://gitlab.gnome.org/GNOME/gobject-introspection/-/blob/master/giscanner/ast.py#L347
2020-06-11 13:59:32 <Cogitri> Thanks
2020-06-11 14:01:13 <[[sroracle]]> I will try to update the wiki page today
2020-06-11 14:17:31 <Cogitri> That should be pretty easy to fix in g-ir-scanner at least, the problem will be regenerating all the bindings
2020-06-11 14:18:00 <Cogitri> I guess we'll just have to live with Rust applications using gtk-rs crashing since those are generated from Ubuntu GIR (which was bound to break at some point, I guess)
2020-06-11 14:18:14 <Cogitri> Not sure what the situation is with Vala's VAPI
2020-06-11 16:33:28 <dalias> type_names['dev_t'] = TYPE_INT is also wrong
2020-06-11 16:33:36 <dalias> and would have broken badly if anyone used it
2020-06-11 16:34:31 <dalias> and socklen_t is u32 not signed
2020-06-11 16:40:04 <dalias> all of these should be detected via a configure script then *generated* appropriately rather than hard-coded in the source to a particular known platform's ABI
2020-06-11 16:51:29 <Cogitri> Yup, I guess that can be fixed in one go together with time_t
2020-06-11 17:09:04 <ikke> armhf/borgbackup is faling due to bus error during tests
2020-06-11 17:11:31 <Cogitri> Yup, replied on the MR for that already
2020-06-11 17:24:44 <ikke> I do think we had that earlier (when building for 3.12)
2020-06-11 17:36:26 <oneinsect> quick question, glib seems to compile to usr/lib64 and usr/lib, did anyone notice?
2020-06-11 17:37:11 <oneinsect> which causes the mv "$pkgdir"/usr/lib/*.a "$subpkgdir"/usr/lib/
2020-06-11 17:37:11 <oneinsect>  to causes error during building
2020-06-11 17:37:27 <oneinsect> and NOT usr/lib
2020-06-11 17:57:47 <dalias> didn't glib switch from autoconf to some new fad build system?
2020-06-11 17:57:49 <dalias> meson or something
2020-06-11 17:58:05 <dalias> it seems these all keep reintroducing lib64 despite it being nonstandard and wrong
2020-06-11 17:58:09 <dalias> i know cmake does it
2020-06-11 17:58:09 <mps> oneinsect: you are building on glibc system
2020-06-11 17:58:25 <dalias> ?
2020-06-11 17:58:53 <oneinsect> yes
2020-06-11 17:59:00 <oneinsect> building on a glibc system mps:
2020-06-11 17:59:06 <oneinsect> why whats wrong?
2020-06-11 17:59:18 <mps> just to clarify
2020-06-11 18:00:02 <oneinsect> but its the same APKBUILD, it supposed to build to lib right? i mean does the latest one build to lib in musl?
2020-06-11 18:08:10 <maxice8> Yes, Yes
2020-06-11 18:11:35 <oneinsect> hmmm
2020-06-11 18:12:11 <oneinsect> strange just by compiling in glibc it outputs to lib64
2020-06-11 18:12:24 <oneinsect> cannot understand what makes this change
2020-06-11 18:13:35 <Cogitri> dalias: meson only does that if you explicitly tell it to do so
2020-06-11 18:15:57 <oneinsect> but Cogitri: we are not telling anywhere explicitly
2020-06-11 18:18:15 <Cogitri> That's probably the problem then
2020-06-11 18:18:48 <Cogitri> We should really move things to abuild-meson, it's a bit annoying how we have different parameters for values we always want among different APKBUILDs
2020-06-11 18:19:07 <Cogitri> For now, --libdir=/usr/lib will do it
2020-06-11 18:26:09 <oneinsect> let me try that now
2020-06-11 18:31:30 <oneinsect> works now Cogitri:
2020-06-11 18:31:37 <oneinsect> thank you (as always)
2020-06-11 18:31:51 <oneinsect> i am checking all main packages one by one by hand
2020-06-11 18:32:01 <oneinsect> tedious but worth it
2020-06-11 18:33:22 <oneinsect> phew
2020-06-11 18:33:23 <oneinsect> ERROR: glib-dev-2.64.3-r0: trying to overwrite usr/include/libintl.h owned by glibc-dev-2.31-r0.
2020-06-11 18:33:32 <oneinsect> ooh my god!
2020-06-11 19:07:07 <mps> I'm working on pidgin upgrade, and have to use new pkg libgnt because it is split from pidgin now
2020-06-11 19:07:52 <mps> to add this pkg I have to break rule and push it straight to community, skipping testing
2020-06-11 19:08:00 <mps> is this ok?
2020-06-11 19:11:38 <Cogitri> Yup, should be fine to introduce dependants directly in community
2020-06-11 19:16:38 <mps> I think so, thanks
2020-06-11 19:36:34 <dalias> wtf, why would glib install a libintl.h ?!
2020-06-11 19:38:31 <Cogitri> Probably because we patch it https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/glib/musl-libintl.patch
2020-06-11 19:40:05 <dalias> but glib still should not be providing this
2020-06-11 19:41:13 <Cogitri> I guess that libintl_proxy thingie is installing it when it should only install the lib
2020-06-11 19:44:05 <oneinsect> hmmm
2020-06-11 19:45:55 <dalias> alpine already ships gnu libintl i think
2020-06-11 19:46:08 <dalias> (which should also be fixed after figuring out how to get stuff to work with musl's internal gettext)
2020-06-11 19:48:14 <Cogitri> Yes, we ship libintl via gettext and I think we don't have glib installing libintl.h
2020-06-11 19:48:21 <Cogitri> That's only in the unofficial glibc port of alpine
2020-06-11 19:48:34 <Cogitri> But yes, it'd be nice to switch to musl libintl once that's ready
2020-06-11 19:53:35 <dalias> it's been ready all along
2020-06-11 19:53:56 <dalias> the problem is fixing packages with autoconf checks for glibc/gnu-gettext internal symbols
2020-06-11 23:45:42 <Ariadne> dalias: we can probably solve that by just adding dummy symbols, no?
2020-06-11 23:46:27 <Ariadne> actually i am interested in the glibc port of alpine, but for the purposes of using GNU HURD
2020-06-11 23:46:29 <Ariadne> ;)
2020-06-12 00:30:41 <dalias> ariadne, maybe you could add a dummy static lib that defines them just for the sake of configure-time check. not sure
2020-06-12 00:30:57 <Ariadne> yeah that is the idea i had
2020-06-12 00:31:32 <Ariadne> but we would want that to be transparent
2020-06-12 00:31:43 <Ariadne> i'm not sure how to accomplish that without using a linker script
2020-06-12 00:35:57 <dalias> linker script?
2020-06-12 00:36:12 <dalias> you just pass LIBS or LDFLAGS or CC customized into configure
2020-06-12 00:36:25 <dalias> or just override the bad config test with a command line option
2020-06-12 00:38:41 <Ariadne> hmm
2020-06-12 00:38:55 <Ariadne> actually, autotools can read a 'site config file'
2020-06-12 00:38:59 <dalias> yes
2020-06-12 00:39:05 <dalias> that would be a great way to fix lots of crap
2020-06-12 00:39:07 <Ariadne> maybe we just ship a site config file
2020-06-12 00:39:20 <dalias> that's what sabotage does
2020-06-12 00:39:25 <maxice8> I think void linux does that for cross-compilation
2020-06-12 00:39:35 <dalias> yeah for cross comppiling you kinda need it
2020-06-12 00:40:19 <maxice8> https://github.com/void-linux/void-packages/tree/master/common/environment/configure/autoconf_cache
2020-06-12 00:40:22 <dalias> because autoconf has so many tests that default to something wrong/broken if they can't do execution checks
2020-06-12 00:40:37 <Ariadne> while waiting for consensus on team maintenance to be verified (it would be helpful if people commented on the teams i proposed as an initial test), i will work on this
2020-06-12 00:41:28 <Ariadne> hmm
2020-06-12 00:41:35 <Ariadne> that is not the best way to do it
2020-06-12 00:41:41 <Ariadne> configure itself will look in /etc/something
2020-06-12 00:41:48 <dalias> why?
2020-06-12 00:41:58 <dalias> there's a way to make it look at a particular file
2020-06-12 00:42:11 <dalias> rather than something system global
2020-06-12 00:42:26 <Ariadne> CONFIG_SITE=/foo/bar
2020-06-12 00:42:30 <Ariadne> will make it source that file
2020-06-12 00:42:32 <Ariadne> afaik
2020-06-12 00:43:10 <Ariadne> otherwise
2020-06-12 00:43:21 <Ariadne> it defaults to $ac_default_prefix/share/config.site
2020-06-12 00:44:13 <Ariadne> which evaluates as $prefix/share/config.site with /usr/local/share/config.site as fallback
2020-06-12 00:44:15 <Ariadne> so
2020-06-12 00:44:19 <Ariadne> i think what we do is
2020-06-12 00:44:34 <Ariadne> install arch-specific config as symlink to /usr/share/config.site
2020-06-12 00:44:58 <Ariadne> and then if CARCH != CBUILD, set CONFIG_SITE environment variable
2020-06-12 00:45:17 <dalias> i dont think there's any reason for the config to be arch-specific
2020-06-12 00:45:35 <Ariadne> we can specify arch-specific data
2020-06-12 00:45:40 <Ariadne> to speed up configure scripts
2020-06-12 00:45:42 <dalias> but why would you want to?
2020-06-12 00:45:50 <Ariadne> so for example, we can specify that time_t is 64-bit
2020-06-12 00:45:54 <dalias> it's just more maintenance burden and won't make anything faster
2020-06-12 00:45:56 <Ariadne> so it does not run a test
2020-06-12 00:46:01 <dalias> time_t being 64-bit is not arch-specific
2020-06-12 00:46:06 <Ariadne> how does it not mke it faster
2020-06-12 00:46:24 <Ariadne> if it is already known, then it does not compile a test program
2020-06-12 00:46:29 <Ariadne> by definition that is faster
2020-06-12 00:47:30 <Ariadne> this also solves cross-compile
2020-06-12 00:48:15 <dalias> because <1% of the tests have arch-specific results
2020-06-12 00:48:15 <dalias> and the ones that do are all very fast anyway
2020-06-12 00:49:07 <Ariadne> yes, but when cross-compiling, you have to tell it things like endianness
2020-06-12 01:08:57 <Hello71> seems like we have another situation in #alpine-linux
2020-06-12 01:09:13 <Hello71> Ariadne, Cogitri, dalias: ^
2020-06-12 01:25:11 <Ariadne> none of us have any capability to moderate that channel directly, and freenode staff are MIA
2020-06-12 01:27:38 <maxice8> None in the Alpine team has permissions to kick/ban from a channel ?
2020-06-12 01:27:57 <Ariadne> clandmeter, ikke, ncopa and shiz handle moderation
2020-06-12 01:28:03 <Ariadne> perhaps we should fix that
2020-06-12 01:28:33 <maxice8> I belive that composition is very eurocentric
2020-06-12 01:28:57 <Ariadne> indeed
2020-06-12 01:29:00 <maxice8> The 3 first should be sleeping rn, I don't know shiz
2020-06-12 01:29:03 <Hello71> didn't we talk about this last time already
2020-06-12 01:29:19 <Ariadne> Hello71: yes unfortunately i have had more important issues to deal with
2020-06-12 01:29:38 <Ariadne> and my desire to moderate an irc channel is basically zero
2020-06-12 01:30:43 <maxice8> I can try
2020-06-12 01:30:55 <Hello71> as an interim measure we could at least add freenode-staff to the access list
2020-06-12 01:31:17 <Hello71> as pointed out by D[_]
2020-06-12 01:32:19 <Ariadne> except, we can't
2020-06-12 01:32:33 <Ariadne> because none of the people around can do that
2020-06-12 01:33:19 <Hello71> right, the interim is between "one of them show up again" and "we actually get pacific-time ops"
2020-06-12 01:34:19 <Hello71> now, if you can make that time short enough that it's a moot point, then sure
2020-06-12 01:36:52 <Ariadne> i mean
2020-06-12 01:36:57 <Ariadne> i can blow up people's phones
2020-06-12 01:37:00 <Ariadne> but
2020-06-12 01:37:07 <Ariadne> i don't think they would appreciate being woken up
2020-06-12 01:37:12 <Ariadne> over IRC bullshit
2020-06-12 01:39:01 <Hello71> my point is that by "interim" I don't mean "literally right now", I just mean between some near future and some more distant, more hopeful future
2020-06-12 01:56:40 <tehcloud> consider it a sign of success when the trolls come for you
2020-06-12 02:00:17 <Hello71> I'll hold out for the president calling me an antifa provocateur
2020-06-12 02:06:58 <Ariadne> lets not go there please :)
2020-06-12 04:37:17 <Ariadne> this autoconf-policy I'm fleshing out is pretty great
2020-06-12 04:37:29 <Ariadne> we can simplify apkbuilds with it
2020-06-12 04:44:17 <oneinsect> https://gitlab.alpinelinux.org/kaniini/autoconf-policy
2020-06-12 04:44:19 <oneinsect> that one?
2020-06-12 05:37:01 <Cogitri> Ariadne: I think the most frequent problem we hit with gettext is things picking up gettext libintl but then not linking against it, but I guess that'd solve itself once we switch over to musl gettext everywhere and don't pull in gettext's headers anymore
2020-06-12 05:37:39 <Ariadne> Cogitri: yes, i am not proposing we do the cutover immediately.  autoconf-policy is about getting the plumbing in place to do a few diffrent things to autotools packages
2020-06-12 05:38:11 <Ariadne> for example, APKBUILDs have --prefix=... and so on.  we can actually get rid of all of that and specify it in autotools-policy.
2020-06-12 05:39:06 <Ariadne> speeding up builds with dabuild+qemu is also a nice win
2020-06-12 05:39:17 <Ariadne> since fork performance is garbage under qemu :D
2020-06-12 05:43:34 <Cogitri> Ah neat, specifying all that shared config in one central place sounds very neat
2020-06-12 06:33:58 <Ariadne> Cogitri: https://gitlab.alpinelinux.org/kaniini/autoconf-policy should make it more clear now
2020-06-12 06:35:59 <mps> iirc, this is something like debian have
2020-06-12 06:36:30 <mps> defaults for build tools
2020-06-12 06:37:32 <Cogitri> Ariadne: So does this also specify build, host, localstatedir etc. for us?
2020-06-12 06:37:38 <Ariadne> Cogitri: not yet :)
2020-06-12 06:37:44 <Cogitri> Ah, but it can?
2020-06-12 06:37:53 <Ariadne> Cogitri: i want to do a change proposal for that
2020-06-12 06:37:58 <Cogitri> Ah okay
2020-06-12 06:38:05 <Cogitri> Well, we already have it for meson via abuild-meson
2020-06-12 06:38:22 <Ariadne> similarly with deprecating GNU gettext (starting with libintl, and later replacing it with gettext-tiny)
2020-06-12 06:38:33 <Cogitri> I'd like to have an abuild-cmake too, it's pretty annoying mentioning missing CMake options in every other review
2020-06-12 06:38:49 <mps> ah, we have abuild-meson? didn't know, nice
2020-06-12 06:39:06 <Ariadne> if you read the gnu autoconf manual on config.site
2020-06-12 06:39:17 <Ariadne> it will show how you set default localstatedir etc using this mechanism
2020-06-12 06:39:31 <Ariadne> what is there now is a set of low risk overrides
2020-06-12 06:39:43 <Ariadne> that allow us to speed up configure scripts significantly
2020-06-12 06:39:54 <Ariadne> namely, anything that uses gnulib
2020-06-12 06:40:16 <Ariadne> there is also a set of overrides that disable GNU libintl
2020-06-12 06:40:21 <Ariadne> but those aren't live right now
2020-06-12 06:40:39 <Ariadne> so the next step is to tag a release, package this and integrate it into build-base
2020-06-12 06:40:48 <Ariadne> i can make a layout module i guess
2020-06-12 07:05:07 <Ariadne> the autoconf-policy aport i just pushed is the proof of concept version
2020-06-12 07:14:48 <maxice8> nice
2020-06-12 07:22:27 <ikke> strange, we fixed borgbackup by setting some flags, after which it apparently built. But now after just a pkgrel bump, it fails to build again with a bus error :/
2020-06-12 07:22:32 <ikke> (for arm)
2020-06-12 07:22:44 <ikke> f11f43acb10088bebf37322ef7ab43a89116883f
2020-06-12 07:22:54 <ikke> 5d34bdc1b7621b12292e2988814305ab573c4d1b
2020-06-12 07:23:12 <ikke> ah, there is an upgrade
2020-06-12 07:23:22 <ikke> f601214ebf7a2f927f7e8027814a6b6a92ffd3df
2020-06-12 08:08:01 <MathiasHMK> Morning guys :) Where is the best place to ask advice for adding a new kernel module to Alpine?
2020-06-12 08:08:14 <ikke> You just asked the same question in #alpine-linux ;-)
2020-06-12 08:08:27 <ikke> Most people here are in that channel as well
2020-06-12 08:08:58 <ikke> MathiasHMK: It's better to ask an actual question though, then you can get the actual help you look for :)
2020-06-12 08:16:36 <MathiasHMK> Ok. Well. Specifically, I need to add socketCAN (https://www.kernel.org/doc/html/latest/networking/can.html) such that I can attach and use hardware that communicates via CAN. I've already checked and the module is not present in Alpine 3.10, so I guess I'll have to add it. The question is how?
2020-06-12 08:16:49 <MathiasHMK> I've searched through the Alpine Wiki, and the most likely hit for any guidance is this (https://wiki.alpinelinux.org/wiki/Custom_Kernel). But I'm unsure how exactly to approach it. I've used some Linux before, but I've never really worked with kernel modules. Any guidance on where to start? Any great resources or a place or a thread where I can
2020-06-12 08:16:49 <MathiasHMK> document my findings and issues? I guess I'm not the one who needs CAN support, as it is a protocol widely used in the automotive industry. So I'd like to keep things public :)
2020-06-12 08:18:14 <mps> MathiasHMK: I answered on #alpine-linux
2020-06-12 08:20:27 <mps> ok, it is not enabled in linux-lts, but it is in linux-edge for armv7
2020-06-12 08:22:26 <MathiasHMK> Where can you see that? I'm using x86_64, so ARM is not really going to help :)
2020-06-12 08:22:28 <mps> and aarch64
2020-06-12 08:23:00 <MathiasHMK> Ok, I'll take a look.
2020-06-12 08:23:19 <mps> grep CAN /boot/config-lts
2020-06-12 08:23:25 <MathiasHMK> You may be a complete lifesaver, bud :)
2020-06-12 08:23:37 <mps> # CONFIG_CAN is not set
2020-06-12 08:24:01 <MathiasHMK> Which means? I need to enable the module manually, right?
2020-06-12 08:24:11 <mps> that is for x86_64
2020-06-12 08:24:31 <mps> you have to enable module in config and rebuild kernel
2020-06-12 08:24:39 <clandmeter> mps: linux-edge has diff config for arches?
2020-06-12 08:24:56 <mps> clandmeter: yes
2020-06-12 08:25:07 <MathiasHMK> mps Do we have a wiki page for that?
2020-06-12 08:25:29 <mps> I tried to keep x86_64 to be 'in-line' with linux-lts
2020-06-12 08:26:14 <mps> but with arm I'm more 'adventure'
2020-06-12 08:26:43 <clandmeter> tbh, i would expect the same product if it has the same name.
2020-06-12 08:26:57 <clandmeter> but maybe thats just me :)
2020-06-12 08:26:58 <mps> MathiasHMK: there are doc on kernel.org about these things
2020-06-12 08:28:11 <mps> clandmeter: just tell me what you prefer and I will do that, even if it is against all others wishes
2020-06-12 08:28:54 <clandmeter> im just expressing my opinion, its not a request.
2020-06-12 08:29:00 <mps> in next linux-edge CAN will be enabled for x86_64
2020-06-12 08:29:18 <mps> your opinion is my command
2020-06-12 08:29:30 <clandmeter> :p
2020-06-12 08:29:32 <mps> :)
2020-06-12 08:29:55 <MathiasHMK> You two =D
2020-06-12 08:30:10 <clandmeter> my opinion is, if you can help MathiasHMK, that would be cool :)
2020-06-12 08:30:33 <mps> MathiasHMK: we will not change this option for 3.10 release
2020-06-12 08:30:55 <MathiasHMK> But mps, can you be a bit more specific of what needs to be done to get it running. There's a lot of new stuff to take in. :)
2020-06-12 08:30:59 <mps> but we can change it for edge, and maybe 3.12-stable release
2020-06-12 08:31:00 <clandmeter> maybe he works for Daimler and he will send you one of its products ;-)
2020-06-12 08:31:34 <mps> clandmeter: ofc, I need to test if it works first :)
2020-06-12 08:31:41 <MathiasHMK> This is what I have gotten so far: Edge x86 has the CAN modules, but they need to be enabled.
2020-06-12 08:32:06 <MathiasHMK> To do this, we need to rebuild the kernel, which kernel.org documents because reasons?
2020-06-12 08:32:10 <mps> MathiasHMK: no
2020-06-12 08:32:13 <clandmeter> MathiasHMK: are you ok with running edge release?
2020-06-12 08:32:31 <MathiasHMK> Well, depends on how stable edge is.
2020-06-12 08:32:38 <mps> clandmeter: linux-edge can run on 3.12 without problem
2020-06-12 08:32:41 <MathiasHMK> It is for production systems, real life fuel trucks.
2020-06-12 08:33:17 <mps> just need to add testing in /etc/apk/repositories
2020-06-12 08:33:21 <clandmeter> right, you can pin install the kernel on stable.
2020-06-12 08:34:31 <clandmeter> if it works as expected we can ask ncopa to backport it.
2020-06-12 08:34:37 <mps> MathiasHMK: but it is still not enabled for x86_64
2020-06-12 08:34:59 <MathiasHMK> clandmeter Those are words, yes. What is pin install? Any reading resources would help a lot, I'm a complete novice in this area. :)
2020-06-12 08:35:21 <clandmeter> check our wifi for pinning repositories
2020-06-12 08:35:23 <mps> 
ACTION wonders who use intel in industry control devices

2020-06-12 08:35:30 <clandmeter> s/wifi/wiki
2020-06-12 08:35:30 <alpine-meetbot> clandmeter meant to say: check our wiki for pinning repositories
2020-06-12 08:36:22 <MathiasHMK> Ah, I'll take a look. mps industrial PCs are great. We have fuel trucks driving around in -40 C and such. :)
2020-06-12 08:36:51 <mps> MathiasHMK: if it is urgent I can enable it for x86_64 today in linux-edge kernel
2020-06-12 08:38:42 <mps> MathiasHMK: and I tried to be a truck driver long time ago :) (what's a life)
2020-06-12 08:44:03 <ncopa> MathiasHMK: are you interested in run alpine in cars/trucks?
2020-06-12 08:45:00 <ncopa> what architecture? x86_64?
2020-06-12 08:45:44 <MathiasHMK> ncopa yup, x86_64. We need CAN support though for the truck communication and such :)
2020-06-12 08:46:47 <MathiasHMK> It's not in 3.10 as far we can tell. But we sorta really do need it. The question is how I can add it today (or in a few weeks at max).
2020-06-12 08:47:34 <MathiasHMK> None of my colleagues nor I are that great with Linux, so I'm trying to figure out where to start.
2020-06-12 08:48:22 <ncopa> I dont think we will backport it to 3.10
2020-06-12 08:48:28 <ncopa> possibly 3.12
2020-06-12 08:48:47 <MathiasHMK> Any dates on 3.12 release?
2020-06-12 08:48:53 <ikke> It's already released
2020-06-12 08:49:00 <ncopa> 3.12.1
2020-06-12 08:49:08 <MathiasHMK> And that has CAN?
2020-06-12 08:49:18 <ncopa> well, best case yes
2020-06-12 08:49:29 <ikke> MathiasHMK: We would need to add it..
2020-06-12 08:50:36 <ncopa> it is "easy" for me to add it, but it will increase the size for *everyone*, so I need to be convinced that it is worth it
2020-06-12 08:50:53 <mps> MathiasHMK: in about 15-30 minutes you will have linux-edge with CAN drivers in mirrors, I hope
2020-06-12 08:51:04 <mps> x86_64 arch, I mean
2020-06-12 08:51:28 <ncopa> I'd think that automobile vendors would want build their own kernels anyways?
2020-06-12 08:51:42 <ncopa> rather than use a general purpose kernel
2020-06-12 08:52:02 <mps> ncopa: I agree, and any vendor of machinery
2020-06-12 08:52:18 <mps> but we live in 'express' world nowadays
2020-06-12 08:52:35 <ikke> MathiasHMK left btw
2020-06-12 08:52:40 <MathiasHMK2> So, my other client lost connection...
2020-06-12 08:52:47 <ikke> ah ok
2020-06-12 08:53:00 <MathiasHMK2> I'm here, I don't know what happend. It's still trying to connect.
2020-06-12 08:53:23 <MathiasHMK2> I got "it is "easy" for me to add it, ....
2020-06-12 08:53:44 <ncopa> <@ncopa> I'd think that automobile vendors would want build their own kernels anyways?
2020-06-12 08:53:55 <ncopa> <@ncopa> rather than use a general purpose kernel
2020-06-12 08:54:12 <MathiasHMK2> The best case for adding CAN support is that it is a widely used communication protocol in cars and trucks.
2020-06-12 08:54:19 <mps> MathiasHMK2: you can always look at our IRC log archive https://irclogs.alpinelinux.org/ if you miss something
2020-06-12 08:54:37 <MathiasHMK2> ncopa at least 1 (one) do use Alpine though ;)
2020-06-12 08:55:07 <ncopa> that they don't use alpine may be related that the kernel has CAN disabled by default :)
2020-06-12 08:55:10 <mps> <mps> MathiasHMK: in about 15-30 minutes you will have linux-edge with CAN drivers in mirrors, I hope
2020-06-12 08:55:44 <MathiasHMK2> There's a whole industry around building things on top of the cars anyways. Not being able to communicate with the car/truck is a big bummer.
2020-06-12 08:55:54 <mps> maybe they build their kernels
2020-06-12 08:55:55 <MathiasHMK2> @mps you are lovely :)
2020-06-12 08:56:22 <mps> np
2020-06-12 08:56:57 <mps> I already thought to enable it on x86_64 but didn't because it is not enabled in linux-lts
2020-06-12 08:57:57 <ncopa> MathiasHMK2: can you please create an issue: https://gitlab.alpinelinux.org/alpine/aports/-/issues
2020-06-12 08:58:23 <ncopa> so I can reference to it the git commit message
2020-06-12 08:58:36 <MathiasHMK> Yes, of course!
2020-06-12 08:58:59 <ncopa> do you need USBIP_VUDC?
2020-06-12 08:59:09 <ncopa> This enables the USB/IP virtual USB device controller
2020-06-12 08:59:09 <ncopa> driver, which is run on the host machine, allowing the
2020-06-12 08:59:09 <ncopa> machine itself to act as a device.
2020-06-12 08:59:53 <MathiasHMK> Yes, that would be very nice.
2020-06-12 09:00:18 <mps> huh, and I skipped it by intention
2020-06-12 09:00:27 <MathiasHMK> We may also need to add the Can Utils for userspace.
2020-06-12 09:01:13 <MathiasHMK> I'll do a write-up of it in the issue I'll create on GitLab.
2020-06-12 09:02:29 <ncopa> hang on a sec. i was on wrong machine...
2020-06-12 09:04:27 <ncopa> do you need CAN Identifier (NET_EMATCH_CANID)?
2020-06-12 09:04:36 <ncopa> Say Y here if you want to be able to classify CAN frames based
2020-06-12 09:04:36 <ncopa> on CAN Identifier.
2020-06-12 09:05:15 <MathiasHMK> Y
2020-06-12 09:05:49 <ncopa> Raw CAN Protocol (raw access with CAN-ID filtering) (CAN_RAW)?
2020-06-12 09:06:02 <ncopa> The raw CAN protocol option offers access to the CAN bus via
2020-06-12 09:06:03 <ncopa> the BSD socket API. You probably want to use the raw socket in
2020-06-12 09:06:03 <ncopa> socket has several filter options e.g. ID masking / error frames.
2020-06-12 09:06:03 <ncopa> To receive/send raw CAN messages, use AF_CAN with protocol CAN_RAW
2020-06-12 09:06:03 <ncopa> most cases where no higher level protocol is being used. The raw
2020-06-12 09:06:23 <ncopa>  Broadcast Manager CAN Protocol (with content filtering) (CAN_BCM)?
2020-06-12 09:06:54 <MathiasHMK> Double Y to RAW, that is what are using on our test machine (running Debian)
2020-06-12 09:07:25 <MathiasHMK> CAN_BCM is up to you, no preference from here.
2020-06-12 09:07:54 <ncopa> then its a 'no' :)
2020-06-12 09:08:02 <ncopa> CAN Gateway/Router (with netlink configuration) (CAN_GW)?
2020-06-12 09:08:26 <mps> I enabled these but as 'm'
2020-06-12 09:08:44 <MathiasHMK> We only use CAN_RAW in our case, so I don't know.
2020-06-12 09:09:06 <ncopa> im enabling the needed ones as 'm' as well
2020-06-12 09:09:07 <mps> they don't need to be build in-kernel for most of our users
2020-06-12 09:10:39 <ncopa> SAE J1939 (CAN_J1939) [N/m/y/?] (NEW) ?
2020-06-12 09:11:18 <MathiasHMK> m
2020-06-12 09:11:32 <ncopa> do you use it? fedora has it off
2020-06-12 09:11:42 <ncopa> and i dont want enable stuff that is never used
2020-06-12 09:13:25 <MathiasHMK> We've only tested on Debian 10. If it's off there, then no worries. I'm not aware of what SAEJ1939 is, I'm not a CAN expert. :)
2020-06-12 09:13:46 <mps> ncopa: be prepared for request from SpaceX soon to enable something in kernel, they will need it for starship :)
2020-06-12 09:14:09 <ncopa> Do youl ahve the debian kernel config you are using?
2020-06-12 09:14:13 <clandmeter> SCAN :)
2020-06-12 09:14:36 <MathiasHMK> ncopa nope
2020-06-12 09:14:44 <ncopa> there are a ton of options here and i have no clue waht it is or what is needed
2020-06-12 09:14:56 <ncopa> is it debian 10 vanilla kernel?
2020-06-12 09:15:10 <MathiasHMK> ncopa Si
2020-06-12 09:15:43 <MathiasHMK> What they have is good enough imo. At least for what we are doing. Alpine should stay small and nimble.
2020-06-12 09:16:05 <ncopa> exactly, so i want disable stuff that is not used
2020-06-12 09:17:38 <MathiasHMK> We only utilise CAN_RAW and slcand (serial can daemon). But we can test the image before it is released to check for anything missing.
2020-06-12 09:17:48 <MathiasHMK> For our use case.
2020-06-12 09:18:50 <mps> MathiasHMK2: how fast CAN is? I thought to make my home network with it instead wifi
2020-06-12 09:19:18 <MathiasHMK> mps It's wired...
2020-06-12 09:19:32 <mps> I already have few rs485 links but they are not so fast
2020-06-12 09:19:49 <mps> yes, I know what CAN is, to wire level
2020-06-12 09:20:14 <MathiasHMK> It's about the same I think. What's great about can I the protocol, not the speed.
2020-06-12 09:21:30 <MathiasHMK> ncopa Should I still create an issue on GitLab or is there anywhere else we can continue this conversation in future? I assume you may have questions in future, and I'd also like to help out where needed (such as testing) :)
2020-06-12 09:21:58 <ncopa> yes please, create an issue in gitlab
2020-06-12 09:22:07 <mps> I've got 2500000 bps (bits per second) on rs485 at 20 meters, can go up but it becomes unstable then
2020-06-12 09:22:32 <MathiasHMK> ncopa Will do. Should i refer to this conversation as well?
2020-06-12 09:22:59 <ncopa> not needed
2020-06-12 09:23:08 <MathiasHMK> A'okay.
2020-06-12 09:23:37 <ncopa> the gitlab issue should be the source of truth for history
2020-06-12 09:25:15 <MathiasHMK> ncopa I'll do that then. Anything else you need at the moment?
2020-06-12 09:26:11 <ncopa> i think not, im looking at the debain 10 kernel config
2020-06-12 09:26:46 <mps> send one truck to ncopa, he should be beta tester :)
2020-06-12 09:26:51 <ncopa> ha
2020-06-12 09:27:17 <MathiasHMK> You live in Scandinavia, bud?
2020-06-12 09:27:22 <ncopa> i do
2020-06-12 09:27:31 <ncopa> Norway
2020-06-12 09:27:38 <maxice8> nice
2020-06-12 09:27:44 <MathiasHMK> Dude, most of our trucks are in Norway
2020-06-12 09:27:57 <mps> and we will have 'one truck factor' instead of 'one bus factor' issue
2020-06-12 09:28:07 <ncopa> lol
2020-06-12 09:28:11 <ikke> :D
2020-06-12 09:29:59 <ncopa> MathiasHMK: you also live in Scandinavia?
2020-06-12 09:30:04 <mps> this is a chance to express my opinion about our kernels, imo we should enable most options (as modules whenever posible), only not for really outdated things
2020-06-12 09:30:39 <ikke> That would increase at least the iso size a lot I guess
2020-06-12 09:30:53 <mps> as distro we should have support for different use cases
2020-06-12 09:31:12 <MathiasHMK> ncopa Yes, we're a danish company.
2020-06-12 09:31:38 <mps> ikke: yes, but also will increase use cases by default
2020-06-12 09:33:07 <GitzHMK> As long as CAN_RAW is supported, you can do quite a bit.
2020-06-12 09:34:32 <ncopa> i'm gonna enable the CAN in the kernel and see what the size difference is
2020-06-12 09:34:47 <ncopa> i guess we could add a sub apckage for can drivers
2020-06-12 09:34:48 <mps> to often we says to our users that they should/must build their kernels for them
2020-06-12 09:35:41 <MathiasHMK> It's question of balance I guess. Alpine is great because of its speed and size. Don't change that.
2020-06-12 09:37:19 <mps>  apk info -s linux-lts => 253079552
2020-06-12 09:37:43 <ncopa> linux kernel is huge
2020-06-12 09:37:51 <mps> apk info -s linux-edge => 167305216
2020-06-12 09:38:13 <ncopa> mps: i am worried the linux-edge kernel will cause confusion
2020-06-12 09:38:58 <mps> why?
2020-06-12 09:40:18 <mps> it is testing, and we expect that users who uses testing knows what they do
2020-06-12 09:41:41 <mps> nice thing -lts and -edge can coexist quite fine, without problem
2020-06-12 09:42:02 <ncopa> who is supposed to use the linux-edge kernel?
2020-06-12 09:42:06 <ncopa> who is it for?
2020-06-12 09:42:10 <GitzHMK> Devs?
2020-06-12 09:43:29 <mps> users who need new mainline kernels features
2020-06-12 09:44:06 <mps> it is optimized for performances and new features/drivers
2020-06-12 09:45:52 <mps> and, also devs can test new things as GitzHMK say
2020-06-12 09:46:20 <mps> without experimenting with -lts
2020-06-12 09:46:36 <MathiasHMK> But other devs just need a stable platform such that they can test their own code ;)
2020-06-12 09:46:56 <ikke> Sounds like multiple 'stakes' in a single packages though
2020-06-12 09:47:02 <ikke> testing, speed, new features
2020-06-12 09:47:28 <mps> MathiasHMK: these devs can use -lts without problem
2020-06-12 09:48:17 <mps> ikke: ime, 5.6 is more 'stable' than 5.4
2020-06-12 09:48:48 <GitzHMK> as I see it: -edge is for alpine devs and -lts is for product devs that use alpine for products
2020-06-12 09:48:49 <mps> and I expect 5.7 will be even more
2020-06-12 09:49:03 <mps> GitzHMK: yes
2020-06-12 09:49:13 <mps> and no
2020-06-12 09:49:20 <ikke> mps: they can and do introduce new bugs as well though
2020-06-12 09:49:21 <ncopa> MathiasHMK: do you need CAN_EMS_PCMCIA?
2020-06-12 09:49:23 <GitzHMK> Actually. Is -lts short for Long Term Support or something else?
2020-06-12 09:49:48 <mps> -edge is quite fine for end users, and some are excited to have it ready-made
2020-06-12 09:49:48 <ncopa> long term support yes
2020-06-12 09:49:55 <ikke> It is, based on long term support from upstream
2020-06-12 09:51:08 <ncopa> we'd like to drop pcmcia support
2020-06-12 09:51:38 <MathiasHMK> ncopa no need for CAN_EMS_PCMCIA
2020-06-12 09:51:42 <ncopa> thanks
2020-06-12 09:51:43 <mps> ikke: most fixes for -lts comes from kernels which are in -edge
2020-06-12 09:53:21 <ncopa> MathiasHMK: do you need any pcmcia support?
2020-06-12 09:54:13 <MathiasHMK> ncopa nope, not in our case.
2020-06-12 09:54:22 <ncopa> or anything on ISA bus
2020-06-12 09:54:46 <ncopa> like: ISA Bus based legacy SJA1000 driver (CAN_SJA1000_ISA)
2020-06-12 09:54:56 <MathiasHMK> ncopa nope
2020-06-12 09:54:58 <ikke> mps: yes, of course, that's usually how it works, you backport fixes onto stable releases, the same we do with our stable releases
2020-06-12 10:00:10 <mps> ikke: I understand your points, and you know how long I contemplated and talked with you will I add -edge and take responsibilty to maintain it. it wasn't easy decision
2020-06-12 10:00:18 <ncopa> i'd like to split the kernel package, but not sure how to do it cleanly
2020-06-12 10:00:40 <GitzHMK> ncopa split it how?
2020-06-12 10:00:43 <ikke> mps: please understand me as not criticizing it, just mentioning my observations :)
2020-06-12 10:00:43 <mps> (till clandmeter didn't come with his 'I wish it' :) )
2020-06-12 10:01:00 <ncopa> like having a group of driver in separate package
2020-06-12 10:01:13 <ncopa> CAN is simple, so i think I'll just go ahead and do it for CAN
2020-06-12 10:01:28 <ncopa> so you get the CAN drivers with : apk add linux-lts-can
2020-06-12 10:01:30 <ikke> ncopa: dividing things up properly is often very difficult :)
2020-06-12 10:01:37 <ncopa> and the rest of the users won't get those
2020-06-12 10:01:45 <ncopa> ikke: eaxctly
2020-06-12 10:01:52 <mps> ncopa: we don't have resource for that, and I think you know this
2020-06-12 10:01:58 <ncopa> i was thinking of doing so with other drivers
2020-06-12 10:02:03 <ncopa> like sound drivers
2020-06-12 10:02:10 <ncopa> apk add linux-lts-sound
2020-06-12 10:02:20 <GitzHMK> iirc socketcan ends up as a single .ko module
2020-06-12 10:02:25 <ikke> ncopa: I have the same issue with labels on gitlab :)
2020-06-12 10:02:32 <ncopa> :)
2020-06-12 10:02:39 <ncopa> or wireless drivers
2020-06-12 10:02:56 <ncopa> you probably dont need wireless drivers for kernels running in cloud
2020-06-12 10:02:59 <ncopa> nor sound drivers
2020-06-12 10:03:42 <ncopa> so i think it would be nice to split those out to separate packages
2020-06-12 10:03:49 <mps> ikke: yes, I know that you not critizing me, don't worry
2020-06-12 10:04:43 <ikke> as a developer, I often deal with separation of concerns, and I see several concerns combined here :)
2020-06-12 10:05:04 <ncopa> problem is how we be backwards compatible
2020-06-12 10:05:14 <mps> maybe we can use minix kernel instead of linux
2020-06-12 10:05:28 <ncopa> heh :)
2020-06-12 10:05:34 <ikke> :D
2020-06-12 10:05:39 <mps> ;)
2020-06-12 10:06:38 <mps> ncopa: 'strip unused symbols' give a lot smaller kernel package
2020-06-12 10:07:07 <ncopa> mps: how does that work?
2020-06-12 10:07:26 <mps> 5.7 even have option to keep some if they absolutly needed to keep
2020-06-12 10:07:50 <mps> ncopa: what: option or how kernel works?
2020-06-12 10:08:11 <ncopa> how does 'strip unused symbols' ?
2020-06-12 10:08:12 <mps> s/what:/what?/
2020-06-12 10:08:13 <alpine-meetbot> mps meant to say: ncopa: what? option or how kernel works?
2020-06-12 10:08:15 <ncopa> is it a kernel option?
2020-06-12 10:08:29 <mps> yes, in modules section
2020-06-12 10:08:43 <mps> -edge have it enabled already
2020-06-12 10:09:17 <mps> because this apk is smaller than -lts despite it have more drivers enabled
2020-06-12 10:09:42 <mps>  apk info -s linux-lts => 253079552
2020-06-12 10:09:43 <ncopa> I'll have a look at that
2020-06-12 10:10:04 <mps> apk info -s linux-edge => 167305216
2020-06-12 10:13:58 <ncopa> what is the config name?
2020-06-12 10:14:50 <mps> iirc from head, CONFIG_TRIM_UNUSED_KSYMS=y
2020-06-12 10:15:00 <ncopa> CONFIG_TRIM_UNUSED_KSYMS
2020-06-12 10:15:01 <ncopa> indeed
2020-06-12 10:16:21 <mps> and I use this for my local kernels from 5.0 iirc
2020-06-12 10:16:39 <mps> maybe earlier, can't remember exactly
2020-06-12 10:16:39 <Ariadne> hi
2020-06-12 10:16:47 <ncopa> hi Ariadne
2020-06-12 10:17:14 <ncopa> mps: seems like it does not work with out-of-tree modules
2020-06-12 10:17:33 <ncopa> If unsure, or if you need to build out-of-tree modules, say N.
2020-06-12 10:17:39 <mps> ah, could be
2020-06-12 10:17:45 <Ariadne> last night we had problems with a ban evader in #alpine-linux who did not wish to abide by the CoC
2020-06-12 10:18:16 <Ariadne> it would be nice if we could get some additional op coverage on that channel in the interim
2020-06-12 10:18:17 <mps> but I build locally one out-of-tree module and everything works fine
2020-06-12 10:19:17 <Ariadne> (sorry for the interruption but I think it's important to improve this situation, that particular person is quite vile with the vitriol he says)
2020-06-12 10:20:36 <ncopa> Ariadne: agree. needs to be handled sooner than later
2020-06-12 10:22:54 <Ariadne> in the interim I think it makes sense to give anyone with developer privileges access to that channel so we can shut down that kind of vitriol asap
2020-06-12 10:23:13 <Ariadne> in long term I think the community should pick its moderators
2020-06-12 10:24:48 <Ariadne> but either way we can't have scenario where there's no active ops for half the day while somebody is telling somebody else to kill themselves etc
2020-06-12 10:26:24 <Ariadne> thankfully, that conduct is also not allowed on freenode at large, so they have stepped in to clean it up but
2020-06-12 10:32:46 <Ariadne> anyways my goal is to have an interim resolution to this issue asap
2020-06-12 10:53:40 <AinNero> i think rnalrd and programmerq are good choices for +o
2020-06-12 10:54:07 <ncopa> rnalrd is europe
2020-06-12 10:54:16 <ncopa> we need someone in america time zone
2020-06-12 11:18:54 <andypost[m]> Is it OK to backport commits with Gitlab's cherry-pick UI like !9160
2020-06-12 11:19:30 <Cogitri> Sure, why wouldn't it be OK?
2020-06-12 11:19:45 <Cogitri> I haven't used Gitlab's UI for that, but I often cherry-pick bumps for GNOME apps
2020-06-12 11:19:56 <Cogitri> Via the CLI that is, but it should do the same thing
2020-06-12 11:20:31 <ncopa> andypost[m]: i think its ok, yes
2020-06-12 11:21:22 <ncopa> CAN drivers adds ~800k
2020-06-12 11:21:29 <ncopa> nopt sure its worth split a subpackage
2020-06-12 11:24:44 <mps> well, we don't have to be smaller than small ;)
2020-06-12 11:25:24 <mps> last time I looked arch alarm kernels was double size of ours for armv7 and aarch64
2020-06-12 11:26:15 <ncopa> seems like MathiasHMK left. I'd want that issue id now...
2020-06-12 11:27:50 <mps> but I appreciate your care to keep our software small
2020-06-12 11:28:02 <mps> pkgs*
2020-06-12 11:31:51 <mps> another problem, if we add lib apk which conflicts with pkg in repo, and that package will be upgraded just after lib is built and will depend on this lib, should we add any conflict/replaces in this lib pkg
2020-06-12 11:33:13 <mps> hmm, maybe I should create MR with all this for review, though it will not build on CI because lib pkg is not in repo
2020-06-12 11:45:55 <Shiz> maxice8: i'm .nl locale
2020-06-12 11:46:20 <maxice8> nl would be Netherlands
2020-06-12 11:47:03 <Ariadne> it's settled
2020-06-12 11:47:07 <Ariadne> we clone Shiz
2020-06-12 11:47:18 <Ariadne> put Shiz clone in Canada
2020-06-12 11:47:26 <Ariadne> and then clone Shiz again
2020-06-12 11:47:39 <Ariadne> and put Shiz clone 2 in say... Japan
2020-06-12 11:47:59 <Ariadne> or put OEM Shiz in Japan and Shiz clone 2 in NL
2020-06-12 11:48:01 <maxice8> might as well get one shiz for every timezone
2020-06-12 11:48:03 <Ariadne> idk
2020-06-12 11:48:06 <Ariadne> yes
2020-06-12 11:48:08 <Shiz> also wew, that person last night
2020-06-12 11:48:12 <Ariadne> an army of Shiz
2020-06-12 11:48:30 <Ariadne> that person has been an ongoing issue
2020-06-12 11:48:55 <Ariadne> unfortunately i have not had the energy to do anything about it other than blow up some freenode staffers
2020-06-12 11:49:14 <maxice8> The shiz ascendancy from star wars now makes sense
2020-06-12 11:49:24 <Shiz> pfft
2020-06-12 11:49:32 <Shiz> Ariadne: i'm not sure if oem me would surive in .jp
2020-06-12 11:49:37 <Shiz> but i do appreciate the appreciation
2020-06-12 11:49:55 <Shiz> also, saying this here because i don't want to make it a promise on the ml, but: i tend to be up at weird times, so if there's things going on feel free to try to ping me
2020-06-12 11:50:22 <Ariadne> anyway that dude would be easily shut down with a +q
2020-06-12 11:50:37 <Shiz> or just a +b :p
2020-06-12 11:50:41 <Ariadne> but he always escalates his rage to the point where he starts saying stuff
2020-06-12 11:50:41 <Shiz> considering their behavior and constant trolling
2020-06-12 11:50:49 <Ariadne> that gets him k-lined
2020-06-12 11:50:51 <Ariadne> sooooooo
2020-06-12 11:52:00 <Ariadne> I feel sorry for him, but he always drops in when i'm already out of spoons for the day
2020-06-12 12:35:38 <timlegge> I assume you are aware the s390 builder is having issues
2020-06-12 13:11:02 <Hello71> my 2c about kernel: I care a lot about keeping alpine base small, so personally I am opposed to adding more limited-use modules. it seems to me like users like this one can be served better by a simple system for building custom kernel
2020-06-12 13:13:57 <Hello71> or maybe we just need a better documentation for this, right now it's kind of scattered
2020-06-12 14:34:42 <mps> s390x CI: https://gitlab.alpinelinux.org/timlegge/aports/-/jobs/141991
2020-06-12 15:38:28 <Cogitri> PSA: Exam time is nearing once again, so I probably won't be too available in the next weeks, but feel free to ping me if I'm needed somewhere :)
2020-06-12 15:59:15 <mps> Cogitri: good luck :)
2020-06-12 16:01:31 <Cogitri> Thanks :)
2020-06-12 17:09:24 <mps> timlegge: what is with these two MR !9136 and !9177
2020-06-12 17:11:13 <mps> which of them is better candidate to merge?
2020-06-12 17:52:08 <timlegge> mps: I missed that there was a prior MR in there.  I can look in a couple of hours.
2020-06-12 17:52:22 <timlegge> `
2020-06-12 17:54:26 <mps> timlegge: ok, no hurry, just write a note here or on MR when you finish.
2020-06-12 17:54:54 <mps> they are same 'thing' but they are somewhat different
2020-06-12 18:28:42 <jpsamaroo> is there a command/tool that i can invoke that builds .apk files from stuff in the pkg/ dir?
2020-06-12 18:30:40 <jpsamaroo> i'm trying to figure out how to get a custom build of linux-edge into an .apk
2020-06-12 18:33:03 <mps> abuild
2020-06-12 18:33:33 <mps> apk add alpine-sdk
2020-06-12 18:34:16 <mps> look at alpine wiki development section
2020-06-12 18:40:17 <Hello71> ... in the pkg dir?
2020-06-12 18:40:44 <jpsamaroo> mps: i'm using abuild to build the package (abuild -rK), and got it to work the first time
2020-06-12 18:40:59 <jpsamaroo> Hello71: aports/testing/linux-edge/pkg/
2020-06-12 18:41:14 <jpsamaroo> i had to then rebuild, but it got stuck on a hanging symlink
2020-06-12 18:41:30 <mps> abuild rootpkg
2020-06-12 18:41:33 <jpsamaroo> i'm trying to just generate the .apk's without having to blast away everything and rebuild
2020-06-12 18:43:13 <mps> 'abuild deps unpack prepare', make changes, 'abuild build', 'abuild rootpkg'
2020-06-12 18:44:06 <jpsamaroo> mps: that did it!
2020-06-12 18:44:15 <jpsamaroo> thanks, i'll make a note of that :)
2020-06-12 18:44:52 <mps> np :)
2020-06-12 19:06:35 <mps> interesting MR !9094
2020-06-12 19:06:52 <mps> and there is change for PHP?
2020-06-12 19:07:58 <andypost[m]> for phpmyadmin) file mask for some reason
2020-06-12 19:08:59 <andypost[m]> btw upgrade for php is ready, I'm looking for reviews and ideas how to exclude x86-32 failed tests
2020-06-12 19:09:27 <andypost[m]> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11002#note_96003
2020-06-12 19:10:55 <andypost[m]> It needs to rebuild lots of packages do does not fit into CI
2020-06-12 19:11:54 <andypost[m]> How to coordinate this big upgrade?
2020-06-12 19:14:04 <mps> andypost[m]: ask ikke, he is CI master, maybe you can get more time and resources
2020-06-12 19:17:28 <andypost[m]> I did split it in 2 wip MRs - php itself and 2 commits to bump community and testing packages
2020-06-12 19:18:11 <andypost[m]> Should I split it per package?
2020-06-12 19:20:51 <mps> I'm not sure, but I think CI builds them one by one, so one MR with some number of pkgs is not problem
2020-06-12 19:21:10 <mps> problem could be even one big pkg
2020-06-12 19:22:05 <mps> for example, crystal never finishes on CI due time limit
2020-06-12 19:23:09 <andypost[m]> The same here for ppc64 it sometimes fail because longer then 1h(
2020-06-12 19:25:16 <mps> well, we have to wait for CI master to explain details
2020-06-12 19:26:08 <Cogitri> You can just set a higher timeout for your fork
2020-06-12 19:26:24 <mps> andypost[m]: btw, I'm impressed by your work with such big package as PHP
2020-06-12 19:27:03 <mps> Cogitri: developer can set it? I just wanted to ask ikke if that is possible
2020-06-12 19:28:02 <ikke> yes, but it's best that people don't set all their pipelines to endless timeouts
2020-06-12 19:28:36 <mps> absolutely agree
2020-06-12 19:29:31 <ikke> ultimately it's just a setting on the project level, which everyone can set on their own fork
2020-06-12 19:39:56 <andypost[m]> Good to know! Thanks you!
2020-06-12 20:44:34 <timlegge> mps: !9136 looks fine.  I closed my version
2020-06-12 20:47:42 <mps> timlegge: thanks, merged
2020-06-12 20:53:13 <andypost[m]> runner for s390x still fails https://gitlab.alpinelinux.org/andypost/aports/-/jobs/142213
2020-06-12 20:54:39 <mps> andypost[m]: yes, it fails for most jobs
2020-06-12 21:19:11 <mps> maxice8: sorry, with MR !9183 I thought it will not build on all archs and because that didn't 'checked' all options needed to merge
2020-06-12 21:19:30 <maxice8> Add a WIP:
2020-06-12 21:19:30 <mps> and forgot to mark as WIP
2020-06-12 21:19:44 <maxice8> It also prevents accidental merges (mgmr will fail to merge)
2020-06-12 21:19:57 <mps> yes, I know but forgot it
2020-06-12 21:20:25 <mps> anyway, thanks for help
2020-06-12 21:22:41 <timlegge> mps: !8941 is alos there to move perle-sereal and two dependencies from testing to community.  I just rebased it let me know if you see any issues
2020-06-12 21:26:23 <mps> timlegge: ok, thanks. but will look tomorrow, late is here and I'm going to bed, I'm tired now. good night
2020-06-12 21:27:07 <mps> meh, someone already merged and saved me time tomorrow. :)
2020-06-12 21:27:19 <maxice8> :)
2020-06-12 21:27:24 <mps> I can guess who was done this
2020-06-12 21:27:38 <mps> hehe, thanks
2020-06-12 21:34:33 <Ariadne> humm
2020-06-12 21:34:43 <Ariadne> it would be nice if newedge builders were uploading their build logs
2020-06-12 21:34:48 <maxice8> @Ariadne i kicked my first person! :D
2020-06-12 21:35:20 <timlegge> thanks
2020-06-12 21:36:44 <Ariadne> huh?
2020-06-12 21:36:47 <Ariadne> where
2020-06-12 21:37:06 <maxice8> #alpine-linux, kicked ncopa's test account
2020-06-12 21:37:26 <maxice8> The matrix/riot bridge to IRC is very nice, i can kick like it is matrix and it will kick on IRC
2020-06-12 21:38:35 <Ariadne> ah
2020-06-13 05:32:05 <ikke> fyi, the s390x builder / ci-host are currently unreachable
2020-06-13 05:37:05 <oneinsect> anyone still here?
2020-06-13 05:37:07 <oneinsect> or sleeping?
2020-06-13 05:37:24 <ikke> or just awake :)
2020-06-13 05:37:38 <ikke> it's early morning now in CEST
2020-06-13 05:38:04 <oneinsect> lol my brain is fried, can you advice me with something ikke, i am compiling a package in alpine and it is getting added to repo,
2020-06-13 05:38:30 <oneinsect> is there a way after that to identify newly added packages and install all of them
2020-06-13 05:39:10 <oneinsect> i could extract subpackages but there are not uniform
2020-06-13 05:39:30 <oneinsect> for example they have "$pkgname-$CTARGET_ARCH"-dev
2020-06-13 05:39:31 <oneinsect>  or $pkgver-r$pkgrel"-doc
2020-06-13 05:39:44 <oneinsect> compile and then auto install them?
2020-06-13 05:39:51 <oneinsect> including all sub packages?
2020-06-13 05:40:13 <oneinsect> extract subpackage names*
2020-06-13 05:40:25 <oneinsect> and good morning ikke:
2020-06-13 05:40:30 <maxice8> you can source the APKBUILD and look at subpackages=
2020-06-13 05:41:03 <oneinsect> exactly and the subpackages= have so many non standard
2020-06-13 05:41:07 <oneinsect> entries
2020-06-13 05:41:13 <ikke> oneinsect: Try apk add $(apk -X ~/packages/<reponame> info)
2020-06-13 05:41:38 <ikke> hmm, I'm not sure if that limits it to package from that repo
2020-06-13 05:42:34 <oneinsect> what does that give ikke:?
2020-06-13 05:43:16 <oneinsect> packages which are just added index but not installed?
2020-06-13 05:43:23 <oneinsect> added to index*
2020-06-13 05:43:45 <ikke> No, not really
2020-06-13 05:44:13 <ikke> My goal was to limit info / search to just packages in ~/packages/<repo>, and apk add them all
2020-06-13 05:44:48 <ikke> abuild has no option to automatically install just built packages
2020-06-13 05:44:55 <oneinsect> aaaah
2020-06-13 05:45:26 <oneinsect> you see, i need to maintain the compile order, meaning i compile the first package, add it to index and then install them immediately so that the next package has its dependencies installed
2020-06-13 05:45:48 <oneinsect> i so wish abuild had that option
2020-06-13 05:45:54 <ikke> isn't that just a matter of specifying the dependencies?
2020-06-13 05:46:09 <ikke> You know you can add ~/home/packages/<repo> to /etc/apk/repositories?
2020-06-13 05:46:16 <ikke> then abuild -r will just install them from there
2020-06-13 05:46:33 <ikke> (You need to specify the whole path, though)
2020-06-13 05:46:50 <ikke> /home/<user>/packages/<repo>
2020-06-13 05:47:18 <oneinsect> hmmm i could try that
2020-06-13 05:47:21 <ikke> That's how our builders work, they just use local repositories
2020-06-13 05:47:33 <oneinsect> right now for each package starting from 1st
2020-06-13 05:47:34 <oneinsect> i do
2020-06-13 05:47:36 <oneinsect> abuild -F clean && abuild -F checksum && abuild -F unpack && abuild -F prepare && abuild -F build && abuild -F package && abuild -F rootpkg && abuild -F index
2020-06-13 05:47:53 <oneinsect> abuild -r does all the above right?
2020-06-13 05:47:55 <ikke> You know abuild can take multiple commands
2020-06-13 05:47:58 <ikke> yes
2020-06-13 05:48:07 <ikke> you forgot deps btw
2020-06-13 05:48:17 <mps> :)
2020-06-13 05:48:28 <oneinsect> forgot deps??? meaning
2020-06-13 05:48:29 <mps> '-r' do all
2020-06-13 05:48:38 <ikke> oneinsect: abuild deps installs all required dependencies
2020-06-13 05:48:46 <oneinsect> aha
2020-06-13 05:48:55 <mps> and he forgot undeps
2020-06-13 05:49:01 <ikke> yes, was about to say that
2020-06-13 05:49:08 <oneinsect> and whats undeps?
2020-06-13 05:49:09 <ikke> or just use abuild -r to do everything
2020-06-13 05:49:14 <oneinsect> okie
2020-06-13 05:49:18 <ikke> oneinsect: after building, uninstalling them again
2020-06-13 05:49:31 <oneinsect> i will try that now for a small builder i am building for glibc version
2020-06-13 05:49:39 <oneinsect> thank you ikke:
2020-06-13 05:49:48 <oneinsect> may you live long for 100 years
2020-06-13 05:50:12 <mps> uhm, why so short life
2020-06-13 05:50:16 <oneinsect> lol
2020-06-13 05:50:18 <ikke> oneinsect: protip: also look into lua-aports
2020-06-13 05:50:45 <oneinsect> any specific command for my usage you recommend?
2020-06-13 05:50:48 <ikke> It's not the best documented tool atm, but it can be quite convenient
2020-06-13 05:50:50 <ikke> yes
2020-06-13 05:51:40 <oneinsect> there is ap and buildrepo
2020-06-13 05:52:13 <oneinsect> abuild.lua is over 6 years old?
2020-06-13 05:52:15 <oneinsect> https://github.com/alpinelinux/lua-aports/tree/master/aports
2020-06-13 05:52:33 <ikke> yes, but it still works :)
2020-06-13 05:52:43 <ikke> out builders use both
2020-06-13 05:52:59 <mps> yes
2020-06-13 05:53:21 <ikke> ncopa is planning to rewrite ap
2020-06-13 05:53:27 <ikke> but for now it still works
2020-06-13 05:53:29 <oneinsect> hmmmm
2020-06-13 05:54:18 <ikke> there is ap build-list
2020-06-13 05:54:21 <mps> people nowadays tend to think if something is not updated monthly it is outdated
2020-06-13 05:54:27 <ikke> heh
2020-06-13 05:54:33 <ikke> or dead
2020-06-13 05:54:46 <mps> aha
2020-06-13 05:55:03 <ikke> or ap builddirs <package
2020-06-13 05:55:12 <mps> but most technology is older than these people
2020-06-13 05:55:42 <ikke> oneinsect: ap builddirs is convenient when you have a list of packages, and want to know in which (dependency) order to build the
2020-06-13 05:55:49 <oneinsect> aha
2020-06-13 05:56:07 <oneinsect> yes i use that often since the last time you told to get a list of packages to build in order
2020-06-13 05:56:09 <ikke> ap build-list shows you what packages need to be rebuilt
2020-06-13 05:56:20 <oneinsect> why do we need to rebuild?
2020-06-13 05:56:29 <ikke> if there is a new version, but you did not build it yet
2020-06-13 05:56:39 <oneinsect> aha
2020-06-13 05:56:43 <ikke> it compares to the repo in ~/packages/<repo>
2020-06-13 05:57:45 <oneinsect> there is recursdeps also
2020-06-13 05:57:51 <oneinsect> Recursively print all make dependencies for given packages
2020-06-13 05:58:02 <ikke> yes
2020-06-13 05:58:22 <oneinsect> so let me go back and try abuild -r for the builder
2020-06-13 05:58:43 <oneinsect> ofcourse by adding the local repo
2020-06-13 05:58:45 <ikke> make sure to add the local repo to /etc/apk/repositories
2020-06-13 05:58:47 <ikke> yes
2020-06-13 05:59:07 <ikke> If you want to make sure it *only* uses packages from that repo, just make sure to only have that repo in there
2020-06-13 05:59:22 <oneinsect> there is another headache, post this, i will need to make the iso generation scripts work
2020-06-13 05:59:23 <mps> and 'local' keys?
2020-06-13 05:59:26 <oneinsect> dont know how that will be
2020-06-13 05:59:35 <oneinsect> yes i have local keys
2020-06-13 05:59:42 <mps> good
2020-06-13 05:59:43 <oneinsect> installed
2020-06-13 05:59:43 <oneinsect> signed
2020-06-13 05:59:59 <mps> oneinsect: btw, namaste :)
2020-06-13 06:00:04 <oneinsect> lol
2020-06-13 06:00:15 <oneinsect> Namaste Namaste!
2020-06-13 06:00:37 <mps> it has to be say two times ?
2020-06-13 06:00:46 <oneinsect> naa
2020-06-13 06:01:05 <oneinsect> just that we say that in usage
2020-06-13 06:01:20 <mps> ah, I see why most says it as "Namaste Namaste"
2020-06-13 06:02:05 <oneinsect> yeaaa
2020-06-13 06:03:39 <mps> will remember for next time :)
2020-06-13 06:03:49 <oneinsect> haahaaaa
2020-06-13 06:04:25 <oneinsect> you are in Washington, DC
2020-06-13 06:05:04 <mps> who? ikke or me?
2020-06-13 06:05:15 <ikke> oneinsect: according to that logic, you are as well
2020-06-13 06:05:20 <oneinsect> mps: naa i mistook i think
2020-06-13 06:05:28 <oneinsect> yes WHOIS info i mistook
2020-06-13 06:05:32 <oneinsect> :D
2020-06-13 06:05:33 <oneinsect> sorry
2020-06-13 06:05:36 <ikke> It's the server you are connected to
2020-06-13 06:05:40 <oneinsect> yes
2020-06-13 06:05:49 <mps> we are in Europe, fyi
2020-06-13 06:06:01 <oneinsect> oooh nice
2020-06-13 06:06:26 <oneinsect> my wife lived in east london for a few years
2020-06-13 06:08:04 <oneinsect> before we met, she loves Europe very much but life moves on now
2020-06-13 06:08:24 <oneinsect> anyway back to work
2020-06-13 06:12:39 <mps> oneinsect: don't forget that 'abuild -r' will left src and possible pkg dirs if it fails for any reason
2020-06-13 06:16:14 <ikke> You can control that in /etc/abuild.conf
2020-06-13 06:16:47 <mps> yes
2020-06-13 06:17:32 <mps> but default is to keep them if abuild fails
2020-06-13 06:18:21 <oneinsect> meaning it will leave the src and pkg dirs incase the package fails
2020-06-13 06:18:22 <oneinsect> ?
2020-06-13 06:18:49 <oneinsect> probably i will use abuild clean before starting abuild -r
2020-06-13 06:19:00 <ikke> abuild -r does clean
2020-06-13 06:19:17 <ikke> so no need to manual do it
2020-06-13 06:19:18 <mps> ikke beats me again
2020-06-13 06:21:47 <oneinsect> gdbm expects -fcommon in CFLAGS and whats the cleanest way to pass it without editing /etc/abuild.conf
2020-06-13 06:22:08 <ikke> CFLAGS="$CFLAGS -fcommon" make
2020-06-13 06:22:19 <ikke> or export it just before running make
2020-06-13 06:22:23 <oneinsect> aha i need to patch APKBUILD them
2020-06-13 06:22:28 <oneinsect> then*
2020-06-13 06:22:40 <ikke> yes
2020-06-13 08:07:41 <russkel> yo mps
2020-06-13 08:07:56 <russkel> did you ever get the camera stuff working on your rpi builds?
2020-06-13 08:10:55 <mps> russkel: I didn't tried any camera drivers, so don't know if it works or not
2020-06-13 08:11:42 <russkel> yeah fair enough, I was only able to get it working on RPiOS 64bit
2020-06-13 08:11:55 <russkel> ALARM - no dice, I don't think they had the firmware files
2020-06-13 08:12:01 <russkel> rpis suck
2020-06-13 08:12:26 <russkel> now I am running ROS2 in a docker image because I have given up on ubuntu
2020-06-13 08:18:40 <mps> russkel: yes, RPis are worst choice of arm devices
2020-06-13 08:19:30 <russkel> I mistakenly thought its massive popularity would have made them a great choice, but it seems support for aarch64 is really bad
2020-06-13 08:19:46 <russkel> and if you're not using raspiOS, good luck using anything on there mate!
2020-06-13 08:21:18 <mps> allwinner based boards are most open, I downloaded all their specifications, nothing is hidden
2020-06-13 08:22:09 <mps> except add-ons what they don't have right to disclose
2020-06-13 08:22:43 <mps> i.e. GPUs
2020-06-13 08:24:36 <russkel> did that guy ever create the open source driver for the Mali chip?
2020-06-13 08:28:26 <russkel> also, https://www.raspberrypi.org/forums/viewtopic.php?f=117&t=275370
2020-06-13 08:28:35 <russkel> I dunno if you have seen this or not, but it might be of some help
2020-06-13 08:28:46 <russkel> unlikely if I think about it
2020-06-13 08:41:06 <mps> Mali is ARM ltd property and is closed
2020-06-13 08:41:34 <mps> but new kernels have panfrost and lima already
2020-06-13 08:41:44 <oneinsect> whats wrong with RPI aarch64
2020-06-13 08:41:54 <oneinsect> doesnt the camera drivers work?
2020-06-13 08:41:55 <mps> reverse engineered Mali chips
2020-06-13 08:42:31 <mps> oneinsect: broadcom is too closed
2020-06-13 08:44:35 <russkel> oneinsect, it just doesn
2020-06-13 08:44:43 <oneinsect> hmmmm
2020-06-13 08:44:48 <russkel> really work on anything outside of rpios
2020-06-13 08:45:06 <russkel> in my experience of trying ALARM, ubuntu
2020-06-13 08:45:06 <oneinsect> i thought Alpine did a good job
2020-06-13 08:45:16 <oneinsect> for rpi
2020-06-13 08:45:42 <russkel> I'm sure mps has done a good job but there's only so much one can do if it's all closed
2020-06-13 08:45:55 <oneinsect> indeed
2020-06-13 08:46:12 <russkel> oh how timely: https://www.tomshardware.com/news/kimx-micro-offers-open-source-hardware-raspberry-pi-alternative
2020-06-13 08:46:40 <oneinsect> yeaaa i saw that
2020-06-13 08:46:58 <oneinsect> https://www.phoronix.com/scan.php?page=news_item&px=Raspberry-Pi-Vulkan-Summer-2020
2020-06-13 08:47:06 <oneinsect> Raspberry Pi Vulkan Driver Making Progress But Long Road Remains
2020-06-13 08:49:11 <mps> russkel: I didn't done much for alpine on RPis, just some tests and maybe some small fixes. clandmeter, artok and ncopa did most things iirc
2020-06-13 08:50:21 <mps> uhm, https://www.tomshardware.com/cc.html, 'AD BLOCKER INTERFERENCE DETECTED'
2020-06-13 08:51:33 <russkel> I run ad blocker too but didn't get that.
2020-06-13 08:51:48 <russkel> I guess thanks to my adblocker-blocker blocker list
2020-06-13 08:51:52 <russkel> 
ACTION head explodes

2020-06-13 08:53:22 <mps> I think ghostery add on in FF
2020-06-13 09:02:33 <russkel> "Mini PCIe is also perfect for other types of wireless such as LTE and LoRa radios."
2020-06-13 09:02:46 <russkel> yeah if there's one thing that LoRa needs is pcie
2020-06-13 09:03:53 <Ariadne> i have a solidrun honeycomb
2020-06-13 09:03:59 <Ariadne> i need to actually set it up
2020-06-13 09:09:05 <russkel> has anyone here used lttng or babeltrace?
2020-06-13 10:57:46 <ikke> maxice8: Are you aware you pushed a new aport directly in community>
2020-06-13 10:58:13 <maxice8> Wasn't until you mentioned
2020-06-13 10:58:17 <maxice8> sorry, should have been more careful
2020-06-13 10:59:29 <maxice8> !9200 should fix it
2020-06-13 10:59:50 <maxice8> can't wait for Cogitri bots
2020-06-13 11:14:29 <mps> 
ACTION remembers how long waited for some packages to be moved from testing, but that was before new era

2020-06-13 11:21:37 <russkel> hmm do metapackages exist on alpine?
2020-06-13 11:21:46 <ikke> yes
2020-06-13 11:21:56 <ikke> alpine-sdk for example is a metapackage
2020-06-13 11:22:55 <russkel> thank you
2020-06-13 11:23:59 <russkel> perfect
2020-06-13 11:24:12 <Cogitri> Or the gnome package
2020-06-13 11:24:19 <ikke> yes, there are more
2020-06-13 11:24:25 <ikke> build-base
2020-06-13 11:29:12 <russkel> also has anyone made any python libraries for APKBUILD stuff I can build upon?
2020-06-13 11:29:31 <maxice8> something like lua-aports but in library format and in python ?
2020-06-13 11:29:46 <russkel> let me look at what that is
2020-06-13 11:30:00 <ikke> lua-aports is kind of also a library
2020-06-13 11:30:16 <russkel> I need to create the bridge between ROS package.xml and APKBUILD so I can autogenerate them
2020-06-13 11:30:28 <maxice8> oh
2020-06-13 11:30:31 <maxice8> an APKBUILD generator
2020-06-13 11:30:37 <maxice8> i think wsinatra wrote one in Lisp
2020-06-13 11:31:20 <russkel> it's not an issue if not, I will just use jinja2 or something
2020-06-13 11:34:39 <russkel> parsing :/
2020-06-13 11:35:37 <maxice8> well there is newapkbuild, you just need to parse the .xml
2020-06-13 11:36:09 <maxice8> in fact there is apkbuild-cpan that consults the metacpan API and creates packages with its info
2020-06-13 11:37:37 <russkel> I'll check them out
2020-06-13 12:26:30 <maxice8> a lot of MRs have gone weeks without response from the one that submitted it, do we leave it there, how long till we can close it ?
2020-06-13 12:28:06 <oneinsect> even mine
2020-06-13 12:28:15 <oneinsect> i could not understand the comments
2020-06-13 12:28:27 <oneinsect> hence could not change my MR to the one required
2020-06-13 12:28:42 <ikke> oneinsect: which MR?
2020-06-13 12:29:06 <oneinsect> let me show you
2020-06-13 12:30:07 <oneinsect> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8930
2020-06-13 12:31:02 <ikke> The comment from Cogitri means that you need to rewrite your commit message according to alpine linux' standard
2020-06-13 12:31:45 <ikke> The comment from Leo (maxice8) means that you need to add `default_prepare` at the start of the `prepare` function
2020-06-13 12:32:22 <andypost> what's wrong with s390x builder, can someone restart it?
2020-06-13 12:32:28 <ikke> andypost: it's MIA
2020-06-13 12:32:56 <ikke> Waiting for a response from the people maintaining it
2020-06-13 12:33:11 <oneinsect> rewrite my commit message, hmmmm
2020-06-13 12:33:16 <oneinsect> let me check
2020-06-13 12:33:45 <russkel> oneinsect, just use the one that Cogitri suggested to use
2020-06-13 12:34:03 <maxice8> You can rewrite with git commit --amend
2020-06-13 12:34:07 <russkel> beat me to it
2020-06-13 12:34:07 <andypost> ikke: as I got builders are running fine? just CI affected?
2020-06-13 12:34:19 <ikke> builder is also missing
2020-06-13 12:34:43 <andypost> oh... I thought to commit php 7.4)
2020-06-13 12:36:01 <andypost> maybe disable gtk4 on mips64? it blocks a lot
2020-06-13 12:36:20 <oneinsect> made those changes
2020-06-13 12:36:29 <oneinsect> are they getting reflected?
2020-06-13 12:36:35 <oneinsect> online?
2020-06-13 12:37:05 <ikke> yes, but you added them as new commits
2020-06-13 12:37:16 <oneinsect> darn
2020-06-13 12:37:30 <ikke> git rebase -i can help you squash / fixup them
2020-06-13 12:37:43 <oneinsect> i am doing it via GUI
2020-06-13 12:38:00 <russkel> don't, haha
2020-06-13 12:38:04 <ikke> Via the GUI it's not possible to do any more advanced things
2020-06-13 12:38:39 <russkel> oneinsect, you were in here the other week saying the samething
2020-06-13 12:39:25 <oneinsect> yeaa i dont own the servers/workstation etc at my place, someone kindly lends them now and then
2020-06-13 12:39:37 <oneinsect> hence dont have infrastructure setup
2020-06-13 12:40:14 <oneinsect> okie i see that MR is the same just has version1 version2 etc
2020-06-13 12:41:18 <russkel> I don't understand, are you on your phone or tablet or something haha?
2020-06-13 12:42:26 <oneinsect> this is remote desktop that i am currently on via ipad pro 11
2020-06-13 12:43:11 <oneinsect> there was an option in GUI to squash all commits
2020-06-13 12:44:12 <russkel> that must be frustrating - do you just need this changed?
2020-06-13 12:44:20 <oneinsect> yes if you can please
2020-06-13 12:44:43 <russkel> add russkel as a contributor to your repo
2020-06-13 12:45:09 <oneinsect> let me
2020-06-13 12:48:33 <oneinsect> added russkel
2020-06-13 12:49:24 <russkel> okay lets see
2020-06-13 12:51:32 <russkel> i'll also bump the pkgver
2020-06-13 12:51:35 <russkel> err rel
2020-06-13 12:51:53 <ikke> Make sure to update the checksums as well then
2020-06-13 12:51:54 <oneinsect> sure
2020-06-13 12:53:58 <russkel> what's the verdict on bumping pkgrel ?
2020-06-13 12:54:09 <russkel> I thought you had to
2020-06-13 12:54:13 <ikke> If you want the package to be rebuilt, that's necessary
2020-06-13 12:54:35 <russkel> I trust that's what is desired then, oneinsect ?
2020-06-13 12:54:47 <oneinsect> yes go ahead
2020-06-13 12:55:12 <ikke> But because of this: https://gitlab.alpinelinux.org/alpine/aports/-/blob/8d507dc2ba77ac3624b64daf5987b0088a657079/main/alpine-baselayout/APKBUILD#L29, you need to update the checksums (because it matches it by filename, which changes when you change pkgrel
2020-06-13 12:55:54 <russkel> ah thanks ikke, will do
2020-06-13 12:58:32 <russkel> okay done, hopefully i didn't burn the repo
2020-06-13 12:59:01 <russkel> wait hold on oops
2020-06-13 12:59:32 <russkel> it gave it a different branch name on my end, sigh
2020-06-13 13:01:17 <oneinsect> there is nothing in repo except this
2020-06-13 13:03:27 <russkel> okay there we go, third time lucky
2020-06-13 13:06:39 <oneinsect> perfect all got squashed into one commit
2020-06-13 13:06:46 <oneinsect> thanks russkel:
2020-06-13 13:06:50 <oneinsect> thank you very much
2020-06-13 13:06:51 <russkel> no worries
2020-06-13 13:09:11 <ikke> russkel: thanks from me as well :)
2020-06-13 13:10:37 <russkel> my pleasure
2020-06-13 13:34:01 <ikke> andypost: CI should be back
2020-06-13 13:34:23 <ikke> The builder not yet, but I guess that would come soon as well
2020-06-13 13:38:53 <russkel> if you love something you let it go
2020-06-13 13:38:55 <russkel> etc
2020-06-13 15:09:18 <Greyfn> does anybody have any insight into how build.alpinelinux.org works?
2020-06-13 15:09:41 <ikke> It connects to mqtt over websockets
2020-06-13 15:09:47 <ikke> the builders announce their status over mqtt
2020-06-13 15:10:01 <Greyfn> ah sorry, specifically I mean the builders
2020-06-13 15:10:39 <ikke> It's a script that is executed by listening to push messages to aports on mqtt
2020-06-13 15:10:47 <ikke> The scripts runs in an LXC container
2020-06-13 15:11:06 <ikke> it updates the local git repo and determines what needs to be built in what order
2020-06-13 15:11:25 <ikke> afterwards, the packages are uploaded to a master mirror
2020-06-13 15:11:34 <Greyfn> and is that whole process using in-house software or is it something off-the-shelf?
2020-06-13 15:11:41 <ikke> in-house mostly
2020-06-13 15:12:07 <Greyfn> is there a repo or set of repos?
2020-06-13 15:12:16 <Greyfn> I've tried looking but it's a bit of a black box it seems
2020-06-13 15:12:46 <ikke> Yeah, it's not documented extensively
2020-06-13 15:13:07 <Greyfn> I'm trying to put together a mirror as a learning exercise, and the build server is the only missing part
2020-06-13 15:13:58 <Greyfn> well thanks for the info
2020-06-13 15:14:05 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/main/aports-build
2020-06-13 15:14:15 <Greyfn> ah!
2020-06-13 15:14:17 <Greyfn> perfect
2020-06-13 15:14:24 <ikke> https://github.com/alpinelinux/lua-aports/
2020-06-13 15:14:45 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/main/mqtt-exec
2020-06-13 15:14:57 <ikke> That's the tool that listens on mqtt and runs the build script
2020-06-13 15:14:58 <Greyfn> that'll do nicely
2020-06-13 15:15:08 <Greyfn> I'll dig around in those
2020-06-13 15:15:10 <Greyfn> thanks!
2020-06-13 15:18:45 <ikke> Note that we do want to improve this system at some point
2020-06-13 15:19:58 <Greyfn> that seems to be a common theme; it appears almost every tool I've asked about I've had that same statement
2020-06-13 15:20:13 <Greyfn> I'm curious though, why? what are the shortcomings at the moment?
2020-06-13 15:21:19 <ikke> The builders are stateful
2020-06-13 15:21:37 <ikke> and also not very transparent
2020-06-13 15:22:05 <ikke> You want every build be done in a clean environment
2020-06-13 15:22:39 <ikke> There is also no timeout, so some builds might get stuck forever until someone decides to kill it
2020-06-13 15:22:52 <Greyfn> I suppose, but it seems to be working pretty well right now - at least from a user perspective
2020-06-13 15:22:59 <Greyfn> the timeouts thing I can imagine being a problem though
2020-06-13 15:23:22 <ikke> Yes, but it's a delicate issue
2020-06-13 15:23:25 <oneinsect> ikke
2020-06-13 15:23:36 <oneinsect> i wish we had split the packages in more sub categories
2020-06-13 15:23:37 <ikke> you don't want timeouts to cause valid long builds to be canceled
2020-06-13 15:23:45 <oneinsect> could have helped with timeouts
2020-06-13 15:23:56 <ikke> No, that has nothing to do with it
2020-06-13 15:24:02 <oneinsect> like networking, graphical etc
2020-06-13 15:24:07 <ikke> stuck packages happen due to deadlocks
2020-06-13 15:24:17 <oneinsect> and the core system utilities also, i mean otherwise also
2020-06-13 15:24:19 <ikke> most often in test suites
2020-06-13 15:24:41 <ikke> oneinsect: separating things more also leads to more issues
2020-06-13 15:24:53 <oneinsect> but look at
2020-06-13 15:24:54 <oneinsect> https://code.foxkit.us/adelie/packages/-/tree/master/
2020-06-13 15:24:56 <ikke> inter repo dependencies
2020-06-13 15:25:05 <oneinsect> their system is a core packages only
2020-06-13 15:25:20 <oneinsect> and LFS and beyondLFS
2020-06-13 15:25:40 <oneinsect> saves so much pain during bootstrapping
2020-06-13 15:26:11 <oneinsect> i agree with that inter repo dependencies, but you always a system core packages
2020-06-13 15:26:37 <ikke> This is trickier then you first think though
2020-06-13 15:26:42 <Greyfn> must take a decent amount of compute to build everything; I see 51 builders on the status page
2020-06-13 15:26:47 <Greyfn> what sort of hardware are they running on?
2020-06-13 15:27:27 <ikke> each arch has a dedicated builder with a decent amount of cores and memory
2020-06-13 15:27:56 <ikke> different versions of each arch run on the same builder
2020-06-13 15:31:50 <ikke> oneinsect: it's interesting they have user/ but also some system/user/* packages
2020-06-13 15:33:26 <ikke> oneinsect: We already have packages that ideally we want to move from main to community, but cannot because other packages in main somehow depend on them
2020-06-13 15:35:15 <oneinsect> yes indeed ikke: i liked their layout
2020-06-13 15:35:58 <oneinsect> we got to simply stuff for those who only want to build around that core set of packages
2020-06-13 15:49:23 <AinNero> dd
2020-06-13 15:49:26 <AinNero> oops
2020-06-13 15:53:23 <[[sroracle]]> i'm not sure what you mean by system/user/
2020-06-13 15:53:35 <[[sroracle]]> packages are either in one or the other..
2020-06-13 15:54:50 <ikke> Oh, sorry, I confused the root somehow :)
2020-06-13 15:55:28 <ikke> the gitlab interface sometimes shows all user packages in the root
2020-06-13 15:56:36 <ikke> https://imgur.com/a/dntT9Dn
2020-06-13 15:56:59 <[[sroracle]]> what the heck lol
2020-06-13 15:57:02 <[[sroracle]]> interesting
2020-06-13 15:57:09 <oneinsect> naaa
2020-06-13 15:57:16 <oneinsect> yes you confused the root
2020-06-13 15:57:18 <ikke> it's not that they're in the root
2020-06-13 15:57:21 <oneinsect> yes
2020-06-13 15:57:25 <ikke> just deaggregated
2020-06-13 15:57:28 <oneinsect> they are not in root
2020-06-13 15:57:34 <[[sroracle]]> probably just a gitlab bug
2020-06-13 15:58:16 <ikke> if you navigate back from a folder, it does that
2020-06-13 15:59:38 <oneinsect> damn bugs!
2020-06-13 15:59:48 <oneinsect> i remember mem in black when it got released
2020-06-13 16:55:56 <russkel> are you kidding me?! why on earth does it require maven and jdk
2020-06-13 16:56:19 <russkel> cyclonedds is a C project yet uses these?!
2020-06-13 17:47:05 <afontain_> question: if I've written a tiny script for an aports, does it make sense to add a spdx license identifier or is is considered to be the same license as the APKBUILD?
2020-06-13 17:48:34 <afontain_> (by the way, what's the APKBUILDs licenses?)
2020-06-13 17:52:04 <dalias> i hate gitlab
2020-06-13 17:52:21 <dalias> alpine should migrate to something non-awful :)
2020-06-13 17:52:57 <ikke> It works for us :)
2020-06-13 17:53:07 <dalias> the ux is soooooo bad tho
2020-06-13 17:53:34 <ikke> I've gotten used to it
2020-06-13 17:53:41 <ikke> But we use it at $work as well
2020-06-13 17:54:49 <ikke> And many other solutions seems to choke on aports
2020-06-13 18:00:06 <andypost> s390x is dead again, looks it limited to 80mins and php tests just longer
2020-06-13 18:00:30 <ikke> andypost: yes, noticed it
2020-06-13 18:02:18 <mps> heh, in praise to linux-edge, first kernel which survived on my aarch64 chromebook working from emmc 5 days, without emmc driver crash
2020-06-13 18:03:20 <mps> with suspend-to-ram at night and resume in morning. Finally
2020-06-13 18:03:34 <ikke> nice
2020-06-13 18:05:34 <mps> that is related to our linux-edge talk yesterday :)
2020-06-13 18:05:50 <ikke> I'm quite aware ;-)
2020-06-13 18:06:11 <mps> ;)
2020-06-13 18:06:29 <ikke> But I'm happy for you, unstable systems are no fun
2020-06-13 18:06:52 <mps> thanks ikke
2020-06-13 18:07:07 <ikke> For some reason my (non-alpine) laptop loses wifi from time to time
2020-06-13 18:07:15 <ikke> I have to reset the wifi card on a PCI level
2020-06-13 18:07:21 <mps> if all alpine developers could be kind like you
2020-06-13 18:07:25 <ikke> lately it does not happen often though
2020-06-13 18:09:02 <mps> I have similar situation on my old x86_64 asus laptop, but restart iwd is enough, no need to touch driver
2020-06-13 18:09:28 <ikke> I have a script which basicaly resets my entire network stack :D
2020-06-13 18:10:13 <mps> hackers method to solve problem :)
2020-06-13 18:10:34 <ikke> Took a while before I found the solution, before I had to just reboot my system
2020-06-13 18:11:09 <mps> big hammer doesn't help on it ;P
2020-06-13 18:11:16 <ikke> I probably should open the laptop to see if there are any hardware issues (at some point, it seemed to be correlated to movement)
2020-06-13 18:11:25 <ikke> mps: I need you to know where to hit it :P
2020-06-13 18:12:55 <mps> oh, my daughter is good for opening and disassembling laptops, but not so much good to assembling them back :)
2020-06-13 18:13:00 <ikke> haha :D
2020-06-13 18:13:24 <ikke> I used to do that all the time
2020-06-13 18:13:36 <ikke> disassemble things without a clue how to get it back together
2020-06-13 18:13:53 <mps> I do only to open cover for replacing disks
2020-06-13 18:14:16 <afontain_> is there a way to disable a subpackage for some architecture?
2020-06-13 18:14:39 <ikke> afontain_: Only add it when it's not that arch
2020-06-13 18:14:51 <afontain_> ah, maybe case "$CARCH" in …
2020-06-13 18:14:53 <ikke> case $CARCH in
2020-06-13 18:14:54 <ikke> yes
2020-06-13 18:15:56 <mps> and another good news, I finally found u-boot version which can work on RPi zero
2020-06-13 18:16:53 <mps> now I can boot alpine linux-edge using u-boot on RPi zero, a lot easier to experiment with kernels
2020-06-13 18:42:30 <Cogitri> PureTryOut[m]: Should we add dbg subpkgs for qt-* ? They're probably useful for debugging loads of stuff
2020-06-13 18:56:14 <Hello71> ikke: ath10k?
2020-06-13 18:57:40 <ikke> No, intel 3168NGW
2020-06-13 19:09:52 <Hello71> I heard that ath9k is pretty good, iwl is mediocre, and ath10k is crap
2020-06-13 19:10:49 <Hello71> have ath10k, can confirm ath10k sucks. hardware keeps freezing and the kernel doesn't know how to restart it, and then it blocks half the userspace in weird syscalls
2020-06-13 19:11:02 <Hello71> can't even turn on monitor mode without downloading some sketchy third-party firmware
2020-06-13 19:12:02 <oneinsect> abuild -r is running tests as well, hmm taking a long time
2020-06-13 19:12:30 <ikke> yes, it does :)
2020-06-13 19:13:20 <oneinsect> another strange problem is it does Uninstalling dependencies...
2020-06-13 19:13:33 <ikke> that's the undeps step
2020-06-13 19:13:44 <ikke> after the package is built, the deps are no longer necessary
2020-06-13 19:13:44 <oneinsect> cant i just ask it not to do that?
2020-06-13 19:13:47 <ikke> yes
2020-06-13 19:13:51 <ikke> /etc/abuild.conf
2020-06-13 19:13:54 <oneinsect> aaaah
2020-06-13 19:14:30 <ikke> It does make your builds less reliable though
2020-06-13 19:15:05 <oneinsect> i mean my problem i have to build the entire distro by building one package on top of the other
2020-06-13 19:15:09 <oneinsect> since this is bootstrap
2020-06-13 19:15:32 <oneinsect> i dont want it to delete the chroot compiler files etc since i dont have apks for them
2020-06-13 19:15:40 <oneinsect> if you know what i mean
2020-06-13 19:16:25 <oneinsect> if the deps or files of the deps are removed, i cannot get them, since the chroot is not built using apks
2020-06-13 19:16:28 <ikke> then add them to /etc/apk/world
2020-06-13 19:16:57 <ikke> I would try to package them as soon as possible though
2020-06-13 19:17:44 <oneinsect> abuild -F clean && abuild -F checksum && abuild -F unpack && abuild -F prepare && abuild -F build && abuild -F package
2020-06-13 19:17:56 <oneinsect> where does abuild dep fit in the above during building?
2020-06-13 19:18:35 <ikke> somewhere before prepare
2020-06-13 19:18:41 <oneinsect> aha
2020-06-13 19:18:57 <ikke> and you can do: abuild -F clean checksum deps unpack prepare build package
2020-06-13 19:19:02 <oneinsect> let me retry the whole steps again
2020-06-13 19:19:04 <ikke> no nee to call abuild multiple times
2020-06-13 19:19:12 <oneinsect> understood
2020-06-13 19:54:11 <oneinsect> ikke: thank you
2020-06-13 19:54:14 <oneinsect> this works for me
2020-06-13 19:54:15 <oneinsect> abuild -F clean checksum deps unpack prepare build package rootpkg index
2020-06-13 19:54:26 <oneinsect> i am loop building all packages
2020-06-13 19:54:41 <oneinsect> manages dependencies on its own
2020-06-13 19:54:49 <oneinsect> i add tests later
2020-06-13 19:55:02 <oneinsect> need to get alpha iso first to establish the builder
2020-06-13 19:55:53 <ikke> alpine itself is bootrstrapped without iso
2020-06-13 19:56:30 <ikke> the iso is created when everything is finished building
2020-06-13 19:57:29 <oneinsect> hm....well i have an alpine chroot with pure glibc (no apks), will need to loop build each apk and install them into the chroot itself thereby getting the entire stable system with local apk repo
2020-06-13 19:57:55 <oneinsect> then my first iso comes and from there on life becomes very very easy
2020-06-13 19:58:50 <oneinsect> i need to check each page for potential issues of patches etc
2020-06-13 19:58:57 <oneinsect> each package*
2020-06-13 19:59:05 <oneinsect> so i have to go that way
2020-06-13 20:00:30 <oneinsect> strangely the musl patched APKBUILDs for most packages are compiling perfectly (kinda strange)
2020-06-13 20:03:06 <ikke> I don't think it's too strange
2020-06-13 20:03:41 <dalias> why would that be strange?
2020-06-13 20:04:06 <dalias> except in some cases where the upstream was broken enough it was hard to do a correct fix, the patches are just fixing bugs (portability bugs) not doing anything musl-specific
2020-06-13 20:04:09 <oneinsect> i thought patches will only work with musl
2020-06-13 20:04:14 <oneinsect> hmmmm
2020-06-13 20:04:19 <dalias> that's missing the whole point of musl...
2020-06-13 20:05:05 <ikke> The patches are not "make it work with musl", but more "don't rely on glibc"
2020-06-13 20:05:39 <oneinsect> aha
2020-06-13 20:05:40 <maxice8> The patches mostly deal with usage of glibc specific features
2020-06-13 20:06:11 <dalias> often it
2020-06-13 20:06:11 <maxice8> Mostly replacing them with posix and other widely used functions, so it should work in more places
2020-06-13 20:06:25 <oneinsect> great! this is great to know!
2020-06-13 20:06:28 <dalias> often it's not even a glibc *feature*, just gratuitously wrong things that happen to work on glibc
2020-06-13 20:06:37 <dalias> like using an internal-use-only type name prefixed with __
2020-06-13 20:06:39 <dalias> e.g. __sigset_t
2020-06-13 20:06:53 <dalias> or assuming header A includes header B implicitly when it's not supposed to
2020-06-13 20:06:55 <Hello71> ... that then turn into de facto api
2020-06-13 20:07:28 <dalias> using anything with __ in the name is wrong by default unless there's a documented reason why you should
2020-06-13 20:18:18 <oneinsect> hmmmm
2020-06-13 20:19:14 <dalias> hello71, the vast majority of software with problems like that already fails to build on bsd, mac, etc., so it's not really a matter of de facto api even, just linux+glibc centric laziness
2020-06-13 20:20:42 <PureTryOut[m]> Cogitri: sure I wouldn't mind
2020-06-13 20:20:55 <Hello71> I'm referring to cases where glibc cannot remove api because of backwards compatibility
2020-06-13 21:06:09 <AinNero> dalias: if there is something wrong with me, say it to me please, and i might be able to work something out
2020-06-13 21:06:17 <AinNero> other people are also invited, just query me
2020-06-13 21:06:45 <AinNero> say it to my face whats wrong with me and i'll look how i can work on it
2020-06-14 01:28:53 <dalias> ainnero, what's wrong with you is that you think people owe you an argument
2020-06-14 01:29:49 <AinNero> go ahead and call people bigots and ban them, i think we are done here
2020-06-14 01:30:20 <AinNero> if you are so right that your ideas dont need explaining, good for you
2020-06-14 01:30:56 <dalias> and ffs please stop stalking me
2020-06-14 01:31:08 <AinNero> then dont post online what i say to you
2020-06-14 01:31:29 <AinNero> i mean like, what is your twitter for if not the public? am i not part of the public?
2020-06-14 01:32:11 <dalias> i did not identify you or quote you in any nontrivial amount. i wrote about requests for bad-faith arguments
2020-06-14 01:32:27 <dalias> you identified yourself
2020-06-14 01:33:59 <AinNero> at least reply to me or something
2020-06-14 01:34:03 <dalias> not because i care about you, but because it's a common demand and your question was a good starting point for framing it
2020-06-14 01:34:10 <AinNero> but answering public on twitter and then call me a stalker is just a shitty move
2020-06-14 01:34:38 <dalias> i don't even know what you want a reply to
2020-06-14 01:35:51 <AinNero> ah fuck off, i asked enough times
2020-06-14 01:36:03 <AinNero> +b was your answer, "must have been in bad faith"
2020-06-14 01:36:16 <AinNero> good night
2020-06-14 01:40:19 <[[sroracle]]> this is weird and also off topic
2020-06-14 01:40:31 <dalias> yes it is
2020-06-14 01:40:59 <maxice8> andypost: ping, about php7.
2020-06-14 01:52:52 <Ariadne> i feel like dalias is allowed to operate #musl however he wishes to do so
2020-06-14 01:52:58 <Ariadne> being that it is, you know, his project
2020-06-14 01:53:24 <Ariadne> if he wants to ban someone simply because he dislikes them, that's his business.  he doesn't need to justify it really.
2020-06-14 01:53:37 <Ariadne> his space, his rules
2020-06-14 01:54:23 <Ariadne> and please do not bring alpine into your disputes with other projects
2020-06-14 01:55:31 <Ariadne> if dalias were to say ban me from #musl ebcause he thinks i'm an idiot, that would be his right to do.  i would be disappointed, but again, it's his space, with his rules.
2020-06-14 01:56:45 <Ariadne> similarly, alpine irc channels require adherence to the alpine code of conduct, this is a decision implemented by the alpine core team
2020-06-14 01:57:00 <Ariadne> but this is all offtopic anyway, please don't bring this stuff here
2020-06-14 01:58:30 <Ariadne> and besides, if you dislike how musl is run by dalias, you can fork it
2020-06-14 01:58:40 <Ariadne> and you can also fork alpine to replace musl with your libc fork
2020-06-14 01:58:40 <Hello71> I was thinking to post something like that. then I was also thinking that it is also important to have congeniality within the project, and it is important for people to agree and not have the major internal rifts. at that point I got distracted and started working on other stuff.
2020-06-14 01:59:04 <AinNero> like, if dalias woud explain their rationale, and its something i could understand
2020-06-14 01:59:11 <AinNero> that would already be fine with me
2020-06-14 01:59:21 <Ariadne> its his channel, if he doesn't want you there, that's between you and him
2020-06-14 01:59:24 <Ariadne> please leave us out of it
2020-06-14 02:00:20 <Hello71> on the whole I am inclined to say that if it is reasonably possible for you two to avoid each other while remaining within the project, then we should not have this discussion here
2020-06-14 02:00:58 <Hello71> on the other hand, if it is absolutely impossible to work otherwise, then we are forced to have a discussion. that doesn't seem to be the case to me at this point, although I could very well be wrong now or in the future
2020-06-14 02:01:06 <Eighth_Doctor> 
ACTION feels like he was transported to 2005

2020-06-14 02:01:35 <Ariadne> Eighth_Doctor: yeah basically
2020-06-14 04:04:56 <russkel> does abuild prevent access to /tmp/ ?
2020-06-14 04:15:59 <maxice8> I belive only if you use rootbld
2020-06-14 04:16:14 <maxice8> looking at /usr/bin/abuild shows it creates BUILD_ROOT=$(mktemp /var/tmp/pkg.XXXXXX)
2020-06-14 04:16:44 <maxice8> and with bwrap (used in rootbld) it does --bind $BUILD_ROOT/tmp /tmp
2020-06-14 04:17:18 <russkel> weird, getting test failures saying can't find /tmp/blahblahblah
2020-06-14 04:17:42 <russkel> https://github.com/ros-infrastructure/rosdep/issues/765
2020-06-14 04:17:43 <maxice8> that shouldn't be a problem, the program should be able to use /tmp
2020-06-14 04:17:58 <russkel> Execution failed with OSError: [Errno 2] No such file or directory: '/tmp/tmpgbquad8l'
2020-06-14 04:17:59 <russkel> yeah
2020-06-14 04:18:00 <maxice8> it will just use a /tmp created specifically for it
2020-06-14 04:18:35 <russkel> 
ACTION wonders

2020-06-14 04:20:03 <maxice8> You're using rootbld, docker or just abuild ?
2020-06-14 04:23:02 <maxice8> If you're using the latter it is possible you have /tmp mounted with noexec
2020-06-14 04:42:51 <russkel> maxice8, that was CI
2020-06-14 04:43:27 <russkel> gitlab runners
2020-06-14 04:45:41 <maxice8> oh i see, Let me check what they run
2020-06-14 04:58:15 <maxice8> Danct12: ping
2020-06-14 07:03:45 <andypost[m]> maxice8 pong)
2020-06-14 07:21:46 <russkel> any hints maxice8 ?
2020-06-14 07:25:15 <ikke> russkel: CI jobs run in this container: https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci
2020-06-14 07:25:27 <ikke> afaik, writing to /tmp should not be restricted
2020-06-14 08:10:03 <maxice8> @andypost so i understand both php MRs can be merged ?
2020-06-14 08:37:11 <russkel> thanks ikke then I have no idea
2020-06-14 08:38:51 <ikke> russkel: do you have an MR? I'll try to see if I can reproduce it
2020-06-14 08:39:04 <russkel> I do good sir
2020-06-14 08:39:32 <russkel> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8976/diffs?commit_id=02f2c88529d5e6473e2155bcd540e1bea233b3d8
2020-06-14 08:40:12 <russkel> oh wait I have checks disabled
2020-06-14 08:40:17 <russkel> maybe that was just my machine
2020-06-14 08:40:26 <russkel> crap maybe I got confused
2020-06-14 08:40:42 <russkel> let me remove that and see what happens
2020-06-14 09:19:19 <russkel> ikke, https://gitlab.alpinelinux.org/russkel/aports/-/jobs/143582#L1222
2020-06-14 09:19:26 <russkel> still happening by looks of things
2020-06-14 09:19:44 <ikke> Will look at that in a bit
2020-06-14 09:20:13 <russkel> yeah no rush, just if you get a clue
2020-06-14 09:20:23 <russkel> I haven't looked at source, maybe they're doing something silly
2020-06-14 09:25:24 <andypost[m]> maxice8 not yet, it needs to run on s390x and rebase
2020-06-14 09:56:45 <andypost[m]> it looks like php build makes CI to fails s390x(
2020-06-14 09:57:34 <andypost[m]> it just interrupts randomly https://gitlab.alpinelinux.org/andypost/aports/-/jobs/143662
2020-06-14 09:58:55 <clandmeter> andypost[m]: we are aware
2020-06-14 09:59:05 <clandmeter> andypost[m]: its killing our ci machine
2020-06-14 09:59:24 <clandmeter> ci for s390x is currently down for an upgrade
2020-06-14 10:00:50 <andypost[m]> Thanks! Cos I see similar failures only with php) karma...
2020-06-14 10:07:55 <clandmeter> machine is rebooting, so ci should be back shortly if all goes well.
2020-06-14 10:30:45 <oneinsect> rootbld option of abuild builds in clean chroot?
2020-06-14 10:31:40 <Cogitri> Basically, yes
2020-06-14 10:31:59 <Cogitri> It builds in a bubblewrap sandbox in which a fresh alpine system is installed
2020-06-14 10:32:27 <Cogitri> Pretty nifty for reproducible builds (where you don't want the host system to influence the build)
2020-06-14 10:32:46 <oneinsect> so basically i use it as abuild -F rootbld clean checksum unpack prepare build package
2020-06-14 10:32:57 <Cogitri> Although I personally use docker-abuild since that's a fair bit faster for me and allows for super easy switching between branches
2020-06-14 10:33:03 <Cogitri> Jist abuild rootbld should do it
2020-06-14 10:33:11 <oneinsect> alright
2020-06-14 10:36:04 <oneinsect> abuild-rootbld package not installed
2020-06-14 10:36:05 <oneinsect> ............. is it a separate package?
2020-06-14 10:36:13 <ikke> yes
2020-06-14 10:36:27 <oneinsect> where is the source code?
2020-06-14 10:36:34 <oneinsect> cannot find it here
2020-06-14 10:36:34 <oneinsect> https://dev.alpinelinux.org/archive/abuild/
2020-06-14 10:37:06 <ikke> It's a separate project
2020-06-14 10:37:16 <oneinsect> oooh
2020-06-14 10:37:19 <ikke> sorry, no
2020-06-14 10:37:44 <oneinsect> https://pkgs.alpinelinux.org/package/edge/main/x86/abuild-rootbld
2020-06-14 10:37:46 <ikke> ah
2020-06-14 10:37:48 <oneinsect> 1.2kb?
2020-06-14 10:37:49 <ikke> it's a metapackage
2020-06-14 10:38:01 <ikke> https://git.alpinelinux.org/aports/tree/main/abuild/APKBUILD#n72
2020-06-14 10:39:16 <oneinsect> but
2020-06-14 10:39:25 <ikke> but?
2020-06-14 10:39:28 <oneinsect> i only see mkdir -p "$subpkgdir
2020-06-14 10:39:38 <ikke> yes, like I said, a metapackage
2020-06-14 10:39:52 <ikke> basically just there for the dependencies
2020-06-14 10:40:37 <oneinsect> okie
2020-06-14 10:40:42 <ikke> abuild by default does not depend on bubblewrap and gettext, but if you want to use rootbld, you need them
2020-06-14 10:40:51 <oneinsect> alrite
2020-06-14 10:43:40 <oneinsect> seems it requires the subpackage to be present even its a meta package for the command to work
2020-06-14 10:43:48 <oneinsect> even though*
2020-06-14 10:44:06 <ikke> yes, it's easier to check for the metapackage than for all the deps
2020-06-14 10:44:15 <ikke> which could potentially change
2020-06-14 10:44:31 <oneinsect> thanks ikke
2020-06-14 12:32:12 <oneinsect> any ideas why
2020-06-14 12:32:15 <oneinsect> >>> ERROR: abuild: Found non-PIE files that has SUID:
2020-06-14 12:32:16 <oneinsect>         /usr/bin/abuild-sudo
2020-06-14 12:32:23 <oneinsect> latest abuild does that?
2020-06-14 12:32:38 <oneinsect> i am trying build an abuild.apks and it does that
2020-06-14 12:32:50 <oneinsect> abuild package to be exact
2020-06-14 12:33:36 <ikke> I guess you are not building your software as PIE
2020-06-14 12:34:04 <ikke> It's a policy check to only allow PIEs to be suid
2020-06-14 12:34:59 <oneinsect> all i am doing is abuild -F clean checksum unpack prepare build package rootpkg index
2020-06-14 12:35:05 <oneinsect> on abuild itself
2020-06-14 12:36:31 <nmeum> are you using our default gcc?
2020-06-14 12:36:46 <oneinsect> naaa
2020-06-14 12:36:54 <oneinsect> i am on gnu glibc
2020-06-14 12:37:01 <oneinsect> and gcc 10.1.0
2020-06-14 12:37:12 <oneinsect> they all compile fine and able to create apks
2020-06-14 12:37:26 <oneinsect> only abuild itself doesnt create its apk
2020-06-14 12:37:30 <nmeum> well we patch gcc itself to make sure it always creates PIEs
2020-06-14 12:37:37 <ikke> You need to pass -fPIE I guess to the linker?
2020-06-14 12:37:37 <nmeum> if you don't have that you will run into problems
2020-06-14 12:37:57 <oneinsect> okie let me do it in abuild.conf then
2020-06-14 12:38:24 <oneinsect> for ldflags?
2020-06-14 12:39:08 <oneinsect> export LDFLAGS="-Wl,--as-needed -fPIE"
2020-06-14 12:39:50 <oneinsect> same error even after that
2020-06-14 12:52:40 <nmeum> any repology expert around? is there any way to sort packages by “date flagged” or something along those lines, i.e. to find recently outdated packages in Alpine
2020-06-14 12:53:09 <maxice8> You can look at RSS feeds of individual maintainers
2020-06-14 12:53:16 <maxice8> saldy i know now way to do it for the complete list
2020-06-14 12:54:12 <nmeum> i haven't found any way of doing it either which seems very strange to me as this is such an obvious feature
2020-06-14 12:57:29 <oneinsect> got it
2020-06-14 12:57:40 <oneinsect> works now after configure abuild.conf
2020-06-14 12:58:26 <oneinsect> export CFLAGS="-Os -fomit-frame-pointer -fpic"
2020-06-14 12:58:28 <oneinsect> export LDFLAGS="-Wl,--as-needed -pie"
2020-06-14 12:58:31 <oneinsect> thanks guys
2020-06-14 13:41:32 <oneinsect> darn glibc requires export LDFLAGS="-Wl,--as-needed -fPIE"
2020-06-14 13:41:45 <oneinsect> but with -fPIE abuild doesnt work
2020-06-14 13:41:53 <oneinsect> any ideas why?
2020-06-14 13:42:11 <oneinsect> what could be difference between -pie and -fPIE
2020-06-14 13:44:55 <timlegge> Just looking at 3.12 and a few of the perl packages I maintain are outdated.  Is it as simple as a MR for the 3.12 branch?  Are there any update rules/timeframes that I should know about?
2020-06-14 13:45:34 <maxice8> Yes it is as simple but you stable should have bugfixes only
2020-06-14 13:51:58 <timlegge> Okay, so really if a bug is reported that is impacting someone on 3.12 as opposed to a bugfix upstream that may not impact anyone
2020-06-14 13:52:20 <timlegge> s/impact /impacting /
2020-06-14 13:52:20 <alpine-meetbot> timlegge meant to say: Okay, so really if a bug is reported that is impacting someone on 3.12 as opposed to a bugfix upstream that may not impacting anyone
2020-06-14 13:52:46 <timlegge> not sure I made that clearer :-)
2020-06-14 13:53:25 <ikke> if upstream does a release that only contains bugfixes (ie, for version x.y.z, only z changes), than it should not be an issue to upgrade
2020-06-14 13:54:10 <ikke> but if upstream is combining bugfixes with new features, than it would be an issue
2020-06-14 14:02:02 <timlegge> okay thanks
2020-06-14 14:05:21 <oneinsect> gcc5 changed something in how -fPIE and -fPIC work and ever since, Qt requires -fPIC and not just -fPIE for the executable as well, because -fPIE no longer prevents copy relocations. This is all only relevant if Qt is built with -reduce-relocations, but that has become the default in Qt5.
2020-06-14 14:05:30 <oneinsect> hence
2020-06-14 14:05:45 <oneinsect> export LDFLAGS="-Wl,--as-needed -fpic -pie -fPIE"
2020-06-14 14:06:34 <oneinsect> CMake is lacking that it does not add the flag -pie to the linker step of executable targets hence we are forced to do so abuild.conf
2020-06-14 22:31:22 <Ariadne> oneinsect: copy relocations are bad.  glibc is bad.
2020-06-14 22:31:33 <Ariadne> oh he's gone
2020-06-15 00:10:29 <andypost[m]> Looks mips64 builder hangs
2020-06-15 00:36:05 <Ariadne> no
2020-06-15 00:36:08 <Ariadne> it is just very slow
2020-06-15 00:38:38 <Ariadne> oh, hmm
2020-06-15 00:38:42 <Ariadne> it appears to be down
2020-06-15 04:53:00 <maxice8> Ikke: ping, i have commented on 2 repos that need to be made public
2020-06-15 04:53:40 <ikke> done
2020-06-15 04:53:49 <ikke> I thought I already did it, but ran wrong command :P
2020-06-15 04:54:38 <maxice8> :D i just pinged you a few seconds ago on the second repo
2020-06-15 04:54:42 <maxice8> so you probably did the first one
2020-06-15 04:55:10 <ikke> Well, I see in my history I ran the wrong command anyway :)
2020-06-15 04:59:52 <maxice8> Oh, well :D
2020-06-15 05:00:07 <maxice8> no need to hurry, the package has everything in package() instead of prepare(), build() and package()
2020-06-15 05:00:16 <ikke> heh
2020-06-15 06:32:22 <HRio> need help in merging !9207 (can not merge to main)
2020-06-15 06:41:21 <ikke> HRio: done
2020-06-15 06:42:08 <HRio> thanks
2020-06-15 08:03:06 <ikke> pkgs.a.o will be unavailable for a minute to fix a database issue. Should be back soon.
2020-06-15 08:04:54 <ikke> Ok, it's up again
2020-06-15 14:10:07 <nmeum> PureTryOut[m]: any objections on upgrading snapcast to 0.20.0?
2020-06-15 14:11:43 <PureTryOut[m]> No why would I? 😛 Just notify me in MR
2020-06-15 15:19:03 <PureTryOut[m]> Can someone merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9272? We kinda need it at pmOS 😛
2020-06-15 15:24:55 <PureTryOut[m]> Thanks!
2020-06-15 17:10:12 <PureTryOut[m]> What is this build-newedge-x86 about on build.alpinelinux.org?
2020-06-15 17:10:31 <ikke> PureTryOut[m]: rebuild of edge for 32-bits systems due to time_t change
2020-06-15 17:10:34 <ikke> in musl
2020-06-15 17:10:46 <mps> with musl 1.2.0
2020-06-15 17:11:12 <PureTryOut[m]> Ah ok
2020-06-15 17:11:26 <ikke> Might affect pmos as well
2020-06-15 17:32:43 <mps> how we set conflicts in APKBUILD with particular version? 'depends="!finch<=2.13.0-r2"' or 'depends="!finch<=2.13.0"', i.e. without pkgrel
2020-06-15 17:33:41 <ikke> isn't that just a matter of inverting the logic?
2020-06-15 17:34:12 <ikke> 'depends="finch>2.13.0"'
2020-06-15 17:34:15 <ikke> for example
2020-06-15 17:34:39 <ikke> rather that a conflicts, you transform it into a requires
2020-06-15 17:35:06 <mps> hm, no
2020-06-15 17:35:32 <mps> I'm preparing libgnt and it should depend on finch
2020-06-15 17:35:43 <ikke> hmm, ok
2020-06-15 17:35:46 <mps> but finch depends on it
2020-06-15 17:36:02 <mps> new finch version, I mean
2020-06-15 17:36:06 <afontain_> ikke: do you rebuild everything?
2020-06-15 17:36:21 <mps> old finch 2.13.0 contains libgnt files
2020-06-15 17:36:26 <ikke> afontain_: yes, the ABI is incompattible
2020-06-15 17:37:02 <afontain_> I think we should also rebuild everything
2020-06-15 17:37:41 <afontain_> to be honest, I prefer that to Alpine upgrading as needed and rebuilding only the dependencies each time
2020-06-15 17:38:22 <afontain_> (as if I understood correctly the only ABI problem is about the time_t definition in librairies)
2020-06-15 17:39:40 <Cogitri> Not sure if I understand you correctly, but rebuilding the entire package tree for any ABI break sounds like our builders would never get a chance to idle
2020-06-15 17:43:36 <ikke> rebuilding world takes about 2-3 weeks
2020-06-15 17:44:43 <Cogitri> That's with us fixing build failures because things changed in the 6 months between versions
2020-06-15 17:45:12 <Cogitri> So I guess if we rebuilt for every ABI break it'd be like ~1 week on fast arches (but of course that's still too long to get anything done, especially when there's no reason to do so :)
2020-06-15 19:00:04 <mps> heh, we have twm in repo, didn't know. nice to see it maintained
2020-06-15 19:13:19 <mps> would someone look at testing/libgnt/APKBUILD and review, first time created package with meson. need to move it to community for pidgin/finch upgrade
2020-06-15 19:14:03 <mps> not sure how to enable test with meson/ninja
2020-06-15 19:14:21 <Cogitri> ninja -C builddir test
2020-06-15 19:14:50 <mps> heh, thanks. it looked something like that but I wasn't sure
2020-06-15 19:14:59 <ikke> libgnt fails on x86_64
2020-06-15 19:15:07 <ikke> oh, network issue
2020-06-15 19:15:15 <mps> ikke: sf.net timeout
2020-06-15 19:15:48 <ikke> built now
2020-06-15 19:16:23 <mps> thanks for asking algitbot to retry
2020-06-15 19:35:57 <mps> hmm, is it something else or we should bump pkgrel when move pkgs from testing to community or main
2020-06-15 19:36:28 <ikke> no pkgrel is required
2020-06-15 19:36:38 <Cogitri> No need to, builders will rebuild it either way
2020-06-15 19:36:41 <ikke> just moving is enough to get it rebuilt
2020-06-15 19:37:26 <mps> just moved libgnt but build not started till I instruct algitbot to retry master
2020-06-15 19:38:03 <ikke> mps: there is a race condition between the builders getting the message and the repo they pull from getting the change
2020-06-15 19:38:08 <ikke> it's something we need to adjust
2020-06-15 19:38:21 <mps> ah, ok, undestand
2020-06-15 20:37:01 <andypost[m]> Is there option for builder to add -j N to speedup build?
2020-06-15 20:37:18 <[[sroracle]]> export JOBS=N
2020-06-15 20:37:39 <[[sroracle]]> export MAKEFLAGS=-jN
2020-06-15 20:37:43 <[[sroracle]]> in your abuild.conf
2020-06-15 20:37:51 <andypost[m]> I see good speed up of php build with -j4 locally
2020-06-15 20:38:26 <ikke> yes, running more jobs in parallel helps immensely
2020-06-15 20:38:35 <andypost[m]> But each builder has different ncpu, what is recommended
2020-06-15 20:38:43 <ikke> $(nproc)
2020-06-15 20:38:48 <artok> $(npr
2020-06-15 20:38:49 <ikke> that's what the builders use
2020-06-15 20:38:53 <artok> too slow
2020-06-15 20:39:20 <ikke> andypost[m]: don't override it in your APKBUILD
2020-06-15 20:39:34 <ikke> /etc/abuild.conf you can set your local preference
2020-06-15 20:39:49 <andypost[m]> Yes, that's why I asked)
2020-06-15 20:40:18 <ikke> if you would add -j4 in the APKBUILD, you would only slow down the builders
2020-06-15 20:40:31 <andypost[m]> Why?
2020-06-15 20:40:40 <ikke> they have >32 cores
2020-06-15 20:41:29 <ikke> so you would limit the build to only 4 of them
2020-06-15 20:41:51 <ikke> so setting it locally in /etc/abuild.conf will increase it for you
2020-06-15 20:41:51 <andypost[m]> There's 3 build jobs in build() so maybe parallel them?
2020-06-15 20:42:04 <ikke> that's rarely ever a good idea
2020-06-15 20:42:18 <ikke> log output would be even more confusing
2020-06-15 20:42:58 <ikke> (-jx already causes out-of-order logging)
2020-06-15 20:42:59 <andypost[m]> Yes, that's best point! Thank you
2020-06-15 20:44:00 <andypost[m]> Then better focus on tests clean-up, which are single core
2020-06-15 20:45:50 <andypost[m]> Linking also single thread operation
2020-06-15 20:48:08 <andypost[m]> Is there aports which using extra services like memcache for check()?
2020-06-15 20:48:44 <ikke> I don't think so
2020-06-15 20:48:51 <ikke> would make things quite complicated
2020-06-15 20:49:55 <andypost[m]> I see php spends 30% of build time in skipping tests for dblib(waiting for connection timeout)
2020-06-15 20:50:42 <[[sroracle]]> you can just disable those tests if they're being skipped
2020-06-15 20:50:49 <[[sroracle]]> i think i did something like that for adelie
2020-06-15 20:51:51 <andypost[m]> Yep, thank you - i just updated it for latest version, so could be ported
2020-06-15 20:52:32 <andypost[m]> Used it as hood example but found less issues in locales
2020-06-15 20:54:56 <andypost[m]> Looks excluding this tests speeds it up 40%)
2020-06-15 20:55:33 <andypost[m]> And it gives a chance to test more
2020-06-15 20:55:47 <artok> hah, seems that opencv tests have stuff trying to use non-free algorithms even they are disabled on cmake configure =D
2020-06-15 20:55:59 <artok> ..so they fail
2020-06-15 21:00:12 <andypost[m]> Adelie do more tests... Looks it could help to catch bug with cos() on x86
2020-06-15 21:00:58 <[[sroracle]]> what cos bug?
2020-06-15 21:05:46 <andypost[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/2421#note_93511
2020-06-15 21:06:19 <andypost[m]> Kinda overflow in deg or rad...
2020-06-15 21:09:24 <andypost[m]> Also looking for help with https://gitlab.alpinelinux.org/alpine/aports/-/issues/11645
2020-06-15 21:11:04 <Cogitri> So it's php assume wrong things or musl not holding up to spec?
2020-06-15 21:11:29 <ikke> andypost[m]: you could ask in #musl
2020-06-15 21:12:24 <Cogitri> Yup, asking upstream is best in that case, I doubt anyone will be able to help you out in that downstream issue
2020-06-15 21:20:34 <andypost[m]> Will do because it needs to figure if tests using 0.0025 but gets extra in float
2020-06-15 21:21:40 <andypost[m]> Maybe some serialiser in a middle
2020-06-15 21:21:44 <[[sroracle]]> this is weird because i don't think i ran into this issue
2020-06-15 21:21:57 <[[sroracle]]> may be due to difference in our x86 ISAs though
2020-06-15 21:25:30 <andypost[m]> As there's similar reports in php db drivers looks it's php issue
2020-06-15 21:27:17 <andypost[m]> Some of php internals of math using asm implementation, so needs more time to dig
2020-06-16 03:36:09 <clandmeter> upgrading gitlab
2020-06-16 03:38:21 <maxice8> oh
2020-06-16 03:38:33 <maxice8> please ping when i can touch again i was about to merge a few MRs
2020-06-16 03:39:00 <clandmeter> should be in a min
2020-06-16 03:39:09 <clandmeter> if i dont break anything
2020-06-16 03:40:10 <clandmeter> maxice8: ping
2020-06-16 03:40:30 <maxice8> pong
2020-06-16 05:06:53 <oneinsect> anyone still up?
2020-06-16 05:07:13 <ikke> you know the drill :P
2020-06-16 05:07:17 <oneinsect> lol
2020-06-16 05:07:38 <oneinsect> i have got a list of apks now, is there any info where i could build an iso?
2020-06-16 05:07:57 <oneinsect> and any specific packages that are a must?
2020-06-16 05:08:02 <oneinsect> like openrc?
2020-06-16 05:08:24 <ikke> /scripts in aports is the staring point
2020-06-16 05:08:34 <oneinsect> aaah i knew you would say that
2020-06-16 05:08:37 <oneinsect> :P
2020-06-16 05:09:01 <ikke> alpine-base + dependencies
2020-06-16 05:09:12 <oneinsect> checking alpine-base
2020-06-16 05:10:13 <oneinsect> i have most of them, checking scripts now
2020-06-16 05:11:01 <oneinsect> which of these scripts is for building base iso?
2020-06-16 05:11:24 <oneinsect> mkimg.base.sh
2020-06-16 05:11:25 <oneinsect> ?
2020-06-16 05:11:39 <ikke> mkimage.sh
2020-06-16 05:11:49 <ikke> the rest are profiles
2020-06-16 05:13:33 <ikke> I think minirootfs is a good profile to start with
2020-06-16 05:20:32 <oneinsect> yeaa the mkimg base profile is not bad
2020-06-16 05:20:34 <oneinsect> alpine-base alpine-mirrors busybox kbd-bkeymaps chrony e2fsprogs haveged network-extras openssl openssh tzdata
2020-06-16 05:21:15 <oneinsect> also one other aspect how does mkimage pick up these aps?
2020-06-16 05:21:19 <oneinsect> local repo or online?
2020-06-16 05:23:51 <oneinsect> never mind
2020-06-16 05:24:00 <oneinsect> i can specify the repository
2020-06-16 07:25:42 <mps> looks like sf.net rate limit us, or their network/download mirrors have issue in last days
2020-06-16 08:43:39 <Ariadne> any opinions on renaming the master branch in aports.git to edge?
2020-06-16 08:46:22 <Cogitri> I don't like the breakage that'll introduce
2020-06-16 08:46:35 <mps> I'm accustomed to current naming
2020-06-16 08:47:03 <Cogitri> And I think it actual won't decrease the burden on new contributors but will actually make it more difficult to contribute, since master is just the standard name for the "live" branch
2020-06-16 08:47:14 <Cogitri> s/ual/ually/
2020-06-16 08:47:15 <alpine-meetbot> Cogitri meant to say: And I think it actually won't decrease the burden on new contributors but will actually make it more difficult to contribute, since master is just the standard name for the "live" branch
2020-06-16 08:47:29 <mps> Cogitri: I tend to agree with you
2020-06-16 08:48:40 <maxice8> will operations on master branch be redirect to edge ? I don't want  my scripts to break
2020-06-16 08:58:14 <Ariadne> you can configure a git repo to have a different default branch name
2020-06-16 09:00:56 <maxice8> Is there a way to look that up in a script ?
2020-06-16 09:01:43 <clandmeter> Ariadne: yes i have one :)
2020-06-16 09:01:46 <Ariadne> well git will default to whatever branch the repo is configured to default to
2020-06-16 09:01:58 <clandmeter> i think i prefer to keep it as is.
2020-06-16 09:02:52 <Ariadne> any particular reason why
2020-06-16 09:03:03 <clandmeter> i see no reason to change it
2020-06-16 09:04:09 <Ariadne> I can list a few
2020-06-16 09:04:21 <clandmeter> be my guest
2020-06-16 09:05:35 <Ariadne> 1. gits default of master branch name is poorly chosen to begin with.  git did it because bitkeeper did it.  bitkeeper refers to remote repos as "slave repos"
2020-06-16 09:06:23 <Ariadne> 2. renaming the branch would cause the branch to reflect it's output, e.g. edge branch in git = edge repos
2020-06-16 09:07:32 <Ariadne> 3. with GitHub changing the default branch on their platform, there will be pressure for us to do the same.  better to just do it now.
2020-06-16 09:08:28 <clandmeter> why would 3 be an issue?
2020-06-16 09:08:41 <Ariadne> 4. it is desirable to show solidarity with other FOSS projects making the change away from master at large.
2020-06-16 09:08:45 <clandmeter> who would pressure us?
2020-06-16 09:08:59 <Ariadne> people from the internet
2020-06-16 09:10:30 <mps> most of repos I cloned have 'master' as default
2020-06-16 09:10:44 <Ariadne> yes, right now.
2020-06-16 09:10:55 <Ariadne> with GitHub changing the default, that will change.
2020-06-16 09:11:36 <clandmeter> its becoming a thing of ppl being offended about anything. I wonder where it will stop. (probably never).
2020-06-16 09:12:02 <Ariadne> well it's a stupid default to begin with on technical reasons alone
2020-06-16 09:12:05 <mps> would they use new name (main) for all already existing repos or for new ones
2020-06-16 09:12:28 <Ariadne> presumably for new, but they plan on making it easy for projects to make the change
2020-06-16 09:13:04 <clandmeter> i agree the name could have been better picked
2020-06-16 09:13:32 <clandmeter> but it has been done, and now we need to change just because almighty github is changing.
2020-06-16 09:13:55 <mps> I would prefer if keep it as it is for now and look what will happen in future, then we can discuss about idea again
2020-06-16 09:14:33 <Ariadne> i mean it's not a huge deal either way, but there's reasons why doing it now may be a good idea.  at the very least we should investigate the feasibility
2020-06-16 09:15:15 <Cogitri> I don't see a need to investigate feasibility when devs don't want the change to be honest
2020-06-16 09:16:04 <Cogitri> Also, as for reason 3: We'd change to a different name so I don't see the connection there and for 4: context matters
2020-06-16 09:16:05 <Ariadne> why do devs want or not want it
2020-06-16 09:16:42 <clandmeter> i dont think a dev is interested 1 thing in the name itself, except if you are offended.
2020-06-16 09:16:50 <Ariadne> correct
2020-06-16 09:16:59 <Ariadne> I don't really care.  it was just a thought I had.
2020-06-16 09:17:14 <clandmeter> but from inra point of view i will need to update a lot of repos
2020-06-16 09:17:27 <clandmeter> infra..
2020-06-16 09:18:05 <Ariadne> from "offended" point of view we simply explain that "master" is the branch git chose 14 years ago when aports.git was created
2020-06-16 09:18:16 <Ariadne> and updating it would break tons of things
2020-06-16 09:18:32 <maxice8> hmm, git rev-parse --abbrev-ref --symbolic-full-name '@{u}' seems to give me the correct information for my scripts
2020-06-16 09:18:36 <clandmeter> ive been reading a bit about the change, and seen some opinions.
2020-06-16 09:18:51 <clandmeter> i wanted to address it yesterday already in offtopic
2020-06-16 09:19:23 <clandmeter> but im not sure i wanted to give it too much weight.
2020-06-16 09:19:44 <Ariadne> I think basically making a statement about it is sufficient.  if the burden to infra is significant then it's not feasible
2020-06-16 09:19:47 <Ariadne> simple as that
2020-06-16 09:20:18 <Ariadne> for future repos we follow whatever gitlab does
2020-06-16 09:20:37 <clandmeter> +1
2020-06-16 09:21:01 <Cogitri> Sounds good
2020-06-16 09:21:32 <Ariadne> and perhaps if asked our position on gitlab changing the default we support that
2020-06-16 09:22:38 <Ariadne> as long as the proposal is reasonable and not like some troll shit anywau
2020-06-16 09:32:55 <mps> I enabled ead (Ethernet Authentication daemon) for upgraded iwd 1.8, so anyone who have infrastructure can test it and report if it works
2020-06-16 09:34:55 <ncopa> i actually think that it would be nice if the repository release branch name (edge, v3.x) corresponded to git branch (master, 3.x-stable)
2020-06-16 09:36:32 <ncopa> but i dont think its worth the breakages
2020-06-16 09:38:09 <ncopa> would be good to avoid hardcode 'master' in scripts and code though, like maxice8 is sayin
2020-06-16 09:38:25 <maxice8> Then i have good news (for me)
2020-06-16 09:39:16 <maxice8> https://github.com/maxice8/meltryllis/commit/5ed4e1f0842b983dabb879bab8a3a612f0e8289b
2020-06-16 09:47:01 <ncopa> clandmeter: re containerd and go on s390x, did you try build containerd using go version from alpine 3.11 in a 3.12 environment?
2020-06-16 09:47:18 <ncopa> i dont think GOFLAGS are significant
2020-06-16 09:47:40 <ncopa> but i think it may be a bug in some of the libraries in go
2020-06-16 09:52:25 <clandmeter> ncopa: the golang version in 11 is only a patch release different
2020-06-16 09:52:36 <clandmeter> but i did build it to try
2020-06-16 09:54:29 <ncopa> go 1.13.12 is out
2020-06-16 09:59:14 <ncopa> there is only one commit from go 1.13.10 to 1.13.11 in go
2020-06-16 10:09:19 <ncopa> clandmeter: i have a containerd build I'd like to test. how can we test it?
2020-06-16 10:09:37 <ncopa> its containerd build with go 1.13.10
2020-06-16 10:17:25 <Ariadne> yeah if there's no clean way to do it, there's no clean way
2020-06-16 10:17:36 <Ariadne> maybe someday there will be :)
2020-06-16 11:11:00 <clandmeter> ncopa: we have qemu running on s390x-ci.a.o
2020-06-16 11:11:06 <clandmeter> its running in tmux
2020-06-16 11:11:38 <clandmeter> its running from ram so if you restart it it should be pristine
2020-06-16 11:12:49 <clandmeter> ncopa: you can also spin another one if you like
2020-06-16 11:12:59 <clandmeter> ah you are already on it
2020-06-16 11:13:39 <clandmeter> its qemu you cannot ping :)
2020-06-16 11:13:51 <ncopa> thats what i eanted to confirm :)
2020-06-16 11:14:06 <clandmeter> it has some custom repos defined
2020-06-16 11:14:18 <clandmeter> i have a docker container running to build some stuff
2020-06-16 11:14:26 <clandmeter> and its exported over http
2020-06-16 11:17:00 <ncopa> can you test if containerd works now?
2020-06-16 11:17:26 <clandmeter> nope
2020-06-16 11:17:27 <clandmeter> fails
2020-06-16 11:17:32 <clandmeter> same error
2020-06-16 11:18:51 <clandmeter> what is magic about your containerd?
2020-06-16 11:19:20 <ncopa> i built it with go 1.13.10
2020-06-16 11:19:33 <clandmeter> add --allow-untrusted
2020-06-16 11:19:40 <clandmeter> i did not copy the sigs
2020-06-16 11:19:50 <clandmeter> err keys :)
2020-06-16 11:20:45 <clandmeter> that error is different
2020-06-16 11:21:47 <clandmeter> the kernel is from host directory
2020-06-16 11:23:31 <ncopa> how can i load a clean v3.12 containerd package
2020-06-16 11:25:15 <clandmeter> you cound it :)
2020-06-16 11:27:11 <clandmeter> voila :)
2020-06-16 11:27:20 <clandmeter> its weird
2020-06-16 11:27:38 <ncopa> I think we should report this upstream
2020-06-16 11:27:53 <clandmeter> im not sure what to report
2020-06-16 11:28:08 <ncopa> docker: Error response from daemon: read unix @->@/containerd-shim/bc36da43a580055c291c1f102839f50e1fe1de3326176f4789b8eeaeb2c47f79.sock: read: connection reset by peer: unknown.
2020-06-16 11:28:08 <ncopa> ERRO[0002] error waiting for container: context canceled
2020-06-16 11:28:54 <clandmeter> btw
2020-06-16 11:29:01 <clandmeter> you only updated containerd
2020-06-16 11:29:07 <clandmeter> there are more bins
2020-06-16 11:29:23 <clandmeter>  /usr/bin/containerd-shim-*
2020-06-16 11:34:07 <ncopa> right
2020-06-16 13:13:23 <Ariadne> I keep finding myself adding features to git
2020-06-16 13:13:30 <Ariadne> this is not the timeline I want to be in
2020-06-16 13:21:12 <ikke> what kind of features?
2020-06-16 15:00:09 <meehow> is it describe somewhere when aport can be moved from testing to community aports?
2020-06-16 15:02:29 <Cogitri> I think the only guideline for that is that you made sure it works, the builders like it and that you're OK with maintaining it for 6 months in the next stable release
2020-06-16 15:05:23 <mps> I remember time when it have to be in testing for at least one release cycle
2020-06-16 15:21:44 <maxice8> can abuild consider /usr/lib64 and /lib64 a tainted path ?
2020-06-16 15:22:35 <oneinsect> no should not
2020-06-16 15:22:58 <oneinsect> tough for people like us who are bootstrapping and porting
2020-06-16 15:23:45 <maxice8> Just had to deal with ramifications of having a package silently install pkgconfig files to /usr/lib64/pkgconfig
2020-06-16 15:23:47 <maxice8> breaking a few things
2020-06-16 15:23:54 <maxice8> Not an isolated incident
2020-06-16 15:24:22 <oneinsect> atleast give us an option to disable it if required
2020-06-16 15:24:33 <oneinsect> fedora for example has no /lib or /lib64 but all symbol linked to /usr/lib and /usr/lib64
2020-06-16 15:25:04 <oneinsect> tainting those would mean we will not be able properly port stuff
2020-06-16 15:25:58 <maxice8> Sorry, but what does that even mean ?
2020-06-16 15:26:05 <oneinsect> lol
2020-06-16 15:27:14 <oneinsect> i mean i will get lots of build errors as the almost all distros have lib64 in some form or the other if i use abuild natively
2020-06-16 15:27:50 <maxice8> yeah but Alpine doesn't have lib64
2020-06-16 15:28:01 <oneinsect> but then yes it doesnt matter you much since you are only concerned with alpine but i am putting
2020-06-16 15:28:09 <oneinsect> it as gentle request from my side
2020-06-16 15:28:10 <PureTryOut[m]> Can someone merge !9306? CI is still running on x86 and armv7 but the changes made don't affect the 32-bit architectures
2020-06-16 15:32:17 <Hello71> I mean, if you have such strange needs then surely you can patch abuild?
2020-06-16 15:44:36 <meehow> py-qrcode has been already seasoned in testing for 6 years, do you think it be moved to community?
2020-06-16 15:47:13 <ikke> meehow: if you tested it and it works properly, sure
2020-06-16 15:47:26 <ikke> Make sure it uses python3, though
2020-06-16 15:48:02 <meehow> yes, it was renamed to py3-qrcode some time ago. Thx
2020-06-16 15:49:32 <ikke> Packages don't have to spend a long time in testing. It just needs confirmation that it works properly
2020-06-16 16:51:13 <PureTryOut[m]> Could someone merge !9306? I need it for some cool stuff 😃
2020-06-16 17:18:46 <dalias> oneinsect, lib64 should never exist. i don't know why you want it to
2020-06-16 17:18:59 <dalias> maxice8, i strongly support considering it tainted
2020-06-16 17:20:59 <dalias> oneinsect, if you want to reuse aports with a redhat-style layout with lib64's all over the place you'd have to patch the APKBUILD files anyway to use it. so you can patch it back in at the same time. i don't see why you'd want it to silently ignore the error of putting files in an inconsistent location where they might not be found
2020-06-16 17:24:52 <oneinsect> hello dalias, i though isnt it the job the package being installed to install at correct location with a prefix being set in APKBUILD
2020-06-16 17:27:20 <oneinsect> i mean they dont end up in lib64, the challenge is when we are the very very initial bootstrap, because we have to reuse the host which has glibc, forcing abuild to ignore or taint lib64 doesnt let it compile in the first
2020-06-16 17:27:32 <oneinsect> this is a problem only for the first very very initial basic set of packages
2020-06-16 17:28:01 <oneinsect> after that the chroot of that basic packages takes care of putting in lib correctly
2020-06-16 17:30:48 <dalias> i don't follow and it sounds like you are doing something horribly wrong
2020-06-16 17:30:59 <dalias> you do not bootstrap a distro from an existing glibc-based host
2020-06-16 17:31:10 <dalias> you cross-compile the minimal dependency set then bootstrap natively
2020-06-16 17:31:43 <dalias> and even if you did reuse some existing host, you would not install things in its lib64 dirs
2020-06-16 17:31:46 <oneinsect> i cant bootstrap from alpine since musl leaks into glibc, cross-compile creates issues with the spec files in GCC
2020-06-16 17:32:16 <oneinsect> i resue existing host only to compile abuild and create some apks to build a base
2020-06-16 17:32:47 <dalias> if you're trying to make a glibc-based distro using aports (why?!) you absolutely can cross-compile the necessary base to bootstrap it
2020-06-16 17:32:58 <oneinsect> assuming now abuild taints lib64, i cannot use an existing host
2020-06-16 17:33:03 <dalias> sure you can
2020-06-16 17:33:05 <oneinsect> well there are lots of issues
2020-06-16 17:33:10 <oneinsect> i faced
2020-06-16 17:33:25 <oneinsect> especially crosstools-ng etc
2020-06-16 17:33:26 <dalias> yes because you're doing all sorts of things wrong and not taking the time to figure out why they're wrong and fix them
2020-06-16 17:33:28 <oneinsect> with*
2020-06-16 17:33:40 <dalias> but instead doing random hacks until something seems to work
2020-06-16 17:34:08 <maxice8> speaking of which i made https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/51
2020-06-16 17:34:12 <maxice8> but I have an idea
2020-06-16 17:34:51 <maxice8> apparently postcheck() will return at the first error, that can be annoying when the packaging has gone more than minimally bad and you have to rebuild just to get another postcheck err
2020-06-16 17:35:34 <oneinsect> well i face issues like this
2020-06-16 17:35:34 <oneinsect> https://answers.ros.org/question/55150/ld-searches-in-wrong-folder-for-libraries-when-cross-compiling/
2020-06-16 17:35:36 <dalias> uhg gitlab. how many clicks does it take to get from the MR to the actual commits??
2020-06-16 17:35:46 <maxice8> 1
2020-06-16 17:36:02 <maxice8> besides overview there is a list of commits
2020-06-16 17:36:19 <mps> maxice8: heh, +1
2020-06-16 17:36:27 <dalias> oneinsect, whoever asked that has no idea what they're doing
2020-06-16 17:36:47 <dalias> when *cross* compiling you don't use any LD_* env vars (settings for dynamic linker) because *nothing ever gets run for the target*
2020-06-16 17:36:57 <dalias> you can't run binaries for the target because they're foreign binaries
2020-06-16 17:37:31 <oneinsect> i know what you are telling, but i think i havent told the problems clearly
2020-06-16 17:37:43 <dalias> if you have a working cross toolchain its ld will not look anywhere outside its sysroot
2020-06-16 17:38:00 <oneinsect> exactly
2020-06-16 17:38:26 <oneinsect> that creates issues
2020-06-16 17:38:48 <oneinsect> as there is noo mechanism to disable/chain sysroot for the original toolchain
2020-06-16 17:39:03 <dalias> why would you want to do that??
2020-06-16 17:39:40 <oneinsect> because for example ld -lcursesw --verbose doesnt find it in the correct location
2020-06-16 17:40:15 <oneinsect> certain packages fail
2020-06-16 17:41:15 <oneinsect> i know dalias: you want to spend quality time to properly fix at step and move forward
2020-06-16 17:41:36 <oneinsect> but use an existing host is much easier for single person work like mine
2020-06-16 17:41:40 <oneinsect> atleast initially
2020-06-16 17:41:47 <oneinsect> using*
2020-06-16 17:42:00 <oneinsect> at each* step
2020-06-16 17:42:33 <oneinsect> you guys here are like an Army!
2020-06-16 17:42:47 <oneinsect> i am foot solider with little time now and then
2020-06-16 17:42:52 <oneinsect> a*
2020-06-16 17:44:10 <dalias> oneinsect, if your problem is that some programs' build systems are buggy and fail with cross-compiling, that's an ages-old issue. the easy fix is don't cross compile them. just cross compile the minimal system needed to bootstrap (note: this does not include curses) then build everything else natively once you have it
2020-06-16 17:44:55 <oneinsect> hmmmm
2020-06-16 17:44:58 <dalias> the kind of frankenstein system you're trying to do naively *seems easy* at first but it's not. all sorts of stuff breaks.
2020-06-16 17:45:16 <dalias> because it's hard to control and keep track of crap that tries to use mismatched libs/headers/pkg-conf/etc. from the host
2020-06-16 17:46:25 <oneinsect> yeaa i have been tracking each package for those during each compile and its taking ages not to mention the correct patches to include or exclude
2020-06-16 17:46:43 <oneinsect> even with the minimal system built
2020-06-16 17:46:58 <oneinsect> never mind
2020-06-16 17:47:14 <oneinsect> the MR just spits out an error
2020-06-16 17:47:20 <oneinsect> should be fine for me
2020-06-16 17:47:23 <oneinsect> infact will help me
2020-06-16 17:48:54 <oneinsect> i do have weirdly symbol stuff to prevent mismatch between lib64 and lib, oh god you do not want to know
2020-06-16 17:48:58 <oneinsect> have to*
2020-06-16 18:24:10 <Hello71> dalias: wellll... nix does this, but... y'know
2020-06-16 18:48:22 <artok> was CI builders https://gitlab.alpinelinux.org/alpine/infra/docker/aports-build one?
2020-06-16 18:49:09 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci
2020-06-16 18:49:13 <artok> thanks
2020-06-16 18:50:21 <artok> some weird stuff going on, segfaults on tests on CI but on my alpine edge based build container passes
2020-06-17 01:57:24 <Jiggy> SpaceToast: Wasn't sure where to reach out other than the mailing list; are you the maintainer of the Caddy package? If so, I was wondering if you planned on upgrading to Caddy 2.x within Alpine 3.12.x or later
2020-06-17 02:17:04 <kaey> Jiggy: !8122
2020-06-17 02:23:19 <Jiggy> kaey: Thank you! I'm not very familiar with te ports system yet, or caddy dependencies; is go 1.14 required for compiling or running?
2020-06-17 02:26:45 <kaey> alpine has 1.14 in edge. i'm not sure what this MR is blocked on
2020-06-17 02:28:01 <Jiggy> Ahh I see that! Got it, thank you. I'll keep my eyes on that and announcements
2020-06-17 06:59:59 <Ariadne> i think that the caddy telemetry feature introduced in 2.0 should be turned off by default in alpine
2020-06-17 07:05:51 <mps> Ariadne: sure
2020-06-17 07:05:59 <mps> any telemetry
2020-06-17 08:47:56 <Cogitri> Ariadne: Could you take a look at !9306 ?
2020-06-17 08:48:46 <Ariadne> seems ok
2020-06-17 08:48:48 <Ariadne> i merged it
2020-06-17 08:49:15 <PureTryOut[m]> Ariadne: thanks for the merge!
2020-06-17 08:49:21 <Cogitri> That wad quick, thanks :)
2020-06-17 08:49:29 <Ariadne> i looked at it earlier
2020-06-17 08:49:44 <Ariadne> but got distracted with other tasks
2020-06-17 08:50:14 <Ariadne> mps: i think it may be good to formalize this policy of disabling telemetry features
2020-06-17 08:51:02 <Ariadne> generally speaking, we do not wish software packages in alpine "phone home"
2020-06-17 08:51:16 <Ariadne> or at least this has historically been the opinion of the alpine developers
2020-06-17 08:52:18 <mps> Ariadne: I fully agree
2020-06-17 09:09:44 <MathiasHMK> mps you mentioned that the SocketCAN kernel modules maybe already are in edge, where? I've checked http://dl-cdn.alpinelinux.org/alpine/edge/main/ both armv7 and x86_64 and nothing. Am I looking in the right place? :)
2020-06-17 09:10:10 <MathiasHMK> *and found nothing
2020-06-17 09:13:53 <Ariadne> they are part of linux-lts
2020-06-17 09:14:49 <MathiasHMK> Hm, ok. How do you figure that out Ariadne?
2020-06-17 09:17:31 <clandmeter> MathiasHMK: i think its in the linux-edge kernel in testing repo
2020-06-17 09:18:03 <clandmeter> https://pkgs.alpinelinux.org/package/edge/testing/x86_64/linux-edge
2020-06-17 09:18:18 <clandmeter> check the commit in that page
2020-06-17 09:18:41 <MathiasHMK> Right, because it's on edge.
2020-06-17 09:19:29 <MathiasHMK> And it even has a content list. You guys are wonderful :)
2020-06-17 09:24:52 <mps> MathiasHMK: you can install linux-edge package and can-utils, but have to enable testing repo in /etc/apk/repositories
2020-06-17 09:31:22 <MathiasHMK> mps Yup, just got an error. I need to mess a bit around with our build system. You'll get a ping once the image is up and running - or if I get completely lost ;)
2020-06-17 09:36:52 <ncopa> MathiasHMK: I have a git branch for enabling CAN in linux-lts as well, I'm just waiting for an issue id i can reference to in commit message
2020-06-17 09:38:06 <SpaceToast> Jiggy: caddy 2 has an entirely different interface, so it should be handled via a separate package, imo; I've been using it just via a static binary and a handwritten service file since the beta
2020-06-17 09:39:01 <SpaceToast> the main issue is there seem to be people that care a lot about specific details of the service files (i.e using pidfiles and co for the sake of making openrc handle the logging in its entirety), and I don't really have the time/energy to argue with those people about the right thing to do in that regard
2020-06-17 09:49:19 <MathiasHMK> ncopa I have not forgotten about you. In fact, I'm working on creating the issue right now. I Just want to cover my ground and make sure I'm not asking for anything you already have. :-)
2020-06-17 09:52:19 <mps> MathiasHMK: just thinking, is it possible to connect two computer boards over canbus
2020-06-17 09:54:03 <MathiasHMK> @mps I guess. Can't think of any reasons why that would not work. You could even do it on a single pc if you have, say, two CAN to USB converters.
2020-06-17 09:55:00 <mps> I have to arm32 boards right now with can on their pins
2020-06-17 09:55:15 <mps> don't have any of usb devices
2020-06-17 09:55:45 <MathiasHMK> Should work imo.
2020-06-17 09:56:11 <MathiasHMK> Just remember to wire them correctly :P
2020-06-17 09:56:22 <mps> good idea, will look details. maybe I could get them connected
2020-06-17 09:56:42 <mps> yes, ofc. don't like smoke tests
2020-06-17 10:09:45 <PureTryOut[m]> Ariadne: you might want to merge !9340 🙈
2020-06-17 10:10:42 <ikke> ncopa: We might want to switch the remotes on all builders from git.a.o to gitlab.a.o. Now we are getting race conditions
2020-06-17 10:11:24 <PureTryOut[m]> Thanks!
2020-06-17 10:13:13 <ncopa> ikke: ok
2020-06-17 11:22:50 <artok> Ariadne: telemetry was on caddy v1, v2 still haves that?
2020-06-17 11:26:04 <ollieparanoid[m]> hey, all!
2020-06-17 11:26:37 <ollieparanoid[m]> I'm a bit confused about build.a.o. Is it building testing/gcc-cross-embedded 9.2.0-r2 for build-edge-aarch64 now, or not? it says that in the table, but there is no related log file
2020-06-17 11:26:54 <PureTryOut[m]> Yeah I was wondering what happened there as well. It seems to have been stuck for a while
2020-06-17 11:27:33 <ikke> buildlogs for all arches except x86_* are uploaded once the build is ready
2020-06-17 11:28:38 <ollieparanoid[m]> ikke: that explains it, thanks
2020-06-17 11:33:44 <mps> MathiasHMK: this guide will help me I hope http://lnxpps.de/bpi/
2020-06-17 11:34:09 <mps> though it is in German but I think I will understand enough
2020-06-17 11:48:53 <MathiasHMK> mps looks like fun :D
2020-06-17 11:49:40 <MathiasHMK> ncopa I've created an issue for adding CAN bus support. Let me know if you need anything :)   https://gitlab.alpinelinux.org/alpine/aports/-/issues/11661
2020-06-17 11:50:46 <mps> yes, i checked my banana pi have CAN interface, just installed can-utils and now is time for reading how to setup all this
2020-06-17 12:43:37 <Hello71> artok: pretty sure it was removed from v1 long time ago
2020-06-17 12:55:52 <artok> Hello71: latest 1.0.5 has it still, disabled on binary builds, but defaults on when building from source
2020-06-17 12:55:59 <artok> checked
2020-06-17 12:56:43 <Hello71> isn't it the other way around?
2020-06-17 12:58:13 <artok> tail caddy/caddymain/run.go  -> https://termbin.com/ei64
2020-06-17 13:00:08 <Hello71> oh, I was looking at v2 -.-
2020-06-17 13:00:21 <artok> "Telemetry is enabled by default in the source code and disabled by default on our download page. " https://caddyserver.com/v1/docs/telemetry =)
2020-06-17 13:00:55 <artok> but yeah, even grepping telemetry on v2 sources gives nothing
2020-06-17 15:52:41 <afontain_> Hi, I believe https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9241 is ready for merging, maybe someone want to have a look?
2020-06-17 15:56:11 <ikke> afontain_: will be merged
2020-06-17 15:56:20 <ikke> if someone does not preempts it
2020-06-17 15:57:07 <ikke> afontain_: in the MR message you mention a glm dependency, but I don't see it being added
2020-06-17 15:58:45 <afontain_> it's a header-only dependency
2020-06-17 15:59:09 <ikke> ok
2020-06-17 15:59:19 <ikke> Just wanted to make sure
2020-06-17 15:59:33 <ikke> It's merged
2020-06-17 16:00:03 <afontain_> thanks :)
2020-06-17 17:21:18 <mps> is the adding '$pkgname-dbg' to subpackages enough to build debug version of pkg
2020-06-17 17:21:52 <mps> looks like it is
2020-06-17 17:29:38 <ikke> Yes
2020-06-17 17:30:12 <mps> hmm, '(gdb) list' => 1       crt/Scrt1.c: No such file or directory.
2020-06-17 17:30:30 <mps> why this happens
2020-06-17 17:32:02 <ikke> You stil need to have the source somewhere
2020-06-17 17:32:57 <mps> 'ile /usr/sbin/rngd' => usr/sbin/rngd: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, with debug_info, not stripped
2020-06-17 17:33:36 <mps> usually this enough for all previous programs which I tested with gdb on alpine (musl)
2020-06-17 17:34:13 <Hello71> did you install crt/Scrt1.c
2020-06-17 17:35:14 <mps> Hello71: no. how to install it?
2020-06-17 17:37:43 <mps> looks like only zig pkg have it 'usr/lib/zig/libc/musl/crt/crt1.c'
2020-06-17 17:38:33 <Cogitri> Well, it's in musl's source so you'd have to unpack the tarball
2020-06-17 17:43:06 <mps> huh, had to run gdb in musl source dir, learned something new. thanks
2020-06-17 17:43:46 <ikke> I think you can also specify a path
2020-06-17 17:44:29 <mps> probably, but didn't searched
2020-06-17 17:44:49 <ikke> https://sourceware.org/gdb/current/onlinedocs/gdb/Source-Path.html
2020-06-17 17:45:43 <ikke> set directories
2020-06-17 17:48:00 <mps> yes, I see, thanks
2020-06-17 18:29:22 <Hello71> why is nomodeset set on iso anyways? seems like lots of people come to #alpine-linux with broken xorg
2020-06-17 18:31:18 <ikke> Mostly because some hardware works very poorly with modesetting, so you don't even get a chance to disable it
2020-06-17 18:32:06 <Hello71> does any other distro set it, even for install media?
2020-06-17 18:32:55 <Hello71> it particularly hurts because setup-disk copies it to update-extlinux.conf, so graphics is mysteriously broken by default
2020-06-17 18:33:14 <ikke> Yes, I have been bitten by that as well
2020-06-17 18:58:10 <Cogitri> I guess we should just add a safe graphics boot entry then
2020-06-17 19:49:37 <artok> goddamn irssi/st is crashing now
2020-06-17 19:50:37 <mps> not here
2020-06-17 19:50:52 <Cogitri> Pango upgrade maybe? Seems like it crashes some things :/
2020-06-17 19:51:59 <artok> just running upgrade from 1.45.2-r0 -> r1
2020-06-17 19:52:30 <Cogitri> That only adds a dbg package
2020-06-17 19:52:42 <Cogitri> Try running it in Valgrind
2020-06-17 20:18:59 <artok> after reboot
2020-06-18 07:27:26 <mps> \o
2020-06-18 07:27:58 <ikke> o.
2020-06-18 07:28:01 <ikke> o/
2020-06-18 07:28:19 <mps> managed to build crystal 0.35.0 on aarch64 last night. with help from crystal developer (jhass)
2020-06-18 07:29:07 <mps> so I hope we will have it again in repo
2020-06-18 07:29:20 <ikke> nice
2020-06-18 07:29:20 <Cogitri> 👍
2020-06-18 07:29:54 <mps> thanks for encouragement :)
2020-06-18 08:49:57 <ncopa> mps: awesome!
2020-06-18 08:58:27 <mps> ncopa: also thank you for encouragement :)
2020-06-18 08:59:38 <mps> it was not so hard when I talked with upstream devs, take their advices and contemplate some time. at the trial and error, ofc
2020-06-18 09:00:21 <mps> at the end*
2020-06-18 09:01:58 <mps> working on alpine as packager and bug 'fixer' I learned how it is important to work with upstream devs
2020-06-18 09:02:30 <mps> very good to have this skill
2020-06-18 10:08:59 <ncopa> totally agree
2020-06-18 10:27:09 <PureTryOut[m]> Are the CI runners broken?
2020-06-18 10:27:59 <ikke> hmm
2020-06-18 10:28:03 <ikke> I see what you mean
2020-06-18 10:38:21 <mps> ncopa: did you build latest perl upgade with BIG_TIME?
2020-06-18 10:38:31 <ikke> I saw that being reverted again
2020-06-18 10:39:52 <mps> hmm, I build week ago on aarch64 and don't see any issue, though I'm not sure should we use it
2020-06-18 10:40:30 <mps> looks like we should but some more testing is needed, I think
2020-06-18 10:44:02 <ikke> f0d993256e1127cb95bd15b9c3da67fcfa39cff2
2020-06-18 10:44:52 <mps> ikke: aha, thanks
2020-06-18 11:27:25 <ncopa> we need a testcase to test if perl is y2038 compatible or not
2020-06-18 14:53:24 <ncopa> i think we should use https apk repos by default for dl-cdn
2020-06-18 14:54:16 <wsinatra> +1 for https for what it's worth
2020-06-18 14:58:59 <ikke> means we need to use the fastly domain
2020-06-18 14:59:51 <ikke> https://alpine.global.ssl.fastly.net/
2020-06-18 15:00:17 <ikke> which also means we lose the flexibility to switch
2020-06-18 15:01:54 <ncopa> you mean, redirect via DNS
2020-06-18 15:02:57 <ikke> It's a cname, so we can switch the cname over
2020-06-18 15:03:30 <ncopa> for now i think its mainly for docker images
2020-06-18 15:04:10 <yunfan> ncopa: how about add p2p download support?
2020-06-18 15:04:40 <ncopa> https://github.com/gliderlabs/docker-alpine/issues/386
2020-06-18 15:05:10 <ncopa> p2p would be cool
2020-06-18 15:06:53 <ncopa> this is what I was thinking: https://tpaste.us/4ExO
2020-06-18 15:06:53 <yunfan> guess it could be done by a aria2 based daemon
2020-06-18 15:07:39 <ncopa> would not affect the docker images by default
2020-06-18 15:07:47 <ncopa> s/not/only/
2020-06-18 15:07:47 <alpine-meetbot> ncopa meant to say: would only affect the docker images by default
2020-06-18 15:17:04 <Hello71> in case anyone wants to add 2c: I filed https://gitlab.alpinelinux.org/alpine/aports/-/issues/11665 for removing nomodeset by default
2020-06-18 15:17:28 <Hello71> imo the main issue is that it is carried over to sys install
2020-06-18 15:17:54 <Hello71> not sure how to fix that though. might be more confusing for users if iso works but then sys install doesn't boot
2020-06-18 15:18:12 <Hello71> but I also don't want to add some magic gpu whitelist or something
2020-06-18 15:19:09 <Cogitri> I think nomodeset is something which you want very rarely
2020-06-18 15:19:39 <Cogitri> Basically only when things are broken (e.g. if you use Nvidia)
2020-06-18 18:10:48 <dne> ncopa: can't Fastly sponsor TLS/SNI for dl-cdn.alpinelinux.org?
2020-06-19 03:17:05 <Ariadne> nomodeset is desirable with IPMIs
2020-06-19 07:27:54 <fabled> ncopa, do you think we could enable CONFIG_FTRACE_SYSCALLS=y for at least x86_64 kernel? possibly all the big machines. it's useful for performance analysis
2020-06-19 08:03:41 <mps> fabled: this was big dilemma for me, when preparing first versions of linux-lts and later with linux-edge
2020-06-19 08:05:08 <fabled> i created https://gitlab.alpinelinux.org/alpine/aports/-/issues/11668
2020-06-19 08:05:19 <mps> on the one hand to have much possible debug, performance analysis etc and on the other hand to have small and fast kernel
2020-06-19 08:05:33 <fabled> seems linux-edge does not have CONFIG_FTRACE at all
2020-06-19 08:06:54 <mps> yes, that was intention to test how big and fast it will be, and even how it will accepted by our users without all these 'extra' features
2020-06-19 08:07:15 <fabled> i believe the performance impact when not active is pretty minimal
2020-06-19 08:07:20 <fabled> it does add to size though
2020-06-19 08:11:17 <mps> my minds are split about this and I don't have final opinion
2020-06-19 08:12:41 <fabled> i'll test build and see what the size impact is
2020-06-19 08:12:57 <fabled> i think not huge, since FTRACE is already on for linux-lts
2020-06-19 08:13:12 <mps> i think so
2020-06-19 08:13:49 <mps> don't except much size increase, probably few KB
2020-06-19 08:16:50 <fabled> seems so, there's some memory usage more, and a bit of code. but overall looks not too huge overhead
2020-06-19 08:18:53 <mps> please don't forget to share your results in issue you created, or here, whatever you find easier for you
2020-06-19 08:29:12 <ncopa> fabled: on all 64bit kernels?
2020-06-19 08:29:32 <fabled> i think so
2020-06-19 08:29:41 <fabled> perhaps even 32-bits. the impact is small
2020-06-19 08:30:04 <ncopa> virt kernels as well?
2020-06-19 08:30:31 <fabled> yes please
2020-06-19 08:31:04 <fabled> i'm doing test build currently
2020-06-19 08:32:44 <ncopa>   Perform a startup test on ftrace (FTRACE_STARTUP_TEST) [N/y/?] (NEW)
2020-06-19 08:33:17 <ncopa> i guess 'no
2020-06-19 08:35:39 <fabled> no
2020-06-19 08:35:45 <fabled> i mean correct. not wanted
2020-06-19 08:36:37 <fabled> if you are doing new kernels, i saw some other config requests in gitlab
2020-06-19 08:41:01 <ncopa> some serial driver and CAN drivers, i think i did those yesterday
2020-06-19 08:43:38 <fabled> there's also https://gitlab.alpinelinux.org/alpine/aports/-/issues/11588
2020-06-19 08:46:29 <fabled> mps, kernel image size (vmlinuz) +32kB
2020-06-19 08:48:59 <mps> fabled: thanks for info
2020-06-19 08:49:17 <mps> not much as we expected
2020-06-19 09:29:52 <PureTryOut[m]> Cogitri: any chance you could merge !9167? It would shorten my repology out-of-date list a whole lot lol
2020-06-19 09:33:17 <Cogitri> Ah yes, was waiting for CI to give it another go and then forgot about it
2020-06-19 09:54:04 <PureTryOut[m]> CI succeeded on everything but gwenview which had outdated checksums which I just now updated
2020-06-19 09:54:05 <PureTryOut[m]> So should be good to go 🤷‍♂️
2020-06-19 09:55:53 <PureTryOut[m]> I should probably make the same MR to 3.12 actually
2020-06-19 10:02:21 <mps> PureTryOut[m]: I stopped to care about this, but still think we should backport only sec and bug fixes
2020-06-19 10:02:57 <PureTryOut[m]> Point releases here are bug fixes
2020-06-19 10:03:08 <PureTryOut[m]> 20.04 to 20.08 would be a feature release
2020-06-19 10:06:37 <Ariadne> yes, CONFIG_FTRACE_SYSCALLS=y would be great
2020-06-19 12:34:02 <Hello71> iirc on x86(_64) ftrace is implemented with self-modifying code, so runtime impact is negligible?
2020-06-19 12:34:49 <Cogitri> Ariadne: Sorry to ping you about smth that I indirectly broke by merging the openexr upgrade, but could you maybe look into why it's failing on mips? I don't really have means to test it at all so I can't really work on it
2020-06-19 12:35:19 <Cogitri> And having openexr disabled means that we'll have to disable lots of other stuff because they need Gstreamer or kde
2020-06-19 12:35:34 <Ariadne> yeah I can look into it
2020-06-19 12:36:21 <Cogitri> Thanks
2020-06-19 12:37:03 <artok> opencv guys blamed gstreamer for problems on tests
2020-06-19 12:37:35 <artok> "opencv guys" this time is irc channel, not officially anyone of the project
2020-06-19 12:40:56 <Cogitri> Well, it's certainly not impossible that something is wrong in our GStreamer setup (although that does seem to work fine for me with the things that use it)
2020-06-19 12:41:00 <Cogitri> What exactly did they say?
2020-06-19 12:42:32 <artok> just that it is gstreamer fault, can't remember anymore =)
2020-06-19 12:51:21 <artok> there is something with their testsuite that doesn't work as it should, their CMake is awfully written, mainly those macros that I need to learn what they do
2020-06-19 12:53:17 <Cogitri> Ah yes, CMake is great fun
2020-06-19 12:55:00 <artok> it is fun, but when everyone extends it with their own macros so that basic cmake knowledge doesn't help at all without learning their OCV_ macros
2020-06-19 12:55:27 <artok> they even have added their own wrapper to option() stuff =(
2020-06-19 13:12:31 <artok> midsummer stuff going on.. I think I also go to somewhere seaside and start drinking
2020-06-19 17:23:28 <jsm> Hi there! I forked lvm2 package by @ncopa and trying to make -libs-static out of it (I'm expecting libdevmapper.a). I got (package specific) --enable-static_link set for configure, so there is usr/lib/libdevmapper.a. I don't get that indirection with subpackages. I was trying `device-mapper-libs:dm_libs_static` and own dm_libs_static() {...} AND device-mapper-libs-static. Please give me some hints.
2020-06-19 17:24:35 <Cogitri> I'm a bit confused as to what's you want to know
2020-06-19 17:30:48 <jsm> @Cogitri, APKBUILD has some implcit rules for creating static libraries. I don't understand that. My abuild is saying: >>> WARNING: lvm2-dev: Found static archive on usr/lib/libdevmapper.a but name doesn't end with -static.
2020-06-19 17:31:28 <Cogitri> Well, it wants you do add a $pkgname-static subpackage (in which case it'd automatically add all static libraries to that package via default_static)
2020-06-19 17:31:29 <ikke> jsm: it basically wants you to specify a $pkgname-static subpackage
2020-06-19 17:31:51 <PureTryOut[m]> Just add lvm2-static subpackage?
2020-06-19 17:32:06 <ikke> yes, you just missed us telling that :P
2020-06-19 18:30:55 <maxice8> can we get some attention to the MRs in alpine/abuild ?
2020-06-19 18:31:03 <maxice8> It is starting to pile up lots of small fixes
2020-06-19 18:35:24 <clandmeter> w00t
2020-06-19 18:35:39 <clandmeter> dl-cdn.a.o now has https support
2020-06-19 18:38:13 <oneinsect> maxice8:
2020-06-19 18:38:18 <oneinsect> are you leo?
2020-06-19 18:38:20 <maxice8> ?
2020-06-19 18:38:23 <maxice8> yes i am Leo
2020-06-19 18:38:54 <oneinsect> thanks for merging that small alpine-baselayout mr fast, it helped
2020-06-19 18:49:33 <maxice8> welcome
2020-06-19 18:55:39 <artok> valgrind shows memoryleaks on st when running irssi inside it
2020-06-19 18:56:01 <artok> https://termbin.com/92tf
2020-06-19 18:56:37 <artok> libfontconfig on every time
2020-06-19 18:57:06 <Cogitri> Well, that's something you should report to upstream, not us
2020-06-19 18:57:39 <artok> just saying, reporting would be from gitlab anyway =)
2020-06-19 19:14:24 <afontain_> 
ACTION note that Leo is maxice8

2020-06-19 19:15:13 <clandmeter> sometimes he also goes undercover
2020-06-19 19:19:07 <jsm> I pull-requested my libdevmapper patch: https://gitlab.alpinelinux.org/jacekmigacz/aports/-/commit/cedf7b58a1df2bc7cdfe6f7ded4e1809da87dd5f I'm almost happy about it. I don't like that "-dev".
2020-06-19 21:21:55 <mps> amrv7 CI is stuck?
2020-06-20 13:03:24 <oneinsect> anyone still here
2020-06-20 13:04:06 <afontain_> of course
2020-06-20 13:06:44 <oneinsect> the subpackage $pkgname-dev" packages up the symbol links of the lib folder but leaves the actual files in package within the main package
2020-06-20 13:06:50 <oneinsect> any idea how to solve this?
2020-06-20 13:07:28 <oneinsect> say make pkgname-dev to install compulsorily when installing main package? something on those lines?
2020-06-20 13:07:41 <oneinsect> adding depends is enough?
2020-06-20 13:08:09 <maxice8> Can't process, can you provide an example ?
2020-06-20 13:09:23 <oneinsect> https://justpaste.it/3f1jy
2020-06-20 13:10:44 <oneinsect> the libxcrypt-dev subpackage ends up with a broken symbol link file libcrypto.so while the main files remain in libxcrypt package
2020-06-20 13:11:12 <maxice8> that is correct
2020-06-20 13:11:19 <maxice8> the -dev package automatically depends on the mainpkg
2020-06-20 13:11:31 <oneinsect> how do i make sure libxcrypt-dev installs by default when installing the main libxcrypt package
2020-06-20 13:11:48 <oneinsect> coz i will require that libcrytpo.so file
2020-06-20 13:11:57 <maxice8> idk why you would do that, -dev packages are only for developing
2020-06-20 13:12:02 <maxice8> if you are develping you install -dev packages
2020-06-20 13:12:06 <oneinsect> alright
2020-06-20 13:12:54 <oneinsect> understood
2020-06-20 13:13:13 <maxice8> the -dev packages will install the main package itself
2020-06-20 13:13:22 <oneinsect> aha
2020-06-20 13:13:25 <oneinsect> nice!
2020-06-20 13:13:28 <oneinsect> that should do
2020-06-20 13:13:34 <ikke> But the main package does not need the -dev pacakge
2020-06-20 13:13:54 <oneinsect> thanks leo so i will just add the -dev package as dependencies for some packages that require it
2020-06-20 13:14:05 <ikke> libcrypto.so is a symlink to the actual .so file
2020-06-20 13:14:13 <maxice8> -dev will almost always go in makedepends=
2020-06-20 13:14:22 <oneinsect> yes
2020-06-20 13:14:23 <ikke> libcrypto.so.1.1
2020-06-20 13:14:26 <maxice8> abuild will automatically scan ELF binaries and find the libraries needed so you don't need to put it in depends=
2020-06-20 13:14:35 <oneinsect> understood
2020-06-20 13:14:43 <oneinsect> thank you friends
2020-06-20 13:14:46 <oneinsect> :)
2020-06-20 13:15:50 <oneinsect> one other question for compatible library of libxcrypt do I need to make libxcrypt-compat seperately
2020-06-20 13:15:59 <oneinsect> is there a way a single package can build both?
2020-06-20 13:16:22 <oneinsect> both have some different configure options
2020-06-20 13:17:10 <ikke> but same source?
2020-06-20 13:17:47 <oneinsect> yes same source
2020-06-20 13:18:16 <oneinsect> one builds newer so.2 and another builds older compat so.1
2020-06-20 13:18:32 <oneinsect> one config*
2020-06-20 13:21:31 <ikke> zabbix for example builds multiple versions
2020-06-20 13:21:38 <ikke> from the same source
2020-06-20 13:22:27 <ikke> It makes a copy of the builddir
2020-06-20 13:22:36 <ikke> and each builddir is configured with different options
2020-06-20 13:24:56 <oneinsect> aha
2020-06-20 13:24:59 <oneinsect> i will check it out
2020-06-20 13:25:06 <oneinsect> thanks "lord" ikke
2020-06-20 13:25:17 <maxice8> lol
2020-06-20 14:17:51 <fabled> remember when I complained about random xfce4-terminal hangs, timeouts, and delays exiting... it got fixed by https://gitlab.alpinelinux.org/alpine/aports/-/commit/55eafd3cc3d145961677c71e8a246e61490c3114
2020-06-20 14:18:23 <Cogitri> Oof
2020-06-20 14:18:29 <Cogitri> But nice that it's fixed
2020-06-20 14:19:00 <Cogitri> What's weird is that I didn't notice anything wrong on GNOME
2020-06-20 14:19:40 <fabled> probably some helper library that often spawned a thread that exited and returned process to single threaded state
2020-06-20 14:20:17 <fabled> Ariadne, picked one of the four patches, but seems it was not enough. maybe it's the first of the four patches that was also needed...
2020-06-20 14:21:03 <Ariadne> fabled: I picked the one dalias said to pick
2020-06-20 14:21:16 <Ariadne> so dunno
2020-06-20 14:23:10 <fabled> yeah, that looked like the most important one. but somereason it alone did not fix the issue
2020-06-20 14:25:39 <Ariadne> well glad we got a fix :)
2020-06-20 14:26:44 <fabled> yeah. i saw Rich's mail when it came, but was busy. and sadly forgot. was meaning to apply the whole thing asap.
2020-06-20 14:26:58 <fabled> it also fixed random xfce4 login failures
2020-06-20 14:27:30 <fabled> i wonder if it's a regression, or something that got exposed in recent library changes
2020-06-20 14:27:41 <fabled> as-in, how far back we need to backport the patch series
2020-06-20 15:14:09 <andypost[m]> maxice8: -dev packages doesn't depends on main package https://github.com/alpinelinux/abuild/blob/master/abuild.in#L1831
2020-06-20 15:14:37 <maxice8> I know they technically don't
2020-06-20 15:15:22 <maxice8> but it is easier to just say they do than to explain that they depend on various packages and have other dependencies depending on various factors like if it has /usr/lib/pkgconfig and will try to match .so from the -dev package to one from the mainpkg or another subpackage present
2020-06-20 15:17:24 <andypost[m]> I find it also not obvious that I need to mention both -dev and the main twice - in make and check depends
2020-06-20 15:18:19 <afontain_> depending on the package and the language, they often don't
2020-06-20 15:19:21 <afontain_> for example, some C++ code that makedepends on lxc-dev, will be autodetected as linked to lxc-libs
2020-06-20 15:23:13 <andypost[m]> Thanks ! Missed this
2020-06-20 16:21:58 <dalias> hm?
2020-06-20 18:20:22 <mps> I'm little disappointed by some MR, !9446 for example
2020-06-20 18:20:39 <mps> is the author here?
2020-06-20 18:21:29 <mps> a lot of failed pkgs on CI from her/him
2020-06-20 18:29:21 <mps> heh, we got kernel config option: CONFIG_ARCH_ALPINE :)
2020-06-20 18:29:57 <mps> 'This enables support for the Annapurna Labs Alpine Soc family.'
2020-06-20 18:31:59 <mps> hehe, even their site looks familiar, http://www.annapurnalabs.com/
2020-06-20 18:32:13 <oneinsect> will they us a free sample?
2020-06-20 18:32:31 <oneinsect> holy shucks
2020-06-20 18:32:34 <oneinsect> indeeed
2020-06-20 18:33:02 <oneinsect> Alpine symbol is so similar to theirs or err their symbol is so same to us
2020-06-20 18:33:54 <mps> oneinsect: don't expect much from Amazon
2020-06-20 18:34:26 <mps> oneinsect: and, Namaste Namaste!
2020-06-20 18:38:20 <oneinsect> lol namaste namaste namaste
2020-06-20 18:38:43 <oneinsect> finally my builder is working well (it seems)
2020-06-20 18:38:55 <oneinsect> just starting building using abuild -r
2020-06-20 18:39:21 <oneinsect> only thing the tests take a long time
2020-06-20 18:39:31 <oneinsect> even on AMD 3900x
2020-06-20 19:31:49 <oneinsect> The requested URL returned error: 404 Not Found
2020-06-20 19:31:50 <oneinsect> >>> ERROR: rsync: fetch failed
2020-06-20 19:31:57 <oneinsect> https://download.samba.org/pub/rsync/rsync-3.1.3.tar.gz
2020-06-20 19:32:07 <oneinsect> did anyone notice this regarding rync?
2020-06-20 19:32:19 <mps> network issue?
2020-06-20 19:32:31 <maxice8> no
2020-06-20 19:32:48 <maxice8> rsync had new release (if one upgrade please enable zstd support)
2020-06-20 19:32:50 <maxice8> 3.2.0
2020-06-20 19:33:14 <oneinsect> oooh we still havent updated yet?
2020-06-20 19:33:16 <ikke> some projects only host the latest version, or move older versions somewhere else
2020-06-20 19:33:34 <mps> maxice8: nice idea
2020-06-20 19:33:54 <oneinsect> darn
2020-06-20 19:35:32 <oneinsect> found it here for now http://mirrors.ibiblio.org/rsync/
2020-06-20 19:36:23 <mps> or here https://download.samba.org/pub/rsync/src/
2020-06-20 19:36:27 <ikke> https://repology.org/project/rsync/information#Downloads
2020-06-20 19:36:40 <oneinsect> so are moving to 3.2.0 soon?
2020-06-20 19:37:36 <mps> https://download.samba.org/pub/rsync/src/rsync-3.2.0.tar.gz
2020-06-20 19:38:49 <tsarna> What are the criteria for moving a package from testing to community? I submitted docker-credential-ecr-login a while back and it's been working fine for me.
2020-06-20 19:38:59 <ikke> basically that :)
2020-06-20 19:39:05 <ikke> confirmation that it's working properly
2020-06-20 19:39:10 <ikke> and a MR to move it
2020-06-20 19:39:26 <tsarna> OK, thanks. Does it need a pkgrel bump if the only change is moving it?
2020-06-20 19:39:32 <mps> and, intention to maintain it would be nice
2020-06-20 19:39:41 <ikke> yes, certainly
2020-06-20 19:40:05 <tsarna> Sorry was that yes to pkgrel or yes to maintaining? I plan on the latter :)
2020-06-20 19:40:07 <mps> tsarna: no need to bump pkgrel
2020-06-20 19:40:36 <tsarna> ok, cool
2020-06-20 19:41:15 <mps> if I read ikkes mind correctly 'certainly' is related to maintaining
2020-06-20 19:41:34 <ikke> :)
2020-06-20 19:48:08 <mps> does gnome-keyring really need to depend on linux-pam?
2020-06-20 19:51:07 <Cogitri> Yes, for automatic unlocking
2020-06-20 19:52:40 <mps> :(
2020-06-20 19:54:42 <Cogitri> Although I think that's currently broken tho?
2020-06-20 20:43:46 <Hello71> without looking at the package, I would speculate that it distributes a dynamically linked pam module
2020-06-20 20:43:56 <Hello71> but the module is not loaded unless you configure it in /etc/pam.d
2020-06-20 20:45:11 <mps> I only looked to the point I see that it can be built without pam
2020-06-20 21:16:33 <alexeymin> do edge armhf & armv7 builders feel good?
2020-06-20 21:17:08 <mps> alexeymin: I think yes
2020-06-20 21:17:28 <mps> what is your issue
2020-06-20 21:17:39 <mps> problem*
2020-06-20 21:18:42 <mps> they are building some packages right now
2020-06-20 21:23:18 <alexeymin> those percentages don't change for a long time :)
2020-06-20 21:23:46 <mps> load average: 26.10, 26.01, 25.52
2020-06-20 21:24:39 <mps> building gnome 'things' require time :)
2020-06-20 21:26:42 <mps> especially if 'someone' at the same time build linux-edge on 'them' ;)
2020-06-20 21:28:01 <ikke> heh
2020-06-20 21:29:50 <alexeymin> we in pmos have CI monitoring pipeines that run every hour https://gitlab.com/postmarketOS/monitoring/pipelines
2020-06-20 21:30:15 <alexeymin> and musl revbump was detected 5 hours ago according to it
2020-06-20 21:30:38 <ikke> Yeah, I'm just looking at it
2020-06-20 21:30:38 <alexeymin> but http://dl-cdn.alpinelinux.org/alpine/edge/main/armhf/musl-1.1.24-r9.apk this is still 404?
2020-06-20 21:30:45 <ikke> does seem stuck
2020-06-20 22:08:26 <clandmeter> alexeymin: its unstuck
2020-06-20 22:08:43 <clandmeter> but it will have a hard time to get uptodate
2020-06-20 22:08:49 <clandmeter> so it will take some time
2020-06-21 04:12:01 <oneinsect> how does the actual alpine builders work? any script you guys can share?
2020-06-21 04:12:29 <oneinsect> i am simply doing a loop of building apks in order of dependency
2020-06-21 04:13:31 <oneinsect> if the builder gets an error, will it stop the loop and when I restart will it resume from the last position? do you such mechansisms for alpine builder?
2020-06-21 06:04:31 <Ariadne> oneinsect: see aports-build package
2020-06-21 06:04:58 <oneinsect> thank you Ariadne thank you very much
2020-06-21 08:11:10 <oneinsect> is python3 passing all tests in alpine builder?
2020-06-21 08:12:17 <oneinsect> some seem to fail on x86_64?
2020-06-21 08:13:46 <Cogitri> Well, if they failed we'd mark that in the APKBUILD via `options="!check"`
2020-06-21 08:14:09 <Cogitri> And since that's not in the APKBUILD the tests seem to work
2020-06-21 08:15:20 <oneinsect> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/python3/APKBUILD
2020-06-21 08:15:32 <oneinsect> i read fails on x86_64
2020-06-21 08:15:35 <oneinsect> at some places?
2020-06-21 08:15:44 <oneinsect> # FIXME: failures needing investigation
2020-06-21 08:17:05 <Cogitri> Some tests are skipped apparently, but we do run the other ones
2020-06-21 08:17:12 <oneinsect> hmmmm
2020-06-21 08:21:43 <ollieparanoid[m]> build-3-12-armv7 and others are stuck at "pulling git". how can this be resolved?
2020-06-21 08:24:04 <Cogitri> ikke: ^
2020-06-21 08:27:44 <mps> huh, again multipath problem
2020-06-21 08:51:53 <andypost[m]> Docker image ppc64 packaged with s390x alpinelinux/docker-abuild
2020-06-21 09:03:34 <ikke> I can check later
2020-06-21 10:10:08 <ikke> armhf/v7 don't seem stuck
2020-06-21 10:22:16 <ikke> fontconfig is currently failing on armhf
2020-06-21 11:54:42 <russkel> anyone have any experience with things like babeltrace/lttng?
2020-06-21 18:40:24 <Cogitri> Someone up for testing !9465 ?
2020-06-21 18:40:38 <Cogitri> Tried with ff and seems to work, but would be good to have a 2nd look
2020-06-21 19:53:52 <Ganwell> The three or four times I tried to build something with qemu-user-static and docker multiarch it failed for different reasons. Some builds were a long time ago, I can't remember the reasons. My latest one was the build of rust freezing after 20 minutes. Is this expected or my bad-luck or maybe a mistake I keep repeating?
2020-06-21 19:54:14 <Ganwell> I using abuild of course.
2020-06-21 19:54:48 <Ganwell>  * I was using abuild of course.
2020-06-21 19:58:28 <artok> rust build is slow anyway
2020-06-21 19:59:29 <artok> and it hangs once in a while even in builders if I remember correctly =)
2020-06-21 20:01:49 <Cogitri> It actually doesn't hang, it just used to crash with LLVM <10
2020-06-21 20:04:13 <Ganwell> So usually multiarch works. Good to know.
2020-06-21 20:07:58 <artok> is rust built with LTO ?
2020-06-21 20:11:48 <Cogitri> Not sure, that's set per package via Cargo.toml
2020-06-21 20:13:44 <Ganwell> I guess rust (not the apk) would still use their LLVM 9 fork.
2020-06-21 20:14:19 <Ganwell> Oh, its merge: https://github.com/rust-lang/rust/pull/67759
2020-06-21 20:16:14 <Ganwell> The fork is now archived. At last.
2020-06-21 20:16:14 <Cogitri> Well, we build with system llvm
2020-06-21 20:26:16 <Ganwell> Oh, no. I checked the wrong repo. They stilll use it, but updated to 10. I hope this goes way soon so rust-lld and the whole wasm-workflow gets into stable.
2020-06-21 20:28:36 <Ganwell> qemu: uncaught target signal 6 (Aborted) - core dumped
2020-06-21 20:53:30 <Ganwell> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1737312 seems to be that bug.
2020-06-21 21:00:33 <artok> well that is 2018 thingie
2020-06-21 21:00:57 <artok> and in ubuntu ;)
2020-06-21 21:01:07 <artok> havin' latest qemu?
2020-06-21 21:03:58 <artok> at least the multiarch docker image seems to be 5.0.0-2
2020-06-21 21:04:06 <artok> so yah should...
2020-06-21 21:04:27 <Ganwell> Well, it kinda says they won't fix vfork.
2020-06-21 21:06:34 <Ganwell> But I downgraded qemu to 4.2. It runs past the point 5.0 crashed. So its not that bug.
2020-06-21 21:06:35 <Ganwell> docker run --rm --privileged multiarch/qemu-user-static:4.2.0-7 --reset --persistent yes --credential yes
2020-06-21 21:07:08 <artok> makes me more and more lean on cross compiling
2020-06-21 21:11:11 <artok> apk is nice, able to do chroot for foreign arch
2020-06-21 21:11:51 <Ganwell> Cross compiling is very hard and won't work at all for most compilers/interpreters because they get parameters like size of int from the host system, which can be very wrong. About the only thing that really plays nice in cross-compiling is the kernel. It means we have to use qemu-sysstem, which is also hard. Finding the right settings so the kernel boots is a very special magic.
2020-06-21 21:13:37 <artok> I've got GNU toolchain for compiling kernel (and modules) and then llvm toolchain to do the crossbuilds
2020-06-21 21:13:47 <artok> targeting aarch64
2020-06-21 21:15:15 <artok> gnu autotools is hell for cross compilers
2020-06-21 21:15:22 <Ganwell> I mean compiling compilers and interpreters: python, rust ...
2020-06-21 21:16:37 <artok> old config.guess etc is bad
2020-06-21 21:17:05 <Ganwell> yes, it is.
2020-06-21 21:18:03 <artok> for example I've got hacky diff for llvm11 for alpine, instead of calling config.guess, I take triple from gcc -dumpmachine
2020-06-21 21:26:03 <artok> that reminds me about the patch I was about to send
2020-06-21 21:26:10 <artok> add the musl triplets
2020-06-21 21:26:33 <artok> Cogitri: had any second opinions on your nss ?
2020-06-21 21:30:29 <mps> will we upgrade neomutt or remove
2020-06-21 21:34:05 <Cogitri> artok: not yet, fails on CU because the buildsystem apparently doesn't like multiple build jobs
2020-06-21 21:34:59 <artok> I was just checing for build artifacts
2020-06-21 21:35:36 <artok> when apk is ready, I'd might try it out
2020-06-21 21:35:44 <Cogitri> Okie
2020-06-21 21:36:09 <Cogitri> I built it locally and that worked just fine so I had hoped 8 buildjobs would be OK
2020-06-21 21:36:19 <artok> normal
2020-06-21 21:36:36 <artok> opencv x86_64 all test pass, CI even x86_64 didn't pass
2020-06-21 21:41:35 <artok> but their tests use deprecated stuff anyway
2020-06-22 09:53:59 <Cogitri> artok: nss MR passed CI: !9465
2020-06-22 09:54:37 <artok> wheee
2020-06-22 10:04:58 <artok> at least firefox runs
2020-06-22 10:08:15 <artok> no problems so far, RELEASE! =)
2020-06-22 15:04:13 <ollieparanoid[m]> build-edge-armhf is stuck at main/fontconfig, some test is failing
2020-06-22 15:04:34 <ollieparanoid[m]> I've just built it on an arm phone for armhf successfully
2020-06-22 15:04:53 <ollieparanoid[m]> so... it might be a race condition or something. can somebody trigger it to start again?
2020-06-22 15:05:10 <ikke> ollieparanoid[m]: you can, but it's failing for quite some time now, so I don't think a rebuild will fix it
2020-06-22 15:05:25 <maxice8> plus every push will trigger it
2020-06-22 15:05:30 <ollieparanoid[m]> ikke: would you accept a patch that disables the tests for armhf then?
2020-06-22 15:05:49 <ikke> ollieparanoid[m]: preferably just specific tests if possible
2020-06-22 15:06:35 <ollieparanoid[m]> ikke: I'll try to do that
2020-06-22 15:30:31 <ollieparanoid[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9503
2020-06-22 15:48:13 <ikke> ollieparanoid[m]: CI fails on armv7 for some reason (also tests)
2020-06-22 16:08:05 <ollieparanoid[m]> wtf
2020-06-22 16:08:27 <ollieparanoid[m]> clicking retry
2020-06-22 16:10:03 <ollieparanoid[m]> and the same test fails. what the hell... the same test has worked on the build bot :\
2020-06-22 16:22:22 <ollieparanoid[m]> interesting, it is passing with -j1
2020-06-22 16:22:53 <ollieparanoid[m]> I'll change the patch to set -j1 and cat test-suite.log, maybe that "fixes" it for armhf too. and if it does not, at least we see the proper error
2020-06-22 16:30:38 <ollieparanoid[m]> ikke: this should do it, can you take another look?
2020-06-22 16:31:01 <ikke> I can in a bit
2020-06-22 16:31:44 <ollieparanoid[m]> thanks! I'm afk now
2020-06-22 17:10:45 <ikke> ollieparanoid[m]: will be merged when the pipeline is green (after rebase)
2020-06-22 17:10:50 <ikke> Let's see if that fixes it
2020-06-22 17:23:43 <ikke> ollieparanoid[m]: I think it's fixed now, the builder is proceeding
2020-06-22 17:24:06 <ikke> thanks
2020-06-22 17:40:31 <ollieparanoid[m]> \o/
2020-06-22 17:49:52 <ikke> ollieparanoid[m]: sad-face
2020-06-22 17:49:55 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-armhf/main/fontconfig/fontconfig-2.13.1-r3.log
2020-06-22 17:50:27 <ikke> and no test suite log
2020-06-22 17:51:21 <ollieparanoid[m]> ikke: huh, is it not fixed?
2020-06-22 17:51:25 <ikke> which might mean it still was building the previous version
2020-06-22 17:51:30 <ollieparanoid[m]> are you sure that this is not an old log file?
2020-06-22 17:51:45 <ikke> I saw a failed message in #alpine-commits
2020-06-22 17:51:47 <ollieparanoid[m]> yeah, because the new one does print the log file. it failed once without -j1 in gitlab and printed test-suite.log:
2020-06-22 17:52:03 <ikke> it just failed again
2020-06-22 17:52:08 <ikke> now with output
2020-06-22 17:52:26 <ollieparanoid[m]> https://gitlab.alpinelinux.org/ollieparanoid/aports/-/jobs/149211#L683 that's how it looks like
2020-06-22 17:52:34 <ollieparanoid[m]> damn
2020-06-22 17:52:38 <ikke> :*** Test failed: Basic functionality with the bind-mounted cache dir:
2020-06-22 17:53:40 <ollieparanoid[m]> okay, at least we have output and can add another patch to disable that part then
2020-06-22 17:53:48 <ollieparanoid[m]> I need to go though, will probably look at it tomorrow
2020-06-22 17:54:08 <ikke> I do wonder why that is failing only on armhf though
2020-06-22 17:54:18 <ikke> and only on the builder
2020-06-23 06:22:21 <ollieparanoid[m]> the test probably failed, because it tries to use bubblewrap
2020-06-23 06:22:22 <ollieparanoid[m]> https://gitlab.freedesktop.org/fontconfig/fontconfig/-/blob/2.13.1/test/run-test.sh#L181-182
2020-06-23 06:23:00 <ikke> aha, ok
2020-06-23 06:23:03 <ollieparanoid[m]> this would also explain why I was not able to reproduce it - if bubblewrap is not installed, it seems that the test is just skipped
2020-06-23 06:23:32 <ollieparanoid[m]> I'll make a MR with a patch that disables "run-test.sh" for armhf
2020-06-23 06:24:13 <ikke> But bubblewrap is not installed on the builder either
2020-06-23 06:24:24 <ikke> build-edge-armhf [~]# apk version bubblewrap
2020-06-23 06:24:25 <ikke> Installed:                                Available:
2020-06-23 06:25:01 <ollieparanoid[m]> but how can it go through the code path of that if condition then?
2020-06-23 06:25:26 <ollieparanoid[m]> what does "which bwrap" give?
2020-06-23 06:27:42 <ikke> hmm, ok, strange, an orphaned binary
2020-06-23 06:27:50 <ikke> ERROR: /usr/bin/bwrap: Could not find owner package
2020-06-23 06:28:02 <ikke> that explains
2020-06-23 06:28:25 <ollieparanoid[m]> lol ok
2020-06-23 06:28:39 <ollieparanoid[m]> great, so you delete it, and let it build again?
2020-06-23 06:28:39 <ikke> Then I think it will succeed now
2020-06-23 06:28:59 <ollieparanoid[m]> glad that we found this, thanks ikke :)
2020-06-23 06:29:10 <ikke> ollieparanoid[m]: you as well for doing the research
2020-06-23 06:29:24 <ollieparanoid[m]> yw
2020-06-23 06:32:30 <ollieparanoid[m]> yay, seems like it passed now
2020-06-23 06:32:48 <ikke> nice
2020-06-23 09:19:04 <hc-hmk> Hi @ncopa, you've been chatting with my colleague mathias-hmk a few days ago. We're having trouble booting linux-lts@edge, which is weird since both linux-lts and linux-edge@testing works fine. Could you help me wrap my brain around why this doesn't work?
2020-06-23 09:19:56 <ikke> hc-hmk: Hello, welcome. Please post any details here so anyone who has time and the knowledge can help you
2020-06-23 09:21:50 <hc-hmk> I'm afraid I don't have much to go on. I'm using extlinux/syslinux as bootloader, and it straight up just fails to load. It shows a static cursor in the top left corner, which I haven't seen since the early days of development of our firmware.
2020-06-23 09:26:10 <ikke> hc-hmk: ncopa just pushed a new kernel version of linux-lts
2020-06-23 09:26:38 <ikke> maybe you can try that after it's built
2020-06-23 09:26:41 <ikke> 5.4.48
2020-06-23 09:29:32 <hc-hmk> Our stable firmware runs 5.4.43-1-lts. Are you saying he *just* pushed a new kernel? If that's the case, I'll brew up a debug build real quick. The kernel that's failing us is linux-lts@edge (5.4.47-r1)
2020-06-23 09:29:49 <ikke> yes, _just_
2020-06-23 09:29:54 <ikke> 10 minutes ago
2020-06-23 09:29:57 <ikke> or 20
2020-06-23 09:30:53 <hc-hmk> alright. pkgs.alpinelinux.org says that 5.4.47 from 2020-06-19 is latest, but that's probably just slightly out of date then
2020-06-23 09:31:18 <ikke> yes, it's still being built
2020-06-23 09:31:37 <ikke> (out of tree modules atm)
2020-06-23 09:32:02 <hc-hmk> Oh, it's still building. My bad.
2020-06-23 09:58:10 <hc-hmk> I'll check back in tomorrow with an update on whether it works or not. Thank you for your time.
2020-06-23 11:33:27 <ncopa> go is missing on mips64?
2020-06-23 11:34:38 <ikke> yes
2020-06-23 11:55:49 <ncopa> im not sure what we should do with github source downloads
2020-06-23 11:55:58 <ncopa> checksums changes once in a while
2020-06-23 11:56:01 <ncopa> https://build.alpinelinux.org/buildlogs/build-edge-mips64/community/libbpf/libbpf-0.0.9-r0.log
2020-06-23 11:57:03 <ncopa> ncopa-edge-x86_64:~/aports/community/libbpf$ abuild -r cleancache all 2>&1 | tpaste
2020-06-23 11:57:03 <ncopa> https://tpaste.us/Z0b4
2020-06-23 11:57:14 <ncopa> its not the first time that happens and it will not be the last
2020-06-23 11:57:23 <ncopa> any ideas how we deal with it?
2020-06-23 11:57:31 <ikke> Isn't that because upstream changed something?
2020-06-23 11:57:34 <mps> right, I had it few times
2020-06-23 11:57:45 <ncopa> ikke: not neccesarily
2020-06-23 11:57:45 <mps> forgot which pkg
2020-06-23 11:57:58 <ncopa> i think github archives are generated on the fly
2020-06-23 11:58:03 <ncopa> similar to what cgit does
2020-06-23 11:58:10 <mps> sometimes it worked in 'flip-flop' mode :)
2020-06-23 11:58:12 <ikke> it's just git archive over http
2020-06-23 11:58:25 <ncopa> i think it generates it on the fly
2020-06-23 11:58:29 <ncopa> and possibly caches it
2020-06-23 11:59:17 <ncopa> i suspect that they cache it, since it works in most cases
2020-06-23 11:59:39 <ncopa> but i think if they update git version or similar on server side, the archive may be different
2020-06-23 12:00:03 <ikke> Something must trigger it, otherwise we would run into it all the time, rather than once in a while
2020-06-23 12:00:21 <ikke> afaik, the archive generation itself should be deterministic
2020-06-23 12:00:59 <ncopa> i think it is. cgit was, up to the point git was updated on server side
2020-06-23 12:01:01 <mps> correct RFC term is 'MUST'
2020-06-23 12:01:02 <ncopa> then it changed
2020-06-23 12:01:45 <mps> but until we get sources.a.o such things will happen
2020-06-23 12:01:52 <ncopa> that is the reason why i had a git hook that generated a tarball and uploaded it to dev.a.o/archive
2020-06-23 12:02:11 <ikke> git archive is deterministic at least
2020-06-23 12:02:24 <ncopa> as long as you use same git version yes
2020-06-23 12:02:50 <ncopa> but i dont think they guarantee it to be deterministic across git version
2020-06-23 12:03:34 <ncopa> i also dont know if it depends on file system ordering etc
2020-06-23 12:04:51 <ncopa> oh
2020-06-23 12:05:04 <ncopa> they did change the tag for libbpf
2020-06-23 12:05:26 <ncopa> $ diff -ru /tmp/a /tmp/b | tpaste
2020-06-23 12:05:26 <ncopa> https://tpaste.us/lY9g
2020-06-23 12:05:29 <mps> deterministic create of archive depends on some nondeterministic things
2020-06-23 12:06:50 <mps> only sane solution for such pkgs is put them on dev.a.o, for now at least
2020-06-23 12:07:06 <ikke> ncopa: ha
2020-06-23 12:07:07 <ikke> :P
2020-06-23 12:07:36 <ikke> If this was a systemic issue, we would have this much more frequently
2020-06-23 12:07:44 <ikke> loads of packages come from github
2020-06-23 12:08:02 <ikke> We would be updating checksums non-stop when building a new release
2020-06-23 12:08:37 <mps> ikke: yes, and I don't have better idea
2020-06-23 12:26:55 <ikke> We are kind of already archives sources
2020-06-23 12:26:59 <ikke> distfiles.a.o
2020-06-23 14:13:36 <Hello71> I don't think github currently uses git archive. the format changes "once in a while". on github you are "supposed to use" pre-generated archives and then upload those to releases page. arguably they should not guarantee the format, because then they cannot optimize the tar or change the backend algorithm forever
2020-06-23 14:14:16 <Hello71> debian and gentoo deal with this by storing the archive locally. arch deals with this by punting to individual maintainers
2020-06-23 14:14:29 <Hello71> or using a git url in sources
2020-06-23 14:15:12 <Hello71> because git guarantees the content of a commit hash (mumble sha1 mumble)
2020-06-23 14:22:02 <ikke> comment from peff (both core contributor in git and github employe): https://github.com/Homebrew/homebrew-core/issues/18044#issuecomment-329313468
2020-06-23 14:22:16 <ikke> seems to indicate they should be pretty stable except for bug fixes from upstream
2020-06-23 14:23:27 <ikke> and it also confirms it's using git archive in the back
2020-06-23 14:24:50 <ikke> "We're discussing the possibility of providing byte-stable tarballs automatically (by cementing the archives, bugs and all, at the time a tag is uploaded)."
2020-06-23 14:25:05 <ikke> so potentially even stronger guarantees
2020-06-23 14:30:31 <maxice8> I have vague memories of OpenBSD people warning some distros about it
2020-06-23 14:30:32 <maxice8> I think it was with Void Linux
2020-06-23 14:35:06 <Hello71> ikke: ... as of 2017.
2020-06-23 14:38:30 <Ariadne> itis probably better to use git uri for github projects tbh
2020-06-23 14:38:41 <ikke> It kind of indicates githubs intention of keeping them stable and not putting all kinds of optimizations in front. Of course that can change, but we have not seen any evidence of that yet
2020-06-23 14:38:47 <ikke> 'git uri'
2020-06-23 14:40:58 <Ariadne> git://whatever
2020-06-23 14:41:10 <Ariadne> anyway i am uncaring
2020-06-23 14:41:19 <Ariadne> sometimes we have checksum fails on github archives
2020-06-23 14:41:27 <ikke> Not sure if that's such a great idea honestly
2020-06-23 14:41:27 <Ariadne> we just regen those checksums i guess
2020-06-23 14:41:41 <Ariadne> after making sure they didnt actually change
2020-06-23 14:41:49 <ikke> Which was the case
2020-06-23 14:42:06 <ikke> for libbpf
2020-06-23 14:42:08 <ikke> https://tpaste.us/lY9g
2020-06-23 14:42:49 <ikke> We are already suffing from projects using git clone to obtain secdb
2020-06-23 14:43:27 <ikke> (or were)
2020-06-23 14:43:32 <Ariadne> like i said i'm apathetic
2020-06-23 14:43:37 <Ariadne> status quo seems fine enough
2020-06-23 16:15:18 <dalias> what does "bugs and all" mean?
2020-06-23 16:15:33 <dalias> are they claiming git-archive might produce wrong output they need to fix?
2020-06-23 16:16:32 <dalias> seems like the git-archive format should be pegged to the commit date of the commit the tag points to (not the date the tag was uploaded to github)
2020-06-23 16:18:07 <ikke> dalias: "bugs and all" means, if there would happen to be a bug in the format of git archive, because they stored the archive itself, it will not be regenerated to fix potential bugs
2020-06-23 16:20:03 <dalias> right. it seems odd to me that they would expect that to happen anyway though
2020-06-23 16:20:17 <ikke> He pointed to one case
2020-06-23 16:20:23 <dalias> oh? what was it?
2020-06-23 16:20:57 <ikke> https://github.com/git/git/commit/22f0dcd9634a818a0c83f23ea1a48f2d620c0546
2020-06-23 16:20:59 <dalias> did it affect virtually everyone or just obscure corner case? i can't imagine there being a bug with wide impact in archive generation or pppl would hit it
2020-06-23 16:21:16 <ikke> corner case (long paths)
2020-06-23 16:22:01 <dalias> ah
2020-06-23 16:22:04 <Hello71> and it only affected people with... netbsd 6 tar
2020-06-23 16:22:23 <dalias> well now it affects anyone with long paths since it destabilized output :/
2020-06-23 16:22:36 <dalias> however "anyone with long paths" = "java shit" ;-)
2020-06-23 16:22:51 <dalias> so $shruggie
2020-06-23 16:23:10 <ikke> apparently netbsd tar tripped over it
2020-06-23 16:23:44 <dalias> on the same topic do you know how they make the gz part deterministic? is it their own gzip impl?
2020-06-23 16:23:57 <ikke> He mentioned that as well
2020-06-23 16:24:00 <dalias> iirc i looked this up like 7 or 8 years ago but can't remember
2020-06-23 16:24:13 <ikke> "this is calling gzip -cn under the hood"
2020-06-23 16:24:23 <ikke> https://github.com/Homebrew/homebrew-core/issues/18044#issuecomment-329313468
2020-06-23 16:25:15 <ikke> "but it's possible your local gzip may produce slightly different output, wrecking the hash"
2020-06-23 16:25:38 <Hello71> a fun article on tar portability: https://dev.gentoo.org/~mgorny/articles/portability-of-tar-features.html
2020-06-23 16:30:10 <dalias> ah
2020-06-23 16:30:34 <dalias> fwiw i use busybox gzip for releases iirc
2020-06-23 16:34:03 <mps> this is non issue when the releases are proper, i.e. created tarballs in one fixed time
2020-06-23 16:34:32 <dalias> it's still an aspect of reproducibility
2020-06-23 16:34:37 <mps> 'on the fly' creating releases tarballs are problems
2020-06-23 16:35:02 <dalias> i like to be able to say: "you can verify this release tarball was generated from git-archive of this repo [with this configuration]"
2020-06-23 16:36:02 <mps> yes, if you can guarantee deterministic 'entries' for tarball
2020-06-23 16:36:19 <dalias> entries?
2020-06-23 16:36:26 <mps> deterministically*
2020-06-23 16:36:57 <mps> by entries I mean all what can change during creation
2020-06-23 16:37:46 <mps> I'm not sure how DST can effect this
2020-06-23 16:37:52 <Hello71> ...
2020-06-23 16:37:53 <mps> DST change
2020-06-23 16:39:12 <mps> (uhmm, I'm much irritated by my jaw bone ache to think clearly, and less cleary write)
2020-06-23 16:40:00 <mps> 
ACTION better stop babbling

2020-06-23 16:49:27 <dalias> DST??
2020-06-23 16:50:01 <dalias> asking how DST changes your dir entries is like asking how CSS changes your HTML
2020-06-23 16:50:09 <dalias> (it doesn't because it's purely presentation-layer)
2020-06-23 16:53:16 <mps> interesting, I always thought DST changes that, but never checked, I must tell
2020-06-23 16:53:24 <mps> thanks
2020-06-23 16:53:58 <ikke> timestamps are in UTC, which is not affected by DST. Only when converting to a local timezone, it comes into affect
2020-06-23 16:55:30 <dalias> i wish ppl understood this better because so much wrongness (syslogs in local time, etc.) ppl do/want-to-do is based on misunderstanding of representation vs presentation
2020-06-23 16:55:34 <mps> now it sounds clear :)
2020-06-23 16:56:15 <mps> never thought about that, must confess
2020-06-23 16:56:51 <ikke> s/affect/effect
2020-06-23 16:56:51 <alpine-meetbot> ikke meant to say: timestamps are in UTC, which is not effected by DST. Only when converting to a local timezone, it comes into affect
2020-06-23 16:56:57 <ikke> lol :D
2020-06-23 16:56:59 <mps> (working with end users in business screw minds :) )
2020-06-23 16:58:15 <mps> and, I'm happy that DST insanity are planned to die, but when ...
2020-06-23 16:59:33 <ikke> mps: only in Europe, if they ever come to an agreement
2020-06-23 17:00:52 <mps> ikke: good point, :)
2020-06-23 17:01:38 <mps> but iirc some countries already done that
2020-06-23 17:01:50 <mps> can't remember which ones
2020-06-23 17:02:28 <ikke> There are lots of changes all the time
2020-06-23 17:11:31 <[[sroracle]]> pun intended? :p
2020-06-23 17:11:41 <ikke> heh, not even :)
2020-06-23 18:09:04 <mps> is that about how we trying to change some things in Alpine :)
2020-06-23 18:09:30 <ikke> Line the name of the linux kernel? :P
2020-06-23 18:16:30 <ikke> https://www.openwall.com/lists/oss-security/2020/06/23/2 Important point about not being too focused on CVE's
2020-06-23 18:17:11 <ikke> Red Hat found a bug that was fixed 18 months ago in the linux kernel
2020-06-23 18:18:43 <mps> :)
2020-06-23 18:19:39 <mps> 'Security is complex, isn't it' - Steve Bellowin, in ~90-ties
2020-06-23 18:31:25 <mps> heh, so linux-edge is most secure kernel
2020-06-23 18:31:51 <ikke> mps: it also inroduces new security issues :P
2020-06-23 18:32:15 <mps> yes, but first where are they fixed
2020-06-23 18:33:20 <mps> (says one who run 5.8.0-rc2-1-gru #2 SMP PREEMPT Mon Jun 22 06:05:19 UTC 2020 aarch64 GNU/Linux)
2020-06-23 20:54:02 <the6543> hello
2020-06-23 20:56:02 <ikke> hi
2020-06-23 20:56:36 <the6543> so this is the main chat for alpine development
2020-06-23 20:56:41 <ikke> yes
2020-06-23 20:56:57 <the6543> nice IRC is still used :)
2020-06-23 20:57:03 <ikke> alive and kicking
2020-06-23 20:57:10 <the6543> hehe
2020-06-23 20:57:52 <the6543> I was going to ask @clandmeter if I can take maintainership of the gitea package
2020-06-23 20:58:19 <clandmeter> hi
2020-06-23 20:58:25 <clandmeter> please do
2020-06-23 20:58:28 <ikke> :))
2020-06-23 20:58:35 <ikke> I already assumed you wouldn't mind
2020-06-23 20:58:54 <clandmeter> i saw the MR
2020-06-23 20:59:01 <the6543> MR ?
2020-06-23 20:59:05 <clandmeter> but just too busy to follow it up
2020-06-23 20:59:18 <clandmeter> there is a MR for gitea i think
2020-06-23 20:59:19 <the6543> ah MergeRequest ...
2020-06-23 20:59:24 <ikke> it was already merged
2020-06-23 20:59:32 <clandmeter> oh ok, it was assigned to me.
2020-06-23 20:59:35 <clandmeter> but i am lazy
2020-06-23 20:59:49 <ikke> https://docs.gitlab.com/ee/ci/variables/predefined_variables.html
2020-06-23 20:59:51 <ikke> hmm
2020-06-23 20:59:54 <the6543> I usualy use the term PR (pull request) ...
2020-06-23 21:00:06 <the6543> but this is just one alias for the same thing anyway
2020-06-23 21:00:14 <ikke> https://git.alpinelinux.org/aports/commit/?id=e3e73faf
2020-06-23 21:00:29 <ikke> gitlab calls it merge requests, so hene, MR :)
2020-06-23 21:01:06 <the6543> hihi - ok clandmeter I'll create a smal pull
2020-06-23 21:01:45 <the6543> > but i am lazy
2020-06-23 21:02:04 <the6543> I think you have more tasks to do as I have - so never mind
2020-06-23 21:02:22 <the6543> and thats one reason I'd like to take care of it now
2020-06-23 21:02:45 <clandmeter> assign it to kdaudt ;-)
2020-06-23 21:02:47 <ikke> :D
2020-06-23 21:03:00 <clandmeter> else you will shoot carrots
2020-06-23 21:03:23 <clandmeter> thats really a bad translation of a dutch saying.
2020-06-23 21:03:27 <ikke> :)
2020-06-23 21:03:43 <ikke> Was about to say, you'll only udnerstand that when you're dutch
2020-06-23 21:04:25 <clandmeter> the6543: thx for taking care of it.
2020-06-23 21:05:01 <the6543> hope this: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9540
2020-06-23 21:05:05 <the6543> is the way it is done
2020-06-23 21:05:32 <the6543> :thinking: eventualy all lowercae ?
2020-06-23 21:05:34 <ikke> commit messages are lower case
2020-06-23 21:05:36 <ikke> yes
2020-06-23 21:06:11 <the6543> 'community/gitea: change maintainer to @6543'
2020-06-23 21:07:18 <ikke> 'community/gitea: adopt package'
2020-06-23 21:07:38 <the6543> hmm it was close
2020-06-23 21:07:54 <the6543> done
2020-06-23 21:08:46 <ikke> Updated the title as well
2020-06-23 21:09:12 <the6543> nice was going to do it but was already done
2020-06-23 21:09:27 <ikke> heh :)
2020-06-23 21:09:37 <the6543> killing some pipelines ... done
2020-06-23 21:15:53 <the6543> just a question
2020-06-23 21:16:05 <the6543> why there is a gitlab.apline... and a git.alpine...
2020-06-23 21:16:30 <the6543> wouldn't do it a gitlab.alpine alone?
2020-06-23 21:17:00 <ikke> mostly yes. It's still there because that's what we had before we switched to gitlab
2020-06-23 21:17:10 <the6543> or has this to do with some backup strategie ?
2020-06-23 21:17:22 <ikke> mostly to keep links working
2020-06-23 21:17:51 <ikke> and also, aports is huge, and gitlab does not show all directories
2020-06-23 21:17:54 <ikke> cgit does
2020-06-23 21:18:14 <the6543> yes this restriction is somehow anoing
2020-06-23 21:18:19 <ikke> so for browsing aports, cgit is more convenient / faster
2020-06-23 21:18:41 <the6543> (y)
2020-06-23 21:20:09 <Hello71> maybe it would be good to fix " Unnamed repository; edit this file 'description' to name the repository. " then
2020-06-23 21:20:29 <Hello71> even though it says "Mirror of https://gitlab.alpinelinux.org/alpine" at top-level, this is not very clear
2020-06-23 21:20:45 <Hello71> and doesn't show in individual repos
2020-06-23 21:23:39 <Hello71> https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10696
2020-06-23 21:24:12 <ikke> Hello71: (y)
2020-06-23 21:51:46 <the6543> just noticed gitlab now shows all entrys too
2020-06-23 21:51:50 <the6543> it loads on demand
2020-06-23 21:52:04 <the6543> - or whatever you would call it -
2020-06-23 22:45:58 <the6543> since I'm the maintainer for gitea package - who is responcible for lgtm the MR?
2020-06-23 22:46:15 <the6543> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9549 - for example
2020-06-23 23:03:47 <mps> !9549
2020-06-23 23:05:56 <mps> what is the reason for upgrade
2020-06-23 23:10:01 <mps> for stable releases only sec fixes and bug fixes are acceptable and some 'special' cases
2020-06-23 23:10:46 <the6543> minor version upgrades are always sec/bug-fixes only
2020-06-23 23:11:04 <the6543> I only know 1 release where there was a enhancement added ...
2020-06-23 23:11:05 <mps> ok
2020-06-23 23:11:28 <mps> then it should be mentioned in commit messages
2020-06-23 23:11:42 <the6543> this will be a long list ...
2020-06-23 23:11:45 <the6543> will add it
2020-06-23 23:11:54 <mps> np
2020-06-23 23:12:16 <mps> good commit message which explains reasons are welcome
2020-06-23 23:12:38 <mps> no problem if it is long
2020-06-23 23:13:19 <mps> though, I would say 'reasonable enough' :)
2020-06-23 23:15:42 <the6543> ok https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9548 has it in the description now
2020-06-23 23:15:48 <the6543> is it the way it should
2020-06-23 23:15:53 <the6543> ?
2020-06-23 23:17:23 <mps> sorry, I'm not logged in right now so can't see complete commit msg
2020-06-23 23:17:51 <mps> gitlab interface annoys me too much
2020-06-23 23:18:05 <mps> web interface, I mean
2020-06-23 23:18:23 <the6543> well there is gitea ;)
2020-06-23 23:18:36 <the6543> just kidding
2020-06-23 23:19:15 <mps> :)
2020-06-23 23:19:55 <mps> long time ago I installed and played with its predecessor (even forgot name)
2020-06-23 23:20:05 <the6543> gogs
2020-06-23 23:20:16 <mps> yes, thanks for reminder
2020-06-23 23:20:37 <the6543> you would be surprised what has changed
2020-06-23 23:20:56 <mps> now, 'lab' (gitlab cli) helps me, I see your commit msg
2020-06-23 23:21:01 <mps> looks fine
2020-06-23 23:21:29 <the6543> by the way
2020-06-23 23:21:52 <the6543> tea the cli for gitea - i should add it to alpine at some point
2020-06-23 23:22:46 <mps> ok, but first in testing
2020-06-23 23:23:12 <the6543> ok I'll try to creat my first "own" package then
2020-06-23 23:23:50 <mps> yes, we all had our first 'own' pkg
2020-06-23 23:25:29 <the6543> mps should I creat MR to stable branches older thatn 3.11 for gitea?
2020-06-23 23:25:42 <the6543> there are serious once on the old versions
2020-06-23 23:25:43 <the6543> https://www.cvedetails.com/vulnerability-list/vendor_id-19185/product_id-49829/Gitea-Gitea.html
2020-06-23 23:25:59 <mps> btw, people with real (full) names get more attention from devs
2020-06-23 23:26:24 <mps> new packages goes to edge (master) branch
2020-06-23 23:26:36 <the6543> well I use my nickname all over the place
2020-06-23 23:27:01 <mps> oh, sorry, you mean fixes for gitea and not new aport 'tea'
2020-06-23 23:27:16 <the6543> both
2020-06-23 23:27:40 <the6543> there is https://gitea.com/gitea/tea
2020-06-23 23:27:43 <mps> I doubt tea will be backported to stables
2020-06-23 23:28:19 <mps> but gitea is in community so only backport to 3.12 makes sense
2020-06-23 23:28:46 <mps> community is 6 months 'release'
2020-06-23 23:28:53 <the6543> and alpine 3.9 has gitea package with securety issues
2020-06-23 23:28:54 <the6543> https://gitlab.alpinelinux.org/alpine/aports/-/blob/3.9-stable/community/gitea/APKBUILD
2020-06-23 23:29:05 <the6543> this is the other issue ,,,
2020-06-23 23:29:15 <mps> this is not suppoted
2020-06-23 23:29:23 <the6543> ah good to know
2020-06-23 23:29:32 <mps> only main have 2 years of support
2020-06-23 23:30:13 <the6543> I should have looked at https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
2020-06-23 23:30:22 <mps> yes
2020-06-23 23:32:44 <the6543> ok then all should be fine
2020-06-23 23:33:47 <mps> :)
2020-06-23 23:34:19 <the6543> just !9548 and !9549 will do it
2020-06-23 23:39:51 <maxice8> https://bugzilla.kernel.org/show_bug.cgi?id=208251
2020-06-23 23:40:55 <mps> maxice8: is that fixed in 5.4.48
2020-06-23 23:41:32 <mps> I'm drunk to look at changelog
2020-06-23 23:42:12 <mps> but iirc it fixed
2020-06-23 23:44:56 <maxice8> linux-edge is on 5.7.5
2020-06-23 23:47:56 <mps> yes
2020-06-23 23:48:20 <mps> and I think this is fixed
2020-06-23 23:51:00 <mps> hmm, ok
2020-06-23 23:51:04 <mps> maybe not
2020-06-24 00:00:17 <mps> hmm, I loocked myself
2020-06-24 01:21:41 <Terror> Hi, can anyone check https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9085 please?
2020-06-24 01:30:31 <Hello71> atm alpine hooks don't print anything
2020-06-24 02:01:19 <Terror> Happy to get rid of the watcher. It'll be built into the next version of mdnsd
2020-06-24 02:16:46 <Hello71> I mean that sounds bad too but at least it's (hopefully) less maintenance
2020-06-24 02:21:12 <Terror> Any preference on how to get rid of that? A new merge request? A new commit to the same one?
2020-06-24 02:42:12 <Terror>  Hello71: Fixed it now.
2020-06-24 07:14:26 <ncopa> morning!
2020-06-24 07:14:37 <ncopa> Ariadne: what is the status of go for mips64?
2020-06-24 07:14:59 <Ariadne> the status is
2020-06-24 07:15:14 <Ariadne> the BSP kernel we use on the builder is too old
2020-06-24 07:15:26 <Ariadne> working on getting a new kernel on there somehow
2020-06-24 07:15:38 <Ariadne> otherwise perhaps we can build go package on a different machine
2020-06-24 07:18:51 <ncopa> ok. how do we get a new kernel there?
2020-06-24 09:20:37 <hc-hmk> ncopa: ikke: for some reason 5.4.48 boots flawlessly. I'm not sure what fixed our issue, but it works now.
2020-06-24 09:21:57 <Ariadne> ncopa: the main blocker is that the networking driver is proprietary.  we are reverse engineering it.  almost have a working driver :)
2020-06-24 09:22:24 <ikke> hc-hmk: strange, but good to hear
2020-06-24 09:26:37 <Cogitri> Can we maybe modify the abuild.conf on the builders again? Would be nice if we were to set DFLAGS to something sane to get optimizations for D applications&libraries
2020-06-24 09:27:10 <Cogitri> Just `DFLAGS="-Os"` would do
2020-06-24 09:31:19 <ncopa> Ariadne: would it be possible to ask the authors of the proprietary drivers? if they could either rebase it to newer kernel, or if they could backport the fix for go?
2020-06-24 09:31:46 <Cogitri> Ah also, ncopa: Are you working on the chromium bump already? Otherwise I can take a look today
2020-06-24 09:31:48 <ncopa> or if they could share the sources
2020-06-24 09:32:02 <ncopa> Cogitri: im not working on chromium. please go ahead with it
2020-06-24 09:32:14 <Cogitri> Okie :)
2020-06-24 09:32:32 <ncopa> i have an issue with chromium. it hangs occationally. never had time to investigate, aslo due to i dont have a stable reproducer
2020-06-24 09:35:16 <Cogitri> Ah, I use FF 99% of the time, so not sure about that :)
2020-06-24 09:42:22 <Ariadne> ncopa: i have a backup plan to fix go: run a 5.4 lts kernel on kvm inside the vendor kernel
2020-06-24 09:42:29 <Ariadne> it will be resolved this weekend at latest
2020-06-24 09:42:56 <Ariadne> i have the sources to the vendor kernel
2020-06-24 09:49:33 <ncopa> does the mips64 machine has VT extensions in cpu? for kvm
2020-06-24 09:51:10 <Ariadne> yes
2020-06-24 09:51:22 <Ariadne> i just have to backport the patches to the 4.9 vendor kernel
2020-06-24 09:51:43 <Ariadne> we can boot lts kernel with kvmtool
2020-06-24 10:05:25 <Ariadne> ncopa: anyway, the proprietary driver authors tried to upstream the driver but linux devs rejected it for being substandard.  we are writing a new driver based on theirs which works correctly basically.
2020-06-24 10:06:20 <Ariadne> marvell want $1 million worth of cpu orders to work with them on this stuff, we are not planning on using octeon processors in any products we make ourselves
2020-06-24 11:16:49 <Ganwell> Ariadne: I am working on a programm that creates images and boots qemu-system, hopefully for all archs of alpine. Like this
2020-06-24 11:16:49 <Ganwell> https://gitlab.alpinelinux.org/jeanlf/alpine-now
2020-06-24 11:16:49 <Ganwell> anow build 20200428 x86_64
2020-06-24 11:17:38 <Ariadne> nice
2020-06-24 11:17:38 <Ganwell> sudo anow build 20200428 aarch64
2020-06-24 11:17:38 <Ganwell> ssh -p 2222 user@localhost
2020-06-24 11:17:39 <Ganwell> anow boot 20200428 aarch64
2020-06-24 11:17:52 <Ganwell> Meant for people who have no access to actual hardware.
2020-06-24 11:18:17 <Ariadne> well i have solidrun honeycomb with 64gb ram and a gpu :p
2020-06-24 11:18:55 <Ariadne> audio is kinda poopy tho
2020-06-24 11:19:03 <Ariadne> have to use a usb audio interface for it
2020-06-24 11:20:14 <Ariadne> and mips is dead outside loongson
2020-06-24 11:20:41 <Ariadne> we are playing with doing some loongson stuff, but most of the products we are engineering ourselves are likely to be POWER and ARM based moving forward :p
2020-06-24 11:20:56 <Ganwell> nice! How fast is it compared to raspi 3?
2020-06-24 11:21:11 <Ariadne> honeycomb is 16 cores at 3ghz
2020-06-24 11:21:35 <Ganwell> I can't boot mips64 with alpine-now at the moment, but I didn't research much yet.
2020-06-24 11:21:51 <Ariadne> you need to use -M malta
2020-06-24 11:21:56 <Ariadne> with lts kernel
2020-06-24 11:22:04 <Ariadne> 2GB RAM max :(
2020-06-24 11:26:27 <Ariadne> Ganwell: honeycomb is very comparable performance wise to a threadripper build
2020-06-24 11:26:36 <Ariadne> like, this thing hauls
2020-06-24 11:26:39 <Ariadne> especially on alpine
2020-06-24 11:27:05 <Ariadne> but it's not cheap
2020-06-24 11:27:31 <Ariadne> $750 for the board and cpu, plus you have to use ECC RAM, plus you need a decent GPU
2020-06-24 11:27:33 <Ganwell> The ram constraints are a problem, I was hoping that I don't have to provide swap.
2020-06-24 11:27:57 <Ariadne> yeah in mips world kvmtool is the one most commonly used
2020-06-24 11:27:59 <Ariadne> but kvmtool is pv
2020-06-24 11:28:58 <Ganwell> I hope that. a) on virtual system emulation all alpine packages will build. b) my threadripper compensates the overhead.
2020-06-24 11:29:19 <Ariadne> qemu emulation is hit and miss
2020-06-24 11:29:27 <Ariadne> we bootstrapped mips64 using qemu (:
2020-06-24 11:29:37 <artok> and it took time
2020-06-24 11:29:48 <Ariadne> yeah we missed 3.11 because of it
2020-06-24 11:30:00 <Ariadne> and that was on a POWER9 machine with a shitload of threads
2020-06-24 11:32:31 <mps> 'shitload'?
2020-06-24 11:32:45 <mps> a lot?
2020-06-24 11:37:55 <Ariadne> yeah
2020-06-24 11:37:58 <Ariadne> 192 threads
2020-06-24 11:38:00 <Ariadne> (:
2020-06-24 11:38:37 <mps> aha
2020-06-24 11:38:51 <mps> thanks for teaching me some slang :)
2020-06-24 11:57:09 <Ganwell> Ariadne: Thanks for the hint about -M malta. I still don't get a tty nor vga (or whatever it is)
2020-06-24 11:57:09 <Ganwell> qemu-system-mips64 -M malta -m 512M -smp 16 -serial stdio -monitor null -kernel vmlinuz-lts -initrd initramfs-lts -netdev user,id=alpine_now.0,net=10.0.10.0/24,hostfwd=tcp::22222-:22 -device virtio-net-pci,netdev=alpine_now.0 -drive file=root-lts.img,if=virtio,format=raw --append root=/dev/vda console=ttyS0 rootfstype=ext4 overlaytmpfs=yes
2020-06-24 11:57:34 <Ariadne> use -nographic
2020-06-24 11:57:51 <Ariadne> also, smp is limited too i believe :)
2020-06-24 11:59:21 <Ganwell> the limit is 16. -nographic should be an alias for -serial stdio -monitor null, but I'll test it.
2020-06-24 12:00:53 <Ganwell> No nographic is different. Thanks.
2020-06-24 12:01:28 <Ariadne> Ganwell: also, -cpu MIPS64R2-generic
2020-06-24 12:01:39 <Ariadne> otherwise you'll wind up with R4000
2020-06-24 12:01:43 <Ariadne> which is too old to boot the kernel
2020-06-24 12:01:45 <Ariadne> :)
2020-06-24 12:04:03 <Ganwell> smp was the problem, I set it to one :-(
2020-06-24 12:06:06 <Ariadne> anyway, hoping to have opencfp up this weekend
2020-06-24 12:17:25 <Ganwell> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/JJdHrXoxHqxXSFpyzDIHodcY >

2020-06-24 12:18:04 <Ariadne> that is with MIPS64R2-generic ?
2020-06-24 12:18:40 <Ganwell> qemu-system-mips64 -M malta -cpu MIPS64R2-generic -m 512M -smp 1 -serial stdio -monitor null -kernel vmlinuz-lts -initrd initramfs-lts -netdev user,id=alpine_now.0,net=10.0.10.0/24,hostfwd=tcp::22222-:22 -device virtio-net-pci,netdev=alpine_now.0 -drive file=root-lts.img,index=0,media=disk,format=raw --append root=/dev/sda console=ttyS0 physmap.enabled=0 noapic rootfstype=ext4 overlaytmpfs=yes
2020-06-24 12:18:48 <Ganwell> I added physmap.enabled=0 noapic, which I found somewhere. But it didn't help.
2020-06-24 12:18:58 <Ganwell> yes. MIPS64R2-generic
2020-06-24 12:19:15 <Ariadne> is there an /etc/inittab on the FS?
2020-06-24 12:21:13 <Ganwell> yes. diff root/etc/inittab /etc/inittab its the same as my system. Other archs work.
2020-06-24 12:21:47 <Ganwell> $> file root/bin/busybox
2020-06-24 12:21:47 <Ganwell> root/bin/busybox: ELF 64-bit MSB pie executable, MIPS, MIPS-III version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-mips64-sf.so.1, stripped
2020-06-24 12:21:50 <Ariadne> dunno
2020-06-24 12:22:28 <Ariadne> note that etc/inittab on malta requires enabling ttyS0 console
2020-06-24 12:23:00 <Ariadne> but that is a null deref inside init
2020-06-24 12:36:48 <Ganwell> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/qWkHfvAevQWtJKtEyHwFYTFL >

2020-06-24 13:03:05 <midasi> hello, we are not able to cross compile any package with abuild 3.6.0. It always terminates with the error "Is $builddir set correctly?"
2020-06-24 13:03:44 <midasi> is abuild 3.6.0 known to work in combination with bootstrap.sh cross compilations?
2020-06-24 13:04:54 <Cogitri> midasi: Huh, are you sure that's on abuild? We recently started removing builddir from APKBUILDs when it was the default anyway, but maybe a mistake happened in the meantime
2020-06-24 13:06:41 <midasi> Cogitri: I don't know if it's an abuild issue, but we are able to build the same package properly natively. It only fails with cross compilation
2020-06-24 13:07:35 <midasi> you can reproduce the issue using "bootstrap.sh aarch64". I also opened an issue on abuild's gitlab
2020-06-24 13:09:52 <Cogitri> Yeah, I guess it might not work when pkgname is set differently due to bootstrapping
2020-06-24 13:10:16 <Cogitri> I think we had something similiar reported for crosscompiling binutils a few days agi
2020-06-24 13:10:53 <midasi> my issue was indeed reported for crosscompiling binutils
2020-06-24 13:11:20 <midasi> is there a workaround?
2020-06-24 13:13:00 <Cogitri> dad8b0e8287359738bc9c8fab1f8968bbbb36bbd
2020-06-24 13:13:06 <Cogitri> I guess that wasn't backported to 3.12
2020-06-24 13:13:20 <Ganwell> midasi: use a mini-root-fs?
2020-06-24 13:13:55 <Ganwell> so you don't have to bootstrap...
2020-06-24 13:15:58 <midasi> can I build custom kernels with that?
2020-06-24 13:16:57 <midasi> Cogitri: thanks, I'll try this fix
2020-06-24 13:17:19 <Ganwell> you can cross-compiler the kernel without bootstrapping, not?
2020-06-24 13:19:55 <Ganwell> ah, sorry, wrong distro.
2020-06-24 13:23:04 <Ganwell> midasi: I forgot that there are no cross compiler packages. And the last time a cross compiled I used bootstrap indeed. qemu-user-static or qemu-system would be an alterntive, but they are sloooow.
2020-06-24 13:23:15 <midasi> Cogitri: The patch seems to do the trick, thank you!
2020-06-24 13:24:23 <Cogitri> Great :)
2020-06-24 13:24:31 <Cogitri> Sorry for the breakage, we should backport that to 3.12
2020-06-24 13:24:32 <midasi> Ganwell: yes indeed, that the reason we are still using bootstrap on Alpine... We would love to see an option to cross-compile the kernel without bootstrapping
2020-06-24 13:33:21 <Ariadne> Cogitri: there is other work to fix bootstrap.  i am frustrated that nobody tested bootstrap when removing $builddir
2020-06-24 13:35:05 <midasi> Ariadne: Thanks for mentioning. Are there already patches available?
2020-06-24 13:35:12 <Ariadne> no
2020-06-24 13:35:16 <Ariadne> i am not done cleaning it up yet
2020-06-24 13:35:31 <Ariadne> hohum did some work on it, but we have not completely fixed the damage yet
2020-06-24 13:35:59 <Cogitri> Ariadne: Well, bootstrapping and cross is something only relatively few devs do :/
2020-06-24 13:36:42 <Ariadne> yes, but changing critical behavior in APKBUILDs is something that should have gotten much more testing than it did.
2020-06-24 13:37:25 <Cogitri> Yup, certainly should've received more testing
2020-06-24 13:37:38 <Ariadne> anyway, we are preparing to bootstrap ppc64 (big-endian)
2020-06-24 13:37:47 <Ariadne> so we will clean it up at that time i guess
2020-06-24 13:38:23 <midasi> Cogitri: it would be a simple test which could be automated without much effort. Just run the bootstrap script and check if it ended successfully
2020-06-24 13:39:34 <Cogitri> Would be nice to have that as opt-in pipeline in CI
2020-06-24 13:40:13 <Ariadne> alternatively perhaps just test bootstrap when editing APKBUILDs for the base system and toolchain (:
2020-06-24 13:41:29 <Cogitri> I think most devs (including me) don't have a good grasp of how the bootstrapping works
2020-06-24 13:41:32 <midasi> Ariadne: we ran into the next bootstrap issue: unsatisfiable constraints in gcc-pass2-aarch64. Is that already known and/or fixed?
2020-06-24 13:41:41 <Ariadne> yes :)
2020-06-24 13:41:46 <Ariadne> just use edge :P
2020-06-24 13:42:18 <Ariadne> i am of the opinion that 3.12 is probably just never going to support cross because people broke it
2020-06-24 13:43:24 <midasi> Cogitri: In the past few releases we always had the same problems with bootstrap. The issues were usually fixed by Timo at the end
2020-06-24 13:43:37 <Ariadne> or me
2020-06-24 13:43:49 <Ariadne> i think timo and i are the only people who really care about bootstrap
2020-06-24 13:44:20 <ikke> Care about it and have the knowledge
2020-06-24 13:44:31 <Ariadne> for example, rust should be integrated into bootstrap, but idk how to accomplish that
2020-06-24 13:44:51 <Ariadne> the problem with rust and why rust requires so much trouble is because it is not cross-aware
2020-06-24 13:45:06 <Ganwell> Ariadne:  Maybe at least providing some docker-containers that are bootstrapped?
2020-06-24 13:45:35 <Ariadne> maybe just
2020-06-24 13:45:38 <Ariadne> don't break bootstrap
2020-06-24 13:45:43 <Ariadne> if you have any doubt, run it
2020-06-24 13:45:45 <Ariadne> and see
2020-06-24 13:45:47 <Ariadne> if you broke it
2020-06-24 13:46:12 <Ariadne> or, ask me
2020-06-24 13:46:17 <Ariadne> and i will run it on my power9 machine
2020-06-24 13:46:25 <Ariadne> which will take less time (:
2020-06-24 13:46:26 <Ganwell> That means bootstrap should go into check()?
2020-06-24 13:46:31 <ikke> It starts with being aware what is involved with bootstraping
2020-06-24 13:47:00 <Cogitri> Ariadne: bootrapping rust without binaries means bootstrapping via mrustc and then at least bootstrapping 20 rustcs while slowly going up versions to the final version
2020-06-24 13:47:01 <Cogitri> Which is a massive pain, especially since we still need patches
2020-06-24 13:47:26 <Ariadne> Cogitri: wrong.  you add cross-awareness to rust APKBUILD and use system rust to cross-compile rust for the target
2020-06-24 13:47:45 <Ariadne> we do not need to bootstrap rust using mrustc or whatever
2020-06-24 13:47:49 <Ariadne> we already have rust
2020-06-24 13:48:13 <Ariadne> bootstrap is not about solving the chicken and egg problem, it's about providing a path to enablement using what is available
2020-06-24 13:48:45 <Ariadne> i can tell you how to accomplish that in the APKBUILD, but i do not know the rust side of it
2020-06-24 13:48:50 <Cogitri> Ah, thought you meant bootstrapping from scratch
2020-06-24 13:49:25 <Cogitri> I did the crosscompiling of Rust for Void, that was relatively painless
2020-06-24 13:49:27 <Ariadne> otherwise i would have solved this rust malarkey already (:
2020-06-24 13:49:39 <Ariadne> ok
2020-06-24 13:49:46 <Cogitri> I can look into it in a few weeks
2020-06-24 13:49:48 <Ariadne> so basically in an APKBUILD there is $CARCH and $CTARGET
2020-06-24 13:49:54 <Ganwell> I wanted to backport rust-edge to 3.11 and gave up because of that.
2020-06-24 13:49:56 <Ariadne> i am sure void has similar
2020-06-24 13:50:10 <Ariadne> so i am sure you can map it
2020-06-24 13:50:14 <Ariadne> feel free to ask questions
2020-06-24 13:50:22 <Ariadne> but it would be nice to have rust in bootstrap.sh
2020-06-24 13:50:31 <Ariadne> we have most everything else now
2020-06-24 13:50:39 <Ariadne> just rust and crystal need to be addressed
2020-06-24 13:51:15 <Ariadne> but the thing is
2020-06-24 13:51:21 <Ariadne> and this is what frustrates me.
2020-06-24 13:51:28 <Cogitri> One problem we have is that Rust triplets don't map 1:1 to GCC triplets, so bootstrapping would involve adding a new custom triplet too
2020-06-24 13:51:39 <Ariadne> people have excuses on excuses for breaking bootstrap with builddir removal
2020-06-24 13:51:43 <Ariadne> but heres the thing.
2020-06-24 13:51:49 <Ariadne> if you look at binutils or gcc APKBUILD
2020-06-24 13:51:53 <Ariadne> you will see that in cross mode
2020-06-24 13:51:56 <Ariadne> it changes pkgname
2020-06-24 13:52:18 <Ariadne> and if you see that, you will realize that builddir cannot be removed from that APKBUILD
2020-06-24 13:52:27 <Ariadne> because the calculated one would be wrong
2020-06-24 13:52:49 <Ariadne> this *is* something i would expect an alpine dev with commit rights to be aware of
2020-06-24 13:53:06 <Ariadne> but instead, some sort of automated removal of builddir was done
2020-06-24 13:53:52 <Ariadne> anyway, i know i am beating a dead horse here, but this is not smart development
2020-06-24 13:54:09 <Ariadne> it's round peg goes in square hole and i am going to get a bigger sledgehammer until it "works"
2020-06-24 13:54:19 <Ariadne> and if something broke, oh well
2020-06-24 13:54:54 <Ariadne> so, what i am saying is, don't make excuses
2020-06-24 13:55:13 <Ariadne> let us just work together to ensure that we test bootstrap whenever we make a breaking change to every APKBUILD in the distro
2020-06-24 13:55:23 <Ariadne> that way we fix it then and there
2020-06-24 13:58:31 <Ariadne> ok? :)
2020-06-24 13:58:36 <Ganwell> ah, it took a while understand, builddir is still there, but it gets removed because people try to satisfy the linter.
2020-06-24 13:59:14 <Ariadne> no.  somebody removed it when that policy went into place
2020-06-24 13:59:17 <Ariadne> i had to go readd it
2020-06-24 13:59:23 <Ariadne> because bootstrap path is special
2020-06-24 14:00:08 <Ganwell> binutils now gets a linter error because it uses builddir again?
2020-06-24 14:00:14 <Ariadne> yes
2020-06-24 14:00:56 <Ganwell> so next time, someone not aware of bootstrap touches binutils, it will be removed again.
2020-06-24 14:01:52 <Ariadne> and to be clear i think the linter is great
2020-06-24 14:01:55 <Ariadne> for 99% of cases
2020-06-24 14:02:00 <Ariadne> but for bootstrap
2020-06-24 14:02:11 <Ariadne> it is hurting us
2020-06-24 14:02:12 <ikke> It needs exceptions :)
2020-06-24 14:02:35 <ikke> Or people who know when to ignore the linter
2020-06-24 14:04:17 <Ganwell> or maybe a # noqa
2020-06-24 14:04:18 <Ganwell> builddir="$srcdir/$pkgname-$pkgver"  # noqa
2020-06-24 14:04:21 <Ariadne> i'm more than willing to mark bootstrap APKBUILDs in some way so the linter will ignore them
2020-06-24 14:04:33 <Ariadne> but afaik such does not exist
2020-06-24 14:05:11 <ikke> yet
2020-06-24 14:05:58 <Ariadne> [07:51:28] <Cogitri> One problem we have is that Rust triplets don't map 1:1 to GCC triplets, so bootstrapping would involve adding a new custom triplet too
2020-06-24 14:06:12 <Ganwell> Well, the feedback loop with the linter mainainer is very fast. I had a false-positive and he fixed it on the spot and reran the CI.
2020-06-24 14:06:16 <Ariadne> i noticed patches adding these
2020-06-24 14:06:18 <Ganwell> No thats not true
2020-06-24 14:06:46 <Ariadne> sounds like we need to have an extended discussion about making rust crossable then
2020-06-24 14:06:48 <Ganwell> The CI was still failing, because the new version was going out. But he fixed it immediatly
2020-06-24 14:07:16 <ikke> the aport package needs to be updated and the docker image needs to be regenerated
2020-06-24 14:11:12 <Ariadne> Cogitri: about this rust triplets issue, is it possible, given data about the triplets included with the APKBUILD, to automatically generate the necessary files in the rust source tree?
2020-06-24 14:11:37 <Ariadne> perhaps we should make a bug about this
2020-06-24 14:13:07 <Ganwell> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/mdPsDXFaErUGXOHYlxHYkIel >

2020-06-24 14:13:39 <Ariadne> Ganwell: yes but thats because we patch it
2020-06-24 14:14:01 <Ariadne> Cogitri: created https://gitlab.alpinelinux.org/alpine/aports/-/issues/11683
2020-06-24 14:14:52 <Ganwell> Yes we have to patch it. because x86_64-unknown-linux-musl is broken. It will assume static linking.
2020-06-24 14:15:19 <mps> Ariadne: imo it is not worth hassle to support crystal in bootstrap, at least not yet
2020-06-24 14:15:28 <Cogitri> Ariadne: It might be possible to auto-generated them, but to be honest it's not worth the effort
2020-06-24 14:15:30 <Ganwell> And then the compiler can't emit macro-code, because these go into share-objects.
2020-06-24 14:15:51 <Cogitri> It's easy enough to manually create the triplets and you want to manually verify them anyway
2020-06-24 14:15:55 <Ariadne> Cogitri: whenever you have time if you could elaborate on how void crosses rust in 11683, i'll work on it
2020-06-24 14:16:08 <Ganwell> So x86_64-alpine-linux-musl is correct and valid.
2020-06-24 14:16:15 <Cogitri> Ganwell: You can just do `RUST_FLAGS="-C=target-flags=-static-crt` or something like that
2020-06-24 14:16:18 <Cogitri> Has the same effect
2020-06-24 14:16:33 <Cogitri> Ariadne: Sure, I'll make a writeup in that issue soon
2020-06-24 14:16:38 <Ariadne> great
2020-06-24 14:16:41 <Ganwell> Cogitri: I know thats how I run my wasmer toolchain.
2020-06-24 14:17:36 <Ganwell> Cogitri: But there are packages that refuse building because they think its going to be static even though `RUST_FLAGS="-C=target-flags=-static-crt` was set.
2020-06-24 14:17:55 <Ganwell> It is very annoying
2020-06-24 14:18:33 <Ganwell> I am just lucky that the wasmer toolchain doesn't need any of these crates.
2020-06-24 14:20:12 <Ganwell> Off course one could probably send patches to upstream. I though patching in *-alpine-linux-musl is going to be best thing, so I never bothered.
2020-06-24 14:20:16 <Ariadne> anyway, presently fixing bootstrap again :)
2020-06-24 14:20:35 <Ariadne> latest casualty is musl 1.2 preparation (:
2020-06-24 14:20:58 <midasi> Ariadne: we fixed now several bootstrap issues but are still running into new problems. do you happen to have a list of your fixes so we can backport them to 3.12? And is there already a bug for that?
2020-06-24 14:21:23 <Ariadne> midasi: we (the devs who maintain the bootstrap chain) only support bootstrap for git master
2020-06-24 14:24:15 <midasi> I understand. I'm happy to backport it by myself if you provide me with the changes
2020-06-24 14:26:08 <Ganwell> midasi: maybe diff all the packages that are in bootstrap?
2020-06-24 14:27:14 <midasi> Ganwell: That will be quite a few... I expected to find a bug somewhere with all the fixes linked to it
2020-06-24 14:27:29 <Ariadne> hahahahahahahahaha
2020-06-24 14:27:35 <midasi> :)
2020-06-24 14:27:47 <Ariadne> that is quite optimistic, unfortunately :)
2020-06-24 14:27:47 <midasi> but anyway, we will fix it by ourselves then
2020-06-24 14:38:55 <Ganwell> midasi: Here are all the changes: https://gist.github.com/ganwell/2cc5834968425d52275158d3614e79cd
2020-06-24 14:40:33 <Ganwell> If you can deduce what package is involved it might help.
2020-06-24 14:41:00 <mps> musl stdlib.h don't have qsort_r(3) function. what we (can) use instead of?
2020-06-24 14:42:09 <midasi> Ganwell: great, many thanks!
2020-06-24 14:42:46 <Ariadne> mps: you can probably just use qsort in most cases.  seems useful to add to musl though
2020-06-24 14:43:26 <ikke> https://stackoverflow.com/questions/4300896/how-portable-is-the-re-entrant-qsort-r-function-compared-to-qsort
2020-06-24 14:43:27 <mps> Ariadne: thanks for clarification. I thought to make patch for package
2020-06-24 14:43:35 <Ariadne> dalias: any objection to adding qsort_r?
2020-06-24 14:44:17 <Ganwell> "The qsort_r() function is identical to qsort() except that the comparison function compar takes a third argument. A pointer is passed to the comparison function via arg. In this way, the comparison function does not need to use global variables to pass through arbitrary arguments, and is therefore reentrant and safe to use in threads."
2020-06-24 14:44:36 <Ariadne> libbsd-dev has qsort_r
2020-06-24 14:44:41 <Ariadne> could use that (:
2020-06-24 14:44:44 <ncopa> Ariadne: https://www.openwall.com/lists/musl/2018/09/03/3
2020-06-24 14:46:09 <mps> hmm, looks like bsd and glibc qsort_r(3) are in collision :(
2020-06-24 14:46:18 <Ganwell> "In the mean time, you can always implement a thin wrapper defining qsort_r in terms of qsort, using thread-local storage for the context argument", says dalias.
2020-06-24 14:46:22 <ncopa> Cogitri: did you want me to set DFLAGS=-Os on the edge-builders?
2020-06-24 14:46:50 <Cogitri> Yes, that'd be appreciated
2020-06-24 14:46:58 <Cogitri> Right now we just build D applications without any optimizations
2020-06-24 14:48:48 <ncopa> done
2020-06-24 14:49:11 <Cogitri> Thanks! :)
2020-06-24 14:49:18 <Ariadne> looks like
2020-06-24 14:49:25 <Ariadne> bootstrap right now is mostly healthy in edge
2020-06-24 14:52:09 <Ariadne> i think i should make a "bot" which does bootstrap every day and opens a bug if there is a regression
2020-06-24 14:52:09 <mps> heh, interesting fix for qsort_r issue, just deleted it from source L)
2020-06-24 14:52:17 <mps> :)
2020-06-24 14:52:20 <Ariadne> well
2020-06-24 14:52:25 <mps> https://github.com/Tomas-M/iotop
2020-06-24 14:52:25 <Ariadne> that may or maay not be good
2020-06-24 14:52:44 <Ariadne> if you use bsearch(3) on something not properly sorted you can get infinite loop
2020-06-24 14:53:32 <mps> yes, I thought something like that, but that was just for playing for now
2020-06-24 14:54:50 <mps> anyway noticed linux-edge missing CONFIG_TASKSTATS, CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING so this C version of iotop doesn't work
2020-06-24 14:56:13 <mps> one of these, I mean
2020-06-24 14:57:14 <mps> CONFIG_TASK_IO_ACCOUNTING is missing
2020-06-24 15:01:15 <Ganwell> midasi: I added all the related commits to the gist.
2020-06-24 15:03:29 <Ariadne> theres more
2020-06-24 15:05:39 <midasi> Ganwell: Thanks, we are already analyzing it..
2020-06-24 15:20:24 <Ariadne> ok
2020-06-24 15:20:31 <Ariadne> bootstrap is working again
2020-06-24 15:20:39 <Ariadne> i just bootstrapped ppc64 big-endian with it
2020-06-24 15:22:01 <Ariadne> (why big-endian?  networking and pattern matching is more efficient in most cases)
2020-06-24 15:22:49 <Ganwell> Adran: https://git.io/JfpAe would exiting with an error in main() if -a and --no-network are set be an acceptable fix for that problem?
2020-06-24 15:23:54 <Ganwell> Ariadne: sorry I missclicked the completion
2020-06-24 15:25:04 <Ganwell> and sorry to adran too.
2020-06-24 15:25:46 <midasi> Ariadne: good to know. we still face some issues on 3.12...working on it
2020-06-24 15:26:02 <Ariadne> (well everything but the kernel anyway.  still ponder what our baseline should be for ppc64 big-endian)
2020-06-24 15:26:17 <Ariadne> at $dayjob we will only be supporting POWER9 and later regardless (:
2020-06-24 16:11:14 <Ariadne> Ganwell: incidentally, bootstrap.sh ppc64 only takes 11 minutes on my honeycomb (with modified ppc64le kernel config dropped in)
2020-06-24 16:11:42 <Ariadne> that is the only benchmark that matters (to me anyway)
2020-06-24 16:13:23 <Ganwell> Ariadne: cool.
2020-06-24 16:20:25 <Ganwell> Ariadne: Did you see that one?  https://git.io/JfpAe I found it a while ago and just remembered I wanted to fix it somehow. Its a bit scary if you do that on your workstation.
2020-06-24 16:21:13 <Ganwell> Of course apk recovers perfectly.
2020-06-24 16:26:38 <Ganwell> Ariadne: I will compare your 11 minutes to an emulated run on qemu aarch64. I got a bit distracted by getting mips64 to run.
2020-06-24 16:27:48 <Ariadne> emulation will be much slower than even x86 (:
2020-06-24 16:57:16 <ncopa> would be nice to ahve all edge builders idle tomorrow so we can tag a new edge snapshot release
2020-06-24 16:57:25 <maxice8> ack
2020-06-24 16:57:42 <maxice8> Tomorrow whole day ?
2020-06-24 16:58:00 <ncopa> edge snapshot release are relatively quick
2020-06-24 16:58:11 <maxice8> ok
2020-06-24 16:58:18 <ncopa> what will take time is to fix builds for mips64
2020-06-24 16:58:37 <ncopa> for now its just a question of arch="!mips64" for everythign that fails
2020-06-24 17:14:43 <mps> edge release with musl 1.2.0?
2020-06-24 17:16:15 <ncopa> no! i hope not
2020-06-24 17:16:58 <ncopa> im setting up 3 new builders with musl 1.2
2020-06-24 17:17:02 <mps> hmm
2020-06-24 17:17:05 <ncopa> armhf, armv7 and x86
2020-06-24 17:18:04 <mps> ime, 1.2.0 works fine on aarch64 and armv7 about two weeks
2020-06-24 17:18:23 <ncopa> i would exect that for most packages
2020-06-24 17:18:41 <ncopa> problem is when some of the libraries uses time_t in public headers
2020-06-24 17:18:48 <ncopa> when they update
2020-06-24 17:18:52 <ncopa> things goes south
2020-06-24 17:19:08 <ncopa> so we figured its safest to rebuild world
2020-06-24 17:19:38 <mps> i didn't rebuild much pkgs, but those which i did works fine
2020-06-24 17:19:41 <ncopa> i think im gonna rebuild main and community and maybe even testing (ignoring fails) and then swap the 32bit edge builders
2020-06-24 17:20:52 <mps> this reminds me to rebuild busybox on armv7 to see will it manifest bugs
2020-06-24 21:22:27 <Ganwell> util-linux and kmod don't install bash-completion in bootstrap, so the bashcomp submodule fails. I removed it locally.
2020-06-24 21:29:40 <dalias> why is bashcomp in there at all?
2020-06-24 21:34:35 <IamStefan> Hi, why there is no spice-vdagent available in alpine?
2020-06-24 21:47:07 <Hello71> it's nice to have modprobe tab completion
2020-06-24 21:48:15 <Hello71> and util-linux has a bunch of weird stuff like cal and column
2020-06-24 22:27:54 <dalias> but i hate hate hate bash-completion and it shouldn't be installed by default anywhere
2020-06-24 22:28:22 <dalias> why? well aside from lots of nasty least-surprise violations and slowness/bloat..
2020-06-24 22:28:27 <dalias> it breaks tab completion in any dir with a makefile
2020-06-24 22:28:41 <dalias> because it will only tab complete make commands to targets it finds explicitly in the makefile
2020-06-24 22:28:45 <dalias> but all my targets are implciti
2020-06-24 22:47:43 <Terror> Hi team
2020-06-24 22:47:54 <Terror> Can anyone merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9085?commit_id=04009196b24e67b96f909d003e5377ddd3130161 please?
2020-06-24 22:57:21 <Hello71> dalias: I think it isn't though?
2020-06-24 22:57:48 <Hello71> although it might be attached to bash-completion
2020-06-24 22:58:16 <Hello71> pretty sure it's not install_if=bash
2020-06-25 04:00:53 <Terror> Hi there, I've addressed all the comments on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9085, do you think you can merge it?
2020-06-25 05:49:10 <craftyguy> what does the 'p' refer to here? https://git.alpinelinux.org/apk-tools/tree/src/version.c#n74
2020-06-25 05:49:31 <ikke> patch
2020-06-25 05:49:57 <craftyguy> ah, thanks!
2020-06-25 05:59:36 <craftyguy> I'm really confused why using a variable after '_p' in pkgver doesn't work here: https://bpa.st/EZFQ
2020-06-25 05:59:59 <craftyguy> but if I replace ${_purismrel} with, for example, a single digit like '2', it works
2020-06-25 06:01:44 <Ganwell> dalias: bootstrap builds util-linux, kmod and during build it tries to build the bash-completion-subpackage. So with "install" I meant install during build into the pkg-directory.  So the bash-completion wont install onto your system.
2020-06-25 06:03:48 <[[sroracle]]> gl.a.o seems slower than usual
2020-06-25 06:11:44 <craftyguy> weird, if I use '_p${pkgrel}', it works
2020-06-25 06:23:51 <craftyguy> wtf
2020-06-25 06:39:28 <craftyguy> seems like some variables (including non-builtin) can be used in pkgver= but not all. some just fail, even if they are the same value
2020-06-25 06:40:04 <craftyguy> e.g. this works: pkgver=${_kernver}_p${_kernver}
2020-06-25 06:40:30 <craftyguy> but this doesn't: pkgver=${_purismrel}
2020-06-25 06:40:59 <craftyguy> where _purismrel could even be the same value as _kernver, but still fails
2020-06-25 06:44:07 <afontain_> Is _purismrel defined *above* pkgver?
2020-06-25 06:45:30 <afontain_> and without any typo?
2020-06-25 06:48:05 <craftyguy> yes
2020-06-25 06:52:26 <afontain_> I'd try to add an echo $pkgrel to see what you are talking about
2020-06-25 06:52:51 <afontain_> What does it give?
2020-06-25 06:53:52 <ikke> [[sroracle]]: seems fine here
2020-06-25 06:54:51 <[[sroracle]]> i think it is ok now, just a transient issue
2020-06-25 06:54:57 <ikke> ok
2020-06-25 06:58:02 <craftyguy> afontain_: derp. I think the problem is not related to apk-tools
2020-06-25 07:03:14 <ikke> APKBUILDS are just shell scripts, even as abuild itself is, so what variable you put in there should not matter at all
2020-06-25 07:04:19 <craftyguy> ikke: yeah, I figured out the issue. it has nothing to do with APKBUILDs or apk-tools/abuild
2020-06-25 07:04:23 <ikke> nod
2020-06-25 07:05:01 <craftyguy> I'm using pmbootstrap from postmarketos, and pmb 'validates' pkgver. it fails in that validation since the variable isn't being evaluated or something :/
2020-06-25 07:05:04 <craftyguy> sorry for the noise
2020-06-25 07:13:44 <Cogitri> ncopa: Can you merge Chromium (!9561) after you've tagged the new edge snapshot? Not sure when you wanted to do that and didn't want to block the builders with it
2020-06-25 08:46:17 <ncopa> Cogitri: ok. seems like mips64 has a lot to catch up in testing repo
2020-06-25 08:48:01 <ikke> lots of go packages are blocking it
2020-06-25 08:48:20 <ikke> blocky is the latest one
2020-06-25 08:49:40 <Cogitri> Yeah, it's hard to test things on mips without CI or a test runner :/
2020-06-25 08:50:07 <ikke> And the funy part is that go is required for that in the first place
2020-06-25 08:52:08 <ncopa> i think openrc's supervise-daemon may be wrongly designed
2020-06-25 08:52:42 <Cogitri> How come?
2020-06-25 08:56:13 <ncopa> i think that after fork(), you may only do async-safe calls, or you may end up with deadlock and similar
2020-06-25 08:56:43 <ncopa> looking at the openrc code, it looks like they do some "unsafe" things after the fork
2020-06-25 08:57:21 <ncopa> they have(had) same issue with glib: https://gitlab.gnome.org/GNOME/glib/-/issues/2140
2020-06-25 09:00:14 <Cogitri> Oh :/
2020-06-25 09:17:45 <ncopa> not sure it matters in practice. would be nice if either fabled or dalias had a quick look at it. It looks like they do both malloc (https://github.com/OpenRC/openrc/blob/master/src/rc/supervise-daemon.c#L400) and getenv, after fork() but before exec()
2020-06-25 09:18:24 <Ariadne> supervise-daemon doesnt need to malloc anyway
2020-06-25 09:18:30 <Ariadne> i can rewrite it to not
2020-06-25 09:19:36 <ikke> Just allocate everything on the stack?
2020-06-25 09:22:14 <Cogitri> As long as we don't overflow the stack, sure
2020-06-25 09:26:29 <PureTryOut[m]> Is https://wiki.alpinelinux.org/wiki/APKBUILD_examples:JavaScript still the recommended way to package JavaScript stuff? Running `npm install` in the `build()` function will require network access which seems bad
2020-06-25 09:26:40 <PureTryOut[m]> And I assume the npm commans can just be replaced for `yarn` when required?
2020-06-25 09:26:44 <PureTryOut[m]> *commands
2020-06-25 09:27:38 <ikke> PureTryOut[m]: The alternative would be packaging all those dependencies and keeping them up-to-date (not to speak about all the conflicts that are bound to happen)
2020-06-25 09:27:55 <PureTryOut[m]> You can just put all the deps into an archive and use that no?
2020-06-25 09:28:17 <ikke> Where do you host this archive?
2020-06-25 09:28:54 <ikke> basically custom vendoring
2020-06-25 09:29:19 <ikke> projects like go and rust also have this issue
2020-06-25 09:30:19 <PureTryOut[m]> Yeah, really annoying...
2020-06-25 09:30:45 <PureTryOut[m]> Ok will use `yarn install` for now. But hopefully something can be done about it in the future, especially when we want reproducable packages
2020-06-25 09:31:56 <ikke> iirc yarn/npm store the hash of the dependencies, so the build should be reproducable
2020-06-25 09:32:05 <PureTryOut[m]> Also, shouldn't `npm install` be run in the prepare function rather than build?
2020-06-25 09:34:02 <Cogitri> Why would it? Install will download, build and install everything to the node_modules folder, no?
2020-06-25 09:34:37 <Cogitri> And with Rust and Go it's at least not as big of a problem due to static linking (so only the parts of the lib that are required end up in the final binary)
2020-06-25 09:38:31 <PureTryOut[m]> I don't know npm well enough but `install` to me sounds like installing deps. Guess not
2020-06-25 09:39:03 <PureTryOut[m]> Right now I'm trying to package an application that has both a Rust part (backend) and a Javascript part (web frontend) so it's a mess anyway lol
2020-06-25 09:39:13 <Cogitri> I think it's more like "install the package including all deps"
2020-06-25 09:39:25 <ikke> just like go build
2020-06-25 09:39:27 <Cogitri> But I don't know npm well either (lucky me :D)
2020-06-25 09:39:40 <ikke> most of these new package managers just do everything in one step
2020-06-25 09:39:53 <PureTryOut[m]> What about `yarn install --pure-lockfile`? Would that just download the deps?
2020-06-25 09:47:19 <nmeum> this dependency vendoring of modern language package managers really is annoying from a downstream perspective
2020-06-25 09:47:57 <nmeum> recently looked into the alacritty apkbuild and it fetches a bunch of dependency using cargo which we can't track and can't update if bugs occur in them
2020-06-25 09:48:17 <Cogitri> What's really fun is when libgit2 breaks soname&API again
2020-06-25 09:48:32 <Cogitri> Because then we have to patch each Rust package that pulls in libgit2-sys
2020-06-25 09:48:53 <Cogitri> Either to use the newest available libgit2-sys version (once that is released) or to use static libgit2
2020-06-25 09:49:17 <nmeum> urgs, that sounds awful
2020-06-25 09:49:34 <Cogitri> So yeah, from a distro perspective language package managers aren't fun, but I guess devs love them for a reason
2020-06-25 09:49:52 <mps> world of 'feature first'
2020-06-25 09:49:55 <Cogitri> Because adding deps of any version via one line in a TOML file sure is comfortable
2020-06-25 09:50:01 <PureTryOut[m]> Cogitri: btw for some reason the Cargo template from newapkbuild causes abuild to compile the Rust binary 2 times, in both `build()` and `package()`
2020-06-25 09:50:13 <Cogitri> Hum, that's not good
2020-06-25 09:50:23 <Cogitri> I guess we should use install instead of cargo install then?
2020-06-25 09:50:59 <PureTryOut[m]> In this case it would work as there is only one resulting binary, but I'm not sure if that's easy to do with other packages
2020-06-25 10:20:25 <mps> 'musl' announced 1.2.1 soon, with new malloc implementation
2020-06-25 10:21:21 <Cogitri> Neat
2020-06-25 10:40:16 <mps> ncopa: do you still need builders to be idle
2020-06-25 10:40:26 <ikke> mips is still blocked
2020-06-25 10:46:35 <mps> ikke: so we still shouldn't merge/push
2020-06-25 10:48:09 <ikke> the snapshot hasn't been made yet
2020-06-25 10:49:23 <mps> so, to push or not push, question is :)
2020-06-25 10:49:42 <mps> not to*
2020-06-25 10:52:12 <ikke> It's at 8% atm
2020-06-25 10:52:35 <mps> ok, I will wait
2020-06-25 10:59:47 <ikke> ncopa: babeltrace as test errors
2020-06-25 11:00:08 <ikke> has*
2020-06-25 11:17:42 <ncopa> to create an edge snapshot release, yes, the builders needs to be idle
2020-06-25 11:17:50 <ncopa> does not look like we will manage to do that today
2020-06-25 11:18:03 <ncopa> so it will be a friday release, again.... :D
2020-06-25 11:18:13 <mps> :)
2020-06-25 11:20:22 <Cogitri> So I can go ahead and merge Chromium? :)
2020-06-25 11:21:07 <mps> huh, so builder will not be idle again ;p
2020-06-25 11:22:12 <mps> let me finish crystal tools
2020-06-25 11:26:31 <mps> ok, finished, two not big pkgs, which don't require much time
2020-06-25 11:35:34 <nmeum> Cogitri: are you sure that it will be finished by friday? :D
2020-06-25 11:44:08 <ncopa> Cogitri: yeah
2020-06-25 12:16:23 <nmeum> PureTryOut[m]: would you mind if I move testing/nototools to community/? would allow me to move testing/font-noto-emoji to community/ as well
2020-06-25 12:16:57 <nmeum> (decided not to use the prebuilt fonts and therefore still need it as a compile-time dependency)
2020-06-25 12:18:17 <PureTryOut[m]> nmeum: no problem, gladly even
2020-06-25 12:20:05 <nmeum> ok, neat. thanks! will move it later on then :)
2020-06-25 12:26:26 <dalias> ncopa, yes that openrc code is bogus if it csn have threads
2020-06-25 12:26:55 <dalias> it doesnt need to alloc just efut environ in-place ...
2020-06-25 12:27:17 <dalias> the pam stuff is probably all wrong & hopeless
2020-06-25 12:28:47 <ikke> mips is now at 11% :D
2020-06-25 12:33:18 <Cogitri> nmeum: let's hope it finishes in time :D
2020-06-25 12:33:30 <Cogitri> Took a solid 12 hours to build on my VPS
2020-06-25 12:34:24 <ikke> (⊙.⊙)
2020-06-25 12:40:35 <mps> that's time FF took on my arm box 4GB ram and FS on sdcard when I managed to build it first time on alpine
2020-06-25 12:41:02 <mps> 10 hours, iirc
2020-06-25 12:43:41 <PureTryOut[m]> (mips failed btw)
2020-06-25 12:43:56 <ikke> another go dependency
2020-06-25 12:47:35 <dalias> ncopa, AIUI the pam code paths are not used on alpine so i think you can punt on fixing that
2020-06-25 12:48:13 <dalias> and do something like
2020-06-25 12:49:03 <dalias> for (i=j=0; environ[j]; j++) if (!pred(environ[j]) environ[i++] = environ[j];
2020-06-25 12:50:02 <dalias> it's reflects somewhat poorly on openrc that they did some awful malloc'd data structure to implement such a trivial thing, ntm that they didn't check for malloc failure
2020-06-25 13:06:35 <ncopa> dalias: i dont think openrc use threads
2020-06-25 13:20:47 <mps> dalias: would you give me advice what to do with upstream source which have qsort_r
2020-06-25 14:14:55 <dalias> mps, we should probably implement it, but until then you can make a version wrapping qsort using TLS..
2020-06-25 15:55:20 <maxice8> libgme is failing on mips64, Can't figure out the endianess
2020-06-25 15:55:35 <maxice8> It uses a maze of cpp ifs and defs to figure it out
2020-06-25 15:55:44 <maxice8> gme/blargg_endian.h
2020-06-25 15:56:43 <ikke> If it's not easy to fix, just disable it
2020-06-25 15:57:10 <ikke> nothing seems to depend on it
2020-06-25 15:57:50 <ikke> maxice8: are you fixing it?
2020-06-25 15:58:04 <maxice8> I have no clue how to fix it
2020-06-25 15:58:07 <ikke> ok
2020-06-25 15:58:09 <maxice8> I can disable it in the meantime
2020-06-25 15:58:14 <ikke> I'm already on it
2020-06-25 15:58:37 <maxice8> Also remove CMAKE_INSTALL_LIBDIR, It is an unused option according to the logs
2020-06-25 15:58:49 <maxice8> https://build.alpinelinux.org/buildlogs/build-edge-mips64/testing/libgme/libgme-0.6.2-r0.log
2020-06-25 16:00:42 <ikke> done
2020-06-25 16:02:15 <maxice8> nice
2020-06-25 16:06:33 <mps> dalias: thanks for explanation. though my experience is not enough to make it TLS :(
2020-06-25 16:07:32 <mps> especially S in TLS
2020-06-25 16:10:20 <maxice8> I think he is talking about Thread-local storage
2020-06-25 16:10:49 <mps> hm, and not Thread Level Safe?
2020-06-25 16:12:08 <mps> at the end, same :)
2020-06-25 19:29:14 <mps> maxice8: right, thread-local storage
2020-06-25 19:29:49 <mps> here is one https://groups.google.com/forum/#!topic/osv-dev/csfKS5z6MUo
2020-06-25 19:30:01 <mps> and dalias is mentioned in patch
2020-06-25 19:34:52 <dalias> thats not a wrappee but complete code dupl
2020-06-25 19:34:56 <mps> and here is old bug report about alpine https://github.com/matz/streem/issues/158
2020-06-25 19:35:44 <mps> and old PR for musl https://github.com/esmil/musl/commit/194f9cf93da8ae62491b7386edf481ea8565ae4e
2020-06-25 19:36:01 <mps> dalias: yes, I see it implementation
2020-06-25 19:36:09 <mps> it is*
2020-06-25 19:36:28 <dalias> i can demo a poc wrapper
2020-06-25 19:37:41 <mps> it is not needed for me, except if you like to make it
2020-06-25 19:38:34 <mps> I don't want to impede you on more important work, i.e. musl 1.2.1
2020-06-25 19:48:01 <dalias> :)
2020-06-25 20:34:17 <Terror> Hi there, I've addressed all the comments on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9085, do you think you can merge it?
2020-06-25 20:36:36 <ikke> Terror: The code looks good, just one last thing: can you rebase the commits? This can be just a single commit with the same title as the MR
2020-06-25 20:37:27 <ikke> I think you overwrote the original commit message earlier
2020-06-25 20:38:35 <Hello71> does it need to have "static" subpackage?
2020-06-25 20:38:56 <ikke> abuild probably warned about it
2020-06-25 20:39:09 <ikke> The alternative would be disabling statitc
2020-06-25 20:40:02 <Terror> I can do both, yes.
2020-06-25 20:40:21 <Terror> abuild didn't warn about anything actually
2020-06-25 20:40:42 <ikke> ah ok
2020-06-25 20:41:20 <ikke> Terror: once that's addressed, I'll merge it
2020-06-25 20:41:32 <Terror> It might have complained about it NOT having a -static package? It's been a while and I honestly can't remember
2020-06-25 20:42:33 <ikke> yes, that's what I meant
2020-06-25 20:42:57 <ikke> if there are static libraries, it warns about them not being in a -static subpackage
2020-06-25 20:45:09 <Terror> Sorry, it's early in the morning down here.
2020-06-25 20:45:21 <ikke> It's getting late here :)
2020-06-25 20:46:03 <Terror> Is there any issue with bundling the -static libs? It might be useful for someone
2020-06-25 20:46:26 <ikke> No, should not be a problem
2020-06-25 20:46:42 <ikke> It's in a static subpackage anyway
2020-06-25 20:46:42 <Terror> Also seems internet bandwidth today is not great here: Receiving objects:  77% (466733/601198), 93.44 MiB | 59.00 KiB/s
2020-06-25 20:49:41 <mps> my pet peeve is -static libs :)
2020-06-25 20:49:52 <ikke> mps: I was expecting you to jump in
2020-06-25 20:50:01 <mps> :D
2020-06-25 20:50:08 <Terror> So I only have to rebase. Any magic git command to do that?
2020-06-25 20:50:23 <ikke> Terror: You need to fixup the two commits into one
2020-06-25 20:51:00 <artok> git rebase -i <commit_to>
2020-06-25 20:51:14 <ikke> git rebase -i master mdnsd
2020-06-25 20:51:30 <artok> ..or that ofcoz
2020-06-25 20:51:45 <artok> not the form I've used
2020-06-25 20:51:58 <Terror> That looks easy!
2020-06-25 20:52:11 <ikke> then on the first line, you change pick to reword
2020-06-25 20:52:14 <Terror> I'm a white belt at git
2020-06-25 20:52:18 <ikke> and the 2nd line you change to fixup
2020-06-25 20:53:39 <ikke> if you get more or less than 2 lines, something is going wrong :)
2020-06-25 20:54:01 <Terror> Will do that once my 14.4 kbps modem finishes cloning
2020-06-25 20:56:07 <Terror> Thank you team!
2020-06-25 20:56:52 <Terror> Is there any threshold for including a package? I wrote a little utility that use quite a bit and could easily package it for anyone to use.
2020-06-25 20:57:33 <Terror> It a single binary that's like uniq but works on unsorted input via a sliding window and hashing.
2020-06-25 20:57:37 <ikke> We're quite acceptive of packages, as long as they are open source and maintained
2020-06-25 20:57:51 <Terror> So constant memory use instead of the usual AWK unbounded arrays
2020-06-25 20:58:41 <Terror> It is open source and maintained (though that's a big word since it is feature complete so nothing to maintain except for keeping up to date with xxhash lib every now and then)
2020-06-25 20:59:01 <Terror> I'll build an APK then
2020-06-25 20:59:41 <ikke> yeah, we don't expect an update every month :)
2020-06-25 21:03:05 <dalias> :)
2020-06-25 21:03:16 <Terror> Still cloning...
2020-06-25 21:03:33 <Terror> Is there a package that adds dialup sounds to git?
2020-06-25 21:03:38 <ikke> haha :D
2020-06-25 21:11:04 <dalias> :-p
2020-06-25 21:26:16 <Terror> 98%, almost there now
2020-06-25 21:31:13 <mps> Terror: 14.4 kbps, you live in some rural part?
2020-06-25 21:31:38 <mps> or far mountains
2020-06-25 21:31:58 <dalias> GPRS :-p
2020-06-25 21:32:07 <Terror> The bloody capital of NZ
2020-06-25 21:32:17 <Terror> Corporate network connection
2020-06-25 21:32:22 <mps> uh
2020-06-25 21:32:42 <Terror> I should just vpn home, but haven't set up wireguard yet
2020-06-25 21:49:50 <Terror> OK, done the rebase now but it's refusing to push. Says the branch is up to date, even with -f
2020-06-25 21:59:56 <Terror> OK, I think it's done now
2020-06-25 22:42:10 <Terror> Also just uploaded a new aport (swuniq) https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9622
2020-06-25 22:54:46 <mps> Terror: would be good to add comment after options=!check why it is disabled, and it should be actually: options="!check"
2020-06-25 22:54:58 <mps> double quotes around
2020-06-25 22:55:29 <mps> also, isn't pkgdesc to long
2020-06-25 23:03:23 <Terror> Sure. Noticed ppc64 has no -march support, should I just remove all compile options from make? What's the consensus for Alpine?
2020-06-25 23:05:23 <Terror> Same with optimisation levels, do we do O2? O3? Os?
2020-06-25 23:05:47 <mps> there is no consensus
2020-06-25 23:05:50 <Hello71> -march=native -mtune=native doesn't work on most non-x86 archs, and is useless on x86
2020-06-25 23:06:32 <Terror> I'll just `cc swuniq.c` and be done with it then :)
2020-06-25 23:06:36 <mps> and, imo -02 only makes sense
2020-06-25 23:06:50 <Hello71> but in general this makefile is very broken
2020-06-25 23:06:55 <artok> -O2 ?
2020-06-25 23:07:14 <mps> but you don't need to specify it, let default to do whatever it is
2020-06-25 23:07:19 <Hello71> vpath is abused for targets, swuniq target is dumped into all, doesn't respect prefix...
2020-06-25 23:07:26 <Terror> I'll just ignore the makefile
2020-06-25 23:07:30 <Hello71> not to mention as we are already discussing *FLAGS
2020-06-26 00:18:12 <Terror> All done (not sure if the "squash" thing I did is what you expect though)
2020-06-26 04:43:32 <ikke> ncopa: mips edge is idle :)
2020-06-26 05:24:50 <ncopa> morning!
2020-06-26 05:24:53 <ncopa> wonderful!
2020-06-26 05:28:06 <ncopa> ugh. new kernel
2020-06-26 05:28:12 <ncopa> maybe should bump kernel first
2020-06-26 05:45:04 <mps> ah, I forgot to mention new kernel yesterdat
2020-06-26 06:18:21 <mps> interesting, LKRG got preliminary ARM32 support
2020-06-26 06:18:58 <ikke> LKRG?
2020-06-26 06:19:16 <mps> https://www.openwall.com/lists/announce/2020/06/25/1
2020-06-26 06:19:44 <mps> sorry, this is news, here it is https://www.openwall.com/lkrg/
2020-06-26 06:19:56 <ikke> Yeah, found the link there
2020-06-26 06:37:26 <hc-hmk> I'm having difficulties finding out what will happen to linux-lts@edge. Since it's separate from linux-edge@testing and called lts, I'd assume that it won't receive feature updates. Is this correct?
2020-06-26 06:38:30 <mps> linux-lts is actually mainline LTS (Long Term Stable) kernel
2020-06-26 06:39:23 <mps> it is updated regularly, following upstream releases
2020-06-26 06:39:27 <hc-hmk> It's either mainline or LTS, and kernel.org has several versions called LTS.
2020-06-26 06:39:39 <Cogitri> hc-hmk: The edge one follows the latest LTS version
2020-06-26 06:39:43 <mps> ok, latest LTS
2020-06-26 06:40:00 <Cogitri> So once the next LTS version is released edge will upgrade while 3.12 will stay on 5.4
2020-06-26 06:40:23 <hc-hmk> Great, thanks. I was afraid it'd get bumped to 5.7 at some point without notice.
2020-06-26 06:40:31 <mps> linux-edge is not officially supported
2020-06-26 06:40:56 <hc-hmk> Thanks guys
2020-06-26 06:41:02 <Cogitri> 👍
2020-06-26 06:49:21 <mps> why the irc clients are in main and not community
2020-06-26 06:54:46 <ncopa> my guess is that they were introduced before community existed and nobody cared enough to move them to community (yet)
2020-06-26 06:59:14 <mps> aha, so we can start looking at some and creating MRs or issues
2020-06-26 06:59:21 <Cogitri> Can we push 3.12 things? Would be nice to get the Chromium upgrade on 3.12 too
2020-06-26 06:59:45 <ncopa> yeah, 3.12 should be ok to push
2020-06-26 07:00:09 <mps> also, we 'some numbers' of outdated or unmaintained pkgs
2020-06-26 07:00:21 <mps> we have*
2020-06-26 07:00:47 <mps> snort, ejabberd for example
2020-06-26 07:03:53 <Cogitri> ncopa: Okie, will push chromium then, thanks
2020-06-26 07:55:50 <hc-hmk> apk wont tell me if linux-firmware-none conflicts with linux-firmware-intel. It's listed under "sub packages" on pkgs.alpinelinux.org, which I think means that it doesn't provide linux-firmware-intel, but I'm free to install it on top. Is this correct?
2020-06-26 08:01:10 <Cogitri> The purpose of linux-firmware-none is to satisfy the linux-firmware dep so that the other firmware packages are purged when you don't need them
2020-06-26 08:01:19 <Cogitri> (since linux-lts pulls in linux-firmware)
2020-06-26 08:02:43 <hc-hmk> Yeah, I thought I'd abuse the fact that it satisfies all deps to just install the ones we need. We need 4 out of the 86 packages pulled by linux-firmware.
2020-06-26 08:04:48 <hc-hmk> All the firmwares combined weighs almost half a gigabyte, which is quite a lot on a small embedded thing
2020-06-26 08:05:17 <Cogitri> Hm, I think installing any of the subpackages should satisfy the dep and as such purge the other packages
2020-06-26 08:06:23 <Cogitri> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/linux-firmware/APKBUILD#L131
2020-06-26 08:10:51 <hc-hmk> Oh wow, what an oversight. We have linux-firmware linux-firmware-intel linux-fir...... as our required packages for bootstrapping. Simply removing linux-firmware should reduce the size of our images by half. Thanks man.
2020-06-26 08:11:29 <Cogitri> 👍
2020-06-26 08:26:20 <Ariadne> hc-hmk: linux-edge is basically a testing kernel so we can keep up on new features to determine what should go into the next LTS branch kernel
2020-06-26 08:59:12 <mps> Ariadne: yes, it is for testing, but also for normal usage. I use it on two armv7 servers and x86_64 workstation
2020-06-26 09:00:13 <mps> it is quite stable and faster than linux-lts
2020-06-26 09:08:49 <mps> btw, just read on debian-arm ML that someone boot quite fine kernel 5.7.6 on RPi4
2020-06-26 09:09:20 <mps> and looking on .config file :)
2020-06-26 09:09:55 <mps> will try to merge needed config options for next linux-edge upgrade
2020-06-26 09:10:45 <clandmeter> mps: nice
2020-06-26 09:11:23 <clandmeter> but is it a replacement?
2020-06-26 09:11:46 <Ariadne> no
2020-06-26 09:12:21 <mps> iiuc, most drivers upstreamed from rpi kernels
2020-06-26 09:12:34 <clandmeter> is there some info what is still missing in mainline?
2020-06-26 09:13:35 <mps> I didn't found, though I didn't searched
2020-06-26 09:13:53 <clandmeter> but it does support GPU acceleration?
2020-06-26 09:14:14 <mps> not sure
2020-06-26 09:14:25 <mps> I don't have RPi4
2020-06-26 09:16:04 <artok> there is 5.7 branch on rpi foundation still
2020-06-26 09:16:14 <artok> could check slightly the diff
2020-06-26 09:16:33 <artok> or actually "now they also got into 5.7,"
2020-06-26 09:18:17 <mps> most SOC vendors have their 'branch/forks' from which they upstream changes
2020-06-26 09:18:57 <mps> sunxi for example upstreamed most of things and its SOCs works fine with mainline
2020-06-26 09:19:10 <mps> rockchip also
2020-06-26 09:20:35 <artok> but raspbi foundation is slightly different thing
2020-06-26 09:20:39 <artok> bastards
2020-06-26 09:20:40 <artok> =)
2020-06-26 09:24:15 <artok> would be great to get vpu code
2020-06-26 09:30:02 <mps> most of GPU vendors are *that*
2020-06-26 10:25:56 <hc-hmk> I'm not sure what Milan P. Stanićs handle is but it'd just like to report that can-utils@testing works great so far. We haven't noticed any stability issues yet.
2020-06-26 10:26:47 <ikke> mps :)
2020-06-26 10:28:32 <hc-hmk> Oh, that's kinda obvious now that you mention it. @mps
2020-06-26 11:26:26 <mps> hc-hmk: thanks for info. I will move it to community
2020-06-26 14:58:42 <maxice8> How are the builders going ?
2020-06-26 15:17:29 <mps> looks like they are idle
2020-06-26 15:30:29 <maxice8> Yeah but i was asked to not push today
2020-06-26 15:30:32 <ikke> yes, the snapshot has been made and releases have been uploaded
2020-06-26 15:30:56 <ikke> that was 6h ago
2020-06-26 15:31:07 <maxice8> Ah good
2020-06-26 15:31:10 <maxice8> so i can push ?
2020-06-26 15:31:12 <ikke> yes
2020-06-26 15:31:16 <maxice8> yay
2020-06-26 15:33:13 <ikke> We've updated the remotes on the builders as well, so they should not be off-by-one anymore
2020-06-26 17:18:18 <maxice8> @Ikke Please make public https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9632
2020-06-26 17:21:57 <ikke> all are public now
2020-06-26 17:22:05 <maxice8> ty
2020-06-26 17:31:28 <ikke> fyi, anything that depends on go will fail on mips, so please keep an eye on upgrades / new packages
2020-06-26 17:31:51 <maxice8> ight
2020-06-26 17:35:29 <tsarna> Hi, my PR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9452 has been stuck for a bit, I think because it still has status:mr-waiting-maintainer-feedback even though the maintainer replied
2020-06-26 19:29:19 <ikke> fyi, we are going to upgrade gitlab, but also do a system upgrade, so it will be down a little longer
2020-06-26 19:29:36 <maxice8> Good luck
2020-06-26 19:47:17 <ikke> Everything is up and running again
2020-06-26 19:47:30 <maxice8> Good work
2020-06-26 21:50:35 <nmeum> whooo finally a new busybox release
2020-06-26 21:50:39 <nmeum> will look into upgrading shortly
2020-06-26 21:57:51 <dalias> yay
2020-06-26 22:14:16 <nmeum> new busybox also has built-in support for linking wget against openssl, not sure if we want to use that to replace our ssl_client.c based setup
2020-06-26 22:14:43 <mps> nice news, it will work with musl 1.2.x
2020-06-26 22:15:04 <mps> and grep will be better
2020-06-26 22:15:33 <mps> nmeum: please look at changes for grep
2020-06-26 22:15:56 <nmeum> hm?
2020-06-26 22:16:18 <mps> grep in busybox, not gnu grep :)
2020-06-26 22:16:41 <nmeum> my busybox grep pattern_list patch is included with 1.32.0 :3
2020-06-26 22:16:57 <nmeum> > grep: Fix -f FILE when FILE is empty and -x provided
2020-06-26 22:16:58 <nmeum> > grep: add proper support for pattern_list
2020-06-26 22:17:05 <nmeum> these are the two changes mentioned in the release notes
2020-06-26 22:17:10 <mps> ah, that was you \o/
2020-06-26 22:17:22 <nmeum> yes
2020-06-26 22:17:26 <nmeum> the pattern_list thing
2020-06-26 22:17:31 <nmeum> but that was backported before anyhow
2020-06-26 22:17:43 <mps> nice, missed your name when looked at changes
2020-06-26 22:19:12 <mps> (to my excuse, I never look at names when reading changes)
2020-06-26 22:19:43 <ikke> nginx has test failures on mips
2020-06-26 22:28:33 <nmeum> rebased patches and updated configs seems to build fine
2020-06-26 22:31:56 <nmeum> !9659 will continue working on it tomorrow
2020-06-26 22:35:33 <mps> I meant this 'Tomi Leppanen: grep: add -R'
2020-06-26 22:36:16 <nmeum> ah
2020-06-26 22:36:57 <mps> other interesting things related to time 2038 issues are here http://lists.busybox.net/pipermail/busybox/2020-March/087843.html
2020-06-26 22:40:26 <mps> good MR, passed on 32bit arches :)
2020-06-26 22:40:46 <mps> all, actually
2020-06-26 22:41:27 <nmeum> (:
2020-06-26 23:00:13 <dalias> :-)
2020-06-27 05:47:49 <mps> I'm thinking to add more ACPI events handlers for busybox acpid applet
2020-06-27 05:49:24 <mps> not sure will these be accepted for alpine or upstream, so thinking about making quick-and-dirty patch/es or nice ones
2020-06-27 05:49:33 <dalias> mps, you can add custom ones with a config file
2020-06-27 05:49:44 <dalias> at least for input events
2020-06-27 05:49:50 <dalias> do you need something else?
2020-06-27 05:51:10 <mps> dalias: well, I'm thinking about 'generic' patch to have it as pattern for new events
2020-06-27 05:51:45 <mps> end add them when they needed, something like st term patches
2020-06-27 05:52:11 <mps> s/end/and/
2020-06-27 05:52:11 <alpine-meetbot> mps meant to say: and add them when they needed, something like st term patches
2020-06-27 05:53:52 <mps> dalias: and, ' you can add custom ones with a config file', what you mean by this? only those which are defined in bb acpid source?
2020-06-27 05:54:57 <mps> iirc, you added some for your personal use
2020-06-27 05:57:38 <mps> I doubt that these like SW_PEN_INSERTED, SW_LINEOUT_INSERT and similar can be added without patching source
2020-06-27 06:13:14 <mps> huh, I like such pkgdesc 'CoreDNS is a fast and flexible DNS server' :P
2020-06-27 10:00:10 <nmeum> mps: if the patch isn't included upstream, I personally wouldn't include it downstream
2020-06-27 10:01:22 <nmeum> we already have a lot of busybox patches which were not integrated upstream, each new unintegrated patch creates more workload for rebasing patches for new busybox upstream versions
2020-06-27 10:24:43 <mps> nmeum: don't worry, I wouldn't post such patches for inclusion before some discussion and only if they acceptable
2020-06-27 10:25:29 <mps> I have some number of pkgs patched in my local repo for my use
2020-06-27 10:26:22 <mps> for few years already, and didn't posted them to be added in alpine
2020-06-27 10:26:44 <nmeum> yes, I am also maintaining locally patched versions of some aports
2020-06-27 10:29:04 <mps> most patches I add to aports I usually report upstream, well where upstream isn't grumpy or don't want to accept for their reasons
2020-06-27 10:30:40 <nmeum> right, I just wanted to point out that I would personally try to avoid further deviations of our busybox aport from the upstream busybox version
2020-06-27 10:31:28 <nmeum> speaking of busybox: the upgrade to 1.32 looks good now, will test it a bit on my system and hopefully merge it within the next week
2020-06-27 10:31:31 <mps> yes, understand and I agree
2020-06-27 10:34:14 <mps> also I should build it and run on armv7 where I already upgraded musl to 1.2.0, to see how it works with 32bit system
2020-06-27 10:34:47 <mps> nmeum: you build it from your MR
2020-06-27 10:35:00 <nmeum> yes
2020-06-27 10:35:15 <nmeum> further tests would be very much appreciated :)
2020-06-27 10:35:16 <mps> thanks, will use it then
2020-06-27 10:35:19 <nmeum> great!
2020-06-27 10:38:08 <nmeum> just rebooted successfully with 1.32.0
2020-06-27 10:44:08 <mps> \o/
2020-06-27 12:58:09 <mps> busybox 1.32.0 built with musl 1.2.0 on armv7, installed and machine boots fine, all works fine
2020-06-27 12:58:56 <mps> will test it more next few days
2020-06-27 12:58:57 <nmeum> sweet, let me konw if you run into any issues while using it
2020-06-27 12:59:05 <mps> sure
2020-06-27 13:00:15 <mps> btw, machine is armv7 alpine edge and I use is as desktop sometimes
2020-06-27 13:01:53 <mps> these days it is used by my son because on his admin notebook battery died
2020-06-27 13:04:32 <mps> hmm, I can also build it on aarch64 where I already use musl 1.2.0
2020-06-27 14:17:45 <mps> busybox 1.32.0 built with musl 1.2.0 on aarch64, installed and machine (chromebook) boots fine, all works fine
2020-06-27 14:18:36 <mps> I use mostly this machine, so testing will be extensive
2020-06-27 14:19:01 <mps> hmm, mostly use* (never will learn english)
2020-06-28 08:34:10 <afontain_> maxice8: about the MR for telegram-desktop size. If you want, I can remove every patch for that in Alpine and fork it in postmarketOS
2020-06-28 08:35:24 <afontain_> IMO, it would still fit in Alpine, as you need to resize the window very small to create an issue (who would do that), and that issue is small: there's is some text over a button, but you can still click on what you want.
2020-06-28 08:39:07 <Cogitri> I think once you set a bigger size tg-desktop remembers it anyway, doesn't it?
2020-06-28 08:40:40 <afontain_> likely
2020-06-28 08:40:45 <afontain_> also, the default size is a different setting
2020-06-28 08:42:03 <afontain_> "likely", actually, I don't know, I've always used GNOME on Wayland (that remembers it for the windows) or Sway (that doesn't try to remember sizes and force windows into tiling)
2020-06-28 08:51:04 <mps> does void xbps automatically run tests when building package
2020-06-28 08:51:59 <Cogitri> Nop, Void doesn't run tests by default or requires them by policy
2020-06-28 08:52:15 <Cogitri> So next to no packages run tests and the ones that do are disabled if they fail :/
2020-06-28 08:53:25 <Cogitri> And since Void crosscompiles to everything but x86* they can't run tests on those arches anyway (unless they used Qemu, but that's nontrivial to do for all test suites)
2020-06-28 08:54:06 <mps> Cogitri: thanks for explanations
2020-06-28 08:54:51 <mps> (libcap tests are not easy)
2020-06-28 10:57:12 <artok> !9698
2020-06-28 15:23:56 <ikke> fyi, server that hosts pkgs.alpinelinux.org is being rebooted
2020-06-28 15:46:06 <ikke> libkcddb fails on 3.12-stable due to test failures
2020-06-28 17:35:02 <xorex> hi folks, hope you doing well. been using Alpine for a while and mostly with Docker. I always had to manually install s6-overlay, do the checksumming etc so I thought it might be nice to package this up and have it in the Alpine repository since a lot of people seem to be using s6-overlay for their process supervising.
2020-06-28 17:35:34 <xorex> i'm kinda surprised it hasn been in already so it might not even be "allowed", so I'd like to feedback on this whether or not it would be acceptable to have this in the Alpine repos
2020-06-28 17:35:42 <xorex> I already took the liberty of creating the APKBUILD file
2020-06-28 17:35:45 <xorex> -> https://dpaste.org/4dhb
2020-06-28 17:35:54 <xorex> my first time doing such thing though :D
2020-06-28 17:36:31 <xorex> it's p. much a meta-package as most of the dependencies are already in Alpine, just the glue to bind all the parts together is within the overlay
2020-06-28 17:36:56 <xorex> it will require a new package though, which is justc-envdir or something like, I've also started makinng an APKBUILD for that
2020-06-28 17:37:29 <ikke> xorex: feel free to make mergerequest against aports
2020-06-28 17:38:17 <ikke> https://gitlab.alpinelinux.org/alpine/aports
2020-06-28 17:39:07 <xorex> alright, that easy eh? :p i expect the criterium will happen there then? :)
2020-06-28 17:39:15 <ikke> yes, mostly
2020-06-28 17:39:35 <xorex> kk, thank you
2020-06-28 19:13:35 <maxice8> @afontain_ that would be nice yeah
2020-06-28 19:32:58 <Hello71> what's going on with gcc 10 atm? is it hard, or just nobody found time to work on it? I think gentoo/fedora have worked out most of the -fno-common issues
2020-06-28 19:38:18 <ikke> I think focus is on musl 1.2 now
2020-06-28 19:51:36 <Hello71> ok
2020-06-28 19:55:41 <Cogitri> Still loads of patched needed for the -fno-common stuff
2020-06-28 19:56:04 <Cogitri> I think Ariadne did some tests already!
2020-06-28 19:56:09 <Cogitri> s/!/?/
2020-06-28 19:56:10 <alpine-meetbot> Cogitri meant to say: I think Ariadne did some tests already?
2020-06-28 19:58:34 <Hello71> er, "worked out" including "patched downstream"
2020-06-28 19:59:12 <ddevault> what is the recommended way for an openrc script to ensure that a kernel module is loaded
2020-06-28 19:59:41 <maxice8> I have no clue, packages just ship into /usr/lib/modules-load.d like flatpak.conf with `fuse`
2020-06-28 20:00:06 <Cogitri> Yes, that's the canonical way
2020-06-28 20:00:08 <ddevault> alright, I'll do that
2020-06-28 20:00:08 <Hello71> yeah, I don't think this should be the init script's responsibility
2020-06-28 20:00:10 <ddevault> thank you
2020-06-28 20:00:27 <Hello71> huh.
2020-06-28 20:10:46 <Ariadne> gcc 10 we will probably revert the -fno-common change for now
2020-06-28 20:11:48 <Ariadne> we use our own spec file anyway so it's easy to do
2020-06-29 06:35:59 <mps> Ariadne: do you still have Acer arm64 chromebook?
2020-06-29 06:38:22 <mps> I found kernel 5.4 on github which can boot on it, though some drivers needs to be tweaked and some fixed
2020-06-29 08:03:32 <nmeum> can someone move #11689 to alpine/mkinitfs?
2020-06-29 08:11:34 <ikke> done
2020-06-29 08:12:24 <nmeum> thanks
2020-06-29 08:47:31 <nmeum> dalias: brief question regarding FTW_CHDIR: do you think it would make sense to remove this macro from the alpine musl aport until it's actually implemented in musl? currently software using it behaves incorrectly at run-time instead of failing to build at compile-time which would imho be desirable
2020-06-29 11:00:41 <mps> trying to upgrade libcap to 2.36 it failed on few tests
2020-06-29 11:01:17 <mps> looks like arch linux and adelie don't run tests when building it
2020-06-29 11:01:31 <mps> and avoid linux
2020-06-29 11:01:39 <mps> uhm, sorry
2020-06-29 11:01:44 <mps> void linux
2020-06-29 11:01:52 <ikke> hahah :D
2020-06-29 11:01:57 <ikke> ironic misspelling
2020-06-29 11:02:24 <mps> not intentionally really
2020-06-29 11:02:34 <mps> sorry again
2020-06-29 11:02:45 <ikke> Yeah, understood. It was just funny
2020-06-29 11:03:07 <PureTryOut[m]> Agreed, that was funny 😉
2020-06-29 11:03:21 <PureTryOut[m]> Note that Arch Linux runs almost no tests. In general I find their packaging of poor quality
2020-06-29 11:04:06 <mps> oh my god what I did, I will be now accused that I detract nice distro
2020-06-29 11:06:02 <mps> any advice about libcap and failed PURE1E tests
2020-06-29 11:08:12 <ikke> I'm not familiar with libcap
2020-06-29 11:10:08 <mps> thanks ikke
2020-06-29 11:11:07 <mps> if I find time I should read more about PURE1E and why it fails with musl (if it is not general problem on libcap)
2020-06-29 12:16:18 <Ariadne> most: no, lemovo
2020-06-29 12:16:22 <Ariadne> err
2020-06-29 12:16:31 <Ariadne> mps: no, lenovo
2020-06-29 12:27:18 <mps> Ariadne: ah, ok. I wonder why I thought that you told me that you acer R13 chromebook
2020-06-29 12:27:37 <mps> that you have*
2020-06-29 12:38:32 <Hello71> I found libattr/libcap to be very buggy on gentoo. building libattr with bfd would cause libcap to fail *at runtime* *after rebuilding both*
2020-06-29 12:38:35 <Hello71> no idea how that happens
2020-06-29 12:42:05 <Hello71> which was very annoying because I also built tar with xattr/cap support, so then I couldn't install any packages
2020-06-29 12:46:08 <hrio[m]> Need some help with review of !9758, the bugfix is needed in v3.12 as well.
2020-06-29 12:46:40 <ikke> for 3.12 we need a separate MR
2020-06-29 12:46:58 <HRio> yes, will prepare one as soon as its Ok for master
2020-06-29 12:47:05 <ikke> nod
2020-06-29 13:11:46 <mps> Hello71: yes, security and usability doesn't work well in tandem
2020-06-29 13:12:27 <mps> secure system doesn't work at all
2020-06-29 13:14:47 <tehcloud> secure system is shut off, but you can still take the drives out so it's not perfect
2020-06-29 13:15:49 <mps> no, secure system is melted in high towers where iron is melting
2020-06-29 13:38:03 <ddevault> it seems that v1 of my yggdrasil patch was applied
2020-06-29 13:38:07 <ddevault> but it's broken, there was a v2
2020-06-29 13:38:13 <ddevault> https://lists.alpinelinux.org/~alpine/aports/patches/3341
2020-06-29 13:38:25 <ddevault> err, hm
2020-06-29 13:38:51 <ddevault> nevermind, my changes were never committed locally
2020-06-29 13:38:53 <ddevault> I'll send a fixup
2020-06-29 13:39:07 <ikke> ddevault: while you're at it, it fails for some reason on aarch64
2020-06-29 13:39:18 <ddevault> do you have a link to the log handy?
2020-06-29 13:39:23 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-aarch64/testing/yggdrasil/yggdrasil-0.3.14-r0.log
2020-06-29 13:39:31 <ddevault> thanks
2020-06-29 13:42:56 <ddevault> fixes sent
2020-06-29 15:53:24 <SerkanDevel[m]1> Hello again, I'm trying to build multiple packages locally but I always get an error like this:
2020-06-29 15:53:36 <SerkanDevel[m]1> ERROR: APKINDEX.tar.gz: UNTRUSTED signature
2020-06-29 15:53:36 <SerkanDevel[m]1> >>> ERROR: meta.sr.ht: Failed to create index
2020-06-29 15:59:25 <SerkanDevel[m]1> I did install alpine-sdk and run abuild-keygen -a -i and built the package with abuild checksum && abuild -rd but I want to host it as a local repository to be used from other local alpine environments
2020-06-29 16:03:06 <afontain_> and you also should copy the key to apk's keyring
2020-06-29 16:03:26 <afontain_> (I think abuild-keygen say it)
2020-06-29 16:03:47 <afontain_> cp ~/.abuild/something /etc/apk/keys
2020-06-29 16:04:39 <SerkanDevel[m]1> That's what I did already but it still shows that error
2020-06-29 16:07:30 <maxice8> @Ikke can you make repos public again ?
2020-06-29 18:46:00 <ikke> maxice8: Cogitri I have now put the script in a container and it runs hourly
2020-06-29 18:46:14 <maxice8> :D
2020-06-29 18:46:22 <maxice8> Thank you
2020-06-29 18:48:07 <ikke> maxice8: so no more reason to ping me :P
2020-06-29 18:48:34 <maxice8> I'll find other reasons to ping you, don't worry
2020-06-29 19:19:01 <Cogitri> Great, thanks ikke :)
2020-06-29 19:26:49 <dalias> nmeum, does any software #ifdef for it?
2020-06-29 19:29:43 <dalias> i suspect a runtime error might be more useful
2020-06-30 05:22:18 <craftyguy_> is Marian Buschsieweke on IRC?
2020-06-30 05:25:00 <ikke> I don't think so
2020-06-30 06:05:39 <mps> he was  here just few times long time ago, but he answers mails always, at least to me
2020-06-30 06:37:28 <eiro> hello
2020-06-30 06:45:06 <craftyguy> mps: thanks, I'll mail him
2020-06-30 07:31:15 <hrio[m]> Ping on !9758, would really like to get it in master, so I can backport to 3.12. Its a 3.12 rollout blocker for us.
2020-06-30 08:33:21 <steevec> Hi there
2020-06-30 08:33:48 <steevec> do you know where we can set kernel's ulimit? looks like /etc/security/limits.conf is ignored
2020-06-30 08:46:53 <ikke> ulimit is per process
2020-06-30 08:47:56 <ikke> I see that you asked this in #alpine-linux as well
2020-06-30 09:09:46 <eiro> is there a way to make readlink (so abuild) work in a chroot?
2020-06-30 09:12:17 <steevec> thanks ikke
2020-06-30 10:05:19 <fredrigu> I'm trying to install a package with apk and for some reason it fails calculating the dependencies with the "Huh?" error message. I've turned on debug prints and can see that the package I want is selectable=0 but available=1, what does that mean?
2020-06-30 12:13:58 <mps> hmm, issues (bug reports) can be assigned to only one person, not more?
2020-06-30 12:14:30 <ikke> correct
2020-06-30 12:15:38 <mps> ikke: thanks for confirmation
2020-06-30 12:22:51 <ikke> mps: conventional you can "CC:" people
2020-06-30 12:26:58 <mps> selected people or group 'people'
2020-06-30 12:28:55 <ikke> You can refer to groups
2020-06-30 12:30:38 <mps> yes, I know for groups but I tried to selected people
2020-06-30 13:18:31 <afontain_> hey, when one of you have time, maybe you could have a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8689?
2020-06-30 13:20:11 <ikke> "MC:[AL5]:APKBUILD:33:variable set to empty string: install="""
2020-06-30 13:20:26 <ikke> Only linting issue :)
2020-06-30 13:20:31 <ikke> (I don't have much more time atm)
2020-06-30 13:56:11 <ncopa> whats up with the edge builders?
2020-06-30 14:00:55 <ncopa> is broken 6f2fcc2c934326b86e55532094defc46fc2098b2
2020-06-30 14:07:32 <ikke> Hmm, it doesn't say what it's failing on
2020-06-30 14:09:05 <ikke> ah, syntax error :-/
2020-06-30 14:24:13 <ncopa> pushed fix
2020-06-30 14:24:38 <ncopa> >>> xpdf: Checking sanity of /home/buildozer/aports/community/xpdf/APKBUILD...
2020-06-30 14:24:38 <ncopa> >>> ERROR: xpdf: xpdfrc exists in sha512sums but is missing in $source
2020-06-30 14:24:42 <ncopa> whats going on?
2020-06-30 14:25:39 <ikke> good question
2020-06-30 14:26:14 <ikke> maxice8: ^
2020-06-30 15:13:59 <hjaekel> Hi maxice8, thank you for merging !9769. Do you know why the new package isn't built?
2020-06-30 15:35:51 <[[sroracle]]> eiro: /proc needs to be mounted inside your chroot
2020-06-30 16:03:37 <ikke> hjaekel: builders are stuck
2020-06-30 16:08:41 <ikke> ncopa: maxice8 seems that the pipelines for these packages said there was nothing to be built
2020-06-30 16:34:22 <hjaekel> hm, what is needed to trigger the builders? Should I bump pkgver?
2020-06-30 16:37:25 <mps> hjaekel: which ones, edge or stable
2020-06-30 16:37:58 <hjaekel> edge, stable is Ok
2020-06-30 16:38:35 <mps> ok, I triggered them
2020-06-30 16:38:57 <hjaekel> thank you
2020-06-30 16:39:12 <mps> clazy whatever it is fails https://build.alpinelinux.org/buildlogs/build-edge-s390x/community/clazy/clazy-1.7-r0.log
2020-06-30 16:40:20 <mps> 'make[2]: *** No rule to make target '../ON', needed by 'lib/ClazyPlugin.so'.  Stop.'
2020-06-30 16:42:06 <mps> hmm, '-DCLANG_CLANG-CPP_LIB=ON' ?
2020-06-30 16:49:27 <mps> looks like build works without this line
2020-06-30 16:50:52 <mps> is André Klitzing on some of our channels? if not someone who understand what is this pkg should look at this. I don't want to blindly change/remove that line
2020-06-30 16:51:13 <mps> but, it blocks builders
2020-06-30 16:51:30 <ikke> No, he's not here
2020-06-30 16:51:39 <ikke> You can comment on the MR I guess: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9791
2020-06-30 16:52:30 <Cogitri> Weird that it worked on CI 🤔
2020-06-30 16:52:35 <ikke> It did not run on CI
2020-06-30 16:52:42 <ikke> for some vague reason
2020-06-30 16:52:50 <Cogitri> Ah nevermind, right
2020-06-30 16:53:49 <mps> upstream have this for build instructions 'cmake -DCMAKE_INSTALL_PREFIX=<prefix> -DCMAKE_BUILD_TYPE=Release'
2020-06-30 16:54:21 <mps> can't find ''-DCLANG_CLANG-CPP_LIB=ON'' on url https://github.com/KDE/clazy
2020-06-30 16:54:54 <mps> yes, it finished on lxc without mentioned line
2020-06-30 16:55:25 <Cogitri> https://github.com/KDE/clazy/blob/7016297479c5332f4c233780ef8e7bfb8475d49d/CMakeLists.txt#L128
2020-06-30 16:57:13 <mps> ah, aiee
2020-06-30 17:02:15 <mps> do we need this ?
2020-06-30 17:04:48 <Cogitri> Dunno
2020-06-30 17:08:41 <mps> ok, I asked him on MR
2020-06-30 17:14:24 <Cogitri> clandmeter: You did the vlc split, right?
2020-06-30 17:14:39 <Cogitri> Can you check !9790
2020-06-30 17:18:52 <clandmeter> Cogitri: i remember ncopa said that split was bad
2020-06-30 17:19:02 <clandmeter> But it's a long time ago
2020-06-30 17:20:38 <Cogitri> Oh okay
2020-06-30 17:21:39 <clandmeter> Maybe ping ncopa in the issue
2020-06-30 17:23:55 <afontain_> un-splitting the package works for me tbh
2020-06-30 17:28:02 <mps> hmm, is this binary only pkg !9724
2020-06-30 17:40:38 <Cogitri> mps: I think it's just text files
2020-06-30 17:41:15 <Cogitri> Actually, not sure anymore
2020-06-30 17:46:05 <mps> humm, will download and look
2020-06-30 17:50:13 <mps> huh, I wouldn't merge this, we are not docker provider
2020-06-30 17:59:53 <ikke> mps: Not sure what you mean with that?
2020-06-30 18:00:59 <mps> ikke: it looks like it is docker builder, though with specialized environment
2020-06-30 18:01:43 <mps> I'm far from expert in this field, but to me that doesn't smell fine
2020-06-30 20:49:17 <eiro> [[sroracle]]: mount -t proc none /proc made it work! thank you very much
2020-06-30 22:48:51 <[[sroracle]]> np