<    June 2018     >
Su Mo Tu We Th Fr Sa  
                1  2  
 3  4  5  6  7  8  9  
10 11 12 13 14 15 16  
17 18 19 20 21 _2_2 23  
24 25 26 27 28 29 30
00:06 mickibm joined
00:18 duncaen joined
01:07 rajivr joined
01:44 wener joined
01:55 <zava> UUID="4FAE-7F8B" /mnt/usb vfat user,umask=000,utf8,flush,noauto 0 0 same here. Still Operation not permitted
01:56 <zava> ill just make that stick a rootfs. should eventually be the same with some work
01:56 <zava> I think
02:35 mickibm joined
04:18 kolbyjack joined
04:52 kolbyjack1 joined
05:43 quasinoxen joined
06:06 mickibm joined
06:13 <ncopa> morning
06:13 <ncopa> tmh1999: xorriso : FAILURE : Cannot find in ISO image: -boot_image ... bin_path='/boot/merged.img'
06:13 <ncopa> stat: can't stat '/home/buildozer/packages/releases/s390x/alpine-standard-3.8.0_rc6-s390x.iso': No such file or directory
06:15 <tya99> morning ncopa
06:18 <tya99> ncopa: should i upgrade to 3.8rc6 in regard to that vlan thing i'm currently on 3.7
06:18 <tya99> if it effects 3.7 probably effects 3.8 and it would be nice to fix it before final release of 3.8
06:18 rdutra joined
06:20 <ncopa> i'll do my bets to fix it
06:20 <ncopa> best*
06:21 <ncopa> need to debug the recent update-kernel breakage and iso generation for s390x
06:21 <tya99> right
06:21 <tya99> just pm me when you want me to try something :)
06:22 <tya99> i guess when 3.8 comes out 3.7 would still be supported
06:22 <tya99> least if https://en.wikipedia.org/wiki/Alpine_Linux#Version_history that is anything to go by :P
06:22 <ncopa> yes, v3.7 will still be supported
06:41 wener joined
06:51 wener_ joined
06:53 <ncopa> >>> mkimage-s390x: Creating alpine-standard-3.8.0_rc6-s390x.iso
06:53 <ncopa> scripts/mkimage.sh: line 282: mk-s390-cdboot: not found
06:53 <ncopa> this is broken on so many levels...
06:58 kolbyjack joined
06:58 kolbyjack joined
07:04 mickibm left
07:05 mickibm joined
07:06 clemens3 joined
07:12 esainane joined
07:13 terrorjack joined
07:13 <ncopa> clandmeter: did you check if the nvram *.txt got included in the armhf rc6?
07:25 skarnet joined
07:29 <clandmeter> No
07:38 <skarnet> I missed the context, but "No" sounds right
07:38 <awilfox> " did you check if the nvram *.txt got included in the armhf rc6? "
07:39 <skarnet> I was pretty happy supporting clandmeter's "No" without context!
07:40 <clandmeter> context addendum: yes its included.
07:41 <awilfox> yeah, but now you can support it with context
07:41 mickibm joined
07:44 <clandmeter> ncopa, i was having issues yesterday with ipxe.
07:44 <clandmeter> not sure you tried it recently?
07:44 <clandmeter> something with OCSP verification.
07:45 <clandmeter> i wonder if i should simply disable it.
07:48 <ncopa> i havent tried ipxe lately
07:49 <ncopa> tmh1999: iso generate for s390x is broken. scripts/mkimage.sh: line 282: mk-s390-cdboot: not found
07:55 fekepp joined
08:06 _ikke_ joined
08:17 agowa338 joined
08:20 <ncopa> parted tests fails on s390x
08:20 <ncopa> the bsd label support does not seem to support big endian
08:21 <ncopa> i searched for patch in fedora for s390x
08:21 <ncopa> and they have 81(!) patches for parted...
08:21 <ncopa> lots of them seem to be related dasd
08:22 <_ikke_> fun times
08:22 <ncopa> i have been thinking of rewrite setup-disk in lua and make a libparted lua module
08:23 <ncopa> but i think that will not work :)
08:23 <ncopa> libparted is just broken apparently
08:23 <ncopa> some of the patches looks really scary, like "prevent segfault when resize vfat"
08:26 <agowa338> jirutka: The WSL Version is now in the store (unlisted, only accessible by link): https://www.microsoft.com/en-us/p/alpine-wsl/9p804crf0395 so if you want to have a look ;-)
08:29 <ncopa> agowa338: thats pretty cool
08:31 <agowa338> ncopa: Thanks, have you a windows device/vm by hand to test?
08:32 <ncopa> i have windows in vmware and my alpine workstation is also dualboot windows
08:32 <ncopa> the only thing i use windows for in practice is to run updates and antivirus
08:32 <ncopa> :)
08:33 <agowa338> ncopa: Ok, but if you have some time to spare, I would like to hear your opinion on how it looks and feels compared to native alpine ;-)
08:34 <ncopa> "time to spare" is an exceptionally rare animal around here....
08:35 <agowa338> ncopa: I know exactly what you mean. Than let me say it different: "If you feel like not doing what you're supposed to do and waste some time on something else". Does that sound better?
08:36 <ncopa> lol! it does :)
08:38 mercury^ joined
08:38 <agowa338> ncopa: I'm awaiting you're all feedback until I flip the switch to make it public (as in appears in the sore if you search Linux or Alpine)
08:40 <mercury^> ncopa: Hi. The APKBUILD for docker seems to want to enable seccomp support, but doesn't actually.
09:07 tty joined
09:19 <mps> need help with APKBUILD, abuild rootpkg wants to make -dev subpackage but it is not needed
09:19 <mps> how to disable that
09:19 <awilfox> you should have a line in the APKBUILD, subpackages=...
09:20 <awilfox> remove $pkgname-dev from that line
09:20 <mps> huh, I don't have subpackage in APKBUILD
09:22 <_ikke_> mps: MIght be that there are files that require a -dev package?
09:22 <mps> could you point me to some package in aports, I can look at it as sample
09:23 <mps> _ikke_: no, it is simple user space utility, simple-mtpfs
09:23 <mps> https://github.com/phatina/simple-mtpfs
09:24 <mps> here is the APKBUILD http://tpaste.us/WP8B
09:29 <mps> there is no some flag/var for APKBUILD to abuild 'do not make -dev' subpackage?
09:30 <mps> s/to abuild/to tell abuild/
09:30 <_ikke_> mps: -dev is also used for things like headers
09:31 <mps> undertand, but in this case (simple-mptfs) it is not needed
09:32 <_ikke_> mps: usually when you don't have subpackages, it will not try to create it, just complain about it when required
09:32 <awilfox> can you put the output of abuild in tpaste.us?
09:32 <awilfox> oh wait
09:32 <awilfox> subpackages="$pkgname-dev $pkgname-doc"
09:32 <awilfox> make that
09:33 <awilfox> subpackages="$pkgname-doc"
09:33 <mps> awilfox: that is. It works.
09:36 <mps> another question, simple-mtpfs.tar.gz is arhived with it's name twice in root dir
09:36 <mps> i.e. tar -tvf shows simple-mtpfs-simple-mtpfs-0.3.0
09:36 <mps> simple-mtpfs two times
09:38 <mps> so the unpacked it in aports it is src/simple-mtpfs-simple-mtpfs-0.3.0
09:38 <mps> should it be renamed after abuild unpack to src/simple-mtpfs-0.3.0
09:48 <algitbot> Issue (new): [Alpine Linux]: Package request: hstr - Bash and Zsh shell history suggest box: https://bugs.alpinelinux.org/issues/9027
10:20 <ncopa> mercury^: do you have suggestion to a fix?
10:21 <ncopa> mercury^: can you file a bug on bugs.alpinelinux.org with explanation how to reproduce what you see
10:34 <ncopa> clandmeter: I think i'm gonna push this to make it more clear what the intention is: http://tpaste.us/O4pV
10:43 <clandmeter> go ahead.
10:43 <clandmeter> i still dont 100% those scripts.
10:43 <clandmeter> understand*
10:47 <clandmeter> ncopa, I also dont like the current way the rpi fw is selected. it has a tight relation to the kernel but this relation is split in two places.
10:48 <clandmeter> maybe we should store the hash in the kernel apkbuild and update it when we bump kernel.
10:56 wener joined
11:00 <mercury^> ncopa: in short: docker info does not show seccomp under security options, although the kernel has CONFIG_SECCOMP=y; I have not tried to fix it myself, but I suppose that _runc_buildtags (with value "seccomp") is supposed to be used in building runc.
11:00 <mercury^> But instead that variable is set and then never used.
11:04 <mercury^> (I also cannot get apparmor to work with docker; unlike seccomp it is shown as enabled by "docker info", but docker neither loads its default profile, nor does it want to apply any profile to a process. But that seems to be more of an upstream bug.)
11:05 <ncopa> apk info -R docker shows that so:libseccomp.so.2 is linked
11:05 <ncopa> so i'd think its a config problem?
11:06 clemens3 joined
11:06 <mercury^> Perhaps, but I did not find any indication that one would have to manually enable seccomp. As far as I could gather it should work automatically as long as the kernel has seccomp support.
11:17 <mercury^> Hmm, runc has a BUILDTAGS variable in its Makefile that defaults to 'seccomp'; so perhaps the unused _runc_buildtags is a red herring.
11:39 <ncopa> clandmeter: it looks like it is possible to buy an rtc for rpi
11:40 <ncopa> https://wiki.alpinelinux.org/wiki/Saving_time_with_Hardware_Clock
11:46 agowa338 joined
11:54 <clandmeter> ncopa: ok?
11:54 <ncopa> meaning that we cannot assume that if kernel is rpi then there is no rtc
11:55 <ncopa> how did the rdate thing go?
11:55 <clandmeter> did we do that?
11:55 <clandmeter> i dont remember we selected it specifically for rpi
11:56 <clandmeter> i did a small test with rdate
11:56 <ncopa> i think we didnt, it just confirms it was correct thing to not do it
11:56 <clandmeter> it seems it fails most of the time.
11:57 <clandmeter> i wanted to test it with ipxe, but then i bumped into the next issue.
11:59 <clandmeter> ncopa: didnt you test ipxe recently with fetching an iso over http?
12:00 <ncopa> no
12:01 <clandmeter> ok ipxe seems to work again.
12:07 <clandmeter> ncopa: 2018-06-13 14:31:11 <ncopa> qemu-system-x86_64 --enable-kvm -m 1024 -cdrom http://boot.alpinelinux.org/alpine-ipxe/x86_64/ipxe.iso
12:08 wener joined
12:09 <ncopa> i got error
12:09 <ncopa> permission denied
12:09 <clandmeter> probably the same as i had
12:09 <clandmeter> im going to disable OCSP
12:15 <ncopa> ok, we can do rc7 now?
12:17 <clandmeter> do you think we can apply t hat patch tho hwclock?
12:18 <ncopa> ok
12:18 <ncopa> can you please push it?
12:18 <ncopa> with bumped pkgrel
12:18 <clandmeter> yes one min
12:18 <clandmeter> ill send it also upstream see what they say
12:19 <ncopa> good!
12:19 <clandmeter> hwclock is a dep right?
12:19 <ncopa> for some other serivce?
12:19 <clandmeter> yeah
12:19 <ncopa> i think so
12:19 <ncopa> don remember
12:19 <ncopa> looks like it isnt
12:20 <ncopa> i think you can simply rc-update del hwclock
12:21 <ncopa> food is ready and i wanted tag before lunch...
12:21 <ncopa> clandmeter: can you instead just rc-update del hwclock or do you still want push the patch?
12:21 <clandmeter> i cant do magic, sorry wrong channel :)
12:21 <clandmeter> i can test it
12:21 <clandmeter> but i dont think it will work?
12:22 <ncopa> why wouldnt it?
12:22 <clandmeter> doesnt initramfs put it back?
12:22 <clandmeter> or where does it come from anyways?
12:22 <ncopa> only first boot or if you dont have apkovl
12:23 <clandmeter> if you are sure then go ahead.
12:23 wener joined
12:23 <ncopa> it comes from initramfs init
12:23 <ncopa> im 95% sure
12:23 <clandmeter> :)
12:23 <ncopa> ok i'll tag it
12:23 <clandmeter> ill call your cell if it aint working!
12:24 <clandmeter> remember ignore it ;-)
12:24 <ncopa> i'll put my cell on silent :)
12:24 Topic for
12:25 <ncopa> ok. lunchtime
12:30 rdutra joined
12:32 <* clandmeter> rings ncopas cellphone
12:35 roliveira joined
12:35 <clandmeter> ncopa: http://tpaste.us/JgD1
12:36 <clandmeter> http://tpaste.us/8x88
12:38 <tya99> lol i just downloaded rc6 :P
12:38 roliveira left
12:38 <clandmeter> ah it provides clock and syslog and klogd depend on clock
12:39 <tya99> hmm yeah and i am still having issues with assigning ipv6 addresses to VLANs
12:39 <tya99> ncopa: has fixed the script from bitching
12:39 <tya99> but it seems to still not make link local addresses like it should
12:40 <tya99> https://dpaste.de/TuPL
12:40 <tya99> so im thinking its still not working properly
12:41 <tya99> the only error i see now when eth0.3 starts is
12:41 <tya99> Error: either "local" is duplicate, or "/64" is a garbage.
12:41 <tya99> eth0.4 comes up with a link local though and that's exactly the same as eth0.2 and eth0.3 (just with a different address)
12:43 <tya99> for eth0.3 it didn't even assign the primary address
12:50 <tya99> how should i get more debug information?
12:52 <tya99> on that script /etc/network/if-pre-up.d/vlan
12:53 <tya99> okay that is weird, i tried the same thing on my workstation (network wise) and i am getting link locals on every interface
12:53 fekepp joined
13:02 <clandmeter> ncopa: it seems openrc provides swclock, adding that to runlevel instead of hwclock fixes it.
13:02 <clandmeter> its even on the wiki :)
13:15 <ncopa> i wonder if we should try detect /dev/rtc from init.d and use swclock if its missing
13:16 <ncopa> from initramfs i mean
13:16 <clandmeter> yeah
13:17 <clandmeter> hwclock does have some logic for module loading.
13:17 <HRio> ncopa: can not add links to the wiki...
13:17 <clandmeter> HRio: new account?
13:17 <HRio> yes
13:17 <clandmeter> its normal
13:17 <clandmeter> need to wait for x hours.
13:17 <ncopa> i think its a feature
13:17 mickibm joined
13:18 <clandmeter> i think 6 or so
13:18 <HRio> was trying to add a warning about mdadm part types: https://raid.wiki.kernel.org/index.php/Partition_Types (i.e. add a link)
13:18 <ncopa> looks like rc7 didnt work
13:18 <clandmeter> oven is broken?
13:20 <HRio> K, I will do it an other day.
13:20 <clandmeter> HRio: or add it content without links and i can copy them.
13:21 <clandmeter> i think there is some feature to trust you, but mediawiki is such a pita.
13:24 <HRio> 0xda is a phonenumber according to media wiki as well :-0
13:24 clemens3 joined
13:25 <ncopa> i wonder if we can manually whitelist some users
13:25 <ncopa> i don tknow what broke with the rc7
13:28 <DrWhax> `/54
13:28 <DrWhax> scuzi
13:29 <HRio> Please read up on [https://raid.wiki.kernel.org/index.php/Partition_Types partition types], and why you should consider using 0xda instead of 0xfd. in chapter "Creating the partitions" on https://wiki.alpinelinux.org/wiki/Setting_up_a_software_RAID_array
13:34 mranweil_ joined
13:34 <HRio> clandmeter: can you help in adding that text?
13:35 <mercury^> ncopa: when I specify a seccomp profile manually, I get the error message from here: https://github.com/yongtang/docker/blob/master/daemon/seccomp_disabled.go
13:35 <mercury^> so the daemon is built without seccomp support.
13:35 <ncopa> mercury^: what version is it?
13:36 <ncopa> alpine version and docker version
13:36 <mercury^> alpine 3.7, docker 17.12.1-ce
13:36 <clandmeter> HRio: can you add the txt and add replaceme which i need to replace with a link.
13:37 <clandmeter> ah you cant save existing urls iu guess?
13:37 <clandmeter> then edit the part and tpaste it. ill replace it.
13:38 <ncopa> i'll tag 3.8.0_rc8 now
13:39 <ncopa> clandmeter: do you think we should hold rc8 for the rpi swclock issue?
13:39 <clandmeter> not really
13:39 <mercury^> By the way, if I want to contribute a package, should it be based on the master branch?
13:40 <clandmeter> its a feature. i dont think its important.
13:40 <ncopa> mercury^: yes
13:40 Topic for
13:41 <HRio> clandmeter: anything I write it complains its a phone number...
13:41 <tya99> at this rate rc9 will be out :)
13:42 <mercury^> And is it alright if I leave the Maintainer field empty?
13:42 <clandmeter> HRio: when you write?
13:43 <clandmeter> cant you edit the part you want to edit, copy the text to tpaste edit it and paste it to me.
13:45 <HRio> when I do "Save page"
13:45 <HRio> "Please read up on [https://raid.wiki.kernel.org/index.php/Partition_Types partition types], and why you should consider using 0xda instead of 0xfd." is the text
13:47 <tya99> hmm does anyone know what happened to the bcm2708-rng module?
13:48 <clandmeter> HRio: sorry i dont understnad what you want me to do.
13:49 <tya99> i think it's built into the kernel now
13:51 <HRio> clandmeter: sorry was AFK for bit
13:51 <HRio> I am trying to add the text above in the chapter "Creating the partitions" on this page https://wiki.alpinelinux.org/wiki/Setting_up_a_software_RAID_array
13:52 <clandmeter> then click edit, copy the text, edit it and pastbin it for me.
13:53 <HRio> https://pastebin.com/tW4J3THF
13:54 <clandmeter> ok?
13:54 <HRio> perfect! thx
13:57 <HRio> clandmeter: most mdadm howtos I have seen are lacking that ref, and then people risk getting them self into a bit of trouble when they later try to do an emergency recovery.
14:01 <clandmeter> nice, thx for adding it.
14:03 <clandmeter> ncopa: will you tag a stable apk-tools?
14:08 <tmh1999> ncopa: re s390x iso, please upgrade s390-tools packages on the builder, it needs r4 to build. currently it's r3.
14:12 <ncopa> i think its ok now
14:14 <tmh1999> ncopa: re parted, yes dasd disk devices are bitches.
14:15 <tmh1999> is it okay? I just check builder, its s390-tools is still r3.
14:15 <ncopa> rc8 s390x images are uploaded
14:15 <tmh1999> let me check if it works
14:15 <ncopa> i made them manually
14:15 <ncopa> so something may still be broken
14:15 <tmh1999> why dont upgrade s390-tools ? it's already built.
14:16 <ncopa> s390-tools are only installed when doing release and removed afterwards
14:16 <ncopa> so s390-tools is not installed
14:18 <ncopa> 3.8.0 does not boot in vmware for some reason
14:18 <mercury^> Has there been any consideration of reproducible builds for Alpine?
14:18 <tmh1999> I don't understand why we need to remove s390-tools. It contains the bootloader. If some how the machine is turned off, it can't boot again.
14:19 <tmh1999> s390x iso rc8 works.
14:20 <ncopa> mercury^: i have been thinking of it but not had time to actually work on it
14:20 <ncopa> tmh1999: i remove as much as possible from builders
14:21 <ncopa> but to be specific, we used to have mkinitfs installed
14:21 <ncopa> which is only needed when creating the iso, when making releases
14:21 <tmh1999> even bootloader ? do you want me to create s390-tools-zipl subpackage ?
14:21 <ncopa> it caused problems because it was linked to cryptsetup library
14:22 <ncopa> and when cryptsetup upgrade broke abi, things got problematic
14:22 <ncopa> so i removed everything not needed to boot and run the builder container, and only pull in the deps needed to generate the iso when the release i made
14:22 <_ikke_> mercury^: someone was experimenting with reproduducable builds a few days back
14:23 <tmh1999> understood. still above question about s390-tools-zipl, which will contains the zipl binary only for bootloader.
14:24 <ncopa> tmh1999: what was the question?
14:25 <tmh1999> ncopa: do you want me to split s390-tools with s390-tools-zipl package, which will only contain the zipl binary for the bootloader? Just to be safe.
14:26 <tmh1999> or maybe later. anytime.
14:27 <ncopa> i dont understand why not ship it with s390-tools?
14:28 <mercury^> ncopa: in setup-disk, you might want to move the part that deals with a mounted root below the EFI configuration and remove the part where it installs syslinux.
14:29 <ncopa> mercury^: does it install syslinux on EFI installs?
14:29 <mercury^> ncopa: yes.
14:30 <ncopa> does it need syslinux for soemthing?
14:30 <ncopa> i guess it doesnt
14:30 <mercury^> ncopa: I don't think so.
14:30 <mercury^> ncopa: and it refuses to install GRUB.
14:30 <tmh1999> ncopa: Ahhh, my bad. I thought zipl/bootloader binary must be installed in order to boot. My bad. It already wrote booting info (kernel, initrd, etc.) on the disk. So everything's cool :)
14:31 <mercury^> ncopa: when I had fixed it for my installation it worked.
14:31 <mercury^> (without syslinux)
14:32 <mercury^> ncopa: also, why does setup-disk install GNU acct?
14:34 <mercury^> It would be nice also if you could specify that no bootloader be installed at all. Currently there is no efibootmgr so I have to configure the boot process from another system anyway.
14:35 <ncopa> i think acct is used by mkinitfs for some boot performance measuring
14:35 <mercury^> Ah. I had removed it because I could not figure it what it was there for.
14:35 <mercury^> figure out*
14:35 <ncopa> i dont think we need install it by default
14:36 <ncopa> but would prefer not touch any of that til after v3.8
14:37 <ncopa> dealing with bootloader for setup-disk may need som more work
14:37 <ncopa> what worries me a bit more is that the iso does not boot in vmware
14:38 <mercury^> Ah, the 3.7 iso also did not boot on a MacBook Pro 5,3 for me. But that is probably unrelated?
14:39 <mercury^> I just created a bootable image and copied over the files.
14:39 agowa338 joined
14:43 <mercury^> That MacBook by the way has some hardware which is not supported by the shipped kernels. I do not (terribly) mind compiling my own kernels anyway, but for the installer it may be convenient to add as many drivers as possible. (I would not have been able to adjust the backlight brightness before installing my own kernel, for example.)
15:00 <mercury^> ncopa: is the docker issue on your agenda or should I create a issue on the bugtracker? (Can I do that without creating an account there?)
15:04 <ncopa> i think you can create bug anonymous via email
15:06 <mercury^> Category Security or Aports?
15:07 <algitbot> Issue (new): [Alpine Linux]: Docker has no seccomp support: https://bugs.alpinelinux.org/issues/9028
15:54 <HRio> ncopa: shall this be included before release you think? https://github.com/alpinelinux/aports/pull/4565
15:55 <HRio> or shall we hold it until right after?
16:31 wener joined
17:00 <tmh1999> thanks jirutka.
17:33 prspkt joined
17:35 mickibm joined
17:50 wener joined
18:15 clemens3 joined
18:23 <mickibm> @ncopa: something is fishy with ppc64le console access. it actually seems that in order to get a login prompt, i have to provide a apkovl. without and apkovl, the console=hvc0 works instead of ttyS0... something must be missing but the apkovl has it?
18:32 <mickibm> Using these kernel commands with rc8, i did not get a login console: modules= ip= powersave=off alpine_repo=dl-cdn.. modloop= ... so is the use case for booting on bare metal ppc64le just suppose to also include console=hvc0 ?
18:55 <mickibm> @ncopa: I've shared my ppc64le test results more clearly in https://github.com/alpinelinux/aports/pull/4566
19:32 dnull joined
19:53 HRio joined
20:01 <kaniini> ppc64le console works fine for me on bare metal fwiw
20:06 agowa338 joined
20:25 mickibm joined
20:37 <kaniini> mickibm ppc64le console works fine for me on bare metal fwiw
20:42 <mickibm> @kaniini: using rc8? what were your kernel commands?
20:44 <kaniini> mickibm on an ibm s822l, i just put the ISO in and booted with petitboot. kernel commands were the default on the ISO.
20:44 <kaniini> (this is PowerNV though, maybe it is broken on KVM)
20:45 <mickibm> kaniini: interesting... i have been doing a net boot on bare metal - adding a new boot option in petitboot and using these: http://dl-master.alpinelinux.org/alpine/v3.8/releases/ppc64le/netboot-3.8.0_rc8/
20:46 <kaniini> weird, i don't even know why one would want to netboot, since you have virtual media on the bmc
20:46 <kaniini> i guess for automation reasons
22:00 tmh1999 joined
22:21 <azarus> Why does heirloom-doctools conflict with util-linux?
22:21 <azarus> kinda want to have both installed :/
23:47 cfriedt joined
23:50 <cfriedt> Hola compadres. I have a question about the apkbuild file. I have a package that has various installation targets for supporting different programming languages. I want to split them all off as subpackages. The main package is for c++ support. One subpackage is for go support. It would seem silly to make the main package depend on go, but it would make sense for the subpackage to depend on go. Is that possible with the current
23:55 staticfloat joined
23:58 <staticfloat> Hello all, I'm fairly new to Alpine linux, and I'm trying to get `apk` to install `x86` and `x86_64` versions of `musl` side-by-side on the same system, but when I convince `apk` to install a different arch version of `musl`, it removes the original arch version. Is `apk` not meant to be used with multiple architectures at once? If so, is there a
23:58 <staticfloat> commonly-accepted way to configure a system that can run prebuilt `i686` and `x86_64` binaries at the same time? Thanks!