2020-12-01 10:02:37 <ikke> ncopa: apparently firefox upstream no longer tests builds with gcc, so we should prepare to expect more regressesions in that regard
2020-12-01 10:09:41 <dne> ikke: why did ec4425ce83436793a42ac9784b717644fe05479a bump pkgrel for openssh?
2020-12-01 10:09:58 <ikke> dne: euuhm..
2020-12-01 10:10:02 <PureTryOut[m]2> The aarch64 builder is stuck on Firefox currently
2020-12-01 10:10:35 <ikke> dne: I think because I was in the wrong dir when I ran apkgrel -a ..
2020-12-01 10:10:35 <PureTryOut[m]2> Could somebody look in resolving it?
2020-12-01 10:10:44 <ikke> PureTryOut[m]2: is it stuck?
2020-12-01 10:10:48 <ikke> PureTryOut[m]2: Cogitri just pushed it
2020-12-01 10:10:51 <dne> ikke: aha :)
2020-12-01 10:10:52 <ikke> I mean, just pushed a fix
2020-12-01 10:11:31 <PureTryOut[m]2> Just as in a minute or so ago?
2020-12-01 10:11:42 <PureTryOut[m]2> In that case ignore my comment
2020-12-01 10:11:48 <ikke> No, 30 minutes ago
2020-12-01 10:13:11 <ikke> PureTryOut[m]2: I'm keeping an eye on it
2020-12-01 10:13:18 <PureTryOut[m]2> 👍️
2020-12-01 10:14:11 <ikke> PureTryOut[m]2: you are aware you have a 2 appended to your name?
2020-12-01 10:14:32 <PureTryOut[m]2> Yes I am
2020-12-01 10:14:39 <ikke> Oh yeah, now I recall
2020-12-01 10:14:45 <PureTryOut[m]2> It's just until I get my own Matrix server working again
2020-12-01 10:14:52 <ikke> ok
2020-12-01 10:18:48 <Marian[m]> Could someone take a quick look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15116 ? It's only a pkgrel bump and fixes a runtime crash for me.
2020-12-01 10:23:45 <ikke> Marian[m]: will do
2020-12-01 10:35:28 <Marian[m]> Thanks :-)
2020-12-01 10:36:08 <ikke> Ariadne: do we expect the musl related deadlocks to be fixed now? I still seem to see deadlocks on openjdk and firefox (though, not sure what's the reason)
2020-12-01 10:36:15 <ikke> dalias: ^
2020-12-01 10:49:55 <ikke> Cogitri: ping
2020-12-01 10:54:39 <ikke> Cogitri: n/m, found it
2020-12-01 11:04:22 <Cogitri> 👍️
2020-12-01 11:09:39 <PureTryOut[m]2> Firefox still seems to be failing on aarch64
2020-12-01 11:09:47 <PureTryOut[m]2> > `error: could not compile `gkrust`.`
2020-12-01 11:09:59 <PureTryOut[m]2>  * > `error: could not compile \`gkrust\`.`
2020-12-01 11:10:06 <PureTryOut[m]2>  * > `error: could not compile 'gkrust'.`
2020-12-01 11:11:09 <ikke> PureTryOut[m]2: local build?
2020-12-01 11:11:17 <PureTryOut[m]2> No the builders
2020-12-01 11:11:33 <ikke> PureTryOut[m]2: I killed it
2020-12-01 11:11:41 <PureTryOut[m]2> 👍️
2020-12-01 11:12:35 <ikke> Marian[m]: merged
2020-12-01 11:13:04 <Marian[m]> Thanks :-)
2020-12-01 11:31:05 <Cogitri> `/home/buildozer/aports/community/firefox/src/firefox-83.0/security/sandbox/linux/SandboxFilter.cpp:1429:12: error: '__NR_fork' was not declared in this scope` I guess one of our patches is bad (on aarch64)?
2020-12-01 11:31:53 <Cogitri> Oh, seems like that is in the SIGTERM'ed build
2020-12-01 11:36:43 <ikke> "futex(0xfffa70a3d540, FUTEX_WAIT_PRIVATE, 2, NULL"
2020-12-01 11:36:46 <ikke> :(
2020-12-01 11:37:11 <ikke> /usr/bin/rustc --crate-name gkrust toolkit/library/rust/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type staticlib --emit=dep-info,link -C opt-level=2 -C panic=abort -C embed-bitcode=no -Clto ....
2020-12-01 11:40:56 <Cogitri> Weird that rustc only triggers that on aarch64
2020-12-01 11:46:53 <andypost[m]> I bet it same reason for arm
2020-12-01 12:29:00 <ikke> \o/
2020-12-01 12:29:02 <ikke> it's continuing
2020-12-01 12:29:14 <ikke> so we need to have a bit more patience
2020-12-01 12:29:33 <Cogitri> Neat
2020-12-01 13:15:35 <Cogitri> ikke: What's the status on FF now? I'm a bit confused because the build log seems to be from a failed build but it's still displayed as in-progress on b.a.o?
2020-12-01 13:15:47 <ikke> still working
2020-12-01 13:16:22 <Cogitri> Okie
2020-12-01 13:26:10 <ikke> Now it 'seems' to be hanging on gkrust again
2020-12-01 13:26:24 <ikke> 100% cpu, just waiting
2020-12-01 13:27:23 <Cogitri> It just takes forever
2020-12-01 13:27:37 <Cogitri> Takes like 10 minutes to link on my 3950X too
2020-12-01 13:27:45 <ikke> ok
2020-12-01 13:28:24 <mps> yes, this part in building FF takes time
2020-12-01 13:31:54 <Cogitri> Yup, Rust has some nice things to it but build time sure isn't one of them :D
2020-12-01 13:32:23 <clandmeter> get a faster cpu :p
2020-12-01 13:32:59 <ikke> clandmeter: yes pls
2020-12-01 13:33:19 <clandmeter> i have it on my desktop atm
2020-12-01 13:36:05 <mps> long time ago I wrote that all modern langs and software are for CPU/memory/disks ... manufacturers benefit only
2020-12-01 13:37:05 <ikke> Well, I don't think mozilla is writing rust to benefit hardware manufacturers
2020-12-01 13:37:42 <mps> change your mind :)
2020-12-01 13:37:45 <bratkartoffel> just openend a MR to fix the nagios-plugins build on the 3.13 builders: !15124
2020-12-01 13:38:30 <ikke> bratkartoffel: nice, thanks
2020-12-01 13:49:47 <Hello71> I am told it's significantly faster with clang and lld
2020-12-01 13:51:26 <Cogitri> wdym?
2020-12-01 13:51:44 <ikke> That building firefox is faster if would switch to clang + lld?
2020-12-01 13:52:25 <Cogitri> I think the Rust part takes up a major part of the buildtime in FF
2020-12-01 13:53:05 <mps> this is also in my experience
2020-12-01 13:53:58 <Cogitri> CLang and lld certainly are quicker than GCC + bfd, but I don't think it'd make a huge difference for Rust
2020-12-01 14:07:05 <andypost[m]> bratkartoffel looks openjdk hangs on edge harm builders since yesterday
2020-12-01 14:07:23 <ikke> I've restarted them once about 2 hours ago
2020-12-01 14:07:23 <alpine-meetbot> andypost[m] meant to say: bratkartoffel looks openjdk hangs on edge arm builders since yesterday
2020-12-01 14:07:23 <andypost[m]> s/harm/arm
2020-12-01 14:14:33 <Hello71> Cogitri: rustc -C link-arg=-fuse-ld=lld
2020-12-01 14:14:53 <Hello71> https://github.com/rust-lang/rust/issues/39915 https://github.com/rust-lang/rust/issues/71515 https://github.com/rust-lang/rust/issues/71519 etc
2020-12-01 14:33:06 <Cogitri> Ah yes, so s/clang and//
2020-12-01 14:33:25 <Cogitri> Yes, lld is neato
2020-12-01 14:34:02 <Cogitri> ikke: !15125 should fix FF
2020-12-01 14:35:13 <mps> and FF on 3.12 is really outdated, 81.0
2020-12-01 14:35:31 <Cogitri> Yes, will try to backport it once it works on edge
2020-12-01 14:36:25 <mps> my 'fear' was substantial about moving FF to community
2020-12-01 14:37:27 <Cogitri> Yes, sorry, didnt have as much time for Alpine as planned in recent time
2020-12-01 14:38:25 <mps> Cogitri: I don't want to accuse you for that, I see and know that you work a lot for alpine
2020-12-01 14:38:52 <mps> I'm addressing BDFL on that
2020-12-01 14:39:42 <ikke> mps: my opinion is that if something is accepted in testing, it should be fit for at least community
2020-12-01 14:39:42 <Cogitri> Rust itself isn't much of a problem on 3.12 w/ FF community, just mv'ing FF's APKBUILD from edge to 3.12 would probably do the tric
2020-12-01 14:40:02 <ikke> If it can't go into community, it should not belong into testing either
2020-12-01 14:40:07 <mps> ikke: not 'fast moving' as FF
2020-12-01 14:40:50 <mps> FF was long time in testing, and we kept ff-esr for stable releases in community
2020-12-01 14:41:10 <ikke> but the idea of testing is not to keep packages there
2020-12-01 14:41:18 <ikke> although that's what happens in practice
2020-12-01 14:41:48 <mps> it is not good idea to follow any idea blindly, imo
2020-12-01 14:44:29 <ikke> and esr is/was broken on stable, while non-esr is working
2020-12-01 14:45:07 <mps> ff-esr works on my stable box
2020-12-01 14:45:37 <mps> except is sometimes OOM when have too much tabs open
2020-12-01 14:48:30 <mps> to clarify a little, I'm not strongly against move FF to community, but I that case we don't need ff-esr at all (imo)
2020-12-01 14:49:40 <mps> s/but I/but I think in/
2020-12-01 14:49:40 <alpine-meetbot> mps meant to say: to clarify a little, I'm not strongly against move FF to community, but I think in that case we don't need ff-esr at all (imo)
2020-12-01 14:55:49 <bratkartoffel> andypost[m]: i've no idea why jdk8 build hangs on these arches
2020-12-01 14:56:11 <bratkartoffel> but i'll try to reproduce this locally in a vm, maybe i can find out more information about this
2020-12-01 14:57:53 <ikke> mps: -esr now works for me both in stable as edge as well
2020-12-01 14:58:09 <ikke> bratkartoffel: I'll try to get more info as well
2020-12-01 14:58:36 <Ariadne> mips builder fixed.  was kpanic'd and the console to usb cable was fubar
2020-12-01 14:59:20 <ikke> Ariadne: nice, thanks
2020-12-01 15:01:57 <ikke> bratkartoffel: I see one thread is still working
2020-12-01 15:03:12 <bratkartoffel> how long did the build normally take in the past?
2020-12-01 15:06:41 <ikke> I don't know exactly
2020-12-01 15:06:43 <ikke> bratkartoffel: https://tpaste.us/magV
2020-12-01 15:06:49 <ikke> this is the process that is currently running
2020-12-01 15:07:51 <ikke> It's wring html files it seems, so still working
2020-12-01 15:07:53 <Ariadne> openjdk takes forever
2020-12-01 15:07:56 <ikke> writing*
2020-12-01 15:08:11 <Ariadne> several days on slower machines
2020-12-01 15:08:40 <Hello71> i'm wondering why all these packages fail on 3.13 but not edge? were they not rebuilt with gcc 10 yet?
2020-12-01 15:08:52 <ikke> Hello71: most likely
2020-12-01 15:09:05 <ikke> we did not rebuild world on edge with gcc10
2020-12-01 15:09:10 <Hello71> oh
2020-12-01 15:09:33 <Hello71> but wait, wasn't the musl rebuild done with gcc 10?
2020-12-01 15:10:12 <Ariadne> no
2020-12-01 15:10:19 <Ariadne> gcc 10 came after
2020-12-01 15:10:29 <Hello71> ah well that explains it
2020-12-01 15:10:47 <ikke> would be fun, both musl and gcc upgrade at the same time
2020-12-01 15:12:19 <bratkartoffel> ikke: javadoc compilation i think, yes. not sure if we actually need them... maybe we can disable them in the build, this would speed up the build on all arches a lot
2020-12-01 15:12:35 <ikke> bratkartoffel: I can imagine
2020-12-01 15:12:48 <ikke> bratkartoffel: it is doing it single threaded
2020-12-01 15:12:55 <ikke> bratkartoffel: multi threadingi t would help a lot
2020-12-01 15:12:57 <bratkartoffel> thanks oracle ;)
2020-12-01 15:13:04 <bratkartoffel> i'll check that
2020-12-01 15:14:10 <Hello71> make images
2020-12-01 15:20:29 <ikke> I can't imagine it takes this long
2020-12-01 15:20:39 <Hello71> maybe something wrong with the disk
2020-12-01 15:21:11 <ikke> I checked with iostat, didn't see any disk contention
2020-12-01 15:27:47 <mimi89999> Hello
2020-12-01 15:28:00 <mps> mimi89999: o/
2020-12-01 15:28:11 <Hello71> ikke: PSI is the new hotness
2020-12-01 15:29:13 <mimi89999> PSI?
2020-12-01 15:29:29 <Ariadne> pressure-stall indication
2020-12-01 15:46:47 <mimi89999> Why are packages like https://build.alpinelinux.org/buildlogs/build-edge-s390x/community/kajongg/kajongg-20.08.2-r0.log still built even if they have unsatisfied dependencies?
2020-12-01 15:47:08 <Ariadne> because buildrepo is not smart
2020-12-01 15:47:19 <mimi89999> Shouldn't the infa build a dependency graph and if something is missing then not attemtp to build
2020-12-01 15:48:10 <Ariadne> sure
2020-12-01 15:48:30 <Ariadne> unfortunately its not something that has gotten much love
2020-12-01 15:48:43 <Ariadne> [[sroracle]] has apkfoundry which is a bit smarter than buildrepo
2020-12-01 15:48:53 <mimi89999> I will open an MR for kajongg
2020-12-01 15:49:04 <ncopa> i think that we should have tooling that let us check the consequence of disabling a package for a given arch
2020-12-01 15:49:10 <Ariadne> mask mips too
2020-12-01 15:49:10 <ikke> On the other hand, it makes it very clear why it's not being built
2020-12-01 15:49:13 <mimi89999> Who would play a game on an expensive server anyway?
2020-12-01 15:49:21 <Ariadne> i would ^_^
2020-12-01 15:50:04 <Ariadne> notcurses looks pretty cool, but its demoscene stuff
2020-12-01 15:50:07 <Ariadne> lol
2020-12-01 15:54:31 <mimi89999> Here it is: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15126
2020-12-01 15:56:07 <mimi89999> > On the other hand, it makes it very clear why it's not being built
2020-12-01 15:56:07 <mimi89999> You could have a website like tracker.debian.org what would show all that kind of stuff.
2020-12-01 15:57:06 <mimi89999> Also, if somebody finally gets a dependency building an an arch, then all dependent packages will still be masked.
2020-12-01 16:01:31 <[[sroracle]]> I should probably
2020-12-01 16:01:43 <[[sroracle]]> Upstream my abuild patches
2020-12-01 16:02:34 <mps> mimi89999: 'fail early, fail hard' is better than masking problems
2020-12-01 16:11:00 <mimi89999> Why is `build-edge-aarch64` not doing anything?
2020-12-01 16:11:24 <ikke> "build-edge-aarch64: failed to build notcurses"
2020-12-01 16:11:28 <ikke> need to restart it
2020-12-01 16:11:33 <ikke> alpine-meetbot: retry master
2020-12-01 16:11:43 <ikke> alpine-meetbot: retry master
2020-12-01 16:11:45 <ikke> urg
2020-12-01 16:11:50 <ikke> algitbot: retry master
2020-12-01 16:18:55 <dalias> ikke, hm?
2020-12-01 16:29:48 <ikke> dalias: n/m, they were not stuck
2020-12-01 16:31:00 <ikke> 
ACTION found out he needs to look at the thread-level

2020-12-01 16:42:10 <dalias> ?
2020-12-01 16:44:02 <ikke> dalias: I was looking at a process which looked like it was stuck on a futex, but when I looked at the individual threads, I saw one of them still working
2020-12-01 16:44:15 <dalias> ah
2020-12-01 16:55:20 <[[sroracle]]> hmm
2020-12-01 16:55:28 <[[sroracle]]> i can't submit an MR for alpine/abuild.git
2020-12-01 16:55:34 <[[sroracle]]> it keeps redirecting me back to my fork
2020-12-01 17:06:02 <bratkartoffel> [[sroracle]]: you can manually change the target repo when creating the MR
2020-12-01 17:06:12 <[[sroracle]]> yeah, I did
2020-12-01 17:06:18 <[[sroracle]]> and it still took me back to my fork
2020-12-01 17:07:44 <[[sroracle]]> when i try to edit the url manually it gives me a 404 as well
2020-12-01 17:18:20 <[[sroracle]]> ok well after trying about 6 times it is working :p
2020-12-01 17:34:22 <ikke> odd
2020-12-01 17:43:06 <bratkartoffel> ikke: i've disabled the javadoc generation with !15129. should be way faster now
2020-12-01 17:43:46 <ikke> bratkartoffel: ok, but not sure if we want to rebuild now again
2020-12-01 17:44:09 <ikke> openjdk finished on armhf
2020-12-01 17:44:21 <bratkartoffel> should i keep the old pkgrel?
2020-12-01 17:44:31 <bratkartoffel> so only the next upgrade will have this change?
2020-12-01 17:45:29 <[[sroracle]]> bratkartoffel: just to clarify - did $pkgname-doc not include whatever javadoc is?
2020-12-01 17:45:40 <bratkartoffel> nope, just the standard manpages
2020-12-01 17:46:30 <ikke> Then I guess it's better not to bump pkgrel
2020-12-01 17:47:40 <bratkartoffel> pushed my MR again without the bump
2020-12-01 17:48:53 <ikke> canceling the previous pipeline
2020-12-01 18:00:17 <andypost[m]> Nice! it just 10m build time now https://gitlab.alpinelinux.org/bratkartoffel/aports/-/jobs/258624
2020-12-01 18:04:31 <ikke> wowzers
2020-12-01 18:04:31 <[[sroracle]]> what was it before?
2020-12-01 18:04:48 <mimi89999> armhf and armv7 are failed
2020-12-01 18:05:03 <mimi89999> ceph and firefox
2020-12-01 18:06:10 <ikke> hmm, 21 minutes on ci :S
2020-12-01 18:06:14 <ikke> https://gitlab.alpinelinux.org/bratkartoffel/aports/-/jobs/257702
2020-12-01 18:07:18 <[[sroracle]]> aarch64 was 18m1s before
2020-12-01 18:07:36 <[[sroracle]]> x86_64 was 16m24s
2020-12-01 18:07:41 <[[sroracle]]> seems negligible
2020-12-01 18:08:34 <Hello71> error[E0432]: unresolved imports `core::arch::arm::float32x4_t`, `core::arch::arm::int32x4_t`, `core::arch::arm::vaddq_f32`
2020-12-01 18:08:46 <Hello71> wonder what that means
2020-12-01 18:51:32 <mimi89999> How long does it take for a merge request to get reviewed?
2020-12-01 18:59:06 <ikke> mimi89999: depends
2020-12-01 18:59:10 <maxice8> Depends
2020-12-01 18:59:12 <ikke> :D
2020-12-01 19:00:11 <mimi89999> Depends on what?
2020-12-01 19:01:25 <mimi89999> It;s tested
2020-12-01 19:02:11 <ikke> how much time we have at the moment, if we have other things to do, how complicated the MR is, if the maintainer of the package needs to verify it and other factors
2020-12-01 19:02:55 <mps> depends on dependencies :)
2020-12-01 19:17:29 <andypost[m]> And on dependant
2020-12-01 19:31:00 <mimi89999> Could somebody clear the spam flag from `gtkmm3`?
2020-12-01 19:34:05 <insep_> mimi89999: seems like cogitri got sniped by you
2020-12-01 19:34:21 <insep_> :D
2020-12-01 19:52:45 <mimi89999> ?
2020-12-01 19:54:04 <mimi89999> what?
2020-12-01 19:55:29 <mimi89999> Why?
2020-12-01 20:03:30 <mimi89999> The !15120 and the comment under it?
2020-12-01 20:04:47 <mimi89999> There is still the armv7 build 😉️
2020-12-01 20:07:12 <mimi89999> The comment uder `nginx` is also nonsense
2020-12-01 20:07:14 <mimi89999> https://pkgs.alpinelinux.org/flagged
2020-12-01 20:11:28 <mimi89999> `chromium` also
2020-12-01 21:12:35 <dalias> ariadne, any results with latest musl?
2020-12-01 21:13:38 <Ariadne> no complaints thus far
2020-12-01 21:22:02 <dalias> :)
2020-12-01 21:30:22 <mimi89999> What's the repo with the most recent packages
2020-12-01 21:30:23 <mimi89999> ?
2020-12-01 21:30:46 <dalias> edge i guess
2020-12-01 21:31:54 <mimi89999> I mean the mirror that is updated the most frequently
2020-12-01 21:45:59 <dalias> ah
2020-12-01 21:50:43 <Ariadne> dalias: when do you plan to release musl-1.2.2?
2020-12-01 22:24:41 <dalias> ariadne, next couple days i think
2020-12-02 07:03:44 <bratkartoffel> !15164 should fix the dovecot build on armhf and armv7
2020-12-02 07:25:52 <ncopa> morning
2020-12-02 07:30:27 <ncopa> Ariadne: whats up with the mips64 builder?
2020-12-02 07:33:29 <ncopa> oh its back
2020-12-02 07:33:44 <ncopa> and gcc segfautls again...:-(
2020-12-02 07:51:43 <ikke> yes :(
2020-12-02 09:16:09 <ikke> hmm, kmime is not rebuilt yet on s390x, but kitinerary which depends on it seems to be built before kmime
2020-12-02 09:17:59 <ikke> buildrepo -n community does not list it to be built and it's not in the package repo on the builder
2020-12-02 09:18:06 <ikke> ncopa: any idea what might be going on
2020-12-02 09:18:09 <ikke> ?
2020-12-02 09:19:27 <ikke> ok, kmime is disabled on s390x
2020-12-02 09:22:06 <ikke> PureTryOut[m]2: You disabled kmime on several platforms mentioning qt5-qtbase-x11 is missing, but I see it being available on all platforms?
2020-12-02 09:22:08 <ikke> 0b53481594d6c8245da7543fbbda023444d17aea
2020-12-02 09:22:32 <PureTryOut[m]2> Oh, might be because the builders were still stuck at that point?
2020-12-02 09:22:44 <ikke> possibly
2020-12-02 09:22:51 <PureTryOut[m]2> Several platforms though, I think I just disabled it on s390x for that reason?
2020-12-02 09:22:59 <ikke> mips as well
2020-12-02 09:23:17 <ikke> kitinerary fails to build due to that
2020-12-02 09:23:23 <PureTryOut[m]2> Oh, strange I don't think I did that on purpose
2020-12-02 09:25:38 <ikke> I can push a commit to enable them again
2020-12-02 09:29:50 <PureTryOut[m]2> Sure
2020-12-02 09:33:01 <ikke> The comment mentions mips64, but it was not actually disabled there
2020-12-02 09:42:57 <PureTryOut[m]2> I don't know what happened tbh. I had to disable a lot of packages on s390x and I might've messed up some stuff
2020-12-02 09:49:10 <PureTryOut[m]2> Could anyone merge !15171? It finally makes mautrix-telegram launch again
2020-12-02 09:53:00 <ikke> PureTryOut[m]2: isn't it better to change the shebang in mautrix-telegram?
2020-12-02 09:53:09 <ikke> otherwise it's still broken for people who run it directly
2020-12-02 09:53:18 <PureTryOut[m]2> The shebang? What are you talking about?
2020-12-02 09:53:35 <ikke> Ah, sorry, I missed the '-m'
2020-12-02 09:53:54 <PureTryOut[m]2> The launch script has been removed in favor of launching it as a python module
2020-12-02 09:53:54 <ikke> you load it as a module instead of directly
2020-12-02 09:53:58 <ikke> ok
2020-12-02 09:54:03 <PureTryOut[m]2> Yes, that is how upstream recommends it
2020-12-02 09:55:12 <ikke> Would be nice if that kind of info can be part of the commit message :)
2020-12-02 09:55:36 <ikke> for posterity
2020-12-02 09:57:35 <ikke> I'll merge this now
2020-12-02 10:00:51 <PureTryOut[m]2> Thanks!
2020-12-02 10:00:58 <PureTryOut[m]2> Will do in the future
2020-12-02 10:39:12 <bratkartoffel> Wow, I haven't noticed that alpine got over 1 billion pulls on dockerhub... congratulations are in order, i guess?
2020-12-02 10:39:55 <ikke>  nice, I guess that will not grow as fast now since the new pull limitations
2020-12-02 10:44:06 <mps> milliard?
2020-12-02 10:44:53 <ikke> In non-english languages, yes
2020-12-02 10:44:57 <bratkartoffel> 1_000_000_000
2020-12-02 10:46:08 <mps> well, most of us are not native english speakers, and milliard is also used in England iirc
2020-12-02 10:46:14 <ikke> nope
2020-12-02 10:46:20 <ikke> milliion -> billion
2020-12-02 10:46:50 <mps> millililli :)
2020-12-02 10:48:13 <mps> ncopa: did you read my msg few days ago about mandoc upstream plan to remove gzip support
2020-12-02 10:48:52 <PureTryOut[m]2> Billion in English is confusing, as at least in Dutch we have billioen (which sounds almost the same) but is a lot bigger
2020-12-02 10:50:45 <bratkartoffel> in german a billion is also about 1000x1000 bigger than a million; imho i find the english numbers simpler and more consistent. billion, trillion, quadrillion, quintiliion etc.
2020-12-02 10:52:22 <ikke> https://en.wikipedia.org/wiki/Billion
2020-12-02 10:52:23 <alpine-meetbot> [WIKIPEDIA] Billion | "A billion is a number with two distinct definitions:1,000,000,000, i.e. one thousand million, or 109 (ten to the ninth power), as defined on the short scale. This is now the meaning in both British and American English.1,000,000,000,000, i.e. one million million, or 1012 (ten to the twelfth power..."
2020-12-02 10:53:42 <mps> maxice8: re !15141, put CVE in 'subject' commit msg is not good imo. put them in 'body' commit msg
2020-12-02 10:55:12 <mps> maxice8: also thanks for noticing that xorg is released and push it instead of my MR (which I made before new xorg is released)
2020-12-02 10:55:53 <ikke> It's common to have the CVE's listed in the subject
2020-12-02 10:56:02 <ikke> So that the subject is concrete, not generic
2020-12-02 10:56:19 <ikke> iirc, abump -s does that too
2020-12-02 10:56:26 <mps> yes, english is confusing language, writting, reading, listening and speaking
2020-12-02 10:57:03 <mps> ikke: some commit subjects will be tooooo long then
2020-12-02 10:57:12 <ikke> any language is confusing and inconsistent
2020-12-02 10:57:35 <mps> not really, italian is quite good
2020-12-02 10:57:57 <ikke> I think the pattern is: foo/bar: security upgrade (CVE-2020-1234, CVE-20200-1235)
2020-12-02 10:58:18 <ikke> s/20200/2020
2020-12-02 10:58:18 <alpine-meetbot> ikke meant to say: I think the pattern is: foo/bar: security upgrade (CVE-2020-1234, CVE-2020-1235)
2020-12-02 10:58:27 <mps> this is ok for one or two CVEs but what with 5 and more
2020-12-02 11:00:15 <ikke> f48590ae54ca9e0c3bf6b3fae3e6b065f14223e3
2020-12-02 11:00:26 <mps> and german is 'consistent' in building composed words
2020-12-02 11:00:54 <mps> huh, isn't this line too long
2020-12-02 11:01:45 <mps> and imagine same numbers of fixes with CVE-2020-xxxx format
2020-12-02 11:02:22 <ikke> mps: The clue is reasonableness. If the CVE's fit in a reasonable length, add them
2020-12-02 11:03:16 <mps> so, let committer to decide sounds most reasonable to me ;p
2020-12-02 11:03:49 <dne> 
ACTION ducks

2020-12-02 11:04:08 <ikke> 'commit title can be: community/xorg-server: CVE-2020-25712 and CVE-2020-14360' seems quite reasonable to me as well :-)
2020-12-02 11:04:32 <mps> not for me, I want to be consistent
2020-12-02 11:04:39 <ikke> hmm, well, apart that it's missing that it's a security upgrade
2020-12-02 11:05:08 <ikke> mps: what happened to exceptions :P
2020-12-02 11:05:10 <mps> hehe, enough 'yak shavings' for today :)
2020-12-02 11:26:37 <mps> ncopa: this is url about idea of gzip removal from mandoc https://marc.info/?l=mandoc-discuss&m=160668087317110&w=2
2020-12-02 11:49:27 <clandmeter> mps: interesting
2020-12-02 11:56:50 <clandmeter> software got so bloated, lets not consider disk space and/or network connections at all anymore.
2020-12-02 11:57:50 <ikke> 'disk space is cheap'
2020-12-02 12:05:35 <mps> did I wrote yesterday here again for which benefit software 'improves' :)
2020-12-02 12:05:56 <clandmeter> I want carbon neutral disk usage. save the space!
2020-12-02 12:07:51 <mps> memorize everything and no need for (disk) space
2020-12-02 12:14:46 <clandmeter> too bad Moore's law doesn't apply to my brain. its probably opposite :)
2020-12-02 12:16:32 <mps> also here :)
2020-12-02 12:39:55 <mimi89999> armv7 is still missing xorg-server because it's stuck on Firefox
2020-12-02 12:43:37 <ikke> ugh
2020-12-02 12:43:40 <ikke> I think something else is going on
2020-12-02 12:43:49 <ikke> well, not think
2020-12-02 12:43:53 <ikke> I see something else is going on
2020-12-02 12:43:58 <ikke> ncopa: ping
2020-12-02 12:45:30 <ncopa> pong
2020-12-02 12:45:53 <ikke> apparently the gitea test suite is making commits on aports on the armv7 builder
2020-12-02 12:46:40 <ncopa> ugh
2020-12-02 12:46:48 <ncopa> thats not good
2020-12-02 12:46:50 <ikke> nope
2020-12-02 12:47:16 <ikke> I can reset it, but it's something we need to structurally fix
2020-12-02 12:47:59 <ikke> ncopa: One suggestion: set GIT_CEILING_DIRECTORIES
2020-12-02 12:49:22 <ncopa> im in a call right now
2020-12-02 12:49:24 <ikke> ok
2020-12-02 12:49:35 <ikke> I'll reset the repo now
2020-12-02 12:50:00 <ncopa> thanks
2020-12-02 12:52:30 <ikke> mimi89999: so all packages in community except firefox have been built, but they only get uploaded once firefox finished to build (or is disabled)
2020-12-02 12:53:46 <Cogitri> What's the problem with FF? Isn't that fixed after I fixed the sandbox patch
2020-12-02 12:53:59 <ikke> Cogitri: no, different error\
2020-12-02 12:54:13 <Cogitri> Yikes
2020-12-02 12:54:17 <ikke> this is on armv7, not aarch64
2020-12-02 12:54:25 <Cogitri> Ah, aarch64 went through?
2020-12-02 12:54:53 <ikke> yes
2020-12-02 12:54:57 <Cogitri> Nice
2020-12-02 12:55:26 <ikke> error[E0432]: unresolved imports `core::arch::arm::float32x4_t`, `core::arch::arm::int32x4_t`, `core::arch::arm::vaddq_f32`
2020-12-02 12:55:29 <ikke> that's on armv7
2020-12-02 12:55:53 <Cogitri> Ah
2020-12-02 12:56:03 <ikke> sOUNDS HOPEFULL
2020-12-02 12:56:10 <ikke> Ups, caps
2020-12-02 12:57:12 <Cogitri> https://doc.rust-lang.org/beta/core/arch/arm/struct.float32x4_t.html
2020-12-02 12:57:23 <Cogitri> > This is a nightly-only experimental API.
2020-12-02 12:57:25 <Cogitri> nice.
2020-12-02 12:57:30 <ikke> :-/
2020-12-02 12:57:35 <ikke> less hopefull
2020-12-02 12:58:09 <Cogitri> I'll look into that later today, I hope there's some way to disable SIMD on armv7 for now or smth
2020-12-02 14:13:59 <Hello71> how does it work on aarch64 then
2020-12-02 14:18:25 <mimi89999> Maybe it has SIMD?
2020-12-02 14:18:34 <mimi89999> and armhf also...
2020-12-02 14:18:48 <mps> no, they don't have
2020-12-02 14:19:14 <mps> not in x86 sense
2020-12-02 14:19:35 <mimi89999> Then maybe the wrong code path was chosen?
2020-12-02 14:20:28 <maxice8> PureTryOut: ping, ,about plasma MR
2020-12-02 14:20:44 <mps> it is called neon on arm
2020-12-02 14:23:54 <PureTryOut[m]2> maxice8: what?
2020-12-02 14:26:21 <maxice8> can you confirm the CI failures on s390x are related to the xorg-server-community move ?
2020-12-02 14:37:38 <ddevault> I'm revisiting my riscv64 port
2020-12-02 14:37:47 <ddevault> can anyone shed some light on what "APK unavailable, skipped" means
2020-12-02 14:39:04 <ikke> ddevault: in what context?
2020-12-02 14:39:13 <ddevault> apk fix
2020-12-02 14:39:46 <ikke> That it does not know where to find the .apk for a package?
2020-12-02 14:39:48 <ddevault> ah, I think I understand why that happens
2020-12-02 14:39:51 <ddevault> thanks
2020-12-02 14:49:19 <PureTryOut[m]2> maxice8: xcb, yes those are related to the move
2020-12-02 14:55:39 <maxice8> PureTryOut: thanks, merged
2020-12-02 14:56:37 <PureTryOut[m]2> Thanks!
2020-12-02 15:01:47 <ikke> maxice8: without pkgrel bump, maintainership is not updated on pkgs.a.o
2020-12-02 15:01:55 <maxice8> oh, yes
2020-12-02 15:01:56 <maxice8> forgot about that
2020-12-02 16:10:47 <ncopa> i hink i know what wrong with mips64 builder
2020-12-02 16:11:34 <ikke> do tell
2020-12-02 16:11:47 <ncopa> build-edge-mips64:~# apk version gcc
2020-12-02 16:11:47 <ncopa> Installed:                                Available:
2020-12-02 16:11:47 <ncopa> gcc-9.3.0-r2                            < 10.2.1_pre0-r2
2020-12-02 16:12:01 <ncopa> it never completed the build of main so it never apk ugprade
2020-12-02 16:12:07 <ikke> aha
2020-12-02 16:12:39 <ncopa> im gonna upgrade it
2020-12-02 16:13:06 <ncopa> hum
2020-12-02 16:14:58 <ncopa> nope, there was a 'gcc<10' in /etc/apk/world
2020-12-02 16:15:07 <ikke> aha!
2020-12-02 16:15:22 <ikke> I guess Ariadne did that when she downgraded GCC
2020-12-02 16:15:28 <ncopa> or me
2020-12-02 16:15:50 <ncopa> it doesnt matter who. i cleaned that up now
2020-12-02 16:16:01 <ncopa> lets see if it builds now. i thikn it wil :)
2020-12-02 17:03:56 <Ariadne> oops
2020-12-02 17:04:52 <Ariadne> ncopa: well its been building for 45 minutes so i think youre right
2020-12-02 17:27:31 <bratkartoffel> !15183 should "fix" the build on build-3-13-armhf
2020-12-02 17:33:26 <Ariadne> i appreciate the quotes on "fix" :D
2020-12-02 17:33:53 <ikke> :)
2020-12-02 17:34:08 <Ariadne> hmm, NEON triggers it
2020-12-02 17:34:24 <Ariadne> smells like in some cases the vector is not properly aligne
2020-12-02 17:34:25 <Ariadne> d
2020-12-02 17:34:43 <Ariadne> that will cause immediate segfault :D
2020-12-02 17:34:45 <Ariadne> (well bus error really)
2020-12-02 17:35:12 <dalias> fun
2020-12-02 17:37:39 <bratkartoffel> isn't there another aport we currently have problems with neon? smells like a bug in gcc?
2020-12-02 17:41:11 <sirlami> I am trying to write instructions to boot alpine on a RockPro64 sbc and I am having trouble with the boot repository. What is the correct way to do this? I use apk fetch --recursive to get all the packages and then apk index and sign with my abuild key but I get some errors about 'package mentioned in index not found...'. I also tried pulling the APKINDEX.tar.gz from the offical repositories but
2020-12-02 17:41:17 <sirlami> then I can only use packages from main. Am I going about this the wrong way?
2020-12-02 17:43:36 <mps> sirlami: I think this question is for #alpine-linux channel
2020-12-02 17:43:51 <ikke> bratkartoffel: firefox on armv7?
2020-12-02 17:44:59 <mps> does gcc on armv7 use default switch for neon
2020-12-02 17:45:53 <mps> and does it support all neon instructions
2020-12-02 17:47:31 <mps> hmm, --with-fpu=vfpv3-d16
2020-12-02 17:48:16 <sirlami> mps: thanks, I will go ask over there. I am also wondering if support for signing with elipitical curve keys is in the works at all? Would be great to be able to sign repositories with my nitrokey
2020-12-02 17:50:26 <mps> sirlami: not sure that EC is in work for apk-tools
2020-12-02 17:53:03 <sirlami> mps: that's a shame but not the end of the world. thanks for your help
2020-12-02 19:02:15 <Ariadne> bratkartoffel: alignment being off could indeed be a gcc bug
2020-12-02 19:54:15 <mps> bratkartoffel: !15044 ready for merge?
2020-12-02 20:23:44 <Thalheim> git is down?
2020-12-02 20:24:08 <Thalheim> (e.g https://git.alpinelinux.org/aports/tree/community/qemu?h=master)
2020-12-02 20:29:15 <ikke> Thalheim: yes, looking at it
2020-12-02 20:29:34 <ikke> Thalheim: it's a problem that appears from time to time, trying to find out what's going on
2020-12-02 20:40:41 <mimi89999> Ariadne: I think that you need to update MariaDB to `10.5.8`. They seem to have removed sources.
2020-12-02 21:02:53 <bratkartoffel> mps: yes, all openjdk MRs are ready to be merged
2020-12-02 21:13:36 <mps> hm, he left, but ok, merged
2020-12-02 21:40:25 <andypost[m]> Ariadne: there's !14284 for mariadb to unblock build
2020-12-02 22:32:47 <Ariadne> andypost[m]: go ahead and merge it
2020-12-02 22:34:40 <andypost[m]> I've no access for master
2020-12-02 22:35:05 <andypost[m]> Main* I mean
2020-12-02 22:36:50 <mps> ok, will do now
2020-12-02 22:37:29 <mps> merged
2020-12-02 22:38:10 <Ariadne> thanks mps
2020-12-02 22:38:34 <mps> np, pleasure is mine to help :)
2020-12-02 22:50:10 <dalias> s390x folks have any thoughts on the patch on the list re: float_t ?
2020-12-02 23:11:20 <Hello71> not sure if any are here
2020-12-02 23:13:29 <Risk64> I accidentally pushed a commit to master branch. When i hard reset to HEAD~1 and force push it gets rejected. How can i delete the commit?
2020-12-02 23:14:52 <ikke> Risk64: If force push is rejected, there is not a lot you can do
2020-12-02 23:15:33 <Risk64> dry-run works though... error is "pre-receive hook declined"
2020-12-02 23:16:08 <Risk64> i also tried --no-verify to disable the hooks.
2020-12-02 23:16:46 <maxice8> Where you pushing to ?
2020-12-02 23:16:54 <Risk64> to my fork
2020-12-02 23:17:05 <Risk64> bluemax/master
2020-12-02 23:17:21 <maxice8> I think GitLab has force-push protect for master
2020-12-02 23:17:47 <maxice8> need to go to settings and disable it
2020-12-02 23:17:59 <Risk64> it makes sense in some way.. but its my commit and my fork.
2020-12-02 23:18:10 <Risk64> i could revert it..
2020-12-02 23:18:36 <maxice8> Settings -> Repository -> Protected Branches [expand]
2020-12-02 23:21:00 <Risk64> I have no 'Repository' o_O
2020-12-02 23:21:07 <Risk64> in 'Settings'
2020-12-02 23:23:36 <Risk64> nvm.. the left-side menu...
2020-12-02 23:23:52 <Risk64> not top-right user settings
2020-12-02 23:24:34 <Risk64> thx maxice8
2020-12-02 23:24:47 <maxice8> Gitlab settings are confusing
2020-12-02 23:30:16 <ikke> Sorry, thought this was #git :P
2020-12-02 23:57:36 <maxice8> always was
2020-12-03 00:17:55 <Ariadne> dalias: i'll respond in a moment on the list, but the IBM person is right that float_t not being float has significant overhead
2020-12-03 00:17:57 <dalias> :)
2020-12-03 00:20:32 <Ariadne> dalias: the s390x fpu is optimized to use single-width floating point values
2020-12-03 00:20:47 <dalias> *nod*
2020-12-03 00:21:00 <Ariadne> double is quite expensive, as it literally uses 2 registers AFAIK
2020-12-03 00:21:41 <Ariadne> or something like that
2020-12-03 00:22:05 <Ariadne> i'm not 100% sure how double works on s390x, but its emulated
2020-12-03 00:22:40 <Ariadne> fftw with real floats is like 4x faster than fftw testsuite with doubles
2020-12-03 00:22:58 <dalias> lovely..
2020-12-03 00:23:51 <dalias> *sigh* i can't find the tracker the docker-for-mac problem was being discussed on..
2020-12-03 00:24:56 <Ariadne> i agree with you that this magic GCC detection thing is probably going to hurt us
2020-12-03 00:26:41 <dalias> i don't think it will actually hurt anything, but i wanted to make sure they weren't doing something ridiculous
2020-12-03 00:26:54 <ikke> dalias: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11879
2020-12-03 00:26:55 <dalias> if you want to keep float_t as double you can just update configure
2020-12-03 00:26:57 <ikke> this one?
2020-12-03 00:27:04 <dalias> but musl should be ready to handle both imo
2020-12-03 00:27:35 <dalias> ikke, yes that's it --- thanks
2020-12-03 00:30:10 <Ariadne> i feel like this will require a rebuild though
2020-12-03 00:31:27 <dalias> no, it won't
2020-12-03 00:31:51 <dalias> float_t is not an ABI type (well, the author of the patch found a couple places it was wrongly being used as one, but they're being fixed)
2020-12-03 00:32:11 <dalias> on i386 it changes definition depending on -mfp-math=sse
2020-12-03 00:32:24 <Ariadne> ok
2020-12-03 00:32:34 <dalias> so i don't think it's a problem at all for it to change dynamically on s390x too
2020-12-03 00:32:55 <dalias> imagemagick might need the patch to take it out of public signatures tho and that might force some rebuilds
2020-12-03 00:33:11 <Ariadne> yeah
2020-12-03 00:33:23 <Ariadne> well its probably fine then :)
2020-12-03 00:33:32 <Ariadne> and the performance gain will be significant
2020-12-03 00:33:50 <Ariadne> like i said, 4x faster on one of my s390x VMs
2020-12-03 00:34:00 <dalias> good news on the dns issue: https://github.com/docker/for-mac/issues/5020
2020-12-03 00:34:04 <dalias> "Thanks, we don't need any more confirmations, we've reproduced it and will fix it."
2020-12-03 00:34:52 <Ariadne> :D :D :D :D :D :D
2020-12-03 00:37:36 <ikke> dalias: nice
2020-12-03 06:37:20 <ikke> maxice8: strange, xcb-util-dev is still listed as being in main: https://pkgs.alpinelinux.org/packages?name=xcb-util-*&branch=edge&arch=aarch64
2020-12-03 07:38:50 <ncopa> morning
2020-12-03 08:21:29 <ikke> o/
2020-12-03 08:37:08 <Newbyte> Does Alpine still support mips (the non-mips64 mips)?
2020-12-03 08:37:22 <ikke> Newbyte: It never supported it in the first place
2020-12-03 08:37:43 <Newbyte> interesting that some APKBUILDs disable mips then
2020-12-03 08:37:51 <Newbyte> anyway, thanks
2020-12-03 08:37:56 <ikke> Newbyte: There were plans to support it
2020-12-03 08:38:06 <Newbyte> aha, got it
2020-12-03 08:52:12 <mimi89999> Maybe Firefox could be disabled on armv7 until it's fixed?
2020-12-03 08:52:19 <mimi89999> I'm still waiting for `xorg-server` on that arch.
2020-12-03 08:52:33 <ikke> any opinions on that? ^
2020-12-03 08:56:06 <mps> fixed if possible. if not then ... who knows
2020-12-03 08:58:02 <mimi89999> Please
2020-12-03 08:58:22 <mimi89999> It's missing since the migration of xorg to community.
2020-12-03 09:00:02 <ikke> Yes, understand
2020-12-03 09:00:29 <ikke> but, also understand that it means firefox will be removed until it's fixed
2020-12-03 09:02:25 <Cogitri> I'll try to look into FF soon
2020-12-03 09:03:55 <mimi89999> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15213
2020-12-03 09:04:14 <mimi89999> Should unblock the build on `mips64`.
2020-12-03 09:04:54 <ikke> Will be merged
2020-12-03 09:05:40 <mimi89999> Cogitri: I also openend https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15136
2020-12-03 09:06:41 <ncopa> what is the problem with firefox on armv7?
2020-12-03 09:12:47 <ikke> It uses a constant that's only on the nightly version of rust
2020-12-03 09:13:05 <ikke> https://doc.rust-lang.org/beta/core/arch/arm/struct.float32x4_t.html
2020-12-03 09:13:10 <ikke> error[E0432]: unresolved imports `core::arch::arm::float32x4_t`, `core::arch::arm::int32x4_t`, `core::arch::arm::vaddq_f32`
2020-12-03 09:14:07 <mimi89999> If it's nightly, it will be released one day...
2020-12-03 09:15:16 <mimi89999> ERROR: zfs: build failed configure: error: /bin/sed does not support in-place
2020-12-03 09:15:31 <bratkartoffel> busybox sed?
2020-12-03 09:15:42 <ikke> bb sed -i requires an argument
2020-12-03 09:15:45 <ikke> sed -i''
2020-12-03 09:16:30 <ikke> so either patch the check, or add sed to (make)depends
2020-12-03 09:16:42 <ikke> (with the preference to the former)
2020-12-03 10:03:27 <ncopa> im on the zfs problem
2020-12-03 10:03:30 <ncopa> i know what it is
2020-12-03 10:03:35 <ncopa> its busybox mktemp
2020-12-03 10:03:49 <ncopa> https://github.com/openzfs/zfs/blob/dcbf8474933cb22b90dbd7f514c8a4c71ea4c1cf/config/always-sed.m4#L7
2020-12-03 10:05:16 <ikke> Does it not support that?
2020-12-03 10:05:31 <ncopa> https://github.com/openzfs/zfs/issues/11274
2020-12-03 10:05:46 <ncopa> busybox requires 6 trailing Xes
2020-12-03 10:06:08 <ikke> ah, ok
2020-12-03 10:06:32 <ncopa> im making an upstream PR
2020-12-03 11:14:50 <ikke> hmm, berry checksum has changed
2020-12-03 11:27:07 <ikke> It has apparently been re-released
2020-12-03 11:27:24 <ikke> commit was 31st of october, release date is 2nd of november
2020-12-03 11:56:29 <ncopa> i think we can delete the files from our distfiles in that case. did you check what the diff is?
2020-12-03 11:57:33 <ikke> ncopa: not yet, but I don't think we have it on our dists, otherwise the builders would not complain
2020-12-03 11:58:29 <ikke> hmm, it is there
2020-12-03 11:59:04 <ikke> s390x is just not setup to fetch from distfiles
2020-12-03 11:59:14 <ikke> I'll check the diff in a moment
2020-12-03 12:04:10 <Ariadne> for ncopa (but also for myself), I present the ifupdown-ng wifi executor: https://github.com/ifupdown-ng/ifupdown-ng/pull/134
2020-12-03 12:21:41 <mimi89999> Same issue in `main/zfs-rpi`?
2020-12-03 14:33:55 <Hello71> ikke: sed -i'' is the same as sed -i, that's how shell works
2020-12-03 14:34:33 <ikke> Hello71: not necessarily
2020-12-03 14:35:09 <Hello71> sed -i\'\'?
2020-12-03 14:35:23 <ikke> Hello71: rintf '%s,' '' '' ''
2020-12-03 14:35:28 <ikke> with a print before
2020-12-03 14:35:31 <ikke> p
2020-12-03 14:35:37 <ikke> it still counts as an argument
2020-12-03 14:36:06 <Hello71> ikke: printf '%s,'''''''
2020-12-03 14:36:29 <Hello71> <@ikke> sed -i''
2020-12-03 14:38:33 <ikke> Hello71: Hmm, I see the backup argument is optional nowadays for sed
2020-12-03 14:38:47 <ikke> Hello71: you are right, it would have required a space
2020-12-03 14:38:51 <ikke> sed -i ''
2020-12-03 14:49:39 <Hello71> mmhmm
2020-12-03 15:00:29 <ikke> ncopa: apparently they forgot to bump the version in config.mk :)
2020-12-03 15:14:29 <ncopa> oh :)
2020-12-03 15:14:56 <ncopa> i had a look at parted test suite. it seems like something is segfautling, but i am not able to find any core file
2020-12-03 15:15:18 <ikke> not even with ulimit -c unlimited?
2020-12-03 15:17:52 <ncopa> correct
2020-12-03 15:18:11 <ncopa> the log says (core generated)
2020-12-03 15:20:36 <ncopa> i got a core by setting core_pattern
2020-12-03 15:52:41 <andypost[m]> I gonna file mr to move php8 to community it could be great addition to 3.13 release notes
2020-12-03 15:53:21 <ncopa> good!
2020-12-03 15:53:51 <ncopa> i suspect that parted segfault is a double free or similar, caught by mallocng: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12161
2020-12-03 15:55:00 <dalias> nice
2020-12-03 15:55:02 <andypost[m]> Should I ping every maintainer of php7* packages about it or instead of issue #12146 I need to warn at mailing list?
2020-12-03 15:56:00 <dalias> ncopa, not a double-free but buffer overflow clobbering the footer
2020-12-03 15:56:20 <dalias> assert(reserved >= 5);
2020-12-03 15:57:35 <ikke> andypost[m]: feel free to add it to the draft release notes on the wiki
2020-12-03 16:02:11 <ncopa> dalias: nice!
2020-12-03 16:04:08 <dalias> i dont see how this could happen though
2020-12-03 16:04:46 <dalias> the memory is allocated by ptt_read_sector for one sectore
2020-12-03 16:06:52 <dalias> which should just turn into a read() of the sector size
2020-12-03 16:07:34 <ncopa> i dont see it either
2020-12-03 16:07:46 <ncopa> nor sure if this is related (i think not) https://git.savannah.gnu.org/cgit/parted.git/commit/?id=b11bbb5a0b5c357816bff424c2a325806d60f20b
2020-12-03 16:07:52 <dalias> if you can run it under a debugger look what's at the memory
2020-12-03 16:09:27 <dalias> i dont see any writes to memory pointed to by s0 tho
2020-12-03 16:12:20 <dalias> ncopa, doesn't look related
2020-12-03 16:13:16 <ncopa> yeah, i dont think either. it was just a shot in the blind. i saw there was a commit in git log touching the file
2020-12-03 16:13:22 <dalias> i love the architecture with useless malloc/free pairs all over the place for fixed-size data structures...
2020-12-03 16:13:32 <ncopa> im trying to figure out how to run this in debugger
2020-12-03 16:13:56 <dalias> yeah that's a major pet peeve of mine
2020-12-03 16:14:17 <dalias> tests where it's non-obvious how to run one in isolation or under a debugger
2020-12-03 16:14:36 <dalias> like wtf is the point of shipping the test if ppl who get the source can't figure out how to debug failures?
2020-12-03 16:14:44 <ncopa> FAIL t7000-scripting.sh (exit status: 1), but i dont know if it was that test that generated this core dump. i think there were more that failed
2020-12-03 16:15:14 <dalias> strace the whole test run and look at which process segfaults ;)
2020-12-03 16:15:30 <dalias> then look back at the execve it came from :)
2020-12-03 16:15:36 <ncopa> ugh...
2020-12-03 16:16:07 <ncopa> so i thikn there are more than one segfault, and i couldnt find the core dump initially either. i had to point core_pattern to /tmp/core
2020-12-03 16:18:06 <ncopa> oh, there is a "make recheck". thats handy
2020-12-03 16:18:21 <ikke> andypost[m]: https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.13.0
2020-12-03 16:19:37 <andypost[m]> ikke: thanks, will do
2020-12-03 16:20:39 <ikke> How does it affect packages that use php extensions?
2020-12-03 16:23:18 <ncopa> ok, i have debugger running
2020-12-03 16:23:54 <ncopa> breakpoint at bsd_probe
2020-12-03 16:23:59 <ncopa> (gdb) p *dev
2020-12-03 16:23:59 <ncopa> $2 = {next = 0x0, model = 0x7ffff7e74ae0 "", path = 0x7ffff7e74950 "/home/ncopa/aports/main/parted/src/parted-3.3/tests/dev-file", type = PED_DEVICE_FILE, sector_size = 512, phys_sector_size = 512, length = 16384, open_count = 2, read_only = 0, external_mode = 0, dirty = 0, boot_dirty = 0, hw_geom = {
2020-12-03 16:23:59 <ncopa>     cylinders = 128, heads = 4, sectors = 32}, bios_geom = {cylinders = 128, heads = 4, sectors = 32}, host = 0, did = 0, arch_specific = 0x7ffff7f61da0}
2020-12-03 16:25:11 <dalias> can you inspect the memory pointed to by s0
2020-12-03 16:26:00 <dalias> particularly the part just before "end" in free
2020-12-03 16:26:08 <dalias> that might give us a clue how it was clobbered
2020-12-03 16:26:14 <ncopa> how do inspect it?
2020-12-03 16:26:31 <dalias> x/1x end-4
2020-12-03 16:26:42 <dalias> x = examine command
2020-12-03 16:27:02 <dalias> /1x = one default-size (32-bit) value in hex
2020-12-03 16:27:28 <dalias> help x gives further details on using the x command
2020-12-03 16:27:48 <ncopa> iam stepping in bsd_probe now. should i let it run till free and where it segfaults?
2020-12-03 16:27:55 <dalias> yeah, try that first
2020-12-03 16:28:09 <dalias> you can come back to the breakpoint if we don't find anything useful from the point of segfault
2020-12-03 16:28:22 <dalias> (maybe putting a watchpoint on the mem we think is getting clobbered)
2020-12-03 16:28:38 <ncopa> (gdb) x/1x end-4
2020-12-03 16:28:38 <ncopa> 0x7ffff7e74378: 0x04b20236
2020-12-03 16:29:22 <dalias> ok so something looks wrong there
2020-12-03 16:29:37 <ncopa> (gdb) bt
2020-12-03 16:29:37 <ncopa> #0  get_nominal_size (end=0x7ffff7e7437c "\367K\255\004", p=0x7ffff7e74140 "") at src/malloc/mallocng/meta.h:168
2020-12-03 16:29:37 <ncopa> #1  __libc_free (p=0x7ffff7e74140) at src/malloc/mallocng/free.c:110
2020-12-03 16:29:56 <dalias> not sure what that data might be
2020-12-03 16:30:17 <ncopa> *s0 is a read sector
2020-12-03 16:30:53 <ncopa> what did you expect to see at end-4?
2020-12-03 16:31:36 <ncopa> maybe i should try run it in valgrind
2020-12-03 16:31:57 <dalias> some number in the range of 5 up to the max slack between sector size (512) and the next-higher mallocng slot class size
2020-12-03 16:33:19 <ncopa> ==10365== 1 errors in context 1 of 3:
2020-12-03 16:33:19 <ncopa> ==10365== Invalid write of size 8
2020-12-03 16:33:19 <ncopa> ==10365==    by 0x48BECF1: ped_disk_probe (disk.c:158)
2020-12-03 16:33:19 <ncopa> ==10365==    by 0x109398: main (duplicate.c:43)
2020-12-03 16:33:19 <ncopa> ==10365==    by 0x48C07EB: ped_disk_new (disk.c:191)
2020-12-03 16:33:19 <ncopa> ==10365==    by 0x48CDACF: bsd_probe (bsd.c:167)
2020-12-03 16:33:19 <ncopa> ==10365==    at 0x48CD226: alpha_bootblock_checksum (bsd.c:148)
2020-12-03 16:33:20 <ncopa> ==10365==  Address 0x49b9a88 is 8 bytes before an unallocated block of size 304 in arena "client"
2020-12-03 16:33:32 <dalias> the data after end looks wrong too if this is a 512-byte allocation
2020-12-03 16:33:37 <dalias> so i suspect a lot of clobbering happened
2020-12-03 16:35:12 <dalias> oh we were looking at wrong probe function?
2020-12-03 16:35:15 <dalias> *sigh*
2020-12-03 16:36:41 <dalias> wtf is this checksum function doing anyway?
2020-12-03 16:36:44 <dalias> the result seems unused..
2020-12-03 16:37:29 <dalias> and yes they're overflowing the buffer by 64 bytes
2020-12-03 16:37:57 <dalias> because they do a checksum operation that checksums 512 bytes of a 512 byte sector, starting at offset 64, and writes the result at offset 512-8
2020-12-03 16:39:44 <dalias> wow there's lots of wrong code here
2020-12-03 16:40:13 <dalias> in another place they're passing a pointer to BSDDiskData to the checksum function
2020-12-03 16:41:32 <dalias> and BSDDiskData seems to be only aligned to 2 bytes, but the checksum function accesses it as 64-bit words..
2020-12-03 16:42:36 <dalias> anyway from the other place alpha_bootblock_checksum is called, it's clear that s0, not &s0->label, should be passed to it
2020-12-03 16:42:41 <dalias> but the result isn't even used here
2020-12-03 16:42:54 <dalias> so the call should probably just be removed
2020-12-03 16:44:22 <dalias> commit a5f69f396713ab8ac1e57458cbb9af552d2c1659 broke it by changing what label means
2020-12-03 16:44:35 <dalias> without changing the call to alpha_bootblock_checksum
2020-12-03 16:44:54 <dalias> ncopa, is this enough info for you to write a good bug report to upstream?
2020-12-03 16:45:42 <ncopa> i was about to ask you could help me write a bug report?
2020-12-03 16:46:09 <ncopa> otherwise i can try tomorrow
2020-12-03 16:48:04 <dalias> ok i can do it
2020-12-03 16:48:40 <dalias> i realized i already have an account on savannah and dont have to hunt for login information
2020-12-03 16:48:56 <dalias> hmm does it even have a tracker here tho..? not sure
2020-12-03 16:50:01 <ikke> our issue: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12161
2020-12-03 16:56:38 <ncopa> https://git.savannah.gnu.org/cgit/parted.git/tree/BUGS
2020-12-03 16:57:13 <ncopa> http://alioth.debian.org/parted/ is down
2020-12-03 16:57:57 <mimi89999> ncopa: Alioth was replaced by Salsa.
2020-12-03 16:58:13 <ncopa> yeah, i remember. I think they want bugs by email: https://lists.gnu.org/mailman/listinfo/bug-parted
2020-12-03 16:58:51 <mimi89999> Can't they get a normal repo on Salsa?
2020-12-03 16:58:57 <ncopa> dalias: please feel free to CC me
2020-12-03 16:59:01 <ikke> looks like they don't want one
2020-12-03 16:59:04 <mimi89999> Or anywhere?
2020-12-03 16:59:59 <ncopa> i need to go. have a nice evening. and thank you very much dalias! i think i owe you another beer...
2020-12-03 17:00:16 <mimi89999> `main/zfs-rpi` also needs that Busybox sed patch.
2020-12-03 17:01:25 <mimi89999> ncopa
2020-12-03 17:01:52 <ikke> I'll copy the changes over
2020-12-03 17:12:40 <ncopa> mimi89999: oh, i thought I added it
2020-12-03 17:42:49 <PureTryOut[m]2> !14945 only seems to fail because of CI running out of memory (I think?) when building qt5-qtwebengine, otherwise it's ready. Could anyone confirm?
2020-12-03 17:47:30 <mps> timlegge: I'm amazed by seeing https://metacpan.org/pod/XML::Sig. I have for about 3 years in my local dir XML-DSig which I'm using for signing files which are sent to one bank
2020-12-03 17:47:43 <mps> planet is so small :)
2020-12-03 17:48:26 <mps> didn't knew your work till now, and found it by 'accident' :)
2020-12-03 18:13:34 <timlegge> mps: lol.  I took over XML::Sig a while back as it was dormant and backported the changes from Net::SAML2 which was my original interest.  Recently I found time to fix a number of issue
2020-12-03 18:18:23 <mps> timlegge: anyway nice to see your work, will steal some 'things' for my local module :)
2020-12-03 18:20:44 <timlegge> mps: I would be interested in hearing of your use case and any test XML field that you might have
2020-12-03 18:21:46 <timlegge> s/field/files/
2020-12-03 18:21:46 <alpine-meetbot> timlegge meant to say: mps: I would be interested in hearing of your use case and any test XML files that you might have
2020-12-03 18:22:07 <mps> timlegge: my use case deviate somewhat from standard because bank didn't implemented their parts correctly
2020-12-03 18:25:37 <timlegge> mps: from what I have seen that does not appear to be unusual.  greatest thing about standards
2020-12-03 18:25:54 <mps> yes :)
2020-12-03 19:13:51 <mps> mesa 20.3.0 is released https://lists.freedesktop.org/archives/mesa-dev/2020-December/224782.html
2020-12-03 19:14:55 <mps> though they usually declare xx.x.1 as stable and it usually takes 2 weeks, so late for 3.13?
2020-12-03 19:16:15 <mps> but this time msg says '20.3.0 is now available for general consumption'
2020-12-03 20:02:08 <Ariadne> i suspect we will have some time
2020-12-03 20:02:40 <Ariadne> the bitrot fight is more intense this release cycle because gcc 10 imo
2020-12-03 20:09:31 <ikke> nod
2020-12-03 20:15:34 <mps> heh, maybe we will have time for kernel 5.10 as -lts
2020-12-03 20:16:53 <Hello71> in theory i think gcc 10 shouldn't be too bad because it's mainly fcommon and other distros have mostly shaken out the bugs
2020-12-03 20:31:55 <Ariadne> i've prepared a new gcc 10.2.1 snapshot, time64 patches are upstream now
2020-12-03 20:32:18 <Ariadne> i am just testing on x86_64, aarch64 and s390x before pushing
2020-12-03 20:33:44 <dalias> :)
2020-12-03 21:35:33 <mps> artok: ping
2020-12-03 21:50:33 <ddevault> what is involved in addressing textrel issues?
2020-12-03 21:54:11 <ikke> https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide
2020-12-03 21:54:51 <ddevault> thanks
2020-12-03 21:55:05 <ikke> Seems to mostly involve handwritten asm from what I read about it
2020-12-03 22:01:01 <mcf> ddevault: just curious, is this related to riscv64?
2020-12-03 22:01:40 <ddevault> mcf: yes
2020-12-03 22:03:26 <mcf> does it work with -no-pie? i think i ran into something similar a while back: https://sourceware.org/bugzilla/show_bug.cgi?id=22263#c22
2020-12-03 22:04:54 <mcf> try the example in the bug description with your toolchain to see if it works
2020-12-03 22:05:25 <ddevault> going to look deeper in a few minutes
2020-12-03 22:05:27 <ddevault> added that to the pile of resources
2020-12-03 22:24:01 <mcf> i just tested with the musl.cc toolchain built today, and get a textrel with the example in that bug: http://ix.io/2Gp9
2020-12-03 22:24:17 <mcf> so i think the binutils bug is still not fixed
2020-12-03 22:24:37 <ddevault> building with -no-pie now
2020-12-03 22:24:42 <ddevault> do you know if it has been reported to binutils upstream?
2020-12-03 22:24:55 <ddevault> and I wonder if this also explains my nghttp2 issue
2020-12-03 22:26:14 <mcf> yes, see the bug i just linked. there is also https://sourceware.org/bugzilla/show_bug.cgi?id=25694 which i think is a dup, but specific to riscv64
2020-12-03 22:26:24 <ddevault> oh, whoops
2020-12-03 22:26:31 <ddevault> I also had gentoo's bugzilla open and mistook them for one another
2020-12-03 22:27:31 <mcf> based on the commits in the log, it looks like several other architectures had this issue too, but were fixed
2020-12-03 22:28:34 <ddevault> yep this fixes it
2020-12-03 22:28:35 <ddevault> thanks mcf
2020-12-03 22:29:55 <ddevault> now let's see if same thing works for nghttp2
2020-12-03 22:30:19 <mcf> i think the fix should be similar to the other architectures, e.g. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9cb09e33e04feb12df2aaa6e81d61b82ad609ce5
2020-12-03 22:30:42 <ddevault> I intend to attempt a fix, but given that I'm bootstrapping a whole architecture I'm sure you can imagine the length of my todo list
2020-12-03 22:30:45 <ddevault> workaround, move on
2020-12-03 22:31:58 <mcf> i briefly looked at it back when i hit the issue, but couldn't figure it out
2020-12-03 22:46:52 <ddevault> not that easy for nghttp2, oh well
2020-12-03 23:02:11 <Ariadne> it would be nice to get riscv64 builder going somehow
2020-12-03 23:02:23 <Ariadne> i have an unleashed board, but qemu is faster
2020-12-03 23:02:39 <ddevault> I have an unleashed board that I'm willing to devote to alpine's use this time around
2020-12-03 23:02:51 <ddevault> once I finish the bulk of main I'm going to start bringing things upstream
2020-12-03 23:03:23 <ddevault> I'll probably do m68k soon as well
2020-12-03 23:07:41 <Ariadne> i'm down to do m68k
2020-12-03 23:07:53 <Ariadne> also ppc64be
2020-12-03 23:07:58 <Ariadne> the main thing blocking any new ports right now is rust
2020-12-03 23:08:13 <Ariadne> i want to make sure we have rust on all new ports moving forward
2020-12-03 23:08:26 <Ariadne> since its gotten its fingers deep into everything
2020-12-03 23:08:27 <ddevault> I intend to suffer through rust sometime next week at the latest
2020-12-03 23:09:02 <ddevault> it's not an option for m68k though
2020-12-03 23:09:22 <Ariadne> i did quite a bit of work preparing it for cross compilation
2020-12-03 23:09:27 <Ariadne> andyeah not an option yet
2020-12-03 23:09:50 <Ariadne> but if we can finish solving cross compilation, we can bootstrap rust on m68k later
2020-12-03 23:10:04 <Ariadne> i ported libucontext and all of that stuff to riscv64 already
2020-12-03 23:10:16 <ddevault> it's broken
2020-12-03 23:10:20 <ddevault> I have some stuff to give you later
2020-12-03 23:10:29 <Ariadne> libucontext is broken?
2020-12-03 23:10:35 <ddevault> yeah
2020-12-03 23:10:38 <ddevault> on riscv64
2020-12-03 23:10:51 <Ariadne> admittedly i only did some basic testing
2020-12-03 23:11:06 <Ariadne> i want to improve the test program to more thoroughly test it
2020-12-03 23:12:21 <Ariadne> anyway, i will happily stand by for your libucontext patches :)
2020-12-03 23:12:37 <Ariadne> since the US is going back into lockdown, we may as well tackle rv64 port
2020-12-03 23:13:01 <ddevault> https://paste.sr.ht/~sircmpwn/88d7a7c641b86c688a53c5e6f5721a3e2df22851
2020-12-03 23:13:07 <ddevault> I'll put this in your inbox in a more useful form later if you wish
2020-12-03 23:15:29 <ddevault> my repository is here https://mirror.drewdevault.com/alpine/edge/ and my aports tree is here https://git.sr.ht/~sircmpwn/aports-riscv64
2020-12-03 23:23:05 <Ariadne> i can grab it in a bit
2020-12-03 23:23:14 <Ariadne> getting some dinner first
2020-12-03 23:30:43 <Ariadne> hmm -fPIC should be part of the build already
2020-12-03 23:31:58 <dalias> rv64 alpine? :)
2020-12-03 23:51:24 <Ariadne> yes
2020-12-03 23:52:10 <Ariadne> i’m particularly interested because fungible is planning to release a series of DPUs (networking SoCs) with rv64 cores
2020-12-03 23:52:49 <ddevault> I put an order in for the new hifive unmatched board
2020-12-03 23:52:58 <ddevault> mini-ITX risc-v? yes please
2020-12-03 23:54:15 <ddevault> my goal is to have most of the port up and running before it arrives
2020-12-03 23:54:48 <Ariadne> unmatched isn’t doing it for me with only 8g ram
2020-12-03 23:55:09 <ddevault> 90% of my RAM goes to tmpfs
2020-12-03 23:55:11 <ddevault> 
ACTION shrugs

2020-12-03 23:57:10 <Ariadne> i guess it wouldn’t be bad for a secondary dev machine
2020-12-03 23:57:54 <ddevault> the other machine I'm working on has 64M of RAM
2020-12-03 23:58:59 <Ariadne> amiga or atari at
2020-12-03 23:59:05 <Ariadne> atari st*
2020-12-03 23:59:07 <ddevault> kiss-68030
2020-12-03 23:59:21 <Ariadne> what’s that
2020-12-03 23:59:33 <ddevault> homebrew m68k computer
2020-12-03 23:59:37 <ddevault> https://retrobrewcomputers.org/doku.php?id=boards:ecb:kiss-68030:start
2020-12-03 23:59:38 <Ariadne> neat
2020-12-03 23:59:48 <Ariadne> i have an amiga with vampire upgrade board
2020-12-04 00:00:04 <Ariadne> roughly equivalent to 600mhz 68040
2020-12-04 00:02:28 <ddevault> nice, that sounds cool
2020-12-04 00:03:51 <Ariadne> it has supports up to 512mb ddr3
2020-12-04 00:04:18 <Ariadne> i was planning on using that for a builder for an m68k port
2020-12-04 00:09:02 <ddevault> it's going to take me at least a month to finish my m68k box
2020-12-04 00:09:10 <ddevault> I won't be starting my port until then but we'll see
2020-12-04 00:09:22 <ddevault> fuck, textrels in doxygen
2020-12-04 00:09:25 <ddevault> this one I do have to deal with
2020-12-04 00:12:03 <Ariadne> MMU-related instructions are not supported. These are rarely used on AmigaOS.
2020-12-04 00:12:13 <Ariadne> well that rules out using the vampire
2020-12-04 00:12:45 <ddevault> whelp
2020-12-04 00:14:41 <ddevault> m68k is almost definitely going to have to be cross-compiled
2020-12-04 00:14:52 <ddevault> I expect my board to compile linux in about 3 days
2020-12-04 00:15:38 <Ariadne> that’s going to be a substantial bit of work to cross enable enough packages
2020-12-04 00:16:12 <ddevault> yes
2020-12-04 00:16:21 <ddevault> I may not upstream the m68k port and instead focus on just what I need
2020-12-04 00:16:50 <ddevault> or I guess we could just set up a qemu builder
2020-12-04 00:16:59 <ddevault> that's probably the only feasible way to mass build m68k packages
2020-12-04 00:17:03 <Ariadne> that’s what debian is doing
2020-12-04 00:17:29 <Ariadne> it’s a shame because of vampire supported mmu instructions it would be ok enough
2020-12-04 00:17:49 <ddevault> I think there are a couple of open m68k implementations
2020-12-04 00:18:10 <ddevault> and it might even be possible to get google to do that free fab run for one of them
2020-12-04 00:18:21 <Ariadne> yeah vampire is one of them you can download the verilog from github
2020-12-04 00:18:30 <ddevault> let's add an MMU to it
2020-12-04 00:18:31 <dalias> ddevault, doxygen also has time64 bugs, or did a few months back :-p
2020-12-04 00:18:45 <dalias> because they imported some shit code that hadn't been updated since 1980-something
2020-12-04 00:19:28 <ddevault> doxygen is also terrible in general and the world would be better off if we moved on
2020-12-04 00:19:32 <ddevault> but such is life
2020-12-04 00:19:44 <dalias> re: cross compile, what about qemu?
2020-12-04 00:19:57 <ddevault> qemu was addressed a couple of lines later
2020-12-04 00:19:58 <dalias> qemu-system-m68k on a high-end x86 should be a lot faster than any m68k hardware
2020-12-04 00:20:03 <Ariadne> that’s what debian is using
2020-12-04 00:20:26 <dalias> ah
2020-12-04 00:20:28 <Ariadne> but qemu emulation sometimes allows things real hardware wouldn’t
2020-12-04 00:20:37 <dalias> does that matter for compiling?
2020-12-04 00:20:46 <Ariadne> could matter for test suites
2020-12-04 00:21:07 <ddevault> another option would be a distcc cluster
2020-12-04 00:21:19 <Ariadne> afaik debian does both
2020-12-04 00:21:29 <Ariadne> multiple qemu instances plus distcc
2020-12-04 00:21:48 <dalias> ah yes distcc with a cross gcc?
2020-12-04 00:21:59 <dalias> that seems like the best choice of all
2020-12-04 00:22:11 <Ariadne> hmmm
2020-12-04 00:22:18 <ddevault> wait, dist AND cross?
2020-12-04 00:22:21 <Ariadne> that is an interesting idea
2020-12-04 00:22:22 <dalias> yes
2020-12-04 00:22:22 <ddevault> I was referring to a native distcc cluster
2020-12-04 00:22:29 <Ariadne> you use distcc to drive cross compilers
2020-12-04 00:22:39 <ddevault> you can use distcc to drive any compi9ler
2020-12-04 00:22:41 <ddevault> compiler*
2020-12-04 00:22:42 <dalias> use distcc to run a cross compiler on your high-end x86 instead of the native compiler
2020-12-04 00:22:42 <Ariadne> allowing the auto shit tests to run on native
2020-12-04 00:22:56 <ddevault> I meant spreading the work out over several m68k boards
2020-12-04 00:23:08 <ddevault> though now that I see what you mean
2020-12-04 00:23:09 <dalias> you'd need 100+ m68k boards to be the same speed as one x86
2020-12-04 00:23:10 <ddevault> that is a good idea
2020-12-04 00:23:20 <ddevault> yeah, but you don't need one x86 to maintain a port
2020-12-04 00:23:40 <Ariadne> it helps
2020-12-04 00:23:59 <Ariadne> mips64 is octeon3 but still quite slow
2020-12-04 00:24:02 <ddevault> I imagine ld would become the bottleneck
2020-12-04 00:24:05 <Ariadne> even with 16 cores
2020-12-04 00:24:19 <dalias> ppl stop nerd-sniping me!
2020-12-04 00:24:31 <dalias> i already nearly got nerd-sniped into writing my linker on twitter today :(
2020-12-04 00:25:14 <ddevault> dalias: well, I also have a z80 board which can run FUZIX
2020-12-04 00:25:25 <dalias> it's so stupid that linkers are slow and memory-hungry. they should use a few tens of kb of memory and very reasonable time
2020-12-04 00:25:40 <ddevault> https://git.sr.ht/~emersion/sld
2020-12-04 00:26:46 <dalias> how complete is it? what does it do?
2020-12-04 00:26:55 <ddevault> it can link some programs
2020-12-04 00:26:57 <ddevault> it links programs
2020-12-04 00:26:59 <halosghost> lol
2020-12-04 00:27:23 <dalias> :-p
2020-12-04 00:27:41 <dalias> well, it looks like it links some minimal subset of programs on x86_64 only :-p
2020-12-04 00:27:47 <dalias> and not sure if it does so correctly
2020-12-04 00:28:06 <ddevault> simon has written a more sophisticated linker in the past, in ocaml
2020-12-04 00:28:15 <ddevault> I trust he has the know-how
2020-12-04 00:28:25 <halosghost> this is probably just me, but using a non-Make build system for C is an immediate turn-off
2020-12-04 00:28:39 <ddevault> I am working on convincing him of this truth
2020-12-04 00:28:41 <ddevault> give me time
2020-12-04 00:28:48 <dalias> my design uses pretty much all the input in-place, minimal working memory
2020-12-04 00:28:48 <Ariadne> let’s rewrite apk in ocaml
2020-12-04 00:29:02 <ddevault> let's not
2020-12-04 00:29:25 <halosghost> (hell, frankly, using non-Makefile for anything is an immediate turn-off for me, but deeply so for C)
2020-12-04 00:30:06 <Ariadne> pkgconf 2 will likely use meson because that’s what the other contributors want and i’m tired of arguing it
2020-12-04 00:30:16 <ddevault> a friend of mine is rewriting meson in C
2020-12-04 00:30:27 <Ariadne> oh thank god
2020-12-04 00:30:38 <Ariadne> i was planning to do that but hadn’t gotten to it yet
2020-12-04 00:30:45 <ddevault> he is... not quite a novice
2020-12-04 00:30:52 <ddevault> https://git.sr.ht/~bl4ckb0ne/boson
2020-12-04 00:30:57 <halosghost> ddevault: can't say that will make me feel better about it (needing an extra makedep that is itself a build system just drives me nuts)
2020-12-04 00:31:25 <dalias> what is meson written in now? i forget
2020-12-04 00:31:26 <dalias> python?
2020-12-04 00:31:32 <ddevault> yes
2020-12-04 00:31:55 <dalias> doesn't it like let you use arbitrary python expressions in its build definition?
2020-12-04 00:31:59 <ddevault> correct
2020-12-04 00:32:02 <ddevault> wait
2020-12-04 00:32:03 <dalias> making it impossible to have a non-python implementation
2020-12-04 00:32:05 <Ariadne> no
2020-12-04 00:32:07 <ddevault> no, it does not let you use python code
2020-12-04 00:32:10 <Ariadne> that’s scone
2020-12-04 00:32:11 <dalias> oh ok good
2020-12-04 00:32:13 <ddevault> it has its own language which looks like python
2020-12-04 00:32:14 <Ariadne> scons*
2020-12-04 00:32:14 <dalias> ah yes
2020-12-04 00:32:24 <dalias> i forget which shit build system is which
2020-12-04 00:32:26 <ddevault> and it's alledgedly not turing complete
2020-12-04 00:32:28 <ddevault> but I don't believe them
2020-12-04 00:32:30 <dalias> :)
2020-12-04 00:32:34 <Ariadne> there is a special place in hell for the scons and waf people
2020-12-04 00:32:42 <Ariadne> i’ll see them there of course
2020-12-04 00:33:14 <Ariadne> these days i mostly use make files
2020-12-04 00:33:22 <Ariadne> and assume your system is a musl system
2020-12-04 00:33:28 <Ariadne> if this isn’t true, sorry
2020-12-04 00:33:31 <Ariadne> (:
2020-12-04 00:33:50 <ddevault> I have some shell scripts which assemble a POSIX makefile and I presume you have POSIX and a C99 compiler
2020-12-04 00:34:21 <halosghost> I just have a Makefile
2020-12-04 00:34:22 <halosghost> ☺
2020-12-04 00:34:32 <Ariadne> i also find sourcehut pleasant for solo projects
2020-12-04 00:34:36 <halosghost> though, my programs are, by-in-large reasonably simple to build
2020-12-04 00:34:40 <ddevault> the shell script was invited to find libraries and identify the C flags supported by the compiler
2020-12-04 00:34:50 <Ariadne> attempts to use it for non-solo projects have not gone so great
2020-12-04 00:34:55 <ddevault> and to deal with some nicities like generating dependencies from headers
2020-12-04 00:35:14 <halosghost> yeah, I have a shell script to check compiler options that I've been poking around with, and I might integrate that at some point
2020-12-04 00:35:30 <ddevault> most non-trivial projects on sr.ht have some peanut gallery demanding it be moved to github
2020-12-04 00:35:33 <ddevault> 
ACTION shrugs

2020-12-04 00:35:47 <halosghost> lol
2020-12-04 00:37:35 <Ariadne> ddevault: you have -fPIC in the libucontext apkbuild for riscv64, did you hit a textrel in the test program?
2020-12-04 00:37:47 <ddevault> I don't recall exactly what I hit
2020-12-04 00:37:51 <ddevault> I have dealt with 600 packages
2020-12-04 00:37:56 <Ariadne> ok
2020-12-04 00:38:01 <ddevault> but it is on my list of things to revisit
2020-12-04 00:38:04 <ddevault> I'll send you a detailed write-up later
2020-12-04 00:38:07 <Ariadne> i’m going to fix the __gregs issue
2020-12-04 00:38:11 <ddevault> thanks
2020-12-04 00:38:17 <Ariadne> i think that’s because the headers changed
2020-12-04 00:38:34 <Ariadne> i did my port using your initial bootstrap
2020-12-04 00:38:51 <ddevault> the latest run is in better shape
2020-12-04 00:39:14 <ddevault> running on upstream kernel and u-boot now
2020-12-04 00:39:20 <ddevault> which was the main thing that made me abandon the earlier attempt
2020-12-04 00:55:12 <ddevault> did anyone try mrustc as a bootstrap path for rust
2020-12-04 01:00:07 <[[sroracle]]> in general? yes
2020-12-04 01:00:11 <[[sroracle]]> but not for rv64
2020-12-04 01:00:31 <ddevault> oh, it only supports x86
2020-12-04 01:00:33 <ddevault> yikes
2020-12-04 01:01:08 <[[sroracle]]> i think what smaeul did for adelie was build an x86 rustc from mrustc
2020-12-04 01:01:17 <[[sroracle]]> and then cross compiled that to our other arches
2020-12-04 01:01:28 <[[sroracle]]> and then went through the painful rebuild cycles to bring it up to date
2020-12-04 01:02:38 <[[sroracle]]> or cross compiled as a last step probably
2020-12-04 01:13:02 <Ariadne> the rust apkbuild has support for cross compilation now but it’s not working right
2020-12-04 01:17:37 <Ariadne> https://git.musl-libc.org/cgit/musl/commit/arch/riscv64/bits/signal.h?id=ab3eb89a8b83353cdaab12ed017a67a7730f90e9
2020-12-04 01:17:39 <Ariadne> aha
2020-12-04 01:17:41 <Ariadne> ok
2020-12-04 01:30:32 <Ariadne> ddevault: try libucontext 0.12
2020-12-04 01:31:18 <ddevault> with or without PIC
2020-12-04 01:33:52 <andypost[m]> Looks build-3-13-ppc64le builder hangs
2020-12-04 02:57:55 <ddevault> Ariadne: 0.12 fixes the one issue but also breaks my -fPIC workaround, weirdly
2020-12-04 05:01:21 <Ariadne> ddevault: hmm.  what happens, exactly.  do you have a compile log?
2020-12-04 05:01:52 <Ariadne> the build system itself uses -fPIC
2020-12-04 05:43:46 <ikke> andypost[m]: seems like it's fine
2020-12-04 08:50:45 <PureTryOut[m]2> Is `abuild checkout` still a thing? The wiki APKBUILD reference mentions it for the `$giturl` variable but I see no mention for it in `-h` or elsewhere on the wiki
2020-12-04 08:52:20 <PureTryOut[m]2> Also the documentation for the `snapshot()` function talks about live APKBUILDs, are there any docs on that?
2020-12-04 09:02:47 <ikke> there is no checkout() function anymore
2020-12-04 09:03:29 <PureTryOut[m]2> So I guess `$giturl` doesn't exist anymore either?
2020-12-04 09:04:18 <ikke> It's used by snapshot()
2020-12-04 09:04:36 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2529
2020-12-04 09:04:42 <ikke> read: the default snapshot function
2020-12-04 09:07:34 <mps> good morning
2020-12-04 09:07:56 <mps> ncopa: ^
2020-12-04 09:09:20 <mps> ncopa: maybe we have 'issue' with linux-virt for aach64 and armv7 with /boot/dtbs-lts, both -lts and -virt put dtb file in same location
2020-12-04 09:10:19 <ncopa> morning
2020-12-04 09:11:04 <ncopa> mps: sound slike it should be fixable
2020-12-04 09:11:41 <mps> yes, I'm working on linux-edge-virt for aarch64 and noticed that
2020-12-04 09:12:06 <mps> now trying to find 'good' solution
2020-12-04 09:12:12 <ncopa> can you please create an issue and I'll look at it with 5.4.82 when that comes
2020-12-04 09:12:53 <mps> will do something when finish and find solution in linux-edge
2020-12-04 09:19:40 <PureTryOut[m]2> ikke: hmm could you update https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#giturl then maybe?
2020-12-04 09:20:45 <PureTryOut[m]2> So the `snapshot()` documentation on the wiki talks about live APKBUILDs, is that still possible and are there any docs on that? I'd be interested for a personal repo of some sorts, a bit like the Arch Linux -git packages
2020-12-04 09:23:35 <ncopa> im dont think the way snapshot() was implemented in abuild was well thought
2020-12-04 09:24:00 <ikke> PureTryOut[m]2: abuild does not support it directly like makepkg does
2020-12-04 09:24:11 <ncopa> i think it might be a good idea to come up with a good solution for it before we document it
2020-12-04 09:24:27 <ncopa> i suppose the problem it tries to solve is fetching things directly from git?
2020-12-04 09:25:07 <PureTryOut[m]2> seems so yes, for cases where the git hosting provider doesn't offer tarballs
2020-12-04 09:25:31 <ikke> The idea is that you have a way to generate a tarbal and upload it somewhere
2020-12-04 09:25:38 <ncopa> i wonder if we should implement fetch from git directly
2020-12-04 09:25:56 <ncopa> the problem is that we need to have a copy of the sources somewhere in our control
2020-12-04 09:25:58 <PureTryOut[m]2> I'd love that personally
2020-12-04 09:26:13 <ncopa> in case they disappear and we need rebuild for whatever reason
2020-12-04 09:26:19 <PureTryOut[m]2> I'm thinking of live packages not meant for aports but for personal or third party repositories
2020-12-04 09:26:54 <ncopa> if we add the feature we'll get request for adding packages in aports. im certain of it
2020-12-04 09:27:08 <PureTryOut[m]2> Sure, but you can just turn those down
2020-12-04 09:27:25 <PureTryOut[m]2> Just as the Arch Linux repos don't accept -git packages either, that's for the AUR
2020-12-04 09:27:49 <ncopa> and there will  likely be disagreements on that among alpine devs
2020-12-04 09:28:21 <ncopa> i wonder if we could come up with a good way to "automatically" create a backup of those cases
2020-12-04 09:29:06 <ncopa> like git clone directly to a tarball or something
2020-12-04 09:30:50 <ikke> git archive
2020-12-04 09:30:59 <ikke> sadly github does not expose this :(
2020-12-04 09:31:15 <ncopa> yes, but i suppose you cannot git archive from a remote repo
2020-12-04 09:31:20 <ikke> you can
2020-12-04 09:31:27 <ikke> gitlab supports it for example
2020-12-04 09:31:40 <ikke> github wants you to use the web interface (ie, curl)
2020-12-04 09:32:48 <ikke> so you can use https://github.com/alpinelinux/abuild/archive/master.tar.gz to get an archive of the latest master
2020-12-04 11:32:50 <Cogitri> Hm, in a package of mine some file gets linked against `glibc` (I suppose it fetches some prebuilt binary), since abuild yells at me: `libc.so.6: path not found`. Not really sure how I'd check what file actually is linked against glibc though
2020-12-04 11:33:44 <ikke> ldd each file?>
2020-12-04 11:34:09 <ncopa> scanelf -Rn DIR
2020-12-04 11:34:29 <maxice8> ncopa: !15247
2020-12-04 11:34:36 <ncopa> scanelf -Rn DIR | grep libc.so.6
2020-12-04 11:34:37 <Cogitri> ncopa: Ah yes, thanks :)
2020-12-04 11:35:09 <ncopa> maxice8: wow! awesome!
2020-12-04 11:35:10 <Cogitri> ikke: That was my first though too, but it's a node app so there are like a bazillion files in the dir so that'd take like an hour to run :D
2020-12-04 11:35:31 <ncopa> scanelf is relatively fast
2020-12-04 11:36:44 <Cogitri> Yup, scanelf was done within a few secs
2020-12-04 11:37:13 <mimi89999> Hello
2020-12-04 11:37:23 <mimi89999> I'm getting `Could NOT find GObject (missing: GObject_LIBRARY)` when building a package
2020-12-04 11:37:29 <mimi89999> WHat dependency am I missing?
2020-12-04 11:37:38 <ikke> glib?
2020-12-04 11:38:22 <ikke> ah, apparently gobject is a separate project
2020-12-04 11:39:03 <mimi89999> Glib is installed
2020-12-04 11:41:05 <Cogitri> GObject is contained within GLib
2020-12-04 11:41:15 <Cogitri> It's the type system GLib uses to get OOP in C
2020-12-04 11:42:18 <mimi89999> So I have gbib-dev
2020-12-04 11:42:36 <mimi89999> glib
2020-12-04 11:43:23 <Cogitri> I guess the CMake or whatever it is of that project is broken then
2020-12-04 12:06:39 <andypost[m]> ikke: as I see ppc64le 3.13 builder does not pull git
2020-12-04 12:08:40 <ikke> andypost[m]: ah, mqtt-exec crashed
2020-12-04 12:09:51 <ncopa> ha! mallocng found another buffer overflow. I start to like this mallocng :)
2020-12-04 12:10:18 <ncopa> and its fixed upstream already: https://github.com/librsync/librsync/commit/d89f2cd4714f717e6cc5468c6066e18f22b5fea6
2020-12-04 12:38:58 <andypost[m]> ikke: edge ppc64le looks stuck as well
2020-12-04 12:41:01 <ikke> it's building openjdk, not sure how long
2020-12-04 12:46:36 <ikke> I don't see openjdk doing a lot, but using a lot of CPU
2020-12-04 12:46:56 <ikke> 3 threads 100%
2020-12-04 12:47:17 <ikke> but strace shows no syscalls being performed
2020-12-04 12:47:18 <andypost[m]> Hm, it lasts > 4 hours
2020-12-04 13:00:05 <bratkartoffel> ikke: can you see where it hangs, e.g. last logoutput?
2020-12-04 13:00:14 <ikke> bratkartoffel: yes, let me check
2020-12-04 13:01:59 <ikke> bratkartoffel: in the test suite
2020-12-04 13:02:04 <ikke> WaitBarrier
2020-12-04 13:02:28 <ikke> WaitBarrier.generic_wb_test_vm
2020-12-04 13:03:13 <bratkartoffel> hmm, could be https://bugs.openjdk.java.net/browse/JDK-8216560
2020-12-04 13:03:55 <ikke> But they mention it returns an error, while here it just hangs
2020-12-04 13:04:24 <bratkartoffel> ah right, should've read the text completely...
2020-12-04 13:49:43 <Hello71> ikke: did you remember to use -f this time? :p
2020-12-04 13:50:24 <ikke> Hello71: I use htop and just strace the individual threads :)
2020-12-04 13:50:42 <ikke> (you can press 's' in htop to strace that process)
2020-12-04 13:51:03 <ikke> Hello71: So yes, I remembered this time :)
2020-12-04 13:51:43 <Hello71> oh, I don't use htop
2020-12-04 13:51:52 <ikke> I use it extensively
2020-12-04 13:53:20 <tehcloud> htop rulz~
2020-12-04 13:59:46 <ncopa> dalias:  i have revisited the gnu make segfault on s390x. it looks like the memory corruption happens in posix_spawn. I pasted the output of debugging session: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12143
2020-12-04 14:05:51 <ncopa> It would make sense if it is the posix_spawn_file_actions that does it.
2020-12-04 14:07:00 <ncopa> the over written variable (nargv)  should be right after the posix_file_actions struct + flags (short)
2020-12-04 14:23:43 <dalias> probably child stack is just too small...
2020-12-04 14:23:58 <ncopa> thats exactly what im thinking too here
2020-12-04 14:24:10 <ncopa> i just googled in which direction stack grows on s390x :)
2020-12-04 14:24:44 <ncopa> i have seen it before that s390x runs out of stack when other arches does not
2020-12-04 14:24:56 <ncopa> i think it may be due to more or bigger registers or whatever
2020-12-04 14:25:58 <dalias> hmm that makes no sense tho
2020-12-04 14:26:14 <dalias> oh no it does
2020-12-04 14:26:15 <ncopa> ok, but why does it only happen on s390x and not x86_64
2020-12-04 14:26:35 <dalias> it griws down but locals in posix_soawn may be below the child stack array
2020-12-04 14:27:09 <dalias> but not caller's locals...
2020-12-04 14:27:17 <dalias> this is weird
2020-12-04 14:27:40 <ncopa> let me try increase the stack size in posix_spawn and see what happens
2020-12-04 14:29:00 <dalias> ok
2020-12-04 14:33:20 <ncopa> yup. chaning it to 2048+PATH_MAX makes it pass
2020-12-04 14:34:38 <ncopa> maybe struct  sigaction and/or sigset_t is bigger on s390x
2020-12-04 14:35:44 <dalias> i'd still like to understsnd mechsnism of how it corrupted caller's frame
2020-12-04 14:36:11 <ncopa> i should give you a login to the machine
2020-12-04 14:36:13 <dalias> but as fix ill increase this size to at least 2k, maybe 4
2020-12-04 14:36:38 <ncopa> not sure how to calculate how much it needs
2020-12-04 14:36:48 <dalias> can you just breakpoint in the caller then watchpoibt on the var that heys clobbered?
2020-12-04 14:37:01 <dalias> gets clobbered*
2020-12-04 14:37:45 <ncopa> let me try
2020-12-04 14:42:02 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12143#note_128077
2020-12-04 14:42:10 <ncopa> __clone () at src/thread/s390x/clone.s:36
2020-12-04 14:43:41 <ncopa> i must admit that s390x assembler is not my strongest programming language :)
2020-12-04 14:45:24 <ncopa> but if i understand things correctly, it happens in the SYS_clone syscall
2020-12-04 14:49:36 <dalias> ok wtf
2020-12-04 14:49:46 <dalias> if true that sounds like a kernel bug
2020-12-04 14:50:14 <ncopa> or its gdb that cannot follow the child?
2020-12-04 14:50:22 <dalias> oh yes..
2020-12-04 14:50:35 <dalias> you need gdb set to follow the child
2020-12-04 14:51:09 <ncopa> set follow-fork-mode?
2020-12-04 14:52:51 <dalias> set follow-fork-mode child
2020-12-04 14:53:50 <ncopa> it leads me back to the same place
2020-12-04 14:57:08 <ncopa> so no difference at all
2020-12-04 14:58:16 <dalias> ?
2020-12-04 14:58:19 <ncopa> i suppose the follow-fork does not work on s390x
2020-12-04 14:58:29 <dalias> seems unlikely..
2020-12-04 14:58:51 <ncopa> i got same result as when not setting follow-fork-mode child
2020-12-04 14:58:52 <dalias> maybe theres a diff one for vfork like forks
2020-12-04 14:59:45 <ncopa> maybe i can set a breakpoint in the child handler
2020-12-04 15:01:02 <dalias> yeah
2020-12-04 15:01:15 <dalias> maybe the watchpoint only lives in thw parent
2020-12-04 15:01:25 <dalias> since it was set there
2020-12-04 15:01:33 <ncopa> sounds plausible
2020-12-04 15:02:04 <ncopa> i wonder how i get the address or nargv though
2020-12-04 15:02:19 <ncopa> (gdb) p &nargv
2020-12-04 15:02:19 <ncopa> Address requested for identifier "nargv" which is in register $r2
2020-12-04 15:02:35 <ncopa> so i can watch it form the child
2020-12-04 15:02:40 <ncopa> or inspect the address
2020-12-04 15:06:07 <dalias> hm if it lives in a register then the watchpoint may ne malfunctioning
2020-12-04 15:06:26 <dalias> since it wouldnt see how its spilled and reloaded
2020-12-04 15:06:52 <Hello71> are there any architectures where you can watch a register?
2020-12-04 15:07:03 <Hello71> https://reverseengineering.stackexchange.com/questions/20919/how-watchpoint-on-register-works
2020-12-04 15:08:12 <dalias> any - singlestep
2020-12-04 15:08:23 <Hello71> i mean in hardware
2020-12-04 15:08:38 <dalias> doubtful
2020-12-04 15:08:40 <Hello71> i guess it would probably slow down the cpu to implement it, even when off
2020-12-04 15:09:02 <Hello71> especially considering register renaming
2020-12-04 15:09:16 <dalias> if so it might be a trick to turn off speculation!
2020-12-04 15:09:29 <Hello71> heh
2020-12-04 15:09:42 <Hello71> i thought you can already do that (system-wide)
2020-12-04 15:09:52 <dalias> no, i wish..
2020-12-04 15:10:28 <Hello71> is it worth making your cpu 20x slower?
2020-12-04 15:10:56 <Hello71> well, 10x, 20x, one order of magnitude or so
2020-12-04 15:11:19 <ncopa> so, if in understand this correctly, the nvargv is in $r6 reg when posix_spawn is called and it is set to something unexpected after the call? does this mean that clone.s should save and restore the $r6 reg ?
2020-12-04 15:11:44 <ncopa> like push $r6, do its stuff and then pop $r6
2020-12-04 15:15:04 <ncopa> dalias: i havea  breakpoint in posix_spawn now, but i dont know how to check the value of original nargv
2020-12-04 15:18:24 <ncopa> i wonder if the problem is that register is getting clobbered
2020-12-04 15:20:32 <ncopa> how does gcc know what registers are being clobbered when calling assembly?
2020-12-04 15:20:57 <dalias> abi contract
2020-12-04 15:21:11 <dalias> maybe clobe.s has this wrong
2020-12-04 15:21:43 <ncopa> where is this documented?
2020-12-04 15:23:46 <dalias> there should be a psabi doc
2020-12-04 15:24:10 <dalias> i think clone.s is wrong and r5,r6 are not supposed to be call clobbered
2020-12-04 15:24:20 <dalias> the watchpoint is not in the syscall
2020-12-04 15:24:36 <dalias> but because the mov on the line above it clobbers r6
2020-12-04 15:25:34 <ncopa> Register 6 is used for parameter passing, and must be saved and restored by the callee
2020-12-04 15:25:41 <ncopa> https://en.wikipedia.org/wiki/Calling_convention#IBM_System/360_and_successors
2020-12-04 15:25:42 <alpine-meetbot> [WIKIPEDIA] Calling convention#IBM System/360 and successors | "In computer science, a calling convention is an implementation-level (low-level) scheme for how subroutines receive parameters from their caller and how they return a result.  Differences in various implementations include where parameters, return values, return addresses and scope links are placed..."
2020-12-04 15:27:41 <ncopa> https://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_zSeries.html#AEN410
2020-12-04 15:28:29 <ncopa> thast contradictory
2020-12-04 15:29:56 <ncopa> according that refspecs doc: Registers r6 through r13, r15, and f8 through f15 are nonvolatile; that is, they "belong" to the calling function. A called function shall save these registers' values before it changes them, restoring their values before it returns.
2020-12-04 15:33:44 <ncopa> yeah, i think musl should save/restore the r6 register
2020-12-04 15:33:51 <ncopa> i dont know how to do so on s390x
2020-12-04 15:41:28 <bratkartoffel> !15273 should fix the czmq build errors on 3.13 builders
2020-12-04 15:48:31 <dalias> gcc can tell us how. i'll look
2020-12-04 16:05:12 <ncopa> i think we can use r7
2020-12-04 16:05:40 <ncopa> but oh, r7 should also be saved
2020-12-04 16:15:32 <mps> building linux-lts on armv7 I see this "date: invalid date 'Fri, 04 Dec 2020 15:41:59 UTC'". what's wrong with this date?
2020-12-04 16:15:48 <mps> strange
2020-12-04 16:16:18 <dalias> ncopa, you can't use something different because the syscall arg register is r6
2020-12-04 16:17:07 <dalias> syscall_cp is also broken in the same way
2020-12-04 16:17:15 <dalias> so i'm amazed that s390x works at all..
2020-12-04 16:18:52 <ncopa> i was thinkign storing r6 in r7 while doing syscall and then copy r7 back to r6
2020-12-04 16:19:06 <ncopa> but the we clobber r7. so i didnt think very far :)
2020-12-04 16:19:18 <nmeum> fyi: SiFive released a new RISC-V devboard for linux development https://www.sifive.com/boards/hifive-unmatched this time it's actually afforadable. hope i can get my hands on one
2020-12-04 16:19:29 <nmeum> might allow for an alpine riscv port :3
2020-12-04 16:20:46 <dalias> http://ix.io/2GuE
2020-12-04 16:20:57 <dalias> http://ix.io/2GuF
2020-12-04 16:21:22 <dalias> so it looks like the abi reserves a slot for saving and restoring each register
2020-12-04 16:22:03 <ncopa> stg	%r6,48(%r15)
2020-12-04 16:22:16 <dalias> and r5 does not need to be saved
2020-12-04 16:22:22 <dalias> let me send you a proposed patch
2020-12-04 16:22:26 <ncopa> r15 is stack register
2020-12-04 16:22:38 <ncopa> i dont understand where 48 comes from though
2020-12-04 16:22:52 <ncopa> clever though to let gcc tell it :)
2020-12-04 16:23:38 <dalias> it's the call frame abi contract
2020-12-04 16:23:46 <dalias> and this is why s390x uses so ridiculously much stack
2020-12-04 16:24:18 <dalias> each function is entered with the caller having setup a frame for saving any reg it might need to save
2020-12-04 16:24:33 <dalias> ibm loves this kinda complex call frame ABI contract
2020-12-04 16:25:14 <dalias> imo it's designed around making things trivial for debugger/unwinder at the expense of moderate runtime cost
2020-12-04 16:25:18 <dalias> and thus a bad design
2020-12-04 16:27:53 <ncopa> its kinda nice with that many general registers though
2020-12-04 16:28:14 <ncopa> not just eax, ebx, ecx and edx
2020-12-04 16:28:24 <Ariadne> libucontext was honestly easiest to implement on s390x
2020-12-04 16:28:39 <Ariadne> access registers are lol though
2020-12-04 16:30:38 <dalias> ncopa, http://ix.io/2GuF <- patch to test
2020-12-04 16:30:44 <dalias> arg no
2020-12-04 16:30:47 <dalias> copy failed
2020-12-04 16:30:54 <dalias> ncopa, http://ix.io/2GuM <- patch to test
2020-12-04 16:34:53 <dalias> ncopa, let me know if that works. i don't even have a test setup to run it at the moment
2020-12-04 16:35:02 <ncopa> im workign on it
2020-12-04 16:35:04 <dalias> ok
2020-12-04 16:35:35 <dalias> note that all you need to do is recompile musl, and you can test without installing a new package, just running the new ldso as a command
2020-12-04 16:35:50 <ncopa> now it segfaults all the time
2020-12-04 16:35:54 <ncopa> even with make clean
2020-12-04 16:35:58 <Ariadne> nmeum: ddevault wants to resurrect his port, and i am working on some riscv stuff this time
2020-12-04 16:36:00 <ncopa> so i guess its not correct :)
2020-12-04 16:36:05 <dalias> ah ok :/
2020-12-04 16:36:14 <Ariadne> s/this time/as well/
2020-12-04 16:36:14 <alpine-meetbot> Ariadne meant to say: nmeum: ddevault wants to resurrect his port, and i am working on some riscv stuff as well
2020-12-04 16:36:15 <ncopa> i nstaleld it as new package
2020-12-04 16:36:36 <ncopa> i should have used it as ldso
2020-12-04 16:36:36 <ddevault> I intend to have my port in good working order in time for my hifive unmatched to arrive
2020-12-04 16:36:46 <ddevault> though it could come to an early stop as I'm currently building llvm with a microSD card as swap
2020-12-04 16:36:47 <nmeum> hehe
2020-12-04 16:36:53 <nmeum> do they start shipping this year already?
2020-12-04 16:36:57 <ddevault> no, Q1
2020-12-04 16:36:59 <nmeum> ah
2020-12-04 16:37:40 <ncopa> my s390x system is broke now :)
2020-12-04 16:37:53 <dalias> that's why you don't install package to test :-p
2020-12-04 16:38:01 <ddevault> I might try swap over nbd, we'll see how the mmc approach goes
2020-12-04 16:38:11 <ddevault> I set swappiness to 20%, it shouldn't thrash much until link time
2020-12-04 16:38:48 <ncopa> yeah.. its friday evening and i shouldnt mess with s390x assembly this time of the day/week :)
2020-12-04 16:38:58 <dalias> did i mess up the branch logic?
2020-12-04 16:39:05 <ncopa> probably
2020-12-04 16:39:08 <Ariadne> i think so
2020-12-04 16:39:16 <ncopa> i wonder why you needed to change the logic
2020-12-04 16:39:19 <dalias> ariadne, can you read this code and figure out what i did wrong?
2020-12-04 16:39:27 <Ariadne> i'm looking at it already
2020-12-04 16:39:32 <dalias> ncopa, because the old code used a bnzr for "return if nonzero"
2020-12-04 16:39:48 <dalias> but the restore-r6 has to be after the "if nonzero" before the return
2020-12-04 16:40:07 <dalias> since otherwise r15 might be in the child and pointing to the end of the stack
2020-12-04 16:40:15 <dalias> whereby 48(r15) is invalid
2020-12-04 16:40:37 <ncopa> ah
2020-12-04 16:41:00 <dalias> actually i think that's also a problem here -- the child calls the function without adjusting the stack pointer properly for a call frame
2020-12-04 16:41:38 <Ariadne> the GPR store/load looks right to me
2020-12-04 16:42:13 <ncopa> Ariadne: the problem is that we need to save/restore the r6 register
2020-12-04 16:42:19 <Ariadne> yes
2020-12-04 16:42:27 <Ariadne> the save/restore is fine
2020-12-04 16:42:40 <ncopa> and its not like x86 where you can push/pop as i understand
2020-12-04 16:42:45 <Ariadne> no
2020-12-04 16:42:57 <Ariadne> you do it the way dalias did it by stg/lg
2020-12-04 16:43:24 <Ariadne> i'm baffled
2020-12-04 16:43:27 <Ariadne> this code looks fine to me
2020-12-04 16:43:40 <Ariadne> it would be helpful to see a coredump i think
2020-12-04 16:43:55 <Ariadne> my guess is that %r15 is clobbered
2020-12-04 16:44:24 <dalias> r15 is stack pointer
2020-12-04 16:44:33 <dalias> i think the crash is in the branch logic for parent vs child
2020-12-04 16:45:41 <dalias> hmm i think we can do the restore unconditionally
2020-12-04 16:45:58 <dalias> because top of clone already justed stack to have a call frame
2020-12-04 16:46:01 <dalias> child stack
2020-12-04 16:46:04 <dalias> so 48 offset is valid
2020-12-04 16:47:05 <dalias> so this should work: http://ix.io/2GuT
2020-12-04 16:49:36 <Ariadne> its strange, because the bz should be fine there
2020-12-04 16:49:51 <dalias> yeah
2020-12-04 16:49:53 <Ariadne> %r2 should be zero in child and non-zero in parent
2020-12-04 16:50:08 <dalias> at least this change is smaller so it's easier to review
2020-12-04 16:54:36 <ncopa> with that patch the thing builds
2020-12-04 16:54:57 <Ariadne> yeah that patch looks fine to me
2020-12-04 16:55:08 <Ariadne> i'm confused on the branching logic though because it seems right to me
2020-12-04 16:55:21 <dalias> it must be some subtlety of the isa i dont understand
2020-12-04 16:55:33 <Ariadne> hmm
2020-12-04 16:55:51 <dalias> thanks for finding this. it was a BIG bug in s390x port, i'm surprised anything worked at all :-p
2020-12-04 16:55:51 <ncopa> it must be something with s390x assembly that *I* dont understand :)
2020-12-04 16:56:21 <ncopa> thank you too, it was a team effort
2020-12-04 16:57:02 <Ariadne> btw
2020-12-04 16:57:48 <Ariadne> you can actually optimize those loads and stores
2020-12-04 16:58:31 <Ariadne> there's hardware-assisted context swapping that can swap multiple registers at once (specified as a range) with a single instruction
2020-12-04 17:00:45 <ncopa> i updated musl in my env with the s390x patch
2020-12-04 17:00:51 <ncopa> are there any good thigns i can test?
2020-12-04 17:00:56 <ncopa> like compiling gcc?
2020-12-04 17:01:10 <Ariadne> hang on, i have a minor optimization
2020-12-04 17:01:24 <ncopa> its friday here...
2020-12-04 17:01:55 <ncopa> i wonder what i could test that tests the syscall_cp.s change
2020-12-04 17:02:22 <ncopa> there have actually ben cases where things has unexpectedly crashed on s390x
2020-12-04 17:02:27 <ncopa> or hung
2020-12-04 17:02:31 <ncopa> this might be related
2020-12-04 17:03:03 <dalias> yes
2020-12-04 17:03:23 <ncopa> im building gcc now
2020-12-04 17:03:34 <ncopa> have a nice weekend everyone
2020-12-04 17:03:44 <dalias> lol how long does it take?
2020-12-04 17:03:51 <ncopa> I'll push it on monday to alpine edge
2020-12-04 17:04:01 <ncopa> i dunno, but im out of here for the weekend
2020-12-04 17:04:04 <dalias> ah i guess its end of day for you now
2020-12-04 17:04:10 <dalias> noon here :-p
2020-12-04 17:04:12 <ncopa> so i was thining of continue on monday
2020-12-04 17:04:38 <ncopa> i'll push it on monday to alpine edge unless Ariadne has a better fix and pushes it
2020-12-04 17:05:06 <ncopa> Ariadne: the test case that triggered it was https://gitlab.alpinelinux.org/alpine/aports/-/issues/12143
2020-12-04 17:05:40 <ncopa> have a nice weekend everyone! and thanks for a great teamwork!
2020-12-04 17:07:02 <Ariadne> dalias: https://tpaste.us/DMrz
2020-12-04 17:08:49 <dalias> ariadne, the optimization can be done as a separate patch if you like but i dont think it matters
2020-12-04 17:09:08 <dalias> i dont want to mix serious bugfix patch with gratuitous changes to save a couple bytes
2020-12-04 17:09:22 <Ariadne> dalias: sure
2020-12-04 17:09:28 <dalias> because it's hard for someone reading to understand what the actual change was if they dont know the ISA well already
2020-12-04 17:09:52 <Ariadne> well it also saves some microseconds ;)
2020-12-04 17:10:50 <dalias> no, it will save a couple nanoseconds out of a multi-microseconds operation
2020-12-04 17:10:58 <dalias> :-p
2020-12-04 17:11:33 <dalias> (these are all "slow" syscalls since they're blocking/cancelable)
2020-12-04 17:11:51 <Ariadne> gotta save the environment somehow
2020-12-04 17:12:12 <Ariadne> every nanosecond consumes carbon and thus counts
2020-12-04 17:12:21 <dalias> 
ACTION throws the ibm mainframe in the dumpster and replaces it with rpi. mission accomplished :-)

2020-12-04 17:12:24 <Ariadne> ok at this point i'm just trolling
2020-12-04 17:13:13 <dalias> iirc someone is actually running legacy s360 mainframes in emulators on rpi :-p
2020-12-04 17:14:00 <Ariadne> hercules is a pretty capable emulator
2020-12-04 17:14:05 <Ariadne> surprisingly so is qemu
2020-12-04 17:14:22 <Ariadne> qemu's s390x implementation is one of hte better ones
2020-12-04 17:30:45 <mps> ncopa: !15276
2020-12-04 17:31:12 <mps> I don't think it is worth issue report, one line change
2020-12-04 17:53:48 <ncopa> Ariadne: so you can save/restore a register range in a single instruction?
2020-12-04 17:53:54 <Ariadne> yes
2020-12-04 17:54:08 <ncopa> That’s pretty cool
2020-12-04 17:54:28 <Ariadne> the swapcontext in libucontext for s390x is only 6 instructions
2020-12-04 17:54:48 <Ariadne> well technically 9
2020-12-04 17:54:55 <Ariadne> we move some registers around
2020-12-04 17:55:20 <ncopa> however i think I’d appreciate even more comments for each line 🙂
2020-12-04 17:59:44 <ncopa> mps: iirc we should store the dtbs directly under /root for rpi, and assume that /boot is the fat boot partition
2020-12-04 17:59:57 <ncopa> but that’s for rpi only I think
2020-12-04 18:02:40 <mps> ncopa: yes for rpis, but not for other SBCs
2020-12-04 18:06:55 <mps> though I proposed (iirc) to use u-boot also for RPis, to have unified layout and boot menus on arm
2020-12-04 18:10:06 <ncopa> Ok. I don’t know how that works
2020-12-04 18:11:34 <mps> simple, adding u-boot.bin as kernel for RPI bootloader and then use it as u-boot is used on other arm systems
2020-12-04 18:12:45 <mps> I plan to prepare short guide when I finish with linux-edge-virt for armv7 and add linux-edge.armhf (for RPi zero)
2020-12-04 18:13:35 <mps> RPi4 should boot by efi, but I don't have to test
2020-12-04 18:45:59 <artok> have package to extract into FAT partition and I'll fire up
2020-12-04 18:46:22 <artok> =)
2020-12-04 19:03:03 <mps> artok: did you tried linux-edge 5.9.x on any RPi
2020-12-04 19:03:40 <artok> not yet
2020-12-04 19:04:03 <mps> ok
2020-12-04 19:04:38 <artok> I might try one now
2020-12-04 19:04:45 <artok> ..if I find SD card
2020-12-04 19:06:15 <mps> huh, if can slide one to you over my desk :)
2020-12-04 19:33:09 <Newbyte> Would an app that primarily consists of a web view viewing a nonfree website (which is fetched from a remote URL, not stored in the app) qualify for being packaged in Alpine if the code actually contained in the package is free?
2020-12-04 19:34:45 <mps> Newbyte: is the source available and is it free
2020-12-04 19:35:58 <mps> curl (and other free tools) can download non free content
2020-12-04 19:36:49 <artok> how come I always forget to add wpa_supplicant into boot at first time...
2020-12-04 19:38:35 <Newbyte> yes, everything that would be packaged is free
2020-12-04 19:38:49 <Newbyte> it would just download nonfree content (which is the primary part of the app)
2020-12-04 19:39:30 <mps> Newbyte: not sure that I understand
2020-12-04 19:42:26 <Newbyte> I'll be more specific: I don't know if this app exists, but I'd like to be able to check Facebook Messenger on my PinePhone, so I was thinking of looking for an app that uses WebKitGTK or something like that to view Facebook but always use the user agent that makes Facebook display the version of the website meant for old/feature phones
2020-12-04 19:42:38 <Newbyte> and if that doesn't exist I was thinking of putting it together myself
2020-12-04 19:43:00 <Newbyte> the question is whether that would be considered free software by Alpine if all it does it view nonfree web content
2020-12-04 19:43:15 <Newbyte> is view*
2020-12-04 19:44:51 <Newbyte> yes, I could do this in a browser, but that's 1. less convenient 2. this wouldn't be very big in itself anyway since it'd use some other browser engine as dependency
2020-12-04 19:46:13 <artok> mps is -edge packed kernel ? it seems so much smaller, and rpi doesn't support packed aarch64 kernel...
2020-12-04 19:46:28 <mps> that 'field' is out of my knowledge, so I can't tell much about it
2020-12-04 19:47:16 <mps> artok: yes, linux-edge aarch64.
2020-12-04 19:48:16 <mps> artok: hmm, you mean RPi boot loader doesn't recognize vmlinuz-edge from linux-edge
2020-12-04 19:48:59 <artok> affirmative
2020-12-04 19:49:13 <mps> huh, ok thanks for try
2020-12-04 19:50:02 <mps> let me fire up rpizero and check
2020-12-04 19:51:09 <artok> vmlinuz-edge is some 6M and -rpi4 is almost 15M
2020-12-04 19:54:19 <mps> yes, on my rpizero it is '4.6M Oct 20 10:29 vmlinuz-edge'
2020-12-04 19:54:45 <mps> and it boots but using u-boot
2020-12-04 19:55:01 <artok> aarch64 is the one that z is not supported, on normal bootloader
2020-12-04 19:55:20 <artok> uboot might know
2020-12-04 19:55:54 <mps> I tend to think so
2020-12-04 19:58:03 <artok> so installation instructions to be searched =)
2020-12-04 19:59:28 <mps> hmm, rpizero boot loader loads and boot vmlinuz-edge but didn't configured it properly, saying can't open ttyS0
2020-12-04 20:00:11 <artok> yah arm6, arm7 you can use packed kernel
2020-12-04 20:01:20 <mps> 
ACTION wonders where to find rpi arm64 to test all this

2020-12-04 20:02:09 <artok> case aarch64 make install ;)
2020-12-04 20:02:36 <artok> make zImage -> make Image has been on my scripts, if used any
2020-12-04 20:03:07 <mps> yes
2020-12-04 20:03:30 <mps> but need hardware to test
2020-12-04 20:03:41 <artok> sure
2020-12-04 20:07:26 <mps> my question should be 'do anyone run linux-edge on arm64'
2020-12-04 20:08:33 <artok> rpi people (users mainly) are looking forward to use mainline kernel
2020-12-04 20:08:54 <artok> and some debian arm64 maintainers also
2020-12-04 20:09:50 <mps> I know, I'm subscribed to debian-arm ML
2020-12-04 20:10:27 <artok> good =)
2020-12-04 20:10:36 <artok> I've just chatted on irc
2020-12-04 20:16:26 <artok> damn... I just erased my working rpi4 usb stick
2020-12-04 20:17:02 <mps> artok: sorry if I was one who initiated that
2020-12-04 20:17:24 <artok> this one is my own fault
2020-12-04 20:17:47 <artok> not marking those as strictly as my music usb sticks =)
2020-12-04 20:18:43 <mps> huh
2020-12-04 20:20:28 <artok> no worries, I have quite clean edge installation now on SD, I'll have setup-disk from that
2020-12-04 20:20:46 <bratkartoffel> wow, could it be that openjdk15 builder on ppc64le finally finished?
2020-12-04 20:21:10 <ikke> bratkartoffel: I killed the hanging process
2020-12-04 20:21:26 <artok> so answer is no.
2020-12-04 20:21:30 <ikke> well..
2020-12-04 20:21:47 <ikke> apparently it did not see this as an error and just continued
2020-12-04 20:21:48 <artok> what is the actual version people use on jdk nowadays?
2020-12-04 20:22:12 <ikke> so it finished building, but not on its own
2020-12-04 20:22:22 <artok> java and node are so weird to me
2020-12-04 20:23:10 <artok> node.js latest into container, yeah it works but nothing works when doing npm install on project folders
2020-12-04 20:23:27 <artok> that dependency hell is just bad
2020-12-04 20:40:57 <mps> ok, just pushed linux-edge-virt for armv7, so we now have linux-edge-virt for x86_64, aarch64 and armv7
2020-12-04 21:01:41 <bratkartoffel> artok: currently our prod software runs on 8 and 11 (both LTS), but development is with the latest version (15). But yes, java versioning got pretty complex with the faster versioning scheme change a few years ago
2020-12-04 21:02:46 <bratkartoffel> ikke: i have no idea why this test hangs, I couldn't reproduce it locally so far. currently looking for a way to disable this one test, although i'm not that glad with it
2020-12-04 21:22:00 <andypost[m]> Maybe it just points to flux test?
2020-12-04 21:24:03 <andypost[m]> Maybe builder was stressed
2020-12-04 22:23:41 <maxice8> lua5.4 MR is ready but I think it is better we delay it until 3.14
2020-12-04 22:24:24 <maxice8> Jirutka mentioned he wants to get rid of all luas except 5.1 (for luajit) and 5.4, sounds like a good idea to me.
2020-12-04 22:37:38 <Ariadne> yeah that's not a transition i thinkwe should do atm
2020-12-04 22:38:13 <Ariadne> dalias: are you going to push the s390x patch to musl git?  also, when is 1.2.2 expected?
2020-12-04 22:43:44 <micahrl> Hello, I'm trying to build a cross compilation environment for aarch64 on an x86_64 host, and it fails trying to build attr. I'm using `CBUILDROOT=/somewhere ./scripts/bootstrap.sh aarch64`, from a checkout of the latest 3.12-stable plus some cherry picks prescribed in https://gitlab.alpinelinux.org/alpine/aports/-/issues/11991 . attr appears to depend on patch, but patch is listed after attr in bootstrap.sh, and moving
2020-12-04 22:43:44 <micahrl> patch ahead of attr fails as well. Am I going down the wrong path here? Doing something wrong? Would appreciate any help.
2020-12-04 22:46:05 <Ariadne> use edge instead
2020-12-04 22:47:09 <micahrl> Ahh ok, I'll do that. Thanks.
2020-12-04 22:48:04 <micahrl> Do I need an Alpine host OS running edge, or can I use the host OS I already have running 3.12.1 and the master branch of aports?
2020-12-04 23:14:20 <timlegge> would "replaces" be appropriate to fix "ERROR: perl-encode-3.08-r0: trying to overwrite usr/bin/enc2xs owned by perl-dev-5.32.0-r0" it does not seem to be quite right
2020-12-04 23:15:08 <timlegge> similar issue for perl-utils
2020-12-04 23:15:53 <Cogitri> You'd probably have to remove the binary from one of the packages
2020-12-04 23:17:41 <timlegge> I guess in that case one would have to depend on the other
2020-12-04 23:17:44 <Ariadne> micahrl: the latter should be fine
2020-12-04 23:18:42 <micahrl> Cool, gracias
2020-12-04 23:19:09 <Ariadne> i havent tested it tho
2020-12-05 00:39:34 <andypost[m]> 3.13 builders can't find bootstrap, is it ok?
2020-12-05 00:39:45 <andypost[m]> Arm ones I mean
2020-12-05 01:53:32 <Ariadne> ?
2020-12-05 01:53:40 <Ariadne> bootstrap for what
2020-12-05 02:46:51 <andypost> ah, for rust
2020-12-05 04:06:57 <dalias> ariadne, yes. this issue held things up a bit
2020-12-05 04:50:08 <micahrl> when I'm running aports/scripts/bootstra.sh and something it builds fails, where can I look at the logs? I'm not sure how to interpret a failure I'm seeing.
2020-12-05 05:07:59 <micahrl> Hmm. Perhaps there are no logs to find... it fails at "libgit2: Analyzing dependencies...". https://pastebin.com/MCrxgBYt, not while compiling or anything.
2020-12-05 05:40:04 <micahrl> Ooh. Fixed that problem, and one other. I had to add busybox as an explicit depends_dev. Once I did that, I ran into it trying to use my system's libz (/usr/lib/gcc/aarch64-alpine-linux-musl/10.2.1/../../../../aarch64-alpine-linux-musl/bin/ld: /lib/libz.so: error adding symbols: file in wrong format).
2020-12-05 05:41:14 <micahrl> Would this be helpful as a bug report somewhere? Encountered this building master branch of aports on an edge x86_64 VM when doing bootstrap.sh for aarch64. Here's a diff that fixed these two issues for me locally. https://pastebin.com/yJGv5GDk
2020-12-05 06:53:45 <Ariadne> that patch is wrong
2020-12-05 06:55:03 <micahrl> yeah, I am just flailing around to make things compile, would appreciate any pointers
2020-12-05 06:55:39 <micahrl> just linked it to show what I did to work around where I got stuck
2020-12-05 07:43:38 <Newbyte> could someone take a look at !14770? s390x finally caught up
2020-12-05 07:54:03 <Newbyte> thanks!
2020-12-05 09:53:15 <afontain_> micahrl: you probably should have zlib in the native makedepends
2020-12-05 11:31:27 <Cogitri> What's the plan for bootstrapping Rust on 3.13? Moving rust-bootstrap to 3.13 repos?
2020-12-05 11:33:04 <ikke> temporarily add rust-bootstrap from edge
2020-12-05 11:33:58 <Cogitri> Okie. At least the x86_64 builder seems to need it now
2020-12-05 11:34:08 <ikke> armv7 as well
2020-12-05 11:34:35 <ikke> armhf
2020-12-05 11:52:30 <ikke> same with go
2020-12-05 11:52:46 <ikke> ah, rust needs cargo-bootstrap as well
2020-12-05 12:16:29 <_ikke_> Cogitri: it's building rust now on x86_64
2020-12-05 12:28:22 <Cogitri> Nice, thanks
2020-12-05 13:43:50 <mps> hmm, 'quiet' kernel command line option doesn't belong to alpine
2020-12-05 14:16:33 <hechos> hi guys, i know this is de dev ch#
2020-12-05 14:17:19 <hechos> but need to know for what reason lo is always DOWN on system?
2020-12-05 14:50:20 <_ikke_> elogind fails with "static declaration of 'reallocarray' follows non-static declaration"
2020-12-05 14:51:01 <_ikke_> Seems like it uses the same name as musl reallocarray?
2020-12-05 14:51:13 <_ikke_> https://git.musl-libc.org/cgit/musl/commit/?id=821083ac7b54eaa040d5a8ddc67c6206a175e0ca
2020-12-05 14:51:32 <mps> is the reallocarray added to musl in latest push on alpine?
2020-12-05 14:51:39 <_ikke_> ^
2020-12-05 14:51:51 <_ikke_> 2020-11-30
2020-12-05 14:52:18 <mps> aha
2020-12-05 14:52:42 <mps> so, it conflicts with something in elogind
2020-12-05 14:52:51 <_ikke_> yes
2020-12-05 14:53:22 <mps> not looked ever in elogind, but I think it needs fix
2020-12-05 14:53:48 <mps> after musl got reallocarray, I mean
2020-12-05 14:54:02 <_ikke_> The signature is the same, except that elogind declared it static, it seems
2020-12-05 14:54:10 <_ikke_> and inline
2020-12-05 14:54:13 <_ikke_> static inline void *reallocarray(void *p, size_t need, size_t size)
2020-12-05 14:54:25 <_ikke_> void *reallocarray(void *ptr, size_t m, size_t n)
2020-12-05 14:54:33 <mps> this should be removed, imo
2020-12-05 14:57:03 <mps> I remember that I added reallocarray pathch to some package few weeks ago but forgot which one :)
2020-12-05 14:58:00 <_ikke_> if !HAVE_REALLOCARRAY
2020-12-05 14:58:14 <_ikke_> So it's already behind a guard
2020-12-05 15:01:05 <mps> ih, meson build
2020-12-05 15:01:38 <_ikke_> right
2020-12-05 15:03:23 <mps> huh, passed in lxc edge, need to update musl-dev probably
2020-12-05 15:03:43 <_ikke_> elogind supports musl, but upstream refuses to add qsort_r
2020-12-05 15:03:46 <_ikke_> lol
2020-12-05 15:04:18 <mps> heh
2020-12-05 15:04:23 <Cogitri> _ikke_: Seems like your nick is with `_` again?
2020-12-05 15:04:47 <_ikke_> right
2020-12-05 15:06:07 <ikke> Cogitri: Are you familiar with meson?
2020-12-05 15:06:40 <ikke> elogind fails to build because it does not detect that musl provides reallocarray now
2020-12-05 15:06:49 <Cogitri> Ah, yes, I know meson
2020-12-05 15:07:02 <ikke> it calls cc.has_function
2020-12-05 15:08:03 <mps> looks like meson doesn't detect reallocarray in elogind
2020-12-05 15:08:07 <Cogitri> Yup, sounds right
2020-12-05 15:08:49 <mps> removing '!' (#if HAVE_REALLOCARRAY) fixes build but didn't fully tested
2020-12-05 15:09:07 <ikke> removing the code would also fix it
2020-12-05 15:09:14 <ikke> but would be nice if the build system properly detected it
2020-12-05 15:09:15 <mps> src/basic/alloc-util.h
2020-12-05 15:09:29 <ikke> trying to find the musl header that defines reallocarray
2020-12-05 15:10:05 <mps> ikke: /usr/include/stdlib.h
2020-12-05 15:10:25 <ikke> mps: I think I needed to do the same (update musl-dev)
2020-12-05 15:10:51 <mps> heh ;)
2020-12-05 15:11:55 <mps> I think I need to prepare another coffee ;-)
2020-12-05 15:15:11 <ikke> ok, found it
2020-12-05 15:15:20 <ikke> needed to add <stdlib.h> to the included headers for that test
2020-12-05 15:17:06 <ikke> https://tpaste.us/BEMR
2020-12-05 15:17:46 <ikke> Cogitri: does that look right?
2020-12-05 15:18:01 <mps> ah, elogind fails on test not on build
2020-12-05 15:18:21 <ikke> it does fail on build
2020-12-05 15:18:33 <ikke> but meson tests if functions are available
2020-12-05 15:18:45 <ikke> and sets the relevant HAVE_* macros
2020-12-05 15:20:57 <ikke> Because it did not detect reallocarray, HAVE_REALLOCARRAY was not defined
2020-12-05 15:20:57 <mps> aha
2020-12-05 15:20:57 <ikke> hmm
2020-12-05 15:21:02 <mps> 
ACTION making coffee and testing aarch64 install under qemu on x86_64 host

2020-12-05 15:22:32 <ikke> hmm, strange, now it fails again :(
2020-12-05 15:22:32 <mps> finally learned a little about zola and making some short alpine guides and notes on web
2020-12-05 15:27:43 <ikke> ugh
2020-12-05 15:27:46 <ikke> I had it working
2020-12-05 15:27:57 <ikke> now I tried to include it as a patch to the APKBUILD, and now it's no longer building :(
2020-12-05 15:30:15 <ikke> Checking for function "reallocarray" : NO
2020-12-05 15:30:48 <ikke> But at some point, I had: Checking for function "reallocarray" : YES
2020-12-05 15:33:26 <ikke> my bad :(
2020-12-05 15:33:46 <mps> I only see 'NO'
2020-12-05 15:33:59 <ikke> Check that last link I sent real good
2020-12-05 15:35:21 <ikke> Checking for function "reallocarray" : YES :)
2020-12-05 15:36:11 <mps> config.h in build dir have '#define HAVE_REALLOCARRAY 0'
2020-12-05 15:36:30 <ikke> It's not a static define
2020-12-05 15:36:34 <ikke> it's dynamically determined
2020-12-05 15:36:39 <ikke> by meson
2020-12-05 15:36:55 <ikke> check meson.build line 594
2020-12-05 15:37:00 <mps> isn't config.h built by meson
2020-12-05 15:37:06 <ikke> perhaps
2020-12-05 15:37:19 <ikke> probably, yes
2020-12-05 15:38:20 <ikke> I'll send a pull request to elogind
2020-12-05 15:39:20 <mps> ah, it expect it is defined in malloc.h
2020-12-05 15:40:20 <ikke> yes
2020-12-05 15:46:48 <ikke> https://github.com/elogind/elogind/pull/181
2020-12-05 15:59:45 <Cogitri> Ah nice 👍
2020-12-05 16:00:09 <Cogitri> lgtm
2020-12-05 16:00:32 <ikke> odne
2020-12-05 16:00:51 <ikke> Cogitri: would this require a pkgrel bump?
2020-12-05 16:01:19 <insep_> ikke: your desc is bit wrong
2020-12-05 16:01:22 <insep_> it references elogind instead of musl
2020-12-05 16:01:50 <mps> insep_: are you sure?
2020-12-05 16:02:09 <insep_> yes
2020-12-05 16:02:10 <ikke> I accidentally used (0) instead of [0]
2020-12-05 16:03:12 <mps> man reallocarray, ' #include <stdlib.h>;
2020-12-05 16:03:16 <mps> '
2020-12-05 16:03:26 <ikke> fixed, thanks insep_
2020-12-05 16:03:41 <ikke> mps: He means the link I added
2020-12-05 16:04:01 <mps> ah, ok. sorry then
2020-12-05 16:06:04 <Cogitri> ikke: I guess it makes elogind use different functionality, so can't hurt
2020-12-05 16:06:21 <ikke> ok, will bump it
2020-12-05 16:07:33 <ikke> done
2020-12-05 16:09:40 <mps> this reminds me that i have to remove patch from quota-tools
2020-12-05 16:29:38 <ddevault> Ariadne: yeah, libucontext still won't build with -fPIC for me, and I'm not sure why
2020-12-05 16:29:55 <ddevault> I suspect https://github.com/kaniini/libucontext/commit/02470ccdd80910edc030af249e6d572f191f570a is to blame
2020-12-05 16:35:00 <ddevault> Ariadne: https://paste.sr.ht/~sircmpwn/245ae13249356a0c67f11682f53e022e9f786490
2020-12-05 16:35:04 <ikke> maxice8: mkmr seems broken for me. After rebasing, nothing is happening
2020-12-05 16:37:00 <ikke> mkmr --target master --origin=gitlab --upstream=origin
2020-12-05 16:39:44 <ddevault> and now I can't get it to build again at all
2020-12-05 16:41:54 <andypost> btw Looks mips-3.13 builder does no react on retry
2020-12-05 16:42:29 <maxice8> Ikke: probably a bad rebase ?
2020-12-05 16:42:41 <ikke> maxice8: happend with multiple branches
2020-12-05 16:42:47 <ikke> and the rebase is fine
2020-12-05 16:43:27 <mps> andypost: maybe it is again not working at all
2020-12-05 16:43:34 <ikke> maxice8: oh, hmm
2020-12-05 16:43:58 <ikke> seems like a rebase was still in progress
2020-12-05 16:43:59 <andypost> mps: as I see edge one works and failed few seconds ago
2020-12-05 16:44:26 <ikke> maxice8: that was probably it
2020-12-05 16:44:28 <maxice8> Ikke: oof
2020-12-05 16:51:11 <mps> huh, FF 83.0 makes my box unusable
2020-12-05 16:51:33 <mps> and always when I open build.a.o
2020-12-05 17:10:57 <Ariadne> ddevault: ok.  will investigate further
2020-12-05 17:11:22 <ddevault> it has something to do with your j exit instruction in startcontext.S
2020-12-05 17:11:28 <ddevault> not sure what the PIC version would be, investigating
2020-12-05 17:13:35 <ddevault> call exit@plt does the trick
2020-12-05 17:13:37 <ddevault> I'll have a patch for you shortly
2020-12-05 17:16:37 <ddevault> Ariadne: patch in your inbox
2020-12-05 17:16:53 <ddevault> I also had to patch musl btw, see their ML
2020-12-05 17:58:10 <minimal> mps: saw you were talking about not having RPI hardware to test aarch64 edge kernel - am happy to help, am currently using RPI3 with Alpine Edge aarch64 currently with lts kernel but interested to test Edge kernel via both stock bootloader and also u-boot. Let me know if you want any help
2020-12-05 18:00:17 <micahrl> I could also help test aarch64 kernels on an rpi 4. I actually am trying to build a cross compilation environment to ultimately build a kernel with right now, on edge.
2020-12-05 18:02:36 <minimal> micahrl: have been meaning to set up a cross compile env myself for a while but haven't found a simple-yet-complete guide to it and haven't had the time to investigate it yet. Wanting to build minimal/stripped-down kernels for RPIs for my own use. Any pointers to good docs would be welcome
2020-12-05 18:05:32 <micahrl> Well, I haven't succeeded yet :). Yesterday I was told here that I should use master branch of aports, and I am building from an edge alpine VM as well. Ran into some problems building libgit2, which I solved via this patch. Was told the patch has problems, and at least needs zlib in the native makedepends instead of where I put it. https://pastebin.com/yJGv5GDk
2020-12-05 18:05:47 <micahrl> Now it's failing on rust, and I haven't looked very hard at why yet
2020-12-05 18:08:08 <minimal> micahrl: sounds like you're building the whole of aports - can't you just cross-compile the basic dev tools (gcc, abuild, etc) to enable you to then use them to build the linux-rpi packages?
2020-12-05 18:18:31 <micahrl> Hmm sorry, dropped offline for a minute there. I was trying to say, I am using aports/scripts/bootstrap.sh, which seems to be the intended way to build a cross compilation environment, but does seem to expect to build one for all of aports. Not sure if there is a supported method with smaller scope.
2020-12-05 18:21:54 <minimal> yeah, I'm not looking to cross-complile the whole aarch64 tree but rather to build just the kernel packages - I currently do build a few other armv7 & aarch64 packages using QEMU which is fine for most packages but the kernel would take days to building using that approach.
2020-12-05 18:23:59 <minimal> For the linux-rpi aarch64 if you look at the buildlog you'll see it only needs 124 packages to be crosscompiled - https://build.alpinelinux.org/buildlogs/build-edge-aarch64/main/linux-rpi/linux-rpi-5.4.81-r0.log
2020-12-05 18:59:41 <mps> minimal: here are my notes about setting u-boot and linux-edge on RPi Z http://arvanta.net/alpine/mailine-rpizw/
2020-12-05 19:01:02 <mps> and I noticed that I forgot uncommenting /etc/inittab to have login prompt on serial console
2020-12-05 19:03:58 <mps> micahrl: here are my short notes how to install alpine aarch64 under qemu on x86_64 host http://arvanta.net/alpine/install-aarch64-qemu/
2020-12-05 19:04:14 <mps> maybe it can be usable to you
2020-12-05 19:05:35 <mps> today I learned a little to use 'zola' and have to consolidate and find dispersed notes I made for alpine and put them there
2020-12-05 19:06:46 <minimal> mps: thanks. Does it work without serial console?
2020-12-05 19:07:57 <mps> it should but I didn't tested because I don't have hdmi cable with this micro (or mini) hdmi which is on RPiZ
2020-12-05 19:10:14 <minimal> mps: re your qemu doc - I've booted a aarch64 sdcard image on Qemu recently using the "-raspi3" option rather than specifying cpu etc. Its a very messy boot though as qemu doesn't emulate the full RPI hardware
2020-12-05 19:11:19 <mps> yes, qemu is good as generic arch emulator but as good for real hardware
2020-12-05 19:11:37 <mps> s/but/but not/
2020-12-05 19:11:37 <alpine-meetbot> mps meant to say: yes, qemu is good as generic arch emulator but not as good for real hardware
2020-12-05 19:12:21 <micahrl> mps: oh cool thanks. I'll try that if I can't get a cross compilation environment working.
2020-12-05 19:13:00 <micahrl> I haven't gotten rust to build, but for my first attempt I'm just going to comment it out -- what I actually want to build right now is a kernel, so maybe I can get by with a rust-less cross compilation environment.
2020-12-05 19:13:28 <mps> and these notes I put there are just that 'notes', not docs or guides
2020-12-05 19:14:59 <micahrl> makes sense.
2020-12-05 19:16:13 <mps> and I have such notes around on my machines, will try to consolidate them in next days (probably weeks) and put there
2020-12-05 19:17:45 <minimal> mps: with the Edge kernel I think you previously mentioned about location of DTB files (and overlays) for u-boot use - yeah, need to ensure that both the existing RPI bootloader (standalone) and also u-boot can agree on where to find them
2020-12-05 19:20:10 <mps> minimal: RPi bootloader expect dtbs in / of boot partition, because that I had to add FDTDIR for u-boot and set it to /dtbs-edge where linux-edge put dtbs files
2020-12-05 19:22:01 <minimal> mps: yupe, the ongoing problem with RPI on Alpine is that the only thing that puts them in right place is "setup-alpine" and upon kernel or bootloader package updates any revised files are not put in the right place.
2020-12-05 19:22:46 <mps> yes
2020-12-05 19:22:57 <minimal> As a kludge for my own RPIs I bind mount the packaged location onto /boot so package upgrades end up putting them in the right place
2020-12-05 19:23:53 <mps> and I hope we will soon switch to 5.10 as next -lts, which have support for RPis and we will not need linux-rpi kernels anymore
2020-12-05 19:24:48 <mps> and we then could switch to u-boot as default bootloader for RPis
2020-12-05 19:25:39 <minimal> I'd like to see existing bootloader kept as an option tho
2020-12-05 19:26:33 <minimal> plus with 5.10 and the upstream support for RPI what haven't for the separate sets of DTB files for RPI, RPI2, RPI4?
2020-12-05 19:26:34 <mps> it will be always installed because it is needed to load u-boot
2020-12-05 19:27:12 <minimal> oops, haven't == happens
2020-12-05 19:27:43 <mps> RPis are mess and not easy for distro to maintain in consistent and clean state
2020-12-05 19:29:10 <minimal> what I meant is are there any DTB files currently in linux-rpi and linux-rpi4 that differ and therefore 2 sets of packaging (for aarch64) still needs to be maintained?
2020-12-05 19:29:51 <mps> though I think that I read somewhere that RPi4 can boot by uefi, which will simplify it
2020-12-05 19:31:01 <mps> RPi4 is arm64 while RPi 2 (3?) are arm32, so they have different dtbs
2020-12-05 19:31:53 <minimal> but more recent RPI2s and also RPI3/3+ are also aarch64
2020-12-05 19:32:06 <mps> iirc, some RPi3 are arm32 while some are arm64, thanks RPi for mess
2020-12-05 19:32:38 <minimal> the Alpine aarch64 linux-rpi package is for RPI3, RPI3+ and the set of RPI2 that do 64bit s well)
2020-12-05 19:32:51 <mps> huh
2020-12-05 19:33:10 <minimal> I don't have any RPI4s currently - I've been running Alpine aarch64 on RPI3 and RPI3+ for months
2020-12-05 19:33:18 <mps> I knew they are mess, but didn't knew how big mess it is :)
2020-12-05 19:34:25 <minimal> basically (from memory) all RPI3+ are 64bit CPUs, some RPI3 are 64bit as they changed the CPU after 1 or 2 revisions, and AFAIK with recent RPI2 revisions to save costs the standardised on the same CPUs as in RPI3/3+
2020-12-05 19:34:38 <minimal> I could be wrong about the RPI2 but its correct about RPI3/3+
2020-12-05 19:35:22 <mps> yes, I remember that RPi3 are arm64
2020-12-05 19:35:31 <minimal> the RPI3 sitting in front of me that I use as my Alpine testbox is a 3 v1.2 (not a 3+) and its fine with aarch64
2020-12-05 19:37:18 <minimal> to quote from https://en.wikipedia.org/wiki/Raspberry_Pi, "The Raspberry Pi 2 was released in February 2015 and initially featured a 900 MHz 32-bit quad-core ARM Cortex-A7 processor with 1 GiB RAM. Later versions featured a 1.2 GHz 64-bit quad-core ARM Cortex-A53 processor."
2020-12-05 19:38:27 <mps> aha, good to remember (what I probably will not :) )
2020-12-05 19:39:34 <mps> anyway, I think we will have linux-rpi for next stable alpine release, so not much will be changed
2020-12-05 19:39:48 <minimal> my point about the DTBs is that I was wondering if all the files packages in aarch64 linux-rpi (for RPI2 and RPI3) and linux-rpi4 are identical (and so can be merged) - or do any different between RPI4 and non-RPI4?
2020-12-05 19:40:49 <mps> I think they are not identical but all have different file names and could safely put in same dir, i.e. /
2020-12-05 19:41:48 <minimal> also re: u-boot-raspberrypi - it had a missing dependancy on raspberrypi-bootloader. I'm also wondering is it only using bootcode.bin from that package or does it need the other files as well?
2020-12-05 19:42:29 <minimal> re: DTBs - must make some time to do a binary diff/sha256sum of the files in both packages to check
2020-12-05 19:43:29 <MY-R> here is a nice table with rpi's https://en.wikipedia.org/wiki/Raspberry_Pi#Specifications
2020-12-05 19:43:29 <alpine-meetbot> [WIKIPEDIA] Raspberry Pi#Specifications | "Raspberry Pi () is a series of small single-board computers developed in the United Kingdom by the Raspberry Pi Foundation in association with Broadcom. Early on, the Raspberry Pi project leaned towards the promotion of teaching basic computer science in schools and in developing countries. Later, the..."
2020-12-05 19:43:37 <mps> bootcode.bin is from RPi bootloader, iirc
2020-12-05 19:43:56 <MY-R> so ye, kind of mess, have to watch at revisions
2020-12-05 19:44:23 <mps> MY-R: heh, broadcom, worst choice in arm world
2020-12-05 19:44:46 <MY-R> but isnt so bad, need check twice with rpi2
2020-12-05 19:45:12 <MY-R> mps: ye I dont like what broadcom doing too :/
2020-12-05 19:47:03 <minimal> mps: yeah I meant that the u-boot-raspberrypi package should depends on rasyberrypi-bootloader because of the bootcode.bin file. Also I've been intending to submit a MR to modify raspberrypi-bootloader package to create a new raspberrypi-bootloader-common package with just bootcode.bin in it and have raspberrypi-bootloader/bootloader-cutdown/bootloader-experimental depends on raspberrypi-bootloader-common. Reason for this is I use the
2020-12-05 19:47:03 <minimal> cutdown bootloader but have to install the main bootloader package (including the non-cutdown files) just to get the bootcode.bin file.
2020-12-05 19:49:37 <mps> hmm, I think there should start.elf and/or start4.elf also
2020-12-05 19:49:46 <mps> should be*
2020-12-05 19:50:19 <mps> maybe also fixup.dat
2020-12-05 19:50:53 <minimal> that's why I was asking what u-boot needed - cutdown uses start_cd.elf and fixup_cd.elf
2020-12-05 19:52:06 <mps> I read about that 6 months, and not sure now what exactly is needed
2020-12-05 19:52:09 <minimal> so does uboot use start.elf and fixup.elf at all?
2020-12-05 19:52:19 <mps> 6 months ago*
2020-12-05 19:53:10 <mps> no, u-boot don't need anything of these, but these is needed for bootloader to load u-boot
2020-12-05 19:54:22 <minimal> anyway if it does need then then having a dependancy on raspberrypi-bootloader which would then depend on raspberrypi-bootloader-common to pull in bootcode.bin would work for u-boot and would let me install only raspberrypi-bootloader-cutdown (which would pull in raspberrypi-bootloader-common) without raspberrypi-bootloader to use the cutdown bootloader (so saving memory)
2020-12-05 19:55:49 <mps> hm, these are not big files for boot partition
2020-12-05 19:56:31 <minimal> mps - that's what I was asking - the u-boot-raspberry package needs some sort of dependancy defined to pull in a working RPI bootloader and I was asking what files of the RPI bootloader does it need so if/when I raise a MR on raspberrypi-bootloader (to split out common file) and u-boot-raspberrypi (to add dependancy) that my MRs won't break u-boot for you
2020-12-05 19:58:57 <mps> if it boots 'normal' RPi it will not break u-boot
2020-12-05 19:59:35 <minimal> its not just about size - there's already a dependancy missing for raspberrypi-bootloader-cutdown as I found a while ago when I installed it but not raspberrypi-bootloader as it didn't work (due to missing bootcode.bin file).
2020-12-05 20:02:19 <minimal> was wondering if u-boot would also work with cutdown - as cutdown doesn't initialise all the RPI hardware you can reduce the graphics memory "stolen" compared to normal bootloader.
2020-12-05 20:02:51 <minimal> and potentially reduce power usage
2020-12-05 20:03:38 <mps> I can't tell anything about this because I didn't tried and tested this
2020-12-05 20:04:07 <minimal> fair enough - you know more about u-boot on RPI than I do though ;-)
2020-12-05 20:05:07 <mps> I'm using one RPiZ only to testing alpine tarballs when they are released, and in last time testing mainline kernels, nothing else
2020-12-05 20:05:30 <mps> I don't use RPis for anything serious
2020-12-05 20:11:25 <minimal> depends on what you mean by serious - I'm using them with PoE as DHCP servers, NTP servers, DNS resolvers, etc
2020-12-05 20:13:36 <mps> I'm using 'better' (more friendly to linux) SOCs for a lot of 'things'
2020-12-05 20:14:15 <mps> my workstations and servers are arms for more than 5 years
2020-12-05 20:14:42 <mps> actually, last intel box I bought 8 (or more) years ago
2020-12-05 20:15:45 <mps> problem is, alpine works very fine on these old intel boxes so I can't simply throw them 'over the fence' :)
2020-12-05 20:19:03 <minimal> I still have a Pogoplug here doing a few basic network duties :-)
2020-12-05 20:23:30 <MY-R> Im thinking about another arm since I set up rpi4 as a router... I have 100mbit internet so didnt even bother to buy any extra usb nic, vlan's working great
2020-12-05 20:28:00 <MY-R> and ye, basic services like minimal :P but I'm thinking about gps module for ntp
2020-12-05 20:28:34 <insep_> mps: do your phones run alpine? :P
2020-12-05 20:29:07 <ikke> 
ACTION mumbles pmos

2020-12-05 20:29:09 <mps> insep_: one old nokia n900 yes :)
2020-12-05 20:29:41 <minimal> MY-R: yeah have a RPI with a GPS hat as one of my NTP servers
2020-12-05 20:30:03 <mps> and when you prepare pmos for yotaphone2 please inform me, I will for sure install in ;)
2020-12-05 20:30:37 <MY-R> minimal: yeah! is great to have own super accurate clock :P
2020-12-05 20:30:56 <insep_> mps: wait do you really have yotaphone2?
2020-12-05 20:31:00 <insep_> HYYYYYYYYPE
2020-12-05 20:31:05 <minimal> My-R: and another PI with a radio (atomic) clock receiver.......
2020-12-05 20:31:30 <insep_> feel free to join #postmarketos-mainline then, someone might help you with mainlining this
2020-12-05 20:31:40 <minimal> you need 3+ sources to have accurate time....
2020-12-05 20:31:43 <insep_> and join ##linux-msm in advance
2020-12-05 20:31:44 <MY-R> minimal: oh yeah I was thinking about DCF77 too
2020-12-05 20:32:00 <insep_> just don't expect gpu work well
2020-12-05 20:32:12 <insep_> mobile data might work though
2020-12-05 20:32:30 <minimal> MY-R: yupe DCF77 is what it used. Thought about MSF but its not as accurate but did see a relatively cheap radio module for that referently so might get one
2020-12-05 20:32:51 <insep_> audio won't in current state of the art, but i've heard about some work on it
2020-12-05 20:33:10 <insep_> screen might be tricky though, but let's hope for the best lol
2020-12-05 20:33:38 <mps> insep_: yes, I have it about 5 years iirc
2020-12-05 20:33:39 <insep_> oh god i wanted this phone back in a day
2020-12-05 20:34:30 <MY-R> minimal: for now got RTC with battery in case of missing internet, so is still enough then some delay with GPS and would use it even that as a single source or together with ntp servers dunno yet
2020-12-05 20:36:12 <mps> insep_: I have to say big thanks to you and pmos for helping me to install alpine on nokia n900
2020-12-05 20:37:15 <minimal> MY-R: using a RPI? I put in a MR recently to get the RTC drivers build into the kernel rather than as loadable modules so the system time is set from RTC very early in boot. Have RTCs fitted on all my RPIs.
2020-12-05 20:38:40 <mps> ikke: I have linux-n900 in branch of aports, even thought to push it but not sure will it be usefull for alpine users
2020-12-05 20:39:03 <ikke> no idea
2020-12-05 20:39:10 <mps> linux-n900 branch*
2020-12-05 20:39:49 <mps> n900 was quite popular for linux users/developer when it was on market
2020-12-05 20:39:57 <MY-R> minimal: ye I saw MR about it, now wondering if I should put hwclock in "sysinit" instead of current "boot"
2020-12-05 20:40:48 <ikke> mps: yes, I recall that
2020-12-05 20:42:12 <mps> I have two, one is fine but one is broken, some connectors are desoldered
2020-12-05 20:42:36 <minimal> nope, put osclock instead of hwclock if you're using ntp
2020-12-05 20:44:25 <minimal> MY-R: short answer: you don't need hwclock if you have an RTC and have NTP setup, they kernel will take care of it magically for you with no additional software :-)
2020-12-05 20:45:10 <minimal> but you have to enable osclock to replace hwclock/swclock as other init.d service have a clock dependancy which osclock satisfies
2020-12-05 20:45:21 <MY-R> minimal: hmm I need to test it because my system time is correct only after hwclock run in "boot" process and never seen it earlier
2020-12-05 20:47:05 <minimal> MY-R: hwclock is designed to set system clock from RTC at boot and update RTC from system clock during shutdown
2020-12-05 20:48:43 <minimal> MY-R: with an RTC driver built into kernel then kernel will set system time to RTC very early in boot (before initramfs is even loaded) and as long as system clock is synced with NTP then kernel will sync RTC with system time every 10 minutes - so no need for any additional software
2020-12-05 20:50:23 <MY-R> minimal: hmm if that would be true then my system clock should be already correct before init system start and isnt
2020-12-05 20:51:58 <mps> MY-R: if kernel have enabled option to read rtc on boot
2020-12-05 20:52:07 <minimal> MY-R: I'm assuming (a) you're running Alpine Edge as the MR is only in Edge currently, and also (b) that you're using a RTC on your RPI that is supported by the builtin driver (DS1307 and compatibles)
2020-12-05 20:52:18 <mps> and the rtc driver is built in
2020-12-05 20:52:39 <MY-R> oh damn, forgot I'm using 3.12 and I thought that change was already in 3.12 ...
2020-12-05 20:52:45 <minimal> nope
2020-12-05 20:52:48 <MY-R> or it is, wait
2020-12-05 20:54:29 <minimal> as an alternative what you can do is in /etc/mkinitfs/mkinitfs.conf add rtcrpi to the list, and possible tweak the related file inside the features sub-dir, then use mkinitfs to rebuild your initramfs file - this will load the kernel modules as part of the initramfs
2020-12-05 20:55:37 <minimal> however this is a partial fix - you will still see "clock skew" message during boot as when OpenRC first runs the system clock has not yet been set by the kernel modules - that's why I submitted the MR to build the drivers into the kernel
2020-12-05 20:56:45 <mps> every alpine user should build its own kernel :)
2020-12-05 20:57:00 <MY-R> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12317/diffs#diff-content-c83f2f869857671c787d47860c3224fb76d954eb
2020-12-05 20:57:08 <MY-R> is about those 3 changes in kernel, right?
2020-12-05 20:59:14 <MY-R> I have got those 3 lines in 3.12 in /media/mmcblk0p1/boot/config-rpi4
2020-12-05 20:59:59 <minimal> My-R: that's one of my MRs but I'd missed that the RPI I2C driver also needed to be builtin - so a 2nd MR was needed as well: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14200
2020-12-05 21:00:54 <MY-R> and I have "rpirtc" in mkinitfs.conf too
2020-12-05 21:00:56 <MY-R> ahh
2020-12-05 21:01:14 <minimal> MY-R: with the 1st change but without the 2nd change then if you do a "dmesg | grep -i rtc" you should see an error message as kernel can't see RTC
2020-12-05 21:01:36 <MY-R> ye, exactly
2020-12-05 21:02:27 <MY-R> thanks, so that is why it didnt work pff damn! CONFIG_I2C_BCM2835=m
2020-12-05 21:04:07 <MY-R> mps: agree with kernel, dont you have any nice script to build aarch64 kernel? (cross compile) :D
2020-12-05 21:04:12 <minimal> the i2c-bcm2835 will be loaded by initram later in the boot sequence but *IT IS TOO LATE* as the kernel sets the system clock from the RTC very early in the boot - before initramfs will load the i2c BCM driver. So in that case, yes the clock will be set eventually but the kernel "RTC<-->system clock auto-sync when NTP in use" functionality will no be active
2020-12-05 21:05:22 <mps> MY-R: I have such scripts, but must on debian or other distro which have cross toolchain :)
2020-12-05 21:05:38 <mps> must run*
2020-12-05 21:05:46 <minimal> MY-R: that's how I ended up talking to mps a couple of hours ago - ideally I want to cross-compile linux-rpi for exactly this sort of reason - if I'd been able to do so previously then it would only have take 1 MR, not 2, to get this functionality into kernel
2020-12-05 21:05:52 <MY-R> minimal: great! thanks for info I have wrong assumption that "dtoverlay=i2c-rtc,ds3231" line in usercfg.txt will deal with it :\
2020-12-05 21:06:55 <minimal> MY-R: I have a note (far down) on my list to write something for the Alpine Wiki about this. Going full circle, once you have this working then enable the osclock init service, not hwclock
2020-12-05 21:07:02 <mps> but building kernels on alpine in lxc on aarch64 for armv7/armhf is easy
2020-12-05 21:07:52 <mps> I have one arm64 with 4GB ram and ssd disk on usb and it works quite fine
2020-12-05 21:08:25 <minimal> mps: how long does it take to build RPI kernel on aarch64?
2020-12-05 21:08:32 <mps> yesterday I built two kernels on it in about hour or two
2020-12-05 21:09:02 <MY-R> I just set up qemu with alpine x86-64 (like host machine) and used "scripts/bootstrap.sh aarch64" to build all what needed and added there "linux-rpi4" but ye that need trim down little scripts and kernel cus it trying build too much
2020-12-05 21:09:15 <mps> minimal: depends on machine, how -jN is applicable
2020-12-05 21:09:59 <minimal> mps: yeah I thought originally you were referring to using a RPI for it........that would take forever
2020-12-05 21:10:54 <minimal> have a spare 8-core x86_64 that I want to setup cross-compile envs on for armv7 and aarch64
2020-12-05 21:11:06 <mps> doesn't RPi4 have 4GB ram?
2020-12-05 21:11:46 <MY-R> I think rpi4 will build kernel faster than VM aarch64 on x86 host :D
2020-12-05 21:11:59 <MY-R> where on host is some older i5
2020-12-05 21:12:06 <minimal> mps: there's an 8GB model of RPI4 now. However I currently have don't have a RPI4 and memory is not the limitation
2020-12-05 21:12:20 <mps> I build kernels in lxc on my chromebook with 4GB ram with -j2, while browsing, reading mail, chatting and other tasks
2020-12-05 21:14:10 <MY-R> but ye, thanks minimal for clarification and tip with osclock :)
2020-12-05 21:14:17 <minimal> MY-R: so the 2nd kernel change will obviously appear in 3.13
2020-12-05 21:14:53 <MY-R> yep, wondering how my upgrade will go :D setup-bootable working fine?
2020-12-05 21:15:04 <minimal> MY-R: no worries, I've already had to explain the intricacies of how this works to someone before :-)
2020-12-05 21:16:04 <minimal> MY-R: dunno, don't use the setup scripts as all - I've my own Ansible playbook to build prepared SD Card images (complete with cloud-init for initial system config) that I use to set up new machines
2020-12-05 21:16:24 <MY-R> mps: I would be very glad for that script/notes anything because ye... I like building kernels :D
2020-12-05 21:16:34 <minimal> I just "dd" the relevant image onto an SD Card, stick it in the RPI, and turn it on
2020-12-05 21:17:39 <minimal> MY-R: 1 gotcha alert that comes to mind that I was chatting to mps about earlier - the RPI files in /boot for DTBs and bootloader will not be upgraded properly
2020-12-05 21:17:46 <MY-R> minimal: ye I will try do it "live" since rpi4 is my main router :D if wont work then manualy copy to sdcard and think about better script
2020-12-05 21:18:18 <MY-R> minimal: well, that wont be the problem cus I will replace them all during that process or mount /media/mmc* to /boot
2020-12-05 21:19:34 <mps> MY-R: np, but when I found them on archive disks
2020-12-05 21:19:46 <mps> find*
2020-12-05 21:19:48 <MY-R> mps: no rush
2020-12-05 21:20:58 <minimal> As a kludge I have the boot partition bind mounted to /boot in /etc/fstab and also have /boot/dtbs-rpi2 (replace name accordingly) bind mounted to /boot/
2020-12-05 21:21:45 <MY-R> I still have to chill after last time when tried to do it but when saw that linux-rpi4 built fine but was error to create package cus I trim down too much APKBUILD kernel package... then gave up but I was on good path :)
2020-12-05 21:22:10 <MY-R> minimal: ye good idea (noted) !
2020-12-05 21:23:05 <minimal> MY-R: its a nasty kludge but so far there's been no real sign of a proper solution appearing (at least for the config.txt, usercfg.txt files)
2020-12-05 21:23:46 <MY-R> ye
2020-12-05 21:24:26 <MY-R> and speaking about cross-compile, scripts/bootstrap.sh could do it without problem but script need little more love :)
2020-12-05 21:27:27 <minimal> MY-R: well if you figure it out let me know - trade you for the help I gave with the RTC stuff ;-)
2020-12-05 21:28:32 <MY-R> it working just fine but the problem is that building too much for that simple task
2020-12-05 21:29:14 <minimal> that's what I meant, how to trim it down to just sufficient to build kernels
2020-12-05 21:30:39 <MY-R> is community/rust needed to build kernel? :P
2020-12-05 21:32:26 <minimal> no.............not yet!
2020-12-05 21:33:07 <minimal> there are Linux kernel maintainer discussions about whether to use Rust for portions in the future
2020-12-05 21:34:48 <MY-R> oh
2020-12-05 21:35:58 <mps> don't worry, there were long discussions to use c++ :)
2020-12-05 21:36:32 <minimal> just as long as NodeJS isn't an option......
2020-12-06 00:55:50 <hg> the discussions on Rust (afaik) is really only about making it possible/reasonable to include modules written in Rust
2020-12-06 00:56:04 <hg> not really discussions about rewriting any inherent portion (that I've seen so far)
2020-12-06 01:28:43 <Ariadne> regardless of whether linux kernel uses rust, many other important packages are beginning to.
2020-12-06 01:33:39 <ddevault> linux architectures ⊃ rust architectures
2020-12-06 01:33:47 <ddevault> so long as that's true, I doubt we'll see any major incursion of rust into linux
2020-12-06 01:51:27 <Ariadne> yes, anyway
2020-12-06 01:51:41 <Ariadne> community/rust is in bootstrap path because we want it to be available on all archs
2020-12-06 02:26:00 <Ariadne> ddevault: if you have a moment, can you try https://tpaste.us/g6bd
2020-12-06 02:26:17 <ddevault> can you email that to me, Ariadne
2020-12-06 02:26:31 <ddevault> I'm in the thirteenth hour of a full 3-stage gcc native build
2020-12-06 02:26:58 <Ariadne> yes, i'll shoot an email off in a few
2020-12-06 02:28:35 <ddevault> what is the purpose of this patch
2020-12-06 02:30:51 <Ariadne> it aligns libucontext register names and structure accesses with the musl 1.2 changes
2020-12-06 03:08:03 <Ariadne> ddevault: i tested and pushed an updated patch using qemu-system-riscv64
2020-12-06 03:08:12 <ddevault> Ariadne: cool
2020-12-06 03:08:21 <ddevault> I'll verify it when I have some spare cycles
2020-12-06 03:10:03 <ddevault> actually I'm stuck in a serial part of the build, I can spare a core
2020-12-06 03:11:23 <ddevault> Ariadne: it's good
2020-12-06 03:11:30 <Ariadne> cool
2020-12-06 03:11:39 <Ariadne> i'm working on an m68k port of libucontext
2020-12-06 03:12:11 <ddevault> I won't be able to help any time soon, I'm still a couple of months out from finishing my m68k computer
2020-12-06 03:17:14 <Ariadne> i wish elon musk would finish launching his satellites
2020-12-06 03:17:41 <ddevault> I wish he would finish building starship
2020-12-06 03:17:59 <ddevault> though that's more attributable to gwen shotwell
2020-12-06 03:18:19 <Ariadne> starlink would be great for me
2020-12-06 03:18:23 <Ariadne> way better than viasat
2020-12-06 03:18:35 <ddevault> where are you located?
2020-12-06 03:18:42 <Ariadne> middle of nowhere wyoming
2020-12-06 03:18:49 <ddevault> tis a windy place
2020-12-06 04:04:21 <Ariadne> qemu-system-m68k is markedly faster than my amiga without vampire upgrade board installed
2020-12-06 04:05:33 <ddevault> gcc build failed without printing an error message of any kind
2020-12-06 04:05:36 <ddevault> life is suffering
2020-12-06 04:07:55 <Ariadne> on mips we had a bug that we worked around using -fno-partial-inlining
2020-12-06 04:07:57 <Ariadne> might be worth a shot
2020-12-06 04:16:54 <Ariadne> jesus i forgot how slow apt is
2020-12-06 04:17:06 <Ariadne> i've been used to apk ;)
2020-12-06 04:21:35 <Ariadne> hell yeah lets install KDE Plasma on m68k
2020-12-06 04:21:39 <Ariadne> that should be good for some laughs
2020-12-06 07:57:28 <bratkartoffel> good morning guys. the openjdk7 build errors on 3.13 (and edge) builders should be fixed with !15295
2020-12-06 08:01:58 <ikke> bratkartoffel: merged
2020-12-06 09:24:14 <mps> we should consider removing all packages for which upstream don't have e-mail for contact, e-mail is 'least common denominator' for communication
2020-12-06 09:49:33 <Ariadne> that sounds like a nightmae
2020-12-06 09:49:37 <Ariadne> mare*
2020-12-06 09:51:14 <mps> yes, but have to express my opinion. and I don't expect that will happen anytime
2020-12-06 09:51:50 <Jenkler> Whats up with the broken license for mongodb. I need an updated mongodb and I wonder if the best solution is to build from source with abuild.
2020-12-06 09:52:25 <ikke> Jenkler: what do you want to know?
2020-12-06 09:54:33 <Jenkler> ikke, is it easy to mod non-free APKBUILD for mongodb?
2020-12-06 09:54:58 <ikke> Jenkler: sure, should not be difficult
2020-12-06 09:55:12 <Jenkler> dont want to use gentoo and glibc
2020-12-06 09:55:15 <ikke> as long as upstream has not changed something significantly
2020-12-06 09:55:22 <ikke> but you have to build it yourself
2020-12-06 09:55:51 <Jenkler> the abuild tool seams nice
2020-12-06 09:56:04 <ikke> I think too
2020-12-06 09:56:36 <Jenkler> at the moment I build docker pkg for both gentoo and alpine.
2020-12-06 09:57:13 <Jenkler> What is the pros of building the system with abuild. Possible to get it even smaler?
2020-12-06 09:59:02 <ikke> automatic installation of dependencies
2020-12-06 09:59:39 <Newbyte> Have you considered caching Docker images instead of always pulling them from Dockerhub in the CI?
2020-12-06 09:59:44 <Jenkler> ikke, but you have the with apk (bin) also
2020-12-06 10:00:04 <ikke> Newbyte: I think we switched to that. Are there still builders bumping into the limit?
2020-12-06 10:00:19 <Newbyte> Yes
2020-12-06 10:00:23 <ikke> which one
2020-12-06 10:00:28 <Newbyte> !15396
2020-12-06 10:00:31 <Newbyte> armv7
2020-12-06 10:03:45 <ikke> Newbyte: fixed
2020-12-06 10:10:50 <mps> Newbyte: sorry for nitpicking, but sundays are good days for such endeavors :)
2020-12-06 10:12:18 <andypost[m]> ikke: if-not-present flag in gitlab runner applies to helper image too?
2020-12-06 10:13:21 <ikke> andypost[m]: I believe so, otherwise it would still fail the build
2020-12-06 10:14:17 <Newbyte> mps: No worries. I'll gladly follow whatever convention you have.
2020-12-06 10:20:46 <mps> Newbyte: 'we have' I think
2020-12-06 10:21:09 <mps> time to consider renaming APKBUILD to apkbuild
2020-12-06 10:22:58 <PureTryOut[m]2> Why would that matter...?
2020-12-06 10:23:09 <Newbyte> which part?
2020-12-06 10:23:40 <ikke> https vs HTTPS I guessA
2020-12-06 10:23:42 <ikke> ?
2020-12-06 10:24:02 <mps> PureTryOut[m]2: if spaces matter then ... well
2020-12-06 10:25:02 <PureTryOut[m]2> Newbyte: APKBUILD vs apkbuild
2020-12-06 10:25:41 <Newbyte> I think he's joking..?
2020-12-06 10:27:46 <mps> no, I'm not. merged !15396
2020-12-06 11:43:58 <Jenkler> Is this still correct ./sbin/apk.static -X ${mirror}/latest-stable/main -U --allow-untrusted -P ${chroot_dir} --initdb add alpine-base
2020-12-06 11:44:46 <Jenkler> I it complains about the chroot_dir
2020-12-06 11:46:29 <ikke> It should be -p, lower case
2020-12-06 11:46:42 <ikke> -p, --root <ROOT>     Manage file system at ROOT
2020-12-06 11:47:26 <Jenkler> https://wiki.alpinelinux.org/wiki/Alpine_Linux_in_a_chroot
2020-12-06 11:47:32 <Jenkler> Doc error then ;)
2020-12-06 11:48:01 <ikke> fixed
2020-12-06 11:48:52 <Jenkler> ;)
2020-12-06 11:51:34 <Jenkler> ikke, is there any docs for -p -X flags
2020-12-06 11:51:45 <Jenkler> if i do apk --help
2020-12-06 11:52:21 <mps> apk add -h
2020-12-06 11:52:40 <ikke> -p and -X are global flags though
2020-12-06 11:53:04 <ikke> apk --help should list them
2020-12-06 11:53:25 <mps> no, it will not
2020-12-06 11:53:30 <ikke> it does for me
2020-12-06 11:53:48 <mps> and not for me
2020-12-06 11:53:54 <Jenkler> apk --help does not show global
2020-12-06 11:54:08 <Jenkler> but apk add --help does
2020-12-06 11:54:27 <mps> because that flags not apply to all subcommands
2020-12-06 11:54:51 <mps> and that right behaviour of apk
2020-12-06 11:55:09 <ikke> also apk add apk-tools-doc
2020-12-06 11:55:14 <ikke> man apk
2020-12-06 11:56:01 <ikke> there it is listed under global options
2020-12-06 11:56:34 <mps> -doc is not written by apk author, iirc
2020-12-06 11:56:42 <Jenkler> I missed add alpine-base at the end of the command, so apk add --help makes sence
2020-12-06 12:03:02 <Jenkler> alpine mini root system is smaler than alpine-base
2020-12-06 12:04:15 <ikke> alpine-base includes openrc
2020-12-06 12:04:42 <ikke> and alpine-conf
2020-12-06 12:05:03 <ikke> https://pkgs.alpinelinux.org/package/edge/main/x86_64/alpine-base
2020-12-06 12:06:25 <Jenkler> ikke, so ./sbin/apk.static -X ${mirror}/latest-stable/main -U --allow-untrusted -p ${chroot_dir} --initdb add alpine-base
2020-12-06 12:06:34 <Jenkler> is not optimal
2020-12-06 12:07:16 <ikke> Not for a minimal system that does not require an init system, no
2020-12-06 12:07:17 <Jenkler> If you want a minimal build chroot ;)
2020-12-06 12:07:27 <ikke> correct
2020-12-06 12:07:58 <Jenkler> alpine-baselayout
2020-12-06 12:07:58 <Jenkler> alpine-keys
2020-12-06 12:07:59 <Jenkler> libc-utils
2020-12-06 12:07:59 <Jenkler> busybox
2020-12-06 12:07:59 <Jenkler> apk-tools
2020-12-06 12:08:29 <ikke> busybox-suid as well
2020-12-06 12:08:36 <Jenkler> To get a minimal system
2020-12-06 12:09:02 <ikke> but yes
2020-12-06 12:09:03 <Jenkler> if you build as root i guess busybox-suid is nnot needed
2020-12-06 12:09:27 <ikke> Jenkler: You'll miss out on applets
2020-12-06 12:09:29 <mps> Jenkler: https://tpaste.us/kkna
2020-12-06 12:09:47 <mps> that is what I use for armhf setup
2020-12-06 12:09:57 <ikke> but that's not a minimal chroot
2020-12-06 12:10:48 <mps> I know, but just give him hint
2020-12-06 12:11:11 <Jenkler> mps, yes. That is too big in my case ;) only need busybox hehe
2020-12-06 12:11:31 <ikke> https://tpaste.us/OQno
2020-12-06 12:11:37 <mps> Jenkler: I don't expect you will install tcsh :)
2020-12-06 12:11:41 <ikke> s
2020-12-06 12:11:42 <ikke> ls
2020-12-06 12:11:53 <Jenkler> nope, I like ash
2020-12-06 12:12:38 <ikke> Jenkler: if you don't need crontab and passwd, you can do without busybox-suid
2020-12-06 12:13:15 <Jenkler> ikke, nice ;)
2020-12-06 12:13:16 <mps> though tcsh is just 363K
2020-12-06 12:13:48 <Jenkler> I want my system to be 1K ;)
2020-12-06 12:14:32 <mps> rm -rf /
2020-12-06 12:15:11 <Jenkler> mps, is that a good command ;) The ultimate power command. Go big or go home!
2020-12-06 12:16:34 <mps> no, there is better one, big hammer :P
2020-12-06 12:18:37 <Jenkler> 2.1M    test2/ with only busybox ;)
2020-12-06 12:19:03 <Jenkler> desktop os 2.1M ;)
2020-12-06 12:19:53 <mps> and gnome beside kde is running on it :D
2020-12-06 12:20:48 <Jenkler> Yes, indeed. In warpspeed
2020-12-06 12:22:04 <Jenkler> I think I am gonna skip gentoo. Need to learn abuild an get a good version of mongodb working
2020-12-06 12:23:19 <ikke> Jenkler: you know there is an apkbuild in non-free?
2020-12-06 12:23:39 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/non-free/mongodb
2020-12-06 12:30:07 <Jenkler> ikke, yes. But it is not updated
2020-12-06 12:30:28 <ikke> correct
2020-12-06 12:30:36 <Jenkler> So, i fugure that I need to update taht APKBUILD file
2020-12-06 12:30:58 <ikke> Right, but I'd figure it's easier to start from something existing than start from scratch
2020-12-06 12:31:16 <Jenkler> ikke, yes. That was my plan ;)
2020-12-06 12:31:42 <Jenkler> maybe use gentoos ebuild for reference
2020-12-06 12:31:58 <Jenkler> they have a newer version as stable
2020-12-06 12:35:31 <Jenkler> I will not be using apk.static for building this because I am in a alpine system already. Better to use apk with --root option
2020-12-06 16:38:57 <PureTryOut[m]2> Cogitri: https://git.alpinelinux.org/aports/tree/community/squeekboard/APKBUILD#n8 says it's blocked on armv7 because of Rust, but Rust is available on that arch. Could squeekboard be re-enabled?
2020-12-06 16:43:10 <ikke> PureTryOut[m]2: I you make a MR to test it on CI, I can merge that
2020-12-06 16:43:21 <PureTryOut[m]2> Ah sure
2020-12-06 16:44:35 <PureTryOut[m]2> ikke: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15423
2020-12-06 16:45:55 <ikke> Was disabled in 5b097a8f7dbdea0ad12b75f0ba7a8140a8c15e7c
2020-12-06 16:46:40 <PureTryOut[m]2> No information whatsoever, nice
2020-12-06 16:46:57 <PureTryOut[m]2> Can we please use the extended commit message to say why something gets disabled?
2020-12-06 16:47:00 <ikke> :)
2020-12-06 16:47:03 <mps> these 'subject' commit messages are quite informative :)
2020-12-06 16:47:11 <ikke> PureTryOut[m]2: my pet peeve
2020-12-06 16:47:22 <mps> PureTryOut[m]2: I agree
2020-12-06 16:48:15 <mps> (drop on $arch is funny)
2020-12-06 16:48:25 <ikke> PureTryOut[m]2: https://build.alpinelinux.org/buildlogs/build-edge-armv7/community/squeekboard/squeekboard-1.11.1-r0.log
2020-12-06 16:48:51 <ikke> might be a builder related issue
2020-12-06 16:49:27 <ikke> We cache rust crates on the builders, but the cache seems to become inconsistent (crates that are incomplete)
2020-12-06 16:54:38 <ikke> PureTryOut[m]2: merged
2020-12-06 16:54:43 <PureTryOut[m]2> Thanks!
2020-12-06 16:55:23 <ikke> If it fails on the builder, I will check it
2020-12-06 16:55:38 <PureTryOut[m]2> Awesome!
2020-12-06 18:33:56 <David_9> Anyone home?
2020-12-06 18:34:49 <Hello71> it's not polite to cross-post after 34 seconds
2020-12-06 18:51:57 <maxice8> Should we upgrade mbedtls to 2.24.0 ?
2020-12-06 18:54:44 <maxice8> apparently 2.16.x is current LTS
2020-12-06 19:19:12 <David_9> Thank you for telling me
2020-12-06 19:19:27 <David_9> I haven't used IRC in like 20 years
2020-12-06 19:19:38 <David_9> The etiquette is lost on me
2020-12-06 19:26:43 <maxice8> 3.13 has started building community/ on aarch64 and x86_64
2020-12-06 19:27:03 <ikke> several arches already
2020-12-06 19:27:35 <ikke> armv7 and armhf as well
2020-12-06 19:55:01 <ikke> hmm, seems like rust is stuck on armhf
2020-12-06 19:56:57 <ikke> feels a lot like a deadlock
2020-12-06 21:17:30 <andypost[m]> Looks it's not stuck but failed https://build.alpinelinux.org/buildlogs/build-3-13-armhf/community/rust/rust-1.47.0-r1.log
2020-12-06 23:38:11 <mps> https://lore.kernel.org/lkml/CAHk-=wgtCzNv7ghB=1VK1fYe82GwiS8xdaXTDqcVzQKn4QfrXw@mail.gmail.com/T/#u
2020-12-06 23:38:33 <mps> 'o unless something odd and bad happens next week, we'll have a final 5.10 release next weekend, ...]
2020-12-06 23:38:42 <mps> so*
2020-12-07 04:16:44 <omni> I'd like to see CONFIG_NET_9P_XEN=m (should probably raise an issue but just wanted to say it anyway)
2020-12-07 05:26:06 <ikke> andypost[m]: at that point I already stopped it
2020-12-07 07:51:26 <Ariadne> omni: seems reasonable, please open a bug requesting it
2020-12-07 07:59:14 <ncopa> good monday morning
2020-12-07 08:01:16 <maxice8> morning
2020-12-07 08:05:38 <Ariadne> btw i am not kidding
2020-12-07 08:05:42 <Ariadne> apk version -t . ..
2020-12-07 08:05:46 <Ariadne> does work as expected
2020-12-07 08:06:30 <ikke> context?
2020-12-07 08:08:22 <Ariadne> oh a shitpost i wrote on twitter
2020-12-07 08:09:04 <Ariadne> i said that because apk version -t . .. works as expected, i was going to release all future software versioned as an increasingly long series of periods
2020-12-07 08:13:36 <ncopa> hilarious :)
2020-12-07 08:14:29 <ncopa> omni: if you create a ticket, make sure to add a label "kernel"
2020-12-07 08:15:40 <ikke> I don't think most users can set labels themselves
2020-12-07 08:15:49 <markand> is there a way to add custom fields in PR on GitLab? because when people upgrade/change a package if someone® does not ping the maintainer it could miss the PR quite often
2020-12-07 08:16:13 <ikke> markand: custom fields?
2020-12-07 08:16:32 <ikke> there are labels
2020-12-07 08:16:50 <markand> yes custom fields, redmine for example let you put arbitrary fields in a issue form
2020-12-07 08:17:05 <ikke> Then labels
2020-12-07 08:17:16 <ikke> But you need to be at least reported on the project to be able to add them
2020-12-07 08:17:18 <markand> you're still not being notified
2020-12-07 08:18:01 <markand> for example someone updated my package ardour and I was not notified until someone cc @me in the PR comments
2020-12-07 08:18:17 <ikke> Which I did deliberately
2020-12-07 08:18:38 <ikke> But I don't seen how custom fields would help with notifications?
2020-12-07 08:18:51 <markand> yes, but that's a huge waste of time I think, I mean you always need to look who is the maintainer, add a @cc yourself
2020-12-07 08:19:27 <markand> idk just asking, or perhaps a bot that notifies automatically, but that would be harder
2020-12-07 08:19:28 <ikke> I think this is something we could eventually include into the alpine-qa-bot
2020-12-07 08:23:23 <markand> so the package was merged even though it fails to build? 🤔
2020-12-07 08:23:34 <ikke> markand: apparently
2020-12-07 08:23:54 <ikke> and the fun with ardour is that they apparently only publish the latest version
2020-12-07 08:24:26 <markand> no you can get old versions but URL are painful to find
2020-12-07 08:24:32 <ikke> aha
2020-12-07 08:24:37 <markand> ardour is a pretty annoying software
2020-12-07 08:41:27 <mps> update-grub is probably buggy, it doesn't create menu entry for linux-edge-virt correctly
2020-12-07 08:48:17 <omni> ncopa: I just did and noticed that I forgot, I'll try and figure out how to add a label..
2020-12-07 08:49:07 <ikke> omni: Did it for you
2020-12-07 08:50:38 <omni> ikke: thanks!
2020-12-07 09:30:59 <ncopa> thanks to both of you. I'll looks at it when 5.4.82 comes out
2020-12-07 09:31:38 <ikke> ncopa: generally when I see kernel related issues / requests, I add that label
2020-12-07 09:32:30 <markand> someone can explain me why pandoc isn't being installed in this pipeline? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15474
2020-12-07 09:32:59 <markand> it's listed in makedepends
2020-12-07 09:34:04 <ikke> markand: where? https://gitlab.alpinelinux.org/alpine/aports/-/blob/704789704252a79803961bc42fcad7ec774c41e4/testing/amsynth/APKBUILD#L12
2020-12-07 09:34:20 <markand> Oo
2020-12-07 09:34:26 <markand> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15474/diffs#769d05993d305062606f4a800046497da8987aec_12_13
2020-12-07 09:34:29 <markand> its there here
2020-12-07 09:36:09 <markand> oh wait
2020-12-07 09:36:12 <markand> nvm :)
2020-12-07 09:36:55 <ikke> heh
2020-12-07 10:01:56 <markand> hmmm, pandoc seems to be x86_64 only
2020-12-07 10:02:06 <markand> so I have two possibilities for my amsynth package
2020-12-07 10:02:18 <markand> disable manual pages completely (remove pandoc dependency)
2020-12-07 10:02:31 <markand> or add pandoc only for x86_64 arch, what do you suggest?
2020-12-07 10:29:00 <ncopa> disable man pages or fix pandoc on other arches
2020-12-07 10:35:57 <Ariadne> fixing pandoc requires bootstrapping haskell on the other archs
2020-12-07 10:36:04 <Ariadne> which is on my list of things to tackle
2020-12-07 10:43:53 <markand> I'll disable manpages for time being then
2020-12-07 13:21:04 <hc-hmk> Is there an overview of blocking tasks for release of 3.13?
2020-12-07 13:25:57 <hc-hmk> I found (https://gitlab.alpinelinux.org/alpine/aports/-/milestones/149)
2020-12-07 13:26:28 <ikke> right, but not everything is a blocker
2020-12-07 13:26:38 <ikke> It's mostly resolving build issues atm
2020-12-07 13:26:46 <ikke> waiting for a new musl release
2020-12-07 13:30:05 <hc-hmk> Oh, I didn't know a new muslc release was coming up. Is there anything I can do to help, or do all tasks have an owner?
2020-12-07 13:30:41 <ikke> You can look at failed pacakges on build.alpinelinux.org for the 3-13 builders and see if you can fix that
2020-12-07 13:31:37 <hc-hmk> Alright, thanks.
2020-12-07 13:37:38 <hc-hmk> Can jobs be re-run without change? the job for py3-gtts-token on x86-64 seems to fail because of a get request to translate.google.com
2020-12-07 13:38:02 <timlegge> any thought on Issue #12165 and my proposed solution
2020-12-07 13:49:08 <mps> timlegge: /usr/lib/perl5/core_perl/Encode.pm is owned by perl-5.32.0-r0
2020-12-07 13:50:52 <mps> at glance solution looks like 'git rm main/perl-encode'
2020-12-07 13:52:51 <timlegge> mps: hmm.  did not look at that.  Will look closer
2020-12-07 13:52:53 <mps> what perl-encode contains which are not already in perl
2020-12-07 13:53:49 <Hello71> Ariadne: seems not much different from tex pi version
2020-12-07 14:00:22 <mps> timlegge: looks like perl-encode contains more encodings than this in perl
2020-12-07 14:01:08 <mps> Byte  CN  EBCDIC  KR  Symbol  TW  Unicode
2020-12-07 14:07:49 <markand> for some reasons I have a patch that does not apply on the CI but works fine locally: https://gitlab.alpinelinux.org/markand/aports/-/jobs/265186
2020-12-07 14:11:21 <markand> hmm, let see if its still needed anyway
2020-12-07 14:21:32 <timlegge> mps: yes but it looks like for my purpose the perl version of Encode is fine.  perl-encode may need to stay but there are no depends.  Anything that does is likely using the perl delivered version
2020-12-07 14:28:48 <mps> timlegge: also for my usage this what is in perl pkg is enough and good
2020-12-07 14:29:57 <mps> side note, upstream should rewrite it and arrange to not conflict with perl 'base'
2020-12-07 14:30:02 <mps> IMO
2020-12-07 14:31:09 <mps> and I think we should remove it from alpine or move to unmaintained
2020-12-07 14:31:13 <timlegge> I suspect that it is meant to be a more up-to-date version but you are correct
2020-12-07 14:32:18 <mps> I trust perl core developers about inclusion important and useful part
2020-12-07 14:32:30 <mps> parts*
2020-12-07 15:34:21 <ikke> ncopa: seems like rust is hanging on armv7 / armhf
2020-12-07 15:34:35 <ikke> already since yesterday
2020-12-07 15:35:21 <ncopa> on what builders? 3.13?
2020-12-07 15:35:42 <ikke> yes
2020-12-07 15:36:07 <ncopa> i think rust may need manual bootstrap
2020-12-07 15:36:20 <ikke> I did add rust-bootstrap and cargo-bootstrap
2020-12-07 15:36:25 <ncopa> ok
2020-12-07 15:36:44 <ikke> But it's doing nothing atm
2020-12-07 15:37:09 <ikke> all processes seem idle
2020-12-07 15:37:35 <ncopa> btw, we fixed a bug in s390x assembly last friday which has been there for long time
2020-12-07 15:38:10 <ncopa> i hope it makes s390x more robust. we have had issues with s390x in the past
2020-12-07 15:38:24 <ikke> yeah, I followed the discussion with dalias
2020-12-07 15:39:01 <ikke> really nice
2020-12-07 15:39:01 <ncopa> looks like cargo isrunning
2020-12-07 15:39:17 <ncopa> and fakeroot
2020-12-07 15:39:25 <ncopa> so it seems like it running install?
2020-12-07 15:40:07 <ikke> armhf buildlog says that the build has failed
2020-12-07 15:40:17 <ikke> waiting for other jobs to finish
2020-12-07 15:40:32 <ikke> Seems like cache related issues
2020-12-07 15:40:41 <ikke> error: failed to build archive: Is a directory
2020-12-07 15:40:50 <ncopa> hum
2020-12-07 15:41:15 <ncopa> ffef800f46c18e6da7c54279a00ce5766d1483e0
2020-12-07 15:41:41 <ikke> I'm not sure if it's the cache
2020-12-07 15:41:50 <justdan96___> hi, does anyone know if a libgl-static package is being developed by anyone?
2020-12-07 15:42:32 <ncopa> justdan96___: not that i know
2020-12-07 15:43:19 <ikke> ncopa: CARGODEST is not present on armhf
2020-12-07 15:43:38 <justdan96___> okay no worries, I'm just trying to get a static Qt5 build working and I realised I needed static libgl as well
2020-12-07 16:04:43 <Hello71> it's impossible
2020-12-07 16:16:52 <ncopa> sigh.... python3 segfaults which testing py3-hiedis
2020-12-07 16:17:11 <ncopa> s/py3-hiedis/py3-hiredis/
2020-12-07 16:17:11 <alpine-meetbot> ncopa meant to say: sigh.... python3 segfaults which testing py3-hiredis
2020-12-07 16:34:03 <ncopa> ok, py3-hiredis segfaults when built with system hiredis, but works with the embedded/vendored  hiredis client
2020-12-07 16:47:49 <ncopa> Ariadne: we have an issue with ifupdown-ng-openrc
2020-12-07 16:49:26 <ncopa> if something pulls in ifupdown-ng-openrc on the builders, it will replace /etc/init.d/networking, when dependencies gets uninstall, it will delete the file and not restore the original file, meaning that when build server reboots, there will no longer be any /etc/init.d/network script to bring up the network
2020-12-07 18:55:22 <ddevault> I'm trying to write an unusual openrc script
2020-12-07 18:55:46 <ddevault> I need the supervisor to start a new process, THEN signal the old one with SIGINT, then abandon it to shut itself down cleanly
2020-12-07 18:56:38 <ddevault> any ideas?
2020-12-07 18:57:00 <skarnet> flip-flop
2020-12-07 18:57:15 <skarnet> declare 2 services and alternate between the two
2020-12-07 18:57:42 <ddevault> well, I guess that'll do
2020-12-07 18:57:46 <ddevault> is kind of lame
2020-12-07 18:58:12 <skarnet> your operation ordering will probably be incorrect with openrc though unless you poll for readiness
2020-12-07 18:58:22 <skarnet> because openrc doesn't have any kind of readiness notification
2020-12-07 18:58:59 <skarnet> an alternative to flipflop is to do the handoff twice
2020-12-07 18:59:45 <skarnet> start an unsupervised process, signal the old one to do the handoff, then restart the supervised process, and make your temporary one do the handoff to the supervised one then die
2020-12-07 18:59:56 <skarnet> two sides of the same coin
2020-12-07 19:00:10 <ddevault> hm, that's an idea
2020-12-07 19:00:22 <skarnet> I prefer flipflop because you don't have to do two handoffs, but some prefer a temporary service
2020-12-07 19:00:25 <ddevault> but not as good, I'll just flipflop
2020-12-07 19:00:34 <ddevault> killing the old process could take up to tens of minutes
2020-12-07 19:00:46 <skarnet> don't you love enterprise
2020-12-07 19:01:23 <ddevault> I wrote this software lol
2020-12-07 19:01:41 <skarnet> what are you doing that takes tens of minutes to die? XD
2020-12-07 19:01:52 <Hello71> ddevault (TM)
2020-12-07 19:01:52 <ddevault> flushing async task queues
2020-12-07 19:02:01 <ddevault> which have built in exponential backoffs
2020-12-07 19:02:28 <skarnet> also, why do you catch SIGINT, and why do you need live handoff instead of storing state into the filesystem to read it again on restart? :P
2020-12-07 19:02:47 <ddevault> well, there are two things which are handed off, the task queue is the long one
2020-12-07 19:03:04 <ddevault> the other is SO_REUSEADDR to gracefully hand new connections over to the new process without service interruption
2020-12-07 19:03:27 <skarnet> that's what fd-holding is for
2020-12-07 19:03:48 <ddevault> fd-holding just another solution
2020-12-07 19:03:54 <ddevault> with worse performance to boot
2020-12-07 19:04:05 <skarnet> but it makes the handoff simpler
2020-12-07 19:04:29 <skarnet> I'd keep my socket held in another process, store my state into the filesystem, restart, get my socket, read my state
2020-12-07 19:04:33 <ddevault> only with the assistance of a third party who refuses to write man pages
2020-12-07 19:05:03 <skarnet> psh, you're very capable of writing a tiny ad-hoc fd-holder for your service
2020-12-07 19:05:23 <ddevault> aye, but my way really oughtn't be a complicated ask, either
2020-12-07 19:06:40 <skarnet> another solution is to exec yourself
2020-12-07 19:07:02 <skarnet> keep your socket, serialize your state in an envvar
2020-12-07 19:07:02 <ddevault> messy
2020-12-07 19:07:08 <ddevault> and this program is written in golang, so that's super cool
2020-12-07 19:07:24 <skarnet> sr.ht ops stuff?
2020-12-07 19:07:27 <ddevault> yeah
2020-12-07 19:07:44 <ddevault> I think the flip flop approach is best, thanks for the idea
2020-12-07 19:07:45 <ddevault> going with that for now
2020-12-07 19:08:00 <skarnet> np, it's a classic pattern for that kind of process
2020-12-07 19:08:07 <ddevault> easy enough to start whichever is stopped, wait a second, then stop whichever is started. With retry= an appropriate schedule
2020-12-07 19:08:17 <skarnet> is there anything in golang that makes it particularly hard to exec yourself?
2020-12-07 19:08:22 <ddevault> yes
2020-12-07 19:08:40 <skarnet> curious
2020-12-07 19:08:41 <ddevault> best to leave that can of worms closed, I think
2020-12-07 19:08:52 <ddevault> at least if you have a good opinion of Go and want to keep it
2020-12-07 19:09:07 <skarnet> my opinion of Go is 7 years old and likely very obsolete
2020-12-07 19:09:30 <ddevault> I am working on a solution to that
2020-12-07 19:11:04 <skarnet> you should have a hook in your task queues that say "retry flushing NOW"
2020-12-07 19:11:10 <ddevault> yes, I should
2020-12-07 19:11:26 <ddevault> but I don't intend to use such a mechanism under normal circumstances
2020-12-07 19:11:51 <skarnet> yeah, better wait 20 minutes in abnormal circumstances when your production is on fire :D
2020-12-07 19:12:13 <ddevault> when production is on fire is an example of a good time to reach for an instant flush tool
2020-12-07 19:12:20 <ddevault> and perhaps a dump state to disk and fuck off tool
2020-12-07 19:12:37 <skarnet> which are not the first things you wrote
2020-12-07 19:12:58 <ddevault> production is not typically on fire
2020-12-07 19:13:09 <skarnet> famous last words
2020-12-07 19:13:12 <ddevault> addressing the on-fire cases is part of the acceptance criteria
2020-12-07 19:13:18 <ddevault> but there are plenty of those which have yet to be met
2020-12-07 19:51:59 <omni> cargo-zsh-completion tries to install to /usr/share/zsh/site-functions/_cargo/_cargo but I don't understand why, should this https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/rust/APKBUILD#L287 perhaps just be "$subpkgdir"/usr/share/zsh/site-functions/ ?
2020-12-07 19:55:38 <ikke> omni: yes, if you look at that _mv function, it first creates the directory specified as last and then moves everything to that dir
2020-12-07 19:56:27 <omni> ikke: right, sorry for being lazy (=
2020-12-07 19:56:36 <omni> I'll  create an issue
2020-12-07 19:57:15 <maxice8> Is there a way to indicate which provider I want when 2 repos have it ?
2020-12-07 19:57:28 <maxice8> I have zstd from alpine and zstd compiled locally if I try cmd:unzstd it can't decide
2020-12-07 19:59:17 <[[sroracle]]> provider_priority needs to be set for both of them i think
2020-12-07 19:59:28 <[[sroracle]]> or at least one of them. can't remember
2020-12-07 20:00:20 <maxice8> hmm
2020-12-07 20:00:24 <maxice8> unfortunate
2020-12-07 20:00:29 <[[sroracle]]> in this case i would probably just pin it or something instead. or give local version higher number
2020-12-07 20:06:22 <maxice8> oh no, I want to use the alpine version, I just compiled locally because I had to test my changes and now the fact the package exists in 2 repos is causing this conflict
2020-12-07 20:09:15 <[[sroracle]]> just move/delete .apk from your repodest then and rebuild apkindex :p
2020-12-07 20:09:22 <ikke> abuild cleanpkg
2020-12-07 20:11:02 <clandmeter> cant you just add regular repos as pinned ones?
2020-12-07 20:11:39 <[[sroracle]]> oh that would be interesting
2020-12-07 20:15:15 <maxice8> oh ty
2020-12-07 20:15:25 <andypost[m]> Btw is there any wiki about how provider priority supposed to work? Checking lua implementation makes it uncler
2020-12-07 20:15:50 <ikke> not in detail
2020-12-07 20:16:07 <ikke> there is the apkbuild reference, but it does not mention a lot
2020-12-07 20:17:58 <andypost[m]> Yep, I've added php8 with lower priority but can't get how it should work
2020-12-07 20:19:10 <andypost[m]> Thinking about to make dependencies to point php to provider with higher priority
2020-12-07 20:22:15 <andypost[m]> Basically to prevent edit every dependent aport like https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/phpmyadmin/APKBUILD#L11
2020-12-07 20:24:01 <[[sroracle]]> it would be disingenuous for php8 to provide php7 in my opinion
2020-12-07 20:24:08 <[[sroracle]]> so you're just gonna have to edit them
2020-12-07 20:24:31 <clandmeter> afaik, if two pkgs provides the same, the one with the highest priority will be selected.
2020-12-07 20:24:50 <[[sroracle]]> right
2020-12-07 20:25:14 <clandmeter> php7 vs php8 are not the same.
2020-12-07 20:25:50 <clandmeter> but cmd:php would
2020-12-07 20:26:30 <[[sroracle]]> no, you could do provides=php7 et al in php8 which is what i think he was suggesting. and it would work
2020-12-07 20:26:40 <[[sroracle]]> but it would be kinda weird to do
2020-12-07 20:26:44 <alexeymin> builder "build-edge-aarch64" is building community/openjdk7 7.281.2.6.23-r0 for too long, is it fine?
2020-12-07 20:27:14 <ikke> no
2020-12-07 20:27:58 <ikke> bratkartoffel: ^
2020-12-07 20:28:54 <Ariadne> [09:47] <@da8e00ncopa> Ariadne: we have an issue with ifupdown-ng-openrc
2020-12-07 20:29:00 <clandmeter> the whole cmd:x function is kind of useless as its often provided by multiple packages without priority set.
2020-12-07 20:29:24 <Ariadne> hmm.  one workaround would be to install ifupdown-ng on builders directly
2020-12-07 20:29:31 <Ariadne> for now
2020-12-07 20:29:43 <Ariadne> I do agree that is a suboptimal situation though
2020-12-07 20:29:44 <ikke> even without that issue, I regular get issues when upgrading
2020-12-07 20:30:07 <[[sroracle]]> clandmeter: indeed
2020-12-07 20:31:07 <[[sroracle]]> in adelie apkbuilds we only use it for cmd:which i think. otherwise it's only useful for the end user
2020-12-07 20:32:19 <[[sroracle]]> i guess a few other things but mostly which
2020-12-07 20:34:42 <andypost> [[sroracle]], it provides php and php-cli (looks it's not propagated to subpackages) https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/php8/APKBUILD#L85-87
2020-12-07 20:35:12 <[[sroracle]]> right. but the example dependent package you used depended on php7 names
2020-12-07 20:36:33 <andypost> yes, and I think it everything will be converted to exactly php - it will be less edits
2020-12-07 20:39:55 <[[sroracle]]> that would be great, for the long term too
2020-12-07 20:50:19 <omni> I upgraded from v3.12.1 to edge and something broke my boot from zfs root, investigating what
2020-12-07 20:53:18 <Ariadne> [13:29] <@da8e00ikke> even without that issue, I regular get issues when upgrading
2020-12-07 20:53:24 <Ariadne> issues such as?
2020-12-07 20:55:06 <mps> Ariadne: what's with your irc client
2020-12-07 20:55:13 <Ariadne> ?
2020-12-07 20:55:28 <Ariadne> oh I'm using quasseldroid
2020-12-07 20:55:42 <Ariadne> it pastes with colored nicks I guess
2020-12-07 20:55:56 <mps> inverted colors
2020-12-07 20:56:34 <mps> when you paste
2020-12-07 20:56:39 <Ariadne> weird
2020-12-07 20:57:53 <mps> luckily you don't paste much
2020-12-07 20:58:01 <ikke> Ariadne: Something about unsatisfiable constraints
2020-12-07 20:58:05 <Ariadne> usually I paste on desktop
2020-12-07 20:58:07 <Ariadne> oh
2020-12-07 20:58:19 <Ariadne> you're talking about the depsolver
2020-12-07 20:58:32 <Ariadne> I was concerned there was some other ifupdown-ng issue
2020-12-07 20:58:37 <Ariadne> hmm.
2020-12-07 20:58:40 <ikke> Ariadne: aha, sorry
2020-12-07 20:58:51 <Ariadne> I think I have a solution for ifupdown-ng-openrc
2020-12-07 20:59:05 <Ariadne> split out the traditional networking openrc
2020-12-07 20:59:08 <Ariadne> make them conflict :)
2020-12-07 21:12:19 <omni> [zroot] huh, mount can't read-only mount zfs on /sysroot, "failed: Resource busy"
2020-12-07 21:13:45 <omni> if I manually mount rw the system will boot when I exit the rescue shell
2020-12-07 21:15:28 <omni> right, now I have the 2.0.0 butchered zfs man pages..
2020-12-07 23:13:50 <omni> setting rootflags=rw works but doesn't feel right
2020-12-08 04:05:27 <ddevault> bootstrapping vim takes an alarming amount of work
2020-12-08 04:05:37 <ddevault> I thought I set vim as a softball goal before moving on to bigger things
2020-12-08 04:05:41 <ddevault> ...4 days ago
2020-12-08 04:15:03 <insep_> is vis easier to bootstrap? :D
2020-12-08 04:15:39 <ddevault> probably
2020-12-08 04:15:50 <ddevault> but it's not in main, and I'm only doing main right now
2020-12-08 04:16:01 <ddevault> neovim would also be easier
2020-12-08 04:18:23 <insep_> wait why
2020-12-08 04:18:44 <insep_> i thought neovim requires luajit and all that stuff
2020-12-08 04:18:45 <insep_> unless you were joking :D
2020-12-08 04:19:00 <ddevault> yeah, neovim doesn't have gvim
2020-12-08 04:19:03 <ddevault> and that's the main problem
2020-12-08 04:19:42 <ddevault> gvim's transitive dependencies include dozens of wayland and x11 packages, doxygen, bunch of xml stuff, mesa, llvm10...
2020-12-08 04:19:50 <ddevault> python3
2020-12-08 04:19:51 <ddevault> etc
2020-12-08 04:20:48 <ddevault> boost!
2020-12-08 05:32:59 <ikke> mps was thinking of having a separate gvim package
2020-12-08 05:35:28 <Ariadne> lets just drop all editors except busybox vi and gnu nano
2020-12-08 05:47:43 <maxice8> Sounds good
2020-12-08 05:52:34 <Ariadne> ok i'll implement
2020-12-08 05:52:37 <Ariadne> haha just kidding
2020-12-08 06:29:51 <maxice8> Hope it gets in time for 3.14
2020-12-08 06:34:13 <HRio> can anybody help with merging !14575 thanks
2020-12-08 06:47:45 <bratkartoffel> alexeymin: ikke: wow, when was it merged? must be days ago... No, it should only take a couple of hours at most...
2020-12-08 11:19:36 <mps> insep_: heh, we talked few days ago here about this https://lists.freedesktop.org/archives/dri-devel/2020-December/290520.html
2020-12-08 11:20:16 <insep_> about what
2020-12-08 11:20:30 <mps> linux-msm
2020-12-08 11:20:50 <insep_> i don't quite get what you mean
2020-12-08 11:21:20 <mps> then ok (if you forgot so fast :) )
2020-12-08 11:38:40 <Newbyte> Do you guys know if Fabian Affolter is in here?
2020-12-08 11:41:08 <ikke> I haven't seen hem
2020-12-08 11:41:10 <ikke> them
2020-12-08 11:44:42 <ikke> They are usually responsive on gitlab
2020-12-08 11:58:13 <Newbyte> What's their name on GitLab?
2020-12-08 11:58:59 <ikke> Username is fab
2020-12-08 11:59:43 <Newbyte> Thanks
2020-12-08 12:18:43 <Newbyte> afontain: would you be okay with moving py3-matrix-nio from testing to community?
2020-12-08 12:18:52 <afontain_> yup
2020-12-08 12:18:56 <Newbyte> great
2020-12-08 12:19:01 <Newbyte> trying to move mirage from testing to community
2020-12-08 12:19:13 <afontain_> I haven't looked for some time, so there very well could be some updates available
2020-12-08 12:19:30 <Newbyte> do you want to send the MR or should I do it?
2020-12-08 12:19:58 <afontain_> please do
2020-12-08 12:20:04 <afontain_> I'm quite occupied atm
2020-12-08 12:20:07 <insep_> mps: i do remember our conversation about msm8974, but i don't quite get what are you referring to with that link
2020-12-08 12:20:17 <afontain_> it would be nice to move pantalaimon to community too
2020-12-08 12:20:17 <Newbyte> no worries, I'll get to it
2020-12-08 12:20:26 <Newbyte> I can see about that
2020-12-08 12:20:46 <afontain_> thanks!
2020-12-08 12:26:51 <Newbyte> 
ACTION uploaded an image: Screenshot_Alpine_2020-12-08_13:26:33.png (15KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/gKYuapSXLYPaaPQtwhulKdlE/Screenshot_Alpine_2020-12-08_13:26:33.png >

2020-12-08 12:26:55 <Newbyte> this doesn't look promising
2020-12-08 12:27:55 <mps> insep_: it is about works on msm for linux 5.11 (or some of the next versions)
2020-12-08 12:36:30 <alexeymin> I'm still worried about edge aarch64 builder
2020-12-08 12:38:16 <alexeymin> no new aarch64 packages in repos, still building openjdk7
2020-12-08 12:39:05 <ikke> building it again
2020-12-08 12:39:46 <ikke> bratkartoffel: seems to get stuck again, so we need to find a solution
2020-12-08 12:55:58 <Newbyte> does anyone know if André Klitzing is in here?
2020-12-08 12:57:00 <bratkartoffel> ikke: again hanging while executing the tests? we could disable the tests for these arches, although we really shouldn't do this...
2020-12-08 12:57:28 <bratkartoffel> i don't understand why they only hang on the builders but not on the gitlab runners (it works with qemu but not on real hardware?)
2020-12-08 12:58:22 <ikke> perhaps
2020-12-08 12:58:31 <ikke> armv7 and aarch64 ci indeed run on qemu
2020-12-08 12:58:50 <Cogitri> Or maybe the actual builders have more builds jobs than CI?
2020-12-08 12:59:56 <afontain_> it could be an instance of https://bugs.launchpad.net/qemu/+bug/1813398
2020-12-08 13:00:05 <ikke> bratkartoffel: I see it's building community/openjdk7 7.281.2.6.23-r0, is that correct?
2020-12-08 13:00:10 <afontain_> (I'm not too knowledgeable on the subject, though)
2020-12-08 13:00:38 <ikke> I see a buildlog for openjdk7-7.281.2.6.24-r0 as well
2020-12-08 13:00:41 <ikke> which passed
2020-12-08 13:01:03 <ikke> afontain_: in this case, qemu is _not_ the issue
2020-12-08 13:01:11 <ikke> or at least, it passes
2020-12-08 13:01:56 <afontain_> oh, nevermind
2020-12-08 13:01:59 <afontain_> I misread
2020-12-08 13:02:27 <ikke> bratkartoffel: I see it was upgraded to 24, then reverted to 23 and then reverted to 22
2020-12-08 13:02:39 <ikke> and now you bumped it to 23 again
2020-12-08 13:03:51 <ncopa> hi
2020-12-08 13:04:04 <ncopa> im a bit worreid about edge builders not complete build
2020-12-08 13:04:24 <ncopa> seems like we add more (broken) stuff faster than we manage to fix
2020-12-08 13:04:51 <ncopa> i plan to do 3.12 release, hope fully tomorrow. i'm building the 5.4.82 kernel
2020-12-08 13:05:03 <ikke> ncopa: maybe we should do a more thorough feature freeze?
2020-12-08 13:05:03 <ncopa> i'd like to tag a new edge release too asap.
2020-12-08 13:05:10 <ncopa> i dont know
2020-12-08 13:05:14 <ncopa> im open to ideas
2020-12-08 13:05:39 <Newbyte> entirely unrelated: would you be okay with moving py3-logbook to community ncopa?
2020-12-08 13:06:02 <ncopa> i have no opinion since i dont know the consequence :)
2020-12-08 13:06:05 <mps> 14:04 ...........@ncopa| seems like we add more (broken) stuff faster than we manage to fix
2020-12-08 13:06:10 <mps> I agree
2020-12-08 13:06:24 <hjaekel> Can someone please give me feedback on !14638. The PR has been open for some time now. Is it OK to have such a huge resource data package?
2020-12-08 13:06:33 <ncopa> but in general, i am in favor of moving stuff to community
2020-12-08 13:06:37 <Newbyte> I want to move a package to community and one of its depends depends on py3-logbook, so I'd like to move it
2020-12-08 13:06:39 <mps> this will kill alpine
2020-12-08 13:06:53 <ncopa> Newbyte: move from main or testing?
2020-12-08 13:07:06 <Newbyte> testing
2020-12-08 13:07:23 <ncopa> does it work? is it packaged well? does it have maintainer?
2020-12-08 13:07:29 <Newbyte> you are the maintainer
2020-12-08 13:07:33 <ncopa> oh :)
2020-12-08 13:07:35 <ncopa> lol
2020-12-08 13:07:46 <Newbyte> I presume you are Natanael Copa?
2020-12-08 13:07:57 <ncopa> i am
2020-12-08 13:08:49 <Newbyte> It looks packaged well to me, and seems to work from my usage. are you ok with me moving it from testing to community?
2020-12-08 13:09:02 <ncopa> im ok with that. thank you for taking care of it
2020-12-08 13:09:08 <Newbyte> 👍️
2020-12-08 13:09:11 <mps> I'm for old 'rule', keep new in testing at least for one release cycle
2020-12-08 13:09:59 <ncopa> it has been in testing since at least aug 2019
2020-12-08 13:10:21 <mps> I'm not talking about proj
2020-12-08 13:10:29 <mps> in general
2020-12-08 13:10:54 <andypost[m]> ncopa: last night I finished packaging remaining php7 aports (which works atm), would be great to get !15329 in before edge cut
2020-12-08 13:11:25 <mps> and proj is already in community
2020-12-08 13:11:42 <ncopa> andypost[m]: looks good to me
2020-12-08 13:11:59 <ncopa> but really, i'd like that we try focus on fixing whats broken
2020-12-08 13:12:57 <ncopa> or at least get teh edge builders to complete build
2020-12-08 13:13:50 <ikke> mostly openjdk atm
2020-12-08 13:26:36 <ikke> bratkartoffel: https://tpaste.us/mapg
2020-12-08 13:36:29 <bratkartoffel> thanks for the paste. javadoc again? I thought it's already disabled? i'll check this evening
2020-12-08 13:37:44 <bratkartoffel> can you cancel and disable the jdk7 builds for now?
2020-12-08 13:38:25 <ikke> I'm not sure if disabling it is a good idea
2020-12-08 13:38:59 <ikke> oh, openjdk7 can still be built without a jdk
2020-12-08 13:39:47 <ikke> no, it depends on itself
2020-12-08 13:39:54 <ikke> $pkgname-jre
2020-12-08 13:40:40 <ikke> ncopa: do you think we can/should disable openjdk7 for now?
2020-12-08 13:45:45 <bratkartoffel> as far as i understand the openjdk7 (icedtea) build, it uses the gnu java-compiler (1.5) to compile a minimal 1.6 jdk (bootstrap-jdk) to actually compile itself. So it's the root for all java versions and doesn't have a jdk in makedepends.
2020-12-08 13:46:07 <ikke> but it has a jre in it's depends
2020-12-08 13:46:45 <bratkartoffel> i think it's only meant for apk install openjdk7 to include the jre, isn't it?
2020-12-08 13:47:10 <ikke> abuild will add depends, makedepends and if necessary checkdepends
2020-12-08 13:49:03 <ikke> so if it cannot find openjdk7-jre, it will complain
2020-12-08 13:49:10 <bratkartoffel> ah one little detail i haven't known so far...
2020-12-08 13:49:25 <bratkartoffel> that also means we may never add new arches to the jdk-builds?
2020-12-08 13:50:10 <ikke> the APKBUILD would need to be modified to make it better bootstrappable I guess
2020-12-08 13:50:31 <bratkartoffel> well thats another problem for the future, for now I'll try to find out why the javadoc are still built and keep hanging
2020-12-08 13:50:51 <ikke> in this case, it's not they they are slow I think
2020-12-08 13:50:55 <ikke> I don't see any activity at all
2020-12-08 13:51:29 <ikke> With the others, I still saw threads working
2020-12-08 13:51:50 <ikke> here, the CPU is idle
2020-12-08 13:52:41 <ikke> so sounds like a proper deadlock
2020-12-08 14:23:09 <ikke> ncopa: rust on armv7 / armhf 3.13 is also an issue
2020-12-08 14:23:22 <ikke> ncopa: can it be because they both build at the same time?
2020-12-08 14:45:49 <mps> ncopa: if you are working on kernel upgrade please don't forget to look at MR I made for dtbs on -virt
2020-12-08 14:46:17 <mps> I'm out and can't look MR number
2020-12-08 14:46:38 <ikke> mps: you can label them with category:kernel
2020-12-08 14:47:10 <ikke> !15276
2020-12-08 14:47:19 <mps> I assigned it to ncopa
2020-12-08 14:47:31 <ikke> yes, but he gets assigned many things
2020-12-08 14:47:42 <ikke> so these lables help to see the forest through the trees
2020-12-08 14:48:07 <mps> yes yes, I'm not against labels, but I forgot them often
2020-12-08 14:48:20 <ikke> I've added it now
2020-12-08 14:48:39 <mps> thanks
2020-12-08 14:50:10 <mps> and some people asked here in last few days about some option in kernels, XEN_9FS iirc, and something about DEVMEM
2020-12-08 14:51:34 <mps> CONFIG_NET_9P_XEN=m
2020-12-08 15:04:35 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=category%3Akernel
2020-12-08 15:05:36 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=category%3Akernel
2020-12-08 15:07:24 <mps> #12170 this one I forgot
2020-12-08 16:10:38 <mps> hmm, CROSS_MEMORY_ATTACH=y doesn't look as good idea to enable on distro kernels, except if we don't make linux-dev flavour
2020-12-08 16:11:19 <mps> or -risky
2020-12-08 16:12:29 <mps> but, what about BPF (at least for networking)? looks like this is inevitable
2020-12-08 16:59:51 <ikke> btw, tomorrow there will be a new curl release with 3 announced CVE's
2020-12-08 17:01:49 <dalias> :/
2020-12-08 17:02:33 <tehcloud> AWESOME.
2020-12-08 17:08:00 <mps> I like security (theater) :)
2020-12-08 17:11:59 <insep_> ayyyy
2020-12-08 17:13:23 <mps> hmm, should rephrase as 'I like theater, especially security'
2020-12-08 17:13:48 <ikke> :D
2020-12-08 17:15:15 <mps> but in corona times real theaters are closed, I miss them much :(
2020-12-08 17:17:12 <mps> eh, and my grandma told us that theaters worked even during german occupation in 1941-44
2020-12-08 17:47:45 <afontain_> oof
2020-12-08 18:26:44 <PureTryOut[m]2> Gitlab is being annoyingly slow today... One push took an hour for Gitlab to catch up and start running CI, and I'm again waiting for a few minutes already now
2020-12-08 18:26:59 <ikke> hmm
2020-12-08 18:30:18 <dalias> told y'all gitlab was gonna suck... :-p
2020-12-08 18:30:27 <PureTryOut[m]2> There we go, now it started CI
2020-12-08 18:30:38 <PureTryOut[m]2> dalias: I mean, besides this, I have literally 0 complains about Gitlab
2020-12-08 18:30:48 <PureTryOut[m]2> And normally I don't have this issue either
2020-12-08 18:31:28 <Cogitri> PureTryOut[m]2: No `rebase and merge` button us my biggest complaint, it's soooo annoying
2020-12-08 18:31:45 <PureTryOut[m]2> Huh, why?
2020-12-08 18:32:09 <ikke> PureTryOut[m]2: I cleaned up some stale processes
2020-12-08 18:32:40 <PureTryOut[m]2> Ah that might be it then, thanks
2020-12-08 18:32:42 <ikke> dalias: not sure why, but gitaly-ssh is getting stuck (but on 3.12, so musl-1.1
2020-12-08 18:32:44 <DylanVanAssche_> PureTryOut (matrix.org): I noticed such behavior only when the CI runners are under heavy load.
2020-12-08 18:34:52 <Cogitri> PureTryOut[m]2: Because right now my workflow for merging things is `Press rebase` -> wait 10-20 seconds while reloading the website multiple times and wondering if Gitlab got stuck again -> Merge (provided no dev did another merge at the same time) -> Get an email for each merged MR because the CI failed (because the source branch was deleted
2020-12-08 18:35:03 <Cogitri> It takes a long time and the email spam is pretty annoying
2020-12-08 18:35:10 <ikke> yes, I agree
2020-12-08 18:36:45 <ikke> but the stuck processes are most of the reason the rebase process is taking a long time sometimes
2020-12-08 18:40:51 <Cogitri> Oh, that still happens?
2020-12-08 18:41:02 <Cogitri> I was under the impression that was fixed by now
2020-12-08 18:41:02 <ikke> yup
2020-12-08 18:41:13 <ikke> well, this is on 3.12
2020-12-08 18:41:21 <ikke> so it's not the same issue
2020-12-08 18:41:35 <Cogitri> Oohhh, right, Gitlab doesn't run on edge :D
2020-12-08 18:46:22 <ikke> Cogitri: btw, rust on arm(hf|v7) is strugling
2020-12-08 18:46:27 <ikke> (3.13)
2020-12-08 18:47:25 <ikke> Right now I'm making sure it's only built on one arch at the same time
2020-12-08 18:48:23 <Cogitri> Got a log for that? Can't find it in #alpine-commits anymore
2020-12-08 18:50:05 <ikke> This was on armhf: https://tpaste.us/9j77
2020-12-08 18:50:09 <ikke> at that point, it was stuck
2020-12-08 18:51:48 <Cogitri> Huh
2020-12-08 18:52:09 <Cogitri> Custom build scripts for Rust sure are "fun"
2020-12-08 18:52:36 <ikke> I'm currently tailing the log on armv7
2020-12-08 18:53:13 <ikke> but it's not appearing to do anything anymore
2020-12-08 18:54:16 <Cogitri> Yeaaah, might be stuck, might just need another 3 hours :D
2020-12-08 18:54:38 <ikke> right
2020-12-08 18:54:53 <ikke> but usually you see at least some cpu usage or strace progress
2020-12-08 18:55:14 <ikke> https://tpaste.us/nWXr
2020-12-08 18:56:36 <Cogitri> Hmm, it might only take a few percent of cpu while linking
2020-12-08 18:56:50 <Cogitri> which may take really long on arm which has less IPC than x86_64
2020-12-08 18:56:58 <ikke> hmm, ok
2020-12-08 18:57:00 <ikke> just waiting then
2020-12-08 19:05:22 <timlegge> Anything wrong with x86 edge builder.  Its been stuck on build-edge-x86	
2020-12-08 19:05:22 <timlegge> community/py3-peewee 3.14.0-r0 for quite a wihile
2020-12-08 19:06:02 <ikke> checking
2020-12-08 19:07:45 <timlegge> aarch64 appears to be openjdk that was discussed above so...
2020-12-08 19:07:58 <ikke> yes
2020-12-08 19:08:08 <ikke> seems like the test suite is stuck
2020-12-08 19:08:29 <ikke> all threads are waiting on a futex
2020-12-08 19:12:23 <dalias> :/
2020-12-08 19:12:27 <dalias> is this edge or..?
2020-12-08 19:12:32 <ikke> yes
2020-12-08 19:16:24 <dalias> what process is stuck?
2020-12-08 19:18:29 <ikke> python3 runtests.py
2020-12-08 19:19:24 <dalias> any idea yet what it's doing when it hangs?
2020-12-08 19:19:47 <ikke> Not really
2020-12-08 19:20:22 <ikke> The log is just a bunch of fots
2020-12-08 19:20:25 <ikke> dots
2020-12-08 19:21:35 <ikke> trying to reproduce it in my local container, but there it just finishes every time
2020-12-08 19:21:53 <ikke> s/local/personal/
2020-12-08 19:21:53 <alpine-meetbot> ikke meant to say: trying to reproduce it in my personal container, but there it just finishes every time
2020-12-08 19:23:43 <dalias> i mean can attaching gdb show it?
2020-12-08 19:24:51 <PureTryOut[m]2> ikke: it's being slow again 😛
2020-12-08 19:25:34 <ikke> hmm
2020-12-08 19:31:44 <ikke> PureTryOut[m]2: just a single process
2020-12-08 19:40:40 <PureTryOut[m]2> Huh, well it's not starting another CI job for me...
2020-12-08 19:41:19 <Newbyte> what's with python packages getting rid of setup.py?
2020-12-08 19:44:25 <PureTryOut[m]2> 🤷‍♂️
2020-12-08 19:45:35 <ikke> Newbyte: good question
2020-12-08 19:46:34 <Cogitri> I think there's a move to using `pip install` or smth like that
2020-12-08 19:46:48 <Cogitri> I think ncopa sent a link to that a few months ago
2020-12-08 19:47:23 <ikke> will be fun on musl based systems
2020-12-08 19:51:11 <Newbyte> that's annoying. there's a package where I need to pull in a commit that hasn't made its way into a release yet because without this commit it doesn't respect the new API in a dependency,  but pulling in this commit also removes setup.py for whatever reason
2020-12-08 19:51:23 <Newbyte> but, I suppose I could split the commit
2020-12-08 19:51:25 <Newbyte> for now
2020-12-08 19:53:44 <Newbyte> though, how would this affect musl-based systems specifically ikke?
2020-12-08 19:54:20 <ikke> depends on if it's still feasible to package python modules or not
2020-12-08 19:54:35 <Newbyte> what would we do otherwise?
2020-12-08 19:54:45 <ikke> but modules with native extensions are generally not built for musl
2020-12-08 19:54:52 <ikke> so end users end up having to compile them
2020-12-08 19:54:53 <Newbyte> ohh, now I see
2020-12-08 19:54:57 <Newbyte> nugh
2020-12-08 19:54:59 <Newbyte> ugh*
2020-12-08 19:55:20 <Newbyte> pulling in binaries doesn't sound fun regardless
2020-12-08 19:55:42 <ikke> that's what pip does on glibc based systems
2020-12-08 19:55:52 <ikke> if there is a binary wheel available
2020-12-08 19:59:39 <Newbyte> what's the current plan for handling the removal of setup.py?
2020-12-08 20:01:31 <Cogitri> Maybe pip install can do the same thing?
2020-12-08 20:01:35 <Cogitri> Like cargo install
2020-12-08 20:03:00 <Cogitri> But dunno about anything python really, would be weird if they'd kill off distro packaging
2020-12-08 20:03:17 <Newbyte> Yeah, I hope they thought this through
2020-12-08 20:03:37 <mps> ikke: regarding your comment about my intention to move gvim to community and split vim to subpackages, I stepped back after this commnet/objection https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13672#note_119421
2020-12-08 20:04:02 <mps> and discussion on !13680
2020-12-08 20:09:29 <ikke> mps: I personally think there is a difference between splitting vim up in many subpackages or splitting gvim from vim
2020-12-08 20:10:00 <ikke> There is ofcourse a maintenance overhead in doing that
2020-12-08 20:10:50 <mps> not much imo, but ok
2020-12-08 20:11:01 <Newbyte> I like the vim and vim-minimal idea
2020-12-08 20:11:53 <mps> Newbyte: my idea was about that, to have minimal and full version
2020-12-08 20:13:50 <mps> it is ridiculous to have big vim pkg and not have keymaps installed (someone told long time ago that keymaps will make vim pkg to big)
2020-12-08 20:15:40 <mps> anyway, without further discussion and possible majority of devs express their stance I will not change g/vim anymore
2020-12-08 20:27:10 <PureTryOut[m]2> Yeah still waiting for this CI job to start, almost 45 minutes later. Not sure what is going on
2020-12-08 20:27:36 <PureTryOut[m]2> Btw pip install can work for us in packaging as well, I recently added a package that did that
2020-12-08 20:27:52 <Newbyte> could you send it as reference PureTryOut (matrix.org) ?
2020-12-08 20:28:08 <PureTryOut[m]2> https://git.alpinelinux.org/aports/tree/testing/py3-upnpclient/APKBUILD
2020-12-08 20:28:19 <PureTryOut[m]2> You need to build a wheel package somehow, seems at least poetry does the job
2020-12-08 20:28:26 <Newbyte> thank you
2020-12-08 20:28:33 <Newbyte> wheel package?
2020-12-08 20:28:44 <PureTryOut[m]2> As long as there is a pyproject.toml available for the package, you can use poetry to build a wheel package which you can then install with pip install
2020-12-08 20:28:59 <PureTryOut[m]2> Newbyte: https://pythonwheels.com/
2020-12-08 20:32:21 <PureTryOut[m]2> ikke: could you check the Gitlab machine again? 45 minutes later I'm still waiting for a CI job to start 😢
2020-12-08 20:34:41 <ikke> and now?
2020-12-08 20:34:58 <PureTryOut[m]2> Yup it started
2020-12-08 20:40:37 <PureTryOut[m]2> Newbyte: actually talking about that particular package, I messed something up, this is the proper way to do it https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15524/diffs
2020-12-08 20:42:02 <PureTryOut[m]2> Uh, seems CI now has network issues? https://gitlab.alpinelinux.org/PureTryOut/aports/-/jobs/266131#L327
2020-12-08 20:42:08 <PureTryOut[m]2> Downloads the source tarball with 0 bytes/sec
2020-12-08 20:42:39 <PureTryOut[m]2> Now it failed yay, restarting
2020-12-08 20:56:48 <Newbyte> PureTryOut (matrix.org): why is that better?
2020-12-08 20:57:06 <PureTryOut[m]2> Because then it actually installs the stuff you need of the package
2020-12-08 20:57:46 <PureTryOut[m]2> (don't ask my why though)
2020-12-08 20:57:50 <PureTryOut[m]2> Without that, it didn't install any Python or PythonC files
2020-12-08 20:59:42 <Newbyte> strange, py3-matrix-nio complains about not finding nio after switching from setup.py to pip install
2020-12-08 20:59:55 <Newbyte> (when running poetry)
2020-12-08 21:01:01 <PureTryOut[m]2> Does the project have a pyproject.toml?
2020-12-08 21:01:05 <PureTryOut[m]2> Otherwise poetry won't do much
2020-12-08 21:01:05 <Newbyte> yes
2020-12-08 21:01:24 <Newbyte> https://github.com/poljar/matrix-nio/blob/master/pyproject.toml
2020-12-08 21:01:45 <PureTryOut[m]2> Hmm, what is your pip install command?
2020-12-08 21:02:20 <Newbyte> I cherrypicked 1662375abba8ebe9d513da24b938f1381d96416a on top of 0.15.2
2020-12-08 21:02:32 <Newbyte> for depdency reasons
2020-12-08 21:04:25 <Newbyte> PureTryOut (matrix.org): https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15515/diffs#37cbab85127e1382f88c471701e2b8157959763a_54_60
2020-12-08 21:04:29 <Newbyte> see line 60
2020-12-08 21:04:50 <Newbyte> in matrix-nio's APKBUILD
2020-12-08 21:06:09 <Newbyte> you can also watch it fail LIVE in the CI!!
2020-12-08 21:06:34 <PureTryOut[m]2> (note that the check won't work, I haven't figured out how to make that work yet)
2020-12-08 21:06:37 <PureTryOut[m]2> Seems good, hmm
2020-12-08 21:06:40 <Newbyte> oh, wait, it didn't find poetry now?
2020-12-08 21:07:13 <Newbyte> oh
2020-12-08 21:07:19 <Newbyte> poetry is in testing
2020-12-08 21:07:20 <Newbyte> I see
2020-12-08 21:07:47 <PureTryOut[m]2> Ah yes that might be an issue
2020-12-08 21:08:04 <Newbyte> still, it didn't fail there locally
2020-12-08 21:08:17 <Newbyte> anyway I'll look into this later
2020-12-08 21:08:35 <PureTryOut[m]2> abuild doesn't really care where in the repos stuff is locally afaik
2020-12-08 21:08:41 <Newbyte> or just not deal with this now and cherrypick the relevant parts of that commit
2020-12-08 21:08:42 <Newbyte> yeah
2020-12-09 01:46:01 <timlegge> The build-edge-aarch64 builder does not seem to be doing anything - stuck on openjdk but is says is failed (Started Dec 6th)
2020-12-09 01:46:25 <alpine-meetbot> timlegge meant to say: The build-edge-aarch64 builder does not seem to be doing anything - stuck on openjdk but it says is failed (Started Dec 6th)
2020-12-09 01:46:25 <timlegge> s/is/it/
2020-12-09 01:46:41 <timlegge> s/is/it/g
2020-12-09 01:46:41 <alpine-meetbot> timlegge meant to say: The build-edge-aarch64 builder does not seem to be doing anything - stuck on openjdk but it says it failed (Started Dec 6th)
2020-12-09 01:47:44 <Hello71> i think it was killed and restarted
2020-12-09 01:59:50 <timlegge> Hello71: weird, everything in the log shows Dec 6th
2020-12-09 04:28:26 <craftyguy> heh I found a bug on pkgs.alpinelinux.org
2020-12-09 04:29:14 <craftyguy> if you try to get the contents of a package with a '+' in the name, like gtk+3.0, it treats the + as a single character wildcard and you get: https://pkgs.alpinelinux.org/contents?branch=edge&name=gtk+3.0-dev&arch=x86_64&repo=main
2020-12-09 04:29:16 <craftyguy> (nothing)
2020-12-09 04:31:54 <craftyguy> err, not a single character wildcard (that's '?'), but the + in the name isn't handled properly
2020-12-09 04:49:41 <[[sroracle]]> it's because it's not urlencoded properly
2020-12-09 04:49:48 <[[sroracle]]> so it gets converted into space
2020-12-09 04:50:02 <[[sroracle]]> it works fine for me if i type it again in the form and submit it that way.
2020-12-09 04:50:16 <[[sroracle]]> i.e. https://pkgs.alpinelinux.org/contents?file=&path=&name=gtk%2B3.0-dev&branch=edge&repo=main&arch=x86_64
2020-12-09 06:23:26 <craftyguy> Ah that makes sense
2020-12-09 06:26:59 <ikke> Cogitri: rust on armv7 is still going
2020-12-09 06:27:13 <ikke> not a single log line produced
2020-12-09 06:27:19 <ikke> So.. that's not good
2020-12-09 06:29:19 <ikke> https://tpaste.us/zxgj
2020-12-09 07:33:47 <Cogitri> Ugh :/
2020-12-09 07:33:59 <Cogitri> Weird that it only gets stuck on 3.13
2020-12-09 07:35:49 <ncopa> good morning
2020-12-09 07:36:53 <ncopa> oh drats... i missed your issue mps, i only looked at issues tagged with kernel
2020-12-09 07:38:32 <ncopa> it looks like we updated autoconf. i wonder if we should rebuild 3.13 world again from scratch? or what do you think?
2020-12-09 07:39:04 <ncopa> we have a ton of packages that uses autoconf and I'd like to be sure that those still builds
2020-12-09 07:54:48 <ikke> Do we have a choice? If we ignore it, it might end up biting us later
2020-12-09 07:56:57 <ikke> How impactful is the new version?
2020-12-09 07:57:33 <ncopa> collects changes since 2012
2020-12-09 07:57:48 <ncopa> yeah, it does bites us already
2020-12-09 07:57:52 <ncopa> i did a few smoketests
2020-12-09 07:58:01 <ncopa> bacula does not build
2020-12-09 07:58:50 <ncopa> i really really really dont want to need to deal with autoconf breakages when doing emergency security fixes for 3.13 in the future
2020-12-09 07:58:59 <ncopa> i think we should revert the autoconf update
2020-12-09 07:59:03 <ncopa> if possible
2020-12-09 07:59:17 <maxice8> sounds good
2020-12-09 07:59:32 <ikke> (+1)
2020-12-09 07:59:53 <ikke> I think that's part of the toolchain freeze, right?
2020-12-09 07:59:59 <ncopa> yes
2020-12-09 08:00:06 <ncopa> i should have been more clear on that sorry
2020-12-09 08:00:17 <ncopa> and unfortunately, i dont think i will have time today
2020-12-09 08:00:28 <ncopa> i was hoping to get the kernels out and do 3.12.2 stable
2020-12-09 08:00:51 <ncopa> there are security fixes and docker image scanners has started to complain
2020-12-09 08:00:59 <ncopa> shoudl also do edge snapshot
2020-12-09 08:01:13 <ikke> also a curl release with 3 CVEs released today
2020-12-09 08:01:32 <ncopa> but seems like things breaks faster than we manage to fix
2020-12-09 08:01:36 <ncopa> oh well
2020-12-09 08:01:52 <ikke> It's hard to fight entropy
2020-12-09 08:02:28 <ncopa> maxice8: can you help deal with autoconf?
2020-12-09 08:02:55 <maxice8> In 3.13?
2020-12-09 08:03:11 <ncopa> i meant revert it
2020-12-09 08:03:39 <ncopa> either that or grep */APKBUILD autoconf and make sure all those builds with autoconf 2.70
2020-12-09 08:04:03 <ikke> ap revdep autoconf
2020-12-09 08:04:16 <maxice8> Yeah sure
2020-12-09 08:04:44 <ncopa> also verify that 3.13 builders didnt pick up new autoconf
2020-12-09 08:05:15 <ncopa> i mean verify that autoconf actually got downgraded
2020-12-09 08:05:22 <maxice8> reverted
2020-12-09 08:05:23 <ikke> I can do that
2020-12-09 08:05:32 <maxice8> 2.69-r3 should be the version
2020-12-09 08:05:39 <ncopa> look for "Installing autoconf ...." in build logs
2020-12-09 08:05:46 <ncopa> thanks!
2020-12-09 08:05:50 <maxice8> 2.69-r2 -> 2.70-r0 -> 2.69-r3
2020-12-09 08:05:56 <ncopa> perfect
2020-12-09 08:06:34 <ncopa> i need to write email to dev mailing list about feature freeze
2020-12-09 08:06:43 <ncopa> but first i need coffe, and breakfast :)
2020-12-09 08:19:14 <mps> FF becoming more and more stable and predictable, it is killed by OOM every morning around coffee time on aarch64 stable release :)
2020-12-09 08:21:16 <mps> same version, but without dbus, pilewire, wifi, pulse is quite stable and good on edge aarch64
2020-12-09 08:21:51 <maxice8> I just use the flatpak :D
2020-12-09 08:22:42 <mps> heh, then we only need kernel, bb and no other packages :)
2020-12-09 08:23:45 <mps> or we can all switch to ubuntu :P
2020-12-09 08:23:46 <insep_> mps: not sure whether that typo was intentional or not
2020-12-09 08:23:58 <maxice8> mps: yes
2020-12-09 08:24:11 <mps> insep_: what typo
2020-12-09 08:25:43 <insep_> pilewire
2020-12-09 08:26:15 <mps> no, I intentionally did this :)
2020-12-09 08:26:49 <insep_> then i agreed
2020-12-09 08:27:24 <mps> I like when day start with some humor and/or irony
2020-12-09 08:36:02 <mps> 'just in time' qemu 5.2 is released. ncopa: do you think we should upgrade it right now, to have it for next stable?
2020-12-09 08:36:57 <ikke> I would say next release, not?
2020-12-09 08:38:27 <mps> next stable alpine release (3.13-stable), I mean. ?
2020-12-09 08:39:12 <ikke> I mean next next :)
2020-12-09 08:42:19 <mps> ah, that is 'never-stable-release' called edge :)
2020-12-09 08:43:44 <mps> uhm, they switched to ninja build
2020-12-09 08:45:03 <Cogitri> w/ meson?
2020-12-09 08:45:05 <mps> and full pile of ' #warning redirecting incorrect #include <sys/signal.h> to <signal.h>'
2020-12-09 08:45:36 <mps> Cogitri: apk add ninja is enough, or looks like for now
2020-12-09 09:10:47 <ncopa> i think qemu is relatively low risk
2020-12-09 09:10:58 <ncopa> its not a build time dep for many things
2020-12-09 09:15:28 <mps> yes, removed 2 patches and 'sed' in prepare, and adding ninja is enough to build
2020-12-09 09:16:08 <mps> but some subpackages need 'rearrange' and changes
2020-12-09 09:17:18 <mps> ivshmem tool is changed, not yet sure how much
2020-12-09 09:28:29 <mps> and I think I found last night why crystal segfaults in check(), gdb show that the issue is probably in 'gc' lib
2020-12-09 09:30:28 <mps> so, if we want crystal in 3.13 we will need upgrade gc to some git commit or heavy patching
2020-12-09 09:43:44 <mps> hm, https://wiki.qemu.org/ChangeLog/5.2#Build_Information, 'build system is now partly based on Meson. However, building is still done with configure and make as in previous versions of QEMU'
2020-12-09 09:44:29 <mps> like joke about Britain to switch driving on right side :)
2020-12-09 10:16:52 <mps> huh, abuild package fails with 'install: can't change ownership of /home/mps/aports/community/qemu/pkg/qemu/etc/qemu/bridge.conf: Operation not permitted' though 'pkggroups="qemu"' exists
2020-12-09 10:19:38 <mps> also 'chgrp: /home/mps/aports/community/qemu/pkg/qemu/usr/lib/qemu/qemu-bridge-helper: Operation not permitted'
2020-12-09 10:48:24 <mps> hhhm, >>> qemu-doc*: Running split function doc... => mv: can't rename '/home/mps/aports/community/qemu/pkg/qemu/usr/share/doc': Directory not empty
2020-12-09 10:48:49 <mps> and directory is empty for sure, I think
2020-12-09 10:51:23 <mps> and this, mv: can't rename '/home/mps/aports/community/qemu/pkg/qemu/usr/share/man': Directory not empty
2020-12-09 10:52:47 <mps> hmm, maybe I should 'rm -rf pkg' before invocation of 'abuild rootpkg'
2020-12-09 11:22:37 <mps> got qemu 5.2 apks \o/
2020-12-09 11:22:59 <mps> just have to fix problem with chgroup
2020-12-09 11:25:17 <mps> oh, and one test failed
2020-12-09 11:27:42 <mps> ah, '!ckeck' is already ;)
2020-12-09 11:29:29 <mps> check*
2020-12-09 12:10:13 <timlegge> can someone look at !15496 only thing failing on move to community is aarch64 dependency from a few days ago - that builder is blocked
2020-12-09 12:12:06 <ikke> timlegge: aarch64 is stuck atm on openjdk7, need to figure out what to do with that
2020-12-09 12:13:07 <ikke> ncopa: any idea what to do with openjdk7? Do you see issues disabling it?
2020-12-09 12:16:48 <timlegge> ikke: I noticed.  Its a real PITA for moving dependant packages :-)
2020-12-09 12:16:54 <ikke> yes
2020-12-09 12:17:17 <mps> how do we indent git commit messages with enumerations (list)? spaces or tab?
2020-12-09 12:17:32 <ikke> I typically use 2 spaces
2020-12-09 12:17:58 <mps> heh, good, looks like I'm looking your screen :)
2020-12-09 12:18:23 <ikke> :P
2020-12-09 12:20:54 <mps> !15554, please review
2020-12-09 12:21:46 <mps> removed is html from qemu-doc as comment above it in APKBUILD already says
2020-12-09 12:25:56 <mps> so ninja need bash, https://gitlab.alpinelinux.org/mps/aports/-/jobs/266754#L1098
2020-12-09 12:40:33 <Cogitri> > ERROR: libucontext-dev-0.13-r0: failed to rename usr/lib/.apk.56ddbe4a4e20d454c6af781a2b260c68864952ab06a50aa1 to usr/lib/pkgconfig.
2020-12-09 12:40:34 <Cogitri> :/
2020-12-09 12:40:39 <Cogitri> https://gitlab.alpinelinux.org/Geod24/aports/-/jobs/266765
2020-12-09 12:51:40 <Cogitri> ncopa: Can we still get ldc-1.24 in? I know that technically it's toolchain but I'd argue it's not core toolchain and our old ldc isn't really that useful anymore
2020-12-09 12:52:05 <Cogitri> And the new ldc version fixed loads of things (like musl 64-bit time_t compat), so our current D programs on 32-bit are probably broken anyway
2020-12-09 13:10:03 <oliv3r[m]> Hey All, I'm trying to figure out how the public keys are named. They contains a crc32 it seems, but when running crc32 on the file, the tool actually figures and finds the crc32, but complains about it not matching. Where is the repo/code that generates these alpine-keys? I know the APKBUILD has the files pre-generated.
2020-12-09 13:10:22 <ncopa> do we have many pacakges that is built with ldc? would it be a big task to rebuild those?
2020-12-09 13:11:01 <Cogitri> ncopa: Only 7 in community and another handful in testing
2020-12-09 13:11:23 <ncopa> is it big job to rebuild the ones in community at least?
2020-12-09 13:11:36 <ncopa> if not, I'd say go for it
2020-12-09 13:11:53 <Cogitri> Okay. Shouldn't be a big task, so I hope everything should just work (famous last words, I know :D)
2020-12-09 13:15:58 <ncopa> disabling openjdk7 is sort of problematic because it will make build of openjdk8 to fail
2020-12-09 13:16:22 <ncopa> do we know why openjdk7 fails?
2020-12-09 13:16:58 <ikke> ncopa: it hangs
2020-12-09 13:17:11 <ncopa> on all arches?
2020-12-09 13:17:50 <ikke> aarch64 only
2020-12-09 13:17:51 <ikke> apparently
2020-12-09 13:17:58 <ikke> the rest all completed
2020-12-09 13:18:03 <ncopa> looking at git history, it looks like the sec updates have been reverted in the past
2020-12-09 13:18:12 <ikke> yes
2020-12-09 13:20:01 <ikke> I have at least a partial bt
2020-12-09 13:21:19 <ncopa> do we have opnejdk8 in the build queue? in case we disable it
2020-12-09 13:22:19 <ncopa> do we know what is deadlocking? is it javac or gnu make?
2020-12-09 13:22:40 <ikke> no
2020-12-09 13:22:53 <ikke> I mean, no openjdk in the edge build queue
2020-12-09 13:23:28 <ikke> it's a java process I think]
2020-12-09 13:23:32 <ncopa> can we reproduce the deadlock in a dev env?
2020-12-09 13:24:37 <ikke> starting a build in my container
2020-12-09 13:25:18 <ncopa> iff we disable openjdk7, who will follow it up, and make sure it builds again?
2020-12-09 13:25:30 <ncopa> I mean so we dotn forget about it
2020-12-09 13:25:38 <ikke> ncopa: bratkartoffel is involved
2020-12-09 13:26:03 <ncopa> im building openjdk7 in my container too
2020-12-09 13:35:54 <ikke> ncopa: maybe fakeroot blocking rust on armv7? https://gitlab.alpinelinux.org/alpine/aports/-/issues/12178#note_129329
2020-12-09 13:37:17 <ncopa> oh, could be
2020-12-09 13:37:28 <ikke> do we want to push a dbg package for fakeroot?
2020-12-09 13:37:29 <ncopa> iirc rus tries to rebuild stuff in fakeroot
2020-12-09 13:37:41 <ikke> ah
2020-12-09 13:37:45 <ncopa> i think a dbg package for fakeroot makes sense
2020-12-09 13:37:51 <ncopa> rust is annoying
2020-12-09 13:37:56 <ikke> yes
2020-12-09 13:39:19 <skarnet> nomination for the understatement of the month
2020-12-09 13:39:36 <Cogitri> Bootstrapping it certainly isn't fun
2020-12-09 13:46:24 <ddevault> I wasted yesterday afternoon on a failed bootstrapping attempt
2020-12-09 13:46:37 <ddevault> rust sucks
2020-12-09 14:05:51 <insep_> agreed
2020-12-09 14:06:26 <insep_> d sucks a little less, but they don't support risc-v yet
2020-12-09 14:06:28 <insep_> probably
2020-12-09 14:06:45 <insep_> they don't really support armv7 either
2020-12-09 14:07:29 <eloi> Hi. I am looking for some help with #15216. I want to build a OpenSMTPD package with support for the PAM library. The people on the MR suggested to create a opensmtpd-pam package with the option "replaces=opensmtpd". I am worried about the file duplication of this solution and the additional time that maintaining two distinct packages would require. Is there some example of such varying packages in the repository? In your
2020-12-09 14:07:29 <eloi> opinion what is the good practice to deal with this situation?
2020-12-09 14:07:39 <insep_> actually official compiler doesn't support anything but x86(_64), support for other arches is available only in llvm-based fork
2020-12-09 14:08:04 <ddevault> ghc has a dubious patch
2020-12-09 14:08:13 <ddevault> go was a breeze to bootstrap
2020-12-09 14:08:27 <Cogitri> insep_: Well, the DMD frontend doesn't support anything other than x86, the backend does
2020-12-09 14:08:49 <Cogitri> D is pretty ok to bootstrap thanks to gdc too
2020-12-09 14:09:09 <Cogitri> Maybe mrustc will catch up to current rust in the future and make rust ok to bootstrap too
2020-12-09 14:10:44 <insep_> Cogitri: that's why support for other arches is available in ldc, which is a fork (technically) of dmd
2020-12-09 14:11:44 <Cogitri> Yup, it uses the dmd backend
2020-12-09 14:32:56 <mps> eloi: not much can be done to solve issue (I didn't looked MR though)
2020-12-09 14:33:44 <mps> if opensmtpd doesn't support 'modular/module' build, that is
2020-12-09 14:34:33 <mps> 
ACTION wonder why anyone use some other smtp server when we have postfix

2020-12-09 14:38:33 <eloi> What do you mean? With the right ./configure option opensmtpd can be built with PAM support, but jirutka suggested to build a subpackage instead. I am not sure how to achieve this though, I could not find documentation nor examples where a subpackage would share almost every property with the parent package, but for the ./configure options and a few dependencies.
2020-12-09 14:39:39 <eloi> Opensmtpd feels very light, you can write a full configuration for your server with a few lines.
2020-12-09 14:39:55 <eloi> And..., I am used to it :)
2020-12-09 14:40:04 <Hello71> eloi: mps is saying that opensmtpd should have a dynamic module for pam support
2020-12-09 14:40:17 <mps> eloi: that's ok for me
2020-12-09 14:40:40 <Hello71> this is contrary to openbsd development model though. same way nobody would want busybox with dlopen pam support
2020-12-09 14:40:46 <eloi> Hello71: ok I understand.
2020-12-09 14:41:02 <mps> but I never tried to build it, so I don't know if it can build 'modules', as Hello71 says
2020-12-09 14:41:05 <Hello71> even if it is technically possible to implement
2020-12-09 14:41:29 <Hello71> eloi: you can investigate other *-pam packages e.g. busybox-pam
2020-12-09 14:42:59 <skarnet> obligatory reminder that PAM is a security nightmare and the more stuff you link against it the more difficult it is to take it away
2020-12-09 14:43:27 <eloi> Ok Hello71 thank you for the tip
2020-12-09 14:44:19 <mps> skarnet: thanks :)
2020-12-09 14:44:32 <Hello71> yeah, pam opensmtpd doesn't make much sense
2020-12-09 14:44:53 <Hello71> especially since apparently it only supports plain/login sasl, so you cannot implement 2fa or whatnot
2020-12-09 14:46:08 <skarnet> I tried writing PAM isolation software, as in "have the PAM stuff happen in another process", like I did with utmp and nsswitch, but it doesn't work with >50% of software using PAM
2020-12-09 14:46:34 <skarnet> because applications *do use* the in-process features of PAM which make it a security nightmare
2020-12-09 14:46:44 <skarnet> such as allowing PAM modules to modify the app's environment
2020-12-09 14:46:51 <ddevault> agreed RE: PAM
2020-12-09 14:47:20 <ddevault> no one should use PAM, it's an awful, awful package
2020-12-09 14:47:47 <skarnet> and the parts that are documented are about a third of what applications actually use
2020-12-09 14:47:47 <eloi> Well, I need LDAP auth support for my mailserver, and the OpenSMTPD maintainer said he won't develop it and users should just use PAM. https://github.com/OpenSMTPD/OpenSMTPD/issues/812#issuecomment-458482184
2020-12-09 14:48:22 <ddevault> I would sooner switch mail servers than install PAM
2020-12-09 14:48:42 <eloi> Well, I may do that indeed...
2020-12-09 14:49:06 <skarnet> it makes sense to delegate authentication to the system instead of replicating N auth schemes in every app
2020-12-09 14:49:08 <mps> to repeat myself: postfix
2020-12-09 14:49:12 <skarnet> but PAM is entirely the wrong way to go about it
2020-12-09 14:49:42 <Hello71> cyrus-sasl doesn't seem an improvement though
2020-12-09 14:49:55 <eloi> How would you do that then skarnet?
2020-12-09 14:50:19 <skarnet> unfortunately, on this point, I have no better solution than "napalm down the world and rebuild everything sanely"
2020-12-09 14:50:21 <ddevault> I would question the need for N auth schemes in the first place
2020-12-09 14:51:56 <eloi> system auth, flat file auth and LDAP auth can all be interesting on some situations
2020-12-09 14:52:16 <skarnet> if it's just about that then it can be achieved via nsswitch and I even have a secure way to do that
2020-12-09 14:52:37 <skarnet> PAM is when you need other functionality than regular getpwnam() and friends
2020-12-09 14:54:45 <Hello71> using userPassword though, not real ldap authentication?
2020-12-09 14:56:51 <skarnet> well yeah, that's the limitation of /etc/passwd emulation
2020-12-09 14:56:57 <eloi> Doesn't real ldap auth use userPassword?
2020-12-09 14:57:22 <skarnet> if you want more auth schemes such as certificates etc. then you have to use other APIs than getpwnam() and getspnam()
2020-12-09 14:57:32 <Hello71> well you can ldap auth by actual ldap auth
2020-12-09 14:57:48 <Hello71> which i think is usually actually kerberos?
2020-12-09 14:58:33 <skarnet> ldap: the remote key-value store that also comes with a wonky naming scheme and specific crypto
2020-12-09 14:58:41 <skarnet> because design, folks
2020-12-09 14:58:52 <skarnet> we is berry berry good at design
2020-12-09 14:59:00 <Hello71> right, but you can't access those by sasl plain/login anyways
2020-12-09 14:59:43 <Hello71> ah, I remember now. ldap *also* uses sasl. so you could forward smtp auth to sasl auth on an ldap server, but that's not really ldap auth
2020-12-09 15:01:53 <Hello71> skarnet: redis ldap frontend? :p
2020-12-09 15:05:06 <skarnet> miss me with that enterprise shit
2020-12-09 15:40:42 <ncopa> ok i have reproduced the openjdk7 hang
2020-12-09 15:41:29 <ikke> ncopa: ok, good
2020-12-09 15:41:39 <ikke> for me the build passed
2020-12-09 15:42:18 <ncopa> i have two java processes that look suspicious
2020-12-09 15:42:46 <ncopa> 31.4g and 31.3g VSZ
2020-12-09 15:44:02 <ncopa> strace: Process 5432 attached
2020-12-09 15:44:02 <ncopa> futex(0xfff377a34284, FUTEX_WAIT_PRIVATE, 2147483652, NULL
2020-12-09 15:44:18 <ncopa> it is running ant
2020-12-09 15:44:49 <ncopa> strace: Process 5078 attached
2020-12-09 15:44:49 <ncopa> futex(0xfff376facaf0, FUTEX_WAIT_PRIVATE, 2, NULL
2020-12-09 15:45:01 <ncopa> so both are waiting for a futex
2020-12-09 15:46:27 <ikke> are they waiting for eachother?
2020-12-09 15:49:59 <Hello71> ncopa: did you remember to put -f
2020-12-09 15:52:25 <ncopa> nope
2020-12-09 15:53:52 <ncopa> but this is kinda interesting. it seems like the deadlock happens in rdlock from calloc, from opendir, from closeDescriptors from yes you guessed it: childProcess
2020-12-09 15:54:05 <ncopa> it looks like the malloc from child problem
2020-12-09 15:54:34 <ncopa> which i though we had solved in musl by now
2020-12-09 15:55:11 <mps> anyone can help with 'gc' (garbage collector) debug, https://tpaste.us/MQ49
2020-12-09 15:55:42 <mps> that is where I'm now, and don't know how to debug shared libs
2020-12-09 15:56:27 <ikke> ncopa: I could not debug it yesterday, but we had a deadlock in py3-peewee as well
2020-12-09 15:57:00 <ncopa> the other process is waiting on pthread_join apparently
2020-12-09 15:58:04 <ncopa> i think we can solve openjdk7 by adding the patch from openjdk8
2020-12-09 15:58:15 <ncopa> but im a bit surprised that it happens
2020-12-09 15:59:02 <ncopa> i wonder if dalias may be interested in this
2020-12-09 16:00:18 <ncopa> dalias: it seems like openjdk7 build hangs due to a malloc in a child, even from musl git master
2020-12-09 16:03:00 <ncopa> but apparently only on aarch64
2020-12-09 16:05:24 <ddevault> Ariadne: can I email you a patch for alpine-gcc-patches
2020-12-09 16:05:32 <ddevault> I'm trying to fork it on gitlab but it's taking ages because gcc is huge
2020-12-09 16:05:52 <Ariadne> works for me
2020-12-09 16:06:01 <ddevault> cheers
2020-12-09 16:33:33 <dalias> ncopa, i am interested. what do i need to read?
2020-12-09 16:35:45 <Hello71> for 3.14 I think we should consider crosscompile openjdk instead of chaining these unsupported versions. even ignoring security vulnerabilities, i think these build failures and consequent local patches will accumulate in future
2020-12-09 16:37:58 <ikke> dalias: on aarch64, openjdk consistently deadlocks. There are 2 processes both waiting on a futex
2020-12-09 16:38:27 <ikke> trying to get a bt
2020-12-09 16:40:55 <ikke> dalias: https://tpaste.us/E14D
2020-12-09 16:41:01 <ikke> huge bt (thread apply all bt full)
2020-12-09 16:44:18 <dalias> it it doing anything funky instead of proper fork?
2020-12-09 16:45:54 <dalias> ok i thouht ncopa wais there was a malloc involved but i dont see any
2020-12-09 16:46:30 <dalias> looks like they're all waiting on a cond var
2020-12-09 16:47:10 <dalias> or rather a bunch of different condvars
2020-12-09 16:48:40 <ikke> Well, I don't see neither of the functions that ncopa mentioned
2020-12-09 16:49:00 <ikke> Let me bt the child process
2020-12-09 16:49:55 <ikke> dalias: this shows more what ncopa mentioned: https://tpaste.us/0Em7
2020-12-09 16:50:11 <ikke> I see references to vfork
2020-12-09 16:51:33 <dalias> i bet it's doing something idiotic and unsafe after vfork
2020-12-09 16:52:16 <dalias> vfork usage should just be disabled. it's all wrong.
2020-12-09 16:53:30 <dalias> java has ifdefs for use of vfork vs fork vs posix_spawn with jspawnhelper
2020-12-09 16:53:45 <dalias> the vfork path is absolutely wrong and should never be used
2020-12-09 16:53:59 <dalias> the fork path is wrong but should work with MT-fork (musl 1.2.2)
2020-12-09 16:54:07 <dalias> the posix_spawn path is correct
2020-12-09 16:54:27 <dalias> can you tell which is being used?
2020-12-09 17:00:53 <ikke> Hmm, any way to find out
2020-12-09 17:02:35 <dalias> reading the source? :)
2020-12-09 17:02:45 <ikke> heh
2020-12-09 17:02:55 <dalias> you can patch #error into each #ifdef path and see which one gets displayed when you build it
2020-12-09 17:03:14 <ikke> I see "Thread model: posix" in the config.log
2020-12-09 17:03:17 <dalias> or you can put a breakpoint there and step thru the function to see which lines get run, if you have debug info
2020-12-09 17:03:25 <dalias> yes this isn't about thread model
2020-12-09 17:03:41 <dalias> it's the child spawn model (not sure what they call it)
2020-12-09 17:06:35 <ikke> LuanchMechanism I ugess
2020-12-09 17:06:36 <ikke> guess
2020-12-09 17:06:43 <ikke> /* default is VFORK on Linux */
2020-12-09 17:07:11 <dalias> lololololol :)
2020-12-09 17:07:49 <dalias> vfork clearly documents that you can't even inspect variables or do anything other than exec* or _exit from the vfork child
2020-12-09 17:07:59 <dalias> but yolo why not malloc
2020-12-09 17:08:17 <dalias> fucking java shit
2020-12-09 17:08:33 <dalias> anyway i thought this was fixed a long time ago because of course it didn't work so .... ?
2020-12-09 17:08:36 <dalias> still confused
2020-12-09 17:08:43 <dalias> maybe somehow it regressed
2020-12-09 17:09:01 <ikke> or different openjdk versions
2020-12-09 17:09:08 <ikke> we maintain multiple
2020-12-09 17:10:38 <dalias> ah yeah
2020-12-09 17:10:53 <dalias> well if you can confirm it's using vfork, there's your problem
2020-12-09 17:11:27 <dalias> you really should force it to use posix_spawn if possible because that's the fastest (converting a fucking java process's VM space to COW is not cheap) and most correct
2020-12-09 17:11:58 <dalias> and if not, well, now with musl 1.2.2 the fork path should work but it's slow
2020-12-09 17:12:16 <ikke> The enum has 2 options: FORK and VFORK
2020-12-09 17:12:16 <dalias> (and will gratuitously fail with ENOMEM if you don't have enough overcommit)
2020-12-09 17:12:43 <dalias> hmm thats weird because the backtrace has a spawnhelper pathname in it...
2020-12-09 17:13:06 <dalias> maybe this is a version from before the posix_spawn path worked
2020-12-09 17:13:19 <ikke> helperpath = toCString(javahome + "/lib/" + osArch + "/jspawnhelper");
2020-12-09 17:13:23 <dalias> or maybe posix_spawn just replaces one of those two silently or something ridiculous
2020-12-09 17:16:03 <ncopa> i might be able to follow up this tomorrow. we have a patch for openjdk8 that i could try port to openjdk7, which avoids the opendir thingy
2020-12-09 17:16:11 <ncopa> but my time is up for now sorry
2020-12-09 17:16:20 <ikke> np
2020-12-09 17:16:26 <ikke> tomorrow another day
2020-12-09 17:16:42 <ikke> ill kill java to give the builder a chance to advance
2020-12-09 17:17:05 <dalias> ncopa, opendir isn't the problem
2020-12-09 17:17:23 <dalias> as i remember it, they're doing *all sorts* of unsafe junk in the vfork child
2020-12-09 17:17:37 <dalias> just switching it to fork or posix_spawn if possible is the right fix (disabling the vfork support)
2020-12-09 17:19:26 <ikke> in the source, before building, there is only one rerefence to vfork, and that is in java code
2020-12-09 17:20:10 <ikke> It gets the launch method from a System.property, which defaults to vfork
2020-12-09 17:21:28 <ikke> I'll try to switch the default to fork
2020-12-09 17:21:46 <ikke> but first need to confirm if I can reproduce it in my dev env
2020-12-09 17:25:50 <ikke> hmm, same happens now with openjdk7 on 3.13 aarch64
2020-12-09 17:33:05 <dalias> i think it would work to just #define vfork fork
2020-12-09 17:33:15 <dalias> so that vfork is permanently disabled and inaccessible
2020-12-09 17:33:28 <dalias> this is what would happen on targets without vfork.s anyway
2020-12-09 17:36:36 <dalias> probably better to just kill the ability to set it to vfork
2020-12-09 17:36:47 <dalias> since the code path might also have other stuff that's wrong
2020-12-09 17:44:08 <Hello71> there is a comment that says "maybe switch to posix_spawn by default in future" or somesuch
2020-12-09 17:44:46 <Hello71> but, as is typical with enterprise projects, nobody is in charge of code correctness, so as long as it looks like it works, nobody dares change it
2020-12-09 18:01:51 <dalias> :-p
2020-12-09 18:03:53 <bratkartoffel> a typical case for "never change a running system"? anyways, just read through the irclogs. ikke, you need help with the vfork patch?
2020-12-09 18:08:29 <ikke> I'm occupied right now, so would be nice if you could take a look
2020-12-09 18:17:47 <ollieparanoid[m]> hey, all!
2020-12-09 18:17:57 <ollieparanoid[m]> when will the 3.13-stable aports.git branch get created?
2020-12-09 18:19:14 <ikke> After the release
2020-12-09 18:20:15 <ikke> Right now the builders track master
2020-12-09 18:27:23 <ollieparanoid[m]> so it it at the same time as the release is announced? I assumed that it would be a bit in advance
2020-12-09 18:27:26 <ikke> Yes
2020-12-09 18:28:26 <ollieparanoid[m]> ah okay. I know that there isn't a fixed date for alpine releases, but is there a rough estimation when it will be ready?
2020-12-09 18:28:27 <bratkartoffel> oh my, i've pushed the wrong version in the last openjdk7 upgrade... secfixes comment is currently wrong
2020-12-09 18:28:29 <bratkartoffel> ikke: !15562
2020-12-09 18:28:31 <bratkartoffel> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15562
2020-12-09 18:31:53 <Hello71> if anyone wants to sign oracle cla i think you can probably get them to switch to posix_spawn by default upstream
2020-12-09 18:32:14 <Hello71> also this seems like not a good patch, because LaunchMechanism will be incorrect
2020-12-09 18:33:53 <dalias> ahhhh i see why it deadlocked on aarch64
2020-12-09 18:34:07 <dalias> aarch64 has no vfork.s so it calls plain fork syscall
2020-12-09 18:34:38 <dalias> this is not the fork function but the syscall
2020-12-09 18:34:59 <dalias> so it gives a highly restricted child environment like vfork would, but isn't sharing memory
2020-12-09 18:35:25 <dalias> with a real vfork, doing the shit they do from the child is horrible UB, but it happens to work because it syncs with the other threads in the parent
2020-12-09 18:35:34 <dalias> (the child thinks it's a thread of the parent)
2020-12-09 18:36:44 <dalias> but with vfork-as-fork, the situation is worse than pre-MTfork
2020-12-09 18:36:46 <bratkartoffel> so my patch doesn't change anything? sorry, i'm not that deep into c
2020-12-09 18:36:56 <dalias> bratkartoffel, no no your patch is perfect
2020-12-09 18:37:15 <dalias> it makes it call the fork function (and whatever other stuff is in their fork code path) rather than the vfork function
2020-12-09 18:38:26 <dalias> but folks might complain that it starts OOM'ing or whatever :-p
2020-12-09 18:39:10 <dalias> a bunch of other archs should also be hitting the same thing
2020-12-09 18:39:19 <ikke> I think people using Java are more then used to that :-P
2020-12-09 18:39:22 <dalias> ppc(both), mips(all), ...
2020-12-09 18:39:44 <dalias> only arm, i386, s390x, sh, x32, and x86_64 have real vforks
2020-12-09 18:41:25 <ikke> Should this patch also ported to newer jdk's?
2020-12-09 18:41:50 <dalias> probably
2020-12-09 18:46:18 <Hello71> according to, uh... something I read, 7 should have posix_spawn implemented
2020-12-09 18:53:14 <Hello71> my mistake, it's 11+
2020-12-09 18:57:40 <Hello71> so for 11+, posix_spawn should be preferred, and for other versions, fork. it should be patched out in java though, not c
2020-12-09 18:57:54 <Hello71> or should be patched out in both
2020-12-09 18:58:14 <ikke> fork or vfork?
2020-12-09 18:59:03 <Hello71> vfork disabled by default or removed entirely
2020-12-09 18:59:13 <Hello71> disable by default is easy, just reorder the LaunchMechanisms
2020-12-09 19:04:13 <tdtrask> I would like to build alpine packages on my Mint PC. Any recommendations? Create VM? Use docker-abuild? Just not sure what the latest recommendation is.
2020-12-09 19:05:19 <bratkartoffel> i'm currently using wsl2
2020-12-09 19:05:49 <bratkartoffel> runs pretty good
2020-12-09 19:07:57 <tdtrask> https://wiki.alpinelinux.org/wiki/Setting_up_the_build_environment_on_HDD is still linked from category, but last updated in 2012!
2020-12-09 19:08:48 <tdtrask> https://wiki.alpinelinux.org/wiki/Alpine_Linux_in_a_chroot just updated 3 days ago
2020-12-09 19:11:53 <dalias> removed entirely. java is supposed to be a safe lang so it should not have a code path to execute explosive UB in C
2020-12-09 19:12:56 <dalias> wsl2 is kinda a disappointment. the idea of wsl[1] was light independent implementation of linux syscall surface
2020-12-09 19:13:08 <dalias> then wsl2 just dropped linux into a vm
2020-12-09 19:13:45 <dalias> linux vm on windows is of course also nice, but we already had plenty of those
2020-12-09 19:37:12 <ericonr> hi! is the maintainer of supertux2 here? you might want to pull https://github.com/void-linux/void-packages/pull/27054 as a patch for it ;)
2020-12-09 19:38:05 <ericonr> oops, meant to send the upstream PR: https://github.com/SuperTux/supertux/pull/1601
2020-12-09 19:47:33 <[[sroracle]]> i don't think adelie has had any vfork problems with jdk8 on any of our archs...
2020-12-09 19:47:48 <[[sroracle]]> we are still on musl 1.2.0 if that matters though
2020-12-09 19:50:36 <Hello71> actually it should have the same problem on all jdk versions, because the default is still vfork
2020-12-09 19:51:09 <Hello71> [[sroracle]]: it was working on alpine before too so it is (more) broken on new musl
2020-12-09 19:51:32 <Hello71> anyways, it needs to be fixed for all java versions, not just 7
2020-12-09 20:05:01 <dalias> hello71, i don't see why new musl triggered it. probably just got unlucky with old
2020-12-09 20:05:16 <dalias> in particular the patch that fixed lock omission after fork didn't apply to vfork
2020-12-09 20:05:47 <Hello71> i mean new compared to 1.2.0
2020-12-09 20:05:58 <Hello71> not sure what you mean
2020-12-09 20:05:59 <dalias> *nod* same here
2020-12-09 20:06:11 <dalias> well there were 2 changes
2020-12-09 20:06:38 <dalias> lots of ppl wrongly blamed mallocng for the mtfork stuff but it was actually fixing the lock omission bug that exposed the deadlocks (vs unnoticed memory corruption)
2020-12-09 20:06:47 <Hello71> yes
2020-12-09 20:06:55 <dalias> that couldn't have affected vfork
2020-12-09 20:07:12 <dalias> but oldmalloc did make it moderately less likely to hit too
2020-12-09 20:18:42 <ikke> dalias: strange, for some reason, the bug does not trigger in my lxc container
2020-12-09 20:18:47 <ikke> (on the same host)
2020-12-09 20:19:25 <Hello71> well assuming it's a vfork issue then it's a race condition
2020-12-09 20:20:25 <ikke> yes, but on the builders, it triggers every time
2020-12-09 20:20:41 <ikke> on edge and now also 3.13
2020-12-09 20:22:10 <ikke> ncopa managed to reproduce it as well
2020-12-09 20:31:43 <dalias> could be all sorts of reasons timing happens different
2020-12-09 20:33:18 <mps> first signs of AI ascent ;p
2020-12-09 20:54:49 <ikke> Oh, I think I have bingo now
2020-12-09 20:58:39 <maxice8> made an MR to remove fakeroot-tcp now that fakeroot is compiled with --with-ipc=tcp
2020-12-09 20:58:43 <maxice8> !15566
2020-12-09 21:01:44 <maxice8> our curl is... suboptimal
2020-12-09 21:01:57 <dalias> ikke, ?
2020-12-09 21:02:21 <dalias> wait what?
2020-12-09 21:02:25 <dalias> fakeroot tcp?
2020-12-09 21:02:41 <dalias> this sounds like a huge vuln
2020-12-09 21:02:58 <ikke> dalias: a deadlock in my container
2020-12-09 21:03:23 <ikke> maxice8: what is wrong with our curl?
2020-12-09 21:03:26 <dalias> are they transporting events over unauthenticated tcp?
2020-12-09 21:03:47 <maxice8> @Ikke a few CVEs in 3.12 to 3.9 are not fixed (2 issues + the ones fixed recently)
2020-12-09 21:04:00 <dalias> ikke, ah
2020-12-09 21:05:42 <ikke> Backtrace stopped: previous frame identical to this frame (corrupt stack?) :( for cargo
2020-12-09 21:28:11 <Hello71> fwiw the latest vulnerabilities are pretty minor
2020-12-09 21:28:24 <ikke> yes, indeed
2020-12-09 21:28:36 <ikke> I watched the curl release stream today
2020-12-09 21:28:51 <ikke> 2 ftp related and one ocsp
2020-12-09 21:30:34 <maxice8> But they are not the only ones and the older ones had no follow up
2020-12-09 21:31:08 <ikke> were there tickets for the,?
2020-12-09 21:31:45 <maxice8> yes there are confidential issues for them
2020-12-09 21:31:55 <ikke> ok
2020-12-09 21:31:55 <maxice8> just search 'curl:'
2020-12-09 21:31:57 <ikke> nod
2020-12-09 22:39:35 <omni> syslinux could need a reboot, no?
2020-12-09 22:40:06 <omni> things seem a bit scattered
2020-12-09 22:42:10 <dalias> ?
2020-12-09 22:54:29 <omni> just that it seem to receive few updates and that rarely, alpine is using a development pre-release, there are workarounds for things that may have patches in a later pre-release (but seem to be unwise to use because of reasons)
2020-12-09 22:57:47 <omni> there's a mailing list with some activity, a wiki with a lot of outdated info and a bugtracker with quite old issues
2020-12-09 23:02:51 <omni> I began looking because of a common workaround where you 'mkfs.ext4 -O ^64bit -E nodiscard' so that syslinux can boot from the ext4 fs
2020-12-09 23:05:14 <omni> that seem to be fixed in a commit from 2017-10-11
2020-12-09 23:08:50 <mps> omni: alpine boots from ext4 long time
2020-12-09 23:10:30 <dalias> sounds like there's some 64-bit mode that broke some bootloaders
2020-12-09 23:10:41 <dalias> but it's only needed for >15 TB volumes so...
2020-12-09 23:15:10 <dalias> ariadne, pushed some further changes for 1.2.2 -- i'd overlooked a couple non-MTfork-safe pthread_once calls
2020-12-09 23:20:03 <Hello71> imo alpine default should be switched to grub
2020-12-09 23:20:19 <Hello71> grub kinda sucks, but syslinux kinda sucks more atm
2020-12-09 23:20:54 <mps> syslinux is quite fine
2020-12-09 23:21:15 <omni> probably is
2020-12-09 23:21:19 <mps> ok, no but better than grub for me
2020-12-09 23:21:30 <omni> same
2020-12-09 23:22:01 <mps> but some new boards will not boot with syslinux
2020-12-09 23:22:26 <maxice8> Hello71 systemd-bootd here we come
2020-12-09 23:22:53 <Hello71> there is already systemd-boot and it sucks less than either syslinux or grub
2020-12-09 23:22:54 <omni> what I mean with that "things seem a bit scattered" is that it might hold possible contributors at bay
2020-12-09 23:23:16 <tehcloud> bring back LILO
2020-12-09 23:23:27 <omni> heh
2020-12-09 23:23:30 <mps> also, arm64 in uefi mode will only boot with grub, though syslinux never worked on them
2020-12-09 23:23:34 <maxice8> Hello71: i know https://github.com/void-linux/void-packages/pull/10469
2020-12-09 23:23:47 <Hello71> systemd-boot is probably the most suckless part of systemd, in part because they imported it from gummiboot and in part because the vertical integration is limited by arbitrary kernel/initrd
2020-12-09 23:24:15 <mps> Hello71: name is scary :)
2020-12-09 23:24:17 <Hello71> but i'm sure if systemd initrd was more popular they would add much more fdo standards to boot process
2020-12-09 23:24:44 <dalias> i love syslinux
2020-12-09 23:24:54 <dalias> using it instead of grub is one of the nice things about alpine
2020-12-09 23:25:11 <omni> I too prefer and use syslinux over grub
2020-12-09 23:25:19 <Hello71> alpine isn't particularly tied to syslinux though, same as arch
2020-12-09 23:25:23 <mps> yes, I use syslinux whenever possible
2020-12-09 23:25:26 <maxice8> I just boot directly with unified efistub
2020-12-09 23:25:39 <maxice8> have gummiboot on the side if I manage to screw up
2020-12-09 23:25:52 <dalias> i have no efi :)
2020-12-09 23:26:02 <mps> grub is added before two releases iirc
2020-12-09 23:26:13 <mps> uh
2020-12-09 23:26:22 <mps> two releases ago*
2020-12-09 23:27:08 <mps> before that it had to be installed 'by hand'
2020-12-09 23:27:24 <omni> I just wanted to raise that syslinux might need attention, since it's the default in alpine, although this is probably not the forum to move forward with that (there is a #syslinux)
2020-12-09 23:28:49 <mps> omni: I looked about year ago there and didn't found anything important which we need to add
2020-12-09 23:29:46 <mps> nowadays I mostly use u-boot :)
2020-12-09 23:56:20 <omni> mps: you probably looked further than I did
2020-12-10 02:09:45 <Ariadne> dalias: ok I'll push out another snapshot
2020-12-10 02:26:19 <Ariadne> [16:22:23] <maxice8> Hello71 systemd-bootd here we come
2020-12-10 02:26:23 <Ariadne> don't use that language in here
2020-12-10 02:26:39 <maxice8> ?
2020-12-10 02:26:44 <Ariadne> you said systemd
2020-12-10 02:26:46 <Ariadne> bad
2020-12-10 02:26:58 <Ariadne> verboten
2020-12-10 02:27:08 <Hello71> hmm... i wonder if libvirt will be merged into systemd
2020-12-10 02:27:22 <Hello71> systemd-systemd
2020-12-10 02:27:31 <Ariadne> when will openrc be merged into systemd
2020-12-10 02:29:42 <Hello71> i mean libvirt into systemd is plausible if you buy into the theory that red hat loves systemd
2020-12-10 02:29:59 <Hello71> then someone will make "elibvirt"
2020-12-10 02:35:32 <Ariadne> redhat loves centos :D :D :D :D :D :D :D :D :D
2020-12-10 02:50:31 <Hello71> red has has always hated centos
2020-12-10 02:53:38 <Ariadne> no
2020-12-10 02:53:40 <Ariadne> they love it
2020-12-10 02:53:44 <Ariadne> they smothered it with love
2020-12-10 02:53:46 <Ariadne> until it died
2020-12-10 02:53:47 <Ariadne> :D
2020-12-10 02:55:48 <Hello71> ok.
2020-12-10 05:54:09 <ikke> bratkartoffel: fyi: the force check in the unpack() function breaks abuild -rf. With verify not being run when specifying -f, it cannot find the tarballs
2020-12-10 05:55:29 <ikke> bratkartoffel: I'm building your patch a couple of times in my dev container to see if I still get deadlocks
2020-12-10 06:21:01 <bratkartoffel> ikke: thanks for testing my patch. for the force-check in upack() i have no idea why it has been there in the first place or even what it should do. should i just remove it?
2020-12-10 06:24:23 <ikke> I guess, I have no idea either
2020-12-10 06:25:57 <ikke> It was there from the beginning apparently
2020-12-10 06:26:08 <ikke> 6 years ago :)
2020-12-10 06:26:55 <ikke> It's not that important for now, but it supprised me :)
2020-12-10 06:27:05 <ikke> wondering why unpack failed for me
2020-12-10 08:36:10 <ncopa> morning! im testing bratkartoffel's MR in my aarch64 dev container
2020-12-10 08:36:17 <ncopa> the patch looks good to me
2020-12-10 08:36:23 <ikke> ncopa: I have been testing it as well
2020-12-10 08:36:37 <ikke> built it a couple of times
2020-12-10 08:36:55 <ncopa> there is a comment in recent openjdk source: http://hg.openjdk.java.net/jdk/jdk/file/tip/src/java.base/unix/native/libjava/ProcessImpl_md.c#l53
2020-12-10 08:37:37 <ncopa> which sums it up pretty well. I think we might want backport the posix_spawn implementation if other versions of openjdk gets problems
2020-12-10 08:38:00 <ncopa> openjdk7 should only be used for bootstrapping openjdk8 (in theory)
2020-12-10 08:41:17 <ncopa> tdtrask: https://wiki.alpinelinux.org/wiki/Setting_up_the_build_environment_on_HDD should still be valid
2020-12-10 08:42:54 <ncopa> re bootloaders, i like syslinux, but it only runs on x86*, gummiboot was great for EFI, but got sucked into s*d and is non-trivial to build standalone, so it is out of the question.
2020-12-10 08:43:26 <ncopa> grub2 is really really messy and complicated and bloaty, but I think it is the most portable alternative
2020-12-10 08:44:11 <ncopa> for UEFI i currently bypass the bootloader completely, by installing the linux kernel as "bootloader" using efibootmgr
2020-12-10 08:44:57 <ikke> ncopa: fakeroot-dbg did not give any more information in the bactrace for rust
2020-12-10 08:45:23 <ikke> I wonder if we could somehow prevent cargo/rust from compiling things in fakeroot
2020-12-10 08:45:49 <mps> ncopa: could efibootmgr have 'menu' to select kernels to boot
2020-12-10 08:46:23 <mps> or just one kernel
2020-12-10 08:50:08 <ncopa> i thikn that depends on the "hardware"
2020-12-10 08:50:24 <ncopa> i have a dualboot windows and alpine
2020-12-10 08:51:16 <ncopa> when pressing f12 i get a boot menu, and with efibootmgr i added alpine to it as default option
2020-12-10 08:52:09 <ncopa> on my old macbook though, i still havent replaced gummiboot
2020-12-10 08:56:52 <ncopa> openjdk7 built for me, im testing to build openjdk8 now. if that passes I'll suggest that we push bratkatoffel's MR
2020-12-10 09:00:50 <bratkartoffel> should i backport this patch to 3.12 - 3.10?
2020-12-10 09:03:02 <mps> I think I detected bug in gc, ( Program received signal SIGSEGV, Segmentation fault, 0x00007ffff3e09ff7 in GC_find_limit_with_bound () from /usr/lib/libgc.so.1) but don't know how to fix it
2020-12-10 09:14:36 <insep_> u-boot is da best /s
2020-12-10 09:16:05 <ikke> maxice8: thanks for working on these CVE fxies
2020-12-10 09:16:08 <ikke> fixes*
2020-12-10 09:16:13 <maxice8> Welcome
2020-12-10 09:53:31 <ncopa> bratkartoffel: i think no, unless we get the build problem there
2020-12-10 09:53:50 <Newbyte> was the JDK issue on aarch64 fixed?
2020-12-10 09:53:53 <ikke> ncopa: fyi, openjdk7 built 3 times without issues for me
2020-12-10 09:53:59 <ikke> Newbyte: it's about to be
2020-12-10 09:54:08 <Newbyte> nice!
2020-12-10 09:54:08 <ncopa> and openjdk8 built with the fixed openjdk7
2020-12-10 09:54:17 <ncopa> so i say: push it!
2020-12-10 09:54:49 <ncopa> dalias and bratkartoffel: thank you for help fixing the painful openjdk7 issue
2020-12-10 09:55:01 <ikke> bratkartoffel: can you remove WIP from the MR?
2020-12-10 09:56:33 <ncopa> i did it
2020-12-10 09:56:38 <ikke> :)
2020-12-10 09:58:48 <maxice8> mv all sourceforge projects to testing/
2020-12-10 09:59:55 <ncopa> why?
2020-12-10 10:00:59 <maxice8> Just frustrated with having to use sourceforge to find upstream fixes for CVEs
2020-12-10 10:01:11 <ncopa> :)
2020-12-10 10:01:45 <ncopa> btw seems like openldap fails due to checksum mismatch on the fetched patch
2020-12-10 10:01:57 <maxice8> fetched ?
2020-12-10 10:02:04 <maxice8> I swear I made them all local
2020-12-10 10:02:22 <ncopa> https://build.alpinelinux.org/buildlogs/build-3-11-x86_64/main/openldap/openldap-2.4.48-r3.log
2020-12-10 10:02:35 <ncopa> CVE-2020-12243.patch::https://git.openldap.org/openldap/openldap/-/commit/98464c11df8247d6a11b52e294ba5dd4f0380440.patch
2020-12-10 10:03:04 <maxice8> oh derp, I mistook pcre (recently made MRs) and openldap (recently merged them)
2020-12-10 10:03:24 <maxice8> I'll take a look when I finish reviewing imhex
2020-12-10 10:03:33 <ncopa> thank you!
2020-12-10 10:04:08 <mps> ah, you will add imhex, nice
2020-12-10 10:06:19 <maxice8> I won't
2020-12-10 10:06:20 <maxice8> just reviewing
2020-12-10 10:09:50 <mps> it looks good, but I don't have time to package it
2020-12-10 10:15:58 <ncopa> the llvm10 testsuite fails on x86. seems to be a segfault in llvm-objdump
2020-12-10 10:50:22 <maxice8> is reallocarray meant to be in stdlib.h ?
2020-12-10 10:52:52 <ncopa> yes https://man7.org/linux/man-pages/man3/reallocarray.3.html
2020-12-10 10:55:37 <ikke> maxice8: regarding elogind?
2020-12-10 10:55:47 <maxice8> Yes and NetworkManager
2020-12-10 10:55:53 <ikke> aha, ok
2020-12-10 10:56:06 <ikke> elogind accepted my PR
2020-12-10 10:56:08 <maxice8> I just need a short and concise reason to tell the NetworkManager devs
2020-12-10 10:56:58 <ikke> I think that man page should suffice
2020-12-10 10:57:05 <maxice8> yes, thanks ncopa and ikke
2020-12-10 10:58:19 <ncopa> llvm-objdump segfault on x86 seems tricky
2020-12-10 10:58:25 <ncopa> no clue what is going on there
2020-12-10 10:59:36 <mps> maxice8: yes, manpage is clear about this
2020-12-10 11:08:45 <maxice8> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/703
2020-12-10 11:10:36 <ikke> already feedback
2020-12-10 11:12:12 <maxice8> I found my match
2020-12-10 11:12:16 <maxice8> the fastest review in the wild west
2020-12-10 11:12:20 <ikke> heh :)
2020-12-10 11:12:46 <ikke> 2 minutes is the time to beat :P
2020-12-10 11:12:56 <ikke> Not sure if you want to beat that though
2020-12-10 11:13:40 <ncopa> thank you for upstreaming it
2020-12-10 11:14:15 <ncopa> upstreaming patches can be timeconsuming, even for simple patches
2020-12-10 11:14:47 <Cogitri> Yup, but keeping them downstream tends to be even more time consuming in the long run
2020-12-10 11:14:49 <maxice8> No worries
2020-12-10 11:14:53 <ikke> But it's important to have more eyes on those patches
2020-12-10 11:14:57 <maxice8> it provided my the opportunity to add gilab.freedesktop.org support on agl
2020-12-10 11:15:01 <maxice8> my/me
2020-12-10 11:15:38 <maxice8> @Ikke I'm not a speedrunner
2020-12-10 11:15:39 <maxice8> review Merge Request any% no-ci
2020-12-10 11:16:26 <maxice8> I am happy to upstream anything that is github/gitlab
2020-12-10 11:16:34 <ikke> maxice8: no, better not for these things :)
2020-12-10 11:28:59 <ncopa> ugh... dbugging llvm on x86 will not be easy
2020-12-10 11:29:09 <ikke> ugh
2020-12-10 11:29:12 <ncopa>  /usr/lib/gcc/i586-alpine-linux-musl/10.2.1/../../../../i586-alpine-linux-musl/bin/ld: out of memory allocating 1000 bytes after a total of 176128 bytes
2020-12-10 11:29:14 <ikke> nss is missing on x86
2020-12-10 11:29:18 <ncopa> why?
2020-12-10 11:29:20 <ikke> openjdk7 needs nss
2020-12-10 11:29:29 <ncopa> why is nss missing on x86?
2020-12-10 11:29:52 <ikke> seems to be not built yet after move
2020-12-10 11:30:19 <ikke> it's neither in main nor in community
2020-12-10 11:31:09 <ikke> notcurses is blocking x86
2020-12-10 11:31:26 <ikke> test failure
2020-12-10 11:31:39 <ncopa> oh
2020-12-10 11:31:54 <ncopa> main was completed and updated and pushed
2020-12-10 11:31:58 <ncopa> i up uploaded
2020-12-10 11:32:02 <ncopa> so nss got removed
2020-12-10 11:32:17 <ncopa> so the x86 CI fails due to missing nss
2020-12-10 11:32:29 <ikke> yes
2020-12-10 11:32:32 <ncopa> thats not a problem. when we push it should build nss before openjdk
2020-12-10 11:32:34 <ikke> indeed
2020-12-10 11:33:40 <ikke> Should I just push it? Because CI is taking long and chance is another package is already pushed before that
2020-12-10 11:33:47 <ncopa> i think so yes
2020-12-10 11:33:52 <ncopa> just push it
2020-12-10 11:34:10 <ikke> done
2020-12-10 11:34:25 <mps> notcurses passed on CI x86 but fail on builder
2020-12-10 11:35:18 <mps> not sure to disable check on x86 or disable build on x86
2020-12-10 11:35:28 <ncopa> im looking at notcurses now
2020-12-10 11:35:55 <mps> upstream was here some time ago but I forgot nick
2020-12-10 11:37:02 <ncopa> looks like its only testing/growlight that uses it. I suppose we can disable both on x86 for now
2020-12-10 11:38:56 <mps> ok, I will try to inform upstream later
2020-12-10 11:42:40 <ikke> yay, redirect loop for sourceforge :-.
2020-12-10 11:42:42 <ikke> :-/
2020-12-10 11:58:56 <ikke> ncopa: I've set the distfiles mirror for aarch64 edge, it was not set there yet
2020-12-10 12:04:00 <ncopa> ok
2020-12-10 12:04:02 <ncopa> thanks
2020-12-10 12:06:33 <ikke> aarch64 is a bit behind
2020-12-10 12:06:51 <ikke> 30 packages before openjdk7
2020-12-10 12:30:29 <maxice8> snownews is a magical package
2020-12-10 12:37:35 <ikke> it's ah rss reader I see
2020-12-10 12:39:01 <maxice8> even with limits.h it fails on PATH_MAX
2020-12-10 12:42:06 <ikke> Is it missing _POSIX_SOURCE?
2020-12-10 12:42:10 <ikke> or something like that
2020-12-10 12:42:43 <ikke> PATH_MAX is behind _*_SOURCE guards
2020-12-10 13:01:48 <ncopa> might be missing _GNU_SOURCE
2020-12-10 13:17:05 <maxice8> can't wait for 3.14 release
2020-12-10 13:17:28 <ikke> pi-edition
2020-12-10 13:19:04 <maxice8> so I can upgrade lua to 5.4 and python3 to 3.9 :D
2020-12-10 14:57:01 <tdtrask> ncopa: thanks for the confirmation
2020-12-10 14:57:17 <tdtrask> I set up the build environment by creating chroot on my Mint box and then following that doc
2020-12-10 14:58:02 <tdtrask> !15572 is my first MR (since I no longer have push permissions for aports)
2020-12-10 14:58:24 <tdtrask> Anyone able to check it to see if I've done everything properly?
2020-12-10 14:59:52 <ikke> tdtrask: looks alright
2020-12-10 15:00:58 <walbon> clandmeter, ncopa : do you know why the builder of ppc64le for 3.13 is missing here https://build.alpinelinux.org/?
2020-12-10 15:01:13 <tdtrask> ikke: thanks
2020-12-10 15:04:32 <ikke> walbon: mqtt-exec is not running
2020-12-10 15:05:13 <ikke> walbon: fixed
2020-12-10 15:05:17 <ikke> thanks for mentioning
2020-12-10 15:05:53 <walbon> ikke, I thank you for fixing
2020-12-10 15:07:08 <walbon> ikke, will it have new builds for ppc here https://build.alpinelinux.org/buildlogs/build-3-13-ppc64le/? I see main only
2020-12-10 15:08:00 <ikke> walbon: it should, not sure if it finished main already
2020-12-10 15:09:25 <walbon> ikke, sorry for so many questions, I am looking for where I can help.
2020-12-10 15:09:49 <ikke> no worry
2020-12-10 15:10:10 <ikke> there are 28 packages in main that need to be built still
2020-12-10 15:10:11 <walbon> ikke, that error with hexdump conflicts was fixed? I guess maxice8 was seeing it.
2020-12-10 15:10:29 <ikke> I guess so
2020-12-10 15:10:54 <ikke> yes
2020-12-10 15:11:04 <ikke> 8c8c829b85431bb36154eecd556b2d5298419339
2020-12-10 15:12:00 <walbon> great
2020-12-10 15:12:40 <walbon> ikke, 28 package errors ? let me know which to build and look for a patching
2020-12-10 15:12:45 <ikke> no
2020-12-10 15:12:50 <ikke> just 28 packages to be build
2020-12-10 15:12:56 <walbon> ow, ok, I got it
2020-12-10 15:13:01 <ikke> walbon: you can join #alpine-commits
2020-12-10 15:13:07 <ikke> if there are failures, they are announced there
2020-12-10 15:13:12 <ikke> ah, you are already there
2020-12-10 15:14:45 <walbon> ow, ok, I am there, but I started to look for in the irclog
2020-12-10 15:15:38 <ikke> the logs published by algitbot doesn't contain it's own messages
2020-12-10 15:16:37 <tdtrask> I need help with my first MR. The gitlab rebase button failed, and now I cannot rebase locally and push because of "hint: Updates were rejected because a pushed branch tip is behind its remote"
2020-12-10 15:17:15 <tdtrask> how do I rebase if I can't overwrite the remote branch on my own gitlab repo?
2020-12-10 15:17:49 <minimal> Hi folks. Regarding the syslinux discussion earlier and the need to disable 64bit feature for boot filesystem, is there any impact regarding Year2038? I'm sure I recently noticed "ext4 filesystem being mounted at (mountpoint) supports timestamps until 2038" in dmesg output on a machine recently
2020-12-10 15:18:52 <minimal> It seems upstream syslinux has patched to handle the 64bit feature 3 years ago: https://repo.or.cz/syslinux.git/commit/af7e95c32cea40c1e443ae301e64b27f068b4915. Maybe this should be added as a patch to the Alpine package?
2020-12-10 15:19:12 <tdtrask> Failure to rebase in web UI is known problem, apparently: https://gitlab.com/gitlab-org/gitlab/-/issues/213608
2020-12-10 15:20:08 <mps> tdtrask: git push --force youraccount, iiuc your question
2020-12-10 15:20:52 <ikke> tdtrask: the first branch (master) in a repo is protected by default
2020-12-10 15:21:03 <mps> minimal: thanks, will look later when finish day job
2020-12-10 15:21:04 <ikke> tdtrask: generally you are advised to create separate branches for merge requests
2020-12-10 15:21:22 <ikke> tdtrask: you can go to the repository settings of your fork and unprotect the master branch
2020-12-10 15:21:38 <ikke> tdtrask: https://gitlab.alpinelinux.org/ttrask01/aports/-/settings/repository
2020-12-10 15:21:51 <tdtrask> ikke: that explains it
2020-12-10 15:22:20 <minimal> mps: not completely sure if the ext 64bit feature is linked to ext4's post-2038 support but either way that dmesg output didn't exactly fill me with joy ;-)
2020-12-10 15:23:48 <mps> everyone will switch to other fs till 2038 :)
2020-12-10 15:24:30 <tdtrask> thanks mps and ikke, force push worked once I removed the protection from master branch
2020-12-10 15:30:53 <tdtrask> Noticed mirroring settings for my gitlab repo. Can my ttrask01/aports repo be set up to mirror the alpine/aports repo? Seems no because I can only select Push direction.
2020-12-10 15:32:10 <ikke> tdtrask: yes, correct
2020-12-10 15:32:43 <ikke> tdtrask: I don't even care to update master on my fork
2020-12-10 15:32:57 <ikke> I just fetch master from upstream, and create my branches on top of there
2020-12-10 15:33:52 <tdtrask> ikke: makes sense to use separate branch, but I would like to avoid manual rebase when possible.
2020-12-10 15:34:23 <ikke> if you use that workflow, you don't need to rebase
2020-12-10 15:34:39 <ikke> the contributors who merge usually take care of that
2020-12-10 15:34:54 <ikke> but your master branch on your fork certainly does not have to be up-to-date for that
2020-12-10 15:34:56 <ikke> just your local repo
2020-12-10 15:35:29 <tdtrask> related question - am I allowed by policy to merge my own MR?
2020-12-10 15:36:01 <minimal> mps: have doubled checked this - on a VM with boot EXT4 fs without 64bit feature and root EXT4 fs with 64bit feature the kernel dmesg shows the 2038 warning for only the boot fs, i.e. the one with 64bit feature disabled. Think we should get the 64bit patch into syslinux asap...
2020-12-10 15:36:56 <ikke> tdtrask: hmm, I think you _should_ have merge acces
2020-12-10 15:36:58 <tdtrask> seems unworkable to do manual rebase, push, wait for CI, and then someone else pushes a commit before I can merge :/
2020-12-10 15:37:17 <ikke> tdtrask: maxice8 created a command line tool which automates that
2020-12-10 15:37:36 <tdtrask> ikke: I seem to have access, but gitlab keeps telling me to rebase!
2020-12-10 15:38:11 <tdtrask> and rebase through the UI fails
2020-12-10 15:38:18 <ikke> tdtrask: 2 options: merge into master locally and push that, or use the cli tool that maxice8 made
2020-12-10 15:38:28 <ikke> tdtrask: most of the time it should work
2020-12-10 15:38:43 <ikke> tdtrask: I rebase constantly through the webif
2020-12-10 15:38:43 <tdtrask> ikke: I don't have push access to alpine/aports since the move to gitlab
2020-12-10 15:39:05 <ikke> ttrask01 is developer in alpine/aports
2020-12-10 15:39:21 <ikke> or at least, should be
2020-12-10 15:39:24 <tdtrask> I tried pushing, but no luck
2020-12-10 15:39:46 <ikke> ok
2020-12-10 15:40:45 <mps> minimal: good. will you make MR or ... ?
2020-12-10 15:41:28 <tdtrask> remote: Hello ttrask01
2020-12-10 15:41:28 <tdtrask> remote: You are not allowed to push to the main repository
2020-12-10 15:41:36 <ikke> aha
2020-12-10 15:41:47 <minimal> mps: sure, I'll start on it first thing............after a coffee ;-)
2020-12-10 15:41:47 <ikke> that's a different policy
2020-12-10 15:43:18 <tdtrask> ikke: ?
2020-12-10 15:43:37 <mps> minimal: thanks. you can assign it to me. and enjoy coffee :)
2020-12-10 15:43:53 <ikke> tdtrask: through gitlab roles we normally specify who can push / merge
2020-12-10 15:44:00 <ikke> but for packages to main, we have a separate mechanism
2020-12-10 15:44:17 <tdtrask> ah, it a main vs community issue
2020-12-10 15:44:21 <ikke> yea
2020-12-10 15:44:58 <tdtrask> the vast majority of my ACF and Lua packages are in main
2020-12-10 15:45:08 <ikke> right
2020-12-10 15:47:05 <minimal> mps: interesting issue for existing installs - you can't run "tune2fs -O 64bit /dev/whatever" to enable the 64bit feature on a mounted filesystem, so once we get a patched syslinux out the door everyone with existing installs with need to use something like a USB stick boot to manually fix existing filesystems
2020-12-10 15:48:36 <minimal> I guess we have 17 years to work out an action plan for that...
2020-12-10 15:50:27 <ncopa> i think it might be good if someone of the experienced devs could review the MRs for tdtrask before they are merged
2020-12-10 16:00:21 <timlegge> #63458 finally passes all archs if someoen has time
2020-12-10 16:00:48 <timlegge> oops !15496
2020-12-10 16:06:49 <minimal> ncopa: FYI I'm currently working on a syslinux patch to address a Year2038 issue with ext4 boot/root filesystems. MR to follow hopefully later today
2020-12-10 16:10:12 <mps> minimal: I wonder how many bottles I have to buy for these 17 years, that scares me :)
2020-12-10 16:11:52 <minimal> mps: I worked overnight during Y2K. Luckily it was a "non event" due to all the preparation beforehand. I'm sure Y2038 will be deja vu - if my memory is still working by then ;-)
2020-12-10 16:13:00 <mps> also I had increase in jobs (and money) during Y2K
2020-12-10 16:15:07 <tdtrask> ncopa: ikke already said it looked good, but I definitely agree.
2020-12-10 16:16:01 <tdtrask> ncopa: all I did was bump the pkgrel, so it's not exactly rocket science. :D
2020-12-10 16:29:58 <ncopa> i tagged 3.12.2
2020-12-10 16:30:40 <mps> seen it before you announce it here :) (though just few seconds)
2020-12-10 16:41:00 <minimal> mps: false alarm, the syslinux 64bit issue is unrelated to Y2038. I'm still working on syslinux MR for 64bit anyway as its good to have. For Y2038 it looks like its related to the inode size on the created fs, will have to dig further
2020-12-10 17:03:52 <minimal> mps: tracked down the Y2038 issue to ext4 filesystems with inode=128, when creating fs smaller than 512M mkfs.ext4 uses the "small" entry from /etc/mke2fs.conf which specifies 128 byte inodes.
2020-12-10 17:04:30 <minimal> that's a general issue regardless of bootloader used
2020-12-10 18:09:06 <mps> minimal: ok
2020-12-10 18:10:30 <mps> thanks for explanation and investigation. so I was right yesterday, nothing to worry about syslinux
2020-12-10 18:12:30 <minimal> mps: as I said, still good to be able to use ext4 with 64bit (default) feature with syslinux so I'm working on that patch currently (obviously need to test it actually works on a few machines before submitting)
2020-12-10 18:13:58 <minimal> mps: seperately there is still the issue that many Alpine installs will have ext4 filesystems created smaller than 513M which means they can't handle timestamps after 2038. So will also raise MR for that but even with MR merged that won't address the issue for any already created filesystems.
2020-12-10 18:14:10 <mps> sure, I'm not against it, and I think it is good to apply it
2020-12-10 18:15:15 <mps> and ofc it should be tested in few scenarios
2020-12-10 18:15:58 <mps> and with gpt and msdos partitions
2020-12-10 18:16:46 <minimal> downside of using 256byte inodes instead of 128byte inodes for <=512M ext4 filesystems is there will be some reduction in usable space due to the increased inode overhead
2020-12-10 18:17:23 <mps> right
2020-12-10 18:17:55 <minimal> for testing, yupe I routinely build VMs and physical machines with MBR and GPT and Syslinux and Grub-bios and Grub-efi so its just a matter of testing those combinations
2020-12-10 18:18:57 <mps> that is nice to hear, I'm not so much rigorous at testing
2020-12-10 18:20:19 <minimal> mps: not building those for testing, rather for actual use. Its handy having an Ansible playbook to spit out all these different types of disk images. Just need to finish off the LVM, LUKS, and LVM-on-LUKS portions to have a full set :-_
2020-12-10 18:20:34 <mps> looking back (in memory) I think alpine setup for long make 512M boot partition
2020-12-10 18:23:10 <minimal> For the Y2038 issue I don't see it as realistically much of an issue for physical machines (especially for Alpine in USB stick boot scenario) however for VMs there's alway a chance that VM images end up still being around by 2038 - even when they've been regularly upgraded the underlying filesystem could have been created with this limitation
2020-12-10 18:24:18 <mps> yes, also I have this in mind and because that patch make sense
2020-12-10 20:12:04 <omni> it'd be nice if syslinux could boot from zfs
2020-12-10 20:23:05 <minimal> omni: don't think there's much active development on syslinux these days
2020-12-10 21:42:41 <omni> I'd say https://bugzilla.syslinux.org/buglist.cgi?component=syslinux&product=Syslinux&resolution=---
2020-12-10 21:49:33 <minimal> omni: plus ZFS is always an issue for Linux in general due to its licensing/"Its Oracle, run!" situation. I think Ubuntu is the only Linux dist to ship with it out-of-the-box
2020-12-10 22:40:29 <omni> ftr, I happily use zfs on my alpine laptop
2020-12-11 02:19:08 <maxice8> algitbot: retry master
2020-12-11 04:23:34 <maxice8> oh sweet py3-chardet>=4.x is fully compatible
2020-12-11 05:52:15 <ikke> ncopa: gpg signatures for 3.12.2 are missing
2020-12-11 06:56:12 <ncopa> morning
2020-12-11 06:56:33 <ncopa> and releases update and publish release notes. im on it
2020-12-11 07:08:31 <bratkartoffel> just saw that openjdk7 finally passed on aarch64, thanks to all who helped
2020-12-11 07:09:02 <bratkartoffel> i've also included the vfork patch in the next openjdk8 upgrade: !15326
2020-12-11 07:11:46 <ncopa> 👍
2020-12-11 07:15:04 <maxice8> nice
2020-12-11 07:15:35 <ncopa> very nice looks like the edge builders are all idle (except mips64)
2020-12-11 07:18:57 <maxice8> ugh
2020-12-11 07:19:00 <maxice8> py3-sip upstream removed links
2020-12-11 08:20:28 <ollieparanoid[m]> congratulations on the release!
2020-12-11 08:20:41 <ollieparanoid[m]> I'm wondering: does apk always add packages from install_if rules before running post-install scripts?
2020-12-11 08:36:38 <Ariadne> ncopa: i had a thought on how to fix the /etc/init.d/networking issue
2020-12-11 08:36:56 <Ariadne> ncopa: we could split that initscript out into its own package, and have it conflict with the ifupdown-ng one
2020-12-11 09:06:27 <Ariadne> ncopa: what are your thoughts on that approach ?
2020-12-11 09:07:11 <ncopa> could work. why don't we have a single init script that works for both, with conditionals? is the difference that big?
2020-12-11 09:07:37 <MY-R> damn, I could mention about !14200 before 3.12.2 is out :\
2020-12-11 09:09:29 <Ariadne> ncopa: it is not.  the main difference is that it uses ifquery to determine a solution for what interfaces should be brought up, and in what order
2020-12-11 09:21:36 <ncopa> I added a test for ifquery some time ago: 8c8f379f1069d874bb6481ded7bb671ced7b0128
2020-12-11 09:31:19 <ncopa> maxice8 had a tool to scan reverse deps recursively, i dont remember where to find it
2020-12-11 09:31:54 <maxice8> adep ?
2020-12-11 09:31:57 <ncopa> aports-helpers
2020-12-11 09:32:01 <ncopa> yeah, adep
2020-12-11 09:32:46 <maxice8> https://github.com/maxice8/aports-helpers
2020-12-11 09:33:18 <ncopa> thanks
2020-12-11 09:33:50 <ncopa> adep list
2020-12-11 09:34:46 <ncopa> how do yo uprocess the output of the list?
2020-12-11 09:35:34 <maxice8> yq
2020-12-11 09:35:40 <ncopa> lets say, `adep list polkit-dev` gives me a yaml list of packages, and i want to check which of those has mips64 enabled
2020-12-11 09:36:13 <maxice8> http://ix.io/2HwQ
2020-12-11 09:39:25 <ncopa> thanks
2020-12-11 10:15:51 <Ariadne> ncopa: ok, then i propose we just drop the ifupdown-ng-openrc for now
2020-12-11 11:02:38 <ncopa> sounds good
2020-12-11 11:08:15 <ncopa> maxice8: what do you think about adding an --arch=ARCH option to adep list? https://tpaste.us/QW0w
2020-12-11 11:08:45 <ikke> would be nice (but extensive I guess) to have some kind of query language
2020-12-11 11:09:09 <ncopa> ncopa-desktop:~/aports$ ~/src/aports-helpers/adep.lua list --arch=mips64 rust | tpaste
2020-12-11 11:09:09 <ncopa> https://tpaste.us/K54B
2020-12-11 11:09:12 <maxice8> I'll look into it
2020-12-11 11:09:29 <ikke> select pkgname from aports where repo='main' and 'ppc64le' in arch
2020-12-11 11:09:34 <ikke> :P
2020-12-11 11:09:56 <ncopa> adep list does reverse dep list
2020-12-11 11:09:56 <Ariadne> i am hoping to be able to enable ppc64 (big-endian) arch soon.
2020-12-11 11:10:02 <Ariadne> without overhead of KVM.
2020-12-11 11:10:22 <Ariadne> though i think to make this container solution robust, some kernel coding will be needed
2020-12-11 11:10:31 <Ariadne> what i have now is... hacks on hacks
2020-12-11 11:21:47 <ncopa> hum, the adep filter does not do what i hoped for
2020-12-11 11:57:35 <ncopa> interesting, main/gtk+3 shows up as a recursive reverse dep of rust
2020-12-11 11:58:04 <ncopa> i think the reason is the librsvg checkdepends
2020-12-11 11:58:04 <Cogitri> Huh
2020-12-11 11:58:41 <Cogitri> Hm, but Rust doesn't depend on librsvg or gtk
2020-12-11 11:59:13 <ncopa> reverse recursive
2020-12-11 11:59:27 <ncopa> librsvg depends on rust
2020-12-11 11:59:47 <ncopa> and gtk3 depends on librsvg
2020-12-11 12:00:36 <ncopa> i mean: i think the reason is gtk3 checkdepends
2020-12-11 12:01:13 <Ariadne> well, hopefully we can tackle rust bootstrap
2020-12-11 12:01:27 <Ariadne> once that is solved once and for all(tm), it becomes non-issue
2020-12-11 12:01:42 <Ariadne> i just have not succeeded in getting it past stage0
2020-12-11 12:02:11 <Ariadne> though perhaps trying again with new rust is worthwhile
2020-12-11 12:02:28 <ncopa> still want some tooling that can help us show the consecuence of disabling a package for an arch
2020-12-11 12:02:57 <ncopa> i disable libfoo for arch A. what other packages needs to be disabled?
2020-12-11 12:03:01 <Ariadne> yeah
2020-12-11 12:03:03 <Ariadne> makes sense :)
2020-12-11 12:03:21 <Ariadne> also somebody pinged @developers on their MR and now gitlab is annoying me with emails about it
2020-12-11 12:03:32 <Ariadne> perhaps we should not have the bot encourage that activity
2020-12-11 12:04:06 <ikke> You can disable notifications for single MRs / issues, but I agree
2020-12-11 12:04:47 <Ariadne> there should be a separate group for people who deal with new contributors
2020-12-11 12:05:03 <Ariadne> have the bot suggest pinging that group instead
2020-12-11 12:06:07 <Cogitri> Sounds good, yes
2020-12-11 12:50:39 <ncopa> the reverse deplist of rust is insane
2020-12-11 12:50:56 <ncopa> apparently its not possible to build xfce4-terminal without rust
2020-12-11 12:51:53 <Cogitri> Yes, due to librsvg it's in loads of stuff
2020-12-11 12:52:26 <ncopa> it seems like it was due to mozjs78
2020-12-11 12:52:41 <ncopa> ncopa-edge-x86_64:~/aports/community$ ap recursdeps xfce4-terminal | grep moz
2020-12-11 12:52:41 <ncopa> mozjs78-dev
2020-12-11 12:52:41 <ncopa> mozjs78
2020-12-11 12:52:50 <ncopa> it is in the dependency chain somehow
2020-12-11 12:56:22 <ncopa> ah
2020-12-11 12:57:58 <ncopa> libxfce4ui -> glade -> webkit2gtk -> ....
2020-12-11 13:00:17 <mps> does abuild recognize html docs subdir for pkg
2020-12-11 13:00:28 <ncopa> ... -> geoclue -> modemmanager -> polkit -> mozjs78
2020-12-11 13:00:59 <ncopa> so, its currently not possible to build the xfce4 terminal without mozjs78
2020-12-11 13:01:02 <ncopa> kinda insane
2020-12-11 13:01:02 <ikke> mps: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1771
2020-12-11 13:01:10 <ikke> ncopa: yup
2020-12-11 13:01:25 <ikke> like Ariadne said, it's already deeply nestled
2020-12-11 13:01:59 <mps> ikke: thanks, I see now
2020-12-11 13:02:10 <ncopa> $ ~/src/aports-helpers/adep.lua list rust | tpaste
2020-12-11 13:02:10 <ncopa> https://tpaste.us/jnOV
2020-12-11 13:02:10 <Ariadne> we will use rust whether we want to or not
2020-12-11 13:02:13 <Ariadne> (:
2020-12-11 13:02:50 <ncopa> that is the list of packages we need to disable for arches without rust: https://tpaste.us/jnOV
2020-12-11 13:03:10 <ncopa> its like every single package...
2020-12-11 13:03:11 <ikke> Ginormous
2020-12-11 13:04:42 <ncopa> im just disappointed that i sacrificed the day to build the tooling to trace this
2020-12-11 13:04:55 <ncopa> i dont know how to proceed anymore
2020-12-11 13:05:45 <ncopa> i think there is a checkdepends main -> community too
2020-12-11 13:06:36 <Cogitri> Ah yes, but I think gtk has its checks disabled anyway?
2020-12-11 13:06:40 <ncopa> ah
2020-12-11 13:06:42 <ncopa> indeed
2020-12-11 13:06:59 <ncopa> lua-aports does not check if checks are disabled or not
2020-12-11 13:07:10 <ncopa> it just blindly add the checkdepends
2020-12-11 13:12:44 <ncopa> so, any suggestions how we get the edge builders pass building?
2020-12-11 13:12:57 <ikke> ncopa: referring to mips, right"?
2020-12-11 13:13:04 <ncopa> yeah
2020-12-11 13:13:49 <mps> hmm 68dc17b56bdf0a3ede58830d2e8d23a7cbc747f6
2020-12-11 13:14:03 <ncopa> also, there is conditional dep for geoclue that disables s390x due to modemmanager
2020-12-11 13:14:47 <mps> it have comment '# Do not install HTML docs.' but I see in some latest qemu html doc installed?
2020-12-11 13:16:04 <mps> looks like I fixed this unintentionally in qemu !15554
2020-12-11 13:18:15 <ncopa> how do we have geoclue on mips64? http://dl-master.alpinelinux.org/alpine/edge/community/mips64/geoclue-2.5.6-r1.apk
2020-12-11 13:19:40 <ncopa> it depends on modemmanager which depends on polkit which depends on mozjs78 which depends on rust
2020-12-11 13:20:31 <ncopa> hum
2020-12-11 13:20:43 <ncopa> apparently it was built against so:libmm-glib.so.0
2020-12-11 13:20:58 <ncopa> which no longer exists in the mips64 repo
2020-12-11 13:22:14 <ikke> I guess mm was disabled after geoclue was built?
2020-12-11 13:22:30 <ncopa> yes, but how was mm ever built?
2020-12-11 13:23:26 <ikke> from before polkit depending on rust?
2020-12-11 13:23:30 <ikke> just a guess
2020-12-11 13:24:18 <ikke> It was only recently that we needed to disable stuff on s390x due to this
2020-12-11 13:54:51 <ncopa> i think this broke it e348760b7c05e03d80fd20ca7c4708277b661534
2020-12-11 13:55:13 <ncopa> mozjs78 introduced rust dependency
2020-12-11 13:56:02 <ncopa> any ideas how we solve this?
2020-12-11 13:56:09 <ncopa> and prevent things like this to happen in future?
2020-12-11 13:56:31 <ncopa> im tihnking that we could do: apk dot --errors before and after build and run a diff
2020-12-11 13:57:11 <ncopa> if there is a diff in the errors we let the CI fail, as it means the MR introduces dependency graph errors
2020-12-11 13:57:54 <ikke> The problem atm is that we don't have CI for mips64 and armhf
2020-12-11 13:58:08 <ncopa> hum
2020-12-11 13:58:10 <ikke> so they are easily missed
2020-12-11 13:58:49 <ncopa> due to no golang?
2020-12-11 13:58:57 <ikke> for mips, yes
2020-12-11 13:59:03 <ncopa> ok
2020-12-11 13:59:11 <ikke> for armhf, we decided it was not needed (and we don't have sufficient hardware)
2020-12-11 14:00:28 <ncopa> i have meetings now
2020-12-11 14:00:43 <ncopa> im kinda disapointed i spent all day on this. i really didnt have time for it
2020-12-11 14:02:32 <ikke> yeah, I can understand
2020-12-11 14:03:15 <ikke> I was thinking of adding a CI step which at least statically would verify missing dependencies for those archers
2020-12-11 14:07:08 <mps> we are too small to have complex things in distro, imo
2020-12-11 14:13:30 <kpcyrd> I'm running edge and it seems ifupdown-ng-openrc orphaned, which provides /etc/init.d/networking. is this intentional? can I uninstall it without breaking my network config?
2020-12-11 14:14:50 <kpcyrd> I've searched on pkgs.alpinelinux.org and it seems that file is now provided by the openrc package
2020-12-11 14:15:07 <ncopa> try run: apk fix openrc
2020-12-11 14:15:07 <ikke> yes, the ifupdown-ng-openrc subpackage was removed because it was cuasing issues
2020-12-11 14:15:26 <ncopa> kpcyrd: sorry about that
2020-12-11 14:17:54 <kpcyrd> am I doing this right? :) https://paste.debian.net/plainh/72c91016
2020-12-11 14:19:56 <kpcyrd> ah, it seems the new openrc package is still being propagated to the mirrors, I don't seem to have it yet
2020-12-11 14:29:54 <ncopa> anyone can help me disable s390x (and verify that s390x should be disabled) for those packages? https://tpaste.us/DMOl
2020-12-11 14:30:12 <maxice8> I can do it
2020-12-11 14:30:15 <ncopa> its reverse deps for rust
2020-12-11 14:31:09 <ncopa> this is the list for mips64: https://tpaste.us/BEXR
2020-12-11 14:31:15 <ikke> ncopa: I see for example Zabbix in there, but if I do ap recursdeps zabbix, it does not list rust
2020-12-11 14:31:44 <ncopa> where do you see rust?
2020-12-11 14:31:56 <ncopa> sorry, where do you see zabbix?
2020-12-11 14:31:57 <ikke> ah, I was thinking about your previous list
2020-12-11 14:32:20 <ikke> the gigantic one
2020-12-11 14:32:47 <ncopa> i think its incorrect. it did not calculate the dep chain correctly
2020-12-11 14:32:47 <ikke> https://tpaste.us/jnOV
2020-12-11 14:32:51 <ikke> right
2020-12-11 14:33:07 <ncopa> i also added a check for options="!check"
2020-12-11 14:33:18 <ncopa> so it does not pull in checkdepends if checks are disabled
2020-12-11 14:33:34 <ncopa> btw... where should i push lua-aports nowdays? its gitlab right?
2020-12-11 14:33:49 <ncopa> but current origin get-url points to git.a.o
2020-12-11 14:33:52 <ncopa> my*
2020-12-11 14:34:05 <ikke> I think it's still maintained on github (by jirutka)
2020-12-11 14:34:33 <ikke> though, github points to gitlab
2020-12-11 14:34:56 <ncopa> https://gitlab.alpinelinux.org/alpine/lua-aports
2020-12-11 14:55:59 <ncopa> i pushed a few changes to lua-aports
2020-12-11 15:00:04 <ncopa> not sure how much time i should invest in lua-aports. i'd like to reimplement it in golang
2020-12-11 15:00:31 <ikke> ncopa: Was thinking about that as well
2020-12-11 15:01:10 <gwalbon> ikke, helloo.. the mqtt is down in ppc builder?
2020-12-11 15:01:51 <ikke> hmm, yes
2020-12-11 15:02:01 <ncopa> for build-3-13-ppc64le
2020-12-11 15:02:22 <ikke> ncopa: 2nd time it happened
2020-12-11 15:02:34 <gwalbon> well, is there a different config. for that machine?
2020-12-11 15:02:34 <ikke> I see a lot of faked processes
2020-12-11 15:02:55 <ikke> /usr/bin/mqtt-exec, pid 21605, terminated by signal 15
2020-12-11 15:03:18 <ncopa> .makedepends-smokeping
2020-12-11 15:03:33 <ikke> supervise-daemon[389]: respawned "/usr/bin/mqtt-exec" too many times, exiting
2020-12-11 15:03:41 <ncopa> hum
2020-12-11 15:03:46 <ncopa> might be the network is lossy
2020-12-11 15:03:54 <ncopa> i think we should try get a core
2020-12-11 15:04:02 <ncopa> so we can debug why it creashes
2020-12-11 15:04:09 <ikke> signal 15 is sigterm, right?
2020-12-11 15:04:15 <ncopa> i think so
2020-12-11 15:04:21 <kpcyrd> are there any policies regarding analytics and version checks? I've tested the testing/grafana package and it works nicely, but I'm considering writing a patch to disable analytics and version checks from the default config
2020-12-11 15:04:43 <ncopa> im gonna kill cc, uninstall .makedepends* and reboot it
2020-12-11 15:04:51 <ncopa> ok with that ikke?
2020-12-11 15:04:53 <ikke> yes
2020-12-11 15:04:59 <ikke> I did reboot it yesterday as well
2020-12-11 15:05:21 <ncopa> hum
2020-12-11 15:05:30 <ncopa> i think we should find out why it crashes
2020-12-11 15:06:02 <ncopa> kpcyrd: we dont have any policy for it afaik
2020-12-11 15:06:29 <ncopa> we try to stick to upstream if possible, but i suppose we could consider change the default config for specific package
2020-12-11 15:08:39 <ikke> ncopa: What would send signal 15 to programs, though?
2020-12-11 15:09:00 <kpcyrd> ncopa: I don't have hard feelings about analytics, I imagine the version check could be annoying if you aren't following edge
2020-12-11 15:09:40 <ncopa> actually, we disable the version check for browsers
2020-12-11 15:09:47 <ncopa> i think it makes sense to disable that
2020-12-11 15:09:52 <kpcyrd> ok :)
2020-12-11 15:38:39 <ncopa> maxice8: i pushed lua-aports-1.1.0. i also have 3 patches for aports-helpers to list the reverse deps recursively (using lua-aports-1.1.0) and a way to filter by arch: https://tpaste.us/byPB
2020-12-11 15:46:35 <maxice8> Thanks, applied
2020-12-11 15:52:10 <maxice8> wait, so lua-aports=1.1.0-r0 now has an equivalent to `adep list`?
2020-12-11 15:57:15 <ncopa> sort of i guess
2020-12-11 15:57:41 <ncopa> but did adep run the thing recursively?
2020-12-11 15:57:52 <ncopa> i think it only got the first level of revdeps
2020-12-11 16:26:23 <maxice8> Only gets the first level
2020-12-11 16:26:30 <maxice8> it list all reverse dependencies of a pkg
2020-12-11 16:26:44 <ncopa> so i added a way to do it recursively
2020-12-11 16:26:47 <maxice8> no indirects
2020-12-11 16:33:28 <ncopa> with the above patches and lua-aports-1.1.0 i get get the full revdep list:
2020-12-11 16:33:44 <ncopa> ncopa-desktop:~/aports$ CARCH=mips64 ~/src/aports-helpers/adep.lua list --arch=mips64 rust | tpaste
2020-12-11 16:33:44 <ncopa> https://tpaste.us/7gE1
2020-12-11 16:34:25 <ncopa> by setting CARCH the dependency calculation gets correct for things like geoclue, which has different makedepends for s390x and mips64
2020-12-11 16:36:09 <ncopa> i think that is the full list of packages that should be disabled for mips64
2020-12-11 21:43:23 <PureTryOut[m]2> So I have a Python APKBUILD which for some reason gives me a proper package with `abuild rootbld`, but is completely different and useless with `abuild -r`. Any clue why the results might be different?
2020-12-11 21:57:24 <PureTryOut[m]2> It seems in this case the "poetry build" format gives different results depending on what I use, for whatever reason
2020-12-11 21:57:41 <ikke> hmm, strange
2020-12-11 21:59:29 <PureTryOut[m]2> s/format/command
2020-12-11 21:59:29 <alpine-meetbot> PureTryOut[m]2 meant to say: It seems in this case the "poetry build" command gives different results depending on what I use, for whatever reason
2020-12-11 22:03:00 <ikke> PureTryOut[m]2: can it have to do with dependencies being present or not?
2020-12-11 22:03:42 <PureTryOut[m]2> You'd think so since rootbld uses a cleaner build system than -r, but I don't understand why it would matter
2020-12-11 22:04:47 <ikke> Me neither
2020-12-11 22:07:05 <PureTryOut[m]2> rootbld blocks network access by default and -r doesn't, maybe that somehow matters?
2020-12-11 22:08:30 <ikke> oh, could be as well
2020-12-11 22:09:11 <PureTryOut[m]2> (no it doesn't, just gave rootbld network access as well (`options="net"`) and it didn't matter)
2020-12-11 22:09:40 <ikke> :
2020-12-12 02:52:30 <maxice8> back
2020-12-12 02:53:12 <maxice8> PureTryOut: can't the pypi-hosted archive be used ? they usually contain a working setup.py (auto-generated from the poetry thing)
2020-12-12 06:35:07 <maxice8> Compilation failed: 0 error(s), 1 warning(s)
2020-12-12 06:35:11 <maxice8> ok ?!
2020-12-12 06:40:52 <craftyguy> -Werror ? :P
2020-12-12 06:42:30 <maxice8> valac
2020-12-12 08:09:48 <mps> uhm, why: apk del s6-ipcserver => s6-ipcserver: utmps coreutils screen libutempter
2020-12-12 08:18:17 <PureTryOut[m]2> maxice8: oh I did not know that, I'll give it a shot. Still this _should_ work, it seems the Python ecosystem is wanting to replace the good ol' `setup.py` approach
2020-12-12 08:18:28 <maxice8> it is
2020-12-12 08:18:41 <maxice8> and has been a very disruptive
2020-12-12 08:19:01 <maxice8> hopefully toml becomes part of python3 itself and someone writes a super minimal pyproject parser like setuptools
2020-12-12 08:23:19 <skarnet> mps: utmps is normal, I don't know about the other ones, but if people are starting to understand that s6-ipcserver is a useful tool and depend on it, that's not necessarily a bad thing. :P
2020-12-12 08:26:19 <mps> skarnet: :)
2020-12-12 08:26:52 <mps> I like to have option to remove whatever package I don't need
2020-12-12 08:27:15 <mps> or I I don't like
2020-12-12 08:27:19 <skarnet> cool, do that with dbus
2020-12-12 08:27:37 <skarnet> and perl
2020-12-12 08:27:39 <skarnet> and python
2020-12-12 08:27:44 <mps> I'm trying, though time restricts me in last time
2020-12-12 08:28:21 <mps> I don't have python on my servers (most) and I like to have perl everywhere
2020-12-12 08:29:18 <detha> other way around ;) python is needed for ansible, so it is everywhere
2020-12-12 08:29:27 <detha> dbus can go diaf
2020-12-12 08:30:16 <ikke>  I don't get the aversion against dbus
2020-12-12 08:30:45 <detha> unneeded complexity
2020-12-12 08:31:29 <skarnet> the general answer to "I don't get the aversion against foo" is "have you LOOKED at foo's code?"
2020-12-12 08:31:41 <skarnet> but this is beside the point
2020-12-12 08:32:02 <skarnet> my point is that nobody should hate dependencies because they are dependencies
2020-12-12 08:32:06 <mps> and I run X with awesome wm without dbus and without udev
2020-12-12 08:32:23 <skarnet> people should hate dependencies because they're pulling it a lot of low-quality crap
2020-12-12 08:32:32 <skarnet> pulling in*
2020-12-12 08:32:42 <skarnet> and I can prove that with s6-ipcserver it's not the case
2020-12-12 08:33:06 <detha> the idea of dependencies is that not every project reinvents the wheel. Which is good.
2020-12-12 08:33:27 <skarnet> yes
2020-12-12 08:33:38 <mps> one of the reasons to switch from debian for me is so called 'debian dependencies hell'
2020-12-12 08:34:06 <detha> But too much of a good thing can be bad. See leftpad.
2020-12-12 08:34:42 <skarnet> that's because debian 'wheel' pulls in 'rim' and 'hubcap' and 'tire factory'
2020-12-12 08:35:04 <skarnet> if you could just have a wheel you'd be happy
2020-12-12 08:35:06 <mps> if it looks like ubuntu, walk like ubuntu .... it must be ubuntu :)
2020-12-12 08:36:08 <ikke> Sadly there is no good way to pull in optional functionality. Things have to be compiled in, and then, require the dependency
2020-12-12 08:36:44 <mps> no, we should revert to alpine base principle: minimum dependencies
2020-12-12 08:37:02 <ikke> mps: But that's very subjective
2020-12-12 08:37:15 <mps> yes
2020-12-12 08:37:43 <ikke> What's unnecessary cruft for one is absolutely required for another
2020-12-12 08:37:57 <mps> other options leads to switch back to debian, or feel like that using alpine
2020-12-12 08:37:58 <detha> Optional functionality can be implemented perfectly well. Check if you can load the .so, if not, give error on configs that need that functionality
2020-12-12 08:38:14 <ikke> detha: right, but that requires upstream support
2020-12-12 08:38:21 <detha> Indeed.
2020-12-12 08:38:31 <ikke> not a lot you can do about from a distro perspective
2020-12-12 08:38:33 <detha> Or pretty invasive patching
2020-12-12 08:38:56 <mps> ikke: dependencies can be installed 'by hand' and not enforced
2020-12-12 08:39:32 <ikke> only if it's not a soname dependency
2020-12-12 08:39:39 <mps> ofc
2020-12-12 08:39:40 <ikke> and, requires good documentation
2020-12-12 08:40:06 <ikke> You cannot expect everone to know that they need to install libxyz to get certain functionality
2020-12-12 08:40:16 <mps> huh
2020-12-12 08:40:18 <maxice8> oh that is fun
2020-12-12 08:40:22 <mps> why not?
2020-12-12 08:40:31 <detha> subpackages foo-ldap, that pull in ldap, for example
2020-12-12 08:40:36 <maxice8> love having a bad telegram-desktop experience until I package and install libappindicator or something so I can have non-stupid dialogs
2020-12-12 08:41:06 <mps> there is old saying: make system which even idiot can use and then only idiot will use it
2020-12-12 08:41:16 <ikke> mps: because not everyone is intimately familiar with all the dependencies a might have
2020-12-12 08:41:35 <ikke> a project*
2020-12-12 08:41:56 <mps> it is not hard to learn, I think
2020-12-12 08:42:46 <ikke> archlinux gives suggestions
2020-12-12 08:42:52 <ikke> if you want this, instal that\
2020-12-12 08:42:56 <ikke> when installing a package
2020-12-12 08:43:28 <mps> whatever you do for people who don't like to learn it will be 'bad' in their eyes
2020-12-12 08:44:00 <ikke> mps: it's not necessarily about wanting to learn
2020-12-12 08:44:07 <skarnet> mps: such as making a package depend on a utility you don't know?
2020-12-12 08:44:17 <skarnet> ba-dum ksh
2020-12-12 08:44:24 <mps> :)
2020-12-12 08:46:23 <mps> however, but I think we should go back to principle: minimum dependencies (till we officially change this principle to 'install everything')
2020-12-12 08:47:25 <detha> Or finer-grained dependencies
2020-12-12 08:47:37 <skarnet> feels like being in 2002 again
2020-12-12 08:48:05 <skarnet> that's the nice thing with distro discussions, they make you feel perpetually young!
2020-12-12 08:48:26 <detha> Yeah. I have mostly given up on that, and go 'oh, it wants to pull half the repository in? Fine, disk space is cheap'
2020-12-12 08:48:41 <mps> skarnet: no, I feel as old-timer :)
2020-12-12 08:49:33 <ikke> It can be quite frustrating that you have to compile your own software because some required functionality has not been built in (or change distro)
2020-12-12 08:49:53 <ikke> it's a tough choice to make
2020-12-12 08:50:27 <ikke> so do you want to make a distro that's only usuable by yourself, or something that is genereally usefull
2020-12-12 08:50:40 <mps> ikke: then we should change moto: small, simple (secure faded away already)
2020-12-12 08:51:27 <ikke> mps: I think we already do a lot by having as much as possible in subpackages that people can opt into
2020-12-12 08:51:48 <ikke> openssh-pam instead of shipping openssh with pam by default
2020-12-12 08:53:12 <mps> ikke: ascribed to Leonardo is saying: perfection is not when you don't have to add anything more but when you don't have to remove anything more (or similar, from head)
2020-12-12 08:54:07 <ikke> lets ditch community and testing then, and only focus on docker / server deployments :)
2020-12-12 08:54:31 <ikke> nobody would use it, but still
2020-12-12 08:54:55 <mps> and skarnet, known to write minimal and efficient tools advocate for 'big everything' ;p
2020-12-12 08:56:36 <mps> ikke: I think stability, efficiency and similar features are more important that a number of users or downloads
2020-12-12 08:57:46 <ikke> that is absolutely true, but this is also value in having a larger user base
2020-12-12 08:57:56 <ikke> s/this/there
2020-12-12 08:57:56 <alpine-meetbot> ikke meant to say: that is absolutely true, but there is also value in having a larger user base
2020-12-12 08:59:03 <ikke> if you are a small niche distribution, you also have take care of everything, upstream would not bother taking you into account
2020-12-12 08:59:08 <detha> One thing that came out of the centos mess: RH doesn't give a hoot about number of centos users. Until declining number of users starts to impact on number of contributors.
2020-12-12 09:04:16 <Cogitri> I think the main thing that came out is that loads of people sure dislile RH with all the FUD that was around this release
2020-12-12 09:04:22 <mps> detha: hah, no. RH only wants money and if they don't see money in something they don't care for that
2020-12-12 09:04:35 <Cogitri> I mean I don't want to defend RH's move, but people sure let their imagination run wild
2020-12-12 09:07:30 <detha> Perceived value of 'having a free clone that people can upgrade from' beats perceived value of 'having a free testbed, and making people who need X for compliance reasons pay'
2020-12-12 09:07:37 <mps> re deps, on alpine is so easy to create metapackages (virtual) if we need to have 'full blown' and ready made pkgs/flavors/whatever
2020-12-12 09:07:50 <Cogitri> Like people thinking CentOS Stream will be like Arch because it's a rolling release (OK, it wasn't a great idea of RH to mention that on the project website) when it's actually just current RH release + updates which are planned for the next RH release
2020-12-12 09:08:23 <skarnet> mps: you misunderstood me, I am not advocating for anything
2020-12-12 09:08:46 <skarnet> I am advocating *against* making sweeping statements such as 'dependencies are bad' or 'dependencies are good'
2020-12-12 09:09:20 <mps> skarnet: ok, sorry then
2020-12-12 09:09:57 <detha> Cogitri: the main issue will be kABI. Which royally puts a spanner it the works of things like elrepo
2020-12-12 09:16:27 <PureTryOut[m]2> maxice8: you're right, PyPi does ship a `setup.py` and the CI creates a proper package now
2020-12-12 09:16:34 <PureTryOut[m]2> !15524 is ready to go now
2020-12-12 09:36:53 <maxice8> https://lists.alpinelinux.org/~alpine/devel/%3C86c7a81e-1640-7f82-9e13-dfdbe1aad07b%40gmail.com%3E
2020-12-12 09:37:07 <maxice8> Always good to use the pypi, except when tests are not included in the tarball
2020-12-12 09:42:45 <Cogitri> Not sure if we need versioned packages when the only time users would interact with those are when they use edge or upgrade releases
2020-12-12 09:49:48 <mps> Cogitri: I agree
2020-12-12 09:59:20 <Ariadne> i'm advocating in favor of making sweeping statements such as 'plushies are good'
2020-12-12 10:00:11 <Ariadne> [01:09:46] <mps> uhm, why: apk del s6-ipcserver => s6-ipcserver: utmps coreutils screen libutempter
2020-12-12 10:00:32 <Ariadne> this is probably a bug, i think we need split the client side of utmps out.
2020-12-12 10:00:36 <maxice8> The flufflyer the plushie the better
2020-12-12 10:01:04 <Ariadne> it was not my intention to pull in utmps server side unless the admin wanted it
2020-12-12 10:01:52 <mps> I don't understand much of slang
2020-12-12 10:02:05 <mps> Ariadne: nice to hear
2020-12-12 10:02:34 <mps> I thought it was not done by intention
2020-12-12 10:02:56 <Ariadne> yeah only the client side
2020-12-12 10:03:32 <ikke> maxice8: were you working on disabling those packages on mips64? (otherwise I will do it)
2020-12-12 10:03:42 <maxice8> do it
2020-12-12 10:03:47 <ikke> ok
2020-12-12 10:11:55 <Ariadne> mps: a plushie is a stuffed animal
2020-12-12 10:19:14 <afontain_> Oh, I thought it was just a made up word
2020-12-12 10:20:06 <mps> Ariadne: looks nice like this https://blog.stuffedsafari.com/wp-content/uploads/2016/03/stuffed-animal-collection.jpg thanks
2020-12-12 10:20:58 <mps> there are a lot of these in my house :)
2020-12-12 10:23:33 <mps> why i didn't concluded from context, here these are called 'pleesh' (pliš) animals
2020-12-12 10:29:58 <afontain_> oh, those are called peluche around here (phuh-lush)
2020-12-12 10:29:59 <skarnet> Ariadne: I followed the regular Alpine packaging style which doesn't separate the .so's from the binaries, and here the binaries are server-side while the .so is client-side
2020-12-12 10:30:10 <Ariadne> yes
2020-12-12 10:30:13 <skarnet> but if you depend on utmps-static then you should just pull the .a's
2020-12-12 10:30:16 <skarnet> not the binaries
2020-12-12 10:30:28 <skarnet> and the lib is small so linking against the .a should be fine
2020-12-12 10:30:57 <Ariadne> some things did not link optimally against the static lib
2020-12-12 10:31:08 <skarnet> oh? what happened?
2020-12-12 10:37:09 <Ariadne> i forget :)
2020-12-12 15:26:31 <mps> we have allegro 5 and now this !15709
2020-12-12 15:26:58 <mps> why?
2020-12-12 15:27:31 <ikke> "Some packages require allegro4 to work, because allegro5 (packaged in Alpine) is not backwards compatible."
2020-12-12 15:28:57 <mps> hmm, doesn't we package latest stable upstream pkgs whenever possible
2020-12-12 15:29:21 <ikke> there are cases where we have multiple versions side-by-side
2020-12-12 15:29:49 <mps> this is only for important pkgs afaik
2020-12-12 15:29:58 <maxice8> Qt and GTK
2020-12-12 15:30:08 <maxice8> Allegro still supported upstream?
2020-12-12 16:38:25 <maxice8> interesting error in test https://build.alpinelinux.org/buildlogs/build-3-13-aarch64/community/telegraf/telegraf-1.16.3-r1.log
2020-12-12 16:39:08 <ikke> right
2020-12-12 16:39:51 <ikke> I wonder how they are doing a reverse lookup
2020-12-12 16:40:22 <ikke> https://tpaste.us/ejOE
2020-12-12 16:41:27 <ikke> ah, aarch64
2020-12-12 16:42:27 <ikke> maxice8: I think it should be fixed now
2020-12-12 16:42:33 <maxice8> 	require.EqualValues(t, "localhost", f)
2020-12-12 16:43:12 <maxice8> algitbot: retry 3.13-stable
2020-12-12 16:43:23 <maxice8> oh derp, doesn't exist yet
2020-12-12 16:43:26 <maxice8> algitbot: retry master
2020-12-12 17:57:42 <omni> how far off is 3.13 release? I think !12176 may break for anyone running zfs as rootfs (possibly not for someone running grub2?)
2020-12-12 17:58:12 <omni> huh, that was not what I meant
2020-12-12 17:58:27 <omni> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12176
2020-12-12 17:58:32 <omni> how to bot
2020-12-12 17:59:56 <Cogitri> Hm, wfm with a ZFS /
2020-12-12 18:00:16 <omni> I mean to look further into it, otherthan allowing rw mount of /sysroot, but have other things I've prioritized
2020-12-12 18:00:18 <maxice8> omni: # for issues ! for merge requests
2020-12-12 18:00:27 <omni> maxice8: right
2020-12-12 18:43:58 <maxice8> midori failed because it passed --fatal-warnings
2020-12-12 18:45:28 <maxice8> because it thought we were in a development build
2020-12-12 18:45:37 <maxice8> because git tags --describe failed
2020-12-12 18:46:57 <maxice8> another side-effect is that it also didn't disable asserts
2020-12-12 20:24:15 <omni> Cogitri: @edge with syslinux, /boot on ext4 partition and zfs 2.0.0? (or if this is due to another updated package)
2020-12-12 20:28:23 <Cogitri> I use rEFInd with /boot on VFAT but I doubt that changes something
2020-12-12 20:28:52 <Cogitri> I haven't upgraded ZFS to 2.0.0 yet though, so maybe that's it
2020-12-12 21:08:13 <timlegge> anyone notice build-edge-x86 builder seems to be having issues with community/notcurses
2020-12-12 21:14:11 <mps> yes, again
2020-12-12 21:15:01 <mps> i informed upstream about problem
2020-12-12 21:16:05 <mps> a939ff6cb728a8dd2b2c2f6d3c232452def21640
2020-12-12 21:16:31 <mps> commit msg says it is fixed but it is not
2020-12-12 23:14:30 <Hello71> apk fetch
2020-12-12 23:16:48 <tbodt> ?
2020-12-12 23:20:59 <Hello71> popen apk fetch -s
2020-12-12 23:22:12 <tbodt> I'm not running this on linux so that's not really an option
2020-12-12 23:25:10 <Hello71> at a guess, it's the hash of the .SIGN or somesuch
2020-12-12 23:26:32 <tbodt> it is not
2020-12-12 23:27:17 <tbodt> neither is it the hash of the apk, or the output of gunzip -c apk
2020-12-12 23:28:46 <tbodt> the relevant code appears to have been written a decade ago by timo teras
2020-12-12 23:36:41 <mps> https://wiki.alpinelinux.org/wiki/Apk_spec
2020-12-12 23:37:19 <Hello71> but is it accurate
2020-12-12 23:37:36 <mps> well /o\
2020-12-12 23:38:55 <tbodt> even if it were accurate, it doesn't actually have the info I want
2020-12-12 23:39:49 <mps> source is accurate
2020-12-12 23:43:00 <tbodt> not the easiest to read though
2020-12-12 23:43:29 <mps> right
2020-12-12 23:43:34 <tbodt> oh I think I found it
2020-12-12 23:43:58 <tbodt> .apks are a series of 3 gzip streams concatenated together (for some reason gunzip is happy to ignore this fact and decompress them in sequence)
2020-12-12 23:44:04 <tbodt> each one is a tar
2020-12-12 23:44:22 <tbodt> first one has the .SIGN, second has the .PKGINFO, third has the rest
2020-12-12 23:44:23 <mps> yes
2020-12-12 23:44:29 <mps> but, gn
2020-12-12 23:44:44 <tbodt> the hash in the APKINDEX is the hash of the second gzip stream (after decompressing)
2020-12-12 23:48:18 <omni> Cogitri: yes, I think this is related to the zfs upgrade but I'm not entierly sure
2020-12-12 23:48:37 <omni> I may be able to look at it tomorrow
2020-12-13 01:21:13 <omni> how about an IRC channel for documentation? man pages, the wiki etc
2020-12-13 04:08:30 <Ariadne> there is #alpine-docs for that afaik
2020-12-13 04:12:33 <omni> Ariadne: look at that, that I didn't even try!
2020-12-13 04:13:56 <Ariadne> anyway, some scammer is selling alpine images on aws marketplace for the low low cost of $2500/year
2020-12-13 04:14:24 <Ariadne> dalias was able to ping some aws people about it, maybe we won't have to send them a nastygram to get this fixed (:
2020-12-13 04:17:13 <dalias> :)
2020-12-13 04:17:42 <dalias> yeah it helps having presence in right circles on twitter
2020-12-13 04:20:21 <Ariadne> i have presence in those circles too :P
2020-12-13 04:20:26 <Ariadne> i just did not think about doing that
2020-12-13 04:21:09 <dalias> :)
2020-12-13 07:10:30 <maxice8> https://lists.alpinelinux.org/~alpine/devel/%3C86c7a81e-1640-7f82-9e13-dfdbe1aad07b%40gmail.com%3E
2020-12-13 08:01:08 <obarun>  https://youtu.be/41HM-KY-dYU
2020-12-13 08:23:19 <mps> obarun: posting url without explain context is not good things to do here
2020-12-13 09:09:33 <maxice8> ikke: sorry for taking so long, fixed 1/2 of the mkmr issues you opened and need your help with the other
2020-12-13 09:15:04 <ikke> maxice8: no worry. I just open these issues so that we don't forget about them.
2020-12-13 09:16:06 <obarun> mps: sorry, i was so existed to share it. This tool allow to setup a namespace to protect part of the system, and "cherry on the top of the cake" it allow to handle multi-processes which fork itself without any hack like  openning a bunch of fd or using cgroups (which has never designed to track processes). Anyway, i will not doing this kind of stuff here anymore
2020-12-13 09:16:43 <mps> obarun: np :)
2020-12-13 09:32:02 <ikke> It's not an issue to share things, but like mps said, providing context helps
2020-12-13 09:37:02 <mps> yes, that is what I wanted to say. as usual ikke explains better
2020-12-13 09:46:56 <artok> hm.. after upgrading to edge, rpi4 has problem with wlan.. takes minutes to get dhcp lease
2020-12-13 09:47:20 <Ariadne> firmware maybe?
2020-12-13 09:47:38 <Ariadne> which dhcp client do you use?
2020-12-13 09:51:49 <artok> udhcpc
2020-12-13 10:01:35 <artok> I need to doublecheck the firmware, I thought I'd update that
2020-12-13 10:55:16 <artok> well then
2020-12-13 10:55:23 <artok> regulatory.db error at least
2020-12-13 11:03:22 <mps> on rpi zero edge, dhcp works fine
2020-12-13 11:26:22 <walbon> ikke, have you found a reason for the missing of ppc build ? I missed the following up of discuss after.
2020-12-13 11:28:47 <ikke> walbon: no, not yet
2020-12-13 11:29:48 <ikke> seems like smokeping is causing it
2020-12-13 11:33:18 <ikke> trying to keep an eye on it
2020-12-13 11:33:45 <artok> no clm_blob available (err=-2), device may have limited channels available
2020-12-13 11:45:56 <ikke> https://tpaste.us/kkEa
2020-12-13 11:58:07 <ikke> should we just disable smokeping on ppc64le?
2020-12-13 12:00:37 <artok> so brcmfmac43455-sdio.clm_blob needs to be added into brcm firmware
2020-12-13 12:31:29 <artok> now that if only someone would do merge request for that.. =)
2020-12-13 12:32:16 <mps> artok: where it can be found and is it free
2020-12-13 12:34:57 <artok> https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm
2020-12-13 12:35:28 <ikke> "non-free"
2020-12-13 12:35:37 <artok> not into gpl but permitted to redistribute
2020-12-13 12:35:50 <mps> aha, already answered in latest linux-firmware MR upgrade
2020-12-13 12:54:54 <artok> on which MR ?
2020-12-13 13:07:00 <mps> uh, just a moment
2020-12-13 13:08:23 <mps> artok: !13924
2020-12-13 13:25:48 <maxice8> algitbot: retry master
2020-12-13 13:36:31 <maxice8> Can I get some abuild MRs merged ?
2020-12-13 13:45:36 <maxice8> huh
2020-12-13 13:45:41 <maxice8> our sphinx is too old for re2
2020-12-13 14:00:23 <artok> mps: wifi is stable now since I downloaded firmware-nonfree stuff, all 2months or newer
2020-12-13 14:00:35 <artok> some of them are BT stuff, but nevertheless
2020-12-13 14:06:16 <mps> artok: yes, I expected that. Also I downloaded some of these non-free for one old macbook and it works fine
2020-12-13 14:06:52 <mps> but I don't know can we add these to alpine, as people says ianal
2020-12-13 14:20:44 <Ariadne> i don't see any license for those
2020-12-13 14:20:48 <Ariadne> so no, we cant include it
2020-12-13 14:23:15 <artok> https://github.com/RPi-Distro/firmware-nonfree/blob/master/LICENCE.broadcom_bcm43xx
2020-12-13 14:25:32 <mps> artok: read 5.
2020-12-13 14:28:51 <Ariadne> artok: that is only covering bcm43xx-0.fw and bcm43xx_hdr-0.fw
2020-12-13 14:29:08 <Ariadne> artok: the added firmwares are for other broadcom part numbers and that license cannot be construed to apply to them
2020-12-13 14:29:26 <Ariadne> artok: since it literally says in the name it only applies to bcm43xx part numbers
2020-12-13 14:29:36 <artok> I am totally blind today
2020-12-13 14:30:44 <Ariadne> and yes point 5 is a dealbreaker
2020-12-13 14:31:09 <Ariadne> we cannot fulfill that condition as we have no mechanism to do so
2020-12-13 14:31:22 <Ariadne> (that's not an invite to create such a mechanism)
2020-12-13 14:31:39 <artok> that's funny how many just don't care about that
2020-12-13 14:31:40 <artok> =)
2020-12-13 14:31:52 <Ariadne> in practice it does not really matter
2020-12-13 14:32:05 <Ariadne> its probably something broadcom added to cover their ass
2020-12-13 14:32:29 <artok> it was some years ago when that started to really happen
2020-12-13 14:32:38 <Ariadne> either way, that license only applies to the bcm43xx SKUs
2020-12-13 14:32:41 <artok> because of US and A
2020-12-13 14:33:30 <Ariadne> the US has always been really boneheaded about crypto export
2020-12-13 14:33:41 <Ariadne> in practice its mostly relaxed now
2020-12-13 14:33:53 <Ariadne> but you see a lot of terms like that still floating around
2020-12-13 14:34:12 <artok> some with new government could change that
2020-12-13 14:34:34 <Ariadne> unlikely
2020-12-13 14:34:54 <Ariadne> the current regime would have done so if there were any value in it
2020-12-13 14:56:45 <maxice8> Can someone look at abuild MRs ?
2020-12-13 15:08:15 <maxice8> /home/buildozer/aports/community/qt5-qtwebkit/src/qtwebkit-5.212.0-alpha4/build/DerivedSources/WebCore/CSSGrammar.cpp:160:10: fatal error: CSSGrammar.hpp: No such file or directory
2020-12-13 15:21:06 <maxice8> algitbot: retry master
2020-12-13 15:55:35 <maxice8> !15479 review please
2020-12-13 15:57:08 <maxice8> oops !15749
2020-12-13 15:58:17 <omni> awfully similar numbers, I had to check trice
2020-12-13 16:20:05 <maxice8> yes
2020-12-13 16:54:38 <maxice8> Ikke
2020-12-13 16:54:59 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/-/commit/5d5be36740de1b171fb225c78798f96d5d38e1ef
2020-12-13 17:35:41 <ikke> maxice8: ?
2020-12-13 17:35:56 <maxice8> pull requests changing and breaking checksum
2020-12-13 17:36:19 <ikke> right
2020-12-13 17:39:38 <maxice8> also, opinions on !15749 ?
2020-12-13 17:59:30 <ikke> maxice8: I agree with that
2020-12-13 17:59:41 <ikke> super anoying that it uses a built-in cert store
2020-12-13 18:09:16 <Cogitri> ikke: Sorry for the ping, but have you looked into the beginner-help/mr-wrangler group dor gitlab already?
2020-12-13 18:18:07 <ikke> Cogitri: no, not yet
2020-12-13 18:18:46 <ikke> We have not defined who are going to be in it yet
2020-12-13 18:29:09 <Cogitri> Fair enough, I guess I'll write an email to ~devel, let's see if we can get someone to step up
2020-12-13 18:39:02 <mps> arm64 macbook M1 is really good 'box', pity it is not open for linux, would be very alpine developers machine
2020-12-13 18:40:12 <mps> very good*
2020-12-13 19:10:14 <artok> duh.. totally unusable wlan with rpi4 now on edge
2020-12-13 19:19:33 <artok> ...damn closed stuff
2020-12-13 20:05:34 <artok> mps around?
2020-12-13 20:07:08 <artok> rpi4 -edge would need CONFIG_PCIE_BRCMSTB
2020-12-13 20:08:04 <mps> artok: you mean linux-edge aarch64?
2020-12-13 20:08:43 <artok> that
2020-12-13 20:09:14 <mps> ok, will be done on next upgrade. thanks
2020-12-13 20:09:20 <mps> anything else
2020-12-13 20:09:43 <mps> next upgrade will to 5.10 I think
2020-12-13 20:09:57 <artok> well that prevented boot since usb is behind pcie, so that was all
2020-12-13 20:10:01 <artok> for now
2020-12-13 20:10:13 <mps> ok
2020-12-13 20:12:49 <artok> I'll launch build for that bastard and test out more
2020-12-14 00:08:48 <Ariadne> [11:38:59] <mps> arm64 macbook M1 is really good 'box', pity it is not open for linux, would be very alpine developers machine
2020-12-14 00:08:52 <Ariadne> bootloader is not locked
2020-12-14 00:09:01 <Ariadne> drivers are missing though
2020-12-14 00:09:11 <Ariadne> i guess marcan (of fail0verflow group) is going to write drivers
2020-12-14 00:11:16 <Ariadne> dalias: did you ever hear back from that AWS contact
2020-12-14 01:39:28 <dalias> nothing more yet
2020-12-14 02:19:31 <minimal> Ariadne: re that AWS thing - whilst that appears to be blatant profiteering the GPL and MIT licenses don't prevent resale. Other licenses may or may not.
2020-12-14 02:35:57 <jmchael> what's the policy for alsa/pulseaudio/jack support in packages? say if enabling onw excludes the others or something
2020-12-14 02:36:01 <jmchael> one*
2020-12-14 02:48:00 <yZ5vlALg86lP> usually alsa is prefered
2020-12-14 03:06:55 <jmchael> makes sense
2020-12-14 04:45:32 <Ariadne> minimal: while true, it is still a problem to use our logo and branding materials in that effort.  there’s other issues as well, for example the EULA for that image is the docker enterprise one.
2020-12-14 04:46:40 <Ariadne> besides its moot anyway, we will soon have official official images anyway
2020-12-14 04:46:51 <Ariadne> based on your cloud-unit work
2020-12-14 04:47:24 <Ariadne> and those will obviously not cost $2500+ yearly
2020-12-14 04:51:08 <Ariadne> oh he parted
2020-12-14 06:02:57 <Ariadne> dalias: anything remaining for musl 1.2.2?
2020-12-14 06:35:19 <ikke> https://lore.kernel.org/lkml/CAHk-=whCKhxNyKn1Arut8xUDKTwp3fWcCj_jbL5dbzkUmo45gQ@mail.gmail.com/T/#u
2020-12-14 06:35:59 <ikke> linux 5.10 released
2020-12-14 06:36:05 <Ariadne> will it become LTS though
2020-12-14 06:36:52 <ikke> good question
2020-12-14 06:36:58 <ikke> mps thinks it will
2020-12-14 06:42:24 <MY-R> ye it will be LTS but like always after few versions
2020-12-14 06:43:05 <ikke> probably too late before 3.11
2020-12-14 06:43:08 <ikke> 3.13*
2020-12-14 06:46:05 <Ariadne> well if it is known to be LTS, we could just jump it now
2020-12-14 06:46:06 <MY-R> and edge will be freezing to prepare for 3.13?
2020-12-14 06:46:16 <MY-R> and when*
2020-12-14 06:46:22 <ikke> https://twitter.com/gregkh/status/1320745076566433793?s=19
2020-12-14 06:46:23 <Ariadne> i would just like to see a citation on it before we do that
2020-12-14 06:46:27 <ikke> ^
2020-12-14 06:46:34 <Ariadne> ok
2020-12-14 06:46:38 <Ariadne> well if greg k-h says so
2020-12-14 06:46:43 <MY-R> ye GK confirmed in interview?
2020-12-14 06:46:45 <Ariadne> lets jump linux-lts to 5.10
2020-12-14 06:47:55 <Ariadne> provided ncopa is fine with that
2020-12-14 06:49:53 <ozzz> hello all! I try to compile aports packages, but I'm getting that error : ERROR: Unable to lock database: No such file or directory. Not sure if I'm doing it right. I clonde repo, created 2 dirs, working and out, then I call ./mkimage.sh --arch armv7 --hostkeys --profile mini
2020-12-14 06:49:53 <ozzz> rootfs --outdir outdir --workdir workdir --repository http://dl-cdn.alpinelinux.org/alpine/v3.9/main
2020-12-14 06:50:07 <MY-R> here can see some very general highlights about changes: https://kernelnewbies.org/Linux_5.10
2020-12-14 06:50:14 <ozzz> One nuance here: I have nfs catalog
2020-12-14 06:51:20 <ozzz> maybe that due to nfs, I don't know yet. but also maybe I'm doing something wrong? Is there any instructions or manual for building process?
2020-12-14 06:51:55 <Ariadne> unfortunately honeycomb ethernet did not make it to 5.10 :(
2020-12-14 06:53:12 <ikke> https://tpaste.us/7gE1 these packages still need to be disabled on mips64
2020-12-14 06:53:52 <Ariadne> i'll do it
2020-12-14 07:06:05 <ncopa> good morning
2020-12-14 07:08:27 <maxice8> morning
2020-12-14 07:15:58 <ikke> ncopa: morning
2020-12-14 07:16:58 <maxice8> ncopa: can you take a look at some abuild MRs ?
2020-12-14 07:19:12 <ikke> gir-to-d is failing on arm(hf|v7)
2020-12-14 07:19:23 <ikke> and x86 as well
2020-12-14 07:20:15 <maxice8> It is a known issue
2020-12-14 07:20:17 <mps> Ariadne: ikke: yes, most predictable releases of software is kernel
2020-12-14 07:20:33 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14364
2020-12-14 07:21:49 <mps> I think in september I told (by crystal ball) here that the next lts will be 5.10 and that it will be released in december
2020-12-14 07:22:10 <ikke> yeah, with a fixed release schedule it's not hard to predict :P
2020-12-14 07:22:15 <ncopa> maxice8: i think we are a bit late in release cycle to merge in too many abuild changes
2020-12-14 07:22:25 <ncopa> i mean, we have already built v3.13/main
2020-12-14 07:22:42 <ncopa> and changing the build behavior now seems unwise
2020-12-14 07:23:07 <maxice8> they are 5 months old MRs
2020-12-14 07:23:16 <mps> 3-4 weeks ago I proposed to prepare 5.10-rc for 3.13 but BDFL was against and I agreed, too late because 'freeze'
2020-12-14 07:25:48 <mps> so world^Walpine will 'move' with 5.4 and everything will be ok :)
2020-12-14 07:28:56 <ncopa> i must admit that jumping on 5.10 is tempting
2020-12-14 07:29:15 <ncopa> im mostly worried about the 3rd party mods
2020-12-14 07:31:03 <mps> not only this, but first new kernel-headers and rebuild all pkgs with it
2020-12-14 07:31:12 <ncopa> thats not needed
2020-12-14 07:31:38 <ncopa> kernel is ABI compatible backwards
2020-12-14 07:31:51 <ncopa> so you can run all older binaries on newer kernels
2020-12-14 07:31:57 <mps> hmm, some will be good idea to rebuild, liburing comes first to mind
2020-12-14 07:32:15 <ncopa> whats liburing?
2020-12-14 07:32:25 <ikke> New kernel feature of async operations
2020-12-14 07:32:26 <mps> io-uring lib
2020-12-14 07:33:41 <mps> exfat tools should be removed and exfat-utils moved to community or main
2020-12-14 07:33:57 <MY-R> will it be included in 3.13? !14200
2020-12-14 07:34:27 <mps> but I didn't finished my morning coffee yet, so not awaken yet
2020-12-14 07:37:15 <mps> ncopa: yes, I run 5.10-rc and edge with pkgs built with current linux-headers and didn't noticed any problem, but I don't run much of 'corner cases' software, so 'who knows'
2020-12-14 07:37:21 <ncopa> MY-R: Looks like !14200 is merged so yes
2020-12-14 07:38:00 <ncopa> are there any specific new kernel features that we are interested in?
2020-12-14 07:39:04 <mps> heh, kernelnewbies series from 5.4 to 5.10 could tell
2020-12-14 07:39:30 <mps> exfat is maybe
2020-12-14 07:40:09 <mps> and what I think is good thing is we could remove -rpi flavour
2020-12-14 07:40:57 <mps> but I agree with you, move to 5.10 is not 'too much' important
2020-12-14 07:42:40 <mps> linux-edge armhf already work fine on rpi zero
2020-12-14 07:43:40 <mps> (says one who dislike RPis :) )
2020-12-14 07:46:43 <mps> ncopa: for third-party drivers, half of them (at least) will not be needed with 5.10
2020-12-14 07:51:16 <artok> heh.. doing kernel compilation on rpi4 two times at once.. first and last
2020-12-14 08:04:39 <mps> artok: did you tried with ssd attached over usb
2020-12-14 08:05:18 <mps> it works quite fine for me, though on other arm64 SOC
2020-12-14 08:08:25 <artok> usb stickie doing the slowing of things
2020-12-14 08:10:32 <artok> yet, close 100% cpu saturation
2020-12-14 08:13:35 <mps> so RPi4 doesn't have usb 3.1?
2020-12-14 08:14:40 <artok> Via Labs VL805 chip
2020-12-14 08:15:24 <artok> two of each, 3.0, 2.0
2020-12-14 08:20:13 <mps> I have 3.0 on acer chromebook and it is slow really
2020-12-14 08:20:31 <artok> PNY usb 3.0 stick
2020-12-14 09:13:44 <PureTryOut[m]2> could somebody merge !14945? qt5-qtwebengine is killing CI again (out of RAM I think, no clear compilation error) but otherwise it works
2020-12-14 09:27:34 <mps> ncopa: did you had time to look !15554
2020-12-14 09:29:34 <maxice8> PureTryOut: enable collaboration on !14945
2020-12-14 09:29:51 <maxice8> or rebase and fix the conflicts
2020-12-14 09:30:00 <PureTryOut[m]2> If you mean "Allow commits from members who can merge to the target branch", that is enabled
2020-12-14 09:30:14 <maxice8> I can't push to it, there are various packages that conflict
2020-12-14 09:30:39 <maxice8> nvm
2020-12-14 09:30:40 <maxice8> wrong branch n ame
2020-12-14 09:32:25 <PureTryOut[m]2> Rebased it
2020-12-14 09:32:46 <PureTryOut[m]2> Oh you did as well lol
2020-12-14 09:33:23 <PureTryOut[m]2> Thanks for merging!
2020-12-14 09:34:14 <maxice8> I couldn't push because I had the wrong branch name
2020-12-14 09:34:25 <PureTryOut[m]2> Nice
2020-12-14 09:35:20 <maxice8> huh, ttf-font-awesome was removed
2020-12-14 09:35:23 <maxice8> in the qt5 upgrade commit
2020-12-14 09:35:29 <PureTryOut[m]2> Huh?
2020-12-14 09:35:39 <PureTryOut[m]2> Not sure how that happened...
2020-12-14 09:36:27 <PureTryOut[m]2> Oh that's because of my shitty upgrade script crapping out and me temporarily removing that aport to get around it, and then forgot to undo that
2020-12-14 09:36:30 <PureTryOut[m]2> Sorry 🙈
2020-12-14 09:37:01 <maxice8> heh
2020-12-14 09:37:22 <maxice8> I'll restore it
2020-12-14 09:37:28 <PureTryOut[m]2> 👍️
2020-12-14 09:38:30 <maxice8> done
2020-12-14 10:10:34 <maxice8> PureTryOut: can you review !15792 !15752 ?
2020-12-14 10:12:26 <maxice8> afontain: ping
2020-12-14 10:12:47 <afontain_> yes?
2020-12-14 10:13:16 <maxice8> can you review !15773 ?
2020-12-14 10:16:02 <afontain_> oh yes, that one package that ended up in main :X
2020-12-14 10:17:32 <maxice8> Can I move it to community ?
2020-12-14 10:18:09 <afontain_> yes
2020-12-14 10:19:33 <maxice8> ok, added a commit to !15773 to move it to community
2020-12-14 10:22:14 <afontain_> to be fair, for something that was in main, I don't think I was giving it proper care
2020-12-14 10:40:14 <Ariadne> ncopa: linux-lts jump to 5.10?  what say you
2020-12-14 10:41:07 <afontain_> otherwise, the MR looks good to me
2020-12-14 10:42:17 <ikke> Ariadne: https://tpaste.us/9jk7
2020-12-14 10:42:30 <Ariadne> o
2020-12-14 10:42:41 <Ariadne> well some mods we can drop
2020-12-14 10:42:46 <Ariadne> like wireguard
2020-12-14 10:43:29 <ikke> I think rtl8821ce-lts can be dropped too
2020-12-14 10:44:03 <maxice8>  more opinions on !15749 ?
2020-12-14 10:44:30 <Ariadne> maxice8: hold until 3.14
2020-12-14 10:44:35 <maxice8> ok
2020-12-14 10:48:11 <ozzz> hello all! I try to compile aports packages, but I'm getting that error : ERROR: Unable to lock database: No such file or directory. Not sure if I'm doing it right. I clonde repo, created 2 dirs, working and out, then I call ./mkimage.sh --arch armv7 --hostkeys --profile mini
2020-12-14 10:48:37 <ozzz> rootfs --outdir outdir --workdir workdir --repository http://dl-cdn.alpinelinux.org/alpine/v3.9/main
2020-12-14 10:49:03 <Ariadne> mkimage has nothing to do with packages
2020-12-14 10:49:32 <ozzz> Ariadne,hello. Could you please point me on some kind of instruction/manual?
2020-12-14 10:49:52 <Ariadne> to do what, exactly
2020-12-14 10:49:56 <ozzz> I wan't to compile all packages of Alpine
2020-12-14 10:50:04 <Ariadne> ok
2020-12-14 10:50:09 <Ariadne> install lua-aports
2020-12-14 10:50:17 <Ariadne> and use buildrepo main community testing
2020-12-14 10:50:33 <ozzz> I'll explain in detail
2020-12-14 10:50:38 <ozzz> I have tablet
2020-12-14 10:51:22 <Ariadne> mobile devices are better served by postmarketOS than base alpine
2020-12-14 10:51:30 <ozzz> with armv7 cpu. so I wan't to compile directly on that tablet. I installed abuild already and cloned aports repo
2020-12-14 10:51:47 <Ariadne> what do you want to compile though
2020-12-14 10:51:52 <ozzz> Ariadne, yeah, I have postmarketos installed on it
2020-12-14 10:52:16 <ozzz> Ariadne, all packages which used in PMOS
2020-12-14 10:52:41 <Ariadne> you should ask #postmarketOS what the best way is i think
2020-12-14 10:53:14 <ozzz> they said it's necessary to compile all aports, and create my own repo
2020-12-14 10:53:39 <ozzz> so here I stuck. I can't find any manual how to do it properly
2020-12-14 10:53:51 <Ariadne> ollieparanoid[m]: can you help ozzz?
2020-12-14 10:55:02 <ozzz> Ariadne, thanks for help
2020-12-14 10:55:35 <ollieparanoid[m]> ozzz: hi! "necessary to compile all aports" sounds strange. but Ariadne is right, let's discuss this in #postmarketOS instead
2020-12-14 10:55:47 <ozzz> ollieparanoid[m], thanks!
2020-12-14 10:56:01 <Ariadne> thanks, i am not sure how to answer that question :)
2020-12-14 10:57:38 <mps> Ariadne: I hope this night linux-edge will be 5.10.0
2020-12-14 10:58:27 <mps> have to assemble all things for armhf to testing build kernel on it
2020-12-14 11:03:08 <Ariadne> would be great to have chromebook oak support on 5.10 kernel :)
2020-12-14 11:08:20 <mps> hehe, Linux arya 5.10.0-1-elm #2 SMP PREEMPT Mon Dec 14 09:27:41 UTC 2020 aarch64 GNU/Linux
2020-12-14 11:09:05 <mps> run on elm-oak
2020-12-14 11:09:52 <mps> I'm working on elm and gru chromebooks unified kernel
2020-12-14 11:10:25 <mps> on gru it works but not yet on elm
2020-12-14 11:18:47 <Ariadne> cool.  if you work on that i'll work on an update-bootloader thing for it
2020-12-14 11:25:57 <mps> ah, thanks for idea. update is where I'm 'weak'
2020-12-14 11:42:58 <mps> artok: are you around? does PCIE_BRCMSTB need to be in-kernel or it could be built as module
2020-12-14 11:45:46 <artok> mps should be ok with module, as you can load it from initramfs with kernel modules= parameter, right?
2020-12-14 11:46:41 <artok> in-kernel would be user friendly =)
2020-12-14 11:51:27 <mps> artok: in-kernel, most of these are already set as 'in-kernel', so I'm also user friendly :-})
2020-12-14 11:52:20 <mps> anything else, while I'm on 'make menuconfig'?
2020-12-14 11:53:15 <MY-R> HZ=1000 in rpi4 ;)
2020-12-14 11:53:53 <artok> hmm.. was there something
2020-12-14 11:53:55 <Ariadne> mps: well, i have two angles of approach here.  one elm-oak chromebook, i have running tianocore
2020-12-14 11:54:56 <ncopa> Ariadne: im testing 5.10 here now
2020-12-14 11:54:59 <ncopa> looks promising
2020-12-14 11:55:16 <ncopa> the good thing is that we can drop some 3rd party modules
2020-12-14 11:55:30 <Ariadne> if i can get tianocore stable on mtk SoCs, then that would be the preferred way
2020-12-14 11:55:38 <mps> MY-R: why 1000Hz
2020-12-14 11:55:45 <Ariadne> because at that point you can boot any EFI aarch64 image you want
2020-12-14 11:55:54 <mps> Ariadne: yes
2020-12-14 11:56:05 <Ariadne> which is obviously a billion times better than this chrome os bootloader crap :)
2020-12-14 11:57:03 <ncopa> i wonder if we could drop virtualbox guest 3rd party module and drbd-lts
2020-12-14 11:57:19 <Ariadne> drbd is upstream
2020-12-14 11:57:24 <ncopa> yup
2020-12-14 11:57:26 <Ariadne> and virtualbox in 2020, honestly
2020-12-14 11:57:32 <Ariadne> i dont think it is needed
2020-12-14 11:57:35 <MY-R> mps: why not, power consumtion wont change drastical since most of the time devices idling and somehow rpi images are already 1000, and lower latency is always nice :)
2020-12-14 11:57:37 <Ariadne> theres better alternatives
2020-12-14 11:57:37 <ncopa> there is also vritualbox in mainline
2020-12-14 11:57:42 <Ariadne> oh is there?
2020-12-14 11:57:44 <ncopa> yup
2020-12-14 11:57:46 <Ariadne> then yeah
2020-12-14 11:57:49 <Ariadne> just drop it (:
2020-12-14 11:57:55 <ncopa> i think the only missing piece may be shared folder
2020-12-14 11:57:59 <ncopa> but i have to check that
2020-12-14 11:58:02 <Ariadne> does that even work
2020-12-14 11:58:08 <Ariadne> i've never gotten that to work
2020-12-14 11:58:17 <Ariadne> and i gave up on vbox like 10 years ago
2020-12-14 11:58:18 <ncopa> i havent tested recently
2020-12-14 11:58:23 <Ariadne> i just launch VMs with qemu
2020-12-14 11:58:23 <mps> MY-R: it is already on linux-edge for aarch64 :)
2020-12-14 11:58:28 <ikke> I'm still using it (on windows0
2020-12-14 11:58:29 <ncopa> i think the 32 bit does not work
2020-12-14 11:58:43 <Ariadne> ikke: windows has hyper-v built in :(
2020-12-14 11:58:50 <ikke> D;
2020-12-14 11:59:02 <ikke> Thank you, no :P
2020-12-14 11:59:07 <mps> heh, how long I'm proposing drbd removal :P
2020-12-14 11:59:07 <MY-R> mps: I prefer stable :<
2020-12-14 11:59:45 <Ariadne> well anyway
2020-12-14 11:59:52 <ncopa> i have occationally used virtualbox on macos, but it no lnoger works with big sur
2020-12-14 11:59:53 <Ariadne> i think we can drop those
2020-12-14 11:59:59 <ncopa> i think we can
2020-12-14 11:59:59 <Ariadne> its ok
2020-12-14 12:00:01 <mps> vbox driver is in linux-edge
2020-12-14 12:00:04 <Ariadne> you can run iSH
2020-12-14 12:00:08 <Ariadne> on apple mac m1
2020-12-14 12:00:15 <Ariadne> which has alpine built in
2020-12-14 12:00:17 <Ariadne> :D
2020-12-14 12:00:28 <ncopa> thats actually a pretty cool idea
2020-12-14 12:01:22 <mps> what is iSH?
2020-12-14 12:01:54 <ncopa> https://ish.app/
2020-12-14 12:02:00 <ncopa> linux shell for ios
2020-12-14 12:02:29 <Ariadne> yeah they use alpine
2020-12-14 12:02:33 <Ariadne> built into it
2020-12-14 12:03:20 <mps> ah, non native
2020-12-14 12:05:26 <ncopa> so far 5.10 looks promising
2020-12-14 12:06:14 <ncopa> only dahdi-linux-lts may need a bit of work but it didnt look too complicated
2020-12-14 12:06:34 <mps> what's with jool
2020-12-14 12:08:59 <artok> mps your build takes less than 1hr for apk ? =)
2020-12-14 12:09:38 <mps> yes
2020-12-14 12:09:57 <artok> so send me aarch64 one when ready
2020-12-14 12:10:11 <mps> ssd attached over usb-c, really fast
2020-12-14 12:10:55 <mps> artok: I'm going to prepare tea and after that I will push linux-edge 5.10.0 to builders
2020-12-14 12:11:04 <artok> ok
2020-12-14 12:11:43 <mps> with PCIE_BRCMSTB
2020-12-14 12:13:30 <Ariadne> my aarch64 builds are super fast
2020-12-14 12:13:35 <Ariadne> unfortunately no honeycomb ethernet :(
2020-12-14 12:13:46 <Ariadne> guess i will stick with usb ethernet for now
2020-12-14 12:13:54 <ncopa> Linux localhost 5.10.0-0-lts #1-Alpine SMP Mon, 14 Dec 2020 07:30:41 UTC x86_64
2020-12-14 12:14:01 <Ariadne> :o
2020-12-14 12:14:29 <ikke> \o/
2020-12-14 12:14:32 <ncopa> in a vm
2020-12-14 12:14:46 <ncopa> i need to config the other architectures as well...
2020-12-14 12:15:50 <Ariadne> i think the octeon3 drivers will land in 5.11 or 5.12
2020-12-14 12:16:04 <mps> ncopa: wait till I push linux-edge, you can then pick some options from it
2020-12-14 12:16:09 <Ariadne> so we should be able to rid ourselves of that BSP kernel soon
2020-12-14 12:16:13 <Ariadne> on mips64 builder
2020-12-14 12:16:14 <Ariadne> :)
2020-12-14 12:16:20 <mps> it will be ready in 30 mins
2020-12-14 12:19:25 <ncopa> linux-lts-5.10.0-r0 installed size:
2020-12-14 12:19:25 <ncopa> 256 MiB
2020-12-14 12:19:25 <ncopa> 245 MiB
2020-12-14 12:19:25 <ncopa> linux-lts-5.4.82-r0 installed size:
2020-12-14 12:19:31 <ncopa> not too bad
2020-12-14 12:22:38 <minimal> Ariadne: re official cloud image, who is working on those? Glad to help out with any cloud-init related issues
2020-12-14 12:23:11 <Ariadne> minimal: i'm planning to deal with the tooling in 3.14 cycle
2020-12-14 12:23:32 <Ariadne> minimal: most likely we will create a team for cloud images
2020-12-14 12:23:56 <minimal> good stuff
2020-12-14 12:24:06 <Ariadne> minimal: re: the 2500$/year AWS debacle, yes in terms of GPL what he is doing is legal
2020-12-14 12:24:18 <Ariadne> but, what he is doing is not legal at large
2020-12-14 12:24:33 <Ariadne> he is, for example, not authorized to use the alpine logo/name in that way
2020-12-14 12:24:54 <Ariadne> he is also including the docker enterprise EULA as his own image EULA, which implies to people they are getting docker enterprise in the image
2020-12-14 12:25:33 <Ariadne> if it was "Joe Bloggs' Alpine Image" that's one thing
2020-12-14 12:25:38 <minimal> yeah use trademarks etc are an issue. I just wrongly got the impression it was the cost issue that was the main concern
2020-12-14 12:26:02 <Ariadne> i mean, it is and it isn't
2020-12-14 12:26:15 <Cogitri> Oh, is Alpine officially trademarked?
2020-12-14 12:26:18 <Ariadne> he's using our name to scam people out of $2500+ yearly
2020-12-14 12:26:52 <minimal> nothing (legally) wrong with me buying a car for $1000 and trying to sell it for $1m
2020-12-14 12:26:55 <Ariadne> i think there was plans to do it, but i am not sure if we actually executed it
2020-12-14 12:27:00 <ikke> Cogitri: Nothing registered, we don't have a legal entity
2020-12-14 12:27:09 <Cogitri> Yes, that's what I thought
2020-12-14 12:27:11 <Ariadne> yes, we really need to fix that
2020-12-14 12:27:25 <Cogitri> Sounds like a ton of very not fun work though
2020-12-14 12:27:32 <Ariadne> minimal: sure :)
2020-12-14 12:28:02 <Ariadne> minimal: but it would be illegal for you to sell you 93 honda civic and tell people it is a lambo
2020-12-14 12:28:24 <minimal> I'm old enough to remember 25-30 years ago the like of Walnut Creak having a business selling CDROMs of BSD and Linux dists...
2020-12-14 12:28:32 <Ariadne> yeah thats different though
2020-12-14 12:28:40 <Ariadne> you're paying them to burn something to  CD and mail it to you
2020-12-14 12:28:52 <Ariadne> and it did not cost $2500/year
2020-12-14 12:29:31 <Ariadne> i bought my first debian CDs from walnut creek when i was a kid because we didnt have a burner
2020-12-14 12:29:33 <ikke> There is the SFC
2020-12-14 12:29:38 <Ariadne> nonono
2020-12-14 12:29:41 <Ariadne> lets stay away from SFC
2020-12-14 12:29:43 <minimal> well back then they could have advertised a set of CDs for $1m.........but I doubt anyone would have bought them ;_
2020-12-14 12:29:46 <ikke> Ariadne: heh
2020-12-14 12:30:13 <Ariadne> i mean, SFC is great in theory, but
2020-12-14 12:30:31 <Ariadne> hmm, dunno :)
2020-12-14 12:30:51 <Ariadne> perhaps SFC is the way to go.  creating a new organization is a massive pain
2020-12-14 12:31:09 <Ariadne> i am just concerned SFC may do things without our consent
2020-12-14 12:31:16 <artok> I think I paid 100 finnish marks for cd stack for slakware and redhat in -97
2020-12-14 12:32:35 <minimal> remember installing Slackware via stacks of floppy disks :-( Think X-Windows alone was 7 disks
2020-12-14 12:33:24 <artok> it was the reason for buying cd's =D
2020-12-14 12:34:47 <minimal> Ariadne: part of the "subtlety" is as to how they are referring to Alpine - its ok to use Alpine's name to refer it to (like you can say your car is a "Ford Focus" without any trademark issues), different if they are claiming its official Alpine
2020-12-14 12:34:56 <Ariadne> minimal: to be clear the issue isnt somebody reselling alpine, if they make it clear they are reselling alpine as a convenience, that s fine
2020-12-14 12:35:10 <Ariadne> but this guy is just like
2020-12-14 12:35:16 <Ariadne> alpine linux image $2500/year lol
2020-12-14 12:35:21 <mps> minimal: also my first linux was on floppies :)
2020-12-14 12:35:50 <minimal> I'm grey enough that my first Linux was MCC lol
2020-12-14 12:35:57 <Ariadne> ikke: i guess we should first ask conservancy if they are interested, and if so, have a discussion on alpine-devel.  i don't think SFC has taken on anything as large as alpine.
2020-12-14 12:36:10 <mps> yes, mcc
2020-12-14 12:36:58 <Ariadne> ikke: it may be interesting to join forces with debian and use SPI
2020-12-14 12:37:09 <mps> pushed linux-edge 5.10.0 and we will soon have linux-lts 5.10.0 :)
2020-12-14 12:37:22 <Ariadne> given the high amount of cross-pollination between debian and arch, it makes more sense
2020-12-14 12:37:27 <Ariadne> since debian and arch both use SPI
2020-12-14 12:37:28 <ncopa> Ariadne:   1. Generic board-agnostic MIPS kernel (MIPS_GENERIC_KERNEL) (NEW) ?
2020-12-14 12:37:44 <Ariadne> no idea what that is
2020-12-14 12:37:53 <ncopa> on mips64 system type
2020-12-14 12:37:55 <Ariadne> linux-lts targets qemu
2020-12-14 12:37:58 <Ariadne> for mips
2020-12-14 12:38:10 <ncopa> i have to choose a board
2020-12-14 12:38:15 <ikke> What is SPI?
2020-12-14 12:38:20 <minimal> mps: still wrestling with syslinux and the 64bit feature patch......the patch has no effect as syslinux's APKBUILD doesn't appear to actually build much of the software but uses binaries that come in the tarball
2020-12-14 12:38:50 <Ariadne> generic seems fine
2020-12-14 12:38:57 <Ariadne> ikke: Software in the Public Interest, Inc
2020-12-14 12:39:09 <Ariadne> ikke: which is the holding organization for Debian and Arch
2020-12-14 12:39:23 <Ariadne> https://www.spi-inc.org/
2020-12-14 12:40:02 <ncopa> Ariadne: https://tpaste.us/nWrr
2020-12-14 12:40:23 <Ariadne> yes
2020-12-14 12:40:25 <Ariadne> stick with 18
2020-12-14 12:40:29 <Ariadne> for now
2020-12-14 12:41:38 <ncopa>   5. MIPS64 Release 1 (CPU_MIPS64_R1)
2020-12-14 12:41:38 <ncopa> > 6. MIPS64 Release 2 (CPU_MIPS64_R2)
2020-12-14 12:41:38 <ncopa>   7. MIPS64 Release 6 (CPU_MIPS64_R6)
2020-12-14 12:41:38 <ncopa>   8. RM52xx (CPU_NEVADA)
2020-12-14 12:41:38 <ncopa>   9. RM7000 (CPU_RM7000)
2020-12-14 12:41:38 <ncopa> choice[1-9?]:
2020-12-14 12:42:53 <Ariadne> 6
2020-12-14 12:43:17 <Ariadne> R6 is entirely different opcodes
2020-12-14 12:43:27 <ncopa> 👍
2020-12-14 12:44:29 <minimal> anyone know if Jakub Jirutka frequents here and if so what his IRC nick is?
2020-12-14 12:44:38 <mps> minimal: ok, we are not in hurry for this, I think
2020-12-14 12:44:39 <Ariadne> jirutka
2020-12-14 12:44:55 <minimal> thanks
2020-12-14 12:45:25 <mps> iirc, jirutka is banned on irc
2020-12-14 12:45:31 <Ariadne> why
2020-12-14 12:45:34 <Ariadne> wtf
2020-12-14 12:45:58 <Ariadne> oh right, he used to rip on people
2020-12-14 12:46:36 <mps> 'rip'?
2020-12-14 12:49:27 <minimal> oh? I'd sent him an email last week about a couple of his packages and haven't heard back so far and thought I might ping him on IRC in case my email ended up in spam folder
2020-12-14 12:58:44 <artok> damn.. off the qt5 from the edge-aarch46 builder and start doing linux-edge !
2020-12-14 12:58:47 <artok> =)
2020-12-14 12:59:12 <maxice8> good, can't let any rest settle in
2020-12-14 12:59:15 <Ariadne> mps: insult aggressively
2020-12-14 13:00:09 <ikke> minimal: usually he's responsive on gitlab
2020-12-14 13:00:29 <Ariadne> i dont thinkhe was actually banned from irc
2020-12-14 13:00:35 <Ariadne> i think ncopa asked him to take it easy
2020-12-14 13:00:39 <Ariadne> and he left irc (:
2020-12-14 13:00:45 <ikke> yes, twice actually
2020-12-14 13:01:40 <Ariadne> though i think he is doing better now anyway
2020-12-14 13:01:47 <minimal> ikke: for looking to discuss some points around a couple of packages, not as simple as submitting a MR
2020-12-14 13:05:54 <clandmeter> for the record, i dont think jirukta is banned.
2020-12-14 13:06:02 <Ariadne> yes, i dont think so either
2020-12-14 13:06:16 <Ariadne> i think he left voluntarily after being asked to take it easy
2020-12-14 13:08:59 <mps> ah, that's what I expect for myself in some future
2020-12-14 13:11:30 <Ariadne> hmm?
2020-12-14 13:11:41 <Ariadne> i don't think you have to worry
2020-12-14 13:12:06 <Ariadne> the issue in question was new contributors being slammed with crap like "are you retarded?"
2020-12-14 13:12:22 <ikke> nod
2020-12-14 13:12:23 <mps> everyone could write something which could offensive to someone else
2020-12-14 13:12:34 <Ariadne> this stuff was generically offensive
2020-12-14 13:12:53 <Ariadne> you tend to stick to technical points
2020-12-14 13:13:02 <Ariadne> instead of being insulting
2020-12-14 13:13:49 <mps> yes, I tend but who know what tomorrows can 'load' on us
2020-12-14 13:15:38 <mps> and sometimes I don't feel nice when reading something, but I just step back from screen and kbd
2020-12-14 13:15:51 <skarnet> you're a lucky man
2020-12-14 13:15:57 <Ariadne> then you'll be fine (:
2020-12-14 13:16:02 <skarnet> sometimes I do feel nice when reading something
2020-12-14 13:16:10 <skarnet> that's generally not the rule :P
2020-12-14 13:16:14 <mps> keeping in mind that maybe I write something unpleasant to other
2020-12-14 13:16:36 <Ariadne> besides, he was just asked to take it easy
2020-12-14 13:16:43 <Ariadne> he decided that was impossible and walked away
2020-12-14 13:16:44 <artok> is that edge-aarch64 builder stuck?
2020-12-14 13:17:22 <Ariadne> like nothing even resembling a reprimand or anything like that
2020-12-14 13:17:24 <Ariadne> just like
2020-12-14 13:17:29 <Ariadne> "chill out please"
2020-12-14 13:17:44 <artok> I forgot if there is more detailed view of the builder than build.alpinelinux.org
2020-12-14 13:18:07 <Ariadne> qtwebengine
2020-12-14 13:18:09 <Ariadne> is chromium
2020-12-14 13:18:14 <Ariadne> expect that to take many hours
2020-12-14 13:18:26 <artok> oh great
2020-12-14 13:18:37 <artok> mps: send me apk of the kernel =)
2020-12-14 13:19:16 <mps> artok: I only built x86_64 and armhf locally
2020-12-14 13:20:13 <mps> stopped aarch64 because I'm doing that on same machine which is aarch64 alpine builder, to lessen load on it :)
2020-12-14 13:20:52 <mps> aarch64 builder: load average: 64.73, 45.43, 41.33
2020-12-14 13:28:06 <Ariadne> oof :)
2020-12-14 13:36:34 <artok> what is the mkinitfs command run after kernel install?
2020-12-14 13:40:37 <artok> nvm =)
2020-12-14 14:04:48 <Hello71> ikke, Ariadne: qemu supports windows. not sure which things don't work, but should be better than vbox at least
2020-12-14 14:04:53 <maxice8> !11648
2020-12-14 14:05:04 <ikke> Hello71: Can I run qemu on windows?
2020-12-14 14:05:15 <Ariadne> maxice8: ack
2020-12-14 14:05:33 <maxice8> ack == ":shipit:" ?
2020-12-14 14:05:53 <Ariadne> yes
2020-12-14 14:06:03 <maxice8> ight, ty
2020-12-14 14:06:54 <Hello71> ikke: yes. obviously it doesnt use kvm, but there is windows hwaccel support
2020-12-14 14:06:55 <Ariadne> though i cannot test zfcp on mine
2020-12-14 14:07:03 <Ariadne> my machine doesnt support it
2020-12-14 14:07:10 <Ariadne> the alpine builder is newer than mine
2020-12-14 14:07:36 <Hello71> tcg of course works but usually people want hwaccel
2020-12-14 14:07:38 <ikke> Ariadne: you have an s390x container, right?
2020-12-14 14:08:07 <Ariadne> ikke: yes, on the alpine machine.  i also have a whole z13 sitting in my colo now :)
2020-12-14 14:08:20 <Ariadne> my vehicle's suspension will never be the same
2020-12-14 14:08:56 <Hello71> actually I think there is more than one hwaccel for windows?
2020-12-14 14:09:27 <Ariadne> i thik the alpine one is a z14
2020-12-14 14:10:53 <Ariadne> and zfcp requires z15 i believe
2020-12-14 14:11:42 <Ariadne> oh, hmm
2020-12-14 14:11:46 <Ariadne> mine *does* support zfcp
2020-12-14 14:11:53 <Ariadne> interesting
2020-12-14 14:12:02 <Ariadne> i thought it only supported dasd ^_^
2020-12-14 14:21:34 <Ariadne> hmm, writefreely builds fine on s390x for me
2020-12-14 14:21:49 <Ariadne> i guess this 172.16.0.1 stuff is builder network
2020-12-14 14:36:44 <Ariadne> hmm
2020-12-14 14:36:58 <Ariadne> ncopa: can you enable CONFIG_NETFILTER on mips64?  it seems to be missing
2020-12-14 14:38:26 <minimal> I'm tweaking a copy of the syslinux package locally and I'm seeing quite a few of these errors when its building:   error: unknown type name '__uint16_t'; did you mean 'uint16_t'?
2020-12-14 14:39:00 <Ariadne> smells like gcc 10
2020-12-14 14:39:02 <minimal> only seems to happen in the efi subdirectory, the rest of the code uses uint16_t (without the leading underscores).
2020-12-14 14:39:47 <maxice8> as far as I'm aware __uint16_t is an internal type and applications should use uint16_t
2020-12-14 14:40:05 <minimal> uint16_t is defined in stdlib.h, not sure where its expecting __uint16_t to come from
2020-12-14 14:40:18 <dalias> yes the __ one is wrong
2020-12-14 14:40:27 <dalias> just patch it
2020-12-14 14:41:27 <minimal> I found this as syslinux package currently only builds the syslinux installer, not the rest of syslinux, doh!
2020-12-14 14:42:00 <minimal> dalias: yeah was thinking simplest way was to patch the 1 file. Ok, I'll try that
2020-12-14 15:06:56 <ikke> iperf is now failing on 32-bits arches, time_t related
2020-12-14 15:11:17 <ikke> "error: cannot convert 'long int*' to 'const time_t*' {aka 'const long long int*'}"
2020-12-14 15:15:38 <maxice8> Opinions on https://gitlab.alpinelinux.org/alpine/aports/-/issues/12033 ?
2020-12-14 15:15:51 <maxice8> Specifically about enforcing installation of license files to the -doc subpkg if the license contain copyright headers
2020-12-14 15:16:06 <maxice8> ^ This is how Void Linux does it (sort of)
2020-12-14 15:21:07 <ncopa> Ariadne: sure thing
2020-12-14 15:21:58 <ikke> Ariadne: 172.16.0.0/16 is indeed internal network
2020-12-14 15:22:00 <ncopa> dalias: im configuring 5.10 kernel. There is this config option: Provide system calls for 32-bit time_t (COMPAT_32BIT_TIME)
2020-12-14 15:22:02 <ikke> dmvpn/openvpn
2020-12-14 15:22:21 <ncopa> i suppose there are no reason to provide any 32 bit syscall for kernel?
2020-12-14 15:23:08 <mps> ncopa: enable it
2020-12-14 15:23:16 <mps> it is needed
2020-12-14 15:24:01 <mps> dalias explained that few months ago here
2020-12-14 15:24:06 <ncopa> ok?
2020-12-14 15:24:55 <ncopa> why is it needed when our userspace does 64 bit time_t?
2020-12-14 15:24:57 <mps> you can look what is in linux-edge 5.10.0
2020-12-14 15:25:35 <mps> I can't remember exactly
2020-12-14 15:25:45 <artok> CONFIG_RESET_RASPBERRYPI
2020-12-14 15:25:55 <ncopa> i dont find linux-edge very useful since it differs so much
2020-12-14 15:25:55 <mps> dalias can explain this better than me
2020-12-14 15:26:12 <ncopa> COMPAT_32BIT_TIME is default off
2020-12-14 15:26:28 <mps> hmm
2020-12-14 15:26:59 <ikke> CI is kind of busy
2020-12-14 15:27:01 <ikke> 45 jobs pending
2020-12-14 15:27:46 <ikke> wasn't qt-5 already mergeD?
2020-12-14 15:28:04 <mps> I remember that I talked with dalias and maybe also someone else (nsz on #musl?) about this
2020-12-14 15:28:16 <ikke> yes
2020-12-14 15:29:23 <maxice8> qt5 was merged already
2020-12-14 15:29:32 <ikke> there was still one job running (5h)
2020-12-14 15:32:28 <mps> ncopa: 'make defconfig' on aarch64 set 'ONFIG_COMPAT_32BIT_TIME=y'
2020-12-14 15:33:13 <maxice8> !14996 should be good to go
2020-12-14 15:33:59 <mps> if we upgrading bleeding edge kernel why not mesa also ;)
2020-12-14 15:34:23 <maxice8> a mesa-lts and a mesa-edge ?
2020-12-14 15:34:38 <mps> hehe
2020-12-14 15:35:42 <ikke> https://git.alpinelinux.org/aports/commit/?id=3e2e759e8b3a
2020-12-14 15:35:55 <ikke> no context :(
2020-12-14 15:37:03 <ikke> Does this look correct? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15805
2020-12-14 15:37:05 <ikke> fix for iperf
2020-12-14 15:37:46 <ncopa> ugh. yeah. the commit message for busybox sendmail should have an explanation on why it was re-enabled
2020-12-14 15:38:09 <ncopa> ikke: it looks correct to me
2020-12-14 15:40:04 <ikke> ncopa: thanks
2020-12-14 15:43:12 <dalias> COMPAT_32BIT_TIME absolutely must be y (on)
2020-12-14 15:43:40 <ncopa> ok, thanks
2020-12-14 15:43:52 <dalias> off is violating the dobt break userspace rule
2020-12-14 15:44:18 <dalias> this option is highly misdocumented and was added as a bait and switch
2020-12-14 15:44:44 <dalias> it was proposed as a hidden kernel hacking option for catching time32 use
2020-12-14 15:44:59 <dalias> not as something permissible on a production kernel
2020-12-14 15:45:00 <ncopa> they are trickign users to get rid of the 32bit time32 userspace?
2020-12-14 15:45:08 <dalias> no
2020-12-14 15:45:56 <dalias> but theyre risking kernels tgat cant run existing binaries or musl
2020-12-14 15:46:33 <dalias> even if musl didnt use the oldest syscall suitable for an operation and thus didnt break with this option..
2020-12-14 15:46:51 <dalias> .. flipping it to n would break all the users existing binaries
2020-12-14 15:47:07 <dalias> its a complete violation of kernel policy
2020-12-14 15:53:50 <dalias> there's not a goal to trick users
2020-12-14 15:54:24 <dalias> rather the goal was to have glibc and musl always use the new syscalls and drop use of the old ones, rather than using the one that's appropriate for the situation
2020-12-14 15:55:14 <dalias> (for example there's absolutely no reason to use a time64 syscall and go through fallback dances for old kernels when you're passing NULL as the timeout because the syscall is one where a timeout is an obscure usage not relevant to the call point)
2020-12-14 15:55:18 <ncopa> makes sense
2020-12-14 15:56:02 <dalias> anyway my vision for musl has always been that we would use the old syscalls unless the value doesn't fit (or for ones that read back times, isn't known to fit a priori) in 32 bits
2020-12-14 16:03:48 <mps> dalias: thanks, I knew that you will explain this :)
2020-12-14 16:04:45 <ncopa> thanks
2020-12-14 16:06:50 <mps> now I should move liburing and exfatprogs from testing, not sure main or community?
2020-12-14 16:07:23 <mps> ncopa: ^
2020-12-14 16:11:29 <mps> and what to do with exfat-utils? keep or remove from repo?
2020-12-14 16:20:52 <ncopa> um, whats the diff?
2020-12-14 16:20:58 <ncopa> i suppose move from testing to community
2020-12-14 16:21:16 <ncopa> unless you think we should include those on the release media
2020-12-14 16:21:30 <mps> exfat-utils is for old exfat in 5.4
2020-12-14 16:21:52 <ncopa> i think we should keep it
2020-12-14 16:22:15 <mps> exfatprogs is for new exfat driver for kernels after 5.4, forgot exact version
2020-12-14 16:22:48 <ncopa> its it tools for like creating exfat filesystems and such?
2020-12-14 16:22:56 <mps> well, I'm not sure we need these on release media
2020-12-14 16:23:06 <mps> yes
2020-12-14 16:23:19 <ncopa> why would kernel version matter at all?
2020-12-14 16:23:31 <ncopa> if you mkfs.exfat a file image
2020-12-14 16:23:46 <ncopa> kernel version should not matter
2020-12-14 16:23:49 <mps> these tools will make confusion for users because they do similar but not same things
2020-12-14 16:23:56 <mps> it does
2020-12-14 16:24:11 <mps> old exfat driver is different from new one
2020-12-14 16:24:20 <maxice8> Cogitri: modify aports-qa-bot to comment obama meme whenever someone approves their own MR
2020-12-14 16:24:42 <ncopa> so an exfat file system created with old kernel will not be usable by new kernel? makes no sense
2020-12-14 16:24:58 <mps> hmm
2020-12-14 16:25:04 <mps> not so
2020-12-14 16:25:34 <mps> for new driver old utils will not works properly
2020-12-14 16:25:56 <ncopa> looks like its the same thing
2020-12-14 16:26:01 <ncopa> just newer version
2020-12-14 16:26:03 <ncopa> https://www.phoronix.com/scan.php?page=news_item&px=Exfatprogs-Released
2020-12-14 16:26:15 <mps> old driver is from microsoft iirc, and new one is from samsung, so they are different
2020-12-14 16:26:16 <ncopa> looks like they renamed exfat-utils to exfatprogs
2020-12-14 16:26:35 <mps> no, not same
2020-12-14 16:26:53 <ncopa> so are there like a microsoft exfat and a samsung exfat?
2020-12-14 16:26:59 <mps> yes
2020-12-14 16:27:02 <ncopa> which are incompatible?
2020-12-14 16:27:15 <ncopa> that sounds too stupid to be true
2020-12-14 16:27:21 <mps> well, different I would say
2020-12-14 16:27:31 <ncopa> if you create exfat usb on windows it cannot be read by samsung and vice versa?
2020-12-14 16:27:48 <mps> huh no :)
2020-12-14 16:28:04 <ikke> wasn't the ms driver used just a short time period?
2020-12-14 16:28:05 <ncopa> isnt exfat like  a standard?
2020-12-14 16:28:25 <mps> I can't explain in details because I'm not MS develepor nor samsung :)
2020-12-14 16:28:50 <mps> but I know we don't need old exfat-utils
2020-12-14 16:29:04 <mps> if we ship kernel 5.10
2020-12-14 16:29:18 <ncopa> from https://www.phoronix.com/scan.php?page=news_item&px=Exfatprogs-Released it sounds like its the same project but project got renamed.
2020-12-14 16:29:33 <mps> hmm
2020-12-14 16:30:16 <mps> https://github.com/exfatprogs/exfatprogs
2020-12-14 16:30:22 <ikke> https://lwn.net/Articles/797963/
2020-12-14 16:30:46 <ncopa> "Rename project name to exfatprogs." https://lore.kernel.org/lkml/004701d6194c$0d238990$276a9cb0$@samsung.com/
2020-12-14 16:31:11 <ncopa> so exfatprogs is a newer version of exfat-utils, which means that we no longer need exfat-utils
2020-12-14 16:31:55 <mps> heh, I like when BDFL use simple words :)
2020-12-14 16:32:12 <mps> in short, that
2020-12-14 16:32:17 <ncopa> you got me a bit confused there :)
2020-12-14 16:32:45 <ncopa> Ariadne: we have a config-lts.mips config
2020-12-14 16:32:53 <ncopa> can i delete it?
2020-12-14 16:32:54 <mps> sorry, as you know it is not easy for me to express myself in english
2020-12-14 16:33:15 <ncopa> mps: no worries. thank you for being patient with me :)
2020-12-14 16:33:29 <mps> and vice versa :)
2020-12-14 16:35:36 <ikke> ah, the initial version that was imported into linux was an older version
2020-12-14 16:36:33 <mps> ikke: yes
2020-12-14 16:41:19 <minimal> exfat is in theory an "industry standard" however as Microsoft invented and had some patents on it they charged companies (i.e. digital camera makers) to use it, so it never really took off. Samsung's original driver was (from memory) based on some code they'd licensed from Microsoft and accidently released
2020-12-14 16:45:22 <ikke> Didn't microsoft get samsung to pay for each phone they sold due to this?
2020-12-14 16:47:05 <ncopa> i remember the issue with microsoft claiming to have 250 patents in linux or what it was
2020-12-14 16:47:35 <ncopa> i thought it was very shady
2020-12-14 16:49:31 <ncopa> MS: "you have 250 things you borrow from us. no you have to pay rent for those".  community: "oh, ok, sorry we didnt know. please let us know what your 250 things are so we can return them to you". MS: "we won't tell you, as it is not our business model. now pay!"
2020-12-14 16:51:02 <skarnet> ncopa: is it really how it went down? because it's a pretty damning admission that their business model is being patent trolls :P
2020-12-14 16:51:18 <ncopa> thats how i remember it
2020-12-14 16:51:31 <awilfox> no idea where to properly report this (as I don't know if it's a bug in the git server or if it's a bug in the packaging) but acf packages seem to have dead links for url
2020-12-14 16:51:41 <awilfox> as in: https://pkgs.alpinelinux.org/package/v3.12/main/ppc64le/acf-dhcp links to  	https://git.alpinelinux.org/cgit/acf/acf-dhcp
2020-12-14 16:51:54 <awilfox> and there are no acf repos on git.alpinelinux.org that I can find any more
2020-12-14 16:52:01 <awilfox> idk where they even went, but they aren't there
2020-12-14 16:52:10 <ikke> awilfox: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13809
2020-12-14 16:52:44 <maxice8> There is an open MR for fixing those, just nobody got around to checking-n-merging it
2020-12-14 16:52:45 <awilfox> ah.
2020-12-14 16:53:00 <mps> I didn't followed this much but afaik samsung driver is developed separately following specification and backed by samsung, and long time proposed to inclusion in kernel but didn't included till this patent/license issue isn't resolved
2020-12-14 16:53:01 <ikke> maxice8: ttrask is looking at it
2020-12-14 16:53:07 <maxice8> nice
2020-12-14 16:53:46 <awilfox> thanks ikke, maxice8
2020-12-14 16:55:31 <mps> btw, also 'new' ntfs from paragon is in queue for inclusion in kernel
2020-12-14 16:55:47 <mps> ntfs drive
2020-12-14 16:55:51 <mps> uh
2020-12-14 16:56:01 <mps> ntfs driver*
2020-12-14 16:56:51 <minimal> ikke: yupe I seem to remember a story that Microsoft made a lot of money from Android phone vendors due to licensing fees for the exfat driver
2020-12-14 16:58:14 <minimal> think with Microsoft joining the OIN the exfar patents are no longer an issue
2020-12-14 16:59:59 <mps> minimal: 'exfar' or 'unfar' (unfair) :D
2020-12-14 17:03:41 <minimal> having a Monty Python flashback, "I exfart in your general direction!"
2020-12-14 17:16:58 <ncopa> tmhoang: a question about s390x kernel config. default is CONFIG_MARCH_Z196=y CONFIG_MARCH_Z196_TUNE=y
2020-12-14 17:17:22 <ncopa> but afaik we dont run alpine on z196?
2020-12-14 17:17:47 <ncopa> wouldnt it make more sense to pick z13  and tune for z14 or similar?
2020-12-14 17:29:25 <ikke> Cogitri: ldc is segfaulting during tests
2020-12-14 17:29:32 <ikke> 50% tests passed, 794 tests failed out of 1604
2020-12-14 17:29:34 <Cogitri> Yup, looking into it
2020-12-14 17:29:37 <ikke> k
2020-12-14 17:29:53 <Cogitri> Seems like the latest version of the MR broke it
2020-12-14 17:42:02 <ncopa> i think im ready with the kernel configs. will just do another rebuild and then i'll push 5.10 kernel
2020-12-14 17:42:21 <ncopa> this is pretty nice. we get rid of 3 3rd party modules
2020-12-14 17:42:26 <ikke> \o//
2020-12-14 17:42:33 <ikke> including rtl8821ce?
2020-12-14 17:42:42 <ncopa> looks like not
2020-12-14 17:42:45 <ikke> hmm
2020-12-14 17:42:51 <ikke> Oh, mps thought it was included
2020-12-14 17:43:05 <mps> yes, it is iirc
2020-12-14 17:43:14 <ncopa> there is an rtl8821something module, but i cound not find it in the config
2020-12-14 17:43:16 <mps> look at linux-edge config
2020-12-14 17:43:47 <ncopa> config-edge.aarch64:CONFIG_RTL8821AE=m
2020-12-14 17:43:47 <ncopa> config-edge.x86_64:CONFIG_RTL8821AE=m
2020-12-14 17:43:57 <ncopa> it has AE module, not CE
2020-12-14 17:44:03 <ncopa> i dont know if it makes any idfference
2020-12-14 17:44:31 <mps> (nowatCONFIG_RTL8192CE=m
2020-12-14 17:44:42 <mps> uh
2020-12-14 17:44:52 <ikke> 8821
2020-12-14 17:46:06 <ncopa> https://bbs.archlinux.org/viewtopic.php?id=259945
2020-12-14 17:46:09 <ikke> https://github.com/torvalds/linux/tree/master/drivers/net/wireless/realtek/rtlwifi
2020-12-14 17:46:26 <maxice8> ikke: Can you take a quick look at !14180 !14181 !14182 !14183 ?
2020-12-14 17:46:55 <ncopa> did we revert back to the fat format of tzdata?
2020-12-14 17:47:02 <ikke> ncopa: yes
2020-12-14 17:47:27 <ikke> maxice8: apart from that, I don't really know alot about it
2020-12-14 17:48:03 <mps> switdrivers/net/wireless/realtek/rtw88/Kconfig:     tristate "Realtek 8821CE PCI wireless network adapter"
2020-12-14 17:48:24 <mps> drivers/net/wireless/realtek/rtw88/Kconfig:     tristate "Realtek 8821CE PCI wireless network adapter"
2020-12-14 17:48:31 <mps> ikke: is it that one
2020-12-14 17:48:52 <ncopa> https://bbs.archlinux.org/viewtopic.php?id=259945 claims that kernel 5.9 has support for it but users report that it does not work
2020-12-14 17:48:59 <ikke> yes, same as what is talked about in that post that ncopa linked to
2020-12-14 17:49:41 <ikke> https://github.com/torvalds/linux/blob/master/drivers/net/wireless/realtek/rtw88/rtw8821ce.c
2020-12-14 17:49:47 <ikke> that is rtw
2020-12-14 17:50:02 <ncopa> hum
2020-12-14 17:50:02 <maxice8> almost half of ldc tests segfaulted
2020-12-14 17:50:05 <ikke> not sure if there is a difference
2020-12-14 17:50:10 <ncopa> ok. i
2020-12-14 17:50:12 <ikke> maxice8: yes, cogitri is aware
2020-12-14 17:50:36 <ncopa> i'd like to delete the rtl8821ce driver and see what happens
2020-12-14 17:50:42 <mps> ikke: didn't know that there are two, wireless and ethernet, sorry
2020-12-14 17:50:48 <ncopa> if someone compains i can add it back
2020-12-14 17:50:56 <ikke> ncopa: fine with me
2020-12-14 17:51:27 <ncopa> but not today. maybe tomorrow
2020-12-14 17:51:56 <ncopa> but actually, i dont think it hurt to have it there
2020-12-14 17:52:24 <Cogitri> ikke: Do you have the ip of my aarch64 runner handy? I forgot to add it to my ssh config on my laptop 😅
2020-12-14 17:52:55 <mps> ikke: pkgdesc="Wifi drivers for Realtek 8821ce" for community/rtl8821ce-lts
2020-12-14 17:52:59 <ikke> Cogitri: pm'ed it to you
2020-12-14 17:53:07 <mps> so not ethernet
2020-12-14 17:53:07 <Cogitri> Thanks 👍️
2020-12-14 17:58:18 <ikke> mps: I'm confused a bit, because the driver was originally called rtl8821ce, but it seems they renamed it to tw8821ce in-tree
2020-12-14 17:58:24 <ikke> rtw*
2020-12-14 17:58:46 <mps> yes also I'm till looked now in https://github.com/tomaspinho/rtl8821ce/tree/master/core
2020-12-14 17:58:52 <mps> :)
2020-12-14 18:04:26 <mps> ikke: you remember url of video how upstream makes packagers (distro) life 'interesting' :)
2020-12-14 18:04:35 <mps> but I lost url
2020-12-14 18:06:01 <ikke> let me see
2020-12-14 18:07:06 <mps> no, not needed. I just wanted to remind you
2020-12-14 18:07:57 <ikke> But now I want to know :P
2020-12-14 18:10:18 <ikke> meh, cannot find :(
2020-12-14 18:15:48 <mps> https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/
2020-12-14 18:17:31 <ikke> ah, nice, thanks
2020-12-14 18:17:32 <mps> also video http://mirroronet.pl/pub/mirrors/video.fosdem.org/2018/K.3.201/how_to_make_package_managers_cry.mp4
2020-12-14 18:50:17 <maxice8> ncopa: !14218 chromium
2020-12-14 18:59:17 <Cogitri> wtf ldc just works on my aarch64 container
2020-12-14 19:00:10 <Cogitri> Uhhh
2020-12-14 19:00:12 <Cogitri> algitbot: retry master
2020-12-14 19:00:17 <Cogitri> Maybe it just needs another go :D
2020-12-14 19:41:30 <ikke> nope
2020-12-14 19:46:15 <omni> busybox 1.32.0-r7 -> 1.32.0.r8 "stat: can't stat 'usr/sbin/sendmail': No such file or directory"
2020-12-14 19:46:46 <omni> I see the commit message, but does it need to throw an error?
2020-12-14 20:10:24 <maxice8> mps: answered about the licensing
2020-12-14 20:10:50 <maxice8> More opinons on https://gitlab.alpinelinux.org/alpine/aports/-/issues/12033 ?
2020-12-14 20:16:05 <mps> maxice8: right, that is why I wrote that putting it in -doc is useless
2020-12-14 20:16:28 <maxice8> ?
2020-12-14 20:17:04 <mps> i don't install -doc subpkg so I don't have license
2020-12-14 20:17:59 <maxice8> yeah but now we shift from "there is no way to get the license, it isn't in the mainpkg or any subpackage" to "it is trivial to get the license, just install our -doc or -license subpkg"
2020-12-14 20:18:10 <mps> if we follow proposal then license should be installed in 'main' pkg
2020-12-14 20:18:59 <mps> imo current state is ok
2020-12-14 20:21:47 <maxice8> Think it should be in -doc
2020-12-14 20:51:11 <ncopa> im push linux-lts-5.10 now
2020-12-14 20:51:37 <maxice8> nice
2020-12-14 20:57:01 <omni> 
ACTION excites excitement

2020-12-14 20:57:15 <tehcloud> does this mean 5.10 is getting into 3.13?
2020-12-14 21:00:52 <maxice8> yes
2020-12-14 21:01:03 <tehcloud> niiiiice
2020-12-14 21:01:04 <maxice8> 3.13 isn't branched off yet, anything that goes into master branch is going into 3.13
2020-12-14 21:01:07 <maxice8> until 3.13-stable is created
2020-12-14 21:08:11 <mps> ncopa: you declined my proposal for kernel 5.10 in 3.13 and now you added it. I feel 'strange' about that
2020-12-14 21:09:05 <ikke> mps: I think ncopa expected 3.13 to be tagged already
2020-12-14 22:17:32 <mps> heh, https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.1
2020-12-14 22:18:08 <ikke> Hmm, I wonder what happened
2020-12-14 22:18:31 <ikke> "It causes problems :("
2020-12-14 22:18:35 <mps> dm-raid problem
2020-12-14 22:18:37 <ikke> sounds like someone had a bad day
2020-12-14 22:19:03 <mps> i hope our kernels are not still built :)
2020-12-14 22:23:53 <maxice8> doubt it, merged plasma-framework
2020-12-14 22:24:47 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12191
2020-12-14 22:28:32 <mps> pushed linux-edge 5.10.1
2020-12-14 22:29:02 <mps> will the 5.10.0 be 'retired' on builders then?
2020-12-14 22:30:05 <maxice8> linux-edge has been built already, linux-lts not on some arches
2020-12-14 22:31:42 <mps> linux-edge for armv7 wasn't on mirrors (cdn) about half hour ago
2020-12-14 22:33:09 <mps> that is why I don't like to upgrade linux-edge in aport till it 'get' x.x.1 version
2020-12-14 22:33:33 <mps> but today was 'hype' day :)
2020-12-14 22:48:52 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13847
2020-12-14 22:49:02 <maxice8> Ikke: please enable collaboration ^
2020-12-14 22:50:09 <ikke> hm, shouldn't aports-qa-bot do that?
2020-12-14 22:50:37 <Cogitri> It only does it for new MRs
2020-12-14 22:50:42 <maxice8> it should but that MR is old
2020-12-14 22:50:49 <ikke> ah, ok
2020-12-14 22:50:57 <ikke> done
2020-12-14 22:51:02 <maxice8> ty
2020-12-14 22:56:56 <ikke> rust is still not building on arm :(
2020-12-15 01:44:13 <Ariadne> ncopa: for now, leave it if you can.  if you deleted it, its fine too.  it is just 32-bit version of .mips64 config.
2020-12-15 05:54:28 <Ariadne> thinking about this a little more, i think what makes most sense is to form an alpine foundation as a societas cooperative europaea (which is actually really easy to do)
2020-12-15 07:02:26 <ncopa> good morning
2020-12-15 07:03:00 <Cogitri> Morning
2020-12-15 07:03:36 <ncopa> mps: i declined to switch to 5.10 release candidates because i expected the 3.13 release to come out earlier and the 5.10 later. there was too much uncertain at that point
2020-12-15 07:04:45 <ncopa> yesterday i tested the 5.10 release and there were fewer problems than expected, and I though the benefits would outweight the downsides
2020-12-15 07:08:00 <Ariadne> i don't think 5.10.1 is a huge problem
2020-12-15 07:09:04 <ncopa> dmraid fixes looks a bit scary. im not gonna reboot til i have updated to 5.10.1 :)
2020-12-15 07:09:39 <ncopa> one thing i noticed is that my testboot.sh script runs significantly slower with 5.10 kernel
2020-12-15 07:10:13 <ncopa> i think it might be modloop generation or maybe update-kernel
2020-12-15 07:10:15 <ncopa> i wonder why
2020-12-15 07:10:46 <ncopa> its from 30ish seconds to 10mins
2020-12-15 07:43:25 <ikke> ouch
2020-12-15 08:08:00 <Ariadne> weird
2020-12-15 08:38:55 <ncopa> i think its the update-kernel script
2020-12-15 08:41:15 <ncopa> looks like it is  `cp -a /tmp/update-kernel.PJiDJg/root/lib/modules /tmp/update-kernel.PJiDJg/modloop` that is insanely slow in fakeroot
2020-12-15 08:43:28 <ncopa> rm -fr /tmp/update-kernel.PJiDJg also slow
2020-12-15 08:45:44 <ncopa> im pretty sure that it is fakeroot that makes things dog slow
2020-12-15 08:52:05 <ncopa> Ariadne: i wonder if this might be related: 06bddd1a83b6ceee01690a1b5ea5dc5ec6cfd0d3 how is tcp as IPC more crosscompile friendly?
2020-12-15 08:56:13 <mps> ncopa: I have impression that you made decision to upgrade kernel because 'of hype' and that makes me feel somewhat uncomfortable about base things in alpine, and 'process' of alpine development
2020-12-15 08:59:29 <ncopa> it was more about being able to maintain the kernel for 2 more years. it will be increasingly hard to maintain 5.4 kernel
2020-12-15 08:59:52 <ncopa> also upgrading to 5.10 allows us to drop a few 3rd party modules like wireguard
2020-12-15 09:01:28 <mps> if you remember these were my arguments to upgrade a month/s ago
2020-12-15 09:01:55 <mps> but it doesn't matter now
2020-12-15 09:01:56 <ncopa> i also expected the 3rd party modules we have (jool, dahdi, xtables-addons ++) to create more problems than it did
2020-12-15 09:02:20 <ncopa> in the past the 3rd party modules has been a significant amount of work with new kernel
2020-12-15 09:02:31 <mps> yes
2020-12-15 09:02:53 <ncopa> in this case they all worked out of the box or could be deleted, with the exception of dahdi
2020-12-15 09:02:57 <mps> and I'm thinking we don't need such modules
2020-12-15 09:03:29 <mps> better option will be to work on something like dkms
2020-12-15 09:04:03 <ncopa> and after working on dahdi for a few minutes, i concluded that it is not too much work to get it working
2020-12-15 09:04:31 <ncopa> all those things would have been different at the time you suggested it
2020-12-15 09:04:52 <ncopa> also it was no guarantees that the 5.10 kernel would be released
2020-12-15 09:05:03 <ncopa> there have traditionally been more -rc releases
2020-12-15 09:05:11 <Ariadne> ncopa: the autoconf macros without --with-ipc=tcp fail to work when cross compiling
2020-12-15 09:05:12 <mps> heh, not much, but nevermind
2020-12-15 09:05:29 <Ariadne> ncopa: one option may be to use --with-ipc=tcp in cross mode
2020-12-15 09:06:27 <Ariadne> ncopa: and not when not crosscompiling
2020-12-15 09:06:31 <ncopa> will they fail in fakeroot built with --with-ipc=sysv or will the fakeroot build itself fail?
2020-12-15 09:06:38 <Ariadne> the build itself fails
2020-12-15 09:06:45 <Ariadne> becaue the configure script
2020-12-15 09:06:50 <Ariadne> wants to run a program
2020-12-15 09:06:54 <Ariadne> to verify sysv ipc actually works
2020-12-15 09:07:16 <ncopa> right, so if sysv ipc does not work on building machine it will fail
2020-12-15 09:07:22 <mps> some time ago I proposed making alpine releases around equinoxes, a lot of upstream likes to release things at the of the world^Wyear and we will have enough time for fixing their 'shiny' software
2020-12-15 09:07:26 <Ariadne> ncopa: no
2020-12-15 09:07:54 <Ariadne> ncopa: the problem is, autoconf detects rightly that it is a cross build and thus the test program cannot run
2020-12-15 09:07:58 <Ariadne> ncopa: and then fails it
2020-12-15 09:08:08 <mps> s/at the/at the end/
2020-12-15 09:08:08 <alpine-meetbot> mps meant to say: some time ago I proposed making alpine releases around equinoxes, a lot of upstream likes to release things at the end of the world^Wyear and we will have enough time for fixing their 'shiny' software
2020-12-15 09:09:08 <ncopa> Ariadne: i wonder if it would be better to try fix the configure script
2020-12-15 09:09:43 <Ariadne> possibly.  i didn't have time to look at it when i cross-enabled fakeroot, because i was trying to get bootstrap working again (so i could try to start fixing rust cross builds)
2020-12-15 09:09:54 <ncopa> or simply remove the test and just use whatever --with-ipc specified
2020-12-15 09:09:58 <Ariadne> or rather, fixed fakeroot cross builds
2020-12-15 09:10:02 <Ariadne> yes, that sounds agreeable
2020-12-15 09:10:30 <ncopa> i just need to test that sysv ipc makes difference
2020-12-15 09:10:35 <mps> also, my opinion about this someone who 'sell' alpine, I don't care if it sell it for 1 or million and don't care it uses alpine name and logo
2020-12-15 09:11:11 <ncopa> mps: what do you mean with  "releases around equinoxes"?
2020-12-15 09:11:54 <mps> end of march and september
2020-12-15 09:12:12 <ncopa> rather than May and November?
2020-12-15 09:12:24 <mps> yes
2020-12-15 09:13:06 <ncopa> May and november was picked because glib/gtk/gnome/ubuntu does releases April and October, and IIRC also openbsd does
2020-12-15 09:13:27 <ncopa> so upstream should have the releases done around that time
2020-12-15 09:13:57 <ncopa> i also think other upstream projects may aim for ubuntu releases
2020-12-15 09:14:30 <ncopa> if we did March/Sept we'd always ship right before new upstream releases
2020-12-15 09:14:43 <mps> I know that there isn't 'perfect' time to release but my 'impression' is that much software is released at the end of year
2020-12-15 09:15:19 <ncopa> we shouldnt do the release in Dec. we are late. we should have shipped it in Now
2020-12-15 09:15:39 <ncopa> do you have example of upstream that ships at the end of year?
2020-12-15 09:16:11 <mps> linux lts :)
2020-12-15 09:16:29 <ncopa> linux lts has been unpredictable in the past
2020-12-15 09:16:50 <ncopa> they have traditionally not announced lts until after the release happened
2020-12-15 09:17:11 <mps> no, GKH will make lts kernel of one which is last release on the year
2020-12-15 09:17:53 <ncopa> do you have any documentation or reference for that?
2020-12-15 09:18:05 <Ariadne> yes, 3.13 release cycle has been longer than normal, due to GCC 10 and musl 1.2 costs
2020-12-15 09:18:17 <Ariadne> however, both of those were important to do
2020-12-15 09:18:18 <mps> I had it somewhere, but can't find right now
2020-12-15 09:18:24 <Ariadne> so i don't think it is a big deal
2020-12-15 09:18:29 <ncopa> i have the impression that the November releases have always been late
2020-12-15 09:18:55 <Ariadne> my opinion there is that a rigid release schedule is not really beneficial
2020-12-15 09:19:11 <mps> but yes, nothing is 100% predictable, maybe not even 50%
2020-12-15 09:19:25 <mps> Ariadne: I agree
2020-12-15 09:19:52 <Ariadne> i rather ship when *done* and make sure a new branch counts for something
2020-12-15 09:19:58 <mps> personally I think 'when it is in good shape' then release it
2020-12-15 09:20:21 <ncopa> whoaaaaa..... --with-ipc=sysv is just ...
2020-12-15 09:20:26 <Ariadne> rigid release schedule means we avoid making changes
2020-12-15 09:20:57 <ncopa> 1-2 seconds instead of minutes
2020-12-15 09:21:29 <ncopa> i think aiming for 2 releases a year, May and November is pretty good
2020-12-15 09:21:33 <Ariadne> i think its possible to do fakeroot better with seccomp anyway
2020-12-15 09:21:49 <Ariadne> ncopa: yes, agreed, but if there is delay, there is delay.  not end of world
2020-12-15 09:21:49 <ncopa> i'd like to drop fakeroot if possible
2020-12-15 09:21:54 <ncopa> yeah
2020-12-15 09:22:14 <Ariadne> if you want more predictability, there are options available for that
2020-12-15 09:22:29 <ncopa> and i think you are right about the reasons re musl 1.2 and gcc10
2020-12-15 09:22:40 <ncopa> those have been pretty time consuming
2020-12-15 09:22:45 <mps> debian started to make 'pseudo' as replacement but doesn't look finished yet
2020-12-15 09:22:46 <ncopa> and we also have rust issues
2020-12-15 09:23:08 <Ariadne> rust bootstrap will have to be kicked until 3.14
2020-12-15 09:23:11 <ncopa> Ariadne is there a simple way to test the cross compile of fakeroot?
2020-12-15 09:23:21 <Ariadne> run bootstrap.sh :P
2020-12-15 09:23:37 <ncopa> ok. i thikn there are other broken things there
2020-12-15 09:23:43 <ncopa> which we should fix
2020-12-15 09:24:03 <mps> ncopa: and don't worry about my complains, managing and making decisions about distro is not easy, I know
2020-12-15 09:24:08 <Ariadne> hmm
2020-12-15 09:24:38 <ncopa> mps: i know. there will always be trade offs
2020-12-15 09:24:39 <Ariadne> mps: i think your feedback is valuable.  sometimes it is good to be more conservative
2020-12-15 09:24:57 <Ariadne> and with 3.13, we've gotten a lot done
2020-12-15 09:25:22 <ncopa> reminds me
2020-12-15 09:25:25 <Ariadne> gcc 10, musl 1.2 with active testing of the next musl 1.2.2 release, ifupdown-ng, ...
2020-12-15 09:25:42 <ncopa> we switched back to fat format for tzdata, but did we do that for edge as well?
2020-12-15 09:25:46 <Ariadne> yes
2020-12-15 09:25:50 <ncopa> i wonder if we can use the new format for edge
2020-12-15 09:25:54 <Ariadne> that however is fixed
2020-12-15 09:25:58 <Ariadne> we can use new format
2020-12-15 09:26:13 <ncopa> better to do that before new stable branch
2020-12-15 09:26:57 <mps> ncopa: I think it would be nice to upgrade linux-headers
2020-12-15 09:27:20 <Ariadne> the fact that some person is selling alpine 3.11.3 with CVEs in the image for $2500 yearly on AWS really grinds my gears though
2020-12-15 09:27:26 <Ariadne> we need to fix that for 3.14 :P
2020-12-15 09:28:16 <ncopa> mps: we will do but it will have more significance for the build than for the runtime, and i dont think its a good idea to do that buildtime changes this late in release process
2020-12-15 09:28:53 <Ariadne> we don't necessarily want programs using 5.10 kernel features yet too
2020-12-15 09:29:34 <ncopa> but we should upgrade linux-headers early after 3.13 release
2020-12-15 09:30:27 <ncopa> ok, i pushed 5.10.1
2020-12-15 09:30:44 <ncopa> i'll fix the fakeroot thingy later
2020-12-15 09:30:56 <ncopa> i simply reverted back to ipc
2020-12-15 09:31:01 <ncopa> for now
2020-12-15 09:32:45 <ncopa> Ariadne: btw. i am all for alpine cloud images. thank you for taking the initiative
2020-12-15 09:33:03 <Ariadne> i have fakeroot fix actually.
2020-12-15 09:33:12 <ncopa> last months i have also been missing a fast way to get alpine vms locally
2020-12-15 09:33:43 <ncopa> "give me a new alpine vm. here is my ssh key"
2020-12-15 09:34:03 <ncopa> i know there are scripts to generate vm images
2020-12-15 09:34:16 <ncopa> but maybe we should ship a vm image
2020-12-15 09:35:54 <Ariadne> the images in question we upload into the actual clouds themselves
2020-12-15 09:36:04 <Ariadne> mcrute can elaborate
2020-12-15 09:36:27 <Ariadne> he started the community AMI project after discovering the $2500/year image on AWS marketplace
2020-12-15 09:39:26 <mps> btw, firefox doesn't crash on my box at time of morning coffee after rebuilt it without dbus, wifi, pipeware and libpulse
2020-12-15 09:42:36 <[[sroracle]]> note that i am already working on a fakeroot replacement using pure seccomp. it's still very early in development though
2020-12-15 09:43:05 <ncopa> i regret that i didnt do a $3000/year image of alpine myself :)
2020-12-15 09:43:41 <Ariadne> ncopa: me too
2020-12-15 09:44:20 <Ariadne> ncopa: as i said elsewhere, i'm clearly in the wrong business, i should just make EC2 images and charge obscene prices for them (:
2020-12-15 09:44:38 <ncopa> :)
2020-12-15 09:44:43 <Ariadne> get some of that delicious VC money without having to ever interact with a VC
2020-12-15 09:45:26 <fcolista> Ariadne, the cloud initative is smart and nice..thanks for the idea.
2020-12-15 09:55:07 <Ariadne> [[sroracle]]: nice
2020-12-15 09:56:47 <[[sroracle]]> so far it can intercept some chown syscalls and keep track of what id was set for that dev/ino. i have some uncommitted changes that will for example then return those fake ids on stat syscall
2020-12-15 09:57:38 <[[sroracle]]> i was in the middle of trying to rewrite one of the internal functions then got busy with other stuff. watch this space: https://code.foxkit.us/sroracle/comproot/
2020-12-15 09:58:11 <ncopa> i'd like avoid do fakeroot tricks. i think you can use an arg to GNU tar and set the permissions of the files that way
2020-12-15 09:58:55 <[[sroracle]]> well yes but then you have to declare everything that should have certain uid/gid/xattr et al other than 0/0/none
2020-12-15 09:59:01 <[[sroracle]]> and then there are device files etc
2020-12-15 09:59:21 <ncopa> right, but its doable in theory
2020-12-15 09:59:38 <[[sroracle]]> i was trying to get libarchive to support mtree xattr decls then you could take an approach like that and make everything declarative. and i think that would be preferable in the long term
2020-12-15 10:00:09 <ncopa> in either case, i understand the need and usecase of fakeroot-like tools
2020-12-15 10:00:10 <[[sroracle]]> but i'm doing this instead now because people kept wondering if it was possible. and it seems like it is
2020-12-15 10:00:40 <ncopa> cool
2020-12-15 10:08:48 <Ariadne> telmich: ping
2020-12-15 10:09:54 <telmich> Ariadne: pong
2020-12-15 10:10:19 <Ariadne> telmich: got your bug report, but you have ifupdown-ng 0.8 installed.  can you try to reproduce on 0.10 with --verbose?
2020-12-15 10:13:09 <telmich> Ariadne: sure. Just checking, is there already a package for it?
2020-12-15 10:13:16 <Ariadne> yes, 0.10.2 is in edge
2020-12-15 10:13:29 <Ariadne> strangely your helpers are at 0.10.2 already, but not ifupdown-ng core
2020-12-15 10:13:51 <Ariadne> apk upgrade ifupdown-ng should upgrade it
2020-12-15 10:14:09 <telmich> It doesn't :-)
2020-12-15 10:14:21 <telmich> [11:13] router2.place5:~# apk upgrade ifupdown-ng
2020-12-15 10:14:21 <telmich> OK: 1860 MiB in 449 packages
2020-12-15 10:14:48 <ikke> telmich: apk add -u ifupdown-ng
2020-12-15 10:15:28 <telmich> ikke:  vlan-2.2-r0: breaks: ifupdown-ng-0.10.2-r1[!vlan] satisfies: world[vlan]
2020-12-15 10:15:43 <telmich> (from apk add -u ifupdown-ng)
2020-12-15 10:16:48 <telmich> `apk upgrade -a` works though
2020-12-15 10:17:38 <Ariadne> ah
2020-12-15 10:17:42 <Ariadne> you can apk del vlan
2020-12-15 10:17:49 <Ariadne> ifupdown-ng has its own built in vlan handling
2020-12-15 10:18:03 <telmich> trying to restart the network now
2020-12-15 10:18:48 <telmich> it looks good!
2020-12-15 10:19:10 <telmich> rebooting to test
2020-12-15 10:19:10 <Ariadne> also you can simplify that config a lot
2020-12-15 10:19:25 <Ariadne> ifupdown-ng lets you attach additional addresses to loopback for example
2020-12-15 10:19:40 <Ariadne> and fully supports CIDR
2020-12-15 10:20:24 <telmich> Oh, have to check that out
2020-12-15 10:20:31 <telmich> (router still booting)
2020-12-15 10:21:12 <Ariadne> also `address` is supported multiple times per stanza :)
2020-12-15 10:21:19 <Ariadne> no need to do post-up /sbin/ip addr add foo
2020-12-15 10:53:12 <maxice8> afontain: left a question on !15816
2020-12-15 11:01:29 <ncopa> 5.10 kernel failed to boot on my desktop
2020-12-15 11:02:16 <ncopa> that is uefi failed to boot my 5.10 kernel
2020-12-15 11:03:53 <ncopa> i wonder if it is related to +CONFIG_EFI_DISABLE_PCI_DMA=y
2020-12-15 11:05:23 <Ariadne> telmich: i assume all is well?
2020-12-15 11:05:39 <telmich> All well!
2020-12-15 11:15:46 <ncopa> ncopa-desktop:~$ uname -a
2020-12-15 11:15:46 <ncopa> Linux ncopa-desktop 5.10.1-0-lts #1-Alpine SMP Tue, 15 Dec 2020 09:14:42 UTC x86_64 GNU/Linux
2020-12-15 11:15:50 <ncopa> boots with grub
2020-12-15 11:18:01 <mps> ncopa: https://people.kernel.org/gregkh/next-long-term-supported-kernel-release
2020-12-15 11:29:51 <telmich> Ariadne: I might have misreported. It seems that `apk upgrade -a` purged ifupdown-ng and I am using `busybox-ifupdown` at the moment
2020-12-15 11:30:08 <Ariadne> oh no
2020-12-15 11:30:22 <Ariadne> ok well if there is a problem please reopen :)
2020-12-15 11:33:23 <maxice8> !15826 !15827 should be ok ? upstream says all 1.1.1 users should upgrade
2020-12-15 11:34:04 <Ariadne> yes, proceed
2020-12-15 11:36:55 <ncopa> my machine boots if i add boot option efi=no_disable_early_pci_dma
2020-12-15 11:37:33 <ncopa> maxice8: yes looks good
2020-12-15 11:38:44 <nmeum> why was the networking services dropped from ifupdown-ng?
2020-12-15 11:38:47 <nmeum> 69ac0711d35c69e5dc385d337b83c51c9978f62c
2020-12-15 11:39:07 <nmeum> without it /etc/init.d/networking doesn't exist anymore on my machine
2020-12-15 11:39:29 <nmeum> causing network interfaces such us lo to be no longer configured properly
2020-12-15 11:39:35 <nmeum> *as
2020-12-15 11:40:54 <ikke> nmeum: It would cause issues on the builders, whenever something pulled in ifupdown-ng, it would cause it to purge the interface file when it was uninstalled again
2020-12-15 11:41:18 <nmeum> ah
2020-12-15 11:41:25 <nmeum> apk fix openrc restores the old networking openrc service
2020-12-15 11:53:18 <ncopa> yeah, you need apk fix openrc
2020-12-15 11:55:58 <Ariadne> nmeum: ncopa made the old service leverage ifquery if available, making the one i made moot.  given that, and the problem on the builders, dropping itmade most sense
2020-12-15 11:59:45 <ncopa> nmeum: you may also want have your rescue boot usb available when upgrading to 5.10
2020-12-15 12:00:31 <nmeum> I always have an alpine usb stick laying around ;)
2020-12-15 12:01:23 <ncopa> same here, but my usb key still has alpine 3.11 and didnt have the eth driver for my newish work desktop
2020-12-15 12:01:30 <ncopa> so usb ethernet to the rescue
2020-12-15 12:03:47 <nmeum> Ariadne: just a friendly suggestion: if you add that info to the commit it would make it easier for people like me to figure out why this change was made by looking at the commit log
2020-12-15 12:04:38 <Ariadne> yes, sorry about that.  i forgot to do it :(
2020-12-15 12:05:10 <nmeum> happes, i do know the struggle of writting good commit messages
2020-12-15 12:05:13 <nmeum> *happens
2020-12-15 12:31:16 <omni> 
ACTION upgraded a couple of DomUs and then Dom0 to 5.10.1 just fine

2020-12-15 12:31:58 <omni> but I stayed off of 5.10.0 ;)
2020-12-15 12:40:57 <mps> hmm, two months I'm running my two working machines from 5.10-rc1, didn't had any issue, except some drivers/devices didn't in good shape
2020-12-15 12:41:38 <maxice8> PureTryOut: !15807
2020-12-15 12:42:09 <PureTryOut[m]2> Can't they be disabled only on mips?
2020-12-15 12:42:18 <maxice8> the tests ?
2020-12-15 12:42:38 <PureTryOut[m]2> Yes
2020-12-15 12:42:46 <maxice8> ok
2020-12-15 13:29:01 <maxice8> our id3tag.pc is broken
2020-12-15 13:30:04 <maxice8> or minidlna autoconf is
2020-12-15 13:34:00 <Ariadne> what does pkgconf --validate say about it
2020-12-15 13:34:08 <maxice8> not in that way
2020-12-15 13:34:52 <Ariadne> id3tag.pc seems fine
2020-12-15 13:35:04 <maxice8> yes
2020-12-15 13:35:10 <maxice8> seems like the configure script is broken for minidlna 1.3.0
2020-12-15 13:35:14 <Ariadne> /usr/include/id3tag.h is kosher, libid3tag is in right place
2020-12-15 13:41:34 <maxice8> yes id3tag seems to be fine
2020-12-15 13:41:47 <maxice8> minidlna configure script is being weird
2020-12-15 14:02:16 <Ariadne> synapse fallout appears to be due to twisted ;/
2020-12-15 14:02:48 <maxice8> oof
2020-12-15 14:02:53 <maxice8> what arches ?
2020-12-15 14:03:16 <maxice8> also openssl on 3.10 (armv7|armhf) and 3.11 (armhf) is failing to fetch/checksum mismatch
2020-12-15 14:04:29 <Ariadne> ppc64le
2020-12-15 14:05:07 <Ariadne> protobuf downgrade why
2020-12-15 14:05:25 <maxice8> It fails on 32bit arches
2020-12-15 14:05:33 <maxice8> it == tests
2020-12-15 14:05:57 <Ariadne> did you forget to run abuild checksum ?
2020-12-15 14:06:03 <Ariadne> >>> ERROR: py3-protobuf: protobuf-python-3.13.0.tar.gz is missing in checksums
2020-12-15 14:06:11 <maxice8> excuse me
2020-12-15 14:06:16 <maxice8> fak
2020-12-15 14:06:26 <maxice8> yes i did
2020-12-15 14:06:55 <Ariadne> :)
2020-12-15 14:10:00 <maxice8> Just gave a 2048x1536 image for gitlab profile and it bugged the cropbox up
2020-12-15 14:15:27 <walbon> ikke, sorry, I'm again. We saw into smokeping log https://build.alpinelinux.org/buildlogs/build-3-13-ppc64le/main/smokeping/smokeping-2.7.3-r4.log that it cant remove into cleanup a trash file, so,.. can you access remotely the server to do that? rm: can't remove '/home/buildozer/aports/main/smokeping/src/smokeping-2.7.3/thirdparty/work/1607868839.45492': Directory not empty
2020-12-15 14:16:43 <maxice8> algitbot: retry 3.10-stable
2020-12-15 14:16:47 <maxice8> algitbot: retry 3.11-stable
2020-12-15 14:18:00 <ikke> walbon: strange thing is that abuild clean works
2020-12-15 14:18:04 <maxice8> can someone look at build-3.10-armhf, build-3.10-armv7 and build-3.11-armhf, they fail to build openssl due to checksum errors
2020-12-15 14:19:17 <walbon> ikke, yes, strange it is.
2020-12-15 14:20:56 <walbon> ikke, do you suspect of some component of build on ppc?
2020-12-15 15:57:19 <yZ5vlALg86lP> interesting: apk segfaults, when doing apk del -r vlc
2020-12-15 16:00:04 <Thermi> Cogitri: Hi, did you have any time to look at the current state of MR 8569 (https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8569)? As of the last changes, it ran stable on Alpine.
2020-12-15 16:05:19 <maxice8> some builders seem stuck
2020-12-15 16:05:26 <ikke> maxice8: will look at it in a bit
2020-12-15 16:05:32 <maxice8> edge-armhf, edge-armv7, edge-mips64 edge-x86
2020-12-15 16:05:37 <maxice8> all of them on py3-protobuf
2020-12-15 16:06:47 <yZ5vlALg86lP> is it this? so:libprotobuf.so.25 (no such package): required by: protobuf-c-1.3.3-r3[so:libprotobuf.so.25] | so:libprotoc.so.25 (no such package): required by: protobuf-c-1.3.3-r3[so:libprotoc.so.25]
2020-12-15 16:06:49 <Cogitri> Thermi: Ah, I don't really have tine for Alpine right now, hopefully I'll be able to look into it during uni holidays
2020-12-15 16:07:12 <Thermi> Cogitri: Thank you for your time. Do you know the IRC handle of Leo? I'd like to pester him with that then. ;)
2020-12-15 16:07:13 <maxice8> that would cause a build failure not a stuck build
2020-12-15 16:07:37 <Cogitri> That would be maxice8 :D
2020-12-15 16:10:05 <yZ5vlALg86lP> ah. true
2020-12-15 16:10:15 <Thermi> Oh mighty maxice8, could you please look at MR 8569 and tell me if there needs any additional work to be done, except a rebase and squash? :)
2020-12-15 16:10:27 <maxice8> sure
2020-12-15 16:10:29 <maxice8> !8569
2020-12-15 16:16:13 <maxice8> I left a review, I'll separately merge some of the dependencies to reduce the review load.
2020-12-15 16:16:33 <Thermi> maxice8: Ty! I will get these two items fixed ASAP
2020-12-15 16:23:26 <ikke> timlegge: ping
2020-12-15 16:36:12 <maxice8> Thermi: ping
2020-12-15 16:36:34 <Thermi> pong
2020-12-15 16:36:54 <Thermi> maxice8:
2020-12-15 16:36:55 <Thermi> ^
2020-12-15 16:37:11 <Thermi> I'm checking the dependency stuff now.
2020-12-15 16:37:20 <Thermi> (To see if they're detected and if so, which ones are)
2020-12-15 16:37:44 <Thermi> Regarding the db stuff: I'll need to look at that and talk with our contact about it
2020-12-15 16:53:44 <maxice8> algitbot: retry master
2020-12-15 16:55:27 <ikke> walbon: I think it's something in the smokeping build system that is having issues
2020-12-15 16:56:52 <ikke> But there are several strange things
2020-12-15 17:21:56 <walbon> well, in the edge smokeping have build fine
2020-12-15 17:22:23 <ikke> yes
2020-12-15 17:22:28 <ikke> When was this?
2020-12-15 17:22:55 <ikke> july
2020-12-15 17:26:09 <ikke> Summarized: 1) The issue happens during packaging. 2) faked processes remain behind. 3) a CC process is orphaned. 4) at some point, mqtt-exec crashes (the parent process)
2020-12-15 17:26:54 <ikke> 4) it complains about a directory that it wants to remove, but that's not empty
2020-12-15 17:33:54 <timlegge> ikke:  Hi
2020-12-15 17:35:29 <ikke> timlegge: we have some strange build issues with smokeping on the ppc64le 3.13 builder
2020-12-15 17:36:13 <ikke> Was wondering if you had some time to help figure out what's going on (though, I have some work to do in 30 minutes)
2020-12-15 17:36:49 <ikke> https://build.alpinelinux.org/buildlogs/build-3-13-ppc64le/main/smokeping/smokeping-2.7.3-r4.log
2020-12-15 17:37:24 <timlegge> sure, I can look
2020-12-15 17:38:00 <ikke> I have access to the builder, so I can check what's going on there
2020-12-15 17:38:07 <walbon> ikke, ow, I build by hand in a ppc machine
2020-12-15 17:38:26 <walbon> sorry my delay
2020-12-15 17:38:33 <ikke> walbon: no problem
2020-12-15 17:54:51 <mps> 'rm: can't remove '/home/buildozer/aports/main/smokeping/src/smokeping-2.7.3/thirdparty/work/1608050334.73148': Directory not empty'
2020-12-15 17:56:54 <ikke> yes
2020-12-15 17:57:07 <ikke> which is true
2020-12-15 17:57:39 <ikke> Going to upgrade gitlab in a couple of minutes
2020-12-15 17:57:40 <mps> something wrong with builder?
2020-12-15 17:57:53 <ikke> mps: abuild clean works without issue
2020-12-15 17:58:21 <mps> hmm, lets try on x86_64 lxc
2020-12-15 17:58:58 <maxice8> ldc still fails on aarch64
2020-12-15 17:59:57 <Cogitri> Did it work with x86_64
2020-12-15 18:00:15 <maxice8> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/ldc/ldc-1.24.0-r0.log
2020-12-15 18:00:17 <maxice8> let's find out
2020-12-15 18:00:20 <maxice8> just started tests
2020-12-15 18:00:30 <Cogitri> Ah, it'll probably blow up again
2020-12-15 18:00:48 <ikke> Ok, gitlab is going down now
2020-12-15 18:00:49 <Cogitri> It runs through just fine on my system and my aarch64 runner though
2020-12-15 18:03:14 <Thermi> Cogitri: maxice8 when you're removing berkeley db, how will you deal with postfix? It needs an inter process database, too, so lmdb is out?
2020-12-15 18:04:15 <Cogitri> Not involved in that process
2020-12-15 18:05:35 <mps> Thermi: db is already 'removed' from postfix
2020-12-15 18:05:49 <Thermi> mps: just the dependency?
2020-12-15 18:05:55 <mps> yes
2020-12-15 18:06:26 <mps> cefc8415715c247a8d424a46a05ccb9be8ca091d
2020-12-15 18:06:49 <Thermi> Ah, I just saw that lmdb is actually capable of inter process reads and writes
2020-12-15 18:07:09 <Thermi> So not an issue
2020-12-15 18:07:42 <Thermi> Oh, no Python bindings.
2020-12-15 18:07:44 <Thermi> Pity.
2020-12-15 18:10:31 <PureTryOut[m]2> 
ACTION was about to complain that Gitlab was down but then remembered he saw a notice that maintenance was going to happen

2020-12-15 18:10:49 <ikke> :)
2020-12-15 18:10:51 <ikke> almost done
2020-12-15 18:12:15 <ikke> PureTryOut[m]2: I still need to figure out how to get traefik to show a nice message
2020-12-15 18:12:58 <PureTryOut[m]2> Yeah that'd be nice 😃
2020-12-15 18:14:38 <maxice8> yep
2020-12-15 18:14:39 <maxice8> ldc x86_64 blew up :D
2020-12-15 18:14:47 <ikke> PureTryOut[m]2: It's up again
2020-12-15 18:15:01 <PureTryOut[m]2> 🎉
2020-12-15 18:15:16 <Cogitri> Maybe just disable ldc for now
2020-12-15 18:22:07 <mps> TBK[m]: now that linux-lts is 5.10 with samsung exfat driver does it make sense to remove exfat-utils and move exfatprogs from testing to community
2020-12-15 18:31:43 <timlegge> ikke:  weird I added rm -fr "$builddir/thirdparty/work" after the install - rm -fr "$builddir/thirdparty/work/*" that should have worked left the directories in work
2020-12-15 18:31:57 <timlegge> no idea whetehr that might work for you
2020-12-15 18:55:28 <timlegge> ikke: there are some complaints at the end about ExtUtils::MakeMaker but that has been part of perl for a while
2020-12-15 18:55:39 <ikke> ok
2020-12-15 18:55:47 <ikke> It's strange it happens at the end, though
2020-12-15 18:56:02 <ikke> maybe buffering?
2020-12-15 18:56:57 <timlegge> could be.  I almost looks like the previous build left the src directory - maybe delete it
2020-12-15 18:57:24 <ikke> timlegge: yes, that's normal when the build fails
2020-12-15 18:57:49 <ikke> abuild -r cleans up the srcdir at the start
2020-12-15 18:58:05 <ikke> timlegge: The strange thing is, if I run abuild -r manually, it just continues
2020-12-15 18:59:43 <ikke> timlegge: do you know why it's installing all kinds of modules during the packaging phase?
2020-12-15 18:59:59 <ikke> Successfully installed FCGI-0.78
2020-12-15 19:00:54 <timlegge> it seems to install them to the thirdparty dir.  I assume it seems to want to ensure that its perl depend are fine.
2020-12-15 19:01:08 <ikke> right
2020-12-15 19:01:08 <timlegge> seems like overkill to me
2020-12-15 19:01:16 <ikke> But it also looks like it's compiling them?
2020-12-15 19:01:23 <ikke> or at least, some
2020-12-15 19:01:52 <ikke> I mean, some modules seem to have binary parts
2020-12-15 19:02:32 <timlegge> the work/? includes the file probably from cpan so it would need to compile/make them
2020-12-15 19:03:03 <timlegge> let me look at the fresh src pkg
2020-12-15 19:03:28 <ikke> I mean, building takes 3 seconds, packaging over a 5 minutes
2020-12-15 19:04:16 <ikke> " Configure failed for IO-Tty-1.12. See /home/buildozer/aports/main/smokeping/src/smokeping-2.7.3/thirdparty/work/1608058734.105878/build.log for details."
2020-12-15 19:04:19 <ikke> ah
2020-12-15 19:06:54 <ikke> > FAIL Timed out (> 60s). Use --verbos
2020-12-15 19:06:55 <ikke> e to retry
2020-12-15 19:07:48 <ikke> one thing is clear to me, smokeping does too much in the package phase
2020-12-15 19:07:57 <ikke> I think it's some interaction with libfakeroot
2020-12-15 19:08:15 <timlegge> thirdparty has a Makefile that uses a local to thirdparty cpan mirror to install the modules in ../PERL_MODULES
2020-12-15 19:09:28 <timlegge> it user thirdparty/bin/cpanm to install each of the modules from cpan
2020-12-15 19:10:00 <timlegge> cpanm is faily fast but wound still need to compile each module if there were bins
2020-12-15 19:10:30 <ikke> which should not happen in the package phase
2020-12-15 19:10:58 <ikke> That apkbuild could use some love
2020-12-15 19:13:08 <ikke> so it's the `make install` that does it :-/
2020-12-15 19:14:18 <timlegge> yes, mot it up under the cofigure?
2020-12-15 19:14:28 <timlegge> s/mot/move/
2020-12-15 19:14:28 <alpine-meetbot> timlegge meant to say: yes, move it up under the cofigure?
2020-12-15 19:15:27 <ikke> just `make`
2020-12-15 19:15:48 <timlegge> true
2020-12-15 19:15:55 <ikke> trying that now
2020-12-15 19:16:38 <ikke> libfakeroot had some updates / changes, and I feel that now causes issues with projects that somehow do more than just installing stuff in packaging
2020-12-15 19:17:07 <ikke> strip: unable to copy file './usr/lib/x86_64-linux-thread-multi/auto/HTML/Parser/Parser.so'; reason: Permission denied
2020-12-15 19:17:10 <ikke> sight
2020-12-15 19:17:20 <ikke> -t
2020-12-15 19:20:08 <TBK[m]> <mps "TBK: now that linux-lts is 5.10 "> I think that is a good idea. Maybe add provides/replaces to migrate users. btw it seems a dash is missing from https://git.alpinelinux.org/aports/tree/testing/exfatprogs/APKBUILD#n25
2020-12-15 19:20:16 <ikke> permissions 0555 😕
2020-12-15 19:21:56 <TBK[m]> mps: ^
2020-12-15 19:22:39 <timlegge> in the build () make DESTDIR="$pkgdir" || return 1
2020-12-15 19:22:43 <ikke> yes, provides/replaces should be added
2020-12-15 19:23:31 <ikke> those `|| return 1` parts are redundant now
2020-12-15 19:24:08 <timlegge> I had to had the DESTDIR="$pkgdir"
2020-12-15 19:24:11 <ikke> ok
2020-12-15 19:24:47 <ikke> I'll modernize the APKBUILD as well
2020-12-15 19:26:05 <ikke> timlegge: yes, that does it!
2020-12-15 19:26:42 <timlegge> nice
2020-12-15 19:29:30 <mps> TBK[m]: oh, I see, thanks
2020-12-15 19:32:46 <mps> TBK[m]: yes, I also think replaces and/or provides should be set
2020-12-15 19:37:27 <ikke> timlegge: pushed
2020-12-15 19:37:29 <ikke> thank you so much
2020-12-15 19:37:41 <ikke> hope it helps
2020-12-15 19:37:45 <ikke> walbon: ^
2020-12-15 19:37:52 <timlegge> ikke: no problem
2020-12-15 19:37:59 <walbon> ow, thx ikke
2020-12-15 19:38:21 <ikke> http://dup.pw/alpine/aports/44ee49ea6040
2020-12-15 19:39:52 <ikke> \o/
2020-12-15 19:39:55 <ikke> seems to have succeeded
2020-12-15 19:40:07 <ikke> uploading packages to main
2020-12-15 19:40:52 <ikke> 413c7f9a4fd1938a8b247213d25528ed26be00f7
2020-12-15 19:41:11 <ikke> maybe this was the issuee (the previous change)
2020-12-15 19:41:24 <ikke> I see that libfakeroot was built right after
2020-12-15 19:44:15 <walbon> ikke, I see. Thank you , great work. smokeping is back and I believe so the building :)
2020-12-15 19:44:32 <ikke> yes
2020-12-15 19:47:18 <ikke> hmm, for some reason grpc is not being rebuilt
2020-12-15 19:47:26 <ikke> on some arches
2020-12-15 19:49:05 <ikke> ah, it is rebuilt, just not uploaded yet
2020-12-15 20:01:55 <ikke> maxice8: I think grpc has still been built against the newest libprotobuf (so:libprotobuf.so.25)
2020-12-15 20:02:00 <ikke> at least on some arches
2020-12-15 20:14:10 <ikke> You can now comment on multiple lines of code in a merge request: https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/#multi-line-comments-for-merge-requests
2020-12-15 20:14:57 <Cogitri> Neat
2020-12-15 21:00:08 <ikke> huh, trying to build apk-tools in an alpine docker container, similar to what is done in CI, but it complains about headers missing
2020-12-15 21:00:57 <ikke> make[1]: *** No rule to make target '/usr/include/sys/cdefs.h', needed by 'libfetch/common.o'.  Stop.
2020-12-15 21:01:51 <Cogitri> build-base is installed?
2020-12-15 21:01:53 <ikke> yes
2020-12-15 21:02:26 <ikke> https://gitlab.alpinelinux.org/kdaudt/apk-tools/-/blob/master/.gitlab-ci.yml#L9
2020-12-15 21:06:31 <ikke> meson works
2020-12-15 21:06:36 <ikke> but make not :(
2020-12-15 21:10:17 <ikke> I don't get it
2020-12-15 21:10:35 <ikke> WHy does it work in CI, but not when I do it locally
2020-12-15 21:11:51 <Hello71> at a guess, -j :p
2020-12-15 21:13:20 <ikke> tried, doesn't make a difference
2020-12-15 21:15:08 <Hello71> try make clean; make -j1, if that doesn't work make -d | ixio
2020-12-15 21:16:05 <ikke> 🤦
2020-12-15 21:16:36 <ikke> make clean did the trick
2020-12-15 21:17:21 <Hello71> it shouldn't be needed but i cba to go kbuild fishing
2020-12-15 21:17:56 <ikke> I lost you in the last half of that sentence
2020-12-15 21:18:00 <PureTryOut[m]2> Nice, linux-pam installs a systemd unit file https://pkgs.alpinelinux.org/contents?file=pam_namespace.service&path=&name=&branch=edge&arch=x86_64
2020-12-15 21:22:00 <ikke> Hello71: thanks btw
2020-12-15 21:22:17 <ikke> I worked on an old repository of apk-tools I still had
2020-12-15 21:22:34 <Hello71> ikke: make clean probably shouldn't be required in this case. it's odd though because c_flags was copied from kbuild, which doesn't use -MP...
2020-12-15 21:23:06 <Hello71> i guess maybe some other part of kbuild is fixing it, and apk-tools stripped kbuild doesn't
2020-12-15 21:23:27 <ikke> No idea what kbuild is :)
2020-12-15 21:23:48 <ikke> Makefile framework?
2020-12-15 21:24:05 <ikke> : A set of makefile rules loosely based on kbuild.:
2020-12-15 21:24:47 <ikke> ah, from the kernel
2020-12-15 21:25:22 <Hello71> ah, yes, fixdep injects the null deps
2020-12-15 21:25:27 <alpine-meetbot> Hello71 meant to say: ah, yes, fixdep injects the null rules
2020-12-15 21:25:27 <Hello71> s/deps/rules/
2020-12-15 21:25:54 <Hello71> in the conversion from .d to .cmd
2020-12-15 21:59:30 <TBK[m]> Do anybody recall why go was disabled on mips64?
2020-12-15 21:59:30 <TBK[m]> bc90d36da5f4f7822fbad1746b61dd327411c7d9
2020-12-15 22:00:01 <ikke> TBK[m]: kernel is too old
2020-12-15 22:00:15 <ikke> the mips builder kernel
2020-12-15 22:00:18 <TBK[m]> ah
2020-12-15 22:02:21 <ikke> The builder runs a BSP kernel, and the NIC driver is preventing from running another kernel
2020-12-15 22:03:56 <TBK[m]> is the mips64 builder still the edgerouter pro 8?
2020-12-16 04:27:34 <Ariadne> ikke: build-edge-x86 is stuck on protobuf, can you kick it?
2020-12-16 04:27:53 <Ariadne> TBK[m]: no.  it is edgerouter infinity.  16-core Octeon 3
2020-12-16 05:33:03 <ikke> Ariadne: done
2020-12-16 05:33:41 <Ariadne> thanks
2020-12-16 05:33:55 <ikke> got stuck on several arches
2020-12-16 05:39:23 <Ariadne> kick the x86_64 and aarch64 builders too, so we dont waste time building ldc
2020-12-16 05:43:47 <ikke> done
2020-12-16 05:45:55 <dalias> ug why does protobuf hang? :-p
2020-12-16 05:45:55 <ikke> wow, rust finally built on armv7
2020-12-16 05:46:21 <ikke> I think the libfakeroot switch back to ipc fixed it?
2020-12-16 05:47:17 <dalias> tcp broke stuff?
2020-12-16 05:47:27 <dalias> fwiw tcp sounds like an utterly awful insecure idea here
2020-12-16 05:47:45 <dalias> "lol any process on localhost is trusted" mentality
2020-12-16 05:47:52 <ikke> dalias: ncopa at least found out it caused a lot of performance issues
2020-12-16 05:48:22 <dalias> no idea why they would use tcp rather than unix sockets or pipes or posix shm to replace sysvipc
2020-12-16 06:28:24 <ikke> dalias: seems to he py3-protobuf 3.14, which was reverted
2020-12-16 07:32:42 <ncopa> morning
2020-12-16 07:32:47 <ikke> ncopa: o/
2020-12-16 07:33:05 <ikke> seems like your fakeroot change fixed a few other issues as well
2020-12-16 07:33:40 <ikke> rust is now built on 3.13 armv7
2020-12-16 07:33:48 <ncopa> we used tcp sockets for fakeroot due to autoconf script tried to test run something which failed when crosscompiling
2020-12-16 07:33:52 <ncopa> oh, right
2020-12-16 07:34:07 <ncopa> might be it would have succeded if we'd give it enough time (a year?)
2020-12-16 07:34:18 <ikke> I guess
2020-12-16 07:34:36 <ikke> smokeping most likely failed (on ppc64le) due to that as well
2020-12-16 07:34:47 <ncopa> llvm10 fail on x86 is nasty though
2020-12-16 07:34:53 <ncopa> no clue whats going on there
2020-12-16 07:35:28 <ncopa> and when i tried to build it with debugging symbols, the linker ran out of mem
2020-12-16 07:39:09 <Cogitri> Ah, nice that rust works now, thanks for looking into it! :)
2020-12-16 07:43:20 <ikke> np
2020-12-16 07:48:54 <Ariadne> TBK[m]: Octeon 3 NIC driver is not yet upstream.  may never be upstream, at this rate (marvell does not care much about Octeon)
2020-12-16 08:17:55 <mps> I agree with jirutka and ncopa latest mails on ML about supervisor in init scripts (as I told many times here earlier). to all: please revert these changes in init scripts
2020-12-16 08:20:04 <Cogitri> Or rather, make it configurable
2020-12-16 08:20:18 <Cogitri> I think some global switch for this would be pretty nifty
2020-12-16 08:20:42 <mps> Cogitri: it is as jirutka described in mail, /etc/conf.d/files
2020-12-16 08:25:09 <Cogitri> Yes, but that's a per-service switch, isn't it?
2020-12-16 08:28:46 <mps> yes
2020-12-16 08:29:57 <mps> (if someone need distro which 'walks like systemd' then use systemd distro)
2020-12-16 08:30:43 <Cogitri> I really don't see how that's connected to systemd
2020-12-16 08:30:48 <ikke> me neither
2020-12-16 08:32:10 <ikke> systemd does this better than openrc atm
2020-12-16 08:32:17 <mps> supervise everything by default, i.e. global
2020-12-16 08:32:20 <ikke> it's configurable per service if it should auto restart
2020-12-16 08:32:58 <ikke> which is not enabled by default
2020-12-16 08:33:19 <mps> ikke: where? on openrc or systemd
2020-12-16 08:33:32 <ikke> systmed
2020-12-16 08:33:34 <ikke> systemd
2020-12-16 08:34:23 <mps> well, theoretically not but practically yes
2020-12-16 08:34:49 <ikke> I like the declarative nature of systemd unit files
2020-12-16 08:35:01 <ikke> openrc has moved a bit more towards that
2020-12-16 08:36:30 <mps> I liked it when I switched to systemd as early adopter (from upstart) but started to dislike 'declarative' after (some) years of usage
2020-12-16 08:38:06 <mps> computers are bad at 'declarative' work, they need 'imperative' instructions (orders)
2020-12-16 08:38:32 <ikke> yes, but a lot of those imperative instructions are repetative
2020-12-16 08:39:29 <mps> yes
2020-12-16 08:39:47 <ikke> And with this repetition, the chance of doing it wrong increases as well
2020-12-16 08:40:00 <mps> but that doesn't mean 'that is bad'
2020-12-16 08:41:02 <mps> 'predictable' executions is better and safer than 'easy config'
2020-12-16 08:41:39 <ikke> declarative style is more predictable then imperative
2020-12-16 08:41:49 <mps> it is not
2020-12-16 08:42:05 <ikke> It's not for nothing most systems turn away from imperative style for init scripts
2020-12-16 08:43:16 <mps> 'declarations' are 'free' for interpretations, while imperative order is not
2020-12-16 08:44:18 <mps> most system is converted by marketing and business reasons
2020-12-16 08:44:27 <ikke> no
2020-12-16 08:44:31 <Cogitri> supervise everything by default isn't a systemd only thing, s6-rc and runit do it too
2020-12-16 08:44:43 <mps> heh, :)
2020-12-16 08:44:44 <Cogitri> I think runit did it before systemd (?)
2020-12-16 08:44:52 <ikke> It's by peop[le have been bitten for the umpteenth time by bad sysv init scripts
2020-12-16 08:45:48 <mps> actually DJBs daemontools where one of first which are used on linux
2020-12-16 08:46:19 <Ariadne> my goal is to eventually get alpine off of openrc and onto s6
2020-12-16 08:46:42 <mps> and I have experience with most of these supervisors (except s6)
2020-12-16 08:47:12 <mps> I don't see yet anything which is better than openrc
2020-12-16 08:47:38 <Ariadne> making something better than openrc using s6 is something that is a prerequisite to executing that plan obviously
2020-12-16 08:47:53 <mps> openrc is bad, I agree, but other options looks worse
2020-12-16 08:48:22 <Ariadne> yes I agree that's why we are dealing with openrc for now
2020-12-16 08:48:29 <Ariadne> even though our openrc is quite modified
2020-12-16 08:48:42 <mps> yes
2020-12-16 08:48:48 <ikke> But when openrc says a service is running, while it's actually crashed, that's bad
2020-12-16 08:49:06 <Ariadne> skarnet is however working on making s6-rc feel like openrc
2020-12-16 08:49:12 <mps> that's bad, ofc
2020-12-16 08:49:33 <Ariadne> once that materializes more my plan is to introduce s6-rc as alternative
2020-12-16 08:49:45 <ncopa> maybe it is possible to have a global supervise switch in /etc/rc.conf?
2020-12-16 08:49:49 <Ariadne> and really shake out the missing spots
2020-12-16 08:49:54 <Ariadne> yes it's possible
2020-12-16 08:50:02 <Ariadne> just put supervisor= in there
2020-12-16 08:50:33 <Ariadne> but openrc long-term isn't the future anyway
2020-12-16 08:50:34 <ncopa> and then its possible to override in /etc/conf.d/<service>
2020-12-16 08:50:44 <ncopa> yeah, probably not
2020-12-16 08:51:46 <Ariadne> declarative openrc services are preferable because they are easily translated away later
2020-12-16 08:52:20 <ikke> My experience with s6 is this: https://pkgs.alpinelinux.org/contents?file=&path=*bin&name=s6&branch=edge&repo=main&arch=x86_64
2020-12-16 08:52:41 <ikke> s6-<tab>
2020-12-16 08:53:12 <mps> hmmm
2020-12-16 08:53:37 <ikke> an explosion of commands, and no clue which I should use
2020-12-16 08:53:45 <maxice8> Ikke: what is the tag I must use when adding CI to one of my alpine projects ? I'm using docker-alpine
2020-12-16 08:53:58 <ikke> maxice8: Make sure you enable shared runners
2020-12-16 08:54:04 <maxice8> oh derp
2020-12-16 08:54:06 <maxice8> ty
2020-12-16 08:54:12 <Ariadne> ikke: yeah that's something that were going to fix by putting something pleasant in front of all of that porcelain
2020-12-16 08:54:38 <maxice8> https://gitlab.alpinelinux.org/Leo/agl/-/merge_requests/1 Should be good enough ?
2020-12-16 08:54:40 <mps> anyone looked at !15554, if no objections I would like to merge it
2020-12-16 08:54:49 <Ariadne> (think like git here, internally there's git-this and git-that, but there's nice frontend)
2020-12-16 08:55:05 <ikke> yes
2020-12-16 08:55:20 <ikke> maxice8: Yes, should be fine
2020-12-16 08:56:48 <ncopa> mps: !15554 looks good to me
2020-12-16 09:01:46 <mps> thanks, merged it
2020-12-16 09:02:12 <mps> lets hope it will work on all arches
2020-12-16 09:03:26 <mps> uh, >>> ERROR: qemu: unpack failed on armv7
2020-12-16 09:04:49 <mps> uhm, 'sha512sum: WARNING: 1 of 1 computed checksums did NOT match'
2020-12-16 09:05:29 <mps> ah, 'curl: (22) The requested URL returned error: 404'
2020-12-16 09:07:23 <ikke> That's from distfiles
2020-12-16 09:07:40 <ikke> You see below it downloads it from the upstream source
2020-12-16 09:11:38 <mps> I see this but not sure I understand. maybe checksums are different for distfiles and upstream
2020-12-16 10:07:31 <ncopa> hum... qemu failed on mips64
2020-12-16 10:08:18 <ikke> 1ninja: bad depfile: multiple outputs: /home/buildozer/aports/community/qemu/src/qemu-5.2.0/docs/interop/dbus.rst != docs/interop.stamp
2020-12-16 10:13:19 <Ariadne> :D :D :D :D :D :D :D :D :D
2020-12-16 10:13:24 <Ariadne> amazing
2020-12-16 10:29:34 <skarnet> "no clue which I should use" is unfair criticism
2020-12-16 10:30:03 <skarnet> when you compare the s6 documentation and the openrc documentation, they're really not in the same league
2020-12-16 10:30:16 <skarnet> at some point people just need to actually, you know, _read_ the documentation
2020-12-16 10:30:36 <skarnet> but yeah, I know and understand why "an explosion of command" is bad UI
2020-12-16 10:30:46 <ncopa> im tagging alpine 3.12.3 now
2020-12-16 10:35:57 <rnalrd> ncopa, at your earliest convenient time would you pls push kernel 5.4.84 to AL3.12?
2020-12-16 10:36:18 <rnalrd> it contains a kernel fix for the machines in my datacenter https://marc.info/?l=linux-kernel&m=160797435209978&q=mbox
2020-12-16 10:36:38 <rnalrd> long boot times due to be2iscsi
2020-12-16 10:36:46 <ncopa> ugh
2020-12-16 10:36:55 <rnalrd> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/drivers/scsi/be2iscsi/be_main.c?id=v5.4.84&id2=v5.4.83
2020-12-16 10:36:56 <ncopa> i just pushed 3.12.3
2020-12-16 10:37:06 <rnalrd> yeah, i just realized this morning
2020-12-16 10:37:24 <ncopa> i cant believe it!
2020-12-16 10:37:24 <rnalrd> sorry
2020-12-16 10:37:39 <ncopa> literally minutes after the 3.12.3 release
2020-12-16 10:38:14 <ncopa> do we need to make a 3.12.4 release for this?
2020-12-16 10:38:36 <rnalrd> i use HDD installs, so no problem in tagging later
2020-12-16 10:38:44 <ncopa> ok
2020-12-16 10:53:48 <Ariadne> hmm
2020-12-16 10:54:02 <Ariadne> i dont think this mips64 qemu issue is caused by mips64
2020-12-16 10:54:11 <Ariadne> probably samurai?
2020-12-16 10:54:52 <Cogitri> https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49904 The "Allow collaboration" button might be checked by default soon 🎉
2020-12-16 10:57:11 <ikke> They have 'merge request coaches'
2020-12-16 10:57:18 <ikke> (if we need inspiration for a name)
2020-12-16 10:58:26 <Ariadne> they have what
2020-12-16 10:59:03 <ikke> Ariadne: people who help outside contributes with their merge request
2020-12-16 10:59:15 <Ariadne> oh, mentors
2020-12-16 10:59:17 <ikke> basically, regarding your comment that we should not encourage users to ping @developers
2020-12-16 10:59:34 <Ariadne> 'merge request coach' sounds like some dystopian walmart shit
2020-12-16 10:59:46 <Ariadne> like when walmart wants to yell at you for doing a bad job, they call it 'coaching'
2020-12-16 10:59:46 <ikke> lol
2020-12-16 11:00:10 <Ariadne> or so i've been told, i've never worked at walmart, thankfully
2020-12-16 11:00:28 <mps> :)
2020-12-16 11:01:02 <ikke> I've never been in a walmart :)
2020-12-16 11:01:03 <mps> we should enable everyone from net to merge :P
2020-12-16 11:01:19 <ikke> mps: ok, making the change right now :P
2020-12-16 11:01:29 <mps> :D
2020-12-16 11:02:14 <mps> qemu on mips64, probably some samurai issue but I'm not sure
2020-12-16 11:03:39 <mps> and yes, would be nice to disable 'ping @developers', before you allow merge from random net
2020-12-16 11:05:19 <Ariadne> the problem with ping @developers is that not all alpine devs have time to deal with mentoring new contributors, and it just DoSes our inbox
2020-12-16 11:05:39 <mps> Ariadne: agree
2020-12-16 11:06:48 <ncopa> ok. i have a dilemma sort of
2020-12-16 11:06:59 <ncopa> i just tagged v3.12.3 with kernel 5.4.83
2020-12-16 11:07:14 <ncopa> minutes after, the 5.4.84 was released upstream
2020-12-16 11:07:42 <Ariadne> tag 3.12.4 :D
2020-12-16 11:07:42 <ncopa> now i need to tag a new v3.11 release. should i include the 5.4.84 kernel or leave it at 5.4.83?
2020-12-16 11:07:54 <Ariadne> i would update 3.11 to 5.4.84
2020-12-16 11:08:17 <ncopa> which means it would get a bit delayed
2020-12-16 11:08:49 <ncopa> main reason for new 3.11 release is for the openssl CVE
2020-12-16 11:27:14 <ncopa> ok, i apparently didnt push 5.4.83 to 3.11-stable yet.
2020-12-16 11:29:18 <maxice8> Anyone using podman instead of docker while running dabuild?
2020-12-16 11:31:05 <TBK[m]> maxice8: I am and I think Cogitri is as well.
2020-12-16 11:34:57 <Cogitri> Yup
2020-12-16 11:35:33 <Ariadne> does podman even work on alpine
2020-12-16 11:35:37 <Ariadne> i thought it needs systemd?
2020-12-16 11:35:44 <maxice8> I'm not in Alpine
2020-12-16 11:35:56 <maxice8> if TBK is on alpine then yes it does
2020-12-16 11:35:58 <Ariadne> 
ACTION tilts head

2020-12-16 11:36:13 <Ariadne> burn the witch!
2020-12-16 11:36:34 <maxice8> only if it is by nuclear fire
2020-12-16 11:45:47 <mps> developers don't use their distro?! sounds strange to me
2020-12-16 11:47:06 <Ariadne> as i said, burn the witch
2020-12-16 11:49:41 <mps> before burn there should inquisition process/procedure :)
2020-12-16 11:50:17 <omni> I've used podman on alpine (but never docker locally)
2020-12-16 11:52:20 <mps> 
ACTION changing nick to Ignatius_of_Loyola

2020-12-16 11:59:06 <ikke> Ariadne: nice story from notcurses
2020-12-16 11:59:22 <Ariadne> hmm?
2020-12-16 11:59:41 <ikke> the github issue
2020-12-16 11:59:47 <ikke> I just read it
2020-12-16 12:00:41 <maxice8> https://gitlab.alpinelinux.org/Leo/agl/-/jobs/273120
2020-12-16 12:00:49 <maxice8> CI is having a funny failure which can't be reproduced locally :D
2020-12-16 12:01:03 <ikke> heh
2020-12-16 12:01:16 <ikke> try to run it in alpinelinux/alpine-gitlab-ci
2020-12-16 12:02:54 <ikke> Seems like C.GIT_BLAME_IGNORE_WHITESPACE is not defined for some reason
2020-12-16 12:03:16 <ikke> maxice8: https://stackoverflow.com/a/12593395/20261
2020-12-16 12:16:37 <ikke> Can't reproduce it in docker either :-/
2020-12-16 12:17:21 <maxice8> I can't reproduce it locally
2020-12-16 15:32:11 <ncopa> mcrute, Ariadne: could we have a video call re official cloud images? when is a good time for you?
2020-12-16 15:44:14 <Thermi> Cogitri: maxice8 kindly requesting a review for #15842
2020-12-16 15:45:06 <ncopa> !15842
2020-12-16 15:49:21 <maxice8> Am cooking
2020-12-16 15:49:36 <ikke> yum
2020-12-16 15:55:36 <Thermi> yum yum
2020-12-16 15:57:32 <maxice8> Ikke: did you mean dnf?
2020-12-16 15:58:12 <ikke> :D
2020-12-16 16:04:28 <ikke> maxice8: seems more packages need to be rebuilt after the protobuf downgrade
2020-12-16 16:04:44 <maxice8> Yes
2020-12-16 16:14:19 <omni> did not finish?
2020-12-16 16:25:10 <ikke> maxice8: did you have succes with agl already?
2020-12-16 16:25:18 <maxice8> success as in ?
2020-12-16 16:25:24 <ikke> getting the tests to run
2020-12-16 16:26:51 <maxice8> Yes
2020-12-16 16:26:56 <ikke> ah, what was it?
2020-12-16 16:28:07 <maxice8> building static versions in musl
2020-12-16 16:28:13 <maxice8> is the real problem, tests already worked
2020-12-16 16:28:27 <ikke> right, I mean, in the pipeline
2020-12-16 16:28:40 <maxice8> the pipeline isn't solved, I'm still working on getting it working
2020-12-16 16:28:44 <ikke> riht
2020-12-16 16:29:43 <ikke> https://gist.github.com/Ikke/c30f7ac2ca30379b413674163b75c40f#file-configure
2020-12-16 16:29:55 <ikke> those LDFLAGS is how you can build static binaries
2020-12-16 16:30:18 <ikke> But I assume you were already aware of that
2020-12-16 16:30:21 <maxice8> I have a working Dockerfile to build a static single binary agl docker image and it works
2020-12-16 16:30:28 <ikke> ok, cool
2020-12-16 16:33:25 <mps> what keeps !15464 to merge
2020-12-16 16:34:24 <ikke> there is a mention of a bug
2020-12-16 16:36:36 <mps> yes, but bug is not in readline but octave
2020-12-16 16:51:44 <Thermi> Hi, what's the status of the APK tool rewrite?
2020-12-16 16:52:42 <Thermi> I got a bug thrown to me that would require support for CIDR subnets in APK tools, but if the code is supposed to be replaced anyway, the effort in comparison to the time the code would be used would be questionable
2020-12-16 16:53:04 <ikke> What part would require cidr subnets?
2020-12-16 16:54:16 <ikke> https://gitlab.alpinelinux.org/alpine/apk-tools/-/compare/master...v3.0-wip
2020-12-16 16:55:35 <Thermi> ikke: the part of apk tools that does HTTP connections because the no_proxy or NO_PROXY variables could not only contain domain names (implicitely supporting IP addresses), but also CIDR subnets
2020-12-16 16:55:55 <Thermi> (also, obviously not just the stuff doing HTTP connections but also FTP connections and so on)
2020-12-16 16:56:22 <Thermi> apk tools internally currently uses libfetch.c and other ancient *BSD code that could be replaced by curl or another library
2020-12-16 16:56:50 <ikke> Thermi: apk-tools needs to be conservative with dependencies
2020-12-16 16:57:27 <Thermi> ikke: And what would be a problem with a dependency on libcurl that's basically omnipresent?
2020-12-16 16:57:40 <ikke> Thermi: think about bootstrapping a new arch
2020-12-16 16:58:03 <Hello71> also rebuild upgrades are complicateder
2020-12-16 16:58:08 <ikke> indeed
2020-12-16 16:58:19 <Hello71> we already had trouble with time64
2020-12-16 16:59:25 <Thermi> using libcurl would add nghttp2-libs, brotli-libs, and ca-certificates in term of dependencies
2020-12-16 16:59:36 <Thermi> Their dependencies are all already dependencies of apk-tools as of now
2020-12-16 17:00:28 <ikke> python3 as well it seems
2020-12-16 17:00:42 <Thermi> ? What package are you looking at?
2020-12-16 17:00:47 <Thermi> I am looking at libcurlk
2020-12-16 17:00:48 <Thermi> *libcurl
2020-12-16 17:01:01 <ikke> I'm looking at recursive dependencies for curl
2020-12-16 17:01:10 <Thermi> I am using apk dot libcurl
2020-12-16 17:01:13 <Thermi> What are you using?
2020-12-16 17:01:26 <ikke> lua-aports'
2020-12-16 17:01:45 <Thermi> how does lua-aports relate to apk-tools?
2020-12-16 17:02:16 <ikke> lua-aports is a tool to look at aports as whole
2020-12-16 17:03:16 <Thermi> what command is used for looking at the dependency tree?
2020-12-16 17:03:40 <ikke> ap recursive-deps libcurl
2020-12-16 17:04:04 <Thermi> ty
2020-12-16 17:04:20 <Thermi> Ah, you're looking at build time dependencies.
2020-12-16 17:04:24 <Thermi> (makedepends)
2020-12-16 17:04:44 <ikke> Yes, indeed
2020-12-16 17:07:09 <Thermi> Well, okay
2020-12-16 17:08:42 <Thermi> Added dependencies would be brotli-dev c-ares-dev ca-certificates cunit-dev expat-dev gdbm-dev groff libcurl libev-dev libffi-dev nghttp2 nghttp2-dev python3 python3-dev sqlite-dev tcl-dev xz-dev
2020-12-16 17:09:24 <Thermi> I admit, that's quite a lot
2020-12-16 17:09:35 <Thermi> python3 stuff is about 40 MB each
2020-12-16 17:09:37 <Thermi> *MiB
2020-12-16 17:09:55 <Thermi> How often do you stand up new arches though
2020-12-16 17:09:57 <Thermi> :P
2020-12-16 17:10:19 <ikke> Often enough for this to be an issue
2020-12-16 17:10:23 <Thermi> :(
2020-12-16 17:10:38 <Thermi> So you rather reimplement or reuse the old libfetch code?
2020-12-16 17:10:40 <mps> Thermi: some people do that often
2020-12-16 17:11:34 <ikke> Thermi: in the end, it's up to fabled to decide what to use
2020-12-16 17:12:16 <Thermi> Oh noes
2020-12-16 17:12:50 <ikke> seems like python3 is only checkdepends
2020-12-16 17:13:30 <ikke> hmm, python3-dev still remains in the dep tree thoguh
2020-12-16 17:14:04 <Thermi> Thank you for your time
2020-12-16 17:22:26 <maxice8> Ikke: http://ix.io/2IjO
2020-12-16 17:22:32 <maxice8> Dockerfile for fully static libgit2
2020-12-16 17:23:00 <maxice8> /libgit2/agl
2020-12-16 17:23:32 <ikke> ok, you build libgit2 from source as well
2020-12-16 17:24:21 <alu20> hi. i wanted to submit a package but not sure i can long term maintain it. can a package be submitted with empty maintainer or its required?
2020-12-16 17:24:27 <ikke> maxice8: using libgit2-static does not work?
2020-12-16 17:24:56 <maxice8> I need to deal with libssh2
2020-12-16 17:25:00 <maxice8> separate -static was a mistake
2020-12-16 17:25:55 <ikke> :D
2020-12-16 17:26:19 <mps> ;)
2020-12-16 17:26:39 <mps> separate -static is always mistake
2020-12-16 17:26:45 <maxice8> or rather, it was implemented wrong because they are no static deps done automatically
2020-12-16 17:27:08 <maxice8> libgit2-static won't bring libssh2-static even though we compile with libssh2 support which adds it to Requires: and thus -dev brings it
2020-12-16 17:27:36 <maxice8> as far as I remember from trying it in Alpine compiling with libgit2-static will fail with missing stuff from libssh2-static
2020-12-16 17:27:52 <mps> MY-R: kernel 5.10 is not much interesting, most was already in 5.9. 5.11 merges looks interesting
2020-12-16 17:32:53 <MY-R> mps: still, 5.10 in 3.13 will be good thing like few minutes ago example of a guy who couldnt have working network card
2020-12-16 17:33:45 <MY-R> and not everyone can use edge stuff
2020-12-16 17:37:21 <mps> if this gay have working driver another one will come with another card which missing driver. this is 'never ending story'
2020-12-16 17:38:00 <skarnet> Turn around, look at what you seeeeee
2020-12-16 17:38:20 <mps> yes
2020-12-16 17:41:41 <MY-R> well yeah, network cards, wifi etc are rly never ending story :\
2020-12-16 17:56:23 <Thermi> Any idea why the CI fails at my MR !15862 with failing to resolve liburing-dev?
2020-12-16 17:56:43 <Thermi> It's in edge and I can resolve it locally after I built it, so what's happening here
2020-12-16 17:57:24 <Thermi> The problem I had locally with the dependency was that libprotobuf and libprotobufc weren't resolvable
2020-12-16 17:57:32 <Thermi> The problem in the CI is now that it can't find liburing-dev
2020-12-16 17:59:38 <mps> liburing is in community while samba in main
2020-12-16 18:00:30 <Thermi> I see. Maybe move it to main then? :P
2020-12-16 18:00:30 <mps> moved it few days ago from testing and asked if it needs to go main. you confirmed it should/must go in main?
2020-12-16 18:01:17 <mps> will do in next hour, samba will benefit from liburing, and probably some other pkgs
2020-12-16 18:19:31 <mps> Thermi: liburing is in main
2020-12-16 18:34:06 <Thermi> mps: great, ty
2020-12-16 18:36:54 <mps> Thermi: thank you for raising this and for adding vfs_uring to samba. will be interesting to test and use
2020-12-16 18:37:05 <Thermi> mps: you are very welcome
2020-12-16 18:37:31 <mps> :)
2020-12-16 18:44:17 <mps> I have some time and need help with provides and replaces. I want to move exfatprogs to community from testing and remove exfat-utils
2020-12-16 18:44:58 <Thermi> mps: https://gitlab.alpinelinux.org/Thermi/aports/-/jobs/273332#L51 :^
2020-12-16 18:45:04 <Thermi> Problem with the same dependencies as I had
2020-12-16 18:46:12 <mps> I will add 'provides="exfat-utils"' and 'replaces="exfat-utils"' but not sure should I add current exfat-utils version
2020-12-16 18:46:39 <mps> Thermi: maybe liburing is not yet uploaded to mirrors
2020-12-16 18:48:14 <Thermi> mps: Why is the issue with libprotobuf then?
2020-12-16 18:48:19 <Thermi> Like ??? :D
2020-12-16 18:49:52 <mps> Thermi: sorry I'm looking wrong build
2020-12-16 18:51:12 <mps> it finished on x86 CI, but something is wrong with protobuf on x86_64
2020-12-16 18:52:49 <ikke> provides="exfat-utils=$pkgver-r$pkgrel"
2020-12-16 18:54:27 <mps> ikke: thanks. I thought so but is nice to have you confirmed
2020-12-16 18:56:20 <Thermi> mps: So no issue with the MR?
2020-12-16 18:58:30 <mps> probably no
2020-12-16 18:59:35 <mps> protobuf pkg is 'unstable' in last few days
2020-12-16 19:01:15 <Thermi> Thank you, that is good to read.
2020-12-16 19:01:47 <ikke> It was upgraded and then downgraded again
2020-12-16 19:02:15 <ikke> Buwit the downgrade, dependent packages were not rebuilt.
2020-12-16 19:06:06 <ikke> But with*
2020-12-16 19:07:39 <mps> ikke: on x86 CI samba passed ok
2020-12-16 19:08:00 <Hello71> mps: qemu too, but qemu is community
2020-12-16 19:10:19 <Hello71> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/qemu/qemu-5.2.0-r0.log also zstd
2020-12-16 19:13:30 <mps> ah, I didn't noticed qemu
2020-12-16 19:16:23 <mps>  is replaces syntax ok in !15869
2020-12-16 19:17:01 <ikke> Swap replaces and provides
2020-12-16 19:19:57 <mps> what? order in APKBUILD
2020-12-16 19:20:19 <mps> hmm, no, values?
2020-12-16 19:21:36 <Newbyte> I noticed that GTK 4.0 is disabled for 32-bit arches due to it requiring more than 4GB when compiling. Would it be possible to work around this by using swap or zram or cross compiling or something like that?
2020-12-16 19:23:27 <mps> Newbyte: problem is 32bit address space and not memory on builders
2020-12-16 19:23:58 <ikke> mps: left comment
2020-12-16 19:25:35 <Newbyte> yes, but I mean, isn't the amount of swap you have unrelated to your address space?
2020-12-16 19:25:53 <mps> ikke: thanks
2020-12-16 19:26:04 <Newbyte> also, would address space be an issue if you cross-compiled from x86_64 to x86? not very familiar with cross-compiling
2020-12-16 19:26:30 <Newbyte> granted, these are somewhat complicated workarounds for a single package
2020-12-16 19:26:34 <mps> with cross compile/build it should work
2020-12-16 19:28:12 <mps> swap and real RAM all counts to same address space/range (nowadays). there were 'tricks' on old-old-old machines to use memory larger than address space
2020-12-16 19:29:11 <mps> 'who will ever need more than 640KB of RAM' :D
2020-12-16 19:32:53 <ikke> Oh, mps, I missed that the values should be the actual pkgver
2020-12-16 19:32:58 <Hello71> still works now but problem is the 4gb limit is only an issue for linker
2020-12-16 19:33:13 <Hello71> pae doesn't help if your problem is a single process
2020-12-16 19:34:19 <mps> Hello71: I think so but I don't follow much cpu architectures in last decade
2020-12-16 19:34:46 <Hello71> x86 is same as 15 years ago :p
2020-12-16 19:34:54 <mps> yes
2020-12-16 19:35:25 <mps> it would be shame to say 'two decades actually' ;)
2020-12-16 19:35:35 <afontain_> do we have fancy optimisations?
2020-12-16 19:35:57 <afontain_> maybe we could try to build with -fno-lto or something like that
2020-12-16 19:36:20 <mps> afontain_: you mean 'rm -rf all_big_software'? ;P
2020-12-16 19:36:52 <mps> that would be best optimization
2020-12-16 19:36:53 <afontain_> compile it with tcc :P
2020-12-16 19:37:35 <mps> but optimized software is not good for big companies
2020-12-16 19:37:47 <mps> or foundations
2020-12-16 19:37:58 <afontain_> (note that if gtk uses gresources in its source code, it won't work well)
2020-12-16 19:38:22 <afontain_>  * (note that if gtk uses gresources in its source code, tcc won't work well)
2020-12-16 19:39:57 <mps> ikke: I don't understand 'provides="exfat-utils=$pkgver-r$pkgver"', how abuild knows $pkgver and r$pkgver (I think it is $pkgrel)
2020-12-16 19:40:52 <mps> I mean, how abuild building exfatprogs knows there two from exfat-utils
2020-12-16 19:41:08 <mps> s/there/these/
2020-12-16 19:41:08 <alpine-meetbot> mps meant to say: I mean, how abuild building exfatprogs knows these two from exfat-utils
2020-12-16 19:43:10 <ikke>  It's basically the current package that defines the version, but in this case that might not work, as the oldpkg has a newer version
2020-12-16 19:43:50 <mps> I thought so
2020-12-16 19:44:02 <mps> so, it is good as it is now?
2020-12-16 19:44:38 <ikke> The question is how upgrades should be handled
2020-12-16 19:44:49 <mps> exfat-utils will be removed, I think
2020-12-16 19:53:17 <TBK[m]> yup, please include the removal/move to unmaintained in your MR.
2020-12-16 19:54:28 <mps> TBK[m]: Ok, though I expected that you will decide about its status
2020-12-16 20:00:03 <Newbyte> weird, GTK 4 builds fine in a 3GB RAM VM for me
2020-12-16 20:00:08 <Newbyte> maybe they fixed it in the final release?
2020-12-16 20:00:37 <Newbyte> though, it's an x86_64 VM
2020-12-16 20:02:52 <Newbyte> Maybe I'm doing something wrong
2020-12-16 20:04:33 <PureTryOut[m]2> Well for one you were building on x86_64
2020-12-16 20:04:57 <Hello71> set it to 2 and try again
2020-12-16 20:06:08 <Newbyte> !15870
2020-12-16 20:06:13 <Newbyte> x86 built
2020-12-16 20:06:59 <Newbyte> armv7 as well
2020-12-16 20:16:06 <Newbyte> hopefully this means they resolved the issue
2020-12-16 20:26:05 <ollieparanoid[m]> mps: with the qemu 5.2.0 upgrade, I'm getting symbol not found errors like:
2020-12-16 20:26:08 <ollieparanoid[m]> Error relocating /usr/lib/qemu/ui-sdl.so: egl_fb_setup_for_tex: symbol not found
2020-12-16 20:26:47 <ollieparanoid[m]> from "ldd /usr/lib/qemu/ui-sdl.so". looks like something broke?
2020-12-16 20:59:05 <ollieparanoid[m]> when I add qemu-modules, it works. so I guess abuild didn't properly detect the so dependencies or something. I'll make an issue
2020-12-16 20:59:53 <mps> ollieparanoid[m]: apk add qemu-ui-opengl
2020-12-16 21:00:14 <ollieparanoid[m]> mps: I did that, but that alone doesn't fix it. I've also tried qemu-ui-egl-headless
2020-12-16 21:00:23 <ollieparanoid[m]> so I probably need a couple of those
2020-12-16 21:00:37 <mps> hmm, for me this one is enough
2020-12-16 21:01:04 <mps> just tested on aarch64
2020-12-16 21:01:39 <ollieparanoid[m]> thanks. interesting. I can figure out the proper depends by installing parts of qemu-modules...
2020-12-16 21:01:50 <ollieparanoid[m]> so what's the proper fix for this, explicitly add the depends in the APKBUILD for the subpackages?
2020-12-16 21:03:33 <mps> not sure, if I never run 'sdl' ui why qemu have to depend on it
2020-12-16 21:03:52 <mps> alpine is not debian, I hope
2020-12-16 21:03:56 <ollieparanoid[m]> no I mean, add the proper depends to qemu-ui-sdl etc
2020-12-16 21:04:07 <ollieparanoid[m]> it surely isn't :P
2020-12-16 21:04:18 <mps> aha, maybe this make sense
2020-12-16 21:04:54 <ollieparanoid[m]> I'll figure out the depends I need and make a MR
2020-12-16 21:05:25 <mps> actually I think meson should do that automatically
2020-12-16 21:06:08 <mps> there is no sdl subpkg
2020-12-16 21:06:29 <ollieparanoid[m]> https://pkgs.alpinelinux.org/packages?name=qemu-ui-sdl&branch=edge&arch=x86_64
2020-12-16 21:06:43 <ollieparanoid[m]> (and the same happens for me with qemu-ui-gtk)
2020-12-16 21:07:43 <mps> expected
2020-12-16 21:08:05 <mps> probably will be fixed in some of next qemu minor releases
2020-12-16 21:08:38 <mps> they just switched to meson in 5.2.0 and not all 'switching' finished yet
2020-12-16 21:11:43 <mps> lets see if there something in git repo
2020-12-16 21:13:57 <ollieparanoid[m]> I tried the dependencies again, and you are right, only `qemu-ui-opengl` is missing. if I install that, it works again
2020-12-16 21:14:24 <ollieparanoid[m]> why should meson do that though, isn't it abuild's duty to autodetect the dependencies from the linked libraries?
2020-12-16 21:14:48 <Ariadne> qemu-ui-opengl is a plugin, not a linked library
2020-12-16 21:15:23 <mps> I just quessing about meson, don't know much how it works
2020-12-16 21:15:25 <ollieparanoid[m]> but if ldd shows missing symbols, doesn't that mean it was linked against qemu-ui-opengl?
2020-12-16 21:15:40 <ollieparanoid[m]> (or the so it provides)
2020-12-16 21:15:53 <Ariadne> having a DT_NEEDED entry means it was linked
2020-12-16 21:16:02 <Ariadne> meson is kind of screwy about this i've found
2020-12-16 21:16:11 <mps> ldd for me doesn't shoq that anything is missing
2020-12-16 21:17:49 <mps> hm, 'apk info -r qemu-ui-sdl' => qemu-modules-5.2.0-r0
2020-12-16 21:18:56 <mps> so, practically by upgrade qemu-ui-sdl qemu-modules should be upgraded/installed
2020-12-16 21:19:54 <ollieparanoid[m]> huh, qemu-ui-sdl doesn't pull in qemu-modules for me (not sure if that is what you were saying)
2020-12-16 21:21:28 <mps> yes, right, because that i wrote 'should', but it doesn't
2020-12-16 21:23:16 <mps> huh, net is so slow that is unusable now, can't finish exfat things
2020-12-16 21:25:53 <ollieparanoid[m]> https://bpa.st/7TTQ these are the ldd errors I'm getting. but it's probably unrelated, possibly my specific (postmarketOS) setup or something. the ldd errors are still there when I install the packages that make qemu-ui-sdl work again.
2020-12-16 21:26:44 <ollieparanoid[m]> I don't think qemu-ui-sdl needs all of qemu-modules, but it does need qemu-opengl. and same with qemu-ui-gtk.
2020-12-16 21:27:14 <mps> yes, true
2020-12-16 21:31:04 <mps> and can't find bug report on qemu.org about this
2020-12-16 21:34:10 <ollieparanoid[m]> https://bpa.st/O5BA this would be the patch for the APKBUILD (untested), if you want I can submit it properly.
2020-12-16 21:34:12 <ncopa> mcrute is now officially on the alpine infra team and will work on the official cloud images. Welcome!
2020-12-16 21:34:26 <ollieparanoid[m]> welcome!
2020-12-16 21:34:36 <ollieparanoid[m]> mps: I'm still not sure how meson would define it, so abuild could pick it up
2020-12-16 21:36:00 <mps> ollieparanoid[m]: not sure, ask maintainer about this and/or open issue report so we can look more on it
2020-12-16 21:37:02 <mps> oh, I'm sick of clouds here, they lasts for whole week, no chances to see sun :)
2020-12-16 21:37:07 <ollieparanoid[m]> ncopa: hi! you maintain the qemu package. how should we deal with this? qemu-ui-{sdl,gtk} is missing a depend on qemu-opengl
2020-12-16 21:37:20 <mcrute> thanks @ncopa, looking forward to making these AWS AMIs official and starting to add other cloud providers
2020-12-16 21:38:04 <mcrute> mps: same here in Seattle, it's always cloudy
2020-12-16 21:38:07 <ncopa> ollieparanoid[m]: create an issue and/or MR.
2020-12-16 21:38:08 <mps> mcrute: welcome
2020-12-16 21:38:09 <ollieparanoid[m]> mps: thanks for looking into this btw :)
2020-12-16 21:38:31 <ollieparanoid[m]> will do, thanks
2020-12-16 21:39:13 <mps> ollieparanoid[m]: np, thanks for reporting it so fast, someone told about two hours ago that qemu is not built
2020-12-16 21:39:53 <mps> and I didn't tried to upgrade till you reported problem
2020-12-16 21:40:18 <ollieparanoid[m]> np
2020-12-16 21:54:24 <Ariadne> finally, we will be able to use alpine on AWS without having to be bankrupted by a $2500/year license fee going to some scammer
2020-12-16 21:55:31 <mcrute> for real, that image needs pulled
2020-12-16 22:00:50 <Ariadne> technically its legal what that guy is doing
2020-12-16 22:01:02 <Ariadne> it's also highway robbery
2020-12-16 22:01:09 <Ariadne> and it amkes alpine look bad :)
2020-12-16 22:01:47 <mcrute> I've got an issue open to add the soon-to-be-official AMIs to the marketplace so hopefully those will push that out of the way
2020-12-16 22:02:06 <mcrute> given that it's not illegal it seems kinda unlikely AWS would pull it for us, but we can try I guess :-)
2020-12-16 22:02:58 <ikke> But providing ano offical free alternative should curb their efforts tremendously
2020-12-16 22:03:44 <mcrute> yeah that should hopfully pass the version >= and price <= checks of most reasonable people
2020-12-16 22:06:33 <TBK[m]> regarding https://build.alpinelinux.org/buildlogs/build-3-13-armhf/community/openvpn-auth-script/openvpn-auth-script-0_git20180315-r0.log
2020-12-16 22:06:33 <TBK[m]> "openssl/x509.h: No such file or directory" would it be best to move "main/openvpn"'s openssl-dev depend to depends_dev or just add openssl-dev to openvpn-auth-script's makedepends?
2020-12-16 22:11:01 <Ariadne> > conceive of and assemble alpine cloud team
2020-12-16 22:11:12 <Ariadne> > ncopa announces video chat to kick everything off
2020-12-16 22:11:17 <Ariadne> > i forget how timezones work
2020-12-16 22:11:24 <mps> Ariadne: to repeat, I'm not against if someone 'sell' alpine for whatever reason
2020-12-16 22:11:26 <Ariadne> > miss call kicking off team i created
2020-12-16 22:11:45 <mps> only problem I see is logo and name
2020-12-16 22:11:56 <Ariadne> mps: yes, we are in agreement
2020-12-16 22:12:14 <mcrute> mps: yeah using the Alpine logo seems like a good case for them to get pulled, also appearing to be official when not part of the project
2020-12-16 22:12:32 <Ariadne> mps: if somebody wants to make some image and sell it, that's cool, just don't pass it off as something we are doing
2020-12-16 22:12:33 <mcrute> Alpine is a nice base for other things but nobody should be selling "Alpine Linux" directly IMO
2020-12-16 22:13:03 <Ariadne> the fact that he was able to do that is a failing on our part
2020-12-16 22:13:19 <mcrute> Ariadne: thanks for getting this rolling though! there's still tons of stuff to be done before 3.14
2020-12-16 22:13:20 <Ariadne> we should have had this in place sooner, then he wouldn't have been encouraged to do this :)
2020-12-16 22:14:50 <Ariadne> in fairness
2020-12-16 22:14:53 <Ariadne> this hasn't really come up
2020-12-16 22:15:07 <Ariadne> because we've just kinda been assuming people were just finding your unofficial images and using them
2020-12-16 22:15:24 <mcrute> it's been mentioned a few times on the image project
2020-12-16 22:15:27 <Ariadne> i didnt even know about the 2500$ one until that one dude brought it up on twitter last week
2020-12-16 22:15:30 <mcrute> but people tend to find us next and just use that
2020-12-16 22:15:32 <Ariadne> then i was like
2020-12-16 22:15:37 <Ariadne> oh hell nah
2020-12-16 22:15:42 <Ariadne> we need to do something about that
2020-12-16 22:16:22 <Ariadne> i mean, he can even continue selling it imo
2020-12-16 22:16:36 <Ariadne> if people go on marketplace and see $0 image vs $2500 image
2020-12-16 22:16:43 <Ariadne> they're going to use the $0 image
2020-12-16 22:16:48 <Ariadne> so it makes it moot really
2020-12-16 22:16:58 <mcrute> yeah but it's a pretty old and broken image with the Alpine logo, makes it seem legit
2020-12-16 22:17:19 <Ariadne> don't forget the docker enterprise EULA
2020-12-16 22:18:20 <mcrute> for maximum irony it's tagged "Security"
2020-12-16 22:19:46 <Ariadne> to be clear i have no problem with somebody taking alpine, building something on top and selling it
2020-12-16 22:19:52 <Ariadne> i mean, literally, that is what i do for a living
2020-12-16 22:20:12 <mcrute> agreed, but do you sell "Alpine Linux" or <the name of your thing> ?
2020-12-16 22:20:45 <mcrute> selling "Alpine Linux" itself is the problem as I see it
2020-12-16 22:20:46 <Ariadne> the name of my thing :P
2020-12-16 22:21:07 <Ariadne> and our downstream product is quite different than alpine
2020-12-16 22:22:08 <Ariadne> we build it from alpine, but it has a lot of differences, for example completely different kernel in some cases, completely different default package set
2020-12-16 22:22:38 <Ariadne> (sometimes we're stuck with vendor kernels, its a bummer really)
2020-12-16 22:22:57 <mcrute> so you don't just apk install docker and start charging for it? seems like you're missing out on a lot of cash there :-P
2020-12-16 22:23:09 <Ariadne> however, we try to drive new features we are working on in alpine directly
2020-12-16 22:23:13 <Ariadne> like ifupdown-ng
2020-12-16 22:23:16 <Ariadne> :)
2020-12-16 22:23:41 <Ariadne> but some components (like broadcom SDK) cannot go into alpine
2020-12-16 22:23:49 <mcrute> oh yeah and thanks for that too btw... has made my life so much easier in a bunch of work stuff
2020-12-16 22:24:23 <mcrute> oh fuck Broadcom they're as bad if not worse than Nvidia
2020-12-16 22:25:56 <Ariadne> the meat and potatoes of that operation is making our little alpine-based NOS run on broadcom trident2/trident3/trident4/tomahawk/tomahawk2 switches
2020-12-16 22:26:15 <Ariadne> which yes, is as unpleasant as it sounds.  broadcom SDK = shitshow
2020-12-16 22:27:01 <mcrute> hey but at least their kernel module to flip registers in their ASIC is open source! you just need 400MB of binary blob to call through it :-( :-(
2020-12-16 22:27:51 <mcrute> Broadcom just kinda makes me angry... I have a ton of Trident 3 stuff that I'd love to run anything but iProc on but can't because of their driver stack
2020-12-16 22:30:07 <Hello71> doesn't nvidia drivers at least work most of the time
2020-12-16 22:30:32 <Hello71> assuming you use totally conventional config
2020-12-16 22:31:22 <Ariadne> mcrute: the SDK is "open" "source"
2020-12-16 22:31:28 <Ariadne> mcrute: its on github
2020-12-16 22:32:14 <mcrute> Ariadne: haha, true that, it's even got "Open" in the name! :-P
2020-12-16 22:32:49 <Ariadne> the SDK is also largely useless
2020-12-16 22:33:02 <mcrute> actually FB has a nice switch config stack using OpenNSL but it's very not trivial to configure
2020-12-16 22:33:25 <Ariadne> we just use the broadcom SAI blob and pray
2020-12-16 22:33:26 <mcrute> Ariadne: are you using the super-proprietary for-NDA-signers-only version?
2020-12-16 22:33:52 <Ariadne> i refuse to sign any broadcom NDA :)
2020-12-16 22:34:46 <Ariadne> also if you run strip on the blobs
2020-12-16 22:34:57 <Ariadne> they come down to about 5MB of blob
2020-12-16 22:35:12 <mcrute> orly? what adds the 395M to them?
2020-12-16 22:35:22 <mcrute> that seems way more than just debug symbols
2020-12-16 22:35:31 <Ariadne> its full debug info
2020-12-16 22:35:37 <Ariadne> including source fragments
2020-12-16 22:36:06 <Ariadne> this is on SAI blob though
2020-12-16 22:36:16 <Ariadne> libbrcmsdk.a is a totally different shitshow
2020-12-16 22:36:23 <mcrute> ignore the broadcom behind the binary curtain
2020-12-16 22:36:39 <mcrute> are the SAI blobs on GH?
2020-12-16 22:36:53 <Ariadne> yeah
2020-12-16 22:36:53 <mcrute> and are they enough to drive an ASIC alone?
2020-12-16 22:37:16 <Ariadne> mostly.  you still have to provide init code
2020-12-16 22:37:23 <Ariadne> compiled against brcmsdk
2020-12-16 22:37:26 <Ariadne> :D :D :D
2020-12-16 22:37:50 <Ariadne> broadcom is mostly so we can snag the cumulus linux crowd
2020-12-16 22:37:51 <mcrute> that was interesting... but yeah... that's why they pay you the big bucks :-D
2020-12-16 22:38:10 <Ariadne> we're mostly recommending centec for our platform
2020-12-16 22:38:17 <Ariadne> should have that prod-ready early 2021
2020-12-16 22:38:35 <Ariadne> centec is of course bootleg chinesium broadcom
2020-12-16 22:38:39 <Ariadne> but its better silicon
2020-12-16 22:38:47 <Ariadne> and less garbage SDK experience
2020-12-16 22:38:48 <mcrute> I really wish more vendors would get on the DSA and switchdev bandwagon, it's such a beautiful management interface from the outside
2020-12-16 22:38:55 <mcrute> but only Marvell seems to be using it right now
2020-12-16 22:39:09 <Ariadne> mellanox is doing switchdev
2020-12-16 22:39:36 <mcrute> er yeah the other big M vendor
2020-12-16 22:39:46 <Ariadne> i wish there were a way to make it so userspace processes can respond to netlink queries
2020-12-16 22:39:52 <Ariadne> would make life a lot easier
2020-12-16 22:40:01 <Ariadne> then we could fake switchdev in userspace
2020-12-16 22:40:04 <Ariadne> with SAI
2020-12-16 22:40:31 <mcrute> that would be really beautiful... sounds like it could be a big re-architecture about how the kernel things about netlink though?
2020-12-16 22:40:49 <Ariadne> we're also working on a high-quality netconf-based management plane for our little NOS, as well as alpine hosts
2020-12-16 22:41:11 <mcrute> what NOS are you working on?
2020-12-16 22:41:29 <Ariadne> right now we call it NSL, its not publicly released yet
2020-12-16 22:41:44 <Ariadne> NSL is basically cumulus, but alpine-based and FOSS
2020-12-16 22:42:04 <Ariadne> (if you notice, ifupdown-ng is largely modelled after cumulus ifupdown2)
2020-12-16 22:42:50 <mcrute> that's cool! I've not used Cumulus, can't touch it without a license agreement
2020-12-16 22:42:56 <mcrute> but I wish they had open sourced way more
2020-12-16 22:43:15 <Ariadne> 2021 is going to be really exciting i think
2020-12-16 22:43:22 <mcrute> although their kernel patches are pretty nice... having VRF on Linux is great
2020-12-16 22:43:41 <Ariadne> we have a lot of ideas about how to tie together FOSS alpine and commercial products in the wider alpine ecosystem to enable 'smart DC'
2020-12-16 22:45:47 <mcrute> the merchant silicone market is ready to be flipped on it's head, this NSL project sounds like it'll be great to start that
2020-12-16 22:46:05 <mcrute> silicon even :-/
2020-12-16 22:48:42 <Ariadne> the basic premise of our idea is to allow people to run their networks in a traditional way, but also allow them to work programatically with other components of the datacenter, like k8s
2020-12-16 22:49:48 <Ariadne> so k8s talks to our controller, and our controller does the necessary network changes to satisfy k8s desired state
2020-12-16 22:50:18 <mcrute> so it's kinda like service mesh meets the networking metal?
2020-12-16 22:50:41 <mcrute> or like k8s as an real SDN controller?
2020-12-16 22:50:58 <Ariadne> yep
2020-12-16 22:51:07 <Ariadne> exactly the first one
2020-12-16 22:51:23 <Ariadne> and possibly second as well, but haven't explored that yet much
2020-12-16 22:51:40 <mcrute> that's a neat idea! one of my biggest complaints about k8s is how convoluted the networking layer is
2020-12-16 22:51:48 <Ariadne> but the basic idea is
2020-12-16 22:51:56 <Ariadne> mr. CTO
2020-12-16 22:52:03 <Ariadne> can buy whitebox switches with NSL
2020-12-16 22:52:09 <Ariadne> buy servers with alpine on them
2020-12-16 22:52:22 <Ariadne> buy mirantis kubernetes engine licenses for his servers
2020-12-16 22:52:44 <Ariadne> and have a full stack that is fully supported by key players in alpine community
2020-12-16 22:53:30 <mcrute> technically that sounds awesome, but won't CTOsan also want a support contract?
2020-12-16 22:53:36 <Ariadne> yeah
2020-12-16 22:54:01 <Ariadne> that's what my day job provides :)
2020-12-16 22:54:24 <Ariadne> we are already supporting NSL devices in the field as CPE
2020-12-16 22:54:43 <Ariadne> for a telecom company
2020-12-16 22:54:45 <mcrute> develop the core concepts in the ISP market?
2020-12-16 22:54:55 <Ariadne> that's what spawned the mips64 port in fact
2020-12-16 22:55:51 <Ariadne> (the CPE devices the telecom provider chose were ubiquiti edgerouter-pro)
2020-12-16 22:56:31 <mcrute> that seems weirdly high end for telco CPE though probably easily in their budget
2020-12-16 22:56:31 <Ariadne> [15:54:42] <mcrute> develop the core concepts in the ISP market?
2020-12-16 22:56:35 <Ariadne> right exactly
2020-12-16 22:56:46 <Ariadne> edgerouter pro?  nah
2020-12-16 22:56:55 <Ariadne> you can get them for $200 or less
2020-12-16 22:57:07 <Ariadne> they are octeon2 devices
2020-12-16 22:57:09 <mcrute> I mean most companies are passing out TPLink junk for $5 a pop
2020-12-16 22:57:34 <Ariadne> oh, sure
2020-12-16 22:57:36 <mcrute> yeah those octeon2 chips are really solid for home users
2020-12-16 22:57:45 <Ariadne> this isnt for home
2020-12-16 22:57:52 <Ariadne> its a b2b engagement
2020-12-16 22:58:01 <mcrute> that makes more sense then
2020-12-16 22:58:07 <Ariadne> we were planning to support 30k sites but then covid happened
2020-12-16 22:58:28 <Ariadne> so that kinda didn't work out, but it did get NSL off the ground
2020-12-16 22:58:46 <mcrute> is this telco planning to manage their CPE with k8s?
2020-12-16 22:58:59 <Ariadne> no
2020-12-16 22:59:07 <Ariadne> the k8s angle is my idea :)
2020-12-16 22:59:12 <mcrute> oh, because that sounded actually insane :-P
2020-12-16 23:02:16 <Ariadne> part of my goal is to also bring more of these alpine derivatives into the flock
2020-12-16 23:02:48 <Ariadne> there's zededa for example, which is some IoT/edge compute solution built on alpine
2020-12-16 23:03:38 <mcrute> how many are there?
2020-12-17 06:59:12 <Newbyte> I'm trying to upgrade mesa, but meson says: meson.build:21:0: ERROR: Options "drm, surfaceless" are not allowed in choices: "auto, x11, wayland, haiku, android, windows" when I build it (after fixing the patches)
2020-12-17 06:59:28 <Newbyte> Any ideas what this might be about?
2020-12-17 07:07:03 <Cogitri> Well, it says that the values you've supplied to a meson option aren't valid
2020-12-17 07:07:22 <Cogitri> You chose drm,surfaceless but valid choicws are auto, x11, wayland...
2020-12-17 07:07:59 <Cogitri> Also, keep in mind that we don't upgrade to .0 mesa releases since those are unstable
2020-12-17 07:08:52 <Newbyte> I know! Mesa 20.3.1 came out today
2020-12-17 07:10:08 <Newbyte> But yes, I do see that. However, I'm not sure where that's happening exactly. I don't see anything like this on line 21 (or elsewhere in the file by searching)
2020-12-17 07:11:18 <Newbyte> Or rather, I do, but I'm not sure what to make of it since this is part of the meson.build from upstream
2020-12-17 08:15:48 <fcolista> guys do you recall where's the page with date and ETA until which $alpinever is supported?
2020-12-17 08:16:13 <ikke> https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
2020-12-17 08:16:26 <fcolista> ikke, as always you are my hero
2020-12-17 08:29:55 <ncopa> morning
2020-12-17 08:33:50 <Newbyte> good morning!
2020-12-17 08:44:09 <Newbyte> What is the purpose of the contributor field in APKBUILDs?
2020-12-17 08:45:12 <ikke> Not a lot. Kind of 'acknowledge' people who have made significant contributions to the package
2020-12-17 08:46:22 <ncopa> we copied that from arch linux iirc
2020-12-17 08:46:44 <ikke> Heh, I had the suspicion :)
2020-12-17 08:48:27 <ikke> ncopa: https://git.alpinelinux.org/aports/commit/?id=a0243ee90618
2020-12-17 08:48:34 <Newbyte> So there's no real reason to add yourself there?
2020-12-17 08:48:41 <ikke> Newbyte: correct
2020-12-17 08:48:51 <ncopa> ikke: i just noticed
2020-12-17 08:49:29 <Cogitri> Sometimes you could reach out to previous contributors to an APKBUILD in case things are unclear in the APKBUILD and the maintainer doesn't know/isn't available
2020-12-17 08:49:52 <ikke> Cogitri: git blame / log does wonders for that
2020-12-17 08:49:57 <ncopa> git blame and git log can also help
2020-12-17 08:50:00 <ikke> :P
2020-12-17 08:50:14 <ncopa> why does qemu build fail on mips64?
2020-12-17 08:50:21 <Marian[m]> https://todo.sr.ht/~sircmpwn/hg.sr.ht/33#event-62271 hg.sr.ht now has stable archives. No need to mirror the source tarballs anymore :-)
2020-12-17 08:50:32 <ikke> Marian[m]: nice
2020-12-17 08:51:31 <ncopa> nice indeed
2020-12-17 08:53:43 <Cogitri> ikke: Fair, but that's a bit more effort since people doing mass changes (e.g. change how meson configure is done for all APKBUILDs) show up in that too
2020-12-17 08:54:43 <ikke> Cogitri: on the other hand, not everyone who is making (significant) changes is adding themselves as contributor
2020-12-17 08:55:39 <ikke> And you can tell git blame to ignore certain commits
2020-12-17 08:59:35 <Cogitri> Yup, if Contributors doesn't yield results git blame is the way to go
2020-12-17 08:59:59 <ikke> I like git blame better, because I can see who changed the particular line :)
2020-12-17 09:00:31 <ikke> (I use tig blame, which makes it easier)
2020-12-17 09:08:11 <ncopa> Ariadne: is or mips64 softfloat?
2020-12-17 09:08:16 <ncopa> our*
2020-12-17 09:08:46 <Ariadne> yes
2020-12-17 09:10:55 <ncopa> ok. thanks. thats why qemu fails
2020-12-17 09:11:21 <Ariadne> i guess, block it for now
2020-12-17 09:11:38 <Ariadne> the main reason why the port is softfloat is a lot of mips64 cpus have buggy fpus
2020-12-17 09:12:32 <ncopa> looks like it happens in tests/fp/fp-bench.c
2020-12-17 09:12:45 <ncopa> so i suppose we could disable tests for mips64
2020-12-17 09:14:35 <ncopa> is there any preprocessor define that tells if its softfloat?
2020-12-17 09:15:22 <ncopa> #ifdef SOFTFLOAT ... #endif
2020-12-17 09:17:13 <ncopa> I guess I can use __mips_soft_float
2020-12-17 09:46:13 <ncopa> im fixing go on build-3-13-s390x now
2020-12-17 09:46:51 <ikke> ncopa: ah
2020-12-17 09:47:11 <ncopa> im also working on llvm10 on x86
2020-12-17 09:47:19 <ncopa> im simply removing the test that fails
2020-12-17 09:50:10 <ncopa> hum...
2020-12-17 09:50:22 <ncopa> wher did build-3-13-mips64 go?
2020-12-17 09:52:57 <ikke> it's stuck on py3-lz4
2020-12-17 10:14:03 <mps> arm: 'In Linux-5.10, there are 452 devicetree files based on 76 SoCs, or 30 SoC families, far more than any other Arm core...' https://lwn.net/Articles/838807/
2020-12-17 10:14:30 <mps> jungle
2020-12-17 10:26:50 <ncopa> let me deal with the build-3-13-mips64
2020-12-17 10:27:02 <ikke> ncopa: btw, it happened before
2020-12-17 10:27:49 <ncopa> i suspect its related the fakeroot issue
2020-12-17 10:27:59 <ncopa> so im gonna update fakeroot there first
2020-12-17 10:28:04 <ikke> aha, ok
2020-12-17 10:28:09 <ikke> makes sense
2020-12-17 10:28:34 <ncopa> i also have a fix for qemu mips64
2020-12-17 10:28:41 <ikke> nice
2020-12-17 10:35:14 <ncopa> ok good. i think we are making progress
2020-12-17 10:35:22 <ncopa> now it is mips64 that is behind
2020-12-17 10:35:35 <ncopa> i think we need to prioritize mips64 build failures for 3.13
2020-12-17 10:35:52 <ncopa> it will be the thing that determines when we get rc1 out
2020-12-17 10:37:33 <ncopa> after that its x86 and armhf(?)
2020-12-17 10:39:16 <ikke> arm(hf|v7) have long been stuck on rust
2020-12-17 10:47:30 <ncopa> hum. ok
2020-12-17 10:47:44 <ncopa> re py3-gtts-token: https://github.com/Boudewijn26/gTTS-token
2020-12-17 10:47:50 <ncopa> it fails due to change int google api
2020-12-17 10:50:47 <ikke> always fun, checks that rely on external services
2020-12-17 11:20:39 <Ariadne> ifupdown-ng 0.11 will be out shortly after 3.13 release i think
2020-12-17 11:20:50 <ncopa> sounds good
2020-12-17 11:21:00 <ncopa> seems like virt-manager broke with qemu-5.2
2020-12-17 11:21:12 <ncopa> or i dont have the right combination of plugins installed
2020-12-17 11:21:12 <Ariadne> one thing i am working on is netlink executors for it, which speak to kernel directly
2020-12-17 11:21:45 <ncopa> libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor
2020-12-17 11:21:45 <Ariadne> that should allow for configuring any scenario regardless of whether busybox supports it :)
2020-12-17 11:21:58 <ncopa> sounds like a good idea
2020-12-17 11:26:20 <ikke> with busybox, you mean bb iproute2?
2020-12-17 11:29:41 <Ariadne> yes
2020-12-17 11:35:59 <ncopa> virt-manager failed due to missing qemu-audio-* drivers
2020-12-17 12:26:53 <ikke> flake8 fails with "packaging.version.InvalidVersion: Invalid version: '/usr/lib/python3.8/site'", trying to figure out where that comes from
2020-12-17 13:08:45 <Ariadne> lto1: fatal error: bytecode stream in file '/usr/lib/python3.8/config-3.8-arm-linux-gnueabihf/libpython3.8.a' generated with LTO version 9.0 instead of the expected 9.2
2020-12-17 13:08:47 <Ariadne> hmmph
2020-12-17 13:30:02 <ncopa> the 5.10.1 kernel boots fine on rpi3 and rpi4 (aarch64)
2020-12-17 13:31:48 <mps> ncopa: -lts or -rpi variant
2020-12-17 13:35:31 <ncopa> -rpi
2020-12-17 13:36:39 <mps> I just read debian-arm ML what is needed for mainline to boott RPi, will add these options later in linux-edge
2020-12-17 13:37:25 <mps> btw, forgot to ask artok did he managed to boot RPi4 with linux-edge 5.10.1
2020-12-17 14:20:59 <minimal> mps: I intend to test aarch64/armv7 linux-edge 5.10.1 with RPI3 shortly. Will let you know how I get on.
2020-12-17 14:22:58 <minimal> Ariadne: so what's the roadmap/gameplan regarding cloud images for providers other than AWS?
2020-12-17 14:24:10 <Ariadne> minimal: 3.13 will be AWS-only.  3.14 will support the others.  gameplan is to switch from tiny-ec2-bootstrap to cloud-init.  mcrute is running that effort, since he was already doing the AWS images
2020-12-17 14:24:39 <Ariadne> we concluded doing a 3.13 AWS-only release is good if only to give people an alternative to that other image
2020-12-17 14:28:02 <minimal> ok. is there going to be a mailing list or something else to co-ordinate things going forward?
2020-12-17 14:36:03 <Ariadne> alpine-devel as usual, maybe we can make a new one later
2020-12-17 14:45:33 <mps> minimal: nice, thanks in advance
2020-12-17 14:48:02 <ncopa> seems like kubernetes is not happy running from tmps on an RPI with only 1G ram
2020-12-17 14:48:29 <ncopa> needs 1.1G diskspace
2020-12-17 14:48:51 <ncopa> just to be able to connect to the cluster and accept workloads
2020-12-17 15:02:12 <minimal> mps: while the linux-edge packages for armv7/aarch do have the RPI dtbs main files they don't have the additional RPI various overlays/*.dtbo files.
2020-12-17 15:04:00 <mps> minimal: right, alpine should make just these files which are in mainline
2020-12-17 15:05:59 <mps> we are not 'alpibian' like raspbian
2020-12-17 15:06:55 <mps> till someone make raspalpinian :)
2020-12-17 15:07:45 <ikke> centalpubianos
2020-12-17 15:07:58 <mps> :D
2020-12-17 15:10:06 <minimal> mps: am digging into it currently ;-)
2020-12-17 15:21:56 <mps> I would like to have alpineBSDstyle
2020-12-17 15:26:12 <minimal> mps: so the RPI overlays in linux-rpi kernel are coming from https://dev.alpinelinux.org/archive/rpi-patches/rpi-5.10.1-alpine.patch
2020-12-17 15:26:50 <minimal> so portions of that patch would also need to be used by linux-edge for RPI
2020-12-17 15:30:45 <mps> minimal: no, I'm strongly against that idea, we should 'keep' upstream (in linux-edge case mainline kernel) and not add other things from random net
2020-12-17 15:31:30 <minimal> well without the dtbs/overlays directory a lot of RPI hardware device will not work
2020-12-17 15:31:40 <mps> though some will tell that rpi upstream is not random, to 'cut' that thinking I'm saying 'it is from random net'
2020-12-17 15:32:31 <mps> that same can be done for a lot of arm devices and we will end in chaos
2020-12-17 15:32:44 <artok> truly, there is already -rpi
2020-12-17 15:32:52 <minimal> for example my hardware RTC won't work as the stock RPI bootloader currently (with linux-rpi) loads /boot/dtbs-rpi/overlays/i2c-rtc.dtbo
2020-12-17 15:33:33 <mps> does RPi have RTC? or maybe some of latest
2020-12-17 15:33:40 <minimal> artok: mps is trying to help wean RPIs off a distinct patched kernel towards upstream kernel
2020-12-17 15:33:54 <artok> it is
2020-12-17 15:34:09 <artok> oops.. triggerhappy enter
2020-12-17 15:34:41 <minimal> mps: RTC is hardware addon. Also this used for the RPI official POE HAT: /boot/dtbs-rpi/overlays/rpi-poe.dtbo
2020-12-17 15:34:42 <artok> when upstream gets those patches, sure, it comes to -edge
2020-12-17 15:34:44 <mps> artok: disable 'enter' key in your irc client
2020-12-17 15:35:20 <artok> mps: ctrl-j would do the trick
2020-12-17 15:35:25 <minimal> basically for various 3rd hardware HATs as well as for i2c, gpio, etc uses these overlays are needed
2020-12-17 15:35:49 <mps> artok: ctrl-j is long ago 'enter' in my irrsi
2020-12-17 15:36:04 <maxice8> Ok set up my alpine environment on Fedora Silverblue
2020-12-17 15:36:54 <mps> minimal: I understand and know this, but how to do that with mainline kernel
2020-12-17 15:37:21 <mps> I don't have 'clear' idea except a lot of patches
2020-12-17 15:37:50 <artok> after bunch of patches that's not mainline kernel anymore
2020-12-17 15:38:06 <artok> it is -rpi kernel =)
2020-12-17 15:38:10 <mps> artok: right
2020-12-17 15:38:41 <minimal> I'd expect that for linux-edge on armv7 and aarch64 there should still be a patch to add these files. These aren't drivers, they're devicetree "configs" for discovering various additional RPI hardware
2020-12-17 15:38:52 <mps> for us (alpine) is enough if board boot and basic works
2020-12-17 15:39:47 <mps> there are a lot of add-on boards and support all of them or most is big task
2020-12-17 15:41:50 <artok> ..and since uname -r gives 5.10.1-0-rpi4, I'm happy with it
2020-12-17 15:41:52 <minimal> actually its not just 3rd hw, if you want to disable bluetooth or wifi on RPI you put lines such as "dtoverlay=disable-wifi" in config.txt for bootloader........which then needs to load these from overlays/
2020-12-17 15:42:55 <artok> oh and should now check if the latest updates got wifi working again
2020-12-17 15:43:13 <minimal> I thought the plan was to get rid of the linux-rpi* kernel packages in preference to linux-edge, but without the overlays that's not workable
2020-12-17 15:43:54 <artok> yes, when mainline does that, -rpi can be dropped
2020-12-17 15:46:03 <mps> it sounds like nice idea to have dtbos for a lot of things and a lot of SBCs but I presume you understand how much work this will need
2020-12-17 15:46:24 <minimal> mps: its already being handled for the linux-rpi* packages
2020-12-17 15:46:56 <minimal> so it would basically be the same or similar amount of work
2020-12-17 15:46:57 <mps> minimal: huh, why is rpi 'first class' supported devices?
2020-12-17 15:47:29 <mps> there are a lot of other SBCs which deserves support
2020-12-17 15:47:46 <minimal> mps: ? Alpine has a downloadable RPI versions. Someone thought it was a good idea to have that
2020-12-17 15:47:51 <afontain_> well, it's supported now, if we add support to linux-edge it will probably also be supported
2020-12-17 15:48:23 <artok> linux-rpi is because of there is rpi kernel patches available and maintained by that foundation
2020-12-17 15:48:42 <mps> but, anyone is free to make 'spin off' of alpine and make tailored subdistro for specific board or class of boards
2020-12-17 15:48:58 <afontain_> (something something postmarketOS)
2020-12-17 15:49:02 <artok> but we can't call -edge as mainline kernel if there is patches out of kernel.org
2020-12-17 15:49:03 <minimal> artok: right, and as more stuff for RPI in mainlined the foundation patches get smaller with time
2020-12-17 15:49:11 <mps> artok: right, most other arm works fine on mainline for long time
2020-12-17 15:50:15 <mps> I run arm32 and arm64 different devices on mainline for more than 7 years
2020-12-17 15:50:38 <minimal> mps: so the million dollar question is, are Alpine going to keep supporting RPI or not? There's been support for a while, its not a new thing.
2020-12-17 15:51:04 <mps> minimal: probably, but with -rpi kernels
2020-12-17 15:51:31 <mps> if someone continue to maintain these, ofc
2020-12-17 15:51:42 <mps> which is waste of time, imo
2020-12-17 15:51:45 <minimal> mps: ok. I thought for our past discussions that there was an active process to move RPIs away from distinct -rpi kernels into the main kernels. I guess I got the wrong impression
2020-12-17 15:52:42 <mps> minimal: no, your impression is right, but we don't know when the goal will be achieved or near at least
2020-12-17 15:53:54 <artok> it would need: a) mainline kernel to have all needed features for brcm, b) bootloader that knows how to start
2020-12-17 15:53:57 <minimal> mps: but as the mainline kernels don't have the DTB overlays and you don't see why a patch should be used to add them.......then this means effectively there's an active process to end RPI support
2020-12-17 15:54:00 <mps> I'm working on it when I have free time and will, but no one promised anything
2020-12-17 15:55:03 <mps> minimal: I just express my personal ideas and what I work and what I think. that doesn't mean these are alpine plans
2020-12-17 15:55:29 <artok> and kernel.org people are ones to push with these patches
2020-12-17 15:55:39 <artok> when it happens upstream, it happens on alpine
2020-12-17 15:55:48 <artok> on that particular -edge package
2020-12-17 15:55:50 <mps> when something officially announced then we can say 'alpine plan is this'
2020-12-17 15:56:34 <mps> artok: well told
2020-12-17 15:56:45 <minimal> mps: wasn't trying to conflate your expressions and an official Alpine line. Was just trying to understand Alpine's plans regarding ongoing RPI support
2020-12-17 15:57:13 <mps> minimal: alpine don't have any plan, imo
2020-12-17 15:57:23 <mps> on anything
2020-12-17 15:57:51 <mps> except to ruin 'small, simple, secure' :D
2020-12-17 15:58:00 <afontain_> :O
2020-12-17 15:58:27 <mps> but also this is not officially announced
2020-12-17 16:00:03 <minimal> mps: back to what started this conversation, there's no point me trying to test linux-edge on RPI as it doesn't contain the DTB overlay files needed
2020-12-17 16:01:34 <mps> I have some other kernels in my local branches, linux-elm for acer chromebook, linux-gru for gru-kevin chromebook, linux-exynos for exynos chromebook, linux-n900 for nokia n900 and linux-rc for brave people but didn't pushed them (yet) to aports
2020-12-17 16:02:47 <mps> minimal: I don't know for you but I test linux-edge on rpi zero and it works fine on task I need on it
2020-12-17 16:03:33 <minimal> I'm using overlays for RTC, disabling BT and Wifi (to save power), PoE, etc
2020-12-17 16:03:47 <mps> if I have other RPi boards probably will run -edge on them, but I don't need such boards for now at least
2020-12-17 16:05:09 <mps> even thought to buy one RPi4 only to test alpine on it, but I don't want to give money (however small amount) to broadcom
2020-12-17 16:05:19 <artok> I couldn't get -edge to load rpi4 usb driver on init
2020-12-17 16:05:49 <mps> artok: I enabled it in 5.10.1, PCI iirc
2020-12-17 16:08:59 <ncopa> i thikn it woudl be nice to drop the linux-rpi kernel in alpine, but it does not seems to be doable at this point
2020-12-17 16:09:08 <artok> mps: I have 5.10.1 installed
2020-12-17 16:09:32 <ncopa> i also think that it might make sense to have an -rpi kernel instead of a generic arm kernel, which would be alot more bloated
2020-12-17 16:10:14 <ncopa> currently the -rpi kernel does not add much extra work for us
2020-12-17 16:10:40 <mps> artok: maybe something from this debian bug report should be enabled https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977438
2020-12-17 16:11:07 <ncopa> it adds a little bit, but its manageable. -rpi kernel and the rpi release tarball will be available for alpine 3.13
2020-12-17 16:11:12 <mps> minimal: so, ncopa just solved your issue :)
2020-12-17 16:12:15 <ncopa> we will not drop the rpi kernel until we have a good way to use the mainline kernel linux-lts
2020-12-17 16:12:20 <minimal> mps: I already have had linux-rpi working for some time. The issue was whether there was an active intention to drop linux-rpi packages without the same functionality (DTB overlays) making it into linux-edge
2020-12-17 16:12:51 <mps> minimal: I don't have answer to this, tbh
2020-12-17 16:13:20 <ncopa> we will not drop linux-rpi in favor of linux-edge, which is an experimental kernel
2020-12-17 16:13:25 <mps> (but I have to prepare another coffee, I'm too sleepy)
2020-12-17 16:13:27 <minimal> ncopa: from the RPI patch currently used for linux-rpi it may be possible to extract only the overlay diffs to create a new (sub)patch that might work for linux-edge. It would be an additional bit of ongoing work though
2020-12-17 16:14:06 <ncopa> would be for linux-lts for "production"
2020-12-17 16:14:24 <alpine-meetbot> minimal meant to say: ncopa: from the RPI patch currently used for linux-rpi it may be possible to extract only the overlay diffs to create a new (sub)patch that might work for linux-lts. It would be an additional bit of ongoing work though
2020-12-17 16:14:24 <minimal> s/-edge/-lts/
2020-12-17 16:14:42 <ncopa> that is a possibility
2020-12-17 16:14:53 <ncopa> the question is if we want those patches for everyone
2020-12-17 16:15:16 <minimal> that's the important stuff currently missing from upstream.
2020-12-17 16:15:33 <ncopa> i suppose the best thing woudl be to add them upstream
2020-12-17 16:16:49 <minimal> yeah, I haven't been tracking things to see why they're missing. The "source code" for the overlay is plain text descriptions, there must be a util to convert DTB to dtbo files.
2020-12-17 16:17:40 <mps> did I posted this morning here quote from Arnd Bergman article on lwn about jungle of dts file in mainline kernel
2020-12-17 16:17:42 <minimal> arch/arm/boot/dts/overlays/disable-wifi-overlay.dts for example is only 20 lines long
2020-12-17 16:19:17 <minimal> mps: didn't see that
2020-12-17 16:19:36 <mps> btw, this Arnds article is good overview about arm current status in kernel https://lwn.net/Articles/838807/
2020-12-17 16:22:20 <mps> 'In Linux-5.10, there are 452 devicetree files based on 76 SoCs, or 30 SoC families, far more than any other Arm core, and more than all non-Arm machines combined'
2020-12-17 16:23:14 <mps> cortex-a9
2020-12-17 16:24:01 <minimal> mps: wondering how the Nvidia purchase might affect Arm longterm........
2020-12-17 16:24:55 <mps> 'find arch/arm/boot/dts/ | wc -l' => 2189
2020-12-17 16:25:36 <mps> minimal: my crystal ball don't work for this
2020-12-17 16:25:56 <minimal> did you run that find on linux-edge or linux-rpi?
2020-12-17 16:26:32 <mps> imo, more important is what will happen with risc-v and how it will extinct arm
2020-12-17 16:26:39 <minimal> mps: I contracted at Arm last year but was nowhere near the CPU side of the business
2020-12-17 16:27:14 <mps> this count is from 5.10.1 mainline
2020-12-17 16:28:19 <minimal> right, if you do the same with linux-rpi then you'll see the missing overlay stuff for RPI in your count - 50-odd files at a guess
2020-12-17 16:29:17 <TBK[m]> I do not think the purchase of ARM has been approved as of yet, to my knowledge the UK might block it.
2020-12-17 16:29:59 <mps> hmm, just thought, maybe there overlay dts can be made as separate add on package for mainline -lts and -edge kernels
2020-12-17 16:30:10 <mps> s/there/these/
2020-12-17 16:30:10 <alpine-meetbot> mps meant to say: hmm, just thought, maybe these overlay dts can be made as separate add on package for mainline -lts and -edge kernels
2020-12-17 16:30:30 <minimal> yeah, that was sort of what I was getting to when I mentioned "extracting" the overlays from the existing RPI patch
2020-12-17 16:30:58 <minimal> that's assuming the DTBO "compiler" is already in mainline kernel, I assume so
2020-12-17 16:31:24 <mps> and by this everyone can make overlays for other SBSc also
2020-12-17 16:31:37 <mps> doesn't sound as bad idea
2020-12-17 16:31:56 <mps> SBCs*
2020-12-17 16:32:14 <minimal> have a look at the file arch/arm/boot/dts/overlays/Makefile inside the rpi-5.10.1-alpine.patch file (used by linux-rpi)
2020-12-17 16:33:44 <mps> I would left this to you because I don't have much experience with RPis
2020-12-17 16:34:50 <minimal> yeah, I'll look into it. Seems there's a "dtc" command in upstream for the compiling
2020-12-17 16:35:12 <mps> yes, it is in makedepends for kernels
2020-12-17 16:36:53 <minimal> I would like to use linux-edge - I always prefer to use upstream support hardware. These DTB overlays are drivers at all - in RPI they're a replacement for lack of ACPI for the kernel to discover devices. As an example, for the RTC I have the driver is in the upstream kernel, but the driver won't load unless the DTB overlay is configured in config.txt for the kernel to discover the hardware
2020-12-17 16:38:09 <minimal> s/are/aren't/
2020-12-17 16:38:09 <alpine-meetbot> minimal meant to say: I would like to use linux-edge - I always prefer to use upstream support hardwaren't. These DTB overlays are drivers at all - in RPI they're a replacement for lack of ACPI for the kernel to discover devices. As an example, for the RTC I have the driver is in the upstream kernel, but the driver won't load unless the DTB overlay is configured in config.txt for the kernel to discover the hardware
2020-12-17 16:38:56 <minimal> mps: right, I'll play with this to see if I can come up with a workable solution
2020-12-17 16:39:48 <minimal> TBK: whether or not the Arm purchase gets approved some unrelated bits of Arm have been spun off already
2020-12-17 17:48:21 <artok> let's see how emulated build goes
2020-12-17 17:50:32 <artok> xeon E5520 16 core doing docker image of aarch64 alpine and abuild there
2020-12-17 17:51:23 <minimal> artok: I tried to build-rpi using qemu-user in a docker container once on an 8-core laptop..........gave up as it would have taken days/weeks to complete
2020-12-17 17:52:32 <artok> that same abuild took 12hrs on rpi4 or so
2020-12-17 17:52:38 <artok> might have been more
2020-12-17 18:06:58 <artok> but yah, that older mac pro doesn't have anything more to do at the moment, I installed linux on that when I removed UAD DSP from it and started making music on my laptop
2020-12-17 18:31:29 <fcolista> anyone knows how to workaround the issue: /sys/class/net/eth0/operstate: No such file or directory  ?
2020-12-17 18:31:38 <fcolista> this happens if ip=dhcp is set on kernel parameters
2020-12-17 18:32:28 <fcolista> am I missing something to have network works before the initramfs is loaded?
2020-12-17 18:33:10 <minimal> network driver issue? with Realtek there was an issue with phy driver missing from initramfs
2020-12-17 18:38:23 <fcolista> i tried with qemu with e1000 driver, as well as on hw with via-velocity module
2020-12-17 18:41:06 <minimal> have you checked the initramfs contents to see the relevant driver is in it? is there anything in "dmesg" output about the driver?
2020-12-17 18:43:45 <fcolista> the driver fails only on boot:
2020-12-17 18:44:19 <fcolista> I'm checking the initramfs
2020-12-17 18:46:23 <fcolista> yeah...e1000 and via_velocity are missing from initramfs
2020-12-17 18:53:47 <minimal> the other thought I had was missing firmware
2020-12-17 18:54:10 <minimal> so for the missing drivers, add them to the /etc/mkinitfs/modules.d/network.modules file (from memory)
2020-12-17 18:54:21 <minimal> the rebuild initramfs
2020-12-17 18:55:06 <mps> fcolista: so no eth0 when you run 'ip l'
2020-12-17 18:55:30 <fcolista> mps, after it boots, eth0 takes the ip
2020-12-17 18:55:59 <fcolista> I'm trying to have network working *before* alpine boots
2020-12-17 18:56:00 <mps> hmm, then what is issue, I don't understand
2020-12-17 18:56:10 <mps> aha
2020-12-17 18:56:14 <fcolista> you can pass to kernel parameters ip=dhcp
2020-12-17 18:56:23 <mps> yes,ofc
2020-12-17 18:56:24 <fcolista> e.g. if you want to load an apkovl via network
2020-12-17 18:56:49 <mps> but then driver must be built in kernel, not as module
2020-12-17 18:58:09 <fcolista> mps, that makes sense
2020-12-17 18:58:30 <minimal> the initramfs can configure ip (via dhcp) - I'm working on getting LUKS-decrypt-via-SSH using it
2020-12-17 18:58:33 <mps> what bootloader you use
2020-12-17 18:58:42 <fcolista> mps, syslinux
2020-12-17 18:59:03 <mps> ah, syslinux can't do that, as u-boot can
2020-12-17 18:59:26 <fcolista> ah..
2020-12-17 18:59:37 <fcolista> didn't know that
2020-12-17 18:59:46 <fcolista> I'm booting via usb
2020-12-17 18:59:53 <fcolista> a minitx with via
2020-12-17 18:59:54 <minimal> from the mkinitfs source code:
2020-12-17 18:59:56 <minimal> "# if "ip=dhcp" is specified on the command line, we obtain an IP address
2020-12-17 18:59:56 <minimal> # using udhcpc. we do this now and not by enabling kernel-mode DHCP because
2020-12-17 18:59:56 <minimal> # kernel-model DHCP appears to require that network drivers be built into
2020-12-17 18:59:56 <minimal> # in the initrd should have been loaded."
2020-12-17 18:59:56 <minimal> # the kernel rather than as modules. At this point all applicable modules
2020-12-17 18:59:58 <mps> minimal: yes, but if I understood fcolista he wants kernel to use dhcp
2020-12-17 19:00:31 <mps> minimal: use tpaste please
2020-12-17 19:00:40 <fcolista> How then alpine is able to boot via pxe?
2020-12-17 19:00:52 <fcolista> how does the apkovl is loaded?
2020-12-17 19:01:50 <mps> fcolista: by loading initramfs, but again I think bootloader must 'know' how to configure net first
2020-12-17 19:02:09 <fcolista> yeah. So it's about syslinux not supporting it?
2020-12-17 19:02:22 <mps> I think OVMF support net config
2020-12-17 19:02:52 <mps> not sure about syslinux, but never seen net option for it
2020-12-17 19:03:13 <fcolista> https://wiki.archlinux.org/index.php/syslinux
2020-12-17 19:03:32 <fcolista> it's supported.
2020-12-17 19:04:02 <fcolista> Since this is part of initrd option, the module should be into initramfs
2020-12-17 19:04:08 <mps> ah I see
2020-12-17 19:05:29 <mps> http://boot.alpinelinux.org/
2020-12-17 19:07:06 <minimal> yupe
2020-12-17 19:07:33 <fcolista> umh...
2020-12-17 19:24:00 <fcolista> ok ,this is what I get now
2020-12-17 19:24:00 <fcolista> DHCP requested but not present in initrd
2020-12-17 19:24:11 <fcolista> https://github.com/alpinelinux/mkinitfs/blob/master/initramfs-init.in
2020-12-17 19:24:14 <fcolista> line 190
2020-12-17 19:25:25 <fcolista> I can go ahead and set a static ip address.
2020-12-17 19:30:57 <MY-R> https://wiki.alpinelinux.org/wiki/PXE_boot#Configure_mkinitfs_to_generate_a_PXE-bootable_initrd
2020-12-17 19:34:12 <fcolista> MY-R, thanks a lot.
2020-12-17 19:36:04 <fcolista> I'm working on having a custom image
2020-12-17 19:36:04 <fcolista> https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image_with_mkimage
2020-12-17 19:36:39 <fcolista> I need to understand how to integrate a "custom" mkinitfs with a "custom" image
2020-12-17 19:38:03 <fcolista> ok, figured
2020-12-17 19:38:07 <MY-R> fcolista: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/mkimg.base.sh#L294
2020-12-17 19:38:54 <fcolista> initfs_features="base network squashfs"
2020-12-17 19:39:06 <fcolista> initfs_features="base network dhcp squashfs usb"
2020-12-17 19:39:11 <MY-R> looks like update-kernel doing the job
2020-12-17 19:39:51 <MY-R> dont forget about "network"
2020-12-17 19:40:05 <MY-R> ah ye got it, me blind sry!
2020-12-17 19:40:43 <fcolista> MY-R, thanks you have putted me on the right track
2020-12-17 19:40:46 <MY-R> + e1000 drivers stuff
2020-12-17 19:41:03 <MY-R> np, gl! :)
2020-12-17 19:41:20 <fcolista> I'm playing with https://github.com/bjwschaap/alpine-lift
2020-12-17 19:41:37 <fcolista> and want to pass a yaml file to have alpine configured
2020-12-17 19:44:59 <minimal> fcolista: I'm the cloud-init maintainer if you're interested in trying that...
2020-12-17 19:45:08 <fcolista> <3
2020-12-17 19:45:21 <fcolista> I do
2020-12-17 19:46:10 <minimal> I don't build ISOs myself, though I do build prepped disk images ready to be dd'ed onto machines
2020-12-17 19:46:48 <minimal> alpine-lift is interesting as its trying to be compatible with a subset of cloud-init's YAML
2020-12-17 19:47:13 <fcolista> yes, looks simple and straightforward
2020-12-17 19:47:21 <minimal> though of course it doesn't have all the various cloud provider support
2020-12-17 19:47:40 <fcolista> I've not tried cloud-init as yet though
2020-12-17 19:48:22 <minimal> Yeah, the YAML is relatively straighforward. To be honest, most of my use of cloud-init is not for cloud purposes - rather for bootstrapping physical machines (x86 and RPIs) and non-cloud VMs
2020-12-17 19:49:14 <fcolista> minimal, I want to try that as well
2020-12-17 19:49:25 <fcolista> https://cloudinit.readthedocs.io/en/latest/
2020-12-17 19:50:43 <minimal> For my RPIs I have a prepped disk image that I copy onto SD Cards, then edit the YAML network-config and user-data files on the 1st partition to set things like hostname, IP, then stick the card in a RPI and boot.......and its ready to rock and roll
2020-12-17 19:51:09 <fcolista> my idea is having the same approach but via network
2020-12-17 19:51:28 <fcolista> you have a centralized provisioning server for differente alpine distro
2020-12-17 19:51:53 <minimal> there's 2 ways to do that - for "proper" cloud provider they have Metadata Services that cloud-init talks to to get the YAML
2020-12-17 19:52:33 <minimal> the other way is when the kernel cmdline is passed a URL to go fetch config from
2020-12-17 19:53:01 <fcolista> the second one it's easier
2020-12-17 19:54:36 <minimal> yupe, been meaning to set that up but haven't found a decent CMDB-type opensource project that I like to use as a basis for a central config store
2020-12-17 19:55:13 <fcolista> minimal, git? :)
2020-12-17 19:55:47 <minimal> I had in mind something like a JSON database
2020-12-17 19:57:00 <minimal> for the PXE stuff are you using iPXE?
2020-12-17 19:57:07 <fcolista> I don't use PXE
2020-12-17 20:01:32 <minimal> yeah, keep forgetting you're using ISO
2020-12-17 20:01:42 <fcolista> a USB, actually
2020-12-17 20:02:38 <fcolista> ok so now dhcp is working
2020-12-17 20:02:39 <fcolista> APPEND ip=dhcp modules=loop,squashfs,sd-mod,usb-storage quiet alpine-data=http://192.168.88.10/alpine-data.yaml
2020-12-17 20:02:59 <fcolista> but is unable to mount the rootfs
2020-12-17 20:07:34 <fcolista> ok I think I've found the issue..
2020-12-17 20:18:38 <Hello71> if you're using an initramfs there's very little reason to use kernel dhcp
2020-12-17 20:18:43 <minimal> fcolista: need any help?
2020-12-17 20:18:50 <Hello71> kernel dhcp is if you want to boot fully from kernel with nfs or cifs
2020-12-17 20:21:18 <fcolista> Hello71, I'm trying this: https://github.com/bjwschaap/alpine-lift
2020-12-17 20:21:45 <fcolista> and for what I understand, i need to have a working network interface in order to get the yaml file
2020-12-17 20:21:59 <Hello71> that's unrelated to kernel dhcp though
2020-12-17 20:22:29 <fcolista> why?
2020-12-17 20:22:45 <Hello71> if you're using an initramfs you're already in userspace
2020-12-17 20:22:51 <Hello71> just use udhcpc/dhcpcd
2020-12-17 20:23:15 <fcolista> so I need a prepared apkovl with networking up
2020-12-17 21:57:47 <Thermi> Hi, we're looking to replace the usage of berkeley db (bsddb) in some software with libmdbx, which is another embedded database library that is somewhat similiar to berkeley db, libmdbx is under the openldap license, so that's okay. Do any of you people have experience with libmdbx by any chance?
2020-12-17 21:57:56 <Thermi> (project page: https://github.com/erthink/libmdbx)
2020-12-17 22:40:12 <Hello71> fcolista: sounds plausible
2020-12-17 22:41:48 <Hello71> Thermi: seems not widely packaged https://repology.org/project/mdbx/versions
2020-12-17 22:42:05 <Hello71> https://repology.org/projects/?search=mdbx
2020-12-17 22:43:05 <Thermi> Yeah well I'll package it then for Alpine
2020-12-17 22:43:15 <Thermi> I don't need to support anything else than Alpine in the application
2020-12-17 22:44:38 <Hello71> if it's strictly better than lmdb shouldn't it be a dropin replacement?
2020-12-17 22:45:06 <Hello71> possibly needing new database
2020-12-17 22:57:04 <Thermi> It has its own API.
2020-12-17 22:57:21 <Thermi> The software in question isn't even available on Alpine yet.
2020-12-17 22:57:24 <Thermi> I'm working on doing that.
2020-12-17 22:57:46 <Thermi> So there are no databases that'd need to be rebuilt or something because they don't even exist yet :^
2020-12-18 00:54:13 <Ariadne> Thermi: i dont see any problem with using libmdbx for that
2020-12-18 00:55:03 <Ariadne> though: The next version is under active non-public development from scratch and will be released as MithrilDB and libmithrildb for libraries & packages. Admittedly mythical Mithril is resembling silver but being stronger and lighter than steel. Therefore MithrilDB is a rightly relevant name.
2020-12-18 00:55:21 <Ariadne> it may not be a good plan to use a database that is predeclared abandonware
2020-12-18 02:02:36 <Hello71> oh, this is the t1ha guy
2020-12-18 07:05:19 <ncopa> morning
2020-12-18 07:08:55 <ncopa> only edge armhf and armv7 are non-idle now
2020-12-18 07:09:19 <ncopa> maybe we can get all edge builders to complete today?
2020-12-18 07:14:52 <ncopa> caula fails on build-3-13-x86 due to: (4/39) Installing autoconf (2.70-r0)
2020-12-18 07:15:05 <ncopa> i thikn it was wise of us to downgrade it
2020-12-18 07:15:57 <ncopa> i just had to manually delete the autoconf-2.70 since main repo was not completed
2020-12-18 07:16:56 <Cogitri> Can we get backtraces from things building on the runners?
2020-12-18 07:17:28 <Cogitri> For some reason half of the ldc tests SEGFAULT on the builders but I can't reproduce that on my computer/laptop nor my x86_64 and aarch64 container
2020-12-18 07:35:57 <ncopa> which builder? build-3-13-x86_64?
2020-12-18 07:39:32 <Cogitri> edge x86_64 and aarch64
2020-12-18 07:39:52 <Cogitri> I disabled ldc a few days ago so it doesn't block the builders though
2020-12-18 09:37:02 <juli> hi i wanted to create a apk and i did it actually, but now after abuild -r i don't know how to proceed ...
2020-12-18 09:37:08 <juli> i have these two files:
2020-12-18 09:37:28 <juli> packages/testing/aarch64/APKINDEX
2020-12-18 09:37:31 <juli> and
2020-12-18 09:37:41 <juli> packages/testing/aarch64/julians_first_apk-0.1-r0.apk
2020-12-18 09:38:26 <juli> but if i run "sudo apk add --repository /home/julian/packages/testing/ julians_first_apk-0.1-r0" i get:
2020-12-18 09:38:29 <juli> julians_first_apk-0.1-r0 (missing):
2020-12-18 09:38:35 <juli> required by: world[julians_first_apk-0.1-r0]
2020-12-18 09:38:46 <juli> what did i do wrong?
2020-12-18 09:44:06 <MY-R> juli: did you try without version? sudo apk add --repository /home/julian/packages/testing julians_first_apk
2020-12-18 09:44:19 <ikke> ye,s indeed
2020-12-18 09:44:22 <ikke> without a version
2020-12-18 09:44:30 <juli> ah :) thank you it did work :D
2020-12-18 12:10:47 <ncopa> ikke: did you bootstrap rust on build-3-13-armhf?
2020-12-18 12:12:13 <ncopa> looks like you did. im uninstalling .rust-bootstrap
2020-12-18 12:14:46 <ncopa> im building rust on build-3-13-x86 now
2020-12-18 12:15:07 <Cogitri> ncopa: Got an update on the backtraces? Something I can help with? Otherwise 3.13 will be stuck on that eventually
2020-12-18 12:17:32 <ikke> ncopa: right, yes
2020-12-18 12:20:18 <ncopa> im trying to build ldc in my dev env now
2020-12-18 12:20:32 <ncopa> its built and running tests now
2020-12-18 12:28:44 <Cogitri> ncopa: Ok great, thanks
2020-12-18 12:50:21 <ncopa> it segfaults in my lxc env
2020-12-18 12:50:31 <ncopa> so i think i can reproduce it
2020-12-18 12:50:33 <Cogitri> Huh
2020-12-18 12:50:45 <ncopa> problem is that there is a ton of tests that fails
2020-12-18 12:50:46 <Cogitri> Weird, it passed on my aarch64 container on Alpine infra :o
2020-12-18 12:51:07 <ncopa> make: *** [Makefile:20: /home/ncopa/aports/community/ldc/src/ldc-1.24.0-src/runtime/druntime-test-thread/external_threads.done] Segmentation fault
2020-12-18 12:51:09 <Cogitri> Yes, I think any one of them will do, since they probably all segfault due to the same reason
2020-12-18 12:51:19 <ncopa> this is on x86_64
2020-12-18 12:51:46 <ncopa> any idea how i run this test alone?
2020-12-18 12:52:08 <Cogitri> Not sure to be honest, I haven't done that much with ldc's build system
2020-12-18 12:52:20 <Cogitri> I think it's possible to filter with ctest
2020-12-18 12:52:21 <Cogitri> Let me check
2020-12-18 12:52:38 <ncopa> i guess its ctest -I <num>,<num>
2020-12-18 12:52:53 <Cogitri> ctest -R '^testname' should work too
2020-12-18 12:53:16 <Ariadne> yeah i use ctest -R ^testname
2020-12-18 12:53:58 <Ariadne> Cogitri: why do we need LDC?  is GDC not good enough?
2020-12-18 12:54:26 <Ariadne> i may have already asked this question
2020-12-18 12:54:45 <Ariadne> but i think that it makes sense to invest time in the compiler which is portable to all archs
2020-12-18 12:54:58 <Ariadne> than chase something which only supports x86_64 and aarch64
2020-12-18 12:57:33 <ncopa> ok i can run a single test:
2020-12-18 12:57:41 <ncopa> ctest -R ^std.csv -I 1,1
2020-12-18 12:59:37 <Cogitri> Ariadne: GDC is very slow moving
2020-12-18 12:59:49 <Cogitri> As in the version of the D stdlib it ships is some 2 or 3 years old now
2020-12-18 12:59:54 <Ariadne> ah
2020-12-18 13:00:04 <Ariadne> even in gcc 10?
2020-12-18 13:00:43 <Cogitri> So it doesn't ship many of the musl improvements which were upstreamed and also isn't recent enough for most of the D packages
2020-12-18 13:01:35 <Ariadne> how can we get LDC on all archs?
2020-12-18 13:01:45 <Cogitri> And GDC also doesn't support for code generation thingies yet (like static foreach)
2020-12-18 13:02:29 <Cogitri> And yes, GDC 10 didn't update the stdlib from GDC 9 because the GDC dev was busy fixing/updating things in GDC itself
2020-12-18 13:02:35 <Cogitri> I think they want to update it for GCC 11
2020-12-18 13:04:08 <ncopa> ok.. how do i get a bactrace from this. there are like 20 files named 'core' and i dont have any evidence that it actually generates a core
2020-12-18 13:04:21 <ncopa> oh... i found it
2020-12-18 13:04:34 <Cogitri> As for LDC on all arches: armhf, mips and s390x probably won't happen (way too much effort and I'm not too enthusiastic investing that for arches which are dead or don't matter for D) x86 and armv7 should work again once the time64 patches are in shape and upstreamed
2020-12-18 13:04:57 <Ariadne> "don't matter for D"?
2020-12-18 13:05:26 <Ariadne> what if i want to deploy D code to my mainframe that i bought :)
2020-12-18 13:05:55 <ncopa> it means we cannot use D for anything critical like installer, or system tools
2020-12-18 13:06:02 <ncopa> i have a backtrace
2020-12-18 13:06:22 <Ariadne> yeah, i was wanting to write a new installer, and was thinking maybe use D for parts of it
2020-12-18 13:06:44 <Ariadne> (i'm planning to use notcurses for the frontend, so it looks nice in terminal, like FreeBSD's installer)
2020-12-18 13:09:14 <Cogitri> Ariadne: Sorry, should've said don't matter for me so I wouldn't want to invest my sparse OSS time into getting them running
2020-12-18 13:09:30 <Cogitri> I think gdc works on s390x
2020-12-18 13:09:33 <Ariadne> thats fair :)
2020-12-18 13:10:11 <Cogitri> Ah yes, gdc is on everything but ppc64le, I think that's still kinda broken in D's stdlib
2020-12-18 13:10:29 <Cogitri> D's stdlib really needs some sort of automatic binding generator from C headers, right now it's all manual
2020-12-18 13:10:51 <Ariadne> right now i am doing some critical batch processing (running quassel core, and hosting distfiles.dereferenced.org) on my IBM parallel enterprise server (z13 mainframe bought from uncle sam on the downlow with both A+B power cables plugged into the same breaker)
2020-12-18 13:12:36 <Cogitri> Ah, I run x86_64 on all of my machines (other than a few RPIs/OpenWRT routers) for the just works factor
2020-12-18 13:12:38 <Ariadne> as they say, if the mission is critical, so is the hardware
2020-12-18 13:13:27 <Ariadne> oh
2020-12-18 13:13:31 <Ariadne> this is just
2020-12-18 13:13:35 <Ariadne> i mean i bought this thing
2020-12-18 13:13:39 <Ariadne> so may as well use it, right?
2020-12-18 13:13:51 <Ariadne> and it works super good
2020-12-18 13:14:07 <Ariadne> alpine is the only s390x OS i was able to just install and have work out of the box without drama
2020-12-18 13:14:10 <Ariadne> :)
2020-12-18 13:34:35 <ncopa> i have a question about https://cateee.net/lkddb/web-lkddb/EFI_DISABLE_PCI_DMA.html I have set it to 'y' because it is the more "secure" setting, and thought that its better to be secure by default and let users set the boot option when it does not work
2020-12-18 13:34:57 <ncopa> we already have at least two users that needs to set the boot option, including myself
2020-12-18 13:35:08 <Cogitri> ncopa: Could you post the backtrace in !14364 ?
2020-12-18 13:35:20 <ncopa> so I wonder if we should set it to 'n', which is ther kernel default
2020-12-18 13:35:22 <ncopa> oh, right
2020-12-18 13:35:24 <ncopa> will do
2020-12-18 13:35:38 <ncopa> sorry was in a video call and then i forgot about ldc
2020-12-18 13:35:50 <Cogitri> Ah no worries. Thanks for looking into it! :)
2020-12-18 13:41:51 <ncopa> i posted a backtrace. I have no clue how to debug it
2020-12-18 13:45:18 <Cogitri> Hopefully Mathias Lang (D maintainer) knows what's up with that SEGFAULT
2020-12-18 13:58:13 <Ariadne> meanwhile, back to writing a wayland compositor that won't fall over every 10 minutes because kwin is junk
2020-12-18 14:17:50 <Hello71> ncopa: doesn't it say "This option will cause failures with some poorly behaved hardware and should not be enabled without testing."?
2020-12-18 14:19:31 <Hello71> given average x86 firmware quality, I would assume the majority of systems don't work
2020-12-18 14:23:09 <artok> 12h for that 16core x86_64 to build aarch64 kernel with qemu-static
2020-12-18 14:23:49 <artok> so basically it's rpi4 =D
2020-12-18 14:24:22 <artok> native build of kernel is less than 1h
2020-12-18 14:28:57 <artok> another wasted time statistics =)
2020-12-18 14:29:45 <artok> mps: did you have some more discussion of overlays/ dir with minimal?
2020-12-18 14:30:28 <artok> if that would be added as subpackage from linux-rpi, and linux-rpi depends on it, others may install it if wanted..
2020-12-18 14:37:26 <ncopa> Hello71: exactly. but it protects against "hostile devices" whatever that means
2020-12-18 14:37:51 <ncopa> artok: lol!
2020-12-18 14:38:15 <Hello71> if someone plugs in an fpga pci they can dma your memory
2020-12-18 14:38:25 <artok> =D
2020-12-18 14:38:41 <ncopa> fedora also has it 'n'
2020-12-18 14:38:48 <ncopa> i guess i should use the default
2020-12-18 14:39:42 <Hello71> the failure mode is really bad too. on my computer it just shows a black screen
2020-12-18 14:40:24 <ncopa> ok so it affects you too Hello71
2020-12-18 14:40:46 <Hello71> I don't use alpine on my desktop but yes, it's broken
2020-12-18 14:42:45 <Hello71> x86 firmware rule: if windows doesn't exercise it and oem is in charge of it, it's broken
2020-12-18 14:45:14 <Hello71> even if it should be stock edk2 code, odds are it'll still be broken somewhere
2020-12-18 15:06:05 <minimal> artok: Hi. The idea was whether creating an rpi-overlays package which armv7/aarch64 linux-edge (later linux-lts) depended on would then work for RPIs
2020-12-18 15:08:07 <artok> I just thought that would it be easiest technically to just let linux-rpi abuild to pack that rpi-overlays package?
2020-12-18 15:10:27 <minimal> well I thought the aim was to try and get linux-lts working by itself fully for RPIs (so that linux-rpi can in future be removed). So yes could generate overlays from linux-rpi or could do it from an independant package (which I think is better)
2020-12-18 15:16:47 <artok> if it just needs dtc, it's quite straight forward
2020-12-18 15:17:20 <ncopa> edge builders are all idle for the first time for weeks
2020-12-18 15:17:24 <ncopa> \o/
2020-12-18 15:17:35 <ncopa> im gonna tag a snapshot before something breaks again
2020-12-18 15:18:14 <ncopa> and snapshot tagged :)
2020-12-18 15:18:20 <mps> artok: minimal: these dtbos should be made as separate pkgs
2020-12-18 15:18:50 <minimal> yeah. I'm working on it currently, will see if it works this weekend. I did notice that in the RPI-specific patch in linux-rpi separate from the overlays dir there are some new DTBs for Pi400 and for PI4. Even if the overlays packaging works linux-edge still won't work for Pi400 or (some) Pi4s without those additional changes
2020-12-18 15:18:58 <mps> also, RPi boot loader can't load zImage-d kernels afaik
2020-12-18 15:19:01 <artok> mps, sure, separate pkgs, but separate abuild vs subpackage from linux-rpi
2020-12-18 15:19:17 <artok> mps correct
2020-12-18 15:19:36 <mps> this is another problem with runing mainline on RPis
2020-12-18 15:19:49 <minimal> Santa's sending me a Pi4 and Pi400 so I'll have more to play with then next few weeks
2020-12-18 15:19:57 <artok> problem is with 64bit
2020-12-18 15:20:06 <mps> but u-boot on them can quite fine load 'vmlinuz'
2020-12-18 15:20:07 <artok> 32bit runs zImage no prob
2020-12-18 15:20:29 <artok> arch people use u-boot + mainline
2020-12-18 15:20:46 <mps> compressed kernels boots fine on some other arm64
2020-12-18 15:20:50 <artok> ...not that they're quick updating the u-boot for the latest versio that would allow booting from usb..
2020-12-18 15:21:20 <minimal> ncopa: thought I saw you mention a couple of days ago you booted linux-lts on a RPI4 ok - was that armv7 or aarch64 and with normal bootloader or u-boot?
2020-12-18 15:28:49 <mps> artok: for some reason rpi zero boot loader doesn't boot linux-edge armhf, and I didn't looked much why
2020-12-18 15:29:46 <mps> I think crystal lang will not build on 3.13
2020-12-18 15:30:12 <mps> sorry, it will build but compiler test will fail
2020-12-18 15:30:45 <mps> and I think bug is in 'gc' pkg
2020-12-18 15:47:10 <Cogitri> ncopa: Thanks a lot for the help w/ ldc, I'll take a look later and see if I can get it fixed
2020-12-18 15:55:52 <bratkartoffel> can someone please merge the backported security upgrades for openjdk7? !15597, !15297 and !15298
2020-12-18 15:56:28 <Cogitri> I'm a bit scared that the buildeds get stuck again
2020-12-18 15:56:40 <Cogitri> ikke: Are you available to kill them in case that happens?
2020-12-18 15:57:06 <bratkartoffel> afaik it only happens with latest musl and gcc, so at least 3.10 and 3.11 should be safe
2020-12-18 15:58:28 <bratkartoffel> 3.12 should also be ok, although i'm not that confident
2020-12-18 15:58:34 <ikke> Cogitri: at least some point tonight
2020-12-18 16:01:23 <ncopa> i made it merge on CI success
2020-12-18 16:05:14 <bratkartoffel> thanks ncopa, but i think i canceled it by force-pusing my rebase on !15597
2020-12-18 16:05:46 <bratkartoffel> ah ok, it's back again. thanks!
2020-12-18 16:06:07 <Cogitri> 👍
2020-12-18 19:46:04 <Newbyte> is there anything in Alpine that provides libsystemd?
2020-12-18 19:48:26 <ikke> maybe https://pkgs.alpinelinux.org/package/edge/community/x86_64/elogind-dev
2020-12-18 19:48:33 <ikke> it has a libsystemd.pc file
2020-12-18 19:49:10 <Newbyte> elgoind?
2020-12-18 19:49:12 <Newbyte> oh
2020-12-18 19:49:12 <Newbyte> yes
2020-12-18 19:59:19 <maxice8> it only provides certain parts of systemd though
2020-12-18 20:02:28 <craftyguy> Newbyte: for the purposes of your phosh update, elogind-dev is sufficient
2020-12-18 20:02:34 <craftyguy> (but you already know that now :P)
2020-12-18 20:02:38 <ikke> Fun, I think we will be running more into "DeprecationWarning: Creating a LegacyVersion has been deprecated and will be removed in the next major release"
2020-12-18 20:07:08 <afontain_> Newbyte: fun fact, it also contains a dbus lib
2020-12-18 20:09:49 <ikke> https://github.com/pypa/packaging/issues/368
2020-12-18 20:11:33 <maxice8> can anyone find out why mkvtoolnix is failing on aarch64
2020-12-18 20:11:44 <maxice8> it appears from time to time and returns 404 when I try to get the log
2020-12-18 20:13:54 <ikke> on 3.13?
2020-12-18 20:15:41 <maxice8> yes
2020-12-18 20:23:38 <ikke> tpaste is not cooporating
2020-12-18 21:06:52 <bratkartoffel> !15597 automatic merge got canceled again, can someone please trigger again?
2020-12-18 21:07:58 <ikke> I'll just merge it, pipelines are green
2020-12-18 21:08:32 <ikke> TBK rebased it
2020-12-18 21:09:13 <ikke> merged
2020-12-18 21:10:43 <bratkartoffel> thanks :)
2020-12-18 21:35:08 <mps> hmm, we don't have perl-gtk3 pkg
2020-12-18 22:11:51 <ikke> maxice8: https://termbin.com/yso7
2020-12-18 22:17:35 <ikke> maxice8: I suspect its fakeroot
2020-12-18 22:47:24 <mps> 5.10 kernel is lts officially now https://www.kernel.org/category/releases.html
2020-12-18 23:42:38 <craftyguy> I need apk-tools to support triggering by file (and not just dir), so I'm thinking about implementing this: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10712
2020-12-18 23:43:26 <craftyguy> after about an hour of wandering through the apk-tools source, I have some ideas what might need to change, but I'm still unsure of a lot of it. I assume no one else is working on that 'issue'
2020-12-19 00:25:57 <tomleb> Hi, I've been told to ask my question here. Anyone got podman working with alpine?
2020-12-19 00:27:08 <tehcloud> as a host or container?
2020-12-19 00:31:22 <yjftsjthsd> host
2020-12-19 00:31:40 <yjftsjthsd> (sorry to butt in; I was following the other thread and am also very curious)
2020-12-19 00:32:38 <tomleb> host, yes
2020-12-19 00:36:18 <ipcloud> (sorry to butt in; I was following the other thread and am also very curious)
2020-12-19 00:37:48 <omni> I've had it working, but my setup seems broken now
2020-12-19 00:40:57 <ipcloud> omni: Did you look at other options? (not docker, not podman)
2020-12-19 00:42:14 <ipcloud> am I off and podman is good but tied to/heavy use of systemd?
2020-12-19 00:44:24 <tomleb> There's the --cgroup-manager which accepts either cgroupfs or systemd so maybe systemd is not required. I could ask in #podman.
2020-12-19 00:44:48 <tomleb> omni: What did you do to get it working when it was working?
2020-12-19 00:45:22 <omni> right, trying to figure that out
2020-12-19 00:45:46 <omni> but I think I only configured things in ~/.config/containers/
2020-12-19 00:46:53 <omni> I haven't had to use system-d for podman
2020-12-19 00:48:00 <omni> I needed to do container things and wanted to to them as a regular user
2020-12-19 00:48:26 <ipcloud> omni: I have a couple of machines (not alpine) running systemd podman alpine containers
2020-12-19 00:48:39 <omni> there's manuals with the podman-doc package
2020-12-19 00:51:03 <tomleb> I'm looking at the docs right now to build it. I guess as long as all dependencies build fine then it should work. and you got it working too. Is this something that could be added to alpine?
2020-12-19 00:51:30 <omni> oh, I installed from the @testing repo
2020-12-19 00:51:55 <tomleb> Oh, podman is in testing?
2020-12-19 00:52:07 <omni> so it is in testing and eventually it may show upp in community
2020-12-19 00:53:28 <tomleb> Ah, should've checked that first. What's the policy/process to make a package go from testing to community?
2020-12-19 00:55:14 <omni> I'm not involved enough to be sure
2020-12-19 00:55:21 <omni> there's also podman-compose in testing (=
2020-12-19 00:56:54 <tomleb> perfect, well, thank you all
2020-12-19 01:07:42 <omni> glhf!
2020-12-19 02:42:30 <TBK[m]> tomleb:  You can request a move by creating a MR or an issue ticket (gitlab.alpinelinux.org/alpine/aports). The rule of thumb is that the software should be stable, the aport of high quality and "owned" by a maintainer wanting to maintain it for an aport to be moved out of testing.
2020-12-19 05:40:47 <tomleb> TBK[m]: Great, thanks for the info
2020-12-19 08:56:36 <ikke> mps: the expected lifetime of 5.10 is quite short compared to other lts kernels
2020-12-19 08:58:21 <mps> yes, but till then there will be at least another one lts :)
2020-12-19 08:59:20 <ikke> sure, just interesting to see
2020-12-19 08:59:38 <mps> and two years are quite fine for alpine, we also support main for two years, so coincidence or what
2020-12-19 08:59:57 <ikke> 5.4 has 6 yers, 5.10 just 2 years
2020-12-19 09:03:27 <mps> earth is moving faster and faster every year
2020-12-19 09:06:31 <afontain_> meh
2020-12-19 09:07:00 <mps> heh, people wants impossible
2020-12-19 09:08:01 <mps> have a long term fixes and stable and at the same time new and 'shiny' features. hard to make such 'product'
2020-12-19 09:09:48 <mps> I can't wait first 5.11-rc1 to run it on my workstations, because there are new 'shiny'-es already merged
2020-12-19 10:31:53 <HRio> hmm, what should bring up network interfaces at boot in current edge?
2020-12-19 10:32:11 <ikke> HRio: still /etc/init.d/networking
2020-12-19 10:32:23 <HRio> https://git.alpinelinux.org/aports/commit/?id=69ac0711d35c69e5dc385d337b83c51c9978f62c
2020-12-19 10:32:34 <ikke> That's only for ifupdown-ng
2020-12-19 10:32:47 <ikke> HRio: apk fix openrc
2020-12-19 10:32:52 <HRio> seems to have removed if bringup durign boot in my laptop that tracks edge
2020-12-19 10:32:58 <ikke> ^
2020-12-19 10:38:58 <HRio> ikke: apk fix openrc, fixed it, thanks
2020-12-19 11:44:30 <ikke> awesomwm is failing, I guess to -fno-common
2020-12-19 11:52:04 <ikke> yup, fixed with -fcommon
2020-12-19 11:53:27 <mps> ikke: you saved me day ;)
2020-12-19 11:55:08 <ikke> hehe :)
2020-12-19 11:55:17 <ikke> were you looking at it?
2020-12-19 11:57:37 <ikke> https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common
2020-12-19 11:59:29 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15967
2020-12-19 11:59:47 <mps> no, I didn't, I saw your msg here that it failed and alarm raised in my head
2020-12-19 11:59:54 <ikke> aha, ok
2020-12-19 12:00:31 <mps> and just few minutes later msg that you fixed it
2020-12-19 12:01:52 <ikke> xmlsec seems to have some kind of issue with NSS
2020-12-19 12:59:09 <ikke> PureTryOut[m]2: kcalutils tests are failing on armv7. DndFactoryTest::testPasteAllDayEvent() Compared values are not the same
2020-12-19 13:36:56 <Hello71> shouldn't we bump openrc pkgrel?
2020-12-19 13:40:18 <Ariadne> it may help
2020-12-19 15:00:09 <ikke> hmm, elogind fails on mips, Unknown MIPS_ABI
2020-12-19 15:00:20 <ikke> _MIPS_SIM_ABI32 not deifned
2020-12-19 15:00:31 <ikke> and others
2020-12-19 15:29:05 <Ariadne> weird
2020-12-19 15:29:46 <Ariadne> those should be defined in asm/sgidefs.h
2020-12-19 15:31:49 <ikke> I don't see asm/sgidefs.h
2020-12-19 15:32:02 <ikke> there is sgidefs.h, but that uses those constants, it does not define them
2020-12-19 15:32:49 <ikke> asm/sgidefs.h is in linux-headers
2020-12-19 15:35:10 <Ariadne> perhaps elogind needs linux-headers, or perhaps we should move those defines to our sgidefs.h?
2020-12-19 15:57:17 <ikke> Ariadne: but is asm/sgidefs.h automatically included if you install linux-headers?
2020-12-19 15:57:22 <Ariadne> yes
2020-12-19 15:57:49 <ikke> ok
2020-12-19 15:58:36 <ikke> not sure if it makes sense, but it would be the quickest solution, I guess
2020-12-19 16:01:05 <Ariadne> we can just copy them
2020-12-19 16:01:19 <ikke> in sgidefs.h?
2020-12-19 16:01:44 <Ariadne> yeah
2020-12-19 16:03:15 <ikke> so patching musl
2020-12-19 16:03:39 <ikke> or?
2020-12-19 16:04:13 <ikke> ah, libc-dev
2020-12-19 16:05:26 <Ariadne> yeah libc-dev
2020-12-19 16:07:55 <ikke> hmm, I see sgidefs.h incldues asm/sgidefs.h
2020-12-19 16:08:11 <ikke> why does that not cause issues if linux-headers is not installed?
2020-12-19 16:35:34 <ikke> (in other words, I wonder how that even works)
2020-12-19 17:10:20 <skarnet> ah yes, a login daemon that needs details of the MIPS ABI
2020-12-19 17:10:23 <skarnet> very normal programming
2020-12-19 17:10:26 <ikke> :)
2020-12-19 17:11:10 <skarnet> when do we overthrow fdo and put them back in the garbage dump truck they came out from?
2020-12-19 17:12:30 <ikke> https://github.com/elogind/elogind/blob/master/src/basic/missing_syscall.h
2020-12-19 17:12:53 <ikke> apparently they do their own syscalls
2020-12-19 17:13:29 <skarnet> how to do sysdeps wrong
2020-12-19 17:14:24 <skarnet> istg I clicked 3 times and had a glance
2020-12-19 17:14:39 <skarnet> this whole repository is a lesson on how not to write C
2020-12-19 17:18:55 <ikke> Ariadne: linux-headers is already installed apparently
2020-12-19 17:19:01 <ikke> (49/79) Installing linux-headers (5.7.8-r0)
2020-12-19 17:19:37 <ikke> #ifdef ARCH_MIPS
2020-12-19 17:19:42 <ikke> Maybe that is the issue?
2020-12-19 17:20:02 <ikke> asm/sgidefs.h is only included if ARCH_MIPS is defined
2020-12-19 17:22:53 <Ariadne> shouldn't be?
2020-12-19 17:22:54 <Ariadne> idk
2020-12-19 17:23:16 <ikke> Where should ARCH_MIPS be defined?
2020-12-19 17:23:37 <Ariadne> hmm i see
2020-12-19 17:23:41 <Ariadne> in elogind
2020-12-19 17:23:50 <ikke> was checking the meson.build file
2020-12-19 17:24:01 <Ariadne> change ARCH_MIPS to _MIPS_SIM ?
2020-12-19 17:24:41 <ikke> That could work I guess
2020-12-19 17:27:09 <ikke> So something like this: https://tpaste.us/X1wl
2020-12-19 17:30:34 <Ariadne> yes
2020-12-19 17:30:37 <Ariadne> should get it done
2020-12-19 17:31:26 <ikke> testing it now
2020-12-19 17:44:10 <ikke> nice, someone made an MR to fix ldc
2020-12-19 17:52:33 <ikke> Ariadne: patch works
2020-12-19 18:21:25 <Ariadne> [10:11:07] <skarnet> when do we overthrow fdo and put them back in the garbage dump truck they came out from?
2020-12-19 18:21:31 <Ariadne> i'm working on it
2020-12-19 18:22:01 <Ariadne> right now i am writing my own wayland compositor because kwin keeps dying and sway is not what i want behavior-wise
2020-12-19 18:22:14 <Ariadne> though sway is super stabl
2020-12-19 18:22:15 <Ariadne> e
2020-12-19 18:22:26 <Ariadne> no complaints there, its a solid project
2020-12-19 18:22:45 <Ariadne> just not what i want re: window management :P
2020-12-19 18:23:51 <ikke> hmm, ap does not seem to catch dependencies in subpackages
2020-12-19 18:24:25 <ikke> docker-engine depends on tini-static, but ap recursive-deps does not return it
2020-12-19 18:24:47 <ikke> (problem is that tini-static is not built yet on builders, so packages depending on docker are failing
2020-12-19 18:25:02 <Ariadne> hmm
2020-12-19 18:29:30 <insep_> Ariadne: are you using some wayland lib for that?
2020-12-19 19:21:47 <Ariadne> insep_: at first i tried to use QWaylandCompositor (since all of my other GUI software that I've written uses Qt), but QWaylandCompositor has an incomplete and broken xdg-shell implementation
2020-12-19 19:22:29 <insep_> 
ACTION is not surprised

2020-12-19 19:22:37 <Ariadne> insep_: so now i am working with wlroots (made by ddevault) and it's quite pleasant, like his other software
2020-12-19 19:22:55 <Ariadne> sway is a really solid compositor, it's just that i don't want a tiling compositor
2020-12-19 19:23:03 <Ariadne> otherwise i would probably use sway :)
2020-12-19 19:23:29 <insep_> how much functionality are you going to implement in your compositor?
2020-12-19 19:23:35 <Ariadne> minimal
2020-12-19 19:23:47 <Ariadne> basically think xfwm but wayland
2020-12-19 19:24:00 <Ariadne> put windows on screen, make the decorations themable, call it a day
2020-12-19 19:24:11 <Ariadne> do one job, do it well :)
2020-12-19 19:24:13 <tehcloud> floating vs tiling?
2020-12-19 19:24:17 <Ariadne> yes
2020-12-19 19:24:21 <Ariadne> i want floating windows
2020-12-19 19:24:27 <tehcloud> might be a nice basis for a later more full featured floating wm
2020-12-19 19:24:36 <Ariadne> i'm open to adding more features
2020-12-19 19:24:51 <insep_> damn, i hoped for input-method-unstable :(
2020-12-19 19:25:00 <Ariadne> but for now my goal is to implement what i want in a way that is clean and simple to implement
2020-12-19 19:25:10 <Ariadne> and allow for future expansion
2020-12-19 19:25:34 <Ariadne> insep_: don't consider my pursuit of an MVP indicative of not accepting more features after the MVP :)
2020-12-19 19:25:40 <Ariadne> if they come with code, i'll merge it
2020-12-19 19:26:09 <Ariadne> but i am trying to bootstrap a stable wayland-based desktop environment, so i want to get the WM to the point where i can use it for daily tasks
2020-12-19 19:26:31 <Ariadne> if people want to add wobbly windows or whatever, and we can make it configurable, i'll merge it if the code is proper
2020-12-19 19:26:44 <Ariadne> i'm just not *personally* interested in usecases that don't benefit me
2020-12-19 19:26:59 <Ariadne> but i'll be happy to help people who want to take on additional functionality
2020-12-19 19:27:13 <Ariadne> wlroots makes enabling a lot very easy
2020-12-19 19:27:33 <insep_> are you writing it in c++?
2020-12-19 19:27:49 <Ariadne> no, i'm writing the compositor in C
2020-12-19 19:28:00 <Ariadne> no point in using C++ to drive a C framework
2020-12-19 19:28:02 <Ariadne> imo
2020-12-19 19:28:12 <tehcloud> <Ariadne> no point in using C++
2020-12-19 19:28:17 <tehcloud> I like that better :p
2020-12-19 19:28:29 <Ariadne> tehcloud: i like C++ for writing Qt apps
2020-12-19 19:28:39 <Ariadne> GTK is very repetitive
2020-12-19 19:28:48 <tehcloud> yeah, does make sense in that case... and I do write C++ myself when it makes sense
2020-12-19 19:28:54 <tehcloud> but I like to avoid
2020-12-19 19:28:58 <Ariadne> in audacious the qt side has more features in half the code
2020-12-19 19:29:21 <Ariadne> because GTK makes you spell everything out
2020-12-19 19:29:23 <Ariadne> every time
2020-12-19 19:29:34 <tehcloud> yeah, GTK is why I don't write graphical programs anymore
2020-12-19 19:30:13 <Ariadne> i just want to build something that is stable
2020-12-19 19:30:33 <tehcloud> I was an early GTK3 adopter and I had to rewrite stuff every time there was a minor release
2020-12-19 19:30:37 <Ariadne> yeah
2020-12-19 19:30:41 <Ariadne> so was audacious
2020-12-19 19:30:50 <Ariadne> we switched to qt because gnome people kept breaking our app
2020-12-19 19:31:01 <Ariadne> i think that lead to a lot of stubbornness on our side though
2020-12-19 19:31:11 <Ariadne> client side decorations can look really slick
2020-12-19 19:31:18 <Ariadne> but because gnome kept fucking us up
2020-12-19 19:31:29 <Ariadne> people aren't willing to think about stuff like that
2020-12-19 19:31:44 <tehcloud> yeah, I got less than civil responses when I asked questions about stuff that broke too
2020-12-19 19:31:52 <Ariadne> yeah
2020-12-19 19:32:09 <Ariadne> some canonical guy told us we needed to determine if we were a gnome app or an ubuntu app or something else
2020-12-19 19:32:17 <Ariadne> that's why we switched to qt
2020-12-19 19:32:22 <Ariadne> got tired of it :)
2020-12-19 19:32:49 <Ariadne> and qt is largely a good framework
2020-12-19 19:32:56 <insep_> at least you are not using imgui just not to participate in framework wars
2020-12-19 19:33:01 <Ariadne> its just qwaylandcompositor is shit :)
2020-12-19 19:33:22 <insep_> unlike some c++ dev in very big company does
2020-12-19 19:33:49 <Ariadne> but anyway, patches to this compositor are very welcome
2020-12-19 19:34:08 <Ariadne> i want to enable accessibility features like macos has
2020-12-19 19:34:16 <Ariadne> where you can hold down a hotkey and have it zoom
2020-12-19 19:34:30 <Ariadne> just, you know
2020-12-19 19:34:38 <Ariadne> you can't walk until you've crawled first
2020-12-19 19:34:41 <Ariadne> if that makes sense
2020-12-19 19:35:08 <skarnet> not for baby horses
2020-12-19 19:37:58 <Ariadne> well we ain't horses
2020-12-19 19:56:11 <skarnet> speak for yourself, you don't know anything about neigh
2020-12-20 01:48:46 <ipcloud> Ariadne: what is yor compositor?  I have sway and weston running ; and on another machine hikari (I like it)
2020-12-20 01:49:55 <ipcloud> specifically hikari is not on Alpine , but I think that would be great
2020-12-20 02:01:02 <Ariadne> hikari looks nice but not what i am looking for :P
2020-12-20 02:02:36 <ipcloud> i think a simple terms + browser + many desktops + stacking works good for me
2020-12-20 05:06:13 <maxice8> https://lists.alpinelinux.org/~alpine/devel/%3C86c7a81e-1640-7f82-9e13-dfdbe1aad07b%40gmail.com%3E
2020-12-20 11:04:22 <Thermi> Heyam please merge !16001 and 16000
2020-12-20 11:04:32 <Thermi> !16000
2020-12-20 11:05:32 <Thermi> First is an update to a release with a bugfix, the latter (!16000) is a bugfix to make the start_post action work
2020-12-20 14:52:18 <Newbyte> If I want to move a package from testing to community but the person hasn't replied to my email (and I've waited over a week), what might I do?
2020-12-20 14:58:36 <maxice8> depends on the person
2020-12-20 14:58:50 <Newbyte> could you elaborate?
2020-12-20 14:58:52 <maxice8> some people just contribute once and then disappear
2020-12-20 14:58:58 <Newbyte> oh, makes sense
2020-12-20 14:59:53 <maxice8> make an MR and try to tag their GitLab,  if they don't have a gitlab then it is mostly safe they are not around anymore
2020-12-20 15:00:03 <Newbyte> how do I know what their GitLab account is?
2020-12-20 15:00:42 <maxice8> That is the fun part
2020-12-20 15:00:59 <Newbyte> I looked the package's history and only you (I presume you're Leo) and Justin Berthault have touched it
2020-12-20 15:01:13 <ikke> Justin is still active
2020-12-20 15:01:16 <Newbyte> the maintainer is Stefan Wagner and I can't find anything when searching for that name
2020-12-20 15:01:33 <Newbyte> anything on Alpine's GitLab, that is
2020-12-20 15:01:44 <ikke> @stwa
2020-12-20 15:01:50 <maxice8> Justin is very active
2020-12-20 15:02:11 <Newbyte> as I said the maintainer is Stefan Wagner, not Justin
2020-12-20 15:02:19 <Newbyte> Justin has just touched the package
2020-12-20 15:02:24 <Newbyte> (upgraded it)
2020-12-20 15:02:36 <ikke> stwa: is here
2020-12-20 15:02:42 <Newbyte> nice, thanks
2020-12-20 15:03:21 <Newbyte> his profile on GitLab seems devoid of any recent contributions though
2020-12-20 15:19:22 <Newbyte> ikke:  would you be ok with moving py3-prawcore from testing to community?
2020-12-20 15:20:31 <ikke> yup
2020-12-20 15:20:48 <Newbyte> nice, thanks
2020-12-20 15:21:25 <ikke> means moving py3-praw as well
2020-12-20 15:21:47 <Newbyte> 👍️
2020-12-20 15:22:21 <ikke> well not necessarily, but makes sense
2020-12-20 15:22:46 <ikke> but py3-betamax*
2020-12-20 15:22:58 <ikke> that does need to be moved
2020-12-20 15:23:39 <Newbyte> actually py3-praw is the package I want to move but I already got permission for that, so now I'm getting dependencies
2020-12-20 15:23:45 <ikke> right
2020-12-20 15:23:54 <Newbyte> how come py3-betamax need to be moved?
2020-12-20 15:24:09 <Newbyte> dependency of praw?
2020-12-20 15:24:36 <ikke> of prawcore
2020-12-20 15:24:40 <ikke> checkdepends
2020-12-20 15:30:13 <maxice8> PureTryOut: 15936
2020-12-20 15:30:17 <maxice8> !15936
2020-12-20 15:32:18 <PureTryOut[m]2> What about it?
2020-12-20 15:38:57 <maxice8> just missed you already gave a review
2020-12-20 15:38:58 <maxice8> sorry
2020-12-20 15:39:17 <PureTryOut[m]2> Np 😛
2020-12-20 16:28:10 <ikke> maxice8: zstd is failing on armhf
2020-12-20 16:28:11 <ikke> bus error
2020-12-20 16:35:16 <maxice8> oof
2020-12-20 17:15:17 <maxice8> Ikke
2020-12-20 17:15:30 <maxice8> https://build.alpinelinux.org/buildlogs/build-3-13-armhf/main/zstd/zstd-1.4.8-r0.log can you get the log from this ? I'm filling a bug report
2020-12-20 17:16:50 <ikke> What log do you mean? That link already shows the log?
2020-12-20 17:18:17 <maxice8> Doesn't it have a .log file like autoconf that shows more information ?
2020-12-20 17:18:52 <maxice8> because that error message is not really helpful
2020-12-20 17:19:04 <maxice8> in the meantime anyone feel free to downgrade to 1.4.7
2020-12-20 17:26:29 <ikke> There is not really a log file
2020-12-20 17:26:35 <ikke> it's just a shell script that is being run
2020-12-20 17:26:50 <maxice8> ah
2020-12-20 17:26:54 <maxice8> ok, thanks for looking into it
2020-12-20 17:27:36 <ikke> It generates data, runs zstd -f on the generated file
2020-12-20 17:28:22 <ikke> you downgraded to 1.4.5?/
2020-12-20 17:30:05 <maxice8> yes
2020-12-20 17:30:09 <ikke> ok
2020-12-20 18:57:13 <ikke> nmeum: bear is failing now
2020-12-20 18:59:09 <nmeum> hehe
2020-12-20 19:01:34 <nmeum> hm
2020-12-20 19:01:40 <nmeum> it passes fine here both in rootbld and without it
2020-12-20 19:02:07 <ikke> maybe only on x86?
2020-12-20 19:02:33 <nmeum> looks like it, yeah
2020-12-20 19:04:03 <ikke> testing it
2020-12-20 19:05:51 <nmeum> hm
2020-12-20 19:05:56 <nmeum> lets see if it also happens on the ci...
2020-12-20 19:06:00 <nmeum> wanted to upgrade to 3.0.4 anyhow
2020-12-20 19:12:51 <nmeum> 3.0.4 passes on x86 !16014
2020-12-20 19:16:46 <ikke> nmeum: it did not fail in my x86 container
2020-12-20 19:16:50 <nmeum> ikke: hm, even 3.0.4 fails on the builders even though it passes on the ci. maybe a problem with the x86 builder?
2020-12-20 19:16:57 <nmeum> https://build.alpinelinux.org/buildlogs/build-edge-x86/community/bear/bear-3.0.4-r0.log
2020-12-20 19:23:06 <nmeum> maybe just disable the tests? idk, looks weird for sure
2020-12-20 19:25:54 <ikke> /bin/busybox" "/home/buildozer/aports/community/bear/src/Bear-3.0.4/test/cases/citnames/exit_code/exit_code_for_success.sh" "/home/buildozer/aports/community/bear/src/Bear-3.0.4/build/subprojects/Build/BearTest/cases/citnames/exit_code/
2020-12-20 19:25:56 <ikke> Output/exit_code_for_success.sh.tmp.commands.json"
2020-12-20 19:25:59 <ikke> this is suspect
2020-12-20 19:26:56 <ikke> you see that it passes the script directly to busybo
2020-12-20 19:26:58 <ikke> busybox
2020-12-20 19:26:59 <nmeum> yeah, not sure what's happening there, the invocation is wrong of cause but why only on x86?
2020-12-20 19:27:08 <ikke> yes, wondering why too
2020-12-20 19:27:29 <nmeum> maybe somekind of configuration that is unique to the x86 builder?
2020-12-20 19:27:57 <nmeum> the bear test script stuff is also horribly complicated *sigh*
2020-12-20 19:29:58 <nmeum> huh
2020-12-20 19:30:07 <nmeum> looks like these tests aren't even executed on the other architectures
2020-12-20 19:30:31 <ikke> oh, huh
2020-12-20 19:31:01 <Cogitri> Darn, test-built ldc to debug something but forgot to redirect the stdout&stderr to a file and my screen buffer just barely isn't big enough to reach back to the place where my debugging messages are printed :D
2020-12-20 19:31:17 <Cogitri> Time for yet another testbuild
2020-12-20 19:31:35 <ikke> yugh
2020-12-20 19:33:59 <ikke> maxice8: seems like suitesparse is still broken, seems to try to install things directly to /usr
2020-12-20 19:34:19 <ikke> /usr/local to be precise
2020-12-20 19:34:35 <maxice8> Huh
2020-12-20 19:34:58 <maxice8> Why do things pass in CI and then commit seppuku in the builders
2020-12-20 19:35:06 <ikke> no clue
2020-12-20 19:36:42 <nmeum> haha
2020-12-20 19:39:05 <nmeum> ikke: regarding bear: it seems that the tests are only run on x86 because /usr/bin/lit is only available on x86 but not on the x86_64 builders
2020-12-20 19:39:48 <ikke> aha
2020-12-20 19:40:24 <ikke> sigh
2020-12-20 19:41:03 <ikke> rust makedepends were still intsalled
2020-12-20 19:41:06 <ikke> installed
2020-12-20 19:41:09 <nmeum> lol
2020-12-20 19:41:13 <nmeum> how did that happen?
2020-12-20 19:42:05 <ikke> some crash where depends were not cleaned up properly I guess
2020-12-20 19:42:18 <nmeum> ah
2020-12-20 19:42:24 <nmeum> well, uninstalling them should fix the failure
2020-12-20 19:42:29 <ikke> yes
2020-12-20 19:42:41 <nmeum> with lit installed I can also reproduce the failure locally
2020-12-20 19:43:59 <ikke> I should've immediately checked /etc/apk/world
2020-12-20 19:44:21 <ikke> bear already succeeded
2020-12-20 19:46:55 <nmeum> I also figured out why the lit tests fail: the test script uses realpath on /bin/sh which causes that path to be resolved to /bin/busybox
2020-12-20 19:47:13 <nmeum> and then it attemps to execute shell scripts with /bin/busybox which doesn't work
2020-12-20 19:47:15 <ikke> right, I had some suspicion it was something like that
2020-12-20 19:48:01 <ikke> sounds broken
2020-12-20 19:48:21 <nmeum> no idea why you would do that though ':D
2020-12-20 19:48:22 <nmeum> yeah
2020-12-20 20:03:27 <nmeum> this lit test suite has so many additional issues, I will just refrain from enabling it I guess
2020-12-20 20:06:47 <ikke> nod
2020-12-20 20:48:38 <ikke> maxice8: are you looking at suitespares
2020-12-20 20:49:51 <maxice8> Yes got an MR open
2020-12-20 20:49:59 <maxice8> Am getting a cup of water atm will send number later
2020-12-20 20:51:02 <ikke> ok
2020-12-20 20:51:28 <ikke> !16016
2020-12-20 20:52:25 <maxice8> thanks
2020-12-20 20:52:38 <maxice8> yes, also Draft: will be the only work-in-progress marker starting from gitlab 14.0
2020-12-20 20:52:44 <ikke> yes
2020-12-20 20:52:52 <ikke> was aware of the switch
2020-12-20 20:52:56 <maxice8> rip WIP, a much better marker
2020-12-20 20:53:27 <ikke> still wonder why this does not happen in CI
2020-12-20 20:53:58 <maxice8> works locally
2020-12-20 20:54:15 <ikke> fails in my lxc container
2020-12-20 20:55:15 <maxice8> huh
2020-12-20 20:56:15 <ikke>   file cannot create directory: /usr/local/include.  Maybe need
2020-12-20 20:57:26 <ikke> but it's a fun concoction of a makefile calling a makefile calling cmake
2020-12-20 20:58:14 <maxice8> > insert link to "how to make package managers cry" talk
2020-12-20 20:58:35 <ikke> :)
2020-12-20 21:12:55 <opal> i updated https://gitlab.alpinelinux.org/alpine/aports/-/issues/12014 with an assertion message and notified #transmission about the issue
2020-12-20 21:13:28 <opal> i dont have an environment suitable for musl development right now so i dont even want to think about seeing if i can fix this myself
2020-12-20 21:14:00 <opal> would be nice to have one again but i have to clean up one of my home devices or something
2020-12-20 21:16:33 <opal> might at least take a visual look at the code
2020-12-20 22:50:59 <maxice8> !16022 Can someone test rootless X proposed here ?
2020-12-20 22:53:11 <Ariadne> rootless in what way
2020-12-20 22:53:45 <Ariadne> as in without root?
2020-12-20 22:54:34 <AinNero> i thought i was using rootless xorg all the time...
2020-12-20 23:06:47 <mps> maxice8: I run Xorg long time without setuid
2020-12-20 23:07:14 <maxice8> mps: good to know
2020-12-20 23:07:50 <mps> I'm starting it with 'slim' DM
2020-12-20 23:07:58 <AinNero> mps: do you also have a zombie process as child from /usr/bin/X ?
2020-12-20 23:08:20 <mps> no
2020-12-20 23:08:25 <mps> never
2020-12-20 23:08:39 <AinNero> i have one during the session, but it gets reaped afterwards
2020-12-20 23:09:10 <AinNero> so its not the setuid flags responsible for it
2020-12-20 23:09:27 <mps> I think so
2020-12-20 23:09:55 <mps> '-rwxr-xr-x 1 root root 2052424 Dec  2 01:20 /usr/bin/Xorg'
2020-12-20 23:10:03 <Ariadne> i tossed X out the window and made https://github.com/kaniini/hopalong
2020-12-20 23:10:15 <Ariadne> it's sway, but for people who don't want sway
2020-12-20 23:10:59 <mps> I still use mostly X apps and don't want to mess with wayland
2020-12-20 23:13:24 <Ariadne> well, Xwayland makes those apps work
2020-12-20 23:14:39 <mps> yes, but Xorg also :)
2020-12-20 23:17:49 <Ariadne> if you saw what i've seen
2020-12-20 23:17:57 <Ariadne> you wouldn't want Xorg anywhere near you
2020-12-20 23:18:02 <Ariadne> :)
2020-12-20 23:19:05 <AinNero> i doubt xorg is the only body in the cellar of the linux ecosystem
2020-12-20 23:19:44 <Ariadne> the XF86 side of Xorg is an eldritch horror of state machines guarded by mutexes
2020-12-20 23:20:15 <mps> well, all software is bad, if I want better life I wouldn't touch computers
2020-12-20 23:20:46 <Ariadne> this began as an attempt to figure out why X was stalling on both ARM and x86 for me since musl 1.2.1 upgrade
2020-12-20 23:21:17 <Ariadne> i concluded my time was better spent burning it all to the ground and putting in something sane instead
2020-12-20 23:21:59 <mps> I don't have any extraordinary problem, only usual ones
2020-12-20 23:22:32 <mps> and I run mostly on aarch64
2020-12-20 23:23:05 <AinNero> mps: rpi?
2020-12-20 23:23:14 <Ariadne> well, yes aarch64 greatly improves uptime on its own
2020-12-20 23:23:18 <Ariadne> x86 is just hopeless
2020-12-20 23:25:39 <mps> AinNero: no, chromebooks
2020-12-20 23:26:26 <Ariadne> yeah i run on chromebooks too :)
2020-12-20 23:27:13 <Ariadne> hmm
2020-12-20 23:29:39 <mps> only issue in last month on edge is firefox likes to crash, kill by OOM
2020-12-20 23:30:08 <mps> and ofc, not quite good some kernel drivers
2020-12-20 23:38:13 <mps> even didn't had to look at crystal build log failed on build-3-13-aarch64 builder to know where it will fail :)
2020-12-21 00:15:48 <Ariadne> mps: do you have 5.10 elm-oak kernel apk i can borrow?
2020-12-21 00:16:35 <halosghost> I'm a little annoyed with the pyinstaller devs
2020-12-21 00:16:47 <halosghost> why have such an extensive test suite if it fails everywhere on a ton of tests?
2020-12-21 00:16:49 <halosghost> what's the benefit?
2020-12-21 00:19:06 <halosghost> if I write a multi-hundred test test suite that takes over an hour to run (and fail) on every target platform, I assume I'd be fired
2020-12-21 00:19:33 <halosghost> it's libre (not corporate-backed), but I still don't get the benefit of such a thing
2020-12-21 00:19:45 <halosghost> I'm certain that no dev runs the test suite at that point
2020-12-21 00:19:48 <halosghost> what would running it show you?
2020-12-21 00:19:53 <halosghost> -_-
2020-12-21 00:19:53 <halosghost> /rant
2020-12-21 07:35:18 <ikke> morning
2020-12-21 08:05:19 <mps> ikke: goede morgen
2020-12-21 08:06:20 <ikke> dobro jutro
2020-12-21 08:06:23 <mps> Ariadne: sure, in a few hours I will put it somewhere on dev.a.o
2020-12-21 08:06:33 <mps> ikke: :)
2020-12-21 08:06:41 <ikke> добро јутро
2020-12-21 08:06:54 <mps> ah, this is even better
2020-12-21 08:08:03 <insep_> доброе утро
2020-12-21 08:09:19 <mps> insep_: you are russian or ukrainian?
2020-12-21 08:10:32 <insep_> russian
2020-12-21 08:10:57 <insep_> i believe it's different in ukrainian
2020-12-21 08:11:28 <mps> I can read and even speak somewhat russian but I'm bad at writing in it
2020-12-21 08:12:39 <mps> and I really don't understand what is ukrainian lang, it is baffling to me
2020-12-21 08:12:59 <insep_> it's доброго ранку in ukranian
2020-12-21 08:13:25 <mps> though I talked with people from Ukraine with much problems
2020-12-21 08:14:15 <mps> s/with/without/
2020-12-21 08:14:15 <alpine-meetbot> mps meant to say: though I talked without people from Ukraine with much problems
2020-12-21 08:14:28 <mps> uh, algitbot:)
2020-12-21 08:14:46 <mps> without much problems*
2020-12-21 08:16:46 <insep_> it's доброго ранку in ukranian
2020-12-21 08:17:49 <mps> I understand this also
2020-12-21 08:18:24 <insep_> uhhh i thought that i didn't send that message
2020-12-21 08:18:33 <insep_> because i still had it in buffer
2020-12-21 08:18:58 <mps> but this is sign of decadence of lang
2020-12-21 08:30:05 <mps> would anyone who have github account contact gc upstream and send backtrace from crystal test where it fails, here is bt https://tpaste.us/vZvB
2020-12-21 09:52:30 <ncopa> i saw something about gc in #musl a month ago or two
2020-12-21 09:52:33 <ncopa> morning
2020-12-21 09:52:37 <clandmeter> there is no way to add packages to an already existing virtual?
2020-12-21 09:52:47 <ikke> clandmeter: you need to repeat all the packages
2020-12-21 09:52:54 <clandmeter> ncopa: morning
2020-12-21 09:52:58 <clandmeter> and the rest :)
2020-12-21 09:53:17 <clandmeter> ikke: right, so thats a no :)
2020-12-21 09:53:30 <ikke> ncopa: edge is / was mostly green this weekend. Only suitsparse (which has an MR), and ldc on aarch64
2020-12-21 09:54:25 <ncopa> i saw. i tagged edge snapshot last friday :)
2020-12-21 09:54:37 <ikke> ncopa: ah, missed that :)
2020-12-21 09:54:47 <ncopa> i forgot to announce it :)
2020-12-21 09:55:08 <ncopa> would be nice if we could make 3.13 builders pass and get the rc1 out this week
2020-12-21 09:55:13 <ikke> One thing I noticed is that ap seems to miss dependencies defined in subpackages
2020-12-21 09:55:30 <ikke> docker-engine depending on tini-static
2020-12-21 09:55:32 <ncopa> brb
2020-12-21 09:59:51 <clandmeter> ikke: i remember it came up before and there was some request for a feature.
2020-12-21 09:59:59 <clandmeter> not sure it was ever added
2020-12-21 10:07:24 <ncopa> clandmeter: you should be able to `apk add --virtual somethign newpkgs` where newpkgs is the updated full list of new deps
2020-12-21 10:07:47 <ikke> so you cannot append to the list, only replace it
2020-12-21 10:08:11 <clandmeter> yes, its not a nice interface for scripting
2020-12-21 10:08:56 <clandmeter> we need crud :)
2020-12-21 10:08:58 <ncopa> you can append with: apk add --virtual .myvirtual $(apk info --depends --quiet .myvirtual) newpkg
2020-12-21 10:10:25 <clandmeter> what happens if by any means apk info fails?
2020-12-21 10:17:12 <ncopa> then you get newpkg as only dep
2020-12-21 10:20:30 <mps> ncopa: re gc on #musl, probably same what I posted here, iirc I talked with dalias a little about that on #musl
2020-12-21 11:05:45 <mps> Ariadne: https://dev.alpinelinux.org/~mps/ kernel and modules.
2020-12-21 11:06:55 <mps> kernel have to be 'dd'-ed to kernel partition, and it will use FS from partiotion next to the kernel one
2020-12-21 11:07:19 <mps> it can use root FS on ext4 and f2fs
2020-12-21 11:07:51 <mps> these drivers are compiled in kernel, other FSs are modules
2020-12-21 11:13:01 <minimal> mps: any of your ARM boards have RTCs?
2020-12-21 11:14:39 <mps> minimal: yes, exynos arm32, and two chromebooks
2020-12-21 11:14:55 <nmeum> any abuild rootbld users around?
2020-12-21 11:15:29 <mps> but I also added DSxxxx (forgot numbers) to two allwinners A20 boards
2020-12-21 11:16:09 <minimal> mps: thinking about linux-lts for Arm. Unlike x86 & x86_64 there's no standardised access to RTCs, so to support RTCs (whether onboard or aftermarket) properly would require building various drivers into the linux-lts kernels
2020-12-21 11:16:47 <minimal> on x86/x86_64 just need CONFIG_RTC_DRV_CMOS and you're done
2020-12-21 11:17:43 <mps> well, there are 'standard' drivers for some boards, for example my current arm32 router have it but need external battery (which I attached ofc)
2020-12-21 11:17:50 <mps> and it works fine
2020-12-21 11:18:02 <minimal> so for the Allwinner boards, the DS chips are i2c right? so you'd also need the relevant i2c board driver added to the kernel
2020-12-21 11:18:47 <mps> right, and who would make kernel for SBCs without i2c, spi etc
2020-12-21 11:19:03 <mps> gpio
2020-12-21 11:19:18 <minimal> multiple the various RTC chips (DSxxxx etc) and also the various board I2C drivers and the linux-lts armv7 and aarch64 will end up having a lot of studf builtin
2020-12-21 11:19:19 <Ariadne> mps: great.  will test
2020-12-21 11:20:29 <mps> Ariadne: it have configs.ko also to look configuration
2020-12-21 11:21:12 <Ariadne> i was going to try to get my compositor running on my elm-oak chromebook, but the graphics driver is still incomplete
2020-12-21 11:21:13 <mps> minimal: yes, look at armv7_defconfing in kernel configs dir
2020-12-21 11:21:51 <Ariadne> no ability to grab regions of vram
2020-12-21 11:23:21 <minimal> mps: for example, with current config-lts.aarch64 would need to set CONFIG_I2C_BCM2835=y and CONFIG_RTC_DRV_DS3232=y to support RPIs with typical commot RTCs
2020-12-21 11:24:24 <minimal> oops, sorry, should be CONFIG_RTC_DRV_DS1307=y not 3232
2020-12-21 11:27:06 <minimal> mps: the point being, the RTC (and supporting i2c board) driver need to be compiled in (not modules) to ensure system clock is set during early boot so avoiding OpenRC generating "clock skew" messages during boot
2020-12-21 11:50:44 <mps> minimal: question is, do we want big and inefficient kernel which covers everything or small and optimized ones
2020-12-21 11:51:23 <mps> you know about 'one size doesn't fit all' saying
2020-12-21 11:52:18 <minimal> mps: agreed. Its an issue with ARM ecosystem fragmentation, image if PCs/servers from Lenovo, HP, Dell, etc all needed different RTC drivers built into the kernel....
2020-12-21 11:52:59 <minimal> however I think having a functional RTC is quite important, plus the "clock skew" messages are quite annoying
2020-12-21 11:53:18 <mps> sure, I agree
2020-12-21 11:54:34 <minimal> Arm servers, seems a little easier, according to https://www.linaro.org/assets/downloads/VMSystemSpecificationForARM-v2.0.pdf seems they should support UEFI RTC (i.e. CONFIG_RTC_DRV_EFI))
2020-12-21 11:55:37 <minimal> so adding just that 1 entry to linux-virt for aarch64 might sort 90-ish% of aarch VMs
2020-12-21 11:56:12 <mps> hmm, isn't that already enabled
2020-12-21 11:57:39 <mps> hmmm
2020-12-21 11:59:30 <minimal> yupe it is enabled for linux-virt, not for linux-lts. Its unclear if any aarch64 physical servers can make use of CONFIG_RTC_DRV_EFI
2020-12-21 12:00:53 <minimal> I guess I was just originally stating the "obvious" - that the linux-lts armv7 and aarch64 will become large over time as more RTC (and supporting) drivers are compiled into the kernel for varying SBCs, etc
2020-12-21 12:01:22 <mps> (it's time for me to read at least one article about u/efi, how it works and what 'features' it have)
2020-12-21 12:08:05 <Ariadne> ARM is largely standardizing on EFI
2020-12-21 12:08:15 <Ariadne> EFI sucks but its better than the current shitshow :)
2020-12-21 12:08:23 <minimal> certainly the server stuff on ARM is going that way
2020-12-21 12:08:39 <Ariadne> even raspberry pi 4 you can use efi
2020-12-21 12:09:05 <minimal> Ariadne: its somewhat experimental on Pi4 AFAIK
2020-12-21 12:09:27 <Ariadne> sure
2020-12-21 12:09:36 <Ariadne> im just saying thats where the ecosystem is going
2020-12-21 12:09:43 <minimal> only just got my Pi4 so that's on my list of things to try
2020-12-21 12:10:07 <Ariadne> my honeycomb system boots with EFI (or you can use petitboot)
2020-12-21 12:10:22 <mps> minimal: you selected to use worst, imo
2020-12-21 12:10:34 <minimal> unrelated, on CI what's the solution to "The script exceeded the maximum execution time set for the job"
2020-12-21 12:10:47 <Ariadne> there is none
2020-12-21 12:10:55 <Ariadne> the time limit is hardcoded ;/
2020-12-21 12:11:13 <minimal> this is an MR I submitted that failed with this error on armv7 and aarch64
2020-12-21 12:11:27 <mps> it can be extended but I don't know how
2020-12-21 12:12:02 <minimal> I can guess why it failed - its a change to both linux-lts and linux-rpi - so obviously long compile times
2020-12-21 12:12:25 <Ariadne> what is the MR
2020-12-21 12:12:37 <minimal> !16036
2020-12-21 12:12:45 <mps> minimal: make small incremental changes
2020-12-21 12:12:59 <minimal> mps: is was a small incremental change
2020-12-21 12:13:14 <Ariadne> if pkgrel needs to be bumped
2020-12-21 12:13:26 <Ariadne> make sure to bump the kpkgrel on the out of tree modules
2020-12-21 12:13:27 <ikke> Ariadne: the time is adjustabe
2020-12-21 12:13:53 <minimal> Ariadne: ah, didn't think about that
2020-12-21 12:14:12 <mps> time is in ikkes hands :)
2020-12-21 12:14:21 <ikke> :D
2020-12-21 12:14:56 <minimal> so should I have submitted 2 separate MRs, one for linux-lts and other for linux-rpi? Its the same issue/fix so made sense for only 1 MR
2020-12-21 12:15:32 <mps> makes sense for git commit, but not for CIs
2020-12-21 12:16:18 <mps> anyway, I prefer minimal changes always when possible
2020-12-21 12:18:20 <minimal> mps: all my changes are minimal changes ;-)
2020-12-21 12:18:38 <mps> minimal:)
2020-12-21 12:19:58 <minimal> Ariadne: re: out-of-tree modules, in theory should their increments also be part of the same MR as a kernel package change? That would obviously increase the CI runtime even more
2020-12-21 12:23:10 <ikke> f++
2020-12-21 12:24:17 <afontain_> what does f++ means?
2020-12-21 12:24:48 <Ariadne> minimal: yes
2020-12-21 12:25:44 <minimal> Ariadne: yes it should be part of the same MR or yes it would obviously increase the CI runtime (and make time exceeded more likely)? ;-)
2020-12-21 12:40:09 <ikke> nmap license issues (gentoo thinks it's no longer FLOSS): https://github.com/nmap/nmap/issues/2199
2020-12-21 12:41:11 <minimal> so what's the suggested fix? should I remove the linux-rpi changes from !16036 and add the out-of-tree lts modules to the MR to make it about lts only and then submit a separate MR for linux-rpi and its out-of-tree modules?
2020-12-21 12:41:26 <ikke> minimal: yes, that makes sense
2020-12-21 12:46:43 <mps> minimal: for such changes related to kernel I usually create MR and assign it to ncopa, so he decide what to do with in next -lts upgrade
2020-12-21 12:47:08 <mps> sometimes he forget them :)
2020-12-21 12:48:19 <minimal> mps: I can do that, the current timeout issue is with the automatic pipeline build upon MR submission. I could ignore that ping ncopa to look at the MR anyway (I can't assign MRs to anyone)
2020-12-21 12:48:38 <mps> and looking on MR, it doesn't deserve separate git commit
2020-12-21 12:49:32 <mps> btw, I added findutils to linux-edge long time ago
2020-12-21 12:50:20 <minimal> my concern was that the possibility that the currently built kernel packages might not be 100% ok due to the error during build, though I haven't dug into the kernel Makefiles to see the implications of the "find -printf" failure
2020-12-21 12:51:39 <mps> minimal: your notice is correct, -lts need findutils, how we overlooked that? (I know but wont tell :) )
2020-12-21 12:52:32 <minimal> mps: I noticed your linux-edge had findutils deps right from the start ;-)
2020-12-21 12:53:40 <mps> yes, it is needed from 5.6 iirc
2020-12-21 12:54:03 <minimal> I found this last night while building stripped down kernels locally
2020-12-21 12:54:44 <mps> but I think you should make separate MRs, -lts and -rpi
2020-12-21 12:54:54 <mps> but .... :)
2020-12-21 12:55:36 <minimal> in future I will :-)
2020-12-21 12:56:50 <minimal> for now, have pinged ncopa on the current MR. Not sure whether to go ahead and close MR and open 2 new ones or whether to leave to him to decide what to do (he might have some other kernel changes to do and could wrap this into them in same MRs)
2020-12-21 13:24:15 <mps> minimal: 5.10.2 is just released
2020-12-21 13:24:46 <minimal> ok. so ncopa could roll the deps change in with that
2020-12-21 13:24:58 <minimal> assuming he notices my ping in the existing MR
2020-12-21 13:33:05 <bratkartoffel> openjdk7 built fine on 3.12, can someone please merge !15297 for 3.11?
2020-12-21 14:20:13 <kunkku> Ariadne: I encountered a minor issue with ifupdown-ng: the IF_ADDRESS variable passed to the scripts includes the prefix length, which it did not with BB ifupdown
2020-12-21 14:21:25 <Ariadne> i'm not sure if it is worth changing that
2020-12-21 14:21:39 <Ariadne> there are advantages to passing it with CIDR
2020-12-21 14:22:00 <kunkku> sure, but it's not bw compatible
2020-12-21 14:22:08 <Ariadne> hmm
2020-12-21 14:22:42 <Ariadne> i could add IF_ADDRESS_CIDR for that
2020-12-21 14:22:58 <Ariadne> that would restore backwards compatibility and allow users to choose which they want
2020-12-21 14:23:00 <Ariadne> :)
2020-12-21 14:23:11 <kunkku> sounds good
2020-12-21 14:23:17 <mps> or fix script to check format of IF_ADDRESS
2020-12-21 14:23:25 <Ariadne> that's also true
2020-12-21 14:23:27 <Ariadne> on debian
2020-12-21 14:23:32 <Ariadne> you can get CIDR in IF_ADDRESS
2020-12-21 14:24:21 <kunkku> has it always been like that, or did Debian break compatibility too?
2020-12-21 14:24:51 <ikke> mps: that means we need to find every script that uses this information and fix it
2020-12-21 14:25:27 <Ariadne> they changed it when debian ifupdown gained CIDR support
2020-12-21 14:25:39 <Ariadne> busybox i believe also passes through CIDR if you use CIDR support there too
2020-12-21 14:25:54 <Ariadne> however
2020-12-21 14:26:10 <Ariadne> IF_ADDRESS without CIDR and IF_ADDRESS_CIDR is fine
2020-12-21 14:26:17 <mps> ikke: how many scripts should be on list, I think not much but I didn't checked so I could be wrong
2020-12-21 14:26:40 <Ariadne> its not many scripts
2020-12-21 14:26:57 <Ariadne> endgame is to speak netlink directly where possible fwiw
2020-12-21 14:27:13 <Ariadne> those netlink helpers will just read the config file directly instead of use env vars
2020-12-21 14:27:15 <Ariadne> :)
2020-12-21 14:27:56 <kunkku> isn't it stupid to expose it to the scripts whether netmask or CIDR is used?
2020-12-21 14:30:01 <kunkku> (ofc these potential stupidities no longer matter from AL point of view)
2020-12-21 14:30:49 <kunkku> so let's just decide how ifupdown-ng will work
2020-12-21 14:31:16 <kunkku> I don't really care which way to do it
2020-12-21 14:41:15 <Ariadne> in this case, i think we should just standardize on CIDR then
2020-12-21 14:41:45 <Ariadne> CIDR is the standard way to do this these days so it just makes sense
2020-12-21 14:41:47 <ikke> yes
2020-12-21 14:41:49 <ikke> agreed
2020-12-21 14:41:57 <Ariadne> CIDR wasn't standard in 1997 when ifupdown was first made
2020-12-21 14:41:58 <Ariadne> :)
2020-12-21 14:42:08 <ikke> And consistent between ipv4/ipv6
2020-12-21 14:42:15 <Ariadne> ok
2020-12-21 14:42:24 <Ariadne> i guess discuss this in release notes for 3.13
2020-12-21 14:42:30 <Ariadne> "documentation bug" :)
2020-12-21 14:42:43 <kunkku> and fix all up/down scripts
2020-12-21 14:43:00 <ikke> https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.13.0#Switching_from_busybox_ifupdown_to_ifupdown-ng
2020-12-21 14:43:04 <Ariadne> which scripts depend on it being not CIDR?
2020-12-21 14:43:43 <kunkku> static-routing broke at least
2020-12-21 14:43:51 <kunkku> but the fix is trivial
2020-12-21 14:44:03 <kunkku> $IF_ADDRESS -> ${IF_ADDRESS%/*}
2020-12-21 14:44:37 <kunkku> didn't check other yet
2020-12-21 14:45:28 <minimal> Ariadne: minor correct, CIDR was around in 1997 (went I left the ISP industry), think it was from around '95 or so
2020-12-21 14:45:50 <Ariadne> i'm still working on bringing static-routing into ifupdown-ng
2020-12-21 14:46:03 <Ariadne> we're trying to determine what to call the vocabulary
2020-12-21 14:46:41 <Ariadne> (a design goal of ifupdown-ng is that all data in it can be mapped to an YANG vocabulary)
2020-12-21 14:47:10 <ikke> Heh, naming things
2020-12-21 14:47:26 <Ariadne> the hardest problem in computer science
2020-12-21 14:47:39 <Ariadne> 0.11 has some neat stuff
2020-12-21 14:47:51 <Ariadne> you'll be able to set up MPLS networks out of the box on alpine 3.14 :)
2020-12-21 14:48:21 <ikke> neat, now a usecess for mpls :P
2020-12-21 14:48:34 <minimal> what about frame-relay? lol
2020-12-21 14:48:56 <Ariadne> hmmph
2020-12-21 14:49:02 <ikke> Is that ATM?
2020-12-21 14:49:05 <Ariadne> i broke resize in my window manager when fixing pointer events
2020-12-21 14:49:22 <Ariadne> yes frame relay is a form of ATM
2020-12-21 14:49:27 <minimal> mpls is basically derived from frame-relay from memory
2020-12-21 14:49:58 <Ariadne> my first ISP job back in the day the owner was so proud because he had a 100% frame relay network
2020-12-21 14:50:03 <Ariadne> for his backbone
2020-12-21 14:50:27 <minimal> with a CIR of 0? ;-)
2020-12-21 14:50:27 <Ariadne> then carrier grade ethernet crushed his dreams 2 years later
2020-12-21 14:53:03 <minimal> remember Net99 - they became a backbone provider using something like 5 Cisco 3650s and T1s between them
2020-12-21 15:22:42 <Ariadne> nlayer is the more interesting story there
2020-12-21 15:22:49 <Ariadne> nlayer was largely tunnels at first :)
2020-12-21 15:23:21 <Ariadne> today you have stuff like megaport, which offers "transport" that is really tunnel over MTU=9000 transit link
2020-12-21 15:23:41 <ikke> hence megaport?
2020-12-21 15:24:02 <Ariadne> they call it megaport because you can buy from them and interconnect with like 30 IXPs
2020-12-21 15:24:40 <ikke> right, so an IXP for an IXP, I guess
2020-12-21 15:24:48 <Ariadne> but if you're in mumbai, there really isn't any point in remote peering at say, LINX imo
2020-12-21 15:24:48 <ikke> for IXPs
2020-12-21 15:25:26 <Ariadne> like the whole point of IXs is that latency is low
2020-12-21 15:26:33 <Ariadne> especially when you can get transit from Cogent and HE for $0.06/mbps
2020-12-21 15:27:40 <Ariadne> even more reputable carriers like zayo you can get pricing well north of $1/mbp
2020-12-21 15:27:43 <Ariadne> s
2020-12-21 15:28:02 <Ariadne> thats what enables businesses like megaport :)
2020-12-21 15:28:33 <Ariadne> transport and dark fiber products are now more expensive than just transit
2020-12-21 15:39:23 <minimal> Ariadne: back in the day I'd seriously considered using ISDN bandwidth on-the-fly to drop links into national peering location - this was in Europe in 95/96 when an ISP only having a 64K Internet connection was the norm.
2020-12-21 15:40:27 <minimal> e.g. 64K LL to IXP plus ISDN2 (2x64K) to give impression of 196K connection
2020-12-21 15:41:06 <minimal> s/196/192
2020-12-21 15:41:06 <alpine-meetbot> minimal meant to say: e.g. 64K LL to IXP plus ISDN2 (2x64K) to give impression of 192K connection
2020-12-21 17:28:39 <mps> ldc blocks aarch64 builder
2020-12-21 17:29:52 <ikke> yes
2020-12-21 17:29:52 <ikke> Cogitri: ^
2020-12-21 17:30:27 <Cogitri> Yuck, forgot to run abuild checksum
2020-12-21 17:30:33 <Cogitri> It should work after that for good :D
2020-12-21 17:31:05 <Cogitri> I should really come up with something nicer than git diff | wgetpaste on my lxc and then applying that on my local dev checkout
2020-12-21 17:32:38 <Cogitri> Ah whoops, the abuild helper script to run abuild in a podman container exits silently if the container didn't start yet
2020-12-21 17:32:41 <Cogitri> maxice8: ^
2020-12-21 17:33:18 <maxice8> @Cogitri I'll take a look at it later im going to birthday party
2020-12-21 17:33:28 <Cogitri> oki, thanks
2020-12-21 17:34:20 <maxice8> Open an issue on my github please
2020-12-21 17:36:57 <Cogitri> Could someone else run abuild checksum for ldc for me please? My ISP seems to have an especially bad today, takes 44 minutes to download the ldc tarball that's only a few mb big
2020-12-21 17:39:41 <mps> Cogitri: should I bump pkgrel
2020-12-21 17:40:01 <Cogitri> Nop
2020-12-21 17:40:05 <mps> ok
2020-12-21 17:40:11 <Cogitri> Only change behaviour on aarch64 and that didn't build yet
2020-12-21 17:40:18 <Cogitri> s/change/changed/
2020-12-21 17:40:18 <alpine-meetbot> Cogitri meant to say: Only changed behaviour on aarch64 and that didn't build yet
2020-12-21 17:44:16 <mps> hmm, git push didn't worked
2020-12-21 17:44:16 <Ariadne> ok
2020-12-21 17:44:16 <Ariadne> i will do some enterprise batch processing on my IBM parallel enterprise server model z13
2020-12-21 17:47:00 <ikke> seems like freenode had some issues
2020-12-21 18:29:38 <skarnet> understatement of the year
2020-12-21 18:47:10 <Thermi> Cogitri or maxice8 please take a look at !16000 and possibly merge it. It's a bug fix.
2020-12-21 18:48:11 <maxice8> Thermi am at birthday party
2020-12-21 18:48:15 <Thermi> Actually. Wiat Wait a second.
2020-12-21 18:48:16 <ikke> I'm looking
2020-12-21 18:48:18 <ikke> ok
2020-12-21 18:48:18 <Thermi> maxice8: And on IRC? :D
2020-12-21 18:48:26 <Hello71> maxice8: is it your birthday?
2020-12-21 18:48:41 <Ariadne> birthday party
2020-12-21 18:48:53 <maxice8> Thermi: yes
2020-12-21 18:48:54 <Ariadne> what does that even look like
2020-12-21 18:48:58 <Ariadne> during a plague
2020-12-21 18:49:00 <Thermi> maxice8: That's not how you party
2020-12-21 18:49:04 <Ariadne> or is this like a zoom birthday party
2020-12-21 18:49:22 <maxice8> Hello71: no
2020-12-21 18:49:50 <maxice8> Ariadne: just a bunch of people making bbq and resting on the pool since it is 30C
2020-12-21 18:50:19 <maxice8> And playing cards
2020-12-21 18:50:35 <Thermi> Have a conversation then
2020-12-21 18:53:09 <Thermi> Now. I added the argument to explicitely mention the pidfile location, so even if it changes at some point in the future, the script still works
2020-12-21 18:53:11 <Ariadne> wtf
2020-12-21 18:53:21 <Ariadne> brazil sounds great
2020-12-21 18:53:21 <Thermi> (The default value that is)
2020-12-21 18:53:28 <Thermi> Ariadne: ? :D
2020-12-21 18:53:53 <Thermi> Thanks for the merge, whoever did it. :)
2020-12-21 19:05:45 <Thermi> I rebased !16001 onto master, it should merge well now
2020-12-21 19:06:08 <Thermi> Ah ikke ty
2020-12-21 19:06:52 <ikke> np
2020-12-21 19:14:14 <maxice8> Ariadne: Brazil is very good at creating laws and not enforcing them.
2020-12-21 19:27:20 <Ariadne> i just forwardported my nano patch to allow disabling the titlebar
2020-12-21 19:27:33 <Ariadne> will send to FSF
2020-12-21 19:27:35 <Ariadne> i guess
2020-12-21 19:32:15 <mps> maxice8: then I would like to live in such country :)
2020-12-21 19:32:30 <mps> down all laws
2020-12-21 19:33:36 <ikke> inbefore mps moves to brazil
2020-12-21 19:34:07 <mps> heh, I have two friends from Brazil
2020-12-21 19:34:48 <mps> one is famous samba dancer girl and another is mma fighter
2020-12-21 19:38:53 <Thermi> ikke: tyvm!
2020-12-21 19:39:07 <ikke> np
2020-12-21 19:48:18 <skarnet> you have 2 friends from Brazil and they manage to perfectly embody the clichés about Brazil
2020-12-21 19:48:22 <skarnet> congratulations
2020-12-21 19:50:16 <mps> interesting, and I don't know any cliche about brazil. well samba is famous true
2020-12-21 19:51:47 <Thermi> Merge pretty please? !15862
2020-12-21 19:52:11 <mps> Thermi: samba :)
2020-12-21 19:52:19 <Thermi> Samba!
2020-12-21 19:52:23 <Thermi> samba?
2020-12-21 19:52:38 <Thermi> Samba.
2020-12-21 19:52:47 <mps> yes, I looked MR and forgot to merge few days ago, sorry
2020-12-21 19:54:35 <Thermi> mps: that is fine. Thank you!
2020-12-21 19:55:50 <mps> np, I moved liburing to main because of that MR and wait till builders finish, and they take some time. in meantime I forgot
2020-12-21 20:21:20 <Thermi> mps: pipelines passed
2020-12-21 20:25:27 <Thermi> mps: merge please?
2020-12-21 20:26:40 <Thermi> I just rebased into onto master
2020-12-21 20:28:53 <mps> yes, I'm looking and it is ready
2020-12-21 20:29:20 <mps> merged
2020-12-21 20:29:36 <Thermi> tyvm
2020-12-21 20:30:01 <mps> np :) thank you for adding vfs_io_uring
2020-12-21 20:57:22 <Thermi> Btw, I had some conversations with engineers at my company working with Alpine Linux and they'd like to have static, fixed per release or date folders on the package mirrors. One could do that using ZFS snapshots and making them via rsync/http. Is that viable?
2020-12-21 20:57:35 <Thermi> I'd put it together if interested
2020-12-21 20:57:46 <Thermi> Assuming you'd use it
2020-12-21 20:58:17 <ikke> Thermi: We tried something like that ourselves, but it quickly drained our available diskspace
2020-12-21 20:58:17 <Thermi> the folder structure would be something like alpine/packages-by-date/2020-12-21/allthepackagesandmirrorlistgoeshere
2020-12-21 20:58:34 <Thermi> ikke: I see. Even with ZFS snapshots and compression and deduplication?
2020-12-21 20:58:54 <ikke> It was something zfs based, but I don't know all the details
2020-12-21 20:59:16 <ikke> packages are compressed, so not sure how much deduplication helps
2020-12-21 20:59:21 <Thermi> With snapshots, only changed data is saved, and with deduplication, you can get what isn't tracked correctly
2020-12-21 20:59:31 <Thermi> deduplication on the FS block layer that is
2020-12-21 21:05:35 <Ariadne> Thermi: the ability to choose a given date for the archive would be cool
2020-12-21 21:05:46 <Ariadne> i was thinking about using ipfs for this
2020-12-21 21:06:18 <Thermi> well, it'd need to be provided by the mirror passively, or possibly with a parameter of the GET command that then, maybe transparently, opens the snapshot and mounts it
2020-12-21 21:06:23 <Thermi> although that could just be automated
2020-12-21 21:07:25 <Thermi> ipfs' distributed nature could be a source of possible problems with enterprises that want to or need to limit access of build servers and so on
2020-12-21 21:07:39 <Thermi> They probably don't like machines communicating with seemingly random IP addresses %)
2020-12-21 21:08:25 <Hello71> this in the vein of "ping is a security vulnerability"?
2020-12-21 21:09:00 <mps> Hello71: yes :)
2020-12-21 21:10:22 <mps> I still wonder why anyone is brave to use system for critial operations where I 'put' fingers
2020-12-21 21:11:02 <mps> and yes, I know that I use same system where other people 'put' their fingers :)
2020-12-21 21:16:04 <Thermi> So ... native ipfs support for apk coming or something? :P
2020-12-21 21:18:59 <Ariadne> probably not
2020-12-21 21:19:11 <Ariadne> i was going to say ipfs to http gateway
2020-12-21 21:19:12 <Ariadne> :P
2020-12-21 21:30:19 <Thermi> Aha
2020-12-21 22:12:24 <crosbymichael> Thermi: why don't you just run your own mirror internally?
2020-12-21 22:15:21 <Thermi> crosbymichael: I'll need to discuss that internally then. I don't know the reason for that, besides that everyone doing their own thing doesn't help others.
2020-12-21 22:15:56 <crosbymichael> not speaking on the behalf of alpine, i'm just a heavy user :)
2020-12-21 22:16:00 <Thermi> I see
2020-12-21 22:16:25 <Thermi> Well, other companies use Alpine Linux, too, so an improvement of the public infrastructure in that regard would benefit others too
2020-12-21 22:16:51 <crosbymichael> i would think for security reasons, an internal mirror fits best and you also have fast access to packages on large rollouts
2020-12-21 22:16:53 <Thermi> How large are the mirrors right now and what's the amount of data that changes over a month?
2020-12-21 22:17:04 <Thermi> (Just to get a kind of figure)
2020-12-21 22:17:20 <crosbymichael> i run a mirror, its only 500-600gb,
2020-12-21 22:19:54 <Thermi> I got a message that the issue is with mirroring from the official mirrors using http. They don't want to allow rsync from an internal network for some reason. When mirroring using http, when the contents of the upstream mirror change during the download, the resulting repo is inconsistent
2020-12-21 22:20:16 <Thermi> (broken dependencies, for example)
2020-12-21 22:22:00 <crosbymichael> sounds like a fun group of ppl ;)
2020-12-21 22:23:03 <Thermi> *shrug*
2020-12-21 22:23:12 <Thermi> I'm just the messenger
2020-12-21 22:23:24 <Thermi> So that's why we want versioned mirrors
2020-12-21 22:23:25 <Thermi> %)
2020-12-21 22:24:12 <crosbymichael> build it with symlinks?
2020-12-21 22:24:16 <Thermi> Maybe the problem could be solved by using HTTP/2 and requesting all files at the same time. That way the daemon should open all the files so when the contents are updated by replacing the files (exchanging directories), the same files are still referenced
2020-12-21 22:24:54 <Thermi> Well, it won't be atomic on the server side, in the daemon, or during transfer, but it'll be the best one can do in the situation
2020-12-21 22:27:40 <crosbymichael> sounds like a lot of code written when you could just rsync
2020-12-21 22:27:48 <kpcyrd> Thermi: 1) download and parse the database files 2) check which packages are referenced in the database that you currently don't have 3) download all missing packages 4) write the new database file 5) garbage collect all packages that are not referenced anymore 6) wonder if it was really worth it instead of using rsync
2020-12-21 22:28:23 <crosbymichael> kpcyrd: i choose 6
2020-12-21 22:29:11 <Thermi> kpcyrd: good idea. Are the database files signed?
2020-12-21 22:30:25 <kpcyrd> APKINDEX.tar.gz contains a file named .SIGN.RSA.alpine-devel@lists.alpinelinux.org-5261cecb.rsa.pub
2020-12-21 22:30:29 <kpcyrd> so I assume yes
2020-12-21 23:07:46 <Thermi> ty
2020-12-22 06:34:57 <ikke> Cogitri: "meson.build:1:0: ERROR: Executables created by D compiler gdc are not runnable." for openssl-d
2020-12-22 06:35:05 <ikke> on x86 3.13 builder
2020-12-22 06:43:06 <maxice8> big oof for D
2020-12-22 06:43:17 <maxice8> Ikke: I found an alternative to agl
2020-12-22 06:53:58 <ikke> Oh, something already existed?
2020-12-22 07:39:24 <ncopa> good morning
2020-12-22 07:45:04 <ikke> o/
2020-12-22 07:59:24 <maxice8> Morning ncopa
2020-12-22 07:59:34 <mps> \o
2020-12-22 07:59:57 <maxice8> Ikke: yes it did, I'm working with upstream to make it suitable and they went out of their way to package it for Alpine
2020-12-22 08:00:03 <maxice8> So I am very optimistic
2020-12-22 08:00:11 <ikke> cool
2020-12-22 08:00:15 <ikke> combined efforts
2020-12-22 08:01:13 <maxice8> https://github.com/profclems/glab/issues/created_by/@me
2020-12-22 08:01:24 <ikke> That link does not work for me :P
2020-12-22 08:01:34 <maxice8> derp
2020-12-22 08:01:37 <maxice8> !16051
2020-12-22 08:01:52 <maxice8> https://github.com/profclems/glab/issues/created_by/maxice8 try this one
2020-12-22 08:02:46 <ikke> That does work :)
2020-12-22 08:41:20 <Cogitri> ikke: Ah yes, gdc on 32-bit is still very unhappy apparently
2020-12-22 08:59:25 <ikke> py3-joblib is stuck on x86_64 3.13
2020-12-22 08:59:43 <ikke> seems the threads are still working, but not a lot is happening
2020-12-22 09:15:59 <ikke> dalias: not sure, but it seems like py3-joblib test suite is deadlocked: https://termbin.com/4544
2020-12-22 09:19:23 <ikke> I see 3 threads constantly running select() timing out
2020-12-22 09:26:21 <ozzz> hello guys, is there a way to obtain nbd module?
2020-12-22 09:26:35 <ozzz> or I should compile it manually
2020-12-22 09:27:00 <afontain_> I think I had it when I tried with linux-lts the other day?
2020-12-22 09:34:00 <afontain_> Turns out it was a pmOS question. Should be fixed soon
2020-12-22 09:36:13 <ikke> had what/
2020-12-22 09:36:16 <ikke> ?
2020-12-22 09:38:31 <afontain_> They were using the linux-asus-grouper kernel from pmOS, so asking how to enable nbd in that kernel was not a good question for Alpine folks and we moved to the main pmOS channel
2020-12-22 09:38:44 <ikke> right
2020-12-22 09:52:02 <ncopa> ozzz: i thnk we build the nbd module by default? which kernel do you use?
2020-12-22 09:54:10 <ozzz> ncopa, thanks, I asked question on wrong channel
2020-12-22 09:54:40 <ozzz> module was disabled in PMOS by default
2020-12-22 09:58:02 <ncopa> 👍
2020-12-22 09:59:54 <ncopa> mps: the new modules in qemu feb4aaf0bfc093ac5d122e9aef9ee43f6955629f are creating some issues for me
2020-12-22 10:00:08 <ncopa> qemu-system-x86_64: Virtio VGA not available
2020-12-22 10:00:42 <ncopa> my virt-manager did not start my vms due to audio modules was not installed after upgrade
2020-12-22 10:00:53 <ncopa> and it was non-trivial to figure out whoch package was needed
2020-12-22 10:01:09 <ncopa> now i have similar issue with "Virtio VGA not available"
2020-12-22 10:04:41 <mps> yes, new qemu is not 'polished' yet because upstream switching to meson build and that is fully done
2020-12-22 10:06:13 <mps> for me it works because I don't helpers (libvirt ...) but only cli and scripts, and mostly use consoles
2020-12-22 10:06:38 <mps> because that I didn't noticed issues you and some other have
2020-12-22 10:07:07 <detha> Do I see oddness in accessing git.a.o using ipv6? Pingable, but using https it seems to be ignoring me
2020-12-22 10:08:00 <mps> maybe solution for now is 'install all pkgs which begins with qemu*'
2020-12-22 10:18:29 <ncopa> i was thinking to have some install_if="spice-server" or similar would pull in all the spice modules if you have spice server installed
2020-12-22 10:18:37 <ncopa> similar for sdl and pulse audio etc
2020-12-22 10:19:19 <ncopa> so `apk add qemu` will not install spice or pulseaudio or sdl, but if you have any of those installed, support in qemu will automatically be enabled
2020-12-22 10:19:26 <mps> yes, looks like these will be needed
2020-12-22 10:19:57 <mps> especially if upstream build stays as it is now
2020-12-22 10:20:56 <HRio> ncopa: will that not make the dom0 from ram situation even worse?
2020-12-22 10:21:45 <HRio> I.e. even more qemu "crap" being pulled?
2020-12-22 10:22:03 <ncopa> not if you dont have the "crap" installed from before
2020-12-22 10:22:21 <mps> HRio: yes, but nowadays that is a 'solutions'
2020-12-22 10:22:34 <ncopa> qemu  will not pull in pulseaudio, spice or sdl dependencies
2020-12-22 10:22:50 <ncopa> but if you do have spice server installed qemu will support it
2020-12-22 10:23:19 <ncopa> seems like qemu-hw-display-virtio-vga needs qemu-hw-display-virtio-gpu
2020-12-22 10:23:28 <mps> f.e. sdl need qemu-opengl
2020-12-22 10:24:33 <HRio> the problem is that the current dependency chain for xen, actually installs spice-server
2020-12-22 10:24:53 <mps> uh
2020-12-22 10:24:55 <ncopa> ok
2020-12-22 10:25:04 <ncopa> but you dont want spice support?
2020-12-22 10:25:06 <ncopa> in qem?
2020-12-22 10:25:22 <HRio> I do not want qemu period :-)
2020-12-22 10:25:37 <HRio> I run pvh domUs
2020-12-22 10:25:53 <ncopa> what is pulling in spice-server?
2020-12-22 10:26:03 <ncopa> maybe we can split that out in xen package
2020-12-22 10:27:07 <HRio> Yes, I am working on a full qemu split
2020-12-22 10:27:36 <HRio> but there are a problem with the current xl tools that complain its not there even if it does not use it at all
2020-12-22 10:28:07 <HRio> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14877#note_131916
2020-12-22 10:28:45 <mps> !14877
2020-12-22 10:29:01 <mps> !14877#note_131916
2020-12-22 10:30:03 <ncopa> ok
2020-12-22 10:57:41 <mps> Ariadne: https://dev.alpinelinux.org/~mps/linux-elm-5.10.2-r0.apk
2020-12-22 11:02:57 <HRio> mps: seems the ! syntax (in algitbot) does not handle links to a specic note?
2020-12-22 11:03:09 <ikke> no, it's very stupid :)
2020-12-22 11:06:43 <ikke> HRio: https://gitlab.alpinelinux.org/alpine/infra/compose/algitbot/-/blob/master/sircbot/scripts/sircbot.lua
2020-12-22 11:36:30 <Ariadne> mps: thank
2020-12-22 11:41:09 <Thermi> ncopa: ty for the merges
2020-12-22 11:49:04 <ncopa> np
2020-12-22 12:01:51 <ncopa> i tagged 3.5.0_rc1. I hope nothing breaks...
2020-12-22 12:02:42 <ikke> ncopa: you might want to turn off travis-ci
2020-12-22 12:02:55 <ikke> "Please be aware travis-ci.org will be shutting down in several weeks, "
2020-12-22 12:02:56 <ncopa> ok?
2020-12-22 12:03:19 <ikke> The buid is failing as well
2020-12-22 12:03:23 <ikke> https://travis-ci.org/github/alpinelinux/mkinitfs/builds/751011562
2020-12-22 12:22:33 <Cogitri> ikke: Isn't it just a switch to travis-ci dot com ?
2020-12-22 12:22:50 <ikke> Cogitri: Not just
2020-12-22 12:23:06 <ikke> Cogitri: they are apparenly very limited in giving out credits to floss projects
2020-12-22 12:23:45 <Cogitri> Oh :/
2020-12-22 12:24:22 <ikke> So it's not worth it, just switch to our own CI
2020-12-22 12:25:53 <ikke> travis was both by a private equiti firm, which tries to make it profitable
2020-12-22 12:28:50 <Cogitri> Ah yes, I doubt many people paid for travis-ci.org
2020-12-22 12:29:32 <Cogitri> Void Linux did all of their CI test builds on their plaform, that sure wasn't cheap for them
2020-12-22 12:29:32 <ncopa> ikke: so simply delete .trais.yaml?
2020-12-22 12:29:50 <ikke> ncopa: I think so
2020-12-22 12:29:59 <Cogitri> Uh, if travis-ci.org goes down I better migrate my blog thingie to GitHub actions :D
2020-12-22 12:30:00 <ikke> maybe disconnect an app or something like that
2020-12-22 12:31:18 <ncopa> hum. stunnel tests on s390x are flaky
2020-12-22 12:31:35 <ncopa> tests passes but seems to deadlock on the cleanup occationally
2020-12-22 12:51:20 <ncopa> what does this mean? lto1: fatal error: bytecode stream in file '/usr/lib/python3.8/config-3.8-i386-linux-gnu/libpython3.8.a' generated with LTO version 9.0 instead of the expected 9.2
2020-12-22 12:52:46 <mps> hmm, what in cmake/c++ this means https://tpaste.us/jnve
2020-12-22 12:53:03 <mps> missing lib or build option?
2020-12-22 12:53:11 <ncopa> kind of annoying. seems like we need to rebuild libpython3.8.a when gcc updates
2020-12-22 12:53:29 <ncopa> undefined reference to `backtrace_symbols'
2020-12-22 12:53:48 <ikke> mps: mising -l* option to linker?
2020-12-22 12:53:48 <mps> yes, don't know what and why is this
2020-12-22 12:53:54 <ncopa> musl does not have backtrace
2020-12-22 12:54:30 <ncopa> best is to disable use fo backtrace_symbols in util_debug.cpp
2020-12-22 12:54:30 <mps> author told me in private mail that s/he built scribus on alpine
2020-12-22 12:54:50 <ncopa> second best is to use libexecinfo or what the lib was called
2020-12-22 12:55:09 <mps> i added libexecinfo-dev
2020-12-22 12:56:08 <mps> looks like author who posted it to aports ML simply copied arch PKBUILD and added some things
2020-12-22 12:56:21 <Cogitri> mps: then you have to add -lexecinfo to the linker cmdline
2020-12-22 12:56:25 <Cogitri> (LDFLAGS)
2020-12-22 12:56:49 <mps> Cogitri: aha, where should be added in cmake files?
2020-12-22 12:56:56 <Cogitri> The project probably doesn't link it by itself because it assumes the libc contains it
2020-12-22 12:57:02 <ikke> export LDFLAGS="$LDFLAGS -lexecinfo"
2020-12-22 12:57:15 <mps> thanks all, will test now
2020-12-22 12:58:31 <ikke> ncopa: you meantioned you wanted to build something like lua-atools in go, but I guess it can never be actually used on the builders, right?
2020-12-22 12:58:31 <mps> and one who invented PKBUILD to APKBUILD should go three days in corner and rest there on knees :)
2020-12-22 12:58:43 <mps> converter*
2020-12-22 13:07:30 <Hello71> detha: mtu
2020-12-22 13:08:51 <ikke> ncopa: py3-joblib is still hanging on x86_64, but I haven't killed it yet because wanted to give the chance to inspect it
2020-12-22 13:09:00 <ikke> (3.13)
2020-12-22 13:12:12 <ncopa> ok. i'll have a look
2020-12-22 13:13:22 <ikke> I've installed a few debug packages with a virtual package .debug
2020-12-22 13:14:42 <ncopa> looks like it deadlocks in pthread_cancel
2020-12-22 13:18:08 <ikke> How do you determine that?
2020-12-22 13:19:06 <ncopa> i did gdb -p <pid>
2020-12-22 13:19:11 <ncopa> and a backtrace
2020-12-22 13:20:14 <ikke> right https://termbin.com/4544
2020-12-22 13:20:48 <ncopa> i have no clue why
2020-12-22 13:21:02 <ncopa> im trying to reproduce in my dev env
2020-12-22 13:24:49 <ncopa> testsuite fails in my env. but does not deadlock
2020-12-22 13:25:06 <ncopa> i wonder if we can simply kill it and reboot the container and see what happens?
2020-12-22 13:27:00 <detha> Hello71: ah. that would explain yes. thanks
2020-12-22 13:30:06 <ncopa> there are new versions of it too, but they also fail. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14158
2020-12-22 13:31:28 <Hello71> ncopa, ikke: pthread_cancel is a red herring. that is just a wrapper to enable cancellation. the actual syscall is shown one stack frame up
2020-12-22 13:32:11 <ikke> _cp_end?
2020-12-22 13:32:12 <Hello71> I think this backtrace does not contain sufficient information to determine the issue. probably an strace (-f) from the beginning is required
2020-12-22 13:32:34 <Hello71> uh, down
2020-12-22 13:32:44 <Hello71> wait
2020-12-22 13:32:55 <Hello71> up in gdb terms, down in text terms
2020-12-22 13:33:00 <ikke> hehe
2020-12-22 13:34:19 <ikke> 0x00007f40ce0c3305 in select (n=n@entry=0, rfds=rfds@entry=0x0, wfds=wfds@entry=0x0, efds=efds@entry=0x0, tv=tv@entry=0x7f3fce8b4fd8) at src/select/select.c:38
2020-12-22 13:35:37 <Hello71> that's just a (complicated) sleep
2020-12-22 13:35:56 <ikke> ah, that explains what I see in strace
2020-12-22 13:36:18 <ikke> (on a running thread)
2020-12-22 13:38:43 <Hello71> select/poll allow the sleep to be accurately(-ish) restarted if a signal is received
2020-12-22 13:40:07 <Hello71> ah, no, it's because select/poll allow usec sleep durations before nanosleep
2020-12-22 13:44:46 <mps> huh, got scribus building by dirty hacks in scribus/util_debug.cpp
2020-12-22 13:45:04 <mps> now have to install it to see will it work
2020-12-22 14:02:16 <Hello71> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/python3/APKBUILD#L71
2020-12-22 14:31:13 <omni> is it just me who can't access https://git.alpinelinux.org over IPv6?
2020-12-22 14:32:23 <ikke> omni: You can if you override the ipv6 address :P
2020-12-22 14:32:55 <Hello71> i think it's been broken for a while actually
2020-12-22 14:33:36 <omni> just checkin' so it ain't no misconfiguration on my part
2020-12-22 14:45:40 <omni> but it's just for the web server
2020-12-22 14:46:24 <ikke> Yeah, I was working on fixing it, but because we used a cname for git.a.o, we cannot assign a different AAAA ip
2020-12-22 14:51:52 <omni> I'm not sure I follow, but I'm  a bit tired today
2020-12-22 14:52:11 <omni> bbl
2020-12-22 14:52:56 <Ariadne> is there a full set of alpine linux logos somewhere?
2020-12-22 14:53:14 <Ariadne> i've observed there is no package, but if there is a full set, i will package them :)
2020-12-22 14:54:00 <ikke> Ariadne: I'm not aware of anything
2020-12-22 14:54:20 <Ariadne> we should probably rectify this
2020-12-22 15:01:25 <TBK[m]> Ariadne: I have not yet replied to your ml post. I create a repo and MR yesterday for alpine-artwork.
2020-12-22 15:01:25 <TBK[m]> https://gitlab.alpinelinux.org/TBK/artwork & !16077
2020-12-22 15:02:02 <ikke> omni: it just means I need to make some DNS changes to get it to work properly
2020-12-22 15:13:46 <Ariadne> TBK[m]: since its just data, it can go into main without testing
2020-12-22 15:17:06 <TBK[m]> atm it is just a skeleton aport (feedback wanted + commits welcome) and I think the repo should be hosted under alpine with proper license files and usage guidelines.
2020-12-22 15:29:56 <ncopa> seems like iproute2 sources changed upstream
2020-12-22 15:30:04 <ikke> fun
2020-12-22 15:32:42 <ncopa> https://tpaste.us/kkQr
2020-12-22 15:33:27 <skarnet> Ariadne: about dnsfunnel (that was the only vaguely relevant name I could find that was not already taken). I'm nearing the point where it will be time to implement the query and response processing.
2020-12-22 15:34:19 <skarnet> (queries from clients, which may need to be transformed into several queries to the caches; and responses from caches, which may need to be processed before giving an answer to the client)
2020-12-22 15:34:20 <ikke> ncopa: clssic
2020-12-22 15:34:23 <ikke> classic*
2020-12-22 15:35:01 <skarnet> Ariadne: since every kind of processing comes with a drawback, I'd like to make them kinda pluggable.
2020-12-22 15:35:45 <skarnet> So: can you list the operations you'd like to (potentially) make to queries/responses?
2020-12-22 15:36:10 <skarnet> there will be a list of command-line options to activate/deactivate the workarounds and processing
2020-12-22 15:43:07 <dalias> ikke, any news on the py3-joblib thing?
2020-12-22 15:43:31 <ikke> dalias: ncopa was trying to reproduce it, but was not able to yet
2020-12-22 15:44:50 <dalias> select doesn't seem relevant; the first thread (13) is waiting on a semaphore
2020-12-22 15:46:24 <dalias> so is #4
2020-12-22 15:47:13 <dalias> and 3 and 2 and 1
2020-12-22 15:47:51 <dalias> something is presumably wrong with however it's using that semaphore
2020-12-22 15:55:05 <nmeum> anyone with ssh access to dev.alpinelinux.org around? seems to me fortify-headers upstream no longer provides tarballs so we need to create a snapshot via `abuild snapshot` in order to make it build again. I can't upload the snapshot though, see !16095
2020-12-22 15:57:16 <Ariadne> nmeum: yes i can do it
2020-12-22 15:57:21 <nmeum> ty
2020-12-22 15:58:26 <nmeum> not to happy with the version scheme change but unfourtunatly the default git snapshot function seems to enforce that
2020-12-22 15:58:30 <nmeum> *too
2020-12-22 15:58:47 <Ariadne> skarnet: mostly i'd like to see it truncate long responses or prefer a single set of responses instead of merging responses together
2020-12-22 15:59:31 <skarnet> yeah so I have an option to activate the truncation of long responses
2020-12-22 15:59:50 <skarnet> what do you mean merging responses together?
2020-12-22 16:00:44 <Ariadne> some DNS resolver libraries merge responses together if they are disparate
2020-12-22 16:00:49 <Ariadne> i think that's not good
2020-12-22 16:01:09 <skarnet> what does 'disparate' means in that context?
2020-12-22 16:01:14 <skarnet> mean*
2020-12-22 16:01:53 <Ariadne> say you have 3 resolvers, A, B and C
2020-12-22 16:02:01 <Ariadne> and then you make a query to some internal thing
2020-12-22 16:02:11 <Ariadne> A returns 1.1.1.1, B returns 2.2.2.2 C returns 3.3.3.3
2020-12-22 16:02:19 <Ariadne> it should only return one of those records, not all of them
2020-12-22 16:02:35 <ikke> ncopa: I think we need to remove iproute2 from distfiles?
2020-12-22 16:02:36 <skarnet> the other thing that dalias was talking about was caches incorrectly returning nxdomain instead of nodata in some cases; iirc the proper workaround is to always send a AND aaaa and if you get a nxdomain, wait for the other query to return in order to make sure
2020-12-22 16:02:37 <Ariadne> that way its consistent
2020-12-22 16:02:47 <Ariadne> yeah
2020-12-22 16:03:32 <Ariadne> other than that i look forward to implementing the skarnet stub resolver in alpine 3.14 :)
2020-12-22 16:04:04 <skarnet> well I can have an option to merge but I didn't even think it was even something that some people wanted
2020-12-22 16:04:23 <skarnet> by default you just get the packet from the first server that answers
2020-12-22 16:04:42 <skarnet> and if it's what you want then all good
2020-12-22 16:05:27 <skarnet> so 1. truncation of long responses, 2. check for incorrect nxdomain by sending AAAAA
2020-12-22 16:05:35 <skarnet> anything else?
2020-12-22 16:06:04 <skarnet> regarding truncation: if there are too many answers even after stripping the additional data, what should dnsfunneld do?
2020-12-22 16:06:07 <mps> 3.14 release, codename skalpine :)
2020-12-22 16:06:22 <skarnet> mps: won't be skalpine before s6-svscan is process 1 :P
2020-12-22 16:06:42 <mps> hehe
2020-12-22 16:06:47 <ikke> I would dub it alPIne
2020-12-22 16:06:58 <skarnet> should it strip the last answers until it fits? strip random answers?
2020-12-22 16:07:28 <skarnet> should it attempt to strip the ns section, if that's even legal (I need to check 1035)
2020-12-22 16:08:18 <skarnet> ikke: alpie
2020-12-22 16:08:31 <ncopa> ikke: i removed iproute2 from distfiles
2020-12-22 16:10:11 <ikke> ncopa: 2nd time it went through
2020-12-22 16:10:39 <ncopa> i updated the checksum and bumped pkgrel so we are sure we have the correct 5.10.0 everywhere
2020-12-22 16:11:08 <Ariadne> skarnet: i would say last answers, and if you can strip NS section may as well
2020-12-22 16:11:13 <Ariadne> though that may cause problems
2020-12-22 16:11:21 <Ariadne> we should test it
2020-12-22 16:12:01 <skarnet> yeah before stripping ns I will definitely refresh my memory on what it does exactly
2020-12-22 16:12:04 <Ariadne> mps: i'm enthusiastic about replacing crappy tools with good tools, regardless of who makes them :)
2020-12-22 16:12:06 <ncopa> dalias: im looking at an update of py3-joblib. testsuite seems to fail, but does not deadlock
2020-12-22 16:12:14 <dalias> skarnet, ariadne: note that always requesting both can be significantly slower if nobody else is making AAAA queries to keep the AAAA cached
2020-12-22 16:12:37 <skarnet> dalias: I know it will definitely be slower, that's why I want to make it pluggable
2020-12-22 16:13:11 <skarnet> dalias: if you have info on that bug: can the nxdomain be returned on either A or AAAA? or only on AAAA or something?
2020-12-22 16:13:23 <skarnet> because if A is always correct, then no need to request both on an A
2020-12-22 16:13:30 <Ariadne> also querying for AAAA is useless if you're in v4 only environment
2020-12-22 16:13:44 <Ariadne> similarly A for v6
2020-12-22 16:13:51 <skarnet> Ariadne: the content is independent from the transport
2020-12-22 16:14:08 <Ariadne> true
2020-12-22 16:14:22 <Ariadne> i'm just saying that in practice A vs AAAA does not matter so much if you are not dual stack
2020-12-22 16:15:11 <skarnet> normally I just transmit the exact queries from the client, so making policy here isn't my job. Sending both is only when the workaround is activated
2020-12-22 16:15:38 <skarnet> and in that case we don't care about the v4/v6 environment, we're just using the additional query to check for incorrect nxdomain
2020-12-22 16:15:51 <skarnet> and answering the initial query anyway whether it's A or AAAA
2020-12-22 16:16:11 <skarnet> just replacing nxdomain with nodata if required
2020-12-22 16:16:41 <dalias> skarnet, in theory it will do exactly the same on a domain where only AAAA exists
2020-12-22 16:16:47 <dalias> it's just that not many of those exist
2020-12-22 16:16:52 <dalias> but i personally have some
2020-12-22 16:17:19 <skarnet> okay so send both when receiving an A *or* an AAAA query, got it
2020-12-22 16:17:29 <dalias> i would just do the bug detection at init
2020-12-22 16:17:35 <dalias> when using a new upstream ns
2020-12-22 16:17:42 <dalias> probe it for invalid nxdomain
2020-12-22 16:18:28 <dalias> or do it until you see the first nodata then stop doing it
2020-12-22 16:18:33 <skarnet> that requires knowing a domain where there's an A-only or AAAA-only
2020-12-22 16:18:35 <dalias> or something like that
2020-12-22 16:18:49 <dalias> yeah
2020-12-22 16:18:59 <skarnet> so that depends on the state of the Internet, which I'd rather not do :D
2020-12-22 16:19:06 <dalias> btw my testcase was slackware.com :-p
2020-12-22 16:19:06 <skarnet> (or setting up a local domain etc. too complex)
2020-12-22 16:19:50 <skarnet> BREAKING: Alpine Linux uses slackware.com in its software
2020-12-22 16:19:57 <dalias> :-p
2020-12-22 16:19:59 <maxice8> nice
2020-12-22 16:20:22 <skarnet> the "stop at the first nodata" thing is a good idea though
2020-12-22 16:20:23 <exception> lol
2020-12-22 16:20:24 <dalias> because where else would you go first looking for leet legacy behavior? :-p
2020-12-22 16:22:21 <maxice8> any website with anything close to xXx_1337_xXx
2020-12-22 16:23:14 <Ariadne> we could designate a stable DNS name for these checks
2020-12-22 16:23:50 <skarnet> it's still at the mercy of the Internet
2020-12-22 16:24:00 <skarnet> and you know I don't want to embed policy in my software :)
2020-12-22 16:24:02 <Ariadne> skarnet: it seems to me like it wouldn't be hard to add additional sources outside of DNS/mDNS
2020-12-22 16:24:12 <Ariadne> perhaps, hesiod and similar could be added later
2020-12-22 16:24:29 <dalias> ?
2020-12-22 16:24:39 <dalias> additional sources aren't related to this
2020-12-22 16:24:39 <Ariadne> right now on glibc systems you would use NSS to query those non-DNS sources
2020-12-22 16:24:45 <Ariadne> yes i know
2020-12-22 16:24:57 <skarnet> as it is, dnsfunneld is easy because it's DNS-only, and pretty specific
2020-12-22 16:25:00 <skarnet> only IN class, etc.
2020-12-22 16:25:07 <Ariadne> i am just saying an ideal stub resolver would have the ability to plug in things that are non-DNS too
2020-12-22 16:25:12 <skarnet> if you want to be more generic then it's a whole other endeavour
2020-12-22 16:25:34 <skarnet> if you want nsswitch, start with using nsss and then we can talk
2020-12-22 16:25:37 <dalias> you might consider making it a unioning resolver
2020-12-22 16:25:46 <dalias> i.e. letting you specify N different upstream sources
2020-12-22 16:25:55 <Ariadne> hmm
2020-12-22 16:26:01 <Ariadne> i guess lets stick with DNS for now
2020-12-22 16:26:01 <skarnet> I very much dislike it when specs change after I've started coding
2020-12-22 16:26:15 <dalias> and accepting a non-nxdomain result as soon as you get one but nxdomain only after all return nxdomain
2020-12-22 16:26:19 <Ariadne> NSS is probably best handled with NSS
2020-12-22 16:26:20 <dalias> sorry :(
2020-12-22 16:26:42 <Ariadne> i know
2020-12-22 16:26:47 <dalias> fwiw i think most of the non-dns stuff is misguided
2020-12-22 16:26:48 <Ariadne> alpine can import systemd-resolved
2020-12-22 16:26:52 <Ariadne> and we can plug dbus into musl
2020-12-22 16:26:53 <skarnet> yes, if you want NSS stuff I have a package that does exactly that and if you need code that goes there I can do it
2020-12-22 16:26:58 <Ariadne> ^_^
2020-12-22 16:26:58 <skarnet> but it's not what dnsfunnel is about
2020-12-22 16:27:32 <Ariadne> yeah no i get it, keep dnsfunnel as dns :)
2020-12-22 16:41:19 <ncopa> PureTryOut[m]2: I am working on py3-joblib: this seems to work on x86_64, ppc64le and aarch64: https://tpaste.us/wPvv
2020-12-22 16:42:04 <ncopa> PureTryOut[m]2: do you think you can follow that up? i think we have a MR also
2020-12-22 16:43:57 <PureTryOut[m]2> There is an outdated MR from me yes. you can add that patch to !14158 if you want
2020-12-22 17:36:48 <ikke> fun, another project that recreated a release
2020-12-22 17:37:24 <ikke> https://tpaste.us/JYL0
2020-12-22 17:38:29 <Cogitri> Huh?
2020-12-22 17:39:09 <ikke> In the category: how to make package managers cry
2020-12-22 17:39:42 <ikke> one is from our distfiles, the other is from github
2020-12-22 17:41:05 <maxice8> They are installing musl on ubuntu then compiling it there and packing as an apk ?
2020-12-22 17:42:10 <ikke> Not sure if they are making an APK
2020-12-22 17:42:18 <ikke> they use musl because you can build fully static binaries
2020-12-22 17:43:21 <mps> debian have musl for long time
2020-12-22 17:43:47 <ikke> is it me, or are github actions a lot more elaborate as gitlab ci?
2020-12-22 17:43:48 <mps> I built some go programs few years ago on it using musl
2020-12-22 18:04:34 <mps> Ariadne: does linux-elm boot on you chromebook? did you tried?
2020-12-22 18:07:43 <Ariadne> have not tried yet.
2020-12-22 18:08:08 <mps> ok
2020-12-22 18:08:38 <mps> Linux arya 5.10.2-0-elm #1-Alpine SMP PREEMPT Tue, 22 Dec 2020 09:10:26 UTC aarch64 GNU/Linux :)
2020-12-22 18:11:11 <Ariadne> i'll try momentarily
2020-12-22 18:11:49 <mps> btw, do you run from external mmc or internal emmc
2020-12-22 18:11:59 <Ariadne> internal
2020-12-22 18:12:29 <mps> could you post cgpt show of your emmc
2020-12-22 18:13:01 <mps> I have to keep efi partition, without it my box doesn't boot
2020-12-22 18:13:35 <Ariadne> https://tpaste.us/8j4K
2020-12-22 18:16:19 <mps> aha, similar to my
2020-12-22 18:16:36 <Ariadne> 
ACTION ponders

2020-12-22 18:16:45 <Ariadne> i think having an alpine-developer-keyring would be nice
2020-12-22 18:16:57 <Ariadne> so i can apk add alpine-developer-keyring and get mps's public key
2020-12-22 18:16:58 <Ariadne> :)
2020-12-22 18:16:59 <mps> heh
2020-12-22 18:17:26 <ikke> for people who have access: http://wiki.alpin.pw/team/
2020-12-22 18:17:35 <ikke> though, mps' key is not there
2020-12-22 18:17:53 <mps> I didn't posted it :)
2020-12-22 18:18:01 <mps> maybe because of that
2020-12-22 18:20:19 <Ariadne> it boots
2020-12-22 18:20:37 <Ariadne> great work
2020-12-22 18:21:12 <mps> \o/
2020-12-22 18:21:38 <mps> there are some bugs
2020-12-22 18:22:13 <mps> but I will merge it to aports so you can help to have it in better shape
2020-12-22 18:22:59 <mps> touchsreen works when it is loaded/booted at some astrological time
2020-12-22 18:23:25 <Ariadne> neat
2020-12-22 18:23:33 <Ariadne> even wayland works (though only with llvmpipe)
2020-12-22 18:24:07 <mps> aiee, didn't tried wayland on it, only X
2020-12-22 18:24:26 <Ariadne> alacritty is pretty slow (not surprising)
2020-12-22 18:24:33 <mps> for sound you will probably need tweaks
2020-12-22 18:25:04 <mps> yes, gpu driver is missing and I doubt we will have it ever
2020-12-22 18:26:53 <Ariadne> sway is pretty fast
2020-12-22 18:27:55 <Ariadne> sound works
2020-12-22 18:28:04 <Ariadne> it glitches when first started
2020-12-22 18:29:47 <Ariadne> it would be nice to install a symlink /boot/vmlinux.kpart -> vmlinux-5.10.2-elm
2020-12-22 18:31:27 <mps> rationale? do we this for other kernels?
2020-12-22 18:31:41 <Ariadne> for other kernels we install with a stable name
2020-12-22 18:31:56 <Ariadne> to update the bootloader partition, i need a stable name :)
2020-12-22 18:32:07 <mps> ah understand
2020-12-22 18:32:31 <Ariadne> because then we just have a trigger which loads a config file
2020-12-22 18:32:33 <Ariadne> and then does
2020-12-22 18:32:40 <mps> I didn't yet finished install script which will dd it to kernel partition
2020-12-22 18:32:43 <Ariadne> dd if=$KPART of=$KERNEL_PARTITION bs=4096
2020-12-22 18:32:52 <Ariadne> that should be done as a trigger imo
2020-12-22 18:32:58 <mps> yes
2020-12-22 18:33:16 <mps> but have first to make script
2020-12-22 18:33:56 <Ariadne> but yeah not bad at all
2020-12-22 18:35:10 <mps> thanks :)
2020-12-22 18:35:46 <Ariadne> lol going to try to run kde plasma on the chromebook
2020-12-22 18:35:50 <Ariadne> this should be good for a laugh
2020-12-22 18:36:31 <mps> I even tried stellarium, well slow but usable
2020-12-22 18:37:29 <Ariadne> i'm waiting for lenovo to make a newer model based on the new mediatek laptop soc
2020-12-22 18:39:47 <mps> I'm waiting for risc-v notebook :)
2020-12-22 18:40:13 <Ariadne> well that is why i want to get riscv port going full throttle
2020-12-22 18:40:21 <Ariadne> i think its only matter of time really
2020-12-22 18:42:11 <Ariadne> hmm
2020-12-22 18:42:15 <mps> we will see, I hope not wait too long
2020-12-22 18:42:18 <Ariadne> the update-kpart
2020-12-22 18:42:23 <Ariadne> is probably also relevant for riscv64
2020-12-22 18:42:36 <Ariadne> since the bootloader they use is same as chromebook one basically
2020-12-22 18:42:49 <mps> really, didn't know
2020-12-22 18:47:12 <Ariadne> this is pretty great tho
2020-12-22 18:47:21 <Ariadne> i'll work on a bootloader update script
2020-12-22 18:47:28 <Ariadne> just give me my symlink :)
2020-12-22 18:49:38 <mps> sure
2020-12-22 18:56:08 <ikke> hmm, apparently labs.portcullis.co.uk is not trusted by curl, but it is by firefox
2020-12-22 18:57:13 <ikke> (acccheck comes from there)
2020-12-22 20:26:27 <Hello71> ikke: missing intermediate
2020-12-22 20:26:52 <ikke> Hello71: right, thanks, had the suspicion
2020-12-22 20:42:42 <mps> hmm 'if [[ $var =~ ^yY ]]' is not possible in ash
2020-12-22 20:43:56 <ikke> that's bash syntax indeed
2020-12-22 20:44:02 <ikke> use case instead
2020-12-22 20:44:19 <ikke> case $var in; y|Y)..;; esac
2020-12-22 20:45:13 <mps> aha, ok. wanted to not use case. thanks
2020-12-22 20:45:33 <ikke> case is pretty common
2020-12-22 20:47:16 <mps> what is 'default' in ash case construct
2020-12-22 20:47:33 <AinNero> mps: *) ... ;;
2020-12-22 20:47:55 <ikke> make sure it's last
2020-12-22 20:48:06 <mps> hmm, not that
2020-12-22 20:48:15 <mps> it is ugly
2020-12-22 20:48:24 <ikke> .
2020-12-22 20:48:25 <AinNero> i can recommend the #!/bin/mksh channel, not for mksh, but because the ppl there are quite knowledgeable about portable shell
2020-12-22 20:48:25 <ikke> ..
2020-12-22 20:50:27 <ikke> is the channel called literally that?
2020-12-22 20:50:38 <AinNero> yes
2020-12-22 20:50:41 <ikke> nice
2020-12-22 20:57:32 <mps> how to replace '/dev/mmcblk1p2' to '/dev/mmcblk1p1' in ash? "/dev/${device/%2/1}" doesn't work
2020-12-22 20:58:10 <ikke> just ${device/1/2} ?
2020-12-22 20:58:25 <ikke> sorry, the opposite
2020-12-22 20:58:27 <ikke> /2/1
2020-12-22 20:58:37 <mps> so simple
2020-12-22 20:58:47 <ikke> ofcourse, that does not do any anchoring
2020-12-22 20:59:07 <mps> yes, it works, thanks again
2020-12-22 21:00:24 <mps> I'm preparing linux-elm.install script and this is where I'm now https://tpaste.us/PKJb
2020-12-22 21:00:50 <ikke> echo ${device%?}1
2020-12-22 21:00:54 <ikke> that would also work
2020-12-22 21:02:51 <mps> 'device=echo ${device%?}1' ?
2020-12-22 21:03:26 <ikke> device=${device%?}1
2020-12-22 21:03:43 <mps> ah
2020-12-22 21:04:14 <mps> works
2020-12-22 21:04:19 <ikke> chop off the last character and append a 1
2020-12-22 21:04:35 <mps> I'm tired of 'thanks again' repetitions :)
2020-12-22 21:04:58 <ikke> just 'works' is enough :)
2020-12-22 21:06:31 <mps> we don't have any post install/upgrade script for kernels, but installkernel
2020-12-22 21:07:07 <ikke> what would a script like that do?
2020-12-22 21:07:39 <mps> dd linux to boot partition on chromebooks
2020-12-22 21:08:07 <mps> to kernel partition, which is boot partitions on chromebooks
2020-12-22 21:08:33 <mps> dd if=/boot/vmlinux.kpart of=${device}
2020-12-22 21:09:05 <mps> ohm, and 'reboot' should be added in script ;P
2020-12-22 21:09:54 <ikke> reboot before upgrading, then doing the upgrade, the reboot again? :P
2020-12-22 21:10:11 <ikke> and another time for good measure
2020-12-22 21:10:16 <mps> yes
2020-12-22 21:13:59 <mps> 'before cut three time measure', saying
2020-12-22 21:17:55 <Ariadne> the way i would do the kernel flashing is as a separate package which has a trigger
2020-12-22 21:18:19 <Ariadne> see the way syslinux is done
2020-12-22 21:24:26 <mps> Ariadne: I will push linux-elm and then you can add flash script. ofc if you want
2020-12-22 21:40:36 <mps> 3939b4fae669c913e62705754bfb4b951590fa8f
2020-12-22 22:02:51 <omni> packages amd-ucode and linux-firmware-amd-ucode seem to be built for all architectures?
2020-12-23 00:09:46 <Ariadne> mps: i am looking into extricating the binary blob imgtec driver from chromeos
2020-12-23 00:15:39 <maxice8> Ikke: Even in golang, pointers bit me
2020-12-23 00:24:19 <Ariadne> mps: bruh
2020-12-23 00:24:22 <Ariadne> mps: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/media-libs/arc-mesa-img/files/0001-dri-pvr-Introduce-PowerVR-DRI-driver.patch
2020-12-23 00:25:51 <Ariadne> wtffff
2020-12-23 00:25:54 <Ariadne> this is part of mesa
2020-12-23 00:35:33 <Ariadne> or not
2020-12-23 00:37:02 <Ariadne> there is sme imgtec-ddk thing
2020-12-23 05:38:19 <ikke> maxice8: how
2020-12-23 05:38:44 <maxice8> for-loops and using its value as &
2020-12-23 05:40:15 <craftyguy> this one is no longer WIP: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15045
2020-12-23 05:40:25 <craftyguy> (I'm not sure if it would get re-reviewed anytime 'soon' since its ~3 weeks old, which is why I thought to mention it here)
2020-12-23 05:40:43 <craftyguy> ha, already merged :P
2020-12-23 05:41:11 <craftyguy> maxice8 == Leo ?
2020-12-23 05:41:20 <maxice8> yes
2020-12-23 05:41:29 <craftyguy> thanks for your patience on that one :)
2020-12-23 05:42:16 <maxice8> welcome
2020-12-23 05:44:33 <insep_> maxice8: never had problems with pointers in d
2020-12-23 05:44:41 <insep_> maybe
2020-12-23 05:45:18 <insep_> except for that one moment when i forgot to allocate memory for clasd
2020-12-23 05:49:58 <maxice8> huh
2020-12-23 06:26:56 <craftyguy> what's the preferred way to run 'user' services with openrc (similar to systemd --user services)?
2020-12-23 06:28:30 <craftyguy> I guess setting 'command_user=' in /etc/init.d ? (which would require root to do..)
2020-12-23 06:33:12 <ikke> I'm not sure openrc has a good provision for that
2020-12-23 06:36:02 <halosghost> is there actually a plan for s6 to be a supported init?
2020-12-23 06:36:06 <halosghost> or is that a rumor?
2020-12-23 06:40:12 <ikke> halosghost: no short term plans
2020-12-23 06:40:33 <halosghost> fair
2020-12-23 06:40:45 <halosghost> I'm still kind of tempted to try and enable busybox's init and use that
2020-12-23 06:40:56 <halosghost> likely a gluttony for punishment there
2020-12-23 06:41:06 <ikke> fun fact: alpine uses busybox init :)
2020-12-23 06:41:17 <ikke> but not for managing services
2020-12-23 06:42:32 <halosghost> really? I didn't know that
2020-12-23 06:42:36 <halosghost> I thought it was disabled…
2020-12-23 06:42:38 <halosghost> iiiiiinteresting
2020-12-23 06:42:49 <halosghost> ikke: so, does that mean I could ostensibly use it for service management?
2020-12-23 06:43:15 <ikke> realpath $(which init)
2020-12-23 06:43:21 <ikke> /bin/busybox
2020-12-23 06:45:54 <ikke> halosghost: I guess so
2020-12-23 06:46:14 <halosghost> iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiinteresting
2020-12-23 06:52:24 <mps> lrwxrwxrwx 1 root root 12 Jul 18  2017 /sbin/init -> /bin/busybox
2020-12-23 06:56:49 <halosghost> I kind of love that idea…
2020-12-23 06:56:57 <halosghost> I don't really run a lot of services
2020-12-23 06:57:45 <ikke> Not sure how bb init would handle services thuogh
2020-12-23 06:58:30 <mps> bb runit as pid 1 :)
2020-12-23 07:05:55 <halosghost> ikke: I'm fine with run-commands in a dir
2020-12-23 07:06:02 <halosghost> like I said, I don't need many services :)
2020-12-23 07:07:20 <halosghost> honestly, I'm really enticed by this
2020-12-23 07:38:07 <maxice8> craftguy : unfortunately there is no equivalent to systemd-user for openrc
2020-12-23 07:38:20 <maxice8> One can run s6 in a user context though
2020-12-23 07:47:21 <ncopa> morning
2020-12-23 08:12:54 <mps> Ariadne: interesting patch but too big and I'm not good with gpu things to try anything with it
2020-12-23 08:14:40 <mps> and chromimos patches are not so easy to forward port to mainline software (ime), only some fixes are sometimes useful
2020-12-23 09:34:03 <nmeum> Ariadne: just a friendly reminder that you wanted to run `abuild snapshot` for !16095, just in case you forgot :)
2020-12-23 09:38:05 <ikke> sigh
2020-12-23 09:38:08 <ikke> why
2020-12-23 09:38:19 <ikke> (not this request, but upstream)
2020-12-23 09:39:30 <ikke> nmeum: Would it make more sense to just host a versioned archive?
2020-12-23 09:39:41 <ikke> They still have versions, just now hosted tarballs
2020-12-23 09:39:51 <ikke> s/now/not
2020-12-23 09:39:51 <alpine-meetbot> ikke meant to say: They still have versions, just not hosted tarballs
2020-12-23 09:40:37 <nmeum> I attempted to achieve that through reporev
2020-12-23 09:40:42 <nmeum> it still checks out the 1.1 tag
2020-12-23 09:41:12 <ikke> I don't think fortify-headers receive a lot of development, so somoene can just clone the repo, generate an archive and upload that to distfiles
2020-12-23 09:41:14 <ikke> or dev
2020-12-23 09:41:25 <Cogitri> Hm, what'd be the best way to make sure users don't have packages that aren't the latest version for some reason?
2020-12-23 09:41:36 <Cogitri> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12220 is probably happening because some package didn't upgrade properly
2020-12-23 09:41:47 <nmeum> ikke: yeah, but that's excactly what `abuild snapshot` is for, isn't it? ;)
2020-12-23 09:42:15 <ikke> nmeum: No, it's more for repos where they do not even have versions
2020-12-23 09:42:18 <nmeum> Cogitri: hehe, you are fast with handling assigned issues ;)
2020-12-23 09:42:25 <ikke> Cogitri: apk upgrade --available
2020-12-23 09:43:02 <nmeum> ikke: well, you can checkout repository revisions with abuild snapshot too so it works for that use case
2020-12-23 09:43:13 <ikke> nmeum: but you change the version scheme as well
2020-12-23 09:43:17 <ikke> which is not necessary in this case
2020-12-23 09:43:32 <ikke> just host fortify-headers-1.1.tar.gz and use that as the source
2020-12-23 09:43:54 <nmeum> I would consider the version scheme change a bug in abuild snapshot
2020-12-23 09:44:01 <nmeum> and the version base remains the same
2020-12-23 09:44:21 <nmeum> I just think its easier to upgrade this way
2020-12-23 09:44:24 <ikke> yes, but gets a _git suffix, giving the suggestion we do not use a released version
2020-12-23 09:44:51 <nmeum> yeah, I think abuild snapshot should not change the version unconditionally
2020-12-23 09:44:59 <nmeum> should I quickly come up with an abuild patch to work around that?
2020-12-23 09:45:39 <ikke> nmeum: tha assumption of snapshot is that you want to make a snapshot of some state that you cannot get from upstream (ie, they don't have tagged versions)
2020-12-23 09:46:35 <nmeum> well, but it's also the only way abuild has to handle repos if upstream doesn't provide a tarball
2020-12-23 09:47:24 <nmeum> I mean your suggestion and my implementation ultimately lead to the same thing: we generate a tarball from a git repo, upload that tarball to dev.al.org and add it to $source
2020-12-23 09:47:46 <nmeum> our point of disagreement is just whether or not that process should be automated
2020-12-23 09:47:55 <ikke> right, and whether it's worth it :)
2020-12-23 09:48:34 <ikke> last commit is 1.5 years ago
2020-12-23 09:49:01 <nmeum> tbh, if you really want to do the manual effort go ahead ;)
2020-12-23 09:49:18 <ikke> I think it's just a single command
2020-12-23 09:49:40 <nmeum> more or less, you also need to upload the tarball
2020-12-23 09:49:46 <nmeum> and pass the correct flags to git-archive
2020-12-23 09:49:48 <ikke> pipe git archive into scpo
2020-12-23 09:49:52 <ikke> yes
2020-12-23 09:50:01 <ikke> or into ssh in this case
2020-12-23 09:50:31 <nmeum> let me know when the tarball is available ;)
2020-12-23 09:50:34 <ikke> nmeum: so maybe just override snapshot in this apkbuild?
2020-12-23 09:50:53 <nmeum> provide a custom snapshot() function instead of using the default?
2020-12-23 09:51:06 <ikke> yes, because 90% of the functionality is not needed
2020-12-23 09:51:08 <nmeum> also possible, sure
2020-12-23 09:51:16 <nmeum> fine with me
2020-12-23 09:51:37 <Cogitri> nmeum: Ah yes, was looking at email when I got the email that I was assinged, so it was pretty good timing on your part :D
2020-12-23 09:54:50 <nmeum> ikke: though you just end up duplicating the commands that are already there
2020-12-23 09:55:35 <ikke> nmeum: it first clones the repo, which is not necessary
2020-12-23 09:55:47 <nmeum> why is cloning not necessary?
2020-12-23 09:56:26 <ikke> they expose the git protocol, you can directly get an archive from the remote
2020-12-23 09:57:05 <ikke> oh, but I see they disabled archiving :(
2020-12-23 09:59:13 <nmeum> does that change your opinion on the usage of the default snapshot function? :D
2020-12-23 09:59:30 <nmeum> if this is just about the version change for you (which I also don't like) a one-line change to abuild would fix that
2020-12-23 10:00:05 <nmeum> (e.g. only change the $pkgver in default_snapshot if $reporev is not set)
2020-12-23 10:04:39 <ikke> I think so, yes
2020-12-23 10:10:39 <nmeum> maybe something along the following lines? https://tpaste.us/R49v
2020-12-23 10:16:13 <ncopa> Ariadne: valgrind does not build on mips64: https://tpaste.us/9jE0
2020-12-23 13:35:10 <Ariadne> ncopa: softfloat
2020-12-23 13:36:59 <ncopa> ah, right. thats what i suspected
2020-12-23 13:37:25 <ncopa> so we need to change the hardfloat to softfloat there?
2020-12-23 13:40:08 <ncopa> ".set softfloat" ?
2020-12-23 13:40:11 <ncopa> does not seem to help
2020-12-23 13:49:21 <Ariadne> omitting the fpu register accesses entirely
2020-12-23 13:49:40 <Ariadne> $f registers are fpu registers
2020-12-23 13:51:18 <ncopa> oh
2020-12-23 14:01:53 <ncopa> Ariadne: can you help me fix it? or do we disable valgrind on msip64?
2020-12-23 14:03:43 <Ariadne> lets disable for now
2020-12-23 14:03:46 <Ariadne> can revisit later
2020-12-23 14:11:00 <mps> mips64 doesn't have FPU?
2020-12-23 14:12:39 <ikke> buggy FPU according to Ariadne
2020-12-23 14:13:23 <mps> aha
2020-12-23 14:13:43 <mps> there is FPU which is not buggy :P
2020-12-23 14:48:52 <Ariadne> mips64 fpu is really buggy
2020-12-23 14:49:05 <Ariadne> the bugginess varies from part to part even
2020-12-23 15:03:43 <mps> I have big dilemma about !16093
2020-12-23 15:04:39 <mps> original author of apkbuild told me in private mail that s/he will send me fixed version but didn't
2020-12-23 15:05:34 <mps> and original apkbuild is/was not good, I fixed it a little, to the point scribus builds
2020-12-23 15:07:23 <mps> I would ask (by mail) author to take it from the current state and fix it more but not sure is it good idea to have maintainer who is not careful enough for (well) good software
2020-12-23 15:08:46 <mps> making new apkbuild from 'clean' where I'm maintainer doesn't sounds as 'good' (we will be unpleasant to new contributors) or kind idea
2020-12-23 15:08:54 <mps> huh, what to do?
2020-12-23 15:09:13 <mps> would be nice to have scribus in 3.13
2020-12-23 15:25:21 <wsinatra> Hmm when I was first getting started a few people had to step in and correct things that weren't connecting with me until I actually read the APKBUILD documents
2020-12-23 15:26:06 <wsinatra> could be a similar situation where the contributor just feels overwhelmed? I honestly really appreciate all of the time and effort you guys put in to help people contribute
2020-12-23 15:26:21 <mps> wsinatra: I remember, but you were 'annoying' in good sense
2020-12-23 15:28:16 <wsinatra> :) I can appreciate that. I'm stubborn and determined to learn. From the sounds of it this contributor hasn't responded much outside of the initial fixes?
2020-12-23 15:35:23 <mps> determined and willing contributors/developers is better than super smart a.., imo
2020-12-23 15:38:36 <wsinatra> Agreed entirely!
2020-12-23 22:52:12 <craftyguy> is there anything to help with translating '-' to '_' for pkgver? apparently substitution like ${pkgver/-/_} doesn't work with abuild (bad sub. error..) even though it works in ash
2020-12-23 22:53:04 <craftyguy> upstream src url includes version in the form of 1.0-alpha2, but the - is incompatible with the 'alpha' suffix :*
2020-12-23 22:53:06 <craftyguy> :(
2020-12-23 22:54:16 <MY-R> oh ye I know that pain
2020-12-23 22:55:10 <craftyguy> it's not simple to great aports for an example of how this was handled either :P
2020-12-23 22:55:16 <craftyguy> (handled in other packages)
2020-12-23 22:57:47 <MY-R> craftyguy: but 1.0_alpha2 should work fine
2020-12-23 22:58:32 <MY-R> so ${pkgver/_/-}
2020-12-23 22:58:35 <craftyguy> MY-R: no, my point is that the src url has '1.0-alpha2' in it, I can't use that as pkgver
2020-12-23 22:58:38 <mps> echo ${1//-/_}
2020-12-23 22:58:59 <MY-R> then just use _pkgver etc
2020-12-23 22:59:22 <craftyguy> I get a 'bad substitution' error with abuild when I use this: source="https://github.com/bleakgrey/tootle/archive/${pkgver/_/-}.tar.gz"
2020-12-23 22:59:27 <MY-R> craftyguy: first beter example: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/qt5-qtwebkit/APKBUILD
2020-12-23 22:59:39 <craftyguy> ya I can use _pkgver. boo
2020-12-23 23:00:25 <craftyguy> seems like what I have should work..
2020-12-23 23:00:40 <mps> I hope you will not push something _alpha to repo
2020-12-23 23:00:44 <craftyguy> it's literally the same substitution in the example you found
2020-12-23 23:00:48 <MY-R> :D
2020-12-23 23:01:13 <craftyguy> mps: eh, it's going in testing. don't install it
2020-12-23 23:01:33 <mps> also, no no!
2020-12-23 23:01:37 <MY-R> craftyguy: just do it like in that example and will be fine
2020-12-23 23:01:56 <MY-R> but ye, "alpha" never sounds nice :)
2020-12-23 23:02:22 <craftyguy> 
ACTION rolls eyes

2020-12-23 23:02:36 <MY-R> hehe
2020-12-23 23:02:37 <mps> testing is not trash can
2020-12-23 23:03:02 <craftyguy> I have no idea what you are talking about
2020-12-23 23:03:14 <craftyguy> ffs the example MY-R found is 'alpha' too
2020-12-23 23:03:24 <craftyguy> and it's in 'community'
2020-12-23 23:03:36 <craftyguy> your head must be spinning now
2020-12-23 23:03:38 <craftyguy> :P
2020-12-23 23:03:52 <mps> that is bad, which one to ask removal ;)
2020-12-23 23:04:13 <MY-R> ye of course some alphas are better from releases, but still, better ask upstream to do proper version instead of put some "alphas" even in testing :P
2020-12-23 23:05:49 <mps> main/alpine-base/APKBUILD:pkgver=3.13.0_alpha20201218
2020-12-23 23:06:05 <afontain_> quick, remove it!
2020-12-23 23:06:05 <MY-R> 5.212.0_alpha4 :D sound serious too! :P
2020-12-23 23:06:35 <MY-R> hehehe
2020-12-23 23:06:59 <mps> 2 in community and 7 in testing
2020-12-23 23:07:07 <afontain_> I've seen software in alpha for quite some time. I don't mind if it works well and it's some non-critical app, like a game or a podcast thing
2020-12-23 23:07:59 <mps> yes, but ...
2020-12-23 23:08:08 <MY-R> still is worth to try push upstream to damn release something not named alpha :)
2020-12-23 23:08:21 <afontain_> hmm, craftyguy: does that "alpha" means "release candidate"?
2020-12-23 23:08:36 <afontain_> *mean
2020-12-23 23:08:50 <mps> I have to revoke my opinion that we need janitors for aports
2020-12-23 23:08:56 <craftyguy> that's how I understood it. it's not like the project is completely brand new. they had a number of sub-1.0 releases that weren't tagged 'alpha'
2020-12-23 23:09:09 <mps> we need armed guards :)
2020-12-23 23:09:19 <MY-R> mps: :D
2020-12-23 23:10:58 <MY-R> alpha, beta, gamma, release candidate etc always sounds like not ready for "release" but ye, software wont be ready/stable etc whatever :D
2020-12-23 23:13:07 <mps> yes, bugs are everywhere.
2020-12-23 23:13:16 <MY-R> exactly
2020-12-23 23:13:46 <MY-R> but project owners should have more self confidence :)
2020-12-23 23:14:17 <mps> but if even author declare it as non yet ready (alpha, beta, gamma ...) then this software shouldn't be in distro
2020-12-23 23:15:55 <MY-R> but but, looks like everyone have different idea what is good enough and what no, that is why damn qt5-qtwebkit alpha ;) with that I even agree
2020-12-23 23:15:59 <craftyguy> meh
2020-12-23 23:16:39 <mps> craftyguy: agree with your 'meh'
2020-12-23 23:16:45 <MY-R> craftyguy: dont be shy, push it :)
2020-12-23 23:17:08 <mps> sure
2020-12-23 23:17:12 <craftyguy> oh I'm not being shy, I'm building it locally right now and waiting on that to finidh
2020-12-23 23:17:19 <craftyguy> s/finish/finish
2020-12-23 23:17:24 <craftyguy> bah
2020-12-23 23:18:15 <MY-R> everyone who working with alpine longer got own local repositories of packages which probably repeat with others hidden repos :P
2020-12-23 23:19:24 <mps> last week I started to clean my local branches ;)
2020-12-23 23:19:36 <MY-R> yeah... good luck :D
2020-12-23 23:19:59 <MY-R> clean like, push to official Alpine? :D
2020-12-23 23:20:14 <mps> hehe, yes
2020-12-23 23:20:18 <MY-R> hehe
2020-12-23 23:20:47 <MY-R> sounds good for me :P
2020-12-23 23:23:24 <mps> MY-R: also to me :)
2020-12-23 23:23:39 <MY-R> ikr!
2020-12-23 23:24:24 <mps> 'ikr'?
2020-12-23 23:25:14 <maxice8> means I know, right
2020-12-23 23:25:56 <mps> ah, thanks
2020-12-23 23:27:49 <MY-R> party over maxice8?
2020-12-23 23:27:59 <maxice8> ?
2020-12-23 23:29:44 <MY-R> thought you was on some party or I mess up scrollback... here in europe we will have some evening party today 24 Dec, xmas! ...
2020-12-23 23:30:09 <maxice8> Few days ago
2020-12-23 23:31:00 <MY-R> oh, I should make my scrollbacks shorter :D
2020-12-24 02:19:07 <omni> what an upstream choose to call their version is not an objective measure of quality
2020-12-24 03:05:13 <maxice8> Ok
2020-12-24 06:36:54 <ikke> mps: crystal is faiing on 3.13
2020-12-24 06:50:33 <mps> ikke: yes, I know. I talked on about that on #crystal-lang but no one answered with solution or 'good' idea what to check
2020-12-24 06:51:24 <mps> I think musl mallocng found another bug in gc lib but I'm not 100% sure
2020-12-24 06:51:52 <ikke> ok
2020-12-24 06:53:23 <mps> few days ago I plead here if someone would help and post bug report to gc upstream on githab
2020-12-24 08:44:24 <ncopa> morning
2020-12-24 08:44:33 <ncopa> seems like we can remove llvm8? nothing is using it
2020-12-24 08:44:51 <ncopa> cd ..
2020-12-24 09:24:32 <ikke> seems like libretro-mupen64plus needs -fcommon fixes (just 4 instances)
2020-12-24 09:26:41 <PureTryOut[m]2> Cogitri: now Firefox 84 is in the repos, is https://git.alpinelinux.org/aports/tree/community/firefox/APKBUILD#n15 still true?
2020-12-24 09:28:10 <Cogitri> I doubt that fixed itself with the new FF version
2020-12-24 09:28:19 <Cogitri> Maybe it'll work once we merged Rust 1.48
2020-12-24 09:30:49 <mps> ikke: for crystal we have few options, try do disable failed test (only one), disable check or disable crystal
2020-12-24 09:31:33 <ikke> Also written in order of preference
2020-12-24 09:32:00 <mps> though this failed test is most important one, compiler test
2020-12-24 09:32:05 <ikke> mps: but you are in the best position to judge what is warranted
2020-12-24 09:32:11 <ikke> right
2020-12-24 09:33:07 <mps> huh, though it is not good idea I think to try contact gc upstream by mail instead over github
2020-12-24 09:33:22 <PureTryOut[m]2> Ah ok
2020-12-24 09:33:31 <mps> I don't have GH account
2020-12-24 09:34:15 <mps> or maybe open issue and assign to jirutka who is maintainer of crystal
2020-12-24 09:34:55 <mps> and I think he have GH account
2020-12-24 09:35:44 <ikke> Yes, he has
2020-12-24 10:14:42 <mps> ok, #12228
2020-12-24 10:15:38 <ncopa> mps: this is blocking the 3.13 release, right?
2020-12-24 10:16:39 <mps> yes
2020-12-24 10:21:11 <mps> btw, should we switch mutt to use libidn2? debian, void and arch all uses libidn2 for it. ncopa?
2020-12-24 10:26:48 <ncopa> i suppose thats fine
2020-12-24 10:26:55 <ncopa> i havent checked the implications though
2020-12-24 10:29:20 <mps> 'it works' as 'they' says
2020-12-24 10:29:39 <mps> I tested it locally
2020-12-24 10:39:06 <ncopa> ok. push it.
2020-12-24 10:41:14 <mps> ok, later at evening, I'm busy now
2020-12-24 12:04:40 <ncopa> i've set build-3-13-mips64 to continue on build error
2020-12-24 12:05:13 <ikke> ok
2020-12-24 12:26:27 <Ariadne> probably a good approach to help it catch up
2020-12-24 12:27:59 <ikke> ah, ghc needs to be bootstrapped on x86_64
2020-12-24 12:31:47 <nmeum> yeah, ghc bootstrap is a mess :S
2020-12-24 12:32:52 <ikke> nmeum: in this case it's just a matter of making sure ghc-bootstrap is installed
2020-12-24 12:33:09 <ikke> We don't need to bootstrap if from scratch
2020-12-24 12:42:41 <Cogitri> PureTryOut[m]2: If you want to help get FF to build on armv7 again, Rust 1.48 is currently blocked by https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16105#note_132187
2020-12-24 12:48:44 <ncopa> im gonna be controversial and push xfce 4.16
2020-12-24 12:48:55 <ncopa> seems like it runs ok on my desktop
2020-12-24 12:49:31 <Ariadne> im going to be controversial and replace GNU nano 5.4 with a git snapshot featuring all of my patches actually merged into it
2020-12-24 12:49:37 <Ariadne> including minibar
2020-12-24 12:49:46 <Ariadne> haha just kidding :)
2020-12-24 12:49:56 <Ariadne> (though i am running said git snapshot locally)
2020-12-24 12:50:11 <ncopa> heh... you got me..
2020-12-24 12:50:51 <Ariadne> GNU nano 5.5 is going to be pretty great
2020-12-24 14:13:13 <Ariadne> ncopa be like how dare u take away xfce on mips64, i'm gonna buy an SGI octane2 off ebay
2020-12-24 14:42:32 <ncopa> i have it under control (i think)
2020-12-24 15:39:06 <maxice8> ncopa: don't think that is controversial
2020-12-24 16:16:30 <mps> nice that xfce is upgraded :)
2020-12-24 20:50:17 <ikke> isn't aports-lua not supposed to ignore checkdepends now if checks have been disabled?
2020-12-24 20:53:40 <ikke> or abuild even
2020-12-24 20:54:17 <ikke> ok, ignore me
2020-12-24 20:54:26 <ikke> it's a normal depends, not a checkdepends
2020-12-25 12:54:40 <mps> anyone of ppc64 people around to help with !16157 which passes all CIs except ppc64le, looks like needs to add '#include' somewhere
2020-12-25 12:57:02 <ikke> mps: limits.h
2020-12-25 13:00:49 <mps> I think so, but how to test without ppc machine
2020-12-25 13:01:01 <mps> and no, I don't to have one
2020-12-25 13:01:09 <ikke> mps: If you have a patch, I can test it
2020-12-25 13:01:13 <mps> don't want*
2020-12-25 13:01:20 <ikke> or you patch it and push it
2020-12-25 13:01:23 <ikke> then CI will verify
2020-12-25 13:02:22 <mps> yes, that is last what should be done, I hoped someone with ppc box could do that easier than me
2020-12-25 13:20:43 <mps> hmm, 'git push --force user' didn't noticed by gl.a.o
2020-12-25 13:21:17 <ikke> and 'user' is your forks remote?
2020-12-25 13:21:30 <mps> iofc
2020-12-25 13:21:39 <mps> ofc*
2020-12-25 13:24:51 <ikke> now it is
2020-12-25 13:29:42 <mps> yes, and passed CIs
2020-12-25 13:29:49 <mps> ikke: thanks
2020-12-25 13:35:23 <mps> 
ACTION remember times when we did such things by pushing straight to builders :)

2020-12-25 13:36:45 <ikke> Having CI helps a lot :)
2020-12-25 13:36:58 <ikke> even though it's not perfect
2020-12-25 13:42:22 <mps> and we becoming less careful as a consequence
2020-12-25 13:43:03 <mps> but I agree, CI helps a lot
2020-12-25 16:47:34 <mps> posted this about crystal failure https://forum.crystal-lang.org/t/crystal-compiler-spec-sigfaults-on-alpine-linux/2815
2020-12-26 04:53:47 <craftyguy> hmm what the heck happened with the CI in this MR? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16167
2020-12-26 04:54:00 <craftyguy> https://gitlab.alpinelinux.org/craftyguy/aports/-/jobs/279547#L17
2020-12-26 04:58:13 <maxice8> I rebased then merged it deleted the reference and thus CI broke
2020-12-26 05:04:50 <craftyguy> ah
2020-12-26 08:21:39 <mps> ruby is 3.0 now, looks like speed is improved significantly
2020-12-26 08:56:29 <omni> sure does
2020-12-26 08:57:55 <ikke> Instead of 5 seconds to launch a command, it now takes 3 seconds?
2020-12-26 09:00:04 <maxice8> lol
2020-12-26 09:03:01 <ikke> https://github.com/python/typed_ast/issues/151#issuecomment-751299005
2020-12-26 09:08:10 <maxice8> oof
2020-12-26 17:06:01 <fraolt> I've created a MR for a new package (https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16182). I had to update the APKBUILD, because some dependency is not available for certain archs. What's the protocol: Should I amend the existing commit and force-push or should I make a second commit that fixes the issue?
2020-12-26 17:07:29 <mps> fraolt: yes, amend and --force
2020-12-26 17:10:15 <fraolt> Thx!
2020-12-26 17:11:16 <mps> !16182
2020-12-26 21:04:44 <omni> jirutka isn't here, right? https://gitlab.alpinelinux.org/omni/alpine-make-vm-image/-/merge_requests
2020-12-26 21:07:07 <mps> omni: right
2020-12-28 07:58:10 <ncopa> morning
2020-12-28 07:58:14 <artok> mornin'
2020-12-28 07:59:24 <ikke> o/
2020-12-28 08:01:47 <mps> \o
2020-12-28 08:02:43 <artok> ncopa: have time to 5.10.2 -> 5.10.3 on linux-rpi ? =)
2020-12-28 08:03:17 <ncopa> i'll have a look
2020-12-28 08:03:32 <artok> thanks
2020-12-28 09:35:18 <ikke> Still lots of failing packages, hard to get ready for 3.13
2020-12-28 09:45:22 <ncopa> build-3-13-mips64 completed the build. i changed it back to halt-on-error
2020-12-28 09:45:39 <ikke> nice
2020-12-28 09:56:36 <Marcel45> Hello, i want to compile the driver for my nvida GTX780M Graphics Card. I am on fresh installed Alpinelinux 3.12  with Kernel 5.4.84-0-lts. Wich are the right kernel source to add with apk for this kernel. compiler tells me the source are not the same as the acutal kernel. Thank you for help
2020-12-28 09:57:25 <Marcel45> By the way glibc 2.32 and all other stuff need are alredy installed
2020-12-28 09:58:40 <Marcel45> I used this site: https://arto.s3.amazonaws.com/notes/cuda
2020-12-28 09:59:07 <ikke> Marcel45: alpine uses musl, not glibc
2020-12-28 09:59:07 <Marcel45> this site is outdate with older alpinelinux
2020-12-28 09:59:43 <Marcel45> yes i know, but did install glibc and compile the nvidia driver
2020-12-28 10:01:03 <Marcel45> the newest driver from nvidia 455.... did work fine, but my graphics card needs older driver from nvidia 418.133 and that is compiled with older kernel
2020-12-28 10:02:48 <Marcel45> as descripted here https://arto.s3.amazonaws.com/notes/cuda  all is fine with newest driver from nvidia. driver is installed fine and loaded, but not for my old graphics card :-(
2020-12-28 10:04:17 <Marcel45> the problem is this: apk add linux-vanilla-dev  # Alpine Linux,   wich are the sources for the 5.4.84-0-lts kernel ?
2020-12-28 10:04:20 <maxice8> ncopa: ping
2020-12-28 10:04:30 <ikke> maxice8: linux-lts-dev
2020-12-28 10:04:34 <ikke> Marcel45: *
2020-12-28 10:04:36 <mps> Marcel45: apk add linux-lts-dev
2020-12-28 10:04:45 <ikke> mps: :p
2020-12-28 10:04:50 <maxice8> ncopa: can you take a look at !16012 ?
2020-12-28 10:04:55 <mps> ikke: hhrrrr ;)
2020-12-28 10:05:06 <Marcel45> ok thank you , so i did pick the right one
2020-12-28 10:06:07 <mps> 
ACTION thinking to leave -linux and -devel channels because of ikke :)

2020-12-28 10:06:14 <ikke> :(
2020-12-28 10:06:55 <mps> you don't see ':)'
2020-12-28 10:07:00 <ikke> yes
2020-12-28 10:07:19 <mps> jk
2020-12-28 10:08:23 <Marcel45> ok so i make everything right with the packages, but the old nvidia driver for my old iMac gt780m graphic card did not compile only the newest one from nvdia mmhh.. :)
2020-12-28 10:09:42 <Marcel45> iMac  late 2013 with Nouveau driver and xfce4 ist working, but i want to use this maschine for my blender
2020-12-28 10:09:43 <mps> 'f..k you nvidia' - Linus Torvalds
2020-12-28 10:09:53 <Marcel45> jo
2020-12-28 10:11:02 <Marcel45> blender with nouveau driver , puh, no cuda, it works but slower as under mac os
2020-12-28 10:11:14 <mps> Marcel45: two years ago I tried to build it on alpine, but I gave up. not worth hassles for me
2020-12-28 10:13:41 <Marcel45> jo, since 5 days i am trying, today i made a little rsync script to roll back alpinelinux every time i failed, but i will get it. iMac i7 gtx780m with Blender and Alpinelinux
2020-12-28 10:15:20 <Marcel45> hmm the newest driver from nvdia 455 works fine, everything is compiled , nouveau disabled , nvidia-drm.ko is installed
2020-12-28 10:15:51 <Marcel45> but in this driver my old card is no longer supported,:-(
2020-12-28 10:17:50 <Marcel45> ok thank you everyone, for now i will first again install desktop with nouveau and then again try to install nvdia .bye
2020-12-28 10:20:00 <ncopa> maxice8: LGTM
2020-12-28 10:31:46 <maxice8> ty
2020-12-28 11:04:42 <Marcel45> Hello, is it right when i install with apk add linux-lts-dev, i have the sources for the kernel 5.4.84-0-lts? Than you
2020-12-28 11:06:16 <ikke> it does not include all the sources
2020-12-28 11:06:53 <ikke> mostly header files
2020-12-28 11:07:11 <Marcel45> i also did install apk add linux-headers
2020-12-28 11:07:43 <ikke> They should match the kernel, yes
2020-12-28 11:08:00 <Marcel45> ok
2020-12-28 11:12:38 <ncopa> hum... we didnt have go on mips64
2020-12-28 11:12:55 <ikke> yes
2020-12-28 11:13:00 <ncopa> linux-headers shouldnt be needed
2020-12-28 11:13:05 <ncopa> only linux-lts-dev
2020-12-28 11:15:42 <Marcel45> when i compile with this driver :http://us.download.nvidia.com/XFree86/Linux-x86_64/450.66/README/index.html everything compiles fine
2020-12-28 11:16:47 <Marcel45> but when i use this one for my graphics card it shows errors in nvidia.log missing headers http://us.download.nvidia.com/XFree86/Linux-x86_64/418.113/README/index.html
2020-12-28 11:22:51 <ncopa> ok. is it a kernel module that fails to build or the userspace componets?
2020-12-28 11:22:59 <ncopa> the userspace components may need linux-headers
2020-12-28 11:23:05 <ncopa> the kernel module shoudnt
2020-12-28 11:27:19 <Marcel45> the problem seems to be in the installer from nvidia, i will again try to build with the 455.45 driver for the newest tian cards. i need some minutes
2020-12-28 11:37:56 <Marcel45> ok. with the nvidia 455.45 compiling did work and all driver are build , i get only an error, that the kernel module 'nvidia.ko' could not be loaded of other driver like nouveou or the gcc differs from the one used to build the target kernel,  but this problem is for later.
2020-12-28 11:39:21 <Marcel45> the nvdia 418.113 driver did not come so far, sorry for the bad english, old german dumbman writing here, :)
2020-12-28 11:42:43 <mps> no worries, most of us are not native english speakers
2020-12-28 11:52:03 <ikke> Anyone has experience with debugging python c extensions?
2020-12-28 11:54:33 <artok> ikke: how much needed? what is the package?
2020-12-28 11:54:51 <ikke> py3-typed-ast
2020-12-28 11:55:03 <ikke> It's giving unexpected results on s390x
2020-12-28 11:55:10 <ikke> upstream has no access to the hardware
2020-12-28 11:55:21 <artok> ah, the magic word of s390x
2020-12-28 11:55:46 <ikke> I need to know how to set a breakpoint
2020-12-28 11:56:47 <ikke> I have python3-dbg, musl-dbg and py3-typed-ast-dbg installed
2020-12-28 11:57:13 <mps> printf debug
2020-12-28 11:57:48 <artok> isn't gdb good for it ?
2020-12-28 12:01:14 <artok> gdb python, set the breakpoint for the file (future loaded module yes), run the pythonstuff that loads the module
2020-12-28 12:01:44 <ikke> artok: trying that, but it just continues
2020-12-28 12:03:08 <artok> all debug symbols found on library?
2020-12-28 12:03:49 <ikke> It does not mention it
2020-12-28 12:04:09 <ikke> only python3
2020-12-28 12:04:32 <ikke> https://tpaste.us/5VrX
2020-12-28 12:05:00 <ikke> I also tried just ast.c:459
2020-12-28 12:05:08 <ikke> and the function name
2020-12-28 12:06:26 <artok> ast27 for python2.7 ?
2020-12-28 12:06:35 <ikke> yes
2020-12-28 12:06:42 <ikke> it can handle both python2.7 and python3
2020-12-28 12:09:06 <fraolt> Hi, is there any reason why the rustup-package is x86_64-only? I just built it on aarch64 and so far it works like a charm.
2020-12-28 12:16:56 <artok> oh for the ff
2020-12-28 12:20:07 <Cogitri> fraolt: In the beginning Rust upstream only offered rust packages for x86_64 musl
2020-12-28 12:20:17 <Cogitri> so it didn't make sense to provide aarch64 rustup
2020-12-28 12:20:25 <Cogitri> if that changed, we can enable it
2020-12-28 12:20:54 <fraolt> Cogitri: The only thing is, that the APKBUILD contains a environment variable "RUSTUP_OVERRIDE_BUILD_TRIPLE" set to "x86_64-unknown-linux-musl", which I had to change to "aarch64-unknown-linux-musl".
2020-12-28 12:21:55 <fraolt> I don't know how to set the variable depending on the arch that is currently being built.
2020-12-28 12:23:55 <artok> fraolt: usually it is on block of case "$CARCH" in
2020-12-28 12:26:29 <fraolt> Ah thx, will look for that and provide a MR, ok?
2020-12-28 12:27:51 <Cogitri> Okie 👍
2020-12-28 12:33:43 <artok> gosh, something broke on apk upgrade, couldn't get my linux laptop up without nomodeset
2020-12-28 12:36:56 <artok> calls for later checks for amdgpu
2020-12-28 12:37:06 <artok> ikke: got any progress?
2020-12-28 12:38:18 <ikke> artok: no, and I have to get back to work now
2020-12-28 12:42:46 <fraolt> Cogitri: I'm done, but since this a new aport for aarch64 is it okay to have this is community?
2020-12-28 12:43:49 <ikke> fraolt: is it a new aport, or just the same aport enabled for a new arch?
2020-12-28 12:48:33 <fraolt> same aport, new arch
2020-12-28 12:49:07 <ncopa> maxice8: seems like sdub-cpp is having issues parsing the version string from elogind
2020-12-28 12:50:37 <maxice8> From pkgconfig?
2020-12-28 12:50:46 <ncopa> no the cmake file
2020-12-28 12:51:55 <ncopa> there is a patch to support dots in the version
2020-12-28 12:52:11 <ncopa> the error comes from the patch
2020-12-28 12:52:44 <ncopa> but if i remove the patch it fails later: <command-line>: error: too many decimal points in number
2020-12-28 12:52:44 <ncopa>   118 | #if LIBSYSTEMD_VERSION>=240
2020-12-28 12:52:44 <ncopa>       |     ^~~~~~~~~~~~~~~~~~
2020-12-28 12:53:37 <mps> huh, LIBSYSTEMD
2020-12-28 12:53:52 <mps> sorry, can't resist
2020-12-28 12:54:07 <artok> mps, I was waiting for that reaction =)
2020-12-28 12:54:40 <mps> artok: :)
2020-12-28 12:54:58 <ncopa> i think elogind just set the version string macro
2020-12-28 12:55:32 <ncopa> and then used as numeric compare
2020-12-28 12:55:44 <ncopa> which fails due to two dots in version string
2020-12-28 12:55:50 <mps> could this be faked somehow
2020-12-28 12:56:29 <ncopa> i suppose we can strip the trailing .* from version macro in elogind
2020-12-28 12:59:53 <Cogitri> fraolt: fine to introduce it in aarch64 since you only added a new arch
2020-12-28 13:21:17 <dne> in
2020-12-28 13:21:19 <dne> !16240
2020-12-28 13:21:23 <dne> sorry
2020-12-28 13:22:49 <dne> any idea why this would occur only on armv7? "undefined reference to `_Unwind_GetIP'"
2020-12-28 13:23:15 <artok> ikke: what is your example.py that you're trying to run ?
2020-12-28 13:23:33 <ikke> https://github.com/python/typed_ast/issues/151
2020-12-28 13:23:36 <ikke> the first code example there
2020-12-28 13:25:13 <afontain_> ncopa "I think elogind just set the version string macro" yes
2020-12-28 13:25:15 <afontain_> it does
2020-12-28 13:25:28 <afontain_> how did you encounter the issue?
2020-12-28 13:26:24 <artok> ikke: I got into breakpoint normally
2020-12-28 13:26:28 <afontain_> I thought I had tried to use sdbus-cpp with cmake already
2020-12-28 13:28:30 <ikke> artok: what command did you use?
2020-12-28 13:28:40 <artok> https://termbin.com/p915
2020-12-28 13:32:50 <ikke> hmm
2020-12-28 13:35:15 <artok> I see only difference on "gdb python3 example.py" "run" vs "gdb python3" "run example.py"
2020-12-28 13:35:32 <artok> aaand the fact that python3 itself doesn't have debug symbols
2020-12-28 13:35:55 <ikke> right
2020-12-28 13:36:12 <ikke> and 'cannot disable adress randomization"
2020-12-28 13:36:44 <ikke> did you compile typed_ast?
2020-12-28 13:36:49 <artok> yeah
2020-12-28 13:36:53 <ikke> ok
2020-12-28 13:37:12 <ikke> I installed it via apk, so that might be a difference as well
2020-12-28 13:38:27 <artok> if apk does setup.py install --debug, it is same thing...
2020-12-28 13:39:00 <ikke> I don't think it does
2020-12-28 13:40:39 <ikke> hmm "AttributeError: module 'typed_ast.ast27' has no attribute 'parse'"
2020-12-28 13:44:08 <artok> eg
2020-12-28 13:44:09 <artok> ehh
2020-12-28 13:45:18 <ikke> You created a venv I see
2020-12-28 13:45:59 <ikke> did you install it in that venv?
2020-12-28 13:56:49 <artok> yeah
2020-12-28 13:57:13 <ikke> ok
2020-12-28 14:12:24 <artok> whole system was so clean that I just did "apk add alpine-sdk python3-dev gdb py3-pip" before testing
2020-12-28 14:12:52 <ikke> i'm running it in a docker container
2020-12-28 14:14:47 <ikke> artok: works after installing it
2020-12-28 14:15:00 <fraolt> rustup for aarch64 is at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16257
2020-12-28 14:15:22 <artok> huh
2020-12-28 14:15:33 <ikke> and now the breakpoint works as well
2020-12-28 14:15:44 <artok> great
2020-12-28 14:15:48 <ikke> thanks
2020-12-28 14:16:25 <artok> there was some symbol finding difficulties between site-packages and so o
2020-12-28 14:22:45 <Cogitri> fraolt: Merged, thanks for the MR
2020-12-28 14:30:48 <fraolt> Cogitri: No worries. :) I need it myself for Anki on pinephone (postmarketos).
2020-12-28 15:03:09 <Ariadne> hmm, somebody should have told that Marcel guy that nvidia driver userspace components don't work on alpine
2020-12-28 15:08:57 <mps> :)
2020-12-28 15:09:28 <mps> Ariadne: did you tested external mmc on elm
2020-12-28 15:09:34 <Ariadne> no
2020-12-28 15:10:19 <mps> it 'bugs' for me, but found fix and testing it now. not yet added to linux-elm
2020-12-28 15:17:09 <Ariadne> cool
2020-12-28 15:17:28 <Ariadne> i dont have any sdcards on me to test with
2020-12-28 15:18:29 <mps> np, just in case you see problem now you know that it will be fixed
2020-12-28 15:19:06 <mps> well, I hope
2020-12-28 15:27:23 <artok> Ariadne: oh and also it was because of blender
2020-12-28 15:30:41 <artok> if he's gonna build that one from scratch, good luck
2020-12-28 15:39:22 <Hello71> Ariadne: well it would probably be more useful to ask what they meant by "installed glibc"
2020-12-28 15:41:49 <artok> hmm.. would it be possible to build blender using musl..
2020-12-28 15:42:04 <artok> use case: render farm container
2020-12-28 15:42:20 <ikke> https://pkgs.alpinelinux.org/package/edge/testing/x86_64/blender
2020-12-28 15:42:46 <artok> so yes it is there
2020-12-28 15:43:16 <artok> just need to check what dependencies there are
2020-12-28 15:44:32 <artok> 
ACTION used to build macOS versions of it

2020-12-28 15:47:44 <artok> ncopa: 5.10.3 on rpi4 removed bunch of wifi connectivity issues, so thanks for updating =)
2020-12-28 15:48:13 <artok> blender was really picky about dependencies
2020-12-28 15:48:18 <artok> might still be
2020-12-28 15:52:01 <artok> hence, my dockerfile did build most of them from source, as with windows and macOS it is done
2020-12-28 16:26:16 <ncopa> Cogitri: any idea what this is about? meson.build:1:0: ERROR: Executables created by D compiler gdc are not runnable.
2020-12-28 16:26:28 <ncopa> https://build.alpinelinux.org/buildlogs/build-3-13-armhf/community/openssl-d/openssl-d-2.0.1-r1.log
2020-12-28 16:28:47 <artok> what is under that meson-log.txt ?
2020-12-28 16:28:53 <artok> or in it, not under
2020-12-28 16:30:21 <artok> sounds like some test of the compiler that hasn't got some compiler runtime available
2020-12-28 16:33:47 <artok> ...missign triplet or whatever
2020-12-28 16:34:04 <Cogitri> mcopa: gdc is broken om 32-bit
2020-12-28 16:34:14 <Cogitri> ncopa: ^ :D
2020-12-28 16:34:48 <Cogitri> We already have a tracking issue for it, I also pinged Geod (D upstream) about it, he mentioned that in the ldc MR but I forgot to ask him about it again
2020-12-28 16:34:53 <Cogitri> something something time64 changes
2020-12-28 16:35:46 <Cogitri> I think we can just remove openssl-d, apk-polkit and polkit-d from edge&3.13 since apk-polkit-rs superceded those
2020-12-28 16:38:30 <Cogitri> I'll take care of it once Gitlab feels like accepting my git push
2020-12-28 16:40:19 <ikke> Cogitri: issues?
2020-12-28 16:43:48 <Cogitri> Might just my connection being so overloaded that git push takes forever :3
2020-12-28 16:43:56 <Cogitri> ah, now it did something
2020-12-28 16:43:57 <Cogitri> hooray
2020-12-28 16:44:29 <Cogitri> Took like 3 minutes, but I'm downloading things with like 70Kbyte/s right now apparently, so probably just my upload being even worse
2020-12-28 16:46:24 <Cogitri> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16261
2020-12-28 17:03:20 <ncopa> so we disable 32bit D apps?
2020-12-28 17:03:34 <ncopa> or do we have a fix for gcc?
2020-12-28 17:04:58 <ncopa> looks like we have a time_t patch for gcc
2020-12-28 17:06:02 <Cogitri> Yup, we only have 3 32-bit D apps anyway AFAICS
2020-12-28 17:06:06 <Cogitri> And those are all deprecated
2020-12-28 17:06:38 <Cogitri> But we should fix gdc 32-bit soon-ish, but dunno how to do that, let's wait for Geod to respond
2020-12-28 18:04:39 <zNoctum> is there any high res version of the alpine linux logo?
2020-12-28 18:05:01 <ikke> There is an svg
2020-12-28 18:06:10 <zNoctum> could you give me the link?
2020-12-28 18:06:44 <ikke> https://www.alpinelinux.org/alpinelinux-logo.svg
2020-12-28 18:09:44 <zNoctum> thx
2020-12-28 20:23:51 <fraolt> This rust thingy is driving me crazy. I would like to build anki-2.1.35 for aarch64, which is partly python and partly rust. The rust part (rspy)  depends on openssl. But when compiling it, it complains: "don't know how to configure OpenSSL for aarch64-alpine-linux-musl". I see that it knows "aarch64-unknown-linux-musl". Any rust expert here, who can help me get started on this?
2020-12-28 20:43:37 <artok> adding alpine triples with diff like in clang?
2020-12-28 20:44:25 <artok> does it really need openssl built inside it, can't it use system libs?
2020-12-28 20:45:53 <fraolt> If I'm not mistaken, this is only the bridge for using openssl in rust.
2020-12-28 20:47:21 <Cogitri> Can you paste the whole log?
2020-12-28 20:47:33 <Cogitri> Also, do you have openssl-dev installed?
2020-12-28 20:47:44 <Cogitri> Otherwise it might try to build it's own static openssl which won't work
2020-12-28 20:53:17 <fraolt> artok: I'm now compiling with a manually patched openssl, but I had to patch a file in ~/.cache, because they are automagically downloaded by rustup(?). So, I don't see a way to patch it like in clang.
2020-12-28 20:58:37 <fraolt> Cogitri: I think it worked with the manually patched file. ^^ Unfortunately, it compiles for several hours on my pinephone. Next compile, I'll undo my patch and try with openssl-dev and send the logs. But this will probably not happen today (CET).
2020-12-28 21:01:06 <Ariadne> https://www.crowdsupply.com/sra-centr8/icepeakitx-elbrus-8cb
2020-12-28 21:01:09 <Ariadne> lets port alpine !
2020-12-28 21:01:21 <Ariadne> don't worry, i am kidding
2020-12-28 21:03:47 <Hello71> Ariadne: nintendo 64 alpine linux when
2020-12-28 21:28:48 <insep_> Ariadne: yes
2020-12-28 21:29:21 <insep_> i kinda want to get my hands onto those boards just to run alpine on them
2020-12-28 21:29:42 <insep_> the only problem is that elbrus uses it's own compiler called lcc
2020-12-28 21:29:49 <insep_> maybe it doesn't anymore, idk
2020-12-28 21:32:20 <insep_> they cost 2k$ tho
2020-12-28 21:33:40 <insep_> oh wait i forgot that lcc is proprietary
2020-12-28 21:45:45 <Ariadne> lcc is on github
2020-12-28 21:46:10 <Ariadne> Hello71: in theory, the port should boot fine on n64
2020-12-28 21:46:18 <Ariadne> Hello71: if a kernel is supplied
2020-12-28 21:46:33 <Ariadne> though perhaps n64 is actually 32-bit
2020-12-28 21:46:49 <insep_> i have ramdisk btw
2020-12-28 21:47:04 <insep_> and there's prebuilt rom with bootloader and kernel
2020-12-28 21:47:24 <insep_> https://github.com/clbr/n64bootloader/releases/tag/v1.0
2020-12-28 21:47:41 <Ariadne> r4300 is mips64
2020-12-28 21:47:43 <Ariadne> should work
2020-12-28 21:48:03 <insep_> Ariadne: not https://en.wikipedia.org/wiki/LCC_(compiler), they have their own compiler named lcc
2020-12-28 21:49:43 <Ariadne> insep_: according to a slide deck i saw while reading about elbrus the MCST LCC is also open source
2020-12-28 21:50:09 <Ariadne> that slide deck may be lies though
2020-12-28 21:51:24 <insep_> their website says that you can get binary of lcc either with os or if you give them proof that you have elbrus
2020-12-28 21:51:49 <insep_> and it costs 2000rub
2020-12-28 21:52:09 <Ariadne> fuck that :D
2020-12-28 21:52:14 <insep_> yes
2020-12-28 21:52:21 <insep_> at least not 2000$
2020-12-28 21:53:16 <insep_> well, i'm going to bed now
2020-12-28 21:53:53 <mps> when elbrus is announced it was interesting, not sure still now
2020-12-28 21:54:18 <Ariadne> VLIW is interesting
2020-12-28 21:55:30 <mps> well, yes. intel had 'something' after elbrus, or it was based on elbrus, but dissapeared
2020-12-28 21:55:51 <mps> I forgot code name
2020-12-28 21:57:39 <mps> but elbrus was first vliw
2020-12-28 21:58:07 <mps> intel i860
2020-12-28 21:59:13 <mps> huh, long time passed, have to consolidate memory
2020-12-28 22:00:30 <mps> Boris Babayan designed and published first vliw 'description' and idea. iirc he worked later for intel (or sun)
2020-12-28 22:01:27 <mps> (better go to sleep than refreshing memory, I think)
2020-12-28 22:19:56 <skarnet> Ariadne: https://skarnet.org/software/dnsfunnel/
2020-12-28 22:20:06 <skarnet> totally untested, first draft, very alpha, etc.
2020-12-28 22:20:39 <skarnet> in the next days I'll try and set up an environment where I can kinda test this and at least remove the obvious bugs
2020-12-28 22:20:51 <skarnet> but I don't have it on hand right away
2020-12-28 22:21:14 <skarnet> and the thing builds, so if you want to have a look, feel free :D
2020-12-28 22:21:43 <skarnet> "If it compiles, it's tested. If it builds, it's shipped!"
2020-12-28 22:21:57 <skarnet> (s/builds/links/ but it's the same idea.)
2020-12-28 22:31:34 <Ariadne> cool
2020-12-29 02:15:46 <[[sroracle]]> Cogitri: the url= for apk-polkit-rs should be updated :)
2020-12-29 02:16:00 <[[sroracle]]> just spent like 2 minutes being confused why i was pointed towards Cogitri/apk-polkit instead of -rs
2020-12-29 02:16:24 <[[sroracle]]> in the APKBUILD i mean
2020-12-29 06:44:37 <mps> what to do with !16093
2020-12-29 07:35:35 <ncopa> morning
2020-12-29 07:35:54 <ncopa> mps: looks like we don't have any volunteer to work on it?
2020-12-29 07:36:22 <ncopa> does anyone has a clue whats wrong with py3-pytest-black? or how to fix it
2020-12-29 07:36:28 <ncopa> has anyone reported it upstream?
2020-12-29 07:37:05 <ikke> not yet
2020-12-29 07:37:15 <ikke> I'm working with upstream looking at black on s390x
2020-12-29 07:39:10 <ikke> I'll try to look into this as well today
2020-12-29 07:39:47 <mps> ncopa: I replied to private mail from scribus patch OP about month ago and on alpine ML week ago, no answers
2020-12-29 07:41:45 <Cogitri> [[sroracle]]: Oh yes, thanks for the hint :)
2020-12-29 07:41:57 <mps> though I dislike this idea I think I would create 'clean' (from scratch) scribus aport, merge and again send mail to OP if he want to be maintainer
2020-12-29 07:49:54 <ncopa> if he want to be maintainer he should answer
2020-12-29 07:50:11 <ncopa> if we have a maintainer that does not answer, we'll end up with maintenance anyway
2020-12-29 07:50:27 <ncopa> or someone else will end up doing the maintenance
2020-12-29 07:51:30 <ncopa> any python experts that can help debug py3-pytest-black and ansible-lint? I have no clue why they fail
2020-12-29 07:53:02 <mps> yes, I agree, and I only don't want to be 'unkind' to him
2020-12-29 07:54:33 <ncopa> I think you can do whatever you want if he does not respond in reasonable time
2020-12-29 07:54:36 <mps> on the other hand, I think "Maintainer" field is not much useful
2020-12-29 07:55:15 <ncopa> it tells who to assign issues
2020-12-29 07:55:33 <ncopa> if the maintainer respond or not is another question
2020-12-29 07:55:37 <mps> ok, I will take action because it would be nice to have scribus is next stable
2020-12-29 07:58:27 <detha> Having a maintainer field is good for responsive maintainers. For non-responsive maintainers, better to do like bsd does: no response in X time->maintainer field gets changed to dev@ and the package becomes free-for-all
2020-12-29 08:00:49 <mps> detha: something like this makes sense to me
2020-12-29 08:19:18 <ncopa> ok, so we have nobody that has time and energy and the needed skills to fix ansible-lint and py3-pytest-black?
2020-12-29 08:20:17 <ncopa> do you think we should drop the test or do we drop the package?
2020-12-29 08:22:35 <ncopa> im starting to get annoyed by those python issues. there is an excellent supported upstream package manager for python apps. maybe we should let the users use pip install instead
2020-12-29 08:24:43 <mps> if we do that we will not be new ubuntu ever ;)
2020-12-29 08:25:04 <mps> but I tend to agree with you
2020-12-29 08:30:44 <maxice8> I think the py3-pytest-black tests failures were caused by the new `py3-packaging` which became stricter
2020-12-29 08:30:45 <maxice8> I guess we can just disable them until upstream decides that fixing it is worthwhile
2020-12-29 08:30:57 <maxice8> also, working on fixing usbip-utils
2020-12-29 09:18:22 <maxice8> fixed
2020-12-29 09:25:49 <mps> '>>> scribus-lang*: Running split function lang...', 'mv: can't rename '/home/mps/aports/testing/scribus/pkg/scribus//usr/share/locale': No such file or directory'
2020-12-29 09:26:15 <mps> where we should put -lang subpkgs
2020-12-29 09:29:32 <maxice8> what you mean ? If it doesn't install anything in /usr/share/locale then no point in having a -lang subpkg
2020-12-29 09:30:36 <mps> it installs languages
2020-12-29 09:30:54 <mps> but I'm not sure where to put them.
2020-12-29 09:35:27 <mps>  / usr/share/scribus/translations/ are default in source
2020-12-29 09:38:45 <ncopa> got response from upstream trio (py3-trio). problem is that pytest 6.2 introduced some breaking changes. I guess we can skip the failing test. any idea how?
2020-12-29 09:39:51 <maxice8> py3-pytest --deselect
2020-12-29 09:41:29 <maxice8> py3-pytest --deselect trio/_core/tests/test_asyncgen.py::test_fallback_when_no_hook_claims_it
2020-12-29 09:41:42 <maxice8> might also be worth it to use `-v` so the output is more verbose (a.k.a nicer)
2020-12-29 09:47:50 <maxice8> taking care of py3-gevent
2020-12-29 09:47:57 <maxice8> thanks for mips for revealing this packaging error
2020-12-29 09:53:50 <ncopa> maxice8: thanks! pushing fixed py3-trio :)
2020-12-29 09:53:56 <ncopa> the day is getting better :)
2020-12-29 09:59:40 <mps> abuild source 'for dir in ${langdir:-/usr/share/locale}; do'. define 'langdir' is possible, like builddir?
2020-12-29 09:59:44 <ncopa> py3-pytest-black also fails with pytest 6.2, but passes with 6.1
2020-12-29 09:59:56 <ncopa> yes
2020-12-29 10:00:27 <ncopa> it will loop over the listed $langdir which defaults to /usr/share/locale if unset
2020-12-29 10:02:06 <mps> greping aports for examples
2020-12-29 10:06:00 <mps> thanks, works
2020-12-29 10:38:13 <ncopa> we have a number of build failure due to kde not working with the qt version
2020-12-29 10:38:28 <ncopa> im am backporting lots of Qprinter patches
2020-12-29 10:38:53 <ikke> fun
2020-12-29 10:48:57 <ikke> git 1.30.0 has been released, do we want to include it?
2020-12-29 10:49:21 <ncopa> if it does not break anything... yes :)
2020-12-29 10:49:41 <ikke> hehe :_)
2020-12-29 10:49:43 <ncopa> git is normally backwards compatible, right?
2020-12-29 10:49:46 <ikke> yes
2020-12-29 10:49:56 <ncopa> so i'd say its a low risk
2020-12-29 10:50:22 <ikke> and we run the test suite nowadays (barring some tests)
2020-12-29 10:50:44 <ikke> git 2.30.0*
2020-12-29 10:53:58 <ikke> hmm, new test failure
2020-12-29 10:55:36 <mps> default branch name is 30% shorter :)
2020-12-29 10:57:01 <ikke> not yet
2020-12-29 11:11:40 <maxice8> For those wondering how The Witch still works on Alpine from Fedora: https://www.cogitri.dev/posts/11-alpine-dev-env-in-fedora/
2020-12-29 11:27:22 <ikke> ?
2020-12-29 11:35:20 <ncopa> anybody knows whats wrong with crystal?
2020-12-29 11:37:24 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12228
2020-12-29 11:39:39 <mps> also I posted to crystal forum but no answers https://forum.crystal-lang.org/t/crystal-compiler-spec-sigfaults-on-alpine-linux/2815
2020-12-29 11:40:25 <mps> and posted report to gc ML
2020-12-29 11:43:36 <mps> uhm, earthquake, had to go out of house, just in case
2020-12-29 11:44:45 <ikke> oof
2020-12-29 11:44:48 <ikke> how severe?
2020-12-29 11:45:32 <mps> not strong here, but in Croatia it is 6.3-6.7 Richters
2020-12-29 11:48:18 <mps> noticed it by jitter on Xmas tree and then in head, like I'm on toboggan or something similar unstable
2020-12-29 11:54:10 <AinNero> my setup just got fucked by https://gitlab.alpinelinux.org/alpine/aports/-/issues/12246
2020-12-29 11:54:35 <AinNero> i believe this must be addressed before 3.13 or users might get angry
2020-12-29 11:54:44 <ikke> 3.13 users are not affected
2020-12-29 11:54:55 <ikke> ie, from 3.12 -> 3.13
2020-12-29 11:55:03 <ikke> This is only an issue if you have been tracking edge
2020-12-29 11:55:15 <maxice8> only edge users have an issue
2020-12-29 11:55:28 <maxice8> an/the
2020-12-29 11:55:33 <AinNero> i've been tracking edge on purpose for testing purposes
2020-12-29 11:55:43 <AinNero> and i believed v3.13 to be the next stable coming from edge
2020-12-29 11:55:59 <ikke> AinNero: You are only affected if you had ifupdown-ng-openrc installed, which no longer exists
2020-12-29 11:56:08 <maxice8> It will be but people upgrading 3.12->3.13 won't have this
2020-12-29 11:56:56 <AinNero> ah, that ifupdown-ng-openrc got pulled in was a temporary thing on edge?
2020-12-29 11:57:02 <maxice8> yes
2020-12-29 11:57:06 <ikke> indeed
2020-12-29 11:57:17 <AinNero> this makes this alot easier
2020-12-29 11:59:53 <ncopa> so we drop crystal for 3.13?
2020-12-29 12:03:13 <mps> ask maintainer, (don't ask me)
2020-12-29 12:04:18 <mps> though I wrote here a week ago that the 'disable' is safest option
2020-12-29 12:04:45 <mps> '!check' is another, not sure though is that one good
2020-12-29 12:05:58 <mps> but to me this 'smells' to gc bug
2020-12-29 12:08:13 <mps> if someone with GH account have time to ask gc people here https://github.com/ivmai/bdwgc/issues
2020-12-29 12:11:37 <ikke> I'll do it
2020-12-29 12:12:12 <ikke> mps: I just wonder how to explain why we are opening an issue in that project
2020-12-29 12:12:41 <mps> ikke: I posted gdb bt in issue report
2020-12-29 12:13:13 <ikke> ok
2020-12-29 12:13:19 <mps> 0x00007ffff3e09524 in GC_find_limit_with_bound () from /usr/lib/libgc.so.1
2020-12-29 12:14:19 <ikke> mps: https://github.com/ivmai/bdwgc/issues/154
2020-12-29 12:14:22 <ikke> (existing issue)
2020-12-29 12:16:13 <mps> this looks like another one 'discovered' by current musl
2020-12-29 12:18:01 <mps> hmm, these are from 2017, and we succesfully built crystal for few releases after that
2020-12-29 12:24:20 <mps> hmm, according to this comment and commit it should be fixed https://github.com/ivmai/bdwgc/issues/321#issuecomment-667815720
2020-12-29 12:28:02 <ikke> https://github.com/ivmai/bdwgc/commit/b6173fdc78815c8731979f71ab4ce19d91da3e93
2020-12-29 12:28:12 <ikke> Do we that have in our gc?
2020-12-29 12:32:44 <mps> no, afaik
2020-12-29 12:33:52 <ikke> so would it be worth-wile to try?
2020-12-29 12:34:11 <mps> we have 8.0.4 (latest release) from Mar 2, 2019
2020-12-29 12:34:51 <mps> heh, I tried with build of gc from master branch two ago
2020-12-29 12:35:07 <mps> two weeks ago*
2020-12-29 12:35:40 <mps> and result was same
2020-12-29 12:37:14 <mps> and because crystal and gc upstream are not responsive I stopped further tries, ncopa is right imo. disable
2020-12-29 12:37:52 <mps> or, ask jirutka, he is maintainer
2020-12-29 12:38:42 <mps> to not forget to tell, I asked on #crystal-lang channel also, no luck
2020-12-29 13:00:26 <ncopa> ruby seems to be broken on armv7 and armhf.
2020-12-29 13:00:40 <ncopa>  cc   -pipe -fPIC -fvisibility=hidden -O -W -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wmissing-prototypes -Werror -g
2020-12-29 13:00:40 <ncopa>           -I/usr/include/ruby-2.7.0/armv7-linux-musleabihf -I/usr/include/ruby-2.7.0 -o build/autotest test.c -L/usr/lib -Wl,-rpath,/usr/lib -lruby -lm -lucontext
2020-12-29 13:00:40 <ncopa>  /usr/lib/gcc/armv7-alpine-linux-musleabihf/10.2.1/../../../../armv7-alpine-linux-musleabihf/bin/ld: /usr/lib/libruby.so: undefined reference to `__getcontext'
2020-12-29 13:00:40 <ncopa>  /usr/lib/gcc/armv7-alpine-linux-musleabihf/10.2.1/../../../../armv7-alpine-linux-musleabihf/bin/ld: /usr/lib/libruby.so: undefined reference to `__swapcontext'
2020-12-29 13:00:40 <ncopa> collect2: error: ld returned 1 exit status
2020-12-29 13:02:05 <nmeum> probably need to add -lucontext somewhere
2020-12-29 13:02:27 <nmeum> hm, it's already part of the cc invocation hmhm
2020-12-29 13:03:37 <mps> ucontext doesn't help for this, iirc
2020-12-29 13:04:00 <ncopa> i think the problem is that libruby.so is not linked with -lucontext
2020-12-29 13:04:11 <ncopa> on armv7
2020-12-29 13:04:32 <ncopa> libucontext is static only
2020-12-29 13:04:53 <ncopa> so im not sure how this is supposed to work here
2020-12-29 13:06:12 <mps> lib/libucontext.so.0, armv7
2020-12-29 14:37:56 <ncopa> seems like rebuilding ruby solves it
2020-12-29 14:38:24 <ncopa> maxice8 or Cogitri: sdbus-cpp does not build with elogind due to the version string it sets contains two dots (.)
2020-12-29 14:38:42 <ncopa> any suggestion how to deal with it?
2020-12-29 14:44:15 <Cogitri> Well, I guess either we should patch elogind's version number to not contain dots?
2020-12-29 14:48:16 <fraolt> Cogitri: This is the error log when building anki 2.1.35 on aarch64: https://pastebin.com/4xHVkpLw
2020-12-29 14:48:36 <fraolt> openssl-dev is installed ^^
2020-12-29 14:53:55 <fraolt> It seems, it gets the target from the environment variable TARGET. But I can't figure out for the live of me how to override it. :(
2020-12-29 14:54:30 <Cogitri> Ah, welcome to the endless pain of Rust deps vendoring their own libs
2020-12-29 14:55:09 <Cogitri> Try setting OPENSSL_NO_VENDOR=1 in your environment, maybe that'll make it use the system openssl
2020-12-29 15:01:14 <fraolt> Cogitri: That's not fair, I've been trying to wrap my head around this for hours. It seem's it worked! :)
2020-12-29 15:04:36 <Cogitri> Heh, glad that I could help you :)
2020-12-29 15:07:34 <artok> I think I did mention something like that yesterday ;)
2020-12-29 15:10:18 <artok> not that the exact option, but still =)
2020-12-29 15:10:56 <artok> I hate those things that you look for hours and then someone finds it under minute or so
2020-12-29 15:10:58 <fraolt> artok: Yepp, you said "does it really need openssl built inside it, can't it use system libs?" But I really didn't know that it was actually building openssl (because the description says sth about being a wrapper for rust).
2020-12-29 15:11:38 <Cogitri> Yes, it's a wrapper so it still needs the actual C libs to function
2020-12-29 15:11:50 <artok> sure enough
2020-12-29 15:12:21 <Cogitri> And in an effort to also work on platforms where package management sucks (cough windows cough) most Rust -sys wrappers vendor those libs
2020-12-29 15:12:39 <Cogitri> but since all Rust build scripts are nonstandard they're mostly just hacked together :)
2020-12-29 15:14:43 <fraolt> Dangit, so NO_VENDOR means that it should not do vendoring. I should've thought of that.
2020-12-29 15:18:00 <fraolt> This thing has 385 packages to build. o_O
2020-12-29 15:18:44 <ikke> welcome to rust
2020-12-29 15:21:02 <fraolt> After spending the last ~20 years on linxi, I indeed often forget that there are operating systems without package management. :/ Poor windows gals and guys.
2020-12-29 15:21:18 <fraolt> s/linxi/linux/g
2020-12-29 15:21:18 <alpine-meetbot> fraolt meant to say: After spending the last ~20 years on linux, I indeed often forget that there are operating systems without package management. :/ Poor windows gals and guys.
2020-12-29 15:22:12 <fraolt> whoa, that's a cool bot. :-D
2020-12-29 15:24:52 <skarnet> blah
2020-12-29 15:25:02 <skarnet> s/blah/yes, it is/g
2020-12-29 15:25:02 <alpine-meetbot> skarnet meant to say: yes, it is
2020-12-29 15:25:35 <fraolt> :-D
2020-12-29 15:27:54 <artok> fraolt: do you have some massive(tm) aarch64 machine for the build?
2020-12-29 15:28:11 <fraolt> Okay, next build failure, but now finally on the anki lib i'm trying to build. Down the rabbit hole again.
2020-12-29 15:28:51 <fraolt> artok: It's a pinephone. So, the build takes a few hours. :(
2020-12-29 15:28:59 <artok> ouch
2020-12-29 15:29:52 <fraolt> Thinking about getting me another raspi 4. My current raspi 4 is running as a ubuntu server.
2020-12-29 15:30:46 <fraolt> So, I can't really power it down to start some alpine compiling.
2020-12-29 15:31:49 <fraolt> Especially, since my weechat session is running on it. ;)
2020-12-29 15:33:12 <fraolt> Hmmm... Maybe I should think about using docker for compiling. I guess that is what's being used by gitlab.alpinelinux.org?
2020-12-29 15:42:51 <artok> some proper HD would make it better
2020-12-29 15:43:05 <artok> or do you have neato SSD on usb3 ? =)
2020-12-29 15:46:29 <ikke> fraolt: yes, but we run docker on aarch64 hardware
2020-12-29 15:46:56 <ikke> (beefy servers)
2020-12-29 15:51:05 <fraolt> Well, the raspi 4 is aarch64 (though not particularly beefy).
2020-12-29 15:52:59 <ikke> fraolt: if you want to build an APK, you could use our CI
2020-12-29 16:00:07 <artok> does this look somewhat ok? https://termbin.com/vsdn
2020-12-29 16:00:55 <artok> ..talking about rpi =)
2020-12-29 16:02:17 <ikke> artok: you silently fall back to /tmp if the provided dir does not exists?
2020-12-29 16:04:20 <artok> it seems so =)
2020-12-29 16:09:05 <artok> forcing mkdir here, https://termbin.com/fbag
2020-12-29 16:09:23 <maxice8> ncopa: working on elogind
2020-12-29 16:09:44 <ikke> artok: is that check then even necessary?
2020-12-29 16:09:53 <ikke> you could just always do mkdir -p
2020-12-29 16:16:08 <artok> ikke: true
2020-12-29 16:19:30 <ncopa> 👍
2020-12-29 16:54:22 <fraolt> ikke: Okay, don't wanna hog your resources, but if you say it's fine, I'll gratefully accept the offer. :)
2020-12-29 16:54:57 <fraolt> the only way to trigger the CI is through a MR, am i right?
2020-12-29 17:01:48 <mps> fraolt: on arm64 (and arm32) machines I use ssd disks over usb, not fast as big machines but bearable
2020-12-29 17:03:20 <mps> (say someone who built rust and firefox few times on box with 4GB RAM and FS on mmc card about two years ago)
2020-12-29 17:03:55 <mps> about 12-14 hours for firefox
2020-12-29 17:04:44 <mps> with ssd on usb disk building kernel take about 30-50 minutes, while browsing Inet with firefox
2020-12-29 17:05:48 <fraolt> I'm running on the internal MMC of the pinephone. The four CPU cores are maxed out. So, I don't thing I/O is the limiting factor here.
2020-12-29 17:07:23 <fraolt> Maybe it will be, when I switch to raspi. However, the two USB3 ports are in use for my btrfs-raid. :/
2020-12-29 17:28:27 <ikke> fraolt: as long as it's reasonable
2020-12-29 17:28:40 <ikke>  but yes, it would require an MR
2020-12-29 17:34:25 <fraolt> Ok, should i mark it "[WIP]" or something?
2020-12-29 17:35:00 <fraolt> ikke: ^^
2020-12-29 17:36:21 <mps> yes. you can
2020-12-29 17:36:58 <mps> if it passes tests you can remove 'WIP' and then it could be merged
2020-12-29 17:37:55 <insep_> fraolt: use https://gitlab.alpinelinux.org/alpine/docker-abuild on your server
2020-12-29 17:38:15 <mps> fraolt: when you creating MR there is option to mark it with WIP tag
2020-12-29 17:41:46 <fraolt> insep_: Thanks, I will give that a try.
2020-12-29 17:42:05 <fraolt> mps: I see.
2020-12-29 17:43:11 <fraolt> Thank you all for bearing with me.
2020-12-29 17:44:34 <mps> fraolt: np :)
2020-12-29 19:59:29 <fraolt> Cogitri: Is it intentional that the rustup package does not create a symlink in /usr/bin/ for pointing rustup to rustup-init?
2020-12-29 20:00:22 <fraolt> ^^See my failed build here: https://gitlab.alpinelinux.org/fraolt/aports/-/jobs/281814#L404
2020-12-29 20:01:04 <Cogitri> Yes, that's by design I think, but has been so long that I used rustup that I can't remember the reason why
2020-12-29 20:01:11 <Cogitri> But why does that package try to use rustup
2020-12-29 20:01:14 <Cogitri> It should just use system rust
2020-12-29 20:02:08 <Cogitri> Installing things via pip probably wont fly either
2020-12-29 20:02:21 <Cogitri> Probably as in certainly :)
2020-12-29 20:02:31 <Cogitri> So it should use the python py3-toml or w/e it needs too
2020-12-29 20:07:40 <Ariadne> maxice8: nice
2020-12-29 20:16:38 <fraolt> I've never done any development in rust, so please keep in mind that I probably only understand half of what you and I are saying.
2020-12-29 20:18:39 <fraolt> Cogitri: Anki is using maturin to build the rust to python bindings. I think(!), that the maturin package then uses rustup.
2020-12-29 20:19:54 <fraolt> Do you know how I could convince it to use "system rust" (whatever that is).
2020-12-29 20:23:17 <Cogitri> Dunno, that's something you should ask upstream
2020-12-29 20:23:28 <Cogitri> Well, rustup only installs rust for you
2020-12-29 20:23:51 <Cogitri> But we have rust in our repos and want to use that, so you'll have to somehow make it use /usr/bin/rustc instead of doing some nonsense with rustup
2020-12-29 20:24:51 <fraolt> Oh noes... /o\
2020-12-29 20:25:32 <Cogitri> That's something next to every distro will want though, so maybe you can take a look at how other distros do it
2020-12-29 20:26:24 <ikke> https://github.com/PyO3/maturin/blob/9f8cdba7894cc65110d1ba94140adef97b91e1e3/maturin/__init__.py#L118 seems to indicate it does look for a system rust/cargo
2020-12-29 20:27:04 <ikke> it checks if `cargo --version` works
2020-12-29 20:27:58 <fraolt> I'll keep on digging. Unfortunately, upstream has already changed their build system to something else (bazel), which is not available for musl. :-(
2020-12-29 20:28:15 <ikke> ah fun, bazel
2020-12-29 20:32:36 <mps> :)
2020-12-29 20:33:04 <ikke> mps knows what I'm referring to
2020-12-29 20:33:17 <Cogitri> Hm, I think we have bazel in the repos, no?
2020-12-29 20:33:44 <mps> I hope no, but who knows
2020-12-29 20:33:45 <ikke> https://pkgs.alpinelinux.org/package/edge/testing/x86_64/bazel
2020-12-29 20:34:25 <mps> cmake isn't enough :\
2020-12-29 20:35:29 <fraolt> But only for x86_64, not aarch64. *sigh*
2020-12-29 20:36:12 <mps> it is on aarch64 also
2020-12-29 20:36:41 <ikke> https://pkgs.alpinelinux.org/packages?name=bazel3&branch=edge
2020-12-29 20:36:42 <fraolt> Then maybe I should try getting the newest version to work instead of riding that dead horse.
2020-12-29 20:37:53 <fraolt> Oh, bazel3 is the package. Hmmm... I'll try with that tomorrow.
2020-12-29 20:38:12 <fraolt> Thanks again, everyone!
2020-12-29 21:44:35 <ikke> Most likely found the bug in py3-typed-ast that is causing issues for black
2020-12-29 21:44:42 <ikke> https://github.com/python/typed_ast/issues/151
2020-12-29 22:21:18 <maxice8> Ariadne: ?
2020-12-29 23:13:59 <TBK[m]> ikke: gj 👍️
2020-12-29 23:15:40 <TBK[m]> it is always fun to go down the s390x rabbit hole...
2020-12-30 02:29:54 <Ariadne> if you wanna go down the s390x rabbit hole i have a z13 colocated :))
2020-12-30 07:15:40 <mps> https://busybox.net/downloads/busybox-1.33.0.tar.bz2
2020-12-30 07:16:22 <mps> fixes and improvements
2020-12-30 07:20:12 <mps> 'strace -f' from 'make crystal compiler_spec' https://tpaste.us/g60v
2020-12-30 07:20:42 <mps> mmunmap and FUTEX
2020-12-30 07:22:18 <mps> dalias: if you have some time hints from your deep knowledge would be useful about this ^
2020-12-30 08:01:34 <ncopa> morning
2020-12-30 08:01:48 <fcolista> morning
2020-12-30 08:02:26 <ikke> hey
2020-12-30 08:06:20 <ncopa> ikke: nice work with the typed_ast!
2020-12-30 08:06:48 <ikke> was nice working with upstream
2020-12-30 08:08:07 <ncopa> its always nice with upstream cooperation :)
2020-12-30 08:09:50 <ncopa> is the crystal issue an issue in crystal or in gc?
2020-12-30 08:14:23 <mps> ncopa: I'm not sure, though looks gc
2020-12-30 08:14:40 <ncopa> Ariadne: do you remember why --disable-parallel-mark was reverted?  10b83865787d52b0017cd5b31afa15b9306d7ac9 it looks like it was a workaround for gc for crystal https://www.openwall.com/lists/musl/2020/10/30/1
2020-12-30 08:15:28 <ncopa> ah.. https://www.openwall.com/lists/musl/2020/10/30/10
2020-12-30 08:16:20 <ikke> a regression in musl that should be fixed now
2020-12-30 08:17:13 <mps> hmm
2020-12-30 08:18:29 <mps> last night before bed this arrived to my mind
2020-12-30 08:18:53 <mps> lets see
2020-12-30 08:39:13 <mps> hmm, no luck
2020-12-30 08:40:48 <mps> rebuilt gc with '--disable-parallel-mark' and tried again crystal, it failed with same signal 11
2020-12-30 08:43:01 <mps> but now I see this 'writev(2, [{iov_base="Invalid memory access (signal 11"..., iov_len=60}, {iov_base=NULL, iov_len=0}], 2Invalid memory access (signal 11) at address 0x7ff18041'
2020-12-30 10:42:04 <ncopa> ok
2020-12-30 11:11:28 <ncopa> seems like crystal does not segfault when running in valgrind. i suspect that it is the mallocng that finds something fishy
2020-12-30 11:14:17 <mps> also I think so, and I wrote 'that' (my thinking) few times here
2020-12-30 11:14:51 <mps> or maybe musl MT-fork found something buggy
2020-12-30 11:15:37 <mps> iirc, before MT-fork it worked
2020-12-30 11:15:48 <mps> but not sure
2020-12-30 11:18:48 <mps> unrelated but to not forget, !16183 doesn't look 'fine' (sic!) to me
2020-12-30 11:19:36 <nmeum> weird change indeed
2020-12-30 11:42:56 <ikke> mps: then certainly leave a comment
2020-12-30 11:45:56 <mps> ikke: and always I have to be 'grumpy man' of alpine ;p
2020-12-30 11:47:36 <mps> ncopa: I see that you build gc with debug and it worked. I did same about month ago but it didn't worked for me, load gc symbols I mean. what's the trick?
2020-12-30 13:01:19 <ncopa> I just added -dbg subpackage
2020-12-30 13:09:45 <mps> hmm, I did same
2020-12-30 13:10:39 <mps> and installed gc-dbg but ... will try in few hours, I see you added gc-dbg to aports
2020-12-30 13:18:08 <mps> just pushed linux-edge 5.10.4, new year gift with a lot of fixes :)
2020-12-30 13:48:17 <tehcloud> oh nice, time to see if there are any AMDGPU freezes fixed
2020-12-30 13:58:12 <mps> changelog show amd fixes but AMDGPU is not in good shape in kernel for long time, so only hopes
2020-12-30 13:58:37 <mps> (left all hopes you who entering here)
2020-12-30 14:03:05 <tehcloud> yes, they have messed up my card in 5.10 and the bug reporting process over there is too involved for me to bother with
2020-12-30 14:03:16 <tehcloud> so I'm waiting for someone with more time/patience to have the same problem as me
2020-12-30 18:05:31 <Ariadne> hmm
2020-12-30 18:05:44 <Ariadne> git 2.30.0 upgrade has a broken test on some builders
2020-12-30 18:05:48 <Ariadne> seems related to permissions
2020-12-30 18:08:05 <ikke> ah
2020-12-30 18:08:09 <ikke> there is a patch already
2020-12-30 18:08:14 <ikke> due to sticky bits
2020-12-30 18:08:34 <ikke> Ariadne: https://lore.kernel.org/git/88398ff952a68e8d134dcd50ef0772bb6fc3b456.1609339792.git.matheus.bernardino@usp.br/T/#u
2020-12-30 18:08:38 <ikke> I don't have time to apply this
2020-12-30 18:08:57 <ikke> oh
2020-12-30 18:09:01 <ikke> Oh you disabled it
2020-12-30 18:09:13 <Ariadne> yeah i didn't see that until now
2020-12-30 18:09:17 <ikke> It's not flaky :P
2020-12-30 18:09:29 <Ariadne> yes it reliably fails on some builders
2020-12-30 18:09:33 <Ariadne> either way, it is annoying
2020-12-30 18:09:36 <ikke> yeah
2020-12-30 18:09:51 <ikke> They check permissions, but didn't account for a sticky bit to be present
2020-12-30 18:10:12 <ikke> I'll aply that patch later
2020-12-30 19:29:23 <dalias> mps, what is the problem you wanted me to look at?
2020-12-30 19:30:31 <dalias> ncopa, the parallel mark thing was a workaround for a regression in musl git master that was later fixed
2020-12-30 19:30:34 <mps> dalias: does it segfault because big is mmunmap or because some futex issue
2020-12-30 19:30:50 <dalias> no, it segfaults because it's accessing invalid memory. the strace seems unrelated
2020-12-30 19:31:00 <mps> s/big//
2020-12-30 19:31:00 <alpine-meetbot> mps meant to say: dalias: does it segfault because  is mmunmap or because some futex issue
2020-12-30 19:31:11 <mps> s/big/bug/
2020-12-30 19:31:11 <alpine-meetbot> mps meant to say: dalias: does it segfault because bug is mmunmap or because some futex issue
2020-12-30 19:31:18 <dalias> looks like normal use-after-free
2020-12-30 19:31:49 <mps> aha, in libgc?
2020-12-30 19:32:06 <dalias> the memory it's accessing was unmapped in [pid  2721] munmap(0x7f373e623000, 65536) = 0
2020-12-30 19:32:31 <mps> yes, (I was blind)
2020-12-30 19:41:08 <mps> dalias: ncopa later tested that with gdb and commented here https://gitlab.alpinelinux.org/alpine/aports/-/issues/12228#note_132983
2020-12-30 19:44:56 <mps> sorry, this note https://gitlab.alpinelinux.org/alpine/aports/-/issues/12228#note_133001
2020-12-30 19:46:06 <mps> hmm, so maybe libgc is ok
2020-12-31 07:07:59 <ikke> morning
2020-12-31 07:08:12 <ikke> I think the ansible-lint MR can be merged, right?
2020-12-31 07:18:50 <maxice8> yes, it is consistently failing on the builders
2020-12-31 07:20:09 <maxice8> merged
2020-12-31 07:38:28 <ncopa> morning
2020-12-31 07:43:05 <mps> \o
2020-12-31 07:51:08 <ikke> hi
2020-12-31 07:51:35 <ikke> v3.13/community/s390x: uploaded
2020-12-31 07:52:33 <ncopa> \o/
2020-12-31 08:11:09 <ncopa> looks like rust is broken on ppc64le
2020-12-31 08:11:11 <ncopa>  (signal: 11, SIGSEGV: invalid memory reference)
2020-12-31 08:13:04 <ikke> oof
2020-12-31 08:13:34 <ncopa> i think we should create an issue and have one of our ppc ppl to look at it
2020-12-31 08:14:16 <ncopa> im disabling tau on ppc64le for now
2020-12-31 08:15:17 <ikke> ncopa: same seems to have happened on armv7? https://gitlab.alpinelinux.org/alpine/aports/-/issues/12258
2020-12-31 08:23:23 <ncopa> hum
2020-12-31 08:23:34 <ncopa> i have a feeling that it is llvm that is broken
2020-12-31 08:23:42 <ncopa> both crystal and rust uses llvm
2020-12-31 08:28:05 <Cogitri> fwiw Rust has been SIGSEGV'ing on some arches (especially ppc64le) due to some bugs around LLVM handling since like forever
2020-12-31 08:28:21 <Cogitri> Especially on big packages like gtk-rs
2020-12-31 08:30:36 <mps> I remember that for year or two that crystal on builders also fails, and on next cycle it pass
2020-12-31 08:32:31 <mps> I always thought that whole idea around llvm (and such things) is broken by design
2020-12-31 08:32:41 <ncopa> yeah, we had issues on arm with crystal
2020-12-31 08:32:57 <Cogitri> Hm, llvm is pretty amazing imho, we probably wouldn't have langs like crystal without it
2020-12-31 08:33:17 <Cogitri> Or zig. Having a ready to go compiler backend with lots of optimizations is pretty neato
2020-12-31 08:33:52 <mps> imo, optimization idea what is broken by desing
2020-12-31 08:34:51 <mps> (early optimization is root of all evil, there is such saying in programming circles)
2020-12-31 08:35:28 <ncopa> i dunno if its broken by design. and i think its good that we have llvm. would just be nice if it worked :)
2020-12-31 08:36:05 <Cogitri> Prematuee optimization is the root of all evil, but being slower than a sliderule because you do the have any optimizations isn't much better :D
2020-12-31 08:37:21 <mps> correctness is more important that 'fast', but nowadays not many cares. all want featurism and one most liked is speed
2020-12-31 08:37:48 <detha> so what you are saying is that one needs to optimize the level of optimization that is applied
2020-12-31 08:39:14 <mps> correct optimization to some degree could be done only by human 'mind', not by tool
2020-12-31 08:40:13 <detha> hmm. human mind is genrally not capable of keeping track of what might stall a CPU pipeline
2020-12-31 08:40:48 <detha> the old rule was: don't micro-optimize the implementation, find a faster algorithm
2020-12-31 08:40:51 <mps> and tool made by same human mind can?
2020-12-31 08:41:28 <ncopa> why isnt plasma-desktop built on x86 and x86_64? maybe a circular dep?
2020-12-31 08:43:31 <ncopa> ah
2020-12-31 08:43:39 <ncopa> its built, but it does not have any -dev package
2020-12-31 09:44:22 <Cogitri> Today really is works-for-me day, can't reproduce any of the failures of the builders locally :D
2020-12-31 09:45:44 <ikke> 😑
2020-12-31 09:45:53 <mps> what's with this !!15874
2020-12-31 09:46:09 <mps> so much commits, over 1000
2020-12-31 09:46:48 <ncopa> rebased against wrong branch or similar
2020-12-31 09:46:49 <ikke> 12k :D
2020-12-31 09:47:10 <mps> yes, I thought so
2020-12-31 09:47:13 <Cogitri> Or branched off 3.10-stable and then want to merge against master
2020-12-31 09:47:52 <mps> low bar on gitlab will destroy alpine :)
2020-12-31 09:48:00 <Cogitri> Let's see if merging it into 3.10 will fix it
2020-12-31 09:48:16 <mps> though yes, once I made same error
2020-12-31 09:48:17 <ncopa> i think we will be fine as long as noone merges that :)
2020-12-31 09:48:22 <mps> 
ACTION hides

2020-12-31 09:48:27 <Cogitri> Ah nop, master instead of 3.12-stable is the right target
2020-12-31 09:48:31 <Cogitri> 3 commits against master
2020-12-31 09:48:47 <ikke> so branched off master but wanted to target 3.12-stable most likely?
2020-12-31 09:48:48 <Cogitri> But that downgrades redis?
2020-12-31 09:48:52 <Cogitri> Yes, probably
2020-12-31 09:50:23 <mps> to my defense, I made such error when we just switched to GL and when we still testing it
2020-12-31 09:52:11 <mps> Natanael Copa | main/linux-lts: CONFIG_PINCTRL_CHERRYVIEW=y
2020-12-31 09:52:23 <mps> are you sure this is ok?
2020-12-31 09:52:28 <ncopa> yup
2020-12-31 09:52:43 <ncopa> why wouldnt it be?
2020-12-31 09:52:54 <mps> hmm, one day you will 'make allyesconfig' :)
2020-12-31 09:53:32 <ncopa> then you run linux-edge...
2020-12-31 09:53:34 <ncopa> ;)
2020-12-31 09:53:52 <ncopa> maxice8: that bash update is risky...
2020-12-31 09:53:59 <mps> I'm not sure. why this can't be fixed by using initramfs
2020-12-31 09:54:34 <maxice8> ncopa: Yes but mps wanted new readline and from what I'm reading bash 5.1.0 has a change that requires the new readline.
2020-12-31 09:54:34 <mps> hehe, I run linux-edge for long time already, even linux-rc
2020-12-31 09:54:35 <ncopa> it is explained in #12238
2020-12-31 09:55:33 <mps> ncopa: I read it and still not sure should it be =y
2020-12-31 09:56:09 <mps> hmm, do we use bash for anything essential
2020-12-31 09:57:00 <ncopa> the reporter said that he tried add the kernel module to initramfs and it still wasnt detected
2020-12-31 09:57:13 <ncopa> i checked what fedora does, and they also set it to y
2020-12-31 09:59:08 <mps> ok, but I'm still not sure. If someone else have this 'strabo' to test
2020-12-31 10:00:00 <mps> what looks strange to me is that the kernel can't load module for detected hardware
2020-12-31 10:00:25 <ncopa> i think the problem is that the hardware isnt detected
2020-12-31 10:01:25 <mps> if hardware is not detected how then 'nonolithic' driver work
2020-12-31 10:02:50 <mps> but there are some quirks in kernel with similar behavior, I have one of such which is not solved for months despite bug reports I posted
2020-12-31 10:03:51 <ncopa> bug number?
2020-12-31 10:04:20 <mps> bugzilla.kernel.org, not alpine
2020-12-31 10:05:14 <mps> ohm, no subsystem ML, related to driver/net/usb
2020-12-31 10:06:06 <mps> s/no/no,/
2020-12-31 10:06:06 <alpine-meetbot> mps meant to say: ohm, no, subsystem ML, related to driver/net/usb
2020-12-31 10:06:17 <mps> 
ACTION gramaticus

2020-12-31 12:02:08 <ikke> ncopa: nice one: "underlinking issue" :P
2020-12-31 12:33:04 <Cogitri> https://pkgs.alpinelinux.org/packages?name=gnome-software-plugin-apk&branch=edge weird, gnome-software-plugin-apk works on edge
2020-12-31 12:33:13 <Cogitri> ikke: Can you get me the gnome-software-dev package of 3.13?
2020-12-31 13:38:31 <jvoisin> are there any plans/efforts/experiment/… to build alpine with clang's cfi enabled?
2020-12-31 13:41:07 <ncopa> Cogitri: which arch?
2020-12-31 13:42:05 <ncopa> i make build-3-13-x86_64 continue on errors so it uploads the packages to the mirrors
2020-12-31 13:46:40 <Cogitri> I think gnome-software-plugin-apk fails to build on all arches, so the arch shouldn't matter
2020-12-31 13:49:10 <omni> I found this https://github.com/a13xp0p0v/kconfig-hardened-check/ and became curious if it is something you are aware of and use or not
2020-12-31 13:49:54 <ncopa> havent seen it before
2020-12-31 13:50:22 <omni> I found it through https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
2020-12-31 13:51:35 <mps> aha, 'make allyesconfig' again today :)
2020-12-31 13:59:51 <omni> it seems like a useful tool to help keep track of and have suggestions on kernel configuration parameters, I'm sure you have good reasoning for when to enable something or not
2020-12-31 14:01:02 <omni> but you used to maintain a grsec hardened kernel, before they had their patches only commersially available, perhaps the above could help in maintaing a possible future slim and hardened kernel
2020-12-31 14:02:39 <ikke> "For a particular paranoid system"
2020-12-31 14:05:38 <mps> for more than 20 years I had systems/servers with different hardened frameworks/features (rbac, lids, grsec, selinux) and in last few years I come to conclusion that these are mostly useless
2020-12-31 14:05:44 <omni> paranoid-lts, paranoid-virt
2020-12-31 14:18:02 <mps> and, how we can know for things which 'every man and his dog' put on github (rhetorical question, no need to answer)
2020-12-31 14:20:28 <tehcloud> mps, I'm with you on that... have had the same experience
2020-12-31 14:21:01 <tehcloud> and I've found the biggest security flaws are managerial/human ones
2020-12-31 14:23:07 <ikke> Isn
2020-12-31 14:23:15 <ikke> Isn't there a joke about an operator and a dog?
2020-12-31 14:25:44 <skarnet> it took you that long to realize it ? :D
2020-12-31 14:25:59 <mps> ikke: could be, these words 'compose' nicely with a lot of things
2020-12-31 14:26:15 <skarnet> (gah, scrolling. That was aimed at mps's statement that all the nifty security features are mostly buzzwords)
2020-12-31 14:27:18 <mps> skarnet: I knew this long time, but 'security' is good for selling to those who like these buzzwords, and good to get money :)
2020-12-31 14:27:24 <tehcloud> your boss tells you to turn it off because the CFO or VP Marketing is finding it annoying
2020-12-31 14:27:26 <skarnet> yes, we tech types love to harden things over and over but every time a security issue happens it's something human
2020-12-31 14:27:50 <skarnet> mps: agreed, the only good thing it brings is money, but I'd rather be earning money doing actually useful things
2020-12-31 14:30:15 <mps> well, I usually do like you but when managers come and ask/require 'security' feature I have no options, because I have to have money for living
2020-12-31 14:30:46 <skarnet> I know :/
2020-12-31 14:54:46 <ikke> rust 1.49.0 https://blog.rust-lang.org/2020/12/31/Rust-1.49.0.html
2020-12-31 14:56:12 <ikke> aarch64-unknown-linux-gnu has tier1 support now (no idea if that affects us)
2020-12-31 14:57:23 <mps> gnu is not musl :)
2020-12-31 14:57:56 <mps> rephrasing 'gnu is not unix'
2020-12-31 14:58:07 <ikke> hehe
2020-12-31 14:58:16 <jvoisin> gnusl
2020-12-31 16:12:52 <fraolt> Is it possible to download the package that has been built by a MR's CI build-job?
2020-12-31 16:13:47 <mps> fraolt: yes
2020-12-31 16:15:14 <mps> go to pipeline and click browse or download and follow links
2020-12-31 16:15:20 <fraolt> Now I see it /o\: Job artifacts
2020-12-31 16:15:52 <mps> yes
2020-12-31 16:16:15 <fraolt> mps, thx!
2020-12-31 16:17:52 <fraolt> Does anyone know the reason, why bazel3 is stuck at 3.5.0?
2020-12-31 16:25:51 <Cogitri> You mean why it's not updated in aports?
2020-12-31 16:26:01 <Cogitri> Probably because no one did the work for the upgrade yet
2020-12-31 16:26:46 <ikke> Cogitri: do you still need the apk for gnome-software-plugins-apk?
2020-12-31 16:27:01 <Cogitri> For gnome-software-dev, yes
2020-12-31 16:27:05 <ikke> ah
2020-12-31 16:27:37 <Cogitri> I want to check if the pkgconfig file is different compared to edge since gnome-sofrware-plugin-apk links different things on 3.13 than on edge
2020-12-31 16:30:04 <ikke> https://dev.alpinelinux.org/archive/gnome-software-dev-3.38.0-r1.apk
2020-12-31 16:33:00 <fraolt> Cogitri: Ok, well. Then I'll give it a try.
2020-12-31 17:05:02 <ncopa> the 3.13 packages are available for x86_64 now. i resetting it to halt-on-failure
2020-12-31 17:05:53 <ikke> good
2020-12-31 17:06:42 <mps> I added some notes about some alpine use cases on http://arvanta.net/alpine/, is the disclaimer on top of http://arvanta.net/alpine/install-arm-under-qemu/ 'good enough' in the days of a lot of 'plushies' around
2020-12-31 17:07:08 <ikke> Cogitri: I think I accidentilly gavey you the edge version
2020-12-31 17:08:17 <ikke> Cogitri: the apk that is there now should be the right one
2020-12-31 17:13:08 <Cogitri> ikke: Okie, thanks
2020-12-31 17:59:53 <fraolt> There is now a MR to update bazel3 to the most current release: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16320
2020-12-31 18:00:57 <fraolt> I know who the maintainer is, but an @mention is not completed. Anybody knows why?
2020-12-31 18:01:46 <fraolt> ^^ not completed in gitlab when I type @ and the first letters of their name.
2020-12-31 18:02:01 <ikke> because gitlab only completes usernames for users that are linked to the project
2020-12-31 18:02:09 <ikke> a member
2020-12-31 18:02:16 <insep_> mentions compete only for project members
2020-12-31 18:02:19 <ikke> yes
2020-12-31 18:02:44 <fraolt> can i @mention them anyway when I know their handle?
2020-12-31 18:04:01 <ikke> yes
2020-12-31 18:04:07 <fraolt> thx!
2020-12-31 18:18:25 <ikke> merged
2020-12-31 18:37:03 <Ariadne> mps: probably
2020-12-31 18:37:48 <mps> Ariadne: thanks
2020-12-31 18:38:56 <mps> would be nice if we can enable wiki on gitlab and put such guides/notes there
2020-12-31 18:40:15 <ikke> we have a wiki :P
2020-12-31 18:40:41 <mps> :P
2020-12-31 18:50:29 <mps> ncopa: you asked this morning about bug number related to kernel, https://bugzilla.kernel.org/show_bug.cgi?id=209401
2020-12-31 18:51:04 <mps> this one is not related to one I posted to drivers/net/usb ML
2020-12-31 18:51:38 <mps> but shows how kernel developers are 'fast and responsive'
2020-12-31 18:52:42 <mps> and before opening above one to bugzilla I posted it few months earlier to drivers/gpu/drm ML
2020-12-31 18:53:12 <mps> yes, some of them are fast like snails ;)
2020-12-31 18:54:10 <mps> but some other kernel developers are really fast and responsive (maybe most of them)
2020-12-31 18:54:33 <Ariadne> mps: that display freeze issue has happened to me once or twice on i915 and happens frequently in X
2020-12-31 18:54:43 <Ariadne> i wonder if something in DRI is busted
2020-12-31 18:55:59 <mps> I have it only on gru-kevin chromebook, and it started with kernel 5.4 and up
2020-12-31 18:56:30 <mps> last which worked fine was 5.3
2020-12-31 20:42:03 <fraolt> ikke: Thanks for merging!