2020-07-01 02:51:18 <xorex> mps: what do you mean with “docker builder”?
2020-07-01 06:01:28 <ncopa> morning!
2020-07-01 06:01:42 <ncopa> ikke: i think i fixed the vlc package split
2020-07-01 06:01:59 <ncopa> I mean clandmeter
2020-07-01 06:02:11 <ikke> :-)
2020-07-01 06:02:35 <ncopa> ikke: sounds like the CI does not pick up syntax errors in APKBUILDs
2020-07-01 06:03:42 <ikke> In those cases, it did not detect any packages to be built at all, which should not be affected by syntax errors
2020-07-01 06:04:28 <ncopa> where is the code that detects what to build?
2020-07-01 06:05:46 <ikke> In case of linting: https://gitlab.alpinelinux.org/alpine/infra/docker/apkbuild-lint-tools/-/blob/master/overlay/usr/local/bin/changed-aports
2020-07-01 06:07:08 <ikke> For CI build: https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/bin/build.sh#L99
2020-07-01 06:08:02 <ikke> What makes it tricky is that we use shallow clones (to make the process go faster)
2020-07-01 06:52:44 <mps> do we still need lxcfs
2020-07-01 06:54:24 <mps> and we need guide for merge requests, especially about check box to allow merging
2020-07-01 07:01:43 <mps> looks like s390x CI is stuck again. is it enough to restart job?
2020-07-01 07:02:55 <ikke> yes
2020-07-01 07:03:23 <mps> ok, lets see
2020-07-01 07:04:03 <mps> yes, it worked. thanks
2020-07-01 07:09:51 <clandmeter> ncopa: ok
2020-07-01 07:13:10 <mps> it is annoying to ask MR authors for nearly two thirds of MRs to allow merging
2020-07-01 07:14:43 <mps> can someone enable merging and squashing for !9740
2020-07-01 07:38:00 <mps> xorex: 'docker builder' probably apk for building dockers
2020-07-01 07:41:50 <Cogitri> mps: I'll start working on a gitlab bot to automatically do that today
2020-07-01 07:43:04 <mps> +1
2020-07-01 07:43:48 <mps> though would be nice if gitlab can have option 'forbid merge' for special cases
2020-07-01 07:47:24 <ikke> mps: mark it as WIP :)
2020-07-01 07:48:00 <mps> and then you will come and remove WIP :)
2020-07-01 08:08:04 <mps> ikke: please, if you have some time can you look at this https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9740#note_99917
2020-07-01 08:08:46 <mps> I'm not sure I understand how to proceed with this and what to answer
2020-07-01 08:09:59 <ikke> mps: The should use topic branches, the MR is now based on master (which is protected in their repository), so it's not possible to allow commits from others
2020-07-01 08:16:33 <mps> hmm, ok. will look if I can find some time. today I'm busy with monthly paperwork
2020-07-01 12:48:30 <hc-hmk> ncopa: If i were to submit a patch for alpines mkinitfs, where would I do that? We have some changes we'd like to upstream to you guys.
2020-07-01 12:49:09 <Cogitri> Submit a MR to gitlab.a.o/alpine/mkinitfs
2020-07-01 12:51:53 <hc-hmk> Fantastic, we'll be submitting a MR withing the next week or so. You should consider changing default compression for initramfs to lz4. It's not much larger, supported by the kernel and heaps faster than xz or gzip. It shaved seconds off the boot time for our embedded things.
2020-07-01 12:52:23 <Cogitri> Maybe zstd would be interesting too
2020-07-01 12:52:36 <hc-hmk> We use comp="lz4 --favor-decSpeed --best -lvz";;
2020-07-01 12:53:03 <hc-hmk> Zstd is neat too for things that are read/write. For read only, lz4 is quite a bit faster.
2020-07-01 12:59:12 <Hello71> zstd not upstream yet
2020-07-01 13:00:33 <Hello71> and if we're going to start optimizing for speed rather than size, -O2 is a good place to start (-Os does a bunch of dumb stuff)
2020-07-01 13:01:08 <hc-hmk> Oh wow, are packages built with -Os by default?
2020-07-01 13:02:57 <hc-hmk> -O2 is GCCs default for a reason.
2020-07-01 13:07:07 <hc-hmk> Sorry, my bad, it's not GCCs default, it's Linux' default.
2020-07-01 13:11:46 <Hello71> also it's worth noting that in my experience --favor-decSpeed has no effect on kernels or initramfss. I think it's because the files are too small
2020-07-01 13:15:48 <MY-R> with this commit is fast enough too
2020-07-01 13:15:50 <MY-R> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/commit/59204d36985de5ba2444d5f3e0d50a119287ec51
2020-07-01 13:29:02 <Cogitri> Hello71: Probably not going to happen, -O2 can be a lot bigger than -Os already: https://lists.alpinelinux.org/~alpine/devel/%3C2896c13070c508a49cbaa72c8fb7f34ea947358b.camel%40cogitri.dev%3E
2020-07-01 13:42:55 <Hello71> yes, it's a little unfortunate. -O2 is a lot bigger, but -Os is really slow. https://lore.kernel.org/lkml/20110323211415.GA8791@elte.hu/ from 2011 says 10% slower kernel with -Os. http://web.archive.org/web/20200408145313/https://rv8.io/bench says 20% slower rv8 with -Os
2020-07-01 13:44:21 <hc-hmk> Alpine doesnt ship chattr in e2fsprogs. How do I change the immutable bit on ldlinux.sys when chattr doesn't exist?
2020-07-01 13:44:32 <Hello71> there are some middle grounds, e.g. https://github.com/richfelker/mallocng-draft/commit/a9187f0387dcbb77f1f7e4d7774602fd394fb27b
2020-07-01 13:44:48 <ikke> Hello71: e2fsprogs-extra
2020-07-01 13:44:51 <superduck> Is the mkinitfs maintainer open to a complete rewrite of mkinitfs and the default initramfs?
2020-07-01 13:45:14 <Hello71> also the thread at https://gcc.gnu.org/legacy-ml/gcc/2017-08/msg00280.html points out that lto usually provides more significant improvements
2020-07-01 13:45:15 <hc-hmk> ikke: thanks man
2020-07-01 13:45:28 <ikke> hc-hmk: try: apk search cmd:chattr
2020-07-01 13:45:32 <Hello71> ikke: I don't need it, but thanks for the info
2020-07-01 13:45:54 <ikke> Hello71: heh, autocomplete fail :)
2020-07-01 13:48:46 <mps> hc-hmk: if need faster boot skip initramfs
2020-07-01 13:49:17 <Hello71> it would definitely be interesting to have alpine system-wide lto
2020-07-01 13:49:22 <Hello71> superduck: where are you going with this
2020-07-01 13:49:38 <TBB> it has been discussed, actually
2020-07-01 13:50:09 <TBB> the mkinitfs replacement, that is
2020-07-01 13:50:53 <superduck> I'm booting into a root mounted zram and want to at least add that as an option. But the initramfs is practically unreadable as is, and can be broken into functions to make it more modular so options are easier to deal with
2020-07-01 13:51:46 <superduck> The modloop approach is really weird in relation to initramfs design, and we might be able to look at a XIP FS to replash squashfs modloops. Just some ideas, but my main take is I want to boot fast straight into zram rootfs.
2020-07-01 13:51:49 <TBB> dracut was mentioned in that discussion as a possible tool; I remember working with it on RHEL and that it was quite messy
2020-07-01 13:52:00 <jcdl> how hard would it be to bootstrap a big endian ppc64 build?
2020-07-01 13:52:28 <ikke> jcdl: Ariadne has experience with that
2020-07-01 13:52:50 <Ariadne> jcdl: working on it already
2020-07-01 13:53:48 <superduck> The Alpine docs on APKINDEX and modloops is also terrible, and that's integral to the LBU/mkinitfs philosophy on system management, so the documentation around how early boot and diskless systems function could be much improved as part of a mkinitfs/initramfs rewrite.
2020-07-01 13:55:06 <superduck> For mkinitfs, it'd be nice if it could auto-add insmod modules to the initramfs without having to update the features.d.
2020-07-01 13:55:21 <mps> TBB: afaik, dracut is not so good as marketing about it
2020-07-01 13:55:42 <superduck> At least that way when I build a new mkinitfs targeted for the host its run on, I could rebuild and automatically get the modules I'm running with, even if I omit some from the features list.
2020-07-01 13:56:05 <superduck> mps: software written by humans is not so good
2020-07-01 13:56:32 <TBB> mps, yeah, but it could serve as a base design of sorts, both in good and bad :)
2020-07-01 13:57:11 <Ariadne> jcdl: main point is who hosts the builder atm.  I might host it from my house or something.  or maybe a VM on the ppc64le builder.
2020-07-01 13:57:23 <mps> superduck: true, but is still better than any other software :P
2020-07-01 13:58:30 <jcdl> Ariadne: does it need to be native or can it be cross compiled from an x86 host?
2020-07-01 13:58:35 <hc-hmk> mps: How do you suggest we skip initramfs? I'm very interested in gaining some speed and reducing moving parts on our systems.
2020-07-01 13:58:40 <mps> TBB: more for bad
2020-07-01 13:58:42 <TBB> that's basically what mkinitfs could do with, a bit of automation for enabling features and for creating initramfs-init dynamically
2020-07-01 13:58:53 <superduck> hc-hmk: you can't skip initramfs, it's built into the linux kernel
2020-07-01 13:59:16 <Hello71> superduck: wat
2020-07-01 13:59:19 <hc-hmk> I'm not sure you're entirely right superduck.
2020-07-01 13:59:30 <mps> for all my systems where I need fast and simple boot I build kernel and don't use initram
2020-07-01 13:59:45 <superduck> There's always an initramfs appended to the kernel, it's usually empty, but that's what gets unpacked before the initrd arguments are unpacked
2020-07-01 14:00:16 <mps> superduck: no, you can disable initram in kernel config
2020-07-01 14:00:21 <Ariadne> jcdl: we prefer native building because many packages are not cross aware and tests can't run on cross.
2020-07-01 14:00:55 <superduck> if no initrd argument is provided, the kernel has some fallback rootfs detection, but I'm not familiar with it's approach, and I strongly recommend a lightweight initramfs that becomes the root of your new system, i.e. run straight out of ram your root system with an overlayfs with any "new" root you may want
2020-07-01 14:01:08 <hc-hmk> mps: What do you use instead of initramfs? You cant have nothing, surely. Are the files just on disk next to the kernel or what?
2020-07-01 14:01:20 <Hello71> hc-hmk: =y
2020-07-01 14:01:25 <Ariadne> note that the ppc64 we are targeting is ppc64 (with altivec) and not ppc64spe (whatever that stupid shit freescale did instead of altivec)
2020-07-01 14:01:48 <superduck> mps: https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
2020-07-01 14:02:21 <superduck> hc-hmk: without an initramfs for early boot, the linux kernel *does* have some rootfs detection, but it's decried in that document I linked
2020-07-01 14:02:31 <Ariadne> anyway
2020-07-01 14:02:35 <hc-hmk> I'm not sure I like that idea. Initramfs is neater in our usecase.
2020-07-01 14:02:47 <Ariadne> I am not interested in replacing our initramfs
2020-07-01 14:02:53 <mps> hc-hmk: you build you kernel with base drivers in-kernel (not as modules), mostly filesystem drivers and 'disk' drivers, and you don't need initram at all
2020-07-01 14:03:09 <Hello71> "The kernel's current early boot code (partition detection, etc) will probably be migrated into a default initramfs" narrator: it was not.
2020-07-01 14:03:13 <jcdl> okay good lol, of course I'm asking for my g5 :P
2020-07-01 14:03:17 <hc-hmk> I'm not interested in rolling a custom kernel at this time. We're trying to keep this stuff pretty standard.
2020-07-01 14:03:51 <Ariadne> to the extent that the current initramfs can be improved by a rewrite fine, but I want to still support switching root into a normal fs
2020-07-01 14:04:08 <Ariadne> and I want to support building alpine environment from packages into ram
2020-07-01 14:04:39 <Ariadne> I don't think there would be any interest in an overlayfs replacement
2020-07-01 14:04:50 <mps> Ariadne: I'm not advocating removal of initramfs, just give hints to those who wants faster boot
2020-07-01 14:05:08 <Ariadne> sure
2020-07-01 14:05:14 <hc-hmk> To be honest, what we did to mkinitfs is not completely kosher, but it's a pretty big improvement over stock. We've packed root into a squashfs, which refused to boot with the stock init script.
2020-07-01 14:05:40 <mps> and I use initramfs on boxes which are not 'boot speed' critical
2020-07-01 14:06:00 <Ariadne> I am just saying that any modification to initramfs cannot break these use cases
2020-07-01 14:06:42 <hc-hmk> I agree. Pivoting to a new root mounted from somewhere is pretty crucial functionality. Our root just happen to be squash.
2020-07-01 14:07:18 <Ariadne> no objection to supporting that as long as current behavior remains supported
2020-07-01 14:07:36 <hc-hmk> I take it that we need two separate MRs for that?
2020-07-01 14:07:39 <TBB> writing a custom initramfs-init is pretty much basic stuff if you want to venture outside of the regular
2020-07-01 14:08:03 <hc-hmk> TBB: What is your point?
2020-07-01 14:08:12 <Cogitri> Hello71: LTO does sound great, but also probably is a great amount of work
2020-07-01 14:08:41 <TBB> hc-hmk: that not all scenarios cannot be pre-emptively scripted into easy-to-use modules for generating initramfs-init dynamically
2020-07-01 14:08:52 <Ariadne> Some packages are already built with -flto but there's a lot of problems still enabling it distro-wide
2020-07-01 14:09:01 <mps> Cogitri: not sure that LTO is so great
2020-07-01 14:09:07 <Ariadne> I looked into it
2020-07-01 14:09:07 <Hello71> apparently fedora is working towards system-wide lto
2020-07-01 14:09:23 <TBB> okay, -some- of them can, and the squashfs thing is one of those, I considered it for my previous big work project
2020-07-01 14:09:23 <hc-hmk> TBB: Fair. For something as light and small as Alpine, squashed root doesn't seem that far fetched though.
2020-07-01 14:09:32 <Cogitri> mps: Other than the build failures it causes for some packages it's basically a no brainer to enable it
2020-07-01 14:09:48 <mps> Hello71: are we sure fedora do always right things
2020-07-01 14:09:48 <Cogitri> Smaller binaries which perform a lot better (but also take longer to build) sound nice
2020-07-01 14:09:56 <hc-hmk> I greatly prefer squashed root to the weird APK data mode thing
2020-07-01 14:10:07 <ikke> build-time is certainly a concern
2020-07-01 14:10:10 <Ariadne> jcdl: and yes, the idea is to support G5 and newer, tuning for POWER8 as we do with ppc64le.
2020-07-01 14:10:32 <TBB> hc-hmk: true; it would actually be pretty neat, and if you add file system overlays to that then you could even do sort of reversible system updates
2020-07-01 14:11:03 <superduck> The current initramfs doesn't have zram support for the root partition, and I've added it in a custom initramfs-init script. The default initramfs-init script can be cleaned up a lot without breaking existing functionality.
2020-07-01 14:11:13 <hc-hmk> I'm off for today. See you tomorrow.
2020-07-01 14:11:16 <Ariadne> hc-hmk: sure but we need to still support LBU and I would be opposed (including with the weight of significant $$$) to breaking LBU
2020-07-01 14:11:52 <ikke> lbu is a major usecase of Alpine, I don't think it's feasible to drop support for it
2020-07-01 14:12:26 <Hello71> Ariadne: a fair bit of packages do not support it, but not *that* many: https://github.com/InBetweenNames/gentooLTO/blob/master/sys-config/ltoize/files/package.cflags/ltoworkarounds.conf (only lines 1 to ~141 are actually LTO, so about 130 broken packages)
2020-07-01 14:12:30 <superduck> I'd consider a git wrapper or squashfs or AXFS replacement for LBU, but functionally it shouldn't matter as long as it behaves the same conceptually, detected and unpacked on boot, saved to writable media on demand.
2020-07-01 14:12:46 <Ariadne> Anyways
2020-07-01 14:12:50 <Hello71> I agree that it is non-trivial, and certainly I wouldn't want to put in all of that work :p
2020-07-01 14:13:03 <Hello71> (by myself)
2020-07-01 14:13:04 <superduck> It's possible to think of LBU as an interface instead of as a single solution.
2020-07-01 14:13:09 <Cogitri> ikke: Build time doesn't seem that bad with thin LTO fortunately
2020-07-01 14:13:29 <Ariadne> superduck: that's great but it requires my customers to regenerate their LBU data.  which is not acceptable to me
2020-07-01 14:13:38 <superduck> No it doesn't.
2020-07-01 14:13:38 <Hello71> Cogitri: I think clang is even more of a jump than lto
2020-07-01 14:13:45 <Ariadne> how does it not
2020-07-01 14:13:56 <Ariadne> LBU is a tarball
2020-07-01 14:14:15 <Ariadne> what you want to do is replace that with something else
2020-07-01 14:14:26 <superduck> ariadne: if multiple lbu formats were supported, it could grow in other ways with the lbu tool being an interface to different backend storage
2020-07-01 14:14:55 <superduck> lbu has to locate/detect the current tarball, it can detect a conforming git-repo, or other formatted "lbu" approved format
2020-07-01 14:15:02 <Ariadne> no objection to supporting better ways of achieving LBU feature as long as current LBU is supported :)
2020-07-01 14:15:26 <superduck> I'm a fan of a git wrapper so we can commit some history and recover older versions of comitted LBUs.
2020-07-01 14:15:30 <Ariadne> we can even deprecate it if a timeframe exists for migration
2020-07-01 14:15:30 <Cogitri> <Hello71 "Cogitri: I think clang is even m"> Hm? CLang doesn't really generate faster binaries usually
2020-07-01 14:15:59 <Hello71> well I'm saying that if someone is opposed to lto being too much of a change, then surely they won't like change to clang
2020-07-01 14:16:04 <Cogitri> At least last time I checked CLang was about even with GCC or slower in resulting binaries but it did compile faster (and has way better error msgs)
2020-07-01 14:16:10 <Ariadne> the main reason for clang over gcc is that gcc devs have had some serious regressions in the past few years
2020-07-01 14:16:25 <superduck> How can folks on Alpine object to a switch in compiler if we've switched out the libc already?
2020-07-01 14:17:28 <superduck> My personal goal is to remove the GNU project from Alpine.
2020-07-01 14:17:31 <Ariadne> superduck: well the switches aren't about ideology but about providing the best possible tool for the job for our needs
2020-07-01 14:17:51 <Ariadne> why?
2020-07-01 14:18:19 <Ariadne> if the GNU project provides the best tool, we should use it.
2020-07-01 14:18:20 <mps> superduck: will not pass
2020-07-01 14:18:24 <superduck> Toybox instead of busybox is designed to be a complete minimal system when joined with a kernel + libc
2020-07-01 14:18:38 <Ariadne> that will not ever happen
2020-07-01 14:18:46 <superduck> mps: I'm not suggesting we remove coreutils and such from the repos, but make them opt-in choices
2020-07-01 14:18:55 <Ariadne> landley is not somebody we can depend on for that
2020-07-01 14:18:57 <superduck> ariadne: why not?
2020-07-01 14:19:00 <Ariadne> to be blunt
2020-07-01 14:19:04 <mps> most of us want usability and correctnes, not ideology
2020-07-01 14:19:16 <Ariadne> toybox has been promises and promises and promises and it has been years of vaporware
2020-07-01 14:19:25 <Ariadne> and we have a very tight relationship with denys
2020-07-01 14:19:35 <superduck> who is denys?
2020-07-01 14:19:47 <Ariadne> and I'm not going to allow that relationship to be compromised unless there is a damn good reason
2020-07-01 14:20:06 <Ariadne> denys is the maintainer of busybox
2020-07-01 14:20:18 <mps> Denis
2020-07-01 14:20:24 <Ariadne> oops
2020-07-01 14:20:33 <Ariadne> well point stands
2020-07-01 14:20:33 <jcdl> wikipedia says Denys
2020-07-01 14:20:45 <mps> Vlasenko, iirc, or vda
2020-07-01 14:20:46 <Ariadne> we have a tight relationship with busybox
2020-07-01 14:20:50 <superduck> If toybox could be brought up to functional parity to busybox, would it be considerable to have a switch to the default *box dependency for the base Alpine system?
2020-07-01 14:20:56 <Ariadne> no
2020-07-01 14:21:58 <mps> Ariadne: I was wrong, Denys
2020-07-01 14:21:58 <superduck> Why not?
2020-07-01 14:22:27 <superduck> I'm just curious why it couldn't be considered as an option.
2020-07-01 14:22:32 <Ariadne> because we cannot depend on landley
2020-07-01 14:22:48 <mps> (to my defend I don't read names carrefully)
2020-07-01 14:22:58 <afontain_> I'm not fond of the concept of replacing something with a worse alternative to try to improve it afterwards
2020-07-01 14:23:09 <Ariadne> if we replace busybox it would be with something whose maintainer we can depend on
2020-07-01 14:23:42 <superduck> based on that logic using version 1 of Alpine vs another more maintained distro is illogical
2020-07-01 14:23:48 <Ariadne> apk-tools is GPL, by the way.  will you wish to replace it?
2020-07-01 14:23:57 <Ariadne> because we are not going to change the license
2020-07-01 14:24:22 <Hello71> also of course linux kernel
2020-07-01 14:24:27 <Hello71> you can switch to fuchsia if you want
2020-07-01 14:24:34 <superduck> I said GNU project, not GPL.
2020-07-01 14:24:37 <tehcloud> there is nothing wrong with using a GNU license
2020-07-01 14:24:41 <Ariadne> busybox is not part of the GNU project
2020-07-01 14:24:48 <tehcloud> GNU software on the other hand...
2020-07-01 14:24:54 <superduck> Busybox also is incomplete for a functional system.
2020-07-01 14:25:05 <Hello71> I think it had some infrastructure on nongnu at some point?
2020-07-01 14:25:08 <superduck> It's not bad and it gets you mostly there.
2020-07-01 14:25:13 <Ariadne> so is toybox and it comes with an undependable maintainer
2020-07-01 14:25:22 <superduck> toybox is advocating for a complete minimal userland in a single binary
2020-07-01 14:25:29 <Ariadne> great
2020-07-01 14:25:47 <Ariadne> when they have it AND landley demonstrates that he can commit to an acceptable level of maintenance of it, we can talk about it
2020-07-01 14:25:48 <tehcloud> mature codebases with reliable track records have their value though :)
2020-07-01 14:26:31 <mps> and not make changes for ideological reasons
2020-07-01 14:26:33 <Ariadne> right now reaching landley is basically praying that you can find him on #musl
2020-07-01 14:26:48 <Ariadne> or firing off an email and waiting months
2020-07-01 14:26:51 <afontain_> superduck: ls -l /bin/ls
2020-07-01 14:26:52 <afontain_> /bin/ls -> ../usr/bin/coreutils
2020-07-01 14:27:04 <superduck> afontain_: I don't have that on my system
2020-07-01 14:27:09 <Ariadne> and yes, i made coreutils behave as busybox a long time ago ;)
2020-07-01 14:27:28 <afontain_> superduck: I mean, technically, coreutils is a single binary as well
2020-07-01 14:27:29 <afontain_> and a complete system
2020-07-01 14:27:34 <afontain_> (or at least for some binaries)
2020-07-01 14:27:44 <Hello71> if you really care that much about busybox you can fork alpine and just s/busybox/toybox/g. make alpinuan
2020-07-01 14:28:15 <jcdl> lol
2020-07-01 14:28:30 <Ariadne> there is also the part where there are tons of alpine users dependent on busybox behavior of some applets
2020-07-01 14:28:36 <superduck> coreutils is not posix compliant so developing with it introduces idiosynchrocies in your output
2020-07-01 14:28:45 <Ariadne> posix is stupid in 2020
2020-07-01 14:28:47 <Ariadne> next
2020-07-01 14:29:59 <superduck> Can we brand the Alpine website with that?
2020-07-01 14:30:00 <Ariadne> also export POSIXLY_CORRECT=1
2020-07-01 14:30:03 <Ariadne> sure
2020-07-01 14:30:32 <xorex> mps: i made that MR, just curious :)
2020-07-01 14:30:48 <Ariadne> superduck: alpine community focuses on practicality.  this means, not breaking people, using software where we can depend on upstream to be there if there is a problem
2020-07-01 14:30:52 <xorex> mps: do you mean that the package is only meant for Docker installs?
2020-07-01 14:30:58 <Ariadne> this does not mean strict POSIX conformance
2020-07-01 14:31:04 <mps> xorex: I presumed that, but was not sure :)
2020-07-01 14:31:48 <Ariadne> if you concluded our use of musl was because of its POSIX strictness, the reality is that we prefer musl because it is small, lightweight and provides high quality libc implementation
2020-07-01 14:31:53 <mps> xorex: no
2020-07-01 14:32:01 <Ariadne> the POSIX strictness is actually something that we are not thrilled about
2020-07-01 14:32:12 <superduck> ariadne: I like musl because it's not part of the GNU project.
2020-07-01 14:32:22 <Ariadne> great
2020-07-01 14:32:25 <tehcloud> superduck, what turns you off from GNU?
2020-07-01 14:32:25 <mps> I thought it is for 'creating' dockers with s6 tools
2020-07-01 14:32:34 <Ariadne> that has nothing to do with why we use it
2020-07-01 14:32:42 <Ariadne> if musl was part of GNU we would still use it
2020-07-01 14:33:00 <superduck> tehcloud: largely the license making it difficult to include in sub-projects without license compliance hell indefinitely.
2020-07-01 14:33:15 <Ariadne> but other alpine components
2020-07-01 14:33:21 <Ariadne> are licensed under the same license
2020-07-01 14:33:28 <Ariadne> we're not going to change the apk-tools license
2020-07-01 14:33:39 <Ariadne> and it is GPL-2-only
2020-07-01 14:33:50 <Ariadne> which is even worse for you
2020-07-01 14:34:25 <superduck> I prefer GPL-2.
2020-07-01 14:34:40 <tehcloud> superduck, I'm with you there for some things, but other things are not meant to become sub-projects
2020-07-01 14:34:59 <superduck> GPL3 is infectious, and at least Alpine tools don't need to be extended to be license compliant.
2020-07-01 14:35:06 <tehcloud> I'm a fan of the MPL 2.0 personally
2020-07-01 14:35:09 <Ariadne> GPL2 is infectious
2020-07-01 14:35:16 <mps> xorex: as I commented in MR, I would like if someone with better knowledge than me about dockers creation process can review it before merging
2020-07-01 14:35:35 <Ariadne> if you think GPL3 is somehow more infectious than GPL2 i strongly suggest talking to an intellectual property lawyer
2020-07-01 14:35:59 <Ariadne> (i helped to draft the GPL3 license incidentally)
2020-07-01 14:36:07 <xorex> mps: alright, thanks for checking though :)
2020-07-01 14:36:18 <mps> xorex: and it was pleasure to read that you intend to maintain pkg and keep it in good shape
2020-07-01 14:37:19 <superduck> ariadne: I'm thinking lgpl, so you're probably right about GPL2 v GPL3 with GPL2 being more draconian.
2020-07-01 14:37:41 <Ariadne> GPL2 does not even let you link against OpenSSL (we grant an exception in apk-tools for this)
2020-07-01 14:37:51 <Ariadne> GPL3 does let you link against OpenSSL
2020-07-01 14:38:34 <Ariadne> the reason why people spread FUD about GPLv3 is because it requires that if you hold software patents on the product you are developing that you let your software users have a patent grant
2020-07-01 14:38:47 <Ariadne> this is the same requirement as Apache-2 license incidentally
2020-07-01 14:39:02 <Ariadne> and it is to protect the free software community from patent litigation
2020-07-01 14:40:40 <mps> IANAL, but opposing GPL smells like corporations agenda
2020-07-01 14:41:02 <Ariadne> yes, basically.  they don't want to give patent grants :)
2020-07-01 14:42:13 <superduck> I'm a fan of MIT-0.
2020-07-01 14:42:24 <Ariadne> i'm a fan of using licenses tactically
2020-07-01 14:42:48 <Ariadne> that means, what license for something is appropriate depends on that thing
2020-07-01 14:42:59 <superduck> 👍
2020-07-01 14:43:19 <ikke> Ariadne: for example applications vs libraries?
2020-07-01 14:43:38 <superduck> In this day and age, it's hard to distinguish them.
2020-07-01 14:43:40 <Ariadne> ikke: yes, and also strategic importance of those
2020-07-01 14:43:54 <Ariadne> ikke: for example, in pleroma, we released multiple libraries as AGPL :)
2020-07-01 14:44:08 <ikke> To protect against saas?
2020-07-01 14:44:11 <Ariadne> right
2020-07-01 14:44:18 <tehcloud> MPL 2.0 grants you the ability to do what you want as long as you keep those specific sources open
2020-07-01 14:44:21 <Ariadne> or more precisely, to protect our right to SaaS exclusivity
2020-07-01 14:44:28 <tehcloud> a nice middle ground between GPL and MIT/BSD style
2020-07-01 14:44:35 <jcdl> I really like MPL too
2020-07-01 14:44:39 <tehcloud> and not LGPL which has too much wording around libraries
2020-07-01 14:44:49 <tehcloud> and too much ideological masturbation
2020-07-01 14:44:50 <Ariadne> MPL and GPL-2 are incompatible
2020-07-01 14:45:01 <Ariadne> unfortunately
2020-07-01 14:45:15 <tehcloud> MPL 2.0 is compatible
2020-07-01 14:45:16 <Ariadne> except by way that MPL lets you explicitly use GPL-2 in place of MPL
2020-07-01 14:45:32 <tehcloud> yes, because of that clause
2020-07-01 14:45:41 <superduck> Back to the original points I was trying to get out, I think its problematic that mkinitfs and the default initramfs doesn't support rootfs systems as a default target to run from.
2020-07-01 14:45:54 <Ariadne> sure
2020-07-01 14:46:05 <Ariadne> and as long as you don't break any other usecase, we can add that
2020-07-01 14:46:43 <Ariadne> but we will continue to pick the best tools for our purposes, and ideology does not really fall into this
2020-07-01 14:46:54 <Ariadne> don't get me wrong, a lot of busybox is not great
2020-07-01 14:47:08 <Ariadne> i just don't think toybox is a replacement because if toybox breaks, we're screwed
2020-07-01 14:47:43 <Ariadne> we have several people familiar with busybox internals and we can fix busybox ourselves and get those fixes upstream basically immediately
2020-07-01 14:48:19 <Ariadne> working relationship is far more important than ideology to us
2020-07-01 14:49:08 <Ariadne> and besides, we already ship toybox in edge/testing anyway
2020-07-01 14:49:18 <Ariadne> so if you want to give it a go, you can
2020-07-01 14:50:11 <superduck> Well I'm covering 3 different items, mkinitfs rewrite, initramfs default rewrite, possible support for toybox instead of busybox.
2020-07-01 14:50:41 <Ariadne> the support exists to use toybox if you want to already
2020-07-01 14:50:50 <superduck> The issue with swapping toybox for busybox is I think the alpine packages depend explicitly on busybox, instead of generic *box virtual package provider
2020-07-01 14:51:02 <Ariadne> yes
2020-07-01 14:51:10 <Ariadne> because busybox has applets with specific behavior
2020-07-01 14:51:15 <Ariadne> that are non-standard
2020-07-01 14:51:32 <Ariadne> but very convenient for maintainer scripts
2020-07-01 14:55:06 <superduck>  Is anyone aware of a compressed tmpfs alternative in the kernel? zram creates a block device which makes it an indirect fit, I just want tmpfs with -o compression=zstd
2020-07-01 14:56:03 <superduck> Since I'm not getting any responses in #alpine-linux, why is my APKINDEX rebuild not working with early boot: I'm trying to rebuild the boottime apk index included with the iso, but I get this error on bootup: "package mentioned in index not found"
2020-07-01 15:16:49 <Ariadne> how are you rebuilding it.
2020-07-01 15:19:00 <superduck> Using this as reference: https://engineering.fundingcircle.com/blog/2015/04/28/create-alpine-linux-repository/
2020-07-01 15:19:34 <superduck> apk index -o /media/usb/apks/x86/APKINDEX.tar.gz /media/usb/apks/x86/*.apk
2020-07-01 15:20:08 <superduck> abuild-sign -k /etc/apk/keys/root@localhost-fingerprint.rsa /media/usb/apks/x86/APKINDEX.tar.gz
2020-07-01 15:20:28 <superduck> Then I'm including in my lbu and initramfs the keys under /etc/apk/keys.
2020-07-01 15:28:45 <maxice8> edge x86_64 builder is stuck with failed
2020-07-01 15:29:31 <mps> just thought to go out and enjoy real life but new kernel arrived (:
2020-07-01 15:32:09 <superduck> These instructions don't seem to produce a functional APKINDEX for me: https://wiki.alpinelinux.org/wiki/Apkindex_format
2020-07-01 15:55:45 <superduck> Is there a gitlab project for mkinitfs, or just the aport bundle?
2020-07-01 15:56:03 <ikke> there is
2020-07-01 15:56:12 <ikke> https://gitlab.alpinelinux.org/alpine/mkinitfs
2020-07-01 16:09:26 <Hello71> hm... is it just me or is gcc itself actually slower because of -Os
2020-07-01 16:17:12 <Cogitri> Hello71: Needs benchmarks, I guess
2020-07-01 16:23:36 <Ariadne> i'm not particularly opinionated either way -Os vs -O2
2020-07-01 16:24:13 <Ariadne> on older CPUs, -Os produces better code, but on today's highly pipelined x86 monstrocities -O2 is likely better
2020-07-01 16:24:37 <ikke> What about non-x86?
2020-07-01 16:36:23 <Hello71> needs benchmarks? :P
2020-07-01 16:42:22 <Hello71> alright, so I did a completely unscientific test building kernel 5.7.7 allnoconfig in a ramdisk. debian: ~30 seconds, alpine: ~45 seconds. ran both twice, seems like a few seconds off but definitely a wide gap
2020-07-01 16:43:09 <Hello71> both on Arch kernel, and with standard coreutils/util-linux, not busybox
2020-07-01 16:45:59 <Hello71> installing bash and gawk, alpine is still at 45 seconds. I think alpine kernel uses -Os, so building from disk there would probably be even more (absolute) difference
2020-07-01 16:46:41 <Hello71> Ariadne: actually x86 is less pipelined since core 2 compared to pentium 4 days
2020-07-01 16:47:01 <superduck> Is -Os still smaller these days?
2020-07-01 16:47:22 <Hello71> https://softwareengineering.stackexchange.com/questions/210818/how-long-is-a-typical-modern-microprocessor-pipeline
2020-07-01 16:48:06 <Hello71> says 14 since intel core, 15-25 on cortex a15
2020-07-01 16:49:20 <Hello71> according to https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures more recent arms are 13-stage
2020-07-01 16:49:21 <alpine-meetbot> [WIKIPEDIA] List of ARM microarchitectures | "This is a list of microarchitectures based on the ARM family of instruction sets designed by ARM Holdings and 3rd parties, sorted by version of the ARM instruction set, release and name. ARM provides a summary of the numerous vendors who implement ARM cores in their design. Keil also provides a somewhat..."
2020-07-01 16:50:42 <Hello71> seems like this is a trend of microprocessor design, to go very deep on pipelines, then scale back later. it seems plausible that once a uarch gets started, there is a push for improved microbenchmark performance
2020-07-01 16:51:46 <Hello71> also clock speed back in pentium days, but hopefully that is less of a factor nowadays
2020-07-01 16:52:14 <mps> hmm, how I can edit/change git commit message though web UI for this !9828
2020-07-01 16:52:35 <Hello71> mps: I thought you were opposed to web ui
2020-07-01 16:52:49 <Ariadne> no
2020-07-01 16:53:02 <Ariadne> modern x86 is highly pipelined
2020-07-01 16:53:10 <Ariadne> even sandy bridge is 19 stages
2020-07-01 16:54:07 <mps> yes, I'm but till I found something useful for CLI I'm doomed to web :)
2020-07-01 16:54:24 <mps> I find*
2020-07-01 16:56:25 <Ariadne> zen too has 19 stage pipeline
2020-07-01 16:57:27 <Hello71> source? I'm not going through all 868 pages of intel optimization manual
2020-07-01 16:58:45 <Ariadne> netburst has 31 stages, but 19 is still quite high
2020-07-01 16:58:53 <Ariadne> datasheets
2020-07-01 17:09:32 <Hello71> I checked the intel optimization manual and sandy bridge datasheet, and neither has useful information. as far as I can tell, information about intel pipeline lengths comes from marketing materials and agner's testing
2020-07-01 17:14:58 <Hello71> furthermore, if 19 is 'monstrocity', then so is ARM 15-25, POWER8 17, and everyone else, so not only is it irrelevant to picking -O2 vs -Os, but it also seems to make the whole comparison rather meaningless; "high" compared to what
2020-07-01 17:35:18 <Hello71> for those who were asking about compression earlier, I just posted my (previous) benchmarks on lkml: https://lore.kernel.org/lkml/1588791882.08g1378g67.none@localhost/. something worth noting here is that zstd is still larger than xz, possibly in part due to lack of executable filter
2020-07-01 17:42:11 <superduck> I was asking about zstd for tmpfs instead of zram. zstd isn't aiming to be better than xz, it's aiming to be better than gzip at all compression levels
2020-07-01 17:45:20 <superduck> hello71: do you take into consideration decompression speed? zstd may not compress as much as xz, but the file copy time + decompression speed should beat xz
2020-07-01 17:48:39 <Hello71> hm. that's a good point, I didn't list the contents of the tar
2020-07-01 17:49:01 <Hello71> I provided compression and decompression data and graphs
2020-07-01 17:49:50 <Hello71> zstd was worse than gzip for me at medium compression levels for compression time. decompression time for zstd is ~constant so of course it is better
2020-07-01 17:56:56 <superduck> decompression happens more often than compression
2020-07-01 17:57:37 <superduck> For zram as swap, I use lz4 so that the compression is closer to cpu line speed than it is getting compression improvements, I'd rather a fast system with small compression wins, than slow with big compression wins
2020-07-01 18:08:08 <ikke> mps: you cannot modify commits through the web interface. You need to use interactive rebase on the cli
2020-07-01 18:09:46 <mps> uhm, I don't like to merge something with git commit msg as 'initial aport testing/notcurses 1.5.3-0 #99915'
2020-07-01 18:10:30 <superduck> I got dropped, where did the discussion on zstd packaging go?
2020-07-01 18:10:42 <superduck> Or was that for kernel compression?
2020-07-01 18:11:18 <ikke> superduck: nothing more since you left
2020-07-01 18:54:30 <Hello71> Cogitri: I took a closer look at this libtracker package. after examining the contained files, I realized that they are not stripped. simply rearranging subpackages to have $pkgname-dbg at the top results in the size decreasing from 4902912 to 1056768 for -Os and 5529600 to 1187840 for -O2
2020-07-01 18:55:48 <Hello71> and, interestingly, -O2 -fno-asynchronous-unwind-tables -fno-align-jumps -fno-align-functions -fno-align-loops -fno-align-labels -fno-prefetch-loop-arrays -freorder-blocks-algorithm=simple winds up being even smaller: 1003520
2020-07-01 18:59:07 <Cogitri> Huh, I'm pretty sure abuild always strips unless you specify !strip 🤔
2020-07-01 18:59:23 <Hello71> it does strip. from $pkgdir.
2020-07-01 18:59:23 <Cogitri> And with dbg it just splits them into a subpkg instead of just removing them entirely
2020-07-01 19:00:01 <Cogitri> So only after subpkgs have been created?
2020-07-01 19:00:17 <Hello71> https://gitlab.alpinelinux.org/alpine/abuild/blob/master/abuild.in#L1801: scanelf -R "$pkgdir"
2020-07-01 19:00:36 <Hello71> well... it works in the order of the subpackages list?
2020-07-01 19:01:10 <Hello71> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/tracker/APKBUILD
2020-07-01 19:02:03 <Cogitri> Ah, so -dbg needs to be specified before any other subpkg?
2020-07-01 19:02:22 <Cogitri> Interesting, that seems like a foot gun
2020-07-01 19:02:44 <ikke> same like that -static needs to be defined before -dev
2020-07-01 19:04:13 <Cogitri> That's annoying too, but at least it fails (although with a very bad error msg)
2020-07-01 19:05:58 <Hello71> rg -U --multiline-dotall 'subpackages="[^"]*lib[^"]*dbg[^"]*"': https://bpa.st/V2CA
2020-07-01 19:07:47 <Hello71> looks like it's basically a tossup: 9 packages do it wrong (lib.*dbg), and 14 packages do it right (dbg.*lib)
2020-07-01 19:08:31 <Hello71> musl is, I think accurately, counted as both right and wrong
2020-07-01 19:08:36 <Cogitri> Nice, could you submit a MR for that?
2020-07-01 19:11:27 <Hello71> I can't figure out what's wrong with musl though. dbg is before utils, but getconf, getent, and iconv are all not stripped on my machine
2020-07-01 19:13:33 <Hello71> ikke: any other rules you can think of while I'm reordering the subpackages?
2020-07-01 19:14:14 <ikke> no, -static was the only one I was aware of
2020-07-01 19:15:02 <Cogitri> maxice8: Can we maybe get a lint for that? ^
2020-07-01 19:16:48 <Hello71> I think for a POSIX version maybe do tr '\n' ' ' | grep 'subpackages="[^"]*lib[^"]*dbg[^"]*"'. also check that subpackages is either empty or uses double quotes (only one package currently uses single quotes)
2020-07-01 19:17:31 <Hello71> technically you could write another line checking single quotes but probably it is good to enforce double quotes for these fields which should not contain quotes anyways
2020-07-01 19:21:01 <Hello71> you could refine it by also checking "utils" and maybe excluding noarch packages
2020-07-01 19:22:17 <Cogitri> I don't think it's too problematic when the linter triggers in a few edge cases
2020-07-01 19:25:52 <Hello71> hm, this technically needs a pkgrel bump, doesn't it
2020-07-01 19:26:53 <ikke> yes
2020-07-01 19:27:00 <ikke> if you want it to take effect
2020-07-01 19:27:09 <ikke> But you can also defer it to the next rebuild
2020-07-01 19:30:20 <Hello71> eh, I already changed them to bump pkgrel. I think people will appreciate the vastly reduced disk usage (for that one package) more
2020-07-01 19:35:10 <Hello71> ok, all done. I skipped false positives of libs-static
2020-07-01 21:55:45 <maxice8> @Cogitri can't we fix that in abuild ?
2020-07-01 21:55:46 <maxice8> abuild should also not move *.a when there is a -static
2020-07-01 23:32:28 <godot> howdy. I am curious what the status of grub2 support is with Alpine Linux, sufficient to support a completely encrypted /boot partition? The threads I've been reading give conflicting results, as it looks like grub 2.06 has not yet been integrated into Alpine yet?
2020-07-01 23:54:51 <maxice8> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/53
2020-07-01 23:54:58 <maxice8> Can any of you interested in -dbg test this ?
2020-07-01 23:55:28 <maxice8> It now checks every directory under $pkgbasedir (which is $repository/$pkgname/pkg) separately
2020-07-02 00:56:37 <maxice8> Anyone with abuild access ? There are MRs that need to be merged
2020-07-02 01:00:02 <maxice8> Modified postcheck() so now it will return 1 only after all the errors are printed out, instead of the first error
2020-07-02 01:50:19 <Hello71> apparently most of the benefit of debian gcc was because of lto, not O2 :/
2020-07-02 01:50:57 <Hello71> why does alpine not do --with-build-config=bootstrap-lto? I could swear I read something about it somewhere but don't remember where
2020-07-02 01:57:40 <Hello71> something about gettext I think, or maybe that was unrelated
2020-07-02 02:03:04 <Hello71> is anyone interested in -O2 if it increases performance by 15% but increases size by 56%?
2020-07-02 02:05:02 <[[sroracle]]> alpine is pretty size focused so that sounds like a no-go to me
2020-07-02 02:06:23 <Hello71> is it?
2020-07-02 02:06:55 <Hello71> I kinda reckon that if you really focus on size to the exclusion of all else then you should use openwrt or buildroot or something
2020-07-02 02:10:38 <[[sroracle]]> with a trade off like that and given my historical experience with how alpine balances speed and size, i say size wins
2020-07-02 02:11:11 <[[sroracle]]> they are hard things to compare but 1.5x size is hard to justify with that much speed improvement...
2020-07-02 02:12:16 <[[sroracle]]> you could argue doing it on a case by case basis but you have to remember you're trying to disrupt the status quo so you want to make it easier for the devs, not harder :p
2020-07-02 02:12:26 <Hello71> let's say 30% then. I suspect that gcc is an outlier in this regard, although I haven't tested exhaustively
2020-07-02 02:12:44 <[[sroracle]]> let's say 100%
2020-07-02 02:12:52 <Hello71> I mean for the size
2020-07-02 02:13:14 <[[sroracle]]> do some benchmarks of real world applications, collect the results, and publish them. Otherwise it just seems anecdotal right now
2020-07-02 02:13:15 <Hello71> and also I would argue that whoever installs gcc shouldn't care about some megabytes of disk space, so it is really not a good benchmark to begin with
2020-07-02 02:13:54 <Hello71> that sounds like a lot of work, and I think there needs to be some agreement that a change is reasonable in the first place
2020-07-02 02:14:35 <Hello71> I want to measure the number of people coming out of the woodwork to complain that a 30% uncompressed code size increase will overflow their drives
2020-07-02 02:15:54 <[[sroracle]]> best way to do that is to post to the ML, then you will surely get lots of people coming out of the woodwork :p
2020-07-02 02:17:10 <Hello71> oh, I think I measured it wrong. O2 decreases the size by 56%, not increases. but it's because I also disabled all the non-C/C++ languages while compiling
2020-07-02 02:17:17 <Hello71> so... totally fucked that up
2020-07-02 02:17:24 <Hello71> I blame the gcc compilation taking hours
2020-07-02 02:17:34 <Ariadne> to the exclusion of all else, no
2020-07-02 02:17:41 <Ariadne> but 56% size increase is a no-go
2020-07-02 02:17:58 <Ariadne> it would have to be far more than a 15% increase to justify that
2020-07-02 02:22:47 <Hello71> ok, I did a less-stupid comparison of /usr/libexec/gcc/x86_64-alpine-linux-musl/9.3.0 and it works out to 14% increase for basically cc1+collect2+*lto* (i.e. not including cc1obj and d21, which I think should probably be in subpackages anyways)
2020-07-02 02:25:39 <Ariadne> and what do real performance numbers look like (say building linux-lts)
2020-07-02 02:26:48 <Hello71> I already tried building allnoconfig. I think that should be fairly close, but I can try linux-lts or linux-edge, or something else. I just wanted to get an idea of the opinion before diving into doing extensive benchmarks
2020-07-02 02:53:35 <Hello71> I will send the email now, and see how the responses go. if the general response is positive then we can discuss which benchmarks would be useful for Alpine users, or which packages should be targeted. for example, as I said, I think nobody should begrudge an extra 20 MB of disk usage on their C/C++ build machine, since that uses craploads of space already
2020-07-02 02:54:10 <Hello71> and hopefully nobody is installing gcc on their minimal iot devices or whatever
2020-07-02 06:10:22 <nmeum> ncopa: do you want to take a final look at the busybox upgrade to 1.32.0 !9659? otherwise I would just merge it shortly
2020-07-02 06:36:45 <ncopa> nmeum: thanks for taking care of busybox. i thikn you can push if you are sure that wget works with https
2020-07-02 06:37:48 <nmeum> I only tested it with ssl_client installed, that works
2020-07-02 06:37:59 <ncopa> that is what i mean
2020-07-02 06:38:13 <ncopa> push it! 👍
2020-07-02 06:38:50 <nmeum> alright. have to focus on $dayjob work for now, will push it later today :)
2020-07-02 06:39:38 <ncopa> same... my $dayjob has asked me to work on non-alpine stuff lately
2020-07-02 06:40:30 <mps> nmeum: it works fine about week on three of my machines
2020-07-02 06:40:39 <ncopa> Hello71: thanks for the CFLAGS testing, very nice!
2020-07-02 06:42:39 <ncopa> we have enabled -O2 in the past where it "makes sense"  09838439c042827adfa17b7cf387729c9bc03f71
2020-07-02 08:54:12 <mps> firefox 78 is new firefox-esr
2020-07-02 08:55:20 <ncopa> do we care about firefox-esr at all now that we have firefox in community?
2020-07-02 08:56:55 <ncopa> the original idea with firefox-esr was that it was too much maintenence work to provide security fixes for 6 months due to tight dependency to rust
2020-07-02 08:57:18 <mps> I have same question in my head
2020-07-02 08:58:04 <ncopa> i think we can save some work by dropping firefox-esr and only support firefox
2020-07-02 08:58:09 <mps> I think we don't need both in same repo
2020-07-02 09:00:05 <mps> but we have to check if firefox works on all currently supported architectures, not sure it works on armv7
2020-07-02 09:00:25 <mps> while -esr works
2020-07-02 09:04:24 <Cogitri> Some users might prefer esr though
2020-07-02 09:04:38 <Cogitri> And it's not too much additional effort since we have thunderbird and mozjs anyway
2020-07-02 09:04:49 <Cogitri> Which basically need the same changes during upgrades
2020-07-02 09:07:26 <ncopa> i dont mind as long as someone has time and energy to maintain it
2020-07-02 09:08:36 <Cogitri> J0WI does that fortunately
2020-07-02 09:10:20 <mps> from my experience in last few upgrade it was easy to upgrade -esr
2020-07-02 09:10:38 <mps> so, ok for me
2020-07-02 09:49:26 <ncopa> Cogitri: do you know what the status is for electron with musl? I'm interested in getting vscode running
2020-07-02 09:51:50 <mps> huh :D
2020-07-02 09:53:01 <mps> this sounds funny, run such big and heavy software on small and simple OS
2020-07-02 09:53:27 <mps> but, chromium and firefox are also big
2020-07-02 09:54:46 <ncopa> electron seems to be chromium
2020-07-02 09:55:07 <ncopa> i guess we should try upstream our patches for chromium
2020-07-02 09:58:22 <Cogitri> ncopa: I'm very interested in that too. It builds but unfortunately it SIGSEGVs during start
2020-07-02 09:58:45 <Cogitri> https://github.com/electron/electron/issues/9662#issuecomment-622114406
2020-07-02 09:59:01 <ncopa> did you set thread stack size?
2020-07-02 09:59:07 <ncopa> do you have a WIP APKBUILD?
2020-07-02 09:59:22 <Cogitri> Does -Wl,-z,stack-size do that?
2020-07-02 09:59:29 <ncopa> should do yes
2020-07-02 09:59:42 <ncopa> is it an executable?
2020-07-02 09:59:45 <Cogitri> !7310 for electron and vscode
2020-07-02 09:59:52 <Cogitri> <ncopa "is it an executable?"> Yup
2020-07-02 09:59:52 <ncopa> thanks
2020-07-02 10:00:02 <Cogitri> I think I set that, yes, but not sure anymore
2020-07-02 10:25:39 <mps> Cogitri: before closing this tab in my browser I think it could be interesting to you https://code.foxkit.us/adelie/packages/-/raw/master/user/firefox-esr/seccomp-time64.patch
2020-07-02 10:25:54 <mps> ofc, if you didn't looked already
2020-07-02 10:28:03 <Cogitri> Ah no, but I guess someone with musl 1.2 and 32-bit would have to test this
2020-07-02 10:28:32 <Cogitri> Currently running memtest on my computer because I'm getting really weird ICEs from GCC when compiling with many build jobs
2020-07-02 10:51:00 <godot> Hi again. I am trying to figure out what level of support Alpine Linux has for GRUB2 / grub 2.06, to facilitate a completely encrypted /boot partition? And in the event this is not a natively supported package, what issues there would be with pulling grub 2.06 manually during the install?
2020-07-02 10:54:56 <Cogitri> We do have grub in our repos, so I think  this should just work
2020-07-02 10:55:28 <Cogitri> I only have / encrypted and not /boot, so your mileage may v
2020-07-02 10:57:54 <godot> Thanks Cogitri. It looks like the most recent version in the main development branch is grub-2.04, from what I understand 2.06 is required for encrypted /boot. So if I were to pull and compile grub 2.06, how would that effect future updates? I am assuming I would have to blacklist grub from the update process in some fashion, which I am trying to avoid for obvious reasons.
2020-07-02 10:59:48 <godot> hmm and it looks like edge is still grub-2.04 as well
2020-07-02 11:04:53 <Cogitri> Well, you could try to update it to 2.06, confirm that it works and then make a merge request so that we use the new version too
2020-07-02 11:05:03 <Cogitri> It's easier to collaborate than to work against each other :)
2020-07-02 11:16:48 <godot> haha thanks Coqitri. I'll take a look into it. From what I understand LUKS1 is supported with grub-2.04 and with encrypted /boot support, just not LUKS2 without 2.06. So I'll report back with my findings.
2020-07-02 11:45:27 <Hello71> Cogitri: hopefully polkit switches to duktape and we can drop mozjs
2020-07-02 11:54:20 <Cogitri> That'd be nice, but with the current pace of polkit I doubt that that'll happen any time soon
2020-07-02 11:54:35 <Cogitri> They only upgraded to mozjs68 a few weeks ago :/
2020-07-02 12:29:30 <Cogitri> Alright, is someone else seeing GCC ICEs with many build jobs after upgrading? I just had two installs build things just fine only to start having SEGFAULTs in GCC after upgrades
2020-07-02 12:30:49 <Hello71> standard *FLAGS?
2020-07-02 12:31:05 <Hello71> -Os -fomit-frame-pointer
2020-07-02 12:31:08 <Cogitri> Yup and this rig worked fine a few weeks ago
2020-07-02 12:31:40 <Cogitri> Just upgraded after not using it for 2 weeks and suddenly it likes randomly fail at the weirdest things
2020-07-02 12:32:02 <clandmeter> ncopa: did you see my email about chromium
2020-07-02 12:32:10 <Cogitri> Spewing out syntax errors for mozjs68 with many build jobs (32) but works with 8 build jobs, wtf
2020-07-02 12:33:00 <mps> Cogitri: I can borrow armv7 from my son which have musl 1.2.0 on it, but build firefox on it with 4GB RAM and mmc card is nearly impossible I think
2020-07-02 12:34:30 <Cogitri> Might work with -j1 or -j2, but certainly isn't fun, no
2020-07-02 12:34:38 <mps> I think we should wait for musl 1.2.0 on edge, or maybe ncopa can try mentioned patch on newedge builders
2020-07-02 12:35:34 <mps> sure, it will work somehow with -j1 but I think 4GB is not enough for linking phase
2020-07-02 12:38:19 <Cogitri> Possibly, yes
2020-07-02 12:51:24 <telmich> Good evening. I've code a first version of an init script for wireguard. I assume I should create a merge request against aports the `wireguard-tools` package. I've done that at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9874 and would appreciate and feedback. The sha512sum is omitted intentionally, as I first wanted to hear what you think about the init script
2020-07-02 13:14:33 <Hello71> Cogitri: do you think we should just patch abuild to not require special order in this case?
2020-07-02 13:14:36 <Hello71> or should I make a tracking issue
2020-07-02 13:16:55 <Cogitri> I think it's best to remove that foot gun from abuild
2020-07-02 13:17:04 <Cogitri> Because this is bound to happen again
2020-07-02 13:17:16 <Cogitri> Maybe we should also make sure -static is before -dev
2020-07-02 13:17:52 <mps> no, we should remove -static, for libs
2020-07-02 13:18:13 <Cogitri> And move everything to -dev ?
2020-07-02 13:18:19 <mps> yes
2020-07-02 13:18:30 <mps> you are at my side :)
2020-07-02 13:18:40 <Cogitri> Sounds good to me, I'm not sure why we added -static actually
2020-07-02 13:18:55 <Cogitri> I mean I guess it makes -dev packages a bit lighter but that doesn't sound too relevant to me?
2020-07-02 13:19:01 <ikke> someone pushed that change :)
2020-07-02 13:19:20 <mps> Cogitri: yes, I argue for this long time
2020-07-02 13:19:55 <mps> only for static binaries -static makes sense
2020-07-02 13:19:58 <Cogitri> mps: Time to make a post on the devel ML so we can discuss this then :)
2020-07-02 13:20:40 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/commit/b849aae4b9bd431002935c7bed45024bdd4e9c88
2020-07-02 13:20:46 <mps> Cogitri: nice, will you do hard work to write mail or I will write short one
2020-07-02 13:21:21 <Cogitri> mps: Would be best if you can do that, currently still trying to figure out what's wrong with my computer
2020-07-02 13:21:36 <mps> btw, I thought to raise this for announced alpine conference
2020-07-02 13:22:39 <mps> Cogitri: ok, I will try, I'm not so good to write anything good in English, but...
2020-07-02 13:26:41 <mps> telmich: I think you didn't added -openrc subpkg
2020-07-02 13:52:32 <telmich__> mps: ahhh... true, thanks for the pointer, will fix that!
2020-07-02 13:53:31 <mps> and license in script is missing
2020-07-02 13:54:16 <mps> and you can mark MR with WIP tag instead of not adding shasums
2020-07-02 13:55:56 <mps> commit msg should be 'community/wireguard-tools: add init.d script'
2020-07-02 14:49:10 <Hello71> while I'm messing with default_dbg, should we add --compress-debug-sections?
2020-07-02 14:49:27 <Hello71> I guess I should check how Arch does it
2020-07-02 14:50:01 <Hello71> hm, they don't compress
2020-07-02 14:52:04 <mps> Hello71: rhetorical question and not only to you (and to me also), why we look how other distros do things
2020-07-02 14:52:18 <Hello71> NIH is bad
2020-07-02 14:52:57 <mps> well, not NIH, but how we can improve things for alpine
2020-07-02 14:53:16 <Hello71> if everyone does things one way and you do it another way, you should consider why you are doing it. in some cases you may have a good reason, in other cases maybe you should reconsider your decision
2020-07-02 14:53:42 <mps> yes, that is good thinking imo
2020-07-02 14:54:42 <ikke> You may also learn from mistakes from others
2020-07-02 14:54:51 <mps> btw, are you native English speaker
2020-07-02 14:54:53 <Hello71> for example in this case I think maybe we can justify --compress-debug-sections when other distros don't because we are less focused on proprietary compatibility (e.g. musl instead of glibc) and we are more focused on size
2020-07-02 14:55:14 <Hello71> me? sort of, but I listen to enough non-native speakers that sometimes I pick up their habits
2020-07-02 14:55:59 <mps> Hello71: yes, you. you type and I understand you quite good
2020-07-02 14:56:24 <mps> type fast*
2020-07-02 14:56:37 <mps> (not slow like me :) )
2020-07-02 14:57:17 <Hello71> thanks. I think it is hard to write both fast and good, and I think often I lean too fast and not enough good. but I think this is the same in any language, not just English
2020-07-02 14:57:35 <mps> and, --compress-debug-sections sounds as good idea, to test at least
2020-07-02 14:58:52 <mps> heh, not good everything you write but I understand you good
2020-07-02 14:59:24 <mps> hmm, undesrtand well*
2020-07-02 15:02:23 <Hello71> Gentoo has it as a FEATURE, but I think it is off by default. I think the risk of enabling it system-wide is only that some non-debugger programs or old debuggers cannot understand it. for example some program crashes and the backtrace just shows ???. afaik gdb and lldb and modern libunwind should be able to unpack it, so then the only cost is slightly slower debugger loading
2020-07-02 15:05:03 <mps> I noticed ??? already for some programs when crash id gdb
2020-07-02 15:06:30 <Hello71> well obviously I am assuming you installed all relevant dbg packages
2020-07-02 15:06:53 <mps> anyway, between all features (size, speed etc) I prefer correctness
2020-07-02 15:07:07 <mps> Hello71: yes, sure
2020-07-02 15:09:10 <mps> last ??? was when debuging rng-tools and reporting segfault upstream
2020-07-02 15:09:30 <Hello71> well it can also be caused by stack corruption
2020-07-02 15:09:51 <Hello71> turns out I was wrong, libunwind only supports zlib debug info since Sept 2019: https://github.com/libunwind/libunwind/commit/a36ec8cfdb8764e4f8bf6b16a149a60ea6ad038d
2020-07-02 15:10:13 <Hello71> I will send a proposal email and see what people think
2020-07-02 15:14:15 <maxice8> Hello71 (IRC):  can i get confirmation you're working on reworking default_dbg for abuild ?
2020-07-02 15:14:37 <Hello71> yes, I am working on it now. I was just thinking about adding --compress-debug-sections
2020-07-02 15:14:53 <Hello71> I also set the various PRs as WIP for now
2020-07-02 15:15:31 <Hello71> uh
2020-07-02 15:15:49 <Hello71> not sure how that's possible
2020-07-02 15:19:19 <Hello71> maxice8: I think there is something wrong with your IRC client. not sure it's possible to ping timeout 3 minutes before sending a message
2020-07-02 15:20:01 <maxice8> I use riot.im with matrix<->IRC bridge
2020-07-02 15:21:53 <Hello71> yeah. I think maybe it is buggy. not sure though, could be buggy freenode too
2020-07-02 15:27:01 <PureTryOut[m]> maxice8: are you using Cogitri's bridge then? As for me it seems like you're using IRC
2020-07-02 15:27:16 <maxice8> Yes, I am using Cogitri's bridge and hosted Matrix instance
2020-07-02 15:27:35 <Hello71> ~maxice8ma@cogitri.dev
2020-07-02 15:28:46 <Cogitri> Hello71: Huh, what's broken?
2020-07-02 15:29:02 <Hello71> dunno, just wondering why maxice8 had a ping timeout
2020-07-02 15:29:33 <Hello71> it's strange because from my view they sent me a message 1 minute before receiving 4.5 minutes ping timeout
2020-07-02 15:45:10 <Cogitri> Huh
2020-07-02 15:45:10 <Cogitri> That's weird indeed
2020-07-02 15:45:19 <Cogitri> I just upgraded the matrix bridge to a new version, maybe it didn't like that
2020-07-02 16:27:37 <nmeum> will push teh busybox upgrade now
2020-07-02 16:36:48 <nmeum> done, build passed
2020-07-02 16:46:48 <mps> +1
2020-07-02 17:04:52 <Hello71> hm, has zstd compression for apks been discussed yet? benefit is vastly improved compression ratio, drawbacks are additional dependency and potentially increased memory usage
2020-07-02 17:05:16 <Hello71> I saw there was three mails 8 months ago that seem to have been ignored
2020-07-02 17:17:28 <Cogitri> apk already isn't too light on memory usage :/
2020-07-02 17:21:35 <Hello71> zstd decompression speed is excellent, even better than gzip in my testing
2020-07-02 17:25:50 <Hello71> hm... actually zstd might not help that much with default package set
2020-07-02 17:49:01 <Hello71> alpine-base + deps: storage: 3100k gzip, 2952k zstd -9, 2716k zstd -19, 3564k lz4. decomp: 0.18s+2448k gzip, 0.03s+18448k zstd -9, 0.04s+22128k zstd -19, 0.01s+26976k lz4 --best
2020-07-02 17:58:49 <Hello71> zstd -19 --long=10 is 3836k and 0.12s+8336k, so definitely not a good option
2020-07-02 18:20:21 <Hello71> oh, I should probably test it with mallocng, not glibc malloc...
2020-07-02 18:21:51 <Hello71> eh, basically the same. I guess they probably malloc large chunks
2020-07-03 07:10:59 <ncopa> we have considered other comperssions a few times in the past. IMHO gzip is a good option because even if it not the best in anything, it is also not worst
2020-07-03 07:16:32 <Cogitri> Doesn't xz have a way better compression ratio usually?
2020-07-03 07:16:34 <ncopa> performance is not the best but it is acceptable, that is for both decompression and compression
2020-07-03 07:17:11 <ncopa> compression ratio is not best either with gzip, but it is not the worst either, it is acceptable
2020-07-03 07:17:56 <Cogitri> Yup, it's just that going from xz to gzip seems like a downgrade for me
2020-07-03 07:18:08 <ncopa> i think gzip is good all-round
2020-07-03 07:21:47 <markand> hi there
2020-07-03 07:22:31 <markand> someone has an idea why this package fails about bash-completion? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9123
2020-07-03 07:24:44 <Cogitri> Seems like the bash-completions aren't in the place it expects them to be
2020-07-03 07:25:26 <Cogitri> Also, FWIW no one got a notification for the comment you made on the MR, you were the only participant in that
2020-07-03 07:25:38 <Cogitri> So it's best to ask here :)
2020-07-03 07:26:01 <markand> :D
2020-07-03 07:26:04 <Cogitri> Or if someone else has participated in the MR it's of course OK to ask there too since then someone will get an email for that
2020-07-03 07:26:11 <markand> yes but, some people look at the MR :p
2020-07-03 07:27:24 <Cogitri> Well, it has the mr-build-broken label and CI is still failing, I usually don't look at those and wait for the contributor to fix the build and then ping me back
2020-07-03 07:28:29 <Cogitri> Anyway, about your problem: I don't see the package installing bash-completions so I guess you could just remove the subpkg
2020-07-03 07:34:28 <markand> hmmm, can't remember why I got a warning that asked me to install thenm
2020-07-03 07:34:34 <markand> I mean, to add the subpkg
2020-07-03 07:34:37 <markand> it builds now
2020-07-03 07:43:44 <mps> gzip for 'normal' use cases is best middle ground ime, though I keep some archives in xz
2020-07-03 07:48:24 <markand> the major issue is that busybox xz only supports decompressing
2020-07-03 07:49:12 <markand> having to use a non-busybox supported algorithm I'd suggest zstd
2020-07-03 07:49:30 <markand> https://www.archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/
2020-07-03 07:49:33 <markand> 1300% speedup
2020-07-03 07:51:37 <mps> on a single cpu?
2020-07-03 07:57:50 <ncopa> zstd-libs is 900k
2020-07-03 07:58:22 <ncopa> apk-tools is 262k
2020-07-03 08:01:03 <Cogitri> And I think apk is already crazy fast
2020-07-03 08:11:47 <clandmeter> ncopa: would still be cool to have some benchmarks between standards.
2020-07-03 08:12:17 <clandmeter> i dont mind 900k extra if apk gets 3x faster.
2020-07-03 09:09:30 <ncopa> i dont think apk will get 3x faster
2020-07-03 09:09:58 <ncopa> the way it is designed now, it decompresses while waiting for network io
2020-07-03 09:22:29 <mps> timlegge: ping
2020-07-03 11:04:01 <timlegge> hi
2020-07-03 11:04:53 <timlegge> mps: whats up?
2020-07-03 11:07:30 <mps> timlegge: I follow you great work on packaging perl modules and utils for alpine
2020-07-03 11:08:09 <timlegge> no problem.  Needed them for a Docker container I support :-)
2020-07-03 11:08:56 <mps> I have some in my local repo and want to add them to aports, but in case I need help can I count on you
2020-07-03 11:10:45 <mps> actually for now I'm thinking to add perl-pdf-api2 only, but it need a lot of testing modules
2020-07-03 11:10:52 <timlegge> sure.  abuild/apkbuild-cpan create PERL::MODULE::NAME works pretty well but ping me if you need a hand
2020-07-03 11:11:25 <mps> yes, I used apkbuild-cpan about 3 years
2020-07-03 11:12:29 <mps> side note, this perl test deps insanity makes me irritated sometimes
2020-07-03 11:13:48 <mps> timlegge: ok, thanks. I will start in a day or two to add them one by one
2020-07-03 11:13:55 <mps> see you :)
2020-07-03 11:15:25 <mps> as I switched my business workstation to aarch64 I see 'a lot' issues which needs to be fixed
2020-07-03 11:16:14 <timlegge> yeah looks like a few of them to be added.  I am away this weekend but if I have some time I can take a look at a few of them
2020-07-03 11:17:08 <mps> I have PDF::API2 build apk but without check
2020-07-03 11:17:45 <mps> it works quite good for about year on alpine
2020-07-03 11:18:49 <mps> ( I should push to testing  whatever I made locally and tested that they works)
2020-07-03 11:20:56 <mps> for example I have st term with patches to be HHK friendly (and some other nice patches) but hesitate to push it for more than a year
2020-07-03 11:38:26 <timlegge> yes nothing tests my APKBUILDs quit like the gitlab tests.  I push everything because someone else mi GB ht need it and my Docker project needs to download it. Using cpan to build for a docker container is painful
2020-07-03 12:20:54 <hc-hmk> Is Milan Kupcevic also a maintainer on Alpine? We'd like to have simavr in repos, but it's kinda difficult to get people to adopt new projects.
2020-07-03 12:22:19 <hc-hmk> He's maintaining the package in Debian repos. His handle on github is buserror.
2020-07-03 12:23:29 <ikke> I cannot find him as maintainer in the repos
2020-07-03 12:23:53 <ikke> https://pkgs.alpinelinux.org/packages has a list of all maintainers
2020-07-03 12:25:44 <hc-hmk> OH, I did not know that
2020-07-03 12:26:29 <mps> simavr is avr simulator?
2020-07-03 12:26:37 <hc-hmk> Yup
2020-07-03 12:26:57 <hc-hmk> Does anyone want to adopt it? I'm fairly sure I can get my project manager to take take on maintaining simavr in alpine repos, but we'll drop support as soon as it stops being useful for us.
2020-07-03 12:27:00 <mps> I made it locally about 2 years ago on alpine
2020-07-03 12:27:39 <mps> have to look in my archives if I can make aports
2020-07-03 12:27:46 <hc-hmk> I've done that aswell just now. Build procedure is literally just typing make in a terminal.
2020-07-03 12:27:59 <mps> on alpine?
2020-07-03 12:28:19 <hc-hmk> Note that gcc-9.2.0 complains about strncpy truncation, which buserror needs to fix
2020-07-03 12:28:23 <hc-hmk> Yup
2020-07-03 12:28:52 <hc-hmk> git clone <url> ; cd * ; make
2020-07-03 12:30:04 <mps> iirc, it needs some fixes to actually work
2020-07-03 12:31:08 <hc-hmk> I dunno man, it seems to work just fine for me. We have a +3 line patch that supresses an error about strncpy, but that's about it.
2020-07-03 12:32:11 <mps> good, you can create MR and I will look at it, maybe even merge
2020-07-03 12:32:22 <mps> and, you will be maintainer
2020-07-03 12:32:42 <mps> I hope you will care for it :)
2020-07-03 12:33:02 <hc-hmk> A MR for which repository? Also, be advised that we will stop caring about the package in a few years when it stops being useful-
2020-07-03 12:34:26 <mps> hmm, put it in testing repo and we will see
2020-07-03 12:35:34 <hc-hmk> I cant find a git repository named testing. Can you clarify?
2020-07-03 12:36:24 <mps> gitlab.a.o
2020-07-03 12:36:35 <mps> then aports project
2020-07-03 12:37:20 <mps> you will see few, main, community, testing, non-free and unmaintained
2020-07-03 12:37:20 <ikke> hc-hmk: the aports testing repository in the aports git repository :)
2020-07-03 12:39:34 <hc-hmk> Thank you. I haven't introduced a project to repos before, so this is new.
2020-07-03 12:40:36 <mps> ok, just tell here when you create it and note me, someone will look at it
2020-07-03 12:41:23 <mps> though I'm busy with nightmare called 'printing on unix', but will look for sure
2020-07-03 12:43:38 <hc-hmk> Oh, like physically printing out paper using a consumer HP InkJet thing? That's a terrible experience on linux.
2020-07-03 12:44:14 <mps> laserjet, but same experience
2020-07-03 12:45:59 <hc-hmk> Scotch helps, but it's still more painful than just spinning up a Win10 VM. That's what I've resorted to.
2020-07-03 12:46:45 <ikke> You use scotch to light the printer on fire? :P
2020-07-03 12:46:58 <mps> actually, I did it successfully two years ago, but have to repeat it today
2020-07-03 12:47:05 <hc-hmk> Half for the printer, half for the dev?
2020-07-03 12:47:30 <mps> ? don't understand
2020-07-03 12:48:38 <hc-hmk> Sorry, replying to ikke. I'd use half a bottle to light the printer on fire, half to drink. Anywho, what do you need printer drivers for anyway? Do you use Alpine on desktop?
2020-07-03 12:49:04 <mps> ofc :)
2020-07-03 12:49:33 <mps> everywhere,not only in desktop
2020-07-03 12:50:59 <hc-hmk> Interesting. We run Debian for our devteams desktops. Alpine desktop experience is subpar imo.
2020-07-03 12:52:58 <mps> it depends, for me debian is subpar, and I used debian more than 20 years
2020-07-03 12:54:16 <hc-hmk> Fair enough. I think it mainly depends on usecase.
2020-07-03 12:56:37 <mps> heh, printer nightmare is over :)
2020-07-03 12:58:43 <hc-hmk> It'd like know know what ncopa
2020-07-03 12:59:00 <hc-hmk> 's hourly wage is. I think we'd like to commission him.
2020-07-03 12:59:53 <mps> I doubth, he doesn't work for money but for pleasure ;)
2020-07-03 13:00:36 <hc-hmk> That's unfortunate. We'd like to compromise on a new mkinitfs. We need some features, but it also needs to comply with what Alpine as a whole wants it to do.
2020-07-03 13:02:15 <mps> keep in mind that alpine is community project and no one can easily 'compromise' anything
2020-07-03 13:03:03 <hc-hmk> I know it is a community project, but the package maintainer has final say over their package, I'd assume.
2020-07-03 13:03:48 <mps> for example I arguing two years about removal -static libs subpkg but without any luck still
2020-07-03 13:04:14 <Hello71> Cogitri: xz is a lot slower. you can see in my kernel compression benchmarks, it adds 100s of ms to boot time on fast computers with small kernels. I didn't test xz compression, but it's easy enough, just do xz -9k *.apk; time xz -dc *.apk.xz >/dev/null
2020-07-03 13:04:16 <mps> no, even package maintainer doesn't have 'last word'
2020-07-03 13:04:52 <Hello71> I think even with just alpine-base it will add up to more than a second on a slow machine
2020-07-03 13:05:08 <Hello71> ncopa: that's true, I was thinking more of lbu
2020-07-03 13:05:42 <mps> hc-hmk: we are trying to reach some kind of consensus for every big change
2020-07-03 13:06:23 <hc-hmk> Hello71: We gained a lot from using lz4 for initramfs. I suspect lz4 would yield big gains on apk/lbu aswell.
2020-07-03 13:07:54 <Hello71> I think so far it is agreed in alpine that overly protective maintainers are bad. I think this is good, otherwise you get Gentoo where packages go so out of date and obsolete. even Debian has this problem already, with their huge manpower
2020-07-03 13:08:55 <Hello71> hc-hmk: doesn't initramfs default to xz, not gzip
2020-07-03 13:09:18 <mps> Hello71: gz
2020-07-03 13:09:41 <Hello71> hm. what about kernel? I think that's xz now?
2020-07-03 13:09:55 <Hello71> oh, it is gzip
2020-07-03 13:09:59 <mps> yes
2020-07-03 13:10:16 <Hello71> hopefully zstd kernel will be upstreamed soon
2020-07-03 13:10:26 <hc-hmk> Hello71 Alpines mkinitfs takes either xz or gzip but we patched in lz4. Support is built into kernel since 5.x
2020-07-03 13:10:51 <Hello71> hc-hmk: I thought lz4 was supported even before then?
2020-07-03 13:11:04 <hc-hmk> Maybe so, I honestly don't know.
2020-07-03 13:11:24 <hc-hmk> Hello71 why do you want zstd for read-only things?
2020-07-03 13:11:48 <HRio> should the release notice not be more clear on that that python package must be deinstalled manually?
2020-07-03 13:11:56 <Hello71> I don't see any better options
2020-07-03 13:12:28 <hc-hmk> lz4 provides far superior decompression speeds than zstd. Is that not the goal?
2020-07-03 13:12:32 <HRio> having it installed makes the update to python3 3.8.3 not "happen"
2020-07-03 13:12:33 <Hello71> xz is slow to decompress, lz4 has poor ratio, even with hc, brotli is not suitable
2020-07-03 13:13:21 <Hello71> there are lots of alternative compressors, but I don't want to pick some niche compressor that is not supported on most distros and will probably be unmaintained in a few years
2020-07-03 13:13:35 <andypost[m]> Moreover zstd x5 bigger compiled
2020-07-03 13:14:37 <Hello71> yes, it's true, there isn't any busybox zstd (yet)
2020-07-03 13:15:23 <mps> gz is still best size/speed
2020-07-03 13:15:35 <Hello71> no, zstd is usually better
2020-07-03 13:16:02 <Hello71> zstd has far faster decompression (compared to size) and usually has faster compression (also compared to size)
2020-07-03 13:16:07 <mps> yes, but zstd is still not mature enough to rely on it
2020-07-03 13:16:15 <Hello71> you cannot only look at default settings or maximum settings
2020-07-03 13:17:07 <hc-hmk> I'm not sure I agree with you mps. gzip is old, slow and usually only used because of its wide support. imo.
2020-07-03 13:17:10 <Hello71> zstd is 5 years old, it is already integrated in gnu tar, libarchive, man-db, etc. facebook maintains it, it will not go away any time soon
2020-07-03 13:18:15 <mps> 5 years is not long period
2020-07-03 13:19:09 <hc-hmk> That was the wrong part of the argument to look at. Is argument is wide adoption and huge first-party maintainer, not its age.
2020-07-03 13:19:29 <mps> and keep in mind vertical compatibility
2020-07-03 13:19:55 <mps> it is not so simple as it looks
2020-07-03 13:19:57 <Hello71> alpine switched to musl in 2014, "only" 3 years after initial release
2020-07-03 13:20:37 <mps> well, switching from uclibc is something else :)
2020-07-03 13:21:10 <Hello71> yes, switching libc is a much more significant change. logically you should require *more* "stability" for libc than some compression library
2020-07-03 13:21:18 <hc-hmk> Anyway, I think I'll drop out of this discussion for now. Thank you for the help with MRs and simavr mps and ikke.
2020-07-03 13:22:04 <mps> Hello71: well, to repeat: it is not so simple as it looks
2020-07-03 13:22:23 <Hello71> yes, I agree, it is not as simple as looking at age
2020-07-03 13:22:43 <mps> :)
2020-07-03 13:24:11 <mps> (distribution is not about new and shiny ideas and experiments but about stability, compatibility, usability ...)
2020-07-03 13:32:41 <ncopa> the problem with zstd is that code is 9x size, while not being 9 times better
2020-07-03 13:35:41 <HRio> added this https://wiki.alpinelinux.org/wiki/Talk:Release_Notes_for_Alpine_3.12.0
2020-07-03 13:37:58 <ncopa> what gzip has is: good compression size, good compression speed, good decompression  speed, good code size, good/wide general support and mature codebase
2020-07-03 13:38:16 <ncopa> but its not best at anything
2020-07-03 13:38:52 <ncopa> the last two points are not very important (in this context)
2020-07-03 13:39:53 <ncopa> any other other compression algorithm may be equally or better on most of those points, but always has one catch that is significantly (9x like)  worse
2020-07-03 13:40:48 <ncopa> HRio: may be worth create a ticket for it
2020-07-03 13:41:10 <mps> you forgot one bad point for those who trying to remove GNU :D
2020-07-03 13:42:20 <ncopa> you mean gzip being gnu?
2020-07-03 13:42:22 <mps> (but this discussion started to be boring)
2020-07-03 13:42:42 <mps> yes, GNU
2020-07-03 13:43:06 <mps> for some this is main reason for removal
2020-07-03 13:43:34 <ncopa> even that does not matter, because apk uses zlib
2020-07-03 13:44:30 <mps> ofc
2020-07-03 13:46:45 <HRio> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11714
2020-07-03 14:23:09 <Hello71> ncopa: compiling with ZSTD_LIB_MINIFY=1 ZSTD_LIB_DICTBUILDER=0 (keeping both compression and decompression support), zstd-libs drops from 396k/894k to 88k/183k.
2020-07-03 14:23:51 <Hello71> I also tested profile_base with zstd: drops from 10193358 bytes packed to 7754964 bytes with -19
2020-07-03 14:27:01 <afontain_> for the record, if zstd cause issues with old kernels, it will likely be pretty detrimental for postmarketOS
2020-07-03 14:27:13 <afontain_> we have some very old kernels, sometime even before 3.x
2020-07-03 14:28:40 <Hello71> afontain_: I mean, you can just build your own initramfs. probably you need to do so anyways for custom modules
2020-07-03 14:28:58 <Hello71> for kernel itself then obviously it will be compatible with itself
2020-07-03 14:29:15 <afontain_> if the supports is needed in userspace only, it's fine
2020-07-03 14:29:40 <afontain_> but people have been talking about kernel support, so I've been wondering
2020-07-03 14:30:01 <Hello71> zstd apk is completely unrelated to kernel
2020-07-03 14:30:34 <Hello71> kernel zstd is for kernel and initramfs. obviously kernel zstd must be compatible with kernel, and usually initramfs needs to match kernel modules anyways
2020-07-03 14:31:14 <Hello71> so only question is if mkinitfs will need to detect kernel support, but even if it doesn't then that is an easy override
2020-07-03 14:31:30 <afontain_> hmm, that's not the area I know well, but I think on arm, the bootloader need to decompress anyway
2020-07-03 14:31:40 <afontain_> we do have a custom initramfs by the way
2020-07-03 14:31:54 <afontain_> (well, actually two, because of size constraints)
2020-07-03 14:33:54 <Hello71> could be. I know on x86 the kernel is responsible for decompressing itself. not sure on other archs. but that is part of bootloader API/ABI
2020-07-03 14:34:42 <Hello71> same as not being able to use EFI on BIOS only machine or uboot only machine or whatever
2020-07-03 16:24:40 <telmich> I am wondering - where are all of you located at? eu / americas / asia / oceania / africa ?
2020-07-03 16:25:22 <Cogitri> I think most of the core dev team are from Europe
2020-07-03 16:26:13 <telmich> I somewhat thought so, but that might have been my bias being in the middle of europe
2020-07-03 16:26:54 <maxice8> Mostly Germany, Norway, Netherlands and South Netherlands/North France
2020-07-03 16:27:33 <mps> yes, and Brazil also :)
2020-07-03 16:27:58 <telmich> If you ever want do to a on-site-post-corona-times hacking week(end), give me a shout - I'm running the hacking villa in the mountains of Switzerland with dedicated fiber
2020-07-03 16:28:40 <afontain_> oh, hey from Switzerland
2020-07-03 16:29:44 <afontain_> nico: is that Glarus you are talking about?
2020-07-03 16:30:16 <telmich> It indeed is
2020-07-03 16:30:21 <afontain_> hmm, btw I noticed mps has a ungleich.ch matrix address
2020-07-03 16:30:51 <mps> afontain_: are you kidding with me
2020-07-03 16:30:58 <telmich> For me mps is via the IRC bridge from matrix
2020-07-03 16:31:22 <mps> heh
2020-07-03 16:31:40 <mps> no, I use irssi and connect to freenode
2020-07-03 16:32:19 <telmich> Wait.. gnugen? afontain do you know Timothee?
2020-07-03 16:33:02 <afontain_> I do
2020-07-03 16:33:04 <afontain_> 
ACTION uploaded an image: fractal-pasted-image (9KB) < https://matrix.org/_matrix/media/r0/download/gnugen.ch/SPYUoqfuPlbsOZAolrnXtMPk >

2020-07-03 16:33:21 <afontain_> it was nico's screenshot's fault :P
2020-07-03 16:34:02 <telmich> ahh.. it's only the notification
2020-07-03 16:34:10 <afontain_> seems I jumped to conclusion
2020-07-03 16:34:13 <MY-R> mps, you can hide your IP address if you want on irc
2020-07-03 16:34:29 <mps> MY-R: I know, but I don't care
2020-07-03 16:35:19 <MY-R> will start care when hit by some ddos :D
2020-07-03 16:36:07 <mps> well, I have big hammer and big gun for those who comes uncalled :)
2020-07-03 16:36:22 <afontain_> nico: "Wait.. gnugen? afontain do you know Timothee?" actually I may become the next sysadmin there
2020-07-03 16:36:36 <afontain_> though we may want to switch to the offtopic channel
2020-07-03 16:47:58 <telmich> I feel mps is being literal here (I imagine some mad max scenery)
2020-07-03 16:48:50 <mps> hehe ;)
2020-07-03 17:13:51 <telmich> Hmm, I think the upgrade broke my st
2020-07-03 17:14:52 <telmich> first it does not adhere to xresources anymore, secondly it seems that backspace is broken
2020-07-03 17:16:02 <telmich> It's actually quite "funny" behaviour: after pressing backpace it goes to the right and after about 10 backspace it does not print/move the cursor anymore
2020-07-03 17:16:22 <mps> patch I added is one I use and it works fine on all my boxes, armv7, aarch64 and (yesterday retired) x86_64
2020-07-03 17:21:00 <telmich> Going back to st w/o -xrdb makes backspace & co work again for me
2020-07-03 17:22:47 <mps> telmich: here is example of Xresources file https://github.com/dcat/st-xresources/blob/master/Xresources
2020-07-03 17:23:00 <mps> maybe this can help you
2020-07-03 17:23:32 <mps> and I don't think this patch touch backspace
2020-07-03 17:23:59 <telmich> I am only setting background/foreground/cursorColor/font; but colours are not applied anymore when I switch to st-xrdb 0.8.4
2020-07-03 17:24:56 <mps> hmm
2020-07-03 17:26:04 <nmeum> not sure if it's really a good idea to provide patched versions of suckless software in general
2020-07-03 17:26:34 <mps> it works for me
2020-07-03 17:27:55 <mps> nmeum: well, this is also my dilemma but I see '# Base-Contributor: Sören Tempel' in st-xrdb ;)
2020-07-03 17:28:06 <nmeum> that's because someone copied it from community/st :p
2020-07-03 17:28:42 <mps> ah, I thought that  Sören added it
2020-07-03 17:29:10 <nmeum> nope, b0adf7689056a69cf449a484a60f784ef8251287
2020-07-03 17:29:30 <mps> yes, I just looked
2020-07-03 17:30:26 <mps> but, anyway we add patches for some pkgs, so no big problem with st
2020-07-03 17:30:42 <nmeum> the problem with providing such patched version is: how do we decide which patches we allow and which patches we don't allow? the usual rule of thumb (in my experience) is that we don't add patches unless they fix some relability, build, or security issues
2020-07-03 17:33:33 <mps> I would like if we follow your 'rule of thumb', but as you probably know not all follow it
2020-07-03 17:34:52 <Hello71> is it that much work to patch it yourself? I guess the only problem is abuild patch management is not that simple (compared to debian for example)
2020-07-03 17:35:06 <nmeum> right, I would personally just try to keep deviations from this rule of thumb as small as possible
2020-07-03 17:35:39 <nmeum> I have a custom aports repo for patched version of some aports (include some suckless software)
2020-07-03 17:36:07 <mps> Hello71: it is not easy for casual user to combine all these st patches
2020-07-03 17:37:30 <mps> but we have more serious issues with relaxed merging than that
2020-07-03 17:37:50 <mps> but I will stop moaning here
2020-07-03 17:41:26 <maxice8> Casual people don't seem to be the target of st
2020-07-03 17:41:37 <maxice8> I just use branches to manage custom versions
2020-07-04 07:26:32 <mps> timlegge: are you break my machine and looking in my local branches :)
2020-07-04 07:26:51 <mps> I see perl-tk, which I also have locally
2020-07-04 07:28:45 <ikke> mps: that first sentence doesn't really parse :)
2020-07-04 07:29:15 <ikke> I guess you miss an 'into'
2020-07-04 07:29:23 <mps> ah, yes
2020-07-04 07:30:09 <mps> how I wrote it, it means something totally different :D
2020-07-04 07:31:48 <mps> but hm, context matters
2020-07-04 07:37:20 <ikke> maxice8: ldb fails on ppc64le
2020-07-04 07:37:35 <maxice8> unfortunate
2020-07-04 07:37:47 <ikke> Failed to connect to 'mdb://lmdb_free_list_test.ldb' with backend 'mdb': Unable to load ltdb cache records for backend 'ldb_mdb backend'
2020-07-04 08:02:58 <mps> is it good or bad that most of our initscripts licensed to '# Copyright 1999-2013 Gentoo Foundation'
2020-07-04 08:14:35 <ikke> depends on if they actually come from gentoo or not
2020-07-04 08:14:49 <ikke> If it's just boilerplate being copied over, then it's bad
2020-07-04 08:15:56 <mps> newapkbuild add them by default
2020-07-04 08:16:59 <ikke> I don't see it in the source
2020-07-04 08:18:18 <mps> hmm, true
2020-07-04 08:18:38 <mps> /usr/share/abuild/sample.initd
2020-07-04 08:19:01 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/sample.initd
2020-07-04 08:21:50 <mps> so, probably mostly blindly copied
2020-07-04 10:11:18 <mps> Cogitri: is it possible to build evince to not depend on gsettings-desktop-schemas and adwaita-icon-theme. and so:libgnome-desktop. not asking you to change that but to build it locally without these deps
2020-07-04 10:12:42 <nmeum> without certain schema files it may fail to start
2020-07-04 10:13:14 <nmeum> see 7595ce41b3121e9084d857b35a6c2d1bff3f29c2
2020-07-04 10:14:22 <mps> hmm, ok. I see
2020-07-04 10:15:45 <nmeum> can highly recommend mupdf if you are looking for a pdf reader without gnome dependencies ;)
2020-07-04 10:16:39 <mps> heh, I mostly use it, i.e zathura
2020-07-04 10:17:12 <mps> but sometimes would be nice to have evince for some 'special' pdfs
2020-07-04 10:20:59 <mps> huh, building evince I see this 'Executing networkmanager-elogind-1.24.2-r0.pre-install'
2020-07-04 10:21:10 <mps> (where we go)
2020-07-04 10:21:35 <Cogitri> mps: You can build it without the gnome-desktop dep by passing -Dthumbnail_cache=disabled to meson
2020-07-04 10:22:24 <mps> aha, thanks
2020-07-04 10:24:39 <Cogitri> I think you can just remove the adwaita-icon-theme dep from evince if you don't mind a few broken icons
2020-07-04 10:32:05 <mps> aha, ok. I don't mind icons. my awesome wm 'desktop' doesn't have any
2020-07-04 10:33:30 <Cogitri> It's more about icons in the application itself
2020-07-04 10:35:26 <mps> yes, I understand, but still prefer text even in apps.
2020-07-04 10:35:52 <mps> I dislike WIMP ui
2020-07-04 11:52:42 <timlegg26> mps: lol.  I had some time.  let met know if they test fine an I can move the to community at some point
2020-07-04 11:53:49 <mps> timlegg26: !9952
2020-07-04 11:54:38 <mps> heh, sorry for bothering you but I forgot that I already had everything ready in my local repo
2020-07-04 11:55:13 <mps> perl-pdf-api2 I made about year ago but forgot that is was easy
2020-07-04 11:56:08 <mps> at the same time I made statotcles (http://search.cpan.org/dist/Statocles/) which was real mess
2020-07-04 11:56:30 <mps> and I 'mixed' these two in my head
2020-07-04 11:58:39 <mps> and, no, I don't think we should package statotcles for alpine, but if someone want to do that I'm not opposing
2020-07-04 12:00:09 <mps> timlegge: thanks for packaging all these perl modules and tools
2020-07-04 12:06:13 <mps> clandmeter: (can the gitlab slap new contributors for their first MR with CODINGSTYLE.md and man APKBUILD) :)
2020-07-04 12:10:59 <Cogitri> Gitlab can display a "Please review the contribution guidelines" thingie upon opening a MR
2020-07-04 12:12:32 <Cogitri> ...Or is CONTRIBUTING.md only for issues?
2020-07-04 12:13:12 <mps> good, but some need 'slaps with big trout' :)
2020-07-04 19:25:09 <ikke> It's quiet..
2020-07-04 19:26:04 <mps> no more :)
2020-07-04 19:26:52 <ikke> :)
2020-07-04 19:27:59 <mps> I'm in garden and it is quiet around me now
2020-07-04 19:29:36 <mps> except one dog somewhere but not much loud or noisy
2020-07-04 19:31:35 <ikke> if that's the worst :)
2020-07-04 19:35:29 <mps> yes, this summer no mosquitoes for some unknown but good reason
2020-07-04 19:37:06 <ikke> I've seen some mosquitoes here
2020-07-04 19:37:22 <ikke> I've even been bitten
2020-07-04 19:37:40 <mps> please don't tell them where I live ;)
2020-07-04 19:37:43 <ikke> hehe
2020-07-04 19:56:53 <Cogitri> ikke: Can you make https://gitlab.alpinelinux.org/Cogitri/alpine-qa-bot public for me?
2020-07-04 19:57:18 <ikke> done
2020-07-04 19:57:21 <Cogitri> Currently working on a gitlab bot for things like automatic labeling
2020-07-04 19:57:23 <Cogitri> Thanks :)
2020-07-04 19:58:08 <ikke> yeah, figured
2020-07-04 19:58:11 <ikke> thanks
2020-07-04 19:58:24 <ikke> How is this bot working, with webhooks?
2020-07-04 20:01:21 <Cogitri> Yup, via webhooks
2020-07-04 21:04:18 <Ariadne> PureTryOut[m]: have you investigated why spectacle does not work on wayland yet
2020-07-04 21:23:20 <Ariadne> method call time=1593897763.464337 sender=:1.3906 -> destination=org.kde.KWin serial=104 path=/Screenshot; interface=org.freedesktop.DBus.Introspectable; member=Introspect
2020-07-04 21:23:20 <Ariadne> error time=1593897763.464350 sender=org.freedesktop.DBus -> destination=:1.3906 error_name=org.freedesktop.DBus.Error.ServiceUnknown reply_serial=104
2020-07-04 21:23:20 <Ariadne>    string "The name org.kde.KWin was not provided by any .service files"
2020-07-04 21:23:23 <Ariadne> hmmm
2020-07-04 21:26:04 <Ariadne> indeed, org.kde.KWin is not on d-bus
2020-07-04 21:31:02 <Ariadne> going to try an experiment
2020-07-04 22:44:21 <Hello71> ncopa: how come cc1plus, go1, f951, and *gnat* are in subpackages, but cc1obj and d21 aren't?
2020-07-04 22:45:25 <Ariadne> oversight
2020-07-04 22:45:45 <Hello71> seems suspiciously like the answer is "forgot"
2020-07-04 22:46:30 <Hello71> I thought it was because you need them for linking dependent packages, but that doesn't make sense because then they should all be in main gcc, and second because that's not how linking works
2020-07-04 22:47:50 <Ariadne> that is what 'oversight' means
2020-07-04 22:48:26 <Hello71> yes
2020-07-04 22:50:16 <Hello71> same with libdir/finclude then?
2020-07-04 22:53:58 <Hello71> is it intentional to only move x.so.* instead of x.so*? I can't remember all the ramifications but I think the difference is -lx and dlopen look for x.so
2020-07-04 22:54:18 <Ariadne> yes
2020-07-04 23:02:11 <Hello71> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9970
2020-07-05 06:23:36 <Ariadne> lol
2020-07-05 06:23:45 <Ariadne> toybox is nowhere near ready for alpine to switch to
2020-07-05 06:23:47 <Ariadne> http://lists.landley.net/pipermail/toybox-landley.net/2020-July/011883.html
2020-07-05 06:29:41 <mps> khm, khm
2020-07-05 06:31:14 <Ariadne> ?
2020-07-05 06:32:05 <Ariadne> oh
2020-07-05 06:32:07 <Ariadne> don't worry
2020-07-05 06:32:11 <mps> should be some kind of joke, sorry if I wrote it ambiguously
2020-07-05 06:32:11 <Ariadne> i am going to run afl on toybox
2020-07-05 06:32:30 <Ariadne> it will be ready someday
2020-07-05 06:42:47 <Ariadne> ok
2020-07-05 06:42:51 <Ariadne> umm
2020-07-05 06:43:00 <Ariadne> yeah, we're never using toybox
2020-07-05 06:43:04 <Ariadne> the more i look at this thing
2020-07-05 06:43:09 <Ariadne> the more i see stuff like this:
2020-07-05 06:43:11 <Ariadne>       if ((i = (unsigned short []){80,80,48,16,32,0,64,2,8,96,4}[i]<<9)>=4096)
2020-07-05 06:43:11 <Ariadne>         return (st.st_mode&S_IFMT) == i;
2020-07-05 06:43:11 <Ariadne>       else return (st.st_mode & i) == i;
2020-07-05 06:43:54 <Ariadne> this is terrifying
2020-07-05 06:44:49 <mps> and unreadable, to me
2020-07-05 06:45:19 <Ariadne> that's why it is terrifying
2020-07-05 06:45:24 <mps> 
ACTION wonders why people don't like braces

2020-07-05 06:45:38 <Ariadne> what i am looking for in alpine userspace is more transparency than busybox, not less
2020-07-05 06:45:58 <ikke> Does gcc warn against that style now?
2020-07-05 06:46:09 <ikke> or did they disable that
2020-07-05 06:46:21 <Ariadne> oh
2020-07-05 06:46:24 <ikke> s/Does/Doesn't/
2020-07-05 06:46:24 <alpine-meetbot> ikke meant to say: Doesn't gcc warn against that style now?
2020-07-05 06:46:25 <Ariadne> if you compile this
2020-07-05 06:46:29 <Ariadne> with -Wall -Wextra
2020-07-05 06:46:34 <Ariadne> there is thousands of warnings
2020-07-05 06:46:37 <ikke> heh
2020-07-05 06:48:35 <mps> for me all warnings looks like errors
2020-07-05 06:49:03 <afontain_> hey, that snipped could be a good source of inspiration for the next IOCCC!
2020-07-05 06:49:30 <Ariadne> i don't want our userspace to look like an IOCCC entry.  busybox has enough of that as it is -_-`
2020-07-05 06:49:49 <mps> :)
2020-07-05 06:50:02 <mps> ikke: what's with linter on CIs
2020-07-05 06:50:13 <mps> https://gitlab.alpinelinux.org/mps/aports/-/jobs/158768
2020-07-05 06:50:15 <Ariadne> if rust were actually bootstrapped on all archs, i would just start writing a busybox replacement in rust
2020-07-05 07:06:34 <mps> hmm, 0872cf92d4ac88e65fd5f0ce8e97131d9ea5c62b
2020-07-05 07:07:23 <mps> I can take maintainership of this package, I use it often. ofc if no one else want to take it
2020-07-05 07:10:46 <mps> I need help (experienced eyes) for this https://gitlab.alpinelinux.org/mps/aports/-/jobs/158508#L159
2020-07-05 07:11:10 <mps> it builds on my local machine but fails on CI and on lxc containers
2020-07-05 07:12:00 <mps> so, I have something installed on my machine which should add to makedepends probably, but have no idea what
2020-07-05 07:13:30 <Cogitri> Maybe try invoking the Makefile with V=1 so you can see what it's running
2020-07-05 07:14:27 <mps> Cogitri: tried but didn't helped
2020-07-05 07:14:36 <mps> even with V=99
2020-07-05 07:23:06 <Cogitri> Hm, I guess the Makefile doesn't implement then, I guess some variable isn't set so when it tries to do "$(VAR) -c" to execute some program it tries to execute -c
2020-07-05 07:23:15 <Cogitri> So maybe just grep'ing for -c does it
2020-07-05 07:25:05 <mps> maybe. strange it works fine on my local machine
2020-07-05 07:27:27 <ikke> mps: I have no clue atm
2020-07-05 07:27:31 <ikke> seems something intermittent
2020-07-05 07:28:46 <mps> ok, np. will look in Makfiles and search net
2020-07-05 07:29:11 <ikke> If it persists I can restart docker on that host
2020-07-05 07:31:19 <mps> ikke: ah, you mean APKBUILD linter issue
2020-07-05 07:31:28 <mps> yes, it persist
2020-07-05 07:32:09 <ikke> ok
2020-07-05 07:32:20 <mps> looks like all CIs and for all MR from yesterday
2020-07-05 07:33:30 <ikke> hmm, restarting docker didn't help :(
2020-07-05 07:33:52 <ikke> hmm, that looks familiar
2020-07-05 07:36:49 <mps> ok, np for me, I usually run apkbuild-lint locally before creating MR
2020-07-05 07:59:54 <mps> Cogitri: meh, bash fixes this 'make -c' errors
2020-07-05 08:00:14 <Cogitri> Huh
2020-07-05 08:01:06 <mps> yes, big huh
2020-07-05 08:13:30 <PureTryOut[m]> Ariadne: no, I don't use Wayland at all yet as none of the keyboard hotkeys work
2020-07-05 08:13:36 <PureTryOut[m]> Which completely breaks my workflow
2020-07-05 08:13:51 <Ariadne> PureTryOut[m]: yes, i know why that is.  kwin is failing to register with dbus, so it doesn't know what to grab.
2020-07-05 08:14:08 <Ariadne> but, debugging this further is outside of my knowledge.  do we know any KDE people who can help us? (:
2020-07-05 08:14:16 <PureTryOut[m]> I let some KDE devs go wild on my laptop last Akademy to try and find the issue but they didn't succeed, besides learning it was something with dbus
2020-07-05 08:14:47 <Ariadne> okay.  i'll uhh
2020-07-05 08:14:49 <PureTryOut[m]> I have made a bug report for it but am on mobile so is hard to find currently
2020-07-05 08:14:51 <Ariadne> keep digging i guess.
2020-07-05 08:15:25 <Ariadne> but i ran dbus-monitor over ssh and started a wayland session.  kwin does not even try to connect to dbus
2020-07-05 08:15:35 <PureTryOut[m]> Once keyboard shortcuts do work, I'll probably switch to Wayland entirely and figure out what else needs fixing lol
2020-07-05 08:16:04 <Ariadne> not sure why, because workspace::workspace() calls dbusinterface::dbusinterface() unconditionally.
2020-07-05 08:16:22 <PureTryOut[m]> Since you're more knowledgeable about these things, it's worth discussing with upstream in their Plasma IRC channel
2020-07-05 08:17:40 <Ariadne> i'm just going to add
2020-07-05 08:17:47 <Ariadne> a shitload of printf debugging basically
2020-07-05 08:18:07 <Ariadne> or rather, qDebug() << "whatever" debugging
2020-07-05 08:19:38 <Ariadne> i think something is missing in the wayland session that the x11 session has
2020-07-05 08:19:42 <Ariadne> but i am not sure what it is
2020-07-05 08:22:21 <PureTryOut[m]> Well stuff in the X11 session is broken too, just not the hotkeys lol. For example KSysguard has no idea who owns the processes
2020-07-05 08:31:15 <Ariadne> are you using openrc-settingsd ?
2020-07-05 08:43:54 <Ariadne> setting up DBusInterface!!!! wow
2020-07-05 08:43:54 <Ariadne> failed to register service: "org.kde.KWin" error: QDBusError("org.freedesktop.DBus.Error.Disconnected", "Not connected to D-Bus server")
2020-07-05 08:44:02 <Ariadne> welp
2020-07-05 08:44:05 <Ariadne> that told me fuck all
2020-07-05 08:44:10 <Ariadne> *why* is it not connected
2020-07-05 08:48:09 <Cogitri> Have you try running dbus-monitor?
2020-07-05 08:48:18 <Cogitri> s/try/tried/?
2020-07-05 08:48:18 <alpine-meetbot> Cogitri meant to say: Have you tried running dbus-monitor?
2020-07-05 08:48:25 <Ariadne> setting up DBusInterface
2020-07-05 08:48:25 <Ariadne> dbus is NOT connected!!!  expected bus name: "qt_default_session_bus"
2020-07-05 08:48:31 <Ariadne> hyou know
2020-07-05 08:48:39 <Ariadne> i feel like that is not the correct bus name
2020-07-05 08:49:31 <Ariadne> Cogitri: [02:15:25] <Ariadne> but i ran dbus-monitor over ssh and started a wayland session.  kwin does not even try to connect to dbus
2020-07-05 08:51:28 <Ariadne> time to go down the qt rabbit hole
2020-07-05 09:08:07 <Ariadne> lets see if QDBusConnection::connectToBus() behaves differently
2020-07-05 09:10:39 <Ariadne> so
2020-07-05 09:10:48 <Ariadne> QDBusConnection::systemBus() is working
2020-07-05 09:11:44 <Cogitri> But I don't think apps expect KWin to be available on the system bus and not the session bus?
2020-07-05 09:16:10 <Ariadne> what i mean is
2020-07-05 09:16:18 <Ariadne> it is failing to connect to session bus
2020-07-05 09:16:21 <Ariadne> system bus is fine
2020-07-05 09:18:47 <Cogitri> Ah yes, maybe it's started after KWin or smth
2020-07-05 09:19:05 <Ariadne> no
2020-07-05 09:19:11 <Ariadne> sddm starts it
2020-07-05 09:21:29 <Ariadne> lets try
2020-07-05 09:21:38 <Ariadne> acquiring a dbus connection in main()
2020-07-05 09:24:14 <Ariadne> localhost:~/aports/community/kwin$ QDBUS_DEBUG=1 kwin_wayland
2020-07-05 09:24:15 <Ariadne> bus: "qt_default_session_bus" connected: false
2020-07-05 09:24:18 <Ariadne> no debug
2020-07-05 09:24:18 <Ariadne> hmm
2020-07-05 09:49:00 <Ariadne> DBUS_ENABLE_VERBOSE_MODE
2020-07-05 09:49:03 <Ariadne> hmm what is this
2020-07-05 09:50:52 <Ariadne> 
ACTION rebuilds dbus locally with it enabled

2020-07-05 10:04:12 <Ariadne> well that was not enlightening
2020-07-05 10:06:46 <Ariadne> gonna nap on it, but this seems to be a bug in qtdbus
2020-07-05 11:39:00 <russkel> if a package just states its license is BSD, what SPDX do I use? https://pypi.org/project/rospkg/
2020-07-05 11:40:50 <Cogitri> russkel: Look at the source for clues
2020-07-05 11:40:52 <Cogitri> https://github.com/ros-infrastructure/rospkg/blob/master/src/rospkg/common.py
2020-07-05 11:41:06 <russkel> ahh three clause
2020-07-05 11:41:08 <Cogitri> They use BSD-3-Clause I think
2020-07-05 11:41:09 <russkel> thanks Cogitri
2020-07-05 11:41:42 <russkel> I was trying to hunt it down on the ROS index, but of course its added to each file!
2020-07-05 11:42:25 <russkel> I think I will raise a ticket with ROS and see if they can't standardise their license field on SPDX
2020-07-05 12:10:46 <mps> huh again, https://gitlab.alpinelinux.org/mps/aports/-/jobs/158801#L314
2020-07-05 12:11:03 <mps> >>> ERROR: simavr-dev*: usr/lib/pkgconfig/simavr-avr.pc: pkgconf version unknown is invalid
2020-07-05 12:11:12 <mps> what that means
2020-07-05 12:11:53 <mps> and why it works in native and lxc build boxes but not on CI
2020-07-05 12:12:07 <Cogitri> That it puts "unknown" as pkgconf version, which isn't valid, should be $pkgver or something like that
2020-07-05 12:12:28 <Cogitri> Probably a mediocre makefile, time to rewrite in meson :^)
2020-07-05 12:12:56 <mps> heh, I'm not upstream to rewrite it
2020-07-05 12:13:36 <mps> question is what are difference between CIs and lxc builders
2020-07-05 12:14:44 <Cogitri> `SIMAVR_VERSION  := ${shell git describe --abbrev=0 --tags || echo "unknown" }`
2020-07-05 12:14:54 <Cogitri> That seems broken if you don't build from a git tag :)
2020-07-05 12:15:06 <Cogitri> Try setting SIMVAR_VERSION=$pkgver in your make invocations
2020-07-05 12:15:27 <Cogitri> On your lxc it probably picked up the git dir of aports and hence it "worked"
2020-07-05 12:16:44 <mps> yes, just looking that.
2020-07-05 12:16:51 <mps> Cogitri: thanks for help
2020-07-05 12:17:43 <Cogitri> 👍️
2020-07-05 12:20:00 <mps> looks like it works on lxc, lets see on CIs
2020-07-05 12:26:44 <mps> Cogitri: also works in CIs (except ppc64le, but is second story), thanks again Cogitri :)
2020-07-05 12:28:13 <mps> btw, we don't need to add flags '-fPIC -O2 -std=gnu99', i.e. they are default?
2020-07-05 12:30:41 <Cogitri> I don't think any of them are on by default (but don't quote me on that, I don't do that much C :)
2020-07-05 12:33:43 <mps> yes, looks like -Os is default not -O2
2020-07-05 12:33:57 <mps> -O2 is default for kernel
2020-07-05 12:35:02 <mps> and -fPIE ( --enable-default-pie) not PIC
2020-07-05 12:51:56 <Hello71> mps: I heard rmlint is better than fdupes
2020-07-05 12:54:24 <mps> hm, first time heard for rmlint, maybe I should look at it
2020-07-05 12:54:29 <mps> though I prefer to use tools with which I have experience
2020-07-05 12:55:02 <mps> but if something really better it is always worth to look
2020-07-05 12:55:52 <Hello71> I think it is supposed to be faster for huge amount of files. also it has much more options (I used it to hardlink my duplicates together)
2020-07-05 12:56:50 <mps> on a such tools I don't look for speed but for correctness
2020-07-05 12:58:02 <mps> actually, for all tools I prefer correctness first
2020-07-06 05:39:25 <maxice8> rsync seemed to be using the included zlib instead of the system one
2020-07-06 05:46:51 <ikke> why disable lz4/xxhash/openssl?
2020-07-06 05:48:05 <ikke> Would be nice of those details are part of the commit message
2020-07-06 05:49:13 <maxice8> Because they were never enabled before and now complain if they aren't explicitly disabled
2020-07-06 05:49:28 <maxice8> I'll put that info in the commit
2020-07-06 05:49:35 <maxice8> If someone wants those features they can make a merge request
2020-07-06 05:50:19 <ikke> now people need to guess, and it looks like they are explicitly disabled (instead of implicitly)
2020-07-06 05:50:43 <maxice8> Guess?
2020-07-06 05:50:59 <ikke> If they look at the APKBUILD and the commit that added this
2020-07-06 05:51:45 <maxice8> Yes, I said I'll put that info in the commit message
2020-07-06 06:29:33 <mps> trying to predict future, I think new linux LTS will be 5.10 and will be released on december or end of november
2020-07-06 06:30:00 <mps> so, again late for 3.13 alpine release
2020-07-06 09:24:06 <ncopa> mps: url?
2020-07-06 09:24:22 <maxice8> ncopa :D
2020-07-06 09:24:49 <mps> heh, '08:29 ............. mps| trying to predict future'
2020-07-06 09:27:01 <mps> my impression from looking on https://www.kernel.org/category/releases.html
2020-07-06 09:27:06 <ncopa> oh..
2020-07-06 09:27:19 <mps> last few years show pattern
2020-07-06 09:27:42 <ncopa> why not 5.9?
2020-07-06 09:28:21 <mps> every fifth release is LTS
2020-07-06 09:28:32 <ncopa> 4.4, 4.9, 4.14, 4.19, 5.4, 5.?
2020-07-06 09:28:40 <ncopa> so i'd guess 5.9 :=
2020-07-06 09:28:42 <ncopa> :)
2020-07-06 09:29:08 <mps> yes
2020-07-06 09:29:27 <mps> but I think 5.9 will not be much stable
2020-07-06 09:29:45 <mps> 5.8 introduced a loot of big changes
2020-07-06 09:30:44 <mps> but, as Yogi Berra told 'predicting, especially future, is hard' :)
2020-07-06 09:30:49 <maxice8> ncopa, can you look at abuild ? :D
2020-07-06 09:42:24 <ncopa> oh... right. will try this week
2020-07-06 09:42:43 <maxice8> nice
2020-07-06 09:42:44 <maxice8> ty
2020-07-06 10:10:27 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9978 @Ikke :D
2020-07-06 10:10:48 <ikke> hmm
2020-07-06 10:15:32 <ikke> seems like the cronjob does not get executed for some reason
2020-07-06 10:16:14 <maxice8> oof
2020-07-06 11:18:31 <ikke> maxice8: I ran it manually for now, will look into the cron later
2020-07-06 11:33:26 <nmeum> ncopa: 2f32bfc751bae19369fc06666e8f4b2ce88d17fd do you still recall if the qemu user actually needs a home directory or if we can set it to /dev/null?
2020-07-06 11:34:24 <nmeum> just noticed an undesired /home/qemu on my machine I would preferably get rid of, either by using /var/lib/qemu or /dev/null (or /var/empty) as home for that user
2020-07-06 11:35:39 <nmeum> !10020
2020-07-06 11:36:12 <ikke> strange, it's created as a system user. Should it not make a homedir in that case?
2020-07-06 11:36:46 <mps> nmeum: yes, also I noticed it
2020-07-06 11:36:54 <nmeum> ikke: no
2020-07-06 11:37:03 <nmeum> you have to pass -h / -H explicitly
2020-07-06 11:37:52 <nmeum> adduser invocations in .pre-install scripts are very verbose for that reason ':)
2020-07-06 11:38:07 <ikke> right, most have -S -D -H as option
2020-07-06 11:38:20 <nmeum> and -h as well usually
2020-07-06 11:38:27 <ikke> yes
2020-07-06 11:39:01 <nmeum> add some point an add-system-user script (or similar) would probably be helpful to prevent mistakes (like the qemu one) regarding adduser invocations in .pre-install scripts
2020-07-06 11:39:04 <ikke> I don't see why qemu needs a home dir
2020-07-06 11:39:25 <nmeum> neither do I, it's empty on my machine
2020-07-06 11:39:30 <ikke> It
2020-07-06 11:39:39 <ikke> It's not something required by qemu itself afaik
2020-07-06 11:41:23 <nmeum> will just wait a few hours and merge my mr unless ncopa recalls a specific reason for not passing -h/-H
2020-07-06 11:41:48 <nmeum> have to get back to $dayjob anyhow now (:
2020-07-06 11:42:07 <ikke> heh :)
2020-07-06 11:42:09 <ikke> same for me
2020-07-06 11:49:14 <mps> on my two machine /home/qemu have two files, .xsession and .profile
2020-07-06 16:01:20 <mps> hmm, how formatting works for description in bug reports on bugzilla.kernel.org
2020-07-06 16:02:28 <mps> html?
2020-07-06 16:04:37 <Hello71> text
2020-07-06 16:05:02 <Hello71> and most subsystems don't read those
2020-07-06 16:05:52 <mps> Hello71: preview show all as one line
2020-07-06 16:09:34 <mps> ah, there is 'Enable Markdown support for comments' in preferences
2020-07-06 16:38:12 <PureTryOut[m]> maxice8: why was the last vulkan-* update reverted again? Can we safely upgrade to 146 now?
2020-07-06 16:38:35 <maxice8> Broke API
2020-07-06 16:38:38 <PureTryOut[m]> *1.2.146
2020-07-06 16:38:56 <maxice8> Idk will have to rebuild the packages that use it
2020-07-06 16:48:24 <PureTryOut[m]> Please try 😃
2020-07-06 17:35:16 <maxice8> Don't look at me
2020-07-06 17:55:50 <Cogitri> It still breaks API
2020-07-06 17:55:59 <Cogitri> And most projects haven't adapted to that yet
2020-07-06 17:56:15 <Cogitri> But if you do try it please rebuild all dependants of vulkan-* to test
2020-07-06 21:34:28 <PureTryOut[m]> Damn... Well, will do, I'll start checking upstream bug trackers
2020-07-06 21:34:54 <PureTryOut[m]> A bit strange that a point release just breaks API like that
2020-07-07 05:32:55 <Cogitri> "PureTryOut[m]" (https://matrix.to/#/@freenode_PureTryOut[m]:matrix.exqa.de): I thought they did that by accident at first and opened an issue at the vulkan bug tracker, but apparently they're free to break API at any point however they like
2020-07-07 13:11:34 <maxice8> @Cogitri https://git.alpinelinux.org/abuild/commit/?id=2cc63809 should atools check for those ?
2020-07-07 13:17:29 <Cogitri> Hm, that'd warn on any abuild that uses meson right now
2020-07-07 13:17:59 <Cogitri> I'll go ahead and do a mass migration to the new style once I have a bit more time and afterwards we can do the change atools maybe?
2020-07-07 13:23:54 <maxice8> Ok
2020-07-07 15:00:53 <Ariadne> should hopefully have mips64 builder on mainline kernel by end of week
2020-07-07 15:05:24 <ikke> Ariadne: nice
2020-07-07 15:07:00 <Cogitri> Neat, does that mean Go on mips?
2020-07-07 15:22:32 <ikke> I would expect so
2020-07-07 16:40:26 <tsarna> am I correct that a community package should not depend on a testing package?
2020-07-07 16:40:51 <ikke> correct
2020-07-07 16:41:02 <tsarna> Or more generally, main > community > testing > unmaintained, and a package should only depend on packages >= its own area
2020-07-07 16:41:52 <ikke> Indeed
2020-07-07 16:43:04 <tsarna> OK, thanks. I was thinking nomad is ready to move to community but I noticed it depends on testing/cni-plugins
2020-07-07 16:44:04 <tsarna> It seems many packages hang out in testing longer than they really need to
2020-07-07 16:45:15 <wsinatra> I think part of that is the commitment that comes with moving things to community, not everyone can dedicate the time to maintaining it unfortunately
2020-07-07 16:45:18 <ikke> true, there is no process that actively move packages from testing to community
2020-07-07 16:45:55 <ikke> Packages in testing should still be maintained
2020-07-07 16:46:52 <ikke> tsarna: it's quite common to move a packages with all its dependencies at the same time to community
2020-07-07 16:47:26 <tsarna> I guess I could open an MR for both and tag the maintainers for input
2020-07-07 16:47:38 <tsarna> Speaking of hanging out for a long time, I also have a MR for a nomad upgrade open for about two weeks... is there something I should do to help get changes merged more quickly?
2020-07-07 16:47:53 <ikke> Hmm, usually things are merged quite quicky
2020-07-07 16:48:37 <tsarna> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9452
2020-07-07 16:48:55 <ikke> Yeah, found it
2020-07-07 16:48:59 <ikke> I will look at it
2020-07-07 16:49:02 <wsinatra> @ikke: right, I would say most are, but maybe not at the same cadence that you would want from something "officially" supported
2020-07-07 16:49:39 <ikke> To be honest, there are a lot of packages in testing which are not maintained
2020-07-07 16:49:40 <tsarna> Thanks
2020-07-07 16:50:55 <wsinatra> I wonder if there's any easy way to pull that info. Is there a criteria?
2020-07-07 16:51:03 <ikke> out of curiousity, what are the limitations of vault and consul you are talking about?
2020-07-07 16:51:10 <wsinatra> Like must be touched within X many days.
2020-07-07 16:51:34 <ikke> repology can help as well to figure if there are any updates
2020-07-07 16:52:05 <tsarna> vault is built without the UI due to some version conflict... with nodejs I think? It needs an older one than we have
2020-07-07 16:52:16 <ikke> yes, indeed
2020-07-07 16:52:32 <ikke> Kind of anoying
2020-07-07 16:52:37 <ikke> (I happen to maintain vault)
2020-07-07 16:52:49 <tsarna> and alpine consul doesn't build on arm64, but the official build works fine there with libc6-compat
2020-07-07 16:53:27 <Cogitri> wsinatra: I don't think that that's a great metric for how maintained a package is, some packages don't get updates often so one doesn't have to touch them too often
2020-07-07 16:53:35 <tsarna> So I have been using the official binaries for those
2020-07-07 16:55:28 <tsarna> the nomad binary seems to really, really want real glibc though
2020-07-07 16:55:51 <ikke> 'real'? :P
2020-07-07 16:55:58 <ikke> you mean instead of the compat one
2020-07-07 16:56:24 <tsarna> yes... huge amounts of missing symbols with the compat library
2020-07-07 16:58:13 <ikke> I wonder if there is an issue reported to hashicorp about arm64
2020-07-07 16:58:13 <tsarna> but alpine's nomad is full-featured and works on both x86_64 and arm64 so I use the package for it
2020-07-07 16:58:32 <ikke> (hashicorp might not care anyway)
2020-07-07 16:59:10 <wsinatra> cogitri: absolutely agreed. I have packages that haven't seen updates since I took over them (ie: clisp)
2020-07-07 16:59:34 <wsinatra> but is there something someone can look for to help pick up abandoned packages?
2020-07-07 16:59:49 <wsinatra> I mean, obviously the unmaintained ones are fair game
2020-07-07 17:00:24 <ikke> https://pkgs.alpinelinux.org/packages?name=&branch=edge&arch=x86_64&maintainer=None
2020-07-07 17:00:57 <ikke> https://repology.org/projects/?inrepo=alpine_edge&outdated=1
2020-07-07 17:02:23 <wsinatra> <3
2020-07-07 17:03:54 <mps> big corporation usually doesn't care much about using their software on musl, or anything non glibc
2020-07-07 17:04:17 <ikke> tsarna: I don't get Mathhias comment btw about not allowing the binaries to run a non-root btw
2020-07-07 17:04:57 <ikke> (I maintain vault, but didn't realize that yet, I took it over)
2020-07-07 17:05:20 <ikke> You can perfectly use alpine to administer these projects as well as run them as a service
2020-07-07 17:05:48 <ikke> But they probably only use alpine in containers
2020-07-07 17:07:31 <tsarna> ikke
2020-07-07 17:08:30 <tsarna> ikke: so the consul aarch64 problem was some alpine-specific build issue apparently... with 0.5.3! It could have long since been fixed, perhaps we can re-enable aarch64 now.
2020-07-07 17:08:34 <tsarna> I will try it
2020-07-07 17:09:15 <tsarna> https://gitlab.alpinelinux.org/alpine/aports/-/commit/9abee09e039d5bd4dff1f5959dd08d91687ed2fb
2020-07-07 17:12:26 <tsarna> Yes, I use alpine on the "outside" too, my consul/vault/nomad server nodes and worker nodes run it, and I administer from an alpine node
2020-07-07 17:14:38 <tsarna> Alpine is perfect for this, I don't need a complicated bloated thing like systemd, I just need something small and simple to run consul/vault/nomad and they run everything else
2020-07-07 17:18:06 <ikke> tsarna: nomad upgrade has been merged :)
2020-07-07 17:18:18 <tsarna> Awesome, thanks!
2020-07-07 17:22:29 <ikke> tsarna: ugh, it fails on armv7 now for some reason
2020-07-07 17:22:54 <ikke> process out of memory :/
2020-07-07 17:24:02 <tsarna> All the UI-building stuff needs lots of memory :(
2020-07-07 17:24:16 <ikke> tsarna: believe me, that machine has more than enough memory
2020-07-07 17:24:35 <ikke> 128G
2020-07-07 17:24:46 <Cogitri> Maybe it needs more than 4G per process
2020-07-07 17:25:08 <ikke> you mean a 32-bits limitation?
2020-07-07 17:25:47 <tsarna> I developed the update on a 2GB x86_64 AWS instance
2020-07-07 17:25:48 <Cogitri> Yup
2020-07-07 17:26:17 <ikke> sometimes it's the amount of memory per core (thread / job) that's the issue
2020-07-07 17:26:21 <tsarna> and it built fine last night with gitlab CI on all platforms when I rebased
2020-07-07 17:26:31 <tsarna> and many times before that
2020-07-07 17:26:32 <ikke> yes, it built fine just now
2020-07-07 17:26:35 <ikke> on CI
2020-07-07 17:27:20 <mps> yes, 4GB limit can be problem on builders
2020-07-07 17:27:36 <ikke> why only on builders?
2020-07-07 17:30:03 <mps> linker flags maybe
2020-07-07 17:30:17 <mps> I'm not sure
2020-07-07 17:31:26 <ikke> testing it 'manually' on the builder now
2020-07-07 17:33:49 <ikke> of course then it proceeeds :-/.
2020-07-07 17:34:02 <ikke> algitbot: retry master
2020-07-07 17:35:05 <Cogitri> Huh, you can do that in #alpine-devel too? :o
2020-07-07 17:36:04 <maxice8> Fancy
2020-07-07 17:37:48 <ikke> yes, since algitbot got moved
2020-07-07 17:37:59 <ikke> clandmeter adjusted it :)
2020-07-07 17:39:31 <ikke> ok, nomad now continues
2020-07-07 17:39:38 <ikke> succeded
2020-07-07 18:03:56 <ikke> tsarna: do you consider vault.hcl (/etc/vault.hcl) sensitive?
2020-07-07 18:04:10 <ikke> ie, would you give it 640 or 644 permissions?
2020-07-07 18:04:22 <ikke> iirc, it should not be
2020-07-07 18:06:29 <maxice8> https://gitlab.alpinelinux.org/Dekedro/aports please make public :D
2020-07-07 18:08:32 <ikke> 9done
2020-07-07 18:10:51 <tsarna> ikke: I would say yes, it might contain a consul token
2020-07-07 18:10:59 <ikke> tsarna: aha, ok. thanks
2020-07-07 18:11:40 <mps> anyone using dhcpcd, not udhcpc
2020-07-07 18:12:33 <mps> on #musl dalias just noticed that it sends to server 'Vendor-Class Option 60, length 51: "dhcpcd-7.2.0:Linux-5.4.35-0-lts:x86_64:GenuineIntel"'
2020-07-07 18:12:46 <mps> which is obvious privacy violation
2020-07-07 18:14:08 <Hello71> so does systemd-networkd and most other dhcp clients
2020-07-07 18:18:06 <mps> afaik that is because some buggy dhcp servers doesn't work without this
2020-07-07 18:18:36 <mps> hello msft ;)
2020-07-07 18:21:26 <dalias> just put some generic string then
2020-07-07 18:21:29 <dalias> like Windows 10
2020-07-07 18:22:06 <dalias> there's absolutely no reason to disclose actual os and kernel and dhcp client versions
2020-07-07 18:22:09 <dalias> or cpu arch\
2020-07-07 18:22:41 <mps> or, 'MSFT ....' :)
2020-07-07 18:22:46 <dalias> dhcpcd-999:Linux-66:aarch256 :-p
2020-07-07 18:23:09 <dalias> but seriously, just whatever is the smallest fingerprinting footprint
2020-07-07 18:23:22 <dalias> so maybe whatever iphone or android sends
2020-07-07 18:23:48 <ikke> https://xkcd.com/1105/
2020-07-07 18:23:48 <alpine-meetbot> https://xkcd.com/1105 | License Plate | Alt-text: The next day: 'What? Six bank robberies!? But I just vandalized the library!' 'Nice try. They saw your plate with all the 1's and I's.' 'That's impossible! I've been with my car the whole ti-- ... wait. Ok, wow, that was clever of her.'
2020-07-07 18:26:54 <Hello71> I'm inclined to say that the current behavior is just because dhcpcd is old
2020-07-07 18:27:06 <Hello71> systemd apparently doesn't send vendor class at all if you set Anonymize=yes
2020-07-07 18:27:11 <Hello71> if you don't then it sends systemd
2020-07-07 18:27:28 <Hello71> which I think is reasonable
2020-07-07 18:36:45 <dalias> *nod*
2020-07-07 18:36:49 <dalias> just "dhcpcd" should suffice
2020-07-07 18:45:32 <ikke> PureTryOut[m]: kde-cli-tools is failing. Seems like libkworkspace is not properly updated?
2020-07-07 18:46:48 <ikke> "Could not find a configuration file for package "LibKWorkspace" that is compatible with requested version "5.19.3"."
2020-07-07 19:32:06 <mps> are those CAN-BUS (truck) people here? I'm waiting for them to review !10004 before merging
2020-07-07 19:33:10 <ikke> hc-hmk is not here
2020-07-07 19:34:06 <mps> aha, ok. thanks for info ikke
2020-07-07 21:05:38 <PureTryOut[m]> ikke: seems like plasma-workspace might need a rebuild? That normally provides LibKWorkspace, but was also updated to 5.19.3
2020-07-07 21:06:44 <ikke> PureTryOut[m]: it looks like it went through the 2nd time
2020-07-07 21:07:43 <ikke> only s390x is still building it
2020-07-07 21:08:02 <ikke> that failed multiple times though
2020-07-07 21:08:56 <ikke> ok, but kde-cli-tools now built succesfully as well, strange
2020-07-07 21:18:05 <ikke> maxice8: py3-google-auth fails due to checksum failure
2020-07-07 21:23:13 <ikke> strange, locally the checksum is the same
2020-07-07 21:40:50 <ikke> The patch from github is different on the mips builder (indes hashes changed)
2020-07-07 22:43:41 <Terror> Seems s390 is stuck
2020-07-07 22:44:05 <Terror> I have a PR that's stuck building on that arch too
2020-07-07 22:59:30 <Terror> It's been going for 25 minuts, ppc64le took 53 seconds to build.
2020-07-07 23:36:36 <Terror> Cancelling and restarting the s390 build worked
2020-07-08 04:30:23 <bobby_> Hey there, I'm looking to rebuild the Alpine Xen ISO but with Xen 4.14-rc5.  I've found the Alpine image building script for VM targets, is there a similar script available for the Alpine Xen ISO?  Or an ISO building document?
2020-07-08 04:36:53 <ikke> Terror: yeah, there is some issue with git on s390x where it gets stuck, but no clue what is causing it. Only thing we can do is just restart the job indeed
2020-07-08 04:38:23 <ikke> bobby_: https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/scripts mkimage.sh --profile xen
2020-07-08 04:40:29 <bobby_> ikke:  thanks!
2020-07-08 06:40:41 <hc-hmk> Good morning. Does anyone know if linux-lts@edge is compiled with a different optimization level than linux-lts@main? Our test builds boot times have increased 5x, and we're not sure why.
2020-07-08 06:47:10 <Cogitri> They're pretty much identical, I guess you could just diff their APKBUILD and config to make sure they're the same
2020-07-08 06:53:22 <mps> hc-hmk: would you look and review !10004
2020-07-08 07:48:52 <hc-hmk> mps: The MR looks good, aside from the stringup-trunc flag. The release we're using is very, very old. The issue has since been fixed on master, but the owner has not made a new release in ages.
2020-07-08 07:50:02 <mps> stringup-trunc is needed to build on ppc64le, without it build fails
2020-07-08 07:51:07 <hc-hmk> It really shouldn't be an issue *only* on ppc64le. GCC 9.2 also fails to build on x86-64, for me at least. It's an old issue. Take a look at my comments on the MR.
2020-07-08 07:51:29 <mps> ok, will look
2020-07-08 07:52:15 <mps> we can build master version also, but we prefer released versions
2020-07-08 07:53:10 <hc-hmk> I also greatly prefer a release. I don't want to build the release, since it's not reliable. We need some point-in-time snapshot so it's replicatable.
2020-07-08 07:53:28 <hc-hmk> s/release/master/g
2020-07-08 07:53:28 <alpine-meetbot> hc-hmk meant to say: I also greatly prefer a master. I don't want to build the master, since it's not reliable. We need some point-in-time snapshot so it's replicatable.
2020-07-08 07:53:40 <hc-hmk> Oh heck
2020-07-08 07:53:48 <hc-hmk> You know what I mean
2020-07-08 07:55:05 <mps> yes, ofc
2020-07-08 07:55:46 <mps> we can use particular git commit id for building package
2020-07-08 07:56:14 <mps> would be nice if you can tell us which commit id you think is good enough
2020-07-08 07:57:33 <hc-hmk> Honestly just pick the latest. Exactly which commit we pick is not important, the important thing is that we get the same binary if travis runs again in the future.
2020-07-08 07:58:47 <mps> ok, will look later today, probably at night
2020-07-08 07:58:57 <mps> thanks for feedback
2020-07-08 08:01:18 <hc-hmk> Should I pick something for you?
2020-07-08 08:04:12 <mps> you mean pick commit id?
2020-07-08 08:06:56 <hc-hmk> Yup, I could make some suggestions on the APKBUILD with another commit id etc. etc.
2020-07-08 08:07:46 <mps> that is what I asked you above: '09:56 ............. mps| would be nice if you can tell us which commit id you think is good enough'
2020-07-08 08:13:02 <hc-hmk> Fair enough. I'll pick something and suggest it on the MR.
2020-07-08 08:15:56 <mps> and, your 'A' at the description will not be accepted :)
2020-07-08 08:16:25 <mps> we prefer short descriptions
2020-07-08 08:17:11 <hc-hmk> The current description is grammatically wrong and has an extra space at the end.
2020-07-08 08:18:47 <mps> heh, extra space removal is ok, but we don't write prose
2020-07-08 08:19:07 <mps> and most of us are non native english speakers
2020-07-08 08:19:27 <hc-hmk> I'm not a native English speaker either, I'm Danish.
2020-07-08 08:20:33 <mps> I don't see any reason to have 'A shiny extra ...' having A and space after it
2020-07-08 08:21:03 <hc-hmk> Fair enough. I'm new here anyway.
2020-07-08 08:21:51 <mps> we want to 'say' what is pkg in less possible words and letters
2020-07-08 08:22:10 <mps> alpine is small and simple, at the end
2020-07-08 08:26:16 <mps> could someone help me with https://bugzilla.kernel.org/show_bug.cgi?id=208477
2020-07-08 08:27:37 <mps> i.e. to answer last message, to explain to upstream how to create dev alpine docker environment
2020-07-08 08:27:52 <mps> or, point to url where this is explained
2020-07-08 08:30:54 <hc-hmk> I'm not sure how to test the APKBUILD file, but I've made some suggestions which I believe to be solid.
2020-07-08 08:33:00 <mps> hc-hmk: ok, will look later, now I'm out of working machine
2020-07-08 08:33:35 <Plam> hi there!
2020-07-08 08:34:51 <hc-hmk> Hi. What do you need help with?
2020-07-08 08:34:51 <Plam> got a Xen bug to hunt, and for that I need an Alpine dom0 ISO with latest Xen RC. I'm following the doc on building an ISO but I don't see where I can point to a specific Xen version
2020-07-08 08:35:11 <Plam> (I'm an Alpine noob)
2020-07-08 08:35:56 <hc-hmk> Xen is packaged at version 4.13.1-r1 on ISO version 3.12.
2020-07-08 08:37:07 <hc-hmk> There is no way to get the latest Xen RC from the Alpine repos, since it's not packaged yet. You could manually compile and install it if you really need it.
2020-07-08 08:38:41 <Plam> I would need Xen 4.14-rc5
2020-07-08 08:39:11 <Plam> and yes, I would really need it, I may found a bug that could be a blocker for the release
2020-07-08 08:42:37 <dne> do you really need an ISO? you could just install from standard ISO and add Xen after
2020-07-08 08:42:46 <Plam> that what I was thinking about
2020-07-08 08:43:03 <Plam> ISO is convenient because I can just test it quickly if boot fails (which is the case here)
2020-07-08 08:43:04 <hc-hmk> What I suggest you do now is download Xen 4.14-rc5 from the authors website and compile it. It should work just fine on a standard install
2020-07-08 08:43:15 <Plam> but I could install alpine and then build Xen myself on top of it
2020-07-08 08:43:26 <Plam> but I have little knowledge on doing that on Alpine
2020-07-08 08:43:35 <Plam> (I'm more a Debian guy originally)
2020-07-08 08:43:53 <Plam> okay I'll try that :)
2020-07-08 08:44:00 <dne> sure (or eg use docker-abuild to build on any dist)
2020-07-08 08:44:24 <Plam> no problem to install normal Alpine on that device, non-Xen distro are working well
2020-07-08 08:44:40 <Plam> should I install Xen entirely manually by building it or first apk add xen?
2020-07-08 08:45:46 <hc-hmk> If you type "apk add xen", you'll get version 4.13.1-r1
2020-07-08 08:45:56 <dne> you could install the currently packaged xen, and then just plop in a newer self-built xen.gz
2020-07-08 08:46:07 <Plam> ah yes it might be the easiest path
2020-07-08 08:46:20 <Plam> just a cp of the build result on top of 4.13
2020-07-08 08:46:33 <Plam> or manually edit grub to add an entry toward the newer xen
2020-07-08 08:46:34 <dne> just the hypervisor is needed I guess?
2020-07-08 08:46:46 <Plam> yeah it doesn't boot, so I just need to prove the problem is still there in latest RC
2020-07-08 08:46:54 <Plam> so we can solve it before release
2020-07-08 08:47:03 <dne> yeah drop it in and regen grub.cfg should work
2020-07-08 08:47:12 <Plam> thx I'll do that :)
2020-07-08 08:47:20 <Plam> I'll let you know!
2020-07-08 09:14:53 <HRio> the dom0 does not boot you say? what hardware?
2020-07-08 09:15:11 <HRio> I am running XEN on @edge and v3.12 on Intel hw
2020-07-08 09:18:58 <dne> some specific bug in (not yet released) xen 4.14, I assume
2020-07-08 09:21:00 <HRio> ah, so not reproducable in current @egde?
2020-07-08 09:25:09 <dne> not AFAICT, as they needed 4.14-rc5 specifically
2020-07-08 09:30:40 <mps> maxice8: when you found time !9971 please
2020-07-08 09:34:40 <mps> maxice8: how fast you are :)
2020-07-08 09:37:36 <ikke> the ppc64le builder is still blocked by ldb1
2020-07-08 12:54:30 <rahmanshaber[m]> guys, why checksum is failing here
2020-07-08 12:54:30 <rahmanshaber[m]> https://gitlab.alpinelinux.org/rahmanshaber/aports/-/jobs/160734
2020-07-08 12:55:10 <afontain_> sanity check: did you commit and push?
2020-07-08 12:57:00 <afontain_> next thing I'd try would be to see if `abuild` complain
2020-07-08 13:48:18 <hc-hmk> Do any of you have any idea where I should start looking when cgroups doesnt mount properly?
2020-07-08 13:49:58 <mps> rc-update add cgroups
2020-07-08 13:50:19 <hc-hmk> cgroups service is already at runlevel default
2020-07-08 14:07:55 <clandmeter> rc.conf has cgroups settings
2020-07-08 14:13:02 <hc-hmk> Thanks, I'll have a look
2020-07-08 14:29:14 <mps> sorry for impatience and repeating question, but could someone help me with https://bugzilla.kernel.org/show_bug.cgi?id=208477, i.e. to tell upstream developer how to use docker for building package
2020-07-08 14:29:44 <mps> or point to the url where it is explained to some degree
2020-07-08 14:34:05 <dne> https://gitlab.alpinelinux.org/alpine/docker-abuild ?
2020-07-08 14:35:12 <Cogitri> FROM alpine:edge
2020-07-08 14:35:12 <Cogitri> RUN wget <tarball> && tar xf <tarball> && cd <dir> && ./configure && make && make test
2020-07-08 14:35:12 <Cogitri> Should work, I guess?
2020-07-08 14:35:21 <Cogitri> 
ACTION hopes that is formatted correctly

2020-07-08 14:36:10 <mps> dne: AFAIK this is for using on alpine and from aports
2020-07-08 14:36:42 <dne> you said "building package" so I assumed alpine package :)
2020-07-08 14:37:55 <mps> dne: no, libcap upstream asked how to test build libcap on alpine docker, probably running on some other distro host
2020-07-08 14:38:20 <dne> ok, ignore me :)
2020-07-08 14:38:31 <mps> dne: np, thanks anyway
2020-07-08 14:40:02 <mps> Cogitri: thanks, I will 'go' with your short guide
2020-07-08 14:40:53 <mps> long time ago I looked at https://github.com/sm0svx/svxlink/blob/master/docker/alpine/Dockerfile.build, not sure is good example
2020-07-08 14:41:01 <Hello71_> isn't the point that they need to use the apkbuild
2020-07-08 14:42:06 <mps> Hello71_: here is question https://bugzilla.kernel.org/show_bug.cgi?id=208477#c7
2020-07-08 14:42:48 <mps> I'm not sure how to answer, I don't have much experience with docker
2020-07-08 16:51:55 <mps> dalias: maybe you can help with this libcap on musl issue FROM alpine:edge
2020-07-08 16:52:11 <mps> no, sorry
2020-07-08 16:52:23 <mps> https://bugzilla.kernel.org/show_bug.cgi?id=208477#c9
2020-07-08 16:52:27 <mps> this one
2020-07-08 16:53:12 <mps> (sorry, adapting to new keyboard)
2020-07-08 16:54:04 <mps> other option is to disable tests for libcap package on alpine
2020-07-08 16:57:32 <maxice8> @PureTryOut ping
2020-07-08 16:58:34 <maxice8> is keepassxc broken for you as well ?
2020-07-08 16:59:33 <Cogitri> wfm
2020-07-08 17:00:04 <maxice8> 2.6.0 ?
2020-07-08 17:06:45 <PureTryOut[m]> Uhm my locally built version was built against Qt 5.15.0 lol, old on
2020-07-08 17:06:55 <PureTryOut[m]> *hold on
2020-07-08 17:06:56 <PureTryOut[m]> No, 2.6.0 works fine for me
2020-07-08 17:06:57 <PureTryOut[m]> Except it now completely ignoring my system theme 😒
2020-07-08 17:08:10 <PureTryOut[m]> Also we really need mips CI
2020-07-08 17:09:30 <PureTryOut[m]> py3-networkx tests seem to fail on both mips architectures, but I can't currently disable the tests there. Someone else will have to do it
2020-07-08 17:10:14 <maxice8> It looks completely out of wack for me
2020-07-08 17:29:07 <maxice8> 
ACTION uploaded an image: image.png (39KB) < https://matrix.exqa.de/_matrix/media/r0/download/matrix.exqa.de/YsfRLyfBlDHawQcnCwfbrsYj >

2020-07-08 18:18:30 <Cogitri> maxice8: Just tested with 2.6.0 and seems to work for me - but I don't have that dark theme
2020-07-08 18:18:45 <Cogitri> 
ACTION uploaded an image: image.png (173KB) < https://matrix.exqa.de/_matrix/media/r0/download/matrix.exqa.de/FHyZitVQxNtqxgUokUbuORdF >

2020-07-08 18:24:51 <maxice8> It is broken for me on any theme
2020-07-08 18:26:07 <Cogitri> Huh
2020-07-08 19:25:22 <ikke> restarting gitlab for a moment to apply a patch upgrade
2020-07-08 19:25:39 <maxice8> gl
2020-07-08 19:28:48 <ikke> up again
2020-07-08 19:29:03 <ikke> hmmm
2020-07-08 19:29:28 <ikke> I need to do it again, apparently I didn't have the latest version yet :-/
2020-07-08 19:32:58 <ikke> ok, now it's good :)
2020-07-08 19:48:21 <maxice8> ikke: please make public https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10082
2020-07-08 19:49:24 <ikke> done
2020-07-08 19:51:19 <maxice8> ty
2020-07-08 20:42:38 <dalias> mps, what is the issue?
2020-07-08 20:44:20 <mps> dalias: I'm outside right now so can't tell exactly
2020-07-08 20:44:43 <mps> but could you look at https://bugzilla.kernel.org/show_bug.cgi?id=208477#c9
2020-07-08 20:45:01 <mps> if you have some time, ofc
2020-07-08 20:45:39 <mps> libcap 2.36 segfaults in one of tests when I run 'make test'
2020-07-08 20:46:18 <dalias> probably just UB in tests
2020-07-08 20:46:58 <mps> iiuc, badly written test?
2020-07-08 20:47:16 <Cogitri> Does Valgrind say something useful?
2020-07-08 20:47:41 <mps> Cogitri: never used valgrind seriously
2020-07-08 20:50:02 <Cogitri> Just build the binary with debug info and then run  `valgrind $binary`  and it'll tell you memory bugs
2020-07-08 20:50:28 <mps> already built it with debug
2020-07-08 20:52:22 <dalias> the problem is just UB
2020-07-08 20:52:31 <dalias> they're calling pthread_kill on a thread id that's no longer valid
2020-07-08 20:54:15 <mps> hah
2020-07-08 20:54:23 <mps> nice :)
2020-07-08 20:55:53 <mps> imo, we should just disable tests for this package
2020-07-08 20:56:19 <ikke> Not just one test?
2020-07-08 20:56:56 <mps> I looked at Arch, Debian, Void and Adelie. they don't run tests on their build
2020-07-08 20:57:18 <ikke> arch doesn't generally run tests at all
2020-07-08 20:57:30 <ikke> not sure about the others
2020-07-08 20:58:15 <mps> I think Void and Debian do cross build, so they can't run tests easily
2020-07-08 20:58:23 <ikke> right
2020-07-08 20:58:35 <ikke> Alpine's policy is to run tests when they are present
2020-07-08 20:58:37 <mps> though not sure for debian
2020-07-08 20:58:54 <ikke> Unless they are obviously broken for some reason
2020-07-08 20:59:03 <mps> yes
2020-07-08 20:59:05 <ikke> but there is no need to disable the entire test suite if just one test is
2020-07-08 20:59:14 <dalias> here i think it's not just the test but the code that's broken
2020-07-08 20:59:21 <dalias> i replied on the bz
2020-07-08 20:59:33 <ikke> dalias: so disabling the test suite would just hide a potential issue
2020-07-08 20:59:37 <dalias> right
2020-07-08 20:59:51 <ikke> and basically the reason why we want to run tests in the first place
2020-07-08 21:00:44 <mps> dalias: thanks for answering there
2020-07-08 21:01:25 <timlegge> Where would I find the lint checks that are run against aport APKBUILD files?
2020-07-08 21:01:26 <ikke> fun fact: the reason that we started to enforce this policy is that there was a security related bug with nginx in alpine linux that would have been caught by their own test suite
2020-07-08 21:01:56 <Cogitri> timlegge: install atools
2020-07-08 21:02:39 <mps> ikke: I agree with that, but sometimes we are 'out-of-the-luck' with some packages
2020-07-08 21:03:02 <timlegge> thanks will look
2020-07-08 21:03:27 <ikke> mps: Yes, understand, but it should be an informed decission
2020-07-08 21:04:03 <mps> that is why I annoyed all you here :)
2020-07-08 21:04:07 <ikke> :)
2020-07-08 21:04:53 <mps> most upstream fixes reported issue but some don't
2020-07-08 21:05:06 <ikke> yup
2020-07-08 21:05:18 <ikke> This upstream seems to be quite cooporative
2020-07-08 21:06:06 <mps> hmm, lets see
2020-07-08 23:51:47 <Terror> Hi team
2020-07-08 23:52:14 <Terror> Anyone here can take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/9622 and merge if there's nothing else to do? Thanks!
2020-07-09 08:22:13 <PureTryOut[m]> There are quite a lot of packages in the main repo without a maintainer, what shall we do about them? https://pkgs.alpinelinux.org/packages?name=&branch=edge&repo=main&arch=x86_64&maintainer=None
2020-07-09 08:22:14 <PureTryOut[m]> Cogitri: you might want to take up maintainership for https://pkgs.alpinelinux.org/package/edge/community/x86_64/gnome-icon-theme
2020-07-09 08:23:46 <PureTryOut[m]> Also https://pkgs.alpinelinux.org/package/edge/community/x86_64/appstream maybe?
2020-07-09 08:30:17 <mps> I thought to take maintainership for some of them but I'm not sure is it good idea to take it without having push rights to main
2020-07-09 08:56:08 <Cogitri> I think gnome-icon-theme should be removed, it has been superseded by adwaita-icon-theme years ago AFAIK
2020-07-09 08:58:02 <ikke> mps: You can still make merge requests
2020-07-09 08:58:33 <ikke> maintaining packages in main should be an issue without push rights, similar to how people maintain packages in community / testing without any push rights at all
2020-07-09 08:59:52 <afontain_> you mean shouldn't?
2020-07-09 09:00:17 <ikke> s/should/shouldn't/
2020-07-09 09:00:17 <alpine-meetbot> ikke meant to say: maintaining packages in main shouldn't be an issue without push rights, similar to how people maintain packages in community / testing without any push rights at all
2020-07-09 09:00:19 <ikke> yes
2020-07-09 09:01:14 <mps> Freud :)
2020-07-09 10:32:18 <ncopa> was there any patch that was neeed for tim64 for glib?
2020-07-09 10:32:29 <ncopa> libical testsuite fails
2020-07-09 10:32:36 <ncopa> The following tests FAILED:
2020-07-09 10:32:36 <ncopa>          46 - libical-glib-component (SEGFAULT)
2020-07-09 10:32:36 <ncopa>          54 - libical-glib-recurrence (SIGTRAP)
2020-07-09 10:32:36 <ncopa>          50 - libical-glib-misc (SEGFAULT)
2020-07-09 13:48:46 <mps> ikke: (I'm back) yes, i know that I can make MR, and I 'have' one pkg (ell) in main, but I always feel something strange when creating MR for it
2020-07-09 13:49:50 <mps> thanks good maxice8 is quite fine and 'gracious' with my MRs for main
2020-07-09 13:53:00 <mps> ncopa: regarding glib, this is from one of 32bit newedge builders?
2020-07-09 13:53:25 <ikke> yes
2020-07-09 13:53:40 <ikke> https://build.alpinelinux.org/buildlogs/build-newedge-x86/main/libical/libical-3.0.8-r2.log
2020-07-09 13:53:45 <mps> aha
2020-07-09 13:53:52 <ikke> that does not work yet :-/
2020-07-09 13:54:05 <mps> 404
2020-07-09 13:54:09 <ikke> yes
2020-07-09 13:54:20 <ikke> those builders are not setup to upload the log yet apparently
2020-07-09 13:55:45 <mps> does ti appears on armv7? I can ask my son to borrow me armv7 box later (where is musl 1.2.0 is installed) today to look at this
2020-07-09 13:55:53 <mps> it*
2020-07-09 13:57:02 <Cogitri> mps: seems like it fails on all 32-bit arches, so should fail, yes
2020-07-09 13:57:02 <mps> hmm, maybe I can set lxc on my aarch64 box with musl 1.2.0
2020-07-09 13:57:15 <Cogitri> A stacktrace and valgrind output would be much appreciated
2020-07-09 13:57:21 <ikke> mps: yes, armv7 as well
2020-07-09 13:57:35 <mps> I hope armv7 lxc will work on arm64
2020-07-09 13:57:54 <ikke> mps: that's what we do :)
2020-07-09 13:58:14 <ikke> afaik we only have arm64 hardware
2020-07-09 13:58:30 <mps> though from the head I think time_t should re/defined as ulong or some similar type
2020-07-09 13:58:31 <wsinatra> is there any performance benefit using lxc over qemu?
2020-07-09 13:58:39 <ikke> yes
2020-07-09 13:59:35 <ikke> if only the amount of reosurces you need to reserve :)
2020-07-09 13:59:51 <mps> wsinatra: qemu emulates whole physical machine, while lxc doesn't, so lxc is usually faster
2020-07-09 14:00:02 <wsinatra> hmm I might have to look into that then, I've been using Qemu for armv7/aarch64 to test SBCL builds, and it leaves a lot to be desired
2020-07-09 14:00:15 <ikke> wsinatra: lxc is no virtualization
2020-07-09 14:00:28 <ikke> so you need the hardware
2020-07-09 14:00:49 <mps> but lxc have to run on same arch or 'compatible'
2020-07-09 14:01:26 <wsinatra> Well if you're using arm64 for armv7 lxc builders then I could probably use the pine board I got for building both SBCL versions right?
2020-07-09 14:01:46 <mps> wsinatra: yes, this should work
2020-07-09 14:02:25 <mps> though can depend on host cpu 'subtype'
2020-07-09 14:03:00 <mps> some arm64 can execute arm32 code 'natively'
2020-07-09 14:03:44 <wsinatra> I'll have to look more into it when I'm off work tonight, because the 9+hr build time is killing me
2020-07-09 14:44:46 <Cogitri> Could someone check for me what the permissions on their /var/tmp is?
2020-07-09 14:45:02 <maxice8> 1777
2020-07-09 14:45:05 <Cogitri> I think abuild strips the right permissions (1777) from /var/tmp and makes it 0755, which breaks things
2020-07-09 14:45:47 <ikke> should packages even put stuff in /var/tmp?
2020-07-09 14:46:06 <maxice8> Why does /var/tmp exist and is not a symlink to /tmp ?
2020-07-09 14:46:28 <ikke> maxice8: /var/tmp is ususally not in ram
2020-07-09 14:46:30 <Cogitri> In theory FHS says that /tmp may be cleaned every reboot (so be a tmpfs), whereas /var/tmp should not
2020-07-09 14:46:55 <Cogitri> ikke: No, packages shouldn't put things into /var/tmp, but flatpak tries to put things there during runtime and throws obscure error msgs if it can't
2020-07-09 14:47:01 <maxice8> so it is tmp but not really
2020-07-09 14:47:19 <Cogitri> And something causes /var/tmp to be 0755 on my machines 🤔
2020-07-09 14:47:47 <Cogitri> Hm, it's 1777 on my VPS as well, how did it end up with 0755 on my PC and Laptop
2020-07-09 14:47:56 <Cogitri> I guess some package is overwriting it or smth?
2020-07-09 14:51:23 <ikke> yeah. it's 1777 in alpine-baselayout
2020-07-09 14:51:34 <ikke> Access: (1777/drwxrwxrwt)
2020-07-09 14:52:10 <ikke> drwxrwxrwt root/root         0 2020-06-19 10:32 var/tmp/
2020-07-09 17:31:35 <mps> hmm, looks like building armv7 in chroot on aarch64 doesn't work, 'meson.build:877:4: ERROR: Can not run test applications in this cross environment.'
2020-07-09 17:34:25 <ikke> How did you setup that chroot?
2020-07-09 17:36:23 <mps> apk --arch armv7 and rest of needed things
2020-07-09 17:36:51 <mps> do I need to run linux32 before running abuild -r
2020-07-09 17:36:58 <ikke> is this lxc?
2020-07-09 17:37:12 <mps> no, chroot
2020-07-09 17:37:32 <mps> I'm going to convert it to lxc
2020-07-09 17:37:53 <ikke> I think running with linux32 should work
2020-07-09 17:38:04 <ikke> probably best to enter the chroot with linux32
2020-07-09 17:38:40 <ikke> lxc.arch = armv7l
2020-07-09 17:38:44 <ikke> that's what we have for lxc
2020-07-09 17:40:40 <mps> armv7l or armv7
2020-07-09 17:41:17 <ikke> I copied that exactly
2020-07-09 17:42:28 <mps> ok, thanks. earlier I had armv7 only
2020-07-09 17:43:03 <mps> but, I have another issue with lxc, kernel doesn't have veth
2020-07-09 17:45:42 <mps> looks like running 'linux32' in chroot solved problem
2020-07-09 17:46:24 <ikke> why would your kernel not have veth?
2020-07-09 17:46:33 <ikke> or did you recently upgrade without rebooting?
2020-07-09 17:47:13 <mps> this is kernel I build for mediatek chromebook, it was loooong journey to get it working at all
2020-07-09 17:47:19 <ikke> aha, ok
2020-07-09 17:47:59 <mps> so, when experimenting I removed a lot of stuff, now have to add them back when I hit missing ones :)
2020-07-09 17:48:14 <ikke> right
2020-07-09 17:49:02 <mps> ohay, I rebuild glib without errors ncopa mentioned today
2020-07-09 17:49:53 <mps> with musl-dev-1.2.0-r0 installed
2020-07-09 17:51:32 <mps> hmm, glib have options="!check" :)
2020-07-09 17:51:36 <mps> meh
2020-07-09 17:54:27 <PureTryOut[m]> What does `ERROR: u-boot-pinephone-2020.07_git20200612-r0: failed to rename usr/.apk.62b83ea36893dc5d61ce444eb01c0ed3a8d4921022921b57 to usr/sbin.` mean? Even if I remove the package and rebuild it, I still can't install it
2020-07-09 18:08:05 <PureTryOut[m]> Nvm found the issue
2020-07-09 18:08:47 <ikke> PureTryOut[m]: what was it?
2020-07-09 18:08:53 <ikke> I've seen this being reported before
2020-07-09 18:31:44 <PureTryOut[m]> a faulty `install` statement. It tried to install a binary to `/usr/sbin/` but installed it as `/usr/sbin` instead. And of course it can't just replace `/usr/sbin` for some random binary
2020-07-09 18:31:52 <PureTryOut[m]> However, the error is just very vague
2020-07-09 18:32:09 <ikke> ah, right
2020-07-09 18:32:19 <ikke> you need to specify the destination filename to install indeed
2020-07-10 06:31:29 <sf-mensch> Hi, I was looking for a package and found that it doesn't exist yet.
2020-07-10 06:31:29 <sf-mensch> Can I find someone here who would create it?
2020-07-10 06:32:36 <mps> sf-mensch: you can ask ofc, but good option is to create request on gitlab.a.o
2020-07-10 06:32:50 <mps> which package?
2020-07-10 06:33:20 <Cogitri> "sf-mensch" (https://matrix.to/#/@freenode_sf-mensch:matrix.exqa.de): You could be the one to create it :)
2020-07-10 06:33:24 <Cogitri> https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
2020-07-10 06:33:46 <Cogitri> That would certainly be the best way to get your package in in an acceptable time frame
2020-07-10 06:43:01 <mps> Cogitri: you matrix gateway again send this: '"sf-mensch" (https://matrix.to/#/@freenode_sf-mensch:matrix.exqa.de):'
2020-07-10 06:43:25 <mps> your*
2020-07-10 06:50:07 <sf-mensch> The issues with self-creation are:
2020-07-10 06:50:08 <sf-mensch> * I don't know much of this specific format (only about arch/msys2, a bit of rpm)
2020-07-10 06:50:08 <sf-mensch> * the wiki says you are expected to maintain that package in the future, I'm not sure that I'm able to do so
2020-07-10 06:51:09 <ikke> Then you would need to find someone willing to take it up
2020-07-10 06:55:55 <Cogitri> mps: Ugh, that's annoying, this mobile client really is a bit suboptimal. Thanks for mentioning though
2020-07-10 06:56:22 <sf-mensch> The GnuCOBOL package. I'm the "upstream" maintainer and I try to ensure that's always up to date, but it definitely is better to have the multitude of package environments do what they can do better: take care of the package system they understand and use.
2020-07-10 06:56:55 <sf-mensch> mps: So you suggesting to open an issue "please add package gnucobol" at https://gitlab.alpinelinux.org/groups/alpine/-/issues?
2020-07-10 07:21:05 <mps> sf-mensch: yes, that is best option if you want someone to package it
2020-07-10 07:21:38 <mps> but you can also create APKBUILD and create merge request
2020-07-10 07:23:11 <mps> especially because you are upstream, someone will probably help you even if merge request is not perfect from start
2020-07-10 07:27:47 <Cogitri> And fortunately APKBUILDs are rather simple compared to other formats :)
2020-07-10 07:28:49 <mps> Cogitri: yes :)
2020-07-10 07:29:17 <mps> and it is very good that the upstream is involved in packaging
2020-07-10 07:33:33 <[[sroracle]]> sf-mensch: i might be willing to contribute a package for it
2020-07-10 07:33:46 <[[sroracle]]> i already wrote one for adelie (another APKBUILD distro)
2020-07-10 07:35:38 <mps> [[sroracle]]: so, problem solved :)
2020-07-10 07:36:44 <[[sroracle]]> i still need to bump it to 3.1
2020-07-10 07:36:50 <[[sroracle]]> we are on 3.0-rc1
2020-07-10 07:38:17 <mps> good thing that we know now it works on musl, what I intended to ask as next question
2020-07-10 07:39:12 <[[sroracle]]> indeed it does. none of the patching i needed to do was musl-related
2020-07-10 07:41:10 <mps> so +1 for MR
2020-07-10 08:05:59 <sf-mensch> [[sroracle]]: I suggest to talk on this off-list either by mail or with jami or jitsi.
2020-07-10 08:06:13 <sf-mensch> btw: yay!
2020-07-10 08:52:07 <sf-mensch> [[sroracle]]: mail sent
2020-07-10 11:14:53 <mps> if I rename locally branch from which I created MR, will the 'git push --force mps' rename MR
2020-07-10 11:19:39 <Cogitri> If you change the branch name it won't affect your MR whatsoever
2020-07-10 11:22:45 <mps> thanks
2020-07-10 14:19:35 <maxice8> What should we do with header-only packages ?
2020-07-10 14:19:43 <maxice8> They only install files in places that belong in the -dev package, and this leaves the mainpkg empty
2020-07-10 14:21:03 <Cogitri> I'd say make a -dev package anyway, otherwise it's a bit inconsistent with what files are where
2020-07-10 14:25:00 <maxice8> Aight
2020-07-10 14:27:13 <Hello71> pkgname=x-dev
2020-07-10 14:28:39 <maxice8> I'd rather stay with the actual name of the project as pkgname
2020-07-10 21:22:09 <ikke> hmm, for some reason, run-parts is not executing the script I have to make repositories public
2020-07-10 21:22:14 <ikke> it just does nothing
2020-07-10 21:22:59 <Hello71> chmod +x
2020-07-10 21:23:01 <ikke> I have
2020-07-10 21:23:05 <ikke> I can execute the script
2020-07-10 21:23:10 <ikke> it works
2020-07-10 21:25:15 <ikke> ugh ok
2020-07-10 21:25:18 <ikke> it does not like extensions
2020-07-10 21:32:18 <ikke> maxice8: I think the cron should work now
2020-07-10 21:35:00 <maxice8> nice
2020-07-10 21:38:48 <unrznbl[m]> I am trying to get autoconf to do something different on alpine systems. All I get from autoconf though is target_os=linux-musl, is that "good enough"? I need to find out if the `ps` command will likely be `busybox` or not. I suppose it would be better to just check the `ps` on the path?
2020-07-10 21:39:48 <Cogitri> Checking specifically for Alpine sounds pretty unportable, especially since you can install non-busybox ps too
2020-07-10 21:39:52 <ikke> ps would be on the path (bb symlink)
2020-07-10 21:40:03 <ikke> and that, yes
2020-07-10 21:40:37 <Cogitri> I think it'd be best to detect it during runtime if possible
2020-07-10 21:41:23 <unrznbl[m]> exactly. will do it that way.
2020-07-11 15:58:11 <rahmanshaber[m]> Cogitri:  do you think it is marge-able ?
2020-07-11 15:58:11 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10080?commit_id=2d131a097a1e1dd10508100a21e25722b0fd629f
2020-07-11 16:05:28 <maxice8> No, please remove the reverts and just don't include the commits reverted
2020-07-11 16:10:03 <rahmanshaber[m]> i can't find anything when i do git revert. it shows a text editor in the terminal to put commit message, no way to pass it without adding that revet message
2020-07-11 16:10:54 <rahmanshaber[m]> maxice8:  any help?
2020-07-11 16:11:02 <maxice8> git rebase --interactive
2020-07-11 16:11:25 <maxice8> let everything be `pick` except the revert commits and the reverted commits, put them as `drop`
2020-07-11 16:12:47 <rahmanshaber[m]> so now i have to put this commit and do what you said, right? or have to do revert again?
2020-07-11 16:13:59 <rahmanshaber[m]> also what i do after that rebase cmd is finished? git push? maxice8
2020-07-11 16:28:26 <rahmanshaber[m]> okay, i am out of this, if anyone can fix and add the new release that will be helpful, i can't do this git stuff.
2020-07-11 16:29:00 <rahmanshaber[m]>  * okay, i am out of this, if anyone can fix and add the new release that will be helpful, i can't do this git stuff.
2020-07-11 16:29:00 <rahmanshaber[m]> i am out.
2020-07-11 19:32:22 <timlegge> @rahmanshaber[m] I commented on how to git rebase on your PR its not too hard.  If you have an issue ping me
2020-07-11 23:47:14 <maxice8> ping @mpolaski
2020-07-12 04:53:42 <rahmanshaber[m]> timlegge:  thanks, i commented in the gitlab.
2020-07-12 06:42:59 <russkel> https://github.com/ros/rosdistro/pull/25776
2020-07-12 06:43:06 <russkel> woohoo, all dependencies in the tree!
2020-07-12 06:43:12 <russkel> aports tree*
2020-07-12 07:57:00 <russkel> https://gitlab.alpinelinux.org/russkel/aports/-/jobs/164292
2020-07-12 07:57:05 <russkel> why on earth does this keep failing
2020-07-12 08:04:17 <russkel> wait the armv7 builder returns armv8l ?
2020-07-12 08:04:26 <russkel> mind blown
2020-07-12 08:53:17 <ikke> russkel: the builders run on aarch64 in 32-bits mode. Curious is though that we specify armv7l in lxc, but `arch` return armv8l
2020-07-12 08:53:27 <ikke> While on the host it returns aarch64
2020-07-12 08:59:12 <russkel> is that a bug or some weirdness?
2020-07-12 08:59:31 <russkel> I have amended my patch to add armv8l in any case
2020-07-12 09:00:10 <ikke> I don't know
2020-07-12 10:30:11 <clandmeter> ikke: that's normaal
2020-07-12 10:30:28 <clandmeter> Normal on the right keyboard
2020-07-12 10:31:05 <clandmeter> armv8l is aarch64 in 32bit mode
2020-07-12 10:31:24 <ikke> Right
2020-07-12 10:31:39 <ikke> I had a suspicion, but wasn't sure
2020-07-12 11:43:01 <andypost[m]> ikke how to get what's wrong with tor on armhf builder - bus error...
2020-07-12 11:45:03 <ikke> andypost[m]: what information do you need
2020-07-12 11:54:04 <ikke> andypost[m]: testing it in a docker container now
2020-07-12 11:57:01 <andypost[m]> Curious how to deal, which docker image fir armhf?
2020-07-12 11:58:47 <ikke> armhf/alpine:edge
2020-07-12 11:58:51 <ikke> but apparently that image is old
2020-07-12 11:58:55 <ikke> so you need to upgrade it
2020-07-12 12:07:16 <ikke> also happens in a docker container
2020-07-12 12:23:37 <ikke> andypost[m]: running the test suite with gdb, see if it tells more
2020-07-12 12:47:44 <PureTryOut[m]> On my Qt 5.15 MR, the CI fails to compile qt5-qtwebengine on multiple arches constantly. It crashes with "g++: fatal error: Killed signal terminated program cc1plus". Would that mean OOM?
2020-07-12 12:48:02 <maxice8> most likely yes
2020-07-12 12:48:04 <maxice8> qt5-qtwebengine is
2020-07-12 12:49:20 <PureTryOut[m]> So is there anything I can do about it? It's the only CI failure left, otherwise I'd say it's good to merge
2020-07-12 12:49:21 <ikke> andypost[m]: I have the bus error in gdb, but I don't get a lot of info
2020-07-12 12:49:25 <PureTryOut[m]> I assume it would build just fine on the builders
2020-07-12 12:49:44 <Cogitri> Probably, yes
2020-07-12 12:49:45 <Cogitri> Same thing happens with FF
2020-07-12 12:49:56 <maxice8> That means we will get 5.15 ? :D
2020-07-12 12:52:33 <ikke> for getting debug symbols, adding a dbg subpackage should be enough, right?
2020-07-12 12:52:54 <mps> yes
2020-07-12 12:53:04 <ikke> yeah, I see -g being supplied
2020-07-12 12:53:07 <ikke> though still -O2
2020-07-12 12:53:16 <mps> or build with -g flag and !nostrip option
2020-07-12 12:53:43 <mps> -O2 is ok
2020-07-12 12:53:45 <ikke> ok
2020-07-12 12:54:15 <Cogitri> It can only lead to variables being optimized away, but the backtrace itself should be fine
2020-07-12 12:54:31 <ikke> ok
2020-07-12 13:02:08 <telmich> Can somebody point me in the right direction to solve 2 issues in a package? First one is: why does the -openrc fail in the pipeline on https://gitlab.alpinelinux.org/telmich1/aports/-/jobs/162195 ?
2020-07-12 13:02:49 <PureTryOut[m]> Well in that case !8488 is ready
2020-07-12 13:02:49 <ikke> telmich: it means the default openrc function did not find any files to move, and the resulting package is empty
2020-07-12 13:03:17 <ikke> (or rather, $pkgdir was never created)
2020-07-12 13:03:24 <ikke> $subpkgdir
2020-07-12 13:03:48 <telmich> ahh
2020-07-12 13:03:55 <ikke> telmich: so verify that there are files in $pkgdir/etc/init.d and $pkgdir/etc/conf.d
2020-07-12 13:04:46 <telmich> Ok, which brings me to the comment of mps -- how would you prefer/should the init script be included in case of wireguard tools? For me, using _split() seems like quite some rewrite. I'm not against it, just want to find out whay the preferred style/way is
2020-07-12 13:05:56 <ikke> telmich: there is a default split function for openrc
2020-07-12 13:06:09 <ikke> so it should be enough just to define it as a subpackage
2020-07-12 13:06:34 <ikke> you can just remove what you have and it should work
2020-07-12 13:06:46 <ikke> telmich: the issue is that you moved it to $pkgdir, not $subpkgdir
2020-07-12 13:07:20 <telmich> ahhh
2020-07-12 13:07:26 <ikke> telmich: what you do is you install the init.d files in $pkgdir in package()
2020-07-12 13:07:27 <telmich> I see now
2020-07-12 13:07:36 <ikke> then the default openrc split function handles the rest
2020-07-12 13:07:59 <mps> hm, braces here is must? 'chmod -v 0755 "$pkgdir"/usr/lib/libcap.so.${pkgver}'?
2020-07-12 13:08:01 <telmich> Ahhh, nice
2020-07-12 13:08:10 <ikke> no, they can be left out
2020-07-12 13:08:36 <ikke> they are only necessary if [a-z0-9_] follows the variable
2020-07-12 13:08:43 <mps> telmich: I explained that problem here few days ago, did you read it
2020-07-12 13:08:46 <maxice8> apkbuild-lint will tell you when they are required
2020-07-12 13:09:04 <ikke> you mean, when you use it and not required :)
2020-07-12 13:09:15 <ikke> by definition you cannot tell when they are required
2020-07-12 13:09:46 <telmich> >>> WARNING: wireguard-tools*: Found OpenRC directory (/etc/conf.d or /etc/init.d) but name doesn't end with -openrc
2020-07-12 13:09:48 <mps> ikke: no, I think to ask it is more safe to have braces in such cases
2020-07-12 13:10:07 <ikke> mps: braces have little to do with 'safeness'
2020-07-12 13:10:12 <ikke> unlike quotes in shell scripts
2020-07-12 13:10:21 <mps> telmich: subpackages="xxx $pkgname-openrc"
2020-07-12 13:10:31 <ikke> some people _prefer_ to use them always
2020-07-12 13:11:03 <telmich> <mps "nico: subpackages="xxx $pkgname-"> thanks!
2020-07-12 13:11:08 <mps> ikke: having braces allways is more safe (and cleaner) than sometimes have them and sometimes not
2020-07-12 13:11:34 <ikke> not safer
2020-07-12 13:11:38 <ikke> maybe cleaner
2020-07-12 13:11:51 <mps> hmm
2020-07-12 13:12:24 <ikke> if you have `set -u` defined, you are protected against using undefined variables
2020-07-12 13:12:39 <mps> I think discussion this will be nitpicking from both sides :)
2020-07-12 13:13:01 <ikke> it's like tabs versus spaces
2020-07-12 13:13:11 <mps> right
2020-07-12 13:13:55 <ikke> If you say: always quote variables in shell because it's safer, then I fully agree, because you don't have full control over the contents of the variable
2020-07-12 13:14:01 <mps> I prefer to use them if I'm not sure of the effect of removing them
2020-07-12 13:14:53 <ikke> mps: as long as the variable is not followed by an alpha-numeric character or an _, then there is no differnece
2020-07-12 13:15:06 <mps> I will left this for maintainer of libcap pkg
2020-07-12 13:15:57 <mps> which I finished finally :) !10031
2020-07-12 13:16:25 <mps> now 2.39 not 2.37
2020-07-12 13:31:43 <ikke> hmm. building / installing zstd-dbg does not result in more information :(
2020-07-12 13:32:38 <ikke> no debugging symbols found :(
2020-07-12 13:33:02 <Cogitri> You upgraded the zstd package itself too after rebuilding with -dbg ?
2020-07-12 13:33:16 <mps> file path to zstd bin
2020-07-12 13:33:29 <Cogitri> You need to have the zstd package installed in which the symbols were split
2020-07-12 13:34:12 <mps> ah, yes, both zstd and zstd-dbg
2020-07-12 13:35:28 <ikke> ok, it now loads it, but the backtrace does not improve
2020-07-12 13:35:40 <ikke> #0  0xf7b10188 in ?? () from /usr/lib/libzstd.so.1
2020-07-12 13:35:55 <ikke> Reading symbols from /usr/lib/libzstd.so...
2020-07-12 13:39:22 <mps> somehow you need to tell gdb where to find symbols for libzstd.so
2020-07-12 13:39:38 <ikke> Reading symbols from /usr/lib/debug//usr/lib/libzstd.so.1.4.5.debug...
2020-07-12 13:39:42 <ikke> it found them
2020-07-12 13:40:06 <mps> https://visualgdb.com/gdbreference/commands/set_solib-search-path
2020-07-12 13:40:29 <mps> set solib-search-path [Directories]
2020-07-12 13:41:37 <mps> have to run away, bbl
2020-07-12 13:42:24 <ikke> o/
2020-07-12 13:43:10 <ikke> https://tpaste.us/Jxvq
2020-07-12 13:48:26 <maxice8> CMake lack of pkg-config usage is kinda annoying
2020-07-12 13:53:05 <ikke> andypost[m]: not sure what else I can do
2020-07-12 13:54:45 <ikke> andypost[m]: I guess reporting it upstream
2020-07-12 18:17:18 <PureTryOut[m]> If anyone dares, !8488 is ready
2020-07-12 18:28:12 <maxice8> Let's celebrate sunday by clogging the builders :D
2020-07-12 18:39:31 <PureTryOut[m]> Exactly! 😃
2020-07-12 18:39:45 <ikke> hehe
2020-07-12 19:47:20 <ikke> PureTryOut[m]: py3-qt5 is failing
2020-07-12 19:47:29 <maxice8> too old py3-sip
2020-07-12 19:47:32 <maxice8> I have an MR for it
2020-07-12 19:47:42 <ikke> ok
2020-07-12 19:47:53 <maxice8> Error: This version of PyQt5 requires sip 4.19.23 or later.
2020-07-12 19:48:00 <maxice8> algitbot: retry master
2020-07-12 19:52:11 <ikke> yes, I saw that
2020-07-12 19:59:11 <PureTryOut[m]> Oh algitbot works here?
2020-07-12 20:05:50 <Cogitri> Yup, was surprised by that as well
2020-07-12 20:19:10 <Cogitri> PureTryOut [m]: qt5-qtwebengine fails on armv7
2020-07-12 20:20:08 <PureTryOut[m]> Yeah noticed. Some error which suggests a code failure, but on CI it at least compiled fine on x86 so not sure how this is happening
2020-07-12 20:20:51 <Cogitri> Since it's in cpu.cc I'd guess it's arch dependant
2020-07-12 20:21:25 <PureTryOut[m]> The joy of CI never succeeding because of OOM...
2020-07-12 20:23:32 <Cogitri> You could restrict the amount of build jobs like in ceph
2020-07-12 20:30:31 <PureTryOut[m]> Hmm? How would I do that? I don't have control over the CI do I?
2020-07-12 20:31:53 <Cogitri> export JOBS= in the APKBUILD
2020-07-12 20:33:11 <Cogitri> ceph does that too on in APKBUILD because it OOMS even on the builders
2020-07-12 20:33:55 <ikke> export MAKEFLAGS="$MAKEFLAGS -j$((JOBS<16 ? JOBS : 16))"
2020-07-12 20:43:18 <PureTryOut[m]> Oh just `-j<somenumber>` would work then no?
2020-07-12 20:43:37 <ikke> yes, but using that <somenumber> is still flexible
2020-07-12 20:43:56 <ikke> you don't want to set it to -j16 on an 4 core system
2020-07-13 06:51:09 <ikke> morning
2020-07-13 06:51:38 <mps> ikke: goede morgen
2020-07-13 06:51:57 <ikke> :)
2020-07-13 06:52:34 <detha>  ook goeie morgen
2020-07-13 07:13:59 <ncopa> morning
2020-07-13 07:19:13 <Cogitri> Morning 👋
2020-07-13 07:23:46 <mps> \o
2020-07-13 07:24:30 <mps> ncopa: would you look at libcap upgrade MR
2020-07-13 07:26:51 <mps> !10031
2020-07-13 07:50:15 <ikke> github is down, so expect jobs / builds that depend on github to fail
2020-07-13 08:40:11 <ncopa> mps: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10031#note_102031
2020-07-13 08:41:19 <ncopa> can you please add a comment on top of the makefile-test-fix? why it is needed and possible a reference to an upstream issue or similar
2020-07-13 08:41:50 <ncopa> there is no explanation why it is needed or if it is suitable to be upstreamed
2020-07-13 08:46:30 <mps> ncopa: with latest update in MR it is not needed anymore, all these patches are fixed upstream
2020-07-13 08:47:50 <mps> you can see details here https://bugzilla.kernel.org/show_bug.cgi?id=208477
2020-07-13 08:48:36 <mps> and I'm not sure is it worth to add notes to patch which is now removed
2020-07-13 08:49:21 <ncopa> oh, sorry, i didnt notice that
2020-07-13 08:49:38 <mps> np
2020-07-13 08:49:57 <ncopa> i just saw that there was an "unresolved thread"
2020-07-13 08:51:03 <mps> heh, yes. sometimes also I make similar 'oversights'
2020-07-13 08:52:07 <mps> I'm mostly interested to hear your opinion in check() changes
2020-07-13 09:09:38 <ncopa> LGTM
2020-07-13 09:15:38 <ncopa> re musl 1.2, i think I will simply build main, community and testing with --keep-going --skip-failure and once they are done I simply replace current build-edge-{armhf,armv7,x86}
2020-07-13 09:15:52 <ncopa> there are a handful packages that fails
2020-07-13 09:16:18 <ncopa> Cogitri: do you know what is needed t obe done with the glib introspection thing for time64?
2020-07-13 09:16:35 <mps> ncopa: is the newer kernel headers needed for this
2020-07-13 09:19:26 <Cogitri> Probably just changing a few lines in gobject-introspection and regenerating the bindings
2020-07-13 09:19:57 <Cogitri> But I think most times use GDateTime (or similiar constructs) instead of using time_t directly, so I'm optimistic that there isn't much fallout
2020-07-13 10:21:19 <ncopa> mps: i dont think kernel headers should matter
2020-07-13 10:25:00 <mps> I'm also not sure but noticed that dalias added patch in MCM for some older kernels
2020-07-13 11:08:13 <ikke> ncopa: regarding go, saw (at least) one project providing -ldflags "-s -w" to go to make smaller binaries. Does that make sense for alpine to do in general? (not sure if the default stripping already takes care of that
2020-07-13 11:09:03 <ncopa> what does -ldflags "-s -w" do?
2020-07-13 11:09:11 <ncopa> strips something?
2020-07-13 11:10:34 <ikke> -w: "omits symble table, debug information and the DWARF table"
2020-07-13 11:10:55 <ikke> https://lukeeckley.com/post/useful-go-build-flags/
2020-07-13 11:14:31 <Cogitri> Can't we split that into a seperate -dbg package?
2020-07-13 11:14:54 <Cogitri> Would be a bit unfortunate if we made Go binaries un-debugable
2020-07-13 11:16:48 <mps> -dbg are for developers and not for end users, imo
2020-07-13 11:36:32 <Cogitri> And for end users which report issues
2020-07-13 11:36:44 <Cogitri> Otherwise bug reports are next to useless
2020-07-13 12:21:42 <timlegge> @rahmanshaber[m] I just replied to your MR and I am around if you have questions
2020-07-13 12:24:49 <mps> timlegge: sorry for nitpicking, but you shouln't prefix nick with '@' on irc
2020-07-13 12:25:52 <mps> well, don't need (not "should't")
2020-07-13 12:26:44 <timlegge> mps: thanks.  I sometime forget the application that I am using - different short cust for everyone :-)
2020-07-13 12:27:02 <timlegge> s/cust/cuts/
2020-07-13 12:27:02 <alpine-meetbot> timlegge meant to say: mps: thanks.  I sometime forget the application that I am using - different short cuts for everyone :-)
2020-07-13 12:27:36 <mps> :)
2020-07-13 12:28:07 <timlegge> mps: do I need to repeat it or will most irc clients see it?
2020-07-13 12:29:46 <mps> no, not needed
2020-07-13 12:30:03 <mps> it is visible to all, I think
2020-07-13 12:31:04 <mps> prefix '@' in irc nick means channel operators (those who will kick you or ban from channel :) )
2020-07-13 13:33:56 <PureTryOut[m]> ncopa: do you have any opinions on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/6677#note_80750?
2020-07-13 14:02:51 <rahmanshaber[m]> Cogitri:  https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10080
2020-07-13 14:16:19 <ncopa> PureTryOut[m]: why does it need a cross compiler?
2020-07-13 14:40:07 <mps> !6677
2020-07-13 14:41:51 <mps> it have to build small binary for armv6 (iirc) on aarch64
2020-07-13 14:42:57 <mps> till few months ago I didn't know that arm64 (some at least) have one cortex- cpu in dice
2020-07-13 14:43:16 <mps> forgot which one
2020-07-13 14:44:39 <mps> though these arm-trusted-firmware could be built without it using some hacks, in that case cross compiler will not be needed
2020-07-13 15:06:50 <kunkku> django 1.11 is no longer supported. Should we update to 2.2 LTS or 3.0?
2020-07-13 15:25:02 <PureTryOut[m]> ncopa: yup, what mps said. It needs to build firmware for a core that uses a different architecture
2020-07-13 15:53:05 <dalias> mps, ncopa, what was the kernel header issue? is it resolved?
2020-07-13 16:02:04 <mps> dalias: I noticed that you add patch for some older kernels in MCM when you released musl 1.2.0
2020-07-13 16:02:31 <mps> I thought it is there to fix time64 for older kernels
2020-07-13 16:08:47 <mps> though I built some packages on armv7 with musl 1.2.0 and didn't had any problem, or I didn't noticed them
2020-07-13 16:13:26 <dalias> mps, prior to 5.6, kernel headers are not compatible with time64
2020-07-13 16:13:26 <dalias> that will break any software that uses them
2020-07-13 16:13:26 <dalias> this is documented in the time64 release notes
2020-07-13 16:15:51 <mps> ah, yes, I remember now. thanks for reminding me
2020-07-13 16:18:15 <dalias> it's only a few things that are affected (alsa, v4l, ppp, maybe a couple others)
2020-07-13 16:18:15 <dalias> but they will break completely if the kernel headers aren't fixed
2020-07-13 16:19:09 <mps> that explains why I don't see issues, I have 5.7 on all my boxes
2020-07-13 16:21:30 <mps> I lost my free time for last week trying to make mainline kernel on mediatek aarch64 chromebook
2020-07-13 18:02:14 <mps> what is https url for git fetch from gitlab.a.o
2020-07-13 18:02:52 <ikke> for aports?
2020-07-13 18:03:04 <mps> yes
2020-07-13 18:03:07 <mps> https://gitlab.alpinelinux.org/alpine/aports.git
2020-07-13 18:03:11 <ikke> yes
2020-07-13 18:03:13 <ikke> that
2020-07-13 18:03:48 <mps> hmm, why it didn't worked, lets try again
2020-07-13 18:04:42 <mps> hmm, works now. probably i made error somewhere
2020-07-13 18:40:33 <PureTryOut[m]> maxice8: disabling things is fine, but could you at least notify me for it when I'm the maintainer? https://gitlab.alpinelinux.org/alpine/aports/-/commit/c62541f79db1436b4237471c0937a72e3f38d845
2020-07-13 18:42:53 <mps> PureTryOut[m]: if it blocks builders I think then it is ok to simply disable it
2020-07-13 18:43:31 <PureTryOut[m]> Which I said is fine, but I like to be notified of it
2020-07-13 18:44:00 <mps> join #alpine-commits and you be notified :)
2020-07-13 18:46:13 <PureTryOut[m]> This way it can be left disabled for ages simply because I might not have realized
2020-07-13 18:46:14 <PureTryOut[m]> I am in there
2020-07-13 18:46:19 <PureTryOut[m]> Did not get a notification of it
2020-07-13 18:46:34 <PureTryOut[m]> Just CC the maintainer please
2020-07-13 18:48:51 <mps> this can be done only if there is some triggers for pushes to aports, manually doing this would be too much for those with push rights
2020-07-13 18:55:43 <[[sroracle]]> this is why i suggested that maintainer fields transition to gitlab usernames ;)
2020-07-13 18:55:50 <[[sroracle]]> would make it easy as pie to tag people
2020-07-13 18:57:19 <mps> something like that would be also good
2020-07-13 18:59:05 <PureTryOut[m]> Would it? Really? Stuff don't get disabled that often
2020-07-13 18:59:46 <[[sroracle]]> it's not just for when stuff gets disabled. lol
2020-07-13 19:00:11 <maxice8> @PureTryOut: sure
2020-07-13 19:02:33 <PureTryOut[m]> [[sroracle]]: oh yes that'd be nice
2020-07-13 19:10:42 <Cogitri> I don't think we need to change the maintainer field, having a CODEOWNERS file is the way forward imo
2020-07-13 19:12:15 <ikke> that file would be huge
2020-07-13 19:12:42 <ikke> I'm not sure if codeowners scales
2020-07-13 19:14:32 <Hello71> those sorts of files tend to be handled poorly by git merge
2020-07-13 19:14:44 <Hello71> the size isn't really a big issue
2020-07-13 23:03:49 <Terror> Hi, is the s390 buildbot thing down?
2020-07-13 23:07:10 <finnwww15> The Arch Linux Wiki has a page on installing Alpine Linux under Crostini (https://wiki.archlinux.org/index.php/Chrome_OS_devices/Crostini#Replacing_the_default_Debian_Linux_c... and I think it would be pretty great if the Alpine Linux wiki did too, because I struggled to install Alpine Linux, and I instead installed Arch under Crostini because it
2020-07-13 23:07:11 <finnwww15> was the most well documented option.Is there a place I can open an issue? I already did on the Gitlab documentation project
2020-07-14 05:11:03 <rahmanshaber[m]> ready to merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10080
2020-07-14 05:19:11 <ikke> rahmanshaber[m]: will be merged when the pipeline finishes (again)
2020-07-14 05:22:24 <rahmanshaber[m]> ikke: okay, i hate testes.
2020-07-14 05:40:42 <ikke> merged
2020-07-14 06:05:02 <rahmanshaber[m]> ikke:  thanks. every MR i did it was trouble some.
2020-07-14 06:23:15 <ikke> rahmanshaber[m]: it helps to get familiar with git so that it's easier to make clean MRs
2020-07-14 06:24:54 <rahmanshaber[m]> yes, i knw why those regulation are there but that git always gives me hard time if i did not do all things correctly at first timr.
2020-07-14 06:24:59 <rahmanshaber[m]>  * yes, i knw why those regulation are there but that git always gives me hard time if i did not do all things correctly at first time.
2020-07-14 06:35:23 <mps_> interesting, kiss linux ported to armv7 with musl 1.2.0 and 5.4 kernel. unofficial though, https://github.com/jedavies-dev/kiss-armv7/releases
2020-07-14 07:05:35 <TBB> quite a distro, that one
2020-07-14 07:12:32 <mps_> yes, because most have to be built locally I would call it 'musl gentoo' :)
2020-07-14 08:20:49 <ollieparanoid[m]> +1 for having the gitlab username in Maintainer: instead of the e-mail address (or additionally?) - it's hard to figure out gitlab.alpinelinux.org usernames for maintainers
2020-07-14 09:52:49 <Cogitri> Adding missing secfixes doesn't need a relbump, does it?
2020-07-14 09:56:43 <ikke> No
2020-07-14 09:57:04 <ikke> They are not a part of the built package
2020-07-14 10:04:17 <Cogitri> Okie, thanks
2020-07-14 10:44:01 <PureTryOut[m]> Tests are awesome
2020-07-14 12:39:40 <ncopa> kunkku: re django. we should update, but im not sure if we should go for 2.2 or 3.0
2020-07-14 12:40:55 <ncopa> kunkku: looks like we could do either. what do you think?
2020-07-14 12:41:01 <kunkku> https://static.djangoproject.com/img/release-roadmap.3c7ece4f31b3.png
2020-07-14 12:42:16 <ncopa> there is also a chart on https://www.djangoproject.com/download/
2020-07-14 12:42:36 <ncopa> 3.0 has EOL April, 2021
2020-07-14 12:42:49 <ncopa> which is ok, if we move django to community
2020-07-14 12:43:15 <ncopa> 2.2 has EOL April 2022
2020-07-14 12:43:42 <kunkku> the new versions depend on community/py3-sqlparse
2020-07-14 12:44:26 <ncopa> so either we move django to community or we move py3-sqlparse to main
2020-07-14 12:44:40 <ncopa> not sure if we need 2 year support for django
2020-07-14 12:46:03 <kunkku> if we keep it in main then 2.2 may be better
2020-07-14 12:46:17 <ncopa> agree
2020-07-14 12:46:19 <kunkku> otherwise I would go for 3.0
2020-07-14 12:46:39 <ncopa> im ok with moving it to community and go for 3.0 too
2020-07-14 12:46:54 <ncopa> not sure what will result in more work
2020-07-14 12:47:01 <ikke> patchwork seems the only application that relies on the django package
2020-07-14 12:49:18 <ncopa> so it doesnt matter what we do really
2020-07-14 13:06:02 <kunkku> patchwork is in community
2020-07-14 13:07:05 <ncopa> sounds like we want to move django to community too, and go for 3.0?
2020-07-14 13:24:09 <kunkku> apparently so
2020-07-14 13:58:21 <wsinatra> anyone got a moment to push !10281 ? Pretty sure it's good to go
2020-07-14 13:58:38 <PureTryOut[m]> What is the recommend way to pass environment variables to the program in init scripts?
2020-07-14 13:58:51 <ikke> PureTryOut[m]: conf.d?
2020-07-14 13:59:13 <PureTryOut[m]> Got an example by any chance?
2020-07-14 14:00:24 <ikke> just export VAR=value?
2020-07-14 14:03:16 <PureTryOut[m]> Sure but how to use it from the init script, or does that happen automatically?
2020-07-14 14:03:53 <ikke> yes
2020-07-14 14:04:02 <ikke> the conf.d file is sourced
2020-07-14 14:05:06 <PureTryOut[m]> Ah and then passed to the binary? Cool
2020-07-14 14:05:33 <ikke> yes, the binary inherits the environment
2020-07-14 16:21:06 <maxice8> ping MartijnBraam !10327
2020-07-14 16:21:46 <MartijnBraam> oh that was fast
2020-07-14 16:22:32 <maxice8> I'll need lab ra^W testers though
2020-07-14 16:56:04 <MartijnBraam> well I can't really easily test this, is there any way to see in what order the services were launched?
2020-07-14 16:56:11 <MartijnBraam> because it just seems to work, but there isn't any visible difference
2020-07-14 16:59:39 <maxice8> I think /var/log/rc.log
2020-07-14 16:59:56 <maxice8> needs to be enabled in /etc/rc.conf, rc_logger
2020-07-14 17:43:48 <nmeum_> speaking of openrc service dependencies: /etc/init.d/wpa_cli depends on wpa_supplicant. If wpa_supplicant is restarted, it is restarted as well. However, wpa_supplicant creates the unix domain socket used for communication between the two very late which causes wpa_cli to fail, be restarted immediatly N times by supervise-daemon and ultimately fail. what's the best way to work around that?
2020-07-14 17:47:12 <nmeum_> adding a --respawn-delay "works" but feels kind of clumsy
2020-07-14 17:49:00 <maxice8> Is the location of the socket well-defined ?
2020-07-14 17:49:06 <maxice8> Or can it trivially change due to configuration ?
2020-07-14 17:49:46 <Danct12[m]> ping Cogitri  !10331
2020-07-14 17:50:34 <nmeum> maxice8: no, it's not well-defined
2020-07-14 17:51:42 <maxice8> oof
2020-07-14 17:52:49 <nmeum> well, I think respawn delay is probably my best bet
2020-07-14 17:54:13 <nmeum> maxice8: what would you do if the socket path is well-defined?
2020-07-14 17:54:15 <nmeum> busy wait?
2020-07-14 17:54:31 <maxice8> start_pre() { poll /socket/path ; }
2020-07-14 17:54:57 <nmeum> that's what I thought :p
2020-07-14 17:55:29 <maxice8> the best solution would be a notification system like SYSTEMD_NOTIFY and s6-rc U
2020-07-14 17:55:57 <maxice8> wpa_supplicant would tell us "I'M READY" by writing to a path stored in $NOTIFY (or whatever) and then OpenRC would start the services that depend on it
2020-07-14 17:56:02 <nmeum> yeah, but we don't have that
2020-07-14 17:57:04 <maxice8> unfortunately
2020-07-14 18:00:35 <nmeum> well…I will just add the respawn-delay to wpa_cli for now
2020-07-14 18:03:51 <oweow> https://twitter.com/golang/status/1283082582675070976
2020-07-14 18:04:06 <ikke> ugh
2020-07-14 18:04:08 <ikke> ok
2020-07-14 18:04:20 <the6543> are somebody already on this CVE?
2020-07-14 18:04:23 <mps_> wpa_cli as service ? (:
2020-07-14 18:04:27 <ikke> let me see
2020-07-14 18:04:38 <nmeum> yeah, go rebuilds :S
2020-07-14 18:04:58 <ikke> the6543: afaict, no
2020-07-14 18:05:20 <nmeum> mps_: yes, I use it for link-beat detection with udhcpc, i.e. aquiring a new lease when switching networks. See /etc/wpa_supplicant/wpa_cli.sh
2020-07-14 18:05:43 <the6543> ok so package >go< has to be flagged outdated and the new 1.14.5 has to be packaged
2020-07-14 18:06:21 <the6543> and after this all packages witch are build via go need a new release?
2020-07-14 18:06:54 <ikke> the6543: flagging is not necessary
2020-07-14 18:06:58 <nmeum> they don't need a new release, packages using crypto/x509 or net/http from the go standard library need to be rebuild as go programs are statically linked
2020-07-14 18:07:04 <ikke> I'll create a (confidential) issue
2020-07-14 18:07:11 <mps_> nmeum: ah, interesting. I don't use wpa_anything for more than a year, and earlier used wpa_cli as CLI tool only
2020-07-14 18:07:38 <nmeum> ikke: the crypto/x509 issue seems to be windows-specific
2020-07-14 18:08:20 <nmeum> and the net/http thing is just a crash, so maybe not worth a rebuild? idk
2020-07-14 18:08:31 <ikke> hmm
2020-07-14 18:09:31 <the6543> If its realy windows spesicif In my opinion update the go package should be enouth
2020-07-14 18:09:34 <nmeum> mps_: you can use it for scripting too, it's very handy
2020-07-14 18:09:34 <ikke> I'll still create an issue
2020-07-14 18:09:45 <nmeum> please do :)
2020-07-14 18:10:39 <mps_> nmeum: yes, I know, about more than 5 years ago I wrote perl curses tool to manage wifi using wpa_cli
2020-07-14 18:11:47 <nmeum> hehe
2020-07-14 18:16:27 <ikke> For people who can see confidential issues: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11743
2020-07-14 18:16:45 <maxice8> Something like this: https://wiki.gentoo.org/wiki/S6#Service_readiness_notification
2020-07-14 18:18:36 <nmeum> ikke: you looking into the go upgrade for edge? otherwise I could do it
2020-07-14 18:18:56 <ikke> feel free
2020-07-14 18:19:09 <nmeum> ok, sweet
2020-07-14 18:22:43 <ikke> I'll assign the issue to you
2020-07-14 18:23:51 <nmeum> oh oh
2020-07-14 18:24:25 <ikke> You volunteerd ;-)
2020-07-14 18:25:10 <nmeum> right, already stated my opinion on how this should be handeled in the issue. let's see if anyone else has an opinion on this
2020-07-14 18:26:06 <ikke> nod
2020-07-14 18:31:23 <Cogitri> Danct12[m]: please ping me in MRs, that has a way lower chance of me forgetting it since I only mark the mail as read once I looked at the MR while IRC notifications are gone once I look at the channel :)
2020-07-14 18:33:17 <nmeum> maxice8: https://github.com/OpenRC/openrc/issues/308
2020-07-14 19:31:40 <maxice8> @PureTryOut ping, kde-framworks has kdewebkit failingg because it wants Qt5WebKit 5.14.x
2020-07-14 19:31:45 <maxice8> Please ping once I can merge that
2020-07-14 19:32:36 <maxice8> @nmeun: yes please
2020-07-14 19:34:09 <the6543> v3.12 and v3.11 runn on go-v1.13.x so update them to 1.13.13?
2020-07-14 19:34:22 <the6543> and for the log https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10335
2020-07-14 19:34:27 <ikke> Yeah, in the issue I've mentioned the affected branches
2020-07-14 19:34:33 <ikke> do you have a username on gitlab?
2020-07-14 19:34:46 <the6543> yes but no access to the issue
2020-07-14 19:34:54 <ikke> What's your username?
2020-07-14 19:34:56 <the6543> https://gitlab.alpinelinux.org/6543
2020-07-14 19:35:15 <the6543> its all 6543 - on github, gitlab, ...
2020-07-14 19:35:31 <ikke> I think you should now have access
2020-07-14 19:36:44 <the6543> @ikke sadly https://gitlab.alpinelinux.org/alpine/aports/-/issues/11743 shows still a 404
2020-07-14 19:36:50 <ikke> hhmm, ok
2020-07-14 19:38:12 <the6543> do I have to setup 2FA?
2020-07-14 19:38:22 <ikke> No
2020-07-14 19:38:31 <ikke> at least, not to get access to that issue
2020-07-14 19:38:58 <ikke> I thought mentioning you should work, but I read now that unless you reported it, you have the be at least 'reported' in the project to see it
2020-07-14 19:39:55 <the6543> 'reported' in the project - I have some commits in aports but I think this is not what it mean
2020-07-14 19:41:13 <the6543> @ikke its ok - by the way should I create pull for the 2.12 and 3.11 ?
2020-07-14 19:41:51 <ikke> not sure if nmeum is already working on that
2020-07-14 19:42:32 <the6543> didnt see a merge request come up until now
2020-07-14 19:54:32 <the6543> ok created https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10339 and https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10340
2020-07-14 19:54:39 <the6543> and enable 2FA ...
2020-07-14 19:58:33 <the6543> @ikke @nmeum created https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10335
2020-07-14 21:09:17 <mps_> #11602
2020-07-14 21:10:22 <mps_> libvirt is buggy
2020-07-14 21:10:52 <mps_> I'm not sure this issue is fixable easy
2020-07-14 21:11:06 <mps_> and I wouldn't try
2020-07-14 21:11:19 <mps_> oh, my nick is changed
2020-07-14 21:13:26 <dalias> the libvirt deadlock bug is easy to fix
2020-07-14 21:13:36 <dalias> just remove all the inane logging-reset stuff between fork and exec
2020-07-14 21:13:50 <mps> Cogitri: I meant to mention you for this libvirt issue because I see your comments in issue report
2020-07-14 21:14:13 <mps> and I don't want to comment there
2020-07-14 21:14:45 <mps> dalias: wouldn't that be a big patch
2020-07-14 21:14:57 <dalias> no
2020-07-14 21:15:44 <mps> ok, I stand corrected
2020-07-14 21:17:24 <dalias> just comment out all the virLogReset, virLogSetFromEnv, and virReportSystemError in src/util/vircommand.c's virExec
2020-07-14 21:17:39 <dalias> that might leave you with fd leaks to child
2020-07-14 21:17:54 <dalias> if so, you need to fix the logging code to make the logging fd close-on-exec
2020-07-14 21:18:27 <dalias> uhg i'm still getting logged out of alpine's gitlab
2020-07-14 21:18:39 <dalias> i thought the session expiration bug was fixed
2020-07-14 21:19:02 <mps> thanks for exhaustive explanation, but I will not touch that code
2020-07-14 21:19:14 <dalias> :)
2020-07-14 21:19:20 <dalias> i'll comment on the issue
2020-07-14 21:20:47 <mps> heh, ok. maybe someone brave enough will fix it :)
2020-07-14 21:22:33 <dalias> done
2020-07-14 21:24:24 <mps> dalias: btw, one of my pet-peeve is busybox acpid, and I remember that you patched it for something. but today I found this
2020-07-14 21:24:32 <mps> https://k1ss.org/wiki/software/acpid#2.0
2020-07-14 21:25:05 <mps> didn't know for /etc/acpi.map
2020-07-14 21:26:56 <dalias> that's what i told you about last time :)
2020-07-14 21:28:16 <mps> hmm, so I misunderstood then. I started to making patches for source to change 'that'
2020-07-14 21:29:25 <mps> 'strings /bin/busybox | grep acpi' told me something new
2020-07-14 21:35:33 <dalias> acpid is really poorly named; it's just a daemon to sniff input events globally and perform actions on them
2020-07-14 21:36:11 <dalias> and it uses a rather arcane undocumented file to do the mapping, with only minimal built-in mappings in the absence of that file
2020-07-14 21:38:37 <mps> agree, thinking of something which looks at events and perform actions, evtest but daemon with actions
2020-07-14 21:49:32 <dalias> yeah. that's basically what it is
2020-07-14 21:51:39 <Hello71> I have an idea, you should call it "logind"
2020-07-14 21:52:53 <dalias> ..
2020-07-14 22:22:47 <mps> Hello71: heh, make sense, because I thought to set SW_PEN_INSERTED as login/logout event :)
2020-07-14 22:35:54 <Hello71> the joke is that on systemd, the logind component handles power and other buttons
2020-07-14 22:39:39 <mps> ... joke ... systemd :)
2020-07-14 22:40:02 <wago> Microsoft is pushing code to systemd now so it's risky to run in my opinion. I'm switching my Debian systems to Alpine Linux.
2020-07-14 22:41:38 <mps> heh, I was one of the early proponents of systemd on debian-devel ML, shame on me ;)
2020-07-14 22:42:28 <mps> and, what is worse, early adopter
2020-07-14 22:44:55 <wago> I helped with what is known as SPF (email). MS came in and 'wanted to get involved'. gave the head of the project a payday then told everyone they owned the patents on everything. :) not saying that's what will happen with systemd but they have 'priors'
2020-07-14 22:45:31 <wago> that was like 2 decades ago so maybe they've changed lol
2020-07-14 22:48:46 <mps> big companies/foundations are not evil because there are evil people but because their primary goal is more money and nothing else
2020-07-14 22:53:45 <Hello71> is there any reason why gcc doesn't use bootstrap-lto, or is it just that nobody tested it?
2020-07-14 22:54:13 <Hello71> afaik debian uses it on all archs
2020-07-14 22:56:04 <Hello71> I guess it could cause issues with musl and libgcc, but that seems unlikely?
2020-07-14 22:56:13 <dalias> ?
2020-07-14 22:56:49 <dalias> what does bootstrap-lto mean? build a lto'd gcc?
2020-07-14 22:57:45 <dalias> if so, is there any reason to believe that would produce a better gcc? generally my experience with lto is that, except for really bad c++, it makes things worse not better. and it has huge potential to turn "harmless" UB into catastrophic UB
2020-07-14 22:57:49 <Hello71> uh... all 64-bit archs except alpha hppa m68k mips mipsel mips64el riscv64 sh4 sparc64 hurd-i386
2020-07-14 22:57:59 <dalias> ?
2020-07-14 22:58:22 <Hello71> it runs a lot faster
2020-07-14 22:58:26 <dalias> most of those are not 64-bit archs
2020-07-14 22:58:38 <dalias> can you point to results showing that?
2020-07-14 22:59:11 <dalias> even if it is faster tho, i wouldn't trust gcc not to have UB that manifests when LTO'd
2020-07-14 22:59:30 <Hello71> well I think these two checks were added independently of each other
2020-07-14 22:59:40 <Hello71> I suspect that the 64-bit check is 4G related
2020-07-14 23:00:32 <Hello71> https://lists.debian.org/debian-mips/2019/07/msg00000.html an untested anecdote
2020-07-14 23:03:36 <dalias> 4G?
2020-07-14 23:03:58 <Hello71> ld ram usage
2020-07-14 23:04:20 <dalias> ah
2020-07-14 23:04:24 <Hello71> firefox/chromium ran into it many years ago, so I wouldn't be surprised if gcc is there now
2020-07-14 23:05:00 <Hello71> hm, but gcc lto runs in separate processes... dunno then
2020-07-14 23:06:57 <dalias> that's the process that would oom
2020-07-14 23:07:17 <dalias> essentially lto just re-runs gcc on the saved IR from all the .o files combined
2020-07-14 23:07:23 <dalias> so it's like gcc on a gigantic source file
2020-07-14 23:07:28 <dalias> and it's likely to OOM
2020-07-14 23:07:31 <Hello71> no, it's partitioned
2020-07-14 23:07:40 <Hello71> although it could still oom with the default settings, idk
2020-07-14 23:07:47 <dalias> ok, well it is slightly less awful than that
2020-07-14 23:07:56 <dalias> but the whole concept is really bad
2020-07-14 23:08:04 <Hello71> but you can adjust the partition size, I think down to one object file (although that would obviously be useless)
2020-07-14 23:08:22 <dalias> how does it know which things to put in a partition together? afaict it can't know
2020-07-14 23:08:32 <dalias> it just has to guess and if it guesses wrong it will be useless or worse than useless
2020-07-14 23:08:57 <dalias> lto is a huge hammer in search of rare tiny nails
2020-07-14 23:09:34 <dalias> and it's mostly a workaround for idiomatic c++ being so awful
2020-07-14 23:10:04 <Hello71> uh... I think it splits into similarly sized chunks and then hopes for the best
2020-07-14 23:11:37 <Hello71> cpython sets -flto-partition=none, which bypasses that problem but returns us to the original problem of single-threaded, high ram usage linking.
2020-07-14 23:12:11 <dalias> this whole thing is ill-thought-out
2020-07-14 23:12:24 <Hello71> also see https://lists.alpinelinux.org/~alpine/devel/%3C1593625212.dirkptm3b0.none%40localhost%3E
2020-07-14 23:12:33 <dalias> i'd hope at the very least it would make some dependency graph of functions
2020-07-14 23:12:40 <dalias> and then try to partition according to the structure of the graph
2020-07-14 23:13:57 <Hello71> dunno. I could be wrong, maybe they have some heuristics. I doubt they do a full graph though, that sounds like it would take a long time.
2020-07-14 23:14:08 <dalias> basically LTO is potentially interesting on near-leaf branches where the leaf and possibly a few other levels before it are either trivial-size, or have the potential to collapse to trivial size via IPA constant propagation
2020-07-14 23:14:12 <Hello71> afaik llvm's "thin lto" does something smart, although I have no idea what it is. apparently it can do some caching or something
2020-07-14 23:15:09 <dalias> otherwise it's entirely useless
2020-07-14 23:15:27 <Hello71> I think lto is useful for larger projects where module separation is driven more by development convenience than runtime performance
2020-07-14 23:16:48 <Hello71> at https://lists.alpinelinux.org/~alpine/devel/%3C1593625212.dirkptm3b0.none%40localhost%3E I tested debian gcc vs alpine+O2 gcc and found that debian gcc was 30-50% faster for allnoconfig kernel builds
2020-07-14 23:17:04 <dalias> for that use case LTO is idiotic, it just slows down process
2020-07-14 23:17:07 <dalias> use normal .o files
2020-07-14 23:17:16 <dalias> and it will be vastly faster to develop
2020-07-14 23:18:02 <dalias> hello71, unless you profiled that with perf it doesn't tell you anything about whether LTO was involved in the reason
2020-07-14 23:18:15 <Hello71> sure
2020-07-14 23:18:25 <Hello71> but I was mainly testing O2 there
2020-07-14 23:18:28 <dalias> it could be something like memcpy or memset being faster in glibc
2020-07-14 23:18:46 <dalias> or locks being elided in glibc
2020-07-14 23:19:01 <dalias> or lots of time spent in malloc
2020-07-14 23:19:23 <dalias> or fortify (most likely)
2020-07-14 23:19:39 <Hello71> you mean _FORTIFY_SOURCE?
2020-07-14 23:19:41 <dalias> yeah
2020-07-14 23:19:56 <Hello71> wouldn't that make debian slower and alpine faster
2020-07-14 23:20:00 <dalias> no
2020-07-14 23:20:13 <dalias> alpine builds everything with fortify
2020-07-14 23:21:00 <Hello71> I mean, I can try building gcc with lto on alpine, but my original question was just "is this known to be broken or did nobody try it yet"
2020-07-14 23:21:17 <Hello71> since if it is known to be broken or if it is known to be unwanted then I'll save myself the effort
2020-07-14 23:21:29 <dalias> probably just nobody tried it
2020-07-14 23:21:38 <dalias> i'm not even sure if alpine uses a bootstrapped gcc
2020-07-14 23:23:06 <Hello71> unspecified, which I think is bootstrap
2020-07-14 23:23:35 <Hello71> https://git.alpinelinux.org/aports/tree/main/gcc/APKBUILD#n271
2020-07-14 23:24:03 <Hello71> so the answer is bootstrap except on cross (why does that need to be explicitly specified anyways)
2020-07-15 00:57:46 <Ariadne> 
ACTION mutters Things(tm) about cyrus-sasl

2020-07-15 00:57:56 <dalias> yes?
2020-07-15 00:58:17 <Ariadne> for example, why the hell is SASL PLAIN a plugin in cyrus
2020-07-15 00:58:27 <Ariadne> that is just begging for some packager to shoot themselves in the foot
2020-07-15 01:00:13 <dalias> yes that actually happened (they used to be in main package then were separated out and not deps) and broke things badly
2020-07-15 01:00:13 <dalias> you mean "broken by default unless you also install the plugin packages"?
2020-07-15 01:00:13 <Ariadne> Hello71: tbh alpine is not gentoo, and unless there are actual numbers proving LTO is faster, i'm not terribly interested in doing a ton of work to make LTO a reality in alpine (:
2020-07-15 01:00:22 <Ariadne> yes
2020-07-15 01:00:24 <Ariadne> i fixed it
2020-07-15 01:00:42 <Ariadne> splitting out some plugins is fine, but SASL PLAIN is madness
2020-07-15 01:00:55 <Ariadne> also not conformant to spec ;)
2020-07-15 01:01:47 <Ariadne> that email Hello71 made with huge CFLAGS strings was scary
2020-07-15 01:02:02 <Hello71> 
ACTION coughs

2020-07-15 01:02:24 <Ariadne> i thought for a moment that i was on a gentoo devel mailing list, it was quite confusing
2020-07-15 01:03:36 <Ariadne> and besides, glibc does a lot of things musl does not to get those "kick-ass benchmarks"
2020-07-15 01:03:44 <Ariadne> like AVX-512 memcpy
2020-07-15 01:03:57 <Ariadne> which is crazy but ok
2020-07-15 01:05:32 <Ariadne> (and alpine does use a bootstrapped gcc)
2020-07-15 01:05:46 <Ariadne> every time gcc is built it does the whole stage1/stage2/stage3 thing
2020-07-15 01:06:10 <Ariadne> i would expect all the apk distributions use bootstrapped gcc
2020-07-15 01:06:38 <Ariadne> since most of them just track alpine gcc to some extent
2020-07-15 01:31:24 <Ariadne> personally I think having optimized asm in libc is kinda silly in 2020
2020-07-15 01:31:32 <Ariadne> let the compiler deal with it
2020-07-15 01:35:06 <Hello71> that's, uh... optimistic
2020-07-15 01:42:03 <Ariadne> it really isn't.  compilers are generating largely good code for musl
2020-07-15 01:42:18 <Ariadne> and musl does not have optimized ASM all over the place
2020-07-15 05:35:51 <Cogitri> dalias: that auto logout thingie is a feature of gitlab unfortunately
2020-07-15 05:42:57 <ikke> I do wonder what this setting is for then: (which is what dalias referred to): https://imgur.com/a/EUeqfxn
2020-07-15 07:00:17 <ncopa> im updating linux headers to 5.7
2020-07-15 07:03:35 <mps> :)
2020-07-15 07:03:58 <mps> good to hear
2020-07-15 07:08:41 <mps> how much max. characters should be pkgdesc
2020-07-15 07:09:46 <mps> 80?
2020-07-15 07:11:21 <mps> CODINGSTYLE.md have this 'recommendation and not a string requirement which must be followed at'. string or strict?
2020-07-15 07:11:53 <ikke> Would make sense
2020-07-15 07:11:59 <ikke> 'strict'
2020-07-15 07:13:50 <mps> what about previous question, pkgdesc length
2020-07-15 07:18:18 <ikke> 117 is the current ma
2020-07-15 07:18:19 <ikke> max
2020-07-15 07:18:28 <ikke> ag -G APKBUILD '^pkgdesc' | cut -f2 -d= | tr -d '"' | wc -L
2020-07-15 07:19:22 <mps> thanks for info, but do we have limit or some 'best practice' for this
2020-07-15 07:19:35 <ikke> I don't think so
2020-07-15 07:20:23 <Cogitri> Wasn't version mismatch between linux-headers and linux-lts bad?
2020-07-15 07:20:26 <mps> !10344 look at pkgdesc
2020-07-15 07:21:16 <Cogitri> That's a bit long, yes
2020-07-15 07:21:22 <mps> Cogitri: no, kernel doesn't makedepends on linux-headers
2020-07-15 07:21:44 <ikke> typical you leave out the package / product name
2020-07-15 07:22:29 <ikke> from man units: 'unit conversion and calculation program'
2020-07-15 07:22:46 <mps> would be nice if someone with good and big experience update CODINGSTYLE.md so we can use it as reference when commenting MRs
2020-07-15 07:23:56 <mps> for now I will comment how I know now
2020-07-15 07:24:20 <Cogitri> mps: Yes, the kernel doesn't makedepend on it, but if you build something against the new linux-headers and some struct has changed the application will crash/misbehave on older kernels IIRC
2020-07-15 07:27:57 <mps> Cogitri: right, but it is for edge only and transition to new kernels must start sometimes
2020-07-15 07:28:37 <mps> new kernel is 'must' for musl 1.2.0 on 32bit arches
2020-07-15 07:31:44 <ikke> is there any forwards or backwards compattibility?
2020-07-15 07:33:07 <ncopa> linux has a strict ABI compat policy so it should be ok
2020-07-15 07:33:36 <ncopa> otherwise there would be problems running containers on redhat/centos with ancient kernels
2020-07-15 07:33:41 <mps> ikke: maybe in some corner cases
2020-07-15 07:33:50 <ncopa> should be ok
2020-07-15 07:34:09 <mps> but I didn't found any issue till now
2020-07-15 07:48:06 <Cogitri> It's only an issue if you rebuild things against the new kernel-headers and a new attribute has been added to a struct that an application conditionally uses in newer versions
2020-07-15 07:48:50 <[[sroracle]]> [02:28] <mps> new kernel is 'must' for musl 1.2.0 on 32bit arches
2020-07-15 07:48:54 <[[sroracle]]> new kernel headers are a must
2020-07-15 07:48:58 <[[sroracle]]> new kernel itself isn't required
2020-07-15 08:00:45 <mps> because that i wrote 'must' not MUST
2020-07-15 08:08:12 <ikke> hmm, aparently gzip conflicts with zutils
2020-07-15 09:08:49 <ikke> currently a lot of failures on the newedge buidlers
2020-07-15 10:12:34 <ncopa> yes, im ignoring the errors for now
2020-07-15 10:14:56 <Cogitri> Btw, seems like wine's build makes make SEGFAULT on x86
2020-07-15 10:16:00 <Cogitri> !8465
2020-07-15 11:33:33 <Hello71> Ariadne: regarding those CFLAGS, you'll have to bring it up with dalias
2020-07-15 11:34:10 <ikke> tor and qt5-webengine are still failing on armhf and armv7 respectively
2020-07-15 11:37:11 <Hello71> Ariadne: as I said in the email, I got them from him. I assume he in turn probably got them from the gcc man page
2020-07-15 12:39:11 <PureTryOut[m]> maxice8: !10275 is ready
2020-07-15 13:49:54 <ikke> PureTryOut[m]: kconfig fails (on s390x), "qt.qpa.xcb: could not connect to display :99"
2020-07-15 14:36:30 <maxice8> https://build.alpinelinux.org/buildlogs/build-edge-s390x/community/kconfig/kconfig-5.72.0-r0.log
2020-07-15 14:36:40 <maxice8> Huh, even with xvfb-run
2020-07-15 14:36:50 <maxice8> guess it really wants a full X server
2020-07-15 15:03:35 <Hello71> xvfb isn't working then
2020-07-15 15:05:02 <Hello71> depending on what the test does you may be able to export QT_QPA_PLATFORM=minimal
2020-07-15 15:14:06 <Hello71> offscreen probably works if it wants to copy back
2020-07-15 16:59:47 <andypost[m]> armv7 builder went ouf disk space https://build.alpinelinux.org/buildlogs/build-edge-armv7/main/py3-tox/py3-tox-3.17.0-r0.log
2020-07-15 17:05:03 <andypost[m]> the same for armhf builder
2020-07-15 17:05:36 <andypost[m]> I bet that's why "newedge" fails
2020-07-15 17:07:31 <mps> yes, disk is 100% full
2020-07-15 17:07:48 <ikke> OK, I'll look later
2020-07-15 17:08:38 <mps> maybe newedge filled it
2020-07-15 17:22:25 <ikke> Possibly
2020-07-15 19:07:40 <dalias> cogitri, re: auto logout, its not a feature because it trains you to get phished by fake "update to a bug you're watching" emails
2020-07-15 19:07:55 <dalias> it's a huge misfeature and ikke tried to fix it iirc but it still seems to be broken
2020-07-15 19:08:36 <dalias> <Hello71> Ariadne: regarding those CFLAGS, you'll have to bring it up with dalias
2020-07-15 19:08:39 <dalias> hello71, what was that about?
2020-07-15 19:18:05 <Cogitri> dalias: Yes, I also consider it an antifeature, makes you wanna use weak passwords/no 2FA
2020-07-15 19:23:47 <dalias> unless you're setting up a new/secondary machine, you should basically never enter a password after initial account creation
2020-07-15 19:24:17 <dalias> normalizing reentering your password all the time is how you get phished
2020-07-15 20:33:54 <Hello71> autofill
2020-07-15 21:02:56 <ikke> andypost[m]: I've freed some space again on that builder (and added monitoring at the same time)
2020-07-15 21:13:25 <Hello71> dalias: Ariadne is offended by -fno-align-functions etc
2020-07-15 21:22:27 <dalias> ?
2020-07-15 21:24:41 <ikke>  https://lists.alpinelinux.org/~alpine/devel/%3C1593625212.dirkptm3b0.none%40localhost%3E right?
2020-07-15 21:26:02 <Hello71> yes
2020-07-16 05:22:09 <Ariadne> issue #11745 seems to be a request for mediation between pmOS and other stakeholders
2020-07-16 08:47:07 <ncopa> we are having issues with musl 1.2 rebuilds on arm due to lack of diskspace. if you have an armv7/armhf dev container please help us by cleaning it up if you can
2020-07-16 08:50:05 <ikke> I've cleaned up mine, but it was small anyway
2020-07-16 08:50:32 <ncopa> I've cleaned up mine too
2020-07-16 08:50:48 <mps> on usa4 ?
2020-07-16 08:50:51 <ikke> yes
2020-07-16 08:50:53 <ncopa> yes
2020-07-16 08:51:10 <mps> huh, I have 3-4 GB there
2020-07-16 08:51:16 <Cogitri> aarch64 should also be cleaned up?
2020-07-16 08:51:25 <ncopa> not as urgent
2020-07-16 08:51:40 <mps> Cogitri: everything on usa4
2020-07-16 08:51:42 <ncopa> i was thinking of moving one of the newedge builders to there as an option
2020-07-16 08:52:22 <ncopa> im gonna delete build-3-[5-8]-armhf
2020-07-16 08:52:32 <ncopa> making a copy to my local machine
2020-07-16 08:53:30 <mps> I'll clean what I can
2020-07-16 08:53:34 <mps> in a hour
2020-07-16 08:54:16 <ncopa> i think what i'll do is a best-effort build of it all, then replace the build-edge-{x86,armhf,armv7} with build-newedge and push musl 1.2.0
2020-07-16 08:54:18 <Cogitri> I'll clean my aarch64 container soon too
2020-07-16 08:54:37 <ncopa> it emans that there will be a significant number of missing packages on 32 bit alpine edge
2020-07-16 08:54:52 <ncopa> but it will also make it easier for everyone to help solve those issues
2020-07-16 08:55:05 <ncopa> and it will make it possible to make the CI use musl 1.2
2020-07-16 08:56:45 <mps> uh, mps-edge-aarch64:/ # du -sh => 16.5G
2020-07-16 08:57:00 <ikke> maybe cleanup ~/packages :)
2020-07-16 08:57:01 <mps> distfiles mostly
2020-07-16 08:57:03 <ikke> or that
2020-07-16 08:57:12 <ncopa> distfiles is shared i think
2020-07-16 08:57:15 <ncopa> should be shared
2020-07-16 08:57:21 <ncopa> dont worry about distfiles
2020-07-16 08:57:57 <ikke> I don't see it mounted
2020-07-16 08:58:08 <ncopa> stunnel and s-nail testsuites hangs on 32 bit
2020-07-16 08:58:21 <mps> uh, du -sh is wrong
2020-07-16 09:05:58 <ncopa> im moving build-newedge-armhf to usa1, the aarch64 machine
2020-07-16 09:21:46 <ncopa> build-newedge-armhf is now running on usa1
2020-07-16 09:25:45 <mps> eh, 'du' lies to me, I use about 4-5GB only
2020-07-16 09:26:28 <ikke> mps: this is what I see with du when I check the contents of your container: 3.6G    total
2020-07-16 09:27:09 <mps> aarch64 container?
2020-07-16 09:27:23 <mps> armv7 is less than 1GB
2020-07-16 09:28:22 <mps> I have kernel unpacked for mediatek arm64 and didn't made patches from it so can't remove it, it takes more than 2GB
2020-07-16 09:30:54 <mps> ncopa: doesn't look that distfiles are shared between containers on usa4
2020-07-16 09:32:17 <ncopa> ok
2020-07-16 09:40:53 <ncopa> we also need to work on gcc-10 upgrade
2020-07-16 09:41:07 <ncopa> feels like i have more work but less time :-/
2020-07-16 09:43:36 <mps> gcc 10.2 will be soon released
2020-07-16 09:43:59 <mps> you can wait few days, i.e. take rest :)
2020-07-16 09:46:53 <mps> heh, new LTS kernels just released
2020-07-16 10:05:50 <mps> huh, can't believe, sitting in garden and reading kernel log but suddenly swarm of bees in my garden
2020-07-16 10:06:30 <mps> first time in my not so short life I see this :)
2020-07-16 10:07:12 <ikke> At work, there is this inner yard. There in the wall there is a bee colony. Once per year, they suddenly start to swarm
2020-07-16 10:14:47 <mps> they left us :)
2020-07-16 10:14:54 <mps> huh
2020-07-16 10:35:41 <ncopa> ok. weird issue with s-nail. test suite hangs in edge. does not hang on 3.12
2020-07-16 10:55:05 <ncopa> seems like firefox-esr no longer builds on 32 bit arches: /usr/lib/gcc/i586-alpine-linux-musl/9.3.0/../../../../i586-alpine-linux-musl/bin/ld: ../../../tools/profiler/Unified_cpp_tools_profiler0.o: error adding symbols: memory exhausted
2020-07-16 10:56:44 <ncopa> Ariadne: looks like our mips64 builder is down
2020-07-16 10:59:12 <Cogitri> Huh, ff non esr builds just fine
2020-07-16 10:59:38 <Cogitri> And that is the same version as ff-ear
2020-07-16 10:59:45 <Cogitri> So maybe trying against will work
2020-07-16 13:13:49 <mps> error adding symbols: memory exhausted, firefox-esr on armv7
2020-07-16 13:15:50 <ikke> I guess we need to limit the amount of jobs?
2020-07-16 13:16:54 <mps> that was from linker
2020-07-16 13:17:16 <ikke> mmm
2020-07-16 13:17:36 <ikke> it's not that that machine has a small amount of memory
2020-07-16 13:17:47 <mps> yes
2020-07-16 13:18:12 <ikke> # free -g
2020-07-16 13:18:14 <ikke>               total        used        free      shared  buff/cache   available
2020-07-16 13:18:16 <ikke> Mem:            125          34          50           0          40          90
2020-07-16 13:18:47 <ikke> can it be a 32-bits limit?
2020-07-16 13:18:51 <mps> didn't looked if LTO is enabled for ff-esr
2020-07-16 13:18:59 <ikke> ie, max memory per process?
2020-07-16 13:19:12 <mps> yes, sure 4GB limit for 32bit
2020-07-16 13:19:40 <mps> if the LTO is enabled then disabling it could help
2020-07-16 13:19:50 <mps> LTO is memory hog
2020-07-16 13:20:37 <mps> (optimization is root of all evils)
2020-07-16 13:20:51 <ikke> but shouldn't all 32-bits arches faces that issue?
2020-07-16 13:21:00 <ikke> or is it using more memory on armv7 for some reason?
2020-07-16 13:21:29 <mps> iirc ff-esr is enabled only or armv7
2020-07-16 13:21:51 <mps> of 32bit arches, I mean
2020-07-16 13:23:29 <Cogitri> FF non esr that is of the same version works just fine though
2020-07-16 13:23:55 <mps> different build() options? maybe?
2020-07-16 13:28:02 <Cogitri> You can diff the APKBUILDs ,but I'm pretty sure nmeum just copied it
2020-07-16 13:30:27 <nmeum> yes, i did. though I bumped the required nss version as per your recommendation ;)
2020-07-16 13:32:48 <mps> remove some non-essential libs from makedeps
2020-07-16 13:35:24 <Cogitri> Right, I should bump the nss version for normal ff as well :)
2020-07-16 13:36:01 <nmeum> iirc pipewire was added as a dependency with the upgrade
2020-07-16 13:38:24 <Cogitri> Yup, for Wayland screen sharing
2020-07-16 13:39:18 <mps> uhmmm
2020-07-16 13:40:43 <mps> gtk2 and gtk3 at the same time?
2020-07-16 14:03:47 <nmeum> firefox really is a dependency monster
2020-07-16 14:13:42 <mps> 'abuild deps' shows 230 pkgs, and I removed some deps
2020-07-16 15:15:41 <Ariadne> ncopa: ok.  will investigate it.
2020-07-16 15:25:33 <maxice8> massive derp from me
2020-07-16 15:26:59 <ikke> maxice8: what happened
2020-07-16 15:27:11 <maxice8> merged sway update with wlroots
2020-07-16 15:27:16 <maxice8> forgot other projects use it
2020-07-16 15:27:33 <maxice8> !10374
2020-07-16 15:40:39 <mps> could '--no-keep-memory' linker option help with 32bit 4GB limit? anyone have experience
2020-07-16 21:29:49 <wsinatra> any mind pushing !10281 ?
2020-07-17 06:36:13 <mps> FF-esr is probably somewhat different from 'normal'. tried to build with '-Wl,--no-keep-memory -Wl,--reduce-memory-overheads' but it still fail in link phase
2020-07-17 06:37:18 <mps> error: /usr/lib/gcc/armv7-alpine-linux-musleabihf/9.3.0/../../../../armv7-alpine-linux-musleabihf/bin/ld: reopening /home/mps/aports/community/firefox-esr/src/firefox-78.0.2/objdir/armv7-alpine-linux-musleabihf/release/libgkrust.a: Out of memory
2020-07-17 06:37:28 <mps> a lot of such messages
2020-07-17 06:50:50 <Cogitri> Huh, how does this work for normal FF
2020-07-17 06:57:06 <mps> didn't tried
2020-07-17 07:02:23 <mps> maybe we can try with less deps
2020-07-17 07:48:01 <Cogitri> Sure
2020-07-17 07:48:21 <Cogitri> I can try fixing it during the weekend in case it's still broken at that point :)
2020-07-17 07:55:35 <ncopa> I think we have a problem with testing/gron
2020-07-17 07:55:57 <ncopa> it modifiles files that are checked in to git during build
2020-07-17 07:56:12 <ncopa> there is a go.mod and go.sum in testing/gron directory
2020-07-17 07:56:19 <ncopa> those files are modified during build
2020-07-17 07:56:27 <ncopa> will break the builders for sure
2020-07-17 07:57:19 <Cogitri> Huh, that should not happen, that makes builds not reproducible
2020-07-17 07:57:30 <Cogitri> I guess it updates deps or something during build
2020-07-17 07:57:46 <Cogitri> Not really sure how to fix that though, no clue about Go
2020-07-17 07:57:46 <ncopa> i wonder how it finds/uses the go.* files
2020-07-17 07:58:51 <ncopa> maybe we should notify the maintainer
2020-07-17 07:59:12 <Cogitri> Yup
2020-07-17 08:00:17 <ncopa> i am seeing deadlocks more frequently now,  not sure why
2020-07-17 08:00:29 <Cogitri> You mean on your desktop?
2020-07-17 08:00:33 <ncopa> for example libvirtd deadlocks relatively often
2020-07-17 08:00:34 <ncopa> yes
2020-07-17 08:00:45 <ncopa> xfce4-terminal new tab
2020-07-17 08:00:59 <ncopa> deadlocks 1 out of 5 or so
2020-07-17 08:01:20 <Cogitri> libvirtd and xfce-terminal were both due to undefined behaviour in fork/exec and malloc'ing in-between of those I think
2020-07-17 08:01:35 <ncopa> s-nail testsuite deadlocks consequently
2020-07-17 08:01:35 <Cogitri> Although xfce* should be fixed after the glib upgrade to 2.64.4
2020-07-17 08:01:44 <ncopa> but its not
2020-07-17 08:02:05 <ncopa> i think there is a workaround in musl too that got backported
2020-07-17 08:02:09 <Cogitri> For libvirt they basically just said "yeah well, it works with glibc so how about we just drop support for musl", let's hope they reconsider that position and adhere to POSIX
2020-07-17 08:02:27 <Cogitri> They being upstream
2020-07-17 08:02:33 <ncopa> url?
2020-07-17 08:02:58 <Cogitri> #11602
2020-07-17 08:03:17 <Cogitri> And https://gitlab.com/libvirt/libvirt/-/issues/52 is the upstream issue
2020-07-17 08:03:32 <Cogitri> Dunno how xfce still locks for you, fabled confirmed it was fixed now 🤔
2020-07-17 08:04:32 <Cogitri> Maybe we can just patch those log calls put in libvirtd to un-break it for now
2020-07-17 08:14:17 <ncopa> i also wonder whats up with s-mail testsuite
2020-07-17 08:14:38 <ncopa> it hangs now. doesnt in v3.12. not sure why
2020-07-17 08:15:22 <Ariadne> afaik both 3.12 and edge have the backport
2020-07-17 08:15:30 <ncopa> i'd love to fix libvirtd but my $dayjob is less alpine nowdays and the musl 1.2 rebuilds has priority
2020-07-17 08:15:44 <ncopa> Ariadne: i noticed that, which makes me wonder why it hangs in edge
2020-07-17 08:15:54 <Ariadne> i'll fix libvirt
2020-07-17 08:16:03 <Ariadne> and also beat daniel berrange with a cluebat
2020-07-17 08:16:28 <Ariadne> i am quite certain that under sufficient load you can make libvirtd deadlock on glibc too
2020-07-17 08:16:33 <ncopa> please dont. beating seldomly improve motivation
2020-07-17 08:25:18 <ncopa> stunnel testsuite hangs consistently with 32bit and musl 1.2
2020-07-17 08:26:03 <Ariadne> btw if I could get error logs and repo I would fix those issues
2020-07-17 08:26:39 <ncopa> the plan is to do a best-effort build and switch to newedge
2020-07-17 08:27:45 <ncopa> i think there will be ~1000 missing packages when i do the switch, but its still better than completely empty repo
2020-07-17 08:29:07 <Ariadne> sounds ok to me
2020-07-17 08:29:46 <Ariadne> I'll work to clear the broken ones.  we probably already have patches for some of them in adelie that we can use
2020-07-17 08:30:33 <Ariadne> re: mips should be fixed Monday.  going to set up new builder stateside that I can fix in August
2020-07-17 08:30:35 <ncopa> other option is that I set up a http server on the builders and a reverse proxy somewhere
2020-07-17 08:30:47 <ncopa> ok. sounds good
2020-07-17 08:31:15 <ncopa> im also curious how this go on mips are going?
2020-07-17 08:31:26 <Ariadne> shitshow :)
2020-07-17 08:31:33 <ncopa> i saw that go 1.14 has various issues, causing docker drop go 1.14
2020-07-17 08:31:54 <Ariadne> yes, i know the cause of the deadlock
2020-07-17 08:32:06 <ncopa> but its unfixable?
2020-07-17 08:32:06 <Ariadne> it's because of the way go uses pipes with epoll
2020-07-17 08:32:12 <Ariadne> it is wrong
2020-07-17 08:32:27 <Ariadne> newer kernels than 4.9 allow it
2020-07-17 08:32:43 <ncopa> so kernel 4.10+
2020-07-17 08:32:56 <Ariadne> well 4.19 at least
2020-07-17 08:33:03 <ncopa> hm
2020-07-17 08:33:16 <ncopa> so running go applications on kernel 3.10 may or may not work?
2020-07-17 08:33:21 <Ariadne> we are almost done with reverse engineering the octeon3 nic driver
2020-07-17 08:33:29 <Ariadne> right
2020-07-17 08:33:38 <ncopa> i think centos7 uses 3.10
2020-07-17 08:33:43 <ncopa> but i suppose its heavily patched
2020-07-17 08:34:02 <Ariadne> well what I know is that the BSP kernel we have doesn't like it
2020-07-17 08:34:11 <Ariadne> epoll never wakes up
2020-07-17 08:34:19 <ncopa> reverse enginering the nic driver: you ppl are awesome :)
2020-07-17 08:34:35 <Ariadne> could be that centos backported a fix
2020-07-17 08:34:39 <Ariadne> dunno
2020-07-17 08:34:46 <ncopa> wouldnt surprise me
2020-07-17 08:34:51 <Ariadne> don't really care as we will be moving off of bsp kernel soon
2020-07-17 08:35:21 <Ariadne> I tried to use bsp kernel as dom0 type situation but linux-lts has some vdso regression
2020-07-17 08:35:32 <Ariadne> this also happens on newer linux-octeon
2020-07-17 08:35:35 <Ariadne> sooooooo
2020-07-17 08:35:47 <ncopa> sounds fun...
2020-07-17 08:35:53 <Ariadne> I think other than us the only people caring about mips is loongson
2020-07-17 08:36:24 <Ariadne> and we decided to use x86 and aarch64 (possibly in BE mode) moving forward for future projects
2020-07-17 08:36:27 <ikke> strange all these packages fail so fast on x86
2020-07-17 08:36:34 <ikke> 3 seconds per package..
2020-07-17 08:36:35 <Ariadne> because mips itself are bankrupt
2020-07-17 08:36:46 <ikke> well, that's rate limitting of algitbot I guess
2020-07-17 08:36:47 <ncopa> so we could drop mips64?
2020-07-17 08:36:54 <Ariadne> uhh
2020-07-17 08:37:03 <Ariadne> as far as release arch yes
2020-07-17 08:37:26 <Ariadne> I don't think we will pursue qualifying it for release moving forward since mips declared bankruptcy
2020-07-17 08:37:36 <Ariadne> would like to keep edge around tho
2020-07-17 08:37:38 <ncopa> ikke: sorry aobu the fail spamming
2020-07-17 08:38:03 <ncopa> i dont mind as long as it does not slow us down
2020-07-17 08:38:03 <Ariadne> and it depends on what loongson want to do
2020-07-17 08:38:07 <ikke> Just wondering why, seems no time to have actually build something
2020-07-17 08:38:25 <ncopa> im running the newedge buildesr manually
2020-07-17 08:38:40 <Ariadne> ikke depgraph misses
2020-07-17 08:38:40 <ncopa> and "continue on fail" mode
2020-07-17 08:38:49 <ncopa> yeah
2020-07-17 08:38:49 <ikke> Ariadne: ah, makes sense
2020-07-17 08:39:15 <ncopa> im considering using golang for building infra
2020-07-17 08:39:19 <Ariadne> aarch64be and ppc64 are interesting to us for future projects
2020-07-17 08:39:39 <ikke> Ariadne: curious, why be for aarch64?
2020-07-17 08:39:51 <Ariadne> networking code doesn't have to byteswap
2020-07-17 08:39:56 <ikke> ah
2020-07-17 08:39:58 <ncopa> the only thing with go im sceptic about is that it may make boostrapping new architectures mode difficult
2020-07-17 08:40:21 <Ariadne> in gcc 10, gccgo seems fairly complete
2020-07-17 08:40:28 <Ariadne> maybe we switch to gccgo
2020-07-17 08:41:21 <Ariadne> also I am planning to talk with rust devs next week about how we can move forward on fixing rust in alpine
2020-07-17 08:41:24 <ncopa> i think go is nice for server apps, good concurrency, simple deplyment (single binary)
2020-07-17 08:41:26 <ncopa> yeah
2020-07-17 08:41:32 <ncopa> i have been thinking about rust
2020-07-17 08:41:39 <ikke> I would not be opposed to go
2020-07-17 08:41:39 <Ariadne> e.g. to make rust available as part of bootstrap and without ugly hacks
2020-07-17 08:41:41 <ncopa> we need it posrted to all our arches
2020-07-17 08:41:48 <ncopa> ported*
2020-07-17 08:42:07 <the6543> hi
2020-07-17 08:42:12 <ncopa> hi
2020-07-17 08:42:20 <ncopa> i also wonder if we should drop s390x
2020-07-17 08:42:27 <ncopa> i dont think anyone is actually using it
2020-07-17 08:42:38 <Cogitri> Wouldn't oppose that
2020-07-17 08:42:56 <Ariadne> I'd like to keep it around, but we could drop it from releases
2020-07-17 08:43:04 <the6543> ask the community via twiter or so if they use s390x?
2020-07-17 08:43:17 <Ariadne> s390x has 7 figures starting price
2020-07-17 08:43:18 <Cogitri> Ariadne: Well, with Rust it's either bootstrap from latest version via a tarball/package or build all versions from what mrustc supports to the current version
2020-07-17 08:43:22 <ncopa> the only reason i can think of is that it is nice to have a big-endian platform
2020-07-17 08:43:39 <Cogitri> I don't think dropping it from releases will ease maintaince much
2020-07-17 08:43:48 <ikke> I wonder if it makes sense to have some kind of packacge level support
2020-07-17 08:43:53 <Ariadne> ncopa: yes but ppc64 and aarch64be will solve those niches
2020-07-17 08:44:01 <Cogitri> The main painpoint with it is unreliable CI and basically no upstream support
2020-07-17 08:44:01 <ncopa> *nod*
2020-07-17 08:44:03 <ikke> some arches never need all packages
2020-07-17 08:44:17 <ikke> desktops for s390x don't make sense
2020-07-17 08:44:21 <Ariadne> ikke that was basically my idea with alpine ports
2020-07-17 08:44:21 <ncopa> exactely
2020-07-17 08:44:39 <Ariadne> allow some subset with no official support of alpine to exist for those archs
2020-07-17 08:44:49 <Ariadne> what is the conclusion on squeekboard btw
2020-07-17 08:45:02 <Ariadne> somebody was unhappy that we followed an upstream change early
2020-07-17 08:45:02 <ncopa> i havent read what that was about (yet)
2020-07-17 08:45:12 <ikke> upstream changed the default layout
2020-07-17 08:45:15 <Ariadne> and tbh the new layout is kinda shit on my pinephone
2020-07-17 08:45:25 <ncopa> send them upstream
2020-07-17 08:45:29 <ncopa> i mean
2020-07-17 08:45:31 <Ariadne> would be nice to offer both since it's just a yaml file
2020-07-17 08:45:54 <ncopa> thats my initial thinking. if they complain about upstream desicion, have them complain upstream
2020-07-17 08:46:02 <ikke> Ariadne: I guess squeekboard has no support for switching layouts?
2020-07-17 08:46:26 <Ariadne> no, it just switched layouts based on context
2020-07-17 08:46:30 <Ariadne> no config option
2020-07-17 08:47:16 <ikke> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10331/diffs
2020-07-17 08:47:32 <ikke> the change was manually backported to Alpine already before upstream
2020-07-17 08:47:47 <Ariadne> it's complicated
2020-07-17 08:48:27 <Ariadne> anyways
2020-07-17 08:48:56 <Ariadne> as far as I know
2020-07-17 08:49:07 <Ariadne> there really is not anybody using alpine on s390x
2020-07-17 08:49:54 <mps> regarding go as system apps lang, though I stopped use it 2-3 years ago I still think it good lang
2020-07-17 08:49:54 <Ariadne> and while I do want to improve alpine for scientific computing, s390x is not really what they use
2020-07-17 08:50:31 <Ariadne> I have no objection to go or rust, as long as it's available on all archs and there is clean bootstrap path
2020-07-17 08:50:39 <mps> i stopped to use it because it doesn't fit my view of eccosystem
2020-07-17 08:50:59 <Ariadne> Cogitri: false.  we can generate rust-bootdtrap package that provides=rust
2020-07-17 08:51:02 <mps> imo, rust going to be new c++
2020-07-17 08:51:08 <Ariadne> and then depend on rust to build rust
2020-07-17 08:51:14 <Ariadne> it breaks the circular dep
2020-07-17 08:51:24 <ncopa> re squeekboard: i think we should wait with backporting til upstream has accepted it: https://source.puri.sm/Librem5/squeekboard/-/merge_requests/345
2020-07-17 08:51:25 <Ariadne> this is how go and ghc are done already
2020-07-17 08:52:00 <Cogitri> Ariadne: that's what we're doing already and what I said with "bootstrap from a package"
2020-07-17 08:52:20 <Ariadne> well right now we bootstrap with void package (:
2020-07-17 08:52:55 <Ariadne> point here is that bootstrap.sh would generate a rust-bootstrap package
2020-07-17 08:53:05 <Ariadne> to break the circle
2020-07-17 08:53:24 <Cogitri> As for configurability with squeekboard: You can just drop that file into your $HOME somewhere (don't know it from memory) and then squeekboard will use that
2020-07-17 08:53:31 <Cogitri> But let's see what upstream ends up doinf
2020-07-17 08:53:36 <ncopa> yeah
2020-07-17 08:53:54 <Ariadne> ok well if maintainer wants to just follow upstream, then maintainer can do that :)
2020-07-17 08:54:03 <the6543> I dont like to interupt the conversation - just a quick question
2020-07-17 08:54:05 <Ariadne> no need for core to make a decision I guess
2020-07-17 08:54:14 <the6543> should I update https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10340 to the new 1.13.14 ?
2020-07-17 08:54:20 <ikke> the6543: just go ahead
2020-07-17 08:54:30 <ncopa> im thinking we could use go for the build infra controller, which only needs to run on a single arch, while the workers could be implemented in something else, like C, python or whatever
2020-07-17 08:54:58 <ncopa> the6543: yes, please update
2020-07-17 08:55:11 <the6543> well https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10339 is NOT merged als - but 3.11 only allow securety updates so leave it?
2020-07-17 08:55:16 <the6543> *also
2020-07-17 08:55:38 <Ariadne> I want to replace BusyBox with a new implementation in rust
2020-07-17 08:55:46 <Cogitri> I think Go probably is a better choice than Rust for the infra, Rust would probably be a bit faster but I don't see infra needing that and development speed in Go is a lot better
2020-07-17 08:56:14 <ncopa> the6543: v3.11/community is completely unsupported, which means we only provide security fixes on request
2020-07-17 08:56:21 <Ariadne> the reason why I want to do this is because using rust correctly eliminates several classes of security problems
2020-07-17 08:56:30 <Ariadne> (I also want to port pkgconf to rust)
2020-07-17 08:56:31 <ncopa> so you can provide an MR for it and we'll merge it, but we won't actively fix it
2020-07-17 08:56:52 <Ariadne> (I am kinda getting tired of carrying around the same data structure code I wrote like 12 years ago)
2020-07-17 08:56:59 <ncopa> what are the rust runtime requirements?
2020-07-17 08:57:09 <ncopa> is it like a runtime lib?
2020-07-17 08:57:16 <ncopa> shared lib
2020-07-17 08:57:22 <Ariadne> it can be built that way, or static like go
2020-07-17 08:57:35 <Cogitri> But Rust breaks ABI every release
2020-07-17 08:57:40 <ncopa> how big is the the runtime?
2020-07-17 08:58:02 <Cogitri> So right now we just static link it all the time, which probably is smaller unless yoi have >=20 Rust applications installed
2020-07-17 08:58:05 <ncopa> Cogitri: so basically we need to rebuild every rust app every rust release?
2020-07-17 08:58:15 <Cogitri> If we were to dynamically link, yes
2020-07-17 08:58:19 <ncopa> ah, we do static link
2020-07-17 08:58:30 <ncopa> ok. thats kind of inconvenient
2020-07-17 08:58:30 <Cogitri> We static link everything because that's the only way to stay sane when using Rust :)
2020-07-17 08:58:36 <the6543> @ncopa then I considder aports-MR !10339 as rready
2020-07-17 08:58:47 <Ariadne> I wish rust would have a stable abi
2020-07-17 08:59:07 <Ariadne> maybe I will talk to them about it too
2020-07-17 08:59:21 <ncopa> makes it unsuitable for core system stuff
2020-07-17 08:59:42 <Ariadne> BusyBox is... problematic in a lot of ways
2020-07-17 08:59:46 <Ariadne> and toybox is worse
2020-07-17 08:59:51 <Ariadne> I already looked at it
2020-07-17 08:59:56 <ncopa> how is toybox worse?
2020-07-17 08:59:59 <mps> ncopa: sorry to be annoying by repeating, but I think go is better for this
2020-07-17 09:00:22 <Ariadne> we were talking about rust for BusyBox replacement
2020-07-17 09:00:24 <ikke> mps: I think ncopa is just comparing different options
2020-07-17 09:00:34 <Ariadne> go is fine for build orchestrator
2020-07-17 09:00:42 <ncopa> thats what im thinking
2020-07-17 09:00:44 <Ariadne> elixir would also be fine (:
2020-07-17 09:01:21 <ncopa> go would be unsuitable for a busybox replacement
2020-07-17 09:01:28 <Ariadne> anyways the initial conversation I had with some rust devs was interesting
2020-07-17 09:01:43 <Ariadne> they hadn't really thought about things from a distro perspective
2020-07-17 09:01:57 <mps> :)
2020-07-17 09:02:03 <Ariadne> which fine, but don't make my life miserable
2020-07-17 09:02:06 <ncopa> new languages seldomly do
2020-07-17 09:02:10 <mps> that is obvious
2020-07-17 09:02:13 <Cogitri> They'll need a stable ABI if they want to be a true systems programming language, but right now there's no rush to fix it for them because everything is built with cargo anyway
2020-07-17 09:02:22 <Cogitri> i don't like this shift of everything getting JSy
2020-07-17 09:02:23 <ncopa> yeah
2020-07-17 09:02:39 <Cogitri> But it sure is convenient for devs
2020-07-17 09:02:42 <ncopa> agree
2020-07-17 09:02:52 <ikke> Yeah, there is a force behind it that is hard to stop
2020-07-17 09:03:19 <Ariadne> tbh using modern C++ also eliminates many classes of security hole
2020-07-17 09:03:19 <ncopa> its convenient for those who wants to develop apps for any platform, but not for those who builds the platforms
2020-07-17 09:03:51 <ncopa> maybe i'll do build orchestrator in go, and workers in c++
2020-07-17 09:04:15 <Ariadne> and I'm considering c++ possibly for this BusyBox replacement thing
2020-07-17 09:04:27 <Ariadne> we had a pretty good experience with horizon
2020-07-17 09:04:33 <ncopa> libstdc++ is big
2020-07-17 09:04:58 <ncopa> what are the problems with busybox?
2020-07-17 09:04:58 <Cogitri> C++ is kind of messed up still though, the stdlib prefers a tiny bit of speed over usability or security at many places
2020-07-17 09:05:33 <Cogitri> At work we're basically wrapping all of libstdc++ we need so devs don't shoot themselves in the foot (too often)
2020-07-17 09:05:45 <the6543> @ncopa !10340 updated and CI passed
2020-07-17 09:05:49 <Ariadne> licensing is a mess
2020-07-17 09:06:04 <Ariadne> also many things in BusyBox are optimized for size not security
2020-07-17 09:06:10 <mps> (busybox? I want to destroy this bad world and build new from the scratch)
2020-07-17 09:06:39 <Ariadne> I guess really I just want clean implementations of the core BusyBox applets alpine ships.  we could do it in C, even.)
2020-07-17 09:07:25 <Ariadne> toybox fixes licensing but security and stability are worse and there's so many sizecoding hacks that it reads like a demoscene production
2020-07-17 09:07:30 <mps> ime, busybox upstream are cooperative
2020-07-17 09:07:45 <ncopa> a bit slow to accept patches
2020-07-17 09:07:46 <Ariadne> yes, but
2020-07-17 09:07:59 <ncopa> im relatively happy with busybox
2020-07-17 09:08:04 <Ariadne> BusyBox is basically architectural cruft
2020-07-17 09:08:08 <Ariadne> this isn't like an omg
2020-07-17 09:08:12 <Ariadne> let's replace BusyBox now
2020-07-17 09:08:16 <Ariadne> it's more
2020-07-17 09:08:23 <mps> I wouldn't consider toybox as replacement
2020-07-17 09:08:26 <Ariadne> we should think about these things moving into the next decade
2020-07-17 09:08:29 <Ariadne> yeah it's not
2020-07-17 09:08:49 <Ariadne> toybox takes my primary complaints about BusyBox and amplifies
2020-07-17 09:08:53 <ncopa> i think gnu coreutils can build as a single binary busybox-like
2020-07-17 09:09:01 <Ariadne> yeah I did that already :)
2020-07-17 09:09:04 <Ariadne> long time ago
2020-07-17 09:09:15 <mps> and I agree that busybox need improvements (a lot I'll dare to say)
2020-07-17 09:09:25 <Ariadne> we've been shipping single binary coreutils in alpine since like 3.4
2020-07-17 09:09:36 <mps> yes, coreutils are single bin
2020-07-17 09:09:42 <ncopa> oh, i didnt notice :)
2020-07-17 09:10:23 <Ariadne> BusyBox is basically another openssl case
2020-07-17 09:10:33 <mps> but coreutils doesn't have all applets which are in busybox
2020-07-17 09:10:42 <Ariadne> messed up licensing (which can't be fixed because some authors are dead)
2020-07-17 09:10:59 <Ariadne> some parts of BusyBox are gpl2 only and others are gpl3 only
2020-07-17 09:11:00 <ncopa> one thing i have been thinking of is remove some of the applets from busybox
2020-07-17 09:11:15 <Ariadne> yes, I think first step is to strip down busybox
2020-07-17 09:11:25 <ncopa> that is things that does not makes sense to run in a container
2020-07-17 09:11:29 <Ariadne> we want to replace ifupdown in busybox with a new implementation
2020-07-17 09:11:32 <ncopa> like mount
2020-07-17 09:11:52 <ncopa> ifupdown may be another candidate
2020-07-17 09:12:00 <Ariadne> also I think real iproute2 would be nice.  I have a plan to slim it down
2020-07-17 09:12:34 <Ariadne> ifupdown needs a bit of a rework anyway
2020-07-17 09:12:40 <Ariadne> it does not support dual stack
2020-07-17 09:12:42 <ncopa> but i think busybox is a low prio atm
2020-07-17 09:12:52 <mps> hmm, I prefer full (bloated) iproute2
2020-07-17 09:12:53 <ncopa> there is an issue for ifupdown
2020-07-17 09:12:57 <Ariadne> low prio for alpine but not for my team (:
2020-07-17 09:13:28 <Ariadne> my plan was to introduce ifupdown-ng package in month or two
2020-07-17 09:13:48 <Ariadne> and then talk about deprecation of both Debian ifupdown and BusyBox ifupdown
2020-07-17 09:13:51 <mps> ifupdown follow upstream (debian) closelly
2020-07-17 09:13:59 <Ariadne> it doesnt
2020-07-17 09:14:14 <mps> hm, are you sure
2020-07-17 09:14:16 <Ariadne> Debian ifupdown supports cidr
2020-07-17 09:14:20 <Ariadne> BusyBox does not
2020-07-17 09:14:28 <Ariadne> busybox is about 4 years behind
2020-07-17 09:14:34 <Ariadne> and Debian ifupdown is dead anyway
2020-07-17 09:14:52 <Ariadne> they have your choice of netplan or some python2 monstrosity called ifupdown2
2020-07-17 09:15:05 <mps> last update I did is most things I took from debian
2020-07-17 09:15:07 <Ariadne> that is "the future" over in Debian land
2020-07-17 09:15:37 <Ariadne> are we talking about the alpine "ifupdown" package or busybox
2020-07-17 09:15:55 <Ariadne> because you can apk add ifupdown and get the Debian version
2020-07-17 09:16:03 <mps> though I agree it would be better to use iproute, if someone have time to rewrite all needed 'things'
2020-07-17 09:16:07 <Ariadne> but Debian has deprecated it
2020-07-17 09:16:22 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11562
2020-07-17 09:16:23 <ikke> iproute itself has no network configuration settings
2020-07-17 09:16:32 <mps> ah yes, ifupdown pkg not bb applet
2020-07-17 09:16:56 <ncopa> i wanted to build an ifupdown replacement 10 years ago
2020-07-17 09:17:07 <Ariadne> ifquery is ifupdown2 actually
2020-07-17 09:17:10 <Ariadne> lol
2020-07-17 09:17:35 <mps> ncopa: you are not alone :) I started 20 years ago but never finished
2020-07-17 09:17:42 <Ariadne> anyway that is already kinda sorta in development
2020-07-17 09:17:48 <Ariadne> it's just C99
2020-07-17 09:19:48 <Ariadne> anyway regarding iproute2
2020-07-17 09:20:05 <Ariadne> if we split iproute2 components that are in busybox to iproute2-base
2020-07-17 09:20:13 <Ariadne> the install size difference is minimal
2020-07-17 09:20:19 <Ariadne> less than 100kb
2020-07-17 09:20:56 <Ariadne> and if we debloat busybox we can pay for it that way
2020-07-17 09:21:34 <ncopa>    │      New patch version of npm available! 6.14.5 → 6.14.6       │
2020-07-17 09:21:34 <ncopa>    │   Changelog: https://github.com/npm/cli/releases/tag/v6.14.6   │
2020-07-17 09:21:34 <ncopa>    │               Run npm install -g npm to update!                │
2020-07-17 09:21:37 <ncopa> wonderful
2020-07-17 09:22:03 <ncopa> we should make abuild run `npm install -g npm`....
2020-07-17 09:22:15 <ncopa> .... or maybe not!
2020-07-17 09:22:34 <mps> I remember that there were some efforts long time ago (from redhat iirc) to use iproute for 'ifupdon' called something like etcnet or similar
2020-07-17 09:22:50 <ncopa> then there is always networkd
2020-07-17 09:22:57 <mps> :)
2020-07-17 09:23:11 <mps> systemd-networkd?
2020-07-17 09:23:11 <Ariadne> hard pass
2020-07-17 09:23:34 <ncopa> but really, currently i'd be happy with improving busybox ifupdown
2020-07-17 09:23:52 <Ariadne> no objection to that in meantime
2020-07-17 09:24:08 <Ariadne> but longer term I think it makes more sense to just split it
2020-07-17 09:24:19 <Ariadne> however talk is cheap and showing code matters more
2020-07-17 09:24:29 <Ariadne> so I think I will show code first :)
2020-07-17 09:24:44 <Ariadne> as I did with pkgconf ;)
2020-07-17 09:28:41 <mps> right. but time is short these days which lasts, at least for me :(
2020-07-17 09:28:57 <Ariadne> incidentally where has fabled been lately
2020-07-17 09:29:40 <ncopa> dunno. i guess busy
2020-07-17 09:32:20 <Ariadne> hopefully busy :/
2020-07-17 09:32:25 <Ariadne> in these times who knows
2020-07-17 09:35:52 <mps> don't be pessimist
2020-07-17 09:37:43 <mps> statistic shows that in my county death rate is 2.8% lower for first 4 months than previous year despite all this hype
2020-07-17 09:37:55 <ncopa> i think he is ok. talked with him a couple of weeks ago
2020-07-17 09:39:01 <Ariadne> mps: personal experience shows that my lungs are back to being basically as fucked as they were when i got pneumonia after the 2018 h1n1 flu season
2020-07-17 09:39:27 <Ariadne> it is serious, despite the hype
2020-07-17 09:40:05 <mps> oh, I'm sorry to hear this
2020-07-17 09:40:57 <ikke> people tend to underestimate the severity of it
2020-07-17 09:44:18 <mps> anyway, people have to care for self and other
2020-07-17 09:56:30 <Cogitri> At least in Germany most people act as if everything is back to normal already, kind of scared that we'll have a 2nd wave due to that
2020-07-17 10:03:42 <mps> same is in Serbia. people cannot live too long in fear
2020-07-17 11:25:44 <Hello71> mps, Cogitri: I guess you probably know this already, but afaik firefox upstream officially requires "cross" compiling for 32-bit for many years now
2020-07-17 11:29:51 <Cogitri> Yes, but we can't do that
2020-07-17 11:29:56 <Hello71> Ariadne: according to https://meltware.com/2019/01/16/gccgo-benchmarks-2019.html (I googled "gccgo performance"), gccgo is still much slower than gc
2020-07-17 11:30:21 <Ariadne> Hello71: https://www.shlomifish.org/humour/by-others/funroll-loops/Gentoo-is-Rice.html
2020-07-17 11:30:29 <Cogitri> Ah wait, I think we disabled debug info completely for ff non esr, maybe that didn't get carried over to -esr
2020-07-17 11:30:45 <Cogitri> Can't check right now though, at work (waiting for things to compile... :D)
2020-07-17 11:33:14 <ikke> $pkgname-dbg
2020-07-17 11:33:17 <ikke> its still present
2020-07-17 11:33:29 <Ariadne> i added -dbg to firefox-esr on purpose :/
2020-07-17 11:33:48 <Ariadne> i need debug symbols to continue investigating widevine
2020-07-17 11:34:07 <Ariadne> i hear you can get maximum i/o performance by storing everything on tmpfs, and maximum cpu performance by compiling everything with -O3
2020-07-17 11:35:26 <Ariadne> be sure to set cpu governor to performance tho
2020-07-17 11:35:29 <Ariadne> very important
2020-07-17 11:35:42 <Ariadne> also, if you're on raspberry pi, be sure to overclock the cpu to like 5ghz
2020-07-17 11:35:48 <Ariadne> that way you can get maximum performance
2020-07-17 11:36:11 <Ariadne> at least i think it is raspberry pi that lets you overclock from inside linux
2020-07-17 11:36:12 <Ariadne> i forget
2020-07-17 11:36:39 <ikke> Ariadne: I'm not following your response? What are you reacting to?
2020-07-17 11:36:48 <Ariadne> ikke: to which?
2020-07-17 11:36:56 <Ariadne> oh
2020-07-17 11:37:00 <Ariadne> those are two separate points
2020-07-17 11:37:04 <ikke> aha ok
2020-07-17 11:37:19 <Ariadne> one is "i need debug symbols in firefox to fix widevine"
2020-07-17 11:37:33 <Ariadne> the other is the logical conclusion to pushing for max performance
2020-07-17 11:37:35 <Cogitri> Well, can you build ff-esr-dbg locally?
2020-07-17 11:37:41 <Ariadne> uhhhhhh
2020-07-17 11:37:47 <Cogitri> Or else disable 32-bit
2020-07-17 11:37:57 <Cogitri> We can't get both at the same time unfortunately
2020-07-17 11:37:59 <ikke> firefox-esr is now failing to build
2020-07-17 11:38:07 <Ariadne> does it build on 64-bit
2020-07-17 11:38:15 <Cogitri> Yes, due to debugging info taking up too much RAM
2020-07-17 11:38:16 <Ariadne> i only need it on x86_64
2020-07-17 11:38:32 <Ariadne> maybe
2020-07-17 11:38:36 <Cogitri> Well, it fails to build on 32-bit due to that
2020-07-17 11:38:47 <Ariadne> [ "$CARCH" = "x86_64" ] && subpackages="$subpackages $pkgname-dbg"
2020-07-17 11:38:53 <Hello71> Ariadne: https://en.wikipedia.org/wiki/Slippery_slope
2020-07-17 11:38:54 <alpine-meetbot> [WIKIPEDIA] Slippery slope | "A slippery slope argument (SSA), in logic, critical thinking, political rhetoric, and caselaw, is often viewed as a logical fallacy in which a party asserts that a relatively small first step leads to a chain of related events culminating in some significant (usually negative) effect. The core of the..."
2020-07-17 11:39:17 <Cogitri> Ariadne: Works for me too if you don't want to build it yourself
2020-07-17 11:39:29 <Cogitri> But good that we found why it doesn't build.
2020-07-17 11:39:37 <Ariadne> Cogitri: go ahead.  i don't have enough ram to build firefox-esr on my x86_64 machine
2020-07-17 11:40:07 <Ariadne> or cpu cores
2020-07-17 11:40:50 <Hello71> doesn't it only require slightly more than 4 GB
2020-07-17 11:40:54 <Cogitri> I think you can request a build container for such things then instead of commiting it to the repo
2020-07-17 11:41:00 <Ariadne> i guess then i have enough ram :P
2020-07-17 11:41:59 <Cogitri> I think with the current config the -dbg package won't be too useful anyway since we force disable Rust debug info further down to lessen RAM usage on 32-bit
2020-07-17 11:42:12 <Ariadne> harumph
2020-07-17 11:42:15 <Ariadne> just revert it
2020-07-17 11:42:18 <Ariadne> i'll figure it out later
2020-07-17 11:42:27 <Ariadne> but widevine crashes inside libxul
2020-07-17 11:42:35 <Ariadne> if i cna figure out why
2020-07-17 11:42:38 <Ariadne> then it will work
2020-07-17 11:42:57 <Ariadne> Hello71: i am being sarcastic
2020-07-17 11:43:11 <Ariadne> Hello71: but my point is that sometimes, performance is really kind of a moot point
2020-07-17 11:43:32 <Ariadne> Hello71: in real world terms, the performance of the code generated by gccgo is good enough
2020-07-17 11:43:49 <Ariadne> Hello71: similarly, the performance of our gcc is good enough
2020-07-17 11:44:03 <Ariadne> i don't really care
2020-07-17 11:44:19 <Ariadne> that if we use LTO and some weird defanged -O2
2020-07-17 11:44:23 <Ariadne> to build gcc
2020-07-17 11:44:32 <Ariadne> that it can then build a kernel 1.08x faster
2020-07-17 11:44:48 <Ariadne> if this is what you want in a linux distro, alpine isn't what you're looking for bluntly
2020-07-17 11:45:45 <Ariadne> also if you want max performance non-PIC code will be faster than PIC code
2020-07-17 11:45:51 <Ariadne> similarly with PIE
2020-07-17 11:46:05 <Ariadne> also, fortify slows things down
2020-07-17 11:47:41 <Ariadne> optimizing for "kick-ass benchmarks" will compromise stability and reliability of the distro
2020-07-17 11:48:24 <Ariadne> yes phoronix readers will be super impressed, up until they put it in production and it falls over
2020-07-17 11:49:34 <Ariadne> finally the benchmarks are pointless anyway
2020-07-17 11:49:40 <Ariadne> it is comparing gccgo on glibc
2020-07-17 11:49:47 <Ariadne> verses gc on glibc
2020-07-17 11:50:36 <Ariadne> i suspect much of the overhead with gccgo on glibc is actually due to the ucontext implementation bothering to set/restore signal handlers for every single context switch.  libucontext does not bother with that.
2020-07-17 11:51:34 <Cogitri> I think having -O2 for GCC won't cause any of that and has a significant impact in build performance. Considering that it doesn't increase space requirements too much, build machines usually don't have too tight space constraints and how often we run GCC on our builders it sounds like it's worth it to me
2020-07-17 11:51:49 <mps> ahmm, I remember now that I've seen commit c51f0507637834d2eba2e948a7204cb897b10c45
2020-07-17 11:52:08 <mps> :)
2020-07-17 11:52:30 <Ariadne> Cogitri: that isn't my point
2020-07-17 11:53:35 <Ariadne> i think we should stop using -Os entirely, since people keep writing code that breaks with -Os
2020-07-17 11:53:43 <Ariadne> but that's a practical matter
2020-07-17 11:54:17 <Ariadne> and a 1.08x performance boost is not significant
2020-07-17 11:54:19 <Cogitri> Hm, to be honest I didn't see code that breaks with -Os yet
2020-07-17 11:54:30 <Cogitri> But what would you suggest we use instead?
2020-07-17 11:54:35 <Ariadne> -O2
2020-07-17 11:54:42 <Cogitri> 1.08x across thousands of runs is significant
2020-07-17 11:55:04 <Cogitri> mps: Can you revert that and see if ff-esr builds on 32-bit then? That'd be great :)
2020-07-17 11:55:40 <Ariadne> nayway
2020-07-17 11:55:44 <Ariadne> that is not my point
2020-07-17 11:56:03 <Ariadne> my point is that Hello71 keeps proposing things solely based on performance in synthetic benchmarks
2020-07-17 11:56:17 <Ariadne> in the real world, that is not important
2020-07-17 11:56:34 <mps> Cogitri: yes, I will do in a hour, I'm out of home now
2020-07-17 11:57:03 <Ariadne> worse yet, these are usually apples to oranges comparisons
2020-07-17 11:57:13 <Ariadne> [master 4906f00484] Revert "community/firefox-esr: add debug symbols package"
2020-07-17 11:57:39 <mps> yes, I tend to agree. I always prefer correctness instead of performance and features
2020-07-17 11:57:52 <Ariadne> in fact hyperfocusing on synthetic benchmarks usually screws you
2020-07-17 11:58:32 <Ariadne> consider this
2020-07-17 11:58:46 <Ariadne> 1.08x improvement is derived from building kernel
2020-07-17 11:58:57 <Ariadne> but gcc is a very complex software
2020-07-17 11:59:33 <Ariadne> 1.08x improvement on building kernel could (and probably does) translate to 1.08x slower build of something else
2020-07-17 11:59:45 <mps> if something obvious benefit I'm for change, ofc
2020-07-17 12:00:01 <Ariadne> performance improvement for a specific workload does not mean performance improvement for *all* workloads
2020-07-17 12:00:04 <mps> if is*
2020-07-17 12:00:13 <mps> sure
2020-07-17 12:00:27 <Ariadne> similarly measuring gccgo ipc performance on glibc is not a useful metric for gccgo ipc performance on musl+libucontext
2020-07-17 12:07:24 <mps> and there is saying about programming somewhere, early optimization is root of problems, (or something similar)
2020-07-17 12:08:37 <Cogitri> It's "preliminary optimization is the root of all evil" I think
2020-07-17 12:09:01 <Ariadne> premature
2020-07-17 12:09:04 <Ariadne> bbl
2020-07-17 12:09:39 <mps> yes, something like that
2020-07-17 12:15:56 <Hello71> at that rate we can argue that -Os is bad because it might increase sizes in some cases. all of this "in theory" is absolutely useless. I based my arguments on gcc documentation and benchmarks. if you want better benchmarks, you're free to find or provide them. but making disingenuous slippery slope arguments is unhelpful.
2020-07-17 14:28:33 <JonasRC> !commands
2020-07-17 14:56:25 <ikke> #alpine-commits is a bit more quiet again :_
2020-07-17 14:56:27 <ikke> :)
2020-07-17 14:57:12 <mps> yes, BDFL is on weekend :)
2020-07-17 14:57:19 <ikke> haha
2020-07-17 15:33:00 <mps> Cogitri: 'abuild deps unpack prepare build' and then 'abuild rootpkg' finished ff-esr on armv7
2020-07-17 15:33:43 <mps> with this change in APKBUILD: export LDFLAGS="$LDFLAGS -Wl,-rpath,$_mozappdir -Wl,--no-keep-memory -Wl,--reduce-memory-overheads"
2020-07-17 16:38:16 <gjabell> can someone with build access trigger a rebuild on phoc? wlroots got updated today and it still points at the old libwlroots so
2020-07-17 16:38:45 <mps> algitbot: retry master
2020-07-17 16:38:57 <mps> gjabell: lets see
2020-07-17 16:39:01 <gjabell> thanks <3
2020-07-17 16:39:11 <mps> np :)
2020-07-17 16:40:03 <mps> py3-django-treebeard fails on tests
2020-07-17 16:40:24 <gjabell> does a rebuild typically fix the so issue with packages? or do they need a revision bump
2020-07-17 16:40:56 <mps> if the so deps uploaded then yes
2020-07-17 16:41:10 <gjabell> ok, cool
2020-07-17 16:41:15 <ikke> gjabell: a revbump triggers a rebuild
2020-07-17 16:41:21 <mps> if not, then pkgrel bump will not help
2020-07-17 16:41:28 <gjabell> gotcha
2020-07-17 16:41:37 <maxice8> a rebuild is the primary fix for .so mismatch issues
2020-07-17 16:41:57 <ikke> maxice8: you were taking care of all wlroots deps, right?
2020-07-17 16:42:01 <maxice8> It usually happens when someone (most times me) upgrades a library and it changes from libfoo.X to libfoo.Y and I don't catch all libfoo.X dependants
2020-07-17 16:42:21 <maxice8> I am, yes
2020-07-17 16:42:33 <maxice8> I just fix phoc and am compiling wayfire with new wlroots
2020-07-17 16:42:37 <maxice8> that should fix all of them
2020-07-17 16:42:51 <ikke> maxice8: are you aware of ap revdep *-dev?
2020-07-17 16:43:11 <maxice8> I generally use depends so:ilbfoo
2020-07-17 16:44:12 <maxice8> one example is poppler that has libpoppler, poppler-glib and poppler-cpp, but only poppler-dev
2020-07-17 16:44:31 <maxice8> when poppler updates almost always only libpoppler is changed, the other two don't
2020-07-17 17:56:11 <Cogitri> mps: Alright, great, are you going to commit that? :)
2020-07-17 17:58:49 <mps> however you want, you are maintainer
2020-07-17 17:59:25 <mps> I'm not sure will we use these flags for 32bit arches only or for all
2020-07-17 18:11:05 <Cogitri> I think just 32-bit arches are fine
2020-07-17 18:11:20 <Cogitri> Also, I'm the maintainer for -esr too? :D
2020-07-17 18:11:43 <mps> huh, I thought so
2020-07-17 18:12:11 <mps> sorry
2020-07-17 18:12:49 <Cogitri> No worried :)
2020-07-17 18:15:36 <mps> but, I see firefox-esr-78.0.2-r0.apk in armv7 mirror already
2020-07-17 18:16:34 <mps> and x86
2020-07-17 18:17:20 <mps> I think we don't need to do anything, just remember these flags if they will be needed in future
2020-07-17 18:17:21 <Cogitri> I guess removing the -dbg package already did the trick then?
2020-07-17 18:17:28 <Cogitri> Okie :)
2020-07-17 18:17:36 <Cogitri> Thanks for looking into it though! :)
2020-07-17 18:17:47 <mps> yes, -dbg was problem
2020-07-17 22:38:11 <_c705> dalias: thanks for raising libvirt to upstream
2020-07-18 01:11:36 <Ariadne> Hello71: benchmarks are useless though
2020-07-18 01:28:11 <Ariadne> Hello71: all benchmarks prove is that for some groups of synthetic workload, some performance increase or decrease happens.  benchmarks do not tell the whole story, they are just a single data point, one which needs to be considered as part of the whole story.
2020-07-18 01:28:50 <Hello71> it seems that you have an idiosyncratic definition of the word "synthetic"
2020-07-18 01:28:53 <Ariadne> Hello71: benchmark-based decision making is especially harmful because it discards the rest of the story.  for example, comparing gccgo to gc is comparing apples to oranges.
2020-07-18 01:29:30 <Ariadne> https://lifehacker.com/the-differences-between-synthetic-real-world-and-hybr-1663435313
2020-07-18 01:29:39 <Ariadne> make allnoconfig is a synthetic benchmark
2020-07-18 01:31:37 <Ariadne> Hello71: a comparative benchmark between two completely different architectural approaches is not useful.  gc is faster than gccgo on glibc because of ipc overhead -- gc has custom context switching code while gccgo uses ucontext functions.  libucontext is many orders of magnitude faster than glibc ucontext functions because they only switch contexts.
2020-07-18 01:33:51 <Hello71> this (lifehacker -.-) article appears to contradict your claim that all benchmarks are synthetic
2020-07-18 01:34:08 <Ariadne> i did not say all benchmarks are synthetic, i said *your* benchmarks are synthetic
2020-07-18 01:35:14 <Ariadne> also compiling gcc with -O2 and not isl/cloog/etc is not very helpful
2020-07-18 01:35:27 <Ariadne> most of the cpu overhead is actually going to be in those libraries used by the optimizer
2020-07-18 01:45:20 <Ariadne> note again that i do not care about gcc being compiled -O2 or not
2020-07-18 01:45:28 <Ariadne> what i care about is justifying things with flawed data
2020-07-18 11:25:19 <the6543> I try to add a bash completion package to test/tea
2020-07-18 11:25:30 <the6543> so fare itworks to build the one
2020-07-18 11:25:37 <the6543> but the autocompletion do not work
2020-07-18 11:25:59 <the6543> https://gitlab.alpinelinux.org/6543/aports/-/commit/8f116828fcdaff5d31a98be62a159f6a5e7dc42b
2020-07-18 11:29:22 <the6543> is /usr/share/bash-completion/completions/ the right place for alpine to put bash autocompletion scripts into it?
2020-07-18 11:29:52 <the6543> !10440
2020-07-18 11:32:31 <Cogitri> Well, if the -bashcomp subpackage doesn't complain it presumably is the right place. You have the subpackage installed, right?
2020-07-18 11:49:00 <the6543> yes installed the self build subpackage manualy to test autocompletion
2020-07-18 11:49:06 <the6543> but did not work :(
2020-07-18 11:49:30 <the6543> so I guess its the wrong place I'm puting the script in
2020-07-18 11:55:35 <ikke> the6543: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1967
2020-07-18 11:55:51 <ikke> the6543: looks right
2020-07-18 11:56:10 <ikke> you are running bash, right?
2020-07-18 11:56:15 <ikke> The default shell is ash
2020-07-18 11:56:32 <the6543> yes
2020-07-18 11:57:22 <the6543> oh the file mod looks wrong :/
2020-07-18 11:58:18 <the6543> does it has to be executable?
2020-07-18 11:59:48 <the6543> chmod +x has no efect :(
2020-07-18 12:09:23 <the6543> source /usr/share/bash-completion/completions/tea
2020-07-18 12:09:25 <the6543> and it works
2020-07-18 12:10:12 <the6543> ~/.bashrc is missing
2020-07-18 12:10:16 <the6543> on my system
2020-07-18 12:10:36 <the6543> so I guess the MR is ok just my system need a litle bit more love
2020-07-18 12:13:42 <the6543> ok !10440 and !10442 are ready :)
2020-07-18 12:14:38 <the6543> @ikke hope the title of #10440 is correct?
2020-07-18 12:15:17 <ikke> There is a : missing
2020-07-18 12:15:24 <the6543> already added :)
2020-07-18 12:15:38 <the6543> !10440
2020-07-18 12:16:10 <ikke> ah ok
2020-07-18 12:16:36 <ikke> 10440 is kind of a noop MR
2020-07-18 12:16:40 <ikke> I would combine it with 10442
2020-07-18 12:16:54 <the6543> well still noop maintainer ;)
2020-07-18 12:17:00 <ikke> noop because not pkgrel bump,
2020-07-18 12:17:02 <ikke> no*
2020-07-18 12:17:08 <ikke> but you upgrade it in the next MR anyway
2020-07-18 12:17:23 <the6543> ah ok - yes can combine them
2020-07-18 12:17:40 <the6543> but what is the new commit title then?
2020-07-18 12:18:52 <ikke> You can have 2 commits in a single MR
2020-07-18 12:18:55 <ikke> so you can keep the old commit
2020-07-18 12:19:10 <ikke> the MR title can just be the upgrade
2020-07-18 12:19:34 <ikke> (2 meaning more then one)
2020-07-18 12:23:16 <the6543> ok prepared !10442
2020-07-18 12:27:39 <ikke> One last remark, and then it's ready
2020-07-18 12:27:47 <the6543> :eyes:
2020-07-18 12:28:16 <the6543> ok give me 1s
2020-07-18 12:29:44 <the6543> I think I get the name conviention now:
2020-07-18 12:30:14 <the6543> the package prefix always first, and if its a pugrade use the common syntax else describe it well enouth
2020-07-18 12:30:24 <ikke> yeah, basically
2020-07-18 12:30:37 <ikke> There are some other conventions such as moving a package
2020-07-18 12:30:41 <the6543> gtk
2020-07-18 12:30:45 <the6543> *got to know
2020-07-18 12:30:59 <ikke> good
2020-07-18 12:31:11 <the6543> haha
2020-07-18 12:31:34 <ikke> Will be merged
2020-07-18 12:31:56 <the6543> auto merge is a nice func :)
2020-07-18 12:32:13 <ikke> hehe
2020-07-18 12:32:56 <the6543> hmm what IRC client do you use by the way?
2020-07-18 12:33:03 <the6543> mine is HexChat
2020-07-18 12:33:15 <ikke> weechat
2020-07-18 12:33:24 <the6543> ah cli one :+1:
2020-07-18 12:34:31 <the6543> because I'm looking for a better one - HexChat is not bad but it has its issues!
2020-07-18 12:34:46 <ikke> I basically run it in a tmux session on a vps
2020-07-18 12:35:21 <the6543> a notification func if you got mentiond would be nice throu ...
2020-07-18 12:35:41 <the6543> @ikke I could do that too
2020-07-18 12:36:07 <ikke> I look often enough to not really need one
2020-07-18 12:36:23 <the6543> fair point
2020-07-18 12:36:29 <ikke> But weechat has a relay function for an android app
2020-07-18 12:36:38 <the6543> realy!
2020-07-18 12:36:45 <the6543> do you know the name of it?
2020-07-18 12:37:08 <ikke> The android app is just called weechat-android
2020-07-18 12:37:23 <the6543> https://github.com/ubergeek42/weechat-android - got it
2020-07-18 12:37:27 <ikke> It does need to connect to a full weechat instance
2020-07-18 12:37:34 <ikke> ie, it's not a stand-alone client
2020-07-18 12:38:40 <the6543> this should be not a problem
2020-07-18 12:39:28 <the6543> looks good will look into it - thanks
2020-07-18 16:58:48 <gjabell> could someone with build access please rebuild mtxclient?
2020-07-18 16:59:19 <ikke> that's a library, right?
2020-07-18 16:59:20 <gjabell> nheko's upgrade fails because it uses a newer version of a lib (probably nlohmann-json)
2020-07-18 16:59:26 <gjabell> yes
2020-07-18 16:59:36 <gjabell> if it needs a rel bump I can make a PR real quick
2020-07-18 16:59:46 <ikke> I don't see how bumping mtxclient would help
2020-07-18 16:59:53 <ikke> You need to bump the packages that rely on it
2020-07-18 17:00:38 <gjabell> well nheko currently fails to build (!9992) because it fails to link against pieces of mtxclient
2020-07-18 17:01:12 <gjabell> and rebuilding mtxclient seems to fix that, probably because they are built against different versions of nlohmann-json
2020-07-18 17:01:14 <ikke> a linking issue
2020-07-18 17:01:17 <ikke> hmm
2020-07-18 17:07:34 <gjabell> I can send a log failure if you want to take a look
2020-07-18 17:07:51 <gjabell> But I'm pretty sure bumping mtxclient will fix it in the CI too
2020-07-18 17:08:47 <ikke> I'm looking at the log already
2020-07-18 17:12:48 <ikke> https://pkgs.alpinelinux.org/contents?branch=edge&name=nlohmann-json&arch=x86_64&repo=testing only contains a header file
2020-07-18 17:14:25 <gjabell> hmm
2020-07-18 17:14:32 <gjabell> maybe it's a different lib then
2020-07-18 17:14:56 <ikke> ldd doesn't complain
2020-07-18 17:16:02 <gjabell> weird, I wonder why it fixed it to rebuild locally
2020-07-18 17:16:09 <gjabell> it was failing the same way before I rebuilt mtxclient
2020-07-18 17:16:22 <ikke> hmm
2020-07-18 17:16:32 <ikke> Maybe not a run-time dependency but some build time conflcit
2020-07-18 17:16:34 <ikke> conflict
2020-07-18 17:17:07 <Hello71> ime all linker errors containing std::__cxx11::basic_string are due to libstdc++ mismatch
2020-07-18 17:17:15 <ikke> aha
2020-07-18 17:17:32 <Hello71> (that doesn't mean that's the case here though)
2020-07-18 17:19:11 <ikke> How does such a mismatch happen?
2020-07-18 19:09:25 <Hello71> in the long long ago (I think about 8 years ago?) after gcc 4.8 or something, all c++ programs using std::string had to be rebuilt
2020-07-18 19:09:49 <Hello71> most recently I think I encountered this error trying to link a libc++ program with a libstdc++ library
2020-07-18 19:42:45 <Cogitri> Yes, GCC's libstc++ broke ABI in 4.9->5 I think
2020-07-18 19:43:10 <mps> anyone have vim 'trick' (script or anything) to create alpine patches for aports
2020-07-18 19:43:45 <Cogitri> git format-patch ?
2020-07-18 19:44:20 <mps> hmm, how on unpacked source without .git dir
2020-07-18 19:44:41 <Hello71> like... diff -ru?
2020-07-18 19:45:12 <mps> ok, sorry
2020-07-18 19:45:35 <mps> I don't ask for creating patches for aports tree
2020-07-18 19:45:56 <mps> but patches I create for particular file/s of unpacked tarballs
2020-07-18 19:46:28 <mps> and these patches will be added to APKBUILD and in aports dir of pkg
2020-07-18 19:46:49 <mps> i.e. header to locally created patch files
2020-07-18 20:10:55 <ikke> git init in srcdir
2020-07-18 20:10:58 <ikke> git add .
2020-07-18 20:11:01 <ikke> change files
2020-07-18 20:11:03 <ikke> git diff
2020-07-18 20:13:36 <mps> heh
2020-07-18 20:14:53 <mps> simpler and less intrusive option will be vim snippet or macro
2020-07-18 20:16:01 <ikke> Whatever works
2020-07-18 20:17:04 <mps> do we have preferred format headers for such locally created patches
2020-07-18 20:29:27 <Cogitri> Add a patch header containing what the patch is for, if it is upstreamed and if so the URL to the upstream issue/MR
2020-07-18 20:30:02 <Cogitri> So usually Description: "text"\nUpstream:Yes/No\nUrl: $url
2020-07-18 20:31:56 <mps> Date and Author?
2020-07-18 20:40:55 <Cogitri> That's also helpful, yes
2020-07-18 20:41:43 <mps> and license for 'big' patch :)
2020-07-18 20:43:38 <mps> Date and Author enough, license should be same as APKBUILD (sorry for kidding)
2020-07-19 09:49:19 <opal> https://wowana.me/paste/fEixE3.txt
2020-07-19 09:49:26 <opal> having trouble building ejabberd
2020-07-19 09:49:35 <opal> "cannot find -lerl_interface"
2020-07-19 09:50:06 <opal> im trying to bump ejabberd and fix the dependencies now that erlang-* packages are missing
2020-07-19 09:51:22 <opal> (missing because they were evidently all merged into ejabberd itself)
2020-07-19 09:51:31 <opal> er
2020-07-19 09:51:32 <opal> to erlang itself
2020-07-19 09:51:37 <opal> too many e's
2020-07-19 11:23:46 <Hello71> opal: your ipv6 is cogent-only...
2020-07-19 11:24:05 <Hello71> regarding your actual error, have you checked if you actually have erl_interface
2020-07-19 11:52:39 <opal> what is the search path for it
2020-07-19 11:52:55 <opal> im using abuild so it removes deps when build's over
2020-07-19 11:53:25 <ikke> I saw another package fail due to erl_interface missing
2020-07-19 11:53:27 <opal> also i dont follow, whats the matter with my ipv6
2020-07-19 11:54:01 <ikke> ah, that was ejabberd :P
2020-07-19 11:54:59 <opal> aha
2020-07-19 11:55:48 <opal> just built another erlang package successfully, pleroma-2.0.7
2020-07-19 11:56:03 <opal> so, unsure what the issue may be
2020-07-19 11:59:04 <opal> tried both with ejabberd 20.04 and based off the 17.09-r5 apkbuild
2020-07-19 12:13:34 <Hello71> cogent doesn't peer with he or apparently google either
2020-07-19 12:13:42 <opal> ah
2020-07-19 12:14:02 <opal> seems like all three of them are in a big turf war honestly
2020-07-19 12:14:08 <opal> theyre hurting ipv6 adoption
2020-07-19 12:14:16 <opal> i cant do much about it, im not an employee with any of them
2020-07-19 12:14:32 <opal> only thing i can do is advertise AAAA records and set up ipv6 correctly on my end
2020-07-19 12:14:37 <opal> rest is out of my control
2020-07-19 12:18:50 <opal> "seems like all three of them[…]" i say that cus i have had ipv6 routing issues with like two of my vpses
2020-07-19 12:19:04 <opal> and response from provider has always been "yeah upstream is he"
2020-07-19 12:19:22 <Hello71> it's mostly cogeco's fault
2020-07-19 12:19:40 <Hello71> they're trying to pull a comcast
2020-07-19 12:19:42 <opal> ya ive heard plenty of shit about cogent, wouldnt be surprised
2020-07-19 12:20:18 <opal> imagine how better the world would be without greedy isps pulling this crap
2020-07-19 12:22:04 <opal> ikke if you have an answer about the erl libraries or if i should file a bug on gitlab
2020-07-19 12:22:08 <opal> im all ears
2020-07-19 12:22:20 <opal> gonna get my pi set up with other stuff
2020-07-19 12:22:51 <ikke> No, I have no clue about what is going on or what should provide it. There are people who have more experience with Erlang
2020-07-19 12:23:21 <opal> should i go ahead and ask their channel about the error? or maybe ejabberd i think they have a muc
2020-07-19 12:23:42 <opal> i'll look in a bit
2020-07-19 12:24:27 <opal> oh right im stupid im building for x86_64 when im meaning to build for armhf, need to figure out crossdev
2020-07-19 12:25:07 <opal> CHOST/CTARGET are all i need to worry about?
2020-07-19 12:39:04 <mps> what is 'eis-ng' clamav pkgdesc="An anti-virus toolkit for UNIX eis-ng backport"
2020-07-19 15:40:08 <ikke> The builders could use some love
2020-07-19 15:40:14 <ikke> seems like almost all arches are stuck
2020-07-19 15:40:31 <ikke> stone-soup, vlc, qt5-qtwebengine, ruby-ffi, vlc, osmo
2020-07-19 15:42:07 <ikke> bazel3
2020-07-19 15:43:06 <mps> well, I love builders :)
2020-07-19 15:45:02 <mps> I can disable all these very quickly :D
2020-07-19 15:46:10 <ikke> yes. me too :P
2020-07-19 16:11:25 <opal> how does alpine handle cross compiling
2020-07-19 16:11:43 <opal> cus ive never done any sort of cross compiling and im lost
2020-07-19 16:21:08 <ikke> We only use cross-compiling to boodstrap a new arch
2020-07-19 16:21:15 <ikke> so we do not have a general cross-compile toolchain
2020-07-19 16:23:59 <mps> what's the irony? today I asked contributor on MR comment to use 'mv' instead of 'amove' and s/he fixed MR, and now I just see this in commit msg:  use amove instead mv
2020-07-19 16:25:05 <mps> sorry Duncan Bellamy
2020-07-19 16:26:02 <opal> ikke ah
2020-07-19 16:27:06 <opal> for bootstrapping does this mean building a cross compiler for the target and then installing it into the build environment manually (as in, not tracked by apk)?
2020-07-19 16:28:40 <opal> i tried crossdev on gentoo too but that has sparse documentation thats somewhat out of date. might give another shot idk
2020-07-19 16:28:58 <opal> would like to stick with alpine for my pi since it works fairly nicely
2020-07-19 16:33:23 <ikke> opal: I don't know all the details, but we have a script that sets this up
2020-07-19 16:33:28 <ikke> scripts/bootstrap.sh
2020-07-19 16:33:35 <opal> i'll check it out thank you
2020-07-19 16:46:58 <ikke> " expected -0.477986771153282950419169851899937876e987 to be within 0.01 of 0.3" looks like an overflow
2020-07-19 16:50:18 <Hello71> uh... isn't that a prime95 error
2020-07-19 16:53:42 <ikke> Hello71: no clue
2020-07-19 16:54:18 <Hello71> probably a hardware issue then
2020-07-19 16:54:26 <Hello71> what are you talking about anyways
2020-07-19 16:55:06 <ikke> ruby-ffi failing test suite
2020-07-19 16:55:28 <ikke> on x86
2020-07-19 16:55:52 <ikke> expect(LibTest.add_f128(0.1, 0.2)).to be_within(0.01).of(0.3)
2020-07-19 17:04:58 <Hello71> hm.
2020-07-19 17:06:52 <ikke> hmm, cannot reproduce on a different host (x86_64 with a 32-bits container)
2020-07-19 17:07:34 <Hello71> 987 is a lot, and that's a strange number
2020-07-19 17:09:52 <ikke> Hello71: would prime95 errors be consistent?
2020-07-19 17:10:08 <ikke> now it fails on mips64 as well
2020-07-19 17:10:27 <ikke> well, different assertion
2020-07-19 17:10:33 <ikke> expected 0.123456789012345424794169305681884669e1 to be within 0.1e-18 of 0.1234567890123456789e1
2020-07-19 17:24:39 <mps> hmm, looks like I was right about linux-headers when proposed upgrade some time ago. just found this https://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F
2020-07-19 17:28:00 <ikke> it says newer kernel headers are ok
2020-07-19 17:28:22 <mps> yes, that was my proposal few months ago
2020-07-19 17:28:50 <ikke> From what I've read here, that's exactly what we are doing
2020-07-19 17:31:12 <mps> yes, ncopa changed his mind few days ago :)
2020-07-19 17:32:47 <mps> that should be reminder whenever I propose something that should be considered seriously ;)
2020-07-19 17:44:00 <oneinsect> friends i get error during >>> ERROR: glibc: libCNS.so: path not found
2020-07-19 17:44:00 <oneinsect>  
2020-07-19 17:44:13 <oneinsect> even verbose -v doesnt show much info other than the above
2020-07-19 17:44:20 <oneinsect> this happens during rootpkg stage
2020-07-19 17:44:51 <oneinsect> however the libCNS.so is present /usr/lib64/gconv/libCNS.so
2020-07-19 17:45:30 <oneinsect> any idea why abuild cannot find that file during rootpkg phase?
2020-07-19 17:45:45 <oneinsect> glibc: Tracing dependencies...
2020-07-19 17:45:56 <oneinsect> ikke: any ideas you can throw in?
2020-07-19 17:47:36 <mps> oneinsect: namaste, namaste :)
2020-07-19 17:47:40 <oneinsect> how to understand what exactly is abuild looking for and in what directories?
2020-07-19 17:47:44 <oneinsect> namaste mps:
2020-07-19 17:47:52 <oneinsect> :-P
2020-07-19 17:48:11 <mps> can you check in which dirs tracedeps search libs
2020-07-19 17:48:42 <oneinsect> how to check that?
2020-07-19 17:49:05 <oneinsect> it is meant to search /lib and /lib does symbol link to /lib64
2020-07-19 17:49:55 <oneinsect> https://ctxt.io/2/AADA7s6BEQ
2020-07-19 17:49:58 <mps> it should be /lib and /usr/lib
2020-07-19 17:50:21 <oneinsect> aha
2020-07-19 17:50:36 <oneinsect> so i may have to symbolink for boostrap phase then
2020-07-19 17:51:05 <oneinsect> what is interesting is it does create Create glibc-2.31-r0.apk
2020-07-19 17:51:14 <mps> don't know really, never tried that
2020-07-19 17:51:19 <oneinsect> let me try that
2020-07-19 17:51:24 <oneinsect> thanks for the hint!!
2020-07-19 17:51:47 <mps> np
2020-07-19 17:52:13 <mps> 
ACTION steps back to continue reading Mahabharata again

2020-07-19 17:52:49 <oneinsect> ROFL
2020-07-19 17:53:05 <oneinsect> funny!
2020-07-19 17:53:33 <mps> no, really I started few days ago again
2020-07-19 17:55:31 <oneinsect> hmmmm Ramayana and Mahabharatha are two epics
2020-07-19 17:56:16 <mps> yes, and big ones
2020-07-19 18:01:46 <oneinsect> i have started upload the working APKBUILD files here https://github.com/Engincs/eports/tree/master/main
2020-07-19 18:02:16 <oneinsect> hope it to finish around 100 base packages by next month with ISO
2020-07-19 18:02:26 <oneinsect> thanks for the help everyone
2020-07-19 18:02:35 <oneinsect> very kind of you all folks
2020-07-19 18:02:49 <oneinsect> uploading*
2020-07-19 18:04:20 <oneinsect> hoping* to
2020-07-19 18:04:29 <oneinsect> darn typing bugs
2020-07-19 19:29:04 <mps> Cogitri: how this header for alpine patches look https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/testing/crazydiskinfo/disable-linking-tinfow.patch
2020-07-19 19:30:53 <Cogitri> 👍
2020-07-19 19:31:56 <mps> thanks :)
2020-07-19 19:32:40 <mps> I didn't had time for testing/weex to do same
2020-07-20 01:49:37 <Terror> Hi team, been trying to get a new package merged but I'm stuck with this message: The source branch is 1902 commits behind the target branch and have no idea how to fix that. I'm running out of ideas, does anyone have a pointer on how to sync a forked repo with the source?
2020-07-20 02:47:49 <Terror> I think I managed to kick git into submission, who can take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10501 ?
2020-07-20 02:47:50 <Terror> Thanks
2020-07-20 07:36:22 <Cogitri> Is it already known why CI sometimes says that there are no packages to build like in https://gitlab.alpinelinux.org/Bridouz/aports/-/jobs/168856#L47 ?
2020-07-20 07:36:45 <Cogitri> s390X builders are failing right now because !10495 was merged because CI was green when it really wasn't
2020-07-20 07:36:49 <ikke> No :(
2020-07-20 07:36:53 <Cogitri> :c
2020-07-20 07:37:16 <ikke> But if we could leave that MR as is, I could take a look later to find out
2020-07-20 07:37:22 <Cogitri> Sure
2020-07-20 07:37:28 <Cogitri> Thanks
2020-07-20 08:58:13 <ikke> oh, it's merged now..
2020-07-20 08:58:22 <ikke> "The source branch has been deleted "
2020-07-20 09:01:03 <ncopa> im  running newedge builders again
2020-07-20 09:01:04 <Cogitri> Ahhh, the pipeline did fail previously, but it was merged nontheless
2020-07-20 09:33:49 <ikke> hmm, something going on with rust / cargo? I see packages failing because Cargo.toml files cannot be found
2020-07-20 09:34:15 <ikke> failed to read `/var/cache/distfiles/cargo/registry/src/github.com-1ecc6299db9ec823/cc-1.0.58/Cargo.toml`
2020-07-20 09:35:04 <opal> so far the only issues ive had with the bootstrap.sh script are transient dns issues
2020-07-20 09:35:12 <ikke> on armhf only though
2020-07-20 09:35:13 <opal> stops the whole build process cus a query timed out lmao
2020-07-20 09:35:41 <opal> idk how to best handle that but eh
2020-07-20 09:35:58 <Cogitri> I guess that's concurrent download issues again, ikke
2020-07-20 09:36:21 <Cogitri> cargo sets CARGO_HOME to /var/cache/distfiles/cargo so we can cache things there
2020-07-20 09:36:28 <opal> i am in control of my resolver but generally i dont have much issues
2020-07-20 09:36:37 <Cogitri> I guess if multiple things write to that files at once, bad things happen
2020-07-20 09:37:03 <ikke> but in this case it says no such file or directory
2020-07-20 09:37:56 <ikke> and armv7 is stuck on qt5-qtwebengine, so I don't expect it to conflict with armv7
2020-07-20 09:38:40 <Cogitri> Hm, but I don't think we have seen this issue on other builders yet
2020-07-20 09:48:23 <ikke> Cogitri: I restarted the build, and armhf failed while armv7 is still building on qt5-qtwebengine
2020-07-20 09:51:16 <ncopa> i have rewritten the aport-ghpr tool to gitlab: aports-glmr
2020-07-20 09:51:51 <ncopa> it basically lists the current open merge requests in the aport directory you are in
2020-07-20 09:52:03 <ikke> ncopa: ok, nice
2020-07-20 09:52:08 <ncopa> for example: cd aports/main/gcc; aports-glmr
2020-07-20 09:52:22 <ncopa> will search open "gcc"  merge requests
2020-07-20 09:53:09 <ncopa> the idea is to make it easy avoid bump versions when there are open mergerequests
2020-07-20 09:54:40 <mps> will be useful as was aport-ghpr
2020-07-20 09:54:51 <Cogitri> Nice
2020-07-20 09:55:08 <Cogitri> Might want to partner up with maxice8, I think they have loads of helper scripts for aports too
2020-07-20 09:55:23 <Cogitri> ikke: I think maybe the cache was corrupted earlier
2020-07-20 09:56:01 <Cogitri> Maybe you could just delete /var/cache/distfiles/cargo for a quick workaround? Shouldn't cause any issues, but crates will be downloaded again (which probably isn't a huge problem on builders)
2020-07-20 09:58:10 <ikke> done
2020-07-20 09:58:16 <ncopa> i'd like to write a webhook for gitlab that will look for todo lists in security issues, and auto close when the todolist is all done
2020-07-20 10:00:57 <Cogitri> I can integrate that into the gitlab bot I'm currently making too
2020-07-20 10:00:59 <ikke> ncopa: I gather that aports-glmr is not published yet?
2020-07-20 10:01:24 <ikke> Cogitri: isn't that more focused on merge requests?
2020-07-20 10:02:52 <Cogitri> Yes, right now it's mainly merge requests (marking them as failed if pipeline fails, stale etc.), but it'd be easy making it work with issues too
2020-07-20 10:03:40 <Cogitri> I better write a mail to the ML about what it can do and if everyone is OK with that soon :)
2020-07-20 10:18:44 <ncopa> ikke: i just published it: https://gitlab.alpinelinux.org/ncopa/aports-glmr
2020-07-20 10:19:30 <ikke> ah, as a separate project, ok
2020-07-20 10:20:08 <ncopa> yes, I think I'll archive aports-ghpr
2020-07-20 10:20:23 <ikke> nod
2020-07-20 10:20:37 <ikke> Should I package it, or are you already working on it?
2020-07-20 10:21:28 <ncopa> i think I may need to create a tag first
2020-07-20 10:21:42 <ikke> ok
2020-07-20 10:22:55 <ncopa> hum...
2020-07-20 10:23:03 <opal> these transient errors are on my nerves lol
2020-07-20 10:23:08 <ikke> interesting, not sure when it will arrive, but gitlab maybe will start supporting reviewing commit messages
2020-07-20 10:23:19 <ncopa> i cannot create release if there is an existing tag
2020-07-20 10:23:35 <ikke> ncopa: I think you can adjust the tag
2020-07-20 10:23:39 <ikke> specify a release message
2020-07-20 10:23:57 <ikke> Hmm, I don't see any tags yey?
2020-07-20 10:24:01 <ikke> yet*
2020-07-20 10:24:18 <ikke> ah, now
2020-07-20 10:24:46 <ncopa> i just created it :)
2020-07-20 10:24:51 <ikke> :)
2020-07-20 10:25:00 <ikke> But you can edit the release notes of a tag to create a release
2020-07-20 10:25:06 <ncopa> aha
2020-07-20 10:25:08 <ncopa> ok
2020-07-20 10:25:18 <ncopa> can you please create an aport for it now?
2020-07-20 10:25:25 <ikke> in about 30 minutes
2020-07-20 10:25:28 <ncopa> thanks!
2020-07-20 10:27:49 <ncopa> maxice8: i think we should coordinate the atools, what the plans are etc
2020-07-20 10:31:40 <ncopa> ikke: i have it packaged already
2020-07-20 10:35:23 <ikke> ncopa: ah ok
2020-07-20 10:35:26 <ikke> no problem
2020-07-20 10:37:18 <opal> now im getting this with bootstrap https://wowana.me/paste/vCgTL8.txt
2020-07-20 10:39:19 <ikke> hmm
2020-07-20 10:39:28 <ncopa> i think we dropped that package since we dropped support for linux-lts on armhf
2020-07-20 10:39:44 <ikke> edge still has it
2020-07-20 10:39:59 <opal> # optional cross build packages
2020-07-20 10:40:00 <opal> KERNEL_PKG="linux-firmware linux-lts"
2020-07-20 10:40:39 <opal> so wait what is this bootstrap building exactly, could i just set KERNEL_PKG='' and run this under chroot or not
2020-07-20 10:40:40 <ncopa> i guess we should somehow test if those packages are available for the arch
2020-07-20 10:41:05 <opal> i just want a crosscompiler to run on x86_64 to target armhf thats it
2020-07-20 10:41:41 <ncopa> we dont have any armhf linux-lts, linux-firmware packages
2020-07-20 10:42:00 <ncopa> the only kernel package we support for armhf is linux-rpi
2020-07-20 10:42:26 <ncopa> i guess you can simply comment out the KERNEL_PKG line
2020-07-20 10:42:29 <ikke> https://pkgs.alpinelinux.org/package/edge/main/armhf/linux-firmware?
2020-07-20 10:43:49 <ncopa> i think its failing on linux-lts
2020-07-20 10:44:12 <ikke> ok
2020-07-20 10:44:54 <opal> yeah i dont think i need to build my own kernel for now at least
2020-07-20 10:50:09 <opal> getting this error again: Package not available for the target architecture (armhf). Aborting.
2020-07-20 10:50:15 <opal> i have no idea what package it is talking about though
2020-07-20 10:50:20 <opal> guess i could sh -x
2020-07-20 10:50:32 <opal> ghc
2020-07-20 10:50:33 <opal> heh
2020-07-20 10:51:45 <opal> ok removed ghc from deps it tries to build and it seems fine
2020-07-20 10:51:52 <opal> i dont anticipate needing anything haskell
2020-07-20 10:52:43 <ikke> And getting it to work for armhf is a challenge on its own anyway
2020-07-20 10:54:20 <opal> yeah it sounds like someone recently had issues with ghc
2020-07-20 10:54:49 <ikke> We only build it for x86_64 at the moment
2020-07-20 10:54:53 <opal> hm so now that i ran this, what should i do to actually build packages for target arch
2020-07-20 10:55:09 <opal> i think only haskell thing i ever use is hledger
2020-07-20 10:55:55 <opal> i should also document this process for crossdev so i dont run into future issues, i can just repeat the process
2020-07-20 10:57:15 <ikke> ncopa: did you mean to commit the actual binary in the repository btw?
2020-07-20 11:00:23 <ncopa> no :)
2020-07-20 11:01:03 <ikke> ok
2020-07-20 11:02:54 <ncopa> annoying
2020-07-20 11:03:03 <ikke> :)
2020-07-20 11:03:15 <ncopa> i think i should delete it from history too
2020-07-20 11:03:30 <ncopa> or it will bloat the future git clones for all etternity
2020-07-20 11:03:34 <ikke> yes
2020-07-20 11:03:36 <ikke> 6MB
2020-07-20 11:18:42 <ncopa> fixed
2020-07-20 11:18:50 <ncopa> and i tagged 0.2
2020-07-20 12:07:48 <rnalrd> hi
2020-07-20 12:07:57 <rnalrd> been away for a while
2020-07-20 12:08:04 <rnalrd> what's this newedge thing?
2020-07-20 12:09:03 <mps> new spammer :p
2020-07-20 12:09:09 <rnalrd> :D
2020-07-20 12:09:40 <mps> no, ncopa trying to bootstrap 32bit arches with musl 1.2.0
2020-07-20 12:09:57 <rnalrd> ah tnx
2020-07-20 12:10:10 <ikke> rnalrd: welcome back :)
2020-07-20 12:10:22 <rnalrd> tnx ikke!
2020-07-20 12:10:36 <mps> yes, also WB
2020-07-20 12:10:45 <rnalrd> tnx
2020-07-20 12:16:20 <Ariadne> morning
2020-07-20 12:16:34 <Ariadne> have made a lot of progress on new ifupdown implementation
2020-07-20 12:19:08 <Ariadne> should have something for testing later this week
2020-07-20 12:21:04 <mps> one you wanted to make in rust?
2020-07-20 12:23:27 <Ariadne> yeah, i made it in C instead
2020-07-20 12:23:45 <Ariadne> and grumbled through the process of writing the same bullshit data structure code i've written a dozen times
2020-07-20 12:23:48 <Ariadne> (:
2020-07-20 12:24:03 <Ariadne> https://github.com/kaniini/ifupdown-ng
2020-07-20 12:24:06 <mps> eh, good, I'm ready to test it then
2020-07-20 12:24:36 <mps> I wouldn't go through rust source
2020-07-20 12:25:33 <Ariadne> ifup/ifdown still need to be implemented
2020-07-20 12:25:41 <Ariadne> that's mostly blocking on implementing ifstate
2020-07-20 12:25:44 <Ariadne> which is kind of a mystery
2020-07-20 12:26:12 <mps> reading ...
2020-07-20 12:27:25 <mps> ifquery looks like it is working already?
2020-07-20 12:28:29 <opal> oh god im stupid
2020-07-20 12:28:36 <opal> i should be looking at how bootstrap.sh invokes abuild
2020-07-20 12:28:39 <opal> not running that
2020-07-20 12:28:39 <opal> lmao
2020-07-20 12:29:00 <opal> alright
2020-07-20 12:29:26 <opal> yeah there we go, shit
2020-07-20 12:30:10 <Ariadne> mps: yes, basically, except for --state
2020-07-20 12:30:34 <opal> i think i tried CHOST but i set it to armhf-alpine-linux-musl rather than just armhf
2020-07-20 12:30:58 <Ariadne> opal: to trigger crosscompile if you have a cross-toolchain, use $CARCH
2020-07-20 12:31:09 <opal> ah ok
2020-07-20 12:31:10 <opal> ty
2020-07-20 12:31:29 <opal> do i have a cross-toolchain lol
2020-07-20 12:31:37 <Ariadne> if you ran bootstrap.sh yes
2020-07-20 12:31:40 <opal> ah ok
2020-07-20 12:31:51 <opal> so i *did* benefit from running that
2020-07-20 12:32:15 <Ariadne> note that armhf is quite broken because tons of upstreams quit supporting armv6
2020-07-20 12:32:32 <opal> yay thatll be fun
2020-07-20 12:33:11 <opal> cus fuck supporting old boards right
2020-07-20 12:34:01 <Ariadne> in the absence of upstream cooperation and lack of commercial interest, i suspect armhf will probably just go away eventually
2020-07-20 12:34:24 <Ariadne> the musl 1.2 migration is not presently targeting armhf
2020-07-20 12:35:05 <opal> thats sad to say the least
2020-07-20 12:36:39 <opal> see that happening with x86 too more or less
2020-07-20 12:36:44 <opal> some distros dropping support for it
2020-07-20 12:37:08 <opal> when you have hand-me-down parts you really cant be idealistic about your hardware
2020-07-20 12:37:13 <opal> raspi was a gift to me
2020-07-20 12:38:08 <Ariadne> we are working on multiple tiers of support
2020-07-20 12:38:21 <mps> well, I expect that there will be some small/niche distros for these old boxes
2020-07-20 12:38:24 <Ariadne> most likely armhf will stay around as a "no promises" port
2020-07-20 12:38:38 <Ariadne> x86 will stay around for a while longer, there's many alpine x86 installs in the field
2020-07-20 12:39:02 <Ariadne> but yes, this is generally your wakeup call that 32-bit is starting to be deprecated in alpine :)
2020-07-20 12:39:13 <Ariadne> that includes armv7, incidentally.
2020-07-20 12:39:24 <opal> you mentioned upstream though, by that it isnt "specific to alpine"
2020-07-20 12:39:27 <mps> iirc, RPi armv6 EOL is 2026
2020-07-20 12:39:46 <mps> or 2024
2020-07-20 12:39:48 <Ariadne> opal: yes, but alpine has to respond to upstream trends
2020-07-20 12:39:50 <mps> hmmm
2020-07-20 12:40:10 <Ariadne> mps: hardware maybe, but Qt, GNOME, Mozilla, ...
2020-07-20 12:40:13 <opal> what i mean is im confused by "niche distros still having support"
2020-07-20 12:40:14 <mps> I need to lool at exact EOL
2020-07-20 12:40:19 <opal> via way of patchsets?
2020-07-20 12:40:24 <Ariadne> yes
2020-07-20 12:40:31 <opal> >qt, gnome, mozilla
2020-07-20 12:40:36 <opal> well this isnt a desktop system so that doesnt bother me
2020-07-20 12:40:41 <Ariadne> it is possible to patch these things to support armhf again (:
2020-07-20 12:40:42 <opal> using it for a server
2020-07-20 12:40:48 <mps> Ariadne: sorry, my previous 'hmm' wasn't for you, but for me
2020-07-20 12:40:53 <opal> yeah but theres effort for that ofc
2020-07-20 12:41:12 <opal> i know at least one other whos interested in supporting an array of older boards so im in contact with them about this
2020-07-20 12:41:38 <Ariadne> yes, anyway this is what the multi-tier approach is intended to handle
2020-07-20 12:41:55 <mps> and iirc we talked about month ago about idea to keep armhf but not all packages
2020-07-20 12:42:14 <Ariadne> that way the community may work to keep armhf or say mips/mips64 going (we've dropped our mips plans because wave went bankrupt)
2020-07-20 12:42:46 <Ariadne> but we will keep mips64 going for those who want to run alpine on their edgerouter (with some sort of reduced support)
2020-07-20 12:42:53 <mps> doesn't some Chinese company bought mips?
2020-07-20 12:42:57 <opal> community support im fine with as long as said community is strong and willing to upkeep
2020-07-20 12:43:19 <Ariadne> mps: there is loongson, and we might do stuff with them, but the other chinese company is a patent troll
2020-07-20 12:43:43 <Ariadne> the risk to reward ratio isn't playing out well for that
2020-07-20 12:43:57 <Ariadne> especially considering we can just use aarch64 in big-endian mode
2020-07-20 12:43:58 <mps> yes, loongson, I see a lot of patches in mainline kernel for their cpu
2020-07-20 12:44:16 <Ariadne> and get same performance with octeon tx
2020-07-20 12:44:19 <Ariadne> instead of octeon3
2020-07-20 12:44:27 <Ariadne> and octeon tx NIC driver is upstream ;)
2020-07-20 12:44:57 <Ariadne> mps: also, using a chinese cpu is a no-go for us anyway
2020-07-20 12:45:05 <Ariadne> in the umm... current political climate
2020-07-20 12:45:22 <mps> uh, why
2020-07-20 12:45:44 <mps> alpine doesn't care about politic
2020-07-20 12:45:51 <Ariadne> for us i mean $dayjob
2020-07-20 12:45:59 <Ariadne> in the US, certain forces have convinced the majority of CISOs that chinese stuff is backdoored
2020-07-20 12:46:05 <mps> ah, ok then, understand
2020-07-20 12:46:38 <Ariadne> and considering our target audience is enterprise and government sectors, they're not going to stomach a chinese CPU
2020-07-20 12:46:40 <mps> (what is not backdoored, I wonder)
2020-07-20 12:46:41 <Ariadne> at this time
2020-07-20 12:46:55 <Ariadne> even if we can prove the security of the platform
2020-07-20 12:46:58 <Ariadne> they will be like
2020-07-20 12:47:00 <Ariadne> lol chinese cpu no
2020-07-20 12:47:46 <opal> decreased dependence on china in general sounds ideal but i think that applies more to manufacture rather than design
2020-07-20 12:48:12 <Ariadne> our partners there are not chinese (:
2020-07-20 12:50:40 <Ariadne> mps: anyway, something great about my ifupdown is that localhost will always be configured
2020-07-20 12:51:06 <Ariadne> so if you forget to put it in /e/n/i, it doesn't matter
2020-07-20 12:51:26 <mps> heh, sometimes that's happened
2020-07-20 12:51:34 <Ariadne> that happened to us
2020-07-20 12:51:39 <Ariadne> with one of our customers
2020-07-20 12:51:43 <Ariadne> across like 40 sites
2020-07-20 12:51:49 <Ariadne> :)
2020-07-20 12:52:08 <Ariadne> so i figured i would just remove that way of shooting yourself in the foot entirely
2020-07-20 12:54:21 <opal> i yeeted `su` out of existence, nice
2020-07-20 12:55:06 <opal> wtf its right there
2020-07-20 12:55:15 <opal> oh
2020-07-20 12:55:31 <Ariadne> did you force install an armhf package on your not armhf machine ?
2020-07-20 12:55:32 <Ariadne> :)
2020-07-20 12:55:39 <opal> i didnt force install anything
2020-07-20 12:55:42 <opal> bbsuid is just straight up missing
2020-07-20 12:55:47 <Ariadne> weird
2020-07-20 12:55:54 <Ariadne> abuild-apk fix bbsuid
2020-07-20 12:55:58 <opal> there, fixed with `apk add -u busybox-suid`
2020-07-20 12:56:02 <Ariadne> or that
2020-07-20 12:56:13 <Ariadne> if you're in abuild group, there is a nice backdoor ;)
2020-07-20 12:56:27 <opal> yeah
2020-07-20 13:00:44 <opal> /home/alpine/packages/edge/armhf/pleroma-openrc-2.0.7-r0.apk
2020-07-20 13:00:46 <opal> ayyyyyyy
2020-07-20 13:00:47 <opal> hot
2020-07-20 13:00:54 <opal> wait lol pleroma-openrc
2020-07-20 13:01:00 <opal> no i didnt want the subpackage
2020-07-20 13:01:22 <opal> now to see what i did wrong
2020-07-20 13:02:37 <opal> thats the only file in there and with x86_64 it seems to have built both pleroma and -openrc fine
2020-07-20 13:15:54 <opal> mps lol my friend brought up a fair point, i thought alpine *was* that niche distro to support these boxes ;)
2020-07-20 13:17:33 <mps> probably because people have wrong perception that small means niche ;)
2020-07-20 13:18:06 <mps> though nowadays alpine is not small
2020-07-20 13:18:26 <Ariadne> alpine's install size is still small
2020-07-20 13:18:38 <Ariadne> but yes, no longer small in terms of users or package count
2020-07-20 13:18:53 <Ariadne> oh well, all things grow up eventually.
2020-07-20 13:19:12 <mps> still small in size, yes
2020-07-20 13:22:10 <Ariadne> damn
2020-07-20 13:22:37 <Ariadne> just realized debian ifupdown is maintained by a friend of mine
2020-07-20 13:22:42 <Ariadne> too bad the code is awful
2020-07-20 13:22:58 <Ariadne> maybe i can convince them to just join us on ifupdown-ng ;)
2020-07-20 13:26:58 <ikke> ha
2020-07-20 13:27:02 <ikke> the world is small sometimes
2020-07-20 13:28:38 <Hello71> I thought debian was quietly moving away from ifupdown
2020-07-20 13:30:27 <Ariadne> yes, in favor of ifupdown2 and netplan
2020-07-20 13:36:07 <opal> wtf theres already something called ifupdown2
2020-07-20 13:36:11 <opal> here i was working on something
2020-07-20 13:36:13 <opal> christ
2020-07-20 13:36:42 <ikke> better reserve 3-10
2020-07-20 13:36:47 <opal> lol
2020-07-20 13:36:59 <opal> well i chose the name because it was designed to work with iproute2
2020-07-20 13:38:28 <Ariadne> ifupdown1 works with iproute2 :P
2020-07-20 13:39:34 <opal> well i just wanted to design a more-terse syntax for the config so it was less boilerplate and repetition than in current /etc/network/interfaces
2020-07-20 13:39:45 <opal> and have it behave more like iptables-{save,restore}
2020-07-20 13:39:59 <opal> idk what the gpl'd ifupdown2 is doing
2020-07-20 13:46:21 <Ariadne> that's
2020-07-20 13:46:24 <Ariadne> what ifupdown-ng did
2020-07-20 13:46:26 <Ariadne> lol
2020-07-20 13:46:53 <Ariadne> https://github.com/kaniini/ifupdown-ng/blob/master/tests/fixtures/static-eth0.interfaces
2020-07-20 13:51:15 <dne> ifupdown2 seems pretty dead in debian: https://tracker.debian.org/news/1064997/ifupdown2-removed-from-testing/
2020-07-20 13:54:43 <opal> Ariadne well dont blame me for not having come across any of this because it isnt exactly stuff that gets the most coverage in the software field
2020-07-20 13:54:50 <opal> people too busy arguing about editors and inits
2020-07-20 13:54:53 <opal> lol
2020-07-20 13:55:12 <Ariadne> dne: yeah now it is ifupdown3
2020-07-20 13:55:21 <dne> haha
2020-07-20 13:55:46 <opal> Ariadne whats the grammar for -ng
2020-07-20 13:55:53 <Ariadne> opal: the same as ifupdown2/ifupdown3
2020-07-20 13:56:02 <opal> idk what it is for those
2020-07-20 13:56:10 <Ariadne> with the exception that you have to explicitly declare relationships
2020-07-20 13:56:30 <Ariadne> however, i just linked you an example of a dual-stack ipv4/ipv6 setup ;)
2020-07-20 13:58:01 <opal> i have more complex setups so was just wondering how my rules would translate
2020-07-20 13:59:50 <Ariadne> other than being dual-stack it is same as ifupdown1
2020-07-20 14:18:26 <Ariadne> also you don't have to worry about localhost ;)
2020-07-20 14:22:15 <Hello71> you mean loopback?
2020-07-20 14:33:03 <Ariadne> yes
2020-07-20 14:33:14 <Ariadne> ifupdown-ng always has a definition for loopback
2020-07-20 14:46:10 <Ariadne> mps: i would say that now ifquery is complete
2020-07-20 14:48:49 <mps> nice to heae, but I'm to busy now to look
2020-07-20 14:49:06 <mps> hear*
2020-07-20 16:43:13 <oneinsect> mps: ikke: one major issue i observed with recent abuild (i dont know if you guys noticed)
2020-07-20 16:43:22 <oneinsect> https://github.com/alpinelinux/abuild/blob/master/abuild.in
2020-07-20 16:43:24 <oneinsect> Packages must not put anything under /lib64, use /lib instead
2020-07-20 16:43:32 <oneinsect> however
2020-07-20 16:43:33 <oneinsect> https://github.com/alpinelinux/aports/blob/master/main/musl/APKBUILD
2020-07-20 16:43:42 <oneinsect> x86_64)		_ld="lib64/ld-linux-x86-64.so.2";;
2020-07-20 16:44:14 <oneinsect> on one side we are trying to avoid using lib64 but musl compat requires lib64 directory
2020-07-20 16:44:19 <oneinsect> and the builds are failing
2020-07-20 16:44:24 <oneinsect> has anyone noticed this?
2020-07-20 16:44:51 <oneinsect> Cogitri:
2020-07-20 16:44:53 <oneinsect> anyone?
2020-07-20 16:45:39 <oneinsect> brb going for a walk
2020-07-20 16:56:01 <Hello71> maxice8: ^
2020-07-20 17:00:16 <maxice8> glibc compat ofc :D
2020-07-20 17:00:20 <maxice8> I'll need to add a switch to deal with that
2020-07-20 17:05:42 <maxice8> Thanks for bringing it to attention
2020-07-20 17:13:53 <oneinsect> welcome maxice8:
2020-07-20 17:14:08 <oneinsect> i will test it once you add the switch
2020-07-20 17:14:11 <oneinsect> let me know
2020-07-20 17:14:46 <maxice8> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/61
2020-07-20 17:15:58 <oneinsect> oh you are fast
2020-07-20 17:16:13 <oneinsect> so i just pass an option to abuild
2020-07-20 17:17:56 <ikke> oneinsect: through an options variable in the APKBUILD
2020-07-20 17:18:45 <ikke> options=".. lib64"
2020-07-20 17:19:22 <oneinsect> let me try thanks ikke:
2020-07-20 17:30:58 <oneinsect> thank you kind sirs
2020-07-20 17:30:59 <oneinsect> it works
2020-07-20 20:38:43 <mps> oneinsect: I was out, but reading backlog here I think your problem is solved?
2020-07-20 20:38:56 <mps> and ofc, namaste :)
2020-07-20 20:39:51 <oneinsect> mps: yes yes its solved thanks to maxice8
2020-07-20 20:40:01 <oneinsect> and ofcourse namaste namaste :P
2020-07-20 20:40:15 <mps> good to hear
2020-07-20 20:40:38 <oneinsect> thanks to all kind people in here
2020-07-20 20:40:51 <mps> :)
2020-07-20 20:48:49 <mps> Cogitri: I answered you mail about bot, not sure is it arrived to ML
2020-07-20 20:49:16 <Cogitri> It did, answered just now :)
2020-07-20 20:50:34 <mps> not yet in my inbox, probably graylisting is not expired
2020-07-20 20:51:57 <mps> hmm, no, I receive daily mails from ML
2020-07-20 20:53:08 <Cogitri> I guess you could export& import the mthread if you want to answer right now
2020-07-20 20:55:03 <mps> through WEB? not thanks :)
2020-07-20 20:56:33 <mps> I can wait till tomorrow
2020-07-20 20:56:51 <Cogitri> Okie, thanks for answering though :)
2020-07-20 20:57:09 <alpdev> Hello, just need a quick clarification on APKBUILDs: on the wiki it says that $srcdir is where the sources are both downloaded AND unpacked - but it also says that $builddir is where the main package source is unpacked - my question; assuming I have .tar.gz sources - will they be unpacked to the root $srcdir or to $builddir ?
2020-07-20 21:01:05 <alpdev> I am assuming $srcdir is where sources are unpacked and $builddir is where tools like make etc. have a workdir but the sources themselves are unpacked to the root of $srcdir?
2020-07-20 21:03:03 <mps> $srcdir is where symlinks to source files are created
2020-07-20 21:03:54 <mps> and $buildir is where source file is unpacked
2020-07-20 21:04:20 <mps> usually, $srcdir/$pkgname-$pkgver
2020-07-20 21:04:44 <Cogitri> Yes, $srcdir is where things are unpacked, while $builddir is where you run the build commands (usually $srcdir/$pkgname-$pkgver since that's what the dir in the tarball is called)
2020-07-20 21:04:50 <Cogitri> Ah, mps was faster :)
2020-07-20 21:09:03 <alpdev> @mp  @Cogitri thanks, so if I have sources src.tar.gz which have a single file main.c - this main.c file will be found unpacked in $srcdir/main.c - not $builddir/main.c ?
2020-07-20 21:10:01 <Cogitri> Yup
2020-07-20 21:10:11 <alpdev> cool, thanks both
2020-07-20 21:10:17 <Cogitri> You'd set builddir="$srcdir" in your APKBUILD then
2020-07-20 21:10:59 <Cogitri> Otherwise abuild will try to cd into $srcdir/$pkgname-$pkgver which doesn't exist in your case
2020-07-20 21:11:55 <mps> auto applying patches will not work in that case
2020-07-20 21:12:40 <alpdev> right, that makes perfect sense, appreciate the help
2020-07-20 21:12:55 <mps> or maybe will, but I never tested such source files
2020-07-20 21:13:01 <Cogitri> I think auto applying patches should work as long as builddir is set correctly
2020-07-20 21:13:31 <mps> probably
2020-07-20 21:14:36 <alpdev> last question :-)  Since $srcdir is the root directory within the build environment, if I want to install something from $srcdir into $pkgdir I don't have to reference $srcdir there right? that is implied
2020-07-20 21:15:23 <mps> yes
2020-07-20 21:15:26 <Cogitri> No, $builddir is implied (since abuild will cd into it at the start of functions), but $srcdir is not
2020-07-20 21:15:54 <mps> but if the src is same as dest, it will work
2020-07-20 21:16:10 <Cogitri> If you want to install from $srcdir you still need to do `install -Dm755 $srcdir/file /usr/bin/file`
2020-07-20 21:16:49 <alpdev> right, thanks for the advice
2020-07-20 21:16:59 <mps> `install -Dm755 $srcdir/file $pkgdir/usr/bin/file`
2020-07-20 21:17:08 <Cogitri> Err right
2020-07-20 22:40:49 <Terror> Hi team, I found a missing build dependency on an aport. Can someone merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10513
2020-07-20 22:40:50 <Terror> Thanks
2020-07-20 23:58:46 <Terror> Why doesn't python3 get symlinked as python?
2020-07-21 00:54:23 <Ariadne> Hello71: strangely, the conversation i had with the debian ifupdown guy can be summarized as "thank fucking christ, netplan sucks and ifupdown1 is architecturally problematic"
2020-07-21 02:08:55 <maxice8> @Terror: to make people explicitly notate which python they want
2020-07-21 02:10:02 <Terror> I see, it breaks a lot of configure scripts though, since they are looking for `python` and can't find it.
2020-07-21 02:11:24 <Terror> Also if my python app doesn't care about the version, what am I supposed to do?
2020-07-21 02:12:17 <maxice8> The configure scripts should use python3 as python2 is EOL
2020-07-21 02:14:07 <Terror> Not everyone (and I presume almost noone actually) upstream will change their build/run scripts that work in other distros though. I can see the theoretical issue being addressed but seems like we are generating way more pain with the remedy.
2020-07-21 02:15:18 <maxice8> It is a hard choice, if we pick python3 as python then we get angry people like people got angry at arch
2020-07-21 02:15:30 <maxice8> It is a lose-lose proposition as someone will be angry so we just tell them to be explicit
2020-07-21 02:15:38 <Terror> I understand
2020-07-21 02:16:42 <maxice8> We should get a post-hook like Void Linux has that automatically rewrites the python shebangs to the correct ones or errors out
2020-07-21 02:16:55 <maxice8> Never had any problem with that, was amazing
2020-07-21 02:19:09 <Terror> I've been doing this on my aports: export PYTHON=$(which python3) && sed -i "1c #!$PYTHON" whatever.py
2020-07-21 02:20:00 <Terror> But definitely tooling could take over
2020-07-21 02:21:20 <maxice8> grep -r '#!.*python$' | xargs sed
2020-07-21 02:25:20 <Eighth_Doctor> maxice8: that's what we do in Fedora as well
2020-07-21 02:25:55 <maxice8> Do what ? expect people to pick which python they want explicitly, have a post-pkg hook to convert shebangs, or both ?
2020-07-21 02:25:55 <Eighth_Doctor> we also wrote a helper program that you can use to do it correctly in a lot of scenarios and stuffed it into python-rpm-macros
2020-07-21 02:26:11 <Eighth_Doctor> or at least we used to
2020-07-21 02:26:15 <Eighth_Doctor> maxice8: both
2020-07-21 02:26:32 <Eighth_Doctor> https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error
2020-07-21 02:27:10 <maxice8> nice
2020-07-21 02:27:18 <maxice8> speaking of which I'm still trying to add an equivalent of pc: to py:
2020-07-21 02:28:40 <Eighth_Doctor> the dist-info data isn't enough?
2020-07-21 02:28:57 <Eighth_Doctor> it's what we use for the python dependency generator
2020-07-21 02:29:16 <Eighth_Doctor> https://github.com/rpm-software-management/rpm/blob/master/scripts/pythondistdeps.py
2020-07-21 02:30:26 <Eighth_Doctor> maxice8: https://fedoraproject.org/wiki/Changes/EnablingPythonGenerators
2020-07-21 02:30:47 <Eighth_Doctor> https://fedoraproject.org/wiki/Changes/EnablingPythonGeneratorsByDefault
2020-07-21 02:31:00 <maxice8> It is an aports specific problems
2020-07-21 02:31:06 <maxice8> seeing python generators is what lead me to try to do it
2020-07-21 02:31:21 <Eighth_Doctor> ah
2020-07-21 02:33:24 <maxice8> Is the dist-info data available before installing ?
2020-07-21 03:36:05 <Terror> Some GNU packages use python in the build process, so postprocessing is not enough, you have to do something after extraction but before build.
2020-07-21 04:01:58 <maxice8> I said about that above
2020-07-21 08:38:25 <ncopa> im building rust now for newedge builders
2020-07-21 08:42:05 <Cogitri> 👍
2020-07-21 08:42:42 <ncopa> difficult to know if it has deadlocked or is just slow :)
2020-07-21 08:42:53 <ncopa> i think its just slow
2020-07-21 08:44:21 <Cogitri> Yes, building Rust takes ages
2020-07-21 08:44:30 <ncopa> once rust is done, I'll try to put them in production: 1) stop current 32 bit edge builders, 2) push musl 1.2 update, 3) rename newedge and configure aports-build
2020-07-21 08:44:50 <ncopa> oh.. move one of them back to usa4 if there is space
2020-07-21 08:46:10 <ncopa> should be space
2020-07-21 08:55:40 <ikke> 110GB space left :)
2020-07-21 09:05:31 <ncopa> x86 builder bypassed both arm builders. i guess there is a big single core job
2020-07-21 09:10:04 <Cogitri> You mean for Rust? Yes, most of Rust's compilation is single core (which is why it's soooo slow)
2020-07-21 09:11:29 <Cogitri> AFAICS it only uses multiple cores if it can compile multiple crates at oncr
2020-07-21 09:13:09 <ncopa> i thought rust was good for programming multicores...
2020-07-21 09:21:13 <Cogitri> Heh
2020-07-21 09:55:08 <Ariadne> musl does not include reallocarray???
2020-07-21 09:56:05 <ncopa> is reallocarray in posix?
2020-07-21 09:56:26 <Ariadne> no, but it's even in AIX and Solaris now
2020-07-21 10:03:16 <ncopa> hum rust build of armv7 bypassed arhf rust build
2020-07-21 10:03:18 <ncopa> armhf*
2020-07-21 10:04:18 <Ariadne> i dont think armhf supports rust
2020-07-21 10:04:55 <ncopa> we do have a package of it
2020-07-21 10:06:40 <ncopa> i think its just this machine that is slow
2020-07-21 10:07:04 <ncopa> too bad. I wanted update musl to 1.2 today :-/
2020-07-21 10:07:23 <Cogitri> Should finish within like 3-4 hours
2020-07-21 10:08:05 <Cogitri> <Ariadne "i dont think armhf supports rust"> It works just fine from what I can see
2020-07-21 10:08:29 <Ariadne> anyway i guess i will just include a reallocarray in ifupdown-ng
2020-07-21 10:08:32 <Ariadne> for now
2020-07-21 10:09:40 <Ariadne> although really recallocarrayis better
2020-07-21 10:10:01 <ncopa> looks trivial to implement
2020-07-21 10:11:53 <Ariadne> yes
2020-07-21 10:13:16 <Ariadne> i just think it would be nice if musl includes re[c]allocarray
2020-07-21 10:13:38 <Ariadne> if you're going to include strl[cpy,cat], then re[c]allocarray is justified too
2020-07-21 11:10:24 <ncopa> makes sense
2020-07-21 12:50:11 <oneinsect> why isnt there a check() function for binutils?
2020-07-21 12:50:12 <oneinsect> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/binutils/APKBUILD
2020-07-21 12:50:36 <oneinsect> is binutils passing all tests? any idea where I can get hold of the last test log for binutils?
2020-07-21 12:51:56 <mps> probably not, but maintainer should know better :)
2020-07-21 12:52:13 <mps> anyway, you can add it and try
2020-07-21 12:52:20 <oneinsect> ncopa
2020-07-21 12:53:15 <mps> but options="!check" should be added to APKBUILD with note why it is disabled
2020-07-21 12:53:44 <oneinsect> i am encountering one unexpected failures and 24 expected failures
2020-07-21 12:55:02 <oneinsect> mps: maybe you guys (the admins) can discuss and put it up for testing
2020-07-21 12:57:18 <opal> ln -s `which python3` /usr/local/bin/python
2020-07-21 12:57:19 <opal> shrug
2020-07-21 12:57:26 <opal> i know im late
2020-07-21 12:59:36 <mps> oneinsect: make sense to look why it is disabled (not exists)
2020-07-21 13:00:37 <mps> imo, we have much too of 'test doesn't work, disable it' mentality
2020-07-21 13:01:45 <opal> are there any of those in latest-stable/main
2020-07-21 13:01:59 <opal> those definitely shouldnt have tests disabled, should be first focus
2020-07-21 13:07:52 <ikke> mps: yes, I agree
2020-07-21 13:10:41 <oneinsect> i mean you would want to have tests on something so fundamental like binutils
2020-07-21 13:11:24 <ikke> certainly
2020-07-21 13:11:47 <ikke> but we also rely on upstream
2020-07-21 13:12:20 <oneinsect> hmmm
2020-07-21 13:13:17 <mps> some package test requirements can't be set on builders
2020-07-21 13:13:22 <ikke> that also
2020-07-21 13:18:44 <Ariadne> ok mips64 is fixed
2020-07-21 13:29:39 <Cogitri> PureTryOut [m]: Did you have time for looking into qt5-qtwebengine yet?
2020-07-21 13:30:38 <opal> ikke https://github.com/processone/ejabberd/issues/3282
2020-07-21 13:30:49 <opal> that explains build issue
2020-07-21 13:31:51 <ncopa> oneinsect: probably because nobody enabled the tests for binutils. our binutils package is older than the testing
2020-07-21 13:33:06 <ncopa> humm... armhf newedge is still chewing on rust
2020-07-21 13:33:19 <oneinsect> hmmmm
2020-07-21 13:33:35 <ncopa> i dont know if it has deadlocked. armv7 finished long time ago
2020-07-21 13:34:12 <PureTryOut[m]> Cogitri: the armv7 failure you mean?
2020-07-21 13:34:12 <Cogitri> Huh, that does seem really long
2020-07-21 13:34:16 <Cogitri> Yes
2020-07-21 13:34:19 <ncopa> oneinsect: looks like binutils test suite fails to build
2020-07-21 13:34:34 <oneinsect> yes i am facing the same issue
2020-07-21 13:34:47 <oneinsect> when i enable it, it fails in some cases
2020-07-21 13:34:58 <ncopa> ver_test_pr16504_b.c:10:6: error: ifunc is not supported on this target
2020-07-21 13:34:58 <ncopa>    10 | void foo(void) __attribute__((ifunc("resolve_foo")));
2020-07-21 13:34:58 <ncopa>       |      ^~~
2020-07-21 13:35:10 <PureTryOut[m]> Not currently but I'll look at it this week
2020-07-21 13:35:22 <ikke> the armv7 builder is blocked by it
2020-07-21 13:35:27 <mps> someone with access to builder can check if it is stuck or still chewing
2020-07-21 13:36:26 <ncopa> 31293 28713 buildoze R     391m   0%   4   9% /home/buildozer/aports/community/rust/src/rustc-1.44.1-src/build/armv6-alpine-linux-musleabihf/stage0-tools-bin/fabricate generate --product-name=Rust --rel-manifest-dir=rustlib --success-message=std-is-standing-at-the-ready. --image-dir
2020-07-21 13:36:26 <ncopa> /home/buildozer/aports/community/rust/src/rustc-1.44.1-src/build/tmp/dist/rust-std-1.44.1-armv6-alpine-lin
2020-07-21 13:36:36 <ncopa> cpu is busy
2020-07-21 13:37:12 <mps> so, working on this new and shiny lang
2020-07-21 13:37:29 <ikke> working or 'working'?
2020-07-21 13:37:52 <mps> i mean, builder works
2020-07-21 13:37:59 <ncopa> its not a shiny lang. its rusty :)
2020-07-21 13:38:05 <ikke> haha
2020-07-21 13:38:07 <mps> :D
2020-07-21 13:38:46 <mps> I stopped to learn rust about 5 months ago
2020-07-21 13:52:43 <ncopa> i wonder if i should sstop the rust build, move it to usa4 machine and retry there
2020-07-21 14:10:37 <ikke> opal: so a matter of backporting that 'fix?
2020-07-21 14:12:37 <wsinatra> anyone mind giving !10506 a once over? I know it'll need Carlo's approval, just want to make sure all the other cruft is taken care of
2020-07-21 14:14:47 <ikke> wsinatra: cd "$builddir" should not be required anymore
2020-07-21 14:15:10 <ikke> I wonder why linting doesn't mention it though
2020-07-21 14:15:13 <opal> ikke im stupid i didnt think of adding a patch for it
2020-07-21 14:15:17 <opal> yeah let me go ahead and try that out
2020-07-21 14:15:25 <oneinsect> ikke: quickly how to over-ride the CFLAGS in abuild.conf in the APKBUILD
2020-07-21 14:15:54 <oneinsect> just export would do in APKBUILD?
2020-07-21 14:15:54 <ikke> Just export it with a new value?
2020-07-21 14:15:58 <ikke> sure
2020-07-21 14:15:59 <oneinsect> thanks
2020-07-21 14:16:10 <wsinatra> ikke: good point, that is weird the linter missed it
2020-07-21 14:16:22 <wsinatra> easy fix though :) thanks!
2020-07-21 14:17:08 <ikke> And you do not need to define your own openrc function
2020-07-21 14:17:46 <wsinatra> is there an existing one? the linter yelled about it being in the regular package function
2020-07-21 14:18:18 <ikke> Yes, but you do need to define the subpackage
2020-07-21 14:18:20 <ikke> but that's enough
2020-07-21 14:19:15 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1943
2020-07-21 14:20:09 <wsinatra> Oh man, that's cool!
2020-07-21 14:20:21 <wsinatra> I had no idea it did that automagically
2020-07-21 14:20:32 <ikke> same with -dev, -doc and more
2020-07-21 14:20:51 <ikke> just look for all the default_ function in abuild.in to see what is available
2020-07-21 14:21:33 <wsinatra> I absolutely will, there's more packaging magic behind the scenes than I guessed :)
2020-07-21 14:22:39 <ikke> And the advantage of the default implementation is that it makes sure that it's automatically installed when openrc is installed
2020-07-21 14:24:05 <wsinatra> I was actually wondering why what I did felt a little off, that explains it.
2020-07-21 14:24:34 <wsinatra> I just assumed there was some sort of trigger, and there is, just not how I was doing things :)
2020-07-21 14:24:40 <ikke> thaths the install_if part
2020-07-21 14:25:24 <wsinatra> right that makes sense. I've honestly only poked at subpackages, so this is a good learning lesson for me
2020-07-21 14:25:56 <wsinatra> the auto -dev -doc has helped it not be necessary to totally understand how the mechanics work haha
2020-07-21 14:28:18 <ikke> wsinatra: strange, if I manually execute apkbuild-lint, it does mention it
2020-07-21 14:30:00 <ikke> wsinatra: aha, now I know
2020-07-21 14:30:46 <ikke> we skip these specific linting rules for packages in main
2020-07-21 14:31:01 <ikke> because it makes (or made) backporting more difficult
2020-07-21 14:31:14 <wsinatra> AH that makes a lot of sense then
2020-07-21 14:31:42 <wsinatra> I'll check manually next time I touch a main package if that's the case
2020-07-21 14:32:05 <wsinatra> I'm so used to pushing things to testing and getting them fix by trial and tribulation
2020-07-21 14:32:26 <ikke> you can certainly run apkbuild-lint locally to get feedback before pusing :)
2020-07-21 14:36:18 <wsinatra> I definitely will! Thanks for all your help ikke I really appreciate it!
2020-07-21 14:37:03 <ikke> You're welcome
2020-07-21 14:43:03 <ncopa> i think im gonna update musl 1.2 now
2020-07-21 14:43:35 <ikke> success
2020-07-21 14:43:54 <ncopa> there are lots of build failures
2020-07-21 14:44:01 <ncopa> and lots of missing packages initially
2020-07-21 14:44:16 <ikke> lots of them transient
2020-07-21 14:44:19 <ncopa> but it will help us move forward
2020-07-21 14:45:10 <ncopa> main total built:       1566
2020-07-21 14:45:10 <ncopa> main total relevant aports:     1595
2020-07-21 14:45:20 <ncopa> community total built:  1948
2020-07-21 14:45:20 <ncopa> community total relevant aports:        2842
2020-07-21 14:45:33 <ncopa> testing total built:    1575
2020-07-21 14:45:33 <ncopa> testing total relevant aports:  1955
2020-07-21 14:45:42 <ncopa> thats x86
2020-07-21 14:46:04 <ncopa> the deadlocks are the worst
2020-07-21 14:46:17 <ncopa> some will deadlock when running test suite
2020-07-21 14:49:00 <mps> ncopa: upgrade musl in edge main?
2020-07-21 14:49:21 <ikke> yes
2020-07-21 14:49:27 <mps> +1
2020-07-21 14:49:56 <mps> or, \o/
2020-07-21 14:51:22 <mps> 'apk version musl' => musl-1.2.0-r0                           > 1.1.24-r9
2020-07-21 14:51:58 <mps> on my aarch64 for more than a month, and one armv7 which is only for testing 'things'
2020-07-21 14:52:23 <mps> this aarch64 box I use daily
2020-07-21 14:53:25 <ikke> mps: don't you have ABI issues on armv7 with musl-1.2?
2020-07-21 14:54:02 <mps> didn't noticed any issue
2020-07-21 14:54:15 <mps> though didn't rebuild much packages
2020-07-21 14:58:19 <ncopa> hum
2020-07-21 14:58:30 <ncopa> we should probably notify postmarket ppl
2020-07-21 14:58:44 <ikke> yeah, they would be impacted by this
2020-07-21 14:58:50 <ikke> especially missing packages
2020-07-21 14:59:21 <ncopa> who are the postmarket people here? ollieparanoid[m], PureTryOut[m]?
2020-07-21 14:59:43 <mps> afontain_: ?
2020-07-21 14:59:57 <ncopa> ollieparanoid[m], PureTryOut[m]: I am about to push some breaking changes to edge, that affects 32 bit architectures, armhf, armv7 and x86
2020-07-21 15:06:03 <afontain_> ncopa: technically in this channel we have ollieparanoid, PureTryOut, craftyguy, minecrell1, alexeymin, z3ntu and me
2020-07-21 15:06:22 <afontain_> (sorry for the pings)
2020-07-21 15:06:33 <afontain_> ncopa: link?
2020-07-21 15:08:00 <mps> afontain_: I expect it soon on #alpine-commits :)
2020-07-21 15:15:23 <ncopa> afontain_: I'm about to send an email about it. but in general: I'm about to push musl 1.2 update
2020-07-21 15:15:47 <ncopa> all the 32 bit builds needs to be rebuilt from scratch
2020-07-21 15:15:57 <ncopa> i have built majority of the packages already in new builders
2020-07-21 15:16:14 <ncopa> but there will be some missing packages during trasition time
2020-07-21 15:16:21 <ncopa> transition*
2020-07-21 15:17:19 <ncopa> https://lists.alpinelinux.org/~alpine/devel/%3C20200721171650.48fa63a4%40ncopa-desktop.copa.dup.pw%3E
2020-07-21 15:19:13 <PureTryOut[m]> ncopa: thanks for the heads up! We'll need to rebuild our 32-bit architecture packages as well then.
2020-07-21 15:19:18 <PureTryOut[m]> ollieparanoid: can we rebuild all our armhf, armv7 and x86 packages without pkgrel bumpgs?
2020-07-21 15:55:19 <craftyguy> PureTryOut[m]: why wouldn't you bump pkgrel? If you don't, won't that cause issues and prevent packages from updating to the newer rebuilt version?
2020-07-21 16:09:01 <ikke> craftyguy: we didn't do it for alpine either, ncopa said in the mail users should do apk upgrade --available
2020-07-21 16:21:22 <oneinsect> kind sirs quickly
2020-07-21 16:21:23 <oneinsect> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/bash/APKBUILD
2020-07-21 16:21:39 <oneinsect> there is a subpackages="$pkgname-dbg
2020-07-21 16:21:45 <oneinsect> but no subfunction?
2020-07-21 16:23:50 <oneinsect> got it! never mind
2020-07-21 16:25:10 <ikke> abuild defines a lot of default functions :)
2020-07-21 16:26:13 <oneinsect> yeaa i forgot dbg is one of them
2020-07-21 16:26:19 <oneinsect> which doesnt require a subfunction
2020-07-21 16:26:24 <craftyguy> ikke: I see
2020-07-21 16:27:32 <oneinsect> it is not listed here https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#abuild-defined_functions
2020-07-21 16:28:07 <ikke> Maybe it should then. I always look in the source :_
2020-07-21 16:28:09 <ikke> :)
2020-07-21 16:29:56 <PureTryOut[m]> craftyguy: yeah `apk upgrade -a` should handle it
2020-07-21 16:47:01 <oneinsect> it is required to declare $pkgname-static before $pkgname-dev, otherwise $pkgname-dev will mv the static library to itself and $pkgname-static will fail
2020-07-21 16:47:15 <oneinsect> now there was a PR for this
2020-07-21 16:47:16 <oneinsect> https://github.com/alpinelinux/abuild/pull/72
2020-07-21 16:47:22 <oneinsect> was it merged?
2020-07-21 16:47:51 <oneinsect> i am facing the same issue like i am forced to declare static before dev otherwise abuild is failing
2020-07-21 16:48:00 <oneinsect> anyone notice this issue??
2020-07-21 16:48:59 <oneinsect> this doesnt work ----> "$pkgname-doc $pkgname-dev $pkgname-libs $pkgname-static"
2020-07-21 16:49:07 <oneinsect> however this works ----> subpackages="$pkgname-doc $pkgname-static $pkgname-dev $pkgname-libs"
2020-07-21 16:56:31 <ikke> yes, it's a known issue
2020-07-21 16:56:38 <ikke> I guess that change did not properly fix it
2020-07-21 17:00:32 <ikke> Or not released yet
2020-07-21 17:00:55 <oneinsect> hmmmm
2020-07-21 17:01:08 <oneinsect> someday i will document all this
2020-07-21 17:01:12 <oneinsect> someday
2020-07-21 17:06:11 <ncopa> i havent bumped pkgrel on alpine due to it will trigger rebuilds for all arches, which is not needed
2020-07-21 17:07:03 <PureTryOut[m]> ncopa: did you have an opinion on !6677? Last time I asked I didn't really get an answer 😅
2020-07-21 17:07:41 <PureTryOut[m]> Actually specifically https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/6677#note_80750
2020-07-21 17:08:09 <ncopa> sorry. I'm not too happy with the need for a cross compiler
2020-07-21 17:08:20 <ncopa> we do have native 32bit compilers
2020-07-21 17:10:08 <PureTryOut[m]> Hmm... Problem is that ATF really needs it 😕
2020-07-21 17:10:27 <ncopa> i havent had time to dig in what the problem there is. why cant we use native compilers?
2020-07-21 17:10:30 <PureTryOut[m]> Would you at least be ok with moving it to community for now? Wouldn't be useful for ATF but it would be useful for pmOS
2020-07-21 17:10:50 <ncopa> i guess moving to community would be okish
2020-07-21 17:10:57 <PureTryOut[m]> Because the firmware built in this case is for a co-processor of a different architecture
2020-07-21 17:11:05 <PureTryOut[m]> In this case armhf, where the main CPU is aarch64
2020-07-21 17:11:09 <ncopa> ah, co-processor
2020-07-21 17:11:13 <ncopa> that explains
2020-07-21 17:11:25 <ncopa> i need to go. sorry
2020-07-21 17:11:35 <PureTryOut[m]> Also in pmOS we have a device with a or1k co-processor
2020-07-21 17:11:44 <PureTryOut[m]> Np. Please just think about a proper way to go and come back to me later 😉
2020-07-21 17:55:45 <opal> how does alpine deal with binary patchsets? i'm dealing with https://github.com/processone/ejabberd/commit/2ca5712507473578fe00e4a1bce8e25a0d9f1bca.patch
2020-07-21 17:56:07 <opal> actually im not entirely sure why theres a binary just being included
2020-07-21 17:56:15 <opal> "dirty workaround" may be just that
2020-07-21 17:56:25 <opal> i'll have to look into this further, probably a way to avoid
2020-07-21 18:28:49 <ollieparanoid[m]> ncopa: thanks for the heads up
2020-07-21 18:28:57 <ollieparanoid[m]> PureTryOut et all: let's discuss in #postmarketOS-devel ;)
2020-07-21 20:08:58 <ollieparanoid[m]> ncopa: please ping us, when you roll it out so we can start rebuilding packages. I've announced the breakage for postmarketOS users here and linked to your ML post: https://postmarketos.org/blog/2020/07/21/breaking-update-in-edge/
2020-07-21 20:09:22 <ikke> ollieparanoid[m]: I have a feeling ncopa wants to do it tomorrow
2020-07-21 20:09:28 <ikke> (the original plan was to do it today)
2020-07-21 20:09:48 <ollieparanoid[m]> that's fine, I wrote "today or tomorrow" in the post :)
2020-07-21 20:11:13 <ikke> There will be a lot of fixing to do
2020-07-21 20:13:19 <ollieparanoid[m]> I can imagine
2020-07-21 20:14:37 <ikke> 29 packages in main missing, 896 in community
2020-07-21 20:15:15 <ikke> and more in testing
2020-07-21 20:33:19 <ikke> PureTryOut[m]: py3-networkx has a test failure (sounds like a dependency mismatch)
2020-07-21 20:44:03 <mps> you are pessimists
2020-07-21 20:45:00 <mps> I think some packages will need fixes, but not too much of them
2020-07-21 20:45:00 <ikke> Those are facts :P
2020-07-21 20:45:05 <ikke> no, not all of those
2020-07-21 20:45:19 <ikke> I just mentioned the packages that are currently missing
2020-07-21 20:45:20 <PureTryOut[m]> ikke: oh interesting. I wonder how it passed CI 🤔
2020-07-21 20:46:30 <ikke> beats me :)
2020-07-21 20:47:28 <PureTryOut[m]> ikke: for now you can disable the tests if you want, I don't have time right now to fix it but I'll look into it later
2020-07-21 20:47:54 <ikke> PureTryOut[m]: and apparently it even built on testing before?
2020-07-21 20:48:00 <ikke> maybe a dependency got updated?
2020-07-21 20:48:19 <PureTryOut[m]> Yup built on testing and on community in CI
2020-07-21 20:48:30 <ikke> sounds more like a dependency changed then
2020-07-21 20:48:35 <PureTryOut[m]> Maybe, but I'll have to look into it later
2020-07-21 21:47:09 <PureTryOut[m]> ikke: !10538 will unblock the builders
2020-07-21 21:49:46 <PureTryOut[m]> Thanks for the quick merging maxice8!
2020-07-21 21:49:53 <maxice8> welcome
2020-07-22 05:15:20 <ikke> PureTryOut[m]: nice, I see upstream already fixed the failing test as well
2020-07-22 05:15:57 <ikke> or rather, the broken code
2020-07-22 05:41:46 <Ariadne> ncopa: I'll be around all day to assist with time64 fallout
2020-07-22 05:41:56 <Ariadne> so whenever you want to do it, let's go
2020-07-22 05:43:15 <ncopa> good! i just wanted to check if there were any responses to the email
2020-07-22 05:43:20 <ncopa> lets do it!
2020-07-22 05:44:40 <ncopa> hum. looks like edge aarch64 builder is stuck on python
2020-07-22 05:51:23 <Cogitri> Yeah, it does that sometimes in tests
2020-07-22 05:51:42 <Cogitri> I think just killing the one stuck process made it continue and finish successfully
2020-07-22 05:58:03 <ncopa> musl 1.2 merged
2020-07-22 05:58:08 <maxice8> nice
2020-07-22 05:58:15 <ncopa> now, let me get the new edge builders up
2020-07-22 05:58:30 <Ariadne> button is pushed !
2020-07-22 06:09:13 <ncopa> build-edge-armhf is up
2020-07-22 06:14:52 <ncopa> build-edge-armv7 is up
2020-07-22 06:15:50 <ncopa> build fails on libical
2020-07-22 06:16:33 <mps> 46 - libical-glib-component (SEGFAULT)
2020-07-22 06:17:37 <ncopa> hum. i think i should make it continue and upload the already built packages, otherwise nobody will have a chance to work on those
2020-07-22 06:17:38 <mps> that is where it fails
2020-07-22 06:18:39 <ncopa> yes
2020-07-22 06:19:00 <ncopa> i dont know if it is a problem in glib or in libical
2020-07-22 06:21:09 <mps> glib have check disabled in alpine
2020-07-22 06:22:17 <mps> and when tried to build it with check enabled I have seen something similar, but don't have log so not sure
2020-07-22 06:24:34 <Ariadne> that's libical
2020-07-22 06:24:43 <Ariadne> you can look at the fix I did for mips
2020-07-22 06:24:56 <Ariadne> where it assumes time_t is 32 bit on mips even mips64
2020-07-22 06:24:58 <Ariadne> :)
2020-07-22 06:25:09 <ncopa> ah, ok
2020-07-22 06:46:20 <Ariadne> oops
2020-07-22 06:47:17 <ikke> Was that the wrong button? :P
2020-07-22 06:47:38 <Ariadne> yeah screen on my pixel didn't lock when I put it into my pocket
2020-07-22 06:47:45 <mps> could time_t on 32 bit arches replaced with long
2020-07-22 06:48:09 <Ariadne> no
2020-07-22 06:48:14 <Ariadne> long is 32bit
2020-07-22 06:48:46 <mps> 'long long' ?
2020-07-22 06:49:01 <Ariadne> long long is equivalent yes
2020-07-22 06:49:15 <ikke> long long time_ago;
2020-07-22 06:49:23 <mps> :)
2020-07-22 06:49:28 <Ariadne> we need something like %z
2020-07-22 06:49:32 <Ariadne> for time_t
2020-07-22 06:50:07 <mps> huh, I thought fixes will be simpler
2020-07-22 06:50:12 <[[sroracle]]> inb4 %jd intmax_t
2020-07-22 06:50:40 <Ariadne> (%z means whatever size_t is)
2020-07-22 06:50:41 <Ariadne> oh
2020-07-22 06:50:50 <Ariadne> yes %j would work
2020-07-22 06:50:54 <ikke> ollieparanoid[m]: fyi musl 1.2 has been pushed :)
2020-07-22 06:59:32 <ollieparanoid[m]> ikke: thanks!
2020-07-22 07:04:22 <ollieparanoid[m]> so... how does this work, the packages were built against 1.2 already, and now the builders are switching and uploading the new packages? or do the builders have to rebuild everything?
2020-07-22 07:04:38 <ikke> ollieparanoid[m]: ncopa setup new builders
2020-07-22 07:05:12 <ollieparanoid[m]> also the mirrors still seem to have 1.1.24. which mirror is the most recent one?
2020-07-22 07:05:53 <ollieparanoid[m]> ikke: I saw the new builders. But I don't understand why it fails at libical now, shouldn't this have already been built with the new builders?
2020-07-22 07:06:24 <ikke> ollieparanoid[m]: ncopa set the builders to skip everything that failed
2020-07-22 07:06:29 <ikke> so that it could make progress
2020-07-22 07:06:42 <ikke> That also explains why there are many missing packages
2020-07-22 07:06:53 <ikke> the new builders, that is
2020-07-22 07:07:29 <ikke> so ncopa basically swapped the old builders with the new builders, and now we need to get them in a good shape again
2020-07-22 07:09:36 <mps> so, 'apk update && apk upgrade -a' on armv7 will not break ssh access, I hope
2020-07-22 07:21:27 <ikke> ncopa: are the new 32-bits builders still setup to skip broken packages?
2020-07-22 07:21:37 <ikke> seems so
2020-07-22 07:33:52 <ollieparanoid[m]> okay, I had assumed "Majority of the packages have been rebuilt from scratch, but not all." means that all of main were rebuilt - but apparently not
2020-07-22 07:34:48 <ikke> 29 packages in main are/were missing
2020-07-22 07:34:51 <ollieparanoid[m]> which mirror is the main mirror, from which all others are replicated? I'd like to point our build scripts at that instead of dl-cdn to avoid caching related errors
2020-07-22 07:35:03 <ikke> main total built:       1566
2020-07-22 07:35:05 <ikke> main total relevant aports:     1595
2020-07-22 07:35:13 <ollieparanoid[m]> ah, that doesn't seem so bad
2020-07-22 07:36:17 <Ariadne> most of it is libical blocker
2020-07-22 07:38:20 <ikke> ollieparanoid[m]: i guess you can use dl-t1-1 or dl-t1-2
2020-07-22 07:39:26 <Ariadne> got the answer on libical
2020-07-22 07:39:32 <Ariadne> but people aren't going to like it
2020-07-22 07:39:41 <Ariadne> it's due to gobject-introspection
2020-07-22 07:40:05 <ollieparanoid[m]> ikke: they both still have the old musl version: http://dl-t1-1.alpinelinux.org/alpine/edge/main/armv7/ http://dl-t1-2.alpinelinux.org/alpine/edge/main/armv7/
2020-07-22 07:40:55 <ikke> Looks like the builders have not uploaded it yet
2020-07-22 07:41:02 <Ariadne> i suspect the issue is that gobject-introspection is generating code that assumes 32-bit time_t
2020-07-22 07:41:25 <ikke> ollieparanoid[m]: Once libical is fixed (and no other failures in main), then main is uploaded
2020-07-22 07:42:00 <ollieparanoid[m]> ikke: that explains it, thanks!
2020-07-22 07:47:38 <ikke> Ariadne: what is the consequence of disabling gobject-introspection?
2020-07-22 07:47:58 <Ariadne> can't autogenerate binding from python
2020-07-22 07:48:01 <Ariadne> also no vala, it seems
2020-07-22 07:48:12 <Ariadne> but we need to unblock main right now
2020-07-22 07:48:23 <Ariadne> we can fix gobject-introspection later :)
2020-07-22 07:48:27 <ikke> so we should expect some fall-out later
2020-07-22 07:48:44 <Ariadne> maybe, maybe not
2020-07-22 07:48:52 <ikke> ok
2020-07-22 07:48:55 <Ariadne> i disabled gobject-introspection on xfce months ago and nobody cared
2020-07-22 07:49:05 <ikke> yeah, depends if something is relying on it or not
2020-07-22 07:49:32 <Cogitri> GNOME will be very broken without it
2020-07-22 07:49:42 <Ariadne> yes
2020-07-22 07:49:46 <Cogitri> Anyway, the gir thingie should be a patch of a few lines
2020-07-22 07:49:58 <Ariadne> i'm not saying we disable it forever
2020-07-22 07:50:03 <Ariadne> just long enough to get things moving :)
2020-07-22 07:50:27 <Cogitri> Yup. I'll try to (finally) look into it later today
2020-07-22 07:51:39 <Cogitri> Should be as simple as patching this into shape and generating bindings https://gitlab.gnome.org/GNOME/gobject-introspection/-/blob/master/giscanner/ast.py#L345
2020-07-22 07:52:03 <Cogitri> (I think dalias also mentioned that a few other defitions were wrong)
2020-07-22 08:03:40 <Ariadne> yes, change it to be TYPE_INT64
2020-07-22 08:12:20 <ncopa> im back, sorry, had to eat breakfast
2020-07-22 08:13:37 <ncopa> ikke: i think i arm builders are currently halting on build errors, while x86 ignores errors and continues
2020-07-22 08:14:07 <ncopa> maybe i should let arm builders ignore errors too for a while
2020-07-22 08:14:16 <ncopa> at least til all new packages are uploaded
2020-07-22 08:19:09 <ollieparanoid[m]> sounds like a good idea to me
2020-07-22 08:23:45 <mps> I'm on road now, will try to upgrade and boot armv7 on real hardware later when I come back
2020-07-22 08:24:23 <mps> if it boots it is good, bugs will be fixed later
2020-07-22 08:25:23 <ncopa> ERROR: sqlite-libs-3.32.3-r0: BAD signature
2020-07-22 08:25:23 <ncopa> (141/152) Upgrading nss (3.52.1-r0 -> 3.54-r0)
2020-07-22 08:25:44 <ncopa> need to purge the cache
2020-07-22 08:50:35 <ncopa> so re https://gitlab.gnome.org/GNOME/gobject-introspection/-/blob/master/giscanner/ast.py#L347 are there some way to auto detect size of time_t in python at runtime?
2020-07-22 08:51:16 <ikke> maybe ctypes?
2020-07-22 08:51:47 <ikke> https://docs.python.org/3.8/library/ctypes.html#fundamental-data-types
2020-07-22 08:51:51 <ikke> not sure if it's usefull
2020-07-22 08:54:14 <ncopa> there is no time_t there, but I think a time_t there would be useful
2020-07-22 08:55:45 <oneinsect> quick question, will ap builddirs * option tell me if there are any missing dependencies in the repository?
2020-07-22 08:56:02 <oneinsect> lord ikke:
2020-07-22 08:56:21 <Cogitri> I think we can just hardcode the new time_t there, ncopa
2020-07-22 08:56:38 <Cogitri> almost all bindings should use GDateTime or similiar instead of time_t anyway
2020-07-22 08:56:44 <ncopa> yes, but should be fixed upstream
2020-07-22 08:57:01 <Cogitri> Yup, but upstream is a bit dead
2020-07-22 08:57:27 <ncopa> gobject-introstpection?
2020-07-22 08:57:30 <ncopa> or python
2020-07-22 08:57:37 <Cogitri> So let's just do a quick and dirty patch for g-i
2020-07-22 08:57:40 <Cogitri> gobject-introspection
2020-07-22 09:11:52 <ncopa> i think we should report it at least
2020-07-22 09:14:11 <ncopa> Ariadne: thanks for help with libical. patching gobject-introspection fixes it
2020-07-22 09:15:28 <ikke> should we remove the alpine-mirrors package?
2020-07-22 09:15:37 <ncopa> yeah, lets do so
2020-07-22 09:15:39 <Cogitri> <ncopa "i think we should report it at l"> I think that has been done already
2020-07-22 09:15:52 <Cogitri> actually, not sure if I opened an issue, but talked with upstream on IRC
2020-07-22 09:16:08 <ncopa> Cogitri: can you follow up that please?
2020-07-22 09:16:19 <ncopa> check if we have an upstream issue and create one if not
2020-07-22 09:16:33 <Ariadne> i'm just fixing packages and sending them patches
2020-07-22 09:16:39 <Ariadne> i've sent out like 10 patches so far
2020-07-22 09:16:48 <ncopa> awesome
2020-07-22 09:16:59 <ncopa> the gobject-introscpetion patch is just a hack for now
2020-07-22 09:17:13 <ncopa> needs to be done properly, but not sure how.
2020-07-22 09:17:26 <Ariadne> yeah i just did not wish to deal with that one (:
2020-07-22 09:17:31 <ncopa> :)
2020-07-22 09:19:03 <ncopa> adeile linux does not have the gobject-introspection patch
2020-07-22 09:20:38 <ikke> Ariadne: cjdns commit seems to be missing the patch?
2020-07-22 09:20:46 <ikke> https://git.alpinelinux.org/aports/commit/?id=3edf5bf1
2020-07-22 09:36:10 <ikke> Ariadne: cjdns is failing to build now due to missing patch :)
2020-07-22 09:36:21 <ikke> :)
2020-07-22 09:37:22 <Ariadne> ncopa: adelie does not care about gnome
2020-07-22 09:37:28 <Ariadne> it is strictly kde
2020-07-22 09:41:18 <ncopa> ok
2020-07-22 10:15:03 <Cogitri> Before I kill my IRC session by accident: Upgrading on x86_64 edge should be safe right now, right?
2020-07-22 10:15:17 <ncopa> yes
2020-07-22 10:15:38 <ollieparanoid[m]> ncopa: can you configure arm edge builders to continue building on errors to match x86? then we could start rebuilding postmarketOS packages
2020-07-22 10:15:52 <ollieparanoid[m]> my understanding is, that it would then push the new packages to the mirrors, including new musl version
2020-07-22 10:16:41 <Ariadne> they are already doig that
2020-07-22 10:16:58 <ncopa> i dont remember if i made armv7 do it
2020-07-22 10:17:02 <ncopa> i think armhf does at least
2020-07-22 10:17:07 <ikke> armv7 is not iirc
2020-07-22 10:17:07 <ncopa> i can check in a sec
2020-07-22 10:17:18 <ikke> oh, hmm
2020-07-22 10:17:45 <ikke> But it won't upload the repo as long as packages are still failing, right?
2020-07-22 10:18:01 <ncopa> no, it will upload the ones it managed to build
2020-07-22 10:18:08 <ncopa> and purge those it didnt (i think)
2020-07-22 10:18:32 <ikke> armv7 still contains musl 1.1
2020-07-22 10:18:49 <ollieparanoid[m]> http://dl-2.alpinelinux.org/alpine/edge/main/armhf/ just changed from 1.1 to 1.2
2020-07-22 10:19:29 <ollieparanoid[m]> but armv7 is still on 1.1 on the same mirror
2020-07-22 10:19:30 <ncopa> armv7 does not continue on error
2020-07-22 10:19:34 <ncopa> let me fix that
2020-07-22 10:21:10 <ncopa> looks like zsh tests fails on all arches
2020-07-22 10:21:38 <ncopa> or at least on x86_64
2020-07-22 10:21:42 <ncopa> i wonder what changed
2020-07-22 11:55:56 <Ariadne> looks like libseccomp needs a bump
2020-07-22 11:57:21 <ncopa> how so?
2020-07-22 11:57:55 <ncopa> im trying to debug knot
2020-07-22 11:58:53 <ncopa> testsuite is catching something that broke with musl 1.2 on 32 bit. havent found anything obvious yet
2020-07-22 12:02:01 <Ariadne> many packages are breaking on missing libseccomp.so.2
2020-07-22 12:02:49 <Ariadne> or perhaps it's gnome-desktop-dev that needs bump
2020-07-22 12:02:54 <Ariadne> that makes more sense
2020-07-22 12:47:07 <mps> on armv7 I got 'ERROR: gperf-3.1-r2: BAD signature'. can someone clear cache for armv7 edge
2020-07-22 12:53:09 <ncopa> Ariadne: what arch?
2020-07-22 12:53:14 <Ariadne> x86
2020-07-22 12:53:20 <Ariadne> i nudged it along
2020-07-22 12:53:22 <Ariadne> no worries
2020-07-22 12:53:33 <ncopa> i think the problem was that libseccomp was not built on x86
2020-07-22 12:53:39 <ncopa> and it was skipped during rebuild
2020-07-22 12:53:50 <ncopa> due to i aborted it
2020-07-22 12:54:05 <ncopa> im giving up on knot
2020-07-22 12:54:12 <ncopa> i have no clue why test suite fails
2020-07-22 12:54:19 <ikke> mps: you can do it yourself: curl -X PURGE <url>
2020-07-22 12:54:43 <ikke> mps: because many packages are still updated, we would continuously have to do that
2020-07-22 12:54:58 <ncopa> i will purge the cache for armv7
2020-07-22 12:55:45 <ncopa> this is how i do it: tar -zxf /var/cache/apk/APKINDEX.b53994b4.tar.gz -O APKINDEX | awk -F: '$0 == "" {print "http://dl-cdn.alpinelinux.org/alpine/edge/community/x86/" a["P"] "-" a["V"] ".apk"} {a[$1] = $2}' | xargs curl -X PURGE
2020-07-22 12:57:11 <ncopa> with the rigth apkindex, repo and arch
2020-07-22 12:58:17 <ncopa> man should be ok now
2020-07-22 12:58:21 <ncopa> main*
2020-07-22 12:58:28 <ncopa> edge/main/armv7
2020-07-22 12:58:41 <ncopa> and now shoudl also edge/community/armv7 be ok
2020-07-22 13:25:34 <ncopa> i think edge/testing/x86 is uploaded so i'm making it halt on first error
2020-07-22 13:29:05 <Cogitri> 👍
2020-07-22 13:55:33 <mps> works now, rebuild libseccomp on armv7 without errors
2020-07-22 14:14:35 <oneinsect> can we give a git source in APKBUILD instead of directly tar.gz file?
2020-07-22 14:14:48 <oneinsect> is there a way from which abuild can download it?
2020-07-22 14:15:20 <ikke> afaik, abuild does not directly support it
2020-07-22 14:16:42 <oneinsect> hmmmm
2020-07-22 14:16:47 <oneinsect> nice feature to have
2020-07-22 14:17:44 <mps> oneinsect: for distro? I don't think so
2020-07-22 14:17:44 <ikke> It doesn't really fit in abuilds / alpines philosophy that it should always build the same source
2020-07-22 14:18:07 <oneinsect> hmmmm indeed
2020-07-22 14:19:46 <wsinatra> It's extra work, but if you REALLY need something for the project you're working on you could fork the source, and then tag a release and source that
2020-07-22 14:20:12 <wsinatra> I don't know that that work would be upstreamable though, considering the above arguments
2020-07-22 14:21:08 <oneinsect> wsinatra: hello
2020-07-22 14:21:26 <oneinsect> something like a github mirror?
2020-07-22 14:21:41 <oneinsect> or say http://git.savannah.gnu.org/cgit/
2020-07-22 14:21:44 <oneinsect> of say*
2020-07-22 14:22:26 <wsinatra> yeah that's what I was thinking. I'm not sure a mirror would give you the control, but if the project owner won't/can't provide a static point in their repo to build against, you could try to do so
2020-07-22 14:23:06 <oneinsect> that is what the idea i had
2020-07-22 14:23:23 <wsinatra> At least at that point it gets you what you need for what you're working on, and you can open dialogue with the project maintainer to get it fixed long term so you can upstream your work
2020-07-22 14:23:41 <ikke> That means it takes 1 week before you even see it
2020-07-22 14:23:58 <ikke> but no history only makes sense if there are dependent items that extract information
2020-07-22 14:24:03 <ikke> uups
2020-07-22 14:24:05 <ikke> wrong channel
2020-07-22 14:25:04 <wsinatra> @ikke: at least you weren't typing credentials!
2020-07-22 14:27:06 <oneinsect> hmmm
2020-07-22 14:27:31 <Ariadne> you can technically provide your own fetch()
2020-07-22 14:27:50 <oneinsect> Ariadne: great idea!!!
2020-07-22 14:27:56 <Ariadne> oh no
2020-07-22 14:28:00 <Ariadne> why did i say anything
2020-07-22 14:28:03 <ikke> :D
2020-07-22 14:28:26 <ikke> You would also need to override verify
2020-07-22 14:28:27 <Ariadne> oneinsect: but if you actually do, then you're a horrible person
2020-07-22 14:28:36 <Ariadne> ikke: nah
2020-07-22 14:28:48 <Ariadne> ikke: you just don't put the git repo in $source
2020-07-22 14:28:59 <ikke> right
2020-07-22 14:29:23 <oneinsect> hmmm may be i will avoid it
2020-07-22 14:29:45 <oneinsect> how do i find a set of minimal packages with all interdependencies using ap
2020-07-22 14:30:05 <oneinsect> that is another advise you kind folks can give
2020-07-22 14:30:36 <oneinsect> the main repo contains too many packages
2020-07-22 14:30:54 <mps> oneinsect: but you can have particular git commit id as source for some git hubs, I know it works with github and gitlab
2020-07-22 14:31:21 <oneinsect> yes mps with github i can download the master.zip
2020-07-22 14:31:40 <Ariadne> you can actually
2020-07-22 14:31:41 <ikke> oneinsect: mps means you can use a hash instead
2020-07-22 14:31:47 <Ariadne> download any hash you want
2020-07-22 14:31:51 <ikke> so that you always get the source you want
2020-07-22 14:32:02 <ikke> githubs archive feature is basically git archive over http
2020-07-22 14:32:06 <oneinsect> is that possible in savannah gnu?
2020-07-22 14:32:17 <ikke> oneinsect: no clue
2020-07-22 14:32:29 <Ariadne> yes cgit can do it
2020-07-22 14:32:29 <ikke> that's cgit apparently
2020-07-22 14:32:36 <Ariadne> you just put the hash where master would go
2020-07-22 14:32:57 <mps> oneinsect: look source in testing/wiringx/APKBUILD
2020-07-22 14:33:35 <oneinsect> thanks Ariadne, mps let me look
2020-07-22 14:33:58 <oneinsect> aha _commitid=
2020-07-22 14:34:09 <oneinsect> nice, very nice, extremely nice
2020-07-22 14:34:12 <oneinsect> :D
2020-07-22 14:34:29 <Ariadne> hmm, also you may wish to consider snapshot()
2020-07-22 14:34:49 <Ariadne> but of course, you have to provide the generated source tarball
2020-07-22 14:34:52 <ikke> That requires someone with push access to upload the snapshot
2020-07-22 14:35:05 <Ariadne> indeed
2020-07-22 14:35:34 <ikke> if you can get an archive from a hash, that's preferable
2020-07-22 14:36:00 <oneinsect> not all gnu cgits have snapshots, some are like 5-10 years old
2020-07-22 14:36:28 <oneinsect> Ariadne: any idea on how to download from cgit using a hash
2020-07-22 14:37:20 <Ariadne> yes replace the part in the download url
2020-07-22 14:37:25 <Ariadne> that says master
2020-07-22 14:37:26 <Ariadne> with the has
2020-07-22 14:37:28 <Ariadne> h
2020-07-22 14:37:47 <ikke> under the commit tab
2020-07-22 14:37:50 <ikke> if you select a commit
2020-07-22 14:37:54 <ikke> it has the link
2020-07-22 14:38:07 <ikke> download <projectname>-<hash>.tar.gz
2020-07-22 14:38:57 <Ariadne> also overriding fetch() is not guaranteed to work on alpine builders
2020-07-22 14:39:09 <Ariadne> eventually, the builds will be done without network
2020-07-22 14:39:34 <ikke> Ariadne: but fetching sources would still require network, not?
2020-07-22 14:39:54 <ikke> unless we have something that prefetches the source
2020-07-22 14:39:55 <Ariadne> yes,but could be done before starting container, and without calling fetch()
2020-07-22 14:40:15 <ikke> Ariadne: would be fun with node / rust / go projects
2020-07-22 14:40:55 <oneinsect> let me try that Ariadne
2020-07-22 14:41:00 <oneinsect> thank you kind people
2020-07-22 14:42:40 <oneinsect> this is perfect
2020-07-22 14:42:57 <oneinsect> http://git.savannah.gnu.org/cgit/autoconf.git/snapshot/autoconf-96f0001bcda3ba9bed7eb13257842e556dbc4695.tar.gz
2020-07-22 14:43:03 <oneinsect> http://git.savannah.gnu.org/cgit/autoconf.git/snapshot/autoconf-master.tar.gz
2020-07-22 14:43:06 <oneinsect> both work
2020-07-22 14:43:15 <oneinsect> thank you thank you all
2020-07-22 14:43:40 <oneinsect> this will help me speed up
2020-07-22 14:54:15 <Cogitri> Can I merge things which work on CI right now, or should we wait until "newedge" (now edge) is happy?
2020-07-22 15:05:54 <Ariadne> ??
2020-07-22 15:05:57 <Ariadne> why do you need autoconf git
2020-07-22 15:06:17 <Ariadne> Cogitri: go for it
2020-07-22 15:16:55 <Cogitri> Okie :)
2020-07-22 15:21:15 <oneinsect> Ariadne lots of tests are failing
2020-07-22 15:21:26 <Ariadne> ok...?
2020-07-22 15:21:31 <Ariadne> tests in what
2020-07-22 15:21:35 <oneinsect> just trying to check the latest version
2020-07-22 15:21:40 <oneinsect> tests in Autoconf
2020-07-22 15:21:43 <oneinsect> package
2020-07-22 15:21:58 <oneinsect> when i am compiling*
2020-07-22 15:21:58 <Ariadne> the autoconf testsuite is beyond useless
2020-07-22 15:22:07 <oneinsect> hmmmm
2020-07-22 15:22:30 <oneinsect> but how do big distro like deb and fedora test it
2020-07-22 15:23:10 <oneinsect> even we are not running tests
2020-07-22 15:23:11 <oneinsect> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/autoconf/APKBUILD
2020-07-22 15:23:59 <oneinsect> 'we' as in Alpine
2020-07-22 15:25:02 <oneinsect> this work is way way time consuming than I had initially thought! never wonder you guys are who you are!
2020-07-22 15:25:43 <oneinsect> [bows to Ariadne & others]
2020-07-22 15:26:13 <Ariadne> oneinsect: we don't.  options="!check"
2020-07-22 15:26:29 <Ariadne> we concluded the testsuite was beyond repair
2020-07-22 15:26:30 <oneinsect> indeed
2020-07-22 15:26:53 <Ariadne> this is, unfortunately, common amongst GNU software that testsuites are useless
2020-07-22 15:27:06 <oneinsect> hmmmm
2020-07-22 15:28:27 <mps> and debian don't run tests, iirc
2020-07-22 15:28:36 <Ariadne> debian does run tests now
2020-07-22 15:28:54 <mps> ah, thats news for me
2020-07-22 15:28:58 <Ariadne> at least in some packages
2020-07-22 15:29:05 <Ariadne> there is a check debian/rules target
2020-07-22 15:29:10 <Ariadne> they keep copying us (:
2020-07-22 15:29:26 <Ariadne> its fine
2020-07-22 15:29:47 <Ariadne> mps: debian networking team is very interested in ifupdown-ng
2020-07-22 15:29:49 <Ariadne> sooooo
2020-07-22 15:29:57 <Ariadne> maybe instead of copy they will collaborate
2020-07-22 15:30:54 <mps> in my current debian archive of unpacked src debs no one have 'check'
2020-07-22 15:31:52 <Ariadne> its
2020-07-22 15:31:54 <mps> Ariadne: nice to hear, I will stop to keep eye on debian ifupdown from now :)
2020-07-22 15:31:54 <Ariadne> very very new
2020-07-22 15:32:17 <Ariadne> mps: original ifupdown was dropped because its maintainer concluded netplan was future
2020-07-22 15:32:26 <Ariadne> others are not happy about this and are happy about ifupdown-ng
2020-07-22 15:32:52 <mps> yes, I remember netplan discussion on debian-devel ML
2020-07-22 15:33:59 <mps> announce, actually. meh, looks like travel was to much for me on hot day. I'm so tired
2020-07-23 04:58:11 <opal> https://wowana.me/paste/7S4vL7.txt
2020-07-23 04:58:25 <opal> stunnel evidently doesnt have armhf in repo
2020-07-23 04:58:44 <opal> tried building and came up with this
2020-07-23 04:59:07 <opal> without CHOST it seems to build an x86_64 executable and get stuck during test phase with a running stunnel instance
2020-07-23 04:59:27 <opal> without CHOST and options=!check i should say
2020-07-23 05:01:46 <ikke> We upgraded to musl-1.2 yesterday, which means all packages for 32-bits arches have to be rebuilt
2020-07-23 05:01:50 <ikke> but not all of them have yet
2020-07-23 05:02:04 <opal> ah
2020-07-23 05:02:26 <opal> makes sense, no rush. goes to show i dont keep up with anything
2020-07-23 07:02:36 <maxice8> Seems like armv7 is broken
2020-07-23 07:11:37 <mps> upgrade to musl 1.2.0 didn't went without issues
2020-07-23 07:12:44 <mps> for 32bit arches, I mean
2020-07-23 07:23:46 <mps> llvm batteries 1.0.0.1 with some bug fixes are released
2020-07-23 07:24:26 <mps> 10.0.1*
2020-07-23 10:24:21 <radiomark> Hi, in the Gitlab intereface I accidentally forked the wrong project. I can see no way to delete my fork?
2020-07-23 10:26:03 <ikke> under settings
2020-07-23 10:26:14 <ikke> general > advanced
2020-07-23 10:26:28 <ikke> There should be a section "Remove Project"
2020-07-23 10:26:40 <radiomark> Ah yes
2020-07-23 10:26:42 <radiomark> Wow
2020-07-23 10:26:48 <radiomark> Thank you
2020-07-23 10:27:15 <radiomark> I have been using Git for many years but it will take me a lot of time to get used to all these... buttons :)
2020-07-23 10:49:04 <Hello71> you don't have to delete it
2020-07-23 10:49:22 <Hello71> the space consumption is minimal
2020-07-23 10:59:13 <radiomark> Well I forked the wrong repository, so it would confuse me
2020-07-23 11:22:17 <hc-hmk> I'd like some help with syslinux/extlinux. For some reason I can't ask it to boot from a kernel image within a directory. I've moved the kernel and ramdisk from /boot to /boot/test, updated extlinux.conf accordingly, and applied the config. It just fails with "Loading /test/vmlinuz-lts... failed: no such file or directory"
2020-07-23 11:30:53 <hc-hmk> What's confusing to me is that ArchWiki lists "LINUX ../vmlinuz-linux" as a valid argument. It doesn't seem that it's because directories are not supported, rather me missing something obvious.
2020-07-23 11:35:46 <mps> slash before path
2020-07-23 11:36:15 <mps> what is your line to vmlinuz-lts
2020-07-23 11:36:25 <hc-hmk> You're suggesting that the issue is that I've used an absolute path instead of relative?
2020-07-23 11:37:34 <hc-hmk> Path to vmlinuz-lts is /boot/test/vmlinuz-lts. /boot is not present when bootloader is called, so it's actually /test/vmlinuz-lts
2020-07-23 11:37:39 <mps> no, but something is wrong with your boot partition or line to kernel
2020-07-23 11:38:32 <mps> hmm, is the boot partition mounted under /boot dir
2020-07-23 11:39:05 <hc-hmk> Yes it is
2020-07-23 11:40:08 <hc-hmk> The only change I've made is litterally calling mv and changing /vmlinuz-lts to /test/vmlinuz-lts in extlinux.conf
2020-07-23 11:42:20 <mps> hmm, it should work
2020-07-23 11:43:19 <mps> anyway, try without leading slash
2020-07-23 11:43:52 <hc-hmk> Thanks, I'll give it a try. I just tried ./test/vmlinuz-lts but that failed aswell.
2020-07-23 11:48:22 <afontain_> Hey, I found build.a.o, but I couldn't find a list of broken packages
2020-07-23 11:51:49 <ikke> afontain_: the builders can operate in 2 modes
2020-07-23 11:52:01 <ikke> afontain_: usually, they stop after the first build failure
2020-07-23 11:52:22 <ikke> for this project, the 32-bits builders were set in a mode to just continue
2020-07-23 11:52:52 <ikke> x86 has been switched back, but armv7 and armhf not yet
2020-07-23 11:53:26 <Cogitri> All build failures are posted in #alpine-commits though
2020-07-23 11:53:27 <ikke> Basically that means, in the common case, there is no list of broken packages, just the last package that could not be built
2020-07-23 11:53:41 <ikke> Cogitri: yes, indeed. Most of them currently due to missing dependencies though
2020-07-23 11:53:55 <ikke> So there is a lot of 'noise'
2020-07-23 11:54:15 <ikke> ncopa: would it make sense to switch armv7 and armhf now to stop at build failures?
2020-07-23 11:54:46 <ncopa> yes. but I think they need to first finish with testing?
2020-07-23 11:54:55 <ikke> aha, ok
2020-07-23 11:54:57 <ncopa> looks like they are not done yet with testing
2020-07-23 11:54:59 <ikke> ok
2020-07-23 11:55:11 <ikke> thought they finished already
2020-07-23 11:55:27 <ncopa> im not sure if they have tbh
2020-07-23 11:55:55 <ikke> no, I see, they are still working on testing
2020-07-23 11:58:59 <ikke> afontain_: it seems that on armv7, cjdns and sqsh are not built yet
2020-07-23 11:59:38 <afontain_> is there a way to do the opposite and see if a package has been built?
2020-07-23 11:59:58 <ncopa> im working on nginx on x86 #11772
2020-07-23 12:31:43 <afontain_> so lightdm has been built, but not commited, or did it just not make its way to the mirrors yet?
2020-07-23 12:32:05 <ncopa> what arch?
2020-07-23 12:32:10 <ikke> armv7
2020-07-23 12:32:15 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-armv7/community/lightdm/lightdm-1.30.0-r3.log
2020-07-23 12:32:36 <ikke> was built 6 days ago
2020-07-23 12:33:35 <ikke> it
2020-07-23 12:33:43 <ikke> it's not present in the repo of the builder
2020-07-23 12:34:28 <ncopa> >>> lightdm: Analyzing dependencies...
2020-07-23 12:34:28 <ncopa> ERROR: unsatisfiable constraints:
2020-07-23 12:34:28 <ncopa>   qt5-qtbase-dev (missing):
2020-07-23 12:34:28 <ncopa>     required by: .makedepends-lightdm-20200723.123418[qt5-qtbase-dev]
2020-07-23 12:35:06 <ikke> I guess that buildlog was from the previous builder
2020-07-23 12:38:11 <ncopa> huh.... doas: not installed setuid
2020-07-23 12:38:20 <ncopa> i wonder if fakeroot is broken
2020-07-23 12:40:10 <ncopa> $ apk fetch --stdout -q doas | tar -ztv | grep bin/doas
2020-07-23 12:40:10 <ncopa> -rwsr-xr-x buildozer/buildozer 21712 2020-02-04 00:57 usr/bin/doas
2020-07-23 12:40:18 <ncopa> should be owned by root
2020-07-23 12:41:15 <ikke> strange
2020-07-23 12:41:52 <ncopa> looks like it only affects armv7
2020-07-23 12:43:32 <ncopa> i guess fakeroot was broken during bootstrap
2020-07-23 12:59:09 <tmhoang> surprised there is no aports for yq. wondering if it's too complicated ?
2020-07-23 12:59:12 <tmhoang> looking ...
2020-07-23 12:59:50 <ikke> is that a yaml variant for jq?
2020-07-23 13:00:04 <tmhoang> sounds like that - I don't have much backgrounds of both
2020-07-23 13:00:34 <ikke> https://mikefarah.gitbook.io/yq/
2020-07-23 13:01:03 <tmhoang> two yq : not sure what is what https://github.com/kislyuk/yq , https://mikefarah.gitbook.io/yq/
2020-07-23 13:02:28 <ikke> the former seems to be a wrapper around jq, while the latter more stand-alone is
2020-07-23 13:03:14 <tmhoang> 
ACTION ikke reads fast ...

2020-07-23 13:04:03 <tmhoang> github used to have bar where it shows what languages the project is written on, notw it's gone
2020-07-23 13:04:13 <ikke> it's on the right
2020-07-23 13:04:16 <ikke> in the sidebar
2020-07-23 13:07:09 <tmhoang> +1
2020-07-23 13:07:09 <tmhoang> https://github.com/kislyuk/yq -> seems a python binding/wrapper .
2020-07-23 13:07:24 <ikke> the other one is a go project
2020-07-23 13:16:19 <tmhoang> I think I'd package that go project
2020-07-23 13:20:04 <mps> tmhoang: we have 'oq'
2020-07-23 13:21:08 <hc-hmk> Is there an easy way to recompress vmlinuz? I know it's a buildtime thing, but i thought it might be doable.
2020-07-23 13:24:12 <mps> gcc 10.2 released with 94 bugfixes https://gcc.gnu.org/pipermail/gcc/2020-July/233215.html
2020-07-23 13:26:49 <dne> hc-hmk: this is at least half of the solution: https://raw.githubusercontent.com/torvalds/linux/master/scripts/extract-vmlinux
2020-07-23 13:37:21 <afontain_> ikke/ncopa: odd. Does changing the permission back makes it create the apk?
2020-07-23 13:38:11 <ikke> afontain_: I think it's unrelated
2020-07-23 13:38:50 <afontain_> well, I'd be surprised if it was the cause of the issue too
2020-07-23 13:39:05 <afontain_> maybe if someone restarts the build it'll work
2020-07-23 13:40:02 <ikke> the builder is already working, finishing of testing
2020-07-23 13:40:09 <ikke> we need to wait for that to complete first
2020-07-23 13:40:45 <afontain_> there's the same problem on armhf actually
2020-07-23 13:40:55 <afontain_> oh, it does build testing before community?
2020-07-23 13:41:11 <ikke> no
2020-07-23 13:41:14 <afontain_> (I'd be surprised if it did)
2020-07-23 13:41:27 <ikke> but it basically skipped over all errors in community and is proceeding with testing
2020-07-23 13:42:21 <afontain_> well, if lightdm failed, I could try to look into the error
2020-07-23 13:42:34 <ikke> lightdm itself didn't fail
2020-07-23 13:42:36 <afontain_> (I don't have the error though)
2020-07-23 13:42:38 <ikke> it just is missing a dependency
2020-07-23 13:42:45 <ikke> afontain_: ncopa mentioned it above
2020-07-23 13:43:44 <afontain_> ah, yes
2020-07-23 13:44:13 <ikke> so if some base package is failing, all it's dependees cannot be built either
2020-07-23 13:44:34 <ikke> but in this mode, it's hard to see what the base package is that failed
2020-07-23 13:44:46 <ikke> so best to just wait until it's finished
2020-07-23 13:45:11 <ikke> then we will switch the builder to stop after failure, and then step by step we can start trying to fix things
2020-07-23 13:45:39 <afontain_> ok
2020-07-23 13:45:51 <ikke> for x86, it's perl-mail-dkim
2020-07-23 13:46:37 <ikke> I mean, the package where the builder is stuck on
2020-07-23 13:47:01 <tmhoang> could I override CLEANUP= in /etc/abuild.conf in APKBUILD ?
2020-07-23 13:47:39 <ikke> tmhoang: no, but I guess you have issues with abuild trying to clean-up go packages?
2020-07-23 13:48:12 <tmhoang> hmm no ? ignore that sorry for noice
2020-07-23 13:48:16 <ikke> ah ok
2020-07-23 13:48:19 <tmhoang> 
ACTION stupid 

2020-07-23 13:48:25 <ikke> because we do have a solution for that :)
2020-07-23 13:49:03 <tmhoang> ikke: sound curious to me ? abuild clean up go packages ? go packages as build dependencies ?
2020-07-23 13:49:11 <ikke> yes
2020-07-23 13:49:42 <ikke> a common pattern is to set GOPATH to somewhere in $srcdir
2020-07-23 13:50:10 <ikke> but go sets these files to read-only
2020-07-23 13:50:11 <tmhoang> sounds right, I'm doing that, blatantly copying govendor from clandmeter
2020-07-23 13:50:28 <ikke> so when abuild tries to clean them up, it's denied
2020-07-23 13:54:19 <tmhoang> ikke: like this ? https://git.alpinelinux.org/aports/tree/community/consul/APKBUILD#n61
2020-07-23 13:54:32 <tmhoang> ah no it's only srcdir ?
2020-07-23 13:54:59 <ikke> yes, but we have a built-in option for that
2020-07-23 13:55:14 <ikke> options="..chmod-clean"
2020-07-23 13:56:12 <tmhoang> wow neeat
2020-07-23 13:56:13 <hc-hmk> dne: thanks man, I found the same script on https://github.com/torvalds/linux/blob/master/scripts/extract-vmlinux. There doesn't seem a straight forward way to compress it again using a different algorithm though. Thanks anyway. I'm off for today, bye.
2020-07-23 13:56:38 <ikke> tmhoang: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L125
2020-07-23 14:04:27 <tmhoang> ikke: not too bad ? https://tpaste.us/za09
2020-07-23 14:09:38 <ikke> Looks alright I guess, though I wished we had a bit of a standard, because many APKBUILDs do it in a different way
2020-07-23 14:10:28 <tmhoang> agreed. that's why I copied from signiificant developers :)
2020-07-23 14:10:38 <ikke> hehe
2020-07-23 14:10:51 <ikke> What doesn't make it easy is that things have changed in the last 2 years
2020-07-23 14:11:18 <ikke> mainly due to golang officially supporting dependencies (which is an improvement)
2020-07-23 14:55:35 <PureTryOut[m]> Is there a way to make abuild use more cores for the processes being ran in it? I'm compiling a Rust program and rustc compiles with a single core/thread, which makes it take ages
2020-07-23 15:00:36 <tmhoang> PureTryOut[m] there is an option /etc/abuild.conf
2020-07-23 15:00:42 <tmhoang> ikke: if you have a minute : https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10566
2020-07-23 15:02:39 <PureTryOut[m]> tmhoang: yeah modified it before but it didn't seem to make any difference
2020-07-23 15:03:44 <PureTryOut[m]> It does now though, weirdly. Thanks lol
2020-07-23 15:04:35 <Cogitri> Seems like we don't pass --jobs to cargo
2020-07-23 15:04:43 <Cogitri> So that should probably be changed
2020-07-23 15:08:40 <ikke> tmhoang: will look at that in a bit
2020-07-23 15:08:47 <tmhoang> thanks !
2020-07-23 15:13:45 <PureTryOut[m]> Cogitri: oh yeah now it's down to compiling just a single crate and it's doing it with a single core again
2020-07-23 15:14:07 <PureTryOut[m]> Would be great to have that changed yes 😅
2020-07-23 15:34:24 <Hello71> doesn't cargo use number of cores by default
2020-07-23 15:35:00 <Hello71> https://github.com/rust-lang/rust/issues/47518
2020-07-23 15:35:44 <Hello71> iirc codegen units is 1 by default on release builds
2020-07-23 15:36:09 <Hello71> thinlto can be parallelized but I think is not on by default anyways
2020-07-23 15:38:35 <Cogitri> It's not the default, but many projects set it so they get the best optimization possible
2020-07-23 15:38:57 <Cogitri> Not sure about the number of cores by default, but cargo should respect what we set via $JOBS either way
2020-07-23 15:59:06 <PureTryOut[m]> Yup. I had to recompile this package a lot of times and it's taking multiple minutes per try. Really annoying lol
2020-07-23 16:08:26 <Cogitri> Welcome to modern programming languages :D
2020-07-23 16:20:15 <PureTryOut[m]> Can we remove the possibility to mix edge and non-edge repositories? Like make apk warn or something. I got a mail of someone doing it with one of the packages I maintain and it just breaks things
2020-07-23 16:21:59 <Cogitri> Yes, it always breaks at some point
2020-07-23 16:22:58 <Cogitri> Somehow I thought I already made an issue about that for apk, but apparently I didn't, let me do that now
2020-07-23 16:23:33 <Cogitri> Oh, I'm just blind https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10699
2020-07-23 17:14:10 <afontain_> Maybe the builders can be switched back to the "don't retry on build fail" mode?
2020-07-23 17:14:30 <afontain_> It looks like they tried to build everything from testing already
2020-07-23 17:14:40 <afontain_> (^ take that with a grain of salt, obviously)
2020-07-23 18:39:58 <ikke> Trying to figure out why armv7 gives this weird asn.1 error
2020-07-23 18:40:01 <ikke> I cannot reproduce it
2020-07-23 18:40:06 <ikke> (ci)
2020-07-23 18:42:51 <ikke> Whenever a project is forked, it copies the settings of the jobs that relate to it. This means that if you have shared Runners set up for a project and someone forks that project, the shared Runners will also serve jobs of this project.
2020-07-23 18:42:54 <ikke> interesting
2020-07-23 19:03:10 <ikke> ok, can repro it now
2020-07-23 19:06:43 <ikke> hmm, curl seems broken after system upgrade on armv7
2020-07-23 19:06:52 <ikke> mps: ping
2020-07-23 19:14:30 <mps> ikke: pong
2020-07-23 19:15:12 <clandmeter> pet
2020-07-23 19:15:25 <ikke> mps: do you have issues on armv7 edge after upgrading your system?
2020-07-23 19:15:31 <ikke> with git / curl over https?
2020-07-23 19:15:50 <mps> I didn't upgraded yesterday or today
2020-07-23 19:15:59 <ikke> seems something is broken
2020-07-23 19:16:04 <ikke> not sure if it's transitional or not
2020-07-23 19:16:06 <mps> I can try on lxc in 15 minutes
2020-07-23 19:16:23 <ikke> our CI on armv7 is broken atm
2020-07-23 19:16:38 <ikke> curl just plainly times out
2020-07-23 19:16:43 <mps> ok, I will test it
2020-07-23 19:16:50 <ikke> and git gives an error about not being able to get the time
2020-07-23 19:17:00 <mps> have to finish disk copy
2020-07-23 19:17:06 <ikke> thanks
2020-07-23 19:17:13 <mps> np
2020-07-23 19:17:16 <ikke> clandmeter: is that pim pam pet?
2020-07-23 19:17:31 <clandmeter> :p
2020-07-23 19:18:12 <mps> 'apk update && apk upgrade -a' will be ok?
2020-07-23 19:18:28 <ikke> yes
2020-07-23 19:18:36 <mps> ok
2020-07-23 19:19:36 <ikke> openssl s_client seems to work
2020-07-23 19:19:49 <ikke> oh, it also gives an error
2020-07-23 19:19:55 <ikke> Verify return code: 14 (format error in certificate's notAfter field)
2020-07-23 19:20:10 <ikke> looks like all related to musl upgrade
2020-07-23 19:20:29 <mps> huh, but I upgraded musl about month ago
2020-07-23 19:22:16 <Cogitri> Maybe it only happened after rebuilding things
2020-07-23 19:22:20 <ikke> yes
2020-07-23 19:22:36 <ikke> this is only main btw
2020-07-23 19:22:38 <ikke> no community
2020-07-23 19:22:42 <mps> I thought so
2020-07-23 19:23:14 <mps> but I rebuilt busybox and it worked
2020-07-23 19:23:35 <ikke> right, but this is curl / openssl
2020-07-23 19:23:36 <mps> ah, s_client from openssl, not bb
2020-07-23 19:23:52 <mps> yes,right
2020-07-23 19:31:34 <mps> ikke: 'curl https://www.alpinelinux.org' works after upgrade
2020-07-23 19:31:56 <mps> now I will restart lxc and try again
2020-07-23 19:32:04 <ikke> hmm, yes, that works for me as well
2020-07-23 19:32:08 <ikke> can you try gitlab?
2020-07-23 19:32:32 <ikke> oh, hmm, gitlab now works as well :-/
2020-07-23 19:33:31 <mps> heh, <html><body>You are being <a href="https://gitlab.alpinelinux.org/alpine">redirected</a>.</body></html>
2020-07-23 19:33:38 <mps> works also
2020-07-23 19:35:13 <ikke> ok
2020-07-23 19:35:17 <ikke> looks like perhaps docker related
2020-07-23 19:35:47 <mps> I see, I follow another channel :)
2020-07-23 19:35:53 <ikke> heh
2020-07-23 19:53:32 <ikke> So conclusion is that it's a docker bug
2020-07-23 19:53:52 <ikke> where it returns an invalid error code
2020-07-23 19:54:03 <mps> or missing vdso
2020-07-23 19:57:21 <dalias> having vdso masks the bug
2020-07-23 19:57:21 <dalias> but the bug is that docker is generating EPERM instead of ENOSYS
2020-07-23 19:57:41 <ikke> right, that's what I understood
2020-07-23 19:58:20 <mps> yes, I thought vdso as workaround, temporary
2020-07-23 19:59:42 <mps> hmm, but linux-lts for armv7 have it enabled in kernel config
2020-07-23 20:00:29 <ikke> what about linux-virt?
2020-07-23 20:00:36 <dalias> ?
2020-07-23 20:00:40 <dalias> have what enabled?
2020-07-23 20:00:45 <dalias> vdso?
2020-07-23 20:00:48 <mps> CONFIG_VDSO=y
2020-07-23 20:00:55 <dalias> whether vdso clock_gettime gets used depends on the hardware
2020-07-23 20:01:07 <ikke> In this case it's a VM
2020-07-23 20:01:09 <dalias> if there's not a hardware clock that's usable from userspace, it won't get used
2020-07-23 20:01:26 <dalias> not sure if vm can provide such a clock
2020-07-23 20:01:52 <mps> qemu can
2020-07-23 20:01:53 <ikke> maybe through virtio?
2020-07-23 20:02:06 <ikke> yes, it's qemu
2020-07-23 20:03:12 <mps> I run armv7 on x86_64 with this qemu parameter '-rtc base=utc,clock=host'
2020-07-23 20:03:50 <ikke> ok, let me add that then
2020-07-23 20:08:14 <ikke> Doesn't seem to help
2020-07-23 20:08:26 <ikke> hwclock: can't open '/dev/misc/rtc': No such file or directory
2020-07-23 20:09:01 <mps> let me rework boot qemu script to run on aarch64 and check
2020-07-23 20:09:30 <mps> it need some time to boot :)
2020-07-23 20:13:04 <ikke> I can't seem to find any references on how to do it either
2020-07-23 20:14:21 <mps> yes, it doesn't work on aarch64
2020-07-23 20:14:26 <mps> hmm
2020-07-23 20:24:27 <ikke> dalias: is this a correct description? https://gitlab.alpinelinux.org/alpine/aports/-/issues/11774
2020-07-23 20:24:54 <mps> ikke:  385.452110] rtc-pl031 9010000.pl031: registered as rtc0
2020-07-23 20:25:10 <mps> modprobe rtc-pl031
2020-07-23 20:25:25 <ikke> [    7.250661] hctosys: unable to open rtc device (rtc0)
2020-07-23 20:25:38 <mps> ls /dev/rtc0
2020-07-23 20:25:49 <ikke> ls: /dev/rtc0: No such file or directory
2020-07-23 20:26:03 <mps> yes, but this module needs to be added 'manually'
2020-07-23 20:26:17 <mps> then you get  /dev/rtc0
2020-07-23 20:26:27 <ikke> Module rtc-pl031 not found in directory /lib/modules/4.19.75-0-vanilla
2020-07-23 20:26:39 <mps> ofc, it could in boot cmdline
2020-07-23 20:27:02 <mps> uh, Linux alpine 5.4.5-0-lts #1-Alpine SMP Thu, 19 Dec 2019 09:08:46 UTC armv7l GNU/Linux
2020-07-23 20:27:26 <mps> didn't know this old kernel is still used
2020-07-23 20:27:32 <ikke> me neither
2020-07-23 20:34:49 <mps> new boot msg ' * Setting system clock using the hardware clock [UTC] ... [ ok ]' with rtc-pl031 in /etc/modules and qemu rtc cli changed to '-rtc base=utc,clock=vm'
2020-07-23 20:34:55 <ikke> ok
2020-07-23 20:35:02 <ikke> I'll see if we can get it updated
2020-07-23 20:35:06 <ikke> it's still using linux-vanilla
2020-07-23 20:35:56 <mps> cat /proc/drivers/rtc is here https://tpaste.us/lY0X
2020-07-23 20:36:48 <mps> lets see can we add it on boot loader APPEND line
2020-07-23 20:37:52 <ikke> mps: how do you know what rtc module to use?
2020-07-23 20:38:04 <ikke> there are 59 of them
2020-07-23 20:38:30 <mps> hehe, intuition ;P
2020-07-23 20:38:49 <ikke> Should I look at what the host uses?
2020-07-23 20:38:55 <ikke> non
2020-07-23 20:38:58 <ikke> none*
2020-07-23 20:39:03 <mps> kidding, those which starts with pl0 are usually for some emulation
2020-07-23 20:39:25 <ikke> there aren't any pl0 drivers available
2020-07-23 20:39:43 <mps> rtc-pl031
2020-07-23 20:39:46 <ikke> Hmm, on the host: cat: can't open '/proc/drivers/rtc': No such file or directory
2020-07-23 20:39:48 <mps> rtc-pl030
2020-07-23 20:40:14 <mps> they are not for host, for guest
2020-07-23 20:40:33 <mps> hmm, so host don't have rtc
2020-07-23 20:40:45 <ikke> nope, apparently not
2020-07-23 20:41:42 <mps> but I think that is not important for guest till you use '-rtc base=utc,clock=host'
2020-07-23 20:42:40 <ikke> Well, I _did_ use that :P
2020-07-23 20:43:39 <mps> but that doesn't matter
2020-07-23 20:43:52 <mps> driver is important
2020-07-23 20:44:57 <mps> host is for VM to follow host clock, rt is to not follow it, and 'vm' is to allow VM rtc to sleep when the machine in 'sleep' state
2020-07-23 20:47:57 <mps> that is for 'qemu-system-arm -machine virt -cpu cortex-a15 -m 1024 -bios boot/u-boot.bin ....'
2020-07-23 23:30:25 <the6543> hi
2020-07-23 23:31:24 <the6543> for a package: if you have the potion to download prebuild artefacts or the source code, witch one is prevered ?
2020-07-23 23:31:47 <the6543> more exact: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11764
2020-07-23 23:31:48 <ikke> source code
2020-07-23 23:32:03 <the6543> @ikke me too :)
2020-07-23 23:32:09 <the6543> ok so it is not just me
2020-07-23 23:32:17 <ikke> 'must be'
2020-07-23 23:32:19 <ikke> heh
2020-07-23 23:32:49 <the6543> one interesting thing throu would be to build the frontend once for all architectures but this is more a CI thing i think
2020-07-23 23:33:55 <the6543> @ikke should we close #11764 or wait for responce?
2020-07-23 23:36:01 <ikke> It's polite to at least wait for a reply
2020-07-23 23:37:09 <the6543> :E
2020-07-23 23:37:13 <the6543> ok :)
2020-07-23 23:37:13 <ikke> the6543: what is actually being built for the front-end?
2020-07-23 23:37:59 <the6543> css, fonts, js
2020-07-23 23:38:20 <the6543> imgs
2020-07-23 23:38:52 <the6543> (svg octicons)
2020-07-23 23:39:11 <the6543> summary: css from less files, and the webpack stuff
2020-07-23 23:39:15 <ikke> Right, so it's less clear-cut for those kinds of things
2020-07-23 23:40:06 <the6543> well in the past some of this was included in the git history but it caused only a lot of merge-conflicts
2020-07-23 23:40:08 <ikke> the6543: note that CI is not doing the final building of packages
2020-07-23 23:40:13 <ikke> we have dedicated builders for that
2020-07-23 23:40:21 <the6543> didnt know
2020-07-23 23:40:38 <the6543> how are they doing ;)
2020-07-23 23:40:52 <the6543> 50% usage or more 200%
2020-07-23 23:45:26 <the6543> @ikke is there somewhere a stats.alpinelinux.org ?
2020-07-23 23:45:45 <ikke> Only build.alpinelinux.org
2020-07-24 00:00:45 <dalias> ikke, yes that sounds good
2020-07-24 04:42:28 <ikke> dalias: ok, thanks
2020-07-24 05:47:30 <ikke> ncopa: armv7/testing just finished
2020-07-24 06:35:44 <Ariadne> https://github.com/ifupdown-ng/ifupdown-ng/issues/3
2020-07-24 06:35:51 <Ariadne> would like to hear thoughts on my /e/n/i redesign
2020-07-24 06:59:38 <ncopa> morning
2020-07-24 07:00:27 <Cogitri> Morning
2020-07-24 07:00:32 <ikke> morning
2020-07-24 07:02:59 <mps> \o
2020-07-24 07:04:59 <Ariadne> mps: see above github issue :)
2020-07-24 07:06:37 <ikke> what does triplet refert to in that context?
2020-07-24 07:06:49 <mps> Ariadne: already seen, but I'm busy with my dayjob and trying to fix some arm32 issues
2020-07-24 07:06:56 <ikke> triple*
2020-07-24 07:07:09 <Ariadne> ikke: {A, B, C}
2020-07-24 07:07:14 <Ariadne> in this case,
2020-07-24 07:07:21 <mps> I hope I will try it over weekend
2020-07-24 07:07:23 <Ariadne> {"eth0", "address", "1.2.3.4/24"}
2020-07-24 07:07:28 <Ariadne> would be an example
2020-07-24 07:07:44 <Ariadne> it's a semantic data science term
2020-07-24 07:08:17 <ikke> A fixed size tuple basically
2020-07-24 07:08:43 <mps> sorry to jump in blindly, would be nice to have something like 'address 1.2.3.4/24 brd +' (as iproute have syntax)
2020-07-24 07:08:57 <Ariadne> yes, basically instead of having
2020-07-24 07:09:12 <Ariadne> {key, value}
2020-07-24 07:09:19 <Ariadne> you have {noun, verb, modifier}
2020-07-24 07:09:25 <Ariadne> eth0 is the noun
2020-07-24 07:09:39 <ikke> understood
2020-07-24 07:09:46 <Ariadne> this allows for creating trees for cheap, and if you have triple trees, you have RDF, e.g. xquery
2020-07-24 07:09:49 <mps> broadcast, network are which annoys me most in current ifupdown
2020-07-24 07:10:05 <Ariadne> mps: ifupdown-ng handles that automatically :)
2020-07-24 07:10:13 <Ariadne> you just do
2020-07-24 07:10:17 <Ariadne> address 1.2.3.4/24
2020-07-24 07:10:25 <mps> nice :)
2020-07-24 07:10:25 <Ariadne> and it will do the rest
2020-07-24 07:10:54 <Ariadne> or more accurately, it lets the kernel figure out the rest
2020-07-24 07:11:00 <mps> I will try to find time over weekend to install it and test
2020-07-24 07:11:56 <Ariadne> ikke: this is particularly useful to me, because we are working on an acf-like thing that uses restconf, yang and json-ld to represent full system state
2020-07-24 07:12:03 <Ariadne> :)
2020-07-24 07:12:36 <ikke> right, it's nice to able to 'parse' the format
2020-07-24 07:13:55 <mps> and if can have interface hotplug evenets in mdev by default would be 'win'
2020-07-24 07:14:16 <Ariadne> yes
2020-07-24 07:14:32 <Ariadne> we are going to have a udev/mdev listener and allow-hotplug support
2020-07-24 07:14:40 <Ariadne> code just needs to be written
2020-07-24 07:14:59 <ncopa> i have reconfigured armv7 and armhf builders to halt on errors now
2020-07-24 07:15:09 <mps> maybe with mdevd
2020-07-24 07:15:24 <Ariadne> i also
2020-07-24 07:15:37 <Ariadne> want to have it send events to openrc/systemd
2020-07-24 07:15:42 <Ariadne> so you can say
2020-07-24 07:15:48 <ncopa> sorry i havent been able to follow on the ifupdown-ng thing
2020-07-24 07:15:48 <Ariadne> start these services when eth0 is up
2020-07-24 07:15:56 <Ariadne> stop these services when eth0 is down
2020-07-24 07:16:37 <ncopa> so far the ifupdown-ng looks promising
2020-07-24 07:16:39 <Ariadne> though i am not sure how best to accomplish that
2020-07-24 07:21:43 <mps> also I'm not sure, didn't read exhaustively docs and didn't tested, but maybe run mdevd (as daemon) and disable /proc/sys/kernel/hotplug
2020-07-24 07:26:55 <Ariadne> point being that there is no point in having services up that depend on networking if only loopback is up in many cases
2020-07-24 07:27:23 <Ariadne> the dream is to start networking and related services in background so that you can get to a login prompt faster
2020-07-24 07:27:42 <Ariadne> but first we need to focus on core competencies
2020-07-24 07:27:47 <Ariadne> the fun stuff comes later
2020-07-24 07:29:08 <mps> agree
2020-07-24 07:29:19 <ikke> sqsh on armv7 has some undefined identifiers, wonder where that comes from
2020-07-24 07:30:57 <Ariadne> openrc has hotplig stuff that I think is relevant here
2020-07-24 07:31:21 <mps> ncopa: do you plan to upgrade linux-lts today? changelog doesn't look important for upgrade but some people asked on #alpine-linux
2020-07-24 07:31:31 <Ariadne> but we will need to redesign networking initscript
2020-07-24 07:33:39 <detha> what about setups where logging in depends on networking (e.g. LDAP auth)?
2020-07-24 07:36:45 <Ariadne> well in that case you don't start the services in background :p
2020-07-24 08:18:28 <ncopa> mps: i updated it yesterday i think?
2020-07-24 08:20:36 <ncopa> Ariadne: i have an (old) idea how to prevent having a network daemon listening all times
2020-07-24 08:20:48 <mps> ah, sorry, I missed to see it
2020-07-24 08:22:46 <ncopa> basically,  a netlink listener that spawns a handler, forward the netlink socket, and wait for it to die. the handler dies after 1 sec of timeout from netlink socket
2020-07-24 08:23:21 <ncopa> i think I even made a proof of concept at some point
2020-07-24 08:23:50 <mps> yes, using netlink is good idea
2020-07-24 08:24:28 <mps> also I thought of it, maybe combine somehow with inotify
2020-07-24 08:24:52 <ncopa> inotify monitors files/directories
2020-07-24 08:25:09 <ncopa> not sure what file/directories you want monitor
2020-07-24 08:25:21 <ikke> mps: Interesting point I read here: https://lwn.net/SubscriberLink/825536/7311170740a885ea/ 'The stable kernels are "way better tested" than the mainline because they are seeing actual real workloads, rather than "just developers trying it on their laptops"' ;-)
2020-07-24 08:27:42 <mps> ncopa: teack netlink to make some dirs/files in /proc or /sys and notify program to act on changes
2020-07-24 08:27:51 <mps> teach*
2020-07-24 08:28:26 <mps> 'teach', to be more clear
2020-07-24 08:28:51 <ikke> Isn't that a bit of a roundabout way to do things?
2020-07-24 08:30:05 <Ariadne> ncopa: that seems like a good architecture for event monitoring
2020-07-24 08:31:28 <mps> ikke: thanks for url, will read later
2020-07-24 08:32:21 <mps> but nowadays LTS and latest stable are nearly same in patches which are applied to them
2020-07-24 08:32:55 <Ariadne> anyways
2020-07-24 08:33:21 <Ariadne> next up I'm going to add a multicall frontend and unify ifquery and ifup/ifdown into a single binary
2020-07-24 08:35:33 <mps> ikke: though yes, LTS is more widely tested and don't have some new and sometimes 'not yet well' tested features and changes
2020-07-24 08:36:07 <ikke> In the end, loads of people do a lot of effort trying to prevent any regressions
2020-07-24 08:36:08 <mps> for example 5.8 show some instability and driver issues
2020-07-24 08:36:52 <mps> but someone have to test all this before it become LTS :)
2020-07-24 08:37:17 <ikke> yes
2020-07-24 08:37:45 <mps> and some needs new drivers (fixed/upgraded) or new features
2020-07-24 08:38:32 <mps> for example, I can run only 5.7 on mediatek/acer aarch64 chromebook to work
2020-07-24 08:39:08 <mps> or chromeos3.18 kernel, which is really outdated
2020-07-24 08:39:27 <mps> space before 3, :)
2020-07-24 08:52:21 <ikke> ncopa: we do have an issue with docker on armv7 due to the musl-1.2 upgrade (https://gitlab.alpinelinux.org/alpine/aports/-/issues/11774). The gist is that the seccomp profiles in docker need to be backported, or docker/seccomp fixed to not return EPERM for uknown syscalls
2020-07-24 08:52:22 <ncopa> Ariadne: i wonder if would make any sense to have support for dhcpcd, which also looks for new interfaces
2020-07-24 08:52:52 <Ariadne> yes, it is planned
2020-07-24 08:53:10 <Ariadne> dhcpcd is also a better dhcp client than udhcpc
2020-07-24 08:53:19 <Ariadne> i would like for us to eventually just move to that
2020-07-24 08:54:38 <ikke> We don't see it on x86 because vdso is masking it
2020-07-24 08:57:07 <ncopa> ikke: ok. so it should be enough to backport that upstream patch?
2020-07-24 08:57:18 <ikke> ncopa: I think so
2020-07-24 08:57:42 <ikke> I just copied the entire profile on our armv7 ci box and set that as the secomp profile, and that works
2020-07-24 08:59:46 <Cogitri> Fwiw dhcpcd can't seem to get an ipv4 for me since a few versions
2020-07-24 09:01:08 <ncopa> ikke: what version of docker? apk info docker
2020-07-24 09:01:16 <ncopa> patching file components/engine/profiles/seccomp/default.json
2020-07-24 09:01:16 <ncopa> Reversed (or previously applied) patch detected!  Assume -R? [n]
2020-07-24 09:02:51 <ncopa> ikke: is it alpine v3.12? looks like alpine edge if fixed already
2020-07-24 09:06:25 <Ariadne> converting ifupdown-ng to multicall knocks it down to 31KB
2020-07-24 09:06:36 <ikke> ncopa: docker-19.03.5-r0
2020-07-24 09:06:40 <Ariadne> can probably cut it down more
2020-07-24 09:07:05 <ikke> ncopa: that vm is currently on 3.11, but I wanted to upgrade it to 3.12
2020-07-24 09:12:06 <ikke> ncopa: it doesn't seem to be released yet?
2020-07-24 09:32:42 <ncopa> ikke: docker 19.03.12 seem to have the fix. can you test docker from edge?
2020-07-24 09:32:43 <ikke> can we disable sqsh for now? there are no dependencies apparently?
2020-07-24 09:33:00 <ncopa> let me have a quick look at it
2020-07-24 09:42:47 <mps> ikke: I read article, and that is what I actually wrote here and on #alpine-linux some time ago
2020-07-24 09:45:13 <mps> btw, thanks for allow me to read it, I'm not subscriber on lwn
2020-07-24 09:45:33 <ikke> mps: me neither, was posted on HN
2020-07-24 09:45:44 <mps> ah :)
2020-07-24 09:58:37 <ncopa> sqsh is fixed
2020-07-24 09:58:45 <ncopa> was unrelated musl 1.2
2020-07-24 09:59:09 <ikke> yeah, I figured it was not related
2020-07-24 10:01:51 <ncopa> sweet! all packages in main are now built
2020-07-24 10:02:14 <ikke> nice
2020-07-24 10:02:24 <ikke> euhm
2020-07-24 10:02:32 <ikke> perl-mail-dkim on x86 shows a failure?
2020-07-24 10:02:46 <ncopa> oh, x86
2020-07-24 10:06:56 <Cogitri> Good that it's progressing well :)
2020-07-24 10:07:08 <ikke> qt5-qtbase is failing now
2020-07-24 10:33:19 <ncopa> hum
2020-07-24 10:33:48 <ncopa> perl-mail-dkim fails due to the test domain authmilter.org seems to be gone
2020-07-24 10:35:28 <ikke> oh, fun
2020-07-24 10:49:51 <ncopa> i was wrong
2020-07-24 10:49:56 <ncopa> seems like it exists
2020-07-24 10:50:10 <ikke> I'm upgrading the armv7 ci vm atm
2020-07-24 10:50:21 <ncopa> 👍
2020-07-24 10:55:31 <ikke> ok, running 3.12.0 with linux-lts atm
2020-07-24 10:55:33 <ikke> nice
2020-07-24 10:57:03 <ncopa> awesome
2020-07-24 10:58:29 <ikke> Ok, looks like docker from edge fixes it
2020-07-24 10:58:41 <ikke> disabled the profile I added
2020-07-24 10:58:46 <ikke> oh, wait
2020-07-24 10:58:51 <ikke> forgot one ste
2020-07-24 10:58:53 <ikke> p
2020-07-24 10:59:25 <ikke> Ok, now the test is valid :)
2020-07-24 10:59:33 <ikke>     Verify return code: 0 (ok)
2020-07-24 10:59:45 <mps> ikke: did you added rtc driver
2020-07-24 11:00:04 <ikke> no, not yet
2020-07-24 11:00:25 <ikke> so no vdso
2020-07-24 11:00:37 <ikke> at least, not that I expect
2020-07-24 11:01:27 <mps> but armv7 kernel in -lts have vdso enabled
2020-07-24 11:01:45 <ikke> but according to dalias it's only used when an RTC is present?
2020-07-24 11:02:28 <mps> yes, that is why I asked did you added rtc driver module
2020-07-24 11:02:45 <ikke> [   24.692614] hctosys: unable to open rtc device (rtc0)
2020-07-24 11:02:57 <mps> maybe it is not needed now with fixed docker
2020-07-24 11:03:45 <ikke> yeah, according to ncopa, this version should include the seccomp profile updates that includes clock_gettime64
2020-07-24 11:03:49 <mps> but maybe there will some software which want to access /dev/rtc0 during tests
2020-07-24 11:05:02 <ikke> but if the host doesn't even have /dev/rtc0?
2020-07-24 11:05:57 <mps> enough is if host have time, NTP for example
2020-07-24 11:07:09 <ikke> I don't even see an NTP service :)
2020-07-24 11:07:42 <mps> but host have time interface through syscal
2020-07-24 11:08:31 <mps> I wonder that CIs works without NTP
2020-07-24 11:08:44 <ikke> Why wouldn't they?
2020-07-24 11:08:59 <mps> clock skew
2020-07-24 11:09:17 <ikke> sure, but how does that matter for CI?
2020-07-24 11:09:36 <mps> CI read time from host, iiuc
2020-07-24 11:10:06 <ikke> Right, but how much does it matter that time is synchronized? Ie, what part relies on the absolute time?
2020-07-24 11:10:29 <detha> https stuff
2020-07-24 11:10:45 <mps> there are some, but first you can have artifats built in future
2020-07-24 11:11:43 <mps> and what detha says
2020-07-24 11:12:33 <ikke> that only matters for expired certificates iirc (and from what I read)
2020-07-24 11:13:59 <detha> it's a common problem when installing things with no RTC; trying to download from https gives 'Certificate is not yet valid'
2020-07-24 11:14:01 <mps> no, if your time a long behind current https/tls will not work for most sites
2020-07-24 11:14:11 <ikke> yeah, but that's mostly when the time is way off
2020-07-24 11:14:20 <ikke> without an RTC, it will start at timestamp 0
2020-07-24 11:14:45 <mps> 1 januar 1970, usually :)
2020-07-24 11:14:51 <ikke> yes
2020-07-24 11:14:53 <ikke> timestamp 0
2020-07-24 11:15:12 <ikke> happens on RPIs for example without ntp
2020-07-24 11:15:46 <mps> I had few time this problem with boxes without rtc and with those without battery powered rtc
2020-07-24 11:16:08 <ikke> But I'm not sure whether the host doesn't have an RTC or it's not exposed for some reason
2020-07-24 11:16:43 <ikke> hwclock complains
2020-07-24 11:16:43 <mps> driver missing or not loaded?
2020-07-24 11:16:57 <ikke> possibly, just no clue what driver
2020-07-24 11:17:19 <mps> what is the host
2020-07-24 11:17:47 <ikke> some huawei server
2020-07-24 11:18:28 <mps> don't know what is rtc driver for them
2020-07-24 11:18:45 <ikke> should lshw show an RTC?
2020-07-24 11:18:51 <mps> maybe will look at kernel config
2020-07-24 11:19:18 <mps> I doubt lshw will but it is worth to try
2020-07-24 11:19:29 <ikke> I don't see anything
2020-07-24 11:19:53 <mps> hmm, expected
2020-07-24 11:20:29 <mps> rtc drivers are somewhat 'special things' for autodetect by kernel
2020-07-24 11:21:22 <mps> actually depends on hardware and kernel support
2020-07-24 11:22:41 <ikke> ncopa: do we want to backport those seccomp updates to 3.12?
2020-07-24 11:24:13 <ncopa> ikke: i think so
2020-07-24 11:24:22 <ikke> ok
2020-07-24 11:24:33 <ikke> Shouldn't have a big impact
2020-07-24 11:24:38 <ikke> from what I can tell anyway
2020-07-24 11:24:43 <ncopa> only update version
2020-07-24 11:24:48 <ikke> ok
2020-07-24 11:24:57 <ncopa> cherrypick
2020-07-24 11:25:12 <ncopa> perl-mail-dkim responded superquick
2020-07-24 11:25:17 <ncopa> and have a new release
2020-07-24 11:25:19 <ikke> it's an update from 19.03.11 to 19.03.12
2020-07-24 11:25:23 <ncopa> how great is that
2020-07-24 11:25:29 <ikke> ncopa: very nice
2020-07-24 11:25:45 <ikke> ncopa: we could as well just update docker instead of cherry-picking?
2020-07-24 11:31:00 <ncopa> sure, make sure that you also update the git hashes embed in there
2020-07-24 11:31:08 <ncopa> i think its simpler to cherrypick
2020-07-24 11:34:56 <ikke> ok
2020-07-24 11:37:54 <ncopa> you want me to do it?
2020-07-24 11:37:59 <ncopa> im done with perl-mail-dkim
2020-07-24 11:38:11 <ikke> Ok, feel free, I'm at work atm, so no time until later
2020-07-24 11:55:11 <radiomark> Hi, how can I deal with upstream version "numbers" like "1.2.3.test.5" in APKBUILD ? It fails sanity check
2020-07-24 11:59:17 <Cogitri> Make the pkgver 1.2.3_alpha5 and then change that via string manipulation to what you need in another variable (e.g. _pkgver=${pkgver/_alpha/.test./})
2020-07-24 12:00:03 <radiomark> Is that just to try and bypass sanity check, though?
2020-07-24 12:00:28 <radiomark> I presume there's a proepr way to handle versions which are not fully numeric, or is it strict to define an 'order'
2020-07-24 12:00:35 <ikke> that sanicheck is there because it guards what apk considers valid versions
2020-07-24 12:03:54 <ncopa> apk needs to know if 1.2.3.test.5 is newer or older than 1.2.3.beta.1
2020-07-24 12:04:44 <ncopa> the answer is that its impossible to know what upstream does, so the "test" part needs to be transformed to something apk understands
2020-07-24 12:05:09 <radiomark> I see, I suspected it might be that
2020-07-24 12:05:11 <ncopa> does it mean alpha? beta? releasecandidate? prerelease?
2020-07-24 12:05:22 <radiomark> I'm working with my own fork of upstream source code
2020-07-24 12:05:47 <radiomark> So I do have control over version number, but I also wondered about hte general case
2020-07-24 13:41:24 <wsinatra> thank you everyone for all of the hard work getting musl 1.2.0, and the subsequent CI/CD rebuilds going
2020-07-24 13:41:44 <wsinatra> lots of hard work, you guys are excellent :)
2020-07-24 13:42:56 <dalias> :)
2020-07-24 13:54:12 <ncopa> thanks :)
2020-07-24 13:58:58 <ncopa> looks like spamassasin build  hangs on x86
2020-07-24 14:09:30 <ncopa> no, tests are just slow
2020-07-24 14:09:59 <ncopa> and there seems to be some failing tests
2020-07-24 14:12:41 <radiomark> Can I ask for some guidance to adding a script to the initramfs? I want to expand the partition to the full device before LVM starts to use it
2020-07-24 14:13:07 <radiomark> I can see /etc/mkinitfs/features.d to add files to the initramfs, but not invoke them
2020-07-24 14:13:20 <ncopa> i think we need some sort of plugins to initramfs
2020-07-24 14:14:23 <radiomark> I just want to insert a very simple command at the right time: "echo ,+ | sfdisk ..."
2020-07-24 14:14:43 <radiomark> I am publishing a VM image that will boot up on VMs of various sizes
2020-07-24 14:16:23 <ncopa> im thinking that we should have some pre-mount-root, post-mount-root hooks
2020-07-24 14:16:58 <ncopa> maybe pre-coldplug too
2020-07-24 14:17:04 <radiomark> Can you point me to the actual script run in the in itramfs? I can't quite see where it originates from
2020-07-24 14:17:29 <radiomark> Or each 'feature' should be able to add script at these times
2020-07-24 14:17:46 <radiomark> So then I add my own feature for 'expand partition at boot time'
2020-07-24 14:17:46 <ncopa> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in
2020-07-24 14:18:09 <ncopa> i think your problem is slightly trickier than it sounds
2020-07-24 14:18:20 <ncopa> we have a C app nlplug-findfs
2020-07-24 14:18:53 <ncopa> which will trigger coldplug, load kernel modules, and wait for the event with the specific device it is looking for
2020-07-24 14:19:12 <ncopa> i think it will mount it too
2020-07-24 14:19:54 <ncopa> i think you need run the resize thing before mount of rootfs, but after the disk is coldplugged
2020-07-24 14:20:22 <radiomark> I've got sda1=/boot and sda2=LVM   ... then the root is on the LVM itself
2020-07-24 14:20:34 <radiomark> kernel can't re-read partition table if it's already in use
2020-07-24 14:20:45 <radiomark> Does that mean must be nothing mounted at all
2020-07-24 14:21:28 <ncopa> i think so
2020-07-24 14:21:52 <radiomark> And initramfs-init is the first thing initiated by the kernel?
2020-07-24 14:21:57 <radiomark> which then calls nlplug-findfs
2020-07-24 14:22:07 <ncopa> correct
2020-07-24 14:22:10 <radiomark> Because in my specific case, I can probably apply a patch to initramfs-init
2020-07-24 14:22:25 <ncopa> no. i think its trickier
2020-07-24 14:22:34 <ncopa> i think you need to hack nlplug-findfs
2020-07-24 14:23:09 <ncopa> nlplug-findfs will do the coldplug  by tryggering hotplugevents
2020-07-24 14:23:15 <radiomark> I must not understand the complication yet ... because I am assuming initramfs-init runs with a ramdisk mounted
2020-07-24 14:23:23 <radiomark> Ah you mean it simply doesn't have the device driver for /dev/sda
2020-07-24 14:23:28 <radiomark> or /dev/vda or /dev/xvda
2020-07-24 14:23:28 <ncopa> and read the hotplug events from netlink
2020-07-24 14:23:30 <ncopa> correct
2020-07-24 14:23:40 <ncopa> the hotplug will load the drivers
2020-07-24 14:23:49 <radiomark> And it all happens in nlplug-findfs
2020-07-24 14:23:50 <ncopa> and monitor the blockdevices that shows up
2020-07-24 14:23:55 <ncopa> yes
2020-07-24 14:24:27 <ncopa> when a new block device event shows up, which has an LVM partition, it will execute lvm
2020-07-24 14:25:28 <ncopa> what you need to do is execute a script that changes the partition after the blockdevice is detected, but before lvm is started
2020-07-24 14:25:40 <radiomark> Yup
2020-07-24 14:26:16 <ncopa> so, hum...
2020-07-24 14:26:38 <ncopa> what you need is a pre-lvm hook
2020-07-24 14:27:48 <ncopa> could be implemented in nlplug-findfs byt simply execute run-parts /etc/mkinitfs/pre-lvm.d
2020-07-24 14:28:06 <ncopa> then you add your script(s) there
2020-07-24 14:29:04 <ncopa> other thing you could do, that does not require modification of nlplug-findfs is to rename lvm and replace it with your own wrapper script
2020-07-24 14:29:13 <radiomark> Ha, yes
2020-07-24 14:29:18 <radiomark> Interesting thought
2020-07-24 14:29:24 <radiomark> I'm looking at these codes at the moment
2020-07-24 14:29:55 <ncopa> mv /sbin/lvm /sbin/lvm.orig
2020-07-24 14:30:34 <ncopa> echo -e "#!/bin/sh\ndo-the-thing\nexec /sbin/lvm.orig" > /sbin/lvm
2020-07-24 14:33:29 <ncopa> but i guess it makes sense to execute run-parts /etc/mkinitfs/initramfs-hooks/{pre,post}-{lvm,mdadm,cryptsetup,zpool}.d/
2020-07-24 14:34:41 <radiomark> Trouble is those sorts of pre/post script hooks just turn to spaghetti
2020-07-24 14:34:58 <radiomark> Then it feels like RedHat
2020-07-24 14:35:04 <ncopa> :)
2020-07-24 14:35:12 <radiomark> And you find the whole system is implemented in hooks, not actually first class features
2020-07-24 14:35:37 <radiomark> It's a shame that initramfs scripts become a "be everything to everyone" case
2020-07-24 14:36:22 <ncopa> but it allows users do things that is not explicitly supported like resize partitions before starting lvm
2020-07-24 14:36:32 <radiomark> Yes, of course
2020-07-24 14:37:04 <radiomark> In this case it might be worth considering if "running an sfdisk script" is a first class feature of the initramfs, in much the same way as the other features, rather than endless hooks
2020-07-24 14:37:31 <radiomark> But I am not sure either way
2020-07-24 14:37:54 <radiomark> Even with hooks, you still need to copy over the commands needed, so that gets messy
2020-07-24 14:38:23 <ncopa> so you'd want a boot flag for it?
2020-07-24 14:38:44 <ncopa> or should we always call sfdisk on all block devices that shows up?
2020-07-24 14:39:26 <ncopa> what is the exact usecase?
2020-07-24 14:39:36 <radiomark> I've built a base image for all our VMs
2020-07-24 14:39:42 <radiomark> They get deployed to various providers and/or hardware
2020-07-24 14:40:04 <radiomark> Image is < 8G, but we need to use space. The providers give 24G or more
2020-07-24 14:40:37 <radiomark> So I need to enlarge the actual partition, then pvresize, then finally allocate the space
2020-07-24 14:40:53 <radiomark> Everything can be done dynamically except resizing the actual partitin, as the kernel won't re-read a partition table once in use
2020-07-24 14:41:57 <radiomark> There is a workaround, which is on boot we 'force' enlarge the partition, then reboot.
2020-07-24 14:42:03 <radiomark> But that involves a second reboot
2020-07-24 14:42:44 <ncopa> how is the partition resized?
2020-07-24 14:43:09 <radiomark> It's MBR partition table, so "echo ,+ | sfdisk --partno 2 /dev/sda"
2020-07-24 14:43:24 <radiomark> Modifies existing partition, set size to maximum
2020-07-24 14:43:56 <dne> partprobe/partx doesn't work?
2020-07-24 14:44:08 <radiomark> There's added complication, which is some VM providers use /dev/sda, others use /dev/vda, and Xen uses /dev/xvda       ... Right now Alpine handles that all dynamically as LVM finds its own partition and boot is LABEL=boot
2020-07-24 14:44:33 <radiomark> No, neither of those can re-read a partition table if devices are already in use ... unless I missing something
2020-07-24 14:52:27 <ncopa> so, i dont think we always want to resize every lvm partition
2020-07-24 14:52:49 <ncopa> how should you specify that you want resize the lvm parition?
2020-07-24 14:53:01 <ncopa> do need to do the same with mdadm partitions?
2020-07-24 14:53:46 <radiomark> There is no mdadm partition; that is RAID? In a VM we would nto be exposed to that.
2020-07-24 14:53:58 <ncopa> ok
2020-07-24 14:54:03 <ncopa> fair enough
2020-07-24 14:54:10 <radiomark> it is quite a specific functionality
2020-07-24 14:54:14 <radiomark> I appreciate that
2020-07-24 14:54:25 <ncopa> what about zfs pools?
2020-07-24 14:54:36 <radiomark> Also we have created our own Alpine Linux install with custom partition table, so it may not correspond to what would be automatic
2020-07-24 14:54:42 <radiomark> No ZFS here
2020-07-24 14:54:55 <radiomark> But yes, a more general case this has a lot of questions
2020-07-24 14:55:10 <ncopa> im thinking of adding general case support
2020-07-24 14:55:22 <ncopa> would probably also need a way to create such images
2020-07-24 14:55:46 <ncopa> so i can test the functionality
2020-07-24 14:55:57 <radiomark> Yeah we bypassed the entire alpine installer for our own script. It's not complicated, but there are somme bits copied from the actual setup-* scriptrs
2020-07-24 14:56:06 <radiomark> So we build our own LVM and partition layout
2020-07-24 14:56:46 <ncopa> im kind of interested in the feature
2020-07-24 14:57:01 <radiomark> Well I imagine VM images is an increasingly common case
2020-07-24 14:57:06 <ncopa> i think it could make sense to provide some boot image for that
2020-07-24 14:57:10 <ncopa> exactly
2020-07-24 14:57:12 <radiomark> It's not something I am very experienced with, so this is my first steps
2020-07-24 14:57:23 <radiomark> In automating quite a lot of infrastructure
2020-07-24 14:57:37 <radiomark> And I'm a developer so it seems the beenfit is full automation
2020-07-24 14:57:54 <radiomark> Otherwise I have to give someone a list that says "image the machine, now run it, now reboot it, etc."
2020-07-24 14:58:13 <ncopa> how would you tell initramfs that we want increase the size of the found lvm members?
2020-07-24 14:58:31 <ncopa> i agree that rebooting it sucks
2020-07-24 14:58:39 <ncopa> and we should be able to do better than that
2020-07-24 14:58:49 <radiomark> Firstly, it _could_ just do "pvresize" indescrimanately all the time; though that sounds a bit messy
2020-07-24 14:59:05 <radiomark> But secondly, that's not too big a deal -- as it can be done durning runtime when the extra space is required
2020-07-24 14:59:17 <radiomark> That's why the actual resize of the partition is special; it's the only thing we can't do with the system mounted
2020-07-24 15:00:21 <ncopa> i mean, we would probably want a boot option for it
2020-07-24 15:00:31 <ncopa> which you add at first boot
2020-07-24 15:00:54 <ncopa> but not in subsequent bootups
2020-07-24 15:01:21 <radiomark> Ah that's interesting; a "first boot"
2020-07-24 15:01:33 <radiomark> Though it's worth considering that its easy in a VM provider to increase your risk space, and reboot
2020-07-24 15:02:12 <ncopa> we have got requests for kexec, to speedup reboot
2020-07-24 15:02:33 <ncopa> i think it would be nice to avoid reboot :)
2020-07-24 15:02:37 <radiomark> I don't really understand people who need to speed up reboot :o) Especially when Alpine is sooo fast
2020-07-24 15:02:49 <radiomark> Reboot is about getting to a known nstate, not cutting corners IMO
2020-07-24 15:02:52 <radiomark> *state
2020-07-24 15:03:54 <ncopa> i need to work on other stuff now. can you please create an issue on our gitlab?
2020-07-24 15:04:08 <radiomark> Just a request issue for discussion?
2020-07-24 15:04:12 <radiomark> I can when I find a moment
2020-07-24 15:04:17 <ncopa> feature request
2020-07-24 15:04:30 <radiomark> I'm not pushing hard for this feature ... I can see the complications that come
2020-07-24 15:04:39 <radiomark> for the hooks, or the partition resize?
2020-07-24 15:04:50 <ncopa> what i wonder is how initramfs should know if it should resize the parition or not
2020-07-24 15:04:58 <ncopa> the specific feature
2020-07-24 15:05:08 <radiomark> Cool, it can be worked back toa  general one if needs be
2020-07-24 15:05:49 <ncopa> one option is to run hook, which is removed after first boot and initramfs image regenerated without the hook
2020-07-24 15:06:01 <ncopa> other option woudl be to specify it as a boot option
2020-07-24 15:06:10 <ncopa> "resize-rootfs" or similar
2020-07-24 15:06:17 <radiomark> Not sure about that; I think better to consider an idempotent process that just makes partitions as big as possible within some spec
2020-07-24 15:06:38 <radiomark> Though I do appreciate the risks of that on hardware etc.
2020-07-24 15:06:57 <ncopa> would still need to provide a way to disable it
2020-07-24 15:07:06 <radiomark> Oh yes, it should not be anywhere near a 'normal' install
2020-07-24 15:07:20 <ncopa> but i'd rather have it disabled by default, and enabled when needed
2020-07-24 15:07:55 <ikke> like an initramfs feature
2020-07-24 15:08:15 <ncopa> and i think we need to support it with or without lvm
2020-07-24 15:09:07 <ncopa> challenge with lvm is that we dont know what the device node is sda2, vda2, xvda3
2020-07-24 15:09:27 <ncopa> we cannot lock it to second partition always either
2020-07-24 15:09:42 <ncopa> and we need make it work with uefi
2020-07-24 15:10:06 <radiomark> There could be some logic in saying "resize the last partitino on the disk"
2020-07-24 15:10:18 <ncopa> no
2020-07-24 15:10:53 <ncopa> how do you know that it is the last partition? the uevents may not come in order
2020-07-24 15:11:07 <ncopa> when sda shows up, there are no sda1
2020-07-24 15:11:14 <ncopa> that comes as a separate uevent
2020-07-24 15:11:22 <ncopa> then sda2 may or may not show up
2020-07-24 15:11:27 <ncopa> but you never know
2020-07-24 15:11:29 <radiomark> Ah, ok I don't know about such hotplug things. But what I do know is you can't resize earlier partitions on the disk ;)
2020-07-24 15:12:26 <ncopa> so what im thinking is: if resize-lvm-rootfs option is set, whenever ther shows up an lvm member, try resize it
2020-07-24 15:12:57 <ncopa> if its not the last parition, the resize will fail i suppose
2020-07-24 15:13:01 <ncopa> so ignore errors
2020-07-24 15:13:19 <ncopa> hopefully there are only a single lvm member
2020-07-24 15:18:21 <ncopa> spamassasin testsuite fails on x86
2020-07-24 15:18:28 <ncopa> and its horribly slow
2020-07-24 15:30:39 <ncopa> community repo is 72% done
2020-07-24 15:31:06 <ikke> not bad
2020-07-24 15:31:42 <ncopa> moving forward
2020-07-24 15:32:09 <ncopa> i expect that lots of the packages missing was due to missing qt5-qtbase
2020-07-24 15:46:43 <radiomark> ncopa: should I file this issue under mkinitfs, or some other part of gitlab?
2020-07-24 15:46:54 <ncopa> i think im gonna enable the ignore errors so x86 can upload the things it built so far
2020-07-24 15:46:59 <ncopa> radiomark: i guess mkinitfs
2020-07-24 15:47:06 <ncopa> there is where we need to implement it
2020-07-24 15:47:57 <ikke> s390x builder / CI is currently under maintenance
2020-07-24 15:48:12 <ncopa> ok
2020-07-24 15:49:47 <Hello71> radiomark: you can change any partitions as long as they don't overlap with partitions in use
2020-07-24 15:50:19 <Hello71> sometimes commands like fdisk, partprobe, etc will report failure if *any* partitions are in use, even if those didn't change
2020-07-24 15:53:37 <MY-R> hmm, I noticed something like that when used Alpine iso, running for example fdisk, I created partitions etc, save and quit then I see them in /dev/sda1 sda2 etc
2020-07-24 15:54:30 <MY-R> and after that if run cfdisk then it shows disk is empty, quit and all sda1 sda2 disappeared
2020-07-24 15:56:47 <Hello71> is your disk read only
2020-07-24 15:58:02 <MY-R> no, is just when using two different tools
2020-07-24 15:59:24 <MY-R> was same if I start from creating partitions by cfdisk, save quit and all is fine until run after simple fdisk -l, then it showing nothing and again sda1 sda2 gone
2020-07-24 16:02:55 <radiomark> ncopa: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues/6
2020-07-24 16:03:14 <radiomark> ncopa: Hopefully that is in the right place, my gitlab skills are pretty minimal. Had to work out how to quote the IRC conversation
2020-07-24 16:04:06 <ncopa> Hello71: so basically, it is not needed to do it in initramfs
2020-07-24 16:04:36 <ncopa> i think what Hello71 says makes sense. I havent tested it though
2020-07-24 16:05:05 <radiomark> I did try it but it didn't work, even if I did --force on sfdisk
2020-07-24 16:05:19 <radiomark> You can also see sfdisk read back the partition table that's in use, I think
2020-07-24 16:05:41 <radiomark> When I did the pvresize, nothing happened as it saw the PV already matchd the partition
2020-07-24 16:06:10 <Hello71> I don't think sfdisk cares about the kernel interpretation of the partitions
2020-07-24 16:06:35 <ncopa> sfdisk is a "safer" tool, isnt it?
2020-07-24 16:06:43 <Hello71> script
2020-07-24 16:06:54 <ncopa> maybe its possible to resize it with parted
2020-07-24 16:07:32 <radiomark> Is the kernel the problem here, though? That it knows about the size of block devices
2020-07-24 16:07:44 <radiomark> And it won't update that size if it is open
2020-07-24 16:07:56 <Hello71> if fdisk doesn't show your changes then you're doing the changes wrong
2020-07-24 16:07:59 <Hello71> not the reading
2020-07-24 16:09:13 <radiomark> I'd have to check, this is from memory, but I think sfdisk tries to be helpful and say "I did what you ask for, now here's what the kernel thinks of this partition table"
2020-07-24 16:09:22 <Hello71> uh... what?
2020-07-24 16:09:38 <radiomark> Because it was interesting that it showed 8G before, 8G after ... but then a reboot and it showed 24G.. However this is from memory, I would want to double check
2020-07-24 16:09:55 <radiomark> But I did think I exhausted all avenues of doing it with the system mounted
2020-07-24 16:13:18 <ncopa> im testing with a loopback device
2020-07-24 16:13:37 <ncopa> creating paritions on /dev/loop0
2020-07-24 16:13:57 <ncopa> fdisk said
2020-07-24 16:13:58 <ncopa> Re-reading the partition table failed.: Invalid argument
2020-07-24 16:13:58 <ncopa> The partition table has been altered.
2020-07-24 16:13:58 <ncopa> Calling ioctl() to re-read partition table.
2020-07-24 16:13:58 <ncopa> The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or partx(8).
2020-07-24 16:14:19 <ncopa> partprobe didnt make any difference
2020-07-24 16:14:34 <radiomark> This sounds like my experience. I'm sure I come across this case eevery 5 years for the past 25 years
2020-07-24 16:15:36 <ncopa> hum
2020-07-24 16:15:49 <ncopa> you know what did work
2020-07-24 16:16:02 <ncopa> echo add > /sys/block/loop0/uevent
2020-07-24 16:16:28 <ncopa> now it shows up in /proc/partitions
2020-07-24 16:17:07 <ncopa> and in /sys/block/loop0/loop0p1
2020-07-24 16:17:39 <ncopa> let me try resize it
2020-07-24 16:18:43 <ncopa> Calling ioctl() to re-read partition table.
2020-07-24 16:18:44 <ncopa> Re-reading the partition table failed.: Invalid argument
2020-07-24 16:18:44 <ncopa> The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or partx(8).
2020-07-24 16:18:50 <ncopa> thats what sfdisk reports
2020-07-24 16:19:50 <ncopa> fdisk reports that size has increased
2020-07-24 16:20:09 <ncopa> but it does not show in /sys/block/loop0/loop0p1/size
2020-07-24 16:20:38 <ncopa> running partprobe
2020-07-24 16:20:48 <ncopa> $ cat /sys/block/loop0/loop0p1/size
2020-07-24 16:20:48 <ncopa> 18432
2020-07-24 16:20:50 <ncopa> boom!
2020-07-24 16:20:56 <ncopa> looks like Hello71 is right
2020-07-24 16:21:47 <Hello71> you can strace fdisk. afaik there is no "reread partitions" interface. what it actually does is delete all the existing kernel partitions and then create new kernel partitions
2020-07-24 16:21:58 <Hello71> skipping any failures
2020-07-24 16:22:27 <Hello71> so in practice the effect is that everything non overlapping is changed, everything overlapping remains the same, but you get an error as long as *anything* is in use
2020-07-24 16:22:59 <Hello71> even if you didn't change that part. because delete/create cycle is not "optimized" to ignore unchanged parts
2020-07-24 16:23:43 <ncopa> so its not possible to detect a real failure, like trying to change overlapping partitions
2020-07-24 16:26:06 <ncopa> let me create an lvm on top
2020-07-24 16:41:01 <ncopa> radiomark: looks like partprobe solves it
2020-07-24 16:43:06 <radiomark> Hmm, I did try that
2020-07-24 16:43:24 <radiomark> I will need to revisit
2020-07-24 16:43:43 <radiomark> and give a more definitive report
2020-07-24 16:44:01 <ncopa> pvresize seems to work, but how do i extend the vg?
2020-07-24 16:45:04 <ikke> shouldn't the vg be automatically resized when the PVs are grown?
2020-07-24 16:45:09 <ncopa> it doesnt
2020-07-24 16:45:16 <ncopa> but apparently vgscan fixes that
2020-07-24 16:47:55 <ncopa> yup
2020-07-24 16:48:02 <ncopa> everything works. no reboots needed
2020-07-24 16:48:06 <radiomark> Hmmm
2020-07-24 16:48:11 <radiomark> This is with a loopback?
2020-07-24 16:48:17 <ncopa> yes
2020-07-24 16:48:32 <ncopa> losetup -f test.img
2020-07-24 16:48:36 <ncopa> 100MB image
2020-07-24 16:48:59 <ncopa> i created a 50MB sized partition
2020-07-24 16:49:14 <ncopa> added it to lvm with ext4 and mounted it
2020-07-24 16:49:36 <ncopa> extended the partition with: echo ,+ | sfdisk --partno 1 /dev/loop0
2020-07-24 16:49:50 <radiomark> I'm booting a VM now
2020-07-24 16:50:07 <ncopa> partprobe will make the new size visible, even if fsdisk gives you error
2020-07-24 16:50:46 <radiomark> Did you have to use sfdisk --force?
2020-07-24 16:50:51 <ncopa> no
2020-07-24 16:50:56 <radiomark> Ah, ok
2020-07-24 16:50:57 <ncopa> i just ignored the error
2020-07-24 16:51:05 <ncopa> and ran partprobe
2020-07-24 16:51:14 <radiomark> Ok so your disk isn't technically "in use" like mine is
2020-07-24 16:51:20 <radiomark> Mine won't get past the first step without a --force
2020-07-24 16:51:34 <radiomark> I also have /boot mounted: /dev/vda1 on /boot type ext4 (rw,relatime)
2020-07-24 16:51:39 <ncopa> well, the blockdevice was mounted
2020-07-24 16:52:01 <radiomark> Hmm, we're getting very different behaviour then
2020-07-24 16:52:09 <radiomark> Let me pastepin, hold on
2020-07-24 16:53:23 <ncopa> one nasty thing that did happen in my first test wat that old test.img was used with loop back device
2020-07-24 16:53:39 <ncopa> which was only 10MB
2020-07-24 16:53:46 <radiomark> https://pastebin.com/Ny41PKDe
2020-07-24 16:53:53 <ncopa> i needed to partprobe after losetup -d
2020-07-24 16:54:30 <ncopa> whatas the output of /proc/partitions?
2020-07-24 16:55:00 <radiomark> https://pastebin.com/HZHh7YAz
2020-07-24 16:55:16 <ncopa> ok
2020-07-24 16:55:17 <radiomark> Looks like still the small size
2020-07-24 16:55:27 <ncopa> it may be you need --force
2020-07-24 16:55:36 <ncopa> i think i didnt have any open files on the filesystem
2020-07-24 16:55:41 <radiomark> on which command?
2020-07-24 16:55:45 <ncopa> sfdisk
2020-07-24 16:55:56 <radiomark> I did that -- you can see I had to do it to bypass the first check
2020-07-24 16:56:44 <radiomark> So sfdisk prints the new partition table but the kernel doesn't ack it
2020-07-24 16:57:57 <ncopa> yes, its not re-read
2020-07-24 16:58:11 <ncopa> what does /sys/block/vda/vda2/size say?
2020-07-24 16:58:15 <radiomark> But sounds like you're getting different behavior on a loopback
2020-07-24 16:58:34 <radiomark> localhost:~# cat /sys/block/vda/vda2/size
2020-07-24 16:58:34 <radiomark> 15202304
2020-07-24 16:58:51 <ncopa> which is 7.5GB i guess
2020-07-24 16:59:04 <ncopa> and with partprobe /dev/vda?
2020-07-24 16:59:20 <radiomark> partprobe: /dev/vda: Resource busy
2020-07-24 17:00:25 <ncopa> yup
2020-07-24 17:00:44 <ncopa> i dont think it makes any difference if its loopback or not
2020-07-24 17:00:56 <ncopa> but i guess it makes difference if there are open files or something
2020-07-24 17:02:15 <ncopa> maybe try partx?
2020-07-24 17:02:35 <ncopa> its in util-linux
2020-07-24 17:02:56 <radiomark> partx reports the new size, but /proc/partitions doesn't
2020-07-24 17:03:42 <ncopa> partx -v -a /dev/vda
2020-07-24 17:04:00 <radiomark> localhost:~# partx  -v -a /dev/vda
2020-07-24 17:04:00 <radiomark> range recount: max partno=2, lower=0, upper=0
2020-07-24 17:04:00 <radiomark> partx: /dev/vda: adding partition #2 failed: Resource busy
2020-07-24 17:04:00 <radiomark> partition: none, disk: /dev/vda, lower: 0, upper: 0
2020-07-24 17:04:00 <radiomark> partx: /dev/vda: adding partition #1 failed: Resource busy
2020-07-24 17:04:00 <radiomark> partx: /dev/vda: error adding partitions 1-2
2020-07-24 17:04:38 <radiomark> This behavior is what I would expect from prevoius experience, I'm suprised it worked on loopback. Though I do vaguely recall loopback having some flexibility I did not expect
2020-07-24 17:04:47 <radiomark> I'm trying to dig out knowledge that's years old now, though
2020-07-24 17:04:47 <ncopa> check size in /sys/block/vda/vda2/size
2020-07-24 17:05:06 <radiomark> That same 8G-ish size
2020-07-24 17:05:11 <radiomark> presumably in 512 byte blocks
2020-07-24 17:05:15 <ncopa> yeah
2020-07-24 17:05:17 <ncopa> :-/
2020-07-24 17:07:17 <ncopa> i guess its safest to resize it before mounting it anyway
2020-07-24 17:07:29 <ncopa> one more thing i'd like to test
2020-07-24 17:07:43 <ncopa> what happens if you remount all mounts as ro
2020-07-24 17:07:47 <ncopa> and then do partprobe
2020-07-24 17:07:58 <ncopa> or partx
2020-07-24 17:11:29 <ncopa> ok, its weekend. have a nice weekend everyone
2020-07-24 17:12:12 <mps> \o
2020-07-24 18:19:17 <radiomark> ncopa: thank for help today; enjoy your weekend
2020-07-25 00:57:51 <timlegge> !10590 if anyone has time to review - fixes an issue #11753
2020-07-25 11:34:21 <kaey_> ffmpeg is missing on armhf edge, but log says it built fine https://build.alpinelinux.org/buildlogs/build-edge-armhf/community/ffmpeg/ffmpeg-4.3.1-r0.log
2020-07-25 12:05:31 <Ariadne> time64
2020-07-25 12:06:41 <ikke> All packages have to be rebuilt
2020-07-25 12:23:02 <Ariadne> can we perhaps delete the old build logs
2020-07-25 12:23:37 <Ariadne> WARNING: Ignoring /home/buildozer/packages/comunity/armhf/APKINDEX.tar.gz: No such file or directory
2020-07-25 12:23:39 <Ariadne> ohh uhh
2020-07-25 12:23:44 <Ariadne> can we fix that too
2020-07-25 12:38:17 <ikke> huh
2020-07-25 12:38:42 <ikke> -rw-r--r--    1 buildoze buildoze    732731 Jul 25 09:30 /home/buildozer/packages/community/armhf/APKINDEX.tar.gz
2020-07-25 12:38:47 <Ariadne> no
2020-07-25 12:38:50 <Ariadne> look closely
2020-07-25 12:38:52 <Ariadne> comunity
2020-07-25 12:38:59 <Ariadne> instead of community
2020-07-25 12:39:31 <ikke> heh
2020-07-25 12:39:47 <ikke> fixed
2020-07-25 12:39:55 <Ariadne> that should fix arnhf
2020-07-25 12:40:03 <Ariadne> can you check the other builders
2020-07-25 12:41:50 <ikke> armv7 doesn't even have community
2020-07-25 12:44:16 <Ariadne> ok
2020-07-25 12:44:54 <Ariadne> I suspect this solves a lot of problems
2020-07-25 13:48:02 <Ariadne> Cogitri: need some help with gjs when you have time
2020-07-25 14:02:16 <Cogitri> Sure, how can I help?
2020-07-25 14:02:46 <Ariadne> it fails to build due to some glib stuff :p
2020-07-25 14:04:59 <Cogitri> Ah, seems to me like it fails tests?
2020-07-25 14:16:20 <Ariadne> yes
2020-07-25 14:22:27 <Cogitri> I'll look into it
2020-07-25 14:23:25 <Ariadne> 
ACTION goes back to running musl against coverity

2020-07-26 11:25:11 <mps> we made a mistake with haproxy for 3.12, version 2.1.x is not LTS and its EOL 2021-Q1. we should be more careful about pkgs in main and not rush to upgrade
2020-07-26 11:26:41 <mps> we have two options now, forward port 2.0.x which EOL is 2024-Q2
2020-07-26 11:27:26 <mps> or backport 2.2.x (which is LTS also) with EOL 2025-Q2
2020-07-26 11:28:49 <mps> my vote is for backporting, especially because this new version have better support for musl and I'm ready to do that, i.e. make backport and test
2020-07-26 11:33:13 <mps> ncopa: ^ what's your opinion? you are maintainer
2020-07-26 11:35:04 <mps> (anyway I will backport it for my servers)
2020-07-26 11:51:02 <Cogitri> Ariadne: I'll open an issue upstream about the GJS failures and disable the tests in the meantime to unblock the builders
2020-07-26 11:55:39 <Cogitri> Huh, actually, seems like they fail on 64-bit too 🤔
2020-07-26 13:59:19 <nmeum> any suggestion on handling man-page conflicts (other than removing the man page from one of the packages)? e.g. editline-doc and readline-doc both provide editline.3.gz thus if you have the docs meta package installed you can't install both editline and readline
2020-07-26 14:01:10 <Ariadne> well i think in that case we should just get rid of gnu readline
2020-07-26 14:01:49 <nmeum> get rid of the man page in the readline package you mean?
2020-07-26 14:02:11 <nmeum> oh, misread the error message actually the conflict is caused by libedit-doc and editline-doc
2020-07-26 14:02:20 <ikke> s/editline/readline in readline pkg?
2020-07-26 14:02:23 <nmeum> > ERROR: editline-doc-1.17.1-r0: trying to overwrite usr/share/man/man3/editline.3.gz owned by libedit-doc-20191231.3.1-r0.
2020-07-26 14:02:42 <Ariadne> no i mean get rid of readline entirely :P
2020-07-26 14:02:49 <ikke> Didn't we try that already?
2020-07-26 14:03:10 <ikke> We had a readline alternative, but some packages broke due to that
2020-07-26 14:04:26 <Ariadne> afaik we have not, we have only migrated some packages to editline
2020-07-26 14:04:40 <Ariadne> editline and readline provide the same APIs, but some packages may need some patching
2020-07-26 14:04:50 <Ariadne> probably a pain point for post-3.13
2020-07-26 14:05:05 <Ariadne> also remove gnu gettext in favor of gettext-tiny
2020-07-26 14:05:06 <nmeum> the apis are not entirely compatible though
2020-07-26 14:05:09 <Cogitri> Yup, I guess musl 1.2 and GCC10 are enough work for now :)
2020-07-26 14:05:25 <Ariadne> and ifupdown
2020-07-26 14:05:34 <Ariadne> nmeum: yes, hince patching
2020-07-26 14:05:39 <Cogitri> Ariadne: About gjs: Seems like it fails on 64-bit too, so I'm not entirely sure why it started to fail now
2020-07-26 14:05:47 <nmeum> also: personally found quite a few bugs in libedit in the past (the code base is also quite horrible)
2020-07-26 14:05:55 <Ariadne> bummer
2020-07-26 14:06:04 <Ariadne> guess i'll add that to the list of things to rewrite
2020-07-26 14:06:40 <nmeum> the best line editing library i could fine so far is linenoise
2020-07-26 14:06:46 <nmeum> but that's not compatible with the readline api
2020-07-26 14:09:53 <Ariadne> could write a wrapper
2020-07-26 14:11:31 <nmeum> yeah, maybe
2020-07-26 20:29:59 <ikke> acccheck fails because curl cannot verify the certificate
2020-07-27 06:02:51 <ncopa> morning
2020-07-27 06:04:15 <ncopa> mps: looks like we had a comment in haproxy that said we should stick to LTS which was removed in f8c1d041503312cdf93078ee694087c0ea6d81e6, right before the 2.1 upgrade. So it seems to be intentional?
2020-07-27 06:07:19 <mps> yes, I remember this and discussion about that, also we have this git comment (if you remember discussion) 07a3d4a7f0e3bed7d1123a2897774ec4d35293de
2020-07-27 06:08:05 <mps> and, good morning, ofc :)
2020-07-27 06:08:16 <ncopa> :)
2020-07-27 06:08:30 <ncopa> so problem was that the next LTS release came after the 3.12 release
2020-07-27 06:08:42 <mps> yes
2020-07-27 06:09:21 <mps> we should follow their announces of releases and not rush to upgrade
2020-07-27 06:09:40 <mps> like we do for kernel and some other pkgs
2020-07-27 06:09:45 <ncopa> makes sense
2020-07-27 06:09:56 <ncopa> maybe also add a comment that we should only use LTS releases
2020-07-27 06:10:06 <mps> that sounds good
2020-07-27 06:10:17 <ncopa> mps: i think i makes sense that you take over maintainership for haproxy
2020-07-27 06:10:37 <mps> for example I added such comment for sysstat last week
2020-07-27 06:11:18 <ncopa> i also think i would be best if we can update 3.12-stable to haproxy 2.2. then only thing I worry about is if it is a smooth upgrade
2020-07-27 06:11:30 <ncopa> or if users needs to change their configs or do anything manually to upgrade
2020-07-27 06:11:43 <ncopa> ie if it is backwards compatible
2020-07-27 06:12:04 <mps> as I told, I will upgrade first for my servers and test it
2020-07-27 06:12:19 <ncopa> if you are sure that upgrading from 2.1 to 2.2 will not break anything for anyone, then I prefer to upgrade to 2.2
2020-07-27 06:12:54 <mps> well, I'm not sure (and I can't be) but will test it first
2020-07-27 06:14:01 <mps> if it goes ok for me, I will check config diff and try to find potential issues
2020-07-27 06:14:51 <mps> but from the head, I didn't noticed much changes in config options
2020-07-27 06:16:26 <mps> (didn't had time to set 3.12 builder because had to reorganize my data on disk archives this weekend)
2020-07-27 06:30:33 <ncopa> stunnel test suite hangs
2020-07-27 06:30:48 <ncopa> on all arches
2020-07-27 06:31:08 <ncopa> well, at least on all I have tested, x86, x86_64 armv7
2020-07-27 06:36:36 <Cogitri> Could someone disable gjs tests for me for now? They fail on all arches so I don't think they're musl 1.2 related (not quite sure why they started to fail though), I'll look into fixing them later today but we can unblock the builders for now :)
2020-07-27 06:44:20 <mps> Cogitri: hm, I can, what should be commit msg
2020-07-27 06:50:16 <mps> 'options="!check" # fails on all arches, temp disable on maintainer request' ?
2020-07-27 06:52:48 <mps> Cogitri: done
2020-07-27 07:00:46 <Cogitri> Thanks :)
2020-07-27 07:01:36 <mps> np :)
2020-07-27 07:13:51 <maxice8> @PureTryOut ping
2020-07-27 07:14:59 <Ariadne> ncopa: do you have any objection to relicensing and including bridge, bonding, tunnel etc scripts with ifupdown-ng
2020-07-27 07:46:48 <ikke> Hmm, CVE-2020-13777 for gnutls seems quite bad (already patched in Alpine). Passive decryption of most traffic
2020-07-27 07:47:22 <ikke> https://anarc.at/blog/2020-06-10-gnutls-audit/
2020-07-27 07:48:21 <Cogitri> > That is extremely bad. It's pretty close to just switching everyone to HTTP instead of HTTPS, more or less.
2020-07-27 07:48:23 <Cogitri> oof
2020-07-27 07:50:44 <Cogitri> Ah, but its only a problem if GnuTLS is used as server and not as client
2020-07-27 07:50:59 <ikke> Yes, indeed
2020-07-27 07:51:28 <mps> and mutt is on the list, sure it is not server
2020-07-27 07:51:53 <ikke> They just listed everything linking against gnutls on Ubuntu Buster (or later)
2020-07-27 07:52:00 <ikke> s/Ubuntu/Debian/
2020-07-27 07:52:00 <alpine-meetbot> ikke meant to say: They just listed everything linking against gnutls on Debian Buster (or later)
2020-07-27 07:52:36 <mps> 'ap revdep gnutls'
2020-07-27 07:52:48 <ikke> gnutls-dev
2020-07-27 07:53:23 <ikke> I just looked here: https://pkgs.alpinelinux.org/package/edge/main/x86_64/gnutls
2020-07-27 07:53:25 <mps> yes, I see
2020-07-27 07:53:32 <ikke> under required by
2020-07-27 07:54:11 <mps> samba is on the list by 'revdep'
2020-07-27 07:54:20 <ikke> yes
2020-07-27 07:57:33 <Ariadne> anyways I have several installs now running on ifupdown-ng
2020-07-27 07:58:12 <mps> I like to repeat old Steve Bellowins saying from nineties 'Security complex, isn't it'
2020-07-27 08:11:27 <ncopa> Ariadne: what license do you want? MIT or ISC or similar?
2020-07-27 08:11:38 <Ariadne> ISC yeah
2020-07-27 08:12:00 <ncopa> ok with me
2020-07-27 08:16:52 <ikke> Any idea where this error might come from? https://gitlab.alpinelinux.org/alpine/infra/docker/gitlab-runner-helper/-/jobs/172097 "Error relocating /usr/bin/git-lfs: __nanosleep_time64: symbol not found"
2020-07-27 08:16:57 <ikke> I can't seem to reproduce it
2020-07-27 08:17:23 <Ariadne> running musl 1.2 binary on musl 1.1
2020-07-27 08:17:37 <Ariadne> :)
2020-07-27 08:18:25 <ikke> hmm
2020-07-27 08:18:48 <ncopa> my guess is that git-lfs was build with musl 1.1
2020-07-27 08:19:51 <ikke> I tried to reproduce it in docker, but it just installs fine
2020-07-27 08:21:08 <ikke> hmm, I think I need to use the correct base image
2020-07-27 08:22:04 <ikke> yes,
2020-07-27 08:22:13 <ikke> arm32v7/alpine:edge reproduces it :)
2020-07-27 08:23:29 <ncopa> i suppose the fix is to rebuild git-lfs
2020-07-27 08:24:08 <ikke> no
2020-07-27 08:24:14 <ikke> to make sure musl-1.2 is installed
2020-07-27 08:24:34 <ikke> alpine:edge still has musl-1.1
2020-07-27 08:24:37 <ncopa> aha
2020-07-27 08:25:19 <Ariadne> tbh it would be nice if musl printed a nice error for situations where a binary needs a newer musl
2020-07-27 08:25:20 <ikke> I keep forgetting that running alpine:edge on aarch64 does not get you a armv7 container :)
2020-07-27 08:25:26 <Ariadne> like glibc does
2020-07-27 08:26:39 <ikke> Hmm, I *do* wonder why we didn't install an armv7 OS for the armv7 ci runner
2020-07-27 08:26:50 <ikke> maybe because it's simpler to run aarch64
2020-07-27 08:29:30 <kytart> Hi people, can anybody point me in the right direction how armhf and armv7 apks are built? I have aarch64 machine on AWS and I ran armhf and armv7 Alpine docker containers there. It should work right since those are a subset of aarch64. It works for most cases but now I'm trying to build my own copy of quite a big chunk of the Alpine repo and when building pixman, I get an error "meson.build:517:7: ERROR: Can not run test applications in this
2020-07-27 08:29:30 <kytart>  cross environment."
2020-07-27 08:30:20 <ikke> We build on LXC
2020-07-27 08:30:28 <ikke> Which should be similar
2020-07-27 08:31:37 <kytart> I don't know that. How is that different?
2020-07-27 08:32:28 <ikke> how are you running armv7 / armhf containers on aarch64?
2020-07-27 08:32:54 <ikke> for our CI, I had to make sure it was armv7 as well
2020-07-27 08:33:03 <ikke> which is based on docker
2020-07-27 08:34:14 <kytart> With a bit of hacking. I used their experimental buildx command for cross building for other platforms and I just built armhf container (there it's called armv6 or whatever) and ran it on aarch64. When it has no other choice, it just runs whatever you give it
2020-07-27 08:34:40 <ikke> We use buildkit
2020-07-27 08:35:18 <ikke> iirc
2020-07-27 08:36:14 <kytart> buildkit for what?
2020-07-27 08:36:23 <kytart> for your images for CI?
2020-07-27 08:36:25 <ncopa> kytart: im not sure if it is related but you need run linux32 or the container will still have a 64 bit personality
2020-07-27 08:37:59 <kytart> @ncopa you mean a linux32 kernel? I figured as much. My problem is that Docker uses host's kernel, so I'll have to look into LXC. But I've never seen it so don't know much about it.
2020-07-27 08:39:57 <mps> kytart: linux32 cmd, not kernel
2020-07-27 08:40:13 <mps> 'linux32 -h'
2020-07-27 08:42:48 <kytart> ooh, I didn't know about this, thanks! I'll try it out. Looks promising
2020-07-27 08:47:15 <ncopa> i think ash in busybox 1.32 is buggy
2020-07-27 08:47:36 <ncopa> makes stunnel test suite deadlock
2020-07-27 08:47:53 <Cogitri> Oof
2020-07-27 08:48:01 <ikke> kytart: to build 32-bits images on 64-bits host
2020-07-27 08:48:09 <ikke> it's required to be able to specify --platform
2020-07-27 08:49:15 <ikke> https://gitlab.alpinelinux.org/alpine/infra/gitlab-ci-templates/-/blob/master/docker-image.yml#L41
2020-07-27 08:52:45 <kr0k0_2> Cogitri: I have updated !10652
2020-07-27 08:53:17 <kr0k0_2> But I have another question. Do you know why there are no ffmpeg and mpv packages for 32 bit archs?
2020-07-27 08:53:54 <afontain_> because the musl-1.2 rebuild is not finished?
2020-07-27 08:55:00 <ikke> kytart: https://gitlab.alpinelinux.org/alpine/infra/gitlab-ci-templates/-/blob/master/docker-image.yml#L4
2020-07-27 08:55:28 <kr0k0_2> afontain_: Ok, thanks!
2020-07-27 08:58:48 <kytart> yeah, I'm already building the docker images this way. @ikke yeah, that's pretty much what I'm doing but I guess my information is outdated. The --platform thing was experimental until recently but I guess not anymore https://docs.docker.com/buildx/working-with-buildx/
2020-07-27 09:11:39 <ikke> Instead of buildx, we just use regular docker with the buildkit
2020-07-27 09:12:07 <ikke> It's a bit simpler that way
2020-07-27 09:12:38 <ikke> You don't need to create builder instances
2020-07-27 09:17:46 <Cogitri> https://build.alpinelinux.org/buildlogs/build-edge-x86/community/gnome-session/gnome-session-3.36.0-r3.log I think there's a circular dep but I don't see where
2020-07-27 09:18:48 <ikke> always fun tracking those
2020-07-27 09:22:31 <ikke> Cogitri: ap recursdeps gnome-shell indeed returns gnome-session
2020-07-27 09:25:48 <Cogitri> Hm 🤔
2020-07-27 09:27:54 <ikke> you basically need to recursively iterate each dependency of gnome-shell untill you find what pulls in gnome-session
2020-07-27 10:12:32 <ncopa> i have bisected the busybox ash issue
2020-07-27 10:12:39 <ikke> nice
2020-07-27 10:12:41 <ncopa> and reported upstream to mailing list
2020-07-27 10:12:57 <Cogitri> 🎉
2020-07-27 10:12:57 <ncopa> not sure what the proper fix is though
2020-07-27 10:13:24 <Cogitri> ikke: Thanks, I'll try that
2020-07-27 10:14:52 <ikke> I think it should be possible to script that
2020-07-27 10:18:02 <Cogitri> That'd be nice
2020-07-27 10:19:04 <Cogitri> Another thing: texlive and texmf-dist have file conflicts after updating texlive (sorry for doing a bad merge), should the conflicting files be removed from texlive or texmf-dist?
2020-07-27 10:19:23 <Cogitri> Already upgraded texmf-dist to the latest version but they still conflict :c
2020-07-27 10:19:56 <ikke> is one a dependency of the other?
2020-07-27 10:26:09 <Cogitri> Yup, I think texlive pulls in texmf-dist
2020-07-27 10:26:41 <ikke> Then I guess you could remove them from texlive
2020-07-27 10:35:31 <ikke> not sure if the content is significantly different though
2020-07-27 11:13:40 <Cogitri> Asked the maintainer, let's see what they think
2020-07-27 11:13:50 <Cogitri> 
ACTION sent a long message:  < https://matrix.exqa.de/_matrix/media/r0/download/matrix.exqa.de/jAdNoFBpfiaXqZElZhmoILVu >

2020-07-27 11:14:11 <ikke> You ned to run it in the correct directory
2020-07-27 11:14:19 <ikke> it's kind of picky about that
2020-07-27 11:14:25 <Cogitri> Ah, in community?
2020-07-27 11:14:30 <ikke> yes
2020-07-27 11:14:34 <Cogitri> Ah, okie
2020-07-27 11:53:36 <Cogitri> Hmmmm, it circles in gnome-session->gnome-shell->gdm->gnome-session
2020-07-27 11:54:04 <Cogitri> But I don't see why gnome-shell pulls in gdm, it's in checkdepends but I disabled check ages ago to avoid that circular dep
2020-07-27 11:54:28 <ikke> if it's still in checkdepends it is still a dependency
2020-07-27 11:54:39 <ikke> abuild does not check whether checks are enabled or not
2020-07-27 11:56:34 <Cogitri> Oh :D
2020-07-27 11:56:48 <Cogitri> I thought checkdepends are only pulled in if checks are enabled
2020-07-27 11:56:58 <Cogitri> How did this ever work :o
2020-07-27 11:57:49 <ikke> hmm
2020-07-27 11:57:54 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2156
2020-07-27 11:58:04 <ikke> It should work like that
2020-07-27 11:58:17 <ikke> but I guess ap doesn't do that
2020-07-27 11:58:32 <ikke> I think the issue is with ap, not abuild
2020-07-27 11:59:01 <Cogitri> Hm, okie. Then I don't get how we have a circular dep on the builders then though
2020-07-27 11:59:12 <ikke> the builders use ap :)
2020-07-27 11:59:23 <ikke> through buildrepo
2020-07-27 11:59:44 <Cogitri> Oh
2020-07-27 11:59:56 <Cogitri> I'll just remove gdm for now then :)
2020-07-27 12:00:06 <Cogitri> From the checkdepends
2020-07-27 12:00:10 <ikke> nod
2020-07-27 12:01:48 <ikke> I guess this should be conditional: https://github.com/alpinelinux/lua-aports/blob/master/aports/pkg.lua#L112
2020-07-27 12:03:32 <Cogitri> #11781 sounds pretty bad
2020-07-27 12:03:55 <ikke> Cogitri: ncopa already noticed it
2020-07-27 12:04:12 <ikke> Cogitri: He thought that fakeroot was maybe broken during bootstrap
2020-07-27 12:05:01 <Cogitri> Yup, commented that on the issue
2020-07-27 12:06:41 <ncopa> i will try check it later today, or tomorrow
2020-07-27 12:10:19 <Cogitri> 👍
2020-07-27 17:07:45 <ikke> Cogitri: libpeas tests is failing, but not
2020-07-27 17:07:48 <ikke> ugh
2020-07-27 17:08:00 <ikke> libpeas tests are failing, but not just on 32-bits arches
2020-07-27 17:08:13 <ikke> Is it maybe related to gobject-inspection?
2020-07-27 17:08:23 <ikke> Typelib file for namespace 'Introspection', version '1.0' not found (g-irepository-error-quark, 0)
2020-07-27 17:14:06 <Cogitri> Ah, I'd probably need the testlog.txt
2020-07-27 17:14:22 <Cogitri> 
ACTION wishes he already switched everything over to meson test -v so we had proper logs

2020-07-27 17:16:21 <ikke> I have it
2020-07-27 17:19:00 <ikke> https://tpaste.us/admo
2020-07-27 17:20:31 <Cogitri> Seems to fail locally as well, so that's good
2020-07-27 17:20:51 <ikke> yeah, I got that from running it my contaier
2020-07-27 17:20:55 <ikke> container
2020-07-27 17:22:58 <ikke> on x86, there are also syntax errors, but did not get those locally
2020-07-27 18:37:58 <ikke> hmm, curious. After running apk upgrade -U in a docker container (during image build), I cannot install packages anymore with apk, fetching packages results in permission denied with some kind of tls error
2020-07-27 18:38:13 <ikke> 4153058652:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1913:
2020-07-27 18:38:22 <ikke> but only when I use buildkit (DOCKER_BUILDKIT=1)
2020-07-27 18:41:14 <ikke> before running apk upgrade, I can still install packages
2020-07-27 18:42:08 <opal> https://wiki.alpinelinux.org/wiki/Privacy_Policy#Copyright
2020-07-27 18:42:13 <opal> thats a disgusting copyright for the wiki
2020-07-27 18:42:35 <ikke> hmm
2020-07-27 19:41:42 <tobikoch> opal: what's disgusting about it beside it stating the obvious?
2020-07-27 20:33:07 <Terror> Hi team, when/how does an aport move from testing to stable/community ?
2020-07-27 20:33:45 <Cogitri> When someone moves it to community via a merge request
2020-07-27 20:34:01 <Cogitri> the package needs to work, be in OK shape and have a maintainer for that
2020-07-27 20:35:33 <Terror> That sounds easy, is there any timing requirements (like it has to be in testing for 1 release or something like that)?
2020-07-27 20:36:25 <ikke> no
2020-07-27 20:37:00 <ikke> A package can be moved from testing to community rather quickly
2020-07-27 20:43:11 <Ariadne> testing just means the packaging is work in progress
2020-07-27 20:43:26 <ikke> Not necessarily
2020-07-27 20:43:43 <Ariadne> for the intent of this conversation that is close enough
2020-07-27 20:44:23 <ikke> are these kinds of messages normal? objcopy: /home/build/aports/main/git/pkg/git/usr/libexec/git-core/stOhcJAa: debuglink section already exists
2020-07-27 20:44:40 <Ariadne> yes
2020-07-27 20:44:43 <Ariadne> i would say so
2020-07-27 20:44:49 <ikke> ok
2020-07-27 20:50:30 <Cogitri> Btw Ariadne: Are there still plans for alpine conf?
2020-07-27 20:50:46 <Ariadne> yeah but we probably going to push back until like
2020-07-27 20:50:48 <Ariadne> october
2020-07-27 20:50:56 <Ariadne> people got busy
2020-07-27 20:51:06 <Cogitri> Okie
2020-07-27 21:14:23 <Terror> That's good to know, I'll move all my packages to community then, they are mature tools so there's not much "testing" to do. Thanks Ariadne, Cogitri & ikke
2020-07-27 21:22:35 <mps> packages in community and main have to be maintained in all meanings of this word
2020-07-27 21:39:12 <Cogitri> Seems like Debian has the same libpeas failure: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965278
2020-07-27 21:39:27 <Cogitri> Oh, and the same GJS failure!
2020-07-27 21:41:17 <Cogitri> Might be related to a meson upgrade, let's see
2020-07-27 21:46:39 <opal> tobikoch whats the point of the wiki being all rights reserved
2020-07-27 21:47:54 <opal> also if the authors retain all rights then what the hell gives alpine any right to republish on their behalf
2020-07-27 21:47:57 <opal> makes no sense
2020-07-27 21:58:30 <Cogitri> Downgraded meson to 0.54.3 and now gjs&libpeas work
2020-07-27 22:00:18 <mps> looks like makefiles are best :)
2020-07-27 22:00:37 <Cogitri> Heh :D
2020-07-27 22:00:50 <Cogitri> Meson regressions are rather annoying, yes
2020-07-27 22:01:03 <Cogitri> But so is writing makefiles, soooo :D
2020-07-27 22:01:16 <Cogitri> Anyway, time to sleep for me 👋
2020-07-27 22:01:30 <mps> also for me, good night :)
2020-07-28 04:31:43 <ikke> Cogitri: nice find
2020-07-28 05:47:04 <Cogitri> Let's see if I can figure out how to post something to that debian bugtracker :D
2020-07-28 06:07:40 <mps> Cogitri: debian have this nice tool called reportbug
2020-07-28 06:08:58 <mps> would be nice if we have something similar (doesn't need to be featurefull)
2020-07-28 07:41:17 <ollieparanoid[m]> hi all!
2020-07-28 07:41:24 <ollieparanoid[m]> I'd like to help with resolving failures on build-edge-armhf and -armv7
2020-07-28 07:42:05 <ollieparanoid[m]> build-edge-armhf is stuck on acccheck, because the tls cert is broken. how to deal with that? I guess somebody could download the archive to alpine mirrors and then update the URL? the checksum of the file should still be the same
2020-07-28 07:43:46 <ikke> I can put it on distfiles, then it should not even be necessary to update the url
2020-07-28 07:43:52 <ikke> if this issue is temporary
2020-07-28 07:44:03 <mps> we need to upgrade firefox-esr for 3.12
2020-07-28 07:44:31 <ollieparanoid[m]> ikke: this would be great. I can try to contact the admins of that page to make them aware of this
2020-07-28 07:44:40 <mps> do we need to backport rust/cargo or not
2020-07-28 07:46:11 <mps> uh, lets try without upgrading them
2020-07-28 07:47:00 <Cogitri> Should work without upgrading Rust
2020-07-28 07:47:37 <mps> Cogitri: thanks, I'm firing up local builder to test
2020-07-28 07:48:21 <mps> btw, FF 79 is released, if you didn't see that already
2020-07-28 07:52:13 <Cogitri> Ah no, misses that
2020-07-28 07:52:20 <Cogitri> s/es/ed/
2020-07-28 07:52:20 <alpine-meetbot> Cogitri meant to say: Ah no, missed that
2020-07-28 07:53:29 <ollieparanoid[m]> ikke: wrote a mail to the admins of that page. if you can put it in distfiles for now and restart the build, it would be great
2020-07-28 07:57:56 <ikke> done
2020-07-28 07:58:04 <ollieparanoid[m]> thx
2020-07-28 07:59:47 <obarun> Hi. Alpine dev have any plan to implement systemd on near (or not so near) future?
2020-07-28 07:59:58 <ikke> no
2020-07-28 08:00:05 <ikke> systemd doesn't work with musl
2020-07-28 08:00:11 <Cogitri> Not really, if only for systemd upstream not willing to work with musl
2020-07-28 08:00:58 <obarun> and if systemd change their policies and try to make the compilation with musl working?
2020-07-28 08:01:14 <ikke> obarun: there would probably be a lot of opposition
2020-07-28 08:01:22 <obarun> great
2020-07-28 08:01:28 <Cogitri> I'd say we'd need a discussion on the ML if that were to happen
2020-07-28 08:01:32 <obarun> wonderful new
2020-07-28 08:01:55 <obarun> i'm the creator of 66 by the way
2020-07-28 08:02:21 <Cogitri> But I doubt that they would adopt musl support, systemd upstream was pretty clear about them wanting glibc bug compat
2020-07-28 08:02:26 <ikke> the fact that alpinelinux doesn't use systemd attrackted a lot of systemd opposers
2020-07-28 08:02:58 <ikke> obarun: 66?
2020-07-28 08:03:02 <Cogitri> Although I personally kinda like some systemd things, e.g. that new automatic cgroups stuff is so fancy :D
2020-07-28 08:03:21 <Cogitri> ikke: a frontend thingie on top of s6-rc to make it somewhat ergonomic to use
2020-07-28 08:03:31 <ikke> aha
2020-07-28 08:04:35 <Cogitri> I personally haven't used yet, but s6-rc is pretty nice once it's setup (but also sure is a pain to use)
2020-07-28 08:05:16 <obarun> i did a POC on alpine. Quite easy to implement
2020-07-28 08:05:41 <obarun> s6/s6-rc is really a great suite of software for the init and service management
2020-07-28 08:06:04 <obarun> but can be difficult to implement, so 66 : https://framagit.org/obarun/66
2020-07-28 08:06:44 <obarun> currently my distro (Obarun) is under Arch but really i would like to switch to another one
2020-07-28 08:07:57 <mps> Cogitri: only if you want me leave alpine :)
2020-07-28 08:08:35 <Cogitri> mps: No worries, I didn't propose adopting systemd
2020-07-28 08:08:59 <Cogitri> But I think saying that systemd is all bad is unfair, it does have some really nice features
2020-07-28 08:09:34 <Cogitri> It'd be amazing if we could have that cgroup integration stuff or proper service management for user sessions
2020-07-28 08:09:45 <mps> I don't want to say it is bad or good, only I don't want to have it on my machines
2020-07-28 08:09:57 <Cogitri> Which is fair :)
2020-07-28 08:10:59 <Cogitri> I guess I'll have to see if I can implement something like systemd-user's DBus API without reimplementing half of systemd :D
2020-07-28 08:11:02 <mps> maybe you remember that I was told that I was early adopter and proponent of systemd, but time told me how I was wrong
2020-07-28 08:11:33 <Cogitri> Yup, systemd sure has rough edges
2020-07-28 08:12:31 <mps> as everything has them
2020-07-28 08:12:35 <Cogitri> But it'd be nice if we could use the good parts of systemd (like we already do with logind)
2020-07-28 08:13:13 <mps> but I chose alpine and one reason was 'no systemd'
2020-07-28 08:15:03 <mps> Cogitri: back to work, do you think it is good idea just to copy all patches from FF to FF-esr, they both are 78 version
2020-07-28 08:15:26 <mps> I mean, for backport to stable
2020-07-28 08:16:21 <Cogitri> I think that's what we did for ff-esr in edge too, didn't we?
2020-07-28 08:16:40 <mps> didn't looked, thanks for info
2020-07-28 08:16:43 <Cogitri> Also, do we have to upgrade stable to 78-esr? Was 68-esr dropped by mozilla?
2020-07-28 08:17:06 <mps> yes, current -esr is 78.0.2
2020-07-28 08:17:27 <mps> 68.x is EOL for about few weeks
2020-07-28 08:19:35 <Cogitri> Oof
2020-07-28 08:20:20 <Cogitri> Keep in mind that ff >=78 _needs_ nss >= 3.54 or TLS will be really broken
2020-07-28 08:23:20 <mps> Oooof, really
2020-07-28 08:23:47 <mps> that means backport nss also
2020-07-28 08:24:17 <mps> no, in stable nss is already 3.54
2020-07-28 08:24:23 <Cogitri> I think we already backported that
2020-07-28 08:24:30 <mps> yes, nice
2020-07-28 08:24:45 <Cogitri> Yes, just make sure to include nss>=3.54 as dependency so everyone is upgraded
2020-07-28 08:25:05 <mps> ofc, thanks
2020-07-28 08:25:31 <mps> but I have to go for breakfast and coffee now
2020-07-28 08:29:28 <ikke> coffee sounds like a good plan :)
2020-07-28 08:47:50 <ncopa> morning
2020-07-28 08:48:09 <ikke> morning
2020-07-28 08:48:11 <ncopa> i agree that coffe is a good idea!
2020-07-28 08:49:34 <[[sroracle]]> [03:17] <mps> 68.x is EOL for about few weeks
2020-07-28 08:49:37 <Cogitri> Morning 👋
2020-07-28 08:49:38 <[[sroracle]]> this is not true
2020-07-28 08:50:00 <[[sroracle]]> 68.12 will be the final 68 release, currently scheduled for august 25
2020-07-28 08:51:32 <Cogitri> That'll still be before 3.12's community repo is unsupported though, so I think we'll have to upgrade anyway
2020-07-28 08:51:56 <[[sroracle]]> sure, i don't really care about that. i just wanted to correct the record
2020-07-28 08:53:28 <Cogitri> 👍
2020-07-28 08:57:09 <ikke> ncopa: btw, I still notice some issues with docker + buildkit related to the musl-1.2 upgrade
2020-07-28 08:57:11 <ikke> on armv7
2020-07-28 08:57:54 <ikke> But I have a hard time figuring out what is going wrong. For now I've worked around it by not using buildkit on armv7
2020-07-28 09:11:43 <ncopa> ok
2020-07-28 09:11:53 <ncopa> ikke: did you rebuild util-linux on armv7?
2020-07-28 09:12:26 <ikke> ncopa: No, I did not
2020-07-28 09:12:43 <ikke> The issue is a TLS issue with apk after upgrade btw
2020-07-28 09:13:44 <ncopa> this fixed util-linux i guess 2908d66973fcc06a88a18377f210dbc8dca7a828
2020-07-28 09:15:00 <ikke> 4158821724:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1913:
2020-07-28 09:16:58 <ncopa> it fails to verify cert chain
2020-07-28 09:17:09 <ncopa>     i = ssl_verify_cert_chain(s, sk);
2020-07-28 09:17:31 <ncopa> is there some way i can inspect the certificate?
2020-07-28 09:17:50 <ikke> hmm
2020-07-28 09:21:12 <ikke> ncopa: https://tpaste.us/yZ0x
2020-07-28 09:21:22 <ikke> note that this only happens when I build with DOCKER_BUILDKIT=1
2020-07-28 09:21:29 <ikke> If I don't do that, everything is fine
2020-07-28 09:31:44 <ncopa> so its the cert from https://dl-cdn.alpinelinux.org ?
2020-07-28 09:31:54 <ikke> yes
2020-07-28 09:32:08 <ikke> I have a feeling it's a similar issue as we had before
2020-07-28 09:32:18 <ikke> ie, seccomp returning EPRM instead of ENOSYS
2020-07-28 09:32:33 <ikke> but I cannot run strace in that context, so no way to confirm iirc
2020-07-28 09:33:44 <ikke> I tried btw using containerd and runc from edge, but that did not fix it
2020-07-28 09:48:57 <ollieparanoid[m]> ncopa: good morning!
2020-07-28 09:49:10 <ollieparanoid[m]> would it be possible to let build-edge-armhf, armv7 continue building with the next packages after failure for some time, so that their currently built community packages get uploaded?
2020-07-28 09:49:23 <ollieparanoid[m]> I'm seeing that a lot of packages have been built already, but not been uploaded
2020-07-28 09:49:42 <ikke> ollieparanoid[m]: That would also make it hard to see what packages need to be fixed
2020-07-28 09:49:43 <ollieparanoid[m]> a lot of packages from postmarketOS edge depend on those, and are currently stuck -- so if we had them, we could be done much faster with rebuilding our packages against current alpine edge
2020-07-28 09:50:28 <ollieparanoid[m]> ikke: even if we did it for one hour or so (idk how long it takes), until the currently built community packages are uploaded, and then switch it back to not continue building on error?
2020-07-28 09:50:42 <ikke> It takes longer than 1h to build the remaining packages
2020-07-28 09:51:09 <ollieparanoid[m]> would it make sense to do this over night then?
2020-07-28 09:51:23 <ikke> possibly
2020-07-28 09:51:41 <ikke> I haven't seen armv7 in a while btw
2020-07-28 09:51:43 <ollieparanoid[m]> I'd highly appreciate it :)
2020-07-28 09:51:53 <ikke> Oh, I see it there
2020-07-28 09:51:58 <ikke> py3-google-api-core
2020-07-28 09:52:35 <Cogitri> Fails in tests, I think it can't find its own modules?
2020-07-28 09:52:43 <Cogitri> Not sure with python
2020-07-28 09:53:16 <ikke> they seem to be building php7 now, so may take a while
2020-07-28 09:56:37 <ikke> hmm, circular dependency with ruby-enum and ruby-i18n?
2020-07-28 09:56:41 <mps> [[sroracle]]: thanks for clarification and correcting me
2020-07-28 09:57:37 <mps> anyway we have to prepare 78 for 3.12
2020-07-28 09:59:21 <Cogitri> ikke: Was kooking at that too, but ap recursdeps doesn't list ruby-enum has recursdep of ruby-i18n AFAICS
2020-07-28 10:08:40 <ikke> Cogitri: I don't see it either, and ap builddirs lists ruby-i18n before ruby-enum
2020-07-28 10:11:13 <Ariadne> i agree with ollieparanoid[m] btw
2020-07-28 10:11:18 <Ariadne> we need to do another run with errors disabled
2020-07-28 10:11:27 <Ariadne> because of the repo issue
2020-07-28 10:13:56 <ncopa> makes sense
2020-07-28 10:14:08 <ncopa> im struggeling with libzip
2020-07-28 10:14:26 <ncopa> i get error
2020-07-28 10:14:27 <ncopa> (145/156) Installing libzip (1.7.3-r0)
2020-07-28 10:14:27 <ncopa> ERROR: libzip-1.7.3-r0: BAD signature
2020-07-28 10:14:34 <ncopa> that is on x86
2020-07-28 10:14:42 <ncopa> i get error on apk fetch libzip too
2020-07-28 10:14:52 <ncopa> it does not help to purge the cache entry
2020-07-28 10:14:52 <Ariadne> maybe we rebuild libzip
2020-07-28 10:15:13 <ncopa> i can manually fetch it and untar it
2020-07-28 10:16:42 <ncopa> Ariadne: what do you think about berkley db upgrade to version 18: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10666
2020-07-28 10:16:47 <ncopa> i thikn the license is a problem
2020-07-28 10:21:10 <ncopa> i have restarted build-edge-armv7 to make it continue on error
2020-07-28 10:21:43 <Ariadne> ncopa: i responded.  i think the best path forward is to replace it with a shim
2020-07-28 10:22:08 <Ariadne> and to be clear
2020-07-28 10:22:16 <Ariadne> oracle clearly made bdb agpl to be dicks
2020-07-28 10:22:30 <Ariadne> what other explanation is there :)
2020-07-28 10:22:59 <ncopa> i think we have some other packages using agpl
2020-07-28 10:23:43 <Ariadne> yes, but not libraries
2020-07-28 10:23:50 <ncopa> *nod*
2020-07-28 10:23:56 <Ariadne> the problem isn't agpl itself, but agpl being used for a library
2020-07-28 10:24:06 <ikke> Right, makes sense
2020-07-28 10:24:07 <Ariadne> which, that was not the intent of the agpl authors :)
2020-07-28 10:24:54 <ncopa> i guess we could add an db18 package or similar, but dont have any other package linking to it (unless it also is agpl)
2020-07-28 10:24:55 <mps> problem is 'ap revdep db-dev | tpaste' => https://tpaste.us/YpOP
2020-07-28 10:25:37 <ncopa> there are a handful packages in community too
2020-07-28 10:25:51 <mps> maybe some of them can be built with something else instead of db
2020-07-28 10:26:17 <ikke> What's the difference between gpl and agpl for libraries?
2020-07-28 10:26:22 <mps> actually, I planed to look at these pkgs one by one when I found time
2020-07-28 10:26:31 <ikke> As there is also LGPL
2020-07-28 10:27:20 <mps> license in not only problem with db, it is in bad shape anyway
2020-07-28 10:28:31 <Ariadne> ikke: agpl means if you have a network service linking against libdb you have to give over the source code to anyone who interacts with that
2020-07-28 10:30:17 <Cogitri> What's up with aports-turbo failing on x86?
2020-07-28 10:30:18 <mps> IANAL, but then agpl is not problem for alpine, iiuc
2020-07-28 10:33:05 <Ariadne> mps: it is a problem for users
2020-07-28 10:34:15 <Ariadne> anyway lets just nuke db
2020-07-28 10:34:23 <Ariadne> most software supports lmdb now
2020-07-28 10:34:25 <mps> Ariadne: sorry but why? (don't understand quite these licenses insanity)
2020-07-28 10:34:56 <mps> yes, I thought that lmdb could be used in most cases instead of db
2020-07-28 10:35:19 <Ariadne> mps: debian-legal has a long-winded explanation of why its a problem
2020-07-28 10:35:39 <mps> ok, thnaks, I belive you
2020-07-28 10:36:06 <Ariadne> anyway, rpm can use lmdb i know
2020-07-28 10:36:11 <mps> 
ACTION don't want to dive in this water :)

2020-07-28 10:36:31 <Ariadne> also keep in mind agpl infects the entire dpeendency graph
2020-07-28 10:36:44 <Ariadne> so ap revdep doesn't give whole picture for legal
2020-07-28 10:37:32 <ikke> Ariadne: but the same counts for gpl(v3), except the networking part, correct?
2020-07-28 10:37:54 <Ariadne> yes, gpl for libraries is bad too, but the "cost" is not as bad
2020-07-28 10:51:08 <mps> in postfix Berkeley DB database is listed as optional, http://www.postfix.org/INSTALL.html section 4.5 - Building with optional features
2020-07-28 10:51:34 <Ariadne> postfix deprecated db for lmdb
2020-07-28 10:53:54 <mps> but need changes to not use db.h
2020-07-28 11:00:37 <Ariadne> lets postpone this db malarkey for after 3.13
2020-07-28 11:00:51 <Ariadne> that way we can figure out how best to attack it
2020-07-28 11:00:54 <ikke> People asking for upgrades due to CVE's
2020-07-28 11:01:07 <ikke> +are
2020-07-28 11:01:21 <Ariadne> ok, tell them to write to oracle and request that they stop being cunts
2020-07-28 11:01:29 <ikke> Though, it's unclear in what matter those CVE's apply
2020-07-28 11:01:43 <mps> well, if we can drop bdb from some pkgs why not
2020-07-28 11:02:12 <Ariadne> ikke: i see no patches for CVEs in fedora or debian, who are also still on 5.3
2020-07-28 11:02:15 <mps> deps from some pkgs*
2020-07-28 11:02:26 <Ariadne> postfix will break config
2020-07-28 11:02:27 <ikke> Ariadne: maybe for similar reasons?
2020-07-28 11:02:37 <ikke> Ariadne: according the ncopa it's inclear what patches fix what
2020-07-28 11:02:50 <Ariadne> ikke: yes, we're damned if we do, damned if we don't.  basically the winning move is to just nuke it from orbit entirely
2020-07-28 11:03:02 <Ariadne> but that will take time
2020-07-28 11:03:04 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11757#note_104750
2020-07-28 11:03:06 <Ariadne> so our response should be
2020-07-28 11:03:12 <Ariadne> bdb is deprecated
2020-07-28 11:03:26 <Ariadne> we can't upgrade it because oracle has changed the license to something that is not acceptable
2020-07-28 11:03:37 <ikke> That's what ncopa is replying
2020-07-28 11:03:39 <Ariadne> we are working to remove bdb from alpine in its entirety
2020-07-28 11:03:58 <mps> we have to change that and if we start soon we will finish it sooner
2020-07-28 11:04:16 <Ariadne> mps: yes, but we can't do postfix in 3.13
2020-07-28 11:04:26 <Ariadne> because removing db support means the config will break
2020-07-28 11:04:35 <Ariadne> because lmdb does not provide :hash: and :btree: types
2020-07-28 11:04:36 <mps> why not, 3.13 is not released yet
2020-07-28 11:04:51 <ikke> mps: Ariadne says we need to deprecated it first
2020-07-28 11:04:53 <Ariadne> because people will complain upon upgrading to 3.13
2020-07-28 11:05:28 <ikke> so 3.13 deprecate, 3.14 remove
2020-07-28 11:05:29 <mps> sure pwople will complain for 3.13 or for 3.14 or whatever release
2020-07-28 11:06:02 <Ariadne> people will complain more if they aren't warned
2020-07-28 11:06:14 <Ariadne> deprecation is about managing expectations
2020-07-28 11:06:16 <ikke> Ariadne: should we add this to the 3.13 proposed release notes?
2020-07-28 11:06:23 <Ariadne> yes, i think so
2020-07-28 11:06:26 <ikke> and giving people time to respond
2020-07-28 11:07:05 <ikke> Apparently we don't have those yet
2020-07-28 11:07:36 <mps> question is, could we fix bdb for 3.13
2020-07-28 11:07:55 <Ariadne> sure, if we knew what to fix
2020-07-28 11:07:59 <ikke> upgrading is not an option, and backporting seems non-trivial
2020-07-28 11:08:07 <ikke> The code is completely different
2020-07-28 11:08:26 <Ariadne> well if the code is completely different
2020-07-28 11:08:32 <Ariadne> then the cve may or may not exist
2020-07-28 11:08:53 <ikke> exactly
2020-07-28 11:08:56 <Ariadne> anyway i warned about this ticking bomb like 4 years ago
2020-07-28 11:08:58 <ikke> but it's unclear
2020-07-28 11:09:19 <Ariadne> and since then libdb usage is way down
2020-07-28 11:10:43 <Ariadne> community/perl-berkeleydb could be dropped now
2020-07-28 11:12:33 <mps> yes
2020-07-28 11:12:43 <mps> there is perl-db in main
2020-07-28 11:12:55 <Ariadne> perl-db does not use bdb but gdbm afaik
2020-07-28 11:13:18 <Eighth_Doctor> 
ACTION is glad that we finally got rpm to stop requiring bdb

2020-07-28 11:13:21 <mps> apk info perl-db
2020-07-28 11:13:47 <mps> uhm, Perl extension for Berkeley DB version 2, 3 or 4
2020-07-28 11:13:48 <ikke> Ariadne: https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0
2020-07-28 11:13:49 <Eighth_Doctor> Ariadne: lmdb support was removed in rpm 4.16, due to upstream just being unresponsive to our issues
2020-07-28 11:14:01 <Ariadne> Eighth_Doctor: ok, so what do we do about rpm :P
2020-07-28 11:14:08 <Eighth_Doctor> in rpm 4.16, we now have a sqlite backend
2020-07-28 11:14:17 <Ariadne> ok, so upgrade it to 4.16 when released
2020-07-28 11:14:26 <Eighth_Doctor> this is what Fedora is switching to: https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb
2020-07-28 11:14:42 <mps> 'apk info perl-berkeleydb' => Perl extension for Berkeley DB version 2, 3, 4, 5 or 6
2020-07-28 11:15:11 <Ariadne> perl-berkeleydb has no deps
2020-07-28 11:15:13 <Ariadne> lets just drop it
2020-07-28 11:15:21 <mps> +1
2020-07-28 11:15:29 <Eighth_Doctor> bdb will be deprecated in rpm 4.16 and removed in rpm 4.17
2020-07-28 11:15:46 <Eighth_Doctor> after that, you can choose between sqlite and ndb (custom backend) for rpm
2020-07-28 11:16:02 <Eighth_Doctor> Fedora will use sqlite, openSUSE uses ndb
2020-07-28 11:16:47 <Eighth_Doctor> rpm can be compiled to support both at the same time while being set up for having one or the other as the default
2020-07-28 11:21:14 <Ariadne> mps: php7 i think we just disable db extension
2020-07-28 11:21:38 <mps> if perl-berkeleydb entered aports and there is perl-db we need aports janitors :)
2020-07-28 11:22:29 <mps> Ariadne: I didn't worked with php for about two decades so have no any idea what should be done with it
2020-07-28 11:23:12 <ikke> andypost[m] is usually taking care of php iirc
2020-07-28 11:23:23 <mps> yes
2020-07-28 11:23:54 <mps> he cares very well about php
2020-07-28 11:49:55 <Ariadne> maxice8: can we get an alint warning for depending on db-dev
2020-07-28 11:50:11 <maxice8> sure, can I know why ?
2020-07-28 11:50:40 <Ariadne> maxice8: we are deprecating berkeley db and do not want to accept any new packages depending on it
2020-07-28 11:50:59 <maxice8> makes sense
2020-07-28 11:51:29 <Cogitri> Ariadne: But that's just due to AGPL, isn't it?
2020-07-28 11:51:48 <mps> not only this
2020-07-28 11:52:00 <Ariadne> Cogitri: it is due to the fact that it has security vulnerabilities and we cannot distribute the fixed version
2020-07-28 11:52:57 <ikke> and backporting fixes is not reasonably possible as well
2020-07-28 11:53:18 <Ariadne> yes, oracle have intentionally created this situation
2020-07-28 11:53:28 <Ariadne> and we are not negotiating with terrorists
2020-07-28 11:54:31 <Eighth_Doctor> ^ this
2020-07-28 11:55:19 <Eighth_Doctor> this situation was even worse in Fedora and openSUSE, where Oracle likes to cut of their nose to spite their face
2020-07-28 12:02:51 <Ariadne> anyway, i have cut down the db-dev dep tree significantly
2020-07-28 12:03:10 <Ariadne> help would be appreciated with the rest of it
2020-07-28 12:04:10 <Ariadne> i think if we are willing to accept that postfix users will have to adjust their config
2020-07-28 12:04:16 <Ariadne> that we could purge bdb from 3.13
2020-07-28 12:04:52 <mps> for postfix add -NO_DB to cargs is enough
2020-07-28 12:05:41 <mps> didn't checked cyrys-sasl yet
2020-07-28 12:06:38 <Ariadne> fuck it, lets just nuke bdb now
2020-07-28 12:07:00 <mps> I tend to be on your side now :)
2020-07-28 12:07:23 <Ariadne> i don't think postfix fallout is worth waiting
2020-07-28 12:07:37 <Ariadne> everything else seems fine, e.g. bdb is only used for like cache and stuff
2020-07-28 12:07:40 <mps> but I think we should hear what other devs have to say
2020-07-28 12:07:59 <Ariadne> anyway, i guess lets work the other packages and make a final decision on postfix
2020-07-28 12:08:55 <mps> yes, I agree
2020-07-28 12:10:42 <ikke> what? abcde depends on py3-eyed3, which has been removed in 3.12?
2020-07-28 12:10:57 <Ariadne> whoops :)
2020-07-28 12:12:04 <ikke> ah, it's called eyed3 now
2020-07-28 12:12:21 <ikke> e7c9637e4dbfb6c0c2594ed61dac794a4153b4e8
2020-07-28 12:12:29 <ikke> maxice8: ^ :P
2020-07-28 12:13:46 <maxice8> I'll kook into it later
2020-07-28 12:13:50 <maxice8> Im making toast
2020-07-28 12:14:32 <ikke> Hmm, the package does have provides for py3-eyed3
2020-07-28 12:14:59 <ikke> But I guess the issue is that it is not built yet
2020-07-28 12:15:13 <Ariadne> imo
2020-07-28 12:15:14 <ikke> because buildrepo does not take provides into account
2020-07-28 12:15:24 <Ariadne> oracle bought bdb just to agpl it
2020-07-28 12:17:20 <ikke> maxice8: fixed it
2020-07-28 12:17:54 <ncopa> (98/164) Installing enchant2-dev (2.2.8-r2)
2020-07-28 12:17:54 <ncopa> ERROR: enchant2-dev-2.2.8-r2: BAD signature
2020-07-28 12:18:02 <ncopa> now I get that error, on armv7
2020-07-28 12:18:07 <ikke> uhh?
2020-07-28 12:18:13 <ncopa> i wonder whats going on
2020-07-28 12:18:22 <ikke> didn't we expect that?
2020-07-28 12:18:35 <ncopa> i thought i purged the cache
2020-07-28 12:18:45 <ikke> Yes, but if someone fetched it before it was built
2020-07-28 12:18:50 <ikke> then the old package is cached again
2020-07-28 12:18:57 <ncopa> i purged it again
2020-07-28 12:19:01 <ikke> oh, ok
2020-07-28 12:19:03 <ncopa> but still happens
2020-07-28 12:19:16 <ncopa> hum
2020-07-28 12:19:20 <ncopa> i think i purged wrong url
2020-07-28 12:19:24 <ikke> aha
2020-07-28 12:19:44 <ikke> fastly does not give any feedback if something was actually cached
2020-07-28 12:21:23 <ncopa> ok, now it works
2020-07-28 12:21:47 <ncopa> php7 built on x86
2020-07-28 12:21:50 <ncopa> in my dev env
2020-07-28 12:23:06 <ncopa>         case "$CARCH" in
2020-07-28 12:23:06 <ncopa>                 x86 | s390x | mips*) allow_fail='yes'
2020-07-28 12:23:11 <ncopa> thats why it passed on x86
2020-07-28 12:45:14 <Ariadne> Eighth_Doctor: does it really matter what rpm DB backend we use since we only use it to compose container/vm images
2020-07-28 12:45:40 <Eighth_Doctor> Ariadne: if the target distro doesn't have it compiled in, that's a problem
2020-07-28 12:45:50 <Eighth_Doctor> the rpmdb would be effectively broken
2020-07-28 12:46:24 <Eighth_Doctor> if you're always managing the software using host dnf, then it's fine
2020-07-28 12:46:59 <Eighth_Doctor> but if you want the rpmdb to work inside the distro (usually the case for VMs), then it'd be a problem if the rpmdb was in a format the target distro can't read
2020-07-28 12:47:35 <Eighth_Doctor> RHEL 9 and SLE 16 will not support bdb, but RHEL 8 and SLE 15 will not support sqlite/ndb
2020-07-28 12:47:45 <Eighth_Doctor> so this is going to be one of those more painful transitions
2020-07-28 12:48:46 <Eighth_Doctor> we do have the bdb-ro backend in rpm for reading old bdb rpmdb for conversion, but...
2020-07-28 12:49:06 <Eighth_Doctor> again, this is going to be a mess
2020-07-28 12:49:50 <TBB> that's not such a huge problem actually
2020-07-28 12:50:29 <TBB> sure, installing the same set of packages twice just to get a consistent package db in the container is a bit dumb, but it's a (temporary) solution that works
2020-07-28 12:50:30 <Eighth_Doctor> Ariadne: my recommendation is that if you have a development branch for stuff, I'd suggest importing rpm 4.16 beta 3 now and switching over to only compiling in bdb-ro, sqlite, and ndb, and changing the default to sqlite
2020-07-28 12:50:51 <Ariadne> well, we want to drop bdb entirely :)
2020-07-28 12:50:56 <Eighth_Doctor> TBB: yep, not saying there's no way out, it's just going to take some adapting
2020-07-28 12:51:00 <Eighth_Doctor> Ariadne: bdb-ro does not use libdb
2020-07-28 12:51:05 <Ariadne> oh cool
2020-07-28 12:51:16 <Eighth_Doctor> it is a from scratch implementation for just reading bdb for conversion to other db formats
2020-07-28 12:51:32 <Ariadne> i'll bump to 4.16 then
2020-07-28 12:52:22 <Eighth_Doctor> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/RbgKAlohwQdIryBJiwXhZdZY >

2020-07-28 12:52:33 <Eighth_Doctor> that's the snippet from our spec file for switching the backend
2020-07-28 12:52:55 <Eighth_Doctor> you may choose to implement it as a patch if you'd like
2020-07-28 12:53:28 <Eighth_Doctor> DNF already works perfectly fine with SQLite RPMDB
2020-07-28 12:53:33 <Eighth_Doctor> Zypper... not so much
2020-07-28 12:53:51 <Ariadne> well, really we just use rpm2cpio
2020-07-28 12:53:55 <Eighth_Doctor> (though openSUSE is looking at dropping Zypper for DNF, so...)
2020-07-28 12:53:56 <Ariadne> in most cases
2020-07-28 12:54:03 <Ariadne> and then rebootstrap inside the container
2020-07-28 12:54:05 <Eighth_Doctor> Ariadne: sure, but you brought up making containers and VMs :)
2020-07-28 12:54:29 <Eighth_Doctor> so I'm just pointing out everything you need to know there
2020-07-28 12:54:49 <Eighth_Doctor> I don't really know what you have in place for this, so all the advice is being given :)
2020-07-28 12:56:54 <Eighth_Doctor> the latest versions of the DNF package management stack work fine, Zypper's test suite is crashing with latest libcurl and librpm :(
2020-07-28 13:40:12 <andypost[m]> For php7 there's issue #11782 I suggest to add broken test to disabled ones but I'm afk for few days
2020-07-28 13:42:42 <ncopa> andypost[m]: yes, i'm looking at that
2020-07-28 13:42:45 <andypost[m]> Also ++ to get rid of bdb if it's used...
2020-07-28 13:43:28 <ncopa> would be nice to get rid of bdb, but imho its not a priority
2020-07-28 13:44:03 <ncopa> more important to get the 32 bit builds done
2020-07-28 13:45:44 <Cogitri> 👍
2020-07-28 13:47:49 <andypost[m]> As I got #11645 slightly affects php7 x86 (32 bits more then 64) that's why it allowed to fail ncopa, but it's far then I can debug yet
2020-07-28 13:49:28 <andypost[m]> Iirc it still valid for musl 1.2 but I'm sure the cause in php
2020-07-28 13:57:23 <ncopa> i know whats wrong with php
2020-07-28 14:01:27 <ncopa> i though i knew what was wrong with php but im not so sure anymore
2020-07-28 14:08:55 <ncopa> ah... documentation is a bit confusing
2020-07-28 14:09:03 <ncopa> "Integers do no more depend on the firm 'long' type. Instead a platform
2020-07-28 14:09:03 <ncopa> 	dependent integer type is used, it is called zend_long. That datatype is
2020-07-28 14:09:03 <ncopa> 	defined dynamically to guarantee the consistent 64 bit support."
2020-07-28 14:09:20 <ncopa> i thought that meant that it used 64 bit int everywhere
2020-07-28 14:09:21 <ncopa> but no
2020-07-28 14:09:43 <ncopa> on 32bit arches it is https://github.com/php/php-src/blob/master/Zend/zend_long.h#L41
2020-07-28 14:09:49 <ncopa> 32bit
2020-07-28 14:10:09 <ncopa> meaning that I can fix php unixtojd() func but it will still be 32bit
2020-07-28 14:10:53 <ncopa> and it does not seem to be any way to force 64bit arg on 32bit arch
2020-07-28 14:15:18 <ikke> yes, that documentation seems wrong if it's not a 64bit type on 32bits systems
2020-07-28 14:17:51 <ncopa> problem is here: https://github.com/php/php-src/blob/PHP-7.4.8/ext/calendar/cal_unix.c#L33
2020-07-28 14:18:31 <ncopa> it reads a zend_long (aka int32_t on 32 bit arches and int64_t on 64 bit arches) into a time_t
2020-07-28 14:18:47 <ncopa> so passing -1 gives unexpected result
2020-07-28 14:19:27 <[[sroracle]]> ncopa: andypost[m]: https://bts.adelielinux.org/show_bug.cgi?id=266#c2
2020-07-28 14:21:09 <ncopa> yup, thats the one
2020-07-28 14:21:45 <ncopa> and yup dalias is right, there are 2 bugs: one is assume time_t is long and the second is that its not y2038 compat on 32bit arches
2020-07-28 14:35:24 <dalias> the former is easy to fix and i thought someone already did
2020-07-28 14:35:43 <dalias> just change the wrong uses if time_t to long
2020-07-28 14:35:49 <dalias> of*
2020-07-28 14:38:39 <dalias> the atof thing is almost 100% surely tgst theyve broken the x87 control word value
2020-07-28 14:39:10 <dalias> thinking they can configure it for ieee double or single
2020-07-28 14:39:17 <[[sroracle]]> i never got a chance to address the time_t/long problem
2020-07-28 14:39:22 <[[sroracle]]> but yeah it should be just mechanical
2020-07-28 14:39:48 <dalias> this violates call abi and doesnt do what they think it does anyway
2020-07-28 14:43:05 <dalias> and its a really common mistake in interps and jits
2020-07-28 14:43:27 <dalias> because thryre trying to get deterministic double arithmetic
2020-07-28 14:45:03 <dalias> right fix is nearly impossible but the math lib call problem can be fixed with switching modes back and forth at the right places
2020-07-28 15:04:06 <mps> isn't fix 'long long' on 32bit arches (time_t)
2020-07-28 15:04:28 <ikke> mps: then you need to patch based on arch
2020-07-28 15:04:38 <ikke> or some macro trickery I guess
2020-07-28 15:05:00 <mps> yes, true
2020-07-28 15:05:39 <mps> just wanted to point that 'long' on 32bit is not enough
2020-07-28 15:06:30 <ikke> yes, the 2nd issue that dalias raised
2020-07-28 15:07:15 <mps> (case arch==x86|armhf|armv7) sed -ri 's/time_t/long long/g' ...)
2020-07-28 15:08:07 <ncopa> mps: problem is the php args -> C conversion does not support long long or int64_t on 32 bit arches.
2020-07-28 15:08:53 <ncopa> zend_parse_parameters cannot take any 64bit ints on 32bit arches: https://www.php.net/manual/en/internals2.funcs.php
2020-07-28 15:08:56 <mps> I'm not saying that this is solution, just pointing to 'cause'
2020-07-28 15:09:00 <ncopa> yup
2020-07-28 15:09:31 <mps> and trying to wake up after nap :)
2020-07-28 15:10:01 <ncopa> lots of the tests fails on x86
2020-07-28 15:10:13 <mps> (heavy wheather is today here)
2020-07-28 15:10:30 <ncopa> php is just broken on x86
2020-07-28 15:10:43 <mps> I'm sleeping all day
2020-07-28 15:11:36 <mps> yes, what I read about php it is quite problematic on x86 and other 32bit
2020-07-28 15:13:03 <mps> looks like perl and python are safe, maybe some minor issue will appear
2020-07-28 15:16:01 <ncopa> pretty impressive work is done to resurrect jasper from opensource death and avoiding make a fork https://github.com/jasper-software/jasper/issues/208
2020-07-28 15:19:01 <mps> aha, nice to see and read that some people/teams still care about opensource
2020-07-28 15:47:00 <dalias> ikke, you dont need to patch based on arch. their code always uses long and just wrongly assumes time_t is long
2020-07-28 15:47:41 <ikke> dalias: that was a reaction to mps suggestion to make it long long on 32-bits
2020-07-28 16:12:53 <dalias> yes, it doesnt work tho
2020-07-28 16:13:22 <dalias> fixibg the y2038 bug in php id outside distro scope imo, and belongs to upstream
2020-07-28 16:13:31 <ncopa> +1
2020-07-28 16:13:45 <dalias> distro just needs to fix actual type error
2020-07-28 16:13:57 <ncopa> i would have fixed it if it was trivial to do it at the same time, but php has not made that part easy
2020-07-28 16:14:09 <ikke> yeah, just defer that to upstream
2020-07-28 16:14:12 <ncopa> im gonnat fix the type error only for now
2020-07-28 16:16:12 <ncopa> Ariadne: nice work on ifupdown-ng
2020-07-28 16:21:01 <ikke> Looks nice, indeed
2020-07-28 16:23:47 <ncopa> Ariadne: one of the issues i have had in the past with ifdown/ifup is when interface is up, then I change /etc/network/interfaces and do ifdown/ifup
2020-07-28 16:24:04 <Ariadne> ncopa: that is going to be solved by ifreload
2020-07-28 16:24:12 <ncopa> ifdown fails due to the current state does not reflect the modified /etc/network/interfaces
2020-07-28 16:24:42 <Ariadne> oh, ifupdown-ng does not care about that.  it will just synchronize state to what is configured in all cases
2020-07-28 16:24:58 <Ariadne> ifreload will do so atomically
2020-07-28 16:25:29 <ncopa> right, but if you bind eth0 to a bond0 and then move it to a br0, it may fail to add it to br0 unless it is freed from the bond
2020-07-28 16:26:00 <Ariadne> yeah.  the plan is ifreload takes everything down, and then atomically brings everything up
2020-07-28 16:26:30 <ncopa> may want keep the interfaces ssh is connected via open :)
2020-07-28 16:26:33 <ncopa> but yeah
2020-07-28 16:26:43 <Ariadne> as in literally, ifreload will reset state atomically
2020-07-28 16:27:13 <ncopa> i trust you have good solutions to the problems. you are well aware of them
2020-07-28 16:29:51 <Ariadne> well what i plan to introduce to 3.13 is minimally intrusive
2020-07-28 16:30:01 <Ariadne> just the core features :)
2020-07-28 16:32:05 <ncopa> makes sense
2020-07-28 16:32:54 <ncopa> i think bridge, bonding and vlan are the core features needed
2020-07-28 16:33:03 <ncopa> and potentially  pppoe
2020-07-28 16:33:12 <Ariadne> rather, what i mean is
2020-07-28 16:33:21 <Ariadne> we will continue using the bridge, bonding, vlan, etc scripts
2020-07-28 16:33:40 <Ariadne> as they are now
2020-07-28 16:33:51 <Ariadne> so that people can migrate back to busybox/debian ifupdown
2020-07-28 16:34:49 <Ariadne> but it is my intent to ship the bridge, bond, vlan, pppoe, tunnel executors after 3.13 :)
2020-07-28 16:34:57 <Ariadne> if that makes sense
2020-07-28 16:35:02 <ncopa> yup. it does
2020-07-28 16:36:42 <Ariadne> the way the compat code works is
2020-07-28 16:36:53 <Ariadne> if you use `use bridge` and use the current bridge package
2020-07-28 16:37:05 <Ariadne> it will set up the environment so that `requires` is also `bridge-ports`
2020-07-28 16:37:14 <Ariadne> similar with bond, vlan etc
2020-07-28 16:37:41 <Ariadne> so the dependency is installed, without having to specify twice (once for the manager, once for the script)
2020-07-28 16:38:10 <Ariadne> so that allows for the dependency management to be used with the current scripts :)
2020-07-28 18:48:21 <andypost[m]> dalas, [[sroracle]] thanks for pointers, I found it more constructive to use bug reports and PRs with php
2020-07-28 18:48:47 <andypost[m]> Sadly time64 supported only for win https://github.com/php/php-src/search?q=time64&type=Code
2020-07-28 18:51:32 <dalias> andypost[m], i don't think that's what that said
2020-07-28 18:57:41 <andypost[m]> dalias as this only fix, I bet it is https://github.com/php/php-src/commit/44c8b7414ce96038017edc2fd827f8250669a62a
2020-07-28 21:32:12 <Cogitri> PureTryOut[m]: Seems like multiple applications (like Nextcloud-client) fail to build against new qt
2020-07-28 21:32:30 <Cogitri> `error: aggregate 'QPainterPath path' has incomplete type and cannot be defined`
2020-07-28 21:35:31 <PureTryOut[m]> Ugh, wtf
2020-07-28 21:40:06 <Ariadne> just need to #include <QPainterPath> in those files
2020-07-28 21:40:35 <Ariadne> qt 5.15 removed that include in favor of a forward declaration in several headers
2020-07-28 21:50:13 <maxice8> @Ariadne atools>=19.4.0-r0 should warn when db or any of its subpackages are used
2020-07-28 22:43:43 <Ariadne> great!!
2020-07-28 23:11:09 <dalias> andypost[m], that patch just fixes a trivial bug on 64-bit systems. it doesn't fix that php has major y2038 bugs
2020-07-29 05:17:55 <maxice8> @Ariadne you can also pass CUSTOM_DEPRECATED_PACKAGES (it takes the form of $repository/$package (like main/db)
2020-07-29 05:28:57 <ikke> ollieparanoid[m]: armv7 and armhf have been uploaded
2020-07-29 05:30:00 <ikke> x86 is still working on testing
2020-07-29 06:44:09 <Ariadne> maxice8: nice.  probably not useful for CI though
2020-07-29 07:06:59 <ikke> We can set environment variables in the CI definition
2020-07-29 07:07:06 <ikke> Would be just a push to aports
2020-07-29 07:18:29 <ollieparanoid[m]> ikke: thanks!
2020-07-29 07:37:22 <Ariadne> o
2020-07-29 07:38:21 <Ariadne> i would say after the next run, we can switch it back to stopping on failure
2020-07-29 07:45:05 <maxice8> That feature is mostly aimed at other people
2020-07-29 07:45:20 <maxice8> Alpine can just hard-code it because at the end of the day atools is an Alpine Linux project
2020-07-29 07:45:46 <maxice8> pmOS asked for that flexibility because they have more options="" than us
2020-07-29 08:05:55 <ollieparanoid[m]> PureTryOut: there's a cyclic dependency: kde-cli-tools depends on plasma-workspace-libs; plasma-workspace depends on kde-cli-tools
2020-07-29 08:10:00 <Cogitri> (#11785)
2020-07-29 08:10:52 <ncopa> I have switched build-edge-armhf back to halt-on-errors
2020-07-29 08:11:24 <Ariadne> dep could likely be broken with install_if
2020-07-29 08:16:13 <ncopa> maxice8: seems like libluv fails to build after cmake update
2020-07-29 08:17:01 <maxice8> I'll take a look
2020-07-29 08:18:23 <ikke> libmanette is faling again
2020-07-29 08:18:35 <ikke> on armhf
2020-07-29 08:19:35 <Cogitri> Ugh, I think it went through on x86 after trying again, no?
2020-07-29 08:19:56 <Cogitri> I don't really get how it's failing now and how it works for me on my desktop :D
2020-07-29 08:20:32 <ikke> concurrent builds?
2020-07-29 08:28:27 <Cogitri> Possibly
2020-07-29 08:29:01 <Cogitri> But I don't see how concurrent builds would cause undefined symbols which originate from other project
2020-07-29 08:42:17 <ncopa> build-edge-x86 will not halt on build fail
2020-07-29 08:42:25 <ncopa> s/not/now/
2020-07-29 08:42:25 <alpine-meetbot> ncopa meant to say: build-edge-x86 will now halt on build fail
2020-07-29 08:42:59 <ikke> armv7 just finished as well
2020-07-29 08:43:06 <ikke> 10:42:35  algitbot │ edge/testing/armv7: uploaded
2020-07-29 08:43:13 <ncopa> armv7 will now also halt on build fail
2020-07-29 08:43:19 <ikke> thanks
2020-07-29 09:50:49 <ikke> didn't we already fix qt5-qtwebengine?
2020-07-29 09:50:55 <ikke> it's failing again on armv7
2020-07-29 10:08:43 <ncopa> Ariadne: community/webkit2gtk fails on build-3-12-mips64. apparently due to out of memory error
2020-07-29 10:09:03 <ncopa> i wonder if it would make sense to configure some swap on that machine?
2020-07-29 10:09:03 <Ariadne> we only have 16gb
2020-07-29 10:09:11 <Ariadne> o
2020-07-29 10:09:13 <Ariadne> hang on
2020-07-29 10:09:24 <ncopa> or if we should try build it with -j<smaller number>
2020-07-29 10:09:42 <ncopa> i can also try build it manually
2020-07-29 10:11:55 <Ariadne> Swap:         31999           0       31999
2020-07-29 10:12:22 <ncopa> thanks!
2020-07-29 10:12:59 <ncopa> let me see if i can let it pick up where it failed so we dont need to rebuild from scratch
2020-07-29 10:27:47 <PureTryOut[m]> ollieparanoid: yup, I know https://gitlab.alpinelinux.org/alpine/aports/-/issues/11785
2020-07-29 10:29:43 <ollieparanoid[m]> ikke: regarding qt5-qtwebengine on armv7: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11791
2020-07-29 10:54:00 <PureTryOut[m]> Why are depends installed while building the package, rather than just makedepends and checkdepends? That is causing the circular dependency issue #11785
2020-07-29 10:55:17 <ikke> PureTryOut[m]: mostly because we don't want to have to repeat depends in makedepends if they are also required to build
2020-07-29 10:55:29 <ikke> most likely*
2020-07-29 10:58:20 <mps> ssldump in aports is outdated much too
2020-07-29 10:58:58 <mps> is it ok to upgrade from Debian 'fork' which have some fixes and patches ?
2020-07-29 10:59:42 <mps> https://salsa.debian.org/pkg-security-team/ssldump
2020-07-29 11:38:02 <Hello71> imo this is a misfeature of makepkg/abuild. gentoo ebuilds are better here, neither RDEPEND nor DEPEND imply each other. if you want to include one in the other you can simply do DEPEND="${RDEPEND} etc"
2020-07-29 11:38:34 <Hello71> they also like using unnecessary braces but that's a separate issue
2020-07-29 11:40:14 <ikke> changing that would be a massive project though
2020-07-29 11:40:46 <ikke> You basically have run-time deps, run-time + build-time deps and build-time deps
2020-07-29 11:41:58 <maxice8> @ncopa found the problem witih libluv
2020-07-29 11:42:03 <maxice8> It doesn't use pkgconfig
2020-07-29 11:47:39 <Hello71> ikke: gentoo "solves" this problem with EAPIs
2020-07-29 11:49:14 <Hello71> I think in theory it's a good idea to have a system to slowly migrate packages. but, you need to aggressively prune unmaintained packages in order to not hold back the package manager
2020-07-29 11:51:57 <Cogitri> ikke: Is it possible to assign users to an issue without giving them push permissions? https://gitlab.alpinelinux.org/alpine/aports/-/issues/11786#note_104937
2020-07-29 12:02:18 <ikke> Cogitri: I think we can make them reporter
2020-07-29 12:02:37 <ikke> reported should not have push access
2020-07-29 12:04:32 <Cogitri> Okie 👍
2020-07-29 12:06:09 <ikke> ncopa: any issues making PureTryOut[m] a reported on aports?
2020-07-29 12:06:13 <ikke> reporter*
2020-07-29 12:07:10 <ncopa> ofc no issues with that
2020-07-29 12:07:19 <ikke> (y)
2020-07-29 12:07:38 <ikke> done
2020-07-29 12:07:51 <Cogitri> Thanks :)
2020-07-29 12:08:06 <ncopa> one of the reasons we pull in depends together with makedepends is so build order gets correct
2020-07-29 12:08:31 <ncopa> hum.. maybe not
2020-07-29 12:09:02 <ncopa> tbh i dont remember exactly why we pull in runtime deps with makedeps, but iirc it was a good reason to do so
2020-07-29 12:11:48 <ncopa> separating makedepends from depends wouldnt solve the circular deps problem
2020-07-29 12:14:57 <ncopa> because even if you were able to build plasma-workspace without the runtime kde-cli-tools, you wouldn't be able to install it due to a missing runtime dep
2020-07-29 12:15:50 <ncopa> so when building kde-cli-tools it wouldnt be able to install plasma-workspace
2020-07-29 12:25:08 <ncopa> circular dep was introduced with commit 6b100efa4917408cc3500b62a0520fa0824ee24b
2020-07-29 12:26:44 <maxice8> @Cogitri is Firefox good to go ?
2020-07-29 12:28:29 <Cogitri> Of CI is happy, sure
2020-07-29 12:28:34 <Cogitri> s/O/I/
2020-07-29 12:28:34 <alpine-meetbot> Cogitri meant to say: If CI is happy, sure
2020-07-29 12:28:47 <Cogitri> At least it wfm, so I guess it should be gtg
2020-07-29 12:30:31 <maxice8> firefox CI is failing
2020-07-29 12:31:39 <Cogitri> Does it just OOM or fail due to an actual error?
2020-07-29 12:54:42 <ikke> gitlab 13.2 will introduce optional aproval for merge requests (required aprovals are not free (yet)
2020-07-29 12:56:06 <Cogitri> And reviews! :)
2020-07-29 12:57:15 <Cogitri> So you can do comments and then mass-submit them, no more "Oh nevermind, turns out you explaned that 3 lines later" :D
2020-07-29 12:57:32 <ikke> That's already there
2020-07-29 12:57:44 <ikke> in 13.1 that is
2020-07-29 12:58:08 <ikke> Though, anoyingly, that's changed to be the default behaviour
2020-07-29 12:58:31 <ikke> so when you think you are just leaving a comment, you need to still finish the review to actually post it
2020-07-29 13:02:46 <Cogitri> Ah yes, for single comments it can be a bit annoying
2020-07-29 13:03:11 <Cogitri> Oh neat, somehow I didn't notice that in g.a.o, I only noticed it in GNOME's Gitlab
2020-07-29 13:05:24 <maxice8> Isn't that GItHub behaviour ?
2020-07-29 13:06:08 <maxice8> @ncopa fixed libluv
2020-07-29 13:12:47 <ncopa> 👍
2020-07-29 13:53:00 <ollieparanoid[m]> Cogitri: can you take another look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10754?
2020-07-29 13:56:20 <Cogitri> Done, thanks
2020-07-29 14:21:30 <kytart> hi there. I'm having another issue. So I'm trying to build my own apk repo with a subset of the main and community repos in 3.12 branch. I'm having a trouble building lldb. I'm getting this error
2020-07-29 14:21:35 <kytart> ERROR: unsatisfiable constraints:
2020-07-29 14:21:35 <kytart>   ninja (virtual):
2020-07-29 14:21:36 <kytart>     provided by: samurai
2020-07-29 14:21:36 <kytart>     required by: .makedepends-lldb-20200729.133344[ninja]
2020-07-29 14:21:38 <kytart> >>> ERROR: lldb: builddeps failed
2020-07-29 14:21:53 <kytart> not sure what to do about this
2020-07-29 14:22:33 <kytart> I have samurai too so I think it should be used instead of ninja, but it doesn't
2020-07-29 14:23:01 <ikke> kytart: what happens if you do apk add ninja?
2020-07-29 14:23:47 <kytart> it installed samurai
2020-07-29 14:24:11 <ikke> that's expected
2020-07-29 14:24:22 <ikke> When do you get that error then?
2020-07-29 14:24:28 <kytart> I'm using buildrepo command
2020-07-29 14:24:28 <mckay-trabajo> kytart: check if older version of samurai already provided links of ninja.. maybe the last package does not have in standar path
2020-07-29 14:26:21 <kytart> @mckay-trabajo the package in 3.12 installs it in /usr/bin/ninja so that should be ok I think
2020-07-29 14:26:43 <ikke> does abuild deps in the lldb directory work?
2020-07-29 14:37:53 <kytart> @ikke yeah it installs samurai
2020-07-29 14:38:37 <kytart> seems like it only doesn't work in buildrepo
2020-07-29 14:39:15 <ikke> strange
2020-07-29 14:40:51 <kytart> I'll try running buildrepo again with all the already built packages already there
2020-07-29 14:42:17 <kytart> it will take a while I tihnk
2020-07-29 17:09:34 <ikke> Cogitri: ping
2020-07-29 17:10:18 <ggg> pong
2020-07-29 17:12:17 <ikke> mitm detected
2020-07-29 17:17:53 <Cogitri> Heh
2020-07-29 17:18:17 <ikke> Cogitri: cbindgen on 3.12 is too old for firefox
2020-07-29 17:18:49 <Cogitri> Oof
2020-07-29 17:19:07 <ikke> there was also a patch missing, but I took that one from master
2020-07-29 17:19:12 <Cogitri> 
ACTION wishes FF wouldn't oom on CI so this could actually be tested

2020-07-29 17:19:21 <Cogitri> Uhh, the pipewire-0.3 patch?
2020-07-29 17:19:23 <ikke> yes
2020-07-29 17:19:47 <Cogitri> I pushed a commit to remove that patch 😅
2020-07-29 17:19:47 <Cogitri> accidentally added it when cherry picking the bump commit from edge
2020-07-29 17:19:52 <ikke> oh haha
2020-07-29 17:19:57 <ikke> then you need to remove it agian
2020-07-29 17:20:25 <Cogitri> Well, it doesn't hurt I guess since we don't build with pipewire on 3.12 anyway
2020-07-29 17:20:40 <Cogitri> maybe we should do that though, it's required for screensharing on Wayland
2020-07-29 17:23:19 <Cogitri> Oh, apparently I forgot to push the commit removing that patch, oops
2020-07-29 17:29:15 <Cogitri> So, should hopefully be fixed now, thanks for the ping
2020-07-29 17:29:40 <ikke> np, afontain_ mentioned that firefox was not building
2020-07-29 17:33:26 <the6543> hey
2020-07-29 17:33:49 <mckay-trabajo> ¬_¬
2020-07-29 17:34:00 <the6543> did the memory limit of gitlab CI changed lately?
2020-07-29 17:34:08 <the6543> @clandmeter @ikke
2020-07-29 17:34:40 <ikke> the6543: it depends on the host, we do not limit the memory
2020-07-29 17:35:18 <the6543> nice info, will run some retrys
2020-07-29 17:36:11 <ikke> the6543: But what is often the issue is that these hosts of lots of CPU's, so there are a lot of concurrent jobs running
2020-07-29 17:36:30 <ikke> we set -j $(nproc) by default
2020-07-29 17:38:03 <the6543> a test crashed with 'fatal error: out of memory'
2020-07-29 17:38:10 <the6543> shared-runner (armv7) iTPKmZKW
2020-07-29 17:38:37 <ikke>               total        used        free      shared  buff/cache   available
2020-07-29 17:38:39 <ikke> Mem:          32047        2505       22924           0        6617       30214
2020-07-29 17:40:04 <the6543> current jobs runn on (aarch64) byjWLQAr and (armv7) iTPKmZKW
2020-07-29 17:40:07 <the6543> so we will see
2020-07-29 18:14:36 <PureTryOut[m]> ikke: regarding the depends. Maybe, but I rather repeat depends thatn cause circular issues and resort to hacks like we did just now with the kde-cli-tools <-> plasma-workspace circular dependency
2020-07-29 18:15:01 <ikke> according to ncopa it would not have solved that issue
2020-07-29 18:20:57 <PureTryOut[m]> Why not? plasma-workspace only depends on kde-cli-tools on runtime. If you just don't install that while building it, issue fixed no?
2020-07-29 21:02:01 <ikke> maxice8: libluv is still failing
2020-07-29 21:02:44 <maxice8> at least it is a different error
2020-07-29 21:02:48 <ikke> yes
2020-07-29 21:02:57 <ikke> some conflict
2020-07-29 21:06:46 <Ariadne> hopefully people do understand that we are only talking about ifupdown-ng *core* for 3.13 right :p
2020-07-29 21:07:12 <ikke> I hope so too
2020-07-29 21:08:14 <maxice8> I think that what is normally expected
2020-07-29 21:08:36 <maxice8> It is not wise to put it up on already released 3.12 and I don't recall anything about 3.14 being mentioned
2020-07-29 21:08:54 <ikke> yeah, no one is talking about 3.12
2020-07-29 21:10:21 <Ariadne> not wifi management, not ifmond, etc :)
2020-07-29 21:10:37 <Ariadne> although i do want to implement a dbus service providing networkmanager api
2020-07-29 21:10:41 <Ariadne> as an optional package :P
2020-07-29 21:14:28 <Ariadne> i mean, the dep solver is the same solver as in pkgconf basically, and the rest of it is a giant wrapper around posix_spawn() :P
2020-07-30 01:14:43 <the6543> sory - wrong window focus :(
2020-07-30 01:15:00 <the6543> vlc didnt respond
2020-07-30 06:08:15 <ncopa> morning
2020-07-30 06:09:30 <ncopa> PureTryOut[m]: no. issue not fixed. you would be able to build plasma-workspace, but you would not be able to install it when building kde-cli-tools
2020-07-30 06:10:56 <ncopa> when building kde-cli-tools, it would try install plasma-workspace as dependency but install would fail because plasma-workspace's runtime dependency kde-cli-tools is not yet built
2020-07-30 06:11:06 <ncopa> so installing makdepends for kde-cli-tools would fail
2020-07-30 06:14:41 <mps> \o
2020-07-30 06:15:07 <mps> A long list of GRUB2 secure-boot holes https://lwn.net/Articles/827403/
2020-07-30 06:15:31 <mps> we don't support secure boot?
2020-07-30 06:16:16 <mps> i.e. we don't support false sense of security? :)
2020-07-30 06:20:33 <c705> hi folks. i'm trying to reverse engineer the mkimage.sh a little bit, specifically need help with configuring modules in the initramfs
2020-07-30 06:22:01 <c705> i can't really find where it's creating the initramfs, but I suspect `update-kernel` or during an apk add somewhere
2020-07-30 06:24:48 <ncopa> c705: its update-e
2020-07-30 06:24:57 <ncopa> c705: its update-kernel that call mkinitfs
2020-07-30 06:27:28 <c705> ncopa: is there any documentation for update-kernel? busybox provides this?
2020-07-30 06:28:16 <c705> ah, i've found it
2020-07-30 06:35:32 <ncopa> im working on qt5-qtwebengine on armv7
2020-07-30 06:43:24 <c705> does mkinitfs read /etc/modules? I'm trying to get my vfio config into the initramfs
2020-07-30 06:54:22 <ncopa> no, but it reads /etc/mkinitfs/mkinitfs.conf
2020-07-30 06:55:06 <ncopa> so, this package tpm2-tss fails running the test suite
2020-07-30 06:55:22 <ncopa> i wonder what this software does, eg. what problem it is supposed to solve
2020-07-30 06:55:27 <ncopa> so i check the pkgdesc
2020-07-30 06:55:28 <c705> ncopa: what's the syntax of that file? is it the make as mkinitcpio
2020-07-30 06:55:36 <c705> the same, even
2020-07-30 06:55:39 <ncopa> pkgdesc="TPM 2.0 TSS"
2020-07-30 06:56:25 <ncopa> mkinitfs has "features" which are kernel module list and file list defined in /etc/mkinitfs/features.d/
2020-07-30 06:56:43 <ncopa> so pkdesc does not tell me anything
2020-07-30 06:56:49 <ncopa> so i check the website
2020-07-30 06:57:09 <ncopa> About
2020-07-30 06:57:10 <ncopa> OSS implementation of the TCG TPM2 Software Stack (TSS2)
2020-07-30 06:57:31 <ncopa> Overview
2020-07-30 06:57:31 <ncopa> This repository hosts source code implementing the Trusted Computing Group's (TCG) TPM2 Software Stack (TSS). This stack consists of the following layers from top to bottom:
2020-07-30 06:57:53 <ncopa> Feature API (FAPI) as described in the TSS 2.0 Feature API Specification ...
2020-07-30 06:58:13 <ncopa> apparently there are no way to learn what this software does unless you already know it ...
2020-07-30 06:58:41 <ncopa> i need to read the spec apparently
2020-07-30 06:59:48 <ncopa> the spec has an overview and an introduction section
2020-07-30 07:00:02 <ncopa> introduction section says: This TSS 2.0 Feature API is meant to be a very high-level API, aimed at providing 80% of programmers who write a
2020-07-30 07:00:02 <ncopa> program using the TPM with everything they require
2020-07-30 07:00:08 <ncopa> so what is "the TPM"
2020-07-30 07:00:39 <ncopa> Trusted Platform Module
2020-07-30 07:01:05 <ikke> mps: there is already an issue on gitlab for boothole
2020-07-30 07:01:15 <ncopa> tgc apparently means trusted computing group
2020-07-30 07:01:42 <ncopa> so apparently there is a "trusted computing group" that builds a "trusted platform module"
2020-07-30 07:02:01 <ncopa> i guess it is about trusting something that has to do with computers
2020-07-30 07:02:52 <ncopa> oh there is a webpage too
2020-07-30 07:02:53 <Cogitri> TPM is for storing secret keys e.g. for secure boot, no?
2020-07-30 07:02:56 <ncopa> https://tpm2-software.github.io/
2020-07-30 07:03:07 <c705> Cogitri: correct
2020-07-30 07:03:11 <ncopa> which even has tutorials and examples
2020-07-30 07:04:22 <ncopa> right, but those descriptions and explanations does not mean anything unless you already know what it does
2020-07-30 07:04:47 <ikke> multiple layers deep
2020-07-30 07:04:57 <mps> TPM, yet another false sense of security
2020-07-30 07:05:09 <ncopa> Cogitri: thank you for the explanation. makes sense now
2020-07-30 07:06:07 <mps> you have to trust manufacturers that your keys will be safe in 'closed' hardware implementation
2020-07-30 07:06:54 <ncopa> the wiki page gave the answer in seconds
2020-07-30 07:07:28 <ncopa> i wonder if our docs are the same
2020-07-30 07:07:52 <ncopa> if you have no clue about anything. does it help user in right direction. or do we assumes users know everything already
2020-07-30 07:08:59 <ikke> https://docs.alpinelinux.org/user-handbook/0.1a/index.html tries to explain a lot of basic concepts
2020-07-30 07:09:39 <ikke> sadly that effort mostly died
2020-07-30 07:09:57 <c705> ncopa: i hope one day I understand enough to write decent ocumentation
2020-07-30 07:10:21 <c705> but right now i'm resporting to reading the scripts to try and hack it
2020-07-30 07:13:09 <ncopa> c705: sounds like i just throw a stone in the glass house :)
2020-07-30 07:13:39 <ncopa> c705: what do you need to include in the initramfs image?
2020-07-30 07:13:48 <ncopa> a few files and some kernel modules?
2020-07-30 07:13:51 <Cogitri> Hopefully I'll find time soon to write more docs
2020-07-30 07:14:13 <ikke> maybe we should organize some documentation hackathon
2020-07-30 07:14:32 <Cogitri> That'd be great, after AlpineConf or something
2020-07-30 07:15:58 <c705> ncopa: modules and their configuration under /etc/modprobe.d/, which i see is already covered by base feature
2020-07-30 07:15:59 <ncopa> c705: you can define a mkinitfs "vfio" feature by creating /etc/mkinitfs/features.d/vfio.{modules,files}
2020-07-30 07:16:18 <c705> ncopa: yes, my thoughts were an this track myself
2020-07-30 07:16:21 <ikke> ncopa: how does that work in light of mkimage.sh?
2020-07-30 07:16:29 <c705> thank you for your help. now I understand a little more
2020-07-30 07:16:59 <c705> ikke: mkimage.sh calls update-kernel which calls mkinitfs
2020-07-30 07:17:21 <ncopa> an mkimage.sh config has a initfs_features="base network squashfs usb virtio"
2020-07-30 07:17:40 <ikke> Where do you provide those files (/etc/mkinitfs/*)
2020-07-30 07:17:50 <c705> that was my next question
2020-07-30 07:18:28 <ikke> from what I understand, they are installed in $APKROOT or something like that
2020-07-30 07:18:48 <ncopa> so if you set initfs_features="mything" it will include the kernel modules listed in /etc/mkinitfs/features.d/mything.modules and the files in /etc/mkinitfs/features.d/mything.files
2020-07-30 07:19:22 <ikke> yes, that part is clear (to me)
2020-07-30 07:20:28 <ncopa> it is possible those features needs to be shipped with the mkinitfs.apk
2020-07-30 07:20:53 <ncopa> i havent really checked if adding custom features works with mkimage.sh
2020-07-30 07:21:23 <c705> ncopa: I'll find out by tomorrow night
2020-07-30 07:21:47 <ikke> ncopa: maybe some kind of overlay that you can provide
2020-07-30 07:21:54 <c705> i undeerstand more now, thank you. I'm at -4UTC so it's a bit late for me
2020-07-30 07:22:35 <ikke> sounds like an understatement :P
2020-07-30 07:23:18 <c705> i have a sleeping disorder, so this is fairly usual for me
2020-07-30 07:23:52 <ncopa> c705: sleep well!
2020-07-30 07:24:00 <c705> cheers!
2020-07-30 08:14:07 <z3ntu> x11vnc 32-bit build should be fixable with this patch: https://github.com/LibVNC/x11vnc/commit/daecf59cc8b294265666482a4766aaa3148c308b
2020-07-30 09:00:08 <kr0k0> Hi
2020-07-30 09:00:23 <kr0k0> Can anyone help me with !10652?
2020-07-30 09:01:07 <kr0k0> The armv7 build has always package install errors, for example: "ERROR: libdvdcss-1.4.2-r0: BAD signature".
2020-07-30 09:02:44 <Cogitri> I think the CDN caches things it shouldn't again
2020-07-30 09:02:49 <ikke> kr0k0: https://lists.alpinelinux.org/~alpine/devel/%3C20200721171650.48fa63a4%40ncopa-desktop.copa.dup.pw%3E
2020-07-30 09:06:41 <kr0k0> Ah ok
2020-07-30 09:06:59 <kr0k0> ikke: Thanks!
2020-07-30 09:08:13 <ikke> Cogitri: dl-cdn should cache everything
2020-07-30 09:08:22 <ikke> but the cache should be invalidated :)
2020-07-30 09:08:54 <ncopa> kr0k0: workaround is to curl -X PURGE $url
2020-07-30 09:10:01 <ikke> ncopa: I wonder if we can set fastly up to validated the cahced entres
2020-07-30 09:10:04 <ikke> entries
2020-07-30 09:10:43 <ncopa> how would it do that?
2020-07-30 09:10:47 <ncopa> check timestamp?
2020-07-30 09:11:40 <ikke> Something like that
2020-07-30 09:12:57 <ncopa> https://info.varnish-software.com/blog/systematic-content-validation-with-varnish
2020-07-30 09:13:13 <ikke> fastly has documentation on it as well
2020-07-30 09:16:10 <kr0k0> ncopa: Thanks! I'll try that.
2020-07-30 09:16:35 <kytart> @ikke hi, I'm back with my issue from yesterday. Buildrepo fails to build lldb. Getting error that ninja doesn't exist, etc. Got some updates
2020-07-30 09:17:56 <kytart> I have all other packages built at this point in directory /data/alpine-aports/packages. When I run buildrepo, it just tries to build lldb which is the last missing package and I get error
2020-07-30 09:17:59 <kytart> ERROR: unsatisfiable constraints:
2020-07-30 09:17:59 <kytart>   ninja (virtual):
2020-07-30 09:18:00 <kytart>     provided by: samurai
2020-07-30 09:18:01 <kytart>     required by: .makedepends-lldb-20200730.091748[ninja]
2020-07-30 09:18:02 <kytart> >>> ERROR: lldb: builddeps failed
2020-07-30 09:18:06 <ikke> ncopa: do you have any clue ^?
2020-07-30 09:18:17 <kytart> if I just cd to lldb and run abuild deps it works
2020-07-30 09:18:51 <kytart> but I logged out how exactly buildrepo runs it and it runs this command "APORTSDIR='/data/build/alpine-aports' REPODEST='/data/build/alpine-aports/packages' abuild -r -m"
2020-07-30 09:19:24 <kytart> so I tried cd to lldb and run "APORTSDIR='/data/build/alpine-aports' REPODEST='/data/build/alpine-aports/packages2' abuild deps" and I get the same error
2020-07-30 09:19:34 <kytart> if I remove REPODEST it works
2020-07-30 09:21:21 <ncopa> ikke: i wonder if we could do something like: 1) read APKINDEX, 2) for each package read ETag in http header from both dl-cdn and dl-master, 3) if they differ, run purge
2020-07-30 09:22:48 <ikke> But would be nice if fastly could do that validation automatically without us having to constantly
2020-07-30 09:22:52 <ikke> purge everything
2020-07-30 09:27:52 <ncopa> the article above explains some tecniques to do so, with their pros/and cons
2020-07-30 09:28:27 <ncopa> my ieda would be to read the index and headers of each package and only purge those that have been modified
2020-07-30 09:29:17 <ncopa> under normal operation we dont need to "purge everything", its just when we do new release and we need to purge latest-releases
2020-07-30 09:29:49 <ncopa> and right now while doing this musl 1.2. update
2020-07-30 09:29:55 <kr0k0> ncopa: It worked, thanks again!
2020-07-30 09:30:20 <ncopa> kr0k0: sorry for the inconvenience
2020-07-30 10:02:18 <kr0k0> ncopa: Such a big change, like musl major upgrade, must have side effects. ;-)
2020-07-30 10:06:46 <Ariadne> have a linux-lts change in a moment
2020-07-30 10:06:53 <Ariadne> going to open an MR for it
2020-07-30 10:07:11 <Ariadne> but i need it in order to make my GPU work on this other honeycomb board i have
2020-07-30 10:07:16 <Ariadne> which is an earlier silicon revision
2020-07-30 10:07:16 <Ariadne> ;/
2020-07-30 10:07:57 <Ariadne> THE YEAR OF THE AARCH64 DESKTOP LOL
2020-07-30 10:20:39 <Ariadne> atually i guess an MR is excessive
2020-07-30 10:21:19 <Ariadne> make my GPU work :)
2020-07-30 10:24:02 <ikke> Ariadne:
2020-07-30 10:24:04 <ikke> Error: /home/buildozer/aports/main/linux-lts/src/linux-5.4/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dts:186.1-8 Label or path emdio1 not found
2020-07-30 10:24:06 <ikke> Error: /home/buildozer/aports/main/linux-lts/src/linux-5.4/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dts:196.1-8 Label or path emdio2 not found
2020-07-30 10:26:06 <Ariadne> ???????
2020-07-30 10:26:25 <Ariadne> wtf solidrun
2020-07-30 10:26:38 <Ariadne> ok give me a moment
2020-07-30 10:37:31 <Ariadne> solidrun's patches were against the linux-5.4 tree shipped by freescale
2020-07-30 10:37:43 <Ariadne> i added the missing patch from freescale's tree :p
2020-07-30 10:40:42 <Ariadne> these libre hardware vendors are pretty sloppy ;/
2020-07-30 10:49:03 <ncopa> can any perl expert have a look at the perl-metapan-client? tests fails for some reason
2020-07-30 11:02:33 <mps> ncopa: ask timlegge, maybe he can help
2020-07-30 11:03:15 <mps> so, now kernel patches are ok :)
2020-07-30 11:04:26 <Ariadne> mps: it is case by case basis
2020-07-30 11:04:47 <mps> I don't have time to look at perl-metapan-client
2020-07-30 11:05:28 <mps> Ariadne: I'm not against them, I advocated long time to add wireguard patch
2020-07-30 11:05:42 <Ariadne> mps: well, wireguard is better as out of tree module
2020-07-30 11:05:51 <Ariadne> less of a pain
2020-07-30 11:06:07 <Ariadne> but we have patched the kernel to enable hardware to work before :P
2020-07-30 11:06:28 <mps> hmm, I used it as patch nearly after it is announced, never had any problem
2020-07-30 11:06:48 <Ariadne> and, the patches i added are all upstream anyway and will be in next LTS
2020-07-30 11:06:57 <mps> and was easy to patch
2020-07-30 11:07:21 <mps> WG is also upstream :)
2020-07-30 11:08:24 <Ariadne> yeah so it is kind of a moot point :P
2020-07-30 11:08:45 <Ariadne> basically the criteria is
2020-07-30 11:08:53 <Ariadne> if it can be done with a out of tree module
2020-07-30 11:08:57 <Ariadne> that is the preferred way to do it
2020-07-30 11:08:58 <mps> ncopa: could you post perl-metapan-client build log
2020-07-30 11:09:45 <Ariadne> this was mainly adding a DTB and patching the PCIe driver to support the PCIe bus topology used by honeycomb
2020-07-30 11:10:14 <Ariadne> although imo linux PCIe code may be broken, because windows does not require that patch
2020-07-30 11:10:20 <mps> ok ok
2020-07-30 11:10:38 <mps> I know arm will need a lot of patches
2020-07-30 11:11:08 <Ariadne> yes they are not very consistent on upstreaming things, but solidrun has done pretty good with that
2020-07-30 11:11:39 <Ariadne> still, a $700 machine that is user-controlled firmware is a good alternative to talos which costs twice as much
2020-07-30 11:11:41 <Ariadne> :P
2020-07-30 11:11:41 <mps> ncopa: ie, what is problem
2020-07-30 11:12:18 <Ariadne> https://build.alpinelinux.org/buildlogs/build-edge-x86/community/perl-metacpan-client/perl-metacpan-client-2.026000-r0.log
2020-07-30 11:12:37 <mps> i wasted about 550 Eurs three years ago on arm64 chromebook
2020-07-30 11:12:50 <Ariadne> yeah chromebooks are very hit or miss
2020-07-30 11:13:12 <ncopa> timlegge: upstream report: https://github.com/metacpan/metacpan-client/issues/103
2020-07-30 11:13:15 <Ariadne> pinebook pro looks potentially decent now that we have panfrost in alpine
2020-07-30 11:13:36 <mps> ah, Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/core_perl/HTTP/Tiny.pm line 602
2020-07-30 11:13:58 <mps> looks like but  is in perl-http-tyni
2020-07-30 11:14:31 <mps> Ariadne: except panfrost is buggy and still unusable
2020-07-30 11:15:09 <Ariadne> i was able to boot to kde on panfrost
2020-07-30 11:15:15 <Ariadne> seems fine these days
2020-07-30 11:15:29 <mps> I can boot and use it but it is buggy
2020-07-30 11:15:48 <Ariadne> yeah it is still in development but is liveable
2020-07-30 11:16:00 <mps> though I didn't tried with wayland, only X
2020-07-30 11:16:01 <Ariadne> at least, for me
2020-07-30 11:16:10 <Ariadne> yeah i don't even fuck with X anymore
2020-07-30 11:16:17 <Ariadne> have not used X in a year now
2020-07-30 11:17:06 <mps> I doubt I can switch from X till awesome wm is ported to wayland
2020-07-30 11:17:37 <Ariadne> seems like it would not be that hard to make an equivalent to awesome using wlroots
2020-07-30 11:18:12 <afontain_> mps: it exists. It's called way-cooler.
2020-07-30 11:18:37 <mps> could someone try to rebuild perl-http-tyni
2020-07-30 11:18:51 <mps> tiny*
2020-07-30 11:19:29 <mps> I went out to drink coffee
2020-07-30 11:23:40 <mps> huh, I forgot that, usr/share/perl5/core_perl/HTTP/Tiny.pm is owned by perl-5.30.3-r2
2020-07-30 11:25:45 <kytart> I dug deeper into my problem. When I build the packages with buildrepo, it generates the local repo and then for each next package it uses that repo for deps. So when I'm building lldb, it installs the make deps as virtual apk and it fails when ninja is one of the deps
2020-07-30 11:25:48 <mps> looks like metacpan didn't passed all params in failed test
2020-07-30 11:26:04 <kytart> this works "apk add --repository /data/build/alpine-aports/packages/main ninja"
2020-07-30 11:26:30 <kytart> this doesn't "apk add --repository /data/build/alpine-aports/packages/main --virtual tmptest ninja"
2020-07-30 11:27:03 <kytart> not sure why
2020-07-30 11:51:53 <kytart> actually no, "apk add --repository /data/build/alpine-aports/packages/main ninja" doesn't work either
2020-07-30 11:52:19 <kytart> I don't get it why it can install it from the remote repo but not from my local repo
2020-07-30 11:53:04 <kytart> this works "apk add --repository /data/build/alpine-aports/packages/main samurai"
2020-07-30 11:59:06 <kytart> anyway, I created an issue so I don't spam this channel https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10005
2020-07-30 14:16:24 <maxice8> Is there a manpage on `ap` ?
2020-07-30 14:30:59 <mps> I don't think there is
2020-07-30 14:43:54 <hbug___> any ideas what would be the least painfull way to make libvirtd work again without a hacky workaround?
2020-07-30 14:44:44 <hbug___> is it possible to statically link libvirt against glibc and package it as aport?
2020-07-30 14:47:29 <Cogitri> No, since static linking glibc isn't actually fully static
2020-07-30 14:47:37 <Cogitri> Instead of hacking here it'd be best to patch this upstream
2020-07-30 14:48:00 <Cogitri> if there's enough interest in it I hope that upstream will cooperate
2020-07-30 15:06:04 <dalias> is this the stupid fork issue?
2020-07-30 15:06:13 <dalias> i already provided a fix
2020-07-30 15:06:35 <dalias> just remove all the logging stuff between fork and exec
2020-07-30 15:07:21 <Cogitri> Yes
2020-07-30 15:07:31 <Cogitri> Just needs someone to add a patch and test it, I guesd
2020-07-30 15:12:29 <mps> we can expect new kernels with msg 'All must upgrade' https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f227e3ec3b5cad859ad15666874405e8c1bbc1d4
2020-07-30 15:13:16 <mps> looks like network rng issue
2020-07-30 15:25:57 <dalias> ?
2020-07-30 15:26:27 <dalias> why should anyobe care unless it exposes something actuslly secret? network layer is inherently untrusted
2020-07-30 15:27:31 <mps> I don't know really, but to me looks like secfix
2020-07-30 15:28:33 <mps> and yes, no network is one of the first security solution
2020-07-30 15:29:08 <mps> (omg, I told that over network :) )
2020-07-30 16:07:28 <ikke> mps: I would start with no computer
2020-07-30 16:08:20 <dalias> "no network" isn't needed
2020-07-30 16:08:42 <dalias> just assuming anything received over network is malicious/junk unless it's cryptographically validated
2020-07-30 16:08:53 <dalias> in which case the kernel's magic random numbers are pointless
2020-07-30 16:08:59 <dalias> at best they reduce the impact of DoS
2020-07-30 16:09:23 <ikke> Isn't the kernels random number part of a lot of cryptography happening?
2020-07-30 16:09:41 <dalias> no, the cryptography does not happen in the kernel
2020-07-30 16:10:13 <dalias> this is some RNG for sequence numbers or source port selection or syn cookies or tcp fastopen cookies or something
2020-07-30 16:10:19 <ikke> dalias: that's not what I said though :)
2020-07-30 16:13:18 <ikke> hmm, the grub2 patches causes booting issues apparently: https://bugzilla.redhat.com/show_bug.cgi?id=1861977
2020-07-30 16:13:30 <dalias> :-p
2020-07-30 16:13:49 <dalias> i really don't get the point of the grub "vuln"
2020-07-30 16:14:32 <dalias> apparently a lot of people are under the delusion that "secure boot" lets you defend against persistent pwn by an attacker who's gained full kernel control
2020-07-30 16:15:10 <ikke> That's the stated goal of 'secure boot' anyway
2020-07-30 16:16:41 <ollieparanoid[m]> some mirrors on dl-cdn still seem to have the old packages: people are reporting "BAD signature" errors with them. I wonder if we could fix this somehow
2020-07-30 16:17:03 <ollieparanoid[m]> (I was able to reproduce these errors)
2020-07-30 16:17:34 <mps> dalias: hehe, this morning I wrote here (sorry for spam again)
2020-07-30 16:17:37 <mps> 08:15 ............. mps| A long list of GRUB2 secure-boot holes https://lwn.net/Articles/827403/
2020-07-30 16:17:40 <mps> 08:15 ............. mps| we don't support secure boot?
2020-07-30 16:17:42 <mps> 08:16 ............. mps| i.e. we don't support false sense of security? :)
2020-07-30 16:17:42 <ikke> ollieparanoid[m]: the problem is that it will keep happening until everything has been rebuilt
2020-07-30 16:18:01 <dalias> ikke, and laughably impossible to deliver
2020-07-30 16:18:13 <dalias> mps, :)
2020-07-30 16:18:34 <ikke> dalias: doesn't prevent people from trying :)
2020-07-30 16:19:14 <mps> ikke: false security is worse than no security at all
2020-07-30 16:19:31 <dalias> in principle it could be done if there were a hypervisor with proven security properties and it didn't actually give you access to any hardware
2020-07-30 16:19:49 <dalias> but of course everyone wants their gaming gpus and storage device dma and ...
2020-07-30 16:19:50 <ikke> mps: locks don't prevent determined people from entering your house
2020-07-30 16:20:07 <mps> sure, but I know this
2020-07-30 16:20:08 <dalias> which will happily just bypass the hypervisor
2020-07-30 16:20:15 <ikke> no one says that locks give a false sense of security
2020-07-30 16:20:32 <dalias> because locks aren't advertised as delivering impossible security properties
2020-07-30 16:20:46 <mps> worse thing is if I believe locks can prevent determined people to enter house
2020-07-30 16:20:47 <dalias> their purpose and weaknesses are clearly understood by the general public
2020-07-30 16:20:48 <ikke> so it's about managing expectations
2020-07-30 16:20:51 <dalias> that's not the case for "secure boot"
2020-07-30 16:21:09 <dalias> and moreover there's not any actual threat that secure boot successfully mitigates against
2020-07-30 16:21:10 <ollieparanoid[m]> ikke: why? my understanding was, that when the buildbot is through (either because all passed, or because it's configured to just build the next pkg on failure) with one of main, community, testing, it gets pushed to a primary mirror and then all other mirrors sync from that. does it work differently with some mirrors listed in dl-cdn?
2020-07-30 16:21:36 <dalias> it's more like a tinfoil hat
2020-07-30 16:21:46 <mps> dalias: :)
2020-07-30 16:21:58 <mps> right
2020-07-30 16:22:48 <ikke> ollieparanoid[m]: these issues can only happen when the old package is still available and then at some point gets switched with a newer version
2020-07-30 16:23:33 <ikke> I can try to purge it now and see if we get new issues
2020-07-30 16:25:49 <ollieparanoid[m]> ikke: thanks. what does "purge" exactly do?
2020-07-30 16:26:12 <ikke> ollieparanoid[m]: dl-cdn is backed by fastly, which is caching packages
2020-07-30 16:26:29 <ikke> The TTL is quite long for that cache
2020-07-30 16:26:43 <ollieparanoid[m]> aah. I thought it was a frontend for the other mirrors for some reason.
2020-07-30 16:27:02 <ikke> Well, it does use another mirror as a back-end
2020-07-30 16:27:09 <ikke> but it's main purpose is caching
2020-07-30 16:27:24 <ikke> (geographically spread)
2020-07-30 16:27:41 <ikke> So when we rebuild packages without changing the pkgver / pkgrel
2020-07-30 16:27:51 <ikke> The hash of the package is different
2020-07-30 16:28:00 <ikke> (we don't have reproducable builds yet)
2020-07-30 16:28:03 <ollieparanoid[m]> makes sense now, thanks :) can you ping me when you hit the purge button?
2020-07-30 16:29:10 <mps> huh, '/usr/bin/install -c -m 755 -d /usr/share/doc/ssldump' \n 'install: can't create directory '/usr/share/doc/': Permission denied'
2020-07-30 16:29:26 <mps> abuild -r, trying to upgraded ssldump
2020-07-30 16:30:53 <mps> maybe install from coreutils can work with this?
2020-07-30 16:30:54 <ikke> It only specifies BINDIR and MANDIR
2020-07-30 16:31:08 <ikke> mps: isn't the problem that it tries to install it on your system?
2020-07-30 16:31:11 <ikke> not in $pkgdir?
2020-07-30 16:31:45 <mps> ikke: here is package() 'make install sbindir="$pkgdir/usr/sbin" mandir="$pkgdir/usr/share/man"'
2020-07-30 16:32:20 <ikke>         make install BINDIR="$pkgdir/usr/sbin" MANDIR="$pkgdir/usr/share/man"
2020-07-30 16:32:23 <ikke> this is what I saw
2020-07-30 16:32:40 <mps> ikke: in old ssldump?
2020-07-30 16:33:09 <ikke> the one now in aports
2020-07-30 16:33:20 <wsinatra> Anyone know if Carlo has nipped off on vacation or something? (curious about getting Nagios pushed through, but don't want to fuss if he's away)
2020-07-30 16:33:36 <ikke> wsinatra: he's kind of busy with some personal projects
2020-07-30 16:33:41 <mps> ikke: yes, but new is different
2020-07-30 16:33:53 <ikke> mps: ok, but then you need to check if you need to specify new directories
2020-07-30 16:34:06 <ikke> seems like they introduced some DOCDIR or something like that
2020-07-30 16:34:12 <mps> yes, looks like I have to patch Makefile
2020-07-30 16:34:30 <ikke> y u know DESTDIR :(
2020-07-30 16:34:42 <wsinatra> @ikke: I assumed it was something like that, I won't fuss then. Life comes first :)
2020-07-30 16:35:09 <mps> ikke: here is APKBUILD diff https://tpaste.us/1Oe9
2020-07-30 16:35:11 <ikke> wsinatra: I'll take a look it it
2020-07-30 16:36:15 <ikke> mps: docdir
2020-07-30 16:36:39 <mps> hehe, just added it
2020-07-30 16:37:03 <mps> but didn't worked :\
2020-07-30 16:37:08 <wsinatra> I appreciate it! 4.4.5 & .6 fix security issues that were present in 3.5.1, so it'd be nice to have updated
2020-07-30 16:37:19 <ikke> okl
2020-07-30 16:39:26 <mps> ikke: fixed, thanks for help
2020-07-30 16:39:37 <ikke> mps: yw
2020-07-30 16:44:20 <mps> hmm, 'tar tvf ~/packages/testing/x86_64/ssldump-doc-1.1-r0.apk | tpaste' => https://tpaste.us/pK0j
2020-07-30 16:44:57 <mps> do we put all these READMEs etc in -doc, or only man pages
2020-07-30 16:45:26 <maxice8> I think it is optional
2020-07-30 16:46:49 <mps> what to do with 'special' COPYRIGHT file, put it in main pkg or -dco
2020-07-30 16:46:58 <mps> huh, -doc
2020-07-30 16:49:05 <ikke> License goes in -doc
2020-07-30 16:50:44 <mps> sorry for spam again: 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
2020-07-30 16:51:06 <mps> from COPYRIGHT file
2020-07-30 16:56:19 <mps> maybe it is safe to not upgrade ssldump and keep it for private use
2020-07-30 16:56:32 <mps> or move to non-free
2020-07-30 17:00:34 <mps> I'll create MR with WIP tag, so someone more experienced in copyright can fix it
2020-07-30 23:31:23 <Ariadne> oh for fucks sake, the ethernet driver is missing too
2020-07-31 00:15:53 <Ariadne> +CONFIG_PCIE_LAYERSCAPE_GEN4
2020-07-31 00:15:56 <Ariadne> ....
2020-07-31 00:16:05 <Ariadne> that would be important
2020-07-31 00:20:22 <Ariadne> hmm PCI_LAYERSCAPE is set
2020-07-31 00:39:02 <Ariadne> damn, linux-lts does not have the pcie driver
2020-07-31 00:39:04 <Ariadne> ffs
2020-07-31 00:39:15 <Ariadne> 5.7 does tho
2020-07-31 07:17:58 <mps> Ariadne: 37b634590ce4df3d7c64a04c45bbe8dacb4f6c32
2020-07-31 07:18:20 <mps> -CONFIG_CC_HAVE_STACKPROTECTOR_SYSREG=y
2020-07-31 07:18:21 <mps> -CONFIG_STACKPROTECTOR_PER_TASK=y
2020-07-31 07:19:50 <mps> is this now default (by defconfing) or you intentionally 'removed' these two
2020-07-31 10:23:55 <maxice8> I wrote some lua scripts that call lua-aports https://github.com/maxice8/aports-helpers
2020-07-31 10:23:58 <maxice8> they might be useful for some people
2020-07-31 10:33:11 <ncopa> nice
2020-07-31 10:34:27 <ncopa> im gonna take down distfiles/git-old/dev.a.o for a few minutes. moving it to new host
2020-07-31 12:16:28 <ncopa> x86 builders, git-old/dev/distfiles(proxy) moved to new host. i will continue with bld2 (x86_64, distfiles.a.o backend) next week
2020-07-31 12:18:09 <Cogitri> 👍
2020-07-31 12:47:14 <wsinatra> @ikke: thank you so much for your help on the Nagios MR. I really appreciate it
2020-07-31 12:47:25 <ikke> wsinatra: you're welcome
2020-07-31 12:50:03 <wsinatra> Seriously, it's great timing. I pushed those changes on company time, and my boss has been anxious to see the results. They're new to FOSS, and I'm in a great position to show them why this kind of contribution is important
2020-07-31 12:50:49 <wsinatra> Which hopefully can mean more stuff being pushed into Alpine's repos with more consistent maintenance on my part :)
2020-07-31 12:50:56 <ikke> :)
2020-07-31 13:14:24 <Ariadne> mps: did not intentionally remove.
2020-07-31 13:14:36 <Ariadne> mps: maybe same issue as ppc
2020-07-31 13:15:26 <Ganwell> Cogitri: I wanted to switch from rustup to system-rust for development, but rust just isn't made for that. When I tried to build the missing tools like rustfmt, they needed nightly and I was back at rustup again.
2020-07-31 13:16:09 <Ariadne> anyway 5.7 supports honeycomb quite well
2020-07-31 13:16:13 <Ariadne> 5.4 not so much
2020-07-31 13:17:09 <ikke> Ganwell: so you need nightly builds for rust to do proper development?
2020-07-31 13:18:06 <mps> Ariadne: ok, will look tomorrow at it, hope will find some time for alpine
2020-07-31 13:18:43 <Cogitri> Ganwell: Yes, unfortunately because nightly is so easy to get with Rust lots of stuff needs it
2020-07-31 13:18:48 <Ariadne> sorry was focused on trying to get one of our kernels to work
2020-07-31 13:18:51 <Ganwell> ikke: yes some dev-tools only build with nightly. I checked distros, no-one has packages for those. :-(
2020-07-31 13:18:55 <Ariadne> verses the solid-run kernel
2020-07-31 13:18:56 <Cogitri> Although I could do fine with stable rust for my projects
2020-07-31 13:19:00 <Ariadne> which is quite old
2020-07-31 13:19:19 <Ariadne> I did succeed so :)
2020-07-31 13:19:29 <Cogitri> Yes, rust-nightly isn't really meant to be packaged by distros, it often doesn't build or is just badly broken
2020-07-31 13:19:46 <ikke> And still packages depend on it..
2020-07-31 13:19:58 <ikke> packages / programs
2020-07-31 13:20:41 <mps> Ariadne: np
2020-07-31 13:21:03 <mps> that's also happened to me some time ago
2020-07-31 13:22:01 <mps> and nice to know that we have more testers for linux-edge :)
2020-07-31 13:22:43 <Ariadne> well now it is my main kernel being used :)
2020-07-31 13:22:56 <mps> +1
2020-07-31 13:24:24 <Ganwell> ikke: its essential tools like rustfmt. At least the news spreading that x86_64-unknown-linux-musl can be a host and build-scripts are fixed accordingly. I hope tomorrow we will get a rust-docs component for musl.
2020-07-31 13:28:38 <Ariadne> anyway, on linux-edge i am able to boot to KDE on honeycomb using UEFI or petitboot
2020-07-31 13:30:07 <Ariadne> NIC drivers are uhh, a little missing on UEFI but :)
2020-07-31 13:31:38 <mps> NIC driver in UEFI?
2020-07-31 13:31:57 <mps> ah, you mean some data for NIC
2020-07-31 13:37:39 <Ariadne> yes, the firmware exposes information about the DPAA2 bus in UEFI, but Linux isn't yet hooked up to use it
2020-07-31 13:37:44 <Ariadne> linux 5.9 they say :)
2020-07-31 13:38:16 <mps> eh, so in two months :(
2020-07-31 13:38:42 <Ariadne> (DPAA2 is freescale's take on OpenCAPI, they expose things like 100G nics over it, and machine learning accelerators)
2020-07-31 14:48:37 <ollieparanoid[m]> hi! for some reason, the wlroots and sway packages for armhf point to the pre-musl1.2 rebuilt versions on http://dl-2.alpinelinux.org/alpine/edge/community/armhf/
2020-07-31 14:48:42 <ollieparanoid[m]> I thought only dl-cdn would have this problem
2020-07-31 14:51:41 <ikke> This is not a caching issue
2020-07-31 14:53:14 <ikke> ollieparanoid[m]: compare http://dl-t1-1.alpinelinux.org/alpine/edge/community/armhf/
2020-07-31 14:53:54 <ollieparanoid[m]> ikke: what's going on then?
2020-07-31 14:54:09 <ikke> good question, I'd have to investigate
2020-07-31 14:54:44 <ollieparanoid[m]> let me know if I can help. the result is the BAD signature errors, e.g. here: https://builds.sr.ht/~postmarketos/job/269757#task-pmbootstrap_build-540
2020-07-31 14:57:22 <ikke> ollieparanoid[m]: that's strange
2020-07-31 14:59:36 <ikke> ollieparanoid[m]: seems like the newest version of the package is not uploaded
2020-07-31 15:00:00 <ikke> hash on the mirror:
2020-07-31 15:00:02 <ikke> c694d6f3d65b6f1978a4ca39411f7bc1eebfc8ee0c6d65c337bf650bf31eb93cd2a7b5eda0b68d720cafd06f4a2753602d8a9cbc2ea37d48dd138b2ba2434a33
2020-07-31 15:00:13 <ikke> On the builder:
2020-07-31 15:00:15 <ikke> e5b832ebab043a89df378b50da6ea989974c510576cdcc237724cb3fc5f72c4566220d1601c7ef775e230042c80f8943a1c5f0e0db2d66678895d7edc475caa3
2020-07-31 15:00:42 <ollieparanoid[m]> weird
2020-07-31 20:36:04 <Ariadne> might have some more clues on the chromium issues btw
2020-07-31 20:36:47 <Cogitri> Neat
2020-07-31 20:37:02 <Cogitri> btw, do we support anything but http for remote repositories in apk?
2020-07-31 20:38:04 <mps> Ariadne: new 5.7 kernel is in my queue, just testing build on aarch64
2020-07-31 20:38:18 <Ariadne> Cogitri: yes, https :)
2020-07-31 20:38:30 <Ariadne> both kinds of music, country *and* western, etc
2020-07-31 20:39:38 <Cogitri> Ah well, counted that into http :)
2020-07-31 20:40:04 <Cogitri> Wanted to make sure that checking for http in a repo's url is sufficient to know that it's a remote repo
2020-07-31 20:40:30 <Ariadne> aports takes forever to check out the first time
2020-07-31 20:50:47 <Ariadne> mps: doing a kernel build myself to make sure this new build is kosher
2020-07-31 20:50:55 <Ariadne> (hw build that is)
2020-07-31 20:51:18 <mps> I just finished build
2020-07-31 20:51:28 <Ariadne> building a kernel with all hardware threads in use is a fairly reliable stress test i've found
2020-07-31 20:51:46 <mps> yes
2020-07-31 20:52:40 <mps> huh, I'm babbling on #alpine-linux and wasting time :)
2020-07-31 21:02:36 <mps> Ariadne: I pushed linux-edge upgrade to 5.7.12, feel free to fix if something is wrong or bad
2020-07-31 21:02:54 <Ariadne> sure, i'll upgrade once it hits
2020-07-31 21:17:10 <Ariadne> so here's an interesting one
2020-07-31 21:17:17 <Ariadne> chromium is stable on aarch64 with amdgpu
2020-07-31 21:17:27 <Ariadne> but crashy on x86_64 with amdgpu
2020-07-31 21:18:30 <Ariadne> ok this g510 keyboard is trash and has to go
2020-07-31 21:18:33 <mps> hmm, didn't know there are arm64 machines with amd gpu
2020-07-31 21:18:39 <Ariadne> yeah
2020-07-31 21:18:40 <Ariadne> there is
2020-07-31 21:18:42 <Ariadne> honeycomb :)
2020-07-31 21:18:48 <Ariadne> well, honeycomb can be any gpu
2020-07-31 21:18:57 <mps> nice to know
2020-07-31 21:19:04 <Ariadne> honeycomb is basically the arm equivalent to raptor's blackbird thingy
2020-07-31 21:19:50 <mps> looking ...
2020-07-31 21:20:53 <Ariadne> carrier board + processor card is only $800 for the 16-core option
2020-07-31 21:22:35 <mps> year of the arm on desktop
2020-07-31 21:23:09 <Ariadne> yeah my previous desktop dates back to the middle of the Obama administration
2020-07-31 21:23:23 <Ariadne> i decided that was going to be the last x86 desktop i ever bought (:
2020-07-31 21:23:33 <Ariadne> but talos is $$$$
2020-07-31 21:23:34 <mps> who is obama
2020-07-31 21:23:42 <Ariadne> uhh the president before trump
2020-07-31 21:23:45 <mps> president of usa
2020-07-31 21:23:48 <Ariadne> 2008-2016
2020-07-31 21:23:56 <mps> ah
2020-07-31 21:24:02 <Ariadne> last desktop was 2011
2020-07-31 21:24:16 <Ariadne> phenom 2 build
2020-07-31 21:24:34 <mps> I didn't bought desktop for more than a decade
2020-07-31 21:24:44 <mps> only notebooks and chromebooks
2020-07-31 21:24:52 <Ariadne> well you can't get 16-core smt in laptop form yet
2020-07-31 21:25:09 <mps> true, but I don't need them
2020-07-31 21:25:54 <Ariadne> everyone needs 16-core smt
2020-07-31 21:25:56 <mps> old/retired laptop was i7
2020-07-31 21:26:13 <Ariadne> average aports build is like 3x faster now
2020-07-31 21:26:21 <Ariadne> verses my i5 laptop
2020-07-31 21:26:38 <mps> I only need more RAM
2020-07-31 21:26:53 <Ariadne> but that laptop is starting to die, the battery is getting puffy and the ssd has a ton of dead blocks now
2020-07-31 21:27:20 <Ariadne> i could fix it, but i hate x86
2020-07-31 21:27:35 <Ariadne> would rather spend $$$ on things i like
2020-07-31 21:28:48 <mps> when I started to port rust to aarch64 and armv7 with my boxes with 4GB RAM it was so slow
2020-07-31 21:29:15 <mps> and FS on sd cards, imagine :)
2020-07-31 21:29:42 <mps> zram swap saved me