2021-06-01 00:34:14 <ericonr> Ariadne: I think nvidia-docker can work on alpine :P
2021-06-01 00:34:23 <ericonr> though that's a very specific use case
2021-06-01 00:34:35 <ericonr> and I'm not sure it actually works
2021-06-01 01:26:00 <Ariadne> the name 'nvidia-docker' seems redolent of a bad idea
2021-06-01 02:19:52 <ericonr> well, you ship "nvidia-docker" to users and they can launch accelerated tensorflow monstrosities inside without worry
2021-06-01 02:20:04 <ericonr> the intent isn't the worst thing ever
2021-06-01 02:31:06 <Hello71> notwithstanding the total insecurity of gpu device files
2021-06-01 04:33:43 <ikke> maxice8: that repo is not a direct fork from alpine
2021-06-01 04:33:55 <ikke> maxice8: Forked from Victor Diego Alejandro Diaz Urbaneja / aports
2021-06-01 04:34:19 <ikke> Hmm, was not aware you could fork from forks, but apparently you can in gitlab
2021-06-01 04:36:16 <ikke> anyway, it's public now
2021-06-01 05:58:46 <ncopa> good morning
2021-06-01 07:21:33 <ikke> o/
2021-06-01 07:21:47 <ikke> Many builders finished building 3.14
2021-06-01 07:22:04 <mps> good morning
2021-06-01 07:22:15 <ikke> It's x86(_64) and aarch64 that are left 
2021-06-01 07:22:40 <mps> any idea when first rc 3.14 will be out
2021-06-01 07:23:19 <ikke> Once we fixed all the build issues for it
2021-06-01 07:23:58 <mps> aha, around december
2021-06-01 07:24:21 <ikke> Wine, lua-rapidjson, glibd 
2021-06-01 07:25:01 <ikke> Different mingw packaged 
2021-06-01 07:38:45 <mps> anyone know where is this defined `unicode.c:(.text+0x645): undefined reference to `utf8_to_unicode'`
2021-06-01 07:39:00 <mps> I mean, which library
2021-06-01 09:00:23 <maribu[m]> In https://gitlab.alpinelinux.org/maribu/aports/-/jobs/405600 I'm getting `ERROR: libftdi1-1.5-r0: BAD signature` for armhf. Running `curl -X PURGE <PKGURL>` didn't fix the issue :-/ Does anyone have an idea?
2021-06-01 09:05:25 <ikke> Which arch? 
2021-06-01 09:05:44 <ikke> Hmm, purging didn't fix it, huh
2021-06-01 09:09:56 <maribu[m]> Just do make sure I didn't mess up something. Purging is done by `$ curl -X PURGE https://dl-cdn.alpinelinux.org/alpine/edge/community/armhf/libftdi1-1.5-r0.apk`, right?
2021-06-01 09:10:11 <maribu[m]> The output was: `{ "status": "ok", "id": "4053-1622127450-2766070" }`
2021-06-01 09:20:41 <ikke> Yes, looks alright 
2021-06-01 09:23:04 <ncopa> im woring on wine
2021-06-01 09:23:22 <ncopa> s/woring/working/
2021-06-01 09:23:22 <alpine-meetbot> ncopa meant to say: im working on wine
2021-06-01 10:03:54 <donoban> hi guys, I read the dkms thread and just have a small idea, if 
2021-06-01 10:03:58 <donoban> ouch*
2021-06-01 10:07:38 <mps> https://tpaste.us/PKBb
2021-06-01 10:07:42 <mps> :)
2021-06-01 10:08:19 <mps> look commented lines and see what we need to write
2021-06-01 10:09:05 <donoban> if the user has the knowledge for build and install an unofficial kernel module but he also wants to have it in sync with kernel upgrades without manually attention, can't be this achieve with some hooks in kernel post-install? as mps pointed most modules should work with just make && make install, I mean that maybe there is a simple way to achieve a basic automation without
2021-06-01 10:09:07 <donoban> dkms
2021-06-01 10:11:20 <mps> donoban: yes, that also could be possible and maybe a simpler (to keep alpine philosophy :) ) than dkms
2021-06-01 10:11:21 <donoban> uHm, I suppose that should be some hooks examples
2021-06-01 10:13:03 <mps> but if we do that half of users will be happy and half will scorn us because we didn't follow what other distros do and we are 'smart ...' ;)
2021-06-01 10:15:22 <donoban> hehe well, I'm not sure what some people see exactly wrong, if not having a reliable mechanism for having external modules properly upgraded, so you could end upgrading rebooting your system and missing them...
2021-06-01 10:16:10 <donoban> or to have more external modules integrated on the distribution and available with 'apk add ...'
2021-06-01 10:21:46 <mps> I think we should postpone dkms (or whatever about this) after 3.14 released
2021-06-01 10:22:36 <mps> I mean also discussion about this
2021-06-01 10:23:54 <donoban> hehe ok
2021-06-01 11:20:19 <ikke> maribu[m]: seeems to already have a bad signature on dl-master, so it's not a caching issue
2021-06-01 11:28:34 <markand> hey there
2021-06-01 11:29:06 <markand> I wanted this mr (!21452) to be merged *before* 3.14 so it's effective for that release (as it's planned soon AFAIK)
2021-06-01 11:29:33 <markand> but with a milestone of 3.15 I don't understand when it will be merged
2021-06-01 11:31:26 <donoban> Is there some kind of freeze due 3.14? I have !20855 ready since some days ago
2021-06-01 11:35:06 <ncopa> donoban: we do have a freeze for 3.14 but i think !20855 can be merged unless it breaks lots of things
2021-06-01 11:49:39 <spameier> Hello everybody! I submitted MRs !21523 and !20893. I would like to have them merged and am wondering how to get someone to review them?
2021-06-01 11:56:58 <ncopa> im working on mingw
2021-06-01 11:59:17 <ncopa> markand: so libretro does not ship releases? we are just supposed to build and run a random git commit?
2021-06-01 11:59:54 <markand> yes, there are too many cores and their development are not always the same, so only retroarch is versioned
2021-06-01 12:00:40 <markand> but they make good quality cores, their 'master' branch isn't meant to be unstable anyway
2021-06-01 12:01:19 <markand> so packagers like retropie and friends tend to upgrade the packages once in a while in their distributions
2021-06-01 12:01:32 <markand> the idea is not to upgrade every 2 weeks anyway
2021-06-01 12:01:51 <markand> (I myself do usually 2 times per year)
2021-06-01 12:02:02 <ncopa> so basically, they let downstream do the release engineering for them
2021-06-01 12:02:29 <ncopa> i normally don't think it is a good idea that we do it for them. we have more than enough to deal with
2021-06-01 12:02:57 <markand> it's more complex than that. libretro devs tend to fork original emulators to bring their libretro interface on top of it and then push it upstream, but some upstream devs don't care at all 
2021-06-01 12:03:31 <markand> for example mednafen and dolphin (AFAIK, or desmume?) were quite hostile to the libretro integration 
2021-06-01 12:03:41 <ncopa> it is the "upstream devs don't care at all" that im worried about
2021-06-01 12:03:47 <ncopa> what about security fixes?
2021-06-01 12:04:24 <markand> not sure if NES emulators and friends are pretty open to security risks TBH 
2021-06-01 12:04:45 <ncopa> what i normally ask is: if upstream does not want take responsibility, why should we?
2021-06-01 12:05:19 <ncopa> they normally don't want resonsibility for a reason
2021-06-01 12:05:39 <markand> I'm not sure to understand, libretro ship their own binaries that you may install directly from RetroArch for a multiple set of platforms
2021-06-01 12:05:45 <markand> but not for musl
2021-06-01 12:06:08 <ncopa> and they ship them with version numbers?
2021-06-01 12:06:09 <markand> linux, windows, nintendo switch, android, iOS, etc etc
2021-06-01 12:06:17 <ncopa> oh, ok so they do releases
2021-06-01 12:06:26 <maribu[m]> @ikke: was is the solution regarding the bad signature on dl-master? Bump pkgrel and rebuild?
2021-06-01 12:06:26 <ncopa> do they add git tags when they provides those binaries?
2021-06-01 12:06:26 <markand> I think they ship as CI/rolling release
2021-06-01 12:06:41 <ncopa> ok
2021-06-01 12:07:50 <markand> e.g. https://buildbot.libretro.com/nightly/linux/armhf/latest/
2021-06-01 12:09:01 <markand> but most Linux distributions package themselves (to remove bundled deps and stick to a specific version for a LTS release)
2021-06-01 12:09:36 <markand> except few cores (like dreamcast, nintendo 64) they are very stable 
2021-06-01 12:11:49 <ikke> ncopa: would you have a sec to check what's going on with libftdi1 on armhf? 
2021-06-01 12:12:13 <donoban> wops sorry ncopa I wrote and despite with other things, I doubt it can break anything except telegram itself
2021-06-01 12:13:53 <donoban> at least it worked fine in my computer since last month, altought I didn't test all features
2021-06-01 12:14:23 <donoban> (time for lunch)
2021-06-01 12:38:02 <maxice8> Ikke: thanks
2021-06-01 12:47:14 <valerius> <markand> but they make good quality cores
2021-06-01 12:47:42 <valerius> that's debatable... they tend to add regressions and then alienate upstream developers, then fork and stop maintaining
2021-06-01 12:50:27 <valerius> the best way to handle this situation is not package it, and tell people to use their build scripts if they want to use it
2021-06-01 12:53:21 <orbea> ncopa: libretro does not care about quality control or security, only hype. its a regresison/bug farm.... (I used to maintain their build system)
2021-06-01 13:00:14 <mps> 
ACTION wonders why he have impression that alpine becoming trashcan in last time

2021-06-01 13:05:07 <ikke> People like alpine and want to port software they see to it 
2021-06-01 13:06:58 <nero> alpine will accumulate features
2021-06-01 13:07:10 <nero> and when its en par with debian, people will flock to the next minimalistic distro
2021-06-01 13:13:27 <valerius> it may be time to consider a discussion about layering, as was mentioned yesterday
2021-06-01 13:15:24 <ikke> One layer already exists
2021-06-01 13:19:11 <mps> 'one layer to rule them all out' :)
2021-06-01 13:41:01 <ncopa> orbea: that is what was afraid of
2021-06-01 13:41:15 <ncopa> ikke: i'll check libftdi1 now
2021-06-01 13:42:35 <ncopa> ikke: what is the problem with libftdi1?
2021-06-01 13:43:02 <ikke> Bad signature, even from dl-master
2021-06-01 13:43:24 <ikke> On armhf
2021-06-01 13:51:05 <ncopa> edge?
2021-06-01 13:51:51 <ncopa> ok, i can reproduce
2021-06-01 14:52:12 <ncopa> i think there was some mismatch of libftdi1 due to the time64 migration. should be fixed now, but the dl-cdn cache might need to be purged
2021-06-01 14:52:47 <ikke> I can arrange that 
2021-06-01 14:53:05 <ncopa> thanks!
2021-06-01 14:53:15 <ikke> I have a go tool that needs to be polished, but can do that 
2021-06-01 14:53:31 <ncopa> cool
2021-06-01 14:53:52 <clandmeter> apk fix cdn :)
2021-06-01 14:53:57 <ikke> Hah
2021-06-01 14:54:14 <ikke> apk fix release
2021-06-01 15:01:50 <ncopa> :D the best thing with alpine, if you have a problem you can just 'apk fix problem'
2021-06-01 15:13:58 <markand> there are various bloatware in alpine and problematic ones, if you don't like you don't use
2021-06-01 15:14:07 <markand> that's up to the user, not up to alpine
2021-06-01 15:15:02 <dalias> ncopa, time64 stuff still an issue?
2021-06-01 15:25:34 <Habbie> do i understand correctly from the above that alpine has migrated to 64 bit time_t on 32 bit platforms?
2021-06-01 15:26:21 <ikke> yes, since 3.13
2021-06-01 15:28:29 <Habbie> ah, cool
2021-06-01 16:25:19 <Ariadne> dalias: no, there was just some issues with the mirrors
2021-06-01 16:27:06 <ikke> What probably happened is that a newer pre time_t 64 package ended up on master that prevented the one that was built with time_t 64 from being uploaded
2021-06-01 16:27:22 <dalias> ah
2021-06-01 16:27:45 <dalias> maybe i missed some small ones but i think it's quite amazing how few issues there were with it
2021-06-01 17:11:44 <maribu[m]> ncopa ikke : I still get `ERROR: libftdi1-1.5-r0: BAD signature` in the CI, even after another round of curl -X PURGE <pkgurl>. Any idea?
2021-06-01 18:02:55 <Cogitri> Is it just me or did Gitlab get faster? It doesn't take some 10-20 seconds to rebase anymore :D 
2021-06-01 18:07:09 <ikke> nothing changed on our side
2021-06-01 18:11:40 <Cogitri> Hm, maybe gitlab just has a good day today then
2021-06-01 19:47:36 <ncopa> dalias: not really. I think we may have mixed up the edge builders for armhf when we did the rebuild world last year, so some of the packages might have (had) the 32 bit time_t build
2021-06-01 19:47:44 <ncopa> maribu[m]: I'll check it tomorrow
2021-06-01 19:48:30 <maribu[m]> Thx!
2021-06-02 04:34:23 <anjan> Hi, Im trying to package adjtimex
2021-06-02 04:34:30 <anjan> it's pretty easy: https://paste.sr.ht/~anjan/fd9277dfd3a1fc26006fc10b521d4b60ffc8f363
2021-06-02 04:34:45 <anjan> but then, when it tries to make install, I get the following error: https://paste.sr.ht/~anjan/c05664c8a7049ea5a780e5476220387256755bf0
2021-06-02 04:34:52 <anjan> I feel like Im missing something basic
2021-06-02 04:34:54 <anjan> any help?
2021-06-02 04:36:55 <ikke> anjan: destdir="$pkgdir"
2021-06-02 04:37:00 <ikke> /usr should not be part of that
2021-06-02 04:39:15 <ikke> and not sure if it separately creates directories, but otherwise, that install command lacks -D
2021-06-02 04:39:45 <ikke> (not `make install`, but `instal -c ... adjtimex`
2021-06-02 04:40:06 <anjan> hmmm, it seems that the package in the aur has a patch for the makefile
2021-06-02 04:40:35 <anjan> ya, ok the patch for the makefile in the aur adds -d
2021-06-02 04:40:49 <anjan> ikke: should I put that patch in for the alpine package?
2021-06-02 04:40:53 <anjan> https://aur.archlinux.org/cgit/aur.git/tree/Makefile.patch?h=adjtimex
2021-06-02 04:41:46 <ikke> apparently archlinux copied it from debian 
2021-06-02 04:41:48 <ikke> :D
2021-06-02 04:42:09 <anjan> well lol ok
2021-06-02 04:42:15 <anjan> ya, lets patch it up
2021-06-02 04:43:25 <ikke> https://github.com/rogers0/adjtimex/issues/2
2021-06-02 04:44:01 <ikke> ooh, that's just the debian repo
2021-06-02 04:44:06 <anjan> ya
2021-06-02 04:56:59 <anjan> well, that patch didnt fix it
2021-06-02 04:59:27 <ikke> do you see the bindir being created?
2021-06-02 05:01:19 <anjan> whoops, I didnt add bindir to my make command
2021-06-02 05:03:23 <ikke> I guess prefix is not used at all
2021-06-02 05:16:20 <anjan> ya it isnt
2021-06-02 05:16:35 <anjan> well, I just needed this package to debug something that was working all along....
2021-06-02 05:16:45 <anjan> I still sent a MR. Hopefully it helps someone else =)
2021-06-02 06:57:02 <maribu[m]> Anyone using sway? If so, do you also get the segfault right on start after the recent update of the pkg?
2021-06-02 07:23:16 <smcavoy> maribu[m]: just upgraded to 1.6 on aarch64, crashes with no debug or verbose output / no dmesg errors :(
2021-06-02 07:46:52 <maribu[m]> I was able to get a core dump using `echo 1 > /proc/sys/fs/suid_dumpable` to enable core dumps for programs with setuid, and then the usual `ulimit -c  unlimited`.
2021-06-02 07:48:57 <maribu[m]> The segfault is in a call to `strlen()` from somewhere in `eudev`, but there are no debug symbols for `eudev`.
2021-06-02 07:50:18 <maribu[m]> 
ACTION  < https://matrix.org/_matrix/media/r0/download/matrix.org/eQNELZCizbQatSxERmvNMVly/message.txt >

2021-06-02 07:56:52 <maribu[m]> https://github.com/swaywm/sway/issues/6305
2021-06-02 08:20:44 <gjabell> same issue here, thanks for filing a bug report
2021-06-02 09:22:03 <markand> I'm guessing, makedepends automagically append the non -dev packages to runtime dependencies, but how do you take care of libraries that are header only (like boost)?
2021-06-02 09:23:42 <maribu[m]> ncopa: in main/eudev, libudev.so gets installed into $pkgdir/usr/lib, but subpkg eudev-libs moves it to $subpkgdir/lib. Is this intentional?
2021-06-02 09:24:37 <Sheila> abuild sniffs the binaries to determine what other packages need to be added to the runtime dependencies list; a header-only package isn't going to have runtime dependencies.
2021-06-02 09:26:37 <ncopa> Sheila is correct. abuild uses scanelf to detect what the NEEDED section is for the binaries and auto matically add those. for packages that are headers only there are runtime deps so no need to pull anything in
2021-06-02 09:26:52 <ncopa> abuild only pulls in the deps when needed
2021-06-02 09:27:39 <ncopa> maribu[m]: i guess it was intentional at some point, before the /lib -> /usr/lib split from upsream udev, pre-systemd
2021-06-02 09:27:48 <ncopa> i don't know if it matters anymore
2021-06-02 09:28:15 <ncopa> back then we actually supported a separate /usr partition
2021-06-02 09:28:20 <ncopa> i dont know if that works anymore
2021-06-02 09:29:33 <markand> okay cool
2021-06-02 09:50:56 <maribu[m]> OK. For the -dbg subpackge the issue is that the debug symbols are placed /usr/lib/debug/usr/lib, while the lib in not /usr/lib, but in /lib. Only the eudev-libs libs are in /lib btw. The other libraries are in /usr/lib.
2021-06-02 10:38:25 <PureTryOut> Seems the 3.14 builders are done 🎉 When will the release be?
2021-06-02 10:43:28 <ncopa> should do rc1 today then
2021-06-02 10:52:00 <mps> hmm, I hope it will be next week
2021-06-02 10:52:11 <mps> had a hope*
2021-06-02 10:52:30 <mps> have to upgrade ncurses and linux-tools
2021-06-02 11:27:55 <mps> do we keep ncurses tarball on builders cache
2021-06-02 11:29:43 <mps> upstream released new one with fixes but with same filename as previous one
2021-06-02 11:35:59 <ikke> distfiles.a.o
2021-06-02 11:38:00 <Sheila> heads-up: firefox 89.0 stopped supporting FTP links.
2021-06-02 11:40:54 <Sheila> try ftp://ftp.invisible-island.net/ncurses/current/ncurses-6.2-20210522.tgz
2021-06-02 11:42:24 <mps> interesting, it works for me ;)
2021-06-02 11:42:49 <mps> hehe, network.ftp.enabled => true
2021-06-02 11:43:58 <Sheila> love it when they just quietly change defaults.
2021-06-02 11:44:02 <ikke> http://distfiles.alpinelinux.org/distfiles/ncurses-6.2-20210522.tgz
2021-06-02 11:44:18 <mps> ikke: could this be removed?
2021-06-02 11:44:36 <mps> I doubt I have access there
2021-06-02 11:44:46 <petrj> they might remove the config in future.. not sure why ftp is deemed bad. "google said so" is so lame.. firefox is just doing what google is telling 'em
2021-06-02 11:44:59 <ikke> It will automatically be when you build with a new hash 
2021-06-02 11:45:13 <mps> ikke: aha, thanks for info
2021-06-02 11:45:23 <Sheila> unfortunately, Firefox is the only major non-Chrome browser left outside of platform-specific Safari.
2021-06-02 11:45:43 <mps> petrj: google is 'main' sponsor for mozilla
2021-06-02 11:53:14 <donoban> petrj: https://superuser.com/questions/1377319/ftp-ftps-looks-like-its-gradually-being-deprecated-what-are-windows-browser see WONTFIX links about FTP over TLS
2021-06-02 11:53:47 <donoban> they considered ftp deprecated even 5 years ago...
2021-06-02 11:59:51 <petrj> guess gcc release along with dozens of other FOSS software will need to move from ftp to https. and "certificate authority" being google/microsoft.. incontinence aside, somethings i don't like about this. :) 
2021-06-02 12:03:55 <Sheila> a lot of them already provide HTTP/HTTPS access.
2021-06-02 12:31:37 <mps> ikke: looks like it didn't worked
2021-06-02 12:32:04 <mps> I mean, refreshing new tarball for ncurses
2021-06-02 12:32:32 <ikke> Because the remote file above failed the sha512sum check it will be renamed.
2021-06-02 12:32:34 <ikke> Rebuilding will cause it to re-download which in some cases may fix the problem.
2021-06-02 12:32:59 <ikke> So next run it should work 
2021-06-02 12:35:01 <mps> aha, retrying helped
2021-06-02 13:22:23 <ncopa> build-3-14-ppc64le is still behind
2021-06-02 15:42:02 <agris> Hello,
2021-06-02 15:42:40 <agris> the init posix shell script in the initramfs of Alpine, is there a better way to get at those sources rather than dissecting the ISO file?
2021-06-02 15:42:52 <agris> I want to do some development on that
2021-06-02 15:45:49 <ikke> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in
2021-06-02 15:46:47 <agris> thankyou
2021-06-02 19:16:20 <maribu[m]> Regarding the segfault in current sway: Has anyone every seen that the Procedure Linkage Table gets corrupted during execution?
2021-06-02 19:18:32 <maribu[m]> The issue is that when iterating in eudev over the list of subsystem filters, the iteration doesn't stop at the end of the list. The culprit is that `udev_list_entry_get_next()` should return `NULL` at the end of the list, but it doesn't. However, stepping through the machine code revieded that the call to `udev_list_entry_get_next` calls into `udev_list_entry_get_next@plt`, which should in turn call into `udev_list_entry_get_next`. But
2021-06-02 19:18:32 <maribu[m]> it calls into `udev_list_entry_get_name@plt` instead.
2021-06-02 19:18:58 <maribu[m]> Or is this some issue with dynamic linking gone wrong?
2021-06-02 19:19:57 <mps> maribu[m]: try with libudev-zero ;)
2021-06-02 19:23:31 <maribu[m]> mps  thing is: In a minimum C program in which I tried to reproduce the issue everything works fine. I do like libudev-zero from the description, but I think udev segfaulting here is just a symptom of a deeper problem.
2021-06-02 19:24:26 <maribu[m]> That said, I might still give libudev-zero a try. But I want first to fix the issue, as otherwise it might bite me in the ass somewhere else
2021-06-02 19:24:58 <Cogitri> Huh, that sounds really weird
2021-06-02 19:31:45 <maribu[m]> honestly, I just learned about the procedure linkage table now. Normally, gdb will just place a single break point for a function - I think ignoring the trampoline in the plt. But since in sway the plt doesn't call the correct function, GDB created two break points
2021-06-02 19:33:03 <maribu[m]> When single stepping through the minimum example (with `stepi`), I see that the same call also goes through a plt trampoline, but that one calls the corresponding function. And GDB consequently only created a single bread point there.
2021-06-02 19:40:48 <Hello71> sounds like you are being misled by gdb bt
2021-06-02 20:30:56 <nmeum> mps: are you actually using libudev-zero on a daily basis?
2021-06-02 20:41:21 <dalias> maribu[m], i think it's more likely that gdb is presenting wrong information confusing you about what's going on, than that it's doing the breakpoint wrong. but if debug/symbolic info is missing it could be doing something wrong
2021-06-02 20:49:08 <mps> nmeum: you have doubt on this? :)
2021-06-02 20:49:37 <mps> nmeum: yes, on workstations and some servers
2021-06-02 20:51:05 <nmeum> interesting, I might look into it again then :)
2021-06-02 20:53:29 <mps> next thing is removal of dbus from workstations, on server it doesn't make sense and I don't it there
2021-06-02 20:55:52 <mps> actually I use dbus only for keyboard switcher/indicator
2021-06-02 21:12:13 <Misthios> mps werent u doing something to make iwd run without dbus (or am i remembering it wrong)
2021-06-02 21:26:21 <mps> Misthios: yes, I'm playing with eiwd (iwd fork) which don't need dbus
2021-06-02 21:26:42 <mps> but it is not yet ready for alpine pkg
2021-06-02 21:27:25 <mps> author is same for libudev-zero
2021-06-02 21:31:54 <Misthios> Hmm might check it out tmrw
2021-06-02 21:33:54 <ericonr> mps: I didn't accept eiwd into void because it stopped being updated
2021-06-02 21:34:02 <ericonr> iwd still gets bug fixes :/
2021-06-02 21:37:17 <mps> ericonr: did you looked here https://github.com/illiliti/eiwd
2021-06-02 21:52:50 <ericonr> mps: no, wasn't aware of it
2021-06-02 21:57:54 <ericonr> though I actually like iwd's dbus client :p
2021-06-02 22:01:14 <mps> yes, on workstations/notebooks (moving around) iwctl and iwgtk are good to have
2021-06-02 22:01:50 <mps> but for appliances (SBC things) eiwd would be very useful imo
2021-06-02 22:11:59 <ericonr> fair enough
2021-06-02 22:21:39 <ollieparanoid> FYI http://dl-2.alpinelinux.org/alpine/ is outdated: https://mirrors.alpinelinux.org/#mirror3
2021-06-02 22:58:49 <ollieparanoid> that page is missing columns for v3.13 and v3.14 btw, can somebody add them? it's a quite useful status page
2021-06-03 01:04:39 <craftyguy> ncopa: is this just waiting on folks to test it, or something else? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21566
2021-06-03 02:45:39 <anjan> Hi, so I want to move this package to community https://pkgs.alpinelinux.org/package/edge/testing/x86_64/xsel but I think the maintainer might be inactive https://gitlab.alpinelinux.org/alpine/aports/-/issues/12293
2021-06-03 02:45:47 <anjan> I tried emailing the maintainer and the email bounced
2021-06-03 02:46:07 <anjan> can I just claim maintainership?
2021-06-03 02:46:27 <anjan> I need to move that package to community since the package I want in community depends on xsel
2021-06-03 03:02:45 <Ariadne> yes
2021-06-03 03:02:50 <Ariadne> i'm willing to sign off on that
2021-06-03 03:02:57 <Ariadne> can you open an MR doing it
2021-06-03 03:24:23 <anjan> Ariadne: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21979 
2021-06-03 03:24:43 <anjan> The maintainer is actually dai9ah but he is also on that inactive list =(
2021-06-03 03:25:01 <anjan> Ariadne: I hope thats ok
2021-06-03 03:27:01 <Ariadne> done
2021-06-03 03:27:09 <anjan> Thank you!
2021-06-03 03:30:38 <anjan> So question regarding the CI: if I have a package that is in community, but its dependency is in testing, does the CI check for that?
2021-06-03 03:31:03 <anjan> Like a requirement of a package being in community is it should work without testing/. Am I mistaken?
2021-06-03 03:32:34 <craftyguy> anjan: that's my understanding too. stable alpine releases don't include testing, so the package would break
2021-06-03 03:33:19 <anjan> craftyguy: I see, I forgot to include a dependency of the package sxmo-utils (xsel) and the CI for the MR passed.
2021-06-03 03:33:39 <anjan> So now Im worried if I broke my package by moving it to community/
2021-06-03 03:33:55 <craftyguy> huh, yeah I'm not sure the CI is supposed to catch that...
2021-06-03 03:34:03 <anjan> ya
2021-06-03 03:34:11 <Ariadne> it will be fine
2021-06-03 03:34:17 <craftyguy> it's fine on edge
2021-06-03 03:34:43 <anjan> ah ok
2021-06-03 03:34:48 <anjan> Im just paranoid hehe
2021-06-03 03:34:51 <anjan> thanks guys!
2021-06-03 03:40:41 <Ariadne> if you want your app in 3.14 though, might want to get on that asap
2021-06-03 03:40:51 <Ariadne> we're technically in a freeze, but :P
2021-06-03 03:41:45 <anjan> Ariadne: ya, ollie told me to get on it asap today
2021-06-03 03:41:57 <anjan> I do want sxmo 1.4.0 in 3.14
2021-06-03 03:42:16 <anjan> hopefully Im not too late: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21976
2021-06-03 03:42:57 <anjan> Im gonna be up for another couple of hours playing rimworld so feel free to tag me in irc if there's any fixes I need to make in order to get it in tonight.
2021-06-03 04:03:45 <Ariadne> done
2021-06-03 04:04:06 <anjan> Thank you! Alpine is always so quick =)
2021-06-03 04:37:43 <ikke> CI should catch missing dependencies or depending on packages in 'lower' repositories
2021-06-03 05:41:08 <maribu[m]> @dalias: The debug symbols were present. And I did step through the code using `stepi`, and I could really see that the machine code executed is not matching the implementation of the C function called. Doing the same with the minimal proof of concept code, everything was fine.
2021-06-03 06:24:00 <ncopa> good morning. the build-*-x86* servers will be shut down for maintenance in a few minutes
2021-06-03 06:25:28 <ncopa> it also affects dev.a.o and distfiles
2021-06-03 06:32:50 <Ariadne> DylanVanAssche: we're having some problems building eg25-manager.
2021-06-03 06:32:57 <Ariadne> DylanVanAssche: seems to be meson 0.58 related
2021-06-03 06:35:01 <DylanVanAssche> Ariadne: Is there a link where I can see the build logs? build.alpinelinux.org is not responding here and I cannot find an issue in aports
2021-06-03 06:35:16 <Ariadne> DylanVanAssche: https://build.alpinelinux.org/buildlogs/build-3-14-ppc64le/community/eg25-manager/eg25-manager-0.3.0-r0.log
2021-06-03 06:35:22 <Ariadne> o
2021-06-03 06:35:24 <Ariadne> its down
2021-06-03 06:35:48 <Ariadne> DylanVanAssche: https://tpaste.us/MQo7 
2021-06-03 06:38:29 <ncopa> its down for maintenance. will probably be down for a couple of hours
2021-06-03 06:39:54 <DylanVanAssche> Ariadne: It seems to be a problem related to oFono. It was recently upgraded and seems not to include `gdbo-manager.h` for some reason
2021-06-03 06:54:07 <smcavoy> anyone else experience segfaults with the latest (1.6) version of sway in edge? I am seeing segfaults on aarch64 (lima) and in a x86_64 virtualbox (vmware,3daccel), system.
2021-06-03 07:01:21 <Cogitri> I think @maribu:matrix.org had segfaults too
2021-06-03 07:04:04 <Misthios> Lots of people, rhere is/was upstream bug about it
2021-06-03 07:10:43 <maribu[m]> smcavoy https://github.com/swaywm/sway/issues/6305#issuecomment-853316173
2021-06-03 07:22:26 <smcavoy> Cogitri: thanks, I just read his github issue with Sway
2021-06-03 07:23:56 <ikke> DylanVanAssche: when I built it locally, it worked 
2021-06-03 07:24:22 <ikke> It was just that those headers were not generated 
2021-06-03 07:24:51 <DylanVanAssche> ikke: Yes, those headers were missing, but they come from ofono AFAIK
2021-06-03 07:26:24 <ikke> I saw them in my local output dir
2021-06-03 07:29:14 <DylanVanAssche> ikke: Well, It builds locally fine as well here (a couple of days before). I have not really an idea why it cannot find on the builders to be honest
2021-06-03 07:30:36 <ikke> The files need to be generated, which for some reason did not happen on ppc64le
2021-06-03 07:31:05 <ikke> Or at least, it appears like that 
2021-06-03 07:33:12 <ikke> https://gitlab.com/mobian1/devices/eg25-manager/-/tree/master/src/libgdbofono
2021-06-03 07:34:43 <ikke> It uses gdbus_codegen 
2021-06-03 07:40:58 <DylanVanAssche> ikke: Ah, well I'm more familiar with the ModemManager side instead of oFono, I didn't know that :P
2021-06-03 07:40:58 <DylanVanAssche> This package is mostly useful for the PinePhone  with an Quectel EG25-G modem. We can disable building on ppc64le then
2021-06-03 07:41:44 <ikke> Me neither, I just checked the meson.build, but I hardly know how it works 
2021-06-03 07:50:06 <ncopa> build-*-x86* should be back now
2021-06-03 07:51:37 <DylanVanAssche> ikke: Are there any other archs blocking because of the eg25-manager?
2021-06-03 07:51:56 <ikke> No, this is the only one 
2021-06-03 07:52:32 <DylanVanAssche> ikke: Let's skip it then 😛 I don't think we will ever have an ppc64le machine connected over GPIOs to an EG25-G Quectel modem :D
2021-06-03 08:10:43 <Newbyte[m]> Besides, has eg25-manager been tested anywhere but the PinePhone?
2021-06-03 08:26:58 <DylanVanAssche> Newbyte: Euhm not really 😛 
2021-06-03 08:45:11 <mps> huh, very interesting number of reverts in https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.12.9 related to @umn.edu
2021-06-03 08:45:42 <mps> a lot of commit msgs like this 'Upon review, this commit was found to be incorrect for the reasons ...'
2021-06-03 08:50:27 <sosodank> heh the minnesota commits, https://lwn.net/Articles/854064/
2021-06-03 08:51:48 <mps> fcolista: buon giorno :)
2021-06-03 08:52:24 <fcolista> ciao mps :)
2021-06-03 08:52:29 <mps> new acme.sh is released with bug fixes and removal of v1 protocol
2021-06-03 08:52:52 <mps> also url is changed and source url
2021-06-03 08:53:30 <mps> would you upgrade it to have it for 3.14, or if you don't have time I can later today
2021-06-03 08:55:45 <fcolista> When 3.14 will be released?
2021-06-03 08:56:15 <fcolista> I've several packages to upgrade, like libvirt 7.4.0
2021-06-03 08:56:53 <mps> only god^Wncopa knows
2021-06-03 08:57:13 <mps> but rc1 is planned this week
2021-06-03 08:57:55 <fcolista> so mx tomorrow?
2021-06-03 08:57:59 <fcolista> *max
2021-06-03 08:59:02 <mps> I presume ;)
2021-06-03 09:02:37 <ncopa> as soon ppc64le is done we'll do rc1
2021-06-03 09:02:56 <ncopa> i think we can still upgrade things like libvirt
2021-06-03 09:03:17 <ncopa> but we shouldnt upgrade building tools like gcc, binutils etc
2021-06-03 09:03:57 <mps> and alsa?
2021-06-03 09:04:10 <mps> just working on alsa-lib
2021-06-03 09:04:18 <ncopa> does it break abi?
2021-06-03 09:04:29 <ncopa> i think we can upgrade those
2021-06-03 09:04:40 <mps> looks like no, or I'm blind
2021-06-03 09:04:47 <ncopa> then push it
2021-06-03 09:05:02 <ncopa> will simplify long term maintenance
2021-06-03 09:05:05 <mps> I will first test it with some apps
2021-06-03 09:05:34 <ncopa> its great if you test it first, but i'd just push it and test it afterwards :)
2021-06-03 09:05:50 <mps> another pkg candidate for upgrade is mesa, but I don't have time for it
2021-06-03 09:06:25 <mps> kernel definitely should be upgraded
2021-06-03 09:06:51 <ncopa> what we should avoid push is things that is risky, with major changes, takes long time to compile, and require much resource to fix if it turrns out to be broken
2021-06-03 09:07:27 <ncopa> ok. I'll do the kernel. i checked earlier this morning but then it was 5.10.41
2021-06-03 09:15:11 <mps> also I did checked with morning coffee and it was previous, but when I looked for some rc changes I saw new stable series
2021-06-03 10:10:08 <maribu[m]> Regarding the issue with sway: The plt of udev_list_entry_get_next is already broken when main() of sway is entering. Is there any other explanation than breakage during dynamic linking?
2021-06-03 10:10:28 <maribu[m]> If so, I assume I should file an issue at musl, right?
2021-06-03 10:20:53 <ncopa> sounds good. they can probably help find the underlying issue
2021-06-03 10:21:40 <ncopa> sounds like something is not properly initialized
2021-06-03 10:49:17 <mps> oh no, again PATH_MAX on ppc64le problem
2021-06-03 10:49:40 <mps> 'rm -rf ppc64le'
2021-06-03 10:49:54 <mps> (and s390x as bonus)
2021-06-03 11:31:32 <mps> I need git experts help. I have one MR with two commits and I have to add patch to first commit. any hint how to do that
2021-06-03 11:32:37 <nero> check out first commit, --amend it, cherry-pick the second by hash
2021-06-03 11:34:34 <mps> git checkout hashid, add file, git add ., git commit --amend
2021-06-03 11:34:37 <mps> ?
2021-06-03 11:34:50 <nero> likely
2021-06-03 11:35:07 <nero> ah, "yes"
2021-06-03 11:35:08 <mps> git cherry-pick 'second commit hash'
2021-06-03 11:35:15 <nero> yes
2021-06-03 11:35:37 <mps> ok, will try, thanks
2021-06-03 11:35:52 <nero> im not sure whether you end up with a detached head, tell me if you do
2021-06-03 11:36:29 <mps> I feel like my head is already 'detached' ;)
2021-06-03 11:46:58 <mps> nero: doesn't work, probably because I don't understand all this
2021-06-03 11:48:01 <nero> what "doesn't work"?
2021-06-03 11:50:01 <mps> when I added this and switched to branch from HEAD added changes are lost
2021-06-03 11:50:44 <nero> go to the branch, and do git reset 'hash of cherry-pick result'
2021-06-03 11:52:05 <nero> you might end up with the right files being committed, with the files being in the state before the patch
2021-06-03 11:52:50 <nero> eh, with the actual files on the disk in the state before the patch
2021-06-03 11:53:10 <nero> with git checkout you can dicard the state on disk and take whats the state in git
2021-06-03 11:53:26 <mps> nero: thanks again, but I finished it by 'my strange way'
2021-06-03 11:53:37 <nero> editing the ref with vi ?
2021-06-03 11:53:56 <mps> no
2021-06-03 11:53:56 <nero> im curious whats your 'strange way' is
2021-06-03 11:53:58 <ikke> interactive rebase is easier 
2021-06-03 11:54:14 <mps> hard to describe
2021-06-03 11:54:22 <nero> nvm
2021-06-03 11:54:33 <ikke> Even more so with commit --fixup
2021-06-03 11:54:47 <mps> when in HEAD I did 'git format-patch -1 --stdout > alsa-lib.patch'
2021-06-03 11:55:21 <mps> git reset hard 'commitid when created alsa-1.2.5' branch
2021-06-03 11:55:47 <mps> git am alsa-lib.patch ; git am alsa-util.patch
2021-06-03 11:56:08 <nero> TIL --fixup
2021-06-03 11:56:35 <mps> I like simple tools, but git is overburdened one
2021-06-03 11:56:38 <mps> imo
2021-06-03 11:57:14 <mps> to work all this one must be expert in inner things in git
2021-06-03 11:58:23 <mps> oh no, ppc64le needs another PATH_MAX patch
2021-06-03 11:58:46 <nero> im "expert" enough so i get some specific kind of support tickets instantly assigned to me...
2021-06-03 11:58:51 <nero> (at work)
2021-06-03 12:00:02 <mps> I'm using git from 2008-06-01 (first commit in one my private repo) but I still use only basic things
2021-06-03 12:00:35 <mps> probably I started earlier than this date but forgot
2021-06-03 12:03:02 <mps> I see tools obsession as bad idea, except if one making money by 'selling tools'
2021-06-03 12:08:09 <ikke> I want to know the tools I use so that I can use them effectively 
2021-06-03 12:09:36 <mps> ikke: you read Miyamoto Musashi 'Five rings' (gorin no shyo)?
2021-06-03 12:09:42 <ikke> No 
2021-06-03 12:10:16 <mps> He explained about tools, 400 years ago
2021-06-03 12:12:15 <mps> to be effective tools should be simple
2021-06-03 12:12:54 <mps> his 'tools' where two sabre
2021-06-03 12:13:19 <mps> sabres*
2021-06-03 12:13:28 <ikke> Then we should throw out all computer equipment 
2021-06-03 12:13:43 <mps> good idea :)
2021-06-03 12:29:02 <markand> in 17 years of Linux use I've been distro-hopping every 6 months. now that I'm contributing to Alpine I can't tell enough how do I love what we're doing
2021-06-03 12:29:47 <mps> macos is next :)
2021-06-03 12:30:09 <markand> I own a macbook 
2021-06-03 12:30:36 <markand> but coding on it (even though Xcode is great) development is still at it's best on Linux
2021-06-03 12:30:49 <valerius> Alpine is the best distro I've used in years
2021-06-03 12:31:08 <valerius> feels like the good days of FreeBSD
2021-06-03 12:31:21 <markand> and macOS's WM is total insanity
2021-06-03 12:31:32 <markand> most stupid window manager I've ever seen 
2021-06-03 12:31:46 <petrj> reminds me of the book "JavaScript - the good parts" :)
2021-06-03 12:31:48 <Misthios> still better than gnome in my book
2021-06-03 12:32:19 <markand> (not even mentioning how much macOS is bloat, fresh bootup already consume 2GB of RAM with more than 1500 threads running)
2021-06-03 12:32:58 <mps> I'm using linux from 1993-94 and nothing else
2021-06-03 12:33:25 <mps> distros were slackware, debian and now alpine
2021-06-03 12:34:03 <valerius> that was also my progression through distros basically, but throw gentoo in there for me
2021-06-03 12:34:04 <petrj> i'm using Alpine with DWM on physical laptop.. i managed to adjust my expectations and am happy (as most spyware, google DRM etc. are unaware of musl for now..)
2021-06-03 12:34:25 <petrj> once this gets more commercialized, i'll find a new home -.-
2021-06-03 12:41:41 <mps> valerius: eh, I forgot mention build and fix openwrt for years. and openwrt was where I 'meet' musl
2021-06-03 12:43:57 <valerius> for me it was a combination of Debian's packaging being shoddy for a 6 month period and wanting to test my projects on musl
2021-06-03 12:45:12 <markand> I've personally tried my own distro based on musl too but using a pure complete LLVM toolchain (not even binutils or libstdc++) but it was a PITA because too many developers tend to think linux == glibc/gcc 
2021-06-03 12:45:37 <markand> and eventually gave up and started using Alpine instead (I still would love to see a LLVM Linux distro again though)
2021-06-03 12:45:50 <valerius> this distro may become that over time...
2021-06-03 12:50:12 <maribu[m]> @markand: 1500 threads running, without any program launched by the user? Actually, I'm impressed. I think if I would try to intentionally bloat a system, I would be years of hard work to reach that number :-D
2021-06-03 12:50:28 <markand> ;P
2021-06-03 12:51:17 <markand> the only thing macOS did right is the ecosystem and toolkit. so it's coherent, just look at audio mess on Linux, it will never be a good MAO station
2021-06-03 12:51:47 <valerius> the audio mess is gone when you have hardware mixing and do not install pulse or similar rubbish
2021-06-03 12:55:18 <mps> yes, I never had big problems with audio on linux except when pulse appeared on debian
2021-06-03 13:02:42 <Misthios> only struggle i have is firefox mic without pipewire/pulse
2021-06-03 13:04:25 <petrj> markand: interesting, I think some of the llvm/clang patches in alpine can be upstreamed, as other musl-based distros are also just repeating it. fedora style 'upstream everything' philosophy comes handy in such cases :) 
2021-06-03 13:04:56 <markand> sure, but some projects aren't cooperative 
2021-06-03 13:05:09 <markand> for example Linux managed to be GCC dependant for a loooong time
2021-06-03 13:05:16 <markand> as well for elfutils
2021-06-03 13:10:00 <maribu[m]> Note that Linux is a special case, as some hardware interactions can only be done in assembly. LLVM didn't support inline assembly in a reasonable way years ago, which made it technically impossible to use for any kernel. For embedded development (which also requires good inline asm support for similar stuff, such as context switches) LLVM is pretty usable for some time. And with many Linux kernel developers having expressed a high level
2021-06-03 13:10:01 <maribu[m]> of interest in using the LLVM tools, I expect that being able to use LLVM for Linux without any patches / headaches is only a matter of time now.
2021-06-03 13:12:51 <mps> I prefer gcc and batteries over clang/llvm
2021-06-03 13:15:31 <Hello71> maribu[m]: what? clang (not llvm) has supported GCC-style inline assembly for at least a decade: https://web.archive.org/web/20110624022446/http://clang.llvm.org/compatibility.html
2021-06-03 13:15:35 <petrj> same. today i cross compiled kernel for aarch64 using aports gcc cross compiler on alpine, it just worked (with one liner patch (commented out `YYLTYPE yylloc;` in dtc-lexer.l). besides since llvm's libc initiative, and too much big corp backing, i am not too eager to use it (unless i have to; like supporting freebsd binaries..)
2021-06-03 13:15:46 <Hello71> it only didn't support asm goto
2021-06-03 13:20:31 <markand> clang is less bloat than gcc (it really is) and is by itself already a cross-compiler which makes it a very good development tool
2021-06-03 13:20:44 <markand> I just love that I'm able to build for our ARM boards by just using clang -target options
2021-06-03 13:20:49 <Cogitri> And it has actually usable error messages and amazing tooling
2021-06-03 13:21:06 <markand> + apk --root options and I get a proper set of libraries in a couple of minutes 
2021-06-03 13:21:32 <markand> total awesomesauce
2021-06-03 13:26:36 <ncopa> at some point i wanted to use clang/llvm as default system compiler for alpine
2021-06-03 13:27:32 <markand> honestly this is possible, but with libc++/libc++abi/compiler-rt/lld it's PITA at the moment
2021-06-03 13:27:47 <markand> mandriva uses clang but still links to libstdc++ AFAIK
2021-06-03 13:27:54 <ncopa> I also think llvm generates inferior code, at least on some architectures
2021-06-03 13:28:18 <ncopa> so the benefit/cost equation has prevented me to do anything about it
2021-06-03 13:29:46 <petrj> https://github.com/llvm/llvm-project/tree/main/libc seeing (google contributed) llvm-libc in the forefront of their repo (and where they are heading with it), it doesn't inspire the confidence in true FOSS spirit unfortunately. i used to be a huge fan of llvm, but lately things are politically looking questionable. i.e. imo
2021-06-03 13:30:27 <Hello71> depends how you define "bloat", but it does take much longer to build than gcc
2021-06-03 13:30:44 <Hello71> whether this is made up for by having to recompile it less frequently depends on your use case
2021-06-03 13:31:38 <markand> it takes longer because it's in C++
2021-06-03 13:33:19 <Cogitri> I don't think we'd gain that much from switching to CLang right now, the main thing it has going for it is the great dev experience
2021-06-03 13:33:29 <Cogitri> Well, great for C(++) at least :)
2021-06-03 13:33:36 <Hello71> gcc is also compiled with c++ compiler since, uh... many years ago
2021-06-03 13:33:57 <Hello71> in fact gcc 11 requires c++11 according to https://gcc.gnu.org/gcc-11/changes.html
2021-06-03 13:35:06 <Hello71> so i think gcc is now definitively written "in c++", at least as much as c++ usually is (i.e. picking and choosing parts in order to not be totally overwhelmed by complexity)
2021-06-03 13:35:54 <mps> Hello71: after 4.7 iirc
2021-06-03 13:36:26 <Hello71> https://gcc.gnu.org/gcc-4.8/changes.html: "GCC now uses C++ as its implementation language. This means that to build GCC from sources, you will need a C++ compiler that understands C++ 2003. For more details on the rationale and specific changes, please refer to the C++ conversion page."
2021-06-03 13:36:31 <mps> when I started to dislike gcc
2021-06-03 13:37:10 <Hello71> oddly https://gcc.gnu.org/gcc-11/changes.html says When building GCC itself, the host compiler must now support C++11, rather than C++98.
2021-06-03 13:37:18 <Hello71> so apparently at some point they went from 03 to 98
2021-06-03 13:40:00 <petrj> yup, https://github.com/gcc-mirror/gcc says, 14.9% C++ and 47.7% C
2021-06-03 13:45:01 <Hello71> i mean that doesn't really mean anything
2021-06-03 13:45:23 <Hello71> the language detection is sometimes totally wrong
2021-06-03 13:45:59 <petrj> yea just a ballpark in numerical terms
2021-06-03 13:58:37 <markand> 
ACTION proposes to uses tcc as compiler

2021-06-03 13:58:40 <markand> no I'm kidding
2021-06-03 13:59:29 <petrj> i learned programming in borland c++ so tcc is a step up really :) 
2021-06-03 14:31:59 <clandmeter> do we allow spaces in shell shebang? 
2021-06-03 14:33:00 <Hello71> what does "we" mean here
2021-06-03 14:33:30 <clandmeter> interesting
2021-06-03 14:33:42 <clandmeter> on x86_64 brotli builds
2021-06-03 14:34:21 <clandmeter> on riscv64 it fails with: bootstrap: applet not found
2021-06-03 14:37:06 <clandmeter> shebang is:  # !/bin/sh
2021-06-03 14:37:22 <clandmeter> this is arch depended?
2021-06-03 14:39:39 <Hello71> huh, til we have build-edge-riscv64. and also build-riscv64-edge?
2021-06-03 14:40:29 <Hello71> i suspect that issue is unrelated to space
2021-06-03 14:40:53 <clandmeter> i bet you not
2021-06-03 14:41:12 <clandmeter> simple test case shows the diff
2021-06-03 14:41:32 <clandmeter> yes i named the test builder wrongly first time. :)
2021-06-03 14:41:54 <clandmeter> it runs in qemu-user
2021-06-03 14:43:03 <clandmeter> Ariadne: have you seen something similar?
2021-06-03 14:43:11 <Hello71> ah, could be qemu related
2021-06-03 14:43:43 <clandmeter> ah
2021-06-03 14:43:49 <clandmeter> that could be
2021-06-03 14:44:01 <clandmeter> the space messes with qemu user
2021-06-03 14:44:12 <clandmeter> hmm
2021-06-03 14:58:07 <nmeum> probably qemu user related, yeah
2021-06-03 14:58:59 <nmeum> is there any script/documentation on setting up abuild for rv64 with qemu-user?
2021-06-03 14:59:10 <clandmeter> so the proper fix is just remove the space?
2021-06-03 14:59:14 <nmeum> wanted to investigate some riscv test failures
2021-06-03 14:59:31 <clandmeter> nmeum: i have disabled tests for now
2021-06-03 14:59:48 <nmeum> not of brotli, just in general ;)
2021-06-03 14:59:58 <clandmeter> i mean all tests
2021-06-03 15:00:03 <clandmeter> for riscv
2021-06-03 15:00:10 <nmeum> haha :D
2021-06-03 15:00:30 <clandmeter> that and golang was an issue
2021-06-03 15:00:39 <clandmeter> but that seems to be mostly solved in qemu6
2021-06-03 15:01:16 <nmeum> regarding that shebang issue: the proper way to fix this would probably be  figuring out if it is indeed qemu-user related and if so finding out why the qemu behaviour differs and potentially reporting this as bug to the qemu folks I guess?
2021-06-03 15:01:46 <clandmeter> im asking in #qemu 
2021-06-03 15:01:48 <nmeum> clandmeter: how did you setup the riscv qemu-user build setup?
2021-06-03 15:02:35 <clandmeter> currently it runs in docker
2021-06-03 15:03:04 <nmeum> ah, so just docker-abuild then?
2021-06-03 15:03:11 <clandmeter> no 
2021-06-03 15:03:33 <clandmeter> aports-build in docker
2021-06-03 15:03:55 <clandmeter> but i think you also run it in lxc, should not matter which tech you use.
2021-06-03 15:04:06 <nmeum> yeah
2021-06-03 15:04:23 <clandmeter> just enable binfmt
2021-06-03 15:04:46 <clandmeter> you can do that from docker, some script or from qemu-openrc
2021-06-03 15:05:13 <clandmeter> bootstrapping was already done by others like ddevault and roman
2021-06-03 15:05:54 <clandmeter> im just checking if its actually sane to do it in qemu user.
2021-06-03 15:06:09 <Hello71> i think it could depend on your binfmt_misc options
2021-06-03 15:06:16 <Hello71> P O something
2021-06-03 15:08:23 <clandmeter> flags: OCF
2021-06-03 15:08:48 <mps> not sure but from reading around I have some doubts to build riscV with qemu
2021-06-03 15:09:11 <mps> maybe if the target is qemu
2021-06-03 15:10:17 <mps> <rant on> I have impression that riscV will become bigger jungle than arm is </rant off>
2021-06-03 15:11:53 <nmeum> presently the problem is just that there isn't any hardware suitable as a build server
2021-06-03 15:12:57 <nmeum> and I think improving abuild qemu-user integration would also be benifical to other arches, e.g. if someone runs into a test failure on an obscure architecture like ppc64le and would like to debug it further without having access to this architecture
2021-06-03 15:14:49 <clandmeter> rootbld with qemu user would be nice, and should not be too difficult to add.
2021-06-03 15:15:16 <clandmeter> maybe kaarle has some free time :)
2021-06-03 15:15:30 <clandmeter> kunkku i mean :)
2021-06-03 15:15:41 <nmeum> that should indeed be rather straightforward
2021-06-03 15:15:58 <nmeum> how is debian building their RV64 repo though? are they also using qemu?
2021-06-03 15:17:43 <clandmeter> mine has build over 10K pkgs already 
2021-06-03 15:18:29 <clandmeter> i think this shebang is the first obvious issue i bumped into (except the tests/golang troubles)
2021-06-03 15:18:55 <clandmeter> nmeum: https://dev.alpinelinux.org/~clandmeter/packages/riscv64/edge/
2021-06-03 15:19:10 <nmeum> sweet
2021-06-03 15:20:08 <clandmeter> there is also an issue on gitlab
2021-06-03 15:20:39 <clandmeter> https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10722
2021-06-03 15:42:21 <nmeum> > Linux francium 5.10.42-0-lts #1-Alpine SMP Thu, 03 Jun 2021 11:48:39 +0000 riscv64 Linux
2021-06-03 15:42:22 <nmeum> neat, thanks
2021-06-03 15:46:50 <ncopa> im working on e25-manager. its a dependency problem in meson.build
2021-06-03 15:47:02 <ncopa> s/e25/eg25/
2021-06-03 15:47:02 <alpine-meetbot> ncopa meant to say: im working on eg25-manager. its a dependency problem in meson.build
2021-06-03 15:47:11 <ikke> ncopa: aha, I had a suspicion, but I'm not too familiar with meson
2021-06-03 15:59:54 <ncopa> neither am i
2021-06-03 16:00:01 <ncopa> not much at least
2021-06-03 16:00:03 <ncopa> hum
2021-06-03 16:00:16 <ncopa> how can i install and use real ninja instead of samurai?
2021-06-03 16:00:22 <Thermi> ncopa, I might need to make a copy of the swig package, downgraded to version 3 for dependency reasons at build time of kopano-core. That worked fine. It took the binary I wanted. The only changes between the swig package I made (swig3) and the original one are, evidently, the name and two args to ./configure. Because it might be needed by other packages too, I'd like to commit it into main directly, instead of going via testing (doesn't 
2021-06-03 16:00:23 <Thermi> matter in the end though). Is that reasonable?
2021-06-03 16:00:24 <ncopa> i want to generate a graph
2021-06-03 16:00:42 <Thermi> Refering to https://gitlab.alpinelinux.org/alpine/aports/-/issues/12727 and https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8569
2021-06-03 16:00:46 <ncopa> https://graphviz.org/Gallery/directed/ninja.html
2021-06-03 16:00:51 <Thermi> kopano-core requires swig 3.x
2021-06-03 16:00:51 <ikke> ncopa: apparently we do not have it anymore?
2021-06-03 16:00:55 <Thermi> we already have swig 4.0
2021-06-03 16:00:58 <Thermi> err 4.x
2021-06-03 16:01:04 <Thermi> requires 3.x, we have 4.x
2021-06-03 16:01:13 <Thermi> 4.x is not backwards compatible
2021-06-03 16:01:32 <Thermi> Devs explicitely abort configureation if swig version != 3 is detected
2021-06-03 16:01:37 <Thermi> (for good reasons)
2021-06-03 16:01:55 <ncopa> ok, and i suppose its not trivial to fix those to use swig4?
2021-06-03 16:02:03 <Thermi> Nope, all upstream work.
2021-06-03 16:02:14 <ncopa> lets add swig3 then
2021-06-03 16:02:15 <Thermi> swig generates language bindings, so it's difficult already
2021-06-03 16:02:48 <Thermi> upstream kopano doesn't see a need to fix it themselves because the only explicitely supported platform that has swig 4 already is ubuntu 20.04
2021-06-03 16:03:03 <Thermi> and they evidently don't care to support it anymore or something. They just don't fix it.
2021-06-03 16:03:19 <Thermi> Prevent build with SWIG >= 4
2021-06-03 16:03:20 <Thermi> aborts accordingly.
2021-06-03 16:03:20 <Thermi> At time of writing the only supported platform with SWIG 4 is Ubuntu
2021-06-03 16:03:20 <Thermi> For now, SWIG 4 is not compatible, because of changed handling of tuple
2021-06-03 16:03:20 <Thermi> behavior which is currently required. This change detects SWIG >= 3 and
2021-06-03 16:03:21 <Thermi> 20.04, but SWIG 3 is also available.
2021-06-03 16:03:25 <Thermi> Sorry for wall of text.
2021-06-03 16:03:28 <ikke> is it trivial to have multiple swig versions side-by-side?"
2021-06-03 16:03:37 <Thermi> Yes
2021-06-03 16:04:04 <Thermi> add configure arg to add suffix to binary name. All other files go in versioned directories, I checked. :)
2021-06-03 16:04:09 <Thermi> e.g. /usr/share/swig-$version/
2021-06-03 16:04:29 <Thermi> wig3-3.0.12-r1 contains:
2021-06-03 16:04:29 <Thermi> usr/bin/ccache-swig3.0
2021-06-03 16:04:29 <Thermi> usr/bin/swig3.0
2021-06-03 16:04:29 <Thermi> usr/share/swig/3.0.12/allkw.swg
2021-06-03 16:05:00 <Thermi> 3.0 suffix is required for upstream kopano-core autoconf configure macros to detect and use swig3.0 first, instead of potentially parallel installed swig/swig4.0
2021-06-03 16:05:11 <Thermi> autoconf has this:         AC_PATH_PROGS([SWIG_EXEC],[swig2.0 swig3.0 swig4.0 swig])
2021-06-03 16:05:28 <Thermi> Works flawlessly
2021-06-03 16:05:41 <Thermi> like *chefkiss*
2021-06-03 16:06:16 <ikke> ok good, then lets do it, like ncopa sai
2021-06-03 16:06:17 <ikke> said
2021-06-03 16:06:46 <Thermi> Aye aye, will do a MR
2021-06-03 16:06:51 <Thermi> Ty for your time
2021-06-03 16:07:02 <Thermi> Errr
2021-06-03 16:07:36 <Thermi> maintainer is supposed to be me or because of near equivalence to existing swig package is it fine if it is you again, ncopa? )
2021-06-03 16:07:37 <Thermi> :)
2021-06-03 16:07:59 <ikke> preferably you :)
2021-06-03 16:08:08 <Thermi> Okay, I'll change it and make an MR
2021-06-03 16:08:08 <Thermi> Tyvm
2021-06-03 16:10:05 <ncopa> can samurai print a dependency graph?
2021-06-03 16:10:09 <Thermi> Errr
2021-06-03 16:10:21 <Thermi> commit message is still supposed to be of the normal new aport format?
2021-06-03 16:10:37 <Thermi> Because it'd be the same as the existing swig package without giving the reason for inclusion
2021-06-03 16:10:45 <ikke> Thermi: yes, but you can give context in the body
2021-06-03 16:10:50 <Thermi> Ty
2021-06-03 16:10:54 <Thermi> So reasonable :)
2021-06-03 16:11:29 <Thermi> I'll add it to the MR for the kopano stuff, because up to now, it's the only thing requiring it
2021-06-03 16:11:33 <Thermi> Is that fine?
2021-06-03 16:11:42 <ikke> yes, that should be fine
2021-06-03 16:11:58 <ikke> It's even preferred :)
2021-06-03 16:16:16 <Thermi> Done.
2021-06-03 17:00:22 <Ariadne> clandmeter: can't say i have, but i am not surprised :)
2021-06-03 17:01:08 <Ariadne> ncopa: thanks for fixing eg25-manager
2021-06-03 17:01:22 <Ariadne> ncopa: i was getting pretty sleepy, so i didn't know what the answer was :D
2021-06-03 18:12:49 <clandmeter> Ariadne: https://github.com/torvalds/linux/blob/master/fs/binfmt_script.c#L34
2021-06-03 18:13:26 <clandmeter> but its the arg handeling thats broken i think
2021-06-03 18:13:46 <clandmeter> when there is a space it says, applet not found (as in busybox applet)
2021-06-03 18:13:58 <Ariadne> i think busybox is trying to interpret the shebang itself
2021-06-03 18:14:34 <Ariadne> i think the script itself is wrong
2021-06-03 18:15:30 <clandmeter> as in the space is in the wrong place?
2021-06-03 18:15:37 <Ariadne> yes
2021-06-03 18:15:54 <clandmeter> yeah, thats what i also think
2021-06-03 18:15:55 <Ariadne> # !/bin/sh -e
2021-06-03 18:15:57 <Ariadne> this is nonsense
2021-06-03 18:16:17 <clandmeter> but it seems to work without qemu :)
2021-06-03 18:16:58 <Ariadne> i don't think it is supposed to
2021-06-03 18:16:59 <Hello71> have you tried adding P flag
2021-06-03 18:17:21 <Hello71> or does it not work with qemu
2021-06-03 18:17:27 <Ariadne> # !/bin/sh
2021-06-03 18:17:30 <Ariadne> is just nonsense
2021-06-03 18:18:28 <clandmeter> blame google
2021-06-03 18:19:28 <clandmeter> heh https://github.com/google/brotli/issues/833
2021-06-03 18:20:56 <Ariadne> :D
2021-06-03 19:07:08 <nmeum> though they should have fixed the mkdir issue by using mkdir -p instead of checking if the file exists explicitly!
2021-06-03 19:29:44 <ikke> race condition in nss on 3-13-s390x
2021-06-03 19:29:52 <ikke> symlink creation race: /home/buildozer/aports/community/nss/src/nss-3.66/dist/public/nss/nssckfwc.h
2021-06-03 19:38:57 <Cogitri> Yuck
2021-06-03 22:37:00 <ericonr> why does alpine use a custom ldd script instead of just symlinking it? https://git.alpinelinux.org/aports/tree/main/musl/APKBUILD#n105
2021-06-03 22:37:08 <ericonr> it seems to produce the exact same output
2021-06-03 22:49:01 <[[sroracle]]> https://git.alpinelinux.org/aports/commit/main/musl/APKBUILD?id=d4a7955cc72b9395779c20755df88f983763c43b
2021-06-03 22:51:28 <ericonr> was this discussed with musl upstream?
2021-06-03 22:51:36 <ericonr> [[sroracle]]: thanks for the commit link
2021-06-03 23:20:08 <ngortheone> Guys, according to Drew https://drewdevault.com/2021/05/14/Pinebook-Pro-review.html alpine aarch64 builds do not work on pinebook pro. I hoped maybe someone can give a bit more details about this. (why? what is missing? how can we help? etc.)
2021-06-03 23:26:32 <afontain[m]> I'd assume the kernel part is missing
2021-06-03 23:33:17 <craftyguy> you can run alpine on a pbp by way of postmarketOS, but ya I think the main delta is the kernel..
2021-06-03 23:33:25 <craftyguy> and maybe the u-boot too (or, both)
2021-06-03 23:36:39 <sam_> ddevault may be able to help explain :p
2021-06-03 23:41:51 <Ariadne> it is possible to run stock alpine on pbp with a custom kernel
2021-06-03 23:45:21 <ngortheone> I got mine PBP the other day and I want to run Alpine :) What do you suggest me to try as the first step?
2021-06-03 23:46:12 <Ariadne> ngortheone: bake image with the PBP stock kernel that comes with the ubuntu or whatever they include
2021-06-03 23:48:20 <ngortheone> mine came with manjaro kde. I can take /proc/config.gz from it. How do I "bake" the image?
2021-06-03 23:56:38 <Hello71> 23:41 <Ariadne> it is possible to run stock alpine on pbp with a custom kernel
2021-06-03 23:56:40 <Hello71> is it still stock
2021-06-03 23:56:57 <Ariadne> well moreso than pmos
2021-06-03 23:58:22 <petrj> lol :P
2021-06-04 00:06:04 <afontain[m]> you can also take just the kernel package and maybe also the uboot package from the pmOS repos
2021-06-04 00:13:50 <craftyguy> that's basically what I did playing around with the pine64 a64-lts thing. i wanted to run stock alpine, and the mainline kernel is still a mess for that device apparently. so I just installed the pmos kernel
2021-06-04 01:25:34 <Hello71> i have investigated what -Wl,-O does. i believe the only thing it does is "optimize" the elf hash table(s?)
2021-06-04 01:27:00 <Hello71> interestingly, there is a compile time variant to optimize for smaller tables: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elflink.c;hb=HEAD#l6274
2021-06-04 01:28:00 <Hello71> i wonder what the man page means by "should only be enabled for the final binary" then
2021-06-04 01:28:56 <[[sroracle]]> aren't you the one who suggested it in the first place?
2021-06-04 01:29:04 <Hello71> yes but i didn't check exactly what it does
2021-06-04 01:29:05 <[[sroracle]]> why are you just discovering what it does now?
2021-06-04 01:29:15 <Hello71> i read the manual and checked what other distros do
2021-06-04 01:29:15 <[[sroracle]]> that's embarrassing
2021-06-04 01:29:55 <Hello71> plonk incoming
2021-06-04 01:34:10 <Hello71> do you know what every single version bump does?
2021-06-04 01:34:10 <Hello71> in detail?
2021-06-04 01:35:16 <Hello71> what i do is check the release notes to see if there's anything important
2021-06-04 01:36:02 <[[sroracle]]> sorry but i think "changing the default linker flags for the entire distro" might require slightly more scrutiny than "bumping a package". i don't see why such a comparison is even relevant here, or maybe *i'm* missing something
2021-06-04 01:36:38 <Hello71> otherwise i assume hopefully the software writers have hopefully done something reasonable and deal with issues as they arise
2021-06-04 01:37:11 <Hello71> so you carefully investigate every gcc commit?
2021-06-04 01:37:32 <[[sroracle]]> why would i? i'm not responsible for the toolchain...
2021-06-04 01:38:15 <[[sroracle]]> i still fail to see how this is relevant
2021-06-04 01:52:44 <ericonr> Hello71: there can be other things we are missing, void uses different kernels and different intermediate dependencies that might affect things (like how our webkit2gtk is still weird for video)
2021-06-04 01:53:09 <ericonr> still, given that the issue touched on plt, I figured the linker should be investigated
2021-06-04 01:53:16 <Hello71> yes, i agree it is worth looking at
2021-06-04 01:53:33 <Hello71> but not in a "hurr durr ur a dumbass" way
2021-06-04 01:55:27 <Hello71> which is what [[sroracle]] seems to be pulling
2021-06-04 01:56:49 <[[sroracle]]> well i never said anything of the sort. but ok
2021-06-04 01:57:15 <[[sroracle]]> i apologize if i came off as rude in any way
2021-06-04 02:01:26 <Hello71> i'm still offended, but accept your apology. my point, to be clear, is that if we do a deep dive into the source code for every change we make (even to a core component), we'll never get anything done. at some point "read the manual, check what other people are doing, and deal with issues as they arise" is the right move. in this case, i read the manual, checked what other
2021-06-04 02:01:27 <Hello71> distros do, and based on that, recommended the change. as shown, i am willing to own and help diagnose any issues that come up that may be related
2021-06-04 02:01:45 <Hello71> honest question: if you were maintaining gcc, would you go through every commit for every release?
2021-06-04 02:02:15 <Ariadne> Hello71: i do glance over the changes when i rebase our branch of gcc
2021-06-04 02:02:27 <[[sroracle]]> i have done some work to backport gccgo to past branches, so i actually have some familiarity with reading every gcc commit. it's not something i'd wish on my worst enemy though
2021-06-04 02:02:47 <Hello71> sure, maybe you skim the commit messages. it would take a whole team to review every single change in detail though
2021-06-04 02:03:09 <Ariadne> Hello71: yes, which is why i am fairly conservative in how we track gcc
2021-06-04 02:03:30 <[[sroracle]]> i did some heuristics to narrow the changes to specific trees, but i did have to review every single change...
2021-06-04 02:03:38 <Hello71> yes, we don't upgrade immediately, and we give some time to test it before doing a new release
2021-06-04 02:03:39 <ericonr> anyway, rebuilding the package locally without the linker flag should be easy to test, right?
2021-06-04 02:03:58 <Hello71> which is why i didn't suggest adding it two weeks ago (and if i did, i would have said "let's wait for 3.15")
2021-06-04 02:04:31 <Ariadne> still, i was less than impressed with your argument for changing the linker flags
2021-06-04 02:05:02 <Ariadne> it basically came down to "$otherdistro is doing it" and you didn't have a technical answer for what the flags actually changed
2021-06-04 02:05:09 <Ariadne> i think that system changes should be thoughtfully considered
2021-06-04 02:05:33 <Ariadne> and, i felt that in this case, there was not much actual meat to the proposal
2021-06-04 02:05:41 <Ariadne> although ncopa did it anyway :)
2021-06-04 02:06:21 <Ariadne> i would like to see more detail in future toolchain-intersecting proposals in the future, and i hope you agree that this is a fair request
2021-06-04 02:06:55 <Hello71> wrt --sort-common i don't see how this could realistically break anything, object file ordering is almost always indeterminate anyways
2021-06-04 02:07:42 <Hello71> which doesn't necessarily definitely mean something isn't relying on it, but i think it's close enough to certain, assuming that it works as advertised
2021-06-04 02:07:49 <Ariadne> sure, but when you propose changing behavior of the toolchain, it is good to actually discuss what the change actually *is*
2021-06-04 02:09:12 <Ariadne> because when it comes to the toolchain, if your changes break the build, it isn't going to be you fixing it, but me or somebody else who actually maintains the toolchain
2021-06-04 02:11:37 <Ariadne> you have a tendency to propose doing Weird Stuff with the toolchain
2021-06-04 02:11:46 <Ariadne> which, fine, i'm not against doing weird stuff, if the data supports it and the risk-reward balance plays out the right way
2021-06-04 02:13:08 <Ariadne> but at the same time, alpine is not some performance-at-all-costs distro
2021-06-04 02:13:15 <Ariadne> performance is good, if we can get it with low risk
2021-06-04 02:21:50 <Hello71> i have a number of responses to that, but perhaps first, how do you suggest publicizing such things? that MR sat for about three months with no requests for changes before being merged. second, where are we drawing the line? for example, i think we have historically had relatively little discussion on kernel config changes. do we need to start a mailing list thread for each one
2021-06-04 02:21:51 <Hello71> now? i agree mps opinions are "extremist" in various ways, but i also agree with mps that we should try not to turn into debian or gentoo. not that mps is the only one holding these views, but he may be our most vocal "champion" of minimalism. did we have discussion on --as-needed? or -z now? or are those "grandfathered" in, and we are now starting to ossify? that doesn't sound
2021-06-04 02:21:53 <Hello71> good either
2021-06-04 02:39:31 <Ariadne> Hello71: in general, i think it is nice to start threads on the ML about major changes (like toolchain behaviour changes)
2021-06-04 02:39:53 <Ariadne> Hello71: creating a more rigid policy is something i look forward to the TSC doing once it is fully up and running :)
2021-06-04 02:49:04 <Sheila> Hello71: imo if there are compelling reasons to alter the toolchain it's okay to draw attention to the MR or whatever so it's *not* sitting around for 3mo. "$otherdistro does it", e.g., isn't very, even if --sort-common sounds like a reasonable flag to add.
2021-06-04 02:49:07 <Ariadne> (also we did have discussion on --as-needed and -z now)
2021-06-04 03:10:48 <Hello71> Sheila: my point there was "it was around for 3 months so you can't really complain it was rushed in"
2021-06-04 03:13:19 <Sheila> no, I think the way in which it was ultimately handled was rushed, whether it sat around for 3mo before it was brought up or not.
2021-06-04 04:25:35 <ikke> build-3-14-ppc64le
2021-06-04 04:25:37 <ikke> idle
2021-06-04 06:01:46 <mps> !21998 and !21999 have upstream tarballs strangely made, when unpacked they have short 'hash' in dir name
2021-06-04 06:03:24 <mps> Hello71: those who calls me extremist should come in front of me in real world and say that :)
2021-06-04 06:05:29 <mps> re: pinebookpro kernel, no one told what is needed to be enabled in kernel (drivers/options) for mainline to work on PBP, and we don't own PBP nor PBP crystal ball
2021-06-04 06:45:10 <mps> anyone noticed this on builders or CIs 'Expat.c: loadable library and perl binaries are mismatched (got handshake key 0xed00080, needed 0xeb00080)'
2021-06-04 06:47:31 <Cogitri> Sounds as if something needs to be rebuilt against a new version of a library
2021-06-04 06:48:19 <mps> Cogitri: yes, expat
2021-06-04 06:48:33 <mps> https://sourceforge.net/projects/expat/files/expat/2.3.0/expat-2.3.0-RENAMED-VULNERABLE-PLEASE-USE-2.4.1-INSTEAD.tar.lz/download
2021-06-04 06:48:53 <maribu[m]> regarding the segfault with sway: I'm going to vacation now, so I cannot debug any further. It seems that the issue is that two different implementations of libudev get linked in. The eudev-libs version is called for udev_monitor_update (or similar), which calls into udev_list_entry_get_next of the  non-eudev implementation that shouldn't be linked in
2021-06-04 06:49:09 <mps> but upgrading now and get fired by BDFL
2021-06-04 06:49:22 <mps> ncopa: ^
2021-06-04 06:52:46 <maribu[m]> I think I checked yesterday and sway contains no symbols for udev, wlroots only references to symbols it needs to link to. So next up on the list is libinput
2021-06-04 06:54:57 <maribu[m]> Would be nice of someome could take over
2021-06-04 06:55:11 <mps> afaik libinput don't need udev
2021-06-04 06:55:49 <mps> oh no, it is linked to libudev
2021-06-04 08:07:56 <ncopa> good morning
2021-06-04 08:10:10 <ikke> good morning 
2021-06-04 08:10:22 <ikke> ppc64le is ready 
2021-06-04 08:10:27 <ncopa> wow
2021-06-04 08:10:55 <ncopa> also build-edge-riscv64 is done with main and community
2021-06-04 08:11:04 <ncopa> we could sneak in riscv64 support
2021-06-04 08:11:30 <ncopa> if we did minirootfs release media only
2021-06-04 08:11:49 <ncopa> i'd need a riscv64 dev env though
2021-06-04 08:15:24 <donoban> hello
2021-06-04 08:17:18 <donoban> I was trying to improve a little the qemu-openrc scripts and I wonder if there are some reasons for use virtio-scsi instead virtio-blk (apart from number of devices)
2021-06-04 08:20:02 <ncopa> i think you'd need to ask @jirutka on github
2021-06-04 08:21:02 <mps> 
ACTION wants to see jirutka here again

2021-06-04 08:21:08 <ncopa> git blame says it was introduced in the first version, 5 years ago https://github.com/jirutka/qemu-openrc/blame/master/qemu.initd
2021-06-04 08:26:00 <donoban> ok
2021-06-04 08:26:19 <mps> to repeat, what to do with expat problem
2021-06-04 08:26:48 <mps> if we upgrade it some pkgs must be also rebuilt
2021-06-04 08:27:35 <mps> 'ap revdep expat-dev | tpaste' => https://tpaste.us/vZPo
2021-06-04 08:27:37 <ikke> Is there a reason to upgrade expat? 
2021-06-04 08:27:45 <mps> main only
2021-06-04 08:28:08 <mps> https://sourceforge.net/projects/expat/files/expat/2.3.0/expat-2.3.0-RENAMED-VULNERABLE-PLEASE-USE-2.4.1-INSTEAD.tar.lz/download
2021-06-04 08:28:18 <mps> ikke: ^
2021-06-04 08:28:57 <ikke> OK, so a security issue 
2021-06-04 08:29:59 <mps> 'ap revdep expat-dev | tpaste' => https://tpaste.us/QWV0
2021-06-04 08:30:11 <mps> community ^
2021-06-04 08:57:29 <donoban> uhM, until 2019 virtio-blk didn't support BLKDISCARD so virtio-scsi was a clear winner for ssd's,lvm and similar..., probably it stills slightly better altought it has some overhead
2021-06-04 08:58:58 <mps> imo, -blk is better now
2021-06-04 08:59:22 <mps> except if someone need 'full scsi emulation'
2021-06-04 08:59:46 <donoban> well I will try to add configuration options for both
2021-06-04 09:54:54 <ncopa> donoban: sounds like the best way to go
2021-06-04 09:55:20 <ncopa> mps: re expat, does expat upgrade break ABI?
2021-06-04 09:57:41 <ncopa> mps: the expat upgrade does not break ABI. i think we can just push it
2021-06-04 10:04:14 <mps> ncopa: I think so
2021-06-04 10:04:31 <mps> but test all this would take time for me
2021-06-04 10:05:01 <mps> but from reading superficially looks like it doesn't break ABI
2021-06-04 10:05:16 <ncopa> i did a check of a single package. looks good
2021-06-04 10:05:18 <ncopa> just push it
2021-06-04 10:06:08 <mps> ok, but first have to go for breakfast
2021-06-04 10:15:01 <clandmeter> its past 12
2021-06-04 10:26:22 <mps> yes, but I usually don't eat before 11
2021-06-04 10:26:54 <mps> and not after 16
2021-06-04 10:29:48 <donoban> hehe, I thinking the same as clandmeter but five minutes later I was hungry :D
2021-06-04 10:30:08 <mps> I'll risk and merge new expat
2021-06-04 10:30:23 <donoban> I thank*
2021-06-04 10:39:47 <donoban> lol, thunk*
2021-06-04 10:39:51 <donoban> :|
2021-06-04 10:41:12 <donoban> 
ACTION is sent to #alpine-es

2021-06-04 11:51:44 <Hello71> donoban: I think some older guests only support trim on scsi
2021-06-04 11:52:33 <Hello71> also scsi has passthrough but i don't think qemu-openrc supports that?
2021-06-04 11:56:53 <Hello71> about alsa, gentoo reported some issues and masked new version, so better hold for 3.15 imo
2021-06-04 11:58:01 <mps> Hello71: to late for alsa, already merged
2021-06-04 11:58:53 <Hello71> https://github.com/alsa-project/alsa-lib/issues/142, https://github.com/alsa-project/alsa-lib/issues/143
2021-06-04 12:01:59 <Hello71> many people report no sound, but seems like root cause was found, so probably fixes will be out in time for 3.14
2021-06-04 12:18:18 <mps> I tested on x86_64 and aarch64 and armv7 edge, all works
2021-06-04 12:40:49 <Hello71> i think it is related to what devices you have, and also what programs you are using (including pulse)
2021-06-04 12:41:14 <Hello71> i also had no problems, and i assume arch maintainer tested it and found no problems
2021-06-04 12:42:18 <Hello71> for example https://github.com/alsa-project/alsa-lib/issues/143 "this config file is included multiple times, so it's required to clean the updated tree to avoid merging of arrays" i guess it only breaks if you have multiple devices with same (alsa) driver
2021-06-04 12:57:15 <mps> yes, I read these and noticed that it happens on specific drivers and pulse. thanks for pointing to them
2021-06-04 13:10:09 <PureTryOut> ncopa: would you be fine with me taking over maintainership of community/qca? It's a KDE package and I'm already doing the rest of those anyway 🤗
2021-06-04 13:21:59 <donoban> Hello71: ok, the only problem is that the script could be simplified without virtio-scsi but better to have both available (and to keep virtio-scsi as default)
2021-06-04 13:28:26 <Hello71> sure
2021-06-04 13:32:49 <ncopa> PureTryOut: i'd be happy if you took over qca
2021-06-04 13:33:04 <PureTryOut> Great! Will do
2021-06-04 13:33:11 <ncopa> thank you!
2021-06-04 14:32:32 <ngortheone> guys, I'm sorry to repeat the question - please point me to the docs about how to "bake" images? I want to take kernel configuration from manjaro that came with my PBP and see if I can build alpine image that boots and runs on PBP
2021-06-04 14:34:20 <ncopa> ngortheone: i think this is the closes you come to any documentation: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/aports-build/aports-build#L58
2021-06-04 14:53:44 <Hello71> if you don't want run from ram then it should be pretty similar to other distros to make a sys install
2021-06-04 14:54:29 <Hello71> or actually you could also unpack the iso and replace the kernel (but if it needs modules you also need a new initramfs)
2021-06-04 14:56:36 <Hello71> mps: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12731
2021-06-04 14:58:59 <mps> Hello71: I'm watching https://www.alsa-project.org/files
2021-06-04 14:59:51 <mps> if they don't make new release in day or two I will pick patches and add to aports
2021-06-04 14:59:54 <Hello71> [[sroracle]]: since you are familiar with gccgo, do you know why it doesn't use cgo? i'm wondering because of https://gitlab.alpinelinux.org/alpine/aports/-/issues/12593, why doesn't gccgo use system headers to get definition of strerror
2021-06-04 15:01:19 <Hello71> fwiw https://github.com/archlinux/svntogit-packages/blob/packages/alsa-lib/trunk/PKGBUILD seems to have needed patches
2021-06-04 15:03:51 <mps> yes, they pull them from upstream git by htts url in 'source' field
2021-06-04 15:04:33 <mps> I prefer to download and have it locally in aports
2021-06-04 15:06:26 <mps> as I see 3.14 rc will wait for next week, so I feel we are not in hurry (or if someone *really* and ultimatively need them I or we can do that in short time)
2021-06-04 15:07:13 <mps> Hello71: your comment in issue report is quite good
2021-06-04 15:11:28 <ncopa> im building test releases as we speak, but its dog slow. dunno why
2021-06-04 15:37:19 <ncopa> >>> mkimage-x86: Creating alpine-virt-20210604-x86.iso
2021-06-04 15:37:20 <ncopa> Segmentation fault
2021-06-04 15:37:33 <ncopa> looks like the 3.14_rc1 won't happen today :-(
2021-06-04 15:37:38 <ikke> :(
2021-06-04 15:37:41 <ncopa> better do it monday morning
2021-06-04 15:37:56 <ikke> yeah, no need to rush it
2021-06-04 16:37:34 <Hello71> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12731 3.14.0 mistake? should it be 3.15?
2021-06-04 16:41:35 <mps> I don't think so. imo intention is to be fixed before 3.14.0 is released
2021-06-04 16:46:52 <Hello71> uh, right, for some reason i thought next release was 3.15 -.-
2021-06-04 16:52:32 <ikke> Anyone aware of any other major / breaking changes for 3.14? https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.14.0
2021-06-04 16:56:10 <mps> ikke: postfix config is somewhat changed
2021-06-04 16:56:21 <mps> main/haproxy: upgrade to 2.4.0
2021-06-04 16:56:45 <mps> some config options are changed
2021-06-04 16:57:20 <mps> usual qemu changes
2021-06-04 16:58:30 <Hello71> i think that by 3.14 release, the docker section will be inaccurate
2021-06-04 16:58:45 <Hello71> unfortunately i wrote it long enough ago that i'm not sure exactly which parts will be wrong
2021-06-04 17:00:02 <mps> noteworthy news, crystal lang 1.0.0 and zig 0.7
2021-06-04 17:00:30 <mps> simply point users to git log :)
2021-06-04 17:02:10 <mps> edk2 is broken
2021-06-04 17:20:23 <Hello71> mps: re https://gitlab.alpinelinux.org/alpine/aports/-/issues/12418#note_159380, does console=ttyS0 give you getty?
2021-06-04 17:24:18 <mercenary> no, that needs an inittab entry
2021-06-04 17:55:42 <Hello71> that's what i thought
2021-06-04 18:01:24 <Thermi> ncopa, there's some issue with samba smbd and btrfs since tuesday. A server at work shows this and fails to serve any files: btrfs_fget_compression: FS_IOC_GETFLAGS failed: Bad file descriptor, fd -1
2021-06-04 18:09:50 <mps> Hello71: I lost irc/net and reading your question about https://gitlab.alpinelinux.org/alpine/aports/-/issues/12418#note_159380
2021-06-04 18:10:41 <mps> yes, inittab must have entry, also
2021-06-04 18:11:16 <mps> though I think it could be added 'on-the-fly' by boot script
2021-06-04 18:20:18 <Cogitri> Thermi: Have you asked the samba people about that? I think they're a better resource for such specific problems
2021-06-04 18:21:47 <Thermi> Cogitri, Not yet, I am using git blame on samba sources right now, but there are no changes in between the two samba versions that relate to btrfs
2021-06-04 18:25:00 <mercenary> mps: please don't auto-add that sort of thing
2021-06-04 18:26:02 <mercenary> (example where I _don't_ want it: two machines with the consoles cross-over'ed, use screen on whichever on is working to debug the other one)
2021-06-04 18:32:03 <Hello71> mercenary: and you also set console=ttyS0 on both?
2021-06-04 18:32:23 <Hello71> i could swear there are some (non-systemd) distros that already do it. maybe openwrt?
2021-06-04 18:32:29 <Hello71> buildroot? can't remember
2021-06-04 18:35:37 <mercenary> Hello71: yeah. it has its disadvantages (both also have bios-redirect on, and if both power on at the same time, grub on A sees the bios output from B as a 'wait in menu key')
2021-06-04 18:36:14 <Hello71> this sounds like a bad idea
2021-06-04 18:36:15 <mercenary> But it beats walking 50m to go and hit sysrq
2021-06-04 18:36:35 <mercenary> It is. ENOTIME to turn a pi into a console server :/
2021-06-04 18:36:43 <Hello71> plus if you have a crazy setup you can just disable it
2021-06-04 18:39:04 <mercenary> True. Iff there is a knob for that.
2021-06-04 18:49:06 <skarnet> I feel like this is an opportunity to say that serial console (as in, giving a direct shell) is one of many warts with sysvinit-like inits, and modern inits (read: s6-linux-init) can just give you an early getty on whatever terminal you like, including serial, which can both help debug early setups *and* be secure by default since it's not a direct shell. :P
2021-06-04 18:50:01 <skarnet> (of course if your /etc/passwd is borked that won't help, but at this stage you'd be close to init=/bin/sh territory anyway.)
2021-06-04 19:12:01 <mps> ^ that is what I had in mind
2021-06-04 19:16:23 <mercenary> that can have interesting interactions with e.g. LDAP auth before the network is up (or in case the network doesn't come up at all for whatever reason)
2021-06-04 19:20:32 <Hello71> huh?
2021-06-04 19:23:55 <mercenary> sometimes direct shells on a trusted port can be useful to unfsck authentication issues. But as was mentioned, there is always init=/bin/sh
2021-06-04 20:22:05 <liske> serial console: it is already in the initramfs for a long time https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L109
2021-06-04 23:29:25 <Hello71> ah, i did remember it was automatic somewhere
2021-06-04 23:30:08 <Hello71> although i think it might be better to do the systemd way and just check /sys/class/tty/*/active directly?
2021-06-05 08:15:36 <skarnet> pro life tip: when you "think it might be better to do the systemd way", it's time to take a step back and wonder what you've been missing.
2021-06-05 08:20:37 <petrj> fish & chips?
2021-06-05 08:23:15 <skarnet> yes, for instance
2021-06-05 08:23:21 <mps> cat /proc/consoles
2021-06-05 16:06:22 <liske> can someone please take care of !21666 ?
2021-06-05 16:44:57 <liske> thanks :)
2021-06-05 20:05:36 <clandmeter> Ariadne: how did you build gcc-gnat? 
2021-06-05 20:12:03 <smcavoy> hello, I am attmepting to run the bootstrap.sh script to get a cross compile environment for aarch64 on x86_64. It runs and compiles much but breaks on this: "/usr/lib/gcc/aarch64-alpine-linux-musl/10.3.1/../../../../aarch64-alpine-linux-musl/bin/ld: /usr/lib/gcc/aarch64-alpine-linux-musl/10.3.1/adalib/libgnat.a: error adding symbols: file in wrong format"
2021-06-05 20:12:21 <smcavoy> this is on Alpine Linux edge
2021-06-05 20:12:41 <smcavoy> and for the gcc package, any idea what might be broken?
2021-06-05 20:40:19 <Hello71> alpine doesn't natively support cross compilers
2021-06-05 20:40:46 <Hello71> also 
2021-06-05 20:40:47 <Hello71> 20:05 <@clandmeter> Ariadne: how did you build gcc-gnat?
2021-06-05 20:41:34 <Sheila> smcavoy: you may be interested in https://musl.cc
2021-06-05 20:42:06 <ikke> Doesn't seem to load
2021-06-05 20:44:16 <smcavoy> Hello71: I ran the bootstrap.sh script included in the aports git repo
2021-06-05 20:47:17 <smcavoy> ikke: thanks, will check it out
2021-06-05 20:47:30 <ikke> smcavoy: you want to thank Sheila 
2021-06-05 20:57:06 <smcavoy> Sheila: thanks
2021-06-05 20:57:08 <smcavoy> :)
2021-06-05 20:57:15 <Sheila> :)
2021-06-05 20:57:18 <Sheila> np
2021-06-05 21:48:57 <Ariadne> clandmeter: bootstrap.sh builds it
2021-06-06 04:51:37 <ddevault> test. your. shit.
2021-06-06 04:54:48 <Sheila> this is why back in the day I didn't want direct commit access. and that was *before* Alpine had CI/CD.
2021-06-06 05:24:09 <maribu[m]> PureTryOut (matrix.org): pipewire seems to no longer profile /etc/pipewire/pipewire.conf. Is this intentional and users should create one, if they need a custom config? pipewire seems to work as before for me. I only think that the post-upgrade message is a bit confusing, if this change is intentional.
2021-06-06 05:48:22 <maribu[m]> Btw: Could someone take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21956 ? This could become handy next time a similar issue as the current sway segfault pops up.
2021-06-06 06:36:15 <smcavoy> maribu[m]: thanks for the mr for sway.
2021-06-06 06:36:46 <maribu[m]> you're welcome
2021-06-06 06:43:53 <maribu[m]> mps Since you seem to be interested on libudev-zero: Do you happen to know if it is not only API compatible with eudev, but also ABI compatible?
2021-06-06 06:45:41 <maribu[m]> IMO we should try to make libudev-zero and eudev mutually exclusive. And if they are (guaranteed to be) ABI compatible, why not just build libudev-zero also as dynamic lib and let users choose which to install
2021-06-06 06:45:47 <mps> maribu[m]: yes, both (it tries at least)
2021-06-06 07:03:59 <mps> maribu[m]: when you are here, do you plan to upgrade kicad 'batteries'
2021-06-06 07:05:36 <maribu[m]> I'm currently afk, but I'll look into it later today
2021-06-06 07:08:11 <mps> no need to hurry, I'm just curious
2021-06-06 07:52:37 <staceee> Could someone merge aport #21861 please ? We'd will rely on pn on Sxmo and this delay us :D
2021-06-06 07:52:54 <ikke> !21861
2021-06-06 08:15:30 <mps> now we should concentrate on bugs for next release
2021-06-06 08:16:21 <mps> hmmmhmmm, why is riscv6 added to builders just before release
2021-06-06 08:49:55 <Ariadne> mps: its not going to be a release architecture so don't worry about it
2021-06-06 09:09:28 <ikke> imagemagick-libs-7.0.11.13-r0 provides:
2021-06-06 09:09:30 <ikke> so:libMagickCore-7.Q16HDRI.so.9=9.0.0
2021-06-06 09:09:53 <ikke> 2c88acec5fe73a7e359a6745a3d9d62cb913593c on v3.13 seems to introduce a soname change?
2021-06-06 09:10:06 <Ariadne> hmm
2021-06-06 09:10:34 <Ariadne> so it did
2021-06-06 09:10:43 <ikke> php7-pecl-imagick was built against so:libMagickCore-7.Q16HDRI.so.8
2021-06-06 09:11:49 <Ariadne> oh
2021-06-06 09:11:52 <Ariadne> haha
2021-06-06 09:11:55 <Ariadne> oops
2021-06-06 09:12:10 <Ariadne> i have rebuilds for these packages already in my queue
2021-06-06 09:12:15 <ikke> aha, ok
2021-06-06 09:12:18 <Ariadne> i just forgot to push
2021-06-06 09:38:31 <Ariadne> anyway night everyone
2021-06-06 09:38:58 <ikke> o/
2021-06-06 09:50:40 <nmeum> I just woke up! :O
2021-06-06 14:07:35 <Hello71> did we ever come to a conclusion regarding whether .so files should be in -libs or -dev?
2021-06-06 14:12:30 <caskd> aren't they part of -dev as of now?
2021-06-06 14:12:39 <caskd> oh wait nvm
2021-06-06 14:12:41 <caskd> ignore me
2021-06-06 14:14:42 <Hello71> sometimes
2021-06-06 14:14:51 <Hello71> that's what i'm asking about :p
2021-06-06 15:10:03 <ikke> do we want git 2.32.0 in 3.14?
2021-06-06 15:10:09 <ikke> it has just been released
2021-06-06 15:16:49 <mps> we always want new and shiny :)
2021-06-06 15:17:18 <ikke> certainly helps with upgrades
2021-06-06 15:18:40 <mps> that is why we rush to upgrade as much as possible just before release
2021-06-06 15:19:21 <ikke> ahuh
2021-06-06 15:20:02 <ikke> I think with git, the risk is not that high, and if it gives issues for the builders, we can still revert
2021-06-06 15:20:26 <mps> sounds good
2021-06-06 15:21:34 <Cogitri> And git has a good test suite
2021-06-06 15:21:42 <ikke> yes, I made sure to enable that
2021-06-06 15:21:54 <ikke> it has been disabled for quite some time
2021-06-06 15:22:25 <ikke> !22081
2021-06-06 15:25:36 <Cogitri> Ah, nice
2021-06-06 15:47:57 <PureTryOut> @maribu:matrix.org default config is installed to /usr/share/pipewire now and if the user wants to overwrite it then they should copy it to /etc/pipewire/pipewire.conf as before
2021-06-06 16:01:28 <donoban> ey PureTryOut I checked my computer and noticed that I have a pipewire process coming from kde sessione but also have a pulseaudio from init
2021-06-06 16:03:12 <donoban> it seems that its playing with pulseaudio
2021-06-06 16:07:01 <donoban> ouch, firefox crash
2021-06-06 16:32:03 <Ariadne> Hello71: the .so files themselves should be in -dev imo
2021-06-06 16:32:15 <Ariadne> Hello71: -libs is for the .so.X.Y.Z files
2021-06-06 17:07:50 <Hello71> specifically this is still about #12725, where part of the issue was that it was allowed to install both eudev-libs and libudev-zero-dev at the same time
2021-06-06 17:08:17 <ikke> should they conflict?
2021-06-06 17:08:58 <Hello71> i think they would automatically conflict if libudev.so was moved from libudev-zero to libudev-zero-dev
2021-06-06 17:09:14 <Hello71> and i think we should be consistent anyways so it would be an added bonus :p
2021-06-06 17:09:43 <Hello71> hm, wait, it's supposed to be moved already? https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1949
2021-06-06 17:10:05 <Hello71> i guess the problem is libudev-zero moves .so in libs subpackage
2021-06-06 17:10:16 <Hello71> or somesuch? gonna check again
2021-06-06 17:11:43 <ikke> And I'm kinda supprised that libudev-zero provides udev
2021-06-06 17:12:56 <ikke> provides + replaces
2021-06-06 17:14:11 <mps> ikke: what's wrong with this
2021-06-06 17:17:53 <ikke> that it provides a virtual package that shadows an existing package
2021-06-06 17:18:12 <ikke> afaik, that can give issues
2021-06-06 17:20:10 <mps> so, provides shouldn't be used?
2021-06-06 17:21:04 <mps> isn't 'provides + replaces' actually 'conflits'
2021-06-06 17:21:21 <ikke> conflicting is adding !<pkg> to depends
2021-06-06 17:21:21 <mps> conflicts*
2021-06-06 17:21:57 <ikke> if you use provides, you should do provides="udev=$pkgver-r$pkgrel"
2021-06-06 17:22:06 <mps> aha
2021-06-06 17:22:16 <ikke> and replaces is not necessary in this case
2021-06-06 17:22:19 <ikke> afaik
2021-06-06 17:22:30 <mps> new libudev-zero is on 'horizon', will change this
2021-06-06 17:53:33 <ddevault> just got a surprise riscv64 board in the mail
2021-06-06 17:53:37 <ddevault> how's the latest work on that port going
2021-06-06 17:54:35 <ikke> We have an edge builder running in docker atm
2021-06-06 17:55:49 <ddevault> nice
2021-06-06 17:55:51 <ddevault> how's its progress going
2021-06-06 18:02:00 <Sheila> 'lol'. pages and pages of FTBFS in -commits
2021-06-06 18:02:54 <ikke> mostly due to missing dependencies and --keep-going enabled
2021-06-06 19:13:51 <clandmeter> ddevault: the packages are here https://dev.alpinelinux.org/~clandmeter/packages/riscv64/ for now.
2021-06-06 19:13:59 <ddevault> cool
2021-06-06 19:15:18 <clandmeter> logs are in the regular place: https://build.alpinelinux.org/buildlogs/build-edge-riscv64/
2021-06-06 19:15:28 <clandmeter> still a lot needs fixing
2021-06-06 19:15:49 <clandmeter> but qemu 6 is much better compared to 5
2021-06-06 19:16:16 <clandmeter> ddevault: which board did you get?
2021-06-06 19:16:20 <ddevault> hifive unmatched
2021-06-06 19:16:45 <ddevault> I'll get the port up on it when I have some time for it, which could be as late as 3-4 months from now
2021-06-06 19:17:30 <ikke> there is no release anyway
2021-06-06 19:17:38 <ikke> ie, no images
2021-06-06 19:17:44 <ddevault> 
ACTION shrugs

2021-06-06 19:17:56 <ddevault> I ported it to my hifive unleashed a couple of years ago
2021-06-06 19:17:58 <ddevault> nbd
2021-06-06 19:18:01 <ikke> nod
2021-06-06 19:18:42 <clandmeter> i have requested boards from riscv via the developer program
2021-06-06 19:18:47 <clandmeter> not sure we will get any
2021-06-06 19:19:03 <ddevault> I can get you a shell if you wish
2021-06-06 19:20:23 <ddevault> now that I have the unmatched I could also probably be easily convinced to pack up my unleashed and mail it off to someone who can get good use out of it
2021-06-06 19:21:00 <clandmeter> roman was complaining the performance was not that great, not sure it was unleashed or unmatched board
2021-06-06 19:21:12 <ddevault> roman who?
2021-06-06 19:21:14 <ddevault> KDE roman?
2021-06-06 19:21:29 <ddevault> I found the performance to be acceptable, though not impressive, on the unmatched
2021-06-06 19:21:34 <ddevault> err, unleashed*
2021-06-06 19:21:36 <ddevault> have not tested the unmatched
2021-06-06 19:21:38 <clandmeter> the one who did the recent port
2021-06-06 19:21:49 <ikke> ddevault: https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10722
2021-06-06 19:21:54 <ikke> Roman Shaposhnik
2021-06-06 19:22:11 <nmeum> there is also a thread on the devel ML by roman about next steps
2021-06-06 19:22:30 <ikke> ddevault: he gave a talk at the alpine-conf about edge computing
2021-06-06 19:22:30 <nmeum> https://lists.alpinelinux.org/~alpine/devel/%3CCAMmSBy-3%3DMYWhjSVJ1aiMy01mNZxNkERxfvFUpAs6Uwf0sdFgw%40mail.gmail.com%3E
2021-06-06 19:22:53 <ddevault> thanks for the links/details
2021-06-06 19:23:07 <ddevault> offer on the table for an unleashed for anyone who needs it
2021-06-06 19:23:19 <ddevault> otherwise I'll test out the new work in a few months and send patches as I see fit
2021-06-06 19:24:03 <ddevault> once I have the unmatched online in a stable configuration I would be happy to share shell access with alpine devs
2021-06-06 19:24:43 <nmeum> sweet
2021-06-06 19:24:51 <ikke> would help debugging issues
2021-06-06 20:42:52 <Hello71> ah, libudev-zero libudev.so isn't in -dev due to https://github.com/illiliti/libudev-zero/commit/db72f8610d62a5e6884c6d8d86660d07e49455c4
2021-06-06 20:43:07 <Hello71> should work in next version i guess
2021-06-06 21:24:40 <dalias> has the issue with udev-zero been solved? :)
2021-06-06 21:48:23 <Hello71> well sway was fixed
2021-06-06 21:48:42 <Hello71> but i'd like to mitigate some of the underlying gun-foot-pointing
2021-06-07 04:31:54 <ikke> one thing I'm wondering: why do all these go issues only happen on the edge builders, but not on the 3.14 builders?
2021-06-07 04:32:23 <ikke> oh, just realized
2021-06-07 04:32:28 <ikke> they happen in testing :)
2021-06-07 04:45:52 <Ariadne> :)
2021-06-07 04:50:06 <ikke> most of these are just fixed by upgrading
2021-06-07 05:43:54 <mps> build-edge-riscv64 and build-riscv64-edge builders?
2021-06-07 05:46:39 <ikke> one was a mistake
2021-06-07 05:46:43 <ikke> but it's retained
2021-06-07 05:47:34 <mps> aha, thanks for info
2021-06-07 06:18:43 <mps> hmm, libx11 1.7.2 is released with 3 fixes, should we upgrade just before freeze? ncopa?
2021-06-07 06:20:11 <mps> git commit msgs are: "Protect against overly long strings", "Check for NULL strings before getting their lengths" and "include <limits.h> always, not if HAVE_CONFIG_H is set."
2021-06-07 06:25:29 <mps> ncopa: here is MR, just in case !22092
2021-06-07 06:28:54 <ncopa> good morning
2021-06-07 06:31:29 <mps> good (shinny again) morning all
2021-06-07 06:31:51 <mps> yesterday was big storm here
2021-06-07 06:49:10 <rdavidson> hi, I am trying to build an existing package (just to make sure things are set up properly). specifically, community/py3-numpy. I'm doing this in a brand new chroot I made for this purpose. However, when I try building the package from the unmodified git checkout, it fails with a "[Errno 13] Permission denied", and I cannot for the life of me figure out what permission is being denied. (when I build the package as root, using abuild
2021-06-07 06:49:10 <rdavidson>  -F -r, it builds just fine.
2021-06-07 06:49:57 <ncopa> where/when dies it fail?
2021-06-07 06:50:11 <rdavidson> during compilation of the package
2021-06-07 06:50:19 <ncopa> so not during fetch
2021-06-07 06:50:35 <ncopa> is things like /tmp world writeable?
2021-06-07 06:50:44 <ncopa> and /dev/null and things are there?
2021-06-07 06:50:49 <ncopa> and writeable?
2021-06-07 06:52:08 <rdavidson> yeah, /tmp, /dev/, /proc, /sys are all present and accounted for
2021-06-07 06:52:49 <rdavidson> i used alpine-make-rootfs to build the chroot tree (and i'm using schroot on my host debian system to enter it)
2021-06-07 06:56:11 <nmeum> you could check with strace on which file the syscall fails
2021-06-07 06:56:50 <rdavidson> alright, i'll give that a shot.
2021-06-07 06:58:27 <markand> o/
2021-06-07 06:59:21 <mps> fcolista: maybe I'm blind but I don't see !22091 after 'git pull --rebase --all' in git log
2021-06-07 07:00:32 <mps> fcolista: and buon giorno :)
2021-06-07 07:00:53 <fcolista> mps, it-s merged in my git tree just updating other packages and then push it
2021-06-07 07:01:06 <fcolista> ps: buon giorno :)
2021-06-07 07:01:07 <mps> aha, ok. thanks
2021-06-07 07:01:13 <fcolista> just pushed
2021-06-07 07:01:24 <mps> s/thanks/grazie/
2021-06-07 07:01:25 <alpine-meetbot> mps meant to say: aha, ok. grazie
2021-06-07 07:01:45 <fcolista> nm :)(
2021-06-07 07:03:15 <rdavidson> nmeum: if i run strace without -f it doesn't follow into the child process that actually does the build; if i do run it with -f (or -ff), this somehow makes it unable to lock the apk database for installing build deps
2021-06-07 07:03:38 <rdavidson> maybe if i edit the APKBUILD and add it to the build step?
2021-06-07 07:04:09 <ikke> rdavidson: strace disables setuid 
2021-06-07 07:04:24 <rdavidson> i've never used it before :D
2021-06-07 07:05:17 <ikke> In the case of abuild, it's kind of tricky 
2021-06-07 07:05:48 <ncopa> rdavidson: try abuild -v ... to find out exactly what command fails
2021-06-07 07:05:58 <markand> can someone have a look at !21206 ?
2021-06-07 07:06:32 <ncopa> maybe after rc1, dont want spend time in testing right now
2021-06-07 07:08:50 <rdavidson> ncopa: did that, it was not particularly helpful to me. however, strace in the build step worked. it's /dev/shm. my build user can't use it, but obviously root can.
2021-06-07 07:10:10 <ncopa> i think it should be world writable
2021-06-07 07:11:37 <rdavidson> it is not! but a quick chmod later…
2021-06-07 07:12:44 <rdavidson> thanks for the strace tips
2021-06-07 07:12:52 <mps> nmeum: about !22073 and !22072, if they work on problematic machines I think they should be merged
2021-06-07 07:13:27 <mps> I don't have machine where I could test these
2021-06-07 07:13:59 <mps> for me all 1.2.5 worked 'out-of-the-box'
2021-06-07 07:17:00 <nmeum> was waiting to see if maxice8 had any objections :)
2021-06-07 07:17:49 <mps> np for me, it works on all my chromebooks :)
2021-06-07 07:18:10 <nmeum> regarding the crash in load_state: If you think the patch is ok just merge it, I personally always like to wait for upstream feedback before merging custom patches
2021-06-07 07:18:54 <mps> also I don't like to merge such patches if I can't test it
2021-06-07 07:19:06 <mps> so, I'm with you on this
2021-06-07 07:21:44 <rdavidson> the build works now
2021-06-07 07:24:13 <rdavidson> i have another question; i know there is apkbuild-pypi, which handles making an alpine package out of a Python package that's on pypi. But suppose I have a python package which is not on pypi, but I do have a source tarball for it (with the setup.py and all). does apkbuild-pypi work with that situation too? 
2021-06-07 07:26:06 <ikke> New apkbuild -y <name>
2021-06-07 07:26:24 <ikke> Concatenated 
2021-06-07 07:29:16 <rdavidson> ty
2021-06-07 07:40:56 <PureTryOut> donoban: Plasma Wayland uses Pipewire for window previews in the task switcher
2021-06-07 07:41:20 <PureTryOut> If you want Pipewire to also replace your PulseAudio then you have to copy and edit the Pipewire config properly, and make sure `pipewire-pulse` is installed
2021-06-07 07:51:59 <donoban> ah thanks PureTryOut , I was reading the wiki and saw the /etc/pipewire/pipewire.conf but read here that default conf was moved to /usr/share/pipewire , should all the dir be copied to etc or only the pipewire.conf file is enough?
2021-06-07 07:52:12 <PureTryOut> Just the conf
2021-06-07 07:53:04 <donoban> ok, I could update the wiki, mkdir /etc/pipewire, cp /usr/share/pipewire/pipewire.conf... and uncomment "{ path = "/usr/bin/pipewire-media-session"  args = "" }" ?
2021-06-07 07:55:23 <PureTryOut> Yeah sure
2021-06-07 07:55:47 <donoban> ok
2021-06-07 08:00:28 <PureTryOut> fcolista: any chance `-DBUILD_BROWSER` can be set to on for obs-studio?
2021-06-07 08:17:57 <fcolista> PureTryOut, we need obs-browser
2021-06-07 08:18:43 <PureTryOut> That's another dependency? Why can't we just package that?
2021-06-07 08:19:03 <fcolista> PureTryOut, it's another package, obs-browser
2021-06-07 08:20:13 <fcolista> since obs-browser was not available as APKBUILD, i added BUILD_BROWSER=off
2021-06-07 08:20:26 <fcolista> once obs-browser is built, than we can enable it
2021-06-07 08:27:51 <PureTryOut> Ah ok 👍️
2021-06-07 08:38:06 <fcolista> PureTryOut, actually i was wrong. Looking at the documentation of obs-browser, it states that this cannot be built standaolne
2021-06-07 08:38:55 <PureTryOut> Ah so in-program dep then
2021-06-07 08:39:21 <fcolista> umh..
2021-06-07 08:39:27 <fcolista> it needs CEF_ROOT DIR
2021-06-07 08:39:28 <fcolista> CEF_ROOT_DIR is the path to an extracted CEF Wrapper. We provide a custom prebuilt wrapper to simplify the build process. This custom build includes access to hardware acceleration and additional codecs. This enables Browser Source and Custom Browser Docks.
2021-06-07 08:39:28 <fcolista> Be sure to also enable the CMake flag BUILD_BROWSER otherwise this will do nothing
2021-06-07 08:40:29 <PureTryOut> Ha, fun
2021-06-07 08:44:41 <fcolista> So we need to build first cef, then enable BUILD_BROWSER=ON and add the path to CEF via CEF_ROOT_DIR
2021-06-07 08:45:23 <fcolista> https://bitbucket.org/chromiumembedded/cef/src/master/
2021-06-07 09:05:37 <fcolista> who has a ppc64le build env where I can test a patch?
2021-06-07 09:08:39 <fcolista> ah we have a pipeline for ppc64le
2021-06-07 11:57:33 <ncopa> im working on mtools, which appears to segfault since 4.0.28 on 32 bit arches when -fomit-frame-pointer is set
2021-06-07 12:18:58 <mps> hmm, 4.0.29 has just one change 'Fix bug in cluster preallocation, which was accidentally introduced by compiler warning "fixes" from v4_0_28'
2021-06-07 13:26:29 <clandmeter> there is no luajit support for riscv, so i guess we need to disable or hack some aports
2021-06-07 13:41:20 <markand> https://luis-sena.medium.com/creating-the-perfect-python-dockerfile-51bdec41f1c8#3030
2021-06-07 13:41:28 <markand> a friend shown me this
2021-06-07 13:41:40 <markand> I wonder how can ubuntu be faster than alpine 
2021-06-07 14:04:00 <valerius> markand, it's the musl malloc implementation
2021-06-07 14:05:22 <kasper81> hey guys, could anyone review this MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22087? user is created by other packaging systems but not aports. there is no useful error, but after some debugging i found this difference between centos and alpine package.
2021-06-07 14:08:34 <fcolista> markand, since wheel support is based on glibc, while alpine uses musl
2021-06-07 14:09:19 <donoban> kasper81: maybe the adduser options are gnu version? check busybox adduser --help
2021-06-07 14:09:22 <fcolista> https://discuss.python.org/t/wheels-for-musl-alpine/7084
2021-06-07 14:10:57 <kasper81> donoban: i have verified this patch locally on alpine linux, it works as expected. i.e. usbmux user is created, with no profile and belongs to usb group.
2021-06-07 14:13:00 <donoban> ah I understood that you had some problem with user creation
2021-06-07 14:15:10 <minimal> markand: that article is using the Docker image "python:3.9-alpine3.13" which is not the same as the python packaged by Alpine. The python binary in that image is compiled by the Docker image maintainers: https://github.com/docker-library/python/blob/master/3.9/alpine3.13/Dockerfile
2021-06-07 14:15:26 <markand> aah
2021-06-07 14:15:58 <markand> so wrong benchmark
2021-06-07 14:16:47 <minimal> markand: having said that, the Python packaged for Alpine is still compiled using "-Os" (for size) so it may well be slower than that docker image
2021-06-07 14:17:46 <minimal> there were discussions in the past about optimising Alpine's python: #12058
2021-06-07 14:20:03 <ikke> minimal: I see -Os being removed from CFLAGS in the python3 APKBUILD 
2021-06-07 14:22:13 <kasper81> ah, adduser's help menu seems to be missing full names, but it works with them because implementation has the mapping https://github.com/mirror/busybox/blob/4d983dcd/loginutils/adduser.c#L166. i can use the short names if that's preferred.
2021-06-07 14:22:42 <minimal> ikke: maybe I misread that line in the APKBUILD but in the build.log file I see "-Os" being passed to gcc
2021-06-07 14:23:14 <minimal> minimal: ah, I see *both* -O3 and -Os being passed
2021-06-07 14:23:37 <minimal> s/minimal/ikke/
2021-06-07 14:23:37 <alpine-meetbot> minimal meant to say: ikke: ah, I see *both* -O3 and -Os being passed
2021-06-07 14:47:57 <ncopa> alright, i think i've finally got the mtools segfault fixed, should be possible to tag release now
2021-06-07 14:48:01 <ncopa> rc1 that is
2021-06-07 14:49:03 <ncopa> hum
2021-06-07 14:49:13 <ncopa> where did the mips64 builder go?
2021-06-07 14:49:20 <ncopa> maybe its time to drop it
2021-06-07 14:53:24 <donoban> uhM, I having some firefox crashes
2021-06-07 14:53:50 <donoban> https://tpaste.us/ejo5 
2021-06-07 14:54:15 <PureTryOut> Has the riscv builder started building yet? Right now it says "failed" but no mention of any package it failed on
2021-06-07 14:54:48 <donoban> I got to go, see you later
2021-06-07 15:29:56 <ikke> ncopa: network issues, ariadne already pinged someone there
2021-06-07 16:40:44 <nmeum> PureTryOut: yes, packages are currently here https://dev.alpinelinux.org/~clandmeter/packages/riscv64/
2021-06-07 16:41:26 <ikke> PureTryOut: You can ignore "build-risc64-edge", that was an incorrectly named builder
2021-06-07 16:41:37 <ikke> "build-edge-riscv64" is the correct one
2021-06-07 17:04:48 <ncopa> im fixing the heplify-server build error
2021-06-07 17:05:26 <ncopa> so, i found the problem, and sent a PR to upstream
2021-06-07 17:05:54 <ncopa> i posted a "please take a close look at this because I don't really now what i'm doing here" message
2021-06-07 17:06:06 <ncopa> and then i see "merged 18 seconds ago"
2021-06-07 17:06:11 <ncopa> :D
2021-06-07 17:06:40 <ikke> :D
2021-06-07 17:06:48 <ikke> funny, because I was looking at the same thing
2021-06-07 17:07:08 <ikke> I refreshed the page, and saw the issue count increasing, seeing your issue
2021-06-07 17:08:37 <ikke> ncopa: I have some other changes as well for heplify-server
2021-06-07 17:09:29 <ikke> https://tpaste.us/wP6X
2021-06-07 17:12:54 <nmeum> mps: I merged the alsa-utils segfault fix (it has been merged upstream)
2021-06-07 17:14:53 <PureTryOut> ikke: oh yes very cool! Let's see what we can get compiled
2021-06-07 17:15:11 <ikke> it's also anouncing already in #alpine-commits
2021-06-07 17:22:41 <nmeum> does it run tests too?
2021-06-07 17:22:52 <ikke> no
2021-06-07 17:22:57 <ikke> they have been disabled for the time being
2021-06-07 17:23:35 <nero> man, i was just testing edge, and firefox messed up their tab bar and made it some kind of buttons
2021-06-07 17:23:48 <PureTryOut> Stuck on Valgrind not supporting the architecture for now it seems
2021-06-07 17:23:53 <nero> browser.proton.enabled = false to fix it
2021-06-07 17:23:57 <PureTryOut> nero: you can disable that
2021-06-07 17:24:00 <PureTryOut> Oh yes like that 😛
2021-06-07 17:24:16 <ikke> For the time being ;)
2021-06-07 17:24:18 <nero> every time i go into about:config, its to revert some UI shit they think is hip now
2021-06-07 17:28:36 <dalias> oh yay it's fixable? :)
2021-06-07 17:29:16 <dalias> it wastes like 2% more vertical screen space which is hideous
2021-06-07 17:29:58 <dalias> symptom of having a dev team that uses nothing but 36" 4k desktop monitors (probably 2 or 3 side by side) and mac book laptops
2021-06-07 17:30:43 <dalias> on standard latop screen height (sadly still 768) you cannot waste any of it
2021-06-07 17:31:02 <dalias> most sites are already near-unusable without browser/system ui crap wasting more of it
2021-06-07 17:31:44 <jvoisin> dalias: thanks for the tip!
2021-06-07 17:49:44 <ikke> Cogitri: dub has test failures
2021-06-07 17:51:07 <Cogitri> Yuck, worked on CI
2021-06-07 17:53:39 <ncopa> ikke: had to step out for a few seconds. here is what I have https://tpaste.us/8jyO
2021-06-07 17:54:05 <ikke> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22104/diffs
2021-06-07 17:56:21 <ikke> so quite similar, I decided to drop the existing patch, as it effectively does not do anything anymroe
2021-06-07 17:56:35 <ikke> and took into account that riscv64 has no luajit yet
2021-06-07 17:56:49 <ncopa> ok
2021-06-07 17:57:45 <ikke> -buildmode=pie not supported when -race is enabled 😑
2021-06-07 18:01:45 <ncopa> hum dub fails on aarch64
2021-06-07 18:02:24 <dalias> jvoisin, ?
2021-06-07 18:02:37 <jvoisin> oh, it was nero
2021-06-07 18:02:45 <jvoisin> browser.protong.enable = false
2021-06-07 18:02:50 <jvoisin> (I also have a small screen)
2021-06-07 18:03:47 <ikke> ncopa: I already notified Cogitri 
2021-06-07 18:07:35 <ncopa> im tagging rc1 now
2021-06-07 18:07:50 <ikke> \o/
2021-06-07 18:07:59 <ncopa> lets see if it builds
2021-06-07 18:08:19 <jvoisin> \o/
2021-06-07 18:08:26 <ikke> 
ACTION prepares vms to test the build

2021-06-07 18:12:52 <PureTryOut> 🎉
2021-06-07 18:15:11 <ncopa> there is no mips64. lets see if anyone notices that... :)
2021-06-07 18:23:57 <mps> nmeum: well done!
2021-06-07 18:28:04 <Cogitri> Could someone disable the dub tests? They work locally and on CI
2021-06-07 20:02:57 <ikke1> Hello world, from Alpine Linux 3.14-rc1
2021-06-07 20:12:23 <storymode7> /!\ ΤНIЅ ⅭHAⲚΝEL HAS MOVΕD ТO IRC.ⅬIBΕRА.CHAТ ＃HΑMᎡΑᎠІО /ǃ\
2021-06-07 20:12:39 <MY-R> ikke: ^ :D +R
2021-06-07 20:12:58 <ikke> sigh
2021-06-07 20:13:12 <MY-R> now they trying be smart and use other utf chars...
2021-06-07 20:13:13 <jvoisin> thoughts and prayers
2021-06-07 21:29:31 <craftyguy> Cogitri: do you have any thoughts on this? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21893#note_160972
2021-06-07 21:55:22 <Hello71> craftyguy: not sure about your case exactly, but it's GDK_BACKEND=x11, not GDK_BACKEND=X11
2021-06-07 21:56:05 <craftyguy> oops, ya I had actually used x11, but typed it out wrong in the comment
2021-06-07 21:56:41 <craftyguy> the underlying issue is that gsd-xsettings doesn't work at all when `GDK_BACKEND=wayland`
2021-06-07 21:56:44 <Hello71> and GDK_BACKEND= doesn't seem valid either (testing with other gtk programs, but should be same?)
2021-06-07 21:57:12 <craftyguy> well I was trying to come up with a way to unset that var when running gsd-xsettings
2021-06-07 21:57:45 <craftyguy> those are essentially my failed attempts to find a workaround without getting into debugging wtf is going on in gsd-xsettings
2021-06-07 21:58:00 <Hello71> env -u GDK_BACKEND
2021-06-07 21:59:48 <Hello71> what is setting GDK_BACKEND?
2021-06-07 21:59:59 <Hello71> it seems reasonable that xsettings doesn't work without x
2021-06-07 22:00:30 <craftyguy> no idea
2021-06-07 22:00:39 <Hello71> "cannot open display: :0" is a crap error but my expectations are low for gtk
2021-06-07 22:00:50 <craftyguy> ya that's reasonable, I guess. seems like Xwayland would work though, but it doesn't
2021-06-07 22:00:58 <Hello71> well not if you force GDK_BACKEND
2021-06-07 22:01:02 <Hello71> https://github.com/keybase/client/issues/19614#issuecomment-535572603
2021-06-07 22:01:28 <craftyguy> I don't know who or what is setting GDK_BACKEND
2021-06-07 22:01:32 <Hello71> afaik the only thing that required GDK_BACKEND=wayland was firefox, and it didn't work properly anyways
2021-06-07 22:01:54 <Hello71> afaik GDK_BACKEND is a debugging footgun, similar to LC_ALL
2021-06-07 22:01:56 <craftyguy> oh, looks like we are in pmOS
2021-06-07 22:02:03 <craftyguy> 
ACTION facepalm

2021-06-07 22:02:10 <craftyguy> it probably helps some apps, and breaks others
2021-06-07 22:02:30 <craftyguy> e.g. if I don't set it for some apps on my desktop, they try to use Xwayland (which I don't want)
2021-06-07 22:03:08 <Hello71> i think only old firefox and possibly also old electron
2021-06-07 22:03:28 <craftyguy> ya maybe not it's irrelevant at this point
2021-06-07 22:03:32 <craftyguy> s/not/now/
2021-06-07 22:03:32 <alpine-meetbot> craftyguy meant to say: ya maybe now it's irrelevant at this point
2021-06-07 22:03:48 <craftyguy> let's remove it from profile.d and see what happens
2021-06-07 22:03:50 <Hello71> but for the most part they prefer(red) xwayland for a good reason, i.e. broken wayland integration
2021-06-07 22:04:30 <Hello71> which is usually the crappy bloat's own fault, but that's neither here nor there
2021-06-07 22:04:47 <craftyguy> haha, FF 89 is completely broken when GDK_BACKEND is unset
2021-06-07 22:05:55 <craftyguy> http://0x0.st/-_lg.png
2021-06-07 22:06:29 <craftyguy> so, even the latest FF seems to need GDK_BACKEND=wayland, at least on phosh
2021-06-07 23:33:46 <ngortheone> what are the default make flags that are used for building apks? and what file is holding those settings?
2021-06-07 23:36:14 <ngortheone> in particular I want to see what are default -O and -march settings
2021-06-07 23:47:53 <artok> it's /etc/abuild.conf
2021-06-08 00:06:09 <ngortheone> does that mean that all packages in alpine repos are built with -Os?
2021-06-08 00:10:14 <artok> that's default, might be some overrides
2021-06-08 01:51:05 <c705> ncopa: are you folks aware that someone is selling an ami of alpine linux for 2500$ a year?
2021-06-08 01:51:36 <Hello71> yes, it was discussed at alpineconf and, before that, in this channel
2021-06-08 01:51:40 <c705> ah
2021-06-08 01:52:12 <Hello71> and i thought it was actually like $20000/year
2021-06-08 01:52:31 <c705> i guess they have a sale? ;)
2021-06-08 01:52:52 <Hello71> my understanding is we consulted with amazon and they said it was not violating amazon policies, and we think it's probably not illegal, so our plan is to advance our own images instead
2021-06-08 01:52:58 <kasper81> hey guys, i am not sure if anyone has noticed, but s390x+mips64 and in some cases ppc64le+mips64 packages are not being published for past 11 hours.
2021-06-08 01:53:08 <Hello71> kasper81: what does the + mean
2021-06-08 01:53:24 <Hello71> it's scammy, but not all scams are illegal scams
2021-06-08 01:53:32 <c705> yup
2021-06-08 01:54:02 <Hello71> it's bordering on illegal, but without a legal organization and formal trademark paperwork it's hard to enforce
2021-06-08 01:54:20 <kasper81> Hello71, + as in 'and'
2021-06-08 01:54:24 <Hello71> we could probably send legal threats to amazon and they would probably take it down, but i think we want to try to keep good relations
2021-06-08 01:54:43 <Hello71> re mips64, i think the builder is down, and with the other ones, they might just be slow
2021-06-08 01:54:55 <Hello71> what exactly are you seeing that you think is not right?
2021-06-08 01:55:26 <kasper81> yup but nobody pointed out s390x and ppc64le. it was all fine until c0a1144c4834b999e43765105839d0d7c08d03b7 (commit SHA1).
2021-06-08 01:55:29 <c705> Hello71: is there anything official yet in terms of amis, or just talk?
2021-06-08 01:56:13 <Hello71> c705: "cloud team" is working on cloud-init support and some other things
2021-06-08 01:56:23 <Hello71> i think if you want to contribute you can /join #alpine-cloud
2021-06-08 01:56:47 <Hello71> i think we do actually have amis, they're linked on alpinelinux.org... somewhere
2021-06-08 01:56:52 <c705> thanks
2021-06-08 01:56:52 <Hello71> https://alpinelinux.org/cloud?
2021-06-08 02:47:17 <minimal> c705: separate from the "official AMIs" I'm working on creating cloud-init enabled images for multiple cloud providers (plus VMs and physical machines)
2021-06-08 02:49:30 <c705> minimal: interesting. i just quit my job, so I'm hoping i'll be more motivated to contribute
2021-06-08 02:50:13 <minimal> c705: I just published the 1st (early) version of my script at https://github.com/dermotbradley/create-alpine-disk-image
2021-06-08 02:52:04 <c705> minimal: i'll take a look
2021-06-08 02:52:57 <minimal> I've been using my own developed Ansible playbook for the past 12-14 months to build Alpine images. This repo is an equivalent written in Shell. Not everything has been mapped across from my Ansible playbook and I haven't really started testing it yet (beyond Qemu VM) so don't be surprised if you find issues with it
2021-06-08 02:54:01 <c705> ha. me too actually
2021-06-08 02:54:26 <c705> i boot off usbs that have an ansible controller + a smaller playbook to fetch the bulk of my other playbooks from git
2021-06-08 02:56:06 <minimal> I used my Ansible playbook to build an Alpine disk image for an Ansible controller running on a RPI ('dd'ed the image onto SDcard) for managing my other machines :-)
2021-06-08 02:59:27 <c705> it's kind of cool how both of us came up with similar ideas
2021-06-08 03:01:56 <minimal> c705: well I've been building all my machine this way for more than a year, its why I knocked the Alpine cloud-init package into shape (and contributed the Alpine changes upstream)
2021-06-08 03:03:13 <minimal> I boot new physical machines using a small partition for the cloud-init YAML files - simply edit the hostname, dynamic/static IP config, etc in the YAML files before 1st boot and bingo the machine is automagically configured :-)
2021-06-08 05:57:34 <mps> what's with algitbot 'testing/lingot: move from testing | http://dup.pw/alpine/aports/ec6bebbe4e56'
2021-06-08 05:58:13 <ikke> mps: incorrect commit message
2021-06-08 05:58:24 <ikke> I overlooked that
2021-06-08 05:59:01 <mps> ah, ok. looks like I'm not yet awaken
2021-06-08 09:43:38 <clandmeter> fcolista: something is weird with perl-ldap, not running check() will have files under usr/local
2021-06-08 09:48:43 <fcolista> clandmeter, going to check
2021-06-08 09:48:53 <clandmeter> i think i know what happens
2021-06-08 09:48:57 <clandmeter> i will add a hack
2021-06-08 09:49:08 <fcolista> k
2021-06-08 09:49:18 <clandmeter> make will copy soundex to $pgkdir/usr/local
2021-06-08 09:49:30 <clandmeter> make test will remove it again
2021-06-08 09:49:44 <clandmeter> so without test, you end up with usr/local
2021-06-08 10:00:27 <clandmeter> anyone knows how fedora ExclusiveArch works?
2021-06-08 10:00:53 <clandmeter> mainly what the source is they refer to
2021-06-08 10:13:29 <clandmeter> https://status.fastly.com/
2021-06-08 10:36:21 <ikke>  Hmm, how to fix a library depending on a .so files instead of .so.X.Y
2021-06-08 10:38:53 <noneofyourbusiness1> either edit library or symbolic link the so
2021-06-08 10:45:47 <artok> patchelf for hacking
2021-06-08 10:46:51 <ikke> ptex provides libPtex.so.2.4, openimageio needs libPtex.so, which is incorrect
2021-06-08 10:48:29 <ikke> Hmm, seems like a rebuild is fixing it
2021-06-08 11:13:09 <clandmeter> ncopa: i wonder what to do with luajit not being available on riscv64
2021-06-08 11:13:57 <clandmeter> seems a handful of lua pkgs have dependencies, some based on check depends.
2021-06-08 11:20:12 <ikke> clandmeter: can the use non-jit lua instead?
2021-06-08 11:21:25 <noneofyourbusiness1> perhaps it's just not packaged
2021-06-08 11:22:14 <ikke> 9b7accde88aab7526d84c8a0642db57ef321554f
2021-06-08 11:22:16 <Habbie> ikke, some can, some can't
2021-06-08 11:22:31 <ikke> I already took it into account there
2021-06-08 11:34:33 <Habbie> ikke, it's a pity we're now listing luajit architecture inclusions in various APKBUILDs, though
2021-06-08 11:34:41 <Habbie> eh, exclusions
2021-06-08 11:35:53 <Habbie> (Debian has the same problem)
2021-06-08 11:36:42 <ikke> You mean that it's repeated in each apkbuild? 
2021-06-08 11:36:51 <Habbie> yes
2021-06-08 12:13:38 <PureTryOut> Would anyone mind a major Plasma upgrade today...? 😅 Plasma 5.22 finally got released today and is just too late for Alpine 3.14 lol. But I'm probably going to apply that upgrade on 3.14 anyway once it's released
2021-06-08 12:25:05 <PureTryOut> I've been running the beta for this release quite a while already on my 2 Alpine systems and they have worked great. CI is building the release now
2021-06-08 12:32:14 <ncopa> how much needs to be rebuilt? what are the chances for breakages?
2021-06-08 12:32:45 <ncopa> will you be able to fix any problems quickly?
2021-06-08 12:36:29 <afontain[m]> it may not be a bad idea to wait a week or so after it's merged to edge
2021-06-08 12:38:42 <donoban> I can help with plasma issues
2021-06-08 12:39:11 <donoban> how many rc are expected to be released?
2021-06-08 12:39:26 <donoban> the less possible? heh
2021-06-08 12:39:32 <ikke> afontain[m]: 3.14 is not branched yet
2021-06-08 12:40:12 <PureTryOut> Quite a lot of packages, Gitlab says 58 files but that is including removal of some patches. Chance for breakage is near zero if CI is all green. I have already been testing the beta for a few weeks and everything has been working perfectly fine
2021-06-08 12:40:40 <ncopa> ok
2021-06-08 12:41:05 <PureTryOut> When is final release of 3.14 ETA?
2021-06-08 12:41:10 <ncopa> i was hoping to do rc2 tomorrow
2021-06-08 12:41:45 <ncopa> and if nothing serious shows up maybe the 3.14 on thursday?
2021-06-08 12:42:26 <afontain[m]> right
2021-06-08 12:42:28 <PureTryOut> Ok that is quite close, I can wait till after the release then
2021-06-08 12:43:54 <ncopa> im kinda leaning towards ship it
2021-06-08 12:44:33 <ncopa> i mean if you manage to get the MR done today and its all green so we can merge it later today
2021-06-08 12:44:46 <ncopa> i guess the problem is that the machines will be busy for a while
2021-06-08 12:45:02 <ncopa> PureTryOut: what architecture(s) have you tested the beta?
2021-06-08 12:45:11 <donoban> Could you take a look to !20855 ? it maybe be useful for postmarket users
2021-06-08 12:45:20 <PureTryOut> x86_64 and aarch64 ncopa 
2021-06-08 12:46:19 <PureTryOut> I don't have access to any other architectures. Would love a guide to setting up a RISC-V VM at some point in the future once Alpine edge has been released for it though 😜
2021-06-08 12:47:10 <ncopa> i dunno if it would make sense to test build it on armv7 or x86, but iguess the CI will test that fo us
2021-06-08 12:47:38 <donoban> thanks ncopa 
2021-06-08 12:48:42 <PureTryOut> Yeah I would at least wait till CI is all green. It was green for the beta but you never know what changed in between
2021-06-08 12:49:39 <ncopa> ok
2021-06-08 12:51:08 <mps> 
ACTION asking self why he didn't merged perl

2021-06-08 12:51:29 <ncopa> mps: was it minor version?
2021-06-08 12:51:42 <mps> no ;)
2021-06-08 12:52:01 <ncopa> thanks for not merging it then :)
2021-06-08 12:52:23 <mps> I'm just kidding, there was no intention to merge it
2021-06-08 13:18:25 <ngortheone> guys, could someone break it down for me. I have https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/aports-build/aports-build#L58, but how do I get from there to a flashable image that I can put onto SD card and boot on PBP?
2021-06-08 13:22:25 <PureTryOut> Hmm, ppc64le still has some repo problems it seems. "ERROR: ffmpeg-dev-4.4-r0: package mentioned in index not found (try 'apk update')"
2021-06-08 13:43:11 <PureTryOut> Great... armv7 404'd on 2 package sources, but they completed fine on other architectures. I can also download from that URL locally. Can we just ignore that arch?
2021-06-08 13:45:10 <ncopa> ngortheone: what arch do you build for?
2021-06-08 13:45:47 <ncopa> you install the dependencies listed there for the arch you build for
2021-06-08 13:46:23 <PureTryOut> ncopa: they mentioned the PBP (Pinebook Pro) so aarch64
2021-06-08 13:46:38 <ncopa> ngortheone: for x86_64 for example: apk add abuild apk-tools alpine-conf busybox fakeroot xorriso rsync openssh-client squashfs-tools acct mkinitfs mtools syslinux mtools grub-efi
2021-06-08 13:47:11 <ngortheone> ncopa: pinebookpro, which is aarch64 I believe
2021-06-08 13:47:38 <ngortheone> I head there are u-boot related issues
2021-06-08 13:48:24 <ncopa> ok so its the aarch64 deps: apk add abuild apk-tools alpine-conf busybox fakeroot xorriso rsync openssh-client squashfs-tools acct mkinitfs mtools grub-efi
2021-06-08 13:48:26 <mps> eh, this reminds me, ncopa would you make armv7 -virt iso with 3.14 release
2021-06-08 13:49:11 <ncopa> ngortheone: then you do: sh scripts/mkimage.sh --repository $packages/main --yaml --tag "$release" --outdir $releasedir 
2021-06-08 13:50:09 <ngortheone> oh, so does mkimage.sh take packages that are already installed on the system?
2021-06-08 13:50:16 <mps> btw, when will pine send me one PBP to make alpine working on it 'out-of-the-box' ;)
2021-06-08 13:50:34 <ncopa> where $packages is the repository where you want get your packages from  (eg https://dl-cdn.alpinelinux.org/alpine/v3.14), $release is the version to be used in the created files, and $releasedir is the targetdirectory where the release files are to be stored
2021-06-08 13:50:55 <ngortheone> mps: pine64 announced that production of PBP will stop soon, so if you didn't order one already chances are you wont't get one
2021-06-08 13:51:01 <ncopa> ngortheone: it gets the packages from the repository specified with --repository
2021-06-08 13:51:25 <ncopa> it can be a local repository ($HOME/packages/main) or remote
2021-06-08 13:51:44 <mps> ngortheone: I don't need PBP for my usage, just to make alpine work on it
2021-06-08 13:51:47 <ncopa> mps: yeah we should  do armv7 virt iso
2021-06-08 13:52:08 <ngortheone> ncopa: so If I need a modified kernel or u-boot - I need to build those packages first and have them in a local repo first, right?
2021-06-08 13:52:10 <ncopa> im currently fighting openssh APKBUILD to clean up the PAM support
2021-06-08 13:52:14 <mps> I have two aarm64 chromebooks where I run alpine for long time
2021-06-08 13:52:29 <ncopa> ngortheone: yes
2021-06-08 13:52:40 <ncopa> iirc think you can specify multiple repos
2021-06-08 13:53:06 <ncopa> but i dont remember if it was via multiple --repository or via --extra-repositories or similar
2021-06-08 13:53:07 <mps> ngortheone: https://arvanta.net/alpine/install-alpine-on-acer-r13-chromebook/
2021-06-08 13:53:15 <ngortheone> how does it resolve priorities? what if I have same package name in both repos?
2021-06-08 13:53:21 <ncopa> im cleaning up the openssh APKBUILD. its a mess
2021-06-08 13:53:32 <mps> that is how to install alpine on arm64 chromebook (one of them)
2021-06-08 13:53:47 <ngortheone> mps: thanks. I will take a look
2021-06-08 13:54:06 <ncopa> then i think its up to apk to resolve it. i think it takes the one with highest version first and if the version is equal its random
2021-06-08 13:55:27 <mps> ncopa: I think I should make changes for armv7 -lts -virt to use more RAM and virtio-net
2021-06-08 13:55:52 <ngortheone> what is the output of mkimage.sh ? is it going to be an img file that I can just dd onto sd card?
2021-06-08 13:56:34 <ngortheone> is it smart enough to know that uboot needs to live on 64th sector... and stuff like that?
2021-06-08 13:56:39 <mps> ncopa: are you against this idea
2021-06-08 13:57:26 <ncopa> mps: what do you mean "use more RAM"? why would you make it use more ram?
2021-06-08 13:58:18 <mps> when run in qemu, current -lts -virt armv7 can use max 1GB, iirc
2021-06-08 14:00:36 <ncopa> ok? why so?
2021-06-08 14:00:43 <ncopa> sounds like we need bump that indeed
2021-06-08 14:01:23 <mps> yes, I tested this few months ago on linux-edge
2021-06-08 14:02:09 <mps> and can give linux-edge-virt 6GB ram (on 8GB machine)
2021-06-08 14:02:19 <mps> armv7 virt, I mean
2021-06-08 14:05:56 <mps> CONFIG_ARM_LPAE=y and CONFIG_HIGHMEM=y are options to set
2021-06-08 14:08:32 <ncopa> sounds good. please create an issue with label:kernel
2021-06-08 14:08:56 <mps> re PBP, what we need is/are responsive user/tester to try and report back to us problems and success
2021-06-08 14:09:36 <mps> it would be easier for me to just push changes
2021-06-08 14:10:07 <mps> if you not against, ofc
2021-06-08 14:11:36 <mps> (lunch time is)
2021-06-08 14:13:19 <ncopa> ok
2021-06-08 14:13:22 <ncopa> better for me
2021-06-08 14:13:55 <PureTryOut> ncopa: !21376 is ready. 2 arches failed CI: ppc64le because of ffmpeg-dev missing in the binary repo and armv7 because of 404'ing on 2 package sources (but those sources download fine locally and on other arches)
2021-06-08 14:15:29 <ncopa> ok. sorry i dont have time to try fix it
2021-06-08 14:15:55 <minimal> ncopa: you're sorting out the lack of dependancy-conflict between openssh-server and openssh-server-pam?
2021-06-08 14:15:57 <PureTryOut> Well armv7 doesn't need fixing I think. ppc64le just needs a ffmpeg rebuild I think
2021-06-08 14:16:09 <ncopa> minimal: thats what im working on
2021-06-08 14:16:18 <minimal> cool
2021-06-08 14:16:56 <Hello71> ngortheone: it's all in aports/scripts, so you can check yourself what it does
2021-06-08 14:25:40 <mps> I hope openssh will not depend on pam by default
2021-06-08 14:27:32 <PureTryOut> Can we trigger a rebuild of ffmpeg on ppc64le only without bumping the pkgrel? Or do we have to bump it for all to fix one arch?
2021-06-08 14:28:10 <ikke> yes
2021-06-08 14:28:18 <ikke> we cannot rebuild just on one arch
2021-06-08 14:30:17 <PureTryOut> Ok then I'll just issue a pkgrel bump
2021-06-08 14:30:27 <ikke> Hold on a sec
2021-06-08 14:30:53 <PureTryOut> Actually, https://dl-cdn.alpinelinux.org does have that package for ppc64le on edge
2021-06-08 14:32:35 <ikke> The index mentions ffmpeg-dev-4.4-r1
2021-06-08 14:33:06 <ikke> Could it be the fastly issue we had earlier?
2021-06-08 14:33:17 <PureTryOut> Maybe, if that is used 
2021-06-08 14:33:23 <PureTryOut> As that version is definitely there
2021-06-08 14:33:40 <ikke> the docker images use dl-cdn, which is fastly
2021-06-08 14:33:57 <ikke> Your error message said -r0
2021-06-08 14:34:03 <PureTryOut> Oh, huh
2021-06-08 14:34:03 <ikke> so maybe it was an older APKINDEX
2021-06-08 14:34:09 <PureTryOut> So an outdated APKINDEX then
2021-06-08 14:35:12 <ikke> hmm
2021-06-08 14:35:19 <ikke> it still mentions r0 on fastly
2021-06-08 14:36:11 <ikke> hmm, also on master
2021-06-08 14:36:15 <PureTryOut> Well, has nothing to do with my MR at least 😃
2021-06-08 14:36:18 <ikke> nope
2021-06-08 14:36:25 <ikke> so it's not a cdn issue
2021-06-08 14:36:40 <ikke> On the builder, it's -r1
2021-06-08 14:37:12 <PureTryOut> Yeah I see it in APKINDEX as well, somehow still mentions -r0
2021-06-08 14:37:35 <jordbaer> hi... the "nodejs" package has a nasty timezone bug. should I send a mail to report the bug?
2021-06-08 14:37:51 <ikke> jordbaer: preferably an issue on gitlab.alpinelinux.org
2021-06-08 14:38:00 <jordbaer> okay
2021-06-08 14:57:17 <PureTryOut> ikke: should we still bump the pkgrel?
2021-06-08 14:59:15 <ikke> PureTryOut: I think next time the builder uploads community, it should be fixed
2021-06-08 15:02:14 <PureTryOut> Ok good. In that case fine with me merging it ncopa?
2021-06-08 15:03:50 <jordbaer> ikke, the only place, where the system's timezone is set, is /etc/localtime?
2021-06-08 15:04:58 <ncopa> jordbær: https://wiki.musl-libc.org/environment-variables.html#%3Ccode%3ETZ%3C/code%3E
2021-06-08 15:05:36 <ncopa> i think /etc/localtime is supported too
2021-06-08 15:05:39 <Hello71> localtime or TZ
2021-06-08 15:06:57 <jordbaer> TZ doesn't work always. TZ=CET fails, TZ=Europe/Berlin works... so the bug maybe in nodejs or in the timezone database...
2021-06-08 15:09:27 <jordbaer> setting /etc/localtime to Europe/Berlin works, too... "CET" seems to be the bug... so I shouldn't blame the nodejs package.
2021-06-08 15:11:39 <ikke> What sets it to CET?
2021-06-08 15:12:30 <jordbaer> yes. "TZ=CET date" = 15:11 "TZ=Europe/Berlin date" = 17:11
2021-06-08 15:12:50 <jordbaer> set to CET with setup-timezone. doesn't CET mean Central European Time? :)
2021-06-08 15:13:57 <jordbaer> "TZ=EST date" also returns 15:13
2021-06-08 15:14:06 <ncopa> indeed
2021-06-08 15:14:15 <jordbaer> "TZ=EST5EDT date" is correct
2021-06-08 15:14:52 <ncopa> might be worth report to musl devs, in #musl on libera.chat
2021-06-08 15:15:13 <ikke> CET is wintertime
2021-06-08 15:15:16 <jordbaer> I think the bug is in the data files of /usr/share/zoneinfo/*
2021-06-08 15:15:17 <ikke> CEST is summertime
2021-06-08 15:15:25 <ikke> Note sure if the distinction is made
2021-06-08 15:15:28 <ikke> Not*
2021-06-08 15:15:32 <jordbaer> CET is still wrong, CET should be 16:15
2021-06-08 15:15:56 <ikke> I guess it's not recognized and it shows UTC?
2021-06-08 15:16:04 <jordbaer> CET and CEST give 15:15 instead of 16:15 and 17:15
2021-06-08 15:16:13 <ikke> yeah, so just UTC 
2021-06-08 15:16:28 <jordbaer> could be that the musl library doesn't accept short names
2021-06-08 15:16:29 <ikke> try something random
2021-06-08 15:17:14 <jordbaer> every timezone with xxx/xxx works, e.g. Europe/Berlin and Australia/Adelaide
2021-06-08 15:17:46 <jordbaer> EST5EDT works too, but EST doesn't
2021-06-08 15:17:58 <jordbaer> okay, I download the musl source now and verify this
2021-06-08 15:23:44 <jordbaer> strace shows, that no timezone file is loaded when I set the TZ to CET. seems to be a bug in musl
2021-06-08 15:25:52 <Hello71> it is a bug, but you shouldn't use EST anyways
2021-06-08 15:27:23 <jordbaer> I never use EST :-) I use CET :)
2021-06-08 15:27:34 <jordbaer> but all three-letter-timezones are bugged
2021-06-08 15:27:53 <Hello71> or CET, or CEST, or any of those
2021-06-08 15:28:22 <jordbaer> on macos CET and EST works.
2021-06-08 15:28:35 <jordbaer> okay, I shouldn't use that there, too :)
2021-06-08 15:29:23 <jordbaer> but this is a musl bug, so it doesn't belong to this channel :)
2021-06-08 15:30:05 <Hello71> if you want to totally ignore DST then use TZ=EST-5
2021-06-08 15:30:16 <Hello71> but that's dumb
2021-06-08 15:30:38 <Hello71> if you don't want to care about time zones, use UTC, if you want to localize, then do it properly
2021-06-08 15:31:07 <jordbaer> CET should be UTC+1, but musl ignores CET and returns UTC+0, the default
2021-06-08 15:32:16 <Habbie> (in summer, CET should be UTC+2 and call itself CEST, but that's besides your point)
2021-06-08 15:32:17 <Hello71> there was a misunderstanding that POSIX requires TZ=CET to mean "CET is a time zone which is 0 hours ahead of UTC"
2021-06-08 15:32:40 <Hello71> but again, that's broken anyways for half the year
2021-06-08 15:33:15 <jordbaer> fyi: "TZ=/usr/share/zoneinfo/CET date" works :)
2021-06-08 15:33:20 <Hello71> as i explained, if you want it to be broken, you can use TZ=CET1 or TZ=CET+1, or TZ=:CET
2021-06-08 15:33:26 <Hello71> or TZ=/usr/share/zoneinfo/CET
2021-06-08 15:33:34 <jordbaer> "TZ=/usr/share/zoneinfo/CET date" = 17:33   "TZ=CET date" = 15:33
2021-06-08 15:33:40 <Hello71> actually i think the latter two of these might have DST?
2021-06-08 15:34:48 <Hello71> yes, i am aware how musl works, you don't have to explain it for the fourth time
2021-06-08 15:34:48 <jordbaer> it's not about having DST or not. It's about musl loading the apropriate file from /usr/share/zoneinfo or not
2021-06-08 15:35:07 <Hello71> as i have explained repeatedly, 
2021-06-08 15:35:10 <Hello71> 15:32 <Hello71> there was a misunderstanding that POSIX requires TZ=CET to mean "CET is a time zone which is 0 hours ahead of UTC"
2021-06-08 15:35:53 <Hello71> not all values of TZ mean to load the specified file from /usr/share/zoneinfo
2021-06-08 15:36:03 <Hello71> although that is the normal usage
2021-06-08 15:37:59 <jordbaer> seems that musl only loads, if there is a slash in TZ
2021-06-08 15:40:36 <jordbaer> but now for the alpine part: if I start setup-timezone, and type "?", I see a list of "valid" timezones. and if I use one the non-posix timezones (e.g. CET) i'm fucked.
2021-06-08 15:59:02 <Hello71> kind of unfortunate
2021-06-08 15:59:29 <PureTryOut> ncopa: if you are fine with it then I'll merge the Plasma 5.22 MR
2021-06-08 15:59:39 <Hello71> i guess what show_tz_list should do is */* UTC
2021-06-08 16:00:00 <Hello71> since the root directory ones are basically all wrong
2021-06-08 16:10:12 <ncopa> PureTryOut: if everything is green, then go ahead
2021-06-08 16:11:31 <Hello71> honestly i feel we should just invoke tzselect
2021-06-08 16:11:55 <PureTryOut> ncopa: thanks!
2021-06-08 16:16:02 <Hello71> seems like setup-timezone was created in 2011, tzselect not until 2012
2021-06-08 16:17:08 <ncopa> that might explain it :)
2021-06-08 16:18:37 <Hello71> also it allows the user to enter a POSIX TZ value, but i think we probably only want to allow a /etc/localtime
2021-06-08 16:19:02 <Hello71> jordbaer: actually, it should work fine as long as you actually use setup-timezone?
2021-06-08 16:19:23 <Hello71> it only doesn't work if you run setup-timezone, then ?, then copy and paste the value to export TZ
2021-06-08 16:19:33 <[[sroracle]]> there is a thread on musl ML about jordbaer's problem i believe
2021-06-08 16:19:54 <[[sroracle]]> i think dalias and nmeum were working on patches for it
2021-06-08 16:20:26 <[[sroracle]]> https://www.openwall.com/lists/musl/2021/06/05/5
2021-06-08 16:20:30 <dalias> yes, i'll look at it again soon :)
2021-06-08 16:20:41 <dalias> sorry for getting distracted by other work and play :-p
2021-06-08 16:20:56 <[[sroracle]]> :)
2021-06-08 16:23:00 <mps> dalias: I like this excuse, '... and play'
2021-06-08 16:37:08 <mps> did anyone ever managed to boot linux-virt armv7 in qemu?
2021-06-08 16:41:23 <dalias> :)
2021-06-08 16:46:54 <jordbaer> hello71, there is not cut&paste, setup-timezone asks me for a value, and entering CET leads to the problem. only posix-conformant zones should be accepted by setup-timezone if the name isn't a relative path
2021-06-08 16:47:36 <mps> in my test linux-virt can't boot in qemu
2021-06-08 16:47:36 <Hello71> ln -s /usr/share/zoneinfo/CET /etc/localtime doesn't work?
2021-06-08 16:47:56 <mps> in my test linux-virt armv7 can't boot in qemu
2021-06-08 16:48:40 <jordbaer> setup-timezone does a ln -s /etc/zoneinfo/CET /etc/localtime, and no, that doesn't work
2021-06-08 16:48:57 <jordbaer> the string after "/zoneinfo/" needs to be a relative path
2021-06-08 16:49:45 <dalias> :CET should work, no?
2021-06-08 16:51:18 <jordbaer> well, end of my working hours... i'll be back tomorrow :)
2021-06-08 16:56:32 <liske> can we get !22066 merged? I would like to get it into 3.14 if it's not to late
2021-06-08 16:56:57 <ikke> liske: it's in testing
2021-06-08 16:57:09 <ikke> that would not be part of 3.14 anyway
2021-06-08 17:01:25 <liske> ikke: thanks, I was not yet statisfied with the packaging and like to test it before moving it to community ;)
2021-06-08 17:01:48 <ikke> right
2021-06-08 17:22:19 <nmeum> dalias: TZ=:CET works, yes
2021-06-08 17:33:11 <mps> ncopa: https://tpaste.us/E1V6, this is linux-lts virt armv7 built with config-edge-virt.armv7 from linux-edge
2021-06-08 17:34:26 <mps> for some reason qemu-system-arm with '-machine virt' doesn't support more than 8 cpus
2021-06-08 17:34:46 <mps> clandmeter: ikke: ^
2021-06-08 17:35:06 <mps> probably you two are also interested in this
2021-06-08 17:35:30 <ikke> for now, we settled in running everything on aarch64 vms
2021-06-08 17:37:46 <mps> I know, but wanted to tell also to you 
2021-06-08 18:15:49 <liske> there is something weird on pkgs.alpinelinux.org - irtt got flagged (0.9.1-r2 is currently building) and the flagged view claims that the new version is "Samsung galaxy a12" ?!
2021-06-08 18:16:47 <Misthios> Nice version
2021-06-08 18:17:21 <Misthios> Itsnt that just the message from the one that flagged it?
2021-06-08 18:17:59 <liske> there is no such version (upstream): https://github.com/heistp/irtt/releases
2021-06-08 18:18:49 <liske> the 0.9.1-r1 are *not* flagged but the 0.9.1-r2 rebuilds
2021-06-08 18:19:08 <Misthios> I mean if you flag a package you can say the new version so that might explain it, idk why  someone would put a phone name there and the weird message
2021-06-08 18:21:00 <liske> I don't know - the flagged message is "Rooted and apk"
2021-06-08 18:23:16 <Misthios> did the one that flagged it leave his mail?
2021-06-08 18:26:19 <mps> https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20210608
2021-06-08 18:26:38 <mps> if someone have time
2021-06-08 18:29:38 <liske> mps: I can create a MR, is there anything special on ucode packages?
2021-06-08 18:30:35 <mps> not much, afaik
2021-06-08 18:31:50 <mps> it is simple pkg to build
2021-06-08 18:34:06 <liske> would be good to have it for testing rc2 (extened.iso)
2021-06-08 18:34:32 <ikke> Are the ucode packages part of the iso?
2021-06-08 18:35:02 <liske> yes, I did a MR before 3.13 ;-)
2021-06-08 18:35:05 <ikke> ah
2021-06-08 18:35:07 <liske> !22138
2021-06-08 19:03:23 <Hello71> liske: probably spambot or spam meatpuppet
2021-06-08 19:03:30 <Hello71> spam spam spam spam spam
2021-06-08 19:04:10 <Hello71> anything with a <form> gets spammed unfortunately
2021-06-08 20:03:20 <liske> kk
2021-06-08 20:40:31 <ollieparanoid> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22117 <- this CVE was not merged because the repo was modified while it should get merged. can somebody merge it now?
2021-06-08 20:40:35 <ollieparanoid> *cve fix
2021-06-08 20:41:32 <Danct12> i'd like to backport a patch to lxc
2021-06-08 20:43:11 <mps> !22117
2021-06-08 20:43:56 <ikke> ollieparanoid: and due to the fastly outage this afternoon :P
2021-06-08 20:44:47 <ollieparanoid> ah, now I know where those image build errors come from :P
2021-06-08 20:45:11 <ikke> merged
2021-06-08 20:45:22 <ollieparanoid> thanks!
2021-06-08 21:00:22 <Danct12> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22143
2021-06-08 21:01:04 <Danct12> can anyone look into this? this fixes containers that uses read-only rootfs
2021-06-08 21:06:51 <proycon> can somebody also merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21861 ? we need it for sxmo and it should be all ready for merge now
2021-06-08 21:07:43 <proycon> !21861
2021-06-08 22:34:20 <Ariadne> proycon: done
2021-06-08 22:36:09 <craftyguy> Cogitri: I think !21893 is ready to be merged now. the issue was basically in pmOS, and has been worked around/corrected there
2021-06-08 22:39:24 <Cogitri> Alright, I'll try to take a look at it tomorrow
2021-06-08 22:40:22 <proycon> Ariadne: thnks!
2021-06-08 22:43:39 <craftyguy> Cogitri: thanks!
2021-06-09 06:59:09 <clandmeter> \o/
2021-06-09 06:59:18 <clandmeter> riscv64 main completed :)
2021-06-09 07:01:26 <ikke> w00t
2021-06-09 07:08:04 <Habbie> yay!
2021-06-09 07:19:18 <ncopa> good morning!
2021-06-09 07:19:31 <ncopa> congrats with the riscv64
2021-06-09 07:19:38 <ncopa> did anyone test the alpine 3.14.0_rc1?
2021-06-09 07:20:29 <ikke> I did test it in a qemu vm
2021-06-09 07:20:33 <ikke> on x86_64
2021-06-09 07:23:30 <clandmeter> i did
2021-06-09 07:23:50 <clandmeter> well kind of, its the riscv64 builder :)
2021-06-09 07:30:09 <PureTryOut> Congrats with riscv64 🎉
2021-06-09 07:32:55 <fcolista> c00l!
2021-06-09 07:33:33 <Ariadne> it should be possible to get some 20-core riscv64 SoCs at end of year from huawei 
2021-06-09 07:34:06 <ikke> That would be amazing
2021-06-09 07:34:28 <clandmeter> and we do not give them access, its already included.
2021-06-09 07:34:45 <ikke> ;-)
2021-06-09 07:40:48 <Ariadne> heh i doubt it :)
2021-06-09 08:00:43 <mps> what's happens? channel goes more and more to (geo)political debates :P
2021-06-09 08:12:57 <Ariadne> i think it was a joke :p
2021-06-09 08:13:06 <Ariadne> our previous arm server was huawei cpus
2021-06-09 08:21:02 <mps> you didn't noticed ':P' at the end of msg
2021-06-09 08:21:38 <mps> yes, my dev lxcs were on huawei machines
2021-06-09 09:01:23 <ncopa> im continuing with the openssh mess today
2021-06-09 09:02:00 <ncopa> i started with 3 different flavors, but i wonder if we should only have two: one simple (default) and one with both PAM/krb5
2021-06-09 09:02:16 <Cogitri> Sounds like a better idea
2021-06-09 09:02:18 <ncopa> so if you only need pam, you'd get the krb5 build
2021-06-09 09:03:23 <ncopa> im also fixining so that it works with BOOTSTRAP=1, which disables the PAM/krb5/libedit
2021-06-09 09:04:42 <mps> separate all 3
2021-06-09 09:05:27 <mps> i.e. 'normal', with krb, with pam
2021-06-09 09:06:31 <ncopa> what if you want krb with pa, fallback?
2021-06-09 09:06:39 <ncopa> s/pa,/pam,/
2021-06-09 09:06:39 <alpine-meetbot> ncopa meant to say: what if you want krb with pam, fallback?
2021-06-09 09:07:05 <ncopa> im thinking on ly having two flavors makes it simpler for maintenance
2021-06-09 09:08:00 <mps> but it could be used with krb and not need for pam
2021-06-09 09:08:17 <Cogitri> I doubt too many people will actually care about that though
2021-06-09 09:08:34 <Cogitri> And having too many variants is probably confusing to users
2021-06-09 09:08:47 <mps> well, in this world are a lot of different peoples
2021-06-09 09:09:20 <ncopa> i think the more common case would be that you'd want PAM support without krb5
2021-06-09 09:09:32 <ncopa> and then you'd get the krb5 libs pulled in
2021-06-09 09:10:26 <mps> yes if the maintenance is problem
2021-06-09 09:10:55 <mps> if the 'good' is goal then there should be 3 variants
2021-06-09 09:11:04 <ncopa> looking at the current APKBUILD i'd say that maintenance definitively is a problem
2021-06-09 09:11:08 <ikke> It would be more 
2021-06-09 09:11:18 <ikke> Pam + krb
2021-06-09 09:11:47 <mps> yes, I looked at it and didn't wanted to try to fix it, or add more mess
2021-06-09 09:11:48 <ncopa> we could also do: without PAM and krb, with PAM, with PAM+krb
2021-06-09 09:12:39 <ikke> They are not plugins that you can optionally load 
2021-06-09 09:12:57 <mps> in heterogenous environment krb is more often used than pam
2021-06-09 09:14:13 <mps> but, left it for 3.15, imo
2021-06-09 09:15:38 <ikke> I suspect more people will complain due to lack of PAM then lack of krb
2021-06-09 09:16:53 <mps> if I ever make big company I know who will be 'customer support' manager in my company :)
2021-06-09 09:17:50 <ikke> :D
2021-06-09 09:30:56 <mps> interesting change in kernel 5.13 for x86/64 https://lore.kernel.org/lkml/162318455123.29796.8536472725477120608.tip-bot2@tip-bot2/
2021-06-09 09:38:14 <ncopa> 3 different flavors will also make the sshd init.d script more complicated
2021-06-09 09:46:51 <Ariadne> hmmph
2021-06-09 09:46:58 <Ariadne> my HE circuit had a fuckywucky
2021-06-09 09:48:45 <Habbie> fuckywucky :D
2021-06-09 09:52:40 <MY-R> does grub 2.06 will be part of Alpine 3.14? :P
2021-06-09 09:52:47 <ncopa> yes
2021-06-09 09:54:01 <MY-R> niiiice, Im wondering if luks2 will be working, maybe I will check later in vm
2021-06-09 09:55:05 <ncopa> probably not
2021-06-09 09:56:22 <MY-R> nlplug-findfs need some extra love?
2021-06-09 09:56:22 <Ariadne> oh it’s the transport circuit.  fun
2021-06-09 09:56:36 <ncopa> MY-R: probably
2021-06-09 09:56:59 <MY-R> ook
2021-06-09 09:59:48 <ncopa> provides_priority=0, vs provides_priority=1, which will apk pick?
2021-06-09 09:59:58 <ikke> :D
2021-06-09 10:00:10 <ikke> I remember that it was treated as a version
2021-06-09 10:00:22 <ikke> so it should pick 1
2021-06-09 10:01:25 <ncopa> that what i thought too, but it didnt
2021-06-09 10:01:57 <ncopa> because it is `provider_priority` not `provides_priority`
2021-06-09 10:02:01 <ikke> aha :D
2021-06-09 10:02:03 <ikke> yeah
2021-06-09 10:03:25 <ikke> I wonder if I should test 3.14-rc1 on the x86_64 CI host, and check if the lvm root partition issue has been solved
2021-06-09 10:03:42 <ncopa> speaking of nlplug-findfs, i think the most important thing for nlplug-findfs now is a unit test suite
2021-06-09 10:04:27 <clandmeter> ikke: usa5-dev1 is running 3.14
2021-06-09 10:04:34 <clandmeter> with lvm
2021-06-09 10:05:52 <ikke> it was usa7 that had the issue
2021-06-09 10:05:57 <ikke> while nld7 did not
2021-06-09 10:22:20 <nmeum> MY-R: hm? luks2 should work fine with nlplug-findfs
2021-06-09 10:22:49 <nmeum> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/commit/d6a68123b9cd3c751ee45a376b01d1b164c0ab5b
2021-06-09 10:22:54 <nmeum> I am using it with luks2 since that commit
2021-06-09 10:35:20 <MY-R> nmeum: hmm so I wil need to check, point is I wanna have just single fully encrypted partition (together with boot) that is why waited for grub 2.06 to support it
2021-06-09 10:40:00 <clandmeter> riscv64 is now "officially" on our mirrors :D
2021-06-09 10:40:01 <clandmeter> https://dl-cdn.alpinelinux.org/alpine/edge/main/riscv64/
2021-06-09 10:41:16 <nmeum> \o/
2021-06-09 10:41:52 <wej> \o/
2021-06-09 10:41:58 <MY-R> \o/
2021-06-09 10:42:07 <clandmeter> i put some comments here: https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10722
2021-06-09 10:44:02 <nmeum> packages are currently built for RV64gc, right?
2021-06-09 10:44:12 <ikke> gc?
2021-06-09 10:44:29 <nmeum> riscv is a modular architecture there are several extensions you can enable or disable
2021-06-09 10:44:35 <nmeum> s/extensions/modules/
2021-06-09 10:44:35 <alpine-meetbot> nmeum meant to say: riscv is a modular architecture there are several modules you can enable or disable
2021-06-09 10:44:37 <ikke> ah
2021-06-09 10:44:58 <ikke> there was some kerfuffle on lkml about that I guess
2021-06-09 10:47:32 <clandmeter> nmeum: its currently using gcc's default
2021-06-09 10:47:42 <clandmeter> i wonder if we should set it hard
2021-06-09 10:48:55 <clandmeter> should be -march=rv64gc -mabi=lp64d
2021-06-09 10:49:33 <nmeum> what is the gcc default?
2021-06-09 10:52:13 <clandmeter> i just mentioned 
2021-06-09 10:53:51 <nmeum> ah sorry I misread your message
2021-06-09 10:54:37 <clandmeter> hmm
2021-06-09 10:54:45 <clandmeter> looks like the builder deleted go again
2021-06-09 10:54:49 <nmeum> might make sense to hardcode it should probably also document the -march and -mabi somewhere so people know which modules are required
2021-06-09 10:54:55 <clandmeter> im not sure i understand the logic
2021-06-09 10:55:38 <clandmeter> ncopa: when does buildrepo delete packages? 
2021-06-09 10:56:02 <ncopa> after the repo is built
2021-06-09 10:56:13 <clandmeter> even if the pkg is failed?
2021-06-09 10:56:55 <ncopa> only if buildrepo thinks that the package should not be built
2021-06-09 10:57:39 <minimal> ncopa: the issue we found with openssh-server in conjunction with cloud-init is that if a user's account is locked (i.e. passwd -l) which should prevent password-based access but still allow SSH key-based access it turns out that OpenSSH only lets SSH logins via key work if PAM is also enabled (i.e you've installed openssh-server-pam and /etc/ssh/sshd_config has UsePAM=yes)
2021-06-09 10:59:02 <clandmeter> bummer, i need to boostrap go again :|
2021-06-09 10:59:16 <ncopa> backup?
2021-06-09 10:59:20 <ncopa> is it on a mirror?
2021-06-09 10:59:32 <clandmeter> seems i sycned it before
2021-06-09 10:59:37 <clandmeter> so its also missing on my old mirror
2021-06-09 10:59:39 <ncopa> ok :-/
2021-06-09 10:59:55 <clandmeter> i should have not added --delete-after :D
2021-06-09 11:00:41 <ncopa> minimal: i think that makes sense?
2021-06-09 11:01:05 <ncopa> i mean if an account is locked, i'd expect it to be locked, and not unlocked with ssh key
2021-06-09 11:01:41 <ncopa> with PAM on the other hand you can configure it so the 'lock' does not mean anything at all
2021-06-09 11:02:12 <minimal> ncopa: not really, passwd manpage states "Note that this does not disable the account. The user may still be able to login using another authentication token (e.g. an SSH key)"
2021-06-09 11:02:29 <ncopa> hum. ok
2021-06-09 11:02:35 <ncopa> so its a bug in sshd?
2021-06-09 11:02:38 <minimal> its just that openssh devs have decided that PAM also needs to be enabled in such a scenario for key access to work
2021-06-09 11:02:54 <minimal> it doesn't appear to be a bug but rather a conscious decisuion
2021-06-09 11:03:33 <ncopa> reference?
2021-06-09 11:04:23 <minimal> there's a specific check in the openssh code, I'll have to dig it out, mcrute found it when we were discussing his problems with his initial cloud-init enabled AMI
2021-06-09 11:09:11 <ncopa> my other question is, why lock the account instead of doing "PasswordAuthentication no"?
2021-06-09 11:09:52 <minimal> actually its mentioned in the sshd manpage: "If there is a requirement to disable password authentication for the account while allowing still public-key, then the passwd field should be set to something other than these values (eg ‘NP’ or ‘*NP*’ )"
2021-06-09 11:12:03 <minimal> ncopa: cloud-init lets you do various things with user accounts (e.g. set expiry time, add groups, etc). One of those is to lock accounts and its using standard Unix/Linux functionality to do so "passwd -l". Out of the box cloud-init is locking the default created user account.
2021-06-09 11:12:59 <minimal> "PasswordAuthentication no" prevents password access via SSH, locking an account prevents password access from anywhere (i.e. including console)
2021-06-09 11:17:23 <ncopa> ok, so the intention is to disable the password login via the console, but allow via ssh with ssh key
2021-06-09 11:18:51 <minimal> ncopa: found it, https://github.com/openssh/openssh-portable/blob/master/auth.c#L135
2021-06-09 11:19:51 <minimal> if PAM is enabled then locked=0, otherwise line 155 triggers a failure to login message
2021-06-09 11:21:25 <minimal> basically openssh's usual idea of locked accounts is at odds with the general Unix/Linux concept of locked accounts but when PAM is enabled in openssh then it acts in accordance with "normal" practice
2021-06-09 11:22:17 <ikke> yay, standards. The more the merrier
2021-06-09 11:22:35 <minimal> ikke: as long as they're Vanilla :-)
2021-06-09 11:23:43 <mps> (in last time I see more and more nonsenses in computing)
2021-06-09 11:29:10 <clandmeter> ok golang is bootstrapped again
2021-06-09 11:29:17 <clandmeter> i hope it will not be deleted again
2021-06-09 11:55:13 <nmeum> we don't have CI for riscv64 yet, right?
2021-06-09 12:08:55 <clandmeter> nmeum: we kind of have
2021-06-09 12:09:01 <clandmeter> bit its a bit more complicated
2021-06-09 12:09:15 <clandmeter> the runner will pull images from docker hub
2021-06-09 12:09:21 <clandmeter> but those are not yet published
2021-06-09 12:09:45 <clandmeter> the idea is that we are going to have our own registry
2021-06-09 12:10:54 <clandmeter> nmeum: im talking with kunkku about adding multiarch support to rootbld so you could give it a try local with not too much hassle.
2021-06-09 12:11:06 <nmeum> I already setup my own chroot
2021-06-09 12:11:43 <nmeum> what I am wondering is: if I fix riscv stuff can I see if it also passes on the riscv gitlab ci and not just in my chroot environment?
2021-06-09 12:12:03 <clandmeter> atm no
2021-06-09 12:12:10 <nmeum> alright
2021-06-09 12:12:11 <clandmeter> but soon, yes we think so
2021-06-09 12:12:16 <nmeum> sweet
2021-06-09 12:12:37 <clandmeter> the runner is already running and registered on gitlab
2021-06-09 12:12:42 <clandmeter> it just need a little infra work
2021-06-09 12:22:19 <PureTryOut> <clandmeter "nmeum: im talking with kunkku ab"> Oh that'd be great
2021-06-09 13:37:34 <PureTryOut> ikke: APKINDEX of ppc64le most definitely updated (as the Plasma 5.22 MR got merged yesterday) but it still refers to ffmpeg* 4.4-r**0**
2021-06-09 13:39:29 <ikke> 😟
2021-06-09 13:39:45 <PureTryOut> I still have MR's failing on it 😢
2021-06-09 13:39:52 <PureTryOut> So I guess we need to bump pkgrel after all?
2021-06-09 13:40:29 <ikke> Well, we should try to find out what's going on
2021-06-09 15:00:02 <fcolista> quick question about "replaces". I'm going to install a new version of ipcalc. The name is the same, but the binary is totally different.
2021-06-09 15:00:16 <fcolista> Should I use replaces=ipcalc ?
2021-06-09 15:00:32 <fcolista> I don't think it makes sense
2021-06-09 15:00:43 <fcolista> but better to crosscheck first...
2021-06-09 15:01:29 <fcolista> binary is totally different means that is another software, with a different version 
2021-06-09 15:01:52 <fcolista> (bigger than before)
2021-06-09 15:02:04 <PureTryOut> Is it the same software source, just rewritten or something?
2021-06-09 15:02:10 <ncopa> what name is the same?
2021-06-09 15:02:24 <fcolista> no different source
2021-06-09 15:02:26 <fcolista> ipcalc
2021-06-09 15:02:28 <fcolista> the binary
2021-06-09 15:02:39 <fcolista> /usr/bin/ipcalc
2021-06-09 15:02:40 <afontain[m]> note replaces= would not be enough if I'm not mistaken
2021-06-09 15:02:54 <afontain[m]> but first is it the same interface?
2021-06-09 15:02:59 <PureTryOut> then yes you need replaces, but I also think provides in this case, assuming the binary does the same thing as the other one
2021-06-09 15:03:02 <fcolista> perhaps I shoudl put provides=ipcalc
2021-06-09 15:03:14 <ncopa> is it a new package name?
2021-06-09 15:03:16 <fcolista> PureTryOut, yeah, I was wondering the same.
2021-06-09 15:03:29 <fcolista> ncopa, no, the package name is the same
2021-06-09 15:03:31 <afontain[m]> if it dies the same thing, provides+replace indeed
2021-06-09 15:03:37 <afontain[m]> *does
2021-06-09 15:03:57 <ncopa> if package name is the same, then no provides/replaces are needed
2021-06-09 15:04:01 <Sheila> if the interface is the same, also provide a symlink in addition to provides+replaces
2021-06-09 15:04:20 <ncopa> apk will just see it as newer version and relpace whatever was in old package with the new package
2021-06-09 15:04:26 <Sheila> (e.g. rofi vs dmenu)
2021-06-09 15:04:39 <fcolista> ncopa, thanks. From apk persepctive yes, I was wondering from user perspective
2021-06-09 15:05:07 <fcolista> perhaps the user is expecting the "last one" software used with different arguments
2021-06-09 15:05:11 <ncopa> replaces/provides does not do anything from user perspective
2021-06-09 15:05:27 <fcolista> and it maybe will end up in breaking script based on the "old" ipcalc
2021-06-09 15:05:57 <ncopa> normally a major version number indicate breaking changes
2021-06-09 15:06:14 <ncopa> from ipcalc 1.x -> 2.x
2021-06-09 15:06:42 <fcolista> that was from 0.4.1 > 1.0.1, so yes is a major version
2021-06-09 15:06:57 <ncopa> i'd say its acceptable
2021-06-09 15:07:14 <ncopa> can not be pushed to stable branch though, but for edge its ok
2021-06-09 15:07:22 <fcolista> sure thing
2021-06-09 15:07:34 <ncopa> we do reserve the right to push breaking changes to edge, even if we try avoid it
2021-06-09 15:08:57 <ncopa> replaces is used when there is a new package (with a new package name) that provides same file as previous package
2021-06-09 15:09:15 <ncopa> to tell apk that it is ok that it overwrites the file owned by the other package
2021-06-09 15:10:32 <ncopa> so for example, if the ipcalc would move into coreutils, and users should use coreutils instead of the `ipcalc` package
2021-06-09 15:11:26 <ncopa> without replaces=ipcalc you would get an error when upgrading coreutils, saying that coreutils tried to overwrite a file owned by ipcalc package
2021-06-09 15:12:00 <mps> name pkg as 'ipcalc-on-steriods' and problems solveeeeeed
2021-06-09 15:12:06 <mps> apk*
2021-06-09 15:12:12 <ncopa> with replaces=ipcalc in coreutils, apk would now that this is intentionally, and that coreutils takes over ownership
2021-06-09 15:12:37 <ncopa> as long as different packages has the same file, you would still have the problem
2021-06-09 15:13:05 <ncopa> you could rename the /usr/bin/ipcalc to /usr/bin/ipcalc-on-steroids to avoid the conflict
2021-06-09 15:13:59 <ncopa> i just pushed a refactored openssh. would be nice if someone using PAM can help test that it does not break anything
2021-06-09 15:14:27 <mps> pam breaks everything anyway :)
2021-06-09 15:15:02 <mps> hmm 'breaks' (to quote word)
2021-06-09 15:15:10 <ncopa> oh... I think it actually might break things... if you have openssh-server-pam installed but 'UsePAM no'  in config
2021-06-09 15:15:29 <mps> ncopa: jk
2021-06-09 15:15:54 <mps> I don't use pam, but from debian experience I always 'hated' it
2021-06-09 15:16:05 <ncopa> mps: you now have 3 flavors: openssh-server, openssh-server-pam and openssh-server-krb (which also has PAM support)
2021-06-09 15:16:16 <ncopa> yeah, im no big fan of pam either
2021-06-09 15:16:27 <ncopa> fortunately you can disable it in the config
2021-06-09 15:17:15 <ncopa> there are also 2 flavors of openssh-client: openssh-client-krb5 and openssh-client-default
2021-06-09 15:17:30 <mps> heh, you did best possible for now
2021-06-09 15:17:37 <ncopa> i hope so
2021-06-09 15:17:48 <ncopa> i hope it does not come back and bite me :)
2021-06-09 15:17:59 <ncopa> spent two days on it
2021-06-09 15:18:02 <mps> could ikke or maxice8 put this in release notes
2021-06-09 15:18:03 <ncopa> which is too much
2021-06-09 15:18:14 <ncopa> yes. good point
2021-06-09 15:18:35 <mps> ehm, we all do useless works from time to time, so enjoy :)
2021-06-09 15:19:08 <ncopa> hum i think ipcalc broke oneverything
2021-06-09 15:19:54 <fcolista> yes i've a patch
2021-06-09 15:20:04 <ncopa> pushit
2021-06-09 15:20:19 <fcolista> looks that it breaks on 3 different places
2021-06-09 15:20:45 <ncopa> pushit so i can tag rc2
2021-06-09 15:21:22 <fcolista> right now
2021-06-09 15:21:44 <mps> wait, I forgot sshfs merge
2021-06-09 15:22:43 <mps> rebasing, will be in minute
2021-06-09 15:23:11 <fcolista> ok ipcalc done
2021-06-09 15:23:22 <mps> done sshfs
2021-06-09 15:24:20 <fcolista> k
2021-06-09 15:34:12 <ncopa> whats 440c0993ebe6bbcf46e2f733ce3eaebc8eb1d87c
2021-06-09 15:34:33 <ncopa> commit message is weird
2021-06-09 15:36:39 <mps> heh, interesting :-})
2021-06-09 15:36:40 <ikke> ttps://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22087
2021-06-09 15:36:45 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22087
2021-06-09 15:36:53 <ikke>  Natanael Copa @ncopa merged 2 days ago
2021-06-09 15:36:55 <ikke> :P
2021-06-09 15:37:05 <mps> !22087
2021-06-09 15:37:43 <ncopa> i think we should add a commit message linter to the CI, so it complains about weird commit messages
2021-06-09 15:37:48 <ikke> ahuh
2021-06-09 15:38:13 <ncopa> pretty many changes since rc1
2021-06-09 15:38:21 <mps> ikke will invent AI after 3.14 release ;)
2021-06-09 15:38:40 <ikke> I will create an mps AI
2021-06-09 15:38:51 <mps> :D
2021-06-09 15:39:08 <ncopa> rc2 tagged
2021-06-09 15:40:14 <mps> final release on monday?
2021-06-09 15:41:01 <ncopa> hopefully yes
2021-06-09 15:41:19 <mps> good
2021-06-09 15:41:53 <ncopa> disappointingly many pushes to testing repo
2021-06-09 15:42:15 <mps> those who not yet prepared wine bootles should do this on weekend
2021-06-09 16:19:45 <ikke> PureTryOut: seems like mips64 is also still on r0
2021-06-09 16:20:02 <ikke> ah, but that's because the builders are awol
2021-06-09 16:22:20 <ikke> the APKINDEX is 4 days old
2021-06-09 16:22:22 <ikke> on master
2021-06-09 17:25:28 <Jenkler> Checking for C library stemmer... no does not work on edge 
2021-06-09 17:25:46 <Jenkler> but 3.13 is fine. I guess to new version maybe 
2021-06-09 17:26:38 <Jenkler> Tried to install all pkg in edge with stemmer but cant find it  ;)
2021-06-09 17:32:23 <Jenkler> Maybe best to skip use-system stemmer. Seams broken anyway ;)
2021-06-09 18:09:46 <Jenkler> ikke, Is there something else I need todo for this https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22179 ?
2021-06-09 18:10:00 <ikke> having patience :)
2021-06-09 18:10:10 <Jenkler> ikke, ahh ;) 
2021-06-09 18:10:34 <Jenkler> I am trying to solve the mongodb issue now.
2021-06-09 18:31:48 <PureTryOut> ikke: so for some reason the builders are updating the packages, just not the APKBUILD?
2021-06-09 18:39:29 <clandmeter> looks like this is the list of config.sub,guess that needs to be updated (if not applied yet in apkbuild) for riscv (community) https://tpaste.us/8j1O 
2021-06-09 18:40:01 <clandmeter> if anybody feels bored :)
2021-06-09 18:42:25 <PureTryOut> What does "needs update" mean exactly?
2021-06-09 18:44:02 <Jenkler> ncopa, Thanks for approval ;) I have fixed https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22178 also. Compiles fine in both edge and 3.13.
2021-06-09 18:44:45 <mps> Jenkler: 'upgrade' not 'update' in commit msg
2021-06-09 18:45:48 <ikke> PureTryOut: it appears so, trying to figure out what is happening
2021-06-09 18:45:49 <mps> COMMITSTYLE.md
2021-06-09 18:47:07 <PureTryOut> clandmeter: I can update a few of those packages (at least the ones I maintain or find important) but I would need to know what to change
2021-06-09 18:47:51 <ikke> PureTryOut: update_config_sub / update_config_guess in prepare()
2021-06-09 18:47:53 <Ariadne> PureTryOut: needs update_config_guess or whatever
2021-06-09 18:49:09 <PureTryOut> Ah, thanks
2021-06-09 18:49:18 <Jenkler> mps, ohh my bad :(
2021-06-09 18:49:56 <Jenkler> mps, is there some parser that looks for upgrade 
2021-06-09 18:50:07 <mps> Jenkler: ok for now :)
2021-06-09 18:50:36 <ikke> Jenkler: Yes, it's called developers :P
2021-06-09 18:50:44 <mps> there is githook made by maxice8 which cares about this
2021-06-09 18:50:54 <Jenkler> ikke, hehe 
2021-06-09 18:51:09 <mps> and what ikke says :)
2021-06-09 18:52:20 <maxice8> http://ix.io/3pnS  put in .git/hooks/prepare-commit-msg
2021-06-09 18:52:22 <Jenkler> so, when a pkg is approved in master then it will be awilable in edge after a while 
2021-06-09 18:53:03 <Jenkler> do i need to do anything to get it to 3.13 or is there some gracetime for that?
2021-06-09 18:53:04 <ikke> after it's merged, it will be picked up by the builders, and typically available on the repos with 30-60 minutes
2021-06-09 18:53:17 <ikke> Jenkler: No, this will not be available in 3.13
2021-06-09 18:53:42 <ikke> but, if it's in community, it will be part of 3.14
2021-06-09 18:53:43 <Jenkler> ikke, it will be updated with 3.14 
2021-06-09 18:53:47 <ikke> yes
2021-06-09 18:53:54 <Jenkler> ahh, nice 
2021-06-09 18:53:57 <maxice8> mongodb is in non-free
2021-06-09 18:54:14 <ikke> yes, but mongodb-tools not
2021-06-09 18:54:17 <Jenkler> yes, keeping that updated if someone else wants it 
2021-06-09 18:54:25 <maxice8> I see
2021-06-09 18:54:48 <Jenkler> I still do the job localy so why not share, sharing is caring ;P
2021-06-09 18:55:27 <ikke> yes, certainly
2021-06-09 18:55:40 <Jenkler> ikke, so its only bugs that we backport 
2021-06-09 18:55:51 <ikke> yes, bugs and securityfixes
2021-06-09 18:56:04 <ikke> we like to add bugs to stable branches :P
2021-06-09 18:56:18 <Jenkler> hehe 
2021-06-09 19:22:45 <clandmeter> PureTryOut: similar like db6a4c49a7add666ca6ada7ddeb0bb888375101b
2021-06-09 19:40:15 <PureTryOut> clandmeter: thanks, will use that example
2021-06-09 19:44:10 <liske> maxice8: thanks for the msg hook :)
2021-06-09 19:44:39 <maxice8> They live here: https://gitlab.com/maxice8/meltryllis/-/tree/master/alpinelinux
2021-06-09 19:46:38 <liske> 
ACTION feels like an idiot who has been typing it in manually until now

2021-06-09 19:49:52 <Jenkler> ncopa, sorry but needed to update my maintainer email (@leo asked). so, now is that done ;)
2021-06-09 20:06:11 <Ariadne> maxice8: can you be very careful with all of these pushes to ensure you don't push something breaking ABI please :)
2021-06-09 20:06:22 <Ariadne> maxice8: we are still in a freeze :)
2021-06-09 20:06:31 <maxice8> ack
2021-06-09 20:16:27 <maxice8> @liske pre-commit githook I have can check for that pkgrel mistake (may have false-positives in some situations like downgrade)
2021-06-09 20:17:01 <liske> oh, sounds good
2021-06-09 20:18:05 <liske> I got an error with the msg hook: .git/hooks/prepare-commit-msg: 11: community/py3-pyroute2/APKBUILD: Bad substitution
2021-06-09 20:19:15 <liske> the commit message had only the package prefix, the "upgrade to 0.5.19" part was missing
2021-06-09 20:29:28 <PureTryOut> Fixed up and modernized 9 packages for riscv64 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22193
2021-06-09 21:25:00 <Ariadne> PureTryOut: thanks
2021-06-09 21:40:51 <dalias> whats the rv64 status?
2021-06-09 21:41:06 <dalias> i'm about to try getting my beagle-v up and running
2021-06-10 02:03:23 <Ariadne> dalias: main is built, community is 54% complete
2021-06-10 02:04:26 <dalias> :)
2021-06-10 06:22:06 <ncopa> Good morning!
2021-06-10 06:26:25 <craftyguy> hi!
2021-06-10 06:26:43 <Danct12> hello ncopa
2021-06-10 06:29:56 <Danct12> can you look into !22143 ?
2021-06-10 06:30:12 <Danct12> this should allow new lxc read-only containers to start
2021-06-10 07:56:50 <PureTryOut> Hmm qt5-qtbase failed on riscv64 because of textrels 🤔 How can I get rid of those?
2021-06-10 08:00:11 <ikke> that's not trivial
2021-06-10 08:00:20 <ikke> for now, we opted to add options="textrels"
2021-06-10 08:00:27 <ikke> Then we can fix it later
2021-06-10 08:24:52 <PureTryOut> Ok will do
2021-06-10 08:25:07 <PureTryOut> Is there anywhere I can read up on textrels btw? I have no clue what it is
2021-06-10 08:25:38 <ikke> https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide
2021-06-10 08:25:49 <PureTryOut> Thanks!
2021-06-10 08:26:31 <ikke> https://flameeyes.blog/2016/01/16/textrels-text-relocations-and-their-impact-on-hardening-techniques/
2021-06-10 08:26:38 <ikke> That contains more info on what it is
2021-06-10 08:32:07 <clandmeter> PureTryOut: thx for helping out! :)
2021-06-10 08:32:50 <PureTryOut> Np! I'm quite excited for riscv64 and it's promises so I don't mind helping where possible and I have time
2021-06-10 08:33:23 <clandmeter> PureTryOut: you can also find more info in this issue https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10722
2021-06-10 08:33:30 <clandmeter> also regarding textrels 
2021-06-10 08:33:58 <clandmeter> some langs are not enabled in gcc, this could also lead into missing deps.
2021-06-10 08:33:59 <PureTryOut> Thanks, will follow along!
2021-06-10 08:34:22 <clandmeter> PureTryOut: do you have a local setup?
2021-06-10 08:34:33 <clandmeter> or just follow the logs?
2021-06-10 08:34:33 <ncopa> anyone has access to ipv6 environment and can test the 3.14.0_rc2 in a vm with ipv6 only - and has shell scripting skills?
2021-06-10 08:34:42 <PureTryOut> clandmeter: just following the logs for now
2021-06-10 08:34:48 <ncopa> ... and has some time to help with the setup script
2021-06-10 08:34:49 <PureTryOut> I'd like to setup a VM for it at some point though
2021-06-10 08:34:55 <PureTryOut> Would need a guide for that however 😅
2021-06-10 08:35:11 <clandmeter> PureTryOut: its on the list of todo :)
2021-06-10 08:35:31 <ikke> PureTryOut: note that we do not have a riscv64 vm yet
2021-06-10 08:35:35 <ikke> we use qemu-user
2021-06-10 08:35:55 <Jenkler> clandmeter, How do i solve this the best way: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22178?view=inline#note_161970
2021-06-10 08:36:06 <clandmeter> ncopa: i dont have time, but you could use a linode for it?
2021-06-10 08:36:40 <ncopa> can linode boot the alpine-*.iso images?
2021-06-10 08:36:50 <PureTryOut> ikke: like I said, "at some point". I'm fine waiting till you guys get it booting for the first time 😉
2021-06-10 08:36:51 <Jenkler> clandmeter, Michał Polański want me to squash and change commit message 
2021-06-10 08:36:56 <ncopa> or does it require custom boot image
2021-06-10 08:37:24 <Jenkler> Is that possibe if ncopa have merged part of it allready 
2021-06-10 08:37:54 <ncopa> Jenkler: evertying is possible. i agree with michal, it should be squashed
2021-06-10 08:38:09 <Jenkler> all 6 commits?
2021-06-10 08:38:38 <clandmeter> ncopa: ah booting, hmm i guess not.
2021-06-10 08:39:13 <ikke> I think I can set something up locally
2021-06-10 08:39:40 <ncopa> clandmeter: there are 23 open issues with target 3.14.0. the openssh issue took two days. if i spend two days on each of those 23 issues the 3.14 will be out in 46 days approx
2021-06-10 08:39:56 <ncopa> given that my employee is ok that I put everything else in my hands on hold
2021-06-10 08:40:04 <Jenkler> I am not a git guru. I think i need to use rebase 
2021-06-10 08:40:36 <clandmeter> ncopa: right, i think you need help, but im a bit swamped right now :(
2021-06-10 08:40:37 <ikke> ncopa: what do you need tested?
2021-06-10 08:40:37 <ncopa> Jenkler: I'd do: git rebase -i
2021-06-10 08:40:44 <ncopa> clandmeter: same
2021-06-10 08:40:49 <ikke> I have time after work
2021-06-10 08:41:09 <clandmeter> i guess we can ask nicely here for ppl to help (where possible)
2021-06-10 08:41:13 <clandmeter> HELP!!!!!
2021-06-10 08:41:21 <fcolista> how would you filter the open issues for 3.14 release?
2021-06-10 08:41:23 <ncopa> clandmeter: that is what i tried to do...
2021-06-10 08:41:37 <ncopa> fcolista: https://gitlab.alpinelinux.org/alpine/aports/-/issues?milestone_title=3.14.0
2021-06-10 08:41:45 <ncopa> HEEEELLLLP!!!!!!
2021-06-10 08:41:51 <fcolista> :D
2021-06-10 08:41:51 <ncopa> :)
2021-06-10 08:41:53 <clandmeter> ncopa: :)
2021-06-10 08:41:58 <clandmeter> look it helps
2021-06-10 08:42:02 <Jenkler> ncopa, do i need more params...  like HEAD~3 or something?
2021-06-10 08:42:20 <ikke> Jenkler: the base branch, so master most likely
2021-06-10 08:42:27 <ncopa> Jenkler: depends on how you have names your branches
2021-06-10 08:42:32 <ncopa> and remotes
2021-06-10 08:42:55 <Jenkler> but some of it is allready merged to master 
2021-06-10 08:43:04 <Jenkler> i have a branch called mongodb 
2021-06-10 08:43:05 <clandmeter> rebase youjrj branch
2021-06-10 08:43:16 <ncopa> git rebase -i master
2021-06-10 08:43:31 <ncopa> sorry
2021-06-10 08:43:33 <clandmeter> ncopa: go fix 3.14 things ;-)
2021-06-10 08:43:36 <ncopa> git rebase master first
2021-06-10 08:43:53 <ncopa> it will filter out the commited stuff
2021-06-10 08:43:57 <ncopa> then git rebase -i master
2021-06-10 08:44:46 <ncopa> I'd replace 'pick' with 'fixup' on all lines except first, and then git commit --amend to fix the commit message
2021-06-10 08:45:01 <Jenkler> ncopa, so i change to my master first and pull all updates?
2021-06-10 08:45:26 <ikke> Jenkler: git fetch
2021-06-10 08:45:47 <ikke> git fetch origin, and then you can rebase on top of origin/master (assuming origin is alpine/aports
2021-06-10 08:46:18 <Jenkler> I have ha fork of aports 
2021-06-10 08:46:30 <Jenkler> there i have a branch called mongodb 
2021-06-10 08:46:43 <Jenkler> with a few changes 
2021-06-10 08:47:20 <Jenkler> and some of them is merged in your master tree 
2021-06-10 08:47:27 <clandmeter> PureTryOut: for textrels maybe similar to this would be better 7f7a07d490bd020a02a147d2e9c489f08aab0cb2
2021-06-10 08:47:53 <Jenkler> so i guess i need to update my master aginst your master first
2021-06-10 08:48:28 <PureTryOut> clandmeter: ah yes agreed, will update
2021-06-10 08:52:11 <liske> ncopa: for testing rc2 with ipv6, something special to look at (manual, SLAAC, DHCP, ...)?
2021-06-10 08:52:34 <Jenkler> 1. git checkout master; git fetch upstream; git pull upstream master 
2021-06-10 08:54:02 <Jenkler> 2. git push origin master
2021-06-10 08:54:17 <Jenkler> Now my master is updated
2021-06-10 08:56:40 <Jenkler> ikke, then i change to mongodb branch. should i firtst git fetch and rebase from origin/master?
2021-06-10 09:04:45 <ncopa> liske: i think it does not work at all. so the job is to boot a vm with ipv6 only, run setup-alpine. file issue (and preferible fix) every issue that comes along the way
2021-06-10 09:05:39 <ncopa> Jenkler: i think so yes
2021-06-10 09:06:15 <ncopa> any volunteer to have a look at a relatively simple issue with asterisk and file permissions of logs after logrotate?
2021-06-10 09:07:45 <donoban> I can take a look ncopa 
2021-06-10 09:08:03 <donoban> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11142 this?
2021-06-10 09:08:13 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11142 yes
2021-06-10 09:08:17 <donoban> ok
2021-06-10 09:08:25 <ncopa> whats your gitlab nick?
2021-06-10 09:08:30 <donoban> donoban
2021-06-10 09:09:32 <ncopa> hum, i cannot assign you for now. ok...
2021-06-10 09:09:35 <ncopa> thanks anyway
2021-06-10 09:11:20 <donoban> well I can try to fix it anyway
2021-06-10 09:14:54 <donoban> bad begin:  * ERROR: asterisk failed to start :P
2021-06-10 09:28:50 <liske> ncopa: ipv6-slaac-only seems to work fine: used `none` for address setup and enter a valid ipv6 nameserver address
2021-06-10 09:29:57 <Jenkler> ncopa, does not seam to be better https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22178/commits?view=inline#note_161970
2021-06-10 09:30:32 <Jenkler> ikke, now its 41 commits. need advice 
2021-06-10 09:31:36 <ikke> Jenkler: You ran git pull afer you did a git rebase
2021-06-10 09:31:47 <ikke> You need to undo that merge
2021-06-10 09:32:05 <ikke> git reset --hard HEAD~1
2021-06-10 09:32:05 <ncopa> liske: did you manually edit the /etc/network/interfaces? Does it pick a working apk repository?
2021-06-10 09:32:27 <ncopa> ... be careful with --hard
2021-06-10 09:32:44 <ncopa> make sure you have a copy of you work in case you dont know exactly what you are doing
2021-06-10 09:33:00 <Jenkler> Plz, ikke say what todo step by step so its not get more broken 
2021-06-10 09:33:18 <Jenkler> ncopa, ok i take a backup 
2021-06-10 09:33:44 <liske> nope, I did just enter `none` at the address prompt so in /etc/network/interfaces there is only a iface eth0 inet manual\n  pre-up ip link set eth0 up 
2021-06-10 09:34:09 <liske> that works fine for ipv6 slaac envs, apk did just work out of the box 
2021-06-10 09:34:22 <liske> the cdn seems to do ipv6 ;)
2021-06-10 09:35:34 <donoban> ohh sniff sniff traps: kwin_wayland[4247] general protection fault ip:7fd13c8b0aeb sp:7ffccaf55678 error:0 in ld-musl-x86_64.so.1[7fd13c8a9000+48000]
2021-06-10 09:35:55 <liske> (ipv6-dhcpv6-noslaac needs still to be tested)
2021-06-10 09:36:15 <Jenkler> ikke, now i have a backup. what todo next?
2021-06-10 09:36:24 <ikke> did you do the reset?
2021-06-10 09:36:37 <Jenkler> nope 
2021-06-10 09:36:42 <ikke> then do the reset
2021-06-10 09:37:12 <Jenkler> ikke, in the mongodb branch right 
2021-06-10 09:37:19 <Jenkler> ikke, git reset --hard HEAD~1
2021-06-10 09:37:49 <ikke> yes
2021-06-10 09:37:56 <ikke> now, what does git status say?
2021-06-10 09:38:19 <Jenkler> HEAD is now at 0a4767b405 community/qt5-qtbase: only allow textrels on riscv64
2021-06-10 09:38:37 <ncopa> liske: can you please add your findings to https://gitlab.alpinelinux.org/alpine/aports/-/issues/10237
2021-06-10 09:38:53 <Jenkler> ikke, status says nothing to commit, working tree clean
2021-06-10 09:39:09 <liske> ok
2021-06-10 09:40:15 <Jenkler> ikke, nothing in git diff or git status 
2021-06-10 09:43:00 <ikke> Jenkler: can give the output of `git log -n 50 --all --graph --format="%h %p %d %s | curl tpaste.us -F 'tpaste=<-'`
2021-06-10 09:44:45 <donoban> ncopa: asterisk needs some things for starting after install, it seems that at least setting up some modules or enabling autoload, should it provide some working configuration by default?
2021-06-10 09:44:58 <donoban> or at least would be nice it shows more informative error messages
2021-06-10 09:45:34 <Jenkler> ikke, https://tpaste.us/9jpl
2021-06-10 09:45:41 <Jenkler> ikke, added 100 
2021-06-10 09:45:48 <Jenkler> ikke, or +50 
2021-06-10 09:50:49 <ncopa> donoban: i think it would be nice with a working minimal default config, but i think thats less important. fixing the logrotate permission issue is more important
2021-06-10 09:51:13 <donoban> ok
2021-06-10 09:52:11 <Jenkler> ikke, does it make any sence?
2021-06-10 09:52:35 <Jenkler> *sense
2021-06-10 09:53:16 <fcolista> re: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11142 atm we have logrotate setting permission to 0640, which is what fedora does 
2021-06-10 09:53:26 <ikke> Jenkler: I have a bit more time in a bit
2021-06-10 09:53:53 <fcolista> gentoo and debian do not have "create" withing the logrotate file
2021-06-10 09:54:25 <fcolista> wonder if we really need to go ahead and modify permission to 0740 as requested...I don't see the reason, since asterisk starts fine with 0640
2021-06-10 09:54:37 <Jenkler> ikke, nice 
2021-06-10 09:55:18 <fcolista> the asterisk log directory is root:root, while logs are not
2021-06-10 09:55:23 <donoban> uhM
2021-06-10 09:55:34 <donoban> here is asterisk:asterisk fcolista 
2021-06-10 09:55:41 <ncopa> Cogitri: is it realistic to do the /usr/share/appdata to /usr/share/metainfo
2021-06-10 09:55:41 <ncopa>  https://gitlab.alpinelinux.org/alpine/aports/-/issues/11642
2021-06-10 09:55:41 <ncopa> 
2021-06-10 09:55:42 <fcolista> no
2021-06-10 09:55:49 <donoban> drwxr-xr-x    1 asterisk asterisk      72 Jun 10 11:42 asterisk/
2021-06-10 09:56:01 <fcolista> donoban, which version of alpine?
2021-06-10 09:56:04 <donoban> edge
2021-06-10 09:56:35 <fcolista> interesting...wondering why not in my lxc container
2021-06-10 09:56:47 <fcolista> chown -R asterisk:asterisk "$pkgdir"/var/*/asterisk
2021-06-10 09:57:17 <donoban> yeah
2021-06-10 09:57:20 <fcolista> that must be asterisk.asterisk then
2021-06-10 09:57:36 <fcolista> so I don't see what we need to do with @11142
2021-06-10 09:57:42 <fcolista> * #1142
2021-06-10 09:57:50 <fcolista> uff..#11142
2021-06-10 09:57:57 <ncopa> Cogitri can https://gitlab.alpinelinux.org/alpine/aports/-/issues/11701 be fixed within this week? I'll move it to 3.15.0 otherwise
2021-06-10 09:59:13 <ncopa> fcolista: the issue says :"First start of asterisk creates logs with permissions 644." so may be fix it so the log permissions are 640 at start?
2021-06-10 09:59:28 <ncopa> might a question of setting umask in init.d
2021-06-10 09:59:42 <fcolista> gotcha
2021-06-10 10:00:09 <fcolista> thx for the input, i didn't understood what the request was actually
2021-06-10 10:00:52 <donoban> so modify logrorate files to "create 0644 asterisk asterisk"?
2021-06-10 10:02:14 <fcolista> atm asterisk logrotate has 0640. If we set the init to have logs with 0640, why do we need to modify logrotate?
2021-06-10 10:03:03 <donoban> yes thats the other alternative, I was assuming that 0644 was the "correcT"
2021-06-10 10:03:37 <fcolista> tbh i think the from the user perspective is better to have 0644
2021-06-10 10:04:28 <fcolista> otherwise to check the log you need to su asterisk or root
2021-06-10 10:04:51 <fcolista> "It does not really affect anything, only that after logrotate the logs are no longer world readable and normal users will not be able to review the logs if not part of asterisk group. I would expect the behavior of logrotate to keep the permissions as installed"
2021-06-10 10:05:02 <fcolista> ok let's go to fix logrotate with 0644
2021-06-10 10:05:47 <donoban> for what Ryan said on the issue, I guess it has also /var/log/asterisk as root:root
2021-06-10 10:06:12 <donoban> uhm, or maybe not necessary
2021-06-10 10:06:14 <fcolista> yes, but that should have been something related to older alpine version
2021-06-10 10:06:45 <donoban> in the package upgrade it should be fixed?
2021-06-10 10:07:08 <fcolista>  git show 226b4ff5619caba916c2931d2977471569921fa6
2021-06-10 10:08:42 <donoban> wow, near 10years ago :P
2021-06-10 10:09:29 <donoban> so are you going to commit 11142 fix?
2021-06-10 10:09:43 <Cogitri> ncopa: Please move it to 3.15. Exams start on Saturday so I'm not available for that currently unfortunately
2021-06-10 10:09:52 <fcolista> yes I wonder to fix logrotate to 0644
2021-06-10 10:10:20 <ikke> we could use checkpath in the service file?
2021-06-10 10:10:57 <fcolista> ikke, that's what gentoo does for asterisk log dir
2021-06-10 10:10:58 <fcolista> checkpath -d -m 0755 -o "${ast_user}:${ast_group}" "${ast_logdir}" "${ast_rundir}"
2021-06-10 10:11:08 <fcolista> https://gitweb.gentoo.org/repo/gentoo.git/tree/net-misc/asterisk/files/initd-16.16.2-r1
2021-06-10 10:21:19 <Jenkler> ikke, time now to take a look at this mess?
2021-06-10 10:21:45 <ikke> Jenkler: yes
2021-06-10 10:22:25 <Jenkler> ikke, so what do we do next any wiser from my tpaste?
2021-06-10 10:22:48 <ikke> First step (while on mongodb: git reset --hard f9109fa1b5
2021-06-10 10:24:30 <Jenkler> HEAD is now at f9109fa1b5 non-free/mongodb: maintainer email change
2021-06-10 10:25:27 <ikke> now: git rebase HEAD~ --onto 59cbdc9171
2021-06-10 10:26:05 <Jenkler> Successfully rebased and updated refs/heads/mongodb.
2021-06-10 10:26:22 <ikke> can you now show your sutation again?
2021-06-10 10:27:13 <Jenkler> https://tpaste.us/nWm4 
2021-06-10 10:27:34 <Jenkler> is that what you mean?
2021-06-10 10:28:25 <ikke> yes
2021-06-10 10:29:27 <ikke> now first: git rebase HEAD~3 --onto origin/master
2021-06-10 10:30:01 <Jenkler> done
2021-06-10 10:30:15 <ikke> Now your branch has 3 commits
2021-06-10 10:30:32 <ikke> non-free/mongodb: update to 4.2.14
2021-06-10 10:30:38 <ikke> non-free/mongodb: update to 4.2.14 without system stemmer
2021-06-10 10:30:44 <ikke> non-free/mongodb: maintainer email change
2021-06-10 10:31:03 <ikke> the first 2, you can squash
2021-06-10 10:31:04 <ncopa> Cogitri: good. thanks! enjoy your exams!
2021-06-10 10:31:38 <Jenkler> ikke, w8
2021-06-10 10:32:01 <donoban> trying to run qxl with qemu-openrc I ended with this errors:
2021-06-10 10:32:13 <donoban> Failed to open module: Error relocating /usr/bin/../lib/qemu/ui-spice-core.so: egl_texture_blend: symbol not found
2021-06-10 10:32:14 <donoban> Failed to open module: Error relocating /usr/bin/../lib/qemu/hw-display-qxl.so: qemu_spice_display_switch: symbol not found
2021-06-10 10:32:43 <donoban> should be considered alpine issues? or I have to guess what packages I'm missing
2021-06-10 10:33:08 <skarnet> in what world are exams enjoyable? :D
2021-06-10 10:33:21 <Jenkler> ikke, rebase -i just say noop
2021-06-10 10:33:27 <donoban> hehe
2021-06-10 10:33:29 <ikke> Jenkler: git rebase -i origin/master
2021-06-10 10:35:32 <mps> donoban: no it is not alpine issue. you should install needed qemu subpkgs
2021-06-10 10:35:34 <Jenkler> ikke, i have more than 3 
2021-06-10 10:35:59 <Jenkler> ikke, i have 6 non-free/mongodb 
2021-06-10 10:36:00 <ncopa> donoban: sounds like a package dependency problem. i think you can create an issue for it
2021-06-10 10:36:21 <ikke> Jenkler: did you ran git pull again?
2021-06-10 10:36:27 <mps> make qemu-all metapackage
2021-06-10 10:36:33 <Jenkler> ikke, no
2021-06-10 10:36:36 <donoban> ncopa: mps maybe some metapackage for qxl will help
2021-06-10 10:36:48 <Jenkler> ikke, but i aborted a rebase -i
2021-06-10 10:36:56 <Jenkler> in the mongodb branch 
2021-06-10 10:37:14 <donoban> mps: the problem is that is hard to guess what package are missing
2021-06-10 10:37:45 <mps> spice should depened on qemu-ui-spice-core and qemu-ui-spice-app
2021-06-10 10:38:04 <mps> and qemu-ui-opengl
2021-06-10 10:38:11 <Jenkler> ikke, https://tpaste.us/zxNZ
2021-06-10 10:38:37 <mps> qemu-audio-spice
2021-06-10 10:38:38 <Jenkler> ikke, i aborted the  git rebase -i origin/master
2021-06-10 10:38:54 <mps> qemu-hw-display-qxl
2021-06-10 10:39:02 <mps> a lot
2021-06-10 10:39:26 <mps> donoban: it is not so hard
2021-06-10 10:39:33 <ncopa> Failed to open module: Error relocating /usr/bin/../lib/qemu/hw-display-qxl.so: qemu_spice_display_switch: symbol not found
2021-06-10 10:40:00 <donoban> installed all you said, only one was not installed yet and it keeps with same errors
2021-06-10 10:40:16 <ncopa> i think that sounds like the package shipping hw-display-qxl.so should depend on whatever package provides qemu_spice_display_switch
2021-06-10 10:40:55 <Jenkler> ikke, i am in the mongobe branch when running log 
2021-06-10 10:40:56 <mps> apk search qemu | sort | grep qemu-hw
2021-06-10 10:41:23 <mps> and, apk search qemu | sort | grep qemu-ui
2021-06-10 10:42:09 <donoban> qemu-ui-opengl did the trick
2021-06-10 10:42:29 <mps> but for those who want ubuntu style, qemu-all metapkg is solution
2021-06-10 10:42:51 <ncopa> mps: i think the deps are broken
2021-06-10 10:43:50 <mps> ncopa: I agree, but not sure what needs to make it correct
2021-06-10 10:44:07 <ncopa> that is the job at hand :)
2021-06-10 10:44:16 <ncopa> figure it out
2021-06-10 10:44:23 <mps> carrefuly test combos and add them in proper subpkgs?
2021-06-10 10:44:51 <mps> this could be 'task' for next stable
2021-06-10 10:45:03 <ncopa> nm -D may help tell what library provides the symbol
2021-06-10 10:45:09 <donoban> well if you want I open an issue and recopile the info
2021-06-10 10:45:13 <ncopa> and we can simply add it to the depends
2021-06-10 10:45:17 <ncopa> donoban: yes please!
2021-06-10 10:45:20 <donoban> ok
2021-06-10 10:45:49 <mps> yes, actually I have them all in head, just need time to test them and add in apkbuild
2021-06-10 10:46:36 <ncopa> $ for i in /usr/lib/qemu/*.so; do nm -D $i | grep qemu_spice_display_switch && echo "=
2021-06-10 10:46:36 <ncopa>                  U qemu_spice_display_switch
2021-06-10 10:46:36 <ncopa> ==== /usr/lib/qemu/hw-display-qxl.so
2021-06-10 10:46:36 <ncopa> === $i"; done
2021-06-10 10:46:36 <ncopa> 000000000000a5e5 T qemu_spice_display_switch
2021-06-10 10:46:37 <ncopa> ==== /usr/lib/qemu/ui-spice-core.so
2021-06-10 10:46:46 <mps> donoban: yes, please do
2021-06-10 10:47:14 <ncopa> U means its undefined (i think) and T means that it is in 'text' (I think), so the symbol is provided
2021-06-10 10:47:25 <mps> donoban: ofc, if you have time and will
2021-06-10 10:48:06 <donoban> yes no problem
2021-06-10 10:48:08 <ncopa> the means that package providing /usr/lib/qemu/hw-display-qxl.so should depend on package providing /usr/lib/qemu/ui-spice-core.so
2021-06-10 10:49:12 <mps> btw, nowadays everything is broken, nearly
2021-06-10 10:49:13 <ncopa> qemu-hw-display-qxl should depend on qemu-ui-spice-core
2021-06-10 10:49:28 <ncopa> mps: thats why we spend time on fixing things today
2021-06-10 10:49:46 <donoban> let me try deleting all and installing only them
2021-06-10 10:50:03 <mps> qemu-ui-spice-core should depend on qemu-ui-opengl
2021-06-10 10:51:42 <mps> last time i use my (free) time to fix broken arm (new and shiny) kernels
2021-06-10 10:52:48 <mps> now in kernel importanting things are microsoft and other big co features and not drivers stability
2021-06-10 10:53:37 <donoban> ncopa: only with that packages the unfound symbol errors persists
2021-06-10 10:53:52 <ncopa> what symbols?
2021-06-10 10:54:00 <donoban> ailed to open module: Error relocating /usr/bin/../lib/qemu/ui-spice-core.so: egl_texture_blend: symbol not found
2021-06-10 10:54:02 <donoban> Failed to open module: Error relocating /usr/bin/../lib/qemu/hw-display-qxl.so: qemu_spice_display_switch: symbol not found
2021-06-10 10:54:32 <donoban> maybe the first causes the second
2021-06-10 10:54:55 <ncopa> yes. possible
2021-06-10 10:55:16 <donoban> i that that its fixed by qemu-ui-opengl
2021-06-10 10:55:27 <donoban> yeah, it works now
2021-06-10 10:56:07 <ncopa> $ for i in /usr/lib/qemu/*.so; do nm -D $i | grep egl_texture_blend && echo "==== $i"; done | tpaste
2021-06-10 10:56:07 <ncopa> https://tpaste.us/LwLK
2021-06-10 10:56:14 <mps> for any graphic ui qemu-ui-opengl is must
2021-06-10 10:56:49 <ncopa>  the /usr/lib/qemu/ui-gtk.so and /usr/lib/qemu/ui-spice-core.so needs /usr/lib/qemu/ui-opengl.so
2021-06-10 11:02:02 <donoban> so do you think that is solved or should I fire the issue?
2021-06-10 11:02:12 <ncopa> fire the issue
2021-06-10 11:02:16 <donoban> ok
2021-06-10 11:04:40 <ncopa>  for i in /usr/lib/qemu/*.so; do nm -D $i | awk -v f=$i '$1 == "U" && $2 == "egl_texture_blend" { print "needed-by " f} $2 == "T" && $3 == "egl_texture_blend" { print "provided-by " f }'; done
2021-06-10 11:04:40 <ncopa> needed-by /usr/lib/qemu/ui-spice-core.so
2021-06-10 11:04:40 <ncopa> provided-by /usr/lib/qemu/ui-opengl.so
2021-06-10 11:04:40 <ncopa> needed-by /usr/lib/qemu/ui-gtk.so
2021-06-10 11:07:13 <donoban> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12741
2021-06-10 11:09:08 <donoban> the libvirt/virt-manager note means that it fails even with the unfound symbols fixed but I can't debug it now
2021-06-10 11:09:24 <donoban> maybe is best to handle on a different issue
2021-06-10 11:09:32 <donoban> s/best/better
2021-06-10 11:09:32 <alpine-meetbot> donoban meant to say: maybe is better to handle on a different issue
2021-06-10 11:29:52 <Hello71> maybe it would be better to put DT_NEEDED
2021-06-10 11:30:24 <Hello71> but could require too much patching
2021-06-10 12:14:28 <fcolista> donoban: http://dpaste.com/CG43C2Z9A.txt
2021-06-10 12:15:20 <fcolista> ikke ^ 
2021-06-10 12:22:15 <mps> looks like I managed to make perl locale gettext working on musl/alpine
2021-06-10 12:33:02 <fcolista> when a file .so should go into -dev or into main package? What's the criteria?
2021-06-10 12:33:24 <ikke> fcolista: .so -> -dev
2021-06-10 12:33:29 <ikke> .so.x.y -> main package
2021-06-10 12:33:37 <clandmeter> the .so is a symlink?
2021-06-10 12:33:41 <ikke> yes
2021-06-10 12:33:46 <ikke> it typically is
2021-06-10 12:33:54 <clandmeter> yes, but that kind of defines the reasoning :)
2021-06-10 12:34:13 <ikke> and default_dev does the correct thing already
2021-06-10 12:34:36 <fcolista> when the .so should go into -libs?
2021-06-10 12:34:48 <ikke> not
2021-06-10 12:35:02 <fcolista> or, the other way round, which files go into -libs then?
2021-06-10 12:35:08 <ikke> -libs is used when an application provides a library as well
2021-06-10 12:35:18 <ikke> so you can install -libs to just get the libraries
2021-06-10 12:35:23 <clandmeter> fcolista: the .so is normally a symlink to the versioned so
2021-06-10 12:36:08 <clandmeter> but ones its linked you dont need the symlink anymore, so its moved to -dev.
2021-06-10 12:37:45 <kunkku> why is armv7 missingn from here: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/alpine-keys/APKBUILD#L13 ?
2021-06-10 12:37:56 <fcolista> clandmeter, ikke thanks
2021-06-10 12:40:24 <clandmeter> kunkku: good question
2021-06-10 12:42:30 <clandmeter> i guess ncopa forgot to add it in 7c5404f01b0f24adbd3b22a33d1c00b56e1013c6
2021-06-10 12:44:14 <kunkku> is it using the same key as armhf?
2021-06-10 12:44:23 <clandmeter> yes it looks like it
2021-06-10 12:49:13 <PureTryOut> Hmm I don't understand the current riscv64 qt5-qtdeclarative build failure...
2021-06-10 12:49:22 <clandmeter> i do :)
2021-06-10 12:49:38 <PureTryOut> Oh great! Do you know how to fix it as well? 😃
2021-06-10 12:49:44 <clandmeter> i think so
2021-06-10 12:50:31 <clandmeter> link to -latomic
2021-06-10 12:50:47 <clandmeter> it is provided by g cc
2021-06-10 12:51:21 <PureTryOut> And _how_ would we link that to `-latomic`? 😛
2021-06-10 12:51:31 <clandmeter> mangle ldflags 
2021-06-10 12:51:39 <PureTryOut> Oh great... 😢
2021-06-10 12:51:59 <clandmeter> LDFLAGS=$LDFLAGS -latomic"
2021-06-10 12:56:57 <clandmeter> PureTryOut: some more info here: https://github.com/riscv/riscv-gnu-toolchain/issues/183#issuecomment-253721765
2021-06-10 12:57:22 <PureTryOut> Fun, so should be fixed in gcc then
2021-06-10 12:57:32 <PureTryOut> Let's see if mangling the ldflags works in this case
2021-06-10 12:57:48 <clandmeter> im working on CI
2021-06-10 13:00:47 <PureTryOut> clandmeter: just to check, would this work? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22219
2021-06-10 13:02:03 <clandmeter> maybe you need to export it
2021-06-10 13:03:23 <PureTryOut> ldflags is already set though is it not? Or do you need to export it even for updates to it?
2021-06-10 13:03:54 <mps> yes, you have to export it
2021-06-10 13:04:20 <mps> 'export LDFLAGS="$LDFLAGS -latomic"'
2021-06-10 13:14:21 <PureTryOut> Ok fixed
2021-06-10 13:19:41 <ncopa> py3-sphinx is broken
2021-06-10 13:21:14 <ncopa> https://tpaste.us/qgQK
2021-06-10 13:22:40 <ncopa> i think this broke it 113bbd3c3edb9f318478122a20b320984351a400
2021-06-10 13:26:22 <ncopa> its py3-requests that needs it apparently
2021-06-10 13:26:30 <ncopa> i mean its py3-requests thats broken
2021-06-10 13:28:07 <bandali> hi, would alpine folks be open to licensing the alpine website under free software/culture licenses, in case at some point in the future e.g. an alpine derivative wants to base their website on a fork of alpine-mksite?
2021-06-10 13:29:28 <ncopa> im open to that yes
2021-06-10 13:29:43 <ncopa> not sure which license or how
2021-06-10 13:30:05 <bandali> awesome, thanks. i can open an issue about it on the gitlab repo to discuss further
2021-06-10 13:30:30 <bandali> is there any way one of you folks could register an account for me without me having to run recaptcha's proprietary js?
2021-06-10 13:32:09 <Cogitri> Unfortunately we need some form of captcha, we already have some spam every now and then :/
2021-06-10 13:32:27 <Cogitri> Not sure if Gitlab supports other providers
2021-06-10 13:33:13 <ncopa> i guess thats understandable, but the question here is if we can create the account for bandali
2021-06-10 13:33:57 <bandali> :-/ i was hoping the staff could perhaps do one-off requests for accounts (i believe oftc, the network, does the same for account creation requests of folks who want to avoid running recaptcha)
2021-06-10 13:34:00 <ncopa> bandali: i can help you
2021-06-10 13:34:09 <Cogitri> Oh, read that wrong :)
2021-06-10 13:34:20 <bandali> ncopa, thank you :-) okay to msg you?
2021-06-10 13:34:21 <Cogitri> Yeah I think the instance admin can create accounts
2021-06-10 13:34:41 <bandali> +1
2021-06-10 13:35:41 <ncopa> bandali: sure
2021-06-10 13:35:55 <bandali> thanks
2021-06-10 13:44:07 <fcolista> ncopa, i suppose that py3-requests was broken even before
2021-06-10 13:44:15 <fcolista> since requirement is idna<3,>=2.5
2021-06-10 13:44:21 <fcolista> and the previous version was 3.1
2021-06-10 13:44:27 <ncopa> apparently we have a patch for it
2021-06-10 13:44:48 <ncopa> 26a38cae97cdac877d9a55e475c69cb57702a5ee
2021-06-10 13:44:50 <fcolista> update the requruements?
2021-06-10 13:44:55 <Hello71> not sure how much gitlab you can run without gitlab proprietary js though
2021-06-10 13:45:21 <fcolista> ok good..that's what I was going to do
2021-06-10 13:45:48 <ncopa> fcolista: i have it in my queue here, so dont worry
2021-06-10 13:45:53 <bandali> last i'd checked gitlab's js was free, even the js bits of their ee version
2021-06-10 13:46:11 <fcolista> ok thx ncopa 
2021-06-10 13:47:54 <ncopa> I have a fix for #12741 coming up
2021-06-10 13:53:23 <ncopa> mps: I have mixed feelings about this granular qemu modules thingy
2021-06-10 13:54:10 <ncopa> i think its good to not need pull in more deps that absolutely needed (so granular modules in feb4aaf0bfc093ac5d122e9aef9ee43f6955629f makes sense)
2021-06-10 13:54:49 <ncopa> but on the other hand, managing the dependencies can be complicated. I had to write a lua script to figure it out
2021-06-10 13:55:28 <ncopa> and it took some time
2021-06-10 13:55:50 <mps> ncopa: yes, I agree, it is not simple
2021-06-10 13:56:56 <ncopa> i think its good to keep that in mind when splitting packages, to also spend the time to figure out the dependencies
2021-06-10 13:57:06 <mps> I contemplated some time about this and thought to look at it after 3.14, but if you did it already you saved me some time. thanks :)
2021-06-10 13:57:59 <ncopa> i did it already yes
2021-06-10 13:57:59 <mps> again agree with you, we should do such changes carefully (as we can)
2021-06-10 14:00:12 <fcolista> looks that for #12721 we already have a workaround in place:  4df56e491c2b0510c4db6160e5f29d769123d40c
2021-06-10 14:00:14 <mps> I would be pleased if 3.14 will be released tomorrow (or even today at evening)
2021-06-10 14:00:47 <fcolista> perhaps this is another issue that can be closed
2021-06-10 14:02:41 <fcolista> mps is #12418 a wontfix? We used to add to syslinux.cfg the serial connection enabled
2021-06-10 14:03:48 <mps> fcolista: I would like it fixed but we didn't reached consensus yet
2021-06-10 14:03:59 <mps> let it open for now
2021-06-10 14:27:07 <kunkku> clandmeter: the MR for rootbld/qemu-user is now open
2021-06-10 14:27:26 <kunkku> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/100
2021-06-10 14:28:05 <PureTryOut> clandmeter: that did not seem to fix qt5-qtdeclarative 😢
2021-06-10 14:28:42 <clandmeter> kunkku: nice!
2021-06-10 14:28:46 <clandmeter> will try it asap
2021-06-10 14:28:53 <clandmeter> PureTryOut: yes i see it
2021-06-10 14:28:58 <clandmeter> i will check if i can fix it
2021-06-10 14:41:34 <ncopa> kunkku: have you tested that  https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/100 does not break anything else?
2021-06-10 14:48:32 <PureTryOut> Oh that is merged? Very cool! How would we use that once it's available in the repos? `CBUILD=riscv64 abuild rootbld` or something?
2021-06-10 14:53:39 <kunkku> yes
2021-06-10 14:54:07 <kunkku> so the usage is CBUILD=... abuild rootbld
2021-06-10 14:54:25 <kunkku> I have tested with random packages, no known issues
2021-06-10 14:55:06 <kunkku> but you have to manually install the qemu stuff
2021-06-10 14:55:37 <kunkku> and set up binfmt_misc using e.g. the script in qemu-openrc pkg
2021-06-10 15:02:09 <PureTryOut> Awesome!
2021-06-10 15:05:53 <nmeum> kunkku: very nice, thank you
2021-06-10 21:13:01 <clandmeter> PureTryOut: i think i have a fix
2021-06-10 21:50:52 <PureTryOut> Great!
2021-06-11 04:49:07 <Danct12> hi, have anyone running into the rgb screen when trying to install alpine on the pi4?
2021-06-11 04:49:39 <Danct12> i followed this guide: https://wiki.alpinelinux.org/wiki/Raspberry_Pi
2021-06-11 06:01:19 <mps> security by complications, https://github.blog/2021-06-10-privilege-escalation-polkit-root-on-linux-with-bug/
2021-06-11 06:02:49 <mps> mine (and not only mine) observation 'at work'. simpler systems/things are more secure than complicated ones
2021-06-11 06:03:31 <mps> good morning, brawe new world :)
2021-06-11 06:24:50 <ncopa> good morning
2021-06-11 06:25:34 <ncopa> mps: indeed. thats why i prefer doas over sudo
2021-06-11 06:31:37 <mps> I liked alpine moto 'small, simple, secure' when I started to use and work for alpine. but I have impression that I'm 'lossing'
2021-06-11 06:33:28 <insep> kevin is good at finding vulnerabilities it seems
2021-06-11 06:35:58 <mps> ncopa: speaking of doas, did you switched it to be used by abuild
2021-06-11 06:37:23 <ikke> abuild does not depend on sudo/doas anymore
2021-06-11 06:37:36 <ikke> abuild-keygen does by default use sudo though
2021-06-11 06:37:49 <ikke> but can be overriden with an environment variable
2021-06-11 06:38:31 <mps> aha, so I can use doas for abuild and remove sudo? iiuc
2021-06-11 06:39:26 <clandmeter> yes
2021-06-11 06:39:30 <ikke> 39bd500283b46d2d5f3ad24b360e062592558110
2021-06-11 06:39:57 <clandmeter> does abuild need sudo/doas anyway?
2021-06-11 06:40:03 <ikke> ^
2021-06-11 06:40:36 <clandmeter> we have abuild-XXX to do most if not all
2021-06-11 06:40:48 <mps> thank you my friends
2021-06-11 06:40:56 <ikke> sudo has been removed as a dependency, so everything can be done without sudo
2021-06-11 06:41:07 <ikke> only abuild-keygen, when using -i, required sudo / ddoas
2021-06-11 06:41:08 <clandmeter> it could also mean its a choice
2021-06-11 06:43:17 <mps> very good
2021-06-11 06:44:55 <mps> huh, just before release, https://www.tcpdump.org/tcpdump-changes.txt
2021-06-11 06:46:09 <mps> and ofc, https://www.tcpdump.org/libpcap-changes.txt
2021-06-11 06:47:42 <mps> and 'a lot' of pkgs depends on libpcap-dev
2021-06-11 06:50:29 <mps> holly uh, even some pkgs depends on tmux
2021-06-11 06:53:11 <ikke> wait, what?
2021-06-11 06:53:37 <ikke> maybe something like tmuxinator could have a dependency on tmux
2021-06-11 06:54:50 <mps> byobu in main
2021-06-11 06:54:58 <ikke> aha
2021-06-11 06:55:12 <mps> entr and fzf in community
2021-06-11 06:55:50 <mps> but I think it is safe to upgrade tmux, there is no lib deps
2021-06-11 06:56:23 <ikke> fzf has it only in makedepends
2021-06-11 06:56:48 <mps> for test?
2021-06-11 06:56:56 <ikke> I was wondering why
2021-06-11 06:57:33 <ikke> hmm, seems like it's not required. Wonder why I added it
2021-06-11 06:57:48 <mps> ikke: ask maintainer :)
2021-06-11 06:58:06 <ikke> I'm talking to them right now
2021-06-11 06:59:51 <mps> hehe
2021-06-11 07:00:24 <ikke> Removed it :)
2021-06-11 07:05:09 <liske> ncopa: I think #10237 cannot be easily fixed to support all variants of ipv6 setups, at least for 3.14
2021-06-11 07:06:24 <ikke> liske: I don't think we should
2021-06-11 07:07:12 <liske> maybe we could merge !22226 to fix a problem with ipv6 setups: ifup hangs due to dad script
2021-06-11 07:07:59 <liske> (I don't know why this script is there at all)
2021-06-11 07:10:40 <mps> liske: not sure for problem, but afaik dad is good to have on initialization
2021-06-11 07:11:46 <liske> it's broken if the interfaces has no link, like bridges or bonds without slaves
2021-06-11 07:12:03 <liske> found #2773 why it was added
2021-06-11 07:12:16 <mps> so it should be improved or fixed
2021-06-11 07:14:24 <liske> a max dad timeout might be good mitigation
2021-06-11 07:14:26 <mps> btw, bridges can have link
2021-06-11 07:15:28 <liske> but bonding devices would not or if you unplug the link of your router
2021-06-11 07:15:43 <mps> yes timeout could be solution
2021-06-11 07:20:52 <clandmeter> ikke: fzf has tmux option it seems
2021-06-11 07:21:11 <clandmeter> https://github.com/junegunn/fzf/blob/master/bin/fzf-tmux
2021-06-11 07:21:48 <clandmeter> i guess the main pkg also doesnt need bash?
2021-06-11 07:31:10 <kunkku> I wonder if the DAD issue could be solved inside ifupdown-ng
2021-06-11 07:31:22 <kunkku> Ariadne: ^^^
2021-06-11 07:31:46 <Ariadne> yes, open an issue
2021-06-11 07:34:09 <liske> it is only a race condition if you have a daemon binding to an ipv6 address and fails if the address is not available during startup
2021-06-11 07:34:35 <liske> would be better to fix all the daemons ;)
2021-06-11 07:35:25 <kunkku> sometimes DAD takes more time that daemon startup
2021-06-11 07:39:18 <ikke> clandmeter: yes, there is tmux integration, but it's certainly not a build dependency ;)
2021-06-11 07:40:46 <ikke> kunkku: doesn't the kernel handle DAD?
2021-06-11 07:41:25 <ikke> /proc/sys/net/ipv6/conf/all/dad_transmits
2021-06-11 07:43:39 <kunkku> yes, the script just waits until it's done
2021-06-11 07:43:56 <ikke> ah ok
2021-06-11 07:46:14 <kunkku> now you can put "need network" in your init script and assume you have the IPv6 addr ready
2021-06-11 08:00:22 <clandmeter> ikke: ah yes, looked over the build/run dep :)
2021-06-11 08:02:47 <liske> ikke: the bad thing is that dad needs to be done for any ipv6 address, eui64, privacy ext *and* for static addresses
2021-06-11 08:15:13 <PureTryOut> kunkku: I tried cross-compiling a package using the new abuild rootbld function for that, but I get "rootbld: binfmt registration missing for riscv64 binaries"
2021-06-11 08:16:01 <clandmeter> PureTryOut: did you install qemu-openrc?
2021-06-11 08:16:09 <PureTryOut> I did not
2021-06-11 08:16:15 <clandmeter> please do
2021-06-11 08:16:31 <PureTryOut> Ok I did now 😛
2021-06-11 08:16:40 <clandmeter> and qemu-riscv64
2021-06-11 08:17:00 <PureTryOut> Already had that one
2021-06-11 08:17:19 <clandmeter> start the qemu-binfmt service
2021-06-11 08:17:40 <clandmeter> you can add it to default run level if you use it often
2021-06-11 08:17:57 <clandmeter> that should be it
2021-06-11 08:18:17 <PureTryOut> Ah there you go, thanks!
2021-06-11 08:19:42 <clandmeter> Ariadne: what is the status of rust on alpine? is it doable for rv64?
2021-06-11 08:20:45 <PureTryOut> Now I just need a repo with already built packages, or I have to build all of main myself lol
2021-06-11 08:20:57 <clandmeter> PureTryOut: i was waiting for that question :p
2021-06-11 08:21:16 <PureTryOut> 😂
2021-06-11 08:21:47 <Ariadne> clandmeter: not yet
2021-06-11 08:22:24 <clandmeter> PureTryOut: use https://dev.alpinelinux.org/~clandmeter/packages/riscv64/edge/
2021-06-11 08:22:34 <clandmeter> i will try to update it ones in a while
2021-06-11 08:23:07 <PureTryOut> Can I use that repo just for abuild without adding it to `/etc/apk/repositories` somehow?
2021-06-11 08:24:13 <clandmeter> not sure what rootbld will use
2021-06-11 08:24:17 <clandmeter> ah you can
2021-06-11 08:24:22 <clandmeter> define $mirror
2021-06-11 08:24:48 <clandmeter> maybe add a small helper script that sets some variables for you
2021-06-11 08:25:07 <clandmeter> like $mirror and $CBUILD
2021-06-11 08:25:13 <PureTryOut> Sorry, define mirror? As an environment variable?
2021-06-11 08:25:31 <clandmeter> rootbld will look for $mirror
2021-06-11 08:25:53 <clandmeter> so mirror=foobar abuild rootbld..
2021-06-11 08:28:36 <donoban> trying doas I discovered that both sudo/doas are builded without pam support, is this due a feel about pam being bad or unsecure or just trying to reduce deps / mininalism?
2021-06-11 08:28:53 <PureTryOut> yeah ok env variable then, thanks
2021-06-11 08:29:07 <clandmeter> PureTryOut: thats why i mention a small helper script, so its easier to have them set on each run.
2021-06-11 08:30:25 <clandmeter> Ariadne: ok i guess we need to revdep rust and disable all of it.
2021-06-11 08:30:42 <PureTryOut> that variable works indeed, thanks!
2021-06-11 08:30:53 <clandmeter> rtfs :p
2021-06-11 08:31:18 <clandmeter> like all of alpine's dev tools
2021-06-11 08:31:34 <PureTryOut> rtfs? Read the fucking... something?
2021-06-11 08:31:49 <clandmeter> source
2021-06-11 08:32:47 <PureTryOut> Ah lol
2021-06-11 08:32:47 <liske> I've updated !22226 to skip dad on down interfaces and add a max timeout of 20s
2021-06-11 08:33:09 <PureTryOut> I didn't see it documented in `abuild -h` so I guess that output and manpages could use some enhancements
2021-06-11 08:33:25 <PureTryOut> But thanks, this will help a lot fixing stuff up I care about before the builders get to it 😃
2021-06-11 08:35:34 <clandmeter> PureTryOut: you will bump into issues that way, as the builder will have some deps already build. ping me if that happens.
2021-06-11 08:35:49 <PureTryOut> Sure
2021-06-11 08:36:07 <clandmeter> or just build the missing deps yourself, thats also possible :)
2021-06-11 08:38:44 <kunkku> PureTryOut: you can set abuild.mirror in git config
2021-06-11 08:41:15 <PureTryOut> Thanks! That would in this case prevent me from building regular x86_64 stuff, but it's good to know!
2021-06-11 08:43:18 <mps> donoban: both ' bad or unsecure'
2021-06-11 08:43:34 <mps> bad and insecure
2021-06-11 08:44:07 <clandmeter> kunkku: i guess that needs to be arch aware?
2021-06-11 08:44:29 <PureTryOut> Actually, does rootbld have any manpages at all? As in, specific for rootbld rather than abuild? 
2021-06-11 08:44:48 <clandmeter> rtfs is all i think
2021-06-11 08:45:09 <PureTryOut> Damn 😛
2021-06-11 08:45:58 <clandmeter> kunkku: i think that part of rootbld could use a comment on how it mangles git config vars
2021-06-11 08:46:15 <clandmeter> or abuses it, not sure how to name it correctly :)
2021-06-11 08:46:32 <donoban> uhM, there is this on base-auth file: "auth    required        pam_unix.so     nullok_secure" but I didn't find nullok_secure on manpage, now look at source code and I didn't find any reference
2021-06-11 08:46:53 <donoban> mps: do you some alternative for limit fail tries on sudo/doas without it?
2021-06-11 08:47:01 <donoban> s/do you/ do you know
2021-06-11 08:47:01 <alpine-meetbot> donoban meant to say: mps:  do you know some alternative for limit fail tries on sudo/doas without it?
2021-06-11 08:47:12 <clandmeter> donoban: regarding your question, i think probably both :)
2021-06-11 08:48:14 <donoban> well from the size perspective I see difficult to remove linux-pam from the system... but it is reasonable to avoid critical suid binaries rely on it
2021-06-11 08:48:51 <donoban> why sudo/doas not and su yes? uhM
2021-06-11 08:48:56 <clandmeter> i guess all of gnome can be disabled on rv64
2021-06-11 08:49:26 <clandmeter> we should have  group based arch settings :|
2021-06-11 08:50:05 <donoban> I just wanted to add max tries for sudo, I come from a passwordless so I would like to use a more simple password but I should protect it from bruteforcing :D
2021-06-11 08:50:10 <PureTryOut> why would you disable GNOME entirely?
2021-06-11 08:50:21 <clandmeter> no rust
2021-06-11 08:50:23 <PureTryOut> I hope you don't think the same about KDE's software at least 🤔
2021-06-11 08:50:25 <PureTryOut> Ah
2021-06-11 08:50:27 <PureTryOut> that actually makes sense
2021-06-11 08:50:39 <clandmeter> yes sometimes im serious 
2021-06-11 08:50:46 <PureTryOut> haha
2021-06-11 08:51:15 <clandmeter> i think fedora has group based arch settings
2021-06-11 08:51:27 <clandmeter> not sure how it works
2021-06-11 08:51:42 <mps> donoban: this is false (and too old) sense of preventing breaking passwords for login
2021-06-11 08:52:23 <mps> nowadays attackers are more smarter than when this time control idea was introduced
2021-06-11 08:53:33 <donoban> yeah but it could help against no so good attackers
2021-06-11 08:54:47 <donoban> the question if is better a bad password + pam_faillock than just a bad passsword
2021-06-11 08:55:49 <mps> yes, if you want less secure system
2021-06-11 08:56:32 <donoban> https://nvd.nist.gov/vuln/detail/CVE-2020-27780
2021-06-11 08:56:39 <donoban> lol, 2020?
2021-06-11 08:59:05 <mps> absolute secure things are those who passed 'melting pots'
2021-06-11 08:59:19 <mps> which*
2021-06-11 09:04:25 <donoban> I don't understan why use nullok, maybe for some services users?
2021-06-11 09:05:03 <donoban> s/understan/understand
2021-06-11 09:05:03 <alpine-meetbot> donoban meant to say: I don't understand why use nullok, maybe for some services users?
2021-06-11 09:07:31 <liske> to login at alpine's iso with empty root password?
2021-06-11 09:08:05 <donoban> ahh gotcha
2021-06-11 09:20:47 <mps> and alpine isos don't have pam
2021-06-11 09:21:23 <donoban> ouch
2021-06-11 09:28:35 <donoban> if this kind of bugs can happen in something like linux-pam what will be inside systemd? :\
2021-06-11 09:32:03 <mps> I don't know but I never seen any complex system that is secure
2021-06-11 09:34:19 <donoban> uhM, it seems that 'nullok_secure' comes from a debian patch which maybe never was accepted upstream
2021-06-11 09:35:09 <donoban> https://github.com/linux-pam/linux-pam/search?q=nullok_scure nothing :\
2021-06-11 09:35:15 <donoban> wops
2021-06-11 09:35:47 <donoban> https://github.com/linux-pam/linux-pam/search?q=nullok_secure there was an typo, "nothing" too
2021-06-11 09:40:57 <kunkku> busybox has nullok_secure equivalent
2021-06-11 09:45:58 <donoban> ahh, it also parses pam.d?
2021-06-11 09:46:36 <kunkku> it's sepecific to su
2021-06-11 09:46:46 <kunkku> https://git.busybox.net/busybox/commit/?id=335681ca8e39144fa19814f7ba10d0fe760e4055
2021-06-11 09:47:42 <donoban> anyway that file comes from linux-pam package uhM
2021-06-11 09:47:58 <kunkku> which file?
2021-06-11 09:48:30 <kunkku> we ship /etc/securetty with busybox
2021-06-11 09:49:05 <donoban> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/linux-pam/base-auth.pamd
2021-06-11 09:49:36 <kunkku> I don't think it uses pam.d files
2021-06-11 09:49:43 <donoban> it adds: "auth required pam_unix.so nullok_secure" which seems "unsupported" by current linux-pam
2021-06-11 09:49:56 <donoban> I suppose that it doesn't hurt
2021-06-11 09:51:50 <donoban> in the case of "nullok_secure" not being supported, it doesn't talk very good about linux-pam to get an unsupported option and don't complain about it
2021-06-11 10:04:27 <Danct12> does anyone know why wlan0 becomes unmanaged with networkmanager?
2021-06-11 10:29:05 <nero> is the wlan0 somewhere in /etc/network/interfaces ?
2021-06-11 10:44:19 <clandmeter> ncopa: should i bump pkgrel for 59252d405431 ?
2021-06-11 10:44:31 <clandmeter> not sure you want to rebuild gcc this late
2021-06-11 10:45:04 <clandmeter> i can manually rebuild it on rv64 builder
2021-06-11 10:50:25 <kunkku> clandmeter: why should rootbld mirrors be architecture-specific?
2021-06-11 10:51:14 <kunkku> usually apk appends arch to the repo URL
2021-06-11 10:57:58 <Sheila> donoban: CVE year numbers are based on the year of first reporting, if it helps. </late>
2021-06-11 11:02:36 <clandmeter> kunkku: in general there is no case, but like now for rv64 packages are not yet uploaded for all repos so its nice to use a alternative one.
2021-06-11 11:03:03 <clandmeter> i guess just setting $mirror for such corner cases is ok
2021-06-11 11:08:53 <andypost[m]> clandmeter: does it mean no-arch are duplicated because of URLs?
2021-06-11 11:28:17 <donoban> Sheila: hehe well, it doesn't mind very much for consider how dangerous is pam :|
2021-06-11 11:35:49 <Danct12> nero: i have already tried commenting it out, but to no avail.
2021-06-11 12:02:39 <ncopa> clandmeter: no strong opinion
2021-06-11 12:59:09 <guddaff[m]> Hi
2021-06-11 12:59:09 <guddaff[m]> Is there a reason why wpasupplicant isn't compiled with EAP-PWD enabled ?
2021-06-11 13:01:20 <Hello71> according to https://git.alpinelinux.org/aports/commit/main/wpa_supplicant/config?id=1540795eeadf00fe67132374a9db910bad8a588f it's from defconfig
2021-06-11 13:49:40 <guddaff[m]> maybe i dont understand the answer but i meant is there a reason why it is explicitly diasabled
2021-06-11 14:05:04 <PureTryOut> Cogitri: could you have a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22169?
2021-06-11 15:07:52 <clandmeter> andypost[m]: ?
2021-06-11 15:10:09 <andypost[m]> clandmeter: nevermind I misread
2021-06-11 16:20:44 <clandmeter> https://tpaste.us/jnqv packages that somehow depend on rust (and need to be disabled on riscv64)
2021-06-11 17:04:56 <ericonr> clandmeter: I could swear musl had a rv64-musl target already
2021-06-11 17:05:07 <ericonr> even a rv32-musl one, for that matter
2021-06-11 19:22:23 <nmeum> guddaff[m]: no, there is no reason why EAP-PWD is not enabled. could you open an issue in GitLab for this?
2021-06-11 19:40:13 <guddaff[m]> thanks for the answer 
2021-06-11 19:40:17 <guddaff[m]> i can do that
2021-06-11 19:59:05 <donoban> i think that '/etc/pam.d' definitevely needs a cleanup
2021-06-11 20:00:49 <donoban> Alpine should have an extremely simple conf by default right?
2021-06-11 20:03:21 <donoban> currently there are like 200 lines and some are evidently useless
2021-06-11 20:05:00 <dalias> ericonr, ?
2021-06-11 20:06:55 <donoban> it loads also faillock in 'system-login' but it won't work without creating dir /var/run/faillock
2021-06-11 20:07:17 <donoban> but I'm not sure if system-login is really used
2021-06-11 20:10:07 <ericonr> dalias: if you're asking about rv32-musl, rust imported the rv32 patches from the ML into their build
2021-06-11 20:23:53 <dalias> ...
2021-06-11 20:24:05 <dalias> i hope they dont have abi errors...
2021-06-11 21:07:44 <guddaff[m]> <nmeum "guddaff: no, there is no reason "> what is the standard operating procedure if i could fix it 
2021-06-11 21:11:26 <kunkku> I'm reviewing !22226
2021-06-11 21:12:10 <kunkku> for some reason, the Changes tab in GitLab is showing an outdated patch
2021-06-11 21:13:04 <kunkku> ... not the latest force pushed commit in the source branch
2021-06-11 21:13:39 <kunkku> reloading the page does not help
2021-06-11 21:15:41 <kunkku> this is scary... can we trust what we see in GitLab?
2021-06-11 21:18:42 <ikke> kunkku: is there a "show latest" button?
2021-06-11 21:19:33 <ikke> https://i.imgur.com/1zsMwmq.png
2021-06-11 22:45:51 <liske> I did observe the same glitch after the first change I made to the MR
2021-06-11 22:46:22 <liske> some time later the website did indeed show the correct changes... looks like a caching issue?
2021-06-11 22:47:01 <liske> s/website/gitlab/
2021-06-11 22:47:01 <alpine-meetbot> liske meant to say: some time later the gitlab did indeed show the correct changes... looks like a caching issue?
2021-06-11 22:49:17 <ericonr> dalias: re. rv32-musl, it's all static anyway, so if the final version in musl has to fix something, it won't impact them
2021-06-11 22:49:38 <ericonr> (unless the kernel ABI is still undefined, then idk?
2021-06-11 23:22:05 <Ariadne> ericonr: it does have, but bootstrapping the compiler is a lot of work that i want to hold off on until we get 3.14 out the door
2021-06-12 06:29:08 <wener> hi, can someone help review !22227 , tested on several hosts, if entered testing I can install on more hosts.
2021-06-12 06:45:01 <wener> USE_EFI install report Partition id vfat not supported, from here https://github.com/alpinelinux/alpine-conf/blob/master/setup-disk.in#L123 , dose this matter ?
2021-06-12 06:54:08 <kunkku> ikke: yes, but the version button and dropdowns did not have any effect on what was shown
2021-06-12 06:54:42 <kunkku> it showed v3 despite selecting v1, v2, or latest
2021-06-12 06:56:07 <kasper81> hi, can anyone please review my MR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22217 (need it on riscv64 which it supports)
2021-06-12 07:02:56 <mps> !22217
2021-06-12 07:05:25 <mps> it is quite funny to see peoples approval of their MRs :) 
2021-06-12 07:05:54 <mps> this button should be called 'self booster'
2021-06-12 07:06:24 <mps> actually, 'misleading self booster'
2021-06-12 07:15:37 <kasper81> heh, github has a button "(re)request review" to send a reminder to reviewers. i feel like jerk @'ing people in MRs.. or maybe i am that desperate to compile julia runtime on riscv64.. :D 
2021-06-12 07:16:50 <ikke> would be fun to turn into some kind of 'useless button'
2021-06-12 07:17:17 <Cogitri> kasper81: Could you please squash those two commits into one?
2021-06-12 07:30:53 <kasper81> Cogitri: sure, it's done :) 
2021-06-12 07:31:52 <Cogitri> Thanks, merged
2021-06-12 07:32:16 <kasper81> Thank you!
2021-06-12 09:33:56 <clandmeter> kasper81: will probably take some time before the builder builds it and eventually uploads it.
2021-06-12 10:09:03 <donoban> well here is my attemp to have a cleaner pam configuration !22259
2021-06-12 11:10:27 <donoban> auth.warn elogind-daemon[4002]: Failed to create inotify watch on /dev/null/utmp, ignoring: Not a directory
2021-06-12 11:10:39 <donoban> this is like the error that firejail had
2021-06-12 15:47:39 <clandmeter> Ariadne: ping
2021-06-12 18:12:12 <skarnet> why does elogind-daemon create an inotify watch on the utmp file in the first place
2021-06-12 18:12:27 <skarnet> burn it with holy fire
2021-06-12 18:15:07 <ericonr> skarnet: https://bsd.ac/jh3ycr4
2021-06-12 18:16:47 <skarnet> as usual they don't address the real problem
2021-06-12 18:17:58 <skarnet> well the real problems
2021-06-12 18:19:50 <skarnet> breaking the utmp abstraction with a non-portable Linux construct to work around a PAM thing, all because you want to control processes that have nothing to do with you
2021-06-12 18:20:19 <skarnet> and the question, Alex, is "how much suck can you pack in one line of code?"
2021-06-12 18:20:59 <skarnet> they attempted to bring all the suck at once
2021-06-12 18:22:03 <skarnet> if that is what the Linux desktop is made of, I can't possibly see a reason why we haven't gotten the year of the Linux desktop yet
2021-06-12 22:44:02 <Ariadne> clandmeter: pong
2021-06-12 22:45:39 <clandmeter> no worries, already pushed something to gcc
2021-06-13 07:27:55 <mps> aarch64 CI is stuck?
2021-06-13 07:31:19 <ikke> No, just busy
2021-06-13 07:31:49 <ikke> But airsonic is taking it's sweet time
2021-06-13 07:32:38 <mps> aha
2021-06-13 07:33:22 <mps> 6 hours?! (:
2021-06-13 07:35:29 <ikke> yea :-/
2021-06-14 00:33:12 <dalias> is python supposed to still be a symlink to python2 on alpine?
2021-06-14 00:33:21 <dalias> or is that some cruft that didnt get upgraded right?
2021-06-14 00:45:58 <c705> dalias: yeah that's been annoying for me. i ended up making an alias
2021-06-14 00:47:52 <dalias> ok i wondered if it was the cause of my breakage, but no, it was just stupid version skew
2021-06-14 00:48:24 <dalias> apk add py3-setuptools effectively did nothing because it installed a version of setuptools for a newer python i didn't have >_<
2021-06-14 01:59:00 <craftyguy> mps: I'd like to revive this somehow, maybe not a new package like in the MR, but would merging this with the main u-boot package be acceptable?
2021-06-14 01:59:13 <craftyguy> mps: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12358
2021-06-14 02:02:57 <craftyguy> it kinda seems like the only change in the main/u-boot package would be signing the odroid-c2 u-boot with amlbootsig (based on my 5 minutes of looking at it, with no testing yet :P)
2021-06-14 03:43:14 <maxice8> dalias: I originally tried to make python->python3 but it broke some aports, I now want to completely remove cmd:python after python2 is removed
2021-06-14 06:05:56 <mps> good morning
2021-06-14 06:06:41 <mps> 3.14-release today will be?
2021-06-14 06:08:13 <mps> today is 14 jun
2021-06-14 06:09:55 <ikke> Did you test rc2?
2021-06-14 06:10:25 <mps> no, but I'm running edge on few machines
2021-06-14 06:10:45 <mps> I count it as good testing
2021-06-14 06:13:21 <mps> anyway, I made few MRs which would be good for 3.14 imo
2021-06-14 06:13:27 <mps> !22302
2021-06-14 06:14:02 <mps> as usual postfix upstream is late with release notes
2021-06-14 06:15:05 <mps> !22301 will be good for stable release, it doesn't rev deps on any libs so no risk to merge
2021-06-14 06:16:38 <mps> also, !22286 doesn't change much except I'm not sure to enable this, but from bug/wish report it is useful for eduroam
2021-06-14 06:17:23 <mps> ncopa: all these are assigned to you. what you think about them
2021-06-14 06:19:28 <mps> !12358
2021-06-14 06:22:41 <mps> craftyguy: could this be 'integrated' somehow in main/u-boot pkg
2021-06-14 06:23:10 <mps> if not then we can merge it in testing
2021-06-14 06:23:54 <craftyguy> mps: yeah I played around a bit after that message.. it would make building a working u-boot for that board a bit more complicated than the other u-boot images (but not super complicated)
2021-06-14 06:25:27 <mps> understand. if it complicates main/u-boot then is separate pkg maybe is better idea
2021-06-14 06:25:38 <craftyguy> in theory I could do something like: 1) update the ATF package in aports to build ATF for this board, 2) main/u-boot package depends on ATF, 3) build fip_create in u-boot, 4) include ATF + u-boot for that board into a single image, 5) sign it almbootsig
2021-06-14 06:26:00 <craftyguy> steps 2-5 would be in the main/u-boot.. so maybe that's a bit much
2021-06-14 06:26:14 <mps> looks like you are right
2021-06-14 06:27:14 <mps> should we make these changes after 3.14 or it is urgent now
2021-06-14 06:27:29 <craftyguy> oh it can be after 3.14. not urgent
2021-06-14 06:27:55 <mps> good, hope we will not forget
2021-06-14 06:28:08 <craftyguy> this board sitting on my desk won't let me forget :P
2021-06-14 06:28:38 <craftyguy> "fiiiix meeee" -odroid c2 on craftyguy's desk
2021-06-14 06:32:25 <mps> :)
2021-06-14 07:38:54 <ncopa> good morning
2021-06-14 07:41:06 <Cogitri> Morning 👋
2021-06-14 07:43:58 <ncopa> whats up with community/java-jffi? has it hang or is it just slow?
2021-06-14 07:53:29 <wener> k0s still not in testing yet 🤔
2021-06-14 07:53:56 <wener> good afternoon
2021-06-14 07:56:43 <clandmeter> PureTryOut: i moved python the makedepends for now. if you want to fix it another way please do.
2021-06-14 07:56:55 <PureTryOut> That's fine, thanks!
2021-06-14 08:24:54 <craftyguy> Cogitri: any chance you'd have time soon to review this? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21893
2021-06-14 08:30:49 <ncopa> wener: yeah :-/ it is relatively easy to use the manually downloaded binary though. I think you (still) need to `apk add coreutils findutils iptables`
2021-06-14 08:31:31 <ncopa> any blockers for rc3?
2021-06-14 08:32:05 <wener> useed to download k3s binary, but after I can apk add k3s, never look back.
2021-06-14 08:33:05 <ncopa> so if you could `apk add k0s` you'd consider using that instead of k3s?
2021-06-14 08:33:37 <Cogitri> craftyguy: Done
2021-06-14 08:33:54 <craftyguy> Cogitri: thank you :)
2021-06-14 08:54:01 <liske> ncopa: should !22226 merged for 3.14 to improve ipv6 setups
2021-06-14 09:05:32 <wener> maybe, at least easier to try k0s
2021-06-14 10:41:32 <clandmeter> ncopa: what does it need to introduce a new arch for docker? does it need stable releases?
2021-06-14 10:43:57 <ikke> clandmeter: they need to have hardware to build for that arch
2021-06-14 10:44:36 <ikke> https://github.com/alpinelinux/docker-alpine/pull/148
2021-06-14 10:48:08 <clandmeter> aha
2021-06-14 10:48:17 <clandmeter> i thought they already support riscv64 for other projectrs
2021-06-14 10:48:32 <donoban> skarnet: regardless elogin is doing something bad with utmp, the fact that it looks for it on /dev/null/utmp instead the right place, can't afect to other programs too? Well, I remeber that you said that no program should access that file directly... 
2021-06-14 10:50:22 <ikke> clandmeter: Perhaps they do: https://hub.docker.com/u/riscv64
2021-06-14 10:57:49 <clandmeter> ikke: i dont think so https://github.com/docker-library/official-images#architectures-other-than-amd64
2021-06-14 10:58:29 <ikke> Ah, so I guess debian created the riscv64 user
2021-06-14 11:01:31 <clandmeter> https://github.com/docker-library/official-images/issues/8794
2021-06-14 11:56:04 <clandmeter> looks like nodejs-current needs some love for riscv64
2021-06-14 12:02:18 <skarnet> donoban: exactly, the fact that it uses /dev/null/utmp shows that it looks for the utmp file directly with _PATH_UTMP which no program should ever do, and it is difficult to patch for utmps because _PATH_UTMP is defined in <paths.h> which is a compatibility header in musl that programs should avoid using and utmps cannot modify the definition there
2021-06-14 12:03:05 <skarnet> the functionality should be redesigned entirely
2021-06-14 12:13:34 <donoban> gotcha
2021-06-14 12:21:25 <PureTryOut> Any big blockers for Alpine 3.14 still? ncopa what's left to do?
2021-06-14 12:28:22 <ncopa> current blocker is making the builds pass
2021-06-14 12:28:53 <ncopa> im looking at the pdns test suite for s390x now
2021-06-14 12:30:26 <ikke> can replace= also be used for partial replacements? (ie setup-tools being split off from python3?
2021-06-14 12:30:30 <ikke> replaces*
2021-06-14 12:30:46 <Ariadne> yes
2021-06-14 12:31:08 <ncopa> yes
2021-06-14 12:31:10 <ikke> ok, seems like we need to add that then
2021-06-14 12:31:36 <ncopa> hm.. i think luajit might be broken for s390x
2021-06-14 12:31:50 <ncopa> pdns testsuite fails
2021-06-14 12:32:02 <ncopa>    193  unknown location(0): ^[[4;31;49mfatal error: in "lua_auth4_cc/test_prequery": memory access violation at address: 0xde256c3300000000: no mapping at fault address^[[0;39;49m
2021-06-14 12:33:56 <PureTryOut> Ah fun
2021-06-14 12:35:04 <Habbie> hello
2021-06-14 12:35:09 <Habbie> i wrote that test
2021-06-14 12:35:22 <ncopa> hi Habbie
2021-06-14 12:35:36 <Habbie>  grep s390 Dockerfile-auth 
2021-06-14 12:35:38 <Habbie> ENV NO_LUA_JIT="s390x arm64"
2021-06-14 12:35:40 <Habbie> and i put this in our dockerfile
2021-06-14 12:35:43 <Habbie> so you can stop digging :)
2021-06-14 12:36:04 <ncopa> so basically disable luajit for s390x
2021-06-14 12:36:11 <Habbie> for pdns/recursor/dnsdist, anyway
2021-06-14 12:36:19 <Habbie> not all software suffers from broken lightuserdata in luajit on some platforms
2021-06-14 12:36:38 <ncopa> i was about to disable pdns alltogether for s390x
2021-06-14 12:37:00 <PureTryOut> e8: any clue how I can get apkbuild-lint to stop complaining about riscv64 being in `arch=""`? https://gitlab.alpinelinux.org/alpine/aports/-/jobs/414700#L160
2021-06-14 12:37:04 <Habbie> the dnsdist port already has jit/non-jit flavours, that would also be the best solution here
2021-06-14 12:37:54 <PureTryOut> e8: oh actually, found the source already, I'll make a MR
2021-06-14 12:37:58 <ncopa> im disabling it for now
2021-06-14 12:38:04 <Habbie> ok
2021-06-14 12:38:14 <maxice8> <PureTryOut "e8: any clue how I can get apkbu"> https://gitlab.alpinelinux.org/Leo/atools/-/blob/master/apkbuild-lint#L98
2021-06-14 12:38:27 <Habbie> what's the deadline for somebody (say, me) PRing a jit/nonjit split?
2021-06-14 12:38:59 <ikke> PureTryOut: e8?
2021-06-14 12:39:11 <PureTryOut> that's Leo, or maxice8.
2021-06-14 12:39:11 <ikke> truncated maxice8's name?
2021-06-14 12:39:21 <PureTryOut> Their Matrix display name
2021-06-14 12:44:52 <PureTryOut> e8: https://gitlab.alpinelinux.org/Leo/atools/-/merge_requests/50
2021-06-14 12:45:26 <maxice8> thank you, I received an email about it
2021-06-14 12:46:35 <Ariadne> Habbie: this looks like an endianness issue
2021-06-14 12:47:05 <Habbie> it's not, the problem is that lightuserdata addresses in that version of luajit are truncated from 64 to 47 bits
2021-06-14 12:47:20 <Habbie> interestingly, debian bullseye's luajit appears to be fine
2021-06-14 12:47:26 <ncopa> Habbie: i was hoping to get the release out tomorrow
2021-06-14 12:47:28 <Habbie> so i wonder if they imported a patch or if alpine should get a new luajit
2021-06-14 12:47:33 <PureTryOut> Thanks for merging so quick e8!
2021-06-14 12:47:49 <Habbie> ncopa, i see - and would that mean 3.14 has no pdns for s390x forever? until 3.15 comes out?
2021-06-14 12:48:04 <ncopa> but nothing prevents us to re-eneable pdns whenever it is done and backport for 3.14
2021-06-14 12:48:07 <Habbie> ok
2021-06-14 12:48:10 <Habbie> perfect
2021-06-14 12:48:41 <maxice8> PureTryOut: it was a quick but a very poor merge, didn't follow the commitstyle so my changelog-generator missed it
2021-06-14 12:48:53 <Habbie> ncopa, and, to be clear, you're disabling pdns -only- for s390x now?
2021-06-14 12:49:03 <PureTryOut> e8: ouch, sorry for that. Idk about any commitstyle
2021-06-14 12:49:24 <maxice8> no worries I edited the changelog by hand
2021-06-14 12:49:46 <ncopa> Habbie: correct
2021-06-14 12:49:50 <Habbie> ncopa, thanks
2021-06-14 12:53:54 <Habbie> ah! main/luajit is openresty's fork of luajit
2021-06-14 12:56:06 <Habbie> but that fork, at the version used in main/luajit, -should- have working lightuserdata on s390x
2021-06-14 12:56:10 <Habbie> now i'm confused again
2021-06-14 13:18:28 <PureTryOut> Huh, riscv64 builder fails to build dockviz because of missing dependency containerd, but that dep is enabled on riscv64
2021-06-14 13:18:44 <ncopa> mps: did we have an open issue for armv7 release iso image?
2021-06-14 13:19:04 <ikke> PureTryOut: it's due ap missing dependencies
2021-06-14 13:19:18 <ikke> the dependencies are declared in subpackages, which is doesn't pick up
2021-06-14 13:19:23 <ikke> so the order is incorrect
2021-06-14 13:19:51 <ncopa> depends in subpackages needs to be in makedepends
2021-06-14 13:20:03 <PureTryOut> Ah, fun
2021-06-14 13:20:39 <ncopa> otherwise there is no way to figure out the build order properly. the split function runs after the build happened
2021-06-14 13:20:56 <PureTryOut> Not if it's a runtime dependency though
2021-06-14 13:21:38 <ncopa> well, even for runtime deps
2021-06-14 13:22:01 <PureTryOut> This particular package doesn't have subpackages though, and neither does ap
2021-06-14 13:22:07 <ncopa> what if other package needs that runtime at build time?
2021-06-14 13:22:08 <ikke> ap recursive-deps dockviz does not return containerd
2021-06-14 13:22:15 <ncopa> which package is it?
2021-06-14 13:22:20 <mps> ncopa: I can't remember I saw it, we just talked here about this idea
2021-06-14 13:22:20 <PureTryOut> dockviz
2021-06-14 13:23:04 <ikke> the builders struggle with it as well, try to build it many times until docker has been built
2021-06-14 13:23:35 <ncopa> oh, its docker thats broken
2021-06-14 13:23:39 <ikke> yes
2021-06-14 13:23:56 <ikke> engine depends on containerd
2021-06-14 13:24:05 <ikke> but only in a subpkg
2021-06-14 13:25:06 <PureTryOut> Ah...
2021-06-14 13:25:16 <ncopa> https://tpaste.us/raKz
2021-06-14 13:25:40 <ikke> nice
2021-06-14 13:26:05 <ikke> Will probably help a lot when building 3.15 :P
2021-06-14 13:27:30 <ncopa> i pushed fix
2021-06-14 13:28:00 <ncopa> should probably do the same with cli subpkg but ca-certificates was already in endinge's deps
2021-06-14 14:11:20 <PureTryOut> Oh fun, got bad signature on pipewire on x86_64 now...
2021-06-14 14:19:32 <ncopa> PureTryOut: f346747a53fcbe221714fea6f5e5143f67bc19d5 should have bumped pkgrel
2021-06-14 14:19:52 <PureTryOut> Oh shit I thought it did, guess that got lost in the rebase
2021-06-14 14:19:56 <PureTryOut> Will bump, thanks for pointing it out
2021-06-14 14:20:33 <ncopa> i think i have lost pkgrel bump in rebases in the past
2021-06-14 14:21:45 <ikke> ncopa: but how was it rebuilt without the bump?
2021-06-14 14:21:58 <ncopa> new subpackages
2021-06-14 14:22:11 <ikke> oh, right
2021-06-14 14:22:21 <ncopa> ap will detect that something is missing for that aport and trigger build
2021-06-14 14:22:49 <donoban> I would like to hear some comments about !22259 (altought I know that there aren't many PAM friends here :D)
2021-06-14 14:23:44 <donoban> Also maybe a "big" rewrite of this is dangerous for 3.14 but at least there are some "bugs" that could be fixed
2021-06-14 14:24:20 <ncopa> pam has been one of those things that i don't mind are there as long as i dont need to maintain it :)
2021-06-14 14:24:37 <donoban> hehe
2021-06-14 14:25:10 <ncopa> donoban: i appreciate that someone else takes care to clean it up, but im not the right person to review it
2021-06-14 14:25:23 <ncopa> scary stuff
2021-06-14 14:25:56 <clandmeter> ikke: i think riscv64 had an issue with containerd
2021-06-14 14:26:01 <clandmeter> i had to kill it iirc
2021-06-14 14:26:04 <donoban> yep, well maybe I get some consensus with Cogitri 
2021-06-14 14:26:38 <Cogitri> Ah?
2021-06-14 14:27:03 <donoban> the linux-pam default config
2021-06-14 14:27:22 <clandmeter> it would be really nice if abuild would have some sort of timeout with an option to disable it for larger projects
2021-06-14 14:28:15 <ncopa> PureTryOut: is pipewire fix far away? i'd like to tag rc3 now
2021-06-14 14:28:29 <clandmeter> https://build.alpinelinux.org/buildlogs/build-edge-riscv64/community/containerd/containerd-1.5.1-r1.log seemed to hang on go-md2man
2021-06-14 14:28:48 <Cogitri> donoban: Ah, yes, I'll need to get around to testing all the different DMs to make sure we don't blow up something in the rocess
2021-06-14 14:28:53 <Cogitri> I hope I have time to that during the weekend
2021-06-14 14:28:53 <PureTryOut> ncopa: far away? It's done already
2021-06-14 14:29:18 <PureTryOut> Repos haven't been updated yet though
2021-06-14 14:29:22 <ncopa> ok. good thanks
2021-06-14 14:29:33 <ncopa> something is blocking the CI
2021-06-14 14:29:56 <donoban> Cogitri: oh great, are you ok adding a 'system-local-login' which only incudes the respective base-XXXX ?
2021-06-14 14:30:23 <ikke> 11 jobs running
2021-06-14 14:30:36 <Cogitri> donoban: As long as it doesn't break anything
2021-06-14 14:30:42 <ikke> mariadb and ghc10 >1h
2021-06-14 14:30:49 <Cogitri> I have to admit I don't have an amazing understanding of pam either
2021-06-14 14:32:21 <donoban> well, I started to read some days ago trying to enable faillock plugin, and I think that it could be more simpler than it's currently
2021-06-14 14:33:47 <donoban> well ping me if you have some problem when testing it
2021-06-14 14:33:48 <donoban> :)
2021-06-14 14:34:03 <mps> I'm short on time last days but I can help with linux-pam
2021-06-14 14:34:32 <mps> git rm linux-pam :P
2021-06-14 14:34:35 <donoban> mps: apk del linux-pam :D
2021-06-14 14:34:37 <donoban> hahaha
2021-06-14 14:36:05 <ikke> clandmeter: almost looks like go-md2man is waiting for input
2021-06-14 14:36:20 <clandmeter> im building it manually now
2021-06-14 14:36:29 <clandmeter> maybe its tty?
2021-06-14 14:36:38 <clandmeter> not sure i enabled it
2021-06-14 14:36:50 <ikke> but go-md2man itself did build, right?
2021-06-14 14:37:02 <ikke> it itself also generates it's own man page
2021-06-14 14:38:15 <clandmeter> yes
2021-06-14 14:38:23 <clandmeter> and now it also builds containerd
2021-06-14 14:38:47 <clandmeter> i think qemu-user still gets it wrong from time to time.
2021-06-14 14:39:07 <clandmeter> but its like 90% better than before
2021-06-14 14:41:54 <PureTryOut> 🎉
2021-06-14 14:42:01 <PureTryOut> So many packages to touch for riscv64 though 😢
2021-06-14 14:43:04 <clandmeter> i had hopes nodejs-current would build as LTS version does not have riscv64 support, but it returns errors that are beyond my knowledge :)
2021-06-14 14:45:47 <PureTryOut> Have you had luck bootstrapping Rust yet?
2021-06-14 14:49:07 <ikke> We did have fun bootstrapping our CI images :P
2021-06-14 14:53:24 <ncopa> a couple of those would be great for riscv: https://www.sifive.com/boards/hifive-unmatched
2021-06-14 14:54:44 <ncopa> ok, im tagging rc3
2021-06-14 14:54:46 <Cogitri> Certainly
2021-06-14 14:56:24 <ncopa> can we do the 3.14.0 release tomorrow?
2021-06-14 15:00:37 <clandmeter> for anyone interested in nodejs on riscv64, here is the log https://tpaste.us/maQd
2021-06-14 15:01:25 <PureTryOut> 3.14.0 tomorrow would be great!
2021-06-14 15:01:32 <fcolista> <3
2021-06-14 15:01:43 <PureTryOut> ncopa: https://riscv.org/blog/2021/04/risc-v-is-giving-away-developer-boards/
2021-06-14 15:02:54 <tomalok> getting packer moved from testing to community would be handy for some ideas i have for building cloud images -- https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22307
2021-06-14 15:03:29 <tomalok> also, curious if this is waiting for post-3.14?  https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21516
2021-06-14 15:08:12 <ncopa> tomalok: sorry i didnt see that. woudl be nice to have in 3.14
2021-06-14 15:08:38 <ncopa> tomalok: we normally add new packages to testing first
2021-06-14 15:09:37 <tomalok> i can switch buildx over to testing for a bit if you'd prefer
2021-06-14 15:10:00 <ncopa> nah
2021-06-14 15:10:06 <ncopa> lets make an exception
2021-06-14 15:10:26 <ncopa> and lets hope it does not break anything :)
2021-06-14 15:10:47 <tomalok> :fingers-crossed:
2021-06-14 15:11:21 <ncopa> tomalok: feel free to ping me if you have MRs that cloud team needs. we should prioritize stuff for our own teams, infra, cloud, etc
2021-06-14 16:35:53 <mps> ncopa: armv7 virt iso is good starting point. serial console should ttyAMA0 instead of ttyS0
2021-06-14 16:36:37 <mps> and quiet option should be removed from it (as I think in all our releases)
2021-06-14 16:37:45 <mps> but armv7 lts virt kernel need some additions in config, but now you motivated me to finally add all minimum needed changes
2021-06-14 17:35:31 <ikke> hmm, running into a race condition with abuild-keygen -i
2021-06-14 17:35:49 <ikke> it passes -i to cp
2021-06-14 17:36:00 <ikke> in my test suite, apparently it generates the same keyname
2021-06-14 17:36:04 <ikke> and hangs
2021-06-14 17:44:35 <ikke> sed -i 's/cp -i/cp/' /usr/bin/abuild-keygen  :P
2021-06-14 17:46:33 <ikke> Cogitri: ping
2021-06-14 17:46:58 <Cogitri> pong
2021-06-14 17:47:22 <ikke> For CI, it was easier if the logs had a predictable names, right?
2021-06-14 17:50:02 <Cogitri> Yup, so we can use https://docs.gitlab.com/ee/api/job_artifacts.html#download-a-single-artifact-file-by-job-id
2021-06-14 17:50:11 <ikke> ok
2021-06-14 17:50:21 <Cogitri> Instead of downloading the entire zip every time (which also includes the apk packages)
2021-06-14 17:50:26 <ikke> yes, understood
2021-06-14 17:50:57 <ikke> I guess I should include some kind of marker to distinguish between packages?
2021-06-14 17:54:48 <Cogitri> Hm, either that or we have one file with some kind of marker to distinguish between them
2021-06-14 17:55:34 <Cogitri> Or we make it JSON :D 
2021-06-14 17:55:48 <ikke> heh
2021-06-14 17:55:49 <Cogitri> With {"pkgname": string, "diff": string}
2021-06-14 17:57:46 <Cogitri> But either works for me, either checkapk-[1,2,...N].txt or checkapk.txt with some kind of format
2021-06-14 18:01:57 <ikke> Why do I, since a while, need to specify MANPAGER=less in docker containers
2021-06-14 18:14:07 <ikke> [{"pkgname":"base-package","checkapk":"--- filelist-base-package-old\n+++ filelist-base-package\n@@ -0,0 +1,2 @@\n+.PKGINFO\n+.dummy"}] :D
2021-06-14 18:15:24 <DylanVanAssche> Does the x86 builder has less memory than the other builders?
2021-06-14 18:15:24 <DylanVanAssche> I get an out-of-memory error when building `nomad` on x86: https://gitlab.alpinelinux.org/dylanvanassche/aports/-/jobs/415180
2021-06-14 18:15:24 <DylanVanAssche> If it is not the builder, it's just the package itself then...
2021-06-14 18:17:00 <ikke> DylanVanAssche: https://tpaste.us/9j4K 
2021-06-14 18:17:11 <ikke> DylanVanAssche: are you running into address space limits?
2021-06-14 18:17:29 <ikke> 32-bits can use max ~4g per process
2021-06-14 18:19:04 <DylanVanAssche> ikke: Maybe... It's some JS UI that needs building.
2021-06-14 18:19:04 <DylanVanAssche> I don't need x86 32bit, only armv7, but maybe somebody else needs it, that's why I enabled x86 and others as well.
2021-06-14 18:19:04 <DylanVanAssche> It might be that it needs > 4GB/process, there's not much to do about that if it is in the JS build process
2021-06-14 18:20:21 <ikke> https://stackoverflow.com/questions/38558989/node-js-heap-out-of-memory#38560292
2021-06-14 18:22:32 <ikke> So it seems it's an internal nodejs limit
2021-06-14 18:22:55 <DylanVanAssche> Yeah that's maybe an option, but I don't feel comfortable patching a Makefile for this.
2021-06-14 18:22:55 <DylanVanAssche> Almost all arches where disabled for this package, not enabling x86 isn't going to be a problem
2021-06-14 18:23:24 <ikke> alright, but now you at least know what might cause it
2021-06-14 18:24:26 <DylanVanAssche> True 🙂 can come in handy for the future, thanks!
2021-06-14 19:43:33 <ikke> ugh, flaky tests :-.
2021-06-14 20:52:55 <mps> ncopa: in case you are online, https://tpaste.us/X1V1
2021-06-14 20:53:50 <mps> with these changes I booted linux-lts virt armv7 and got 6GB RAM on VM and virtio-net driver works
2021-06-15 03:01:05 <LACampbell> how hard is to make an alpine package and maintain it? I've got a basic grasp of linux but not an expert.
2021-06-15 03:01:30 <valerius> there is one way to find out... just do it
2021-06-15 03:01:57 <valerius> keep it in your own fork of aports for awhile and see how it goes
2021-06-15 03:02:03 <craftyguy> ^^
2021-06-15 03:02:42 <craftyguy> as far as packaging goes, alpine is one of the easiest to create/maintain packages for (assuming the thing you want to package doesn't have any glibc-ism that it can't shake...)
2021-06-15 03:12:19 <LACampbell> alright I'll just see if I'm capable. first road block I ran across was it needed a slightly older version of a package that was already in the repo
2021-06-15 03:25:47 <valerius> ideally, if you find glibc-dependent packages, fix it and create a pull request
2021-06-15 03:26:06 <valerius> I do it all the time, sometimes with good results and sometimes with maintainers not giving a damn
2021-06-15 03:26:38 <LACampbell> all dependencies were already in the alpine repos. just to build the latest stable it asked for slightly older versions. I'll see if that's possible
2021-06-15 03:53:15 <dalias> uhg, some other shit forcing boost to upgrade broke my openscad
2021-06-15 03:53:27 <dalias> and til there's a package for openscad... but it's 2 years outdated :/
2021-06-15 03:53:40 <dalias> any chance someone could bump it to current?
2021-06-15 04:15:03 <maxice8> Looking at it
2021-06-15 04:30:52 <dalias> thanks!
2021-06-15 05:06:24 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22351
2021-06-15 05:54:23 <ikke> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12756 ~
2021-06-15 05:54:26 <ikke> https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/27
2021-06-15 06:35:02 <ncopa> good morning
2021-06-15 06:36:18 <ncopa> ikke: wow! you have almost done all the work :)
2021-06-15 06:36:30 <ncopa> im gonna make some coffe. I think this will be a good day :)
2021-06-15 06:36:48 <ikke> Just the preparation work :)
2021-06-15 06:37:02 <ikke> The release notes still need to be expanded
2021-06-15 06:40:41 <wener> can help review !22341 ?, want to catch 3.14 😬
2021-06-15 06:50:41 <wener> thanks
2021-06-15 06:53:54 <mps> ncopa: did you noticed this https://tpaste.us/X1V1
2021-06-15 07:13:45 <mps> what to use as boot loader for rv64? u-boot because it is simple?
2021-06-15 07:16:52 <mps> and what is issue with autoconf tools on riscv64, anyone knows
2021-06-15 07:18:30 <ncopa> mps: no i didnt notice it. sorry
2021-06-15 07:20:00 <clandmeter> do we want to mention preliminary riscv64 support, or should we do that in a dedicated item?
2021-06-15 07:20:40 <ikke> This post is about 3.14, which does not include riscv64, so I would say, a separate post
2021-06-15 07:22:16 <mps> ncopa: with this patch linux-lts virt armv7 boots fine with more ram (tested with 6GB) and virtio-net device
2021-06-15 07:23:30 <mps> now you have to decide will it be in 3.14
2021-06-15 07:27:23 <mps> we can't add rv64 kernel to aports till we have builder? right?
2021-06-15 07:27:57 <clandmeter> ikke: the first in the v3.13 stable series
2021-06-15 07:28:12 <ikke> Ah, was likely to miss something
2021-06-15 07:28:19 <ikke> feel free to fix
2021-06-15 08:37:24 <ncopa> mps: there is no explanation in commit message why CONFIG_PREEMT=y on virt kernel on armv7 while its disabled on every other architecture
2021-06-15 08:37:37 <ncopa> mps: there are so many questions about that commit
2021-06-15 08:38:45 <ncopa> also what is CONFIG_ARCH_VIRT needed for?
2021-06-15 08:41:00 <mps> ncopa: with CONFIG_PREEMPT=y it runs fasters, nothing else
2021-06-15 08:41:37 <ncopa> also why is driver for ARM AMBA PL030 RTC needed on virt kernel?
2021-06-15 08:41:54 <mps> CONFIG_ARCH_VIRT server to specify '-machine virt' in qemu parameters and to use virt machine emulation
2021-06-15 08:42:29 <mps> PL030 is qemu emulated RTC driver
2021-06-15 08:42:55 <rzl[m]> Good morning!
2021-06-15 08:43:14 <ncopa> would be nice to have all those details in the commit message
2021-06-15 08:43:21 <ncopa> rzl[m]: good morning
2021-06-15 08:43:45 <mps> describing all these in commit is bigger task than to make it working
2021-06-15 08:44:14 <rzl[m]> ncopa: Is there a reason for CONFIG_BPF_SYSCALL not to be enabled in linux-edge on x86_64?
2021-06-15 08:44:21 <mps> and everyone can easily find these things in kernel source
2021-06-15 08:44:28 <ncopa> mps: do you have any documentation that says that CONFIG_PREEMPT=y makes kernel run faster? also, why do we enable it only for -virt on armv7?
2021-06-15 08:45:02 <mps> find -name Kcongig | xargs grep CONFIG_YOU_WANT_TO_SEE
2021-06-15 08:45:21 <ncopa> mps: well, you make the review of the commit a bigger task for the reviewer than it is for you to make it working
2021-06-15 08:45:42 <mps> ncopa: I enabled CONFIG_PREEMPT=y on all flavors in linux-edge
2021-06-15 08:46:19 <mps> btw, PREEMPT will be default in new kernels
2021-06-15 08:46:24 <ncopa> rzl[m]: maybe ask mps
2021-06-15 08:46:40 <ncopa> mps: so we should enable it for all our flavors then, not only for -virt armv7
2021-06-15 08:46:54 <ncopa> i do not like sneaky changes
2021-06-15 08:46:55 <mps> rzl[m]: we are trying to escape BPF wherever we can
2021-06-15 08:47:55 <ncopa> the commit message says that the change is to allow more memory on armv7 virt kernel, but reality is that it tries to make it faster and enables missing rtc drivers
2021-06-15 08:47:56 <mps> ncopa: understand your POV, but we need virt armv7 to work ASAP
2021-06-15 08:48:13 <ncopa> then write a proper commit message
2021-06-15 08:48:20 <ncopa> i dont want spend the day on it
2021-06-15 08:48:25 <rzl[m]> mps: I see. I hit my nose on it since I can't run any containers via Docker if there's no bpf. I was wondering because -lts has it enabled, and -edge enables it on aarch64 and armv7
2021-06-15 08:48:26 <mps> you missed HIGHMEM and LPAE?
2021-06-15 08:48:31 <ncopa> mps: no ididnt
2021-06-15 08:48:54 <mps> these to enable usage RAM over 4GB
2021-06-15 08:49:02 <mps> two*
2021-06-15 08:49:14 <ncopa> those are ok. what i dont like is that you enable lots of other questionable stuff, or even valid stuff, but dont mention why in the commit message
2021-06-15 08:49:22 <ncopa> so i dont trust the commit
2021-06-15 08:49:29 <mps> ok
2021-06-15 08:49:38 <mps> I will not force it anymore
2021-06-15 08:49:43 <ncopa> i get the feeling that there are some other motives to get the changes included, motives that you dont want tell me
2021-06-15 08:50:01 <mps> no, I don't hide anything
2021-06-15 08:50:27 <ncopa> HIGMEM and LPAE changes are ok. i have questions about the other changes
2021-06-15 08:50:58 <mps> just don't have time (and patience maybe) to write about something obvious and easy to find in kernel docs
2021-06-15 08:51:27 <ncopa> if its so obvious and easy to find in kernel docs, why dont you mention it in the commit message
2021-06-15 08:51:54 <mps> maybe I'm just lazy :)
2021-06-15 08:51:58 <ncopa> i dont have time (and patience maybe) to investigate why all those changes are there
2021-06-15 08:52:09 <ikke> It would even make sense to separate changes into different commits
2021-06-15 08:52:18 <ncopa> exactly
2021-06-15 08:52:30 <ikke> Then its commit can have it's own dedicated message, and can be reverted separately if necessary
2021-06-15 08:52:52 <mps> ikke: no because it will take more time and more commits, which will be to late for 3.14
2021-06-15 08:52:57 <ncopa> mps: i already spent more than a full day cleaning up the qemu module split, because you didnt had time (or was lazy) to do the dependencies properly
2021-06-15 08:53:12 <ikke> mps: well, in this case it still gets delayed
2021-06-15 08:53:17 <ikke> because it's hard to review
2021-06-15 08:53:18 <ncopa> it is already late for 3.14
2021-06-15 08:53:37 <ncopa> i could spend a day to investigate why those changes are needed, and try to sync up the other kernel flavors/architectures
2021-06-15 08:53:39 <mps> ncopa: qemu is special case, I agree
2021-06-15 08:53:43 <ncopa> but it will take the rest of the day
2021-06-15 08:53:53 <ncopa> which means 3.14 will not happen today
2021-06-15 08:54:04 <mps> and as I wrote, you are not obliged to merge this
2021-06-15 08:54:30 <mps> I just posted it to you and asked *you* to decide what to do
2021-06-15 08:54:58 <ncopa> lets drop it. its a bad idea to merge this thing on release day
2021-06-15 08:55:03 <mps> actually, I don't need this, I use edge virt
2021-06-15 08:55:30 <mps> just wanted to help alpine users and developers, nothing else
2021-06-15 08:55:35 <ncopa> next time, please create an issue on bug tracker, or a merge request, with a milestone target
2021-06-15 08:55:49 <skarnet> what better day than release day to change the kernel config?
2021-06-15 08:56:28 <ncopa> mps: i appreciate that thanks, but please understand that i dont want to spend hours on fixing up the commit message for you
2021-06-15 08:56:36 <mps> I wonder if anyone can run current lts virt armv7 in qemu
2021-06-15 08:57:33 <mps> ncopa: np, I will step back from these things, and by this you will save me some time ;)
2021-06-15 08:58:00 <ncopa> is there an open issue for the memory problem for virt kernel?
2021-06-15 08:58:24 <ncopa> so it does not get forgotten. i dont read irc history often
2021-06-15 08:58:36 <ncopa> specially not when im stressed around release times
2021-06-15 09:23:57 <mps> rzl[m]: sorry, had to go to eat breakfast before it become cold
2021-06-15 09:25:06 <mps> I looked at MR and wanted to enable BPF_SYSCAL but missed/forgot it with last upgrade to 5.12.10
2021-06-15 09:25:30 <mps> hope will not forget it on next upgrade
2021-06-15 09:26:34 <rzl[m]> I'll rebase it
2021-06-15 09:26:36 <rzl[m]> Thanks
2021-06-15 09:28:32 <mps> you don't need to rebase (but you can if you want). I will try to remember ;)
2021-06-15 09:31:12 <ncopa> im tagging _rc4 now
2021-06-15 09:31:55 <ikke> Anyhting I can do to help in about ~1h?
2021-06-15 09:32:25 <ncopa> i wanted to test the rpi boot loader
2021-06-15 09:37:08 <ikke> I was thinking trying to test upgrading 3.13 to 3.14 with some popular things installed
2021-06-15 09:37:13 <mps> rzl[m]: in latest kernels BPF is inevitable anyway. even microsoft working on bpf for windows these days
2021-06-15 09:39:39 <rzl[m]> ikke: I upgraded from 3.13 to edge about two weeks ago, when I moved from Arch to Alpine as my daily driver. No issues
2021-06-15 09:40:07 <mps> ncopa: have to add that I didn't made mess qith latest qemu, I just upgraded it, and mess come from changes in new release
2021-06-15 09:41:28 <mps> only where I made mess is edk2, sorry for this
2021-06-15 09:42:05 <rzl[m]> mps: BPF is useful, why are you trying to avoid it? BTW, I rebased the MR but I made an oopsie and temporarily added commits that shouldn't have been there, so it gained a few extra tags
2021-06-15 09:42:46 <ncopa> oh, drats! i forgot about edk2
2021-06-15 09:43:34 <mps> BPF is 'can of worms' and we will see consequences in coming years
2021-06-15 09:45:35 <ncopa> mps: since you're lazy: #12758
2021-06-15 09:46:25 <ncopa> mps: I also did #12757 since you didnt have time for it and I dont want forget it
2021-06-15 09:46:41 <ikke> ncopa: what's up with ed2k?
2021-06-15 09:47:08 <mps> ncopa: :P
2021-06-15 09:47:30 <mps> ikke: Ariadne took over MR
2021-06-15 09:48:00 <mps> !20626
2021-06-15 09:48:01 <ncopa> this looks scary: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12752
2021-06-15 09:48:24 <mps> !12752
2021-06-15 09:48:30 <ncopa> is py3-setuptools broken?
2021-06-15 09:49:05 <ikke> there have been setuptools issues, yes
2021-06-15 09:49:22 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12604
2021-06-15 09:49:25 <ikke> for example
2021-06-15 09:49:58 <mps> 
ACTION goes to play with building riscv64 kernel

2021-06-15 10:34:41 <Ariadne> mps: yes, i am still trying to figure out why that edk2 internal program blows up violently :)
2021-06-15 10:40:07 <mps> Ariadne: yes, it is somewhat strange pkg and I sorry why I touched it at all. and I'm thankful you take it to try to fix
2021-06-15 10:42:33 <mps> what I need  to change to fix this 'abuild build' error: checking build system type... Invalid configuration `riscv64-alpine-linux-musl': machine `riscv64-alpine' not recognized
2021-06-15 10:43:11 <ncopa> did anyone test setup-alpine?
2021-06-15 10:43:23 <ncopa> seems like keyboard config is horribly broken
2021-06-15 10:48:19 <ncopa> yup. its broken. i dont think we can release with that
2021-06-15 10:53:04 <PureTryOut> mps: add `update_config_sub` and `update_config_guess` to the prepare function
2021-06-15 10:53:27 <ikke> ncopa: I did test it with rc1
2021-06-15 10:53:41 <mps> PureTryOut: thanks, will try now
2021-06-15 10:54:01 <ncopa> i tested it on rpi. the "no" keymap didnt work at all
2021-06-15 10:54:13 <ikke> I only tested us-us
2021-06-15 10:54:36 <ncopa> i know for sure that norwegian keyboard worked in 3.13
2021-06-15 10:54:59 <mps> PureTryOut: looks like this works
2021-06-15 10:55:12 <PureTryOut> Of course it does, we've done it for a ton of packages for riscv64 already 😜
2021-06-15 11:06:43 <ikke> ncopa: just tested rc4 setup-alpine, and with us-us it works
2021-06-15 11:06:57 <ncopa> does it work for any non-us keyboards?
2021-06-15 11:07:05 <ncopa> i think the us keyboard is the default
2021-06-15 11:07:46 <ikke> yeah
2021-06-15 11:09:15 <ikke> when does it fail? I tried nl-nl, and it seems to continue
2021-06-15 11:09:38 <ncopa> it does not fail. it passes without error, but keyboard is still us
2021-06-15 11:10:01 <ikke> aha, ok
2021-06-15 11:10:15 <ncopa> it says everythign is fine, sucessfully loaded no-no keyboard. but keymap is still us
2021-06-15 11:11:06 <ncopa> im trying to debug it here. zcat /etc/keymap/no.bmap.gz | loadkmap
2021-06-15 11:11:19 <ncopa> passess succesfully, but does not load norwegian keyboard
2021-06-15 11:18:28 <ncopa> hum. it does not seem to work with loadkeys from kbd either
2021-06-15 11:18:48 <ncopa> i wonder whats going on
2021-06-15 11:18:55 <ncopa> maybe its a missing kernel module?
2021-06-15 11:23:23 <PureTryOut> Hmm either the riscv64 builder is stuck or php7 just takes a long time to cross compile
2021-06-15 11:24:52 <ncopa> all keymaps are broken
2021-06-15 11:26:49 <ncopa> the size is 20
2021-06-15 11:27:13 <mps> i noticed some time ago this, and I used clean (text) keymaps to load it
2021-06-15 11:27:36 <mps> but don't know what is fix
2021-06-15 11:35:59 <ncopa> https://build.alpinelinux.org/buildlogs/build-3-14-x86_64/main/kbd/kbd-2.4.0-r0.log
2021-06-15 11:36:17 <ncopa> I wonder what this is: "Can not find file "rules/xorg" in any known directory"
2021-06-15 12:04:37 <donoban> I'm trying to build and I don't get that error
2021-06-15 12:14:47 <donoban> is there some official rc iso?
2021-06-15 12:16:30 <ikke> yes
2021-06-15 12:16:50 <ikke> https://dl-cdn.alpinelinux.org/alpine/v3.14/releases/x86_64/
2021-06-15 12:21:20 <donoban> thanks, I didn't find it through the web
2021-06-15 12:26:59 <ncopa> i cannot reproduce the error either
2021-06-15 12:31:55 <fcolista> ncopa, there's a patch here for kbd from redhat:
2021-06-15 12:31:55 <fcolista> https://bugzilla.redhat.com/show_bug.cgi?id=1950406
2021-06-15 12:32:43 <fcolista> -  ckbcomp "$XKBLAYOUT" "$XKBVARIANT" | gzip > $RPM_BUILD_ROOT%{kbd_datadir}/keymaps/xkb/"$XKBLAYOUT"-"$XKBVARIANT".map.gz
2021-06-15 12:32:43 <fcolista> +  ckbcomp -rules base "$XKBLAYOUT" "$XKBVARIANT" | gzip > $RPM_BUILD_ROOT%{kbd_datadir}/keymaps/xkb/"$XKBLAYOUT"-"$XKBVARIANT".map.gz
2021-06-15 12:33:08 <fcolista> that's redhat specific for rpm, wondering if kbd in alpine should be adjusted as well
2021-06-15 12:58:59 <mps> building rv64 in chroot with qemu-user on I3 machine is slow
2021-06-15 12:59:10 <mps> kernel*
2021-06-15 14:07:04 <ncopa> fcolista: thanks! i think we had same issue
2021-06-15 14:07:21 <ncopa> a rebuild of kbd seems to have solved it. i suspect that xkeyboard-config was broken
2021-06-15 14:09:58 <ncopa> ok! i think we are ready for 3.14 release tag?
2021-06-15 14:14:20 <mps> got alpine linux kernel running in qemu riscv64 'Linux localhost 5.12.10-0-riscv64 #1-Alpine SMP PREEMPT Tue, 15 Jun 2021 11:41:06 +0000 riscv64 Linux'
2021-06-15 14:20:32 <ncopa> liske: can #10237 be closed? or do you think it can be fixed for 3.14.1?
2021-06-15 14:23:02 <donoban> is it too late for trying to fix #12517 ?
2021-06-15 14:28:21 <ncopa> not for 3.14.1
2021-06-15 14:28:27 <ncopa> but for 3.14.0 it is
2021-06-15 14:28:45 <donoban> ok
2021-06-15 14:29:09 <ncopa> donoban: would be great if you could prepare a patch
2021-06-15 14:29:24 <donoban> yeah I'm digging into it
2021-06-15 14:29:52 <donoban> I had this problem when testing 3.14 rc
2021-06-15 14:30:19 <ncopa> mips64 is 86% done
2021-06-15 14:30:35 <ncopa> i wonder if i should wait for it to complete
2021-06-15 14:30:51 <ncopa> i guess its not worth wait another day (another week is not unlikely)
2021-06-15 14:31:28 <ncopa> i think the luajit implementation change was a bit unfortunate so late, but ok...
2021-06-15 14:32:05 <ncopa> if there are no complaints i'll just go ahead and tag 3.14.0
2021-06-15 14:32:22 <donoban> :)
2021-06-15 14:32:47 <ncopa> 10
2021-06-15 14:32:48 <ncopa> 9
2021-06-15 14:32:49 <ncopa> 8
2021-06-15 14:32:51 <ncopa> 7
2021-06-15 14:32:53 <ncopa> 6
2021-06-15 14:32:53 <ikke> ncopa: none of the tests are enabled, no real hardware to test on, so I would say, don't wait for risc
2021-06-15 14:32:55 <ncopa> 5
2021-06-15 14:32:57 <ncopa> 4
2021-06-15 14:32:59 <ncopa> 3
2021-06-15 14:33:01 <PureTryOut> Exciting 😃
2021-06-15 14:33:02 <ncopa> 2
2021-06-15 14:33:03 <ikke> WAIt
2021-06-15 14:33:05 <ikke> :p
2021-06-15 14:33:07 <ikke> NO
2021-06-15 14:33:08 <donoban> ouch
2021-06-15 14:33:09 <ikke> kidding
2021-06-15 14:33:11 <donoban> abort()
2021-06-15 14:33:12 <donoban> haha
2021-06-15 14:33:12 <PureTryOut> Don't you joke about that!
2021-06-15 14:33:15 <PureTryOut> exit 1
2021-06-15 14:33:17 <ncopa> ABORT!!!!
2021-06-15 14:33:32 <ncopa> what happened?
2021-06-15 14:33:39 <ikke> Sorry, couldn't help it
2021-06-15 14:33:44 <ikke> Go ahead
2021-06-15 14:33:46 <ncopa> riscv is late
2021-06-15 14:33:54 <ncopa> mips64 might come back in 3.14.1
2021-06-15 14:34:00 <ncopa> i guess i'll do another try
2021-06-15 14:34:04 <ncopa> 10
2021-06-15 14:34:06 <ncopa> 9
2021-06-15 14:34:07 <ncopa> 8
2021-06-15 14:34:08 <ncopa> 3
2021-06-15 14:34:10 <ncopa> 2
2021-06-15 14:34:13 <ncopa> 0!!!!
2021-06-15 14:34:14 <danieli> GOOOOO
2021-06-15 14:34:32 <ncopa> To gitlab.alpinelinux.org:alpine/aports.git
2021-06-15 14:34:33 <ncopa>  * [new tag]               v3.14.0 -> v3.14.0
2021-06-15 14:34:36 <danieli> nice counting by the way, 8 -> 3 :D
2021-06-15 14:34:47 <MY-R> one extra checklist thing: Add 3.13 and 3.14 to mirror-status list: https://gitlab.alpinelinux.org/alpine/infra/mirror-status/-/blob/master/apkindex.list
2021-06-15 14:34:50 <ncopa> yeah... i didnt want anyone have the chance to abort again
2021-06-15 14:34:57 <PureTryOut> Yay 🎉
2021-06-15 14:35:00 <donoban> hehe
2021-06-15 14:36:33 <donoban> one question, for 3.14.1 fixes is right to merge to edge?
2021-06-15 14:37:16 <PureTryOut> No 3.14 gets it's own branch
2021-06-15 14:37:16 <donoban> well, i suppose that all have to go to edge on a first step
2021-06-15 14:37:33 <PureTryOut> Exists already actually https://gitlab.alpinelinux.org/alpine/aports/-/tree/3.14-stable
2021-06-15 14:38:36 <donoban> so if I fix #12517 should I sent a MR for edge and other for 3.14?
2021-06-15 14:38:48 <donoban> s/sent/send
2021-06-15 14:38:48 <alpine-meetbot> donoban meant to say: so if I fix #12517 should I send a MR for edge and other for 3.14?
2021-06-15 14:40:19 <PureTryOut> Yeah sent it to both branches
2021-06-15 14:40:30 <donoban> ok
2021-06-15 14:55:42 <wener> 🎉🎉🎉
2021-06-15 14:57:44 <donoban> [donoban@localhost][~]% setup-apkrepos                                                                                             │
2021-06-15 14:57:45 <donoban> wget: server returned error: HTTP/1.0 418 I'm a teapot
2021-06-15 14:58:36 <wener> when will the release page get update ?
2021-06-15 14:59:21 <ikke> Soon (tm)
2021-06-15 14:59:29 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12756
2021-06-15 15:01:14 <wener> great, there used to a wiki page to pending release note
2021-06-15 15:01:32 <ikke> https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.14.0
2021-06-15 15:05:18 <wener> thnaks
2021-06-15 15:19:14 <kpcyrd> congratz for the release!
2021-06-15 16:12:38 <PureTryOut> gcc6 is failing on riscv64, but I don't think that version has support for that arch anyway right? So it can just be disabled?
2021-06-15 16:14:19 <ikke> probably. afaik it's there to bootstrap openjdk
2021-06-15 16:15:02 <PureTryOut> We use it at pmOS as well for shitty downstream Android kernels
2021-06-15 16:15:16 <PureTryOut> But we have no need for those on riscv ofc. OpenJDK however is useful
2021-06-15 16:27:12 <ikke> iirc there is another bootstrap path for openjdk as well, but not sure if that works for riscv64
2021-06-15 16:34:35 <PureTryOut> iirc there was/is a project that tries to bootstrap everything, so they have really old stuff bootstrapping more old stuff which eventually bootstraps the latest versions of things like Java, gcc, Rust, etc. I just can't for the life of me remember the name
2021-06-15 16:34:50 <PureTryOut> But I don't understand how they bootstrap it to arches that were never supported on the oldest stuff
2021-06-15 16:36:21 <ikke> I guess cross-compiling from other arches when they reached new enough versions?
2021-06-15 16:36:42 <ikke> I bet bootstrapping rust takes ages
2021-06-15 16:36:56 <PureTryOut> I suppose so but stuff like this, if there isn't another path, how would we bootstrap OpenJDK on a new arch like riscv64?
2021-06-15 16:37:23 <Cogitri> PureTryOut (matrix.org): You mean Guix?
2021-06-15 16:37:36 <PureTryOut> I'm not sure if it was any distro, but yeah might be
2021-06-15 16:38:33 <Cogitri> But for boostrapping things on new arches: You'd usually crosscompile at that point. E.g. with rust you'd do mrustc -> rust -> rust -> [...] -> rust on x86_64 and then bootstrap the latest rust for riscv
2021-06-15 16:40:26 <PureTryOut> So in this case use gcc6 from e.g. x86_64 for riscv64 OpenJDK for example?
2021-06-15 16:40:50 <PureTryOut> Unrelated question: is there a release post for Alpine 3.14 yet?
2021-06-15 16:41:17 <Cogitri> gcc6 -> openjdk some old version -> openjdk recent version -> openjdk riscv recent version I suppose
2021-06-15 16:41:25 <Cogitri> I don't really know how openjdk works though
2021-06-15 16:41:43 <ikke> PureTryOut: working on it
2021-06-15 16:41:51 <ikke> PureTryOut: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/27
2021-06-15 16:42:00 <PureTryOut> 👍️
2021-06-15 16:48:20 <wener> suggest mention haproxy 2.4, really big change
2021-06-15 16:48:58 <ikke> Ok
2021-06-15 16:50:10 <ikke> ncopa: Will you add the commit log statistics to the post?
2021-06-15 16:50:27 <ikke> Or should I do it?
2021-06-15 16:57:20 <ikke> Are the man-pages for git showing extraneous whitespace for others as well?
2021-06-15 17:05:13 <nero> can reproduce
2021-06-15 17:05:52 <nero> happens independently of TERM...
2021-06-15 17:12:44 <nero> ikke: are you onto it?
2021-06-15 17:14:09 <ikke> no, not atm
2021-06-15 17:37:45 <ikke> https://wwwtest.alpinelinux.org/posts/Alpine-3.14.0-released.html
2021-06-15 17:37:52 <ikke> Can you help review this?
2021-06-15 17:40:05 <nero> there are closing parentheses missing around the "more information" links
2021-06-15 17:43:24 <ikke> fixed
2021-06-15 17:44:06 <mps> ikke: postfix changed white/black lists to allow/deny list terminology
2021-06-15 17:44:56 <nero> as long as i dont have to rewrite the configs for it...
2021-06-15 17:46:54 <nero> if they think their performative wokeness will get them friends, they could also consider renaming the master.cf
2021-06-15 17:50:30 <ncopa> re docker version and libseccomp. should we also mention that it only affects kernel older than X (where X is the kernel that introduced faccessat2
2021-06-15 17:51:03 <ikke> ncopa: not sure if that matters
2021-06-15 17:51:16 <ikke> the problem is that libseccomp returns -EPERM no matter what
2021-06-15 17:51:16 <wener> Haproxy -> HAProxy ?
2021-06-15 17:51:30 <ikke> as far as I understood
2021-06-15 17:51:45 <ikke> which breaks the musl fallback
2021-06-15 17:51:50 <ikke> which expects -ENOSYS
2021-06-15 17:52:44 <ncopa> oh, ok. i thought it only happened when kernel returned -ENOSYS, so it woudl actually work when kernel had the syscall
2021-06-15 17:52:55 <ncopa> but it makes sense
2021-06-15 17:53:30 <ncopa> im gonna go out for a run, and then i'll create the docker images and send a tweet. maybe ikke can prepare an email for alpine-announce email list?
2021-06-15 18:03:01 <ikke> wener: fxied
2021-06-15 18:03:03 <ikke> fixed*
2021-06-15 18:03:27 <wener> 👍 just want to say HAproxy -> HAProxy
2021-06-15 18:03:31 <wener> 😄
2021-06-15 18:03:57 <ikke> wener: yes, I had that fixed, but pushed before I did the commit --amend
2021-06-15 18:06:41 <wener> The faccessat2 problem is kind serious, just upgrade the builder in docker to 3.14, then get this https://gitlab.alpinelinux.org/alpine/aports/-/issues/12321
2021-06-15 18:07:59 <ikke> this should be fixed in the host distro
2021-06-15 18:08:02 <ikke> nothing we can do about
2021-06-15 18:08:25 <ikke> (unless alpine is the host distro :P)
2021-06-15 18:09:28 <ikke> So if there are no more remarks, I'll publish it
2021-06-15 18:09:40 <wener> should mention upgrade host first then upgrade container, otherwise the container will become weried
2021-06-15 18:49:07 <PureTryOut> Cogitri: found a GNOME package you're not the maintainer off but might want to be: polkit-gnome
2021-06-15 18:50:46 <PureTryOut> Ok what the hell grpc is failing on builders with RPATH issues now even though it succeeded on CI, what the hell
2021-06-15 18:51:18 <ikke> because on CI it's build in something like /build, and on the builders in /home/buildozer
2021-06-15 18:51:52 <ncopa> i pushe a fix for alpine-releases.conf to alpine-mksite master
2021-06-15 18:52:21 <ikke> ncopa: thanks, I'm working on purging dl-cdn latest-stable
2021-06-15 18:52:37 <ncopa> ok. i'll merge it to prod then
2021-06-15 18:53:22 <ncopa> i'll do docker images
2021-06-15 18:54:28 <ikke> dl-cdn latest-stable has been purged
2021-06-15 18:54:53 <ikke> testing it in docker, I'm not getting any bad checksums
2021-06-15 18:55:47 <PureTryOut> ikke: uh, ok. Tbh no clue how to fix that. On CI I was messing with the RPATH before as well and making CMake just ignore it didn't work either
2021-06-15 18:56:29 <ikke> hackaround: chrpath -d
2021-06-15 18:59:08 <PureTryOut> On the binary in question?
2021-06-15 18:59:15 <ikke> yes
2021-06-15 18:59:44 <ikke> afaik, this is typically a CMake issue
2021-06-15 19:01:38 <PureTryOut> Ok thanks, will do then
2021-06-15 19:03:16 <PureTryOut> #alpine-commits looks horrible currently 😂
2021-06-15 19:04:51 <ikke> It was so green
2021-06-15 19:07:27 <PureTryOut> It'll be green again once grpc is through
2021-06-15 19:07:34 <PureTryOut> well, except for mips64 and riscv64 that is
2021-06-15 19:11:15 <PureTryOut> Hmm chrpath doesn't seem to have helped
2021-06-15 19:12:06 <ncopa> PureTryOut: i see lots of Bart Ribbers in red in #alpine-commits :)
2021-06-15 19:12:59 <ncopa> ikke would you want to send the email annoucement for 3.14.0?
2021-06-15 19:13:53 <ikke> Apparently I do not have access to post there :)
2021-06-15 19:14:22 <ncopa> oh.. bummer
2021-06-15 19:14:45 <ikke> I mean, I have admin access on listserv, so I can add myself there :P
2021-06-15 19:14:57 <ncopa> please do
2021-06-15 19:15:16 <liske> ncopa: I don't think #10237 can already be closed; I can try to provide a MR for alpine-conf/setup-interfaces soon if appreciated
2021-06-15 19:15:43 <PureTryOut> ncopa: that's mainly fixing up riscv64 stuff lol
2021-06-15 19:18:46 <ikke> ncopa: sent
2021-06-15 19:19:19 <ikke> oh, bounced
2021-06-15 19:19:54 <PureTryOut> https://alpinelinux.org/posts/Alpine-3.14.0-released.html has some names and commit counts duplicated
2021-06-15 19:21:49 <ncopa> lua should be Lua also i think
2021-06-15 19:21:55 <ikke> PureTryOut: which ones?
2021-06-15 19:23:21 <ncopa> i fixed the Lua
2021-06-15 19:24:21 <ikke> ok, nice, I get the messages now for the new user I created
2021-06-15 19:24:31 <ikke> ncopa: any clue how to set a username / password for mqtt-exec?
2021-06-15 19:25:23 <ncopa> in /etc/conf.d/mqtt-exec(.*)?
2021-06-15 19:25:42 <ncopa> or you mean for the mosquitto client?
2021-06-15 19:25:51 <ncopa> im not sure its possible tbh
2021-06-15 19:26:15 <ikke> No, for mqtt-exec
2021-06-15 19:26:26 <ikke> The service has no provisions for it
2021-06-15 19:26:52 <ikke> mqtt-exec has support for it
2021-06-15 19:26:57 <ikke> just not the service file
2021-06-15 19:26:58 <ncopa> not following. mqtt-exec is just a libmosquitto client
2021-06-15 19:27:36 <ikke> n/m, I'll fix it in another way
2021-06-15 19:27:56 <ncopa> you can pass additional options to mqtt-exec via command_args in /etc/conf.d/*
2021-06-15 19:29:01 <ncopa> so you should be able to set command_args="--psk verystrongandsafepasswordwhichnoonewilleverguess" 
2021-06-15 19:29:03 <ikke> Isn't command_args overwritten in star_pre?
2021-06-15 19:29:17 <ncopa> looks like its modified
2021-06-15 19:29:26 <ncopa> i thikn it shoudl work
2021-06-15 19:29:33 <ikke> ok
2021-06-15 19:31:51 <ikke> yeah, seems to work
2021-06-15 19:36:04 <ikke> ncopa: with a bit of luck, the sites are now automatically updated on push again
2021-06-15 19:36:19 <ikke> will look at pkgs.a.o now
2021-06-15 19:45:15 <ikke> ncopa: the downloads page still offers v3.13
2021-06-15 19:46:01 <ikke> and the latest-stable symlink still needs to be udpated
2021-06-15 19:46:14 <ncopa> ah
2021-06-15 19:46:17 <ncopa> thats probably why
2021-06-15 19:46:25 <ikke> yeah
2021-06-15 19:46:41 <ikke> just noticed it in the Makefile
2021-06-15 19:46:54 <ncopa> we should add that to the release checklist template
2021-06-15 19:47:20 <ikke> yes!
2021-06-15 19:47:58 <ikke> I've added it
2021-06-15 19:48:20 <MathGeniusJodie> I personally use latest-stable in my /etc/apk/repositories 
2021-06-15 19:48:30 <ncopa> ikke: done
2021-06-15 19:48:31 <MathGeniusJodie> hehe that's why the update didn't work
2021-06-15 19:48:36 <ikke> yes, exactly
2021-06-15 19:48:47 <ncopa> ikke: maybe we need to purge the cdn cache again ... :-/
2021-06-15 19:48:57 <ikke> yes, but that's easy
2021-06-15 19:49:03 <ikke> at least, if my program is working correctly
2021-06-15 19:49:06 <ncopa> :)
2021-06-15 19:49:40 <ncopa> in unchecked it in the checklist
2021-06-15 19:50:25 <ikke> Need to wait for dl-cdn to update the symlink
2021-06-15 19:52:00 <ncopa> ok
2021-06-15 19:53:40 <ikke> trying to import 3.14 now for pkgs.a.o
2021-06-15 19:53:57 <ikke> but that might take a while
2021-06-15 19:54:29 <ncopa> ok
2021-06-15 19:54:47 <ncopa> ikke: so you take care of the pkgs and invalidate latest-stable?
2021-06-15 19:54:50 <ikke> yes
2021-06-15 19:54:57 <ncopa> great thanks!
2021-06-15 19:56:17 <ncopa> EVERYONE: PLEASE HELP with the last item in the release checklist https://gitlab.alpinelinux.org/alpine/aports/-/issues/12756
2021-06-15 19:56:20 <ncopa> \o/
2021-06-15 19:56:35 <ikke> \o/
2021-06-15 19:56:42 <ikke> w00t
2021-06-15 19:57:24 <ikke> 🎉🎉🎉🎉🎉🎉🎉
2021-06-15 19:59:07 <PureTryOut> 🎉
2021-06-15 19:59:21 <PureTryOut> ikke: some names around Rasmus Thomsen (Cogitri)
2021-06-15 19:59:44 <ikke> He should fix that in .mailmap
2021-06-15 19:59:50 <ikke> Apparently he commits with different names
2021-06-15 20:00:45 <ikke> Oh, I see what you mean now
2021-06-15 20:01:59 <Cogitri> Ah yes, the `Rasmus` one was when I didn't have my git username configured on my laptop
2021-06-15 20:02:10 <Cogitri> But not sure why `Rasmus Thomsen` is there twice
2021-06-15 20:02:40 <ikke> something with terminals and pagers
2021-06-15 20:06:20 <PureTryOut> Not just your full name twice, there are multiple people like that in the list
2021-06-15 20:07:18 <MathGeniusJodie> latest-stable just switched to 3.14
2021-06-15 20:07:29 <ikke> PureTryOut: yes, just fixed it
2021-06-15 20:07:31 <ikke> MathGeniusJodie: thans
2021-06-15 20:07:41 <PureTryOut> Great!
2021-06-15 20:11:35 <ikke> ok, seeing the checksum failures now
2021-06-15 20:11:42 <ikke> trying to purge the cahce
2021-06-15 20:15:48 <ikke> PureTryOut: what happened was that git shortlog used a pager by default
2021-06-15 20:15:55 <ikke> I scrolled through the output, and then quit the pager
2021-06-15 20:15:58 <ikke> the output was still there
2021-06-15 20:16:12 <ikke> but by paging, some output was duplicated in the terminal buffer
2021-06-15 20:16:24 <PureTryOut> Ha, fun
2021-06-15 20:16:30 <MathGeniusJodie> checksum failures?
2021-06-15 20:16:36 <ikke> MathGeniusJodie: yes
2021-06-15 20:16:42 <ikke> BAD checksum errors
2021-06-15 20:16:50 <ikke> dl-cdn is a cache
2021-06-15 20:17:00 <ikke> latest-stable is a symlink that gets updated
2021-06-15 20:17:07 <ikke> but the cache still has the old packages in there
2021-06-15 20:17:11 <ikke> for those paths
2021-06-15 20:17:24 <MathGeniusJodie> ah ok I'm running into the "BAD signature" problem with a few packages
2021-06-15 20:17:25 <ikke> so if we do not purge them, apk is going to complain about checksum failures
2021-06-15 20:17:30 <ikke> MathGeniusJodie: should be fixed soon
2021-06-15 20:17:53 <MathGeniusJodie> I'm being a guinea pig lol
2021-06-15 20:18:05 <ikke> :)
2021-06-15 20:18:17 <ikke> This is a known issue, just something we need to do after every release
2021-06-15 20:18:21 <ikke> 'issue'
2021-06-15 20:18:56 <ikke> I've written a go program that sends purge commands to the cache for each package
2021-06-15 20:19:01 <PureTryOut> Uh, build.a.o only lists the edge builders and mips64 for 3.14 now 🤔
2021-06-15 20:19:23 <ikke> PureTryOut: yes, I had to restart mosquitto, so the retained messages are gone
2021-06-15 20:19:47 <ikke> they will appear again when the builders become active
2021-06-15 20:19:58 <PureTryOut> Ah ok cool
2021-06-15 20:57:51 <mps> https://www.phoronix.com/scan.php?page=news_item&px=Alpine-Linux-3.14
2021-06-15 21:03:40 <ikke> hmm, apparently apk add -Ua is not the same as apk update, apk add -a
2021-06-15 21:03:53 <ikke> MathGeniusJodie: it took a bit longer, but the checksum issues should be fixed now
2021-06-15 21:16:56 <ncopa> Btw there is an iso image for alpine virt armv7 with 3.14
2021-06-15 21:16:57 <c705> python3 seems incredibly broken on v3.14
2021-06-15 21:17:12 <ncopa> c705 how so?
2021-06-15 21:17:34 <c705> I added py3-requests and it's installing the package at /usr/lib/python3.8/site-packages/
2021-06-15 21:18:07 <c705> then I ried sudo apk add pip; sudo pip install requests, and i'm getting importlib.metadata.PackageNotFoundError: pip
2021-06-15 21:18:22 <ikke> are you sure you are not mixing things?
2021-06-15 21:18:38 <ikke> y3-requests-2.25.1-r4 contains:
2021-06-15 21:18:40 <ikke> sr/lib/python3.9/site-packages/requests/__init__.py
2021-06-15 21:19:23 <ncopa> Yes v3.14 comes with python 3.9
2021-06-15 21:19:42 <ikke> ncopa: c705 mentioned it installed py3-requests in 3.8
2021-06-15 21:19:52 <c705> i'm not mixing anything. I don't even have python 3.8
2021-06-15 21:19:59 <ncopa> which arc?
2021-06-15 21:20:03 <c705> c64
2021-06-15 21:20:05 <c705> x64*
2021-06-15 21:20:12 <ikke> c705: apk policy py3-requests
2021-06-15 21:20:53 <c705> ikke: https://termbin.com/7cbq
2021-06-15 21:21:05 <ikke>  https://mirror.csclub.uwaterloo.ca/alpine/v3.13/main
2021-06-15 21:21:08 <ikke> 3.13
2021-06-15 21:21:10 <c705> son of a bitch
2021-06-15 21:21:16 <c705> sorry, and thanks
2021-06-15 21:21:45 <ncopa> Phew… 😅
2021-06-15 21:24:06 <ikke> mips64 is failing on luajit btw
2021-06-15 21:25:45 <c705> welp, lets try that again
2021-06-15 21:31:48 <HRio> fail2ban was in main in v3.13, but not included in v3.14 (or edge), could not see that in the release notice.
2021-06-15 21:32:49 <ikke> 1ba59cfd185bd51b650b237133672f4e9ae87f06
2021-06-15 21:32:57 <ikke> we should mention it
2021-06-15 21:35:01 <HRio> it lots of tests that fail, had a look in debian and they simply ignore the failures... I do not really like that, wonder what the actuall state of fail2ban is in upcoming bullseye
2021-06-15 21:36:07 <ikke> 43 tests failed, 4 errors
2021-06-15 21:36:18 <HRio> I guess for some usecases sshguard will be a working replacement in v3.14
2021-06-15 21:36:31 <HRio> yes, that quite bad
2021-06-15 21:43:14 <ikke> HRio: https://tpaste.us/N8gZ
2021-06-15 21:43:51 <HRio> looks good
2021-06-15 21:44:05 <HRio> thanks
2021-06-15 21:45:09 <ikke> pushed
2021-06-15 21:48:54 <HRio> possibly mention xen 4.15.y up from 4.14.y?
2021-06-15 21:49:40 <HRio> right now its 4.15.0 in v3.14
2021-06-15 21:50:13 <HRio> xen version was mentioned in https://alpinelinux.org/posts/Alpine-3.13.0-released.html
2021-06-15 21:58:33 <c705> why is there no firejail package in 3.14
2021-06-15 21:59:05 <ikke> a583a65eab6c9a60d027f712a965c969448bce65
2021-06-15 21:59:40 <c705> "firejail has a conceptually flawed design, and therefore is inappropriate"
2021-06-15 21:59:54 <c705> seriously? i'd love to read the paper
2021-06-15 22:00:17 <ikke> It requires setuid
2021-06-15 22:00:19 <ikke> qed
2021-06-15 22:01:03 <c705> sudo has setuid too, lets remove that then
2021-06-15 22:01:06 <ikke> bubblejail is an alternative that does not require setuid
2021-06-15 22:02:20 <c705> you should let the user decide what is inappropriate or not. now i'm going back to 3.13 because I have to re-create all my profiles for bubblejail
2021-06-15 22:02:33 <mps> I vote for sudo removal
2021-06-15 22:02:42 <c705> but seriously, remove sudo then if that's the reason behind dropping firejail
2021-06-15 22:02:51 <mps> and all setuid programs
2021-06-15 22:03:27 <ikke> c705: it's the combination of being a sandbox and requiring setuid
2021-06-15 22:03:55 <c705> yeah, my point remains. let me make that desicion. I don't need another distro that makes desicions for me
2021-06-15 22:04:01 <clandmeter> i kind agree c705, do not break users setup except if no other way is possible.
2021-06-15 22:04:55 <mps> firejail is insecure
2021-06-15 22:05:12 <c705> i don't give a shit, that isn't my point
2021-06-15 22:05:25 <mps> upstream also agreed
2021-06-15 22:06:05 <clandmeter> on what?
2021-06-15 22:06:22 <mps> that it is insecure
2021-06-15 22:09:05 <ikke> https://github.com/igo95862/bubblejail for context
2021-06-15 22:10:39 <c705> as the administrator of my system I get to decide what is secure and what isn't. and by the way, just because a program has setuid doesn't mean that it's "insecure"
2021-06-15 22:10:50 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12635
2021-06-15 22:10:58 <clandmeter> I wonder if we could add a post install message to the package in stable when its removed from edge.
2021-06-15 22:10:59 <ikke> c705: You are free to build it for yourself
2021-06-15 22:11:13 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12635
2021-06-15 22:11:22 <donoban> well, rusty-snake admitted that bubblejail is the best alternative for firejail: https://github.com/netblue30/firejail/issues/4210
2021-06-15 22:12:48 <c705> and also, i would HIGHLY recommend some method of sharing that a package is going to become depcrecaded next release through apk
2021-06-15 22:15:41 <donoban> c705: I understand your feeling, but I don't think that the decision was bad (and I was trying to improve firejail on alpine when it happened)
2021-06-15 22:16:16 <c705> the desicion itself isn't what i'm angry about. it's the lack of communication to end users
2021-06-15 22:16:32 <donoban> I would take a look to bubblejail 
2021-06-15 22:16:52 <c705> and I will, thank you, but I don't appreciate distros that make desicions for me
2021-06-15 22:17:06 <ikke> c705: distros make constant decisions
2021-06-15 22:17:14 <ikke> but you only care about it if it affects you
2021-06-15 22:17:19 <mps> building linux-edge riscv64 (edge and edge-virt) took more than 3 and a half hours in chroot on I3 machine
2021-06-15 22:17:20 <c705> fine. communicate them
2021-06-15 22:17:48 <c705> mark the package as deprecated next release and print a message in apk
2021-06-15 22:17:56 <omni> ooh.. π!
2021-06-15 22:22:47 <danieli> it does feel very 'windows' when users are being protected against themselves, so a mechanism to warn users that they are creating a glaring security hole in their system might be about time
2021-06-16 00:57:20 <MathGeniusJodie> well, the 3.14 update broke my mouse input in xorg
2021-06-16 00:57:33 <MathGeniusJodie> spent the entire day fixing it lol
2021-06-16 00:57:45 <MathGeniusJodie> anyway, other than that, so far so good
2021-06-16 02:25:00 <kevint> Thanks for the hard work on 3.14 everyone!
2021-06-16 03:26:32 <MathGeniusJodie> \o/
2021-06-16 03:52:45 <valerius> yes, good job on the release... my WAP just updated successfully with no problems
2021-06-16 03:54:46 <dalias> 0_o
2021-06-16 04:10:37 <Ariadne> your what?
2021-06-16 05:37:17 <DylanVanAssche> Just updated as well, no breakage here 🙂 Thanks!
2021-06-16 05:55:05 <ncopa> good morning
2021-06-16 05:55:46 <ncopa> i tend to agree with c705 re firejail. we shouldn't stand in the way if users wants to shoot themselves in the foot
2021-06-16 05:57:03 <ikke> The firejail profiles were broken
2021-06-16 05:57:16 <ncopa> ok
2021-06-16 05:57:53 <ncopa> and we didnt have resources to fix them?
2021-06-16 05:58:22 <ncopa> or i mean, they weren't fixable?
2021-06-16 06:03:29 <ncopa> https://9to5linux.com/security-oriented-alpine-linux-3-14-released-with-kde-plasma-5-22-qemu-6-0-and-more  cool that they took the time to boot it for the screenshot
2021-06-16 06:11:05 <ncopa> not to self: we need give the community a week for the release notes
2021-06-16 06:15:59 <c705> thanks ncopa 
2021-06-16 06:17:11 <c705> i agree that there are better alternatives to firejail, and i should have properly tested 3.14 before booting, but it was inconvienant that firejail was no longer availiable
2021-06-16 06:18:32 <clandmeter> an alternative would be to fist move it back to testing instead of purging it completely
2021-06-16 06:21:57 <ncopa> "@kdaudt marked the task Celebrate 🎉 as completed 1 hour ago" sounds like ikke celebrated all night :)
2021-06-16 06:25:23 <mps> I again disagree. we shouldn't keep insecure things especially these intended for security
2021-06-16 06:26:07 <mps> next will be to keep something with known backdoors
2021-06-16 06:27:52 <ncopa> i guess the problem is who decides what is secure and what is not
2021-06-16 06:28:24 <ncopa> you could argue that md5 is insecure (it is). but that does not necessarily means that it should be removed
2021-06-16 06:28:25 <mps> above link and text is funny, announce secure distro with headline about KDE
2021-06-16 06:29:11 <ncopa> yeah. at least they booted it to make a screenshot. which is more than most other does i think
2021-06-16 06:29:14 <mps> yes, the 'problem' is who decide
2021-06-16 06:29:32 <clandmeter> if you dont like KDE, dont install it. its still the same system and should be similar secure what you refer to. 
2021-06-16 06:30:26 <mps> if you build house for someone would you make it crash prone if owner wants some bad material in foundation
2021-06-16 06:31:24 <ncopa> so i think we shouldnt encourage anyone use bad material for foundation. we should make it as easy as possible to use the good material
2021-06-16 06:31:48 <ncopa> but it does not mean that we shouldnt provide the bad material, because it could be used for other things than as foundation of a house
2021-06-16 06:32:03 <clandmeter> your analogy does not add up imho
2021-06-16 06:32:21 <ncopa> im thinking haveged as example
2021-06-16 06:32:23 <clandmeter> firejail is by far a foundation in our OS
2021-06-16 06:32:23 <mps> for example in Japan building houses require careful thinking because there are a lot of earthquakes
2021-06-16 06:32:33 <ncopa> its questionable where it gets its entropy from
2021-06-16 06:32:47 <c705> i would also caution the argument that many cves against a product means it is insecure. this is survivorship bias, and it's actually a good thing that people are scrutinizing the code
2021-06-16 06:32:51 <Sheila> there's absolutely no reason to ship firejail. it's insecure garbage.
2021-06-16 06:33:36 <mps> building buildings in Japan is not same as building them in Netherlands
2021-06-16 06:33:39 <clandmeter> the issue is not shipping it, the issue is breaking ppl's setup. 
2021-06-16 06:33:40 <Sheila> and we had this conversation back when Ariadne last removed it.
2021-06-16 06:34:04 <clandmeter> i really dislike it when ppl are affected by our decisions 
2021-06-16 06:34:28 <Sheila> it should not have been shipped to begin with, and it was removed before.
2021-06-16 06:35:49 <clandmeter> maybe we or you (who ever takes this personally) did not do enough to prevent customer dissatisfaction. 
2021-06-16 06:36:16 <mps> personally I would left firejail in alpine but also will not criticize Ariadne for removal
2021-06-16 06:37:10 <Sheila> why should we ship software we know is broken and unfit for purpose?
2021-06-16 06:38:19 <mps> in my company I nearly every day 'fight' with user expectations and with security, and I know how hard is to make decisions
2021-06-16 06:38:48 <clandmeter> my issue is not about broken software, its about how to handle it. just rm -rf is maybe not a good interface.
2021-06-16 06:39:07 <c705> even if there was a process where apk notifies a user like "marked for removal" or something instead of being blindsided by it
2021-06-16 06:39:15 <ncopa> i agree with clandmeters point. maybe it was a good thing to remove it. but it could been handled better in general
2021-06-16 06:39:37 <clandmeter> we should take this as a lesson and handle it better next time.
2021-06-16 06:39:46 <mps> create public relation team
2021-06-16 06:39:49 <c705> now that i'm looking at it, i will probably be using another sandboxing application, but it takes time for me to switch
2021-06-16 06:42:52 <mps> clandmeter: I see you fixed lxc templates for riscv64, does that means we can run riscv64 lxc on x86_64
2021-06-16 06:43:08 <clandmeter> yes kind of
2021-06-16 06:43:18 <mps> and with qemu-user?
2021-06-16 06:43:46 <clandmeter> you still need to take care binfmt_misc yourself
2021-06-16 06:43:59 <clandmeter> and it looks like dhcp client is broken
2021-06-16 06:44:00 <mps> aha, ok
2021-06-16 06:44:19 <clandmeter> and the problem could be deeper than just dhcpc
2021-06-16 06:45:10 <mps> another question, what we should use for riscv64 boot loader for qemu VM, u-boot or something else
2021-06-16 06:57:24 <clandmeter> i have no real preference 
2021-06-16 06:57:51 <clandmeter> does uboot provide a bootloader?
2021-06-16 06:59:32 <mps> didn't tried yet but I read that it can be used
2021-06-16 06:59:44 <clandmeter> is coreboot also an option?
2021-06-16 07:00:43 <mps> as I skimmed net, not yet
2021-06-16 07:01:52 <ikke> ncopa: need to give it more visibility, but that's where the draft release notes on the wiki are for 
2021-06-16 07:02:42 <ikke> So that these can be adjusted on the fly when changes happen 
2021-06-16 07:29:33 <clandmeter> mps: https://riscv.org/wp-content/uploads/2019/12/Summit_bootflow.pdf
2021-06-16 07:46:59 <ncopa> is using a qemu system emulator an option? or is that slower than qemu-user?
2021-06-16 07:52:34 <clandmeter> it should be much slower
2021-06-16 07:52:36 <mps> clandmeter: thanks for url. I read already some and plan to make u-boot today and test could it be for qemu boot
2021-06-16 07:54:33 <mps> didn't tested much (first kernel built on monday at night) but they both on x86_64 works fine
2021-06-16 07:55:35 <mps> building linux-edge took about 3.5 hours on i3 with -j4
2021-06-16 07:56:07 <clandmeter> mine was ready in notime, but i disabled almost all device drivers
2021-06-16 07:56:49 <clandmeter> btw, is there a specific reason to have everything build as module for virt?
2021-06-16 07:57:01 <mps> 'dd if=/dev/zero of=kernel bs=1M count=1' :)
2021-06-16 07:58:19 <mps> defconfig selects '=m' for drivers which are not needed for boot
2021-06-16 07:59:18 <mps> but I also switched some non essential from '=y' to '=m'
2021-06-16 08:08:19 <clandmeter> i guess defconfig is not directly suitable for virt 
2021-06-16 08:08:31 <clandmeter> and it looks like you cannot add just virt kernel 
2021-06-16 08:08:40 <clandmeter> you need to build lts too
2021-06-16 08:16:42 <mps> clandmeter: I built both, linux-edge and linux-edge-virt
2021-06-16 08:16:55 <mps> virt is somewhat trimmed down
2021-06-16 08:18:02 <mps> at the evening I will try to find time to build qemu-u-boot-riscv64 and try to boot it with it
2021-06-16 08:19:05 <clandmeter> can you share your apkbuild for kernel?
2021-06-16 08:19:35 <mps> sure, let me boot mackbook pro where it resides
2021-06-16 08:29:56 <mps> clandmeter: https://tpaste.us/K51P
2021-06-16 08:30:58 <mps> vmlinuz is gzip, if used as qemu -kernel param must bu gunziped first
2021-06-16 09:19:13 <PureTryOut> openblas is failing on riscv64 on tests, but I thought tests weren't being executed on that arch for now?
2021-06-16 09:19:18 <PureTryOut> https://build.alpinelinux.org/buildlogs/build-edge-riscv64/community/openblas/openblas-0.3.15-r0.log
2021-06-16 09:19:38 <PureTryOut> I guess it executes those tests in the build fase for some reason
2021-06-16 09:40:24 <PureTryOut> wener: about grpc, do you actually need grpc_cli? It's causing problems with RPATH and stuff and isn't actually installed by upstream's CMake normally. Can we not just stop shipping it?
2021-06-16 09:42:29 <wener> grpc_cli is quit useful when debugging, not installed by upstream's thats why put it into another package
2021-06-16 09:45:33 <mps> clandmeter: https://tpaste.us/oPoB
2021-06-16 09:46:07 <mps> I need proper partition table now
2021-06-16 09:51:36 <clandmeter> what defines for profile to be set when changing user with su -?
2021-06-16 09:52:16 <clandmeter> it seems on this container running su - $user results in empty env
2021-06-16 10:11:22 <donoban> hi
2021-06-16 10:11:48 <donoban> what container image is clandmeter ?
2021-06-16 10:26:52 <clandmeter> donoban: ?
2021-06-16 10:26:56 <clandmeter> im not a container image :)
2021-06-16 10:27:50 <donoban> ahm, just wanted to test :P lxc?
2021-06-16 10:28:00 <donoban> ah lol
2021-06-16 10:28:46 <donoban> s/is/is it, clandmeter ?
2021-06-16 10:28:46 <alpine-meetbot> donoban meant to say: what container image is it, clandmeter ? clandmeter ?
2021-06-16 10:28:53 <donoban> lol
2021-06-16 10:29:46 <clandmeter> donoban: its lxc
2021-06-16 10:30:55 <donoban> ok
2021-06-16 10:34:45 <Hello71> clandmeter: aiui coreboot is not used in vm because its job is to init ram and whatnot, but that is already done by vmm. you only need "os interface" part, like seabios or ovmf for x86
2021-06-16 10:44:34 <Hello71> interesting, https://unix.stackexchange.com/questions/53261/booting-qemu-kvm-directly-from-a-file-system uses -bios grub.bin
2021-06-16 11:07:57 <markand> are there support for clang sanitizers in alpine? -fsanitize complains about missing -lasan and asan_preinit.o 
2021-06-16 11:11:00 <markand> okay for clang we need clang-static
2021-06-16 11:11:06 <markand> ah no
2021-06-16 11:18:10 <Hello71> no, it needs llvm 12
2021-06-16 11:18:33 <Hello71> work on that will probably start soon
2021-06-16 11:19:28 <markand> it exists much prior to llvm 12 though (already used but on arch linux though)
2021-06-16 11:19:32 <markand> and on gcc is there support for it?
2021-06-16 11:20:47 <Cogitri> It's only there for musl w/ LLVM12
2021-06-16 11:21:17 <markand> okay :)
2021-06-16 11:32:13 <ncopa> oh! llvm12 has support for sanitizer with musl? thats awesome!
2021-06-16 11:33:34 <Cogitri> Yup. I haven't tested it yet though, so not sure if it's up to speed with how ASAN works on glibc
2021-06-16 11:41:39 <mps> no luck with u-boot for riscv64 in qemu, Unhandled exception: Load access fault
2021-06-16 11:42:10 <mps> uhm, intended for u-boot channel
2021-06-16 12:00:22 <Newbyte[m]> Do you have any suggestions regarding what I might do about https://gitlab.alpinelinux.org/alpine/aports/-/issues/12597? I tried looking into it but I don't really understand the issue
2021-06-16 12:26:27 <PureTryOut> Not sure why you can't reproduce it, but seems like you just need to package that dep?
2021-06-16 13:40:41 <mps> clandmeter: now when 5.12.11 is released and should be upgraded what you think about adding riscv64 patch I posted few hours ago
2021-06-16 14:40:09 <mps> ok, lets merge it, we have builder. if it fails we can disable it
2021-06-16 14:45:19 <mps> uh, I'm idiot
2021-06-16 15:19:44 <PureTryOut> polkit being disabled on riscv64 causes so many packages to be disabled 😢
2021-06-16 15:21:58 <dalias> those packages all need to be fixed
2021-06-16 15:22:09 <dalias> polkit being a dependency for anything is a serious security bug
2021-06-16 15:22:17 <ikke> same as happened with mips64
2021-06-16 15:22:53 <ikke> dalias: not sure if we have the capacity of fixing all those packages
2021-06-16 15:23:42 <Cogitri> And honestly, it's not really a fix for anything that's a DE (KDE, GNOME)
2021-06-16 15:24:38 <orbea> dalias: reminds me of this  https://github.com/mesonbuild/meson/issues/7345
2021-06-16 15:25:08 <dalias> ikke, just make a dummy package that provides a null implementation of polkit
2021-06-16 15:25:30 <PureTryOut> Yeah good luck letting KDE Plasma and GNOME get rid of polkit...
2021-06-16 15:29:36 <Cogitri> orbea: I have to admit I kind of like that meson does that? It's nice that I can build w/o root and then install with root all in one go without my build folder becoming owned by root
2021-06-16 15:30:14 <orbea> you can do that without that
2021-06-16 15:30:30 <orbea> and much more safely than relying on polkit
2021-06-16 15:34:44 <dalias> there is a safe way to do it and the meson way is not it
2021-06-16 15:35:00 <dalias> the meson way can just as easily be used to steal your root credentials by presenting a fake prompt
2021-06-16 15:35:40 <dalias> the right way is make install DESTDIR=$PWD/staged then running a command as root to install the staged files to their final location
2021-06-16 15:36:07 <dalias> after verifying that they don't contain any bogus stuff that would be written to the wrong places, overwrite stuff, etc
2021-06-16 15:36:52 <dalias> anyway whatever functionality this is in meson, i'm sure it can be configured out at build time so that polkit is not a dependency
2021-06-16 15:37:44 <orbea> according to the issue the way to disable it is: export PKEXEC_UID=99999
2021-06-16 15:38:36 <orbea> but agreed, your way is much safer
2021-06-16 15:38:52 <orbea> and most distros do that already to varying degrees
2021-06-16 15:38:56 <orbea> (if not all)
2021-06-16 15:39:10 <dalias> yes, distros mostly do it right. it's self-build where ppl don't get it right
2021-06-16 15:39:34 <dalias> i have a script to do it
2021-06-16 15:39:49 <dalias> cd staged && mytar cf - . | ssh root@localhost "cd / && tar xvf -"
2021-06-16 19:56:24 <Hello71> is cd x && tar -c . different from tar -C x -c .?
2021-06-16 19:56:46 <ikke> It should not be different
2021-06-16 19:57:01 <ikke> iirc, -C is literally implemented as cwd
2021-06-16 19:58:02 <ikke> "Change to DIR before performing any operations."
2021-06-16 20:05:08 <mercenary> except that tar -C changes back to where you were, and cd leaves you in X
2021-06-16 20:10:53 <dalias> it was just written not to depend on gnu features, i think
2021-06-16 20:11:30 <dalias> mytar is a wrapper script of mine that does depend on gnu features to suppress ownership of files
2021-06-16 21:30:14 <Hello71> libarchive and busybox both support -C, and i'm not sure there still exist other implementations of (/usr)/bin/tar
2021-06-16 21:30:48 <Hello71> like, python -m tarfile is not at all compatible with tar command
2021-06-16 21:32:29 <dalias> *nod*
2021-06-16 21:33:04 <dalias> anyway i just didnt want to bother researching if there are others i might be using
2021-06-16 21:38:07 <clandmeter> Ariadne: is sourcing /etc/profile arch depended?
2021-06-16 21:39:08 <clandmeter> on riscv64 ash does not source it, and i have no clue why (yet)
2021-06-16 21:40:33 <dalias> clandmeter, are you sure it's a login shell?
2021-06-16 21:40:38 <dalias> profile is only sourced for login shells
2021-06-16 21:40:57 <dalias> non-login shells source $ENV
2021-06-16 21:40:58 <clandmeter> im sshing into it
2021-06-16 21:41:32 <ikke> there is a PROFILE define
2021-06-16 21:41:32 <dalias> it could be something going wrong in how it detects if its login or not, too
2021-06-16 21:41:50 <clandmeter> i have two new lxc containers
2021-06-16 21:41:55 <clandmeter> both on x86_64
2021-06-16 21:42:05 <clandmeter> but the riscv64 is using binfmt
2021-06-16 21:42:32 <ikke> login_sh = procargs(argv);
2021-06-16 21:43:44 <ikke> login_sh = xargv[0] && xargv[0][0] == '-';
2021-06-16 21:44:21 <ikke> looks pretty straight-forward to me
2021-06-16 21:44:31 <clandmeter> maybe its qemu 
2021-06-16 21:45:06 <clandmeter> mps: did you try riscv64 in qemu-system?
2021-06-16 21:45:12 <dalias> maybe argv[0] is qemu-rv64
2021-06-16 21:45:23 <dalias> or something dumb like that
2021-06-16 21:45:36 <dalias> did binfmt_misc botch it somehow?
2021-06-16 21:45:44 <ikke> ooh, I did notice that in htop
2021-06-16 21:45:49 <ikke> at least, in docker
2021-06-16 21:45:52 <clandmeter> yes it does
2021-06-16 21:45:54 <ikke> every command was prefixed
2021-06-16 21:45:57 <clandmeter> i think its a setting
2021-06-16 21:46:01 <dalias> iirc there are 2 different ways to configure binfmt_misc
2021-06-16 21:46:14 <dalias> one that handles argv[0] right and one that doesn't
2021-06-16 21:46:19 <ikke> lol
2021-06-16 21:46:27 <dalias> well the legacy one is kept for compat
2021-06-16 21:46:29 <dalias> but botches it
2021-06-16 21:46:30 <mps> clandmeter: yes
2021-06-16 21:46:37 <dalias> because execfn and argv[0] arent' separate
2021-06-16 21:46:53 <dalias> the new one has them both separate
2021-06-16 21:47:01 <mps> it works fine, except lscpu segfaults
2021-06-16 21:47:36 <ikke> dalias: so the process is started with qemu-user-*, but argv does not mention it?
2021-06-16 21:47:44 <mps> lost day trying to boot with u-boot but didn't worked
2021-06-16 21:48:36 <clandmeter> mps: so /etc/profile gets sourced correctly i guess?
2021-06-16 21:48:52 <dalias> well qemu-user needs to be invoked in a way where it gets passed both the pathname to execute and the argv0 separately
2021-06-16 21:49:28 <mps> didn't give any attention to that
2021-06-16 21:49:51 <mps> will look tomorrow
2021-06-16 21:50:11 <clandmeter> mps: i think you would notice if it didnt :)
2021-06-16 21:50:32 <mps> heh, then maybe it worked
2021-06-16 21:50:33 <ikke> dalias: so the issue is that argv is shifted? Doesn't that break bb?
2021-06-16 21:51:17 <clandmeter> i bumped into another issue before where there was a space in the shebang and it failed on qemu but not on real hw.
2021-06-16 21:53:20 <dalias> ikke, no, it's not shifted
2021-06-16 21:53:39 <dalias> it's that argv[0] just gets passed in as the filename the command was invoked as
2021-06-16 21:54:01 <mps> clandmeter: how can I check if /etc/profile is sourced on login
2021-06-16 21:54:07 <dalias> which "works" for bb because the filename is a symlink with the right applet name
2021-06-16 21:54:23 <clandmeter> look in the profile what gets set
2021-06-16 21:54:24 <dalias> but it suppresses any argv[0] the execve caller passed different from that
2021-06-16 21:54:45 <dalias> qemu-user has a -0 option to pass a custom argv[0]
2021-06-16 21:54:50 <clandmeter> ie your prompt looks different
2021-06-16 21:55:03 <clandmeter> PATH is almost empty
2021-06-16 21:55:05 <dalias> that's what needs to be hooked up to binfmt_misc
2021-06-16 21:55:14 <dalias> so the original value makes it thru to the emulated process
2021-06-16 21:55:14 <mps> so, it is sourced then
2021-06-16 21:55:45 <clandmeter> dalias: default flags are OCF
2021-06-16 21:55:46 <mps> PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
2021-06-16 21:58:51 <mps> and it is sourced when entering chroot
2021-06-16 23:00:16 <Hello71> https://en.wikipedia.org/wiki/Binfmt_misc "P to preserve the original program name typed by user in command line — by adding that name to argv; the interpreter has to be aware of this so it can correctly pass that additional parameter to the interpreted program as its argv[0]."
2021-06-16 23:00:17 <alpine-meetbot> [WIKIPEDIA] Binfmt misc | "binfmt_misc (Miscellaneous Binary Format) is a capability of the Linux kernel which allows arbitrary executable file formats to be recognized and passed to certain user space applications, such as emulators and virtual machines. It is one of a number of binary format handlers in the kernel that are involved..."
2021-06-16 23:01:07 <Hello71> https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html: P - preserve-argv[0]: Legacy behavior of binfmt_misc is to overwrite the original argv[0] with the full path to the binary. When this flag is included, binfmt_misc will add an argument to the argument vector for this purpose, thus preserving the original argv[0]. e.g. If your interp is set to /bin/foo and you
2021-06-16 23:01:09 <Hello71> run blah (which is in /usr/local/bin), then the kernel will execute /bin/foo with argv[] set to ["/bin/foo", "/usr/local/bin/blah", "blah"]. The interp has to be aware of this so it can execute /usr/local/bin/blah with argv[] set to ["blah"].
2021-06-16 23:01:54 <Hello71> i guess the reason why it can't be argv = ["/usr/local/bin/blah", "blah"] is that /bin/foo might not be able to find itself? not sure
2021-06-17 06:10:33 <omni> !22404 !22406
2021-06-17 06:12:06 <omni> I'll look at !22403 later when I've got time
2021-06-17 06:47:36 <ncopa> good morning
2021-06-17 07:37:37 <ikke> Morning 
2021-06-17 08:02:19 <mps> goede morgen. we only have main repo for riscv64 here https://dl-cdn.alpinelinux.org/alpine/edge/
2021-06-17 08:02:44 <PureTryOut> Yes, riscv64 hasn't finished building yet
2021-06-17 08:02:45 <mps> no community nor testing
2021-06-17 08:02:58 <PureTryOut> (not by a long shot, lots of packages needs fixing and disabling)
2021-06-17 08:03:44 <mps> but clandmeter made main and community few days ago on his dev.a.o
2021-06-17 08:04:41 <PureTryOut> community? I doubt it, I still see the builder failing on a lot of packages in that repo
2021-06-17 08:04:50 <PureTryOut> community on his dev.a.o is only what has finished building
2021-06-17 08:04:55 <PureTryOut> Not the entire repo yet
2021-06-17 08:10:15 <mps> well, enough to run it in qemu
2021-06-17 08:11:05 <mps> PureTryOut: I see you fix a lot of pkgs for riscv64, please do not forget to fix tcsh
2021-06-17 08:11:43 <mps> I've built it locally in chroot already
2021-06-17 08:11:51 <mps> works fine
2021-06-17 08:13:40 <clandmeter> mps: repos only get uploaded ones they are finished building
2021-06-17 08:13:47 <clandmeter> main is finished
2021-06-17 08:13:54 <clandmeter> community far from it
2021-06-17 08:14:06 <clandmeter> im not talking about about testing yet :)
2021-06-17 08:14:06 <PureTryOut> fix tcsh? if it's broken and you have a fix, you can push it 😉
2021-06-17 08:14:27 <clandmeter> i do push repos to dev.a.o/clandmeter from time to time
2021-06-17 08:14:55 <clandmeter> if you want to build things from community they could depend on things in community, so thats why.
2021-06-17 08:15:56 <ikke> Reminds me, I should finish CI for riscv64
2021-06-17 08:16:11 <mps> understand and know all this, but I told few days ago that I will step back from touching other maintainers pkgs except mine
2021-06-17 08:16:35 <clandmeter> if you can fix a package to be build, thats fine.
2021-06-17 08:17:08 <clandmeter> try to prevent changes for other arches would be best.
2021-06-17 08:17:15 <mps> no, I will not
2021-06-17 08:17:56 <clandmeter> and your reasoning is?
2021-06-17 08:18:27 <mps> till you vote me for new BDFL :)
2021-06-17 08:19:02 <mps> because ncopa thinks I'm making mess
2021-06-17 08:19:12 <clandmeter> there is a lot of work to be done to finish riscv64, so all the help is appreciated. 
2021-06-17 08:19:51 <clandmeter> mps: dont confuse modifying the package or fixing FTBFS
2021-06-17 08:20:15 <mps> and yes, I agree I make mess but at the same time I think that I make sometimes good things
2021-06-17 08:20:55 <ikke> mps: that does not mean we cannot / should not help each other live up to some standards 
2021-06-17 08:21:15 <mps> ikke: you took words from my mouth
2021-06-17 08:22:05 <mps> I thought friends are for cleaning mess after us when we make them and we clean mess for our friends
2021-06-17 08:22:37 <clandmeter> true and i think we do that most of the time.
2021-06-17 08:22:44 <clandmeter> except when we are grumpy :)
2021-06-17 08:22:52 <mps> :D
2021-06-17 08:23:39 <ikke> ncopa was focused on the release, so those last minute changes are not something he could use
2021-06-17 08:24:24 <mps> ikke: ncopa and me talked about this in private
2021-06-17 08:24:24 <ikke> He did try to look at it, but then saw unrelated changes 
2021-06-17 08:24:36 <mps> so, no worries
2021-06-17 08:26:16 <mps> and granted, I know I'm not 'easy' coworker
2021-06-17 08:42:05 <ikke> The best we can do is learn and try to improve 
2021-06-17 08:46:16 <ncopa> mps: im sorry
2021-06-17 08:48:27 <Newbyte[m]> In what situations is it okay to allow textrels for a specific package?
2021-06-17 08:49:32 <clandmeter> mps: true you are difficult, but i still love you ;-)
2021-06-17 08:50:17 <omni> since we also support 3.12 & 3.11 !22408 & !22410
2021-06-17 08:50:43 <omni> also assumed maintainership of the package for those releases
2021-06-17 08:51:35 <PureTryOut> We all love each other here ❤️
2021-06-17 08:52:39 <ncopa> mps: sometimes you can be a messmaker, but you are our messmaker :)
2021-06-17 08:53:07 <ncopa> mps: but really, i think you do good *way* more than you do mess
2021-06-17 08:56:00 <mps> ncopa: no worries (as I already told you)
2021-06-17 08:56:38 <mps> clandmeter: our love then is mutual ;)
2021-06-17 08:58:30 <PureTryOut> Damn PHP7 and PHP8 failing on riscv64...
2021-06-17 08:58:58 <ikke> andypost[m]: ^
2021-06-17 08:58:59 <mps> ncopa: most of pkgs I'm trying to care for are pkgs you are maintainer and I wanted to help you and take some part of your burden because I know that you are too busy
2021-06-17 08:59:34 <mps> ofc, clandmeter wishes are my commands, first of all :)
2021-06-17 09:00:43 <mps> and my main motivation is to make alpine better (whatever it means) because I use alpine and rely on alpine on a lot of things
2021-06-17 09:07:31 <Newbyte[m]> If I can put the source of a package as pythonhosted.org or github.com, which should I prefer?
2021-06-17 09:08:29 <ncopa> me personally have no preference there. I dunno if someone else has
2021-06-17 09:11:11 <PureTryOut> I use pypi source by default, unless the package has tests but are not in the pypi source, then I use Github
2021-06-17 09:17:03 <PureTryOut> Hmm, https://dl-2.alpinelinux.org seems to have been out of date for quite a while. For example it still doesn't have calindori=21.06-r0 even though that package has been added to edge on the 10th of this month
2021-06-17 09:17:12 <PureTryOut> Is the rsync thingy down?
2021-06-17 09:18:12 <ikke> I've heard the disk was full 
2021-06-17 09:18:29 <PureTryOut> Oh fun!
2021-06-17 09:21:44 <ncopa> mps: feel free to take over the packages
2021-06-17 09:23:48 <mps> which ones?
2021-06-17 09:24:12 <clandmeter> all of them :)
2021-06-17 09:24:18 <mps> all alpine :D
2021-06-17 09:24:19 <clandmeter> except qemu ;-)
2021-06-17 09:24:30 <clandmeter> sorry, couldnt resist 
2021-06-17 09:24:33 <ncopa> lol!
2021-06-17 09:24:56 <mps> ehm, I thought qemu as first :P
2021-06-17 09:25:00 <ncopa> preferable the packages you actually use
2021-06-17 09:25:35 <ncopa> fwiw, the qemu package is actually pretty tricky
2021-06-17 09:25:54 <clandmeter> is there any issue in getting linux-edge into community?
2021-06-17 09:25:55 <mps> ok, joke aside, will do one by one but always ask first (as I did already for those taken)
2021-06-17 09:26:18 <mps> clandmeter: no please
2021-06-17 09:26:44 <mps> it is quite fine in testing, imo
2021-06-17 09:26:59 <Newbyte[m]> is there any real issue apart from that you'd have to send your MRs to two branches instead of one?
2021-06-17 09:27:28 <ikke> Newbyte[m]: for what? 
2021-06-17 09:27:31 <mps> major version changes few times during community lifecycles
2021-06-17 09:27:50 <Newbyte[m]> for getting linux-edge into community 
2021-06-17 09:27:59 <mps> usually 2-3
2021-06-17 09:28:27 <Newbyte[m]> isn't that exactly why you'd want to use linux-edge instead of lts?
2021-06-17 09:28:48 <Newbyte[m]> anyway 
2021-06-17 09:28:48 <mps> clandmeter: again, if you think it is good to have it in community you know - your wishes are ....
2021-06-17 09:32:26 <Newbyte[m]> Do you have any idea what that error relocating symbol issue might be about? https://paste.centos.org/view/99cd525d
2021-06-17 09:33:09 <Newbyte[m]> Or the other errors for that matter
2021-06-17 09:33:25 <z3ntu> Looks like some package needs to be rebuilt
2021-06-17 09:33:45 <Ariadne> my concern with linux edge being in community is what happens during the maintenance lifecycle
2021-06-17 09:33:48 <Newbyte[m]> Yeah, I tried rebuilding blist but I still got the same thing 
2021-06-17 09:33:58 <z3ntu> or this thing https://github.com/conda-forge/blist-feedstock/blob/master/recipe/patches/0004-compatibility-with-PEP-620.patch
2021-06-17 09:34:12 <clandmeter> for the record, im not saying it should, i was wondering why or why not.
2021-06-17 09:34:23 <mps> Ariadne: backport, as usual
2021-06-17 09:34:24 <Newbyte[m]> <z3ntu "or this thing https://github.com"> That looks probable 
2021-06-17 09:34:39 <z3ntu> Newbyte: if you put `_PyObject_GC_IS_TRACKED` into $searchEngine you should fine everything you need
2021-06-17 09:34:42 <Newbyte[m]> I'll give it a shot, thanks!
2021-06-17 09:36:01 <mps> Ariadne: but yes, sometimes some options or drivers are removed in community lifetime (6 months)
2021-06-17 09:36:27 <mps> that is only potential problem, but also this doesn't happen often
2021-06-17 09:36:48 <Ariadne> traditionally the edge kernel has been for investigating new stuff for the next lts kernel
2021-06-17 09:37:16 <ikke> It was used for 2 things 
2021-06-17 09:37:36 <Ariadne> i don’t want to commit anybody to maintaining something they don’t want to maintain during a lifecycle 
2021-06-17 09:37:49 <mps> well, this was idea but it is used nowadays as 'normal' kernels
2021-06-17 09:41:04 <mps> personally I don't plan to stop using alpine and working on it, but who know what can happen tomorrow and what reasons can stop me
2021-06-17 09:41:23 <mps> even can die
2021-06-17 09:42:23 <Newbyte[m]> is there any reason py3-mypy is marked as arch=all instead of arch=noarch?
2021-06-17 09:42:34 <PureTryOut> It probably has some native code
2021-06-17 09:42:42 <Newbyte[m]> abuild says it doesn't find any arch-specific binaries 
2021-06-17 09:42:51 <Newbyte[m]> false negative? 
2021-06-17 09:42:57 <PureTryOut> Then it should be changed
2021-06-17 09:44:19 <ikke> Are there subpkgs that have native code? 
2021-06-17 09:44:50 <Newbyte[m]> It does not have any subpackages
2021-06-17 10:01:56 <Newbyte[m]> Could someone with a v3.14 installation see if this lets mirage start up correctly for them: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22413
2021-06-17 10:02:24 <Newbyte[m]> `$ sudo apk add mirage; mirage`
2021-06-17 10:02:51 <Newbyte[m]> I've tested and it works on edge, but I don't have a v3.14 install 
2021-06-17 10:23:24 <clandmeter> 809bd8a5daf3384a590118044b7eb67c2472ea14 had an issue with the commit format, but the pkgdesc is even more interesting :)
2021-06-17 10:31:00 <ncopa> indeed
2021-06-17 10:46:01 <PureTryOut> Ariadne Cogitri: any chance any of you could bootstrap Rust on riscv64? There are _tons_ of packages that depend on it one way or another and it would save so much trouble having to disable packages that have Rust somewhere in the stack
2021-06-17 10:47:56 <ncopa> would be good if we could bootstrap it on s390x first
2021-06-17 10:48:33 <PureTryOut> That'd be great too ofc. Does Rust support it upstream?
2021-06-17 10:48:55 <ncopa> it does afaik, but i dont think the bootstrap works properly with musl
2021-06-17 10:49:00 <ncopa> (for any arch)
2021-06-17 10:51:24 <PureTryOut> Oh great...
2021-06-17 11:16:24 <Newbyte[m]> what about https://github.com/thepowersgang/mrustc?
2021-06-17 11:16:57 <Newbyte[m]> it claims to be able to bootstrap rustc and it's written in C++
2021-06-17 11:17:08 <Newbyte[m]> oh, wait. x86_64 only
2021-06-17 11:17:09 <Newbyte[m]> never min
2021-06-17 11:17:10 <Newbyte[m]> d
2021-06-17 11:23:44 <Cogitri> Newbyte: That's not a problem though, you'd do mrustc -> rust 1.31 -> rust 1.32 -> [...] -> rust 1.52 and then crosscompile to riscv
2021-06-17 11:24:32 <Cogitri> ncopa: Bootstrapping does work, at least it did for aarch64 & armv7 
2021-06-17 11:25:00 <Cogitri> I can try giving it a go at the weekend
2021-06-17 11:25:06 <PureTryOut> That'd be great!
2021-06-17 11:43:19 <PureTryOut> Cogitri: seeing you're assinging a Pipewire upgrade to me, do you not want to maintain it anymore?
2021-06-17 11:46:58 <Cogitri> Ah, it's mostly that I currently don't use it on Alpine so I don't really have means for testing it
2021-06-17 11:47:07 <Cogitri> But I wouldn't mind you taking over maintainership either
2021-06-17 11:47:49 <PureTryOut> Oh sure, that's fine. I actually use it, even with -pulse on my laptop, so it makes sense I guess
2021-06-17 11:52:55 <Cogitri> #12767 
2021-06-17 11:53:06 <Cogitri> That looks odd
2021-06-17 11:54:44 <PureTryOut> The ppc64le builder is having problems
2021-06-17 12:35:25 <mps> should we merge perl 5.34 or it is to early
2021-06-17 12:35:57 <maxice8> 3.14 was released so i'd say go 
2021-06-17 12:36:15 <mps> !21619 
2021-06-17 12:36:33 <mps> ncopa: ^
2021-06-17 12:36:45 <mps> maxice8: thanks
2021-06-17 12:39:03 <Newbyte[m]> https://gitlab.alpinelinux.org/Newbyte/aports/-/jobs/417230#L4086
2021-06-17 12:39:10 <Newbyte[m]> How can I go about resolving this?
2021-06-17 12:41:51 <Newbyte[m]> types-aiohttp is part of some monorepo
2021-06-17 12:42:57 <PureTryOut> Newbyte: hmm? https://pkgs.alpinelinux.org/packages?name=py3%2Daiofiles
2021-06-17 12:47:31 <insep> omni: i have haxe 4.2.2 compiling on alpine, but building that requires to install things from opam, how should this be handled, should i package everything or install stuff from opam in apkbuild?
2021-06-17 12:48:15 <ncopa> mps: i will try look at the perl 5.34 next week
2021-06-17 12:51:14 <mps> ok
2021-06-17 12:51:50 <Newbyte[m]> PureTryOut (matrix.org): yes, that's the source package. types-aiohttp contains types for aiohttp since aiohttp itself doesn't have those apparently 
2021-06-17 12:52:01 <Newbyte[m]> this is used when running mirage's tests
2021-06-17 13:06:05 <PureTryOut> How can I make abuild (rootbld) skip unit tests?
2021-06-17 13:26:58 <PureTryOut> clandmeter: you said riscv64 is skipping tests currently, how are you doing that?
2021-06-17 13:32:15 <omni> insep: cool! I assume I/we prefer things packaged as aports but up-to-date packages over that... others will have to weigh in
2021-06-17 13:50:16 <caskd> PureTryOut: case "$CARCH" in; riscv64) options="$options !check";; esac ?
2021-06-17 13:50:38 <ikke> BOOTSTRAP=1
2021-06-17 13:51:03 <ikke> PureTryOut: Look for want_check in abuild.in
2021-06-17 13:58:44 <andypost[m]> PureTryOut (matrix.org): is there logs of failures of PHP? Please file issue to dig it
2021-06-17 14:00:55 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-riscv64/community/php8/php8-8.0.7-r0.log
2021-06-17 14:01:12 <andypost[m]> Thank you
2021-06-17 14:09:22 <andypost[m]> undefined reference to `__sync_lock_test_and_set_1'  not clear what it means
2021-06-17 14:11:43 <andypost[m]> OTOH it failed for lightspeed webserver which is outdated a lot
2021-06-17 14:30:32 <Newbyte[m]> How do you deal with Python packages that don't ship a setup.py?
2021-06-17 14:37:50 <orbea> what do they ship?
2021-06-17 14:38:16 <Newbyte[m]> orbea: I'm not sure what's of interest, but you can take a look: https://github.com/poljar/matrix-nio/
2021-06-17 14:39:18 <ikke> setup.cfg
2021-06-17 14:39:20 <Newbyte[m]> how do I use that?
2021-06-17 14:39:42 <orbea> Newbyte[m]: https://github.com/poljar/matrix-nio/blob/master/contrib/archlinux/pkgbuild/PKGBUILD.git
2021-06-17 14:39:47 <orbea> they have an example
2021-06-17 14:40:36 <ikke> OK a tool to convert to setuptools
2021-06-17 14:40:43 <Newbyte[m]> orbea: yeah, I looked at that, but they use something called dephell to convert some other file to a setup.py. I looked into packaging dephell, but it required a dozen of dependencies and to make matters worse, is unmaintained 
2021-06-17 14:40:57 <orbea> fun...
2021-06-17 14:41:01 <Newbyte[m]> yeah
2021-06-17 14:41:10 <Newbyte[m]> and to be clear that "dozen of dependencies" are all dephell_<stuff>
2021-06-17 14:41:15 <Newbyte[m]> so I can only assume they also are unmaintained 
2021-06-17 14:42:59 <Newbyte[m]> Surely Alpine must have some package that uses setup.cfg? I remember we discussed how to handle that here months ago
2021-06-17 14:43:12 <Newbyte[m]> git grep -r, here I come
2021-06-17 14:43:53 <ikke> maxice8: ^
2021-06-17 14:44:22 <maxice8> what are the contents of setup.cfg ?
2021-06-17 14:44:31 <Newbyte[m]> feel free to take a look: https://github.com/poljar/matrix-nio/
2021-06-17 14:44:44 <Newbyte[m]> oh, it's just test stuff
2021-06-17 14:44:58 <Newbyte[m]> pyproject.toml seems to be the interesting part
2021-06-17 14:45:23 <maxice8> we already have py3-matrix-nio, you updating it?
2021-06-17 14:45:27 <Newbyte[m]> correct
2021-06-17 14:45:34 <Newbyte[m]> it's outdated and Mirage needs a newer version 
2021-06-17 14:45:40 <maxice8> pyproject.toml is their new build from PEP517
2021-06-17 14:46:02 <maxice8> which makes setuptools obsolete for building, now we need a PEP517-compliant builder which means most of the cases poetry
2021-06-17 14:46:03 <maxice8> fun
2021-06-17 14:46:47 <Newbyte[m]> so I should use poetry to build?
2021-06-17 14:47:23 <insep> omni: also i've noticed that haxelib assumes that linux is always x86_64 glib system and distributes such prebuilds, do you know how to deal with this mess in order to install any packages?
2021-06-17 14:47:49 <Newbyte[m]> `poetry build --format wheel`?
2021-06-17 14:48:06 <maxice8> sorry but I have no clue how to use poetry
2021-06-17 14:48:32 <Newbyte[m]> no worries, thanks for your help 👍️
2021-06-17 14:49:14 <Newbyte[m]> oh, poetry is in testing …
2021-06-17 14:49:24 <Newbyte[m]> and mirage is in community 
2021-06-17 14:49:25 <Newbyte[m]> very fun
2021-06-17 14:49:43 <maxice8> and is dependency heavy, py3-setuptools can be bootstrapped from python3 (its deps use sdist to build)
2021-06-17 14:50:02 <maxice8> the python3 packaging ecosystem is to put it nicely, suboptimal
2021-06-17 14:51:52 <Newbyte[m]> yeah, this is anything but poetry 
2021-06-17 14:53:49 <Newbyte[m]> 
ACTION uploaded an image: (10KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/idINkSGfbrAPUOFOjYzBAsFP/Screenshot_Alpine_2021-06-17_16%3A53%3A31.png >

2021-06-17 14:53:56 <Newbyte[m]> this looks very promising 
2021-06-17 14:58:21 <Newbyte[m]> why not it be that it cannot import things from the `nio` module? 
2021-06-17 14:58:41 <Newbyte[m]> e.g. `DeletePushRuleResponse`
2021-06-17 14:58:58 <Newbyte[m]> is nio something built-in to Python?
2021-06-17 15:04:49 <Newbyte[m]> this is the ugliest packaging I've ever done
2021-06-17 15:04:52 <dne> no, it appears to be part of matrix-nio: https://github.com/poljar/matrix-nio/tree/master/nio
2021-06-17 15:05:06 <Newbyte[m]> yeah, I suppose I'm hitting the bug spoken of in the jedi language server APKBUILD 
2021-06-17 15:08:00 <Newbyte[m]> no, it doesn't work anyway 
2021-06-17 15:12:27 <Newbyte[m]> in gentoo they use magic apparently: https://gitlab.com/src_prepare/src_prepare-overlay/-/blob/master/dev-python/matrix-nio/matrix-nio-0.18.2.ebuild
2021-06-17 15:16:55 <maxice8> check the distutils-r1.eclass
2021-06-17 15:17:28 <maxice8> apparently they use pyproject2setuptools 
2021-06-17 15:17:35 <maxice8> https://devmanual.gentoo.org/eclass-reference/distutils-r1.eclass/index.html
2021-06-17 15:18:32 <Newbyte[m]> 
ACTION uploaded an image: (45KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/JQRrZiYwLTeLnUWVmxSuHVPs/image.png >

2021-06-17 15:18:34 <Newbyte[m]> awesome 
2021-06-17 15:21:19 <maxice8> https://github.com/mgorny/pyproject2setuppy
2021-06-17 15:21:42 <maxice8> it is in community
2021-06-17 15:21:43 <maxice8> you are in luck
2021-06-17 15:21:55 <Newbyte[m]> oh, cool! thanks
2021-06-17 16:06:08 <Newbyte[m]> why might it be that my builddir isn't respected by abuild?
2021-06-17 16:07:00 <Newbyte[m]> it runs build() inside the src directory despite that I set builddir to `"$srcdir/$pkgname-$pkgver`
2021-06-17 16:08:22 <afontain[m]> It usually means the build dir doesn't exist
2021-06-17 16:08:37 <afontain[m]> (I think?)
2021-06-17 16:08:49 <Newbyte[m]> you seem to be right. I tried adding a `cd` to build and it tells me that
2021-06-17 16:09:00 <Newbyte[m]> wouldn't it be cool if abuild could tell me that though
2021-06-17 17:36:02 <bratkartoffel> wow, someone merged almost all of my PRs to use the java-provides
2021-06-17 17:39:44 <tiotags> hello, I have made a new apkbuild and want to merge request it to testing but I can't test it because I can't get qemu to work, is anyone willing to test my apk ?
2021-06-17 17:40:33 <caskd> tiotags: what arch?
2021-06-17 17:41:10 <tiotags> it's not binary, no ?
2021-06-17 17:41:39 <caskd> oh you mean to test if it builds properly on every arch?
2021-06-17 17:41:48 <tiotags> if it runs
2021-06-17 17:41:53 <tiotags> ... oh sorry, my bad
2021-06-17 17:42:07 <tiotags> to test the init.d script
2021-06-17 17:42:24 <ikke> tiotags: what package?
2021-06-17 17:42:26 <tiotags> the apk builds but I can't test the main point, if it runs
2021-06-17 17:42:39 <caskd> you can try installing it yourself and running it
2021-06-17 17:43:28 <tiotags> I made it in a container and as far as I understand I can't get openrc to work under a container (is that true ?)
2021-06-17 17:43:39 <maxice8> bratkartoffel: I manually merged some, assigned others to developers but need to find out the username of some other mainatiners
2021-06-17 17:43:43 <maxice8> maintainers*
2021-06-17 17:44:01 <Newbyte[m]> Is the CI broken?
2021-06-17 17:44:25 <caskd> tiotags: you could start the container with /sbin/init as command and then start the service
2021-06-17 17:44:30 <caskd> that way openrc is pid1
2021-06-17 17:45:14 <bratkartoffel> maxice8: thanks, i've almost forgotten about these. crossing fingers everything builds fine
2021-06-17 17:45:26 <tiotags> I'll try, I hope that works
2021-06-17 17:45:39 <maxice8> well most CI failed so I'm restarting the ones I can
2021-06-17 17:48:18 <ikke> CI broken?
2021-06-17 17:54:05 <tiotags> ikke if you're asking for what program it's for a webserver I'm making https://gitlab.com/tiotags/hin9
2021-06-17 17:55:47 <omni> insep: no, unfortunately
2021-06-17 17:56:00 <insep> ok
2021-06-17 17:59:03 <tiotags> caskd openrc doesn't want to run inside a container
2021-06-17 18:02:12 <mps> tiotags: it runs fine in lxc
2021-06-17 18:03:04 <tiotags> alpine-openrc is what I'm looking for ? I was trying to install openrc by apk add ...
2021-06-17 18:03:17 <ikke> just openrc
2021-06-17 18:04:41 <caskd> tiotags: are you starting the container by setting the command to /sbin/init ?
2021-06-17 18:04:52 <tiotags> I'm using docker, and I ran a "from alpine:latest ... run apk add openrc" it gave me permission errors
2021-06-17 18:04:55 <tiotags> yes
2021-06-17 18:05:23 <tiotags> but it looks like there's a special dockerfile for alpine-openrc ? that's what I want right
2021-06-17 18:06:29 <tiotags> what is lxc mps ?
2021-06-17 18:07:23 <ikke> A container system that existed before docker
2021-06-17 18:07:38 <ikke> which looks more like a vps
2021-06-17 18:07:41 <tiotags> is it better ?
2021-06-17 18:08:41 <ikke> it's different, but if you want to test things like openrc, that's much easier with lxc
2021-06-17 18:09:24 <tiotags> I'll probably try that, thank you
2021-06-17 18:32:44 <nmeum> Newbyte[m]: abuild has an explicit check for ensuring that $builddir points to an existing directory before attempting to cd into it
2021-06-17 18:32:52 <nmeum> hence no warning if the directory doesn't exist
2021-06-17 18:33:28 <nmeum> I assume this is for compatibility with old $_builddir APKBUILDs which didn't set $builddir
2021-06-17 18:52:58 <caskd> btw, does anyone have a resource showing the key differences from APKv2 to APKv3 ?
2021-06-17 18:54:10 <caskd> or do i have to read the log?
2021-06-17 18:58:09 <Newbyte[m]> nmeum: it would be nice if abuild itself warned when that happens 
2021-06-17 18:58:23 <Newbyte[m]> Either way I made an issue about it
2021-06-17 19:02:23 <mps> clandmeter: (and all) all you need to run riscv64 in qemu is here https://dev.alpinelinux.org/~mps/riscv64/
2021-06-17 19:09:06 <ikke> caskd: afaik, it's not properly documented yet, so mostly ariadne and fabled know
2021-06-17 19:09:30 <caskd> guess i could check the log for that branch then
2021-06-17 19:14:41 <nmeum> speaking of riscv64: are tests still disabled for that architecture? if so, can we enable tests for new pushes?
2021-06-17 19:15:29 <ikke> they are, and no
2021-06-17 19:15:41 <ikke> ell
2021-06-17 19:15:42 <nmeum> why not? :)
2021-06-17 19:15:46 <ikke> just enabling them ofcourse
2021-06-17 19:16:01 <ikke> But I think the idea is to first get community built
2021-06-17 19:16:33 <Cogitri> And I'm a bit afraid that enabling tests would set the builder on fire :p
2021-06-17 19:18:21 <nmeum> I would be interested in fixing riscv64 failing tests, though some might just fail due to certain properties of the qemu-user environment
2021-06-17 19:18:37 <nmeum> so maybe it makes sense to wait until we have real hardware idk
2021-06-17 19:19:18 <ikke> yeah, I think that was the idea
2021-06-17 19:19:29 <ikke> tests are more likely to fail due to the environment
2021-06-17 19:19:58 <ikke> nmeum: We do have CI soon, there tests can be enbled
2021-06-17 19:20:09 <mps> you gave me idea, lets try build linux-edge in riscv64 lxc and see how long it takes
2021-06-17 19:45:47 <Ariadne> caskd: entirely different package format
2021-06-17 19:46:23 <caskd> mind going into a few details?
2021-06-17 19:57:25 <mps> not fast but also not too slow, abuild -r in linux-edge took 33 minutes with '-j24'
2021-06-17 20:13:10 <MY-R> performance of 4 core 8 years old cpu :P
2021-06-17 20:22:46 <maribu[m]> Wow, I have the strangest issue ever. If I launch either firefox or chromium-browser and search for any search term containing the word "zoom" in either duckduckgo, google search, or even youtube, the browser will exit.
2021-06-17 20:24:38 <maribu[m]> Even searching for that term in a German new website (tagesschau.de) results in the crash. Searching for random other texts still works. This is crazy!
2021-06-17 20:25:02 <Newbyte[m]> Any error messages in stderr/stdout?
2021-06-17 20:25:22 <maribu[m]> firefox: ###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost
2021-06-17 20:25:41 <Newbyte[m]> Does it happen in e.g. GTK applications? 
2021-06-17 20:26:23 <c705> last time that happened to me, it turns out it was a dbus problem
2021-06-17 20:27:49 <maribu[m]> Wait! I think have the solution :-) Exit code is 0. I have a nasty application that pops up windows (a shitty conference tool my employer favors). I set up a rule to kill all windows with that title. I think that I misconfigured the rule to kill all windows containing "zoom", not matching exactly zoom :-)
2021-06-17 20:29:30 <maribu[m]> Yep. Dropping that rule results in the browser staying alive
2021-06-17 20:33:10 <dne> lol
2021-06-17 20:55:54 <Cogitri> Heh
2021-06-18 00:56:22 <Ariadne> caskd: i plan to write a series of blogs about it
2021-06-18 02:46:59 <anjan> Hi! Can someone please review a patch I submitted 2 days ago: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22366
2021-06-18 02:47:03 <anjan> I think the maintainer is busy
2021-06-18 02:47:34 <anjan> Im just wondering if I did something wrong cause alpine is usually quick with the reviews. No worries if you guys are busy rn
2021-06-18 04:28:45 <anjan> thank you guys. Just got the email confirmation
2021-06-18 05:47:01 <kevint> I'm wondering what the commit style would be for just changing an init.d script?
2021-06-18 05:48:13 <ikke> kevint: '<repo>/<pkg>: fix this issue in init script' or something like that
2021-06-18 05:49:03 <ikke> depends on the kind of change, but just describe what in a succint way (and details in the body)
2021-06-18 06:22:22 <ncopa> good morning
2021-06-18 06:29:11 <Cogitri> Morning 👋
2021-06-18 06:38:51 <Newbyte[m]> Do you know what's going on with the CI in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22412?
2021-06-18 06:38:59 <kevint> @ikke ty
2021-06-18 08:14:03 <fcolista> I need an advice about bareos-webui. It is a subpackage with "noarch". One of the dependencies is py3-selenium, which does not build for arm* arches.
2021-06-18 08:14:34 <fcolista> How can I avoid bareos-webui to be avail for arm* arches?
2021-06-18 08:14:53 <fcolista> Does it work if i add in the subpackage:
2021-06-18 08:15:07 <fcolista> arch="noarch !armhf !armv7" 
2021-06-18 08:15:07 <fcolista> ?
2021-06-18 08:19:02 <ncopa> correct
2021-06-18 08:23:53 <PureTryOut> <Newbyte[m] "Do you know what's going on with"> That's a lot of new stuff in community 🤔
2021-06-18 08:24:39 <PureTryOut> > /usr/local/bin/build.sh: /etc/abuild.conf: line 25: REPODEST: is read only
2021-06-18 08:24:44 <PureTryOut> Not sure why that happens
2021-06-18 08:25:14 <fcolista> ok, thx ncopa 
2021-06-18 08:25:39 <ikke> That's innocent 
2021-06-18 08:27:37 <ikke> Newbyte[m]: is your branch behind a lot? 
2021-06-18 08:34:29 <maxice8> py3-selenium package seems to carry a precompiled binary that can't be stripped
2021-06-18 08:34:38 <fcolista> umh
2021-06-18 08:34:44 <fcolista> >>> ERROR: bareos-webui*: Split function set arch="noarch !armhf !armv7" for bareos-webui
2021-06-18 08:34:51 <fcolista> , use subpackages=pkg:split:arch format instead
2021-06-18 08:35:58 <fcolista> perhaps in the subpackage i only need to put arch="!armhf !armv7" , leaving noarch in the subpakcage 
2021-06-18 08:59:09 <fcolista> maxice8, yes...I can add !strip, but still with arm would not work
2021-06-18 08:59:44 <fcolista> anyway I've not yet found a way to instruct the subpackage to avoid certain arches
2021-06-18 09:24:17 <Ariadne> you have to use a case statement
2021-06-18 09:29:56 <fcolista> within the subpackage ? So if CARCH is arm* then return 0 ?
2021-06-18 09:30:25 <clandmeter> no, when setting subpkg i guess
2021-06-18 09:30:46 <clandmeter> but you will end up with the webif in main pkg
2021-06-18 09:31:37 <fcolista> i don't like it
2021-06-18 09:32:28 <clandmeter> can you sh ow me your apkbuild?
2021-06-18 09:33:10 <fcolista> https://git.alpinelinux.org/aports/tree/community/bareos/APKBUILD
2021-06-18 09:33:28 <clandmeter> the subpkg will be responsible for splitting things into another pkg
2021-06-18 09:33:34 <clandmeter> so if you disable it, it will not split
2021-06-18 09:34:17 <clandmeter> if you dont like it, you need to add some logic in main package function to rm -rf it based on arch
2021-06-18 09:34:32 <fcolista> you mean I should remove the $pkgname-webui
2021-06-18 09:34:52 <clandmeter> it all depends what you actually want as result
2021-06-18 09:34:58 <fcolista> so whoever install bareos will install also webui too
2021-06-18 09:35:05 <clandmeter> exactly
2021-06-18 09:35:14 <fcolista> that's what I don't like
2021-06-18 09:35:21 <clandmeter> and if for arm you dont want it, rm -rf it
2021-06-18 09:35:34 <fcolista> webui  should be a separate package
2021-06-18 09:35:47 <clandmeter> but arm cant have it you say :)
2021-06-18 09:36:21 <fcolista> that's what I'm looking for: how to have a subpackage without specific arches
2021-06-18 09:37:11 <fcolista> if I understood correctly what you mean, i should ship the webui with bareos. This will allow me to have it working for the arches I want, since I can control this with case statement
2021-06-18 09:37:34 <clandmeter> no thats not what i mean
2021-06-18 09:37:44 <fcolista> so I've not understood
2021-06-18 09:37:54 <clandmeter> im explaining you what happens when you disable the subpkg
2021-06-18 09:38:02 <clandmeter> the subpkg is defined by the subpkg function
2021-06-18 09:38:16 <clandmeter> if you dont run it, the result will stay in the main pkg
2021-06-18 09:38:59 <clandmeter> so if for arm you cannot run the webif, you should not ship it.
2021-06-18 09:39:03 <clandmeter> actually
2021-06-18 09:39:19 <clandmeter> does the program have an option to disable the webif?
2021-06-18 09:39:24 <clandmeter> or webif installation
2021-06-18 09:39:48 <fcolista> thats' a good question and a good idea
2021-06-18 09:39:49 <fcolista> let me check
2021-06-18 09:40:54 <clandmeter> but it will still need modifications
2021-06-18 09:41:00 <fcolista> if(BUILD_BAREOS_BINARIES) is defined then it addes add_subdirectory(core) and add_subdirectory(webui) 
2021-06-18 09:41:34 <fcolista> which appears to be the default setting
2021-06-18 09:41:42 <fcolista> I can hack that part
2021-06-18 09:41:57 <clandmeter> fcolista: why is py3-selenium not availalbe?
2021-06-18 09:42:31 <fcolista> clandmeter, build fails 
2021-06-18 09:42:39 <clandmeter>  but it has arch=all
2021-06-18 09:42:54 <fcolista> git pull
2021-06-18 09:43:01 <clandmeter> https://git.alpinelinux.org/aports/tree/community/py3-selenium/APKBUILD
2021-06-18 09:43:02 <fcolista> :)
2021-06-18 09:43:18 <fcolista> see 624c6a019fb2b36573cf8527438f2cd61df15f86
2021-06-18 09:43:30 <fcolista> commit 624c6a019fb2b36573cf8527438f2cd61df15f86 
2021-06-18 09:43:37 <clandmeter> algitbot: ping
2021-06-18 09:43:41 <clandmeter> bot is alive
2021-06-18 09:43:49 <fcolista> i hoped that algitbot would show the commit
2021-06-18 09:43:49 <fcolista> ok
2021-06-18 09:43:51 <clandmeter> did you push it already?
2021-06-18 09:44:15 <fcolista> eheh
2021-06-18 09:44:21 <clandmeter> :p
2021-06-18 09:44:39 <clandmeter> 
ACTION slaps fcolista around a bit with a large trout

2021-06-18 09:44:40 <fcolista> yes, of course
2021-06-18 09:44:45 <fcolista> (right now)
2021-06-18 09:44:49 <fcolista> :D
2021-06-18 09:45:22 <fcolista> i wanted to push it along with the bareos fix actually
2021-06-18 09:45:29 <clandmeter> so that commit msg does not have much info
2021-06-18 09:45:50 <clandmeter> why does it fail to build?
2021-06-18 09:45:53 <clandmeter> can we fix it?
2021-06-18 09:46:06 <fcolista> strip: ./usr/lib/python3.9/site-packages/selenium/webdriver/firefox/amd64/x_ignore_nofocus.so: file format not recognized
2021-06-18 09:46:35 <clandmeter> huh
2021-06-18 09:46:50 <fcolista> seems a prebuild binary
2021-06-18 09:47:12 <fcolista> s/prebuild/prebuilt
2021-06-18 09:47:13 <alpine-meetbot> fcolista meant to say: seems a prebuilt binary
2021-06-18 09:47:15 <clandmeter> amd64 binaries on arm?
2021-06-18 09:48:15 <clandmeter> if it ships prebuild crap, it probably needs to be disabled completely 
2021-06-18 09:48:33 <fcolista> umh
2021-06-18 09:48:35 <fcolista> yeah
2021-06-18 09:48:43 <fcolista> I think I should remove that .so
2021-06-18 09:48:57 <clandmeter> well, maybe there is more fun in that pkg :)
2021-06-18 09:49:41 <fcolista> ./selenium/webdriver/firefox/x86/x_ignore_nofocus.so
2021-06-18 09:49:41 <fcolista> ./selenium/webdriver/firefox/amd64/x_ignore_nofocus.so
2021-06-18 09:49:45 <clandmeter> and why does bareos depend on it? does it run some tests?
2021-06-18 09:51:41 <fcolista> yes, seems so
2021-06-18 10:10:44 <Ariadne> probably makes sense to rm -rf the entirety of selenium
2021-06-18 10:10:55 <Ariadne> if its built for glibc, it is not going to work correctly anyway
2021-06-18 10:11:19 <fcolista> yeah
2021-06-18 10:15:03 <mercenary> Do they not ship the sources (or at least some Makefile) to create that .so ?
2021-06-18 10:24:04 <clandmeter> fcolista: can you build bareos without selelciumcrap?
2021-06-18 10:24:38 <clandmeter> i need to run, when i get home i can help you if needed.
2021-06-18 11:34:06 <clandmeter> fcolista: all ok now?
2021-06-18 11:51:47 <fcolista> clandmeter, jsut come back from lunch
2021-06-18 11:52:10 <fcolista> I tested build of bareos without selenium and built fine
2021-06-18 11:52:19 <BobbyTheBuilder> Hello, build-edge-aarch64	
2021-06-18 11:52:20 <fcolista> no idea why i added this
2021-06-18 11:52:31 <clandmeter> :)
2021-06-18 11:52:54 <fcolista> even because py3-selenium were not existing in the repo at all
2021-06-18 11:53:26 <BobbyTheBuilder> Hello, build-edge-aarch64 executor on build.alpinelinux.org is stuck on testing/clojure 1.10.3-r0 for more than 12 hours. could someon take a look at it ? Thank you.
2021-06-18 12:03:38 <clandmeter> BobbyTheBuilder: killed it
2021-06-18 12:06:14 <BobbyTheBuilder> @clandmeter> Thanks
2021-06-18 12:41:19 <BobbyTheBuilder> maxice8> for gnome-themes-extra you've also changed arch argument from all to noarch; would it explain why the package isn't build for aarch64 ?
2021-06-18 12:43:02 <BobbyTheBuilder> maxice8> Line #8 https://gitlab.alpinelinux.org/alpine/aports/-/commit/a9ca4b06cc2974a25a0ad3563e82bd7bdda39b05
2021-06-18 12:44:16 <maxice8> noarch just means there are no compiled machine code specific to a CPU architecture like aarch64, armhf, x86, riscv64, etc so it should be available on all arches
2021-06-18 12:45:09 <BobbyTheBuilder> okay thanks
2021-06-18 13:55:49 <MY-R> hey, shouldnt be "after firewall"? https://git.alpinelinux.org/aports/tree/main/sshguard/sshguard.initd
2021-06-18 14:47:33 <nmeum> MY-R: instead of `after iptables`? probably makes more sense and doesn't work with ip6tables otherwise I guess
2021-06-18 14:47:42 <nmeum> (the current version that is)
2021-06-18 14:47:58 <nmeum> interestingly, the gentoo service for sshguard also uses after iptables instead of after firewall
2021-06-18 14:48:18 <MY-R> sshguard doesnt work with nftables? 
2021-06-18 14:48:27 <nmeum> hm?
2021-06-18 14:49:30 <MY-R> init script assume that it will be used with iptables, what about nftables
2021-06-18 14:49:59 <nmeum> the present version also shouldn't work when used with ip6tables
2021-06-18 14:50:19 <nmeum> but the sshguard aport depends explicitly on iptables so maybe it does not work with nftables indeed
2021-06-18 14:55:06 <minimal> I'd guess that awall, iptables, iptables6, and nftables should all "provide firewall" and then other init.d scripts can define "after firewall"
2021-06-18 14:55:36 <minimal> though I'm not sure how the IPv4/v6 interaction would work - you'd want both v4 *and* v6 rules in place before starting other services
2021-06-18 14:55:46 <MY-R> looks like it should work with nftables "/usr/libexec/sshg-fw-nft-sets" same as with ip6tables
2021-06-18 14:58:23 <MY-R> will try set up sshguard later and check if will run before nftables or after, in first situation it will probably finish with error since wont be abble to create nft sets
2021-06-18 14:59:06 <minimal> MY-R: I've had sshguard installed on some machine here for months, just haven't found the time to tweak its config yet
2021-06-18 15:00:21 <MY-R> there shouldnt be much to tweak (I hope), I need it since fail2ban failing hard with tests :\
2021-06-18 15:34:34 <PureTryOut> https://dl-cdn.alpinelinux.org has some BAD signatures on x86_64 polkit-elogind 🤔
2021-06-18 15:34:56 <ikke> did something get reverted?
2021-06-18 15:35:02 <PureTryOut> No clue
2021-06-18 15:35:34 <PureTryOut> Last change to the package seems to have been done 5 days ago
2021-06-18 15:35:46 <PureTryOut> Which was only disabling it on riscv64
2021-06-18 15:35:47 <ikke> yeah
2021-06-18 16:08:03 <andypost[m]> What's wrong with ppc64le runner for 3.14? It trying to replace everything inside and fails on build.sh
2021-06-18 16:09:37 <andypost[m]> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/418731
2021-06-18 16:48:00 <tomalok> possibly unrelated, but i started having ppc64le problems with a gitlab.com pipeline a few days ago...  docker buildx --platform ...
2021-06-18 16:54:53 <tomalok> and tonistiigi/binfmt:latest
2021-06-18 16:56:25 <craftyguy> ikke, PureTryOut: what can be done about that "BAD signature" thing with polkit-elogind* ?
2021-06-18 16:56:32 <craftyguy> 
ACTION also seeing that

2021-06-18 16:57:14 <craftyguy> I assume signing keys don't change too often, right? or is that referring to something else?
2021-06-18 17:02:17 <Hello71> ncopa: do you use qemu-guest-agent?
2021-06-18 17:03:03 <ikke> craftyguy: these issues usually only happen when a package is downgraded to something that already existed before, and then only on dl-cdn
2021-06-18 17:03:50 <BobbyTheBuilder> looks like when it happens a pkgrel bump is done: https://gitlab.alpinelinux.org/alpine/aports/-/commits/master?utf8=%E2%9C%93&search=BAD+signature
2021-06-18 17:04:15 <ikke> BobbyTheBuilder: just a pkgrel is not an issue
2021-06-18 17:04:32 <craftyguy> BobbyTheBuilder: that tells me bumping the pkgrel 'fixes' it, not causes it
2021-06-18 17:04:37 <ikke> BobbyTheBuilder: the issue is when a newly built package appears under a name that already existed
2021-06-18 17:05:06 <craftyguy> (oops I misread your comment)
2021-06-18 17:05:19 <ikke> If that's the issue, it's enought to purge the cache on dl-cdn
2021-06-18 17:06:30 <BobbyTheBuilder> yeah I meant to say it seems it already happened in the past, the workaround was to bump pkgrel; as for the exact cause I'm clueless.
2021-06-18 17:08:12 <ikke> it's a solution
2021-06-18 17:08:24 <ikke> or more like a workaround
2021-06-18 17:26:11 <BobbyTheBuilder> well, 6 days ago a commit was created: https://git.alpinelinux.org/aports/log/community/polkit-elogind
2021-06-18 17:26:14 <BobbyTheBuilder> The patch says it was merged yesterday: https://git.alpinelinux.org/aports/patch/community/polkit-elogind?id=107f557b1c6d055915fd57df356731c0597febba
2021-06-18 17:26:18 <BobbyTheBuilder> It didn't had a bump pkgrel
2021-06-18 17:26:20 <BobbyTheBuilder> and today it got built: https://build.alpinelinux.org/buildlogs/build-edge-x86/community/polkit-elogind/
2021-06-18 17:26:23 <BobbyTheBuilder> So I'd say pkgrel should be bumped
2021-06-18 17:27:51 <PureTryOut> No it shouldn't have been bumped
2021-06-18 17:28:04 <PureTryOut> The only thing it did was disable it on an architecture, that does not require a pkgrel bump
2021-06-18 17:28:27 <PureTryOut> pkgrel should only be bumped when the contents of the package, most of the time metadata, changes. architectures it's available for is not part of the resulting package
2021-06-18 17:31:53 <ikke> in other words, just disabling the package on an arch does not cause it to be ruiblt
2021-06-18 17:31:56 <ikke> rebuilt on other arches
2021-06-18 17:33:41 <BobbyTheBuilder> Ohh ( I learn everyday :) ), but this is not what happened on the build infra, it did a full rebuild: https://build.alpinelinux.org/buildlogs/build-edge-x86/community/polkit-elogind/polkit-elogind-0.118-r1.log
2021-06-18 17:34:16 <ikke> Interesting
2021-06-18 17:44:32 <caskd> !13757 has introduced java-jdk general package and others but now i can't select a max version for packages (because of provides?)... how should i handle this?
2021-06-18 17:45:57 <caskd> trying to add java-jdk<15 fails as it selects openjdk16
2021-06-18 17:47:19 <Hello71> probably it should be provides=java-jdk=x
2021-06-18 17:47:32 <caskd> yeah that would be better imho
2021-06-18 17:48:48 <Hello71> but if you're doing apk add shouldn't you pick a specific provider?
2021-06-18 17:49:03 <caskd> is that possible?
2021-06-18 17:49:12 <Hello71> wait, no, they're different names
2021-06-18 17:49:24 <Hello71> i mean you can just do apk add openjdk15
2021-06-18 17:49:28 <Hello71> like, it still works
2021-06-18 17:49:44 <caskd> well yes but in that case i would just close and ignore the change
2021-06-18 17:49:51 <caskd> even though this is a pretty good change
2021-06-18 17:57:20 <caskd> is there anything like abump but for pkgrel?
2021-06-18 17:57:38 <ikke> apkgrel -a .
2021-06-18 17:57:59 <ikke> but a pkgrel bump is not required for polkit-elogind
2021-06-18 18:01:13 <ikke> fixed
2021-06-18 18:02:01 <craftyguy> how'd you fix it?
2021-06-18 18:02:13 <ikke> curl -XPURGE <pkgurl>
2021-06-18 18:02:22 <craftyguy> ah
2021-06-18 18:02:29 <ikke> it's just a caching issue
2021-06-18 18:02:33 <craftyguy> ikke: thanks for fixing it :D
2021-06-18 18:02:35 <ikke> just puring the cache fixes it
2021-06-18 18:02:38 <ikke> purging*
2021-06-18 18:02:40 <craftyguy> 
ACTION tries again

2021-06-18 18:05:38 <caskd> !22449 there we go, this should allow people to select versions
2021-06-18 18:05:57 <ikke> caskd: yes, that makes sense
2021-06-18 18:06:08 <ikke> I think :O
2021-06-18 18:06:38 <caskd> lemme test this in a clean env
2021-06-18 18:11:56 <caskd> yeah this should work fine, tested with: mkdir /tmp/a; apk add --allow-untrusted --root /tmp/a --initdb --repositories-file /etc/apk/repositories 'pulseaudio<0.4'
2021-06-18 18:13:00 <BobbyTheBuilder> @ikke: can you also purge this one: polkit-elogind-openrc-0.118-r1
2021-06-18 18:13:05 <caskd> and ofc alpine-base whoops
2021-06-18 18:15:31 <ikke> 0done
2021-06-18 18:18:12 <PureTryOut> All polkit-elogind subpackages should be purged, not just single ones.
2021-06-18 18:18:16 <ikke> yes
2021-06-18 18:18:25 <PureTryOut> Currently I still get BAD signatures on -doc and -dev
2021-06-18 18:18:34 <ikke> I'm working on a tool to automate that
2021-06-18 18:18:42 <PureTryOut> Good!
2021-06-18 18:18:58 <ikke> I already used it to purge latest-stable
2021-06-18 18:19:56 <ikke> still puzzled though why it was rebuilt in the first place
2021-06-18 18:20:43 <BobbyTheBuilder> ikke: Thank you :) on my side all the packages I need can be installed
2021-06-18 18:21:35 <PureTryOut> Only -doc and -dev left for me 😜
2021-06-18 18:22:12 <ikke> purged them manually now as well
2021-06-18 18:22:31 <PureTryOut> Thanks
2021-06-18 18:22:34 <PureTryOut> the riscv64 builder is stuck btw
2021-06-18 18:22:49 <PureTryOut> Has been building kwayland for way too long, at least an hour, while it should take only minutes
2021-06-18 18:24:18 <ikke> killed the process
2021-06-18 18:24:23 <ikke> algitbot: retry master
2021-06-18 18:24:36 <PureTryOut> Great
2021-06-18 18:24:39 <ikke> some cmake process was stuck
2021-06-18 18:25:12 <PureTryOut> Hmm just while building it seems, somewhere in Make I guess
2021-06-18 19:14:23 <rzl[m]> Good afternoon! I am trying to install thunderbird@edge but it seems like its libraries conflict with firefox's. I've listed both package's contents and they don't conflict at all. Is this some limitation of apk and if so is there interesting in fixing it? I might take a shot at it
2021-06-18 19:16:43 <ikke> it has more to do with dependencies
2021-06-18 19:17:47 <PureTryOut> I have both Thunderbird and Firefox installed right now, no conflicts. Thunderbird just segfaults, but that's a different problem
2021-06-18 19:19:49 <ikke> reproduces for me
2021-06-18 19:19:54 <ikke> not clear why, though
2021-06-18 19:25:44 <rzl[m]> It seems like the problem is in provides. The automatically detected .so are provided by both packages so apk refuses to install even though they install under different directories
2021-06-18 19:30:05 <Cogitri> You have to set a so_prefix
2021-06-18 19:30:10 <Cogitri> See FF/Thunderbird for that
2021-06-18 19:30:28 <Cogitri> Uh actually, just read the backlog, not a great example apparently :D
2021-06-18 19:30:40 <Cogitri> But I thought we fixed that
2021-06-18 19:31:36 <PureTryOut> Lol
2021-06-18 19:33:55 <bl4ckb0ne> 2/b 13
2021-06-18 19:33:58 <bl4ckb0ne> wops
2021-06-18 19:35:44 <rzl[m]> Cogitri: thanks, I'll try it and see if I can get apk to shut up about it
2021-06-18 20:07:44 <Cogitri> https://mobile.twitter.com/rjek/status/1405890267371163651
2021-06-18 20:08:09 <Cogitri> A full GNOME desktop on riscv, exciting times
2021-06-18 20:09:11 <PureTryOut> It would be lovely if somebody could figure out the PHP7 and PHP8 build failures on riscv64 🙈
2021-06-18 20:09:32 <PureTryOut> Cogitri: cool! We could have the same once Rust is bootstrapped 😃 Same for Plasma
2021-06-18 20:09:52 <mps> yesterday I downloaded free desktop sdk image for riscv and tried it qemu
2021-06-18 20:10:07 <mps> in*
2021-06-18 20:33:46 <PureTryOut> #_oftc_#alpine-commits:matrix.org looking lovely red as always
2021-06-18 20:35:46 <ikke> mostly the same things failing
2021-06-18 20:46:51 <PureTryOut> Yeah, it looks bad though
2021-06-18 20:48:12 <ikke> someone needs to take a look at luajit for mips
2021-06-18 23:40:59 <andypost[m]> PureTryOut (matrix.org): filed https://gitlab.alpinelinux.org/alpine/aports/-/issues/12775 no idea how to fix it
2021-06-19 00:53:18 <Hello71> i wonder if alpine has considered the ramifications of distributing cddl licensed zfs
2021-06-19 00:53:37 <Hello71> considering we're ditching bdb
2021-06-19 05:10:43 <kevint> I'm running into an issue trying to write an apkbuild. In the package function I install the default config file to the /etc directory, and I can see that the file is there in /etc when I inspect the pkg directory after it builds. But when I apk install the resulting package, the file and directory doesn't get created. I'm wondering what could be
2021-06-19 05:10:44 <kevint> going wrong?
2021-06-19 05:23:40 <craftyguy> is amove supposed to move symlinks too?
2021-06-19 05:24:04 <craftyguy> kevint: could you post your APKBUILD?
2021-06-19 05:27:45 <kevint> craftyguy sure thing: https://gitlab.alpinelinux.org/KevinThomas0/aports/-/blob/fileshelter/testing/fileshelter/APKBUILD
2021-06-19 05:34:06 <craftyguy> huh, I don't see anything obviously wrong with that
2021-06-19 07:31:01 <mps> !22467 aren't we 'decided' to gradually remove -static subpkgs for libs
2021-06-19 07:31:45 <mps> (which I proposed long time ago)
2021-06-19 07:39:21 <ikke> interestingly, we did have an issue the other day due to static libraries being used instead of dynamic
2021-06-19 07:41:03 <mps> anyway, should we (I) block this MR till we be clear about -static libs, though I think we are already
2021-06-19 07:50:58 <PureTryOut> andypost: earlier we had problems GCC not automatically linking libatomic. Might such a thing be happening here as well?
2021-06-19 07:54:12 <nbm> anyone has trouble capturing mic audio with obs-studio ?
2021-06-19 07:55:27 <mps> oh, ncopa already reported mtools bug https://lists.gnu.org/archive/html/info-mtools/2021-06/msg00016.html :)
2021-06-19 08:07:02 <mps> ikke: I remember now that you told something about so libs problem in libudev-zero but forgot what exactly
2021-06-19 08:07:54 <mps> do you remember, by chance?
2021-06-19 08:10:55 <ikke> mps: I think that was a different issue
2021-06-19 08:11:35 <ikke> libudev-zero provides udev without a version added
2021-06-19 08:11:44 <mps> ah
2021-06-19 08:12:13 <ikke> it should be provides="udev=$pkgver-r$pkgrel"
2021-06-19 08:12:39 <mps> aha, yes. thanks for reminder and sorry for misleading question
2021-06-19 08:53:15 <nmeum> has anybody investigated the textrels problem on riscv64 yet? some packages, e.g. supertuxkart, fail in postcheck() due to textrels. why does that happen only on riscv64?
2021-06-19 09:57:56 <shum> Cogitri would you kindly review my merge request?
2021-06-19 09:58:21 <shum> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21501
2021-06-19 10:02:06 <shum> Thank you!
2021-06-19 10:16:44 <andypost[m]> Is there a way to run riscv64 build to test !22478 /cc PureTryOut (matrix.org) 
2021-06-19 10:17:19 <nmeum> you could try it in a qemu-user riscv64 chroot
2021-06-19 10:17:31 <andypost[m]> thank you, gonna try
2021-06-19 10:17:57 <PureTryOut> andypost: get latest abuild rootbld, and then `CBUILD=riscv64 mirror=https://dev.alpinelinux.org/~clandmeter/packages/riscv64 abuild rootbld`
2021-06-19 10:18:12 <PureTryOut> Oh and you need qemu-openrc, qemu-riscv64 and have the `qemu-binfmt` service enabled
2021-06-19 10:18:27 <nmeum> yep, latest rootbld can create an qemu-user riscv64 chroot for you
2021-06-19 10:18:40 <nmeum> very convenient :)
2021-06-19 10:18:47 <PureTryOut> Yup, works really nice
2021-06-19 10:19:01 <PureTryOut> It'll be slow ofc but it works great
2021-06-19 10:19:23 <andypost[m]> as I see https://github.com/alpinelinux/alpine-chroot-install/ is could work
2021-06-19 10:21:43 <mps> andypost[m]: I can try in riscv64 lxc if you want
2021-06-19 10:22:12 <andypost[m]> mps: please try if it went ok PHP 8 could use the same
2021-06-19 10:22:34 <mps> ok, will do, just to finish postfix backport
2021-06-19 10:34:37 <mps> andypost[m]: https://tpaste.us/R4Zr
2021-06-19 10:35:24 <andypost[m]> means this dependencies are not ready
2021-06-19 10:35:27 <mps> someone should force upload built riscv packages to mirror
2021-06-19 10:35:34 <mps> yes
2021-06-19 10:35:45 <PureTryOut> It does already upload everything it builds, just not immediately
2021-06-19 10:36:22 <mps> ok, will try later again, with a hope
2021-06-19 10:39:12 <andypost[m]> at least I got chroot working and can continue dig it
2021-06-19 10:39:32 <PureTryOut> You can build RISC-V stuff without a chroot as well
2021-06-19 10:40:51 <andypost[m]> I did use it before and looks easy to go known way)
2021-06-19 10:42:24 <andypost[m]> there's php 8.1 coming this year so enough of work ahead !22236
2021-06-19 10:42:57 <PureTryOut> Ah yeah sure, whatever works for you
2021-06-19 11:17:56 <bratkartoffel> !22449 adds versions to the java provides. should the version really be that specific? e.g. provides=java-jre="10.0.2_p13-r2"   wouldn't it make more sense for just provides="java-jre=10"?
2021-06-19 11:22:01 <bratkartoffel> the whole purpose for it is to write something like depends="java-jre=11" or depends="java-jre<14". using such a specific version wouldn't allow it to write an explicit dependency like my first example, would it?
2021-06-19 11:22:15 <bratkartoffel> or do I understand the feature a bit different than it actually is?
2021-06-19 11:24:54 <PureTryOut> afaik you can do `depends="java-jre<14"` with the specific version
2021-06-19 11:27:18 <ikke> bratkartoffel: to be honest, I do not know all the implications when you specify =14 or =14.x.y.z-rn
2021-06-19 11:27:34 <ikke> but it's a common pattern to use the parent package's version
2021-06-19 12:01:02 <[[sroracle]]> I don't think you can do =X instead of =X.Y.Z-rR because it would never match
2021-06-19 12:01:29 <[[sroracle]]> You can do >, >=, <, <=, and ~ with it though
2021-06-19 12:02:50 <[[sroracle]]> in that case > and >= would be the same unless you give the full version for the same reason, but you could also do >~... and so on
2021-06-19 13:39:06 <andypost[m]> PureTryOut (matrix.org): sadly libatimic does not help(
2021-06-19 13:41:19 <andypost[m]>  * PureTryOut (matrix.org): sadly libatomic does not help(
2021-06-19 13:57:28 <PureTryOut> Yeah I saw 😢
2021-06-19 16:06:17 <caskd> does anyone else have problems with haproxy 2.4.1? I've upgraded and none of my backends even loaded
2021-06-19 16:06:29 <caskd> trying to trace down the problem, downgrading fixes it
2021-06-19 16:17:26 <caskd> seems like libc resolver doesn't work anymore on new version
2021-06-19 16:17:29 <caskd> for init-addr
2021-06-19 16:17:58 <mps> caskd: it works for me
2021-06-19 16:18:05 <caskd> 2.4.1?
2021-06-19 16:18:12 <mps> yes
2021-06-19 16:18:22 <caskd> i use SRV records, might have to do with that
2021-06-19 16:18:26 <caskd> with server-template
2021-06-19 16:18:45 <mps> I do not
2021-06-19 16:19:01 <mps> so can't test
2021-06-19 16:19:22 <caskd> nvm, not init-addr
2021-06-19 16:19:49 <caskd> but something related to backends, as i don't see any backends being initalised
2021-06-19 16:23:45 <caskd> http://0x0.st/-914.mp4 O.o identical configurations, yet different behaviour
2021-06-19 17:06:44 <caskd> hmm it seems like they disabled server-template
2021-06-19 17:12:07 <caskd> narrowed it down to specifically SRV server-template
2021-06-19 17:53:50 <ikke> Anyone got a clue how to debug (strace) the server part of rsync?
2021-06-19 18:41:38 <Hello71> rsyncd or rsync ssh?
2021-06-19 18:41:52 <Hello71> for rsyncd of course you just do strace rsyncd
2021-06-19 18:42:17 <Hello71> for rsync ssh, rsync --rsync-path='strace rsync' should work but maybe you need strace -o
2021-06-19 18:42:30 <Hello71> i think stderr goes to the original stderr though
2021-06-19 18:50:31 <ikke> rsync ssh
2021-06-19 19:20:45 <PureTryOut> Great, I can't get riscv64 to retry the community repo anymore
2021-06-19 19:21:01 <Hello71> good news, i re-investigated docker, and the situation sucks less now. the runc changes have slowly propagated through containerd and docker, so now you don't need to update libseccomp anymore
2021-06-19 19:21:57 <ikke> Hello71: still getting issues about it though
2021-06-19 19:22:10 <Hello71> yes well people don't apply security updates
2021-06-19 19:22:17 <ikke> :)
2021-06-19 19:22:35 <ikke> Ah, you already closed the latest on
2021-06-19 19:22:35 <Hello71> also i think some people might still be on docker 19.whatever
2021-06-19 19:22:36 <ikke> one
2021-06-19 19:22:51 <Hello71> yes
2021-06-19 19:23:06 <ikke> Did you take a look at this one? https://gitlab.alpinelinux.org/alpine/aports/-/issues/12764
2021-06-19 19:23:09 <Hello71> also ubuntu updated libseccomp so even docker 19 should work there
2021-06-19 19:23:20 <Hello71> hm, didn't see it
2021-06-19 19:25:13 <Hello71> not sure what's going on there
2021-06-19 19:25:45 <ikke> yeah
2021-06-19 19:28:38 <Hello71> oh i see
2021-06-19 19:28:43 <Hello71> their posted docker info is wrong
2021-06-19 19:28:49 <Hello71> look at the linked log, it's 19.03.8
2021-06-19 19:31:13 <ikke> where do you see that?
2021-06-19 19:31:49 <ikke> Server: Docker Engine - Community
2021-06-19 19:31:50 <ikke>  Engine:
2021-06-19 19:31:52 <ikke>   Version:          20.10.7
2021-06-19 19:31:53 <Hello71> "relevant ci failure here"
2021-06-19 19:32:02 <ikke> ah
2021-06-19 19:32:20 <Hello71> actually can users reopen issues? i keep saying to do that but i'm not sure if it's actually allowed now that i think about it
2021-06-19 19:33:08 <Cogitri> I think only the reporter can re-open issues
2021-06-19 19:33:18 <ikke> They can still respond to issues though
2021-06-19 19:33:24 <ikke> so we still get notifications
2021-06-19 19:33:24 <Cogitri> Any user can comment on closed issues though and request the devs to re-open though
2021-06-19 19:34:18 <Hello71> ah, i see. i think on github the reporter cannot reopen (by default?)
2021-06-19 19:35:41 <Cogitri> I think they can
2021-06-19 19:35:51 <Cogitri> Let me check
2021-06-19 19:36:51 <Cogitri> Ah, on Github you can re-open if you closed it but not when the devs closed it
2021-06-19 19:37:47 <Hello71> hm
2021-06-20 07:44:05 <ikke> hmmm: "ERROR: py3-dotenv-0.15.0-r1: package mentioned in index not found (try 'apk update')"
2021-06-20 07:45:03 <ikke> (3.14)
2021-06-20 08:04:29 <PureTryOut> Can someone give the riscv64 builder a kick? It doesn't want to retry the community branch anymore
2021-06-20 08:09:18 <ikke> PureTryOut: I think there is some ind of issue that affects all builders (See #alpine-infra)
2021-06-20 08:09:37 <ikke> build-edge-riscv64: uploading packages to main
2021-06-20 08:09:39 <ikke> build-edge-riscv64: failed
2021-06-20 08:09:53 <PureTryOut> Yeah seems like it
2021-06-20 08:09:56 <PureTryOut> Ok joined
2021-06-20 08:31:45 <PureTryOut> Cogitri: any luck so far bootstrapping Rust on s390x or riscv64? 😃
2021-06-20 09:02:00 <ikke> issue has been fixed, was a syntax error in an APKBUILD
2021-06-20 10:03:41 <mps> does it make sense to disable check for https://build.alpinelinux.org/buildlogs/build-edge-x86/testing/async-profiler/async-profiler-1.5-r2.log
2021-06-20 10:12:48 <ikke> are all checks broken somehow?
2021-06-20 10:13:31 <mps> I don't know java so can't tell much
2021-06-20 10:21:11 <ikke> signal-cli is also failing 
2021-06-20 10:21:48 <mps> a lot of pkgs also
2021-06-20 10:25:52 <Cogitri> PureTryOut (matrix.org): Ah no, I'll try setting up the riscv64 sysroot today
2021-06-20 10:26:48 <PureTryOut> Oh yay 😃
2021-06-20 10:27:08 <mps> also I'm going to build riscv kernel, can't wait till builder start build testing
2021-06-20 14:17:53 <kasper81> hi fellas, sorry i made a typo in the last pr and now nim is broken. if you have powers, please merge this MR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22381
2021-06-20 14:24:17 <ikke> kasper81: taking a look
2021-06-20 14:25:48 <kasper81> ikke: appreciated :) 
2021-06-20 14:26:28 <kasper81> this will unblock !22382
2021-06-20 14:31:28 <ikke> kasper81: Would be helpful to have a short description in the commit message about why this is correct
2021-06-20 14:42:01 <kasper81> ikke: sure, pushed an update. d521575166e5 describes the change (regression from my previous MR)
2021-06-20 14:42:55 <ikke> Thanks, appreciated
2021-06-20 16:22:42 <kasper81> Thanks ikke for merging. unfortunately, only arm package was updated to r1, other jobs were cancelled somehow. it's a quite annoying issue that package publish jobs only run once and if that get cancelled or skipped, build infra doesn't retry.
2021-06-20 16:23:00 <kasper81> should i create a separate MR to bump r1 to r2?
2021-06-20 16:24:07 <ikke> kasper81: don't confuse CI with our builders
2021-06-20 16:24:31 <ikke> and
2021-06-20 16:24:53 <ikke> if the builders have a build failures, these need to be fixed first before packages are uploaded
2021-06-20 16:25:52 <ikke> The builders will keep retrying building packages
2021-06-20 16:30:19 <kasper81> is there a place where i can find the build/package logs for nim aarch64 and x86_64? only armhf and v7 were updated it seems.
2021-06-20 16:33:07 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-x86/testing/nim/
2021-06-20 16:33:15 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/nim/
2021-06-20 16:33:23 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-aarch64/testing/nim/
2021-06-20 16:51:37 <ikke> kasper81: also check https://build.alpinelinux.org/
2021-06-20 16:52:07 <ikke> async-profiler is failing on certain arches, preventing nim from being built
2021-06-20 18:02:23 <insep> mps: i recall you having page about installing alpine to some arm platform, do you still have link to that?
2021-06-20 18:06:45 <ikke> https://arvanta.net/mps/install-aarch64-under-qemu.txt ?
2021-06-20 18:07:02 <ikke> https://arvanta.net/alpine/install-aarch64-qemu/
2021-06-20 18:18:55 <insep> nah i think it was armv7
2021-06-20 18:19:39 <insep> ah, it was https://arvanta.net/alpine/install-arm-under-qemu/
2021-06-20 18:20:42 <insep> thanks
2021-06-20 19:33:55 <PureTryOut> So far basically every Go package is failing for different reasons on riscv64 😢
2021-06-20 20:14:19 <clandmeter> PureTryOut: which pkgs?
2021-06-20 20:14:55 <PureTryOut> Uh I don't remember any particular out of the top of my head, let me check
2021-06-20 20:15:18 <PureTryOut> gotop for example, https://build.alpinelinux.org/buildlogs/build-edge-riscv64/community/gotop/gotop-4.1.1-r1.log
2021-06-20 20:16:11 <clandmeter> ah those
2021-06-20 20:16:31 <clandmeter> most are syscalls
2021-06-20 20:16:54 <clandmeter> not compat with rv64 (yet)
2021-06-20 20:17:48 <PureTryOut> Yeah guess so
2021-06-20 20:20:41 <PureTryOut> How would we fix those things though?
2021-06-20 20:27:12 <nmeum> assuming the syscalls is available for riscv64 this needs to be fixed in go
2021-06-20 20:27:37 <nmeum> syscall is a go standard library package
2021-06-20 20:28:08 <clandmeter> PureTryOut: i think we can fix it
2021-06-20 20:28:31 <clandmeter> looks like there is already a fix for arm64 which can be used for rv64 aswell 
2021-06-20 20:28:53 <nmeum> for go?
2021-06-20 20:28:54 <clandmeter> it used dup3 instead of dup2
2021-06-20 20:29:13 <nmeum> ?
2021-06-20 20:29:29 <clandmeter> https://github.com/xxxserxxx/gotop/blob/master/logging/logging_arm64.go
2021-06-20 20:29:45 <nmeum> but why is dup2 not available on arm/riscv64?
2021-06-20 20:30:40 <clandmeter> This happens because there is not dup2 syscall on riscv64, just like
2021-06-20 20:30:40 <clandmeter> arm64. Instead dup3 should be used which provide the same features with
2021-06-20 20:30:40 <clandmeter> the possibility to also pass additional flags. The issue has already
2021-06-20 20:30:40 <clandmeter> been fixed upstream:
2021-06-20 21:45:41 <mps> insep: something of these https://arvanta.net/alpine/
2021-06-20 21:50:40 <Ariadne> clandmeter: trying to source one of those huawei riscv64 servers that they're only selling inside mainland china, btw
2021-06-20 21:51:44 <Ariadne> or rather alibaba
2021-06-20 21:52:05 <clandmeter> you have contacts in china?
2021-06-20 21:53:23 <Ariadne> i have some friends who live in shanghai, yes
2021-06-21 04:33:26 <ikke> bratkartoffel: seems like several java related projects are failing lately
2021-06-21 04:34:10 <ikke> async-profiler, bazel3, signal-cli, sigar
2021-06-21 07:57:35 <kasper81> ikke: nim package was not updated properly. other package updates since have been ran.  
2021-06-21 07:58:26 <kasper81> should i send an MR just updating r1 to r2 because somehow package job got cancelled? or can someone with powers rerun the job manually?
2021-06-21 08:00:58 <ikke> No
2021-06-21 08:03:17 <kasper81> https://pkgs.alpinelinux.org/packages?name=libconfig&branch=edge was merged 14 hours ago and is updated in packages.
2021-06-21 08:05:22 <ikke> They _will_ be retried 
2021-06-21 08:07:52 <ikke> The builders will make sure every package gets built 
2021-06-21 08:13:35 <kasper81> alright, so i will sit tight and wait for few days. even the ppc64le job from 7+ days ago hasn't been updated https://pkgs.alpinelinux.org/packages?name=nim.
2021-06-21 08:30:47 <PureTryOut> Cogitri: sorry for bothering and maybe pushing you with this, but have you had any luck with bootstrapping Rust on riscv64 this weekend? 😅 It would save so much work if we had that available
2021-06-21 09:35:41 <mps> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/420504#L43
2021-06-21 09:36:25 <mps> lint says 'SC3060: In dash, string replacement is not supported.' we don't use dash
2021-06-21 10:15:06 <PureTryOut> It seems like the riscv64 builder is stuck again... Or `community/bullet` just takes really long to compile
2021-06-21 11:18:40 <PureTryOut> Nah it's definitely stuck, it takes way too long
2021-06-21 11:19:57 <ikke> hanging on doxygen
2021-06-21 11:20:58 <ikke> Running dot for graph 2509/2510
2021-06-21 11:21:00 <ikke> Running dot for graph 2510
2021-06-21 11:21:05 <ikke> it stopped there
2021-06-21 11:22:47 <PureTryOut> Oh fun, so close!
2021-06-21 11:28:46 <kasper81> how was libconfig published on x86_64 while the queue was blocked at asyn-profiler for everyone else?
2021-06-21 11:29:42 <kasper81> i guess if you have access you can prioritize queue of "your" package.
2021-06-21 11:33:38 <Ariadne> libconfig isnt in testing iirc
2021-06-21 11:41:53 <shum> Hmm, lgogdownloader package that was recently merged is available only for amrhf and armv7, but I can see that there's build log available for other arches (https://build.alpinelinux.org/buildlogs/build-edge-x86/testing/lgogdownloader/lgogdownloader-3.7-r0.log for example). Is there's something wrong with repos?
2021-06-21 11:42:15 <shum> Is there*
2021-06-21 11:46:52 <kasper81> shum: same case with nim, merged 17+ hrs. ago, buildlogs available for x64 with explicit ">>> nim*: Create nim-1.4.8-r1.apk" and signing message, but no package was published.
2021-06-21 11:47:26 <kasper81> Ariadne: ah, so each repository has a separate queue i reckon.
2021-06-21 11:47:43 <Ariadne> kasper81: yes
2021-06-21 11:48:10 <Ariadne> kasper81: testing wont upload until its green
2021-06-21 11:50:10 <Ariadne> [06:49:23] <algitbot> edge/testing/x86_64: uploaded
2021-06-21 11:50:14 <Ariadne> its green
2021-06-21 11:50:32 <Ariadne> if you like things to be available, work to get them out of testing
2021-06-21 11:50:47 <Ariadne> testing is 'best effort' :)
2021-06-21 11:53:35 <shum> I see.
2021-06-21 17:30:15 <insep> either my messages didn't get delivered to #alpine-linux or it's *that* slow, so i'm going to ask there: how different are uboot images from http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/armv7/ and "disk" installation type?
2021-06-21 17:30:47 <Habbie> insep, you're not in #alpine-linux :)
2021-06-21 17:31:50 <insep> then my messages didn't get delivered at all :\
2021-06-21 17:32:04 <Habbie> looks that way
2021-06-21 17:33:12 <insep> am i there now?
2021-06-21 17:33:38 <Habbie> no
2021-06-21 17:33:49 <Habbie> are you logged in to nickserv?
2021-06-21 17:34:41 <Sheila> you will need to identify with oftc services on the IRC side in order for the matrix bridge to let you in.
2021-06-21 17:34:56 <insep> i am there somehow ;)
2021-06-21 17:35:09 <ikke> You do not appear for us
2021-06-21 17:35:12 <Habbie> is it possible the matrix bridge is letting you read, because somebody else on the bridge is in there?
2021-06-21 17:35:21 <insep> i mean here
2021-06-21 17:35:36 <Habbie> yes
2021-06-21 17:35:40 <Habbie> i don't understand how you are here :D
2021-06-21 17:36:14 <Sheila> matrix integration with IRC is shit shocker
2021-06-21 17:37:37 <Habbie> insep, welcome back, your /whois now -does- show you identified with services
2021-06-21 17:38:13 <insep> are my messages shown in that channel now?
2021-06-21 17:38:31 <ikke> insep: yes, I responded to you
2021-06-21 17:38:33 <Sheila> 👍
2021-06-21 17:38:55 <insep> perfect, now i can't see your messages :\
2021-06-21 17:39:06 <insep> maybe one more rejoin will fix stuff ^^
2021-06-21 17:39:12 <Sheila> no, matrix is just trash.
2021-06-21 17:39:24 <insep> that too
2021-06-21 17:39:46 <insep> but oftc is even more so /s
2021-06-21 17:41:00 <Sheila> I mean, yes, IRC is also trash, but that's a discussion for somewhere else.
2021-06-21 17:45:48 <insep> can someone write something in #alpine-linux?
2021-06-21 17:46:33 <Habbie> done
2021-06-21 18:50:19 <kasper81> aarch64 builder is running `community/java-jna 5.6.0-r1` for past day or two. it's most likely stuck?
2021-06-21 18:51:18 <ikke> yes, that's certainly possible
2021-06-21 18:51:53 <ikke> killed it
2021-06-21 19:03:01 <kasper81> thanks. does killing it free the builder for pending jobs?
2021-06-21 19:03:32 <ikke> yes and no
2021-06-21 19:03:49 <ikke> it depends on what order it builds things
2021-06-21 19:04:08 <ikke> sometimes it goes straight into building the same package again
2021-06-21 19:04:28 <ikke> What it does do is first build everything in main, then community, then testing
2021-06-21 19:04:37 <ikke> (everything that needs to be built)
2021-06-21 19:04:55 <ikke> If you look here: https://build.alpinelinux.org/
2021-06-21 19:05:07 <ikke> You see that build-edge-aarch64 is now building packages in main
2021-06-21 19:05:15 <ikke> ncurses, bash
2021-06-21 19:06:44 <kasper81> yes, i am watching the same page. great to see it has resumed building.
2021-06-21 19:07:11 <kasper81> there is no `build-edge-ppc64le`?
2021-06-21 19:11:07 <ikke> there should be
2021-06-21 19:13:13 <ikke> dns issues on the builder
2021-06-21 19:17:28 <ikke> that looks better
2021-06-21 19:22:28 <Cogitri> PureTryOut (matrix.org): Just started the riscv64 bootstrapping (as in for the sysroot), let's see how that goes
2021-06-21 19:23:03 <Cogitri> Was pretty busy with moving flats, but I hope I have time to look into Rust tomorrow (if the sysroot builds tonight)
2021-06-21 19:23:56 <PureTryOut> Oh great!
2021-06-21 19:24:04 <PureTryOut> You're moving? To a different town or just different house?
2021-06-21 19:29:23 <kasper81> alpine riscv64 sysroot bootstrapping on debian host was just `curl -sSL https://raw.githubusercontent.com/alpinelinux/alpine-chroot-install/master/alpine-chroot-install     | sh -s -- -a riscv64 -b edge`
2021-06-21 19:30:50 <kasper81> also added support for alpine and fedora/RHEL hosts https://github.com/alpinelinux/alpine-chroot-install/pull/29
2021-06-21 19:50:05 <Cogitri> PureTryOut (matrix.org): I moved from Kiel (city where my university is) to a smaller villager. Uni is all remote for the rest of my studies so there's not really a reason to keep a relatively small and expensive flat when I can have a flat 3x the size in a pretty nice village too :p
2021-06-21 19:50:32 <Cogitri> Maybe I'll move back to Kiel in a year or two for my master's degree, but I'll see how that goes
2021-06-21 19:51:12 <PureTryOut> Ah yes understandable. Nice!
2021-06-21 19:51:54 <Cogitri> Certainly glad I'm done with the move, that sure was taxing :D 
2021-06-21 19:52:17 <Cogitri> At least I only had to move stuff from a relatively small flat and not an entire house ^^
2021-06-21 19:54:09 <ikke> :D
2021-06-21 20:09:42 <Cogitri> Hm, building openssl on riscv64 fails for me with: `openssl: Unable to determine architecture from (CARCH=riscv64)`
2021-06-21 20:13:47 <dalias> lol..
2021-06-21 20:14:17 <dalias> why do they do stupid shit like that rather than "if (unknown_arch) use_portable_C_code"
2021-06-21 20:14:34 <dalias> they even have portable C
2021-06-21 20:14:43 <dalias> but make you explicitly request it
2021-06-21 20:14:45 <dalias> >_<
2021-06-21 20:19:04 <Cogitri> I'm actually not sure if that's coming from openssl itself or abuild
2021-06-21 20:19:26 <Cogitri> Do I need something newer than 3.8.0_rc4 for riscv64?
2021-06-21 20:23:07 <dalias> ah, hmm
2021-06-21 20:26:21 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/commit/51c03644baec0cea73a4735f4cb9b0087dccf607
2021-06-21 20:27:14 <mps> Cogitri: maybe update_config_sub and update_config_guess could help
2021-06-21 20:27:27 <mps> iirc this helped me with tcsh
2021-06-21 20:27:30 <ikke> That's only for autoconf
2021-06-21 20:28:24 <ikke> Cogitri: 3.8.0_rc4 should have it
2021-06-21 20:30:36 <mps> I see, it is missing set arch
2021-06-21 20:32:47 <ikke> Cogitri: I don't see that message in abuild
2021-06-21 20:33:05 <mps> I see it
2021-06-21 20:35:03 <mps> problem is openssl doesn't have linux64-riscv support
2021-06-21 20:36:27 <dalias> it should just ignore arch then
2021-06-21 20:42:12 <mps> https://tpaste.us/MQPD
2021-06-21 20:42:49 <mps> with this change in APKBUILD https://tpaste.us/E1j5
2021-06-21 20:43:46 <ikke> ah, it's in the APKBUILD itself
2021-06-21 20:50:46 <Cogitri> Oh, I had assumed the riscv64 builder would've built openssl already
2021-06-21 20:55:04 <Cogitri> Thanks, I'll try that tomorrow
2021-06-21 20:57:39 <PureTryOut> Uh, openssl should be build already yes, it's in main and that was fully built already before
2021-06-21 20:57:59 <PureTryOut> And it is listed and downloadable from https://dev.alpinelinux.org/~clandmeter/packages/riscv64/edge/main/riscv64/
2021-06-21 20:59:58 <clandmeter> openssl is in boostrap pkgs
2021-06-21 21:04:44 <Cogitri> Yeah, weird that it didn't work for me, I'm pretty sure I pulled last master
2021-06-21 21:08:25 <clandmeter> Cogitri: its correct i think
2021-06-21 21:09:12 <clandmeter> that it fails :)
2021-06-21 21:10:05 <clandmeter> i think i missed that when moving to official remote 
2021-06-21 21:10:42 <clandmeter> mps: i think we need to set linux-generic64
2021-06-21 21:13:37 <Cogitri> Oh :)
2021-06-21 21:22:15 <clandmeter> looks like roman put in another change
2021-06-21 21:22:48 <clandmeter> its a pity his changes are in a single commit with no meaningful msg.
2021-06-21 21:23:07 <clandmeter> Ariadne: ping
2021-06-21 21:35:36 <clandmeter> dalias: do you have an idea why roman (who bootrapped riscv64) would set no-asm and no-threads for openssl?
2021-06-21 21:45:35 <Ariadne> i've no idea
2021-06-21 21:47:21 <mps> clandmeter: looks like this works, now in check phase
2021-06-21 21:49:37 <Ariadne> clandmeter: i pinged roman
2021-06-21 21:50:20 <clandmeter> looks like fedora does not include those switches
2021-06-21 22:17:57 <clandmeter> Ariadne: ok thx, it builds fine without them.
2021-06-21 23:39:57 <dalias> clandmeter, no-threads is badly wrong
2021-06-21 23:40:06 <dalias> no-asm is correct if openssl lacks asm for riscv
2021-06-22 06:06:19 <kevint> Just remembered I was looking to get some help getting something onto https://dev.alpinelinux.org/archive/ardour/ in order to fix the ardour package: !21517
2021-06-22 06:07:32 <kevint> It's related to this issue: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12619
2021-06-22 06:31:20 <ncopa> good morning!
2021-06-22 07:08:47 <PureTryOut> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22539 will fix the libcap build failure on riscv64
2021-06-22 07:15:38 <clandmeter> PureTryOut: that is probably the reason for the checkdepends
2021-06-22 07:16:20 <PureTryOut> Yes but clearly Bash isn't just used for testing
2021-06-22 07:54:31 <PureTryOut> Could that MR be merged please? 😃
2021-06-22 07:54:58 <clandmeter> do we still need bash in checkdeps?
2021-06-22 07:59:03 <kasper81> edge-aarch64 builder got stuck at community/java-lz4 1.7.1-r1
2021-06-22 08:02:45 <clandmeter> dalias, Ariadne: i think its from here: https://mta.openssl.org/pipermail/openssl-users/2020-March/011996.html
2021-06-22 08:06:32 <mps> clandmeter: it passed in my test with 'linux-generic64'
2021-06-22 08:07:07 <clandmeter> mps: yes i think we can just push it with linux-generic64
2021-06-22 08:07:18 <clandmeter> and without no-asm and no-threads
2021-06-22 08:07:29 <clandmeter> i hope it does not break abi
2021-06-22 08:09:40 <mps> btw, why I get 'ERROR: APKINDEX.tar.gz: UNTRUSTED signature' in abuild index on riscv64 lxc
2021-06-22 08:10:01 <clandmeter> did you add your key?
2021-06-22 08:10:14 <mps> to /etc/apk/keys?
2021-06-22 08:10:21 <clandmeter> yes 
2021-06-22 08:10:30 <mps> heh, I forgot. thanks
2021-06-22 09:14:48 <PureTryOut> clandmeter: oh uh guess not if it's in makedeps already
2021-06-22 09:21:51 <PureTryOut> clandmeter: fixed
2021-06-22 09:29:31 <kasper81> automatic rectification of build pipeline would be nice, especially when the manual solution is always to kill the job.
2021-06-22 09:30:16 <kasper81> e.g. edge-aarch64 is jammed at 3% for 24 hours.. so it's a nobrainer at this point to obviously kill it in order to unblock others
2021-06-22 09:30:44 <kasper81> and not sure if this one-at-a-time build model is scaling at all
2021-06-22 09:31:35 <kasper81> quite frustrating situation from community standpoint tbh, who have no control or say over this too frequent build fiasco
2021-06-22 09:55:42 <clandmeter> Cogitri: im going to push a rebuild of openssl with removal of no-asm (probably does not change anything as its the default) and removal of no-threads which does matter.
2021-06-22 09:55:58 <clandmeter> Cogitri: what is the status of rust? did you get any further?
2021-06-22 10:14:41 <PureTryOut> clandmeter: coud you merge the libcap MR? That'll get the builder building again
2021-06-22 10:24:02 <clandmeter> sure
2021-06-22 10:30:15 <clandmeter> doesnt applying the patch auto close the MR?
2021-06-22 10:31:06 <clandmeter> sorry dont interact with MR's much
2021-06-22 10:52:04 <PureTryOut> If you merge it via the Gitlab UI yes, otherwise idk
2021-06-22 11:10:00 <ikke> ncopa: !22548 fixes an issue introduced with the openssh refactoring you did
2021-06-22 11:28:20 <ncopa> ikke: look good
2021-06-22 11:31:25 <PureTryOut> ikke: uh, I'm having BAD signature again on polkit-elogind, x86_64 dl-cdn mirror
2021-06-22 11:51:59 <Cogitri> clandmeter: Couldn't give it a try yet since I couldn't bootstrap rust
2021-06-22 11:52:15 <Cogitri> s/rust/the sysroot/
2021-06-22 11:52:15 <alpine-meetbot> Cogitri meant to say: clandmeter: Couldn't give it a try yet since I couldn't bootstrap the sysroot
2021-06-22 11:52:44 <Cogitri> And I need the sysroot so I can cross-compile Rust (I think? I haven't really done cross compilation in Alpine yet)
2021-06-22 11:55:04 <kasper81> ikke: java package bloat struck again. edge-ppc64le is stuck on openjdk at 9%, edge-aarch64 is java-lz4 at 3%. kill them? its getting nowhere..
2021-06-22 11:55:38 <kasper81> Cogitri: did this not work: `curl -sSL https://raw.githubusercontent.com/alpinelinux/alpine-chroot-install/master/alpine-chroot-install     | sh -s -- -a riscv64 -b edge`
2021-06-22 12:06:06 <Cogitri> I'm pretty sure I can't do that since I don't want a chroot, I a cross compile environment
2021-06-22 12:09:06 <kasper81> you can install compiler in chroot and set sysroot to /alpine. it works for other architectures to build rust and other stuff. i'm pretty sure it will get you what you want.
2021-06-22 12:32:58 <clandmeter> chanserv died?
2021-06-22 12:43:12 <danieli> there was a netsplit
2021-06-22 14:26:29 <minimal> could someone please consider !22503 for merging
2021-06-22 15:24:17 <dalias> anyone from alpine have input on this? https://github.com/shadow-maint/shadow/pull/360#issuecomment-866059557
2021-06-22 17:52:29 <Cogitri> openssl still fails for me during bootstrap for riscv64: `riscv64-alpine-linux-musl/bin/ld: cannot find -latomic`
2021-06-22 17:55:22 <ikke> gcc should've been patched to fix that
2021-06-22 17:55:46 <ikke> 9a63416183087f223b7c63eb6319e9d3481816c0
2021-06-22 18:44:23 <clandmeter> Bootstrap was also broken for me
2021-06-22 18:44:45 <clandmeter> Sounds like libatomic is not available
2021-06-22 18:45:19 <clandmeter> Maybe it's not build when bootstraping
2021-06-22 18:46:14 <clandmeter> Cogitri: you need to bootstrap Alpine to build rust?
2021-06-22 20:49:04 <Cogitri> I think I need a sysroot to cross compile, dont I?
2021-06-22 20:49:09 <Cogitri> I really don’t know much about cross on Alpine
2021-06-22 20:50:28 <clandmeter> you can generate a sysroot from apk?
2021-06-22 20:51:36 <Cogitri> And that integrates with abuild so it’ll find the riscv64 libs?
2021-06-22 20:52:10 <clandmeter> i have no idea how to boostrap rust, so im unsure what you are doing.
2021-06-22 20:52:57 <Cogitri> I basically just want abuild to do a simple cross compilation
2021-06-22 20:53:12 <Cogitri> Could be any C library for the beginning :)
2021-06-23 05:04:55 <smcavoy> hello, should bootstrap.sh be working on edge and v3.14? On a fresh install of both v3.14 and edge builing for aarch64 on x86_64 it fails on gcc with a error: libgnat.a: error adding symbols: file in wrong format
2021-06-23 05:10:52 <ikke> smcavoy: it should work on edge
2021-06-23 05:11:25 <ikke> it's not maintained on stable branches
2021-06-23 06:51:17 <smcavoy> ikke: so no crosscompiling for stable branches?
2021-06-23 06:53:32 <ikke> We don't provide a generic cross-compiler 
2021-06-23 06:54:18 <ikke> Our goal is just to bootstrap a toolchain, and then switch to native 
2021-06-23 07:01:04 <mps> is it safe to replace '__free_fn_t' with 'void (*)(void *)' in musl?
2021-06-23 07:01:33 <ikke> Maybe ask in #musl? 
2021-06-23 07:02:17 <mps> hah, I intended, but looks like I'm not yet wake up
2021-06-23 07:15:20 <DylanVanAssche> Could somebody consider !22383 for merging? Would help me a lot to get these ODROID devices packaged in postmarketOS.
2021-06-23 07:19:47 <mps> DylanVanAssche: could this wait for next u-boot stable release
2021-06-23 07:20:25 <PureTryOut> Why?
2021-06-23 07:21:02 <PureTryOut> The change is simple enough, I don't see why we would wait?
2021-06-23 07:23:16 <DylanVanAssche> mps: The next U-boot release is soon, but it only adds a new config to build which creates an additional subpackage. Is there a special reason why a new U-boot release is needed for this?
2021-06-23 07:24:24 <smcavoy> ikke: thanks
2021-06-23 07:25:31 <mps> DylanVanAssche: need time to review some changes for u-boot
2021-06-23 07:26:16 <PureTryOut> But it's literally just enabling a single board, why would that need any more reviewing other than checking if the pkgrel is bumped and the right name is used for the board?
2021-06-23 07:28:53 <mps> PureTryOut: I prefer to more carefully look in changes for pkgs in main
2021-06-23 07:29:08 <PureTryOut> Have a look at it then, it's such a small change 😂
2021-06-23 07:29:31 <mps> I will, as soon as I find time
2021-06-23 07:37:14 <markand> I think it's time for a linux-headers update
2021-06-23 07:37:21 <markand> gpio'v2 interface isn't exposed 
2021-06-23 07:38:06 <markand> oh, nvm, our box was still on 3.13 ;p
2021-06-23 07:41:39 <markand> linux devs are able to make simple things so complicated, the GPIO linux API is total nonsense (when compared to OpenBSD) 
2021-06-23 08:14:12 <clandmeter> Cogitri: do you have scripts to boostrap rust? or how does it work?
2021-06-23 08:44:58 <Cogitri> It should be as simple as doing CBUILD=$riscv64Triplet abuild -r in the sports dir of Rust and then fixing all the builder rods
2021-06-23 08:45:15 <Cogitri> And probably the APKBUILD itself so it works with cross compiling
2021-06-23 09:04:28 <clandmeter> Cogitri: Package not available for the target architecture (riscv64). Aborting.
2021-06-23 09:04:39 <clandmeter> have you ever boostrapped for a different arch?
2021-06-23 09:06:55 <PureTryOut> It would probably help removing the `!riscv64` from the Rust package when bootstrapping it 😜
2021-06-23 09:13:53 <clandmeter> oh im stupid, i though it was coming from something else..
2021-06-23 09:28:35 <mps> DylanVanAssche: could be merged right now
2021-06-23 09:29:29 <DylanVanAssche> mps: Awesome! Let's get it merged then 🙂 
2021-06-23 09:29:55 <mps> rebasing it now
2021-06-23 09:30:09 <mps> and merged
2021-06-23 09:31:41 <DylanVanAssche> Thanks!
2021-06-23 09:32:05 <mps> np ;)
2021-06-23 09:32:21 <mps> s/;/:/
2021-06-23 09:32:21 <alpine-meetbot> mps meant to say: np :)
2021-06-23 09:32:53 <PureTryOut> Thanks mps!
2021-06-23 09:33:17 <mps> PureTryOut: you are welcome
2021-06-23 09:34:46 <PureTryOut> mps: u-boot fails to build on riscv64 currently https://build.alpinelinux.org/buildlogs/build-edge-riscv64/main/u-boot/u-boot-2021.04-r1.log
2021-06-23 09:34:57 <PureTryOut> or well, it builds fine but package function goes wrong
2021-06-23 09:35:16 <mps> already disabled it on riscv64
2021-06-23 09:35:18 <PureTryOut> I guess because of no boards?
2021-06-23 09:35:20 <PureTryOut> Ah good
2021-06-23 09:36:07 <mps> I have it ready for riscv64 in my local repo but have to wait till some other things are fixed on riscv64 first
2021-06-23 09:37:50 <PureTryOut> Oh ok
2021-06-23 11:41:48 <PureTryOut> ikke: polkit-elogind has BAD signatures on aarch64 as well
2021-06-23 11:47:38 <PureTryOut> Hmmpf, some package are having undefined references to udev functions. I thought they would just need a rebuild against eudev but that does not seem to help
2021-06-23 11:49:28 <PureTryOut> *some packages.
2021-06-23 11:49:49 <PureTryOut> Atm most notably `community/solid` and `community/libgudev`. I can't figure out how else to fix it
2021-06-23 12:17:19 <Kerum> how could i overwrite a config provided by one APKBUILD from another?
2021-06-23 12:18:44 <ikke> Only one package can own a file at the same time 
2021-06-23 12:40:45 <mep> is there a metapackage for standard build tools?
2021-06-23 12:40:51 <mep> i forgot the name of it if there is
2021-06-23 12:41:57 <ikke> build-base
2021-06-23 12:42:05 <mep> ty
2021-06-23 13:39:59 <PureTryOut> What is this `ModuleNotFoundError: No module named '_ssl'` error about multiple Python packages have on riscv64?
2021-06-23 13:43:05 <danieli> sounds like that version of python was built without SSL support, _ssl is built when python itself is compiled
2021-06-23 13:47:06 <bratkartoffel> ikke: yeah, i already thought that merging moost of my java related MRs at once will be a problem. Do you have a list of whats currently hanging / failing? Which arches?
2021-06-23 13:47:29 <PureTryOut> sounds right, but the Python 3 of riscv64 isn't build any differently than others afaik
2021-06-23 13:47:46 <ikke> bratkartoffel: check #alpine
2021-06-23 13:48:10 <ikke> #alpine-commits
2021-06-23 13:51:18 <ikke> https://irclogs.alpinelinux.org/%23alpine-commits-2015-06.log
2021-06-23 13:54:57 <danieli> I don't see any build logs for python3 in build-edge-risc64 at all
2021-06-23 14:00:49 <PureTryOut> Well the failure doesn't come from python3 itself, that built fine, but from one of it's reverse deps
2021-06-23 14:53:20 <clandmeter> Cogitri: seen this error before? https://tpaste.us/jnEl
2021-06-23 15:04:04 <mep> certbot is broken on edge :(
2021-06-23 15:15:27 <Cogitri> clandmeter: Hm, that looks weird. But I suppose it's our APKBUILD for Rust being broken for cross builds
2021-06-23 15:15:44 <Cogitri> Maybe we only set musl-libdir for the target and not the host
2021-06-23 15:37:06 <Cogitri> How did you get your cross environment for Rust? Then I can give that a go
2021-06-23 15:43:47 <Newbyte[m]> Do you understand what's with the CI on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22412
2021-06-23 15:45:40 <ikke> Newbyte[m]: "528 commits behind"
2021-06-23 15:51:22 <Newbyte[m]> ikke: it was doing the same thing when it wasn't that far behind. either way, I rebased and it's still doing the same thing. also, do you understand why the lint fails? it says builddir is redundant in the APKBUILD for py3-redbaron, but py3-redbaron doesn't set builddir from what I can tell
2021-06-23 15:55:13 <ikke> let me check
2021-06-23 16:00:09 <Newbyte[m]> 👍️
2021-06-23 17:12:45 <ikke> Newbyte[m]: one of the files has a conflict
2021-06-23 17:13:10 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22412/diffs#37cbab85127e1382f88c471701e2b8157959763a_61_63
2021-06-23 17:21:19 <Newbyte[m]> ikke: thanks! I'll fix that
2021-06-23 17:23:41 <ikke> https://gitlab.alpinelinux.org/Newbyte/aports/-/jobs/422318#L81
2021-06-23 17:24:00 <omni> !22408 !22410
2021-06-23 17:24:25 <omni> merged for 3.11 but not 3.12
2021-06-23 17:26:06 <Newbyte[m]> another weird thing is that it says I can remove builddir for py3-pytest-toolbox, but when I do the build fails
2021-06-23 17:30:28 <Ariadne> omni: please feel free to ping me on security upgrades
2021-06-23 17:30:56 <ikke> or @team/security :)
2021-06-23 17:36:23 <omni> ty
2021-06-23 17:57:52 <ddevault> is there anyone here who would be interested in picking up maintainership of the wlroots and sway packages? (and related ones like swaybg)
2021-06-23 18:05:33 <ngortheone> ddevault: maybe, but I've never been a maintainer before. What's the job description?
2021-06-23 18:06:03 <ddevault> updating the package when new upstream releases come up
2021-06-23 18:06:14 <ddevault> but I'd prefer to work with someone who has some experience with package maintenance already
2021-06-23 18:06:37 <ngortheone> :(
2021-06-23 18:07:45 <ddevault> not saying that you shouldn't learn package maintenance, it's just that sway/wlroots is a pretty complex and important package to choose as your first
2021-06-23 18:09:56 <ngortheone> these are the packages I do care about as I use sway daily. But you are right, if someone more experinced steps forward - I wouldn't object
2021-06-23 18:12:34 <ngortheone> ddvault: why are you giving up the role if you dont mind me asking?
2021-06-23 18:12:45 <ngortheone> ddevault*
2021-06-23 18:13:08 <ddevault> I'm no longer the upstream maintainer and I would prefer to spend less time working with it so I can focus on other things
2021-06-23 18:32:29 <PureTryOut> danieli: example of a failing Python package with ssl https://build.alpinelinux.org/buildlogs/build-edge-riscv64/community/mercurial/mercurial-5.7-r0.log
2021-06-23 18:33:15 <danieli> PureTryOut: yeah, the 'ssl' module is a wrapper around the native module _ssl which is conditionally built when python itself is built
2021-06-23 18:33:24 <danieli> same with 're' and '_re'
2021-06-23 18:46:30 <PureTryOut> I get that, but the Python on riscv64 isn't anything different than other arches so it should've been built just fine afaik
2021-06-23 18:53:11 <ikke> PureTryOut: were you looking for this? https://upaste.de/raw/mfj
2021-06-23 18:53:57 <PureTryOut> Not me, danieli 
2021-06-23 18:54:00 <ikke> oh
2021-06-23 18:54:03 <ikke> danieli: ^
2021-06-23 18:54:40 <danieli> Failed to build these modules:
2021-06-23 18:54:40 <danieli> _hashlib              _ssl     
2021-06-23 18:54:45 <ikke> Failed to build these modules:
2021-06-23 18:54:46 <ikke> _hashlib              _ssl                                     
2021-06-23 18:54:48 <danieli> hahaha yes
2021-06-23 18:54:48 <ikke> heh
2021-06-23 18:55:02 <danieli> was it built against libressl or something?
2021-06-23 18:55:06 <danieli> it says the reason just below the error
2021-06-23 18:55:06 <ikke> Python requires an OpenSSL 1.0.2 or 1.1 compatible libssl with X509_VERIFY_PARAM_set1_host().
2021-06-23 19:45:51 <PureTryOut> Maybe Python just needs a rebuild then, OpenSSL only got proper riscv64 support yesterday
2021-06-23 19:46:37 <ikke> possibly, yes
2021-06-23 19:47:15 <PureTryOut> Should I push a pkgrel bump?
2021-06-23 19:58:34 <PureTryOut> There is also something wrong with ffmpeg, somehow no package depending on it can find the development headers
2021-06-23 20:00:32 <omni> !22394 could be closed since !22403
2021-06-23 20:06:41 <omni> Ariadne: !22256 is (also) a secfix
2021-06-23 20:32:43 <PureTryOut> Ah... `>>> ERROR: ffmpeg*: libavcodec.so.: path not found`
2021-06-24 01:01:42 <craftyguy> the aarch64 edge builder seems to be stuck on community/java-jna 5.6.0-r1
2021-06-24 04:36:26 <ikke> :/
2021-06-24 04:36:45 <ikke> bratkartoffel: ^
2021-06-24 07:07:25 <Ariadne> :(
2021-06-24 07:23:57 <mps> I think clamav should be backported because of this (but not only this) https://github.com/Cisco-Talos/clamav/commit/8dd90c16b4a7284db0c727afbc931afcf9005a85
2021-06-24 07:29:34 <fcolista> ikke there's an issue with zabbix-agent for x86
2021-06-24 07:29:35 <fcolista> ERROR: zabbix-agent-5.4.0-r1: package mentioned in index not found (try 'apk update')
2021-06-24 07:29:35 <fcolista> (6/7) Installing zabbix-agent (5.4.0-r1)
2021-06-24 07:29:35 <fcolista> (7/7) Installing zabbix-agent-openrc (5.4.0-r1)
2021-06-24 07:29:35 <fcolista> ERROR: zabbix-agent-openrc-5.4.0-r1: package mentioned in index not found (try 'apk update')
2021-06-24 07:29:36 <fcolista> 2 errors; 212 MiB in 97 packages
2021-06-24 07:29:48 <fcolista> I tried several mirrors
2021-06-24 07:30:17 <ikke> That's an rsync issue we're debugging
2021-06-24 07:30:53 <fcolista> ah ok
2021-06-24 08:10:35 <PureTryOut> clandmeter: just build php7 locally for riscv64, your patch to disable lightspeed works indeed. Shall we push it?
2021-06-24 08:10:49 <PureTryOut> *litespeed
2021-06-24 08:10:52 <clandmeter> my patch?
2021-06-24 08:11:29 <PureTryOut> Oh sorry, andypost's patch
2021-06-24 08:12:06 <clandmeter> disable is an option yes
2021-06-24 08:12:12 <PureTryOut> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22478
2021-06-24 08:12:14 <clandmeter> would be nice to have a fix
2021-06-24 08:12:21 <PureTryOut> the litespeed package itself is already disabled
2021-06-24 08:13:19 <clandmeter> its not arch based disable?
2021-06-24 08:15:22 <PureTryOut> the litespeed package not no, it's disabled for all arches
2021-06-24 08:16:01 <PureTryOut> https://gitlab.alpinelinux.org/alpine/aports/-/commit/6a46d5bca260c2b57a060bcdebd48573b8fb5461
2021-06-24 08:16:39 <PureTryOut> e8 disabled that already 10 months ago. And for this PHP patch it's disabled for all arches as well
2021-06-24 08:30:28 <PureTryOut> riscv64 seems to be stuck on py3-numpy currently
2021-06-24 08:31:02 <clandmeter> ok, still think we should not just disable things because of other arches.
2021-06-24 08:31:11 <clandmeter> it will impact users
2021-06-24 08:31:18 <clandmeter> but im not the maintainer 
2021-06-24 08:31:48 <clandmeter> does litespeed php depend on regular litespeed pkg?
2021-06-24 08:32:08 <PureTryOut> I don't know, you'd have to ask andypost 
2021-06-24 08:32:48 <PureTryOut> Doesn't seem like it to me if I check the APKBUILD
2021-06-24 08:33:17 <clandmeter> i guess php bundles it
2021-06-24 08:33:25 <clandmeter> not even sure what it is
2021-06-24 08:33:47 <PureTryOut> ikke: I issued a pkgrel bump of `community/solid`, but it never appeared in the repositories. This is blocking several packages from building correctly atm, most notably `community/discover` which is blocking the builder atm
2021-06-24 08:33:52 <PureTryOut> clandmeter: me neither
2021-06-24 08:34:04 <clandmeter> ah its a http server
2021-06-24 08:34:16 <clandmeter> and its disabled on alpine
2021-06-24 08:34:28 <clandmeter> i guess it does not matter that much
2021-06-24 08:34:41 <clandmeter> we can probably keep it disabled and spend time wisely 
2021-06-24 08:34:42 <PureTryOut> 🤷‍♂️
2021-06-24 08:34:48 <PureTryOut> It should help PHP8 as well
2021-06-24 08:34:50 <PureTryOut> Yeah
2021-06-24 08:35:01 <clandmeter> lgtm
2021-06-24 08:35:09 <clandmeter> ill check the builder
2021-06-24 08:35:53 <clandmeter> should i sync pkgs to dev.a.o again?
2021-06-24 08:37:54 <clandmeter> looks like gcc is hanging
2021-06-24 08:38:09 <clandmeter> no its python
2021-06-24 08:38:30 <clandmeter> it called gcc and now it sits and waits
2021-06-24 08:39:16 <clandmeter> another qemu anomaly 
2021-06-24 08:39:54 <clandmeter> killed it
2021-06-24 08:42:43 <PureTryOut> Sorry, sync pkgs to dev.a.o? I thought it uploaded them there in the first place?
2021-06-24 08:44:28 <PureTryOut> Ok I'll merge the PHP7 MR then and apply the same to PHP8
2021-06-24 08:49:13 <clandmeter> no it will not auto sync
2021-06-24 08:49:37 <clandmeter> syncing now
2021-06-24 08:49:46 <clandmeter> wow
2021-06-24 08:49:50 <clandmeter> thats a lot of pkgs
2021-06-24 08:50:09 <clandmeter> PureTryOut: good work :)
2021-06-24 08:50:20 <clandmeter> i guess some are aslso updates
2021-06-24 08:52:41 <PureTryOut> Yeah some are
2021-06-24 08:52:47 <PureTryOut> In that case yeah please sync 😃
2021-06-24 08:57:27 <clandmeter> PureTryOut: https://tpaste.us/yNVx
2021-06-24 08:57:54 <insep> omni: new ocaml-gen, which i'm trying to package because other things require it, needs dune-configurator and it's located inside dune source tree, should i create new apkbuild for it or make it a subpackage of dune?
2021-06-24 08:59:15 <PureTryOut> Fancy 😃
2021-06-24 08:59:33 <PureTryOut> Lots of stuff gets disabled because of Rust dependencies somewhere in their stack, so once that is bootstrapped most stuff should compile just fine
2021-06-24 09:08:38 <andypost[m]> clandmeter: I got successful build of php7 without litespeed but did not run tests yet, gonna run'em today but afk still
2021-06-24 09:10:02 <andypost[m]> PureTryOut (matrix.org): did you run tests on riscv for php?
2021-06-24 09:10:33 <andypost[m]> I used clandmeter's repo for build
2021-06-24 09:11:06 <PureTryOut> For a while, they took way too long for my taste so I quit them at some point
2021-06-24 09:11:49 <mps> PureTryOut: pinbook SOC is sunxi familly?
2021-06-24 09:11:57 <andypost[m]> I can start in 3-4 hours, build itself took 1.5 hour
2021-06-24 09:13:38 <PureTryOut> mps: idk, I don't have a Pinebook. MartijnBraam will know
2021-06-24 09:14:44 <insep> pinebook is sunxi, pinebook pro is rockchip
2021-06-24 09:15:16 <mps> insep: thanks
2021-06-24 09:15:20 <andypost[m]> Sadly I fail to build fresher litespeed !2580 but as I know it's one of fastest ways to run php
2021-06-24 09:15:31 <mps> I thought so, just asked confirmation
2021-06-24 09:15:53 <mps> have to reorganize board for u-boot
2021-06-24 09:23:07 <mps> oh, and pine64-lts is also sunxi
2021-06-24 09:48:45 <mps> any objections to this idea !22592
2021-06-24 10:39:17 <DylanVanAssche> mps: I think it makes sense, when the PinePhone and PineTab use upstream u-boot, they will be there as well 🙂 all sunxi
2021-06-24 10:39:24 <PureTryOut> PHP7 just finished building on riscv64, tests seems to have passed
2021-06-24 10:43:08 <martijnbraam> mps: that change looks fine, we just need to rename some dependencies in pmos :)
2021-06-24 10:54:37 <PureTryOut> clandmeter: got another Go package failure, different error to last time though https://build.alpinelinux.org/buildlogs/build-edge-riscv64/community/gocryptfs/gocryptfs-2.0.1-r0.log
2021-06-24 10:57:27 <ikke> hash.go:97:3: undefined: xorBlock
2021-06-24 10:57:52 <ikke> Probably has files with arch specific buildtags that implement this
2021-06-24 10:58:35 <mps> DylanVanAssche: martijnbraam: thanks for look at
2021-06-24 10:58:46 <ikke> PureTryOut: https://github.com/jacobsa/crypto/blob/master/cmac/hash_64bit.go#L16 riscv64 is missing there
2021-06-24 10:59:14 <PureTryOut> Ah, so should be easy fix then. I'll try it out
2021-06-24 10:59:52 <ikke> The comments do mention some caveat
2021-06-24 10:59:57 <ikke> about unaligned access
2021-06-24 11:02:06 <PureTryOut> Those comments have arguments for every arch why it's safe to use as is
2021-06-24 11:03:01 <ikke> nod
2021-06-24 11:03:09 <ikke> So you need to figure out if that's the case for riscv64
2021-06-24 11:03:36 <PureTryOut> Uhm... Can't the maintainer of that package do that? I have no clue about these things lol
2021-06-24 11:03:46 <ikke> Sure
2021-06-24 11:03:50 <ikke> You could open an issue :)
2021-06-24 11:04:17 <ikke> https://stackoverflow.com/questions/64748879/risc-v-load-address-not-aligned-to-word-boundary
2021-06-24 11:04:30 <ikke> "The base ISA supports misaligned accesses, but these might run extremely slowly depending on the implementation. Furthermore, naturally aligned loads and stores are guaranteed to execute atomically, whereas misaligned loads and stores might not, and hence require additional synchronization to ensure atomicity."The base ISA supports misaligned accesses, but these might run
2021-06-24 11:04:31 <ikke> extremely slowly depending on the implementation. Furthermore, naturally aligned loads and stores are guaranteed to execute atomically, whereas misaligned loads and stores might not, and hence require additional synchronization to ensure atomicity.
2021-06-24 11:08:39 <PureTryOut> Ok made an issue https://gitlab.alpinelinux.org/alpine/aports/-/issues/12793
2021-06-24 11:08:42 <PureTryOut> And disabled the package for now
2021-06-24 11:11:38 <ikke> PureTryOut: did you also open an upstream issue?
2021-06-24 11:11:55 <PureTryOut> No, I feel that someone with more knowledge about the problem should do it
2021-06-24 11:12:39 <martijnbraam> I feel like that all the time :P
2021-06-24 11:13:11 <ikke> PureTryOut: why?
2021-06-24 11:14:39 <PureTryOut> Upstream will expect me to provide info about the problem and test things and what not. Seems more like something e.g. the maintainer of the package should do, I have enough to do and maintain already 😅 
2021-06-24 11:17:28 <ikke> fair enough
2021-06-24 11:26:33 <insep> ikke: it looks to me like that new sunxi subpackage should have old subpackages in provides and replaces
2021-06-24 11:27:04 <insep> oh wait
2021-06-24 11:27:28 <insep> ah yes
2021-06-24 11:53:15 <PureTryOut> PHP8 built successfully as well now
2021-06-24 12:20:20 <mps> insep: you mean mps and not ikke, I think
2021-06-24 12:21:33 <insep> mps: yes
2021-06-24 12:22:14 <mps> and not sure we need to complicate this with replaces and provides, u-boot is not package which is upgraded blindly anyway
2021-06-24 12:41:23 <PureTryOut> another Go package failing on riscv64, apk-file this time https://build.alpinelinux.org/buildlogs/build-edge-riscv64/community/apk-file/apk-file-0.3.6-r2.log
2021-06-24 12:45:22 <PureTryOut> ikke: could you look into why solid 5.83.0-r1 hasn't been uploaded/built? I issued a rebuild against latest eudev but it never uploaded to the repository so some packages like `community/discover` keep failing to build
2021-06-24 12:47:06 <ikke> I can check later today 
2021-06-24 12:47:37 <PureTryOut> Thanks!
2021-06-24 13:57:56 <insep> wq
2021-06-24 13:58:14 <insep> oops
2021-06-24 13:58:39 <bratkartoffel> can someone please do a "kill -3" on running java process on the stuck aarch64 builder?
2021-06-24 14:21:18 <ikke> bratkartoffel: I have done that more than once 
2021-06-24 14:21:46 <ikke> I can do that later today 
2021-06-24 14:27:48 <yyp> Did LLVM 12 WIP aport just go nowhere?
2021-06-24 14:36:15 <PureTryOut> Hmm... https://build.alpinelinux.org/buildlogs/build-edge-riscv64/community/py3-nodeenv/py3-nodeenv-1.6.0-r1.log
2021-06-24 14:37:09 <ikke> Does anyone recall a simple make like tool wheren
2021-06-24 14:37:41 <ikke> Where you just specify some tasks you regularly execute? 
2021-06-24 14:38:49 <ikke> Ah, go-task
2021-06-24 15:17:10 <ikke> bratkartoffel: done
2021-06-24 15:50:25 <bratkartoffel> meh, the stacktrace didn't come out in the logs
2021-06-24 15:51:08 <bratkartoffel> ikke: you did a kill -3, did you? this should normally not terminate the program but print stracktrace for each thread in the jvm
2021-06-24 15:51:50 <ikke> oooh, sorry :(
2021-06-24 15:51:58 <ikke> I should've read better
2021-06-24 15:52:27 <ikke> I'll do that the next time it hangs
2021-06-24 15:52:33 <bratkartoffel> no problem :) i have to think about the whole situation again. it can't be that these builds are so incredible unstable
2021-06-24 15:52:41 <ikke> bratkartoffel: fyi, there is one process I need to kill -9
2021-06-24 15:52:47 <ikke> just regular -15 does not work
2021-06-24 15:53:11 <ikke> bratkartoffel: So far it has been increadible stable at hanging :D
2021-06-24 15:53:58 <bratkartoffel> it annoys me that i cannot reproduce it locally
2021-06-24 15:54:55 <ikke> yeah, can be anoying
2021-06-24 15:55:01 <ikke> and so far, it only happens on aarch64
2021-06-24 15:55:15 <bratkartoffel> the hangs yes, but there is also the SIGFPE on s390x
2021-06-24 15:55:21 <ikke> ah, ok
2021-06-24 15:55:46 <bratkartoffel> #12275
2021-06-24 16:09:00 <omni> insep: if it is or could be built as part of the dune aport build it sounds like it should and be a subpackage
2021-06-24 16:10:02 <insep> it's built with dune (https://github.com/ocaml/dune/blob/main/dune-configurator.opam#L33), would that be a problem?
2021-06-24 16:19:04 <omni> insep: I'm sorry, I don't have much time right now, but I could look at an MR or two over the weekend (or possibly later today)
2021-06-24 16:20:16 <insep> definitely not today, haxe needs luv and that needs quite a lot of packaging
2021-06-24 16:20:52 <omni> I'd be very happy to have someone to collaborate with on ocaml aports
2021-06-24 16:21:51 <omni> I had a lot of time earlier this year and spent some of it improving the state of some of the ocaml related aports
2021-06-24 16:22:32 <insep> i can send some aports that i've touched already
2021-06-24 16:23:58 <omni> do you work locally? I've  mostly been using gitlab
2021-06-24 16:25:15 <insep> yup, i didn't push my work anywhere nor i've configured ssh to alpine gitlab on this machine
2021-06-24 16:32:44 <omni> do you then mostly test on your local arch?
2021-06-24 16:33:15 <omni> the gitlab.a.o ci is pretty sweet in that regard, that it builds for most of the targets
2021-06-24 16:34:20 <insep> on x86_64, not that there's that much testing involved, i just make sure that stuff builds and passes tests when available/doesn't require me to build even more stuff
2021-06-24 16:55:03 <insep> omni: i've pushed some of my stuff to https://gitlab.alpinelinux.org/DolphinChips/aports/-/commits/haxe-422, feel free to take a look at them and ignore empty "Maintainer: " fields
2021-06-24 17:05:00 <ikke> I think the udev issues are due to udev-zero
2021-06-24 17:05:05 <ikke> (90/508) Installing libudev-zero (0.5.1-r0)
2021-06-24 17:05:23 <ikke> mps: ^
2021-06-24 17:07:20 <ikke> bratkartoffel: https://tpaste.us/QWXl 
2021-06-24 17:10:58 <mps> uh, why that happens
2021-06-24 17:11:37 <mps> something expects udev to be built?
2021-06-24 17:12:19 <ikke> udev-dev I guess
2021-06-24 17:13:25 <mps> libudev-zero-dev can be used as replacement for udev-dev
2021-06-24 17:14:13 <mps> but anyway, why it pulls libudev-zero instead of udev by default
2021-06-24 17:16:38 <ikke> euhm
2021-06-24 17:17:37 <mps> which pkg?
2021-06-24 17:17:43 <ikke> gnome-shell for example
2021-06-24 17:17:46 <ikke> but
2021-06-24 17:17:50 <ikke> where is (lib)udev?
2021-06-24 17:18:13 <ikke> ah, eudev?
2021-06-24 17:18:18 <mps> yes
2021-06-24 17:19:07 <ikke> eudev has 'provides=udev=176'
2021-06-24 17:19:25 <ikke> (just noting)
2021-06-24 17:19:59 <mps> holly umh whatever, it pulls 481 pkgs with abuild deps
2021-06-24 17:22:24 <mps> I see where problem is
2021-06-24 17:22:34 <mps> but don't see solution
2021-06-24 17:22:38 <ikke> do tell
2021-06-24 17:23:06 <mps> gnome-shell expects particular udev-lib version
2021-06-24 17:23:15 <ikke> where?
2021-06-24 17:23:35 <ikke> I don't see a direct dependency in the APKBUILD
2021-06-24 17:23:43 <mps>  undefined reference to `udev_device_get_devlinks_list_entry@LIBUDEV_183'
2021-06-24 17:24:13 <ikke> This is not the only package
2021-06-24 17:24:13 <mps> actually looks like problem is with libgudev
2021-06-24 17:24:13 <Hello71> musl doesn't support symbol versioning anyways
2021-06-24 17:24:19 <Hello71> but udev doesn't use it
2021-06-24 17:24:38 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-x86/community/discover/discover-5.22.2.1-r0.log
2021-06-24 17:24:41 <ikke> another one
2021-06-24 17:26:10 <mps> so, I should revert you proposed changes to libudev?
2021-06-24 17:26:12 <ikke> ad2e13dad1cc25039e2b5ff20e1ea87604cccf1c
2021-06-24 17:26:38 <mps> libudev-zero*
2021-06-24 17:28:55 <Hello71> here is same problem, solid used eudev-dev but discover using libudev-zero-dev
2021-06-24 17:29:18 <Hello71> we should rm libudev.a from libudev-zero-dev
2021-06-24 17:29:30 <Hello71> probably also ask upstream to stop building that too
2021-06-24 17:30:24 <mps> Hello71: why?
2021-06-24 17:31:56 <Hello71> dalias explained already in #musl last time, it is a huge footgun
2021-06-24 17:32:57 <Hello71> and udev static linking cannot possibly improve performance that much
2021-06-24 17:35:27 <mps> hmm, then I missed that part
2021-06-24 17:35:43 <mps> ok, we can do this
2021-06-24 17:37:25 <Hello71> at most it could save some space, but libudev-zero is only 48 kB anyways. if 48k is a problem for you then you need to use buildroot or something
2021-06-24 17:37:51 <Hello71> i meant to report upstream but forgot for some reason
2021-06-24 17:39:41 <mps> done
2021-06-24 17:40:12 <Hello71> hm, imo would be better to patch to disable building it, but should be ok this way too
2021-06-24 17:42:34 <mps> Hello71: I agree, but this was simple and fast, ofc I'm not against to report upstream
2021-06-24 17:42:41 <Hello71> mmhmm
2021-06-24 17:45:32 <PureTryOut> Didn't fix Discover at least. Solid still reporting the same failures
2021-06-24 17:46:16 <Hello71> where?
2021-06-24 17:46:57 <mps> looks like libudev-zero is not yet rebuilt
2021-06-24 17:49:33 <PureTryOut> At least on x86_64 it was
2021-06-24 17:49:41 <PureTryOut> I saw it happening before it retried Discover
2021-06-24 17:50:10 <Hello71> wondering if we should also increase eudev provider_priority (reduce libudev-zero)
2021-06-24 17:50:41 <Hello71> theoretically i think it should work to build against libudev-zero-dev (once libudev.a is deleted) but i suspect it will lead to more bugs later
2021-06-24 17:50:51 <Hello71> er, build against libudev-zero-dev and then run against eudev
2021-06-24 17:52:15 <mps> I don't see any issues using programs built with udev on systems where libudev-zero installed
2021-06-24 17:52:44 <mps> opposite could be problem but I don't have any info
2021-06-24 17:58:41 <mps> should the revert of 'provides="udev=$pkgver-r$pkgrel"' to 'provides="udev"' fix problem?
2021-06-24 17:58:50 <mps> ikke: ^
2021-06-24 18:22:08 <ikke> Perhaps, I assumed udev was an existing package, but apparently it's not (it's a virtual package, normally provided by eudev)
2021-06-24 18:23:07 <PureTryOut> Ah for virtual packages it should just be `provides="udev"` then yes
2021-06-24 18:25:29 <ikke> eudev has: `provides="udev=176"`
2021-06-24 18:25:48 <ikke> And there is also provider_priority
2021-06-24 18:31:29 <mps> lets hope now
2021-06-24 18:32:03 <mps> iiuc provider_priority is for virtual pkgs
2021-06-24 18:32:25 <PureTryOut> Can we try to be a bit more detailed in our commit messages? There is a lot of room for descriptions in commit messages and it would help looking back later why decisions were made
2021-06-24 18:33:20 <ikke> word
2021-06-24 18:33:47 <PureTryOut> word?
2021-06-24 18:35:06 <mercenary> more words
2021-06-24 18:35:32 <ikke> https://www.merriam-webster.com/dictionary/word definition 12
2021-06-24 18:36:02 <PureTryOut> Ah ok, cool
2021-06-24 18:36:24 <mps> as usual, it depends. sometimes yes and sometimes no
2021-06-24 18:37:55 <ikke> In most cases, when a change is non-trivial, at least some explenation is waranted
2021-06-24 18:38:43 <mps> agree, depends on changes
2021-06-24 18:39:34 <ikke> The commit message is also an oportunity to communicate things to others, and to remind yourself in the future
2021-06-24 18:41:26 <PureTryOut> Yup
2021-06-24 18:54:27 <mps> nothing helps, gnome-shell still use libudev-zero
2021-06-24 19:01:51 <ikke> Are you trying locally?
2021-06-24 19:05:52 <mps> no, looked at build log
2021-06-24 19:06:24 <ikke> ok
2021-06-24 19:08:20 <mps> ah, just started in dev lxc and now it didn't pulled libudev-zero
2021-06-24 19:08:43 <ikke> mps: I guess we should add provider priorities?
2021-06-24 19:09:30 <mps> ohm, to early
2021-06-24 19:09:42 <mps> it pulls it
2021-06-24 19:10:07 <ikke> I'm looking at the apk-tools solver code
2021-06-24 19:10:33 <mps> will it work for normal pkgs?
2021-06-24 19:10:50 <ikke> will what work?
2021-06-24 19:11:11 <mps> provider_priority
2021-06-24 19:13:18 <ikke> Do you know what is actually pulling in udev for gnome-shell?
2021-06-24 19:14:34 <mps> libgudev, I think
2021-06-24 19:15:33 <ikke> I built a local version of apk-tools with PRINT_DBG
2021-06-24 19:16:16 <ikke> gives a lot of output :P
2021-06-24 19:16:29 <mps> ibudev-zero-dev-0.5.1-r1 is required by libgudev-dev-236-r1
2021-06-24 19:16:52 <mps> l*
2021-06-24 19:17:05 <ikke> right
2021-06-24 19:22:38 <ikke> if I install libgudev-dev locally, I just ged eudev-dev
2021-06-24 19:23:05 <ikke> (22/25) Installing eudev (3.2.10-r0)
2021-06-24 19:23:13 <ikke> (24/25) Installing eudev-dev (3.2.10-r0)
2021-06-24 19:24:23 <ikke> disqualify_package: libudev-zero-0.5.1-r0 (conflicting provides)
2021-06-24 19:28:30 <mps> in my case it is opposite
2021-06-24 19:30:41 <ikke> did you also build apk-tools with debug output/
2021-06-24 19:30:43 <ikke> ?
2021-06-24 19:33:33 <mps> no
2021-06-24 19:34:03 <mps> sorry, battery empty, have to find power
2021-06-24 19:34:59 <mps> looks like provider_priority could be solution
2021-06-25 03:32:12 <craftyguy> the aarch64 builder is still stuck on some java thing :(
2021-06-25 03:40:41 <dalias> :/
2021-06-25 03:56:22 <craftyguy> there's a single line in the log: "Killed", so it must have timed out/hung?
2021-06-25 03:56:44 <craftyguy> but the build system seems to be stuck on that and not building anything else for aarch64 on edge
2021-06-25 04:32:12 <ikke> craftyguy: that's when I killed it
2021-06-25 04:32:56 <ikke> bratkartoffel is looking at it
2021-06-25 04:32:59 <ikke> add17bdb3ef03ac44c05b51fa0ed0b99b4c336a7
2021-06-25 04:33:14 <ikke> sorry, this one: https://tpaste.us/QWXl
2021-06-25 05:36:51 <craftyguy> ah ok
2021-06-25 05:51:30 <mps> only ikke have 'license to kill' around :)
2021-06-25 05:52:08 <ikke> :D
2021-06-25 06:06:40 <mps> anyone knows how to solve 'conflict' with eudev-dev and libudev-zero-dev? with provider_priority?
2021-06-25 06:19:45 <clandmeter> mps: what is the "conflict"
2021-06-25 06:20:06 <clandmeter> and good morning CET ppl  (and similar) :)
2021-06-25 06:20:24 <mps> clandmeter: goede morgen
2021-06-25 06:20:36 <mps> good morning for the rest :)
2021-06-25 06:21:27 <mps> libgudev-dev pulls libudev-zero-dev instead of e/udev-dev during abuild deps
2021-06-25 06:22:12 <mps> libudev-zero 'provides="udev"'
2021-06-25 06:22:53 <mps> and 'replaces="udev"'
2021-06-25 06:24:40 <clandmeter> why does libudev-zero provide udev?
2021-06-25 06:25:41 <mps> it is replacement for udev
2021-06-25 06:26:05 <clandmeter> but you dont want to use it by default?
2021-06-25 06:26:26 <mps> I want, not sure for rest of people
2021-06-25 06:27:09 <clandmeter> you provide udev in community, that kind of says you want it :)
2021-06-25 06:27:25 <mps> and not only I
2021-06-25 06:27:42 <clandmeter> provider_priority is probably what you want to use
2021-06-25 06:27:56 <clandmeter> so apk will pull the higher priority
2021-06-25 06:28:03 <clandmeter> but you can still manually overule it
2021-06-25 06:28:10 <mps> yes, ikke and I come to this conclusion last night
2021-06-25 06:28:30 <clandmeter> good, case closed, happy weekend ;-)
2021-06-25 06:28:58 <mps> I never used provider_priority so not sure what and where to add it
2021-06-25 06:29:20 <mps> what to change*
2021-06-25 06:30:04 <ikke> eudev should have a higher priority than libudev-zero
2021-06-25 06:30:22 <ikke> afaik, you need to add it to both 
2021-06-25 06:30:34 <mps> i think so
2021-06-25 06:30:39 <clandmeter> yes
2021-06-25 06:30:46 <clandmeter> add it to both and make one higher
2021-06-25 06:31:07 <mps> but what is 'higher' in it? 10 is higher than 20?
2021-06-25 06:31:34 <mps> or opposite
2021-06-25 06:31:47 <clandmeter> 20 for eudev
2021-06-25 06:31:52 <clandmeter> 10 for the other
2021-06-25 06:32:01 <mps> aha, understand
2021-06-25 06:32:13 <clandmeter> its more like a weight
2021-06-25 06:32:20 <clandmeter> highest weight wins
2021-06-25 06:32:27 <mps> :D
2021-06-25 06:32:27 <clandmeter> probably me
2021-06-25 06:32:35 <ikke> Higher is higher ;-)
2021-06-25 06:32:42 <mps> clandmeter: so you always win
2021-06-25 06:33:01 <clandmeter> yes, this kind of game i unfortunately do 
2021-06-25 06:33:32 <clandmeter> need to do some more construction work instead of sitting behind this pc all day long
2021-06-25 06:35:17 <clandmeter> ps, you need to be careful with provides, it could break ppl's system, i guess you noticed :)
2021-06-25 06:36:54 <mps> long time ago I learned that any change can break systems
2021-06-25 06:39:28 <mps> I didn't cared about this if I break my systems, I could fix them fast, but now when I'm distro dev/packager I care and what is worse I have fear to introduce changes, especially big ones
2021-06-25 06:41:32 <clandmeter> fear is not a good mentor
2021-06-25 06:42:50 <mps> it is not 'fear' as in real world, but I can't find correct english word
2021-06-25 06:44:42 <clandmeter> naming things is the hardest part, for sure when its not your native language. but i get your point dont worry :)
2021-06-25 06:51:59 <mps> yes, it's a pity Wittgenstein is 'not in schools' and/or media
2021-06-25 06:55:31 <mps> just finished with linux-edge, linux-elm and linux-gru upgrades
2021-06-25 06:56:09 <mps> now will look at lib/udev libudev-zero
2021-06-25 07:08:29 <mps> I pushed changes, lets see will it solve problem
2021-06-25 07:10:58 <PureTryOut> Could someone with merge rights to main merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22603?
2021-06-25 07:11:29 <mps> !22603
2021-06-25 07:13:22 <mps> PureTryOut: could you rebase it, just pushed directly to aports changes
2021-06-25 07:14:37 <PureTryOut> Done
2021-06-25 07:15:59 <mps> you forgot pkgrel
2021-06-25 07:25:12 <clandmeter> should not be needed
2021-06-25 07:26:39 <mps> are you sure?
2021-06-25 07:27:45 <mps> eudev-3.2.10-r1 is already built
2021-06-25 07:32:34 <clandmeter> abuild does not allow textrels
2021-06-25 07:32:40 <clandmeter> so if that happens its not build
2021-06-25 07:32:47 <clandmeter> but only for riscv64
2021-06-25 07:43:33 <PureTryOut> Exactly. Only riscv64 package is changing but it has not been built yet anyway
2021-06-25 07:44:00 <mps> ok, lets merge
2021-06-25 07:44:22 <mps> it passed in my rv64 lxc
2021-06-25 07:44:52 <PureTryOut> 👍️
2021-06-25 07:45:11 <mps> done
2021-06-25 07:47:05 <mps> I read somewhere that in some cultures 'thumb up' is not nice to use or even offensive
2021-06-25 07:48:47 <mps> https://lwn.net/Articles/859307/
2021-06-25 07:59:24 <smcavoy> hello I found the testing/borgmatic package has not been updated for aarch64. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22457 it looks like the aarch64 build was canceled but the pull request was still merged. Would this explain the lack of aarch64 package?
2021-06-25 08:00:09 <smcavoy> I have attempted to build the package on aarch64 myself and found it hangs during the checks. This does not happen on x86_64
2021-06-25 08:00:52 <ikke> "The miscommunications will happen anyway in a diverse environment. It’s much better if we can learn to laugh at them instead of automatically taking offense. " 
2021-06-25 08:16:24 <mps> ikke: tell to those who want to erase some words, 'master/slave', 'black/white' .......
2021-06-25 09:09:55 <ncopa> good morning
2021-06-25 09:11:26 <ncopa> im gonna be offline all next week
2021-06-25 09:11:54 <ncopa> is there anything important that i should look at? today is the day i need to do it
2021-06-25 09:22:17 <PureTryOut> clandmeter: so far anything using ffmpeg fails on riscv64 due to `>>> ERROR: ffmpeg*: libavcodec.so.: path not found` at https://build.alpinelinux.org/buildlogs/build-edge-riscv64/community/ffmpeg/ffmpeg-4.4-r2.log
2021-06-25 09:22:23 <PureTryOut> Any clue why that is happening by any chance?
2021-06-25 09:22:32 <PureTryOut> Cogitri: hey, had any luck with bootstrapping Rust so far?
2021-06-25 09:41:55 <mps> ncopa: not to do but if you have little time to comment !22592
2021-06-25 09:42:29 <mps> waiting for this, after that I want to add riscv there
2021-06-25 09:43:34 <ncopa> mps: I don't know arm hardware well enough so i have no clue how to group them. I think grouping them by family sounds like a good idea
2021-06-25 09:43:56 <ncopa> mps: you are also the maintainer, so I trust you and have no objection to that MR
2021-06-25 09:44:43 <ncopa> just please keep in mind that if you later change it, it needs to be done in a way to we dont make people's devices unbootable. so it needs to be in a backwards compatible way
2021-06-25 09:46:15 <mps> yes, understand your concerns, but we don't have any feedback how users installs arm SBCs, or I don't know for feedbacks
2021-06-25 09:53:25 <mps> btw, I think I fixed drbd-utils 9.18.0 upgrade !22564
2021-06-25 09:54:29 <mps> and we can look at perl upgrade when you come back here,  !21619, anyway I want to test it once more
2021-06-25 09:56:25 <mps> oh, and 'brainstorming' question: libudev-zero have utility named 'hotplug' and I want to add it but name is to generic imo
2021-06-25 09:56:41 <mps> it should go in /sbin
2021-06-25 09:57:13 <mps> to give it some other name for alpine or keep upstream name?
2021-06-25 10:04:41 <Cogitri> PureTryOut: Nop, still blocked on getting a functional Alpine cross env
2021-06-25 10:05:46 <PureTryOut> Ah, damn. OpenSSL still blocking you?
2021-06-25 10:06:39 <Cogitri> I think it was something later in the bootstrap chain, not sure right now
2021-06-25 10:07:46 <Cogitri> Apparently there are ways do cross compilation without the bootstrapping step but since we don’t have docs on any of that (or I can’t find them at least) and I already have a pretty poor understanding of how cross works on Alpine I'm not really up to messing with that
2021-06-25 10:10:39 <PureTryOut> Yeah makes sense
2021-06-25 10:13:10 <PureTryOut> Got any docs on how to set up that cross env? Even if it's broken for now
2021-06-25 11:13:45 <Cogitri> I only know that ./scripts/bootstrap.sh riscv64 gives me a sysroot and then CBUILD=riscv64-triplet abuild -r in the rust dir should apparently do the cross build but I only picked that up from chitchat in this channel
2021-06-25 11:14:50 <PureTryOut> Hmm, this stuff should get some proper documenting then
2021-06-25 11:15:34 <PureTryOut> Lol that script immediately fails for me
2021-06-25 11:15:49 <PureTryOut> 
ACTION  < https://matrix.org/_matrix/media/r0/download/matrix.org/tBOilldgZaigePraMRSGjMXa/message.txt >

2021-06-25 11:15:49 <PureTryOut> 
ACTION  < https://matrix.org/_matrix/media/r0/download/matrix.org/DGOqUEvcyzJWXfanCbfxxPsU/message.txt >

2021-06-25 11:16:17 <clandmeter> PureTryOut: hi
2021-06-25 11:16:24 <PureTryOut> hi 👋
2021-06-25 11:16:46 <clandmeter> sounds like a broken symlink?
2021-06-25 11:17:56 <PureTryOut> Uh, idk. I have no symlinks in `~/.abuild` though
2021-06-25 11:18:34 <clandmeter> it only breaks on riscv64?
2021-06-25 11:19:58 <PureTryOut> No every arch fails
2021-06-25 11:24:37 <clandmeter> ikke: isnt it that libs need to split before dev?
2021-06-25 11:25:25 <ikke> yes, if you have dev before libs, the files are already moved to the -dev subpackage
2021-06-25 11:25:45 <clandmeter> and this issue never happened before?
2021-06-25 11:26:39 <clandmeter> ffmpeg builds fine for me local with current tree
2021-06-25 11:27:21 <clandmeter> PureTryOut: why are you bundling two pkgs in 1 commit?
2021-06-25 11:31:04 <PureTryOut> Am I?
2021-06-25 11:31:08 <PureTryOut> I normally don't, so that would be a mistake
2021-06-25 11:32:57 <clandmeter> PureTryOut: 74bac2332044057efda6e9e02326edd7a43b07cd
2021-06-25 11:33:16 <PureTryOut> Oh, yeah definitely a mistake
2021-06-25 11:33:30 <PureTryOut> I was trying to see if I could get the ffmpeg package fixed, I guess I forgot to undo that pkgrel bump
2021-06-25 11:33:32 <PureTryOut> sorry
2021-06-25 11:35:52 <clandmeter> np, happens
2021-06-25 11:36:26 <clandmeter> i need to check that build failure on my riscv64 host
2021-06-25 11:38:05 <PureTryOut> Well it builds, it's just that it can't find the path of important libs
2021-06-25 11:52:37 <clandmeter> The pkg is ok in my machine
2021-06-25 12:01:13 <PureTryOut> Hmm. Did you change anything?
2021-06-25 12:08:32 <clandmeter> no, i mean on x86_64
2021-06-25 12:17:35 <PureTryOut> Oh yeah it's just riscv64 that's broken
2021-06-25 12:21:14 <Ariadne> aarch64 is still blocked by java-jna?
2021-06-25 12:21:18 <Ariadne> can we just block java-jna
2021-06-25 12:21:20 <Ariadne> for now
2021-06-25 12:22:45 <ikke> What depends on it? 
2021-06-25 12:23:32 <Ariadne> `ap revdep java-jna` shows nothing
2021-06-25 12:24:21 <ikke> Required by (0)
2021-06-25 12:25:15 <Ariadne> i blocked it
2021-06-25 12:25:19 <Ariadne> can you kick the aarch64-edge
2021-06-25 12:25:21 <Ariadne> builder
2021-06-25 12:25:30 <ikke> Not atm
2021-06-25 12:25:45 <ikke> clandmeter: ^? 
2021-06-25 12:25:57 <Ariadne> you being anyone who can do it
2021-06-25 12:25:58 <Ariadne> :p
2021-06-25 12:27:23 <clandmeter> dont know which box it is
2021-06-25 12:27:31 <clandmeter> netbos is out of date
2021-06-25 12:27:38 <ikke> usa9
2021-06-25 12:28:35 <clandmeter> ok rebooted
2021-06-25 12:30:00 <clandmeter> i dont see it on build.a.o?
2021-06-25 12:32:18 <Ariadne> build-edge-aarch64?
2021-06-25 12:44:42 <Ariadne> GCC 10 tree looks calm lately, going to roll an update
2021-06-25 12:58:42 <Cogitri> Ariadne: Since you're around: Do you know how cross compilation with abuild is supposed to work? I was trying to cross compile stuff for riscv64 without much success
2021-06-25 12:59:20 <Ariadne> look at how bootstrap.sh does it
2021-06-25 12:59:39 <Ariadne> APKBUILDs have to be written in a special way to enable them for cross compiling
2021-06-25 12:59:46 <Ariadne> you can't just cross compile any APKBUILD
2021-06-25 13:00:22 <Ariadne> thats basically what i can say :D
2021-06-25 13:03:43 <Ariadne> >>> gcc: Building main/gcc 10.3.1_git20210625-r0 (using abuild 3.8.0_rc2-r1) started Fri, 25 Jun 2021 13:03:11 +0000
2021-06-25 13:03:44 <Ariadne> :)
2021-06-25 13:03:51 <Ariadne> on s390x
2021-06-25 13:07:42 <Hello71> mps: /sbin/hotplug name is already reserved for udev (hal is obsolete) so i think as long as it conflicts eudev it should be ok
2021-06-25 13:08:00 <Hello71> ncopa: i asked earlier if you use qemu-guest-agent, not sure if you answered
2021-06-25 13:08:45 <Hello71> Ariadne: this confusion about bootstrap.sh seems to happen a lot, should we update bootstrap.sh to be more clear about it
2021-06-25 13:11:35 <Ariadne> btw
2021-06-25 13:11:42 <Ariadne> gcc 11 will probably be alpine 3.16
2021-06-25 13:11:47 <Ariadne> there is still a lot of bugs :(
2021-06-25 13:11:57 <mps> Hello71: apk search cmd:hotplug show nothing
2021-06-25 13:12:14 <Hello71> er, yes, also modern udev doesn't use it i think :p
2021-06-25 13:12:20 <Hello71> hm, i guess mdev also uses it?
2021-06-25 13:12:56 <Hello71> dunno, maybe make a complicated "alternatives" system to handle adjusting a symlink :p
2021-06-25 13:13:23 <mps> no, mdev 'install' self in /proc/sys/kernel/hotplug
2021-06-25 13:13:56 <Hello71> mmhmm
2021-06-25 13:14:52 <Ariadne> alternatives is on the todo list for apk3
2021-06-25 13:14:56 <Ariadne> but probably won't be in apk 3.0
2021-06-25 14:25:51 <z3ntu> Is there an easy way to find all packages that depend on a specific .so lib (like libfoo.so.1; and what packages need to be rebuilt for libfoo.so.2)? 
2021-06-25 14:26:12 <z3ntu> Like all packages in Alpine, not from what's installed locally
2021-06-25 15:01:16 <fcolista>  apk search -r libv4l2.so <---will find all pacakges depending from libv4l2.so
2021-06-25 15:03:40 <PureTryOut> Uhm, the aarch64 builder seems to be stuck on `community/java-lz4`
2021-06-25 15:13:51 <Newbyte[m]> Is there any way to tell the builders to always rebuild a package when a different package is upgraded?
2021-06-25 15:15:43 <ikke>  No
2021-06-25 15:15:57 <ikke> The package needs a pkgrel bump 
2021-06-25 15:16:09 <ikke> So it always needs to be explicit 
2021-06-25 15:16:44 <ikke> Without a pkgrel bump, the package would not be upgraded for users who have it already installed 
2021-06-25 15:38:33 <kasper81> ikke: is there anything in infra where a policy could be defined, such as: "if builder job hasn't advanced by even 1% in past $configurable hours, mark it as failed, save its logs with _failed suffix and kill it so other packages can continue" (without requiring human intervention)?
2021-06-25 15:41:34 <ikke> Not atm
2021-06-25 15:42:28 <ikke> And build failures should be fixed, not ignored
2021-06-25 15:44:47 <kasper81> which is why i explicitly said "mark it as failed, save its logs with _failed suffix"
2021-06-25 15:45:12 <ikke> Atm, when a package fails, the builder stops
2021-06-25 15:45:19 <ikke> Which is by design
2021-06-25 15:45:51 <ikke> So, even if it would time out, it will not continue building other packages 
2021-06-25 15:47:32 <nmeum> z3ntu: https://tpaste.us/K5wY
2021-06-25 15:47:43 <nmeum> I think there are several similar scripts flying around
2021-06-25 15:47:44 <kasper81> this design is clearly not scaling and wasting tons of hours for people waiting for stuff of their interest. e.g. ppc64le is stuck on sigar for past few days.
2021-06-25 15:47:53 <nmeum> maybe we should add one of those rebuild scripts to abuild.git at some point
2021-06-25 15:56:32 <ikke> kasper81: there are ideas to completely restructure the build infra, but 1) it takes time, 2) we know what we want, but not necessary the technology that is suitable
2021-06-25 15:57:19 <ikke> In any case, we still need to make sure the repository is in a consistent state
2021-06-25 15:57:49 <ikke> And, the incentive to fix packages instead of ignoring them is should not be underestimated
2021-06-25 16:04:57 <ikke> kasper81: what package are you waiting for?
2021-06-25 16:10:46 <kasper81> again, i have not said "ignoring" the package is an answer. instead, save the failure log and continue. a simple cron job can handle it with one string per builder ${BuilderID}-${PkgInProgress}-${ProgressPercent}, if it hasn't changed in next tick (say 6 hours), then save failure logs and continue. this is potentially what maintainers are doing,
2021-06-25 16:10:47 <kasper81> killing it and saving logs manually.
2021-06-25 16:29:59 <ikke> kasper81: the 'and continue' part is not happening
2021-06-25 16:51:18 <PureTryOut> The aarch64 builder is definitely stuck, can it be killed?
2021-06-25 17:14:25 <ikke> yes, was about to address it
2021-06-25 17:19:52 <PureTryOut> Cool thanks
2021-06-25 17:47:46 <z3ntu> fcolista: thanks! `apk search -r --origin -q libfmt.so.7 | sort | uniq` seems to be what I need :)
2021-06-25 18:47:51 <kasper81> just fyi, `| sort | uniq` == `| sort -u` :) 
2021-06-25 19:04:44 <dekedro> Hi, sometimes I try out various applications and in process write APKBUILD. However, I am not sure about maintaining them in a long run (as I often end up not using these programs). Should I push APKBUILD to testing anyway?
2021-06-25 19:06:59 <ikke> dekedro: We don't want testing to end up as a graveyard (even though in practice it sometimes already is)
2021-06-25 19:07:29 <ikke> If you make sure you clean up when you decide to not use those programs, you could still push them
2021-06-25 19:08:18 <dekedro> What do you mean by saying "clean up"? Move to unmaintained?
2021-06-25 19:08:25 <ikke> for example, yes
2021-06-25 19:08:52 <ikke> But don't add a package for just 2 weeks and then move it to unmaintained
2021-06-25 19:10:59 <dekedro> Ok, got it, thanks
2021-06-25 19:27:04 <tiotags> do apks have a clone sources directly from git option ?
2021-06-25 19:27:15 <tiotags> before compiling*
2021-06-25 19:27:57 <ikke> abuild has no native option for specifying a git repository as source
2021-06-25 19:29:46 <ikke> Nothing prevents you from just running git clone, though
2021-06-25 19:30:36 <tiotags> hmmm
2021-06-25 19:31:13 <tiotags> where in build () ?
2021-06-25 19:31:42 <tiotags> where would that go, in build () ?*
2021-06-25 19:33:16 <ikke> Is this just for a personal aport, or are you planning to contribute it?
2021-06-25 19:33:47 <tiotags> I have a merge request, one sec
2021-06-25 19:34:53 <ikke> because for official aports, that's not really a solution
2021-06-25 19:36:34 <tiotags> what is ?
2021-06-25 19:37:09 <tiotags> ah, then how would it work better ?
2021-06-25 19:37:36 <ikke> Where is the git repository hosted?
2021-06-25 19:37:53 <tiotags> gitlab
2021-06-25 19:38:09 <ikke> Does the project have releases?
2021-06-25 19:38:46 <tiotags> I'm usually lazy about that
2021-06-25 19:39:23 <ikke> You cannot just checkout master and package that, we expect predictable packages
2021-06-25 19:39:37 <ikke> With checksummed sources
2021-06-25 19:40:07 <tiotags> so no way to do some sort of testing apk at least for myself ?
2021-06-25 19:40:52 <tiotags> that makes sense
2021-06-25 19:41:13 <ikke> If it's for yourself (ie, you build it yourself), of course you can do whatever your want
2021-06-25 19:41:45 <ikke> So I gather you do not have tags either, or do you?
2021-06-25 19:41:49 <tiotags> what I mean is right now I just modify the apk sources to point to a local tar.gz, is there an easier way ?
2021-06-25 19:42:10 <ikke> sources can point to a location on disk
2021-06-25 19:42:42 <tiotags> yes I do have tags, but I was trying to say I'm not very proactive at making tags
2021-06-25 19:44:54 <ikke> You can also point to a specific commit
2021-06-25 20:03:42 <tiotags> is it weird to ask for feedback on a git merge request on irc ?
2021-06-25 20:03:59 <danieli> not at all
2021-06-25 20:06:28 <tiotags> I have this webserver I wanted to have a binary apk package I can just install in docker images
2021-06-25 20:06:47 <tiotags> but my git mr got ignored https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22514
2021-06-25 20:07:04 <tiotags> why, it's a perfectly decent webserver
2021-06-25 20:07:25 <mps> !22514
2021-06-25 20:08:46 <ikke> tiotags: to be honest, 4 days is not being ignored :)
2021-06-25 20:09:52 <tiotags> is there a review process or how does it work ?
2021-06-25 20:10:07 <ikke> volunteers will look at them when they have time
2021-06-25 20:10:17 <mps> why depends on openssl
2021-06-25 20:11:02 <tiotags> it's not an optional dependency but I don't know how to make it optional in apkbuild
2021-06-25 20:12:11 <tiotags> is there a better ssl library ?
2021-06-25 20:12:12 <mps> then don't add it without good reason
2021-06-25 20:12:47 <mps> it have openssl-dev in makedepends, which is enough
2021-06-25 20:13:17 <mps> abuild and apk auto solves this
2021-06-25 20:13:35 <tiotags> doesn't it need the openssl so ?
2021-06-25 20:13:38 <ikke> correct, apkbuild automatically traces dependencies
2021-06-25 20:13:58 <ikke> if there is a so depend
2021-06-25 20:14:37 <tiotags> so I just remove it and it works ?
2021-06-25 20:14:38 <mps> same for lua-libs
2021-06-25 20:15:01 <tiotags> then what's the point of the depends variable
2021-06-25 20:15:18 <ikke> https://gitlab.alpinelinux.org/tiotags/aports/-/jobs/420646#L246
2021-06-25 20:15:27 <ikke> tiotags: for run-time dependencies that are not automatically detected
2021-06-25 20:15:33 <mps> actually 'depends' line not needed at all
2021-06-25 20:16:27 <tiotags> did not know that, that's an interesting system you have there
2021-06-25 20:16:33 <mps> also boilerplate pre-install and post-install are not needed
2021-06-25 20:16:55 <dalias> ariadne, is there any howto about running anbox? you suggested just apk add but presumably there's more you have to do to actually be able to run it..
2021-06-25 20:17:07 <mps> run dir should be /run
2021-06-25 20:21:51 <ikke> And TMP_DIR /tmp, I guess?
2021-06-25 20:26:24 <tiotags> tmp dir is where the cache is placed
2021-06-25 20:26:42 <tiotags> it will be persistent in the future
2021-06-25 20:27:18 <tiotags> (in the future, dk when I get to it, but it is on the list of things)
2021-06-25 20:27:46 <ikke> ok, then /var/tmp makes sense
2021-06-25 20:30:43 <tiotags> I've added a new version of init.d and fixes proposed by everyone
2021-06-25 20:30:53 <tiotags> thank you btw
2021-06-25 20:34:21 <ikke> Oh, I just noticed that it lacks a maintainer. I guess you want to maintain the package (ie, make sure it's kept up-to-date)?
2021-06-25 20:36:46 <tiotags> how would that work, would I just add merge requests for new versions ?
2021-06-25 20:37:54 <tiotags> can somebody with commit access do that for me pretty please with a cherry on top ?
2021-06-25 20:38:17 <tiotags> I'm pretty new to alpine I'd be a horrible maintainer
2021-06-25 20:45:00 <ikke> You'd need to find someone willing to take that responsibility
2021-06-25 20:45:29 <ikke> But yes, it would just be merge requests to aports
2021-06-25 22:57:50 <Ariadne> dalias: ask in #postmarketOS i guess
2021-06-26 02:09:06 <insep> dalias: in pmos we have https://gitlab.com/postmarketOS/pmaports/-/tree/master/main/postmarketos-anbox which sets things up and wiki.postmarketos.org/wiki/Anbox which explains how to launch it and everything
2021-06-26 02:09:18 <insep> just hope that it's not broken
2021-06-26 02:37:21 <craftyguy> hey can folks look at this one somewhat quickly? util-linux-misc is broken on edge :( https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22630
2021-06-26 02:40:59 <craftyguy> Ariadne: any chance you're still awake? ^^
2021-06-26 02:41:27 <craftyguy> apparently we (pmOS) rely on quite a few things in util-linux, so everything is on fire right now :(
2021-06-26 02:50:45 <Sheila> probably 4-6 hours, depending on when she wants to be up.
2021-06-26 03:31:20 <afontain[m]> dalias: the installation instructions on the pmOS wiki won't be as useful, so basically it's
2021-06-26 03:34:04 <afontain[m]> 
ACTION  < https://matrix.org/_matrix/media/r0/download/matrix.org/ieBvTTYYJoYgtYPsuvlKlCvv/message.txt >

2021-06-26 03:34:25 <afontain[m]> You'll need X.org and dbus
2021-06-26 03:41:54 <Ariadne> craftyguy: util-linux installs all packages via install_if
2021-06-26 03:43:28 <craftyguy> Ariadne: no that's not the problem... The problem is it installs the binaries in the wrong location. See the commit message in that MR :)
2021-06-26 03:43:41 <Ariadne> craftyguy: "wrong" location
2021-06-26 03:43:49 <craftyguy> E.g. /sbin/sbin/agetty ???
2021-06-26 03:44:20 <craftyguy> or /usr/bin/bin/rfkill , and so on. That looks wrong to me :)
2021-06-26 03:44:49 <Ariadne> huh
2021-06-26 03:44:52 <Ariadne> okay
2021-06-26 03:44:59 <Ariadne> do you have a fix? :D
2021-06-26 03:45:12 <Ariadne> indeed you do
2021-06-26 03:45:39 <craftyguy> :)
2021-06-26 03:46:10 <Ariadne> done
2021-06-26 03:48:54 <Ariadne> craftyguy: thanks for the quick fix :)
2021-06-26 03:54:21 <craftyguy> thank you! that util-linux APKBUILD has... a lot going on in it...
2021-06-26 08:53:48 <mps> testing/java-asmtools passed 'abuild -r' on dev lxc aarch64, why it is stuck on builder
2021-06-26 08:54:34 <mps> I can't see log on builder
2021-06-26 09:20:26 <ikke> Same like other java- packages
2021-06-26 09:20:30 <ikke> not sure why they are stuck
2021-06-26 09:22:12 <PureTryOut> sigar (also a Java package) is stuck on ppc64le as well
2021-06-26 09:36:15 <ikke> It seems some kind of deadlock
2021-06-26 09:37:18 <ikke> there is still a thread that is running
2021-06-26 09:37:33 <ikke> but just waiting for a futex
2021-06-26 09:41:53 <ikke> One thread is reading from a pipe
2021-06-26 10:40:38 <kasper81> sigar is stuck on ppc64le for 4-5 days now.
2021-06-26 11:24:47 <kpcyrd> I'm trying to use mkimage.sh to build a raspi image (on x86_64 to aarch64) but I'm getting signature errors, what's the easiest way to import the right key?
2021-06-26 11:24:49 <kpcyrd> ERROR: http://dl-cdn.alpinelinux.org/alpine/edge/main: UNTRUSTED signature
2021-06-26 11:26:37 <kpcyrd> ah found it, never mind: cp /usr/share/apk/keys/aarch64/* /etc/apk/keys/
2021-06-26 11:27:01 <ikke> There is a --hostkeys option
2021-06-26 11:29:31 <kpcyrd> didn't work for some reason, it's working now :)
2021-06-26 11:31:55 <kpcyrd> I'm not sure if I'm meant to run those scripts from x86_64 though, rpi_blobs fails because `apk fetch --quiet --stdout raspberrypi-bootloader` doesn't output anything
2021-06-26 11:37:47 <kpcyrd> replaced it with curl for now
2021-06-26 12:25:52 <nmeum> is there any way to replicate the gitlab CI environment locally? I am trying to debug a community/go test failure on x86 but I cannot replicate it inside a x86 qemu vm, it only seems to fail on the CI...
2021-06-26 12:26:49 <ikke> Use the alpinelinux/alpine-gitlab-ci docker image
2021-06-26 12:27:10 <ikke> or build-base, if you don't need the CI automation
2021-06-26 12:30:34 <nmeum> https://gitlab.alpinelinux.org/alpine/infra/docker/build-base this?
2021-06-26 12:31:02 <ikke> yes
2021-06-26 12:31:14 <ikke> But you can just pull the image
2021-06-26 12:31:43 <ikke> https://hub.docker.com/r/alpinelinux/build-base
2021-06-26 12:31:45 <nmeum> ah, right
2021-06-26 12:31:47 <nmeum> thanks
2021-06-26 14:20:47 <PureTryOut> The riscv64 builder is stuck on `community/font-noto-emoji`, can it be killed?
2021-06-26 14:24:45 <ikke> It looks like it's still continuing
2021-06-26 14:24:52 <ikke> just very slow
2021-06-26 14:26:08 <PureTryOut> Oh, huh. I wouldn't expect that package to take that long
2021-06-26 14:26:32 <ikke> checking the log output
2021-06-26 14:27:00 <ikke> There are 20+ processes, all taking 100% cpu
2021-06-26 14:27:02 <ikke> load is 48
2021-06-26 14:27:33 <ikke> 48 process running
2021-06-26 14:28:23 <PureTryOut> Damn
2021-06-26 14:36:36 <Hello71> makedepends="optipng"
2021-06-26 14:38:49 <ikke> it finished
2021-06-26 16:13:03 <PureTryOut> riscv64 has now built 80% of the community repository
2021-06-26 16:13:32 <ikke> Noice!
2021-06-26 16:13:43 <PureTryOut> Well, better said, "finished going through 80% of the community repository". Lots of stuff gets disabled of course, mainly Java and Rust related
2021-06-26 16:30:30 <nmeum> does rust not support riscv64 yet?
2021-06-26 16:30:39 <nmeum> or is it just a bootstrapping problem?
2021-06-26 16:32:57 <ikke> bootstrapping
2021-06-26 16:33:19 <dalias> insep, ariadne, it looks like (among possibly other things) there's no android.img
2021-06-26 16:33:33 <dalias> presumably you're supposed to get that somewhere else but there are no instructions :/
2021-06-26 16:33:52 <Ariadne> dalias: i hate to be a squeaky wheel, but what would your opinion be re: switching to 256kb/512kb stacks like darwin and openbsd did
2021-06-26 16:34:42 <dalias> ariadne, pretty much entirely against. our current value is aligned with what the linux kernel does (which is not presently customizable, but should be made customizable with PT_GNU_STACK like it is on fdpic)
2021-06-26 16:35:07 <insep> dalias: afontain gave you instructions on how to get one, i guess you didn't see them because matrix
2021-06-26 16:35:19 <dalias> insep, oh i'll look..
2021-06-26 16:35:47 <insep> there's one at anbox.postmarketos.org
2021-06-26 16:36:45 <dalias> indeed i didn't notice the matrix paste
2021-06-26 16:36:48 <dalias> but see it now
2021-06-26 16:37:17 <dalias> it'd be really nice if container-manager weren't needed and you could just invoke it direct as user...
2021-06-26 16:38:45 <Ariadne> fwiw the people i actually care about seem to think the 128kb stack is a feature, since it shows programs which need to be fixed
2021-06-26 16:39:11 <dalias> i don't even really care if they're fixed. the link option made a solution for stuff that refuses to fix
2021-06-26 16:39:12 <Ariadne> if some weirdo on hacker news decides to use gnu/linux for his needs, well, thats the great thing about all of this, he can just go do that
2021-06-26 16:39:51 <dalias> HN is stupid and i don't want to design around stupid HN comments
2021-06-26 16:40:19 <Ariadne> agree
2021-06-26 16:41:10 <dalias> insep, is the .img read-only or does it need COW space?
2021-06-26 16:42:03 <Ariadne> i find it funny when HN people talk about alpine needing to do what the "big boys" do
2021-06-26 16:42:12 <Ariadne> 
ACTION looks at, basically the entire world

2021-06-26 16:42:21 <Ariadne> i think alpine is a big distro too
2021-06-26 16:42:27 <ikke> heh
2021-06-26 16:42:33 <dalias> such cringeworthy language pretty much makes me ignore the speaker
2021-06-26 16:43:04 <valerius> it is a distro that is getting big by doing things differently, in such a way that it attracts a lot of people whose needs it suits better than older and more established distros
2021-06-26 16:43:23 <insep> dalias: pretty sure it's ro
2021-06-26 16:43:49 <dalias> where does rw data get stored? do you have to configure how much there is?
2021-06-26 16:44:08 <caskd> valerius: exactly, alpine is loved because it does things better
2021-06-26 16:44:25 <wener> It woupd be nice if the article explained why was the current size set and what is the benefit of doing so?
2021-06-26 16:44:30 <Ariadne> we should innovate harder, and introduce 1GiB thread stacks
2021-06-26 16:44:33 <wener> from hn comment
2021-06-26 16:44:34 <Ariadne> who needs malloc
2021-06-26 16:44:37 <Ariadne> just use alloca
2021-06-26 16:44:40 <caskd> lmao
2021-06-26 16:44:47 <valerius> hardware is cheap ;)
2021-06-26 16:44:47 <Ariadne> built in garbage collection
2021-06-26 16:45:10 <Ariadne> don't worry, i am kidding
2021-06-26 16:45:25 <ikke> Oh, just got my hopes up :P
2021-06-26 16:45:56 <dalias> 1. there's already a soft 128k limit on the main thread and if you just write programs assuming you have more/unlimited stack they'll crash under oom conditions. crashing early catches that bug and gets you to fix it
2021-06-26 16:47:17 <dalias> 2. it's rather unsafe and unreasonable for applications that *want* to make lots of thread and intentionally avoid using much stack space to *reduce* the default stack size, since the implementation might have internal reasons it needs it to be large. so nothing reduces it, and having N MB default thread stacks means your application uses N*nthreads MB
2021-06-26 16:47:49 <dalias> the only reason this is "acceptable" on glibc is because they assume you're using overcommit and a 64-bit arch
2021-06-26 16:49:03 <afontain[m]> dalias: the image can be chmod 0400 root
2021-06-26 16:49:30 <Ariadne> look, alpine on april 1, 2022
2021-06-26 16:49:35 <Ariadne> is gonna have the biggest stacks ever
2021-06-26 16:49:43 <Ariadne> we're going all the way to 1TiB
2021-06-26 16:49:48 <Ariadne> cloud scale stacks
2021-06-26 16:49:53 <afontain[m]> Yes!
2021-06-26 16:50:01 <afontain[m]> no need to malloc anymore!
2021-06-26 16:50:03 <Ariadne> actually, no
2021-06-26 16:50:15 <Ariadne> musl will fetch the current price of gamestop and the current price of bitcoin
2021-06-26 16:50:29 <Ariadne> and then the default stack size will be set to bitcoin / gamestop
2021-06-26 16:50:32 <afontain[m]> Yes!
2021-06-26 16:50:53 <Ariadne> i should stop before dalias has a stroke
2021-06-26 16:50:54 <Ariadne> haha
2021-06-26 16:51:38 <dalias> on 32-bit, just 256-384 threads hard-exhausts the vm space, with *nothing else* in memory
2021-06-26 16:51:44 <dalias> (assuming glibc 8MB thread stacks)
2021-06-26 16:52:17 <dalias> afontain[m], i'm going to have to figure out how to fix that part :-p
2021-06-26 16:53:09 <afontain[m]> which part?
2021-06-26 16:53:32 <dalias> that something is running as root letting user access a mode-400, root-owned file :-p
2021-06-26 16:53:38 <Ariadne> somebody pointed out that PTHREAD_MIN_STACK is allowed to be 0
2021-06-26 16:53:46 <Ariadne> so, technically
2021-06-26 16:53:54 <Ariadne> musl is 128,000x more forgiving
2021-06-26 16:54:01 <Ariadne> than POSIX
2021-06-26 16:54:02 <Ariadne> :)
2021-06-26 16:55:22 <afontain[m]> sry for the matrix paste btw, I assumed the oftc bridge worked like the libera one, but it seems its config is a bit different
2021-06-26 16:55:48 <dalias> np
2021-06-26 16:55:54 <afontain[m]> dalias: well, it should allow access only to the world-readable files*
2021-06-26 16:55:58 <dalias> i still get No runtime directory specified
2021-06-26 16:56:16 <afontain[m]> export XDG_RUNTIME_DIR
2021-06-26 16:56:21 <dalias> what should it be?
2021-06-26 16:56:28 <dalias> i dont use any gnome stuff
2021-06-26 16:56:57 <afontain[m]> very poor man's one, $(mktemp -d)
2021-06-26 16:57:05 <dalias> lol
2021-06-26 16:57:17 <Ariadne> oh, we should just cram hundreds of KB of crap on the stack, because it will fit in cache line
2021-06-26 16:57:45 <Ariadne> HN is amazing
2021-06-26 16:58:01 <dalias> ok now it doesn't error out but doesn't seem to be doing anything
2021-06-26 16:58:18 <afontain[m]> it means it works
2021-06-26 16:58:37 <afontain[m]> have you got some anbox.appmgr command?
2021-06-26 16:58:55 <dalias> ?
2021-06-26 16:59:10 <Hello71> 16:53 <Ariadne> musl is 128,000x more forgiving
2021-06-26 16:59:16 <Hello71> 128000/0=128000?
2021-06-26 16:59:21 <dalias> no output from anbox session-manager
2021-06-26 16:59:24 <afontain[m]> otherwise you need a long manual command
2021-06-26 16:59:36 <dalias> what should i run to try to see something interesting?
2021-06-26 17:00:46 <afontain[m]> anbox launch --package=org.anbox.appmgr --component=org.anbox.appmgr.AppViewActivity
2021-06-26 17:01:04 <dalias> [launch.cpp:72@launch_session_manager] Can't find correct anbox executable to run. Found /memfd:liblxc (deleted) but does not exist
2021-06-26 17:01:21 <afontain[m]> huh
2021-06-26 17:01:27 <afontain[m]> how did you start dbus?
2021-06-26 17:02:26 <dalias> however xfce-session did
2021-06-26 17:02:33 <dalias> if you mean the user bus
2021-06-26 17:02:41 <dalias> system is just from openrc
2021-06-26 17:03:54 <afontain[m]> yeah, user bus
2021-06-26 17:04:05 <afontain[m]> I haven't seen this error before
2021-06-26 17:04:15 <afontain[m]> do you have any hardening that could interfere?
2021-06-26 17:04:45 <dalias> maybe. is it trying to do some crap where system dbus lazy-launches services?
2021-06-26 17:04:57 <dalias> i globally nuked that and i dont remember how :-)
2021-06-26 17:05:52 <afontain[m]> I don't think it does
2021-06-26 17:06:25 <afontain[m]> are you launching both command from graphical terminal emulators?
2021-06-26 17:06:33 <dalias> going to watch strace of anbox service side when i run anbox session-manager
2021-06-26 17:06:41 <dalias> i'm launching with DISPLAY set
2021-06-26 17:07:02 <afontain[m]> ah, that's probably why it doesn't work
2021-06-26 17:07:03 <dalias> i dont know what other notion of "graphical terminal emulator" this fdo hell might have :-p
2021-06-26 17:07:27 <dalias> i so hate this whole ecosystem
2021-06-26 17:07:37 <afontain[m]> well, it's quite sensible on environment setup
2021-06-26 17:07:57 <afontain[m]> the IPC feels quite fragile IMO
2021-06-26 17:08:05 <dalias> i think all that could be nuked
2021-06-26 17:08:11 <dalias> i just want to study how it works
2021-06-26 17:08:24 <dalias> and make a 50-line shell script version using unshare(1) to replace it
2021-06-26 17:08:39 <dalias> i wonder if it's just oom'ing
2021-06-26 17:08:49 <afontain[m]> well, some started a rewrite at https://github.com/Anbox-halium/anbox-halium
2021-06-26 17:09:09 <afontain[m]> but huh, I would dare no claim on code quality on that side either
2021-06-26 17:10:46 <dalias> i also want to strip down the android.img to be nothing but system libraries to run a single app
2021-06-26 17:11:02 <dalias> rather than a multi-app-hosting android environment
2021-06-26 17:11:50 <afontain[m]> so you would have a different android image for different apps?
2021-06-26 17:12:12 <afontain[m]> or just a different container made by mounting different things in place
2021-06-26 17:12:13 <dalias> no, the app isn't part of the image
2021-06-26 17:12:46 <dalias> i mean having no home screen manager, settings program, android ipc services, etc.
2021-06-26 17:13:06 <dalias> instead dummying the ipc that apps actually need with HLE
2021-06-26 17:13:17 <afontain[m]> so there is that thing I could find no documentation on, anbox-cloud
2021-06-26 17:13:21 <afontain[m]> https://anbox-cloud.io/
2021-06-26 17:13:47 <afontain[m]> it's using a different codebase
2021-06-26 17:13:58 <afontain[m]> (possibly luckily for them)
2021-06-26 17:14:09 <afontain[m]> it's not free software, AFAIK
2021-06-26 17:15:08 <afontain[m]> would your thing support GUI apps?
2021-06-26 17:15:15 <dalias> lovely anbox process is spinning with 1ms sleeps and non-blocking recvmsg between them
2021-06-26 17:15:18 <dalias> yes
2021-06-26 17:16:19 <dalias> lovely, x server crashed eventually
2021-06-26 17:16:27 <afontain[m]> anbox-halium currently has recent LineageOS (the one corresponding to Android 10)
2021-06-26 17:17:20 <dalias> it sounds like this stuff has a long ways to go to be usable
2021-06-26 17:17:31 <afontain[m]> agreed
2021-06-26 17:17:55 <dalias> but i think the underlying problem is not that hard
2021-06-26 17:18:09 <dalias> and it just has a lot of fdo ipc junk interfering with it working
2021-06-26 17:18:32 <dalias> there's no reason for it to even have a container manager or run as root
2021-06-26 17:19:12 <afontain[m]> maybe once upon a time you needed root for squashfs?
2021-06-26 17:19:21 <afontain[m]> now there's squashfuse though
2021-06-26 17:19:23 <dalias> just unshare(1), use some tmpfs and bind mounts, and userspace networking
2021-06-26 17:19:34 <dalias> well they have the network bridge that needs root they way they implemented it
2021-06-26 17:19:50 <dalias> and once you have stuff that needs root you need a complex docker-esque container manager to mediate that
2021-06-26 17:19:56 <afontain[m]> I believe the container manager actually can run as user
2021-06-26 17:19:59 <afontain[m]> never tested that
2021-06-26 17:20:27 <dalias> well it'd need root to setup the network bridge interface and move it into the container, at least
2021-06-26 17:20:37 <afontain[m]> (also please don't look at the mounting code, it's really bad)
2021-06-26 17:20:41 <dalias> :-p
2021-06-26 17:26:03 <rhatr> Hey @channel -- sorry for somewhat dropping the ball on the RISCV64 patches (was waiting for Alpine 3.14 to get released and then was traveling -- however unbelievable that is these days). I am, however, back.
2021-06-26 17:26:50 <rhatr> So... if anyone can tell me what's the best place to pick things up -- I'd appreciate that. Will go through all of the email (MR comments and whatnot now). And I guess I can at least start with rebasing all my work on the latest master (if nothing else).
2021-06-26 17:27:26 <rhatr> In other RISCV64 news -- I got 2nd SBC to play with (this one with a CPU done by Allwinner) will attempt booting Alpine on it as well
2021-06-26 17:28:38 <afontain[m]> dalias: would you just ignore the android dæmons? I must say I don't know how many of them are needed.
2021-06-26 17:29:10 <afontain[m]> and if you don't have some kind of manger I'm not sure how you would handle the daemons
2021-06-26 17:31:08 <valerius> rhatr, what SBCs are you using?
2021-06-26 17:31:55 <rhatr> I've got two https://www.indiegogo.com/projects/nezha-your-first-64bit-risc-v-linux-sbc-for-iot/x/13053257#/ and
2021-06-26 17:32:06 <rhatr> https://beagleboard.org/beaglev
2021-06-26 17:32:20 <rhatr> Been doing all my Alpine port testing on the later one so far -- the former just arrived
2021-06-26 17:33:27 <dalias> FUCK YOU ALPINE
2021-06-26 17:33:46 <valerius> umadbro?
2021-06-26 17:33:48 <dalias> bootmisc just rm -rf /'d
2021-06-26 17:34:06 <dalias> for uselessly wiping /tmp
2021-06-26 17:34:25 <dalias> which is a tmpfs and needs no wiping
2021-06-26 17:35:43 <dalias> now i need to find a suitably large usb flash to image this on
2021-06-26 17:38:24 <afontain[m]> ouch
2021-06-26 17:38:55 <dalias> look at the rm -rf commamd in thst script
2021-06-26 17:39:06 <dalias> it relies on already being in right dir
2021-06-26 17:39:12 <dalias> and is horribly unsafe
2021-06-26 17:39:18 <dalias> it should be nuked
2021-06-26 17:39:52 <dalias> ok i have world
2021-06-26 17:42:34 <dalias> arg this is going to be a huge time waste recovering
2021-06-26 17:43:15 <dalias> can someone please look into removing that dangerous bootmisc?
2021-06-26 17:50:33 <orbea> dalias: set -eu helps so much
2021-06-26 18:01:40 <nmeum> bootmisc is a horrible standard openrc service
2021-06-26 18:01:45 <nmeum> https://github.com/OpenRC/openrc/blob/master/init.d/bootmisc.in
2021-06-26 18:02:33 <nmeum> rhatr: a riscv64 builder has been setup, it has built (see #alpine-commits for it's current status)
2021-06-26 18:02:45 <nmeum> *it has built roughly 80% of community/
2021-06-26 18:02:52 <orbea> if ! rm -rf -- [!ajlq\.]* 2>/dev/null ; then
2021-06-26 18:02:56 <orbea> *shudder*
2021-06-26 18:03:05 <rhatr> aha! @nmeum -- thanks a million -- will check it out
2021-06-26 18:04:05 <nmeum> riscv64 packages can also be found on your favorite mirror now ;)
2021-06-26 18:04:46 <nmeum> would be very neat if someone could look into bootstrap rust on riscv64 since many packages depend on it and have been disabled for now
2021-06-26 18:07:18 <ikke> nmeum: cogitri has been looking into it, but he was trying to figure out how to cross-compile it in alpine
2021-06-26 18:07:40 <rhatr> Funny you should mention it @nmeum -- I'll be looking into rust/riscv combo for a personal project very soon
2021-06-26 18:09:23 <rhatr> Oh, and does anyone know why am I getting "<irc.oftc.net> Error(404): #alpine-infra Cannot send to channel" when trying to join #alpine-infra ?
2021-06-26 18:09:34 <ikke> Anyone knows how to run strace on the server side with rsync over ssh? I tried to provide it with 'f() { strace -o rsync.strace rsync "$@" 2>&1 >strace.out; }; f()'
2021-06-26 18:10:10 <ikke> rhatr: You should be able to join
2021-06-26 18:10:15 <ikke> I gather you use matrix?
2021-06-26 18:10:41 <rhatr> Thanks @ikke
2021-06-26 18:16:15 <dalias> orbea, it has cd || fail but some reason it didnt work right
2021-06-26 18:16:57 <dalias> theres no excuse for ever writing rm -rf that depends on being in right working dir to be safe tho
2021-06-26 18:17:21 <dalias> and theres no excuse for the abstract operation of cleaning /tmp on boot.
2021-06-26 18:17:24 <superduck> @ikke: isn't that where you use -e to rsync command?
2021-06-26 18:17:52 <orbea> yea, seems bad all around
2021-06-26 18:18:17 <superduck> --rsync-path=
2021-06-26 18:18:27 <nmeum> i am sure openrc will glady accept improvements to that script
2021-06-26 18:18:28 <ikke> I used --rsync-path
2021-06-26 18:19:04 <superduck> create a simple strace.sh #!/bin/sh strace rsync "$@"
2021-06-26 18:19:58 <superduck> is this channel of #alpine-linux a better place to discuss abuild issues?
2021-06-26 18:20:15 <ikke> This
2021-06-26 18:21:11 <superduck> + die 'rootpkg failed'
2021-06-26 18:21:15 <superduck> what would cause that during abuild?
2021-06-26 18:23:24 <superduck> using fakeroot-tcp and trying to build main/tree as a test of my abuild environment and getting failures
2021-06-26 18:24:11 <Hello71> ikke: why did you make a function?
2021-06-26 18:24:17 <superduck> upon entering fakeroot, I get >>> ERROR: *: Could not find ./APKBUILD (PWD=/home/$USER/src/aports/main/tree/src/src/tree-1.8.0)
2021-06-26 18:24:26 <ikke> Hello71: I also tried without
2021-06-26 18:24:38 <ikke> But there is something else going on
2021-06-26 18:24:48 <ikke> 'ash: strace: not found'
2021-06-26 18:24:49 <Hello71> like, rsync --rsync-path="strace -o rsync.strace rsync"?
2021-06-26 18:25:01 <ikke> rsync --rsync-path='strace -o rsync.strace rsync' -rui --delete-delay --delay-updates  community/x86/APKINDEX.tar.gz  dl-master.alpinelinux.org:alpine/v3.14/community/x86/
2021-06-26 18:25:02 <superduck> rsync-path doesn't take arguments as I recall
2021-06-26 18:25:24 <superduck> i.e. i think it's strictly and exec with no args passed
2021-06-26 18:25:35 <ikke> superduck: the manual said it's evaluated with a shell
2021-06-26 18:25:49 <Hello71> it also specifically has an example with &&
2021-06-26 18:25:52 <ikke> rsync -avR --rsync-path="cd /foo; rsync" \
2021-06-26 18:25:54 <superduck> @ikke: my memory can be bad
2021-06-26 18:26:00 <ikke> that's from the man
2021-06-26 18:26:15 <Hello71> did you check that strace is actually installed
2021-06-26 18:26:28 <ikke> yes
2021-06-26 18:26:33 <ikke> ash: /usr/bin/strace: not found
2021-06-26 18:26:52 <ikke> https://tpaste.us/prjj 
2021-06-26 18:26:53 <superduck> is rsync installed on the remote end?
2021-06-26 18:26:58 <ikke> yes
2021-06-26 18:27:33 <ikke> ooh, I'm stupid, strace is not installed :/
2021-06-26 18:27:34 <Hello71> so ssh dl-master.alpinelinux.org strace --help works, but rsync --rsync-path='strace --help' dl-master.alpinelinux.org: doesn't?
2021-06-26 18:27:55 <superduck> Hello71 is the winner of the debug contest
2021-06-26 18:28:24 <ikke> Somewhow how, each time I checked it, I typed rsync, instead of strace
2021-06-26 18:29:18 <ikke> ok, success
2021-06-26 18:32:50 <ikke> https://tpaste.us/gBKm
2021-06-26 18:33:15 <ikke> trying to figure out why rsync --delay-updates does not actually update files sometimes (APKINDEX.tar.gz in this case)
2021-06-26 18:34:24 <ikke> The file is uploaded as .~tmp~/APKINDEX.tar.gz (which is what --delay-updates does), but then never moved to APKINDEX.tar.gz
2021-06-26 18:34:54 <Ariadne> this bootmisc thing seems rather concerning
2021-06-26 18:35:28 <ikke> bootmisc?
2021-06-26 18:37:25 <Ariadne>  /etc/init.d/bootmisc
2021-06-26 18:37:29 <Ariadne> it just hosed dalias's box
2021-06-26 18:39:14 <Hello71> ikke: maybe try rsync -M --debug=all5
2021-06-26 18:39:24 <Hello71> (without strace)
2021-06-26 18:39:30 <ikke> hmm, I tried all4, not all5 yet
2021-06-26 18:40:03 <Hello71> Ariadne: another reason to get rid of openrc? ;)
2021-06-26 18:40:10 <Ariadne> yes
2021-06-26 18:40:12 <Ariadne> absolutely
2021-06-26 18:41:22 <ikke> Hmm, interesting. I've moved the temp file, and then it worked
2021-06-26 18:41:47 <ikke> sadly, I did that before I ran it with --debug=all5
2021-06-26 18:42:17 <ikke> It mentioned: renaming .~tmp~/APKINDEX.tar.gz to APKINDEX.tar.gz
2021-06-26 18:47:12 <ikke> Hello71: another case: https://tpaste.us/eVMa 
2021-06-26 18:48:21 <ikke> I have a feeling it's because these .~tmp~/* files are somehow still there
2021-06-26 18:48:31 <ikke> ie, left behind after an earlier attempt
2021-06-26 18:48:42 <ikke> though rsync does see the file needs to be updated
2021-06-26 18:49:43 <ikke> sorry, that was with -n, this is without: https://tpaste.us/kxBZ 
2021-06-26 18:50:49 <ikke> Compared to https://tpaste.us/Orob  where it did update
2021-06-26 18:51:25 <Ariadne> reason 9001 at this point Hello71
2021-06-26 18:51:49 <ikke> gen mapped .~tmp~/APKINDEX.tar.gz of size 1405209
2021-06-26 18:52:05 <ikke> compared to
2021-06-26 18:52:07 <ikke> gen mapped APKINDEX.tar.gz of size 1454150
2021-06-26 18:57:51 <dalias> hmm so now i need to find ..
2021-06-26 18:58:20 <dalias> 1. way to restore world
2021-06-26 18:58:46 <dalias> 2. way to verify that my disk image contains anything that may be recoverable
2021-06-26 18:59:08 <afontain[m]> that reminds me I need new backups
2021-06-26 18:59:27 <dalias> i need a nonshit automated bsckup system
2021-06-26 18:59:51 <afontain[m]> I did half-automated rsync
2021-06-26 19:00:11 <dalias> rsync isnt bsckup
2021-06-26 19:00:17 <afontain[m]> (a shell script that I run manually, that mounts stuff and sync)
2021-06-26 19:00:26 <afontain[m]> good enough if my data is safe
2021-06-26 19:00:48 <afontain[m]> it's kinda rather an archive than a backup
2021-06-26 19:00:53 <dalias> well it will happily clobber your backuo with new bad data
2021-06-26 19:01:05 <dalias> its a clone/mirror
2021-06-26 19:01:18 <afontain[m]> fine for me
2021-06-26 19:01:22 <dalias> part of my definition of backup is append-only
2021-06-26 19:01:24 <afontain[m]> (and yes)
2021-06-26 19:01:31 <mercenary> zfs snapshot + rsync, 10 line backup system
2021-06-26 19:02:12 <afontain[m]> if it's append-only, I don't have the disk space D:
2021-06-26 19:02:21 <dalias> :)
2021-06-26 19:02:42 <dalias> and i want suitable privacy properties
2021-06-26 19:03:07 <afontain[m]> cryptsetup?
2021-06-26 19:03:16 <dalias> so that backup host doesnt have to be trusted at all except not to lose data
2021-06-26 19:03:43 <afontain[m]> oh, yes, and I plug in an usb key / hard drive
2021-06-26 19:04:57 <dalias> so how can i "reinstall over top of partly hosed fs" with a world file?
2021-06-26 19:05:57 <mercenary> apk fix `cat world` ?
2021-06-26 19:07:35 <dalias> maybe but i dont have apk or sh
2021-06-26 19:07:48 <dalias> i have to run from a rescue disk
2021-06-26 19:08:34 <Sheila> pull apk.static from apk-tools-static on another box?
2021-06-26 19:09:10 <dalias> i need a rescue disk regardless but i have that
2021-06-26 19:09:16 <dalias> the fs is not bootable
2021-06-26 19:09:34 <mercenary> mount it, copy apk.static into it, chroot
2021-06-26 19:10:42 <mercenary> Then the appropriate grub/whatever to get it bootable again
2021-06-26 19:12:21 <Hello71> if you only did rm -rf /, i think testdisk/extundelete/thatothertool should work decently
2021-06-26 19:13:02 <Hello71> ext4magic
2021-06-26 19:13:21 <Ariadne> can somebody go loudly complain to #openrc
2021-06-26 19:13:22 <Ariadne> :D
2021-06-26 19:16:53 <dalias> hello71, really? will it recover names?
2021-06-26 19:17:26 <dalias> other thsn mount at reboot, no ops on fs after rm
2021-06-26 19:17:27 <Hello71> sometimes
2021-06-26 19:17:39 <Hello71> if you don't want the names then photorec
2021-06-26 19:17:52 <Hello71> but the names are usually helpful, aiui it's the main point of a filesystem
2021-06-26 19:18:03 <dalias> i imaged the partition intending to do that after getting it back running
2021-06-26 19:19:06 <dalias> but i dont really care about or want to trust recivering alpine pkg binaries
2021-06-26 19:19:13 <dalias> just data
2021-06-26 19:19:35 <dalias> so id be ok with apk fixing firat
2021-06-26 19:21:03 <Sheila> the issue with that is potentially overwriting data
2021-06-26 19:22:53 <dalias> ?
2021-06-26 19:23:15 <dalias> did you miss i said i imaged it? :)
2021-06-26 19:24:07 <Sheila> <.<
2021-06-26 19:26:34 <dalias> just to be sure, theres no idiotic trim mode by default, is there?
2021-06-26 19:29:56 <kasper81> does abuild uses default assembler with gcc for autoconf-based packages?
2021-06-26 19:31:27 <kasper81> `echo "#include <endian.h>" > test.S && gcc -c test.S` <-- with default assembler this horks a couple of errors on Alpine.
2021-06-26 19:33:32 <dalias> that errors because its not valid
2021-06-26 19:34:29 <kasper81> it is valid if we use the $other assembler :) 
2021-06-26 19:34:42 <dalias> no, if you use glibc
2021-06-26 19:35:48 <dalias> if you have asm for an arch with multiple endian options, the arch defines predef macros that indicate which
2021-06-26 19:36:07 <dalias> no need to try to include a C file to get that info
2021-06-26 19:37:11 <kasper81> ah makes sense. on debian/fedora/arch etc. it works so must be a glibc habit. i just did a quick review of libunwind riscv64 PR https://github.com/libunwind/libunwind/pull/267 and found the alpine-specific behavior.
2021-06-26 19:37:38 <kasper81> otherwise their patch worked for me (it was unused in their patch anyway)
2021-06-26 19:41:03 <ericonr> https://github.com/libunwind/libunwind/pull/267/commits/52f0fb0b45bc18bbc90706a4eb2a3944581be3dd
2021-06-26 19:41:42 <ericonr> nix is just great :)
2021-06-26 19:48:14 <kasper81> nice catch! :D 
2021-06-26 20:00:01 <mps> rhatr: did you boot riscv64 in qemu? if yes what boot loader
2021-06-26 20:11:29 <dalias> yay on from my ancient debian laptop, easier to type than phone
2021-06-26 20:12:01 <dalias> whatever this rescue disk is it's sooooo slow accessing the drive it's imaging :(
2021-06-26 20:12:38 <dalias> i love this laptop but the kb is somewhat broken -- probably should just get a new kb for it
2021-06-26 20:12:51 <dalias> classic eeepc
2021-06-26 20:13:12 <dalias> with a working kb and ssd in place of hdd i think it'd be my favorite to use
2021-06-26 20:13:45 <ikke> I have a laptop with a broken kb as well, using an external one for the time being
2021-06-26 20:13:56 <dalias> the kb breakage is amusing
2021-06-26 20:14:17 <dalias> if you slide it slightly left, keys on left side don't work. slightly right, keys on right side don't work. if you get it perfect they all work
2021-06-26 20:14:50 <dalias> vintage pre-systemd debian was actually usably fast :-p
2021-06-26 20:14:51 <mps> heh, my old eeepc keeping dust, though it is ok
2021-06-26 20:16:16 <dalias> remind me next time i get a laptop not to use any internal drives, actually
2021-06-26 20:16:38 <dalias> this would be so much less painful just pulling the usb rootfs and swapping in a new one
2021-06-26 20:17:00 <ikke> does it have emmc?
2021-06-26 20:17:11 <dalias> yes
2021-06-26 20:17:25 <ikke> ah, yeah, that's anoying
2021-06-26 20:18:06 <dalias> next laptop i want to just leave some junk install of windows on the emmc
2021-06-26 20:18:22 <dalias> pop the usb out, perfect for going thru border crossings
2021-06-26 20:20:14 <dalias> anyway
2021-06-26 20:20:33 <dalias> uhg huge time sink
2021-06-26 20:23:20 <MY-R> 
ACTION still wondering why they not making in laptops hotswap 2.5" sata bays or nvme

2021-06-26 20:23:55 <MY-R> that would take even less space than old cd/dvd drives...
2021-06-26 20:24:21 <Sheila> because user serviceability means they can't make them thinner than pancakes.
2021-06-26 20:24:43 <dalias> some can, but yeah. i'd rather just have usb anyway
2021-06-26 20:25:00 <dalias> where i dont need special hardware to hook it up to another machine
2021-06-26 20:25:29 <dalias> usb3 is ungodly fast anyway
2021-06-26 20:25:30 <Sheila> which…the contrast between my chonky T500 and my M1 MacBook Air is pretty interesting, tbh. I'd just as rather have something about half the weight of the T500 that I can actually poke the innards of if I need to, though.
2021-06-26 20:33:39 <rhatr> yes I do quite regularly actually @mps -- the boot sequence is: OpenSBI -> u-boot - GRUB
2021-06-26 20:33:55 <rhatr> GRUB is loaded as a EFI payload from u-boot EFI emulation environment
2021-06-26 20:34:43 <rhatr> You can actually stop just at OpenSBI -> u-boot -- but since Project EVE requires GRUB I figured I'll do this sequence for now (besides it allows me test -- at least somewhat -- both bootloaders)
2021-06-26 20:34:50 <mps> I tried with OpenSBI and u-boot but it fails
2021-06-26 20:34:52 <rhatr> GRUB does require a custom patch still tho
2021-06-26 20:35:11 <rhatr> https://github.com/lf-edge/eve/blob/master/pkg/grub/patches.riscv64/0000-Linux-loading-on-riscv64.patch
2021-06-26 20:35:57 <rhatr> well @mps -- Project EVE is running this sequence all the time -- so it is definitely doable -- give me an hour to do a gist for you so you can retrace my steps
2021-06-26 20:37:00 <mps> I'm not right now on the box where I test it, but u-boot loads kernel and initram and after that I get error msg about some invalid addresses
2021-06-26 20:37:54 <rhatr> well, you can try my sequence then for now (with GRUB at the end)
2021-06-26 20:38:08 <mps> ofc, will do
2021-06-26 20:38:44 <mps> btw, what is project EVE?
2021-06-26 20:39:20 <ikke> That's what Roman talked about at the conf
2021-06-26 20:40:17 <mps> I didn't watched that part because I had some private 'things' to do and can't find video later
2021-06-26 20:40:38 <danieli> yeah, i didn't find recordings either, i didn't have the opportunity to watch the conf
2021-06-26 20:48:03 <mps> rhatr: that is what I get when trying boot https://tpaste.us/JqWq
2021-06-26 20:48:49 <ikke> https://bbb.dereferenced.org/playback/presentation/2.3/75a49eebcb63d6fee8c55417ea7cc51768d86f3d-1621148096606
2021-06-26 20:49:26 <mps> ikke: thanks
2021-06-26 20:50:16 <ikke> it's not perfect, the first day we didn't realize how the recordings worked
2021-06-26 20:52:45 <clandmeter> rhatr: hi
2021-06-26 20:54:49 <clandmeter> rhatr: i wonder how you boostrapped alpine on riscv64, im having troubles with openssl and libatomic
2021-06-26 20:55:56 <rhatr> mps: that tells me you probably didn't build your SBI quite right -- but let me first confirm I can do u-boot -> kernel part
2021-06-26 20:56:32 <rhatr> clandmeter: you DO need a few additional patches on top of the current Alpine's master in order to do that -- specifically in openssl's case you need to disable intrinsics for sure 
2021-06-26 20:56:43 <rhatr> e.g:
2021-06-26 20:57:04 <clandmeter> rhatr: i think i took most of  your patches from your tree
2021-06-26 20:57:18 <mps> rhatr: I didn't built it but took one from freedesktop-sdk-master-riscv64-qemu.tar.xz
2021-06-26 20:57:20 <clandmeter> problem is most of those are bundled in a few commits
2021-06-26 20:57:28 <clandmeter> with not much explanation 
2021-06-26 20:57:54 <rhatr> clandmeter: "problem is most of those are bundled in a few commits" -- that's what I'm about to work on today and tomorrow ;-)
2021-06-26 20:58:10 <rhatr> will keep you guys posted
2021-06-26 20:58:12 <clandmeter> rhatr: most of it is already in aports
2021-06-26 20:58:20 <clandmeter> and more
2021-06-26 20:58:59 <rhatr> clandmeter: "most of it is already in aports" -- yeah -- that's what I have in mind -- rebasing my tree on top of the current master to get rid of anything that's already there
2021-06-26 20:59:00 <clandmeter> largest set of build blockers is rust
2021-06-26 20:59:32 <mps> rhatr: I get same error when following u-boot guide for riscv running in qemu i.e. with '-bios u-boot.bin' parameter invokinq qemu-system-riscv64
2021-06-26 20:59:44 <rhatr> mps: you really have to rebuild it sadly (or so it seems). E.g. here's the Project EVE's recipe (speaking of which I should probably create an alpine packages proper for it)
2021-06-26 21:00:10 <rhatr> https://github.com/lf-edge/eve/blob/master/pkg/uefi/build.sh#L11
2021-06-26 21:00:39 <rhatr> mps: make sure you use exactly the aritfacts that the above recipe mentions 
2021-06-26 21:02:01 <mps> huh, edk2 again?
2021-06-26 21:02:44 <mps> edk2 doesn't build on alpine
2021-06-26 21:02:58 <clandmeter> its probably from somehwere else
2021-06-26 21:03:02 <clandmeter> black magic :)
2021-06-26 21:03:27 <mps> python is black magic :)
2021-06-26 21:04:19 <clandmeter> rhatr: if you have time, please look into boostrap.sh and why openssl fails to find -latomic when cross compiling. i guess you somehow fixed it before. 
2021-06-26 21:04:32 <rhatr> clandmeter: that's the plan!
2021-06-26 21:05:06 <clandmeter> nice, thx. ill be here
2021-06-26 21:05:52 <clandmeter> but not now, need to spend time with the wife.
2021-06-26 21:06:46 <rhatr> clandmeter: same, but with my kid ;-)
2021-06-26 21:28:23 <dalias> anyone have time to help me with this in more detail?
2021-06-26 22:03:19 <PureTryOut> ikke: polkit-elogind is still giving BAD signatures on aarch64
2021-06-26 22:32:07 <Hello71> dalias: hm?
2021-06-26 22:46:59 <craftyguy> PureTryOut: I think the mirror might be outdated?
2021-06-26 22:47:11 <craftyguy> I had that the other day until I changed mirrors
2021-06-26 23:06:55 <dalias> fuck, what tools are available to recover data without journal?
2021-06-26 23:07:34 <dalias> i turned journal off because linux ext4 driver insisted on forcibly remounting ro and hosing the system in the process (interrupting journal writes) if the drive was 1us too slow responding to ommands
2021-06-26 23:21:52 <Hello71> photorec?
2021-06-26 23:23:19 <Hello71> this journal sounds like an uncommon problem
2021-06-26 23:27:51 <dalias> it's a kernel bug that's been present for 5+ years
2021-06-26 23:27:59 <dalias> rather an interaction of multiple bugs
2021-06-26 23:28:13 <dalias> 1. hard failing and forcing device ro on journal write error
2021-06-26 23:28:34 <dalias> 2. timing out 1us after the devices advertised max response time
2021-06-26 23:28:57 <dalias> anyway testdisk looks promising...
2021-06-26 23:34:29 <dalias> uhg testdisk sees most of the deleted stuff but is interactive. how the fuck do you just make it recover everything it can??
2021-06-26 23:49:22 <dalias> ok i found it. it's doing a rather poor job but better than nothing
2021-06-27 00:01:05 <superduck> where is the package function from this `+ fakeroot -- /usr/bin/abuild package prepare_subpackages prepare_language_packs prepare_package create_apks`
2021-06-27 00:01:28 <Hello71> i think testdisk's ext4 recovery is basically ext2, but conveniently that's basically what you have
2021-06-27 00:01:37 <dalias> yep
2021-06-27 01:05:51 <superduck> @ikke: found my issue, I've got a custom readlink implementation that broke abuild.
2021-06-27 01:44:15 <dalias> apk fix running, 19/1276 ...
2021-06-27 01:44:25 <dalias> fun...
2021-06-27 01:49:10 <dalias> uhg this is going to take forever to clean up well
2021-06-27 02:03:54 <dalias> @ #280..
2021-06-27 02:05:18 <dalias> it's going to take like 2 or 3 days to have things in basic working order (self-built stuff reinstalled, etc)
2021-06-27 02:06:23 <dalias> pretty sure i didnt lose any irreplacable data of value, but did lose a bunch of random packratted files and some in-progress restorations of data from deteriorated optical media that i'm mad about...
2021-06-27 02:07:45 <dalias> hah actually...
2021-06-27 02:07:58 <dalias> it looks like e2fsck put all the remaining missing stuff in lost+found
2021-06-27 02:08:02 <dalias> much of it still with names
2021-06-27 03:48:45 <rhatr> clandmeter: just reproduced your -latomic issue (I think it is new actually) and about to submit an MR
2021-06-27 03:50:43 <rhatr> mps: it appears that the SBI bundled with qemu is no good. Curiously enough, while we can re-build u-boot as part of Alpine, I actually don't know what to do about SBI (since historically Alpine relied on qemu shipping the correct bits)
2021-06-27 03:51:12 <rhatr> I suppose I can introduce standalone SBI Alpine package just in case...
2021-06-27 03:51:19 <rhatr> Would love to hear what others think
2021-06-27 04:11:41 <rhatr> clandmeter: actually I may need to dig a bit more. The fix appears to be:
2021-06-27 04:11:51 <rhatr> diff --git a/main/openssl/APKBUILD b/main/openssl/APKBUILD
2021-06-27 04:11:51 <rhatr> index 1cf037ff..d664fc52 100644
2021-06-27 04:11:51 <rhatr> --- a/main/openssl/APKBUILD
2021-06-27 04:11:53 <rhatr> +++ b/main/openssl/APKBUILD
2021-06-27 04:11:55 <rhatr> @@ -75,7 +75,7 @@ build() {
2021-06-27 04:11:57 <rhatr>  		--libdir=lib \
2021-06-27 04:11:59 <rhatr>  		--openssldir=/etc/ssl \
2021-06-27 04:12:01 <rhatr>  		shared no-zlib $_optflags \
2021-06-27 04:12:03 <rhatr> -		no-async no-comp no-idea no-mdc2 no-rc5 no-ec2m \
2021-06-27 04:12:05 <rhatr> +		no-asm no-threads no-async no-comp no-idea no-mdc2 no-rc5 no-ec2m \
2021-06-27 04:12:07 <rhatr>  		no-sm2 no-sm4 no-ssl2 no-ssl3 no-seed \
2021-06-27 04:12:09 <rhatr>  		no-weak-ssl-ciphers \
2021-06-27 04:12:11 <rhatr>  		$CPPFLAGS $CFLAGS $LDFLAGS -Wa,--noexecstack
2021-06-27 04:12:19 <rhatr> but there's something I don't get as to why it doesn't show up in a non-cross build
2021-06-27 04:56:57 <rhatr> And FWIW -- it turns out that libretls also has cross issues -- this is sure going to delay MR
2021-06-27 06:39:16 <ikke> superduck: pph. that's nasty
2021-06-27 07:37:23 <mps> good morning
2021-06-27 07:37:45 <mps> hmm, looks like rhatr left channel
2021-06-27 08:13:35 <omni> !22648
2021-06-27 11:19:47 <clandmeter> rhatr, if you can read backlog, looks like its no-threads that requires libatomic, no-asm is already set per default
2021-06-27 11:24:02 <clandmeter> our cross compiled gcc is build without libatomic so thats why it fails to build openssl
2021-06-27 11:24:43 <clandmeter> so the options are, 1 enable libatomic on gcc when doing cross, or set no-threads for cross version of openssl.
2021-06-27 11:26:29 <clandmeter> option 1 seems to fail for me
2021-06-27 11:47:11 <clandmeter> Ariadne: we killed libtls-standalone in favor of libretls?
2021-06-27 12:07:42 <nmeum> is anyone other than myself still using xdm? :)
2021-06-27 12:08:56 <valerius> I use the OpenBSD fork of it on OpenBSD if that counts
2021-06-27 12:15:14 <nmeum> looking for someone to review !22656 so no :p
2021-06-27 12:49:48 <dalias> if the arch needs libatomic, that needs to be in the cross build. however..
2021-06-27 12:50:07 <dalias> i think gcc trying to link it whenever -pthread is passed is just a bug
2021-06-27 12:50:20 <dalias> and should be patched out of specs
2021-06-27 12:51:01 <dalias> libatomic should not be needed for anything
2021-06-27 12:53:53 <Ariadne> clandmeter: yes
2021-06-27 13:07:24 <dalias> why does option 1 fail?
2021-06-27 13:08:02 <dalias> im saying its not needee (just fix the broken spec or even drop in an empty libatomic.a) but it shouldnt fail
2021-06-27 13:08:17 <dalias> failure suggedts something is wrong
2021-06-27 13:12:03 <insep> omni: do you know how to make ocamlfind find libraries that are built with dune? ocaml-integers is built with dune, but it doesn't install whatever files ocamlfind needs, which prevents ocaml-ctypes from building
2021-06-27 13:12:29 <insep> also what's good package name for https://github.com/janestreet/ocaml-compiler-libs, ocaml-compiler-libs-repackaged?
2021-06-27 13:15:17 <nmeum> mps: the recent man-pages update seems to have caused the removal of several posix man pages
2021-06-27 13:15:22 <nmeum> for example test(1) et cetera
2021-06-27 13:20:26 <nmeum> actually, it looks like non of the posix man pages are installed anymore
2021-06-27 13:24:02 <mps> nmeum: ah, right
2021-06-27 13:24:24 <mps> coretutils install could be 'culprit'
2021-06-27 13:25:34 <nmeum> nah, I think the man-pages project changed their installation procedure and copying the posix man-pages into the man-pages build directory is no longer sufficient
2021-06-27 13:25:36 <mps> will look later, busybox install didn't worked with new release so I added coreutils. probably patch will be needed to use busybox install
2021-06-27 13:26:13 <nmeum> ok :)
2021-06-27 13:26:30 <nmeum> (doubt that this is coreutils related though
2021-06-27 13:27:15 <mps> will look later in evening, I'm to busy now
2021-06-27 13:27:19 <mps> too*
2021-06-27 14:23:14 <nmeum> take your time, it's not urgent
2021-06-27 15:44:05 <dalias> ok apk fix did its thing but  now i have to pull together backups :/
2021-06-27 15:57:55 <PureTryOut> Is riscv64 stuck or just slow again?
2021-06-27 15:59:28 <ikke> seems stuck
2021-06-27 16:09:01 <clandmeter> Kick it
2021-06-27 16:09:50 <clandmeter> algitbot: kick master
2021-06-27 16:12:28 <PureTryOut> Oh that's a thing? What exactly does it do?
2021-06-27 16:18:35 <mps> nmeum: what you think about this changes for man-pages https://tpaste.us/6WQn
2021-06-27 16:19:00 <mps> this way all posix pages are in place, as far as I see
2021-06-27 16:45:24 <ikke> Ooh, I've been able to reproduce the rsync issue
2021-06-27 16:47:19 <ikke> https://www.truenas.com/community/threads/rsync-resuming-an-interrupted-transfer-and-delay-updates.25588/
2021-06-27 16:47:42 <nmeum> mps: can't we just use the install target of the Makefile provided by posix-man-pages itself? instead of moving them manually that is
2021-06-27 16:48:02 <nmeum> also: I would just depend on coreutils instead of patching the makefile install(1) invocation, I think
2021-06-27 16:49:52 <nmeum> `make DESTDIR="$pkgdir" -C "$srcdir"/$pkgname-posix-$_posixver install` should suffice I guess
2021-06-27 16:50:04 <mps> nmeum: I will repeat now my proposal from year or two ago: make man-pages-posix separate package
2021-06-27 16:50:34 <ikke> sigh
2021-06-27 16:50:42 <mps> that would be cleanest 'solution' imo
2021-06-27 16:50:45 <ikke> you need to send an email to request an account for rsync
2021-06-27 16:55:27 <nmeum> mps: let's just fix the existing aport for now :p
2021-06-27 16:56:13 <nmeum> it would actually be neat if main/docs would depend on man-pages then it doesn't really matter if man-pages-posix is separate package or not
2021-06-27 16:57:47 <ikke> or install_if="docs"
2021-06-27 17:04:24 <mps> nmeum: what you mean by 'let's just fix the existing aport for now'? to just push my proposal?
2021-06-27 17:05:09 <mps> (though I will talk with maintainer when he come back next week about splitting man-pages-posix)
2021-06-27 17:06:11 <nmeum> if you split man-pages-posix please consider making main/docs depend on man-pages-posix and man-pages to make it easier for users to actually discover/install these man pages
2021-06-27 17:07:04 <mps> np, and we will discuss this here when ncopa come back
2021-06-27 17:07:24 <nmeum> mps: maybe improve your proposal by using the install target of the provided posix-man-pages Makefile or if it works just push your stuff as is and I can clean it up a bit later. either way is fine with me
2021-06-27 17:08:25 <mps> yes, also I thought to use 'make install' from man-pages-posix dir, but current patch looks least intrusive to me
2021-06-27 17:18:30 <Hello71> ikke: https://github.com/WayneD/rsync/issues/192
2021-06-27 17:18:59 <nmeum> mps: by using the provided makefile install target we can ensure that we don't skip installation of any posix man pages. it's imho more foolproof
2021-06-27 17:20:24 <ikke> Hello71: interesting
2021-06-27 17:37:41 <mps> nmeum: tested you proposal `make DESTDIR="$pkgdir" -C "$srcdir"/$pkgname-posix-$_posixver install` and I got 'usr/share/man/man1p/test.1p.gz'
2021-06-27 17:37:53 <mps> notice 'man1p' is dir name
2021-06-27 17:39:12 <nmeum> hm. isn't that technically more correct even? Using /usr/share/man/man1p/ instead of /usr/share/man/man1/? 🤔
2021-06-27 17:39:41 <mps> it is, but we then have to 'teach' mandoc to search these dirs
2021-06-27 17:40:00 <nmeum> hehe that's actually a problem I had on my todo list for a long time
2021-06-27 17:40:19 <mps> i remember that this was issue about 3 years ago
2021-06-27 17:41:03 <nmeum> man-pages-5.11 uses /usr/share/man/man1/test.1p.gz, so if your version install to that directory just push it
2021-06-27 17:41:11 <nmeum> we can address the 1 vs 1p section thing later
2021-06-27 17:41:16 <mps> well, we can add '/etc/mandirs' and add these extra dirs there, but ...
2021-06-27 17:41:21 <nmeum> naaah
2021-06-27 17:41:26 <nmeum> let's not get ahead of ourselves here
2021-06-27 17:41:32 <nmeum> fix one problem at a time :)
2021-06-27 17:41:41 <mps> yes, agree
2021-06-27 17:42:24 <mps> though I have in my shell rc script added mandirs for some paths
2021-06-27 17:44:48 <mps> !22663
2021-06-27 17:45:42 <mps> btw, what is llvm12 status? zig 0.8.0 needs it to build
2021-06-27 17:45:57 <mps> what is with*
2021-06-27 17:49:49 <Hello71> 12.0.1 is out "soon"
2021-06-27 17:51:20 <mps> Hello71: I mean, what is its status in alpine
2021-06-27 17:53:05 <nmeum> !20759 Cogitri started working on it, it seems
2021-06-27 17:54:12 <mps> good, it is not forgotten then
2021-06-27 18:01:01 <Hello71> mps: i know, i mean not much point to push llvm12 and break everything when next version is out soon
2021-06-27 18:01:13 <Hello71> better wait to push 12.0.1 and break everything in different way
2021-06-27 18:12:30 <mps> I'm not in a hurry, just curious. And would like to try to build new zig
2021-06-27 18:35:43 <Cogitri> nmeum: Yup, but tests broke pretty bad with 12.0.0
2021-06-27 19:30:47 <clandmeter> maxice8: whats up with 5609a33370dcf005c7f17b2c8bd06f31dc6a83b0 ?
2021-06-27 19:31:57 <clandmeter> looks like that commit broke fakeroot
2021-06-27 19:38:42 <Newbyte[m]> can I do an install_if that installs a package if either package A or package B is installed?
2021-06-27 20:02:27 <nmeum> Newbyte[m]: no. install_if can only do logical conjunctions (i.e. A and B) are installed, not disjunctions (i.e. A or B) are installed
2021-06-27 20:03:30 <nmeum> a workaround might be having A and B provide X and then using install_if=X but I am not too familiar with provides myself
2021-06-27 20:14:49 <yyp> Hi, would it make sense to update linenoise aport to git version? There haven't been any releases in a while. And there are no breaking changed in the API to prevent doing this
2021-06-27 20:15:01 <yyp> *changes
2021-06-27 20:17:04 <ikke> Did you ask upstream for a release?
2021-06-27 20:17:51 <yyp> There was an issue, but no response from the maintainer: https://github.com/antirez/linenoise/issues/145
2021-06-27 20:21:55 <ikke> so the last release is from 2015, and that's the version we have in aports
2021-06-27 20:41:24 <nmeum> linenoise is generally very badly maintained (unfourtunatly)
2021-06-27 22:42:20 <kasper81> hi, the `DESCRIPTION` file in aarch64 archive (http://dl-cdn.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz) shows the version like `v3.14.0-1057-ga8f21ed06e`. but the one in ppc64le shows `v3.14.0_rc2-42-g4912f35331`. isn't rc2 quite old? 
2021-06-27 22:58:25 <Hello71> yes, it's not updating properly
2021-06-28 00:17:10 <maxice8> clandmeter: oops, my bad
2021-06-28 01:21:36 <kasper81> yes all the ppc64le packages, which were blocked by stuck java-related package, were built. Jun 11 - Jun 27. however, the new manifest wasn't published.
2021-06-28 01:22:53 <kasper81> so yes it is 17th day of waiting for my thing.. so it's been a longer patience period than the vacation i have gotten for this season :) 
2021-06-28 05:10:47 <mps> everything/anything IBM related should be removed from free software, ppc64le from alpine
2021-06-28 05:46:10 <omni> looks like ppc64le hasn't got the latest nodejs https://pkgs.alpinelinux.org/packages?name=nodejs&branch=edge
2021-06-28 10:26:51 <donoban> Hi, telegram desktop has a new dependency https://github.com/desktop-app/rnnoise which seems a simple mirror of https://github.com/xiph/rnnoise
2021-06-28 10:30:01 <donoban> probably using the upstream version should be better but it doesn't has any realease/tag so I suppose that tg-ap is some kind of "stagging" version
2021-06-28 10:30:28 <donoban> I don't know if create a new package or try to build it within telegram-desktop package
2021-06-28 10:31:08 <donoban> or just kindly disabling this new feature :\
2021-06-28 10:36:06 <afontain[m]> https://gitlab.xiph.org/xiph/rnnoise
2021-06-28 10:36:14 <afontain[m]> ^ upstream
2021-06-28 10:39:07 <afontain[m]> I think it's usually better to package the upstream version unless you have got good reasons?
2021-06-28 10:41:08 <donoban> yes I think that so, but I don't like to package something without any version control :\ I feel that disabling it is the cleanest option
2021-06-28 10:41:50 <donoban> uhM
2021-06-28 10:42:04 <donoban> wait, they are on gitlab
2021-06-28 10:42:20 <Newbyte[m]> What might be causing this: https://gitlab.alpinelinux.org/Newbyte/aports/-/jobs/425156#L2624
2021-06-28 10:44:11 <donoban> well, the gitlab repo has no release/tags too
2021-06-28 10:44:35 <Newbyte[m]> donoban: here's how it works: the telegram desktop developer finds a bug or something he doesn't like in a library. he then makes a fork of it and never upstreams his fixes
2021-06-28 10:44:55 <donoban> lol
2021-06-28 10:45:12 <Newbyte[m]> I'm not kidding
2021-06-28 10:45:37 <donoban> so he created a fork for just https://github.com/desktop-app/rnnoise/commit/20e9c734dc746e076961984742b9f8d109b7b399 ?
2021-06-28 10:45:49 <Newbyte[m]> Yeah, probably
2021-06-28 10:45:58 <Newbyte[m]> I can try to ask him about if
2021-06-28 10:45:59 <Newbyte[m]> it*
2021-06-28 10:46:25 <donoban> anyway I feel that this funciontally is pretty marginal
2021-06-28 10:47:10 <Newbyte[m]> yeah
2021-06-28 10:47:18 <Newbyte[m]> and it's just for macOS and Windows anyway?
2021-06-28 10:47:24 <Newbyte[m]> I mean, the patches
2021-06-28 10:47:42 <donoban> yes it seems
2021-06-28 10:48:24 <Newbyte[m]> I pinged him. I'll ping you if he responds
2021-06-28 10:49:21 <donoban> and there are opened PR for that
2021-06-28 10:49:24 <donoban> https://github.com/xiph/rnnoise/pull/88
2021-06-28 10:49:38 <donoban> or for something similar
2021-06-28 10:50:07 <donoban> what did you tell him? if using the upstream for linux is safe?
2021-06-28 10:51:16 <Newbyte[m]> Here's what he said so far: "Are there patches?"
2021-06-28 10:51:52 <Newbyte[m]> It doesn't seem like rnnoise is particularly actively maintained 
2021-06-28 10:52:07 <donoban> >4years project without any version release
2021-06-28 10:52:14 <donoban> it seems more like an experiment
2021-06-28 10:53:30 <donoban> well it is really something unlikely to break things
2021-06-28 10:53:50 <Newbyte[m]> Yeah
2021-06-28 10:54:05 <donoban> archlinux builds it from upstream
2021-06-28 10:54:07 <donoban> https://github.com/archlinux/svntogit-community/blob/packages/rnnoise/trunk/PKGBUILD
2021-06-28 10:55:15 <Newbyte[m]> 
ACTION uploaded an image: (49KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/uezsAjtMMyWXSrhNFeBXMbde/image.png >

2021-06-28 10:55:21 <Newbyte[m]> There's what he said
2021-06-28 10:56:15 <donoban> ok, thanks Newbyte[m] 
2021-06-28 10:57:28 <donoban> seeing arch package, it only contains .so files
2021-06-28 10:57:38 <donoban> should it be called *-lib?
2021-06-28 11:33:33 <nmeum> does anyone have strong opinions on !22657 otherwise I would just merge this later today
2021-06-28 13:37:46 <orbea> nmeum: maybe non-issue, but using a glob and not quoting $script seems iffy
2021-06-28 13:38:24 <nmeum> orbea: yeah, but that's a separate "issue"
2021-06-28 13:38:35 <orbea> fair enough
2021-06-28 13:38:39 <nmeum> the for loop also does not unset $script currently
2021-06-28 13:39:04 <nmeum> > $ env -i sh -l
2021-06-28 13:39:07 <nmeum> > $ echo $script
2021-06-28 13:39:10 <nmeum> > /etc/profile.d/vte.sh
2021-06-28 13:39:13 <nmeum> :)
2021-06-28 13:39:22 <nmeum> anyway, I will improve that part of the profile later
2021-06-28 13:45:00 <clandmeter> Cogitri: boostrap riscv64 should be sort of workable
2021-06-28 13:45:44 <clandmeter> rust is added to the list of pkgs to bootstrap, but it will fail after stateX (not sure which stage it is or how it works)
2021-06-28 13:46:50 <clandmeter> dalias: so i need to patch gcc to build openssl without libatomic?
2021-06-28 13:47:05 <clandmeter> when no-threads is unset
2021-06-28 13:47:39 <clandmeter> s/stateX/stageX
2021-06-28 13:47:40 <alpine-meetbot> clandmeter meant to say: rust is added to the list of pkgs to bootstrap, but it will fail after stageX (not sure which stage it is or how it works)
2021-06-28 15:19:45 <Newbyte[m]> I'll ask again: What might be causing this: https://gitlab.alpinelinux.org/Newbyte/aports/-/jobs/425156#L2624
2021-06-28 15:21:10 <ikke> Newbyte[m]: rsync issues from our builders to the master mirror
2021-06-28 15:38:04 <dalias> clandmeter, no, you (I think) need to patch gcc not to add -latomic whenever -pthread appears
2021-06-28 15:38:11 <dalias> because it's nonsense to do that
2021-06-28 15:38:37 <dalias> look at gcc -dumpspecs and see where it's coming from
2021-06-28 15:39:23 <dalias> basically AIUI on riscv gcc uses libatomic to implement the __atomic and __sync builtins for sizes other than 4 or 8
2021-06-28 15:39:38 <dalias> and uses -pthread as a bogus heuristic for "the program might want atomics"
2021-06-28 15:40:24 <dalias> however nothing except code that's manually using weird-size atomic ops will ever need libatomic, and whether it does that is completely orthononal to -pthread
2021-06-28 15:40:31 <dalias> which is the same situation as on most other archs
2021-06-28 15:40:38 <dalias> there's no reason for riscv to be treating this special
2021-06-28 15:41:09 <Cogitri> clandmeter: Oh great, thanks. I’ll give that a go soon :)
2021-06-28 15:41:30 <clandmeter> dalias: we are shipping this patch with gcc, not sure its related to this issue https://git.alpinelinux.org/aports/tree/main/gcc/0040-configure-Add-enable-autolink-libatomic-use-in-LINK_.patch
2021-06-28 15:44:21 <dalias> that looks like it's conditioned on whether libatomic was built
2021-06-28 15:44:32 <dalias> i think the problem is just that you're not removing the special case for %{pthread
2021-06-28 15:45:55 <dalias> see gcc/config/riscv/linux.h
2021-06-28 15:45:55 <dalias> #define LIB_SPEC GNU_USER_TARGET_LIB_SPEC \
2021-06-28 15:45:56 <dalias>   " %{pthread:" LD_AS_NEEDED_OPTION " -latomic " LD_NO_AS_NEEDED_OPTION "}"
2021-06-28 15:46:06 <dalias> just remove that
2021-06-28 15:46:09 <dalias> it's wrong
2021-06-28 15:48:30 <dalias> the alpine solution is much more correct and obsoletes this incorrect heuristic
2021-06-28 15:48:49 <dalias> but if you want a quick and dirty solution
2021-06-28 15:49:18 <dalias> ar rc $sysroot/lib/libatomic.a
2021-06-28 15:50:24 <dalias> *sigh* i had to dig out a version of openssh-client from an older alpine to be able to login because of the sha1 breakage with dropbear :/
2021-06-28 15:50:30 <dalias> is that fixed yet on dropbear side?
2021-06-28 15:54:38 <kasper81> could someone review/merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22382. nim is currently in a limbo state (it is too new and its package manager nimble is too old)
2021-06-28 15:55:17 <kasper81> i'll move it to community after that (next to where nim is)
2021-06-28 15:55:59 <ikke> maybe you can ask jirutka to take over maintainership
2021-06-28 16:03:25 <kasper81> ok. you mean separate to the MR or is it a precondition to merge the MR?
2021-06-28 16:04:51 <kasper81> asking because jirutka is not replying for a few days. maybe he is busy.
2021-06-28 16:05:23 <ikke> No, certainly not a pre-condition
2021-06-28 16:06:36 <superduck> when running `abuild -r` I get `ERROR: APKINDEX.tar.gz: UNTRUSTED signature` my pub key is in /etc/apk/keys, so not sure how to resolve that, any suggestions?
2021-06-28 16:06:51 <ikke> superduck: did you rename the key?
2021-06-28 16:07:17 <nmeum> kasper81: just ping him in the gitlab issue and explain that nim is broken without this MR, jirutka is not in the irc
2021-06-28 16:07:55 <superduck> ikke: probably...how's the truncated keyid generated and are cv25519 keys supported as opposed to rsa?
2021-06-28 16:07:57 <ikke> I just pinged him
2021-06-28 16:09:02 <Ariadne> dalias: -oKexAlgorithms=+diffie-hellman-group-exchange-sha1
2021-06-28 16:09:50 <dalias> ah
2021-06-28 16:11:01 <nmeum> superduck: no, apk does not support elliptic curves presently
2021-06-28 16:11:04 <nmeum> https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/package.c#L538
2021-06-28 16:14:47 <dalias> *sigh* most annoying thing i'm missing at the moment is firefox cookie store :/
2021-06-28 16:15:01 <dalias> storage/ dir is there but there's some sqlite index of it that's lost
2021-06-28 16:15:06 <dalias> >_<
2021-06-28 16:15:14 <mps> dalias: as Ariadne wrote. I have this in .ssh/config for an old openwrt router
2021-06-28 16:15:19 <mps> 'KexAlgorithms +diffie-hellman-group1-sha1'
2021-06-28 16:15:24 <dalias> mps, thanks. will do
2021-06-28 16:16:14 <dalias> excellent, that works
2021-06-28 16:16:43 <dalias> i really need to get this fixed dropbear-side tho :/
2021-06-28 16:16:48 <dalias> sha1 is not safe for future
2021-06-28 16:17:09 <kasper81> ikke: i've sent him an email for maintinership of nim and nimble packages.
2021-06-28 16:17:16 <dalias> and nobody seems to care because "use ecc lol nist curves are safe lol"
2021-06-28 16:19:16 <superduck> ikke: I stripped the keyid off the end of the key, how do I regenerate that part of the key filename?
2021-06-28 16:19:33 <superduck> nmeum: thanks for the link to the package.c :)
2021-06-28 16:19:34 <ikke> check ~/.abuild
2021-06-28 16:21:33 <superduck> ikke: I'm trying to store the private key in gopass and override the PACKAGER_PRIVKEY and PACKAGER_PUBKEY, and I think the missing part now is the generated keyid to make it all happy for the pubkey stored in /etc/apk/keys.
2021-06-28 16:21:44 <mps> dalias: yes, I really dislike when someone wants to 'protect me' by removing options I want to use
2021-06-28 16:22:12 <ikke> superduck: the exact name does not matter, the name of the private key has to match the public key
2021-06-28 16:22:45 <ikke> <name>.rsa, <name.rsa.pub>
2021-06-28 16:23:32 <kasper81> i understood the difference between Standard and Extended versions of Alpine Linux is that Extended includes AMD and Intel microcodes. but the size is 5 times larger. is it normal?
2021-06-28 16:23:34 <nmeum> does dropbear not support ed25519?
2021-06-28 16:24:12 <dalias> mps, it really does need to be removed. but the lack of coordination with other implementations to fix the problem was very bad
2021-06-28 16:24:13 <superduck> ikke: guessing /dev/stdin isn't propagated to `$openssl dgst -sha1 -sign "$privkey" -out "$sig" "$i"` 
2021-06-28 16:24:24 <kasper81> i was looking for Standard+<just the microcodes for Intel> so i can then install it on a laptop along with the packages i need on top.
2021-06-28 16:24:33 <superduck> nmeum: yes it does now
2021-06-28 16:24:43 <dalias> openssh folks should have authored a patch to dropbear to add support for the modern replacement and given a grace period
2021-06-28 16:24:44 <superduck> nmeum: keys aren't auto-generated, but it does support that now on alpine
2021-06-28 16:25:30 <ikke> kasper81: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/mkimg.standard.sh#L24
2021-06-28 16:25:47 <mps> I disagree, I have old openwrt router which can't be upgraded and it is in isolated and safe environment, so I need sha1, else have to buy new router
2021-06-28 16:25:51 <dalias> nmeum, it does but that's a recent development and requires rekeying
2021-06-28 16:26:26 <dalias> they need to patch it so rsa keys continue to work (by using the modern handshake with rsa keys rather than the legacy sha1 based one)
2021-06-28 16:26:28 <ikke> kasper81: it includes a lot more packages (+dependencies)
2021-06-28 16:27:15 <ikke> superduck: abuild stores the keyname in the package, so apk will look for that keyname in /etc/apk/keys
2021-06-28 16:27:47 <superduck> ikke: :(
2021-06-28 16:28:19 <superduck> so there's no support for signing keys that don't reside physically on disk for apk signing yet.
2021-06-28 16:28:46 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild-sign.in#L25
2021-06-28 16:28:53 <kasper81> ikke: thanks for the link. maybe a Standard+ breakpoint edition is in order, unless it (500+MB) is really the bare minimum to boot from RAM.
2021-06-28 16:33:01 <Ariadne> kasper81: not all of those packages actually get installed at boot time
2021-06-28 16:33:06 <Ariadne> they are just available for install
2021-06-28 16:33:55 <ikke> superduck: it appears so, yes
2021-06-28 16:34:37 <ikke> superduck: maybe a named pipe?
2021-06-28 16:36:07 <superduck> ikke: that's...a thought gotta write to ${XDG_RUNTIME_DIR}, but I think it'll work
2021-06-28 16:38:59 <kasper81> Ariadne: ah, i guess it helps only the offline/no-network scenarios? in which case if we could decouple the extras/good-to-haves as a separate archive (which consumer can download and include at the time of burning the ISO) that will strip away couple of hundred MBs from extended image.
2021-06-28 16:39:27 <Ariadne> kasper81: seems pointless
2021-06-28 16:39:39 <Ariadne> you can do that yourself, using `apk fetch` and abuild-sign
2021-06-28 16:41:07 <kasper81> for most people internet is available so i think most are not benefiting from extra baggage in extended. (unless i am missing some important usecase)
2021-06-28 16:41:27 <Ariadne> you could just ask that we add the microcode package to the standard ISO
2021-06-28 16:41:58 <Ariadne> there is no need to declare war on an ISO you don't care about
2021-06-28 16:42:47 <Ariadne> sorry, i am in a grumpy mood today because of reasons.
2021-06-28 16:43:19 <ikke> Something to do with a green fruit?
2021-06-28 16:43:26 <Ariadne> yeah
2021-06-28 16:43:28 <kasper81> :) 
2021-06-28 16:44:11 <Ariadne> anyway, i think adding the intel-microcode and amd-microcode to the base ISO makes sense
2021-06-28 16:44:30 <Ariadne> can you open a bug requesting that?
2021-06-28 16:45:22 <kasper81> sure
2021-06-28 17:07:51 <ikke> huh, what do you mean with standard not being bootable?
2021-06-28 17:13:54 <mercenary> cccccgbbghhk427888
2021-06-28 17:14:51 <mercenary> sorry
2021-06-28 17:25:59 <superduck> ikke: I leave you this beauty: alias abuild="exec 3<> \"\${XDG_RUNTIME_DIR}/abuild/\${EMAIL}.rsa\" ; gopass cat abuild/${USER} > \"\${XDG_RUNTIME_DIR}/abuild/\${EMAIL}.rsa\" ; PACKAGER_PRIVKEY=\"\${XDG_RUNTIME_DIR}/abuild\${EMAIL}.rsa\" abuild"
2021-06-28 17:29:41 <Hello71> but... you're not even using 3?
2021-06-28 17:31:44 <Hello71> ikke: doesn't dropbear support curve25519
2021-06-28 17:32:04 <Hello71> wait, never mind
2021-06-28 17:32:47 <Hello71> also i didn't even highlight the right person, i meant dalias 
2021-06-28 17:35:29 <superduck> Hello71: the latest version of dropbear supports curve25519, it does not generate a key by default in the init scripts.
2021-06-28 17:42:39 <ikke> mercenary: I hope that was not you password :P
2021-06-28 17:43:03 <mercenary> ikke: a very temporary one, you might say
2021-06-28 17:43:35 <dalias> hello71, it does. see above
2021-06-28 17:43:36 <mercenary> (i.e. I moved PC, and accidentally touched OTP thingy)
2021-06-28 17:43:57 <ikke> ah, right
2021-06-28 17:43:57 <dalias> before 25519, switching to ecc was a non-starter
2021-06-28 17:44:02 <ikke> so not even a password
2021-06-28 17:44:37 <dalias> now it's viable, but you shouldn't have to change keys/algorithms just because dropbear has a bad handshake (and doesn't support the existing good handshake) for your existing keys
2021-06-28 17:49:50 <tiotags> ikke you reviewed my merge request some time ago, can it be put in alpine ?
2021-06-28 17:53:39 <ikke> Yes, hold on, let me fix the branch for you
2021-06-28 17:54:25 <tiotags> I stil don't understand what I did
2021-06-28 17:54:59 <ikke> you committed on master and pushed that. By default, the master branch is protected, so it cannot be rebased
2021-06-28 17:56:15 <tiotags> I have to name the branch something else, is that what you're saying
2021-06-28 17:57:11 <ikke> tiotags: typically, you create a new branch on top of master (generally, the one from alpine/aports
2021-06-28 18:01:12 <tiotags> I'm missing information, I just forked alpine/aports in the gitlab web gui and then cloned my forked master. after that I should have brached ? or before or when
2021-06-28 18:01:29 <tiotags> I don't really understand git that well, sorry
2021-06-28 18:01:37 <ikke> After you cloned it, then you create a new branch
2021-06-28 18:02:09 <tiotags> ok, can I do that now
2021-06-28 18:02:41 <tiotags> by that I mean create a new merge request
2021-06-28 18:03:09 <ikke> no need
2021-06-28 18:09:36 <ikke> tiotags: I've rebased your branch now (and squashed the two newer commits into the first one)
2021-06-28 18:09:45 <tiotags> ty
2021-06-28 18:09:55 <tiotags> how do you do that ?
2021-06-28 18:11:49 <kasper81> `git rebase -i HEAD~3` then change `pick` to `f` on second and third lines, close the editor and `git push -f`
2021-06-28 18:11:59 <ikke> I fetched the branch from your repo, then ran git rebase -i master (I've called the branch differently locally)
2021-06-28 18:12:19 <ikke> Oh, and I've unprotected your master branch
2021-06-28 18:13:59 <ikke> merged
2021-06-28 18:15:00 <tiotags> thank you kasper81 and ikke
2021-06-28 18:15:15 <tiotags> wow, does that mean what I think it means
2021-06-28 18:15:32 <tiotags> wow
2021-06-28 18:15:35 <ikke> the builders will pick it up for building, and it will apear in the testing repo soon
2021-06-28 18:15:42 <tiotags> thank you ikke
2021-06-28 18:16:39 <ikke> tiotags: so now, you should do this:
2021-06-28 18:16:44 <tiotags> I assume I have to wait for a release to use it ? or is there a git image of alpine
2021-06-28 18:16:48 <tiotags> yes
2021-06-28 18:17:03 <ikke> git remote add upstream https://gitlab.alpinelinux.org/alpine/aports.git
2021-06-28 18:17:23 <ikke> tiotags: it will be available in edge/testing
2021-06-28 18:17:40 <ikke> to be part of a release, it will need to be moved to community
2021-06-28 18:24:13 <tiotags> do I remove the old remote ?
2021-06-28 18:31:05 <ikke> no
2021-06-28 18:31:09 <ikke> you need both
2021-06-28 18:31:18 <ikke> you fetch the latest master from upstream
2021-06-28 18:31:24 <ikke> and you push your branches to origin
2021-06-28 18:34:08 <tiotags> I think I finally understand
2021-06-28 18:34:29 <tiotags> thank you for being patient with me
2021-06-28 18:44:06 <ikke> no worry
2021-06-28 18:44:44 <tiotags> it's alive ikke
2021-06-28 18:45:22 <tiotags> now if I could add fcgi and fix some bugs it will be just like a real webserver
2021-06-28 18:54:21 <kasper81> during setup-alpine, we can't connect to a hidden/unbroadcasted wireless network: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10482. any chance this gets fixed?
2021-06-28 19:06:00 <Hello71> tbf setup-interfaces kinda sucks in general
2021-06-28 19:06:42 <Hello71> hidden networks also suck
2021-06-28 19:07:48 <Hello71> it's useless while you're connected, and even if you aren't it's dubious
2021-06-28 19:08:27 <PureTryOut> riscv64 builder seems to be stuck again
2021-06-28 19:09:26 <ikke> hmm, inkscape
2021-06-28 19:09:31 <ikke> been working on that for a while
2021-06-28 19:09:44 <ikke> and anoyingly, strace does not work
2021-06-28 19:09:57 <ikke> one process is using 100% cpu
2021-06-28 19:10:16 <ikke> [ 42%] Building CXX object src/CMakeFiles/inkscape_base.dir/live_effects/lpe-tangent_to_curve.cpp.o
2021-06-28 19:10:20 <kasper81> if other distros are installed with hidden network, why not alpine. it's not an intentional decision and "hidden networks suck" is not a very helpful argument in the context..
2021-06-28 19:10:39 <ikke> PureTryOut: it's still continuing
2021-06-28 19:10:53 <ikke> PureTryOut: just single core
2021-06-28 19:11:13 <ikke> [ 42%] Building CXX object src/CMakeFiles/inkscape_base.dir/live_effects/lpe-taperstroke.cpp.o
2021-06-28 19:11:20 <PureTryOut> Ok just slow then
2021-06-28 19:11:30 <ikke> PureTryOut: can you check why it's just using a single core?
2021-06-28 19:11:30 <PureTryOut> Let's give it a night 😛
2021-06-28 19:12:15 <PureTryOut> Well because the APKBUILD has `-j1` said
2021-06-28 19:12:17 <PureTryOut> No clue why
2021-06-28 19:12:19 <PureTryOut> *set
2021-06-28 19:12:29 <ikke> right, I had a suspicion
2021-06-28 19:12:43 <ikke> That's going to take a while
2021-06-28 19:12:47 <PureTryOut> 
ACTION  < https://matrix.org/_matrix/media/r0/download/matrix.org/YtbTGKPkgPUmQeamwzGRjqfT/message.txt >

2021-06-28 19:12:53 <PureTryOut> e8: ☝️ not ready how?
2021-06-28 19:13:10 <ikke> d266ebf680c4391eccd9d122a3f704ef2d720724
2021-06-28 19:13:20 <PureTryOut> Yeah I just posted that
2021-06-28 19:13:29 <ikke> yea, noticed just too late
2021-06-28 19:14:19 <PureTryOut> 😃
2021-06-28 22:59:55 <dalias> is the rm -rf fixed yet? :-p
2021-06-28 23:04:20 <kasper81> dalias: was it broken somehow? missed it :D 
2021-06-28 23:04:54 <afontain[m]> well, it worked too well
2021-06-29 00:43:38 <bl4ckb0ne> alpine-extended-3.14.0-x86_64 is borked
2021-06-29 00:44:28 <bl4ckb0ne> missing kbd-bkeymaps and setup-timezone seems misstyped (.setup-timezone)
2021-06-29 00:48:36 <ddevault> I wonder if the extended image really needs to exist anymore
2021-06-29 00:49:50 <bl4ckb0ne> standard is also affected, same issue
2021-06-29 01:00:55 <bl4ckb0ne> turns out i suck at computers
2021-06-29 01:09:19 <superduck> as a user, fewer choices would be helpful, so I'd recommend dumping the extended images
2021-06-29 01:10:04 <superduck> anyone working on riscv support?
2021-06-29 01:32:28 <clandmeter> superduck: yes
2021-06-29 02:01:30 <ddevault> I mean, sarcasm aside, what benefit does having both screen and tmux, openvpn, irssi, zfs, xfs, etc, really provide over the standard install? if you want those things, it's trivial to just install them, and if you don't want them, they're wasted space
2021-06-29 02:01:54 <ddevault> does anyone even use fping?
2021-06-29 02:02:52 <ddevault> extended sits in this weird place where it provides a bunch of weird stuff of dubious value, but doesn't provide so much as to qualify as an opinionated ready-to-use distro like ubuntu
2021-06-29 02:02:58 <ddevault> I don't think that's alpine's niche
2021-06-29 02:05:21 <insep> ddevault: i didn't use fping, but maybe i will now, will be helpful to see whether it's only one website that's unpingable or whether my internet connection to borked
2021-06-29 02:05:56 <ddevault> right, but given that you didn't even know it exists, it's probably reasonable to question its inclusion in an alpine base install
2021-06-29 02:09:57 <ddevault> might also ask why mtr isn't there, if network diagnostic tools are in scope
2021-06-29 02:10:06 <ddevault> I don't think there's a compelling argument for extended anymore
2021-06-29 02:25:43 <Hello71> xfs?
2021-06-29 02:26:08 <Hello71> zfs is different because you can't just install it
2021-06-29 02:26:23 <Hello71> without running copy-modloop anyways. i think that made it into 3.14?
2021-06-29 02:39:41 <clandmeter> ls -lh pkg/ffmpeg-libs/usr/lib |tpaste
2021-06-29 02:39:43 <clandmeter> https://tpaste.us/NMv6
2021-06-29 02:39:49 <clandmeter> that doesnt look good :)
2021-06-29 08:17:01 <mercenary> ddevault: yes, people use both screen and tmux. tmux us easier for handling multiple sessions, but screen handles serial ports.
2021-06-29 08:17:50 <mercenary> And for a particular use case of mine, openvpn/wireguard is the first thing that gets installed, so I can get away from the rickety serial console connection
2021-06-29 08:20:59 <PureTryOut> ncopa: what is the license used in the "xfce4" meta package? It now just lists "GPL" but that is not SPDX compliant
2021-06-29 08:24:17 <mps> PureTryOut: he is and will be offline for a week or so
2021-06-29 08:24:41 <PureTryOut> Oh
2021-06-29 08:24:50 <PureTryOut> Anyone else know then?
2021-06-29 08:25:14 <mps> aside this, why metapackage have license at all
2021-06-29 08:26:11 <mps> these are just a list of packages
2021-06-29 08:26:38 <mps> ah yes, linter will grumble :)
2021-06-29 08:26:51 <PureTryOut> Because APKBUILDs just require licenses 🤷‍♂️ And well, the files alongside of the APKBUILD should be licensed
2021-06-29 08:27:43 <mps> then I'm for 'PD' (public domain)
2021-06-29 08:37:10 <clandmeter> PureTryOut: make it similar like apk tools or abuild, not sure what they are.
2021-06-29 08:42:33 <PureTryOut> Those are both GPL-2.0-only, which I guess is fine then
2021-06-29 08:44:27 <clandmeter> ncopa is away for a few days so i dont think he will answer much here.
2021-06-29 09:31:49 <wener> I was wondering, is it possible to build a BSD based os follow the alpine's philosophy
2021-06-29 09:33:49 <wener> Alpine is great, tools and os are good, but the more important is the alpine's philosophy
2021-06-29 09:34:23 <wener> an os with BSD kernel and apk, abuild, aports, simple, secure, woo, feels amazing
2021-06-29 09:34:36 <mercenary> Some say this has already happened, and point at OpenBSD
2021-06-29 09:35:14 <Sheila> some would be wrong, since OpenBSD is largely NIH and Alpine philosophy tries to avoid NIH unless it's actually warranted.
2021-06-29 09:36:35 <wener> OpenBSD installer is about 600MB, not small to me
2021-06-29 09:40:04 <wener> Used to tried FreeBSD and FreeNAS, no one match the experience of alpine
2021-06-29 09:40:05 <mercenary> That is full installer. PXE installer is ~30Mb (or 50 if you have both .mp and single-core)
2021-06-29 09:41:24 <wener> Thanks, maybe I should look more on OpenBSD
2021-06-29 09:42:12 <mercenary> It is somewhat different. And very opiniated about what they include
2021-06-29 09:57:57 <dne> it's closer to 5M than 30M (pxeboot + bsd.rd for amd64)
2021-06-29 10:16:34 <mercenary> did it get smaller? 6.8 had a 9.9M bsd.rd, and 20M bsd.mp
2021-06-29 10:18:43 <dne> yup, it seems (you don't need bsd.mp to perform the install though)
2021-06-29 10:19:48 <dne> "Began distributing the gzip'd version of bsd.rd on all platforms with boot methods supporting it." :)
2021-06-29 11:16:44 <PureTryOut> Hmm on armv7 `community/animatch` is disabled, but it is still listed for that arch on pkgs.a.o and appears in the repos. Why is that?
2021-06-29 11:18:22 <ikke> afaik, it's only removed after the next update
2021-06-29 11:22:04 <Ariadne> wener: BSD kernel is wrong direction.  think something like fuschia.
2021-06-29 11:23:17 <wener> Yes, fuschia is the feature, and using flutter to replace the X/Wayland ? 🤔
2021-06-29 11:24:17 <wener> s/feature/future
2021-06-29 11:24:17 <alpine-meetbot> wener meant to say: Yes, fuschia is the future, and using flutter to replace the X/Wayland ? 🤔
2021-06-29 11:24:27 <ericonr> just port libdrm to fuchsia and done ;)
2021-06-29 11:30:26 <PureTryOut> ikke: but now it causes confusing error messages when users try to install it
2021-06-29 11:30:36 <PureTryOut> as one of it's deps (allegro) has been removed from the repo
2021-06-29 11:32:59 <MY-R> it would be really great to have some list of packages removed/renamed/moved
2021-06-29 11:40:53 <clandmeter> these silent configure scripts are misleading
2021-06-29 11:49:40 <clandmeter> PureTryOut: i have a fix for ffmpeg :)
2021-06-29 11:50:16 <PureTryOut> Oh nice, that'd help immensely
2021-06-29 11:51:02 <clandmeter> another qemu related issue
2021-06-29 12:05:55 <PureTryOut> Oh interesting
2021-06-29 12:06:13 <PureTryOut> It's good to figure out these things, even if we'll eventually run it on actual riscv64 machines
2021-06-29 12:06:53 <PureTryOut> Also I love the builder skipping tests for now. It uncovered some packages with wrong dependency listings (stuff being in `checkdepends` but then fail to build since they should've been put in `makedepends`)
2021-06-29 12:07:54 <PureTryOut> Oh wut that fix
2021-06-29 12:08:05 <PureTryOut> That one should be easy to upstream
2021-06-29 12:08:28 <clandmeter> i mentioned it in their channel
2021-06-29 12:08:33 <PureTryOut> Shouldn't the pkgrel be bumped though? Since you're changing the contents of the outputted package?
2021-06-29 12:08:36 <clandmeter> i dont have git send email setup 
2021-06-29 12:08:46 <PureTryOut> Oh git-email, yeah ok
2021-06-29 12:09:00 <clandmeter> oh you are right, it actually did build.
2021-06-29 12:09:05 <clandmeter> thats also an issue
2021-06-29 12:09:36 <PureTryOut> Yeah
2021-06-29 12:10:10 <PureTryOut> I'll bump it
2021-06-29 12:11:17 <clandmeter> too late :p
2021-06-29 12:11:46 <PureTryOut> Haha that's fine
2021-06-29 12:12:07 <clandmeter> not sure why abuild accepts that failure
2021-06-29 12:14:29 <PureTryOut> Yeah it probably should just fail on it, the resulting file it complains about is unusable
2021-06-29 12:15:51 <PureTryOut> ikke: at postmarketOS we're still getting reports of people hitting BAD signature on polkit-elogind on x86_64
2021-06-29 12:16:50 <clandmeter> can you reproduce it?
2021-06-29 12:17:25 <PureTryOut> I haven't tried right now, but I could the past few days yeah and I reported multiple cases to ikke 
2021-06-29 12:20:22 <clandmeter> apk add polkit-elogind
2021-06-29 12:20:23 <clandmeter> https://tpaste.us/5njN
2021-06-29 12:20:35 <ikke> What mirror? 
2021-06-29 12:20:40 <clandmeter> PureTryOut: is it on edge?
2021-06-29 12:21:36 <PureTryOut> ikke: dl-cdn, I'll ask what branch the user is using
2021-06-29 12:21:57 <PureTryOut> it's on edge
2021-06-29 12:22:01 <PureTryOut> I'll doublecheck the dl-cdn thing
2021-06-29 12:23:10 <clandmeter> the tpaste is from edge
2021-06-29 12:23:31 <clandmeter> so if they are using dl-cdn that would be strange
2021-06-29 12:25:21 <clandmeter> not entirely impossible if one of the caching servers would be out of sync, but i do not expect that (although stranger things have happened recently with fastly).
2021-06-29 12:29:20 <PureTryOut> I definitely can reproduce it
2021-06-29 12:29:50 <PureTryOut> dl-cdn, edge, `ERROR: polkit-elogind-lang-0.118-r1: BAD signature`
2021-06-29 12:44:04 <ikke> PureTryOut: Can you show the results of curl -I for that package? 
2021-06-29 12:44:44 <PureTryOut> 
ACTION  < https://matrix.org/_matrix/media/r0/download/matrix.org/zrktjRnkkLyeHqmAaKZmRTVT/message.txt >

2021-06-29 12:44:46 <PureTryOut> ikke: ☝️
2021-06-29 12:45:03 <wener> should make the upgrade and move from testing to community in one commit ?
2021-06-29 12:45:30 <ikke> Separate 
2021-06-29 12:46:19 <PureTryOut> can be same MR though
2021-06-29 12:46:34 <ikke> Yes 
2021-06-29 12:48:02 <wener> ok
2021-06-29 13:06:33 <PureTryOut> How long should we wait for a response of the maintainer of a package before we consider them inactive? After no response on Gitlab I just emailed the maintainer of a package but I'm not sure they'll respond
2021-06-29 13:08:23 <PureTryOut> mps: the upstream of your package wdisplays seems to have dissapeared. Do you still use it or can we delete it from aports?
2021-06-29 13:15:56 <mps> wdisplays? first time hear for it
2021-06-29 13:16:13 <mps> and I doubt I'm maintainer ;)
2021-06-29 13:31:14 <insep> PureTryOut (matrix.org): https://github.com/luispabon/wdisplays
2021-06-29 13:32:00 <PureTryOut> mps: are you not Michał Polański?
2021-06-29 13:32:27 <PureTryOut> insep: nice find but it misses tags, so unusable for us
2021-06-29 13:32:38 <afontain[m]> haha
2021-06-29 13:32:49 <afontain[m]> I asked mps that question earlier
2021-06-29 13:33:00 <afontain[m]> M for Milan IIRC
2021-06-29 13:33:05 <ikke> No, mps is not Michal
2021-06-29 13:33:08 <PureTryOut> Oh derp lol
2021-06-29 13:33:11 <ikke> Correct 
2021-06-29 13:33:14 <PureTryOut> Then who is Michał Polański?
2021-06-29 13:33:28 <ikke> No nickname 
2021-06-29 13:33:50 <PureTryOut> Hmm, do they have a Gitlab username I can attach an issue too?
2021-06-29 13:33:55 <ikke> Yes 
2021-06-29 13:33:56 <PureTryOut> I guess I'll just completely disable the package for now
2021-06-29 13:35:48 <ikke> @mpolanski
2021-06-29 13:36:17 <ikke> He had push access to non-main
2021-06-29 13:36:22 <ikke> Has*
2021-06-29 13:36:51 <PureTryOut> Ah ok
2021-06-29 13:37:05 <PureTryOut> I'll disable the package for now then and make an issue and assign them to it
2021-06-29 13:56:21 <mps> hehe, a little fun is not bad for boring task, making distro. mps is shorthand for "Milan Petar Stanić' (Petar is/was my father name)
2021-06-29 13:58:29 <mps> my correctly written name is "Милан Петар Станић"
2021-06-29 14:00:38 <mps> and btw, Milan is oldest known human name
2021-06-29 14:01:41 <ericonr> PureTryOut: if you need a fork, https://github.com/luispabon/wdisplays
2021-06-29 14:02:15 <PureTryOut> I know, if you read chat history insep already linked it, but it doesn't have git tags
2021-06-29 14:17:50 <wener> ppc64le build failed https://gitlab.alpinelinux.org/wener/aports/-/jobs/425928#L71 
2021-06-29 14:17:53 <wener> ncurses-dev-6.2_p20210605-r0: package mentioned in index not found (try 'apk update')
2021-06-29 14:18:09 <wener> kind weird
2021-06-29 14:23:55 <Ariadne> its a known issue
2021-06-29 14:25:05 <clandmeter> mps: you still look young for such name
2021-06-29 14:25:17 <ikke> Network issues combined with known buggy rsync behavior 
2021-06-29 14:25:47 <wener> ok
2021-06-29 14:25:53 <wener> @clandmeter cloud you help review !22707
2021-06-29 14:26:15 <wener> very exciting, tinc-pre dev is active again
2021-06-29 14:26:25 <mps> clandmeter: :D
2021-06-29 14:27:03 <mps> without your fine sense of humor this channel will too boring
2021-06-29 14:27:17 <clandmeter> wener: lgtm
2021-06-29 14:27:27 <clandmeter> you want to take over maintainership?
2021-06-29 14:28:55 <wener> if you don't want to, I use tinc-pre a lot, I can keep it updated
2021-06-29 14:29:27 <clandmeter> sounds good to me
2021-06-29 14:29:31 <clandmeter> i never use it
2021-06-29 14:30:44 <wener> So, should i change the maintainer in this commit ?
2021-06-29 15:09:08 <PureTryOut> clandmeter: could you sync the riscv64 repo again?
2021-06-29 15:09:17 <PureTryOut> I want to test a build that needs the fixed ffmpeg
2021-06-29 15:20:16 <clandmeter> Ok done
2021-06-29 15:26:50 <PureTryOut> Thanks!
2021-06-29 15:31:35 <PureTryOut> Way quicker than building ffmpeg myself 😅
2021-06-29 15:33:07 <ikke> We need better QA for packages that conflict / have issues when upgrading
2021-06-29 15:33:20 <ikke> !12807
2021-06-29 15:33:25 <ikke> #12807
2021-06-29 15:33:53 <Ariadne> LIBRESSL :D
2021-06-29 15:34:49 <ikke> yeah, why's that?
2021-06-29 15:34:57 <Ariadne> yes, why is libressl packaged at all
2021-06-29 15:35:14 <Ariadne> anyway, they ask for libressl-dev
2021-06-29 15:36:01 <Ariadne> libretls and libressl are obviously going to conflict
2021-06-29 15:37:56 <Ariadne> and libretls is depended on by busybox
2021-06-29 15:38:14 <Ariadne> imo the solution is to drop libressl package
2021-06-29 15:38:56 <Ariadne> commit 94d1eed035c785c9743f326ef3b486f15fe2defa
2021-06-29 15:38:58 <Ariadne> hmm
2021-06-29 15:39:42 <ikke> why is there libressl and libretls?
2021-06-29 15:39:46 <Ariadne> i think libressl needs a custom --libdir
2021-06-29 15:39:58 <Ariadne> ikke: libretls replaced libtls-standalone
2021-06-29 15:40:33 <Ariadne> the libretls libtls is part of the alpine base system
2021-06-29 15:40:44 <Ariadne> libressl needs to be fixed to put it in a different libdir or something
2021-06-29 15:41:07 <Ariadne> we cant replaces=libretls on it, because that is likely to be an ABI break
2021-06-29 15:45:05 <Ariadne> another option would be to patch libretls
2021-06-29 15:45:12 <Ariadne> to use a different SOVERSION
2021-06-29 15:52:17 <Ariadne> i'm testing that in rootbld
2021-06-29 16:33:07 <ikke> PureTryOut: maybe we can switch easypki to use bbolt instead of boltdb
2021-06-29 16:33:18 <ikke> https://github.com/etcd-io/bbolt
2021-06-29 16:33:47 <ikke> PureTryOut: are you working on it?
2021-06-29 16:34:47 <ikke> https://github.com/etcd-io/bbolt
2021-06-29 16:35:42 <PureTryOut> I am not no
2021-06-29 16:35:47 <PureTryOut> I tend to skip Go packages
2021-06-29 16:35:59 <PureTryOut> I only just started doing Go in my internship and don't know much about it yet
2021-06-29 16:36:04 <ikke> np
2021-06-29 16:36:09 <ikke> I'm taking a look
2021-06-29 17:37:20 <ikke> I'm wondering if it's worth it to keep a fork of boltdb which adds support for other arches (simple files with constants)
2021-06-29 17:38:20 <ikke> easypki, consul and dep have been disabled due to this
2021-06-29 17:38:28 <ikke> 3 packages, not sure if it's worth it
2021-06-29 17:56:47 <Thermi> Did you try upstreaming it? Hehehe
2021-06-29 17:57:12 <ikke> :)
2021-06-29 17:57:28 <ikke> I tried, but hit a roadblock very quickly
2021-06-29 17:57:30 <ikke> :P
2021-06-29 17:58:03 <Thermi> link please?
2021-06-29 17:58:21 <Thermi> Also, how dense is this? https://github.com/erthink/libmdbx/issues/214#issuecomment-870717981
2021-06-29 17:58:36 <ikke> https://github.com/boltdb/bolt/
2021-06-29 17:58:48 <Thermi> > This repository has been archived by the owner. It is now read-only.
2021-06-29 17:58:52 <Thermi> >:(
2021-06-29 18:58:16 <wener> if you are looking for a golang based kv db, try https://github.com/dgraph-io/badger
2021-06-29 18:58:45 <Ariadne> we are looking to solve ftbfs issues
2021-06-29 18:58:50 <ikke> nod
2021-06-29 18:59:13 <Ariadne> though badger is a good option on go for that sort of thing
2021-06-29 19:50:57 <wener> Do you aware of this problem https://github.com/golang/go/issues/13492
2021-06-29 19:51:48 <wener> golang c-shared not works on musl, due to go depends on glic quirk, but freebsd folllowed the quirk too...
2021-06-29 19:55:26 <ikke> wener: seems to be already a very old issue
2021-06-29 19:56:37 <wener> yes, but not resolve yet, problem still exists, trying to make fluent bit support alpine, but this block the fluent bit plugins
2021-06-29 20:00:46 <kpcyrd> in the alpine diskless image, is the signature in the local APKINDEX.tar.gz actually required or can it be disabled somehow?
2021-06-29 20:01:25 <ikke> all images are diskless
2021-06-29 20:01:57 <ikke> But I'm not sure if apk supports unsigned indexes
2021-06-29 20:02:27 <kpcyrd> there's an explicit `abuild-sign "$_archdir"/APKINDEX.tar.gz` and I'm wondering if I can get around that somehow :)
2021-06-29 20:02:50 <ikke> in scripts/*.sh ?
2021-06-29 20:02:59 <kpcyrd> scripts/mkimg.base.sh, yes
2021-06-29 20:14:18 <kpcyrd> basically that's the last non-deterministic part in my image and I either need to copy the signature over (which is a bit of complexity), or I somehow avoid having a signature in the first place, since it likely doesn't provide security in this specific case
2021-06-29 20:33:43 <kpcyrd> my other question if there are any concerns if https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/io_archive.c#L295 is changed to `?: 0;` instead of `?; time(NULL);`
2021-06-29 20:34:03 <kpcyrd> that way we wouldn't have to implement SOURCE_DATE_EPOCH in apk-tools
2021-06-29 20:35:45 <kpcyrd> this only seems to apply to APKINDEX and DESCRIPTION
2021-06-29 20:41:55 <c705> i would like to revive the dicussion on the removal of firejail from 3.14. Should I open an issue or discussing it here is fine
2021-06-29 20:42:19 <c705> Ariadne: 
2021-06-29 20:46:24 <Ariadne> firejail will not be returned
2021-06-29 20:46:41 <Ariadne> there is no "discussion", there is no "democracy"
2021-06-29 20:46:50 <c705> lol
2021-06-29 20:46:53 <c705> why?
2021-06-29 20:47:20 <c705> we can't disuss things as a community anymore? it's just whatver you or a few others decide?
2021-06-29 20:47:24 <Ariadne> it is a backdoor masquerading as security software
2021-06-29 20:47:29 <c705> because if that's the case, then I would like to know that
2021-06-29 20:47:47 <Ariadne> i don't negotiate with terrorists
2021-06-29 20:48:13 <c705> I've read both sides of the discussion, and I really am not convinced either way. Yes it's suid, but right now I don't have any other alternatives
2021-06-29 20:48:26 <Ariadne> you have an alternative: package it yourself and put it on your own repo
2021-06-29 20:48:41 <Ariadne> alpine does not ship malware
2021-06-29 20:48:59 <c705> Do you have documentation that discusses how this is malware?
2021-06-29 20:49:20 <Ariadne> yes, it is called the insecure coding done by its author in the source
2021-06-29 20:49:24 <c705> Like, I'm not seeing anything convincing besides "firejail is suid and suid is bad"
2021-06-29 20:49:32 <Ariadne> read the damn source
2021-06-29 20:49:44 <c705> Are there open CVEs?
2021-06-29 20:49:47 <MathGeniusJodie> just make your own repo
2021-06-29 20:49:55 <MathGeniusJodie> it's a nice learning experience
2021-06-29 20:49:58 <Ariadne> ^
2021-06-29 20:50:42 <Ariadne> the only way firejail comes back is if there is a repo created for crap that is dubious at best
2021-06-29 20:50:49 <c705> So when will sudo be removed?
2021-06-29 20:50:54 <ikke> c705: yesterday
2021-06-29 20:51:11 <Ariadne> i mean, i would like sudo to be removed :D
2021-06-29 20:51:15 <MathGeniusJodie> same
2021-06-29 20:51:34 <c705> these are nice ideas, but I don't have alternatives
2021-06-29 20:51:43 <Ariadne> you literally do with sudo
2021-06-29 20:51:46 <Ariadne> it is called `doas`
2021-06-29 20:51:48 <ikke> c705: and bublejail doesn't do?
2021-06-29 20:51:50 <c705> bubblejail isn't even prodfuctuion ready
2021-06-29 20:52:06 <Ariadne> you have a strange definition of 'production ready' if it includes firejail ^_^
2021-06-29 20:52:09 <c705> i;ve been farting around with it for an hour, documentation is weak and it's barely even usable
2021-06-29 20:52:19 <Ariadne> which three letter agency are you working at
2021-06-29 20:52:19 <Ariadne> :D
2021-06-29 20:52:45 <c705> I still don't see what the big deal with firejail is. It is not meant to sandbox malware, but I don't see how it is malware itself
2021-06-29 20:52:59 <Ariadne> SUID binaries coded by people who don't know what they're doing is not acceptable
2021-06-29 20:53:08 <c705> I use it to decrease attack surface of well known applications, and I really don't see any issue with using it for that purpose
2021-06-29 20:53:21 <Ariadne> the problem is
2021-06-29 20:53:22 <Ariadne> it doesn't
2021-06-29 20:53:24 <ikke> c705: it is if it fails to do so properly
2021-06-29 20:53:27 <Ariadne> ^^^^^
2021-06-29 20:53:48 <Ariadne> instead you get an SUID binary interposed between your app and the evil world
2021-06-29 20:53:58 <c705> Do you have a POC, a CVE or anything that I can read further about this?
2021-06-29 20:54:01 <Ariadne> which means, you *think* your attack surface is lessened
2021-06-29 20:54:07 <Ariadne> but in reality it is greater
2021-06-29 20:54:13 <Ariadne> you're going to rule lawyer on CVEs
2021-06-29 20:54:17 <Ariadne> so i am not going to play that game with you
2021-06-29 20:54:21 <Ariadne> it's not coming back
2021-06-29 20:54:22 <Ariadne> live with it
2021-06-29 20:54:24 <c705> firejail runs suid, but like every other suid program, drops root after the sandbox is created
2021-06-29 20:54:30 <dalias> c705, firejail is really, *really* bad
2021-06-29 20:55:00 <dalias> if you have something concrete you're trying to achieve with it, tell us, and we probably have a better alternative
2021-06-29 20:55:10 <c705> like i said:
2021-06-29 20:55:31 <c705> I use it to decrease attack surface of well known applications, and I really don't see any issue with using it for that purpose
2021-06-29 20:55:43 <Ariadne> what do you define as 'attack surface'
2021-06-29 20:56:18 <c705> ie: I trust firefox is secure enough, but I would like to run firefox such that is has the minimum access to services that is required for it to work
2021-06-29 20:56:39 <dalias> how do you think firejail contributes to that?
2021-06-29 20:56:45 <dalias> what is it actually doing that you want done?
2021-06-29 20:56:49 <c705> bubblejail seems like it would be fine for this, but it's really not well documented and I can't figure it out
2021-06-29 20:57:21 <c705> well, if I run firefox, from within firefox, I don't have access to /etc, /home, /usr progs etc
2021-06-29 20:57:36 <ikke> c705: according to someone working on firejail, the profiles did not work on alpinelinux
2021-06-29 20:57:47 <ikke> I mean, working on firejail in alpinelinux
2021-06-29 20:57:54 <c705> ikke: that's partially true, some of them did work, but i have made my own modifications to get them to work
2021-06-29 20:58:58 <c705> I get an attack outside of firefox would be bad and firejail isn't going to help me,and would likely be a detriment due to suid (which I face anyways with sway and sudo both being suid), but I would think it decreases attack surface for an attack taking place within firefox itself
2021-06-29 20:59:11 <c705> I would actually prefer to be using apparmor, but this isn't avaliable in 3.14
2021-06-29 20:59:34 <c705> yeah, btw, sway is suid too, something I didn't realize until last week
2021-06-29 20:59:47 <Ariadne> sway isnt pretending to be a security tool :D
2021-06-29 20:59:53 <Ariadne> but yes, that sucks too
2021-06-29 20:59:56 <Ariadne> and should be fixed
2021-06-29 21:00:11 <Ariadne> however i trust that ddevault is writing code that is actually ok
2021-06-29 21:00:23 <Ariadne> the code in firejail is laughably bad
2021-06-29 21:00:23 <ikke> ddevault is no longer maintaining it
2021-06-29 21:00:25 <ddevault> sway does not need to be setuid
2021-06-29 21:00:29 <ddevault> iirc
2021-06-29 21:00:36 <c705> ddevault: it ships with suid
2021-06-29 21:00:37 <ddevault> so long as seatd or elogind is available
2021-06-29 21:00:41 <Ariadne> well, whoever is maintaining suid
2021-06-29 21:00:43 <Ariadne> er
2021-06-29 21:00:44 <Ariadne> sway
2021-06-29 21:00:45 <ddevault> but ask them to be sure
2021-06-29 21:00:46 <Ariadne> is probably doing an ok job
2021-06-29 21:00:58 <ddevault> emersion is the current maintainer
2021-06-29 21:01:02 <ddevault> and he is good at his job
2021-06-29 21:01:09 <Ariadne> i trust his code to be acceptable, yes
2021-06-29 21:01:21 <Ariadne> though perhaps we should look at this suid issue
2021-06-29 21:01:35 <c705> what in firejail is so bad? if the code stinks, why aren't bugs being opened?
2021-06-29 21:01:38 <MathGeniusJodie> you can't expect distro maintainers to just add every package you want, you'll be disappointed often
2021-06-29 21:01:50 <ddevault> some projects are beyond redemption
2021-06-29 21:02:03 <c705> MathGeniusJodie: i'm discussing the removal of a package which is entirely different imo
2021-06-29 21:02:20 <Ariadne> firejail shouldn't have been accepted to begin with
2021-06-29 21:02:41 <ikke> c3dc460ebfbd64041ecade8339ec07fed165daa2
2021-06-29 21:02:50 <Ariadne> c705: i tell you what!
2021-06-29 21:02:53 <c705> can we get apparmor in 3.14? I'm really trying to avoid compiling my own shit
2021-06-29 21:02:57 <Ariadne> if you want to try again with firejail for 3.15
2021-06-29 21:03:01 <c705> I agree firejail isn't ideal
2021-06-29 21:03:03 <Ariadne> and YOU maintain it
2021-06-29 21:03:16 <Ariadne> and YOU agree that YOU are on your own if a vulnerability happens
2021-06-29 21:03:28 <Ariadne> and that if YOU don't fix it within 48 hours
2021-06-29 21:03:34 <Ariadne> we get to remove it
2021-06-29 21:03:40 <Ariadne> then i am fine with firejail coming back
2021-06-29 21:04:00 <c705> I'd rather put the effort in getting apparmor in. I'd much rather use that than firejail
2021-06-29 21:04:04 <Ariadne> :D
2021-06-29 21:04:12 <ikke> apparmor is a lot of work
2021-06-29 21:04:19 <c705> to maintain or run?
2021-06-29 21:04:23 <Ariadne> to maintain
2021-06-29 21:04:26 <ikke> to setup
2021-06-29 21:04:40 <Ariadne> apparmor is on my list of things to look into fwiw
2021-06-29 21:04:50 <Ariadne> also bringing back linux-hardened
2021-06-29 21:04:50 <c705> I mean maintaining the package or setup. Either way i'm going to have to spend time on profiling, weather it's bubblejail or apparmor or wahtever
2021-06-29 21:05:04 <kpcyrd> the way apparmor is implemented in debian for some packages also breaks a bunch of flags
2021-06-29 21:05:06 <ikke> it's not just apparmor itself
2021-06-29 21:05:16 <ikke> you need profiles for everything
2021-06-29 21:05:26 <Ariadne> yeah to do apparmor right
2021-06-29 21:05:29 <Ariadne> its going to be a lot of work
2021-06-29 21:05:35 <Ariadne> i'm not saying it isnt worth doing
2021-06-29 21:05:36 <c705> ikke: well, no, you can run apparmor such that it's only armoring some of your progs
2021-06-29 21:05:38 <Ariadne> we just need like, a plan
2021-06-29 21:05:50 <c705> I am mostly concerned with applications that are internet facing
2021-06-29 21:05:53 <Ariadne> anyway there are apparmor tools in @testing
2021-06-29 21:06:01 <Ariadne> and the kernel has it enabled
2021-06-29 21:06:05 <c705> I don't want to use edge, that has other problems for me in the past
2021-06-29 21:06:16 <Ariadne> obviously we are not going to retroactively add packages to an already released distro
2021-06-29 21:06:25 <c705> No, i'm not asking for that
2021-06-29 21:06:30 <c705> 3.15 would be nice
2021-06-29 21:06:49 <Ariadne> it is doable for 3.15, if people are willing to drive it
2021-06-29 21:07:01 <Ariadne> i'm willing to help with apparmor for 3.15
2021-06-29 21:07:19 <Ariadne> but its gonna take several people driving it
2021-06-29 21:07:23 <jvoisin> apparmor won't fly for people using Alpine in containers unfortunately
2021-06-29 21:07:24 <Ariadne> to get it done
2021-06-29 21:07:35 <Ariadne> indeed not, but they don't have to use it
2021-06-29 21:07:36 <Ariadne> :p
2021-06-29 21:07:38 <c705> jvoisin: it wouldn't be on by default'
2021-06-29 21:08:08 <Ariadne> yeah, this would be a question in the installer or such
2021-06-29 21:08:13 <Ariadne> 'do you want apparmor y/n'
2021-06-29 21:08:22 <Ariadne> containerized alpine doesnt touch the installer
2021-06-29 21:08:27 <c705> what does one need to do to "drive" it. I would like to contribute and help out more, I just have no idea what i'm doing in terms of package building/mait
2021-06-29 21:08:39 <Ariadne> test packages, submit profiles
2021-06-29 21:08:42 <Ariadne> that sort of thing
2021-06-29 21:09:00 <Ariadne> anyway, the reason firejail was dropped
2021-06-29 21:09:10 <Ariadne> is because people recommend using alpine run-from-ram
2021-06-29 21:09:14 <Ariadne> with firefox, firejail and tor
2021-06-29 21:09:23 <Ariadne> for 'secure' internet browsing
2021-06-29 21:09:26 <c705> totally, and I do run from ram. I just like defense in depth
2021-06-29 21:09:32 <wener> just pack for you sefl like https://github.com/wenerme/repository
2021-06-29 21:09:35 <Ariadne> i'm not comfortable with that
2021-06-29 21:09:46 <jvoisin> apparently, it's possible to use apparmor inside of containers, interesting
2021-06-29 21:10:08 <Ariadne> given the CVEs that have been filed against firejail in the past, it is pretty obvious the project is beyond saving
2021-06-29 21:10:22 <Ariadne> and anything involving tor has to be treated as a potential situation where getting owned == somebody dies
2021-06-29 21:10:24 <c705> I'm not like hard for getting firejail back, I just wanted to understand more about why it was removed. Because half the people are saying the codebase is shit, and half of them aren't
2021-06-29 21:10:33 <Hello71> https://github.com/netblue30/firejail/blob/master/configure.ac#L79 this is still here
2021-06-29 21:10:45 <Ariadne> :D
2021-06-29 21:11:01 <c705> And I would like to say that looking at CVE counts as a detriment is a form of survivor bias. It's a good thing CVEs are reported generally - it means people are auditing the codebase
2021-06-29 21:11:15 <Ariadne> c705: it depends
2021-06-29 21:11:28 <c705> But enough people have told me now that firejail is shit, that I guess it is shit
2021-06-29 21:11:30 <Hello71> installing firejail, even if you never run it, means everything running outside firejail is basically security equivalent to root
2021-06-29 21:11:34 <Ariadne> firejail does not have a remarkable CVE count
2021-06-29 21:11:46 <c705> Hello71: that is not what that means at all, unless you have a POC you'd like to share
2021-06-29 21:11:50 <Ariadne> but the CVEs it does have, is awful
2021-06-29 21:11:57 <c705> Ariadne: yeah, i'd agree with that much
2021-06-29 21:12:04 <Hello71> ironically i think firejail blacklists itself so if you run everything inside firejail you might be ok
2021-06-29 21:12:06 <Ariadne> c705: there have been CVEs in the past, which allows running arbitrary shit as root
2021-06-29 21:12:17 <c705> _in the past_ sure
2021-06-29 21:12:35 <Ariadne> i think it is a good predictor in this case
2021-06-29 21:12:39 <Ariadne> given the quality of the codebase
2021-06-29 21:12:42 <c705> fair enough
2021-06-29 21:12:46 <Ariadne> enough that i thought removing it was the better decision
2021-06-29 21:13:06 <Hello71> https://seclists.org/oss-sec/2017/q1/25
2021-06-29 21:13:11 <c705> like I said, I would much rather be using apparmor, so if we can get that in a stable release, taht would be much better off than firejail
2021-06-29 21:13:16 <Ariadne> i've slept since then, but browsing through the codebase was certainly eyebrow-raising
2021-06-29 21:13:22 <c705> bublejail would be nice if/when I can figure this out
2021-06-29 21:13:26 <Ariadne> and given the suggestion to use firejail with tor
2021-06-29 21:13:32 <Ariadne> that suggestion scares the hell out of me
2021-06-29 21:13:52 <Ariadne> i'm not talking about people who buy weed off silk road
2021-06-29 21:14:02 <Ariadne> i'm talking about people who use tor to organize protests and so on
2021-06-29 21:14:13 <Ariadne> if they get owned?  they die
2021-06-29 21:14:17 <Ariadne> in some of these placers
2021-06-29 21:14:20 <Ariadne> places*
2021-06-29 21:14:31 <c705> I think even tor-browser suggests you use tails to that effect
2021-06-29 21:14:34 <Ariadne> and, i don't want alpine to put those kinds of users in that kind of risk profile
2021-06-29 21:14:46 <Ariadne> yeah, and tails doesn't have firejail :D
2021-06-29 21:15:02 <c705> I imagine it's using bwrap
2021-06-29 21:15:04 <Ariadne> but some suggest to use alpine
2021-06-29 21:15:18 <jvoisin> https://ubuntu.com/server/docs/containers-lxc
2021-06-29 21:15:21 <jvoisin> > Programs in a container cannot be further confined - for instance, MySQL runs under the container profile (protecting the host) but will not be able to enter the MySQL profile (to protect the container).
2021-06-29 21:15:23 <jvoisin> my bad.
2021-06-29 21:15:27 <c705> I would much rather use alpine than tails
2021-06-29 21:15:41 <Ariadne> anyway, i assure you, the situation with firejail, we looked at it holistically
2021-06-29 21:15:44 <jvoisin> yeah, nah, firejail will never be part of Tails, over my dead body.
2021-06-29 21:16:03 <jvoisin> (and it's not using bwrap either)
2021-06-29 21:16:14 <jvoisin> Tails has a custom Tor Browser apparmor profile.
2021-06-29 21:16:17 <Ariadne> at least bwrap is basically sane
2021-06-29 21:16:40 <Ariadne> verses browsing through the source of firejail
2021-06-29 21:16:44 <Ariadne> and just laughing hysterically
2021-06-29 21:17:06 <c705> Ariadne: i'm just pissy because I don't have any alternatives and I don't feel great about running firefox raw
2021-06-29 21:17:23 <Ariadne> the firefox sandboxing fully works on alpine
2021-06-29 21:17:28 <Ariadne> its pretty good, actually
2021-06-29 21:17:35 <Ariadne> we worked pretty hard to fix it
2021-06-29 21:17:48 <jvoisin> c705: check the Tor Browser's hardening
2021-06-29 21:17:49 <Ariadne> chromium is the one that is kinda dodgy
2021-06-29 21:18:04 <jvoisin> like, disabling JIT, disabling a ton of optimisations, disabling stupid features/formats/ …
2021-06-29 21:18:36 <Ariadne> and yeah what jvoisin says is the right way to reduce the attack surface
2021-06-29 21:18:45 <Ariadne> you turn the crap off
2021-06-29 21:18:46 <c705> agree, apparmor would be the best
2021-06-29 21:18:52 <Ariadne> not put the crap in apparmor or firejail
2021-06-29 21:19:02 <c705> oh, building without features? yeah
2021-06-29 21:19:07 <Ariadne> apparmor is "oh shit" backup plan
2021-06-29 21:19:12 <c705> well, yeah, defense in depth
2021-06-29 21:19:26 <Ariadne> but yet you are running alpine's firefox with all that crap enabled
2021-06-29 21:19:31 <Ariadne> inside firejail
2021-06-29 21:19:34 <Ariadne> do you see the fallacy here 
2021-06-29 21:19:35 <Ariadne> lol
2021-06-29 21:20:13 <c705> I suppose
2021-06-29 21:20:49 <c705> I still haven't seen any mind blowing POCs or anything, which I believe the developer asked for as well, but I can agree that any 0 days would be mind blowingly awful for the system
2021-06-29 21:21:06 <Ariadne> i mean, i haven't developed any POCs
2021-06-29 21:21:22 <Ariadne> i'm not interested in improving the security of firejail
2021-06-29 21:21:30 <c705> Anyways, guess I'll ship 3.14 for myself without sandboxes and work towards apparmor or something, thanks for the better explanation
2021-06-29 21:21:35 <Ariadne> i am interested in improving the security of alpine
2021-06-29 21:21:42 <c705> right
2021-06-29 21:21:46 <Ariadne> in my case, removing firejail improved the security of alpine
2021-06-29 21:22:26 <Ariadne> anyway, sorry bubblejail didn't work for you
2021-06-29 21:22:43 <Ariadne> all of these software are crap tho
2021-06-29 21:22:51 <Ariadne> bubblejail is just less harmful
2021-06-29 21:23:09 <Ariadne> because bwrap is basically sane
2021-06-29 21:23:14 <c705> yeah, I understand that. it's a cute idea but it needs work and/or documentation
2021-06-29 21:23:43 <c705> like, it's trying to connect to dbus by default and I can't figure out how to make it not do that without just using bwrap itself
2021-06-29 21:23:53 <Ariadne> but this is strictly a matter of risk reduction
2021-06-29 21:23:57 <c705> right
2021-06-29 21:24:03 <Ariadne> firejail is high risk of being popped again
2021-06-29 21:24:11 <Ariadne> and when it has previously been popped
2021-06-29 21:24:15 <Ariadne> it has not been pretty
2021-06-29 21:24:27 <c705> same with sudo though :/
2021-06-29 21:24:32 <Ariadne> yes, fuck sudo
2021-06-29 21:24:34 <Ariadne> 100% fuck sudo
2021-06-29 21:24:50 <c705> so are you using doas, or just running with su
2021-06-29 21:25:06 <Ariadne> i use `su` without even having a root password set
2021-06-29 21:25:36 <c705> did you strip caps or just like to live dangerously?
2021-06-29 21:25:55 <Ariadne> no, i just have defense in other areas
2021-06-29 21:25:58 <Ariadne> the setup i have is fine
2021-06-29 21:26:21 <c705> I see
2021-06-29 21:26:58 <Ariadne> for example, the only way you're getting on my boxes to begin with is with an SSH key
2021-06-29 21:27:02 <c705> anyways, thanks for the ideas
2021-06-29 21:27:07 <Ariadne> oh, you found some way to pop wordpress?  that's cool
2021-06-29 21:27:14 <Ariadne> you're in a kubernetes runner on a damn mainframe
2021-06-29 21:27:18 <Ariadne> good luck with your metasploit shellcode
2021-06-29 21:27:51 <c705> I mean, container escapes have been a thing
2021-06-29 21:27:58 <Ariadne> hell yeah they have been
2021-06-29 21:28:09 <Ariadne> but at that point
2021-06-29 21:28:17 <Ariadne> you can already gain root on my host environment anyway
2021-06-29 21:28:36 <Ariadne> if you're that good, i'm already owned
2021-06-29 21:28:48 <Ariadne> so my plan is to just not piss off the ian coldwaters of the world
2021-06-29 21:30:01 <Ariadne> almost like 90% of what people do security-wise
2021-06-29 21:30:04 <Ariadne> is just security theater
2021-06-29 21:30:41 <Ariadne> jail everything for real, e.g. with k8s
2021-06-29 21:30:45 <Ariadne> use SSH keys for auth
2021-06-29 21:30:49 <Ariadne> and stop caring about root
2021-06-29 21:31:10 <Ariadne> if they get into your shit, they are after your databases and shit anyway
2021-06-29 21:31:27 <Ariadne> secure *that*
2021-06-29 21:32:33 <c705> i mean, i do. i guess i just like taking it to the extreme. mostly for education
2021-06-29 21:32:46 <Ariadne> i like it when my security systems don't fight me
2021-06-29 21:33:06 <Ariadne> a good security system keeps the riffraff out, but doesn't get in your way
2021-06-29 21:33:08 <dalias> fwiw you can do much better sandboxing with just unshare(1)
2021-06-29 21:33:36 <dalias> see for example my usand.sh
2021-06-29 21:34:27 <Ariadne> c705: my vision for apparmor in alpine is that you can turn it on, and it stays out of your way
2021-06-29 21:34:47 <Ariadne> i tried to build that with grsecurity's RBACL stuff back in the day
2021-06-29 21:34:53 <Ariadne> but it was so buggy that i gave up
2021-06-29 21:35:01 <Ariadne> (grsecurity RBACL that is)
2021-06-29 21:35:13 <Ariadne> gradm2 would forget the administrator password
2021-06-29 21:35:19 <Ariadne> after X amount of uptime
2021-06-29 21:35:24 <Ariadne> so it was like corrupting it or something
2021-06-29 21:35:56 <c705> for a long while, i ran all my applications in docker as a sort of sandbox, but someone talked me into using firejail. I don't think lxc/docker is great for sandboxing either
2021-06-29 21:38:34 <Ariadne> docker and lxc can be pretty good for sandboxing, actually
2021-06-29 21:38:45 <Ariadne> you can place an entire container under seccomp profile
2021-06-29 21:39:04 <Ariadne> firejail is just "friendly"
2021-06-29 21:51:46 <kpcyrd> 75% of the bugs in my software is "something changed, the program triggered it's own seccomp rules and died"
2021-06-29 21:52:07 <kpcyrd> goes best with "but only on this specific arm flavor"
2021-06-29 21:52:44 <kpcyrd> pledge(2) is pretty neat
2021-06-29 21:53:11 <kpcyrd> along with unveil(2)
2021-06-29 21:53:23 <Sheila> it'll be nice to see landlock grow now that it's finally merged
2021-06-29 21:54:42 <kpcyrd> there are some nice features in systemd, like "ok I just wrote the software, I know everything except /var/lib/asdf isn't going to be written to, I'm just going to make that readonly"
2021-06-29 22:00:05 <Sheila> yeah, AIUI that's one of the motivations for landlock; https://lwn.net/SubscriberLink/859908/ac11a236daa19846/
2021-06-29 22:01:15 <ericonr> quite an ugly API though :/
2021-06-29 22:01:35 <ericonr> and requires NO_NEW_PRIVS because you can't make it "cloexec"
2021-06-29 22:03:51 <dalias> NO_NEW_PRIVS is a good thing
2021-06-29 22:08:12 <ericonr> dalias: making it required isn't great tho; it would be nice to be able to do "sandbox what I can access, but can still exec into this specific program without restrictions"
2021-06-29 22:28:32 <dalias> i dont think there's any safe way to allow suid from out of a sandboxed environment
2021-06-29 22:28:39 <dalias> it's inherently a sandbox escape
2021-06-29 23:13:48 <rhatr> Hey! Seems like we've got bootstrap.sh to a reasonable shape on riscv64. In fact, to make sure it doesn't bit rot -- I setup this GitHub repo/actions to run it https://github.com/rvs/aports/actions/runs/984439799
2021-06-29 23:14:57 <rhatr> I switching to enable packages that are part of boostrap phase that have disabled for now -- first one on my list is obviously linux-lts
2021-06-29 23:17:09 <rhatr> There my plan is to enable -virt option for now (since 5.10 kernel doesn't really boot on the riscv64 SBCs that are out there)
2021-06-29 23:18:30 <rhatr> This, in of itself, create a question I wanted to ask all of you: what's the proper way to approach maintaining a riscv64 kernel in Alpine that would actually boot on the interesting SBCs? I don't suppose we can have kernel of different versions for different architectures, can we?
2021-06-30 00:13:21 <Thermi> > service kopano-server start
2021-06-30 00:13:21 <Thermi>  * ERROR: kopano-server failed to start
2021-06-30 00:13:21 <Thermi>  * checkpath: /run/kopano/: could not open kopano: No such file or directory
2021-06-30 00:13:21 <Thermi>  * Caching service dependencies ...                                                                                                  [ ok ]
2021-06-30 00:13:28 <Thermi> Oh boy what did they break this time
2021-06-30 00:15:12 <Thermi>  /run exists, has rwxr-xr-x, so that's fine
2021-06-30 00:20:41 <Thermi> Is it not being executed as root, is that why that is?!
2021-06-30 00:20:51 <Thermi> "checkpath -d  -m 750 -o kopano:kopano /run/kopano/" works just fine
2021-06-30 00:21:49 <Thermi> Ze fuck. Manually retyping the path worked, copy and paste not
2021-06-30 00:22:13 <c705> are you copying and pasting from bloody word or something
2021-06-30 00:24:09 <Thermi> God is that stupid
2021-06-30 00:24:13 <Thermi> it didn't like the /
2021-06-30 00:24:19 <Thermi> I'm copying from terminal
2021-06-30 00:24:30 <kpcyrd> is there a reason I'd want --modloopsign?
2021-06-30 00:24:39 <Thermi> If you wanted to sign your modloop for some reason
2021-06-30 00:25:31 <kpcyrd> it seems to be on by default
2021-06-30 00:26:21 <Thermi> Gotta look at it
2021-06-30 00:26:23 <Thermi> Keep defaults they work
2021-06-30 00:32:47 <kpcyrd> if those signature are necessary I'd need to figure out a solution for reproducible builds
2021-06-30 00:34:10 <kpcyrd> I'm now building with two different key pairs and there are only two signatures that differ, it seems the public keys aren't shipped with the image
2021-06-30 00:38:01 <kpcyrd> if the public key is missing the signatures are possibly never verified, which would save me quite a bit of work because I can just turn it off :)
2021-06-30 02:10:12 <kpcyrd> I figured out the public key part, I also found the code that's doing the verification https://github.com/alpinelinux/aports/blob/master/main/openrc/modloop.initd
2021-06-30 02:12:50 <kpcyrd> It seems the signing is relevant in case the file was downloaded during boot and can be safely disabled for the raspi image
2021-06-30 05:37:22 <mps> rhatr: look at testing/linux-edge, riscv64 are already enabled there. both 'normal' kernel and -virt
2021-06-30 05:38:29 <mps> also here are scripts to make qemu img and boot virt version https://dev.alpinelinux.org/~mps/riscv64/
2021-06-30 05:39:23 <mps> uh, looks like he left channell (modern people :p)
2021-06-30 08:52:20 <andypost[m]> any idea what's wrong with ppc index? few packages in index but missing https://gitlab.alpinelinux.org/alpine/aports/-/jobs/426576#L80
2021-06-30 08:52:51 <PureTryOut> Known problem, they're working on it in #_oftc_#alpine-infra:matrix.org 
2021-06-30 08:52:56 <ikke> Network + rsync issues 
2021-06-30 09:54:26 <mps> interesting !22737
2021-06-30 09:54:41 <mps> could  CI build non-free pkgs?
2021-06-30 09:56:00 <ikke> Yes
2021-06-30 09:58:09 <mps> is that 'good idea' for alpine? distribute non-free pkgs from alpine infrastructure
2021-06-30 10:00:19 <ikke> I could prevent the packages being provided as artifacts 
2021-06-30 10:00:41 <ikke> But otherwise, they are not distributed 
2021-06-30 10:01:21 <mps> ianal, but that looks problematic to me
2021-06-30 10:01:30 <ikke> Why? 
2021-06-30 10:01:47 <ikke> Building it in our CI is not distribution 
2021-06-30 10:02:03 <mps> for example CI automatically download pkg which is non free
2021-06-30 10:02:19 <mps> this could be problem for some pkgs
2021-06-30 10:02:35 <mps> but IDK
2021-06-30 10:02:47 <Sheila> if they don't want people downloading it, they shouldn't make it available for distribution.
2021-06-30 10:03:22 <Sheila> the reason non-free exists is that *our* redistributing isn't okay, but giving instructions on how to acquire it *is*.
2021-06-30 10:03:28 <mps> it is 'mine field'
2021-06-30 10:06:52 <ikke> If downloading is problematic, it should be purged m
2021-06-30 10:07:08 <ikke> From aports 
2021-06-30 10:15:11 <clandmeter> if we dont "officially" distribute them, we should be fine. artifacts on gitlab dont count imho.
2021-06-30 10:15:37 <clandmeter> and they get purged after x time 
2021-06-30 10:16:32 <ikke> Not so sure of that 
2021-06-30 11:03:19 <clandmeter> sure of what?
2021-06-30 11:04:40 <ikke> That it matters whether it's 'official' or not
2021-06-30 11:06:05 <clandmeter> thats why its my opinion, im not a lawyer 
2021-06-30 11:06:28 <ikke> ofcourse, if it's as an ephemeral artifact, it's less obvious
2021-06-30 11:23:15 <ikke> mps: there are some vulnerabilities for dovecot which have not been backported, do you have time for that?
2021-06-30 11:39:07 <mps> ikke: will look later tooday. I thought to backport latest stable to 3.14 but want to wait amend from ncopa
2021-06-30 11:40:49 <mps> oh, they made new release of previous stable in meantime, so no needs to backport latest release. better
2021-06-30 11:41:08 <ikke> Right 
2021-06-30 11:42:05 <mps> ok, will do
2021-06-30 13:47:38 <Ariadne> good morning everyone!
2021-06-30 13:47:46 <clandmeter> good afternoon
2021-06-30 13:51:16 <mps> it is too hot here from morning to afternoon (evening), anyway good whatever
2021-06-30 14:04:15 <mps> ikke: does it looks ok !22740
2021-06-30 14:04:56 <mps> it is for 3.13 stable, and I think same should be for 3.12-stable
2021-06-30 14:05:17 <mps> and I already upgraded it for 3.14-stable
2021-06-30 14:40:43 <ikke> Looks ok
2021-06-30 14:48:05 <Ariadne> i merged it
2021-06-30 14:48:27 <Ariadne> security updates are basically open season for non-maintainer updates ;p
2021-06-30 14:52:15 <mps> ok, 3.12-stable will follow
2021-06-30 15:26:49 <bl4ckb0ne> can I have a review for https://lists.alpinelinux.org/~alpine/aports/patches/3506 pls? seems to have been missed by the gitlab bot
2021-06-30 15:28:14 <Cogitri> bl4ckb0ne: Looks ok, make it a gitlab MR so CI can run over it and I can press the magic button :p 
2021-06-30 15:29:31 <bl4ckb0ne> 
ACTION makes a gitlab account

2021-06-30 15:39:54 <bl4ckb0ne> Cogitri: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22742
2021-06-30 15:42:56 <Cogitri> And seems like Gitlab doesn't like to fast forward that for some reason, could you rebase against master and force push to your branch?
2021-06-30 15:43:06 <bl4ckb0ne> sure
2021-06-30 15:43:56 <bl4ckb0ne> done
2021-06-30 15:44:20 <Cogitri> Thanks :)
2021-06-30 15:48:26 <bl4ckb0ne> weeee pipeline failure
2021-06-30 15:49:02 <ikke> /usr/bin/abuild: line 15: abuild-meson: not found
2021-06-30 15:49:04 <ikke> hmm
2021-06-30 15:49:06 <ikke> Cogitri: ^?
2021-06-30 15:57:54 <yyp> bl4ckb0ne: shouldn't this aport have meson in makedepends?
2021-06-30 15:59:05 <Hello71> yes, is meson definitely installed
2021-06-30 15:59:33 <bl4ckb0ne> isnt abuild-meson a built-in dep?
2021-06-30 16:00:09 <yyp> bl4ckb0ne: it comes with meson package
2021-06-30 16:00:32 <Hello71> and besides how would it run without meson
2021-06-30 16:01:10 <yyp> I think I had to install meson manually even after adding alpine-sdk, but idk
2021-06-30 16:02:04 <Cogitri> Yes, meson is not in the base system
2021-06-30 16:10:20 <Hello71> i mean i think autoconf isn't either
2021-06-30 16:18:21 <ikke> https://pkgs.alpinelinux.org/package/edge/main/x86_64/build-base
2021-06-30 16:51:43 <PureTryOut> ikke: have you managed to fix the BAD signature yet?
2021-06-30 16:51:53 <ikke> no, not yet
2021-06-30 16:54:24 <ikke> well, I do now
2021-06-30 16:54:29 <ikke> just purged it
2021-06-30 16:55:40 <ikke> at least, for that specific package
2021-06-30 16:56:00 <PureTryOut> polkit-elogind-lang right?
2021-06-30 16:56:40 <mps> ikke: you mean 'purge from aports' :D
2021-06-30 16:56:53 <ikke> PureTryOut: yes
2021-06-30 16:56:58 <ikke> mps: you wish
2021-06-30 16:57:01 <PureTryOut> Cool thanks
2021-06-30 16:57:12 <mps> heh, just dream
2021-06-30 17:10:31 <bl4ckb0ne> pushed a fix, thanks for the tip yyp
2021-06-30 17:10:44 <bl4ckb0ne> CI seems to be alright, ppc64le already passed
2021-06-30 17:12:54 <ikke> andypost[m]: right now, it seems everything should be synced
2021-06-30 17:14:08 <andypost[m]> ikke, thank you
2021-06-30 17:16:17 <ikke> hmm, it still fails
2021-06-30 17:16:19 <ikke> I have to investigate
2021-06-30 17:19:05 <kpcyrd> I've posted the thread I've asked all those questions for recently :) https://twitter.com/sn0int/status/1410280372051582978
2021-06-30 17:19:45 <ikke> andypost[m]: ah, I checked community, but main was still missing things
2021-06-30 17:21:13 <ikke> andypost[m]: should be fixed now
2021-06-30 17:21:35 <ikke> (need to wait until synced with the mirrors)
2021-06-30 17:31:47 <bl4ckb0ne> all green on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22742
2021-06-30 17:47:44 <Cogitri> Merged
2021-06-30 17:48:35 <bl4ckb0ne> ty
2021-06-30 18:53:52 <jesec> also https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22578 . could someone take a look?