2023-11-01 00:04:18 <omni> nope, not it =(
2023-11-01 01:21:35 <bl4ckb0ne> anybody caught the latest qutebrowser update failure?
2023-11-01 01:21:38 <bl4ckb0ne> > RuntimeError: the sip module implements ABI v13.0 to v13.5 but the PyQt6.QtCore module requires ABI v13.6
2023-11-01 01:25:54 <bl4ckb0ne> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/54472 seems it was forgotten
2023-11-01 02:08:11 <Saijin_Naib[m]> Is there an admin/logged in view for pkgs.alpinelinux? I'd be really interested in seeing what of our packages have release-monitoring assocations
2023-11-01 02:08:21 <Saijin_Naib[m]> I add those when I can't sleep
2023-11-01 02:08:44 <Saijin_Naib[m]> Or if not, how much work would an extra column with even just a checkbox be to implement on pkgs?
2023-11-01 02:15:21 <celie> I think chereskata had a shell script for that
2023-11-01 02:16:35 <celie> Saijin_Naib[m]: https://github.com/chereskata/alpine-linux-apk-check/blob/master/check_release_monitoring.sh
2023-11-01 02:17:08 <omni> bl4ckb0ne: that must've been the py3-qt6 upgrade and I missed the issue since I switched back to qt5
2023-11-01 02:18:58 <bl4ckb0ne> the issue is fixed on my side with the package
2023-11-01 02:20:51 <celie> Btw, Saijin_Naib[m], have you looked into freedoom, your MR to adopt it has been merged, and we fixed new Python Pillow compatibility for you, but there are still errors about missing files, probably game related images, but they don't cause the build to fail
2023-11-01 02:33:42 <omni> bl4ckb0ne: I managed to catch it after you said it, before I got the new py3-pyqt6-sip package
2023-11-01 02:34:04 <omni> but now I'm running with Qt6 again and experience is actually pretty snappy
2023-11-01 02:44:39 <bl4ckb0ne> there's an even newer version?
2023-11-01 02:46:38 <omni> no, I just hadn't upgraded to py3-pyqt6-sip-13.6.0-r0 yet
2023-11-01 04:33:02 <Saijin_Naib[m]> <celie> "Btw, Saijin_Naib, have you..." <- I have not yet, no. It might take me a bit to poke at it.
2023-11-01 04:35:24 <celie> No problem, probably if someone else finds a problem in it first they'll open an issue or something
2023-11-01 04:36:17 <Saijin_Naib[m]> Hopefully! Last I used it, it seemed to work just fine, so this will be fun to explore 🤣
2023-11-01 09:43:21 <omni> building qt6-qtwebengine seems to work fine on the aarch64 CI builder !54509, I don't know why it won't on the package builder
2023-11-01 11:23:47 <ikke> bootstrapping openjdk11 on x86_64
2023-11-01 11:47:04 <ikke> omni: perhaps core/cpu ratio difference?
2023-11-01 11:47:14 <ikke> cpu/memory
2023-11-01 12:43:11 <WhyNotHugo> Any feedback for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/46656 ?
2023-11-01 12:55:31 <minimal> WhyNotHugo: well I recently mentioned it in a conversation in a related MR !54065 ;-)
2023-11-01 12:57:41 <minimal> It would be useful to have a common mechanism to "react" to both kernel and initramfs changes
2023-11-01 12:58:38 <WhyNotHugo> minimal: pmOS has as directory with "triggers", and packages install a new file on each version update into this directory, which triggers a hook...
2023-11-01 12:58:46 <WhyNotHugo> Honestly, it sounds very hacky to me, but it works.
2023-11-01 12:59:17 <WhyNotHugo> mostly mentioning it as prior art)
2023-11-01 12:59:26 <minimal> I'm not just thinking about "triggers" related to package updates though
2023-11-01 13:00:17 <minimal> i.e. if I manually run mkinitfs which changes the /boot/initramfs file then if I'm using UKI or EFISTUB then I'd like the relevant file(s) in the ESP partition to be updated
2023-11-01 13:00:17 <WhyNotHugo> What else could require an initfs update?
2023-11-01 13:01:04 <WhyNotHugo> I don't think that you should run mkinifs manually and expect the UKI to be rebuilt; you should manually run a script which itself runs mkinitfs and the rest of the process.
2023-11-01 13:01:21 <minimal> in the case of UKI booting that would require the "secureboot-hook" script ot be run to rebuild the UKI file, for EFISTUB it would involve copying the updated initramfs file across to the ESP
2023-11-01 13:01:47 <WhyNotHugo> apk fix kernel-hooks would actually run mkinifs and then the secure-book hoot.
2023-11-01 13:02:06 <minimal> that's a manual step
2023-11-01 13:03:14 <WhyNotHugo> If you manually rebuild the mkinitfs and expect the UKI to be rebuilt you have to options: (1) add some post_build hook to mkinitfs, or (2) have a daemon monitoring the initfs for changes.
2023-11-01 13:03:53 <minimal> ...and repeat the same for booster and dracut?
2023-11-01 13:04:23 <WhyNotHugo> The problem with either approach is that if you update some package whose files end up in the initfs, you still don't have a mechanism which rebuilds the initfs automatically.
2023-11-01 13:05:01 <WhyNotHugo> It's easier to do 'mkinitfs && rebuild-uki'
2023-11-01 13:05:10 <minimal> my point being that both /vmlinuz and /boot/initramfs should directly reflect what is actually used for booting, so if either of those files change in any fashion then the boot files (if they are not directly those 2 files) should be auto-updated accordingly
2023-11-01 13:06:17 <WhyNotHugo> What if I cp /home/hugo/custom-vmlinuz /boot/vmlinuz?
2023-11-01 13:07:15 <minimal> then what I already said should happen
2023-11-01 13:07:42 <minimal> and if it then causes boot problems well the same sort of thing would happen if you did that on a grub-based system
2023-11-01 13:09:01 <WhyNotHugo> For that, you need a dedicated daemon using something like inotify. Honestly, I dislike the general idea.
2023-11-01 13:09:10 <minimal> also for EFISTUB booting the /boot/vmlinuz and /boot/initramfs files need copied across to the ESP partition automatically on change (assuming ESP is not mounted as /boot)
2023-11-01 13:09:39 <minimal> also need to add changing ucode files into the mix as well ;-)
2023-11-01 13:10:20 <WhyNotHugo> A problem with using files in /boot/ as input for building the UKI is the files are unsigned and unencrypted (e.g.: extremely easy targets), so it completely negates the use of secureboot.
2023-11-01 13:11:44 <minimal> I didn't mention secureboot - UKI does not specifically mean secureboot - UKI can be used either signed or unsigned
2023-11-01 13:12:44 <minimal> also who says the files in /boot are unencrypted? /boot could be on LUKS (whether as part of / or as a separate /boot filesystem)
2023-11-01 13:13:20 <WhyNotHugo> I was assuming that /boot was the ESP.
2023-11-01 13:14:55 <WhyNotHugo> For what you're aspiring to do, I think that only a daemon monitoring the files is feasible.
2023-11-01 13:15:12 <minimal> ok, it isn't for me and I don't remember whether setup-disk mounts it as /boot or /boot/efi
2023-11-01 13:17:22 <WhyNotHugo> Back to the topic of this MR: I'd like to see this move forward because it allows ordering of operations triggered on kernel update. So I'm mostly looking for feedback on what could be improved to move it forward.
2023-11-01 13:20:09 <minimal> well my comments were relating to the MR as that covers the 1st part of what I mentioned (changes triggered by package updates) rather than the 2nd part (changes trigger by "general" file updates)
2023-11-01 13:21:41 <minimal> so we've got syslinux/grub/limine/u-boot/efistub/uki bootloaders and mkinitramfs/booster/dracut initramfs generators so we really should come up with a solution that handles as many of the various combinations of those as possible
2023-11-01 13:27:17 <WhyNotHugo> kernel-hooks can cover all of them, but the main downside is that [currently] it only executes when the kernel is updated.
2023-11-01 13:27:57 <WhyNotHugo> I think that triggering it when other packages update it a good idea, but I don't like the idea of automatically triggering on file update.
2023-11-01 13:33:10 <minimal> well it is called kernel-hooks ;-) yes it only executes when the kernel updates, and a kernel update in itself will active the mkinitramfs/booster/dracut triggers to regen the initramfs so a kernel-hooks script could also cater to that by *inaccurately* guessing how long to wait for whichever initramfs generator is installed to do its work also (or just check the timestamp of the initramfs file until it changes?)
2023-11-01 13:58:24 <WhyNotHugo> I dislike the file-watching approach. It's too "magic" and too likely to fail in some unexpected way. It doesn't enforce ordering of operations.
2023-11-01 13:59:33 <minimal> well the kernel file and initramfs file are "managed" by different packages so how would you enforce ordering?
2023-11-01 15:24:39 <chereskata> Hi, could someone merge or comment upon !54233, !54063, !53742, !52683 
2023-11-01 16:05:18 <chereskata> Can someone emergency merge !54564, because it resolves a circular dependency issue with libreoffice in its current build. I have erroneously updated it alone :/
2023-11-01 16:36:38 <omni> I'm not sure we need to downgrade it
2023-11-01 16:36:55 <chereskata> I can also just skip libreoffice rebuild
2023-11-01 16:37:00 <chereskata> As it is upgraded anyway
2023-11-01 16:37:18 <chereskata> edge is a test branch after all :D
2023-11-01 16:42:10 <chereskata> everything done
2023-11-01 18:10:52 <omni> I think !54531 is ready but I would prefer if it went in after !53277 so we don't have to rebuild libreoffice again
2023-11-01 18:11:41 <omni> and I added -doc sub-packages and want to see how that goes and it also hadn't run on a couple of arches yet
2023-11-01 18:17:28 <omni> ikke: your guess is better than mine
2023-11-02 06:22:48 <ikke> omni: builder has more memory per core as CI
2023-11-02 06:23:59 <ikke> 256G on the builder, should be plenty
2023-11-02 09:54:14 <WhyNotHugo> Does the builder just use tmpfs as a working filesystem?
2023-11-02 09:56:52 <ikke> Builders not 
2023-11-02 10:00:19 <WhyNotHugo> Why not? 
2023-11-02 10:21:55 <skarnet> I suspect, some stuff's output is too big so tmpfs would use too much ram?
2023-11-02 10:56:01 <WhyNotHugo> You'd use more RAM, but also likely reduce the disk IO bottleneck. So maybe less concurrent builds, but more builds-per-hour.
2023-11-02 11:19:56 <ikke> I've also had test suites fail on tmpfs because it behaved differently / not implemented everything
2023-11-02 11:32:52 <omni> ikke: !52680
2023-11-02 11:33:11 <omni> it's protected
2023-11-02 11:33:16 <celie> omni: While you're on the topic of taking over related aports, perhaps you could look into h2o, it is used by dnsdist
2023-11-02 11:35:08 <ikke> omni: unprotected now
2023-11-02 11:36:31 <omni> thanks
2023-11-02 11:36:52 <omni> celie: I don't think I use any of them?
2023-11-02 11:37:51 <omni> or you mean to suggest for Peter to take over h2o?
2023-11-02 11:41:07 <celie> Yes, that's what i mean
2023-11-02 11:52:36 <Habbie> hello
2023-11-02 11:52:55 <celie> Hi!
2023-11-02 11:53:01 <Habbie> while i'm happy to do that (i also do it for openwrt), we hope to release dnsdist 1.9.0 soon which will no longer require h2o
2023-11-02 11:53:15 <Habbie> if h2o needs love after that in a released alpine, of course i'll fix it
2023-11-02 11:53:24 <celie> Alright
2023-11-02 11:53:42 <Habbie> if it makes sense to stick my name on the port for that, that's fine with me :)
2023-11-02 11:56:46 <Habbie> btw, the netdata port pulls in h2o directly from github; i don't see an update for the http/2 CVE in there
2023-11-02 11:59:42 <celie> Do you mean adding CVE-2023-44487 to the secfixes section of netdata, or are you talking about patching the h2o it pulls from Github?
2023-11-02 12:01:42 <Habbie> patching it, or pointing h2o_commit to a fixed version
2023-11-02 12:01:47 <Habbie> and then adding it to secdata, i suppose, yes :)
2023-11-02 12:03:36 <ikke> hmm
2023-11-02 12:04:04 <celie> I wonder why netdata upstream hasn't updated the h2o commit, it's still pointing to a commit from 2019
2023-11-02 12:04:29 <Habbie> oh i know why that is
2023-11-02 12:04:34 <Habbie> h2o master is not compatible
2023-11-02 12:04:40 <Habbie> and h2o stopped doing releases at all
2023-11-02 12:05:05 <Habbie> the only reason there's even a fix on that branch from 2019 is that we submitted it to them :)
2023-11-02 12:05:37 <Habbie> ah, the good news is that that means the netdata bump is easy
2023-11-02 12:06:17 <Habbie> https://github.com/h2o/h2o/commits/v2.2.x
2023-11-02 12:06:21 <Habbie> they're literally only two commits behind on this
2023-11-02 12:15:51 <celie> ikke, Habbie: I've done that in !54622, let me know if i've missed anything
2023-11-02 12:16:37 <ikke> celie: maybe add a comment that the _h20_commit does not follow upstream in the APKBUILD file
2023-11-02 12:16:55 <ikke> I use the _submodule_commits script to fetch the matching commits
2023-11-02 12:18:41 <Habbie> celie, looks right to me
2023-11-02 12:18:54 <Habbie> upstream should get the same change, of course
2023-11-02 12:18:58 <Habbie> or drop h2o, like everybody should, really :/
2023-11-02 12:19:29 <omni> and maybe that should be backported to 3.18 too?
2023-11-02 12:19:33 <Habbie> yes
2023-11-02 12:22:08 <celie> I've added the comment
2023-11-02 12:23:01 <ikke> thanks
2023-11-02 12:23:41 <celie> You're welcome
2023-11-02 12:24:22 <celie> However, i can't find a reference to h2o in the 3.18 netdata APKBUILD, maybe they were using some other HTTP server back then?
2023-11-02 12:25:11 <Habbie> oh indeed
2023-11-02 12:25:16 <celie> https://github.com/netdata/netdata/tree/v1.38.1/web/server
2023-11-02 12:25:18 <Habbie> it was added after 3.18
2023-11-02 12:25:35 <Habbie> right
2023-11-02 12:25:42 <omni> so they did the opposite of what you would suggest? :D
2023-11-02 12:27:10 <Habbie> yes :>
2023-11-02 12:27:48 <celie> https://github.com/netdata/netdata/commit/66c47355 seems to be the commit that introduced h2o
2023-11-02 12:28:09 <celie> It says "as an alternative"
2023-11-02 12:28:12 <omni> but if dnsdist is the only thing that currently depend on the h2o aport, that has no maintainer and upstream have stopped doing releases, perhaps h2o should be dropped after dnsdist stops depending on it?
2023-11-02 12:28:20 <Habbie> omni, yes
2023-11-02 12:28:29 <Habbie> omni, if you make me maintainer, i can promise that that is what will happen :D
2023-11-02 12:28:35 <ikke> celie: that link is broken
2023-11-02 12:28:37 <Habbie> and if not i'll file the MR anyway
2023-11-02 12:29:39 <celie> https://github.com/netdata/netdata/commit/66c47355b
2023-11-02 12:29:41 <ikke> If h20 is just an alternative, I'm in favor of droppinng it
2023-11-02 12:30:20 <celie> Must have hit that an ambiguous Git commit hash or something
2023-11-02 12:30:54 <omni> Habbie: or, when upgrading dnsdist, you could remove it in the same MR and explain why, we may not need to make you the maintainer in the meantime
2023-11-02 12:31:00 <Habbie> yeah
2023-11-02 12:31:02 <Habbie> seems fine to me
2023-11-02 12:35:21 <ikke> seems no longer optional
2023-11-02 12:40:05 <celie> There seems to be a --disable-h2o configure option, but maybe some users have come to rely on that
2023-11-02 12:40:42 <Habbie>  source="$pkgname-$pkgver.tar.gz::https://github.com/netdata/netdata/archive/v$pkgver.tar.gz
2023-11-02 12:40:47 <Habbie> i guess this doesn't include submodule contents?
2023-11-02 12:42:06 <ikke> Habbie: correct, you need to get them seperately
2023-11-02 12:42:13 <Habbie> ack
2023-11-02 12:42:15 <Habbie> how annoying :)
2023-11-02 12:51:16 <omni> now that poppler upgrade is in !54531
2023-11-02 12:53:03 <omni> or, actually, let me try to rerun the CI builds with the new poppler...
2023-11-02 12:54:14 <omni> but maybe someone could comment on there being any benefits of running autogen.sh for libxion and liborcus
2023-11-02 14:44:42 <nmeum> does anybody know if OpenRC upstream still considers supervise-daemon(8) to be "experimental"? I think previously this was mentioned in the man page but I can't seem to find that statement anymore
2023-11-02 14:50:42 <ikke> ayakael: dotnet6-build fails: "Unable to find toolchain executable.  Name: ar, Prefix: llvm-.
2023-11-02 14:50:44 <ikke> "
2023-11-02 14:50:54 <ikke> possibly related with the upgrade to llvm17
2023-11-02 15:07:11 <sam_> nmeum: https://github.com/OpenRC/openrc/commit/18e53f7fed1a92dd6dc91e79ab620d22fee1e195
2023-11-02 15:15:48 <ncopa> ayakael: i think prefix should be `llvm${_llvmver}-` instead of `llvm-`, bu i have no idea how to set it
2023-11-02 15:17:31 <ncopa> alternatively we could set the PATH
2023-11-02 15:48:05 <ncopa> i fixed it in 4bcd271b699e3f15c5ae598273e4fa64d2a4d49f
2023-11-02 16:10:07 <ikke> scudo_mallocs test suite takes quite some time
2023-11-02 16:21:37 <chereskata> could someone merge !53742
2023-11-02 16:23:24 <chereskata> I have a MR (!54233) open to upgrade xdg-desktop-portal-gtk. Is the settings portal needed for anything on alpine?
2023-11-02 16:25:48 <ikke> ideally itoffshore would approve it
2023-11-02 17:57:53 <nmeum> sam_: ah, thanks! I guess we should also reconsider usage of supervise-daemon for our OpenRC services then
2023-11-02 17:59:47 <ikke> There would still be maintainers who would oppose enabling supervise-daemon by default for aports
2023-11-02 18:00:20 <skarnet> indeed
2023-11-02 18:01:38 <skarnet> supervise-daemon is a half-baked solution, why put in the effort to switch to it when there is already a fully baked solution that you've been offered help with time and time again
2023-11-02 18:04:46 <durrendal> skarnet: is there anything preventing adoption of s6 from a technical standpoint? 
2023-11-02 18:05:46 <skarnet> as a full replacement for openrc? yes, the service manager isn't powerful enough (I'm working on it). As a replacement for supervise-daemon? not at all, it's been there all along.
2023-11-02 18:07:40 <ikke> skarnet: do you have documentation somewhere how that would be implemented?
2023-11-02 18:09:42 <skarnet> ... you mean the whole s6 documentation? yeah, it exists :P
2023-11-02 18:10:04 <durrendal> LOL maybe an example of how you'd use s6-suprvise in lieu of supervise-daemon?
2023-11-02 18:10:25 <skarnet> if you mean, a plan to migrate long-running openrc services under s6 instead of supervise-daemon, I don't have specific documentation for this, but I can probably work on it
2023-11-02 18:11:49 <skarnet> to migrate to supervise-daemon you'll need to get familiar with supervision anyway
2023-11-02 18:12:01 <skarnet> once you are, the rest is implementation details
2023-11-02 18:15:11 <durrendal> I would definitely be interested in even just a rough example, like how you'd use s6 to handle nginx or something
2023-11-02 18:15:28 <durrendal> this might just be me, but it helps to grok things in a familiar setting
2023-11-02 18:16:18 <Ermine> As far as I understand, openrc needs to be taught how to generate s6 service dirs first
2023-11-02 18:19:05 <ikke> skarnet: what durrendal mentioned
2023-11-02 18:19:13 <ikke> I know the replacement of openrc is in the works
2023-11-02 18:19:31 <ikke> Was just interested how you would use what exists today as replacement for supervise-daemon, like you mentioned
2023-11-02 18:19:52 <skarnet> sure
2023-11-02 18:19:54 <skarnet> I can do that
2023-11-02 18:20:21 <skarnet> I have a huge release to get out first, but once it's done, I can work on that
2023-11-02 18:21:01 <ikke> sure, no hurry
2023-11-02 18:21:34 <Ermine> There's a plenty of time until 3.20 anyway
2023-11-02 18:21:44 <durrendal> I look forward to it ^^ I'd love to test it out personally
2023-11-02 18:22:29 <skarnet> what I'll need is a requirement list: how exactly do you intend to set up your services, and in particular what you intend to do with logs
2023-11-02 18:22:47 <skarnet> so far it's syslogd-only, anything else goes to /dev/null
2023-11-02 18:23:11 <skarnet> with ad-hoc exceptions for certain services
2023-11-02 18:23:29 <skarnet> but I suspect it's done that way because it's all OpenRC can manage easily
2023-11-02 18:24:18 <skarnet> s6 can set up a more flexible logging system, but it's also possible that you'll want to keep to syslog to avoid changing the UX
2023-11-02 18:25:00 <durrendal> would a current openrc script work for that? I'm thinking in the context of my website which is lua-lapis + openresty currently. with logging via syslog-ng, so nothing fancy
2023-11-02 18:26:15 <durrendal> when you say it can be more flexible, do you mean it could integrate with something like Grafana Loki directly? Or something different? 
2023-11-02 18:26:24 <durrendal> I'm super curious, s6 sounds fascinating 
2023-11-02 18:29:53 <ikke> skarnet: I guess you'd use s6-supervise as supervisor, but is there more needed?
2023-11-02 18:30:08 <skarnet> durrendal: I have no idea how Grafana Loki, or any other fancy-named tool, works, but s6 can set up a dedicated logger for each service, piping it into your engine directly, or archiving it locally with automatic rotations and possibility of triggering processing on rotation
2023-11-02 18:30:10 <ikke> supervisor=s6
2023-11-02 18:31:24 <skarnet> ikke: if you want to use the very meh way of doing it that openrc folks wrote without once saying hello to the s6 community, sure
2023-11-02 18:31:30 <skarnet> but there's a better way ;)
2023-11-02 18:31:32 <ikke> :)
2023-11-02 18:31:40 <ikke> ok, I'll wait for the documentation :)
2023-11-02 18:31:45 <Ermine> and it didn't work the last time I tries it
2023-11-02 18:31:53 <Ermine> s/tries/tried/
2023-11-02 18:43:49 <durrendal> skarnet: to me it sounds like s6 could replace syslog + logrotate with it's logging engine, which is extremely interesting
2023-11-02 18:44:06 <durrendal> I'm excited for that documentation as well :)
2023-11-02 18:46:10 <skarnet> yes, it does replace syslog+logrotate when you're setting up dedicated loggers
2023-11-02 18:46:31 <ikke> skarnet: personally I don't mind replacing syslog
2023-11-02 18:46:53 <skarnet> and you can already read the s6 documentation, it's not a *migration guide*, but there's an overview giving an intro to supervision
2023-11-02 18:47:04 <ikke> I've just read it
2023-11-02 18:47:24 <skarnet> was talking to durrendal, but you're welcome to it as well :D
2023-11-02 18:47:28 <ikke> at least, the high-level overview
2023-11-02 18:48:10 <durrendal> :) I will definitely read through the s6 docs!
2023-11-02 18:48:12 <skarnet> yeah the overview is really the first thing to read, the rest is mostly reference
2023-11-02 18:56:50 <vkrishn> skarnet: if you plan to document s6 in pmwiki, i can help in installing+formatting wiki text
2023-11-02 18:59:06 <skarnet> thanks, we'll see later :)
2023-11-02 20:29:12 <ikke> omni: I think the issue is that I have VMs runining for CI on the same host that use memory, so less memory available in total
2023-11-02 21:07:42 <omni> ikke: and there's more to build than usual?
2023-11-02 21:07:55 <ikke> qt5-qtweb*
2023-11-02 21:08:05 <ikke> they eat memory for breakfast, lunch and dinner
2023-11-02 21:08:20 <ikke> The builder is hardly responding right now
2023-11-02 21:08:21 <ikke> the host
2023-11-02 21:09:50 <ikke> similar for qt6-qtwebengine
2023-11-02 21:10:24 <omni> and I just pushed new commits to qt?-qtwebengine MRs...
2023-11-02 22:02:09 <khem> ikke: yeah webengine has chromium bundled in 
2023-11-02 22:02:36 <khem> ikke: how much muscle does the builder has ?
2023-11-02 22:03:03 <ikke> 256G mem and 80 cores
2023-11-02 22:03:42 <ikke> But part of it is used by 3 vms that we temporarily setup for CI
2023-11-02 22:04:18 <khem> yeah thats a beefy one but chromium can keep it busy 
2023-11-02 22:05:21 <ikke> it's taking more then an hour just to render the output of `ps`
2023-11-02 22:05:25 <khem> my builder has 40 cores and 256G DDR4 and chromium 117 takes 2+ hrs to build and qtwebengine 6.6 takes around 1 hr 
2023-11-02 22:05:43 <ikke> The issue is not the time, but it running out of memory
2023-11-02 22:06:13 <khem> yeah usually 4G per core works out ok 
2023-11-02 22:06:29 <khem> by that math you need 320G
2023-11-02 22:07:49 <khem> another area is parallelism in compression like xz zstd etc. if threading is enabled they can consume quite a bit of memory too while running
2023-11-03 01:46:31 <celie> omni: Should i change the commit message of !54486 to "security upgrade"? Does that GHSA need to be added to the secfixes?
2023-11-03 02:08:50 <fluix> celie: changing the commit title is probably good. secfixes is optional
2023-11-03 02:09:54 <fluix> given that it's an upstream release that fixes it, it will be picked up by security tracker. some maintainers choose to list all CVEs/GHSAs anyways
2023-11-03 02:20:43 <celie> Yes, i've had this secfixes discussion with you before
2023-11-03 02:24:24 <celie> Anyway, it probably depends on individual maintainers, what they want to add to secfixes, but since there are only 2 aports (that i could find) that list GHSA, i haven't added it to secfixes in !54485, and instead, added that to the commit description, so those looking through the Git commit log will know what the security upgrade was about
2023-11-03 02:24:46 <celie> s/54485/54486/
2023-11-03 02:50:06 <bl4ckb0ne> qutebrowser is borked again
2023-11-03 02:51:38 <bl4ckb0ne> https://paste.sr.ht/~bl4ckb0ne/962c21c741df8d32540d97045f9301d9de6aa4b6
2023-11-03 05:36:26 <fluix> whoever's got perms can close #15424
2023-11-03 06:11:28 <ikke> done
2023-11-03 08:14:26 <ikke> omni: i rebooted the arm builder host and didnt start the ci VMs, so there should be more memory available 
2023-11-03 08:14:59 <ikke> omni: if it still fails due to lack of memory, we should reduce the amount of concurrent processes.
2023-11-03 08:57:02 <omni> ikke: 👍
2023-11-03 09:53:09 <omni> I'm curious of 'options="net"', it doesn't seem to be required for fetching go modules, for example, at least not in CI
2023-11-03 10:03:23 <ikke> omni: it's for when rootbld is used 
2023-11-03 10:52:28 <omni> ok
2023-11-03 10:54:18 <omni> ikke: we have !54655, is there anything you think should go in with that to fix builds on aarch64?
2023-11-03 10:54:54 <omni> or maybe there's something magic in llvm 17.0.4?
2023-11-03 11:27:43 <ikke> nmeum: do you see any chance fixing go x86, or should we bootstrap it with edge?
2023-11-03 13:00:45 <omni> could someone see if these make sense !54669 !54708
2023-11-03 13:09:33 <nmeum> ikke: will be possible to fix but may take some time, will write an email on the upstream ML later today
2023-11-03 13:09:39 <nmeum> it may be wortwhile to bootstrap from edge in the meantime
2023-11-03 13:09:46 <nmeum> so that we can fixup broken aports on x86?
2023-11-03 13:13:02 <ikke> Yes
2023-11-03 13:15:31 <fluix> omni: seems fine to me. I guess sec tracker doesn't look at GHSAs yet though.
2023-11-03 13:16:03 <fluix> maybe still makes sense to add a secfixes comment for posterity?
2023-11-03 13:23:18 <omni> in case trackers would start searching for GHSAs eventually sometime in future maybe?
2023-11-03 13:24:25 <fluix> yeah, and so you don't need to look through the git log
2023-11-03 13:25:03 <omni> the mentioned GHSA is related to docker, but IBM^wRedHat™ seem to have a couple of related issues that are embargoed
2023-11-03 13:26:13 <fluix> ah I see
2023-11-03 13:26:53 <fluix> I think it's still fine to include in secfixes given upstream says "fixed GHSA..."
2023-11-03 13:27:06 <fluix> we can always update it in the future
2023-11-03 13:27:34 <omni> I don't think that is what the secfixes section is for
2023-11-03 13:28:13 <omni> and I think there is enough information in the patches, including upstream commit hashes, if you wanted to go and investigate
2023-11-03 13:28:32 <fluix> I'm thinking that (1) the GHSA should be updated to include podman/buildah and (2) at some point in the future maybe sectracker will look at GHSAs as you mentioned
2023-11-03 13:28:46 <fluix> but I don't lean strongly in either direction in this case; think it's good to merge :)
2023-11-03 13:40:55 <omni> I'll give mpolanski or someone else some time to react and merge
2023-11-03 13:42:03 <omni> ikke: if you can abort individual builds, perhaps you could stop qt6-qtwebengine-6.6.0-r1 on the aarch64 builder as it would have to build qt6-qtwebengine-6.6.0-r2 anyway
2023-11-03 14:02:44 <omni> ok, it failed the same way for -r2 on build-3-19-aarch64
2023-11-03 14:03:06 <omni> so limit jobs how?
2023-11-03 14:09:25 <ikke> Something like export JOB=$((JOBS>64 ? 64 : JOBS))
2023-11-03 14:09:36 <ikke> export JOBS
2023-11-03 15:04:56 <ncopa> does it fail during compile or during link?
2023-11-03 15:35:11 <nmeum> ikke: I reported the gccgo isse on i386 upstream https://github.com/golang/go/issues/63935 still not entirely sure if it is related to our LFS64 gccgo patch, but hard to test that without downgrading musl
2023-11-03 15:46:11 <fluix> fmac: would you consider promoting https://pkgs.alpinelinux.org/package/edge/testing/x86_64/senpai to community? I know upstream isn't great about making release and changelogs, but the package itself seems stable
2023-11-03 16:04:43 <Forza> Hi. I am thinking of moving scsi-tgt from testing to community. Is there a specific procedure to do this? 
2023-11-03 16:05:41 <minimal> Yupe, you raise a MR moving it ;-)
2023-11-03 16:06:37 <minimal> with the appropriate commit message (see COMMITSTYLE.md in aports repo)
2023-11-03 16:07:28 <minimal> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/COMMITSTYLE.md?ref_type=heads#move
2023-11-03 16:08:18 <omni> ncopa: during link, at [149/284] Linking CXX shared library lib/libQt6WebEngineCore.so.6.6.0
2023-11-03 16:10:04 <Forza> minimal: thank you
2023-11-03 16:11:05 <Forza> It doesn't clearly say, but can I do a package bump and a move in the same commit? 
2023-11-03 16:12:04 <minimal> that would generally be 2 different MRs
2023-11-03 16:12:40 <ikke> Can be a single MR honestly
2023-11-03 16:12:53 <Forza> The templates won't work then ;) 
2023-11-03 16:13:07 <Forza> I don't mind bumping and moving 
2023-11-03 16:13:25 <Forza> Celeste i see was already quick to make an MR bump anyway 
2023-11-03 17:08:29 <tomalok> dhcpcd-10.0.4 update -- if i revert https://github.com/NetworkConfiguration/dhcpcd/commit/ac4a70dc89ffd545e7a8c8c07711497376ac85f5#diff-5ba67626cc214a1de027b4cc749baea8e9473a60a89ff3cf5bb6b2b48137dd73R2012-R2026 then it works again.  i think they're maybe prematurely switching file descriptors to /dev/null before it can report back whether the fork
2023-11-03 17:08:29 <tomalok> was successful.
2023-11-03 17:11:06 <tomalok> also the problem has been confirmed on raspberry pi os (trixie) as well, so i haven't been imagining it :)
2023-11-03 17:32:13 <fluix> Forza: you can do it in two commits, 1 MR
2023-11-03 17:32:18 <fluix> for the future, I mean
2023-11-03 17:32:52 <Forza> Thanks. That is good. 
2023-11-03 17:41:36 <durrendal> omni: thanks for your help with lua-lapis/lua-argparse last night. I wasn't aware of the common directory thing
2023-11-03 17:41:49 <Forza> I'd like to merge this https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/54686 but I get an error when clicking rebase or rebase without pipeline. 
2023-11-03 17:42:04 <durrendal> I assume any lua library that just imports pure lua can get stuffed into /common now?
2023-11-03 17:44:02 <fluix> Forza: you don't have permission to merge. someone with developer access will merge it soon
2023-11-03 17:44:15 <Forza> Ah ok. Thanks. 
2023-11-03 17:44:39 <fluix> approving is the correct thing to do btw
2023-11-03 17:44:44 <Forza> I thought ikke had given me that access, but maybe it was just for approval. 
2023-11-03 17:44:49 <Forza> Thanks :) 
2023-11-03 17:45:48 <tomalok> dhcpcd - and now i can't reproduce the issue?  🤦
2023-11-03 17:49:14 <tomalok> (ok, found it again)
2023-11-03 17:49:25 <ikke> Forza: yes, just for approval 
2023-11-03 17:49:57 <Forza> Ok that's fine. I misunderstood. Thanks :) 
2023-11-03 18:03:57 <ncopa> firefox-esr fails to build for some reason. anyone has idea why? https://tpaste.us/nkDp
2023-11-03 18:13:10 <tomalok> ikke, ncopa: any updates to the build toolchain apk's lately? (gcc, etc.)?  suddently i can't reproduce the dhcpcd problem from the exact same set of patches that exhibited the issue yesterday
2023-11-03 18:14:55 <ikke> llvm has been updated to 17
2023-11-03 18:15:30 <ncopa> tomalok: not that i know
2023-11-03 18:16:49 <tomalok> just tested a fresh edge (x86_64), with the existing dhcpcd-10.0.4-r0 that's already there, and the problem isn't there so, not build toolchain.  libs?
2023-11-03 18:17:00 <ncopa> was dhcpcd rebuilt?
2023-11-03 18:17:14 <ncopa> looks like it was updated late october
2023-11-03 18:17:25 <tomalok> it's still -r0
2023-11-03 18:17:42 <tomalok> which exhibited the problem just days ago
2023-11-03 18:17:46 <ncopa> so it is the same binary, regardless of the toolchain
2023-11-03 18:18:17 <ncopa> the only thing it links to is musl
2023-11-03 18:18:30 <ncopa> which has not been rebuilt since october
2023-11-03 18:18:56 <tomalok> okay, so i *AM* going crazy after all.  :/
2023-11-03 18:19:28 <ncopa> could it have been related to something on the network?
2023-11-03 18:20:13 <tomalok> if AWS fixed a bug in their dhcp server, maybe -- but the problem ws happening after all that was successful and it was daemonizing
2023-11-03 18:20:52 <tomalok> the privsep fd was supposed to report exit value, and there wasn't anythnig to read on it 
2023-11-03 18:21:36 <ncopa> maybe it was something in the kernel?
2023-11-03 18:21:45 <ncopa> i pushed new kernel yesterday iirc
2023-11-03 18:22:12 <ncopa> Linux ncopa-edge-x86-64 6.1.61-0-lts #1-Alpine SMP PREEMPT_DYNAMIC Thu, 02 Nov 2023 10:03:31 +0000 x86_64 Linux
2023-11-03 18:22:57 <tomalok> hm, maybe.  though i thought i was still testing on an instance that'd been up for a while
2023-11-03 18:23:20 <tomalok> stepping through the patches between 10.0.3 and 10.0.4 until i found one that caused the problem
2023-11-03 18:24:28 <tomalok> was working my way through the hunks of the patch, and after a certain point i just plain couldn't reproduce
2023-11-03 18:24:38 <tomalok> even going back to the full set of patches
2023-11-03 18:27:20 <tomalok> okay, it's still there... just got a dhcpcd_fork_cb: truncated read 0 (expected 4)
2023-11-03 18:27:37 <tomalok> new edge aarch64 image
2023-11-03 18:51:56 <tomalok> can't re-reproduce on x86_64 now, but was hitting it before, maybe a race condition that happens under certain conditions
2023-11-03 22:13:55 <tomalok> dhcpcd problem reliably reproducible on aarch64 and debugging has narrowed it down to the addition of these two llines - https://github.com/NetworkConfiguration/dhcpcd/commit/ac4a70dc89ffd545e7a8c8c07711497376ac85f5#diff-5ba67626cc214a1de027b4cc749baea8e9473a60a89ff3cf5bb6b2b48137dd73R355-R356
2023-11-04 01:43:56 <omni> durrendal: glad to
2023-11-04 02:30:02 <omni> ikke: 4d859116ca9363ac587db50473b0dfd481a386bb didn't help
2023-11-04 02:32:50 <omni> btw, what is 6e34e3ebd65921fcc0ccb3135e81c4271b070f95 ? probably not related but has carried through every llvm release since
2023-11-04 02:52:09 <celie> omni: Are you sure you meant to request a review from me for !54727?
2023-11-04 07:06:36 <ikke> omni: https://imgur.com/a/yVwA1kv
2023-11-04 07:06:46 <ikke> The host still had plenty of memory available
2023-11-04 07:10:04 <ikke> omni: So we need to figure out where this std::bad_alloc comes from
2023-11-04 07:34:38 <ikke> omni: https://www.mail-archive.com/llvm-bugs@lists.llvm.org/msg69642.html
2023-11-04 07:34:46 <ikke> this is x86, but maybe affecting aarch64 as well?
2023-11-04 07:36:31 <ikke> oh lol, reported by donoban 
2023-11-04 08:11:55 <donoban> hi, does aarch64 also fail due bad_alloc?
2023-11-04 08:13:25 <ikke> donoban: yes
2023-11-04 08:13:36 <ikke> similar error as you have posted in that issue
2023-11-04 08:15:00 <donoban> I supposed that x86 has some memory limit per process which llvm reaches on linkage but maybe there is some bug
2023-11-04 08:15:55 <ikke> yes, for 32-bits, the limit would be 4GB per process
2023-11-04 08:16:00 <ikke> but aarch64 would not have that limit
2023-11-04 08:16:26 <donoban> if the log error is very similar I could reopen https://github.com/llvm/llvm-project/issues/69245 
2023-11-04 08:16:39 <donoban> in the meaintime we can switch to gcc ld
2023-11-04 08:50:31 <donoban> ikke: omni does this work? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/54738/pipelines
2023-11-04 08:50:56 <donoban> if fails you could try setting USE_LLVM=OFF
2023-11-04 08:53:17 <donoban> comparing with the x86 log, it doesn't look exactly the same error
2023-11-04 08:59:46 <donoban> well, I added it to the github issue
2023-11-04 10:14:11 <omni> celie: yeah... you don't have to, I just thought that maybe you could have a look at it since you adopted ltting-tools
2023-11-04 10:14:45 <omni> I could have just suggested that hereinstead of putting you as reviewer but was tired
2023-11-04 10:32:00 <omni> donoban: no, that change is what I meant didn't help
2023-11-04 10:32:19 <omni> so it could be removed in the next iteration of trying to fix this
2023-11-04 10:44:37 <omni> donoban: I'll try gcc ld
2023-11-04 10:44:59 <omni> but the error you had on x86 you also had in gitlab CI, right?
2023-11-04 10:45:12 <omni> the aarch64 one only happen on the package builder
2023-11-04 11:18:59 <donoban> yes it was on local and CI
2023-11-04 11:25:11 <omni> gcc linker failed on aarch64 CI https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1169304
2023-11-04 11:25:16 <omni> for something else
2023-11-04 11:25:47 <Forza> How is the process of including a community package in a stable (3.18) release? 
2023-11-04 11:28:41 <donoban> uhm, maybe it needs some patching for enable gcc
2023-11-04 11:35:21 <Forza> Maybe I should have moved scsi-tgt to the 3.18 branch instead of master? 
2023-11-04 11:59:54 <Forza> Does this look ok? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/54772 or should I move from edge to release branch? I think not as we might have future changes on edge that shouldn't happen on release branches right away. 
2023-11-04 12:16:06 <ikke> Forza: anything in community will be automatically be part of the next release
2023-11-04 12:16:18 <Forza> Ahh
2023-11-04 12:16:23 <Forza> Didn't know this 
2023-11-04 12:16:33 <ikke> The next release is branched off of master
2023-11-04 12:16:52 <Forza> I thought I had to maintain separate trees for releases 
2023-11-04 12:17:40 <Forza> But it makes sense. Thanks. I'll delete the MR draft 
2023-11-04 12:17:57 <ikke> Each release does have it's own branch, but only after the first tag of a release
2023-11-04 12:18:32 <ikke> so after 3.19 is released, to update or fix things you have to target the 3.19-stable branch
2023-11-04 12:57:08 <Forza> Thanks for explaining. :) 
2023-11-04 13:26:11 <omni> 
ACTION autogaslit

2023-11-04 13:35:02 <ikke> omni: wanna share?
2023-11-04 13:37:30 <ikke> nmeum: built go now on x86 3.19 with the help of edge
2023-11-04 13:41:01 <omni> ikke: I figured it out
2023-11-04 15:00:11 <ikke> omni: what?
2023-11-04 17:46:56 <omni> ikke: that I wasn't mad, that I was selfinflected by my own unintentional/subconsious gaslighting of myself, hence autogaslit
2023-11-04 17:48:19 <omni> I was doing stuff and it failed in ways that were at first not clear to me, then I saw where I had erred
2023-11-04 17:49:32 <omni> like "this *used* to work, this *should* work, _what_is_going_on_??"
2023-11-04 18:28:07 <ikke> right, I thought maybe you found the issue with qt6-qtwebengine :p
2023-11-04 19:58:32 <omni> that would've been something
2023-11-04 20:01:19 <ikke> omni: but my conclusion so far is that it's not due to a lack of memory on the builder
2023-11-04 20:01:41 <ikke> If you want to me to test something or get some data from the builder, let me know
2023-11-04 20:09:41 <omni> yeah, it just feels a bit outside of my capacity
2023-11-04 20:11:14 <omni> I added a comment here https://github.com/llvm/llvm-project/issues/69245#issuecomment-1793464262
2023-11-04 20:11:46 <omni> may be a risk that it won't be read soon since the issue is closed and the topic is for another architecture
2023-11-04 20:12:50 <omni> ikke: on of the differences is docker in a vm vs lxc on bare metal?
2023-11-04 20:13:59 <ikke> yes, for aarch64 that's the case
2023-11-04 20:45:29 <omni> how was it with MIT licenses again? !54528
2023-11-04 20:47:07 <omni> is the wiki correct or should it be updated and is this also a thing that could go into aports.git/README.md too?
2023-11-05 05:11:35 <sdomi> hmm... getting some weird firefox crashes on wayland w/ RDP backend. verified reproducible on a fresh v3.18 qemu install, as well as a fully up to date edge - both x86_64. anyone else?
2023-11-05 05:13:10 <sdomi> https://paste.asie.pl/Pojr gdb backtrace stuffs; process crashes once you move the mouse
2023-11-05 05:17:57 <sdomi> https://paste.asie.pl/Nxob <-- reproduction steps; VM is `qemu-system-x86_64 -enable-kvm -cdrom alpine-standard-3.18.0-x86_64.iso -m 4G -boot d -cpu host`
2023-11-05 05:18:52 <sdomi> i'm weirded out by the Illegal Instruction, especially since i'm running this on a recent ryzen (and it was brought up to me by a friend running on an intel 11th gen engineering sample, so even weirder). what gives?
2023-11-05 05:34:44 <lnl> hm, this is a function doing telemetry, should early-exit if you turn it off
2023-11-05 07:34:25 <quinq> Anybody motivated enough to update webkit2gtk packages? :/
2023-11-05 12:38:43 <yann> Hi
2023-11-05 12:42:24 <ysionneau> I noticed some time ago that I had weird issues with Alpine init in initramfs in my attempts to port Alpine to kvx arch. I noticed some weird kernel message about "unable to open an initial console"
2023-11-05 12:42:56 <ysionneau> For the sake of curiosity I tried to add a /dev/console to the initramfs and .. it solved my problem
2023-11-05 12:43:23 <ysionneau> now Alpine initramfs correctly spawns a rescue shell, since I don't have rootfs
2023-11-05 12:43:48 <ysionneau> before it just panic'ed, and I was missing somes of the messages (the one that got echo'ed directly and not echo'ed to /dev/kmsg)
2023-11-05 12:44:44 <ysionneau> I am saying this here in case this is a "general" issue that would need to be fixed
2023-11-05 12:53:26 <skarnet> yes, /dev/console should always be there, it's mandated by posix
2023-11-05 12:53:49 <ysionneau> if I am not mistaking, it's not present in initramfs, or maybe I misgenerated it
2023-11-05 12:53:57 <ysionneau> which is highly probable also :p
2023-11-05 12:54:40 <ysionneau> I generated it using mkinitfs -o alpine-kvx-initramfs -n -k -b $PWD/rootfs
2023-11-05 13:00:43 <skarnet> normally the kernel should mount a devtmpfs at boot time, which should expose a /dev/console node? but I'm not sure how Alpine kernels are configured
2023-11-05 13:00:58 <ysionneau> maybe it's an issue in my kernel config then
2023-11-05 13:03:38 <ysionneau> I have CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT
2023-11-05 13:04:24 <ysionneau> second option is entitled "Automount devtmpfs at /dev, after the kernel mounted the rootfs"
2023-11-05 13:04:31 <ysionneau> I guess we want it mounted earlier than that
2023-11-05 13:05:32 <skarnet> no, initramfs *is* your rootfs, so /dev/console should definitely be there
2023-11-05 13:05:34 <ysionneau> oh but, I can see in init code that it *does* mount devtmpfs
2023-11-05 13:05:56 <skarnet> yeah something's up with your setup one way or another
2023-11-05 13:06:10 <ysionneau> I agree, there must be something I do wrong
2023-11-05 13:06:25 <ysionneau> about rootfs and dev/console : doesn't the kernel differentiate between initramfs and rootfs?
2023-11-05 13:06:38 <ysionneau> I would think so
2023-11-05 13:08:15 <skarnet> it can, but why would it?
2023-11-05 13:08:30 <skarnet> once it gives control to userspace it has no reason to interfere any longer
2023-11-05 13:08:51 <skarnet> userspace can switch_root on its own if needed, and it's not always needed
2023-11-05 13:09:25 <ysionneau> I'll dig a little bit deeper
2023-11-05 13:09:26 <skarnet> so from the kernel's pov, it mounts *a* rootfs, which happens to be an initramfs, and then it's up to initramfs to do whatever change it wants
2023-11-05 13:09:44 <ysionneau> agreed
2023-11-05 13:14:53 <ysionneau> thanks
2023-11-05 13:16:53 <ysionneau> hmm the real issue must be something else, I added some checks in init and devtmpfs *does* get mounted , with a /dev/console
2023-11-05 13:17:27 <ysionneau> but it still craches so I guess the crash is a bit "random", like I change some line somewhere and it behaves differently...
2023-11-05 13:20:55 <papiris[m]> I'm porting snap-pac to alpine, and could use some help in that process. This is my first package (for any distro).
2023-11-05 13:20:55 <papiris[m]> how does apk differentiate between pre- and post-commit hooks in `/etc/apk/commit_hooks.d/`? This part of the `apk-tools` source code is relevant, but I'm not good at reading C... Could someone enlighten me? https://github.com/alpinelinux/apk-tools/blob/3bf521ba06711394d6ac8a12e5e55b452a7e5107/src/commit.c#L232-L270 
2023-11-05 13:21:34 <papiris[m]> repo of my fork here: https://gitlab.com/papiris/snap-apk
2023-11-05 13:24:00 <papiris[m]> going through the wiki for creating an alpine package atm
2023-11-05 14:24:29 <papiris[m]> why do both these fail with  `ERROR: Missing required argument: PKGNAME[-PKGVER] | SRCURL`?... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/ejuvGNcWIYNKFfhOaoRuspbJ>)
2023-11-05 14:25:10 <papiris[m]> * why do both these fail with  ERROR: Missing required argument: PKGNAME[-PKGVER] | SRCURL?... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/jkqmtqyfzUNPfQNDOghnFZea>)
2023-11-05 14:26:20 <papiris[m]> please ignore the <a href...> anchor tags, they're not part of the commands but matrix automatically adds them for some reason
2023-11-05 14:40:47 <papiris[m]> https://gitlab.com/papiris/$pkgname/-/archive/$pkgver/$pkgname-$pkgver.tar.gz
2023-11-05 14:44:03 <papiris[m]> with... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/gAeouHgbvSNOUPNGqXkHEHZx>)
2023-11-05 15:36:09 <ysionneau> hehe I've got alpine that boots on kvx up to rootfs shell, and gcc is able to create a native binary
2023-11-05 17:08:38 <Kladky> papiris[m]: for commit hooks apk will look for files called pre-commit and post-commit, like git
2023-11-05 17:09:02 <Kladky> So inside those files you would need to execute your python code
2023-11-05 18:51:19 <papiris[m]> Wonderful, thank you Kladky 
2023-11-05 18:55:39 <papiris[m]> however, both hooks are still executed both before and after commit, even when they're called pre-commit and post-commit
2023-11-05 19:08:08 <papiris[m]> It's the same if I rename the hook files PRE_COMMIT_HOOK and POST_COMMIT_HOOK
2023-11-05 19:24:42 <papiris[m]> yessss, I got it!
2023-11-05 19:27:42 <quinq> papiris[m], it's horribly undocumented, but any script found in /etc/apk/commit_hooks.d is run at pro and post
2023-11-05 19:28:04 <quinq> Well, any file really, it doesn't have to be a script
2023-11-05 19:28:27 <quinq> But the point is that the executable is supposed to look at argv[0] in order to know if it's "pre-commit" or "post-commit"
2023-11-05 19:28:36 <quinq> (at least it seems so)
2023-11-05 20:02:33 <papiris[m]> Yes, that's what I figured out as well. I'll look at adding some documentation about it after finishing this packaging effort :)
2023-11-05 20:15:12 <quinq> That'd be nice :)
2023-11-05 20:15:19 <quinq> Best kind of patches
2023-11-05 20:30:29 <papiris[m]> why is the downloaded `aports` repo not visible to abuild?... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/ndPPPmeODFkTfjoyoTwYYfmq>)
2023-11-05 20:30:57 <papiris[m]> * why is the downloaded aports repo not visible to abuild?... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/LDVHwBQZDyteuKHQXAtsAJFv>)
2023-11-05 20:32:56 <ikke> I'm not following your question in context of the pasted snippet
2023-11-05 20:34:47 <quinq> I guess the question is “Why do I see WARNING: opening /home/jacob/aports/testing/: No such file or directory
2023-11-05 20:34:50 <quinq> ”
2023-11-05 20:36:12 <ikke> You need to point to a package repository, not to the aports dir
2023-11-05 20:36:20 <papiris[m]> I'm kind of sleepy, so I probably didn't word that well.
2023-11-05 20:36:20 <papiris[m]> I followed this guide https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package# and cloned aports to ~/aports
2023-11-05 20:36:36 <ikke> /home/jacobs/packages/testing
2023-11-05 20:36:48 <ikke> not /home/jacobs/aports/testing
2023-11-05 22:01:11 <papiris[m]> ikke I've made /home/jacobs/packages/testing ++, and listed them in apk/repositories, but abuild still complains "no such file or directory"...
2023-11-05 22:11:45 <papiris[m]> This is my APKBUILD https://gitlab.com/papiris/apk-snap-APKBUILD/-/blob/main/APKBUILD?ref_type=heads
2023-11-05 23:23:27 <sdomi> lnl: re: 063444; so, apparently, no dice after turning off telemetry :(
2023-11-05 23:23:59 <sdomi> if anyone has any ideas then go directly to elly (because this doesn't really directly affect me, and I only now noticed she's here as well XD)
2023-11-05 23:46:19 <lnl> (it's a different elly than on here, @elly@donotsta.re)
2023-11-06 02:07:38 <sdomi> lnl: aye, my bad, she's ellyq on oftc
2023-11-06 05:40:28 <omni> 54e6cdb86e1436b85605f6f00c64e3eab89f780e
2023-11-06 06:16:41 <ikke> omni: 👍
2023-11-06 06:26:37 <quinq> What about webkit2gtk? :D
2023-11-06 06:34:49 <omni> was actually looking at it
2023-11-06 06:40:43 <quinq> nice! :D
2023-11-06 08:09:45 <omni> weird how this fails on (at least) x86 !54890
2023-11-06 08:10:18 <omni> but succeeded with the now removed source file in !54752
2023-11-06 08:13:10 <omni> is it the elfutils update?
2023-11-06 08:14:23 <omni> because it's successful on arm* with elfutils-dev 0.189-r3 but fail on x86* with 0.190-r0
2023-11-06 08:16:12 <ncopa> its probably f5537a7ba61d50178ffe640acd3963c95c8a5bff
2023-11-06 08:17:43 <ncopa> sigh...
2023-11-06 08:41:09 <ncopa> i think it might be a musl vs elfutils issue
2023-11-06 08:41:20 <ncopa> typedef Elf64_Xword    Elf64_Relr;
2023-11-06 08:41:35 <ncopa> only happens  #ifndef SHT_RELR
2023-11-06 08:42:09 <ncopa> so my guess iss that musl defines SHT_RELR but does not typedef  typedef Elf32_Word     Elf32_Relr;
2023-11-06 09:57:31 <ncopa> im gonna report the iproute2 to elfutils in a bit (unless someone else beats me to it)
2023-11-06 09:57:35 <ncopa> In file included from bpf_legacy.c:24:
2023-11-06 09:57:35 <ncopa> 170   86 | typedef Elf64_Relr GElf_Relr;
2023-11-06 09:57:35 <ncopa> 169/usr/include/gelf.h:86:9: error: unknown type name 'Elf64_Relr'
2023-11-06 09:57:35 <ncopa> 171      |         ^~~~~~~~~~
2023-11-06 09:58:01 <ncopa> I believe it was introduced by this: https://sourceware.org/git/?p=elfutils.git;a=commit;h=39f2c500542f69c2f1a13fd0ae4eaa5778d2ed8d
2023-11-06 10:41:43 <indy> hi all, any date for 3.19.0? :)
2023-11-06 10:44:48 <ikke> indy: when its ready, but probably end of november or beginning of de 
2023-11-06 11:08:38 <indy> ikke, thanks
2023-11-06 11:19:31 <ncopa> i really really want it out before december.
2023-11-06 11:20:14 <ncopa> at some point i will kill everything that does not work and just ship whatever we have ready
2023-11-06 11:50:53 <ncopa> man... today is a MOnday...
2023-11-06 11:51:06 <ncopa> the day for typos in commit messages. pushed without blinking
2023-11-06 12:19:40 <ncopa> meh...
2023-11-06 12:19:47 <ncopa> it really is monday today isnt it
2023-11-06 12:20:04 <ncopa> iproute2 failed to build because the renamed the source location
2023-11-06 12:20:18 <ncopa> the MR to fix that failed due to elfutils update
2023-11-06 12:20:45 <ncopa> fixing the MR required fix in musl which was pushed
2023-11-06 12:21:23 <ncopa> but iproute is built before musl, so iproute2 gets stuck with elfutils update
2023-11-06 12:21:45 <ncopa> the fix is to manually build and update musl on all builders
2023-11-06 12:21:58 <ncopa> or temporarily disable iproute2...
2023-11-06 14:33:59 <ncopa> im having problems building qt[56]-qtwebengine with recent clang
2023-11-06 14:38:42 <andypost[m]> ncopa: iirc omni fixed qt5 one
2023-11-06 16:52:11 <ncopa> In file included from gen/third_party/blink/renderer/platform/platform_jumbo_64.cc:8:               
2023-11-06 16:52:11 <ncopa>       |                                                        ^                                    
2023-11-06 16:52:11 <ncopa> ./../../3rdparty/chromium/third_party/blink/renderer/platform/text/text_break_iterator.cc:231:56: error: static assertion failed: breakAllLineBreakClassTable should be consistent                      
2023-11-06 16:52:11 <ncopa>   231 | static_assert(base::size(kBreakAllLineBreakClassTable) == BA_LB_COUNT,                      
2023-11-06 16:53:27 <ncopa> looks like it is related icu update
2023-11-06 16:53:33 <ncopa> (which I am working on=
2023-11-06 17:40:03 <PureTryOut> qt6-qtwebengine has been disabled on aarch64 for now sadly, it was blocking the builders for a while now and we haven't yet been able to figure out why linking fails at the very end. Happens only on the builders for some fun reason
2023-11-06 18:34:07 <PabloCorreaGomez[m]> Is there any suggestion on what to do with something like https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51703?
2023-11-06 18:34:54 <PabloCorreaGomez[m]> The comment from the Release Team in GNOME when it was removed from Core was: "Photos will likely be archived eventually, unless a new maintainer volunteers to save it."
2023-11-06 18:35:12 <PabloCorreaGomez[m]> So my motivation to fix it is quite low
2023-11-06 18:35:44 <PabloCorreaGomez[m]> At the same time, I acknowledge that there might be interest from alpine to keep it, and since we were maintaining it, then we probably should fix it too?
2023-11-06 18:36:08 <PabloCorreaGomez[m]> But to be honest, if it were for me, I'd totally just drop it
2023-11-06 18:56:13 <PureTryOut> I'd drop it entirely if it's in that state and doesn't even compile 🤷
2023-11-06 18:58:46 <skarnet> Please merge !54925 at your convenience, big batch of upgrades :)
2023-11-06 19:11:24 <PabloCorreaGomez[m]> PureTryOut (matrix.org): it does compile, but fails a test. Which to be fair, also fails the upstream CI xD
2023-11-06 20:40:20 <omni> skarnet: you got comments
2023-11-06 20:41:30 <skarnet> yup, I saw
2023-11-06 20:45:06 <omni> I also wrote something here but got disconnected immediately after so not sure anyone got to read that
2023-11-06 20:47:12 <omni> it was similar to what I wrote in the MR, but more, you didn't miss anything if you missed it
2023-11-06 23:32:33 <omni> should mozjs115 (and gjs) and firefox be disabled on riscv64? temporarily
2023-11-07 00:03:32 <skarnet> ncopa: thanks for the merge! didn't expect it to be done at such a late hour :)
2023-11-07 06:00:42 <ncopa> omni: we should report the clang issue upstream
2023-11-07 06:01:13 <ncopa> skarnet: np
2023-11-07 07:26:42 <indy> hi all, created !54957 and !54958 requests for werkzeug
2023-11-07 07:49:58 <ncopa> indy: looks scary to bupm major version. I doubt we can do so for 3.18-stable
2023-11-07 07:55:18 <indy> ncopa, and 3.18 is where i need it desperately :)
2023-11-07 07:57:13 <indy> ncopa, exists something like 'testing' for 3.18?
2023-11-07 07:59:15 <ncopa> I believe we can backport the fix for it
2023-11-07 07:59:27 <ncopa> will do so after breakfast
2023-11-07 08:00:43 <ncopa> fix looks trivial: https://github.com/pallets/werkzeug/commit/f3c803b3ade485a45f12b6d6617595350c0f03e2
2023-11-07 08:00:52 <indy> i looked at comment
2023-11-07 08:01:06 <indy> i'll try it, i'm already after breakfast :)
2023-11-07 08:19:29 <raspbeguy> hello, could you give an eye to !53681 and to !53868 please?
2023-11-07 08:27:57 <ncopa> raspbeguy: im prioritizing fixing existing stuff for 3.19 now. sorry
2023-11-07 08:41:18 <raspbeguy> ncopa, exciting news. no problem.
2023-11-07 08:42:15 <raspbeguy> I forgot we were at that time of the year
2023-11-07 09:37:07 <PureTryOut> ncopa: could you take a look at https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/167? currently the setup-desktop script doesn't work on edge installs and it won't on 3.19 either without that fix
2023-11-07 09:45:21 <ncopa> wouldnt it make more sense to install kde-icons? So we don't need change the script every time the icon pkgname changes
2023-11-07 10:03:50 <indy> ncopa, updated !54958
2023-11-07 10:14:14 <ncopa> indy: I just have a few tiny nitpicks. Good job!
2023-11-07 10:15:01 <indy> ncopa, already on it
2023-11-07 10:15:28 <indy> that patch include in same commit or can be separated?
2023-11-07 10:17:45 <ncopa> patch can be included in same commit.
2023-11-07 10:17:56 <ncopa> but I think you could also do the upgrade in separate commit. does not matter
2023-11-07 10:19:02 <ncopa> indy: ok if I push this to git master: https://tpaste.us/0lO8 ?
2023-11-07 10:21:23 <indy> ncopa, it is ok, sure
2023-11-07 10:21:39 <ncopa> thanks!
2023-11-07 10:28:18 <indy> ncopa, updated !54958
2023-11-07 10:29:32 <ncopa> merged
2023-11-07 10:31:17 <ncopa> ikke: I think we maybe use werkzeug in our security tracker? maybe we should update...
2023-11-07 10:46:50 <donoban> ncopa: do you mean https://gitlab.alpinelinux.org/alpine/security/secfixes-tracker ? I took a look and didnt find any reference
2023-11-07 10:47:00 <indy> ncopa, ikke any way to get machine redable from https://security.alpinelinux.org/ ? something like https://security.alpinelinux.org/json/CVE-2023-46136 ?
2023-11-07 10:47:15 <ikke> indy: it supports json-ld
2023-11-07 10:47:33 <ikke> Just ask for the correct content type
2023-11-07 10:55:38 <indy> ikke, ha, thanks, tried it works :)
2023-11-07 11:00:26 <ncopa> 👍
2023-11-07 11:13:58 <WhyNotHugo> I think it would be a good idea for projects like abuild to publish the man pages as HTML somewhere. Mostly so other sources can link to a fixed online location for them.
2023-11-07 11:14:11 <WhyNotHugo> E.g.: the wiki and other material often have a copy-pasted version of this.
2023-11-07 11:14:47 <WhyNotHugo> Generating the HTML is trivial: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/4496267b4b96d8cfb9d503bb0e25517dbdb583b7/.gitlab-ci.yml#L39-46 Is there some host where this can be hosted under the alpinelinux.com domain maybe?
2023-11-07 11:31:59 <ncopa> yup. that would be nice
2023-11-07 11:33:27 <ncopa> we have at least 3 different version of chromium and at least 2 different version of firefox/gecko
2023-11-07 11:33:43 <ncopa> each takes significant amount of time to build
2023-11-07 11:33:54 <ncopa> i have now spent days on making them all build with icu 74
2023-11-07 11:34:41 <ncopa> im just saying that maintaining all those copies requires significant amount of resources
2023-11-07 11:36:58 <ikke> yup
2023-11-07 11:37:11 <ncopa> same applies to kernel configs
2023-11-07 11:37:25 <ncopa> but kernel is not as heavy as web browsers
2023-11-07 12:15:22 <ysionneau> ncopa: hi, I noticed the alpine APKBUILD for binutils does not --disable-gdb  but there is also a package for gdb
2023-11-07 12:15:24 <ysionneau> how does this work?
2023-11-07 12:16:29 <ncopa> no idea tbh :)
2023-11-07 12:17:44 <ncopa> there seems to be no gdb built with binutils. maybe the configure script finds out that some dep is missing and disable gdb?
2023-11-07 12:17:52 <ysionneau> ah maybe
2023-11-07 12:18:09 <ncopa> would probably be good to add --disable-gdb
2023-11-07 12:18:22 <ysionneau> yes
2023-11-07 12:18:35 <ysionneau> I added it for kvx since in our binutils repo the gdb does not build...
2023-11-07 12:18:52 <ysionneau> the release mechanism for binutils & gdb seems quite ... weird
2023-11-07 12:19:59 <ysionneau> https://github.com/fallen/aports/commit/f058934f1df1ad896aa05c9079410b8789860990 < weird typo included :p
2023-11-07 12:21:12 <ncopa> we could probably disable it explicitly. we should never build gdb from that package afaik
2023-11-07 12:23:13 <ysionneau> agreed
2023-11-07 12:24:33 <ncopa> could you please file an issue? So I have a reference in the commit message
2023-11-07 12:38:30 <ysionneau> ncopa: in there https://gitlab.alpinelinux.org/alpine/aports/-/issues ?
2023-11-07 12:39:02 <ncopa> yes please
2023-11-07 12:39:56 <ncopa> we are below 300 open MRs now! \o/ 
2023-11-07 12:40:05 <ikke> great work
2023-11-07 12:43:26 <ysionneau> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15446 :)
2023-11-07 12:45:30 <ncopa> thank you!
2023-11-07 12:45:33 <ncopa> cbd94c5336c5f6f0c9c6f0851b546fc2d060eca6
2023-11-07 12:45:59 <ncopa> seems like I have issues downloading stuff from dev-www.libreoffice.org
2023-11-07 12:49:21 <ysionneau> ncopa: thanks!
2023-11-07 14:20:45 <omni> nmeum: report the aarch64 qt6-qtwebengine linking issue? to Qt or LLVM? both?
2023-11-07 14:20:59 <omni> ncopa: ^
2023-11-07 14:29:43 <ncopa> maybe both?
2023-11-07 15:20:28 <omni> I may have found why the CI builds were successful https://gitlab.alpinelinux.org/alpine/aports/-/issues/15442#note_352133
2023-11-07 15:20:45 <omni> I hope to be able to trigger this also on the CI builder
2023-11-07 17:24:51 <papiris[m]> Should the `-doc` subpackage contain a copy of the actual license, also when that license is OSI approved and has an SPDX identifier?
2023-11-07 17:24:51 <papiris[m]> The wording here https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#license is just a little bit ambiguous 
2023-11-07 17:27:47 <ikke> papiris[m]: MIT licenses for example contain a copyright statement that needs to be reproduced, it would not be sufficient to point to a generic version of the license
2023-11-07 17:29:40 <ikke> I think there is an expectation that the license document is shipped with the software
2023-11-07 17:30:54 <papiris[m]> Aha, I see. Thanks! The license in question is GPL3-or-later though, so a generic version will suffice. Does abuild point to a generic version automagically, so I the actual license file isn't replicated a bunch of times on the system?
2023-11-07 17:34:37 <papiris[m]> I guess the license has to be conveyed together with the software, yea... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/NnTBvrSFFSOXpRMgptcuYuQe>)
2023-11-07 17:45:55 <papiris[m]> abuild sanitychekck produces a warning about missing maintainer. should I set myself as the maintainer as well as the packager, in the APKBUILD?
2023-11-07 17:49:11 <papiris[m]> maintainer isn't mentioned in "apkbuild reference" or "creating an Alpine Package"... more documentation for me to improve after this :)
2023-11-07 17:56:33 <fluix> the scripts use `PACKAGER` from abuild.conf for the `# Maintainer: ` comment
2023-11-07 17:57:07 <fluix> *or maybe just for `# Contributor` and you should add yourself as Maintainer for new packages
2023-11-07 19:30:03 <papiris[m]> It looks like all aarch64 build jobs in the MRs have been pending/queued for a long time, compared to other arches. Is this normal?
2023-11-07 20:05:59 <ptrc> papiris[m]: there's 2 slots on the CI, and a lot of MRs being stuck usually indicates that either something went wrong or that there's a *really long* build in progress, something like chromium
2023-11-07 20:07:01 <ptrc> https://gitlab.alpinelinux.org/chereskata/aports/-/jobs/1173475
2023-11-07 20:07:05 <ptrc> > Elapsed time: 418 minutes 33 seconds 
2023-11-07 20:07:05 <ptrc> well
2023-11-07 20:07:23 <ptrc> that fails on most arches so might as well just cancel it
2023-11-07 20:09:36 <ptrc> ikke: i assume i'd need admin on gitlab to see *all* jobs on all aports forks for a specific builder?
2023-11-07 20:19:04 <ikke> ptrc: yes
2023-11-07 20:46:49 <ptrc> well, figured out a temporary solution with the graphql api
2023-11-07 20:46:53 <ptrc> works well enough
2023-11-07 20:57:22 <Kladky> On a workflow job I am seeing "No space left on device" errors, is that a concern?
2023-11-07 20:57:27 <Kladky> https://gitlab.alpinelinux.org/Kladky/aports/-/jobs/1173730
2023-11-07 21:00:40 <ikke> Kladky: cleaning up
2023-11-07 21:06:50 <ikke> Kladky: should be plenty of space again
2023-11-07 21:08:07 <Kladky> Thanks.
2023-11-08 00:54:25 <OTLabs> hi ppl
2023-11-08 02:20:33 <OTLabs> re hi
2023-11-08 02:21:32 <OTLabs> I would quite appreciate if someine can review my MR54393, https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/54394
2023-11-08 07:49:43 <raspbeguy> OTLabs, release of 3.19 is on the way. In the meantime the efforts are focused on fixing existing ports.
2023-11-08 07:56:00 <ikke> raspbeguy: OTLabs already left 
2023-11-08 07:57:10 <raspbeguy> weird. they are still present in the room according to my client
2023-11-08 08:09:42 <caskd[m]> hi, i've been working on trying to convert kernel flavours into subpackages. has anyone attempted to split modules and build dependency chains using the module information? i think it would be great especially to minimize space usage with lts/virt flavours and it is helpful when virt with a few extras (like igb) are used
2023-11-08 08:12:01 <caskd[m]> apk has no way of "shadowing" paths to prevent them to be installed as of now so subpackages seem the sanest way
2023-11-08 08:12:51 <caskd[m]> would be nice to hear if someone else attempted this and what challanges and roadblocks they've hit
2023-11-08 08:13:43 <caskd[m]> i am thinking of attempting something like openwrt's kmod-* set of packages but instead they are built in-tree
2023-11-08 09:40:40 <raspbeguy> Hello, what is the correct way to generate multiple flavours of the same package? let's say we have two ways to build a package, one with GUI and one without GUI
2023-11-08 09:46:25 <omni> and they cannot co-exist?
2023-11-08 09:46:44 <omni> my guess it that it depends.. what is it you want to package like that?
2023-11-08 09:47:43 <omni> s/guess it/guess is/
2023-11-08 09:48:33 <omni> (didn't we have a bot for that? I don't mind if we don't)
2023-11-08 09:49:43 <raspbeguy> I wish to package proton-bridge
2023-11-08 09:50:27 <caskd[m]> usually such packages have "extensions" of the base package so you can subpackage the GUI version, for example
2023-11-08 09:50:48 <caskd[m]> but if they cannot coexist, then i guess you'd have to make 2 independent packages
2023-11-08 09:52:21 <ikke> You could use subpackages for that 
2023-11-08 09:53:07 <ikke> Zabbix for example has different database flavors and is built multiple times in the same package 
2023-11-08 09:53:33 <raspbeguy> I will check what is done for zabbix
2023-11-08 09:53:47 <raspbeguy> I also found qbittorrent to be in the same case
2023-11-08 14:10:57 <ncopa> andypost[m]: icu 74 makes php8[12] tests fail: https://tpaste.us/NBWv not sure if there are any fix out there that can be bbackported
2023-11-08 14:36:53 <andypost[m]> ncopa:  please add it with diff (if possible) to !54970
2023-11-08 14:37:21 <andypost[m]> better to disable the tests until will get feedback of upstream
2023-11-08 15:55:01 <ncopa> how do i run the test with diff?
2023-11-08 15:55:55 <ncopa> the sqlite test failed for me too, with the 8.2.12 version. It is likely due to sqlite update
2023-11-08 15:56:39 <ncopa> whatta.. do we really need a firefox-developer-edition?
2023-11-08 15:57:09 <ncopa> i have been fixing the same firefox bug for icu-74 3 times already
2023-11-08 15:59:43 <khem> :) pain of vendored code I guess
2023-11-08 16:00:03 <ncopa> and i have fixed similar issue 3 times in chromium
2023-11-08 16:00:32 <ncopa> yeah, the pain of vendored code...
2023-11-08 16:00:39 <ncopa> the joys of open source
2023-11-08 16:03:42 <lnl> I'm curious now because my chromium (electron) doesn't have any new patches
2023-11-08 16:08:26 <ncopa> urgh.. do we have electron in repos as well?
2023-11-08 16:09:05 <ncopa> rebuilding software on ABI breakages used to be a days work or two
2023-11-08 16:09:17 <minimal> isn't electron one of the testing packages that is marked for removal as it has been there for so long?
2023-11-08 16:09:25 <ncopa> now it is weeks, even if my building machine is 10x faster nowadays
2023-11-08 16:10:31 <ncopa> i'm tempted to let testing repo crash and burn for now
2023-11-08 16:10:36 <ncopa> at least til after 3.19 release
2023-11-08 16:11:12 <ncopa> chromium took almost a full day to build here
2023-11-08 16:17:17 <ikke> puch
2023-11-08 16:17:19 <ikke> ouch*
2023-11-08 16:17:58 <ncopa> i only have an i9 (nproc 32) with 64G ram ....
2023-11-08 16:18:37 <ncopa> anyway... im making progress
2023-11-08 16:19:00 <ncopa> if we can accept that testing is broken for a while, i can push icu 74 today or tomorrow
2023-11-08 16:19:10 <ncopa> (and disable php test that fails)
2023-11-08 16:26:53 <donoban> I wonder why chromium takes so long compared to qtwebengine
2023-11-08 16:29:56 <lnl> ncopa: if you push a patch for the regular chromium I can take it from there
2023-11-08 16:32:29 <lnl> actually, both are M118 currently in alpine. that makes things even easier than I thought
2023-11-08 16:37:05 <vkrishn> will iwd make to main ?
2023-11-08 16:40:23 <vkrishn> oh, it needs dbus
2023-11-08 17:02:34 <ysionneau> for bootstraping Alpine on a new arch, say the aports/script/bootstrap.sh has run completely and I can boot this very basic Alpine in qemu
2023-11-08 17:02:56 <ysionneau> which iso should I build first in aports/scripts/ ?
2023-11-08 17:03:18 <ysionneau> or maybe I should build some other packages natively before trying to generate an image?
2023-11-08 17:05:57 <ysionneau> for instance I tried building --profile standard and it misses squashfs-tools , was I supposed to build it via bootstrap.sh ? or am I supposed to build it directly natively using abuild manually
2023-11-08 17:06:18 <ysionneau> (squashfs-tools is not built by bootstrap.sh afaik)
2023-11-08 17:12:42 <ysionneau> I think what I miss is "what is the next step after bootstrap.sh"
2023-11-08 17:13:08 <ikke> Build the rest of main
2023-11-08 17:15:13 <ysionneau> by trying to randomly cd into aports/main/<name> and doing abuild -r ?
2023-11-08 17:15:24 <ysionneau> or is there some package order defined?
2023-11-08 17:17:25 <ikke> there is
2023-11-08 17:17:56 <ikke> buildrepo from lua-aports builds packages in order
2023-11-08 17:20:00 <ncopa> andypost[m]: do we need testing/php8? or can it be removed?
2023-11-08 17:20:22 <ncopa> i mean we have community/php81 and community/php82
2023-11-08 17:36:55 <ncopa> found this while rebuilding for icu74: testing/php81-pecl-xlswriter/APKBUILD:pkgname=php8-pecl-xlswriter
2023-11-08 17:37:15 <ncopa> note the directory name is php81- while pkgname=php8-
2023-11-08 17:38:30 <andypost> ncopa: 17 days to remove) https://www.php.net/supported-versions.php
2023-11-08 17:39:23 <ncopa> but it is in testing
2023-11-08 17:39:32 <ncopa> with no intention to move to community
2023-11-08 17:40:08 <ncopa> i'd say we cheat and remove it
2023-11-08 17:40:11 <ikke> ncopa: It was moved to testing on the way out
2023-11-08 17:40:26 <andypost> ncopa, ++ to remove
2023-11-08 17:40:34 <ncopa> thank you andypost!
2023-11-08 17:41:01 <ncopa> i am also thinking of disable tests for php* when i push the icu update, so can we try fix those after
2023-11-08 17:41:27 <ncopa> if so, icu 74 is finally done (once i patch libreoffice)
2023-11-08 17:41:40 <ncopa> and i think i have a "fix" for libreoffice which currently is broken
2023-11-08 17:42:38 <andypost> ncopa, you can change TESTS to add relative path to icu test just before --show-diff https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/php82/APKBUILD?ref_type=heads#L376
2023-11-08 17:43:08 <andypost> to get run only one test with diff
2023-11-08 18:02:44 <ncopa> why do we use clang for building qt6-qtwebengine?
2023-11-08 18:09:44 <ikke> 82a8d552b529efef910946bbb0cdd6291e9784b5
2023-11-08 18:10:04 <ikke> 'less memory usage' :)
2023-11-08 18:10:14 <ncopa> allows uncapped parallelism due to less memory usage
2023-11-08 18:12:02 <ncopa> im switching it back to gcc
2023-11-08 18:21:22 <ncopa> and i thought i was done with the monster rebuilds....
2023-11-08 18:21:36 <ncopa> apparently ceph* needs to be rebuilt as well
2023-11-08 18:22:32 <ncopa> ceph18 that is
2023-11-08 18:37:19 <nu[m]1> last time it only took me 40 minutes :P
2023-11-08 18:39:57 <andypost[m]> ncopa: are you going to commit removal of testing/php8*?
2023-11-08 18:40:08 <ncopa> yes, im gonna push it with the icu74 rebuilds
2023-11-08 18:40:18 <ncopa> which i hope im close to ready with
2023-11-08 18:40:26 <ncopa> i just need a few more fixes...
2023-11-08 18:40:44 <ncopa> right now i choked on tectonic which no longer builds for some reason
2023-11-08 19:10:15 <ncopa> im gonna delete tectonic unless someone show up to maintain it
2023-11-08 19:15:32 <ichernev[m]> hey, I'm the maintainer (or at least trying) of py3-dt-schema. Upstream decided to pin py3-jsonschema dependency to <4.18 (lets say 4.17). The py3-jsonschema package is already at 4.19. One way I managed to get it to work is if I create a new package (say jsonschema417) which is a) pinned to a pre 4.18 version and b) all internal imports reference the new name, and then patch dt-schema to import the new package. This way the hacked
2023-11-08 19:15:32 <ichernev[m]> If I submit this to aports will it be accepted or is there a better option?
2023-11-08 19:15:32 <ichernev[m]> (417) and the regular package can coexist and people won't mistake-import one for the other.
2023-11-08 19:17:07 <ikke> ichernev[m]: is there an actual reason it's pinned or 'this was the highest version at the moment'?
2023-11-08 19:17:48 <ichernev[m]> https://github.com/devicetree-org/dt-schema/issues/109
2023-11-08 19:18:26 <ichernev[m]> I mean the author of dt-schema is not happy with a few things in 4.18 (which is a really major change), so he's "holding it off", but this holding off means I can't ship the package, people can't dt check their kernels etc...
2023-11-08 19:18:43 <ichernev[m]> my package was flagged "outdated" (which it is)... so I'm trying to take action
2023-11-08 19:18:49 <ikke> understood
2023-11-08 19:22:20 <ichernev[m]> there is an unofficial "patch"/branch of the dt-schema repo that supports 4.18+, but the author hasn't released it and is not happy with it (performance, rust deps etc), so he doesn't even bother to publish it. So now the question is how do I "bundle" a 417 version for it. One way is what I described above (but renaming is necessary to allow co-existance with official package), the other way is somehow bundling one inside the other,
2023-11-08 19:22:20 <ichernev[m]> but that would be more painful (if possible) due to imports... 
2023-11-08 19:26:53 <ikke> A separate package at least would be better
2023-11-08 19:33:25 <mio> is it okay for a package (in community) that usually only tracks stable releases to update on beta versions, or would it be better to stick to one and not switch back/forth?
2023-11-08 19:34:24 <ikke> Unless there is a compelling reason to update, I'd keep it on stable
2023-11-08 19:34:47 <mio> thanks ikke, will wait then
2023-11-08 20:15:14 <ncopa> im gonna push a huge icu update. lots of big rebuilds
2023-11-08 20:15:39 <ncopa> it also includes libreoffice fix, qt6-qtwebengine (aarch64) fix
2023-11-08 20:15:52 <ncopa> and some more build fixes
2023-11-08 20:16:30 <ncopa> i had not had time to follow up the php tests (sorry), so I have just disabled the tests for now. those needs to be re-enabled and followed up
2023-11-08 20:23:45 <andypost[m]> ncopa: just disable broken tests, I will care the rest
2023-11-08 20:42:22 <ikke> ncopa: thank you :)
2023-11-08 20:42:42 <ncopa> just waiting for electron finish build...
2023-11-08 20:43:33 <ysionneau> ikke: oh, but I need lua, I have basically almost no package so far
2023-11-08 20:44:11 <ysionneau> how are people basically bootstrapping alpine on a new arch? it seems I miss something in the picture here
2023-11-08 20:44:32 <ikke> I have never done that myself, so I don't have the complete picture either
2023-11-08 20:44:44 <ysionneau> ok thanks
2023-11-08 20:45:05 <ikke> but after bootstrap, you should be able to run a chroot for the new arch and build the rest of the packages
2023-11-08 20:45:16 <ysionneau> that's what I also think
2023-11-08 20:45:30 <ysionneau> so far I am indeed able to run basic alpine on my arch, thanks to bootstrap.sh
2023-11-08 20:45:46 <ysionneau> but I think either I miss some packages or I miss the understanding of what to do next
2023-11-08 20:46:13 <ysionneau> I think there was some irc channel here about bootstraping on some arch
2023-11-08 20:46:18 <ysionneau> maybe it was riscv ...
2023-11-08 20:46:32 <ikke> yes, but the bootstrapping part has already been done
2023-11-08 20:47:06 <ysionneau> but maybe it was not so long ago that someone remembers how to do it
2023-11-08 20:47:11 <ysionneau> 
ACTION found the channel

2023-11-08 21:01:41 <ncopa> alright... i pushed icu 74. i better run and hide
2023-11-08 21:03:12 <PureTryOut> ncopa: oh well done on getting Qt6Webengine compiling again!
2023-11-08 21:39:49 <ichernev[m]> I got the dt-schema to build (that was intense): https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/55034
2023-11-08 21:58:33 <andypost> ncopa: for some reason php pass the test on 32-bit x86(
2023-11-08 22:00:01 <andypost> and s390x(
2023-11-08 22:57:14 <clandmeter> ysionneau: i guess it depends what you want to do?
2023-11-08 23:36:08 <papiris[m]> `apkbuild-lint` doesn't give errors for an APKBUILD when # Contributor email address lacks <> tags, but gives a kind-of obscure RFC error when those tags are missing around # Maintainer 
2023-11-08 23:36:29 <papiris[m]> Where can I open an issue to fix this?
2023-11-08 23:37:25 <ptrc> papiris[m]: that would be https://gitlab.alpinelinux.org/Leo/atools, i guess
2023-11-08 23:45:28 <papiris[m]> Thanks! I checked the source, and it doesn't have any check for email formatting. Seems like apk-sanitycheck was the one doing this check :)
2023-11-09 00:32:23 <omni> ncopa: fyi https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.6 something license
2023-11-09 01:36:48 <celie> omni: You asked the same question about npm in !54495
2023-11-09 01:40:12 <omni> celie: thanks, I'll try to remember that this time
2023-11-09 01:40:36 <celie> No problem
2023-11-09 05:32:28 <craftyguy> oops icu was upgraded but none of the dependents were
2023-11-09 05:34:24 <craftyguy> is there a way that CI could detect these situations pre-merge somehow?
2023-11-09 05:38:28 <craftyguy> ok seems like many dependencies were rebuilt at the same time, maybe it's a mirror sync issue
2023-11-09 05:39:21 <andypost> craftyguy: builders still busy
2023-11-09 05:39:40 <craftyguy> ahh ok, I hadn't checked those yet :)
2023-11-09 05:39:50 <andypost> ikke: arm builders looks like went out of disk space
2023-11-09 06:23:46 <ikke> andypost: cleaned the builder up
2023-11-09 06:24:48 <andypost> ерфтл нщг
2023-11-09 06:24:55 <andypost> thank you
2023-11-09 06:28:59 <quinq> It seems there's a harfbuzz break
2023-11-09 06:29:13 <quinq> ERROR: unable to select packages: harfbuzz-subset-8.2.2-r1: breaks: harfbuzz-dev-8.2.2-r0[harfbuzz-subset=8.2.2-r0]
2023-11-09 06:29:43 <quinq> (that's on edge/amd64)
2023-11-09 06:29:52 <quinq> Though the message is unclear, does “select” mean installing?
2023-11-09 06:30:39 <quinq> I guess that means that harfbuzz-subset was updated, but not harfbuzz-dev, that still depends on r0?
2023-11-09 06:34:55 <ncopa> sounds like -r0 is already installed by something
2023-11-09 06:36:54 <quinq> Sorry, I didn't explain the context -_-
2023-11-09 06:37:00 <quinq> That's while doing an apk upgrade
2023-11-09 06:59:38 <ysionneau> clandmeter: the idea would be to , I think , build all aports main packages bits by bits and generate iso images as well as publish the packages in a repository.
2023-11-09 07:02:02 <quinq> ncopa, dependency “tree” is harfbuzz-subset-8.2.2-r0 < harfbuzz-dev-8.2.2-r0 < pango-dev-1.51.0-r0 < gtk+3.0-dev-3.24.38-r3, gtk4.0-dev-4.12.3-r0
2023-11-09 07:10:42 <indy> ncopa, ikke hi, https://dpaste.org/VNWT0 is there anything missing on sending side?
2023-11-09 07:12:47 <indy> i would expect, that https://security.alpinelinux.org/srcpkg/py3-werkzeug/2.3.7-r0 will return json with both repo: "edge-community" and "3.18-community"
2023-11-09 07:19:20 <quinq> Or rather to return several repos in the "repo" field
2023-11-09 07:19:33 <quinq> (well, maybe that's what you meant :))
2023-11-09 07:21:35 <indy> quinq, yes
2023-11-09 07:28:42 <indy> also https://security.alpinelinux.org/vuln/CVE-2023-46136 returns two states without repo/branch in json, while web/html contains also branches
2023-11-09 09:56:22 <chereskata> a lot of packages (ex. firefox-esr) are not rebuilt against latest icu
2023-11-09 09:57:26 <chereskata> is there a fix ongoing?
2023-11-09 09:57:32 <chereskata> is this by accident?
2023-11-09 10:25:12 <ncopa> thats unintentional
2023-11-09 10:25:20 <ncopa> where do you see this?
2023-11-09 10:42:30 <ikke> The builders are still working on community 
2023-11-09 10:42:45 <ikke> Until then, community will be broken 
2023-11-09 10:45:28 <ncopa> yeah, thats the price for having 10+ copies of vendored code in browsers
2023-11-09 10:45:42 <ncopa> and 5 different versions of llvm/clang and what not
2023-11-09 10:46:17 <ncopa> and the price for accepting software like dotnet which easily eat 10G here and there
2023-11-09 10:47:28 <ovf> ...and on top of that there are people like me asking for debug symbols for everything. :-)
2023-11-09 10:47:40 <ncopa> they dont only ask you
2023-11-09 10:47:50 <ncopa> they have asked to enable debugging symbols for *everything*
2023-11-09 10:48:17 <ovf> that's what i said -- i *am* those people
2023-11-09 10:48:31 <ncopa> er... right. sorry.
2023-11-09 10:48:35 <ncopa> im a bit stressed over here... :) 
2023-11-09 10:50:29 <chereskata> Im a fan of devendoring everything in theory. Is it even possible with rust?
2023-11-09 10:51:03 <chereskata> Maybe move dotnet and npm based (personal opinion: trash) to testing?
2023-11-09 10:51:35 <ikke> Testing is not a destination 
2023-11-09 10:51:45 <chereskata> haha
2023-11-09 10:52:03 <ikke> We will start removing packages from testing after 6 months 
2023-11-09 10:52:25 <chereskata> Even if they are maintained?
2023-11-09 10:55:29 <ikke> If it's maintained, it should be moved to community 
2023-11-09 11:00:16 <PureTryOut> ikke: oh removing after 6 months, is that a new policy? I like it
2023-11-09 11:00:19 <chereskata> Okey :)
2023-11-09 11:17:23 <ikke> PureTryOut: was decided a while ago, but we just started actually implementing it 
2023-11-09 11:18:05 <ikke> https://gitlab.alpinelinux.org/alpine/aports/#testing
2023-11-09 11:18:32 <ikke> After 6 months a notification and removal after 9
2023-11-09 12:01:00 <ptrc> ikke: oh, so is there currently no place (in Alpine?) for packages that are too unstable for community? iirc there was a proposal to split another repo off of testing for that kind of stuff
2023-11-09 12:01:12 <ptrc> s/community/stable releases/
2023-11-09 12:02:04 <PureTryOut> ikke: great!
2023-11-09 12:05:44 <ptrc> tbh i'm slightly worried about getting even more "technically orphaned" packages where the maintainer moves it to community because of that requirement, but then forgets about alpine, leaving the package to rot in community instead and forcing developers to fix the issues in stable releases
2023-11-09 12:58:42 <chereskata> To the above: maybe we should have more strict package removal criterion in community. 
2023-11-09 12:59:06 <chereskata> Offtopic: I suspect libxkbcommon in its current version to be the cause of https://gitlab.alpinelinux.org/alpine/aports/-/issues/15378
2023-11-09 12:59:27 <chereskata> how can i downgrade to a previous (self built) version of that package
2023-11-09 12:59:50 <ikke> if it's in a repo: `apk add libxkbcommon=<version>'
2023-11-09 13:02:34 <omni> or if you have a <package>.apk: apk add /path/to/<package>.apk
2023-11-09 13:02:37 <ikke> yes
2023-11-09 13:24:42 <chereskata> thanks!
2023-11-09 15:24:59 <ncopa> alright, i think its time for me to take a break from alpine
2023-11-09 15:25:07 <ncopa> 2 weeks
2023-11-09 15:25:43 <ncopa> feel free to merge an MRs assigned to me meanwhile. specially if its only a patch version bump or security fix
2023-11-09 15:34:04 <khem> ncopa: enjoy the offtime ( vacation I guess )
2023-11-09 15:40:28 <omni> ncopa: good job on fixing the things and enjoy your time off!
2023-11-09 15:42:37 <ysionneau> for lua packages is it possible to just ask abuild to build one version and not all of them?
2023-11-09 15:42:54 <ysionneau> like for instance building lua-cjson but only the lua5.2 one
2023-11-09 15:52:49 <ncopa> thank you! - would be wonderful if builders are all done and 'idle' when im back... ;)
2023-11-09 15:53:46 <donoban> happy break!
2023-11-09 15:54:21 <ysionneau> enjoy ncopa !
2023-11-09 15:54:58 <ncopa> o/
2023-11-09 16:06:29 <ysionneau> hmm weird when building lua-optarg it asks for lua-unit , but website does not show it as dependency: https://pkgs.alpinelinux.org/package/edge/main/x86_64/lua5.2-optarg
2023-11-09 16:07:16 <ysionneau> maybe because it's only a build dependency?
2023-11-09 16:12:30 <ikke> yes
2023-11-09 16:12:38 <ikke> pkgs.a.o only shows run-time dependencies
2023-11-09 16:23:46 <ysionneau> ikke: ok thanks
2023-11-09 16:31:29 <Kladky> ptrc: you mentioned in !52568 that bundled rocksdb should be avoided, but it seems that sqlite is bundled aswell: https://gitlab.com/famedly/conduit/-/blob/next/Cargo.toml?ref_type=heads#L79
2023-11-09 16:32:12 <Kladky> Sorry, meant !54805
2023-11-09 16:32:42 <ptrc> if you check `apk info --depends conduit`, you can see that it's linking against the system one though
2023-11-09 16:33:33 <ptrc> and if you check the actual aport, there's a system-sqlite.patch patch
2023-11-09 16:33:38 <ptrc> which removes the part that you highlighted
2023-11-09 16:34:28 <Kladky> Oh you're right, I missed that...
2023-11-09 16:35:32 <Kladky> And yep, when building inside a chroot without sqlite-dev it fails, sorry about that.
2023-11-09 16:36:27 <Kladky> Lastly, since it is dynamically linked against sqlite, that means the sqlite package must be available at runtime, right?
2023-11-09 16:36:54 <ikke> yes
2023-11-09 16:37:15 <ikke> sqlite-libs to be more precise
2023-11-09 16:37:23 <Kladky> Should there be a post-install message mentioning that then?
2023-11-09 16:37:40 <ikke> abuild automatically adds it as a dependency
2023-11-09 16:37:52 <ikke> try apk info -R rocksdb
2023-11-09 16:38:21 <ikke> You should see so:libsqlite3.so.0.8.6 or something like that
2023-11-09 16:38:39 <Kladky> Yea for conduit.
2023-11-09 16:39:15 <ikke> So when you install the package, apk automatically pulls in sqlite-libs
2023-11-09 16:39:43 <Kladky> So if !54805 is merged, both rocksdb and sqlite-libs will be installed by apk?
2023-11-09 16:40:21 <ptrc> correct
2023-11-09 16:40:26 <ptrc> you can see that in the CI output:
2023-11-09 16:40:30 <ptrc> https://gitlab.alpinelinux.org/Kladky/aports/-/jobs/1173747#L1133
2023-11-09 16:40:43 <Kladky> Ok, thanks!
2023-11-09 18:02:40 <Kladky> Shouldn't cargo-audit list cargo as a dependency as it refuses to run unless invoked by cargo?
2023-11-09 18:05:44 <Kladky> *cargo-auditable
2023-11-09 19:58:06 <z3ntu> Are the much right now? I didn't see the build-edge-x86_64 change in the last hour or so, and I'm waiting to be able to install qt5-qtbase again which is broken since the icu rebuild
2023-11-09 19:58:16 <z3ntu>  * Are the builders doing much right now? I didn't see the build-edge-x86_64 change in the last hour or so, and I'm waiting to be able to install qt5-qtbase again which is broken since the icu rebuild
2023-11-09 20:00:00 <ikke> z3ntu: plenty busy
2023-11-09 20:01:30 <ikke> building these projects takes ages
2023-11-09 20:03:46 <z3ntu> is there any way these half finished rebuilds don't get pushed into the repos until everything's rebuilt? I'm kinda blocked on doing anything with qt5-qtbase until this is done, and it's been already more than 24 hours since I've seen this one first I think
2023-11-09 20:04:57 <ikke> We'd have to make uploading main wait until community (and possibly testing) has finished
2023-11-09 20:05:02 <ikke> Which is a policy change'
2023-11-09 20:05:41 <ikke> Right now, community could be broken but packages in main still get updated
2023-11-09 20:05:59 <ikke> Otherwise, any broken package would block all repos
2023-11-09 20:09:17 <z3ntu> might still be better than having broken repos? at least main+community should be finished imo, as per recent policy testing shouldn't be a big thing anyways so things could be broken there
2023-11-09 21:43:03 <craftyguy> are there many Alpine users who can use main exclusively? at least in pmOS, these types of main<->community breakages affect basically all of our users. I'm guessing most folks using Alpine might also run into problems when the two repos are "out of sync", but maybe I'm wrong :P
2023-11-09 21:43:54 <craftyguy> (obviously only certain packages are affected by these situations, so it's rarely "everyone", but icu seems to touch a lot of stuff :P)
2023-11-09 21:48:58 <Kladky> It can be hard to tell since Alpine doesn't have any sort of analytics, but I would assume most people use community repos
2023-11-09 21:49:40 <Kladky> And people in the devel channel most likely use edge + testing cause, y'know.
2023-11-09 21:50:25 <ysionneau> 
ACTION is having alpine boot on real hw (kvx arch) now, and natively starting to build packages (perl is building...). It's faster with 16 real 1GHz cpu than with 16 qemu emulated ones :D

2023-11-10 01:26:02 <omni> celie: I've beeen thinking about looking at ocaml5 again, there's just been so much else going on
2023-11-10 01:29:37 <celie> I think the deletion script should check for commit date, and (if possible) also check for the latest "new aport" message, otherwise aports that have been added to testing/ before have potential to become a false positive
2023-11-10 01:31:49 <celie> Taking perl-io-async as an example, which i am trying to get into community/ in !55006
2023-11-10 01:32:31 <celie> Looking through https://git.alpinelinux.org/aports/log/?qt=grep&q=perl-io-async
2023-11-10 01:33:51 <celie> i see it was added to testing/ then moved to main/, and finally moved to unmantained/ before being deleted
2023-11-10 01:35:07 <celie> a week ago, i added it back to testing/ without knowing its history, and a few days later i find it marked for deletion
2023-11-10 01:40:22 <celie> or rather, a week ago, the MR containing perl-io-async was committed to testing/
2023-11-10 01:41:49 <celie> ocaml5 sat as a draft for 8 months, and is marked for deletion now after being committed to testing/ less than 3 months ago
2023-11-10 01:46:17 <celie> Sorry for the rant, it is not my intention to question the decision to clean testing/, but seeing something that you have been working on a week ago being slated for deletion is just distressing
2023-11-10 01:51:09 <celie> Imo, the deletion MR should have been posted as a list of aports first, rather than an MR (imo, again, what that has done instead is to balloon community/ for 3.19 as maintainers scramble to save what they have been working on)
2023-11-10 01:54:04 <celie> or at the very least, the MR could just remove the maintainer (orphan the aport), to see if others will pick it up before being deleted in something like !54248, at least then it wouldn't be deleting like half of testing/ or whatever
2023-11-10 01:55:13 <celie> Removing the maintainer should probably be considered as a substitute for deleting, at least for the first 1 or 2 runs (which i guess would mean next year)
2023-11-10 01:57:22 <celie> Alright, i'll stop here now, /end rant
2023-11-10 07:47:57 <omni> I haven't looked closely at the deletion MR myself yet
2023-11-10 09:38:11 <omni> I'm holding off from merging to master until builders catch up
2023-11-10 10:30:24 <donoban> I'm waiting for test qt6-qtwebengine built with gcc, i've checked many times since yesterday but I still on 6.6.0-r2
2023-11-10 10:31:49 <ikke> The builders are still busy 
2023-11-10 10:35:01 <donoban> yeah, there is no rush
2023-11-10 11:25:16 <omni> https://build.alpinelinux.org/
2023-11-10 11:28:16 <ikke> Maybe we should reduce the amount of chromium duplicates we have to build
2023-11-10 11:30:38 <donoban> omni: do you still having problems with qt6-qtwebengine?
2023-11-10 11:51:50 <ovf> i see a mention of -R in abump's usage message, but looks like it has never been implemented?
2023-11-10 11:53:03 <ikke> It has been removed 
2023-11-10 12:09:07 <lnl> what's the list of chromium forks in aports?
2023-11-10 12:15:06 <ikke> qt5/6-qtwebengine, electron, chromium itself
2023-11-10 15:11:04 <omni> donoban: I have issues sometimes
2023-11-10 15:11:53 <omni> and when I do, the most frustrating issue is that keypresses are duplicated so that, for example, I cannot change tab because it immediately switches back to the tab I came from or jumps over the one I wanted to go to
2023-11-10 15:12:18 <omni> consistently
2023-11-10 15:13:12 <omni> so I mostly stick to qt5-qtwebengine
2023-11-10 15:28:26 <ovf> is build-edge-x86_64 ok? it's been building chromium for almost 12 hours now?
2023-11-10 15:28:58 <ikke> It was this afternoon 
2023-11-10 15:30:25 <ikke> It's linking now
2023-11-10 15:32:21 <ikke> 3000% cpu usage 
2023-11-10 15:36:40 <Ermine> = 30 fully occupied cores?
2023-11-10 15:37:44 <ikke> 32
2023-11-10 15:38:04 <ikke> It maxes out at 3200%
2023-11-10 15:38:18 <omni> and also emulating riscv64 and running CI build jobs for x86_64?
2023-11-10 15:38:25 <ikke> No
2023-11-10 15:38:27 <omni> oh
2023-11-10 15:38:33 <ikke> This host is a dedicated builder 
2023-11-10 15:38:43 <omni> ok
2023-11-10 15:38:52 <omni> I have things mixed up then
2023-11-10 15:39:11 <ikke> We have a dev host where the rv64 builder lives 
2023-11-10 15:39:18 <omni> ok
2023-11-10 15:58:29 <ikke> chromium finished 🎉
2023-11-10 16:15:27 <omni> w00t!
2023-11-10 16:15:42 <omni> then all the rest will be done real soon, right?
2023-11-10 16:15:44 <omni> right?
2023-11-10 16:17:01 <ikke> unless there is another chromium hiding somewhere :P
2023-11-10 16:26:13 <lnl> it's on deno now, do we count just V8 as chromium? :p
2023-11-10 16:35:49 <papiris[m]> Darktable build for aarch64 failed because GCC does not currently support mixed size types for 'simd' functions
2023-11-10 16:35:56 <papiris[m]> https://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/darktable/darktable-4.4.2-r2.log
2023-11-10 16:37:24 <ikke> papiris[m]: I noticed it was failing (and am the maintainer). Do you have an idea how to fix that?
2023-11-10 16:39:14 <papiris[m]> I can bash my brain for an hour, search around, see if I can find something. But I'm not good at C programming at all, so my mileage may vary
2023-11-10 16:40:30 <ovf> https://github.com/darktable-org/darktable/issues/15067#issuecomment-1697066708
2023-11-10 16:40:56 <ovf> i feel pretty bad about clang-only software
2023-11-10 16:47:30 <ikke> "clplatform_armplatform=TRUE is now necessary for ARM platform"
2023-11-10 16:47:45 <ikke> Not sure what that refers to though
2023-11-10 16:48:35 <ikke> Otherwise I guess I'll disable it on aarch64
2023-11-10 16:48:44 <ikke> not sure if anyone is using it on arm
2023-11-10 16:51:08 <papiris[m]> Does a version prior to the MR @ovf linked to; getting merged, compile?
2023-11-10 16:51:14 <andypost[m]> ikke: looks deno also building 5th v8 at least
2023-11-10 16:52:05 <andypost[m]> Half of chromium)
2023-11-10 16:52:31 <lnl> nah I think the heaviest part there is blink after all
2023-11-10 16:55:42 <lnl> now I wonder how many vendored boringssls are in the repo
2023-11-10 16:58:29 <lnl> like if you download signal-desktop there's for sure one in libsignal, one in webrtc, and one in electron (which itself also has the entire webrtc, too)
2023-11-10 17:33:13 <quinq> Hummm, is there a reason why there's no libmagic-dev package?
2023-11-10 17:33:26 <quinq> (mainly for magic headers)
2023-11-10 17:36:12 <ptrc> wouldn't that be in like, file-dev?
2023-11-10 17:36:31 <ikke> yes
2023-11-10 17:37:40 <quinq> hu
2023-11-10 17:38:26 <ikke> quinq: https://pkgs.alpinelinux.org/package/edge/main/x86_64/libmagic
2023-11-10 17:38:29 <ikke> check the origin package
2023-11-10 17:38:35 <quinq> File doesn't provide any library
2023-11-10 17:40:27 <ikke> The -dev package is by default called $pkgname-dev
2023-11-10 17:40:37 <ikke> so because the package name is file, the dev package bacome file-dev
2023-11-10 17:40:49 <ikke> even though the libmagic libs are moved to a separate subpackage
2023-11-10 17:40:54 <quinq> Why are they?
2023-11-10 17:41:28 <Ermine> Please take a look at !53231 , bot got worried about it
2023-11-10 17:41:42 <ikke> quinq: why are they what?
2023-11-10 17:42:14 <quinq> Why are they moved to a package named libmagic instead of file-libs
2023-11-10 17:42:37 <quinq> As the development files for the libraries are called file-dev instead of (lib)magic-dev
2023-11-10 17:43:16 <ikke> beter recognizability I suppose
2023-11-10 17:43:46 <quinq> Contrary to file-dev, then
2023-11-10 17:44:16 <quinq> Anyway, thanks for the answers :)
2023-11-10 17:47:18 <papiris[m]> The fix for darktable on aarch64 seems to be part of the 4.6 release, set for 21. December. If we want it fixed for arm before then, I suppose, we need to change the source as per the MR: https://github.com/darktable-org/darktable/pull/15207/files
2023-11-10 17:49:55 <ikke> papiris[m]: thanks for investigating, will try that patch
2023-11-10 17:51:53 <papiris[m]> whoops, I fell off the train of thought after dinner. https://github.com/darktable-org/darktable/issues/15067#issuecomment-1697657583 says clang is still necessary, even with this patch. Apologies, ikke 
2023-11-10 17:52:39 <ikke> Yeah, wouldn't supprise me as the patch didn't seem to involve any simd instructions as far as I could tell (unless they were in those specific functions, but that seemed unlikely to me)
2023-11-10 17:53:50 <papiris[m]> That said, do our build runners support clang?
2023-11-10 17:55:38 <ikke> We can build with clang, yes
2023-11-10 18:02:58 <ikke> lol: "A terminally deprecated method has been called"
2023-11-10 18:03:14 <papiris[m]> haha
2023-11-10 18:03:43 <ikke> java-zstd-jni
2023-11-10 18:04:09 <papiris[m]> guess devs got tired of supporting old cruft
2023-11-10 18:40:01 <papiris[m]> I wanted to use symlinks in the Makefile of my package `apk-snap` to save space and KISS, but it's got problems. If I do `@ln -s $(DESTDIR)$(PREFIX)/bin/apk-snap $(DESTDIR)/etc/apk/commit_hooks.d/` , when I install the package it still points to the `$pkgdir`, not the equivalent dir in my system.
2023-11-10 18:40:01 <papiris[m]> How can I make a symbolic link or thin copy from the executable in `/usr/bin/`, to `/etc/apk/commit_hooks.d/`?
2023-11-10 18:40:11 <papiris[m]> * I wanted to use symlinks in the Makefile of my package apk-snap to save space and KISS, but it's got problems. If I do @ln -s $(DESTDIR)$(PREFIX)/bin/apk-snap $(DESTDIR)/etc/apk/commit_hooks.d/ , when I install the package it still points to the $pkgdir, not the equivalent dir in my system.
2023-11-10 18:40:11 <papiris[m]> How can I make a symbolic link or thin copy from the executable in /usr/bin/, to /etc/apk/commit_hooks.d/?
2023-11-10 18:40:20 <papiris[m]> How can I make a symbolic link or thin copy from the executable in /usr/bin/, to /etc/apk/commit_hooks.d/?
2023-11-10 18:40:20 <papiris[m]> * I wanted to use symlinks in the Makefile of my package apk-snap to save space and KISS, but it's got problems. 
2023-11-10 18:40:20 <papiris[m]> If I do @ln -s $(DESTDIR)$(PREFIX)/bin/apk-snap $(DESTDIR)/etc/apk/commit_hooks.d/ , when I install the package it still points to the $pkgdir, not the equivalent dir in my system.
2023-11-10 18:40:28 <papiris[m]> * I wanted to use symlinks in the Makefile of my package apk-snap to save space and KISS, but it's got problems. 
2023-11-10 18:40:28 <papiris[m]> If I do @ln -s $(DESTDIR)$(PREFIX)/bin/apk-snap $(DESTDIR)/etc/apk/commit_hooks.d/ , when I install the package it still points to the $pkgdir, not the equivalent dir in my system.
2023-11-10 18:40:29 <papiris[m]> How can I make a symbolic link or thin copy from the executable in /usr/bin/, to /etc/apk/commit_hooks.d/?
2023-11-10 18:40:40 <ikke> Please don't use the edit feature, it's quite noisy on irc
2023-11-10 18:40:58 <papiris[m]> Ah, apologies
2023-11-10 18:41:47 <papiris[m]> I couldn't see the telltale bridge bot, so I didn't think there was an IRC bridge
2023-11-10 19:10:43 <craftyguy> papiris[m]: leave off DESTDIR in the source?
2023-11-10 19:11:22 <craftyguy> so it's something like "ln -s /bin/apk-snap $(DESTDIR)/etc/apk/commit_hooks.d"
2023-11-10 19:38:20 <ikke> elly: chromium is failing on aarch64 much like qt6-qtwebengine due to std::bad_alloc (even though the builder has more than enough memory). qt6-qtwebengine was fixed by switching back to building with gcc again, so I suppose we should do the same for chromium
2023-11-10 19:50:46 <sam_> when we've hit this, it's often because of stack size issues
2023-11-10 19:50:52 <sam_> make sure lld is built with the larger stack size param
2023-11-10 20:44:38 <ikke> hmm, I don't see any specific flags to adjust the stack size being specified
2023-11-10 20:52:28 <sam_> we do: use elibc_musl && append-ldflags -Wl,-z,stack-size=2097152
2023-11-10 20:52:46 <ikke> #11086
2023-11-10 20:53:27 <sam_> looks like it is not in the latest apkbuild
2023-11-10 20:53:32 <ikke> yeah, I didn't see it
2023-11-10 20:53:49 <sam_> dropped in https://git.alpinelinux.org/aports/commit/main/lld/APKBUILD?id=c69f28c2c002f9114d204dea9b885586834480c0
2023-11-10 20:55:06 <ikke> With no mention of why
2023-11-10 20:55:58 <ikke> sam_: thanks
2023-11-10 20:56:01 <sam_> np
2023-11-10 20:57:08 <sam_> btw, we do the same for binutils
2023-11-10 20:57:13 <sam_> might be worth you doing it at the same time while at it
2023-11-10 20:58:02 <sam_> just so it doesn't pop up another time 
2023-11-10 21:02:02 <ikke> any way to verify that the stack size has been increased?
2023-11-10 21:02:37 <sam_> I think it adds a note in ELF
2023-11-10 21:02:43 <sam_> let me see
2023-11-10 21:03:01 <ikke> I was already checking readelf output
2023-11-10 21:03:14 <sam_> I remember answering this question ages ago for someone but I'm trying to remember the answer
2023-11-10 21:03:19 <ikke> Properties: stack size: 0x200000
2023-11-10 21:03:38 <ikke> Displaying notes found in: .note.gnu.property
2023-11-10 21:04:19 <ikke> seems to match
2023-11-10 21:04:44 <ikke> so readelf -n <binary>
2023-11-10 21:07:47 <sam_> thanks!
2023-11-10 21:08:31 <sam_> looks like we also do it for cjs, gjs, nothing else (so binutils + cjs + gjs + lld)
2023-11-10 21:08:44 <sam_> at some point I should send it upstream for LLVM given they acknowledged it
2023-11-10 21:09:21 <ikke> I at least changed it for lld now
2023-11-10 21:09:25 <ikke> See if it fixes chromium
2023-11-10 22:38:34 <andypost[m]> btw ikke building few extra tests for php showed that default stack size on builders and in CI are different
2023-11-10 22:39:33 <andypost[m]> ppc64 reported: Maximum call stack size of 81920 bytes reached during compilation
2023-11-10 22:40:33 <andypost[m]> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1176577
2023-11-10 22:41:07 <andypost[m]> that's for CI but the failed test does not fail on builders(
2023-11-10 23:04:00 <andypost[m]> ppc64le has 80k stack that's why only this arch fails
2023-11-10 23:09:45 <PureTryOut> Seems most edge builders have largely caught up now. Just x86_64 and aarch64 keep failing on Chromium...
2023-11-11 05:52:35 <ikke> x86_64 is not failing on chromium, and already onto testing
2023-11-11 05:53:07 <ikke> It's only aarch64 that fails on chromium, similar to qt6-qtwebengine 
2023-11-11 06:00:21 <ikke> The lld stack size fix didn't help
2023-11-11 06:31:14 <ikke> hmm, chromium on aarch64 now fails with a different message
2023-11-11 07:46:49 <omni> the difference in our chached manticoresearch-5.0.2.tar.gz compared to the new upstream is in src/sphinxversion.h.in:
2023-11-11 07:46:51 <omni> -// GIT_COMMIT_ID "348514c86"
2023-11-11 07:46:52 <omni> +// GIT_COMMIT_ID "348514c866"
2023-11-11 07:47:30 <ikke> I guess their repo grew and git increased the minimun hash size
2023-11-11 08:02:03 <lnl> yeah same happened with a zig patch recently
2023-11-11 15:43:07 <sam_> ikke: can you show me the new error?
2023-11-11 15:51:28 <ikke> sam_: hmm, it was a bit of a vague message. The latest shows the std::bad_alloc again, but what I recall is that linking failed with 'terminate called recursively' and 'c++ unable to execute command aborted'
2023-11-11 16:39:43 <papiris[m]> I'll write a snippet on the wiki about how `apk` commit hooks work.
2023-11-11 16:39:43 <papiris[m]> Should it go in #Create an Alpine package or #apk ?
2023-11-11 16:41:50 <papiris[m]> Maybe #apk under chapter ## advanced usage?
2023-11-11 17:27:31 <andypost[m]> some strange errors in armv7/armhf CI https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1178442
2023-11-11 21:06:43 <ikke> andypost[m]: docker has issues
2023-11-11 21:07:02 <ikke> https://www.dockerstatus.com/pages/incident/533c6539221ae15e3f000031/654faa887895d304cc474aed
2023-11-12 02:08:01 <Lestat9> Become a ghost person, get in a situation where the mind gives the perceived death signal, watch a scary movie alone in the dark,when it does just ignore it or pay no attention to it. -Copyright: TXu 2-037-947- Rest the scientists- ghostpeople@gmx.com
2023-11-12 02:11:53 <Lestat9> Become a ghost person, get in a situation where the mind gives the perceived death signal, watch a scary movie alone in the dark,when it does just ignore it or pay no attention to it. -Copyright: TXu 2-037-947- Rest the scientists- ghostpeople@gmx.com
2023-11-12 02:15:45 <Lestat9> Become a ghost person, get in a situation where the mind gives the perceived death signal, watch a scary movie alone in the dark,when it does just ignore it or pay no attention to it. -Copyright: TXu 2-037-947- Rest the scientists- ghostpeople@gmx.com
2023-11-12 11:16:03 <quinq> ikke, regarding file/libmagick/file-dev, there's *kind of* another contradictory example, xscreensaver/libxscrnsaver/libxscrnsaver-dev
2023-11-12 11:16:27 <quinq> (just saying because I need the latter right now and seeing it)
2023-11-12 14:18:39 <quinq> ptrc, thank you very much for the webkit2gtk upgrade! :D
2023-11-12 14:29:18 <ptrc> quinq: you're welcome :3 fwiw it's still outdated, .2 came out recently, i'll bump it today as well
2023-11-12 14:29:31 <ptrc> but at least it has less security vulnerabilities :)
2023-11-12 14:36:16 <quinq> :))
2023-11-12 16:21:38 <lnl> https://gitlab.alpinelinux.org/selfisekai/aports/-/jobs/1179264
2023-11-12 16:21:40 <lnl> oh come on
2023-11-12 16:21:58 <lnl> chromium std::bad_alloc even on x86_64 now?
2023-11-12 16:42:15 <ikke> ugh
2023-11-12 16:43:34 <ikke> I hope it's not caused by 4ab6ef38f167f4983008f8b213e5beace8d453f0
2023-11-12 17:06:08 <elly> hello!
2023-11-12 17:06:39 <elly> I can help investigate that a bit later today as well, I just got back from a long trip
2023-11-12 17:07:03 <ikke> elly: welcome back
2023-11-12 17:07:16 <elly> thanks!
2023-11-12 17:07:47 <ikke> If have haven't noticed, I disabled chromium on aarch64 as it was blocking the builders and community was broken due to the ICU update
2023-11-12 17:07:52 <elly> oh, a crash in the linker during build, that's gross
2023-11-12 17:07:53 <ikke> s/have/you/
2023-11-12 17:07:57 <ikke> elly: yes
2023-11-12 17:08:00 <elly> ikke: I haven't read my email yet, thank you for letting me know
2023-11-12 17:08:12 <ikke> elly: to be honest, I still had to create a ticket :P
2023-11-12 17:08:15 <elly> the aarch64 build ought to work, it's tested upstream, but icu is like ugh
2023-11-12 17:08:16 <elly> ah I see
2023-11-12 17:09:09 <ikke> and disabling chromium enables you to test the build, I couldn't build it locally due to icu version mismatch
2023-11-12 17:09:55 <elly> I feel the icy wind of using the bundled icu rising
2023-11-12 17:11:08 <ikke> That was just because the rebuilt packages in community could not be uploaded yet due to chromium failing to build
2023-11-12 17:26:43 <omni> I think !53217 is redy to be merged, but it's locked
2023-11-12 17:27:50 <ikke> Unlocked
2023-11-12 17:53:48 <omni> <3
2023-11-12 23:35:57 <ptrc> apparently qemu-user is broken in some aspects
2023-11-12 23:36:19 <ptrc> for example, reading /proc/self/stat or /proc/$pid/stat from its own process returns mostly empty values
2023-11-12 23:36:43 <ptrc> and that affects the rv64 builder, for example when a random rust crate is trying to get the thread count 
2023-11-12 23:47:34 <ptrc> apparently they're hijacking that on purpose: https://github.com/qemu/qemu/blob/5d94c2f/linux-user/syscall.c#L8130
2023-11-13 01:35:01 <Hello71> doesn't rust use sched_getaffinity
2023-11-13 02:11:52 <ptrc> well, more specifically, the time crate checks if it's running single-threaded
2023-11-13 02:12:03 <ptrc> and it's using /proc/self/stat, because.. i have no idea why
2023-11-13 07:41:52 <Arnavion> ptrc: Some time ago there was a kerfuffle about libc getenv / setenv not being multi-threaded-safe, so the fact that localtime-related fns internally did getenv meant those fns could not be used if another part of the program did std::env::set_var()
2023-11-13 07:42:57 <Arnavion> I want to believe that most Rust users (including myself) recognized that an issue that only happens if a program has multiple threads *and* does set_var() *and* does something involving localtime would be a rare issue, but the time crate's maintainer is very militant about "correctness", so...
2023-11-13 08:12:48 <quinq> Not sure what's the context, but yes these are not thread safe, so they're not to be called within libraries, or it should be documented that segment of the library should only be called in safe context (before running threads, within proper locking, or no threading at all)
2023-11-13 08:29:29 <ptrc> oh, interesting, thank you both ^^
2023-11-13 18:12:52 <caskd[m]> fcolista: are you aware that libvirt-qemu 'default' autostart causes nftables tables to be deleted?
2023-11-13 18:14:02 <caskd[m]> i've had this happen on some sensitive hosts where they got exposed without me knowing, and disabling it just disables it until you upgrade to the next version as it just deletes the file (instead of modifying it within /etc)
2023-11-13 18:15:04 <caskd[m]> nothing bad happened but that doesn't mean that nothing bad might happen
2023-11-13 18:15:05 <caskd[m]> please let me know how we should handle this problem, it's both annoying and a security concern
2023-11-13 18:20:00 <caskd[m]> (i'm afraid of breaking things :P)
2023-11-13 18:31:38 <minimal> caskd[m]: did you create a gitlab issue for this?
2023-11-13 18:59:08 <caskd[m]> not yet, just thought it might be simpler to ask first as it might be as simple as a PR
2023-11-13 19:02:51 <minimal> caskd[m]: I would suggest you create an Issue and put sufficient information in there so that the issue is easily reproducable
2023-11-13 19:31:18 <hjaekel> Hi, is the CI pipeline currently broken? 
2023-11-13 19:33:12 <ikke> hjaekel: what's up?
2023-11-13 19:33:46 <hjaekel> my pipeline #194155 does not start
2023-11-13 19:34:08 <ikke> There are 2 large jobs running
2023-11-13 19:35:01 <hjaekel> OK, then I wait
2023-11-13 19:37:32 <ikke> I canceled one which appeared to be hanging
2023-11-13 21:29:10 <omni> could someone who feels a bit comfortable wrt licenses update the wiki to say something about MIT licenses and why the license file need to be included in the -doc subpackage?
2023-11-13 21:29:16 <omni> https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#license
2023-11-13 21:29:56 <omni> related !54528
2023-11-13 21:30:15 <ikke> I'm not particularly good with licenses, but for MIT it's not that difficult: the license has a copyright notice that you need to reproduce
2023-11-13 21:30:44 <ikke> "The above copyright notice and this permission notice (including the next paragraph) shall be included in all copies or substantial portions of the Software."
2023-11-13 21:30:52 <ikke> That's part of the MIT license
2023-11-13 21:37:51 <omni> ikke: I added to the wiki, please adjust if needed https://wiki.alpinelinux.org/w/index.php?title=Creating_an_Alpine_package&diff=25647&oldid=25479
2023-11-13 21:38:36 <ikke> Note that MIT is just an example, there may be more licenses that have similar requirements
2023-11-13 21:45:05 <ikke> omni: https://wiki.alpinelinux.org/w/index.php?title=Creating_an_Alpine_package&diff=25648&oldid=25647
2023-11-13 21:47:29 <omni> 👍
2023-11-13 22:32:10 <omni> guddaff: !54997
2023-11-14 00:11:57 <omni> someone else will have to take over fixing the lomiri-location-service build
2023-11-14 00:17:51 <ptrc> sure, could do that
2023-11-14 00:20:54 <omni> :*
2023-11-14 01:28:37 <omni> good job
2023-11-14 01:29:56 <omni> ptrc: active libvmime development seem to be at https://github.com/kisli/vmime linked to from https://www.vmime.org/
2023-11-14 01:30:27 <omni> if that would solve anything, changing upstream and upgrade to some git commit
2023-11-14 02:32:14 <ptrc> might try, thanks for the link
2023-11-14 06:05:36 <WhyNotHugo> Can I configure `abuild rootbld` to re-use the apk cache from my host?
2023-11-14 07:15:14 <caskd[m]> it should use /etc/apk/cache for preparing the packages
2023-11-14 07:15:41 <caskd[m]> unless you are cross-building
2023-11-14 07:21:00 <WhyNotHugo> It doesn't, it's not even using the same repositories from /etc/apk/repositories.
2023-11-14 07:21:24 <caskd[m]> not using the same repositories is expected as it uses .rootbld-repositories
2023-11-14 07:22:04 <caskd[m]> but assuming those are identical it should be able to reuse them without problems
2023-11-14 07:22:29 <WhyNotHugo> Where is .rootbld-repositories located?
2023-11-14 07:22:52 <caskd[m]> parent of the repo, so for example on aports it would be under main/.rootbld-repositories
2023-11-14 07:23:10 <caskd[m]> repo here being a alpine repo and not a git repo
2023-11-14 07:23:29 <WhyNotHugo> I see it now. Where does the $mirror variable get populated from?
2023-11-14 07:25:06 <caskd[m]> it seems to be populated via abuild itself unless it is overriden via a environment var export
2023-11-14 07:25:21 <WhyNotHugo> Ah, I'll peek into the source a bit more, thanks.
2023-11-14 07:26:08 <caskd[m]> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in?ref_type=heads#L2580
2023-11-14 07:26:16 <caskd[m]> this might be helpful
2023-11-14 07:59:50 <fluix> WhyNotHugo: re your new aports MR, if tests aren't in release tarballs, use the GitHub release tarballs where available
2023-11-14 08:00:11 <fluix> this is a common occurance
2023-11-14 10:16:12 <WhyNotHugo> fluix: thanks, done
2023-11-14 10:47:57 <omni> !47987 - they've been at it for a while and, at a glance, it looks ok
2023-11-14 10:49:06 <omni> the only thing I can think of is if provides="larynx2=$pkgver-r$pkgrel" would be a good idea and should be suggested
2023-11-14 10:52:05 <omni> would that also replace larynx2 with piper-tts when `apk -aU upgrade`?
2023-11-14 11:29:05 <omni> !54968 looks good but is locked
2023-11-14 16:40:33 <durrendal> in the past there used to be an option to approve an MR, but it seems to have gone away, any particular reason why? It seemed like a pretty simple way for a maintainer to approve an MR someone opened on their behalf
2023-11-14 16:41:48 <ikke> durrendal: that was due to a change in gitlab, to prevent any random guest approving any MR
2023-11-14 16:42:11 <ikke> I can add you as a guest directly to aports so that you can approvie again
2023-11-14 16:42:36 <ikke> done
2023-11-14 16:43:52 <durrendal> thank you so much ikke really appreciate it :)
2023-11-15 03:16:00 <bl4ckb0ne> PureTryOut: did you ever got around the directfb sdl2 issue with monado?
2023-11-15 07:51:22 <PureTryOut> No, no clue what is happening there
2023-11-15 10:19:20 <chereskata> Could someone merge !51119 ?
2023-11-15 10:19:42 <chereskata> finally it has no conflicts :D
2023-11-15 11:32:44 <ikke> chereskata: regarding https://gitlab.alpinelinux.org/alpine/aports/-/commit/dbc0d6fab448e35e967b1f56d482cb6bfcaa0113?merge_request_iid=51119, has there been some issue created to follow that up?
2023-11-15 11:34:11 <chereskata> No. The disabled tests have been there before. Had to just refine for code changes
2023-11-15 11:34:25 <ikke> ah you are right
2023-11-15 11:38:54 <ikke> brace for impact
2023-11-15 11:58:41 <ikke> opencv: LLVM ERROR: Do not know how to widen this operator's operand!
2023-11-15 11:58:42 <ikke> PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
2023-11-15 12:41:15 <chereskata> Could someone merge !55366 !54063
2023-11-15 15:41:40 <lnl> >Partial download found. Trying to resume. ** Resuming transfer from byte position 31702
2023-11-15 15:41:56 <lnl> huh, how can this happen on a builder?
2023-11-15 15:43:22 <lnl> (then sha512 broke, so something's invalid here)
2023-11-15 18:21:06 <ptrc> lnl: which builder was that?
2023-11-15 21:03:27 <lnl> https://build.alpinelinux.org/buildlogs/build-3-18-aarch64/community/yt-dlp/yt-dlp-2023.11.14-r0.log
2023-11-15 21:03:44 <lnl> but others also failed on checksum
2023-11-16 01:41:27 <ncopa> do we dare bump linux-its to 6.6 for alpine 3.19? might be good since we need to maintain 3.19 for two years
2023-11-16 02:06:17 <durrendal> how big of a jump is it?
2023-11-16 02:06:18 <khem> ncopa: we bumped from 6.4 to 6.5 in yocto at last moment and it was a bit of pain but worth it
2023-11-16 02:06:45 <khem> I guess you meant linux-lts right ncopa ?
2023-11-16 02:45:42 <minimal> ncopa: just need to make sure CONFIG_EFI_HANDOVER_PROTOCOL=y is set - this was added in kernel 6.2 and if it is not "=y" then GRUB and GUMMIBOOT etc will not boot (not sure if it is enabled by default)
2023-11-16 02:46:03 <minimal> for UEFI systems that is...
2023-11-16 02:48:46 <khem> hmm so 6.6 is going to be new LTS .. cool
2023-11-16 09:51:48 <fancsali[m]> Hey peeps!
2023-11-16 09:51:48 <fancsali[m]> I am trying to package an app, that uses git submodules - but the release tarballs don't have those subdirs.
2023-11-16 09:51:48 <fancsali[m]> Is there a way to make abuild fetch a given tag with submodules - or do I have to hack the `APKBUILD` to download those other tarballs too?
2023-11-16 09:52:43 <PureTryOut> fancsali: this is an IRC-first channel so you should try to refrain from using non-IRC features like multiline messages.
2023-11-16 09:53:20 <PureTryOut> And you'll have to "hack" the APKBUILD. Normally I just add a snapshot which git clones the whole project recursively and makes a tarball out of that for the APKBUILD to use
2023-11-16 09:53:35 <fancsali[m]> Ooops; I made that mistake again. Sorry.
2023-11-16 09:53:48 <PureTryOut> Or if it's only like 1 or 2 submodules I add those to $sources directly and move them to the right places in prepare()
2023-11-16 09:54:18 <PureTryOut> Preferably you ask upstream to include those submodules in their release tarballs for the future
2023-11-16 09:54:26 <fancsali[m]> Wow. Thanks. I'll look into those options.
2023-11-16 09:54:37 <fancsali[m]> Yes, definitely. I'll raise that with them!
2023-11-16 13:14:07 <ysionneau> yeay I have a package for lua-aports now, I have buildrepo :)
2023-11-16 13:14:17 <ysionneau> it's not clear to me how to use it though...
2023-11-16 14:11:25 <omni> ikke: No space left on device on arm builders
2023-11-16 14:23:14 <ikke> chromium (and all its variants)
2023-11-16 14:31:16 <ikke> Freed some space again
2023-11-16 14:44:42 <omni> <3
2023-11-16 16:15:41 <ikke> restarting gitlab for upgrades
2023-11-16 16:19:34 <ikke> Done :)
2023-11-16 16:41:56 <ysionneau> is there some example somewhere (like a builder script?) of buildrepo usage?
2023-11-16 16:43:34 <ysionneau> The only documentation I found was the --help and https://wiki.alpinelinux.org/wiki/Include:Buildrepo
2023-11-16 16:43:39 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/aports-build/aports-build
2023-11-16 16:44:46 <ysionneau> thanks
2023-11-17 11:50:39 <omni> I'm looking at mbuffer that failed for arm* after I enabled them
2023-11-17 11:51:12 <omni> I'm thinking of patching the Makefile.in to create a smaller test.tar file
2023-11-17 11:51:16 <omni> for arm*
2023-11-17 12:54:36 <omni> deno failed on x86_64, not sure if that was just a glitc and could be retriggered
2023-11-17 12:55:52 <omni> and then there's !55217 that I feel should get in as it's a security upgrade
2023-11-17 12:55:59 <omni> elly: ^^
2023-11-17 12:57:26 <omni> unfortunately !55098 seem to fail to build on the x86_64 CI builder
2023-11-17 12:57:56 <omni> I just pushed retry on that one and we'll see if anything has changed
2023-11-17 14:39:55 <vkrishn> could someone change url in community/stfl to https://clifford.at/stfl
2023-11-17 14:42:01 <Habbie> vkrishn, if you happen to be in contact with the author, please let them know the screenshots on that page are 404
2023-11-17 14:42:21 <Habbie> also some of the SVN links are broken
2023-11-17 14:42:45 <Habbie> in fact, all of them
2023-11-17 14:45:10 <vkrishn> Habbie: https://d.insteps.net/scr/ can access webpage, let me check svn
2023-11-17 14:45:40 <Habbie> yes, i see this too, but the small screenshots link to 404s
2023-11-17 14:46:04 <Habbie> as for changing the url in the APKBUILD, you can send a Merge Request in gitlab
2023-11-17 14:49:28 <vkrishn> svn is broken, but download link has correct checksum file, thanks
2023-11-17 14:54:41 <Habbie> ah good
2023-11-17 15:01:35 <lnl> omni: actually something more was backported to M119 stable, I'll look into it
2023-11-17 15:02:31 <lnl> "[$10000][1497997] High CVE-2023-5997: Use after free in Garbage Collection."
2023-11-17 15:02:36 <lnl> skull emoji
2023-11-17 18:57:22 <omni> ow
2023-11-18 02:57:26 <celie> omni: Hi, i think you've brought up the MIT license issue a few times, so maybe you can have a look at whether it's alright to remove it in !55595
2023-11-18 03:00:02 <celie> s/remove it/remove the LICENSE file/
2023-11-18 03:39:26 <boomanaiden154> Probably not compliant with the license to remove it.
2023-11-18 03:39:51 <boomanaiden154> There are probably a lot of Alpine packages that don't comply with attribution clauses though, but if one already is, doesn't make sense to remove it.
2023-11-18 03:42:40 <omni> I'll comment and reference the recently updated wiki page
2023-11-18 03:44:02 <omni> we can only improve the situation
2023-11-18 03:45:07 <omni> I have a related question though, does the license file have to be in a -doc subpackage?
2023-11-18 03:45:51 <omni> if you don't have any documentation to package, can the license be in the main package?
2023-11-18 03:57:17 <omni> how do I set target project for my mkinitfs fork?
2023-11-18 03:58:07 <boomanaiden154> I think the license has to be in the main package in order to be compliant?
2023-11-18 03:59:17 <boomanaiden154> The binaries included in the main package and would thus constitute a copy/substantial portion of the software.
2023-11-18 03:59:24 <boomanaiden154> Obligatory I am not a lawyer.
2023-11-18 04:01:05 <omni> me neither, I would love not to have to think about copyright
2023-11-18 04:01:59 <boomanaiden154> Yeah, it's kind of a pain.
2023-11-18 04:02:20 <boomanaiden154> I've been working a little bit on at least cleaning up the SPDX license expressions since there ~500 broken in aports right now.
2023-11-18 04:02:47 <boomanaiden154> Still have like 10 MRs open from the last batch that I did.
2023-11-18 04:04:46 <omni> and I'm not confident enough to touch them
2023-11-18 04:04:53 <omni> they're probably alright though
2023-11-18 04:05:17 <boomanaiden154> I think I've found a couple that are just completely wrong.
2023-11-18 04:05:45 <boomanaiden154> Most of them aren't too bad though. Like it will just be 'GPL' (which isn't a valid SPDX license id) and actually be `GPL-2.0-or-later` or something like that.
2023-11-18 04:06:02 <boomanaiden154> Even just doing anything to them will make them a bit better.
2023-11-18 04:06:46 <boomanaiden154> I'm slowly working on building up infrastructure for other projects to parse/validate SPDX expressions. Might try and add that to the Alpine precommit CI to validate SPDX expressions if people are interested.
2023-11-18 07:05:06 <ikke> boomanaiden154: there already is a check for the license field in ci, but it's just a warning 
2023-11-18 07:05:31 <ikke> You'd have to check the build log to see it
2023-11-18 08:01:31 <boomanaiden154> ikke: What does it check exactly? That the license field is a SPDX compliant expression?
2023-11-18 08:03:21 <ikke> It's a bit crude, but the check is here: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in?ref_type=heads#L1035
2023-11-18 08:04:07 <ikke> so more that it has valid tokens rather than the expression is valid
2023-11-18 08:04:46 <boomanaiden154> Ah, so it is there. That's somewhat similar to what I've been doing.
2023-11-18 08:05:12 <boomanaiden154> That should probably be somewhere like the lint job where it will actually show up as a failure/warning.
2023-11-18 09:34:13 <Kladky> Is there a lower limit for how long a package has to be in testing before it can be moved to community?
2023-11-18 09:44:50 <ikke> no
2023-11-18 12:18:26 <omni> why don't I have the option to set Target project on my mkinitfs fork? under Settings -> Merge requests
2023-11-18 12:21:13 <omni> maybe I did something wrong when I created it?
2023-11-18 12:23:32 <ikke> hmm intersting, not sure why. It is marked as a fork
2023-11-18 12:40:05 <Kladky> Btw with the license distributing requirement, don't most licenses require this? It seems that alongside MIT, BSD-3 and Apache-2.0 reuqire it aswell.
2023-11-18 12:40:14 <Kladky> With *GPL it is less clear.
2023-11-18 12:41:46 <Kladky> Also since most software use one of the few popular licenses, it would be ideal to not have multiple copies of the same license on the disk.
2023-11-18 13:03:35 <omni> but you cannot do that with the MIT license, for example, since the copyright holder is mentioned in the file(s) and so they differ
2023-11-18 13:04:32 <omni> we have no issue with Signed-off-by in the commit message body, right? !55567
2023-11-18 13:08:03 <ikke> omni: no, no problem having it, but it's meaningless :P
2023-11-18 13:08:25 <ikke> Like signing a blank page :D
2023-11-18 13:26:42 <omni> 👍
2023-11-18 13:26:54 <omni> I'm re-creating my mkinitfs fork
2023-11-18 13:29:55 <omni> there we go
2023-11-18 13:34:32 <omni> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/136
2023-11-18 15:31:07 <minimal> omni: what differently/extra is your mkinitfs doing? and is the intention for the changes to be submitted to the mkinitfs package?
2023-11-18 20:23:26 <ikke> armhf / armv7 3.19 just finished :)
2023-11-18 21:14:01 <tomleb> Hey folks, I maintain the navidrome package. With the new release, navidrome has a config for configuring the cache dir. The default stayed unchanged (/var/lib/navidrome/cache). Now that it's configurable, should I let it as default, or should I configure it in /etc/conf.d/navidrome to /var/cache/navidrome?
2023-11-18 21:40:28 <ikke> tomleb: if it's cache, wouldn't /var/cache/navidrome be more logical?
2023-11-18 21:47:49 <tomleb> ikke: It is and that's why I added that feature to navidrome upstream, but the current behavior is  cache is in /var/lib/navidrome/cache. Users will still have some cache files in /var/lib/navidrome/cache until they manually clean it up.
2023-11-18 21:49:17 <ikke> tomleb: oh sorry, you're right. I misread what you proposed 
2023-11-19 01:41:53 <omni> minimal I've tested it back-and-forth between zfs 2.2.0 and 2.1.13 and it works
2023-11-19 01:43:39 <omni> I hope for the changes to be sumbitted to the mkinitifs package because they are needed for the zfs upgrade to 2.2.0, but also allow for previous versions of zfs
2023-11-19 03:39:28 <quinq> omni, but what is the patch actually supposed to do?
2023-11-19 03:40:59 <quinq> extra/spl and extra/zfs will pack extra/spl.ko.gz and extra/zfs.ko.gz, which already works
2023-11-19 06:53:30 <celie> x86_64 3.19 just finished uploading, and i think aarch64 has only 1 blocker left :)
2023-11-19 07:58:42 <ikke> good news
2023-11-19 08:02:42 <ikke> opencv fails to link on ppc64le
2023-11-19 09:04:33 <omni> quinq: for me extra/spl and extra/zfs didn't, but extra/spl* and extra/zfs* did
2023-11-19 09:04:44 <omni> I tried and found out
2023-11-19 09:23:39 <quinq> I've been using the default config (and I'm pretty sure I'm not the only one) for months without issue
2023-11-19 09:25:33 <quinq> Maybe provide a log of mkinitfs command, and/or the output of mkinitfs -l
2023-11-19 09:26:13 <omni> have you run zfs 2.2.0 for months?
2023-11-19 09:26:42 <quinq> No, but the mkinitfs file list regarding zfs
2023-11-19 09:27:32 <quinq> The link in the commit you shared shows that there's actually no change in the produced modules, only zfs.ko and spl.ko
2023-11-19 09:28:05 <quinq> So no change in that regard for 2.2 compared to 2.1, is there?
2023-11-19 09:30:42 <omni> did you follow and read the referenced !53430 ?
2023-11-19 09:31:52 <quinq> I read the linked commit, that confirms what your commit message says
2023-11-19 09:31:53 <omni> I just rebased so that you'll have build artifacts to download and try with for yourself in a bit, if you want
2023-11-19 09:32:07 <quinq> “ZFS has merged all but the spl kernel module into the zfs module” and “linux: module: weld all but spl.ko into zfs.ko”
2023-11-19 09:32:33 <quinq> I don't need to *try*, but just for you to explain why the change in there hasn't been any change? :)
2023-11-19 09:32:40 <quinq> s/?$//
2023-11-19 09:35:26 <omni> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/53430#note_355048
2023-11-19 09:35:32 <omni> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1184007#L1703
2023-11-19 09:35:39 <omni> that has changed
2023-11-19 09:35:46 <omni> how clear can I be?
2023-11-19 09:36:25 <omni> the location of the modules has changed
2023-11-19 09:37:40 <quinq> Ahhh…
2023-11-19 09:38:00 <quinq> Well, you can be cleared by actually telling that in the commit message, instead of the opposite :)
2023-11-19 09:38:52 <quinq> So the actual problem is 2.2.0, which has been fixed and will most likely be distributed in 2.2.1
2023-11-19 09:41:35 <quinq> Or maybe I'm reading this the opposite, sorry if that's the case
2023-11-19 09:41:51 <omni> the commit message https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/136/diffs?commit_id=bd38f0777f97224ceecf519dd0620d2f8a3839f2 mentions the new module locations as explanation
2023-11-19 09:44:21 <quinq> ok, I got it now, my bad.
2023-11-19 09:44:32 <quinq> Sorry for the time lost
2023-11-19 09:45:11 <omni> :*
2023-11-19 09:45:20 <omni> it's ok
2023-11-19 09:46:08 <quinq> I really thought that zfs 1.3 was distributing zfs and spl modules, then they split it in 2.2.0, but decided to revert that for 2.2.1.
2023-11-19 09:46:30 <quinq> Looks good then :)
2023-11-19 09:50:33 <omni> I have seen no 2.2.1 yet
2023-11-19 09:50:57 <omni> https://github.com/openzfs/zfs/commit/ad9e767657c3d3c0ec9e09a17f6732bcbf915401 is in 2.2.0 but not mentioned in https://github.com/openzfs/zfs/releases/tag/zfs-2.2.0 release notes
2023-11-19 10:25:00 <WhyNotHugo> Cogitri: What's the deal with glibmm (currently 2.66.6)  and glibmm2.68 (currently 2.76)? I want to upgrade telegram-desktop, which needs 2.78.
2023-11-19 10:30:35 <WhyNotHugo> But I think the versions of the packages are mixed up. Maybe we don't need both any more?
2023-11-19 10:32:36 <ikke> Cogitri is not really active atm
2023-11-19 11:24:18 <ptrc> WhyNotHugo: the package names match the sonames
2023-11-19 11:24:39 <ptrc> because apparently that's how some projects do breaking changes
2023-11-19 11:26:22 <ptrc> all the *mm projects do the same btw
2023-11-19 11:26:43 <ptrc> so there's also pangomm(2.48), atkmm(2.36), cairomm(1.16)
2023-11-19 12:36:15 <WhyNotHugo> glibmm-2.66.6-r0 contains libglibmm-2.4.so.1.3.0
2023-11-19 12:49:15 <WhyNotHugo> glibmm2.68 contains libglibmm-2.68.so.1.3.0
2023-11-19 12:51:47 <WhyNotHugo> So package glibmm tracks an older version and glibmm2.68 tracks recent versions. o.O
2023-11-19 12:53:36 <WhyNotHugo> Can we have packages glibmm2.4 and glibmm2.68 instead? (kinda like gtk3 and gtk4)
2023-11-19 12:56:51 <AntoniAloyTorrens[m]1> Hello all, I'd like to move some of my maintained packages (most of them are games) to community. Are games accepted in community? Last time I tried to move one ( !48400 ), and even though it was merged, there was a little bit of discussion.
2023-11-19 12:56:51 <AntoniAloyTorrens[m]1> Also, are SDL1 games accepted in community?
2023-11-19 12:57:17 <sam_> you shouldn't really need SDL1 proper
2023-11-19 12:57:20 <sam_> just use sdl12-compat
2023-11-19 12:57:27 <sam_> (dunno if alpine has that packaged though)
2023-11-19 12:57:41 <AntoniAloyTorrens[m]1> Sure, they do, and they make use of it
2023-11-19 12:58:27 <AntoniAloyTorrens[m]1> They build and run successfully, but upstream does not maintain them anymore for a long time
2023-11-19 13:02:20 <ikke> AntoniAloyTorrens[m]1: We've made the decission that testing is not a long-term destination for packages, so things either have to be moved to community or removed all together
2023-11-19 13:04:38 <AntoniAloyTorrens[m]1> Oh, I see. If that's the case I'll move what I use, thanks ikke
2023-11-19 13:05:36 <ikke> My only concern would be if they are large
2023-11-19 13:10:51 <ptrc> 
ACTION grumbles about xonotic-data taking up 1.1G in community

2023-11-19 13:12:29 <AntoniAloyTorrens[m]1> No, they aren't. Most of them are only a couple of MB
2023-11-19 13:12:29 <AntoniAloyTorrens[m]1> The only exception is `trigger-rally`, which their data files are 350MB. If that's too large and can be a problem, I can just make a downloader script like it's done in flightgear: https://git.alpinelinux.org/aports/plain/testing/flightgear/flightgear-data-downloader.sh
2023-11-19 13:15:31 <ikke> ptrc: exactly
2023-11-19 13:27:38 <WhyNotHugo> Given that the maintainer is not active, can somebody else look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/55692 ?
2023-11-19 13:52:56 <ptrc> merged :p
2023-11-19 13:58:42 <WhyNotHugo> Thanks!
2023-11-19 14:52:06 <ikke> Seems like 3.19 is finished 🥳🥳🥳
2023-11-19 14:52:09 <ikke> Thanks all for helping
2023-11-19 15:02:16 <invoked> congrats
2023-11-19 15:03:08 <dari> https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.19.0 looks short, no drastic changes? :)
2023-11-19 15:03:44 <invoked> i dunno if the 6 month cadence is intentional, but lgtm
2023-11-19 15:30:57 <ikke> invoked: yes release is every 6 months. But 3.19 is not released yet 
2023-11-19 15:32:08 <ikke> dari: new lts kernel is still in the line 
2023-11-19 15:46:35 <ikke> Please hold off any pushes, I'll be pushing rc1 soon
2023-11-19 16:10:32 <dari> ikke: I'm already using linux-edge 6.6 with stable :)
2023-11-19 16:55:02 <ikke> v3.19.0_rc1 has been tagged :-)
2023-11-19 17:36:18 <liske> \o/
2023-11-19 18:54:12 <andypost[m]> 👍
2023-11-19 19:17:13 <ikke> anyone up for patching openssl on 3.15-3.17? https://security.alpinelinux.org/vuln/CVE-2023-5678
2023-11-19 19:17:22 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/15482
2023-11-19 19:29:22 <nmeum> ikke: does security.alpinelinux.org automatically pick-up cves fixed in releases? I noticed that you didn't update secfixes for the go 3.18 upgrade
2023-11-19 19:32:47 <nmeum> also: both cves primarly affect windows, right?
2023-11-19 19:32:53 <nmeum> https://groups.google.com/g/golang-announce/c/4tU8LZfBFkY
2023-11-19 19:43:47 <ikke> nmeum: if the cpe indicates that go-1.20.11 is fixed, it should
2023-11-19 19:43:54 <nmeum> ah, good to know!
2023-11-19 19:44:21 <ikke> and to be honest, I didn't find any CVE reference in the release notes / references issues for go 1.20.11
2023-11-19 19:45:27 <nmeum> yea, for some reason the cve are only(?) referenced on the announcement mailinglist and in the bug tracker
2023-11-19 19:46:36 <nmeum> i don't think i will rebuild edge though
2023-11-19 19:47:01 <ikke> right
2023-11-19 22:51:17 <andypost[m]> Is there schedule for next RC? It looks reasonable to move php83 to community as GA at next week 
2023-11-19 23:19:00 <pj> why is CI for !52887 so wrong
2023-11-19 23:19:17 <pj> I'm building rust 1.74 just fine on Alpine x86_64
2023-11-19 23:21:02 <Arnavion> Are you building it with 1.70.0 ? Because that's what you told CI to build it with
2023-11-19 23:30:37 <pj> I have never seen an answer so wrong, yet accidentally right
2023-11-20 02:59:35 <celie> omni: The commit title of !55719 is not the only thing that needs to be changed, the MR is also a move to community (haven't checked if anything in main/ depends upon it), and the move typos the directory name ("p3" instead of "py3")
2023-11-20 03:12:21 <celie> main/py3-sphinx depends on py3-pygments
2023-11-20 03:37:15 <pj> gtk-doc too
2023-11-20 04:36:41 <strophy> Hi, I'm trying to update the testing/bazel6 package and running into an error in CI that I cannot reproduce in local chroot or on an AWS EC2 Alpine host, can anyone help me debug this? Is there a way I can reproduce what the CI environment is trying to do locally? https://gitlab.alpinelinux.org/strophy/aports/-/jobs/1185014#L255
2023-11-20 04:41:42 <quinq> Hi strophy, did you forget to '#include <cstdint>'?
2023-11-20 04:47:49 <lnl> strophy: are you maybe mixing 3.18 and testing on your machines?
2023-11-20 04:48:52 <skarnet> Good morning! when devs get here, please merge !55749 at your convenience. (It's just abumps.) Thanks!
2023-11-20 06:03:41 <strophy> @quinq I'm downloading the same tarball for all builds, so I don't think there is a problem in the code I am trying to build.
2023-11-20 06:04:21 <strophy> @lnl yes, there's a good chance that is what's going on here. I tried using https://github.com/sgerrand/docker-alpine-abuild first, and then also using a chroot environment, as well as on EC2 instances booted with an Alpine AMI. I think my main struggle is setting up a build environment here.
2023-11-20 06:11:53 <ikke> your build environment should be kept clean (in the sense of installed packages)
2023-11-20 06:13:13 <ikke> strophy: CI builds use alpinelinux/build-base
2023-11-20 06:13:46 <ikke> If you use that image, run abuild-keygen -ain, clone the repo and build  the package, it should be as close as CI as possible
2023-11-20 06:14:29 <ikke> Oh, and apk upgrade -Ua before as well
2023-11-20 06:21:12 <strophy> Thanks, I'll give that a try
2023-11-20 06:24:45 <ikke> strophy: fyi, we had to patch several projects to include <cstdint>
2023-11-20 06:58:45 <strophy> I think I'm doing something wrong with this container. I ran `docker run -it --rm alpinelinux/build-base` and then inside the container:
2023-11-20 06:58:46 <strophy> git clone https://gitlab.alpinelinux.org/strophy/aports.git
2023-11-20 06:58:46 <strophy> cd /home/buildozer
2023-11-20 06:58:46 <strophy> abuild-keygen -ain
2023-11-20 06:58:46 <strophy> apk upgrade -Ua
2023-11-20 06:58:47 <strophy> git checkout bazel6-6.3.1
2023-11-20 06:58:49 <strophy> cd aports/testing/bazel6/
2023-11-20 06:58:51 <strophy> abuild -r
2023-11-20 06:59:00 <strophy> This resulted in this error:
2023-11-20 06:59:02 <strophy> >>> bazel6: Building testing/bazel6 6.3.1-r0 (using abuild 3.12.0-r0) started Mon, 20 Nov 2023 06:54:31 +0000
2023-11-20 06:59:03 <strophy> >>> bazel6: Checking sanity of /home/buildozer/aports/testing/bazel6/APKBUILD...
2023-11-20 06:59:03 <strophy> ERROR: unable to select packages:
2023-11-20 06:59:03 <strophy> >>> bazel6: Analyzing dependencies...
2023-11-20 06:59:04 <strophy>   .makedepends-bazel6-20231120.065431:
2023-11-20 06:59:06 <strophy>     masked in: cache
2023-11-20 06:59:08 <strophy>     satisfies: world[.makedepends-bazel6=20231120.065431]
2023-11-20 06:59:12 <strophy>   openjdk11-jdk (no such package):
2023-11-20 06:59:14 <strophy>     required by: .makedepends-bazel6-20231120.065431[openjdk11-jdk]
2023-11-20 06:59:16 <strophy> >>> ERROR: bazel6: builddeps failed
2023-11-20 06:59:18 <strophy> >>> bazel6: Uninstalling dependencies...
2023-11-20 06:59:20 <strophy> ERROR: No such package: .makedepends-bazel6
2023-11-20 07:04:10 <ikke> strophy: oh, you have to add the community and testing repos 
2023-11-20 07:04:30 <ikke> doas vi /etc/apk/repositories 
2023-11-20 07:18:32 <strophy> Thanks, that got me further! It now fails with a different error to what I get in CI. Interestingly, it also fails when I try to build the same package with v6.1.0 without changes from master branch. How was I able to get 6.1.0 building and merged in the first place? At that time I just used the sgerrand docker image...
2023-11-20 07:18:50 <strophy> In file included from ./src/tools/singlejar/output_jar.h:28,
2023-11-20 07:18:50 <strophy>    38 | static_assert(sizeof(off64_t) == 8, "File offset type must be 64-bit");
2023-11-20 07:18:50 <strophy>                  from src/tools/singlejar/singlejar_main.cc:18:
2023-11-20 07:18:50 <strophy>       |                      ^~~~~~~
2023-11-20 07:18:50 <strophy> ./src/tools/singlejar/port.h:38:22: error: 'off64_t' was not declared in this scope; did you mean 'off_t'?
2023-11-20 07:18:51 <strophy>       |                      off_t
2023-11-20 07:19:59 <quinq> Have a nice patch :)
2023-11-20 07:23:46 <strophy> Is there some standard/easy way to have a local build environment and mount keys and the aports repo into it? At this point I just want to be able to reproduce my original build that created this package: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/bazel6
2023-11-20 07:24:34 <strophy> I don't see why it was built, accepted and merged before, and now won't build at all. Plus waiting 12 minutes to clone the aports repo each fresh attempt is getting painful lol
2023-11-20 12:16:04 <raspbeguy> hello, I'm struggling to build a packages that involves nodejs
2023-11-20 12:18:09 <raspbeguy> Not a huge fan of nodejs and I don't even know exactly what I'm doing. There is a building step where I have to use pnmp (which seems to be like a npm wrapper, maybe?) and the command is: pnpm i --frozen-lockfile
2023-11-20 12:18:31 <raspbeguy> it fails with error: Internal Error: EROFS: read-only file system, unlink '/usr/bin/pnpm'
2023-11-20 12:18:56 <raspbeguy> I'm building using abuild rootbld
2023-11-20 12:26:59 <ikke> Why does it want to unlink something in /usr/bin 🤨
2023-11-20 12:30:46 <raspbeguy> dunno
2023-11-20 12:41:24 <raspbeguy> here is my apkbuild so far https://termbin.com/p6vny
2023-11-20 13:44:21 <omni> celie: you're right, it was just the first thing I saw and I think I closed the lid soon after
2023-11-20 15:07:03 <bl4ckb0ne> could I have another set of eyes on !55177 pls 
2023-11-20 15:33:03 <lnl> raspbeguy: they use corepack so the node.js might be trying to download pnpm from npmjs
2023-11-20 15:33:19 <lnl> try removing this line https://github.com/usememos/memos/blob/main/web/package.json#L11
2023-11-20 16:14:40 <raspbeguy> Actually I just figured out that core pack was useless because pnpm is already packaged in Alpine. So I did and now it works great.
2023-11-20 16:15:40 <raspbeguy> !55791
2023-11-20 22:10:25 <omni> I haven't really looked into why !55534 fail on aarch64 and armv7, anyone is welcome to have a look
2023-11-21 09:37:24 <donoban> omni: it seems same error "/builds/alpine/aports/main/xen/src/xen-4.18.0/tools/qemu-xen/include/hw/xen/xen_native.h:5:2: error: #error In Xen native files, include xen_native.h before other Xen headers"
2023-11-21 10:35:57 <donoban> if you or someone with access could retry the CI, downloading the artifacts maybe we could discover the difference in the include chain between a working build and the failed
2023-11-21 10:51:30 <omni> donoban: retriggered with a rebase
2023-11-21 11:23:40 <donoban> ok
2023-11-21 12:58:57 <omni> stupid OOM killer
2023-11-21 13:03:44 <donoban> wops, I thought that the build dir will be included in the artifacts
2023-11-21 13:06:58 <omni> oh, yeah
2023-11-21 13:07:29 <omni> donoban: maybe you could fork the MR and adjust it so that it does
2023-11-21 14:17:46 <donoban> hmm.. I suppose that it needs to add something on .gitlab-ci.yml , ikke ?
2023-11-21 14:22:10 <ikke> How large is that dir?
2023-11-21 14:22:30 <donoban> uhM, let me try to build locally
2023-11-21 14:37:31 <donoban> uhM, the full build dir is 2.4Gb
2023-11-21 14:38:14 <donoban> but probably on need a small subset
2023-11-21 14:38:22 <donoban> s/on/only
2023-11-21 14:39:24 <donoban> tools/qemu-xen -> 1775M
2023-11-21 14:39:27 <donoban> tools/qemu-xen -> 177.5M
2023-11-21 14:48:52 <ikke> You could copy that sub dir to $CI_PROJECT_DIR/packages
2023-11-21 14:50:00 <donoban> ok thanks, I will try after confirm that interesting code is there
2023-11-21 14:50:43 <donoban> maybe only need a few files
2023-11-21 14:50:52 <donoban> ok, great
2023-11-21 17:09:51 <bl4ckb0ne> thoughts on removing wlroots0.15 and wlroots0.12 from the repo?
2023-11-21 17:10:14 <bl4ckb0ne> they are used by hikari and hopalong respectively, which have not received any change since january and august
2023-11-21 18:53:56 <omni> !55581 is locked
2023-11-21 19:24:54 <ikke> omni: because it's a draft?
2023-11-21 19:35:16 <ikke> The branch is not protected 
2023-11-21 23:28:24 <PabloCorreaGomez[m]> Not sure if it's super relevant, but I just got musl CI for glib merged upstream, that I plan to maintain
2023-11-21 23:28:43 <PabloCorreaGomez[m]> So hopefully will mean a bit less breakage and easier updates for it in main
2023-11-21 23:37:59 <PabloCorreaGomez[m]> Also, in postmarketOS we thought about adding a check for alphabetic order in dependencies
2023-11-21 23:38:21 <PabloCorreaGomez[m]> Would that be of any interest in alpine? Like would a patch to atools for that be welcomed?
2023-11-22 08:58:57 <PureTryOut> Oh Musl CI is always good, well done!
2023-11-22 09:46:10 <omni> ikke: no, I cannot rebase it
2023-11-22 09:48:28 <ikke> omni: curious to why then
2023-11-22 09:48:53 <ikke> omni: what does it say?
2023-11-22 09:54:47 <omni> ikke: "Something went wrong. Please try again."
2023-11-22 09:55:33 <ikke> Ah ok, so it lets you rebase but it fails
2023-11-22 11:55:37 <omni> maybe that's it, we just assumed that it was locked
2023-11-22 14:26:48 <ajhalili2006> If I want to also be a package co-maintainer in some other package I use (in my case, I plan to also maintain community/tailscale, probably some time after alpine/aports!55922), do I need approval from existing package maintainer(s) or from TSC?
2023-11-22 14:28:23 <bl4ckb0ne> is the maintainer still around? if not you can ask to get the maintainership of the package
2023-11-22 14:28:44 <bl4ckb0ne> otherwise you dont need any "co maintainer" status to send package updates
2023-11-22 14:49:52 <bl4ckb0ne> does alpine have any kind of metrics regarding package download?
2023-11-22 14:55:59 <pj> nope
2023-11-22 14:58:58 <omni> it would be very hard to have such metrics, not least with all the mirrors
2023-11-22 15:12:55 <ikke> And we won't be adding any telemetry 
2023-11-22 15:43:01 <smcavoy88> Can someone take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/55400 ? (ansilbe)
2023-11-22 15:52:02 <bl4ckb0ne> ikke: perfect
2023-11-22 16:15:44 <ayakael0> Heya! Happy to share that the MR for dotnet8 is now ready for review: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49831
2023-11-22 17:18:51 <RootWyrm> ayakael0: how exactly is RLIMIT_NOFILE breaking on musl? I can probably look into that at some point.
2023-11-22 18:23:08 <Forza> Good evening :)
2023-11-22 18:25:13 <Forza> I am making a small package with only an init script. This is the apkbuild https://bpa.st/GLNQ
2023-11-22 18:26:10 <Forza> Questions: arch= should it be 'all' ? Its arch independent by nature.
2023-11-22 18:26:45 <Forza> Abuild also has a warning about openrc https://bpa.st/5QPQ
2023-11-22 18:27:27 <Forza> Should i name the package dm-cache-openrc instead? 
2023-11-22 18:28:26 <ikke> Forza: arch should indeed be 'all
2023-11-22 18:29:42 <Forza> :)
2023-11-22 18:29:57 <ikke> sorry
2023-11-22 18:30:01 <ikke> noarch
2023-11-22 18:31:26 <Forza> Ah ok
2023-11-22 18:31:41 <Forza> This warning is left: Found OpenRC directory (/etc/conf.d or /etc/init.d) but name doesn't end with -openrc 
2023-11-22 18:32:48 <omni> yes
2023-11-22 18:33:16 <omni> I was just thinking if this shouldn't perhaps be part of main/lvm2
2023-11-22 18:33:29 <Forza> Yes as in rename the package? Or should I make a subpackage? 
2023-11-22 18:34:22 <Forza> That would work too, if you prefer it as a part of lvm
2023-11-22 18:34:31 <omni> where is the script itself?
2023-11-22 18:35:17 <omni> I just thought that it was for lvm2 it was relevant
2023-11-22 18:35:28 <Forza> https://bpa.st/UNIQ
2023-11-22 18:35:41 <ikke> does not make sense to make it a sbupackage
2023-11-22 18:35:49 <Forza> It's not dependent on lvm2, only on device-mapper 
2023-11-22 18:36:40 <Forza> it uses dmsetup to setup devices instead of using LVM tools 
2023-11-22 18:36:50 <omni> ikke: ok
2023-11-22 18:37:18 <ikke> I meant an empty package with this as subpackage
2023-11-22 18:37:35 <Forza> I should maybe make a proper repo somewhere with the sources. Haven't gotten around to it
2023-11-22 18:38:17 <Forza> ikke: yea that seems redundant. Should I just name it -openrc, as it does not work without openrc? 
2023-11-22 18:38:49 <omni> probably best to start out as a separate package in testing, not least  to get it in sooner
2023-11-22 18:39:08 <ikke> thinks it makes sense
2023-11-22 18:39:20 <ikke> similar to busybox-openrc
2023-11-22 18:39:33 <ikke> although, that is a subpackage
2023-11-22 18:39:34 <Forza> Ok so I should rename it? 
2023-11-22 18:41:25 <omni> maybe it should be called device-mapper-cache-openrc, even though it's long, since the device-mapper specific lvm2 subpackages are called device-mapper-something
2023-11-22 18:43:25 <Forza> That's OK with me too
2023-11-22 18:44:05 <Forza> Though, the script is not made by the device-mapper/lvm2 folks 
2023-11-22 18:46:16 <Forza> I'm really ok with any choice that is suitable for Alpine 
2023-11-22 18:48:08 <omni> not sure they provide any init scripts, we have several right in our repo as main/lvm2/*.initd
2023-11-22 19:11:26 <Forza> I think it should be tested by a few people first. I run this script on my Gentoo box with no big issues. 
2023-11-22 19:13:01 <Forza> There is one thing I'd like to add, but am not sure how. I'd want to remove the filesystem uuid symlink in /dev/disk/by-uuid/ because it conflicts when the origin device's filesystem is used through device mapper 
2023-11-22 19:13:48 <Forza> On Gentoo I use a udev rule to remove the link to the origin device, but with mdev I don't know how to do the same 
2023-11-22 19:15:58 <Forza> Udev rule https://bpa.st/MXGA 
2023-11-22 19:21:46 <skarnet> Forza: you can do basically the same. $ID_FS_UUID_ENC=your-device-uuid;$SUBSYSTEM=block root:root 660 @rm -f /dev/disk/by-uuid/your-device-uuid
2023-11-22 19:22:58 <skarnet> that should work with mdev, to the best of my understanding of the syntax
2023-11-22 19:23:06 <skarnet> if it doesn't, switch to mdevd and it will :P
2023-11-22 19:24:04 <Forza> Ah great. I'll try this. 
2023-11-22 19:24:50 <Forza> Does mdev have an include dir, or is it just mdev.conf? 
2023-11-22 19:24:59 <skarnet> it's just mdev.conf
2023-11-22 19:25:53 <skarnet> I've been saying for a while that distros should have a preprocessor to support /etc/mdev.conf.d, but this doesn't seem to motivate people
2023-11-22 19:27:52 <Forza> I'll make some tests and add a comment in conf.d file so users get the choice 
2023-11-22 19:28:53 <skarnet> :thumbsup:
2023-11-22 19:31:13 <Forza> Udev doesn't exist on Alpine, does it? 
2023-11-22 19:31:47 <skarnet> it does
2023-11-22 19:32:02 <skarnet> you can choose between 3 service managers
2023-11-22 19:32:15 <skarnet> /sbin/setup-dev
2023-11-22 19:32:31 <skarnet> not service managers, device managers XD
2023-11-22 19:33:18 <skarnet> unfortunately udev is kinda necessary if you want a desktop :"/
2023-11-22 19:34:01 <Forza> Ah I searched wrong. https://pkgs.alpinelinux.org/package/edge/main/x86_64/eudev 
2023-11-22 19:34:25 <Forza> It would be good if things worked with all three options 
2023-11-22 19:34:55 <skarnet> the lack of modularity for /etc/mdev.conf is really the only thing preventing it
2023-11-22 19:36:05 <skarnet> well post-install and post-deinstall *could* modify /etc/mdev.conf but I think there's no precedent in Alpine and something tells me that's against policy
2023-11-22 19:36:10 <skarnet> especially since it's a file in /etc
2023-11-22 19:36:45 <Forza> It's risky too. Could easily mess up a system 
2023-11-22 19:36:52 <skarnet> well yes there's precedent with /etc/passwd and /etc/group but that's a bit different
2023-11-22 19:37:39 <skarnet> it's risky to get right, but not more dangerous than any other system modification by a package manager
2023-11-22 19:38:05 <skarnet> but really having modularity via a /etc/mdev.conf.d/* preprocessor would make things a lot easier
2023-11-22 19:39:22 <Forza> Could it be a simple "include /etc/mdev.conf.d/*.conf"?
2023-11-22 19:39:29 <Forza> What is preventing this? 
2023-11-22 19:40:46 <skarnet> resistance to change
2023-11-22 19:41:42 <skarnet> and no, it couldn't be a simple include, because the mdev.conf syntax has no include
2023-11-22 19:42:21 <skarnet> it would be *much* easier to add a 'cat /etc/mdev.conf.d/* > /etc/mdev.conf' hook in post-installs
2023-11-22 19:42:45 <skarnet> uh, in /etc/init.d/mdev[d] rather
2023-11-22 19:44:26 <skarnet> include syntax could conceivably be added for mdevd (though it would be more complexity than would be worth) but it just not an option for mdev, which parses mdev.conf for every event
2023-11-22 19:52:41 <MelanieMalik> rechangeance to sist
2023-11-22 19:59:57 <Ermine> skarnet: is this cat atomic?
2023-11-22 20:01:55 <MelanieMalik> from the looks of it, no; the input files could conceivably be changed (although that's kinda unfixable), and the output file is directly onto the desired name rather than a temp-suffix
2023-11-22 20:25:45 <skarnet> Ermine: it was a shortcut, the right way is obviously cat > tempfile && mv -f tempfile realfile
2023-11-22 20:27:57 <Ermine> Ah
2023-11-22 20:29:28 <Forza> There is atomic ioctl to read ranges of bytes though
2023-11-22 20:29:54 <Forza> But the filesystem needs to support it i think 
2023-11-22 20:30:26 <Ermine> rename(2) is atomic on any file system
2023-11-22 20:30:33 <Forza> Ah good
2023-11-22 20:30:49 <Forza> No i mean the first cat thing
2023-11-22 20:46:41 <Forza> I was thinking of clone range
2023-11-22 20:49:55 <sam_> copy_file_range
2023-11-22 20:56:16 <Forza> Hi sam_!
2023-11-22 20:56:23 <sam_> hi!
2023-11-22 20:57:47 <Forza> Running with the enemy too? ;) 
2023-11-22 20:59:15 <sam_> I'm everywhere ;)
2023-11-22 21:01:38 <Forza> It's good. :) 
2023-11-22 21:02:55 <Forza> Realised I made several mistakes in my script. I was using arrays, which isn't supported. Also I didn't have findmnt and blockdev dependencies added 
2023-11-22 21:55:46 <Newbyte> Any chance !52562 could be merged before 3.19? I had forgotten about it so it's been marked as a draft for months now.
2023-11-22 21:59:38 <ikke> merged
2023-11-22 22:28:54 <Newbyte> thanks!
2023-11-23 03:26:45 <celie> omni: Would it be possible to get !55760 merge? Thanks
2023-11-23 10:41:40 <kpcyrd> can somebody help here? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/54393#note_356521 the normal tests run fine with no extra dependencies, but it's possible to set TEST_ACCEPTANCE=true which requires extra tools, I don't know which one alpine wants
2023-11-23 11:57:41 <Forza> skarnet: unfortunately it didn't work wirh that mdev rule
2023-11-23 12:34:44 <omni> Forza: please open an MR in our gitlab and it will be easier for more of us to provide input
2023-11-23 12:42:09 <omni> celie: went fine
2023-11-23 12:49:24 <Forza> omni: i will.
2023-11-23 12:49:46 <Forza> Im thinking to make a new script in /lib/mdev/ that solves it
2023-11-23 13:49:32 <Forza> Ok did a MR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/55985
2023-11-23 14:00:17 <Forza> Added a comment explaining the mdev issue. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/55985#note_356644
2023-11-23 14:01:32 <Forza> I have a working udev rule too. Should i simply add it too, or should i use some check whether the user uses udev or mdev?
2023-11-23 14:42:21 <skarnet> Forza: add it unconditionally, so people can switch device managers after installing the package and it still works
2023-11-23 14:43:08 <Forza> I did that now. What if target dir /etc/udev/rules.d doesn't exist? 
2023-11-23 14:45:41 <skarnet> mkdir -p? doesn't every package that adds udev rules do the same?
2023-11-23 14:46:06 <ikke> install -d
2023-11-23 14:46:12 <skarnet> -D but yes
2023-11-23 14:46:18 <ikke> rite
2023-11-23 14:46:26 <Forza> Ah ok. Thanks 
2023-11-23 14:47:28 <Forza> Like this? 	install -d -Dm755 "$pkgname.mdev" "$pkgdir"/etc/udev/rules.d/90-dmcache-uuid.rules 
2023-11-23 14:47:37 <ikke> without the -d
2023-11-23 14:47:47 <ikke> and add a -t
2023-11-23 14:48:02 <ikke> oh no, -t is not necessary in this case
2023-11-23 14:51:21 <Forza> So just 	install -Dm644"$pkgname.mdev" "$pkgdir"/etc/udev/rules.d/90-dmcache-uuid.rules
2023-11-23 14:51:56 <skarnet> with correct whitespacing, that should work
2023-11-23 15:01:15 <Forza> I've updated the MR now. Sorry for being messy 
2023-11-23 15:06:30 <Forza> Question. Could I use the alpine gitlab to host this script and use it as src instead of including the files with the  apkbuild? 
2023-11-23 15:27:45 <ikke> What's the difference 😉
2023-11-23 15:33:28 <Forza> Not sure
2023-11-23 15:33:50 <Forza> The init script could be used on other distros like gentoo 
2023-11-23 15:34:28 <Forza> So just having a normal repo to source from might be good? 
2023-11-23 15:34:41 <Forza> Anyway not important right now
2023-11-23 15:34:41 <dari> default rules are in "/lib/udev/rules.d"
2023-11-23 15:35:19 <dari>  in /etc/ suposed to be user modificated files
2023-11-23 16:05:53 <Forza> dari: thanks. Fixed it 
2023-11-23 16:13:26 <Forza> But the udev rule needs editing by the user 
2023-11-23 16:17:35 <dari> I thought you wanna create package or something :P
2023-11-23 16:18:32 <Forza> Yes
2023-11-23 16:18:44 <Forza> I do. 
2023-11-23 16:19:11 <Forza> But part of the configuration is a udev/mdev rule 
2023-11-23 16:19:19 <ikke> Forza: the idea is that the default shibs in /lib, and when the user needs to customize it, they move it to /etc
2023-11-23 16:19:24 <ikke> or copy it
2023-11-23 16:20:02 <Forza> Does alpine use /etc/udev/rules.d? 
2023-11-23 19:26:29 <donoban> omni: trying to guess the problem with xen upgrade I noticed many "ninja: bad depfile: multiple outputs..." errors wich doesn't appear on a succesfull x86_64
2023-11-23 19:26:56 <donoban> I wonder if this wrong depfiles could lead to the import error on 'xen-all.c'
2023-11-23 19:45:44 <omni> donoban: thank you for looking at it! it could be something related to how we package xen that cause this
2023-11-23 19:47:48 <omni> ikke: are the chromium builds stuck on x86_64?
2023-11-23 19:48:18 <donoban> do you know if we could force it to output the depencies? maybe somethig like "-MF -" but I'm not sure if it will continue build or just outputs the deps
2023-11-23 19:50:10 <donoban> and also I'm not sure how to pass it, APKBUILD says that it ignoes CFLAGS
2023-11-23 20:26:46 <ikke> omni: it's stil progressing
2023-11-23 20:33:34 <omni> ikke: for how long have they been running? is it because the edge and 3.19 builders are competing for resources?
2023-11-23 20:36:59 <ikke> possibly, and it's know to take a long time
2023-11-23 20:37:13 <ikke> Don't know when the build started
2023-11-23 20:50:03 <omni> it's been going on for quite a few hours I think, took 290ish minutes on the CI builder
2023-11-23 20:52:50 <ikke> 51987/58554
2023-11-23 20:52:52 <ikke> and continuing
2023-11-23 20:58:21 <omni> I believed you at "still progressing" :D
2023-11-24 03:45:32 <ajhalili2006> !55922 is ready for review while testing the build on a VirtualBox-based devenv setup
2023-11-24 09:49:29 <PabloCorreaGomez[m]> BTW, what's going on with the riscv64 builder in edge? Seems it's been stuck for some days?
2023-11-24 09:51:00 <ikke> I'll check it out
2023-11-24 09:53:16 <PabloCorreaGomez[m]> Thanks!
2023-11-24 12:41:05 <celie> Speaking of riscv64, it seems !55922 is failing check() on riscv64, can it still be merged (i think check() is not run on the riscv64 builder)?
2023-11-24 12:54:51 <donoban> is there some ENV or trick for pass an option to ninja?
2023-11-24 12:56:27 <ikke> celie: yeah, tests are disabled 
2023-11-24 15:50:28 <orbea> donoban: you mean like SAMUFLAGS?
2023-11-24 15:52:16 <donoban> maybe, I want to pass '-d keepdepfile' to avoid it removes the depfiles after build
2023-11-24 15:53:17 <donoban> ~/aports/main/xen/src/xen-4.18.0 $ env |grep SAMU
2023-11-24 15:53:20 <donoban> SAMUFLAGS=-d keepdepfile -j8
2023-11-24 15:53:21 <donoban> let's try :D
2023-11-24 15:53:47 <orbea> might need to quote the value
2023-11-24 15:58:10 <donoban> ouch
2023-11-24 15:58:14 <donoban> it failed
2023-11-24 15:59:04 <donoban> what you mean with quote it? \" \"?
2023-11-24 15:59:23 <orbea> oh, i read the man page... " The only options allowed in SAMUFLAGS are -v and -j."
2023-11-24 15:59:44 <donoban> ohh
2023-11-24 16:00:35 <orbea> i guess you could write a wrapper script round it...
2023-11-24 16:00:52 <donoban> uhM, good idea
2023-11-24 17:30:58 <donoban> meh, I can run the wrapper directly, "/tmp/ninja --version" works, but if I add it to PATH it locks
2023-11-24 17:31:38 <donoban> when I ctr+c it prints 1.9 but cancels the rootbld build
2023-11-24 17:54:07 <WhyNotHugo> Any chance of merging this? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/54061 It restores a package that was accidentaly deleted on a previous rewrite. MR has been sitting there for about a month now.
2023-11-24 19:02:31 <ikke> Do we really nead ~1G in fonts?
2023-11-24 19:06:30 <ikke> The reason I'm reluctant is that I already have to do a lot of work to make sure the builders have enough space available and it becomes harder and harder
2023-11-24 19:13:26 <bl4ckb0ne> wow nerdfont is huge https://www.nerdfonts.com/
2023-11-24 19:14:08 <bl4ckb0ne> seems more like a gimmick that actual usable font tbh, im with ikke on this one 
2023-11-24 19:16:21 <abby> a much more sane way to do nerdfonts is to only use the "symbolsonly" font, which acts as a fallback for the private-use areas where it does its magic, instead of patching a million fonts to include extra characters
2023-11-24 19:31:31 <papiris[m]> ptrc: thanks for review and merging !54972 :)
2023-11-24 19:31:31 <papiris[m]> Thanks all y'all in chat too; my first experience with packaging (ever) was quite nice, actually 📦️
2023-11-24 19:31:31 <papiris[m]> Kladky:   thanks as well :)
2023-11-24 20:34:29 <RootWyrm> Ugh, so what I thought was a DTB issue may not be a DTB issue. Is there something dwmac-meson8b wants other than stmmac?
2023-11-24 20:41:19 <donoban> omni: it seems that removing "-mcpu=cortex-a15" fixed it, I'm not sure about the downsides
2023-11-24 20:41:35 <Hello71> donoban: your wrapper calls ninja?
2023-11-24 20:42:10 <donoban> it was something like: "exec ninja -d keepdepfiles $@"
2023-11-24 20:42:48 <donoban> uhmm..
2023-11-24 20:43:26 <donoban> maybe the depfiles get corrupted because they are generated with "-mcpu=cortex-15" but then ninja ignores it
2023-11-24 20:44:15 <donoban> https://gitlab.alpinelinux.org/donoban/aports/-/jobs/1192787
2023-11-24 20:44:36 <donoban> here is the aaarch64 log, the depfiles errors dissaparead and builds fine
2023-11-24 20:58:02 <donoban> Hello71: lol, I just noticed that not calling ninja with full path will produce a new call to the wrapper :)
2023-11-25 00:20:13 <ajhalili2006> celie: I manually ran riscv64 build just to check if the build works
2023-11-25 00:29:07 <ajhalili2006> (sorry for horrbiy late reply, just took sleep early in PH standard time)
2023-11-25 00:33:30 <celie> ajaso: Yes, but riscv64 didn't succeed (test failed), and apparently it can still be merged under those circumstances because tests won't run on the builders
2023-11-25 00:33:35 <celie> Oops
2023-11-25 00:33:41 <celie> Wrong nickname, sorry
2023-11-25 00:33:56 <celie> ajhalili2006: ^
2023-11-25 15:23:54 <omni> is net needed for cargo fetch in prepare()?
2023-11-25 15:24:00 <ikke> yes
2023-11-25 15:24:25 <ikke> without net, after the fetch stage, network is removed
2023-11-25 15:29:40 <omni> but doesn't seem needed on CI/package builders?
2023-11-25 15:29:57 <ikke> omni: it's only needed when you use rootbld (or equivalent)
2023-11-25 15:30:16 <omni> ok, haven't tried that yet
2023-11-25 15:30:25 <celie> I was just about to ask that
2023-11-25 15:31:26 <ikke> I'd like to be able to emulate that in docker (without roobld, which is both redudant and requires extra privileges in docker). I know how I can disable the network, but I need some hook to know when to disable it
2023-11-25 15:38:08 <smcavoy> Could someone take a look at: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/55400 ?
2023-11-25 15:45:29 <quinq> done
2023-11-25 16:23:56 <ikke> omni: you can assign MRs to the maintainers if aports-qa-bot didn't yet
2023-11-25 16:46:01 <zv> is it required (by design) to run 'apk' as root when using --root, in order for triggers to run? I am hoping to understand whether I am looking at an 'apk' bug or user error.
2023-11-25 16:46:32 <zv> e.g. mkdir x; apk add --root x --initdb; cp /etc/apk/repositories x/etc/apk; apk add --root x ca-certificates
2023-11-25 17:03:14 <zv> the error is that 'chroot(".")' fails, which is expected as the code is written. is the requirement for privileges documented?
2023-11-25 17:04:29 <ikke> I guess it falls under the requirement for any apk command making changes requiring to be run as root
2023-11-25 17:09:01 <zv> I see https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/5#note_56023, which sort of gets at this case
2023-11-25 17:12:45 <ikke> so there is a `--no-chown` flag
2023-11-25 17:13:14 <ikke> oh, and it should be enabled automatically when running as a non-root user
2023-11-25 17:42:41 <bl4ckb0ne> is there a protocol to follow to propose a package removal?
2023-11-25 18:17:44 <omni> ikke: I try to when I can, some are hard to find or not selectable from the drop-down
2023-11-25 19:29:14 <ikke> You can use /assign @username if you know it
2023-11-26 09:15:54 <fraolt> Is there anything I can do to move along !55276?
2023-11-27 00:55:09 <celie> Could someone please merge !56080? Thanks
2023-11-27 00:57:43 <celie> Also, getting !56100 and !55827 merged would be nice, but those are in main/ and not maintained by me, so i understand if it needs some time for review and so on
2023-11-27 05:24:59 <ikke> celie: seems like that perl CVE is even windows only
2023-11-27 07:15:21 <ncopa> good morning
2023-11-27 07:17:10 <ikke> o/
2023-11-27 07:21:48 <ncopa> how are things going?
2023-11-27 07:36:00 <celie> The builders finally finished building 3.19, but you've probably noticed that already :)
2023-11-27 07:44:51 <ncopa> yup! congrats! good job!
2023-11-27 07:45:30 <ncopa> and we even have an rc1!
2023-11-27 07:46:08 <ncopa> seems like the s390x machine(s?) is misbehaving. anybody know for how long time it has been doing that?
2023-11-27 07:46:20 <ncopa> its just dead slow
2023-11-27 07:47:51 <ncopa> hum, a restart of build-edge-s390x appears to have fixed that
2023-11-27 10:08:30 <omni> wb!
2023-11-27 10:22:46 <ncopa> thank you!
2023-11-27 10:49:11 <vkrishn> wb! while ur gearing for al, might just enjoy this article+video on it, https://wiki.insteps.net/Mobile/Install-alpinelinux-via-adb
2023-11-27 11:10:03 <sam_> one perl CVE is windows only, one isn't
2023-11-27 11:18:02 <pj> ncopa: have you seen CI for !52887? I'm guessing it's oom'ing or something but I don't have any arm 32-bit machine to debug that
2023-11-27 11:50:30 <omni> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/136
2023-11-27 12:11:32 <ncopa> vkrishn: that was both cool and hilarious at the same time!
2023-11-27 12:12:37 <ncopa> ikke: do you think we could give an 32 bit arm env for pj to debug rust?
2023-11-27 12:15:25 <vkrishn> thanks, I would try to upgrade the kernel to mainline, only if I can grab one
2023-11-27 12:28:34 <ikke> ncopa: fine with me
2023-11-27 15:16:31 <ncopa> those rpi changes are killing me
2023-11-27 15:16:35 <ncopa> lots of changes
2023-11-27 15:16:39 <ncopa> everywhere
2023-11-27 15:16:57 <ncopa> no explanation or reference to *why* thos breaking changes happens
2023-11-27 15:17:38 <ncopa> anybody know why upstream rpi moved the kernel from /boot to /boot/firmware?
2023-11-27 15:18:15 <ncopa> there is no ref to anything on why the change was made in the docs commit https://github.com/raspberrypi/documentation/commit/7d1efe23e7b7227108713d14cdd17e1b41fb674a
2023-11-27 15:35:00 <TangentDelta> I read something about older distros using /boot/firmware, and Raspbian "Bookworm" changed to be consistent with them.
2023-11-27 15:36:41 <TangentDelta> https://salsa.debian.org/debian/raspi-firmware/-/merge_requests/33
2023-11-27 16:28:51 <ncopa> thanks. this also indicates that: https://github.com/raspberrypi/documentation/issues/3089#issuecomment-1817486005
2023-11-27 16:32:59 <ncopa> TangentDelta: that was really good ref. It also links to this issue: https://github.com/raspberrypi/documentation/issues/3089#issuecomment-1817486005
2023-11-27 16:33:11 <ncopa> they are blaming each other at this point
2023-11-27 17:51:11 <TangentDelta> ncopa: Heh, yeah. Looks like a big finger-pointing game :(
2023-11-27 18:12:05 <Arnavion> My x86_64 bookworm box has the kernel and initrd in /boot and no /boot/firmware directory, or is "older releases used /boot/firmware as well" specifically an aarch64 thing?
2023-11-27 18:26:23 <TangentDelta> I can't find much about why /boot/firmware even existed to begin with, other than something to do with binary blobs for the driver for the graphics?
2023-11-27 18:26:47 <TangentDelta> Which seems like a silly place for those to live
2023-11-27 18:40:06 <ncopa> the problem is that dpkg does not support fat, and rpi requires bootloader to be on fat and kernel on same partition as bootloader, so it requires something dpkg does not support
2023-11-27 18:40:56 <ncopa> Arnavion: its an rpi workaround for dpkg not supporting fat, and they changed how the workaround works
2023-11-27 18:41:18 <ncopa> apk-tools does not have this limitation, so there is no point for us to do this nasty workaround
2023-11-27 21:41:33 <skinkie> I am trying to do a merge request. But I end up in a situation which does not allow me to continue, and 404 on the open merge request. Any suggestions? These branches already have an open merge request: !56178. Select a different source or target branch.
2023-11-27 21:42:09 <skinkie> That seems to work now.
2023-11-28 05:05:08 <pj> ikke: is there anything I need to do to get that arm32 (armv7 or armhf) container?
2023-11-28 06:18:47 <ikke> pj: do you have ipv6 connectivity?
2023-11-28 06:19:24 <pj> I should, unless my modem forgot about it again
2023-11-28 06:20:06 <ikke> Should I use these ssh keys? https://gitlab.alpinelinux.org/pj.keys
2023-11-28 06:22:28 <pj> yeah, those should be fine
2023-11-28 06:23:17 <pj> i need to clean that up at some point, since I'm only using single key on my yubi these days
2023-11-28 07:29:50 <quinq> Hi, I get a strange error:
2023-11-28 07:30:01 <quinq> apk info -r qt6-qtwayland
2023-11-28 07:30:01 <quinq> qt6-qtwayland-6.6.1-r0 is required by:
2023-11-28 07:30:06 <quinq> (nothing)
2023-11-28 07:30:16 <quinq> doas apk del qt6-qtwayland
2023-11-28 07:30:23 <quinq> World updated, but the following packages are not removed due to: qt6-qtwayland: gtk4.0-dev [long list of other packages]
2023-11-28 07:30:38 <quinq> The package is still present and not actually removed
2023-11-28 07:31:13 <quinq> How to fix thta?
2023-11-28 07:31:18 <quinq> s/thta/that/
2023-11-28 07:52:24 <craftyguy> seems like the riscv64 edge builder has been stuck on "signing index" for like >5 hours now
2023-11-28 08:00:04 <ncopa> quinq: maybe gtk4.0-dev depends on so:libqtwayland.* or similar, or somethign else provided by qt6-qtwayland?
2023-11-28 08:09:23 <quinq> That'd be strange for gtk to depend on qt
2023-11-28 08:09:35 <quinq> But I'll try to have a better look tonight after work
2023-11-28 08:09:41 <quinq> Thanks ncopa, have a good day everybody :)
2023-11-28 08:42:41 <bratkartoffel> fabled: did you have time to look at !56161?
2023-11-28 08:53:32 <ncopa> anybody knows if macmpi is here on irc?
2023-11-28 08:56:02 <realzNEO> i would like to ask alpine devs a question
2023-11-28 08:56:09 <realzNEO> i been working on a custom distro, hobby project nothing serious
2023-11-28 08:56:19 <realzNEO> and was wondering how difficult was it making the package manager
2023-11-28 08:56:28 <realzNEO> and can i have some resources regarding how alpine does it ?
2023-11-28 08:57:09 <ncopa> first iteration of package manager (apk-tools 1) was not that difficult. It was basically shell scripts
2023-11-28 08:57:49 <ncopa> apk-tools 2, on the other hand, was written by a genius, and is fairly complicated
2023-11-28 08:58:45 <ncopa> the best resources for package manager is the sources themselves.  https://gitlab.alpinelinux.org/alpine/apk-tools
2023-11-28 08:59:35 <ncopa> i wouldnt recommend writing your own package manager unless you have very good reasons to do so
2023-11-28 08:59:49 <realzNEO> why yes i do have very good reasons
2023-11-28 09:00:08 <realzNEO> you see this distro is meant to be security focused
2023-11-28 09:00:24 <ncopa> there are a bunch of package managers out there already
2023-11-28 09:00:29 <realzNEO> as you know pretty much all linux distros package managers use http by default, are written in memory unsafe languages, are overly complicated etc
2023-11-28 09:00:42 <realzNEO> i want do something of my taste
2023-11-28 09:00:42 <realzNEO> truly minimal
2023-11-28 09:00:47 <realzNEO> not complex any idiot can understand how it works
2023-11-28 09:00:51 <realzNEO> written in a memory-safe language
2023-11-28 09:00:54 <realzNEO> enforces https for mirrors
2023-11-28 09:00:56 <realzNEO> etc.
2023-11-28 09:01:00 <bratkartoffel> http is not unsafe itself if you verify the package signatures
2023-11-28 09:01:09 <realzNEO> i know
2023-11-28 09:01:24 <realzNEO> but https can prevent exploitations of bugs in the package manager it's self, say a buffer overflow etc.
2023-11-28 09:01:45 <ncopa> well write a package manager in rust makes sense IMHO
2023-11-28 09:02:07 <realzNEO> maybe rust, maybe go.
2023-11-28 09:02:30 <ncopa> i'd pick rust, even if i dont know rust that well. I do know go
2023-11-28 09:02:52 <realzNEO> I know go as well, saw documentation for Rust and syntax made me vomit lol.
2023-11-28 09:03:04 <ncopa> this also reminds me at one time where I complained about apk-tools. "this is not simple!"
2023-11-28 09:03:30 <ncopa> and the response I got was: "well, the problem it solves is not simple"
2023-11-28 09:04:10 <realzNEO> true some problems need complex solutions to tackle
2023-11-28 09:04:16 <realzNEO> but 99% of things can be done simply
2023-11-28 09:04:38 <realzNEO> like terry davis once said "an idiot admires complexity while a genius admires simplicity"
2023-11-28 09:05:13 <ncopa> yup. simple is one of alpines main goals
2023-11-28 09:05:27 <realzNEO> and i respect alpine for that
2023-11-28 09:05:30 <bratkartoffel> realzNEO: how about the nix package manager? it is focussed on security imho. and only because it's written in a memory "unsafe" language it doesn't mean it's not secure. look at musl libc, i think it's one of the most secure pieces of software i know
2023-11-28 09:05:39 <realzNEO> it is one of the few distros i actually like.
2023-11-28 09:05:43 <ajhalili2006> if I maintain a package with same name but different versions across tracks (stable and unstable in my planned package repo/PPA for alpine:edge), how does apk handle upgrade from that case?
2023-11-28 09:05:44 <ncopa> the problem is where to draw the line. there are trade-offs
2023-11-28 09:06:16 <ajhalili2006> (especially when upgrading from package downloaded from the official repo)
2023-11-28 09:06:25 <realzNEO> @bratkartoffel i have not used nix 
2023-11-28 09:06:38 <realzNEO> ops i don't know how to quote on irc yet lol
2023-11-28 09:06:49 <realzNEO> but you got sources for your claims?
2023-11-28 09:07:18 <realzNEO> like a paper or something, even couple reputable blog posts  
2023-11-28 09:07:22 <ncopa> realzNEO: i'd recommend you study the existing package managers before writing your own, even if you end up re-implementing
2023-11-28 09:07:38 <realzNEO> i do and did to a good degree
2023-11-28 09:07:44 <realzNEO> i just don't know nix
2023-11-28 09:07:51 <realzNEO> but your right
2023-11-28 09:08:01 <realzNEO> can never be too "Expert" on such matters, will def keep digging
2023-11-28 09:08:23 <realzNEO> (its why i asked you about your package manager)
2023-11-28 09:08:27 <ncopa> ajhalili2006: apk does not really handle that case at all. it simply picks the "latest" version it finds of same name
2023-11-28 09:09:07 <realzNEO> one last question ncopa
2023-11-28 09:09:37 <realzNEO> say i do manage to do my distro, what is best way to host it? how does alpine pay for mirrors servers and main website ?
2023-11-28 09:09:54 <omni> ncopa: I'd like to upgrade zfs but this is needed first https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/136
2023-11-28 09:10:11 <realzNEO> don't tell me you pay out of your own pocket lol
2023-11-28 09:10:17 <ajhalili2006> ncopa: guess "@ajhalili2006 https://<package-repo-url-here>/alpine/edge/unstable | sudo tee -a /etc/apk/repositories && apk add package@ajhalili2006" maybe work?
2023-11-28 09:10:39 <ncopa> yeah
2023-11-28 09:11:49 <ncopa> realzNEO: we dont pay for that indeed. we have sponsors. https://www.alpinelinux.org/sponsors/
2023-11-28 09:12:14 <realzNEO> ahh of course
2023-11-28 09:13:34 <realzNEO> surprised theres not that many sponsors 
2023-11-28 09:13:38 <ajhalili2006> ncopa: Speaking for corporate sponsors, can I sponsor the project as individual (in the foreseekable future, although PH taxes may complicate this)?
2023-11-28 09:13:43 <realzNEO> thought google and amazon wouldve been there
2023-11-28 09:14:00 <realzNEO> alpine is pretty popular in containers and stuff after all
2023-11-28 09:14:38 <ncopa> yeah. docker was a sponsor at some point, but never got listed ( iasked them if they wanted be listed, but never got any response)
2023-11-28 09:15:16 <ncopa> amazon should step ump IMHO and help host the AMIs
2023-11-28 09:15:21 <ncopa> google I dont know
2023-11-28 09:15:37 <realzNEO> what does "AMIs" stand for ? execuse my ignorance 
2023-11-28 09:15:41 <ncopa> its on my to-do list to ask amazon
2023-11-28 09:16:14 <ncopa> speaking of google.... google gave me this: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html
2023-11-28 09:16:22 <realzNEO> do the sponsors contact you first or you contact them? 
2023-11-28 09:16:25 <realzNEO> hahhahaha
2023-11-28 09:16:26 <realzNEO> of course
2023-11-28 09:16:34 <realzNEO> thanks, will be sure to duckduckgo next time before asking
2023-11-28 09:17:03 <realzNEO> 403 ERROR
2023-11-28 09:17:03 <realzNEO> The request could not be satisfied.
2023-11-28 09:17:09 <realzNEO> they block tor
2023-11-28 09:17:11 <realzNEO> sad.
2023-11-28 09:17:43 <skarnet> how would they telemetry you if they didn't :P
2023-11-28 09:17:54 <ncopa> good question. i suppose both?
2023-11-28 09:18:08 <ncopa> some has reached out, some have we asked
2023-11-28 09:18:47 <ncopa> reminds me, i think also microsoft offered something on azure
2023-11-28 09:20:40 <realzNEO> good to know
2023-11-28 09:22:55 <realzNEO> welp i got to hit the sack bye! nice talking to you and keep up good work
2023-11-28 09:59:34 <bratkartoffel> ncopa: thanks for merging the java 8 fix, i've also created a backport for 3.18: !56211
2023-11-28 10:27:21 <vkrishn> morning !
2023-11-28 10:28:13 <vkrishn> is busybox-extras pkgs something of lesser used or likely to be reoved in future ?
2023-11-28 10:28:42 <vkrishn> removed^
2023-11-28 10:34:51 <ikke> Lesser used and more security sensitive 
2023-11-28 10:36:00 <vkrishn> thanks, but will stay ?
2023-11-28 10:37:40 <vkrishn> ok, got it
2023-11-28 10:41:30 <ikke> There are no active plans to remove them
2023-11-28 11:18:23 <papiris[m]> Hi clandmeter, could you look at upgrading `py3-sphinx` to a newer version?
2023-11-28 11:18:23 <papiris[m]> I want to retain copyright for the original author of the upstream in the docs of `apk-snap`, but support for multiple authors isn't present in `py3-sphinx-6.2.1`
2023-11-28 11:18:23 <papiris[m]> !15514
2023-11-28 11:19:16 <papiris[m]> Oops, seems algitbot doesn't handle issues the same way it handles MRs
2023-11-28 11:19:25 <ikke> papiris[m]: with a #
2023-11-28 11:19:37 <ikke> like how gitlab itself distinguishes between issues and mrs
2023-11-28 11:22:43 <papiris[m]> Thanks
2023-11-28 11:34:50 <papiris[m]> #15514
2023-11-28 14:11:25 <durrendal> Is there any way to get the CI/CD timeout extended on MR !53545, specifically for armv7/armhf? The build times out while running tests, but Daniel and I are pretty certain they'll pass if it's given a little more time to run
2023-11-28 14:14:10 <ikke> durrendal: you can do it yourself in the CI/CD settings of your fork
2023-11-28 14:18:19 <durrendal> wait, really?
2023-11-28 14:18:37 <durrendal> hang on, this sounds like a gitlab thing I can google then
2023-11-28 14:26:08 <durrendal> right, looks like it's Settings > CI/CD > General Pipelines > Timeout. Thank you ikke :)
2023-11-28 14:26:44 <ikke> 👍
2023-11-28 19:07:15 <celie> chereskata: I am unwell and so won't be able to rebase !53260, sorry. You may find a way to take over, and i will close my MR.
2023-11-28 19:07:17 <celie> Thanks
2023-11-28 19:07:33 <celie> There's also build-3-19-s390x that seems to be stuck on perl-server-starter
2023-11-28 19:07:35 <celie> omni: Since you've opened an MR on main/charybdis, i think there's another IRC-related aport that's no longer developed upstream: community/ircservices
2023-11-28 19:08:07 <celie> Did you download all Python packages, or did you use some code search engine?
2023-11-28 19:08:09 <celie> Ok :)
2023-11-28 19:08:09 <celie> ptrc: I just remembered something regarding pkg_resources
2023-11-28 19:08:11 <celie> Compare /usr/bin/txt2tags from txt2tags 3.8-r1 (in 3.18-stable) and 3.9-r0 (in edge)
2023-11-28 19:08:11 <celie> The one in 3.18-stable refers to pkg_resources but not the one in edge, and i think it's due to the gpep517 migration
2023-11-28 19:08:13 <celie> Ok
2023-11-28 19:08:15 <celie> bl4ckb0ne: Ok, thanks
2023-11-28 19:08:17 <celie> :)
2023-11-28 19:08:25 <celie> I mean, py3-bleach upstream vendors urlparse, and we devendor it, which causes the tests to fail
2023-11-28 19:08:25 <celie> It seems py3-bleach vendors an old version of urlparse and tests for that behavior, it seems we deselected one such test due to changes in Python 3.9, and we'll have to deselect another one for Python 3.11: !53945 (the new failing test was caught by the 3.19 builders)
2023-11-28 19:08:27 <celie> The Github issue i linked to in the MR mentions that the test fails on OpenSUSE and Fedora too, i checked Debian, but it seems Debian leaves the urlparse vendored: https://packages.debian.org/bookworm/all/python3-bleach/filelist
2023-11-28 19:08:41 <celie> omni: Could you have a look at !54027 when you have time? I think it solves #15257, so you'll probably have to backport it, at least the first commit removing typing-extensions from setup.cfg
2023-11-28 19:08:43 <celie> Solving #15257 is complicated a little bit by migrating to gpep517 which uses a different template for generating /usr/bin/pgcli, which does not check for requirements (i mentioned this difference here a few days ago, using the txt2tags aport as an example)
2023-11-28 19:08:45 <celie> I'm leaning more towards the latter as it prevents the problem from occurring should any other aport use the non-gpep517 /usr/bin template
2023-11-28 19:08:45 <celie> In other words, to solve that issue on 3.18, from what i see, you'll either have to backport the gpep517 migration of pgcli (so it uses the /usr/bin template that does not check for requirements), or you'll have to backport the removal of typing-extensions from setup.cfg of py3-psycopg (so typing-extensions is removed from the requirements)
2023-11-28 19:08:47 <celie> To further summarize what i just said, while it looks like #15257 was solved by !54017, it was actually solved (sort of) by migrating to gpep517 in !53999
2023-11-28 19:08:47 <celie> You may double check my findings: in edge, i tried /usr/bin/pgcli of pgcli-3.5.0-r2 from before the gpep517 migration, and i get the error in #15257, after removing typing-extensions from setup.cfg, i no longer get the error (of course, pgcli-3.5.0-r3 doesn't have the error in either case as it doesn't check for requirements)
2023-11-28 19:08:49 <celie> So, for backporting to 3.18, we could consider either migrating pgcli to gpep517, or removing typing-extensions from setup.cfg of py3-psycopg
2023-11-28 19:08:55 <celie> omni: Yes, i'm learning more towards removal of typing-extensions, just in case there's something else that uses py3-psycopg and hasn't been migrated to gpep517 yet
2023-11-28 19:08:57 <celie> and the typing-extensions patch was already updated in 3.18 yeaterday, so this removal from setup.cfg is just a follow-up on that, and should finally solve #15257 for good
2023-11-28 19:08:57 <celie> omni: My comments from the MR are already in the commit message, or did i leave something out?
2023-11-28 19:08:59 <celie> It is still an issue for 3.18, in edge, this is sort of solved by the migration to gpep517, which generates a /usr/bin/pgcli that does not check for requirements on startup
2023-11-28 19:09:01 <ikke> ?
2023-11-28 19:09:03 <celie> Ah, !54086 should fix it
2023-11-28 19:09:03 <celie> Did libdrm_intel.so.1 get removed in !54058?
2023-11-28 19:09:09 <celie> omni: snort & snort-extra 3.1.73.0 are out, so you can update !54023
2023-11-28 19:09:12 <ikke> celie: what is happening?
2023-11-28 19:09:36 <bl4ckb0ne> sounds like pasting previous irc buffer
2023-11-28 19:09:43 <celie> omni: I wonder if !54372 still uses system zstd, looking for clues in the build log, i see -Izstd and -DZSTD_SINGLE_FILE
2023-11-28 19:09:45 <celie> I see you've updated it, but the tests still fail
2023-11-28 19:09:45 <celie> https://github.com/indygreg/python-zstandard/blob/main/setup_zstd.py#L57 and #L81 probably confirms that it isn't system zstd anymore
2023-11-28 19:09:47 <celie> and the zstandard enable on armhf & s390x commit also ended up in !54370
2023-11-28 19:09:47 <celie> Any idea if the tests fails without the gpep517 (so i'm thinking about a simple rebuild)?
2023-11-28 19:09:49 <celie> Hmm, from the log in !54370, it doesn't look like zstandard is using pytest
2023-11-28 19:09:49 <celie> Ah, okay, so i almost answered my own question :D
2023-11-28 19:09:51 <celie> Perhaps you can try -m unittest in 54372, but i would be a little surprised if that allows the tests to pass..
2023-11-28 19:09:57 <celie> Ermine: That seems to be the recommended way to package Python aports now, and omni started migrating main/ to that in preparation for Alpine 3.19. However, there are some aports that don't seem to be ready yet, so if you think one of yours is not ready then you can discuss that in the merge request.
2023-11-28 19:09:57 <celie> Alright, maybe we should just focus on migrating main/ to gpep517 for 3.19
2023-11-28 19:10:10 <bl4ckb0ne> theres one irc client thatallows that, ive seen it before
2023-11-28 19:11:00 <ikke> It's multiple channels
2023-11-28 19:11:11 <bl4ckb0ne> ow
2023-11-28 19:11:42 <ikke> Maybe a bouncer that is going haywire?
2023-11-28 19:12:57 <ikke> seems to replay all chat message
2023-11-28 19:13:25 <ikke> messages from 14 days ago
2023-11-28 19:14:30 <bl4ckb0ne> libdrm stuff is old
2023-11-28 19:17:28 <ikke> I saw a message in #-offtopic which was originally posted on 12 november
2023-11-28 19:23:32 <dari> so many message and I thought there is discusion about new release or something :P
2023-11-28 19:23:42 <ikke> haha
2023-11-28 19:38:43 <Ermine> I thought it's actuall discussion. At least I've resurrected my dev container finally. No need to reboot anymore!
2023-11-28 20:02:59 <TangentDelta> Lol, just celie having a chat with the bot
2023-11-28 20:05:35 <dari> algitbot o/
2023-11-28 22:35:32 <omni> celie: I'm quite beat, will slowly look at things
2023-11-28 22:54:31 <TangentDelta> omni: I don't know if they actually had anything for you to look at. It looks like their bounder started vomitting old messages into the channel.
2023-11-28 22:55:04 <TangentDelta> *bouncer
2023-11-28 22:57:49 <omni> oh
2023-11-28 22:57:58 <omni> hadn't read up on all of it yet
2023-11-28 22:58:22 <omni> but it did sound familiar
2023-11-29 01:47:35 <celie> Sorry about that bouncer fail
2023-11-29 02:03:14 <TangentDelta> I thought that getting U-Boot or Linux to run on this Netgate SG-3100 would be easier than the SG-1000. I can't even find a dts file for it :(
2023-11-29 02:04:56 <bl4ckb0ne> celie: what bouncer are you using?
2023-11-29 02:08:32 <celie> bl4ckb0ne: https://biboumi.louiz.org/
2023-11-29 02:08:49 <TangentDelta> I was at least able to get an old .dts from FreeBSD for the SG-1000, and compiling that I was able to get Alpine to boot and install.
2023-11-29 02:09:05 <celie> Still not sure what caused it to go crazy like that
2023-11-29 02:09:57 <bl4ckb0ne> nice testimonials
2023-11-29 02:10:55 <celie> bl4ckb0ne: Anyway, what IRC client did you have in mind when you said you had seen it before earlier?
2023-11-29 02:15:57 <TangentDelta> I've been trying to build a newer version of Das U-Boot for the SG-1000, but I don't have a firm enough grasp on how to set up a new board.
2023-11-29 02:17:29 <bl4ckb0ne> it was catgirl
2023-11-29 02:18:08 <bl4ckb0ne> theres a feature that allows you to cat a command output into irc
2023-11-29 02:20:45 <celie> Ok, i think that's available in other clients as well, irssi has /exec -msg
2023-11-29 05:52:25 <ikke> Seems like some packages need to be rebuilt when perl is being upgraded (even for minor versions)
2023-11-29 05:52:41 <ikke> (patch upgrades)
2023-11-29 05:52:49 <ikke> #15520
2023-11-29 06:00:53 <ikke> celie: would per-par-packer be the only package that needs to be rebuilt?
2023-11-29 06:05:41 <celie> ikke: I think so
2023-11-29 06:07:52 <ikke> https://tpaste.us/z5dW
2023-11-29 06:08:05 <ikke> that's packages that depend on libperl.so
2023-11-29 06:10:00 <celie> It seems perl-par-packer includes a copy of the Perl interpreter it was compiled with, and there is an option to leave out libperl.so, which could result in the interpreter and library having different versions
2023-11-29 06:11:25 <celie> I think the other packages are fine with our current tradition of only rebuilding them for Perl major versions
2023-11-29 06:14:52 <celie> Anyway, when we do rebuild the Perl aports, i will probably want to include this change for 32-bit architectures: !50233
2023-11-29 06:15:04 <celie> but not now, not so close to 3.19
2023-11-29 06:18:30 <celie> Anyway, i don't think your list is complete, what's missing are the perl-* aports that also drop a *.so into /usr/lib/perl5/vendor_perl/auto (and there are probably a few that use a diferent location)
2023-11-29 06:19:44 <celie> I should probably make a list of Perl aports to rebuild on major version upgrades when i can find the time
2023-11-29 06:20:29 <ikke> It's unexpected to have to do rebuilds for patch upgrades
2023-11-29 06:22:25 <celie> Yes, thankfully it was reported
2023-11-29 06:24:08 <celie> The error comes from a runtime check that's added by this script: https://github.com/rschupp/PAR-Packer/blob/master/myldr/encode_append.pl#L36
2023-11-29 06:26:38 <celie> Maybe they're just being cautious as minor versions shouldn't such incompatibilities
2023-11-29 08:44:59 <ncopa> Linux localhost 6.6.2-0-lts #1-Alpine SMP PREEMPT_DYNAMIC Tue, 28 Nov 2023 13:39:42 +0000 x86_64 Linux  
2023-11-29 08:45:44 <ncopa> im refactoring the rpi kernel flavors, and upgrading kernels to 6.6.2 while at it
2023-11-29 08:45:55 <ncopa> and upgrade zfs to 2.2
2023-11-29 09:13:18 <Kladky> Is there anything keeping aports-turbo/!58 from being merged?
2023-11-29 09:13:56 <Kladky> https://gitlab.alpinelinux.org/alpine/infra/aports-turbo/-/merge_requests/58
2023-11-29 10:14:18 <ncopa> uh-oh... kernel 6.6 and zfs is not compatible on arm64 - due to license change
2023-11-29 10:17:54 <abby> on void we told users to change the licence in the META file themselves
2023-11-29 10:18:27 <abby> the whole kernel GPL symbols thing is extremely iffy 
2023-11-29 10:19:07 <abby> chimera just disabled neon https://github.com/chimera-linux/cports/blob/master/main/zfs/patches/aarch64-disable-neon.patch
2023-11-29 10:19:52 <ncopa> ah. thanks!
2023-11-29 10:20:09 <abby> also I would wait for 2.2.2 and 2.1.14, that will include a huge bugfix for a silent corruption issue
2023-11-29 10:20:21 <abby> expected to drop probably tomorrow or the next day
2023-11-29 10:21:07 <ncopa> would like to test the 6.6 kernel as early as possible
2023-11-29 10:21:14 <ncopa> need get 3.19 out asap
2023-11-29 10:21:31 <abby> https://github.com/openzfs/zfs/pull/15601 and https://github.com/openzfs/zfs/pull/15602
2023-11-29 10:44:44 <ajhalili2006> Since Terraform had been relicensed to BSL, should I make a patch removing from the aports instead of take the risk and upgrade the package?
2023-11-29 10:45:04 <ncopa> i think we removed it already?
2023-11-29 10:45:30 <ajhalili2006> ncopa: probably outdated local copy, wait a sec
2023-11-29 10:47:58 <ajhalili2006> ncopa: apologies on that
2023-11-29 11:27:00 <ncopa> no worries
2023-11-29 13:39:02 <celie> Oh great, i see a perl-5.34.3 was just uploaded to CPAN, please don't tell me there will be a perl-5.36.3 and perl-5.38.2 as well..
2023-11-29 14:16:06 <minimal> ncopa: after the cloud-init conf (in June?) I did try to put yourself and tomalok in contact with the people from Amazon and Azure but got no real feedback on the Alpine side...
2023-11-29 14:31:20 <ncopa> interesting
2023-11-29 14:31:26 <ncopa> what did they say?
2023-11-29 14:31:47 <ncopa> Linux alrpi3 6.6.2-0-rpi #1-Alpine SMP Wed Nov 29 10:07:08 UTC 2023 armv7l Linux
2023-11-29 14:31:55 <ncopa> rpi kernel boots at least
2023-11-29 14:33:30 <ncopa> now the big question is if we bother to make 32 bit  -v7l (with LPAE) flavor and a rpi16k flavor
2023-11-29 14:34:23 <minimal> ncopa: what did who say?
2023-11-29 14:35:03 <ncopa> minimal: oh, i misread
2023-11-29 14:35:30 <minimal> I was saying I got no realy sigh of interest from yourself or tomalok in being put in contact with them
2023-11-29 14:35:37 <minimal> s/sigh/sign/
2023-11-29 14:36:03 <ncopa> well, i am interested in getting in contact with amazon. Do you have a contact there?
2023-11-29 14:37:22 <minimal> I'd have to check my notes, there was a AWS staff member who was also personally involved in Debian cloud-images for multiple cloud providers
2023-11-29 14:38:08 <minimal> that's the point, I had a fresh contact and offered to put you and tomalok in touch month ago and got crickets...
2023-11-29 14:38:22 <ncopa> i mentioned in in #debian-cloud, and gave my email address there, but never heard from anybody
2023-11-29 14:38:51 <ncopa> minimal: im sorry. we are trying our best to keep up with everything
2023-11-29 14:41:00 <tomalok> minimal: last couple months have been hell at DayJob, i'm sorry if i missed it
2023-11-29 14:41:48 <minimal> ncopa: a DM I had sent you: Aug 24 16:06:30 <minimal>	Hi. At the cloud-init summit a couple of weeks ago there was a guy from AWS who also works on Debian cloud-images (in general I believe, not specific to AWS). You mentioned on alpine-cloud a few months ago you were talking to someone from debian-cloud, was this Noah?
2023-11-29 14:59:27 <ncopa> minimal: sorry for letting fall between the cracks.
2023-11-29 15:07:01 <ncopa> i think i may have broken the builders for a sec there
2023-11-29 15:40:51 <ayakael0> Hello everyone, could someone take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/56173 It's simply upgrades to all of my python modules. I've tested these upgrades locally, and havn't found any issues in my applications that use 'em.
2023-11-29 16:02:56 <ptrc> ayakael0: that's quite a bit of packages in one merge request, any reason why they're all grouped together?
2023-11-29 16:08:25 <ayakael0> I've been terribly busy the last few months and just now had the time to go through my python aports. I can break them apart without issue, though.
2023-11-29 16:09:33 <ayakael0> Would you prefer that?
2023-11-29 16:16:40 <ptrc> this is fine, it's just more effort to review it properly since i'd have to check all changelogs and file listing diffs before i can merge the whole thing
2023-11-29 16:17:28 <ptrc> in the case of smaller merge requests, it's easier to either parallelize the work across multiple people to review them, or just merge them separately
2023-11-29 16:19:11 <ayakael0> Undestood, that makes sense. I assumed that since all of these are minor updates it would be more work for y'all if they were seperate, but I see otherwise. I've tied up these projets to anitya now, so I'll now receive a notification when they are out of date as to avoid a mass drop of updates.
2023-11-29 16:21:16 <ayakael0> These packages were all merged in september, so I doubt any of them are dependencies yet.
2023-11-29 16:24:56 <ncopa> ayakael0: me personally will not look at testing/ packages until alpine 3.19 is out, sorry
2023-11-29 16:26:37 <ayakael0> No worries, appreciate the work on v3.19!
2023-11-29 16:26:55 <ayakael0> I plan to move them to community after, but missed the window for 3.19.
2023-11-29 16:50:20 <sicelo> is it still possible to update a package for such update to be included in 3.19, or not anymore? 
2023-11-29 16:52:18 <ncopa> sicelo: depends on how big the update is
2023-11-29 16:52:30 <ncopa> minor updates are accepted
2023-11-29 16:53:04 <sicelo> alright. when does it close completely? 
2023-11-29 16:53:11 <ikke> anything in edge/main and edge/community will be in 3.19
2023-11-29 16:53:14 <ikke> once 3.19 is released
2023-11-29 16:54:02 <ncopa> it closes when we tag 3.19 release
2023-11-29 16:54:18 <ikke> (and branch 3.19-stable
2023-11-29 16:54:20 <ikke> )
2023-11-29 18:06:36 <ncopa> humpf... i booted the 64 bit rpi kernel earlier today, but now it no longer boot. no idea what I have done to break it...
2023-11-29 18:12:00 <ncopa> and the armv7 variand does not boot on rpi4
2023-11-29 18:12:07 <ncopa> only on rpi3
2023-11-29 18:40:43 <khem> ncopa: maybe devicetree got messed up ? what do you see on serial console ?
2023-11-29 18:41:35 <ncopa> i havent checked. i think i messed up the config.txt somehow. it boots now
2023-11-29 18:41:50 <khem> yes that can happen too :)
2023-11-29 18:42:03 <khem> usually the device is specified there
2023-11-29 18:55:19 <sicelo> fcolista: hi. when you get chance, i have aports MR 56284 waiting for your approval. I'm hoping this could go into 3.19
2023-11-29 18:56:33 <ikke> !56284
2023-11-29 19:32:43 <ncopa> ok! both pi3 and pi4 boots here now. I think I am ready to push the 6.6 kernel
2023-11-29 19:35:23 <ikke> Did you sort the license issue out?
2023-11-29 19:35:46 <ncopa> i disabled neon
2023-11-29 19:35:56 <ncopa> so zfs is likely slower on arm
2023-11-29 19:36:35 <ncopa> sigh... need to tag 3.18.5 security release 
2023-11-29 19:36:46 <ikke> yup
2023-11-29 19:53:52 <khem> ncopa: why disable neon ?
2023-11-29 19:54:02 <khem> is there some bug ?
2023-11-29 19:54:35 <ncopa> khem: kernel 6.2+ changed an exported symbol for neon support to become _GPL, so zfs fails to build
2023-11-29 19:55:24 <vkrishn> iirc, neon also allows chroot to run 
2023-11-29 19:55:38 <khem> ah yes I saw that with yocto as well 
2023-11-29 19:55:48 <khem> some time ago
2023-11-29 19:55:59 <ncopa> how did you solve it in yocto?
2023-11-29 19:56:15 <ncopa> i got a patch from chimera
2023-11-29 19:56:57 <khem> no we did not - https://github.com/openzfs/zfs/issues/14555
2023-11-29 19:57:28 <ncopa> yeah, thats the issue
2023-11-29 19:58:00 <ncopa> this is the patch we will use: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/56280/diffs?commit_id=3afef6c6c88a4b8a5be3a985b2459b53074af16e
2023-11-29 19:58:56 <khem> nix folks has the change - https://github.com/jakubgs/nixos-config/commit/4e3e676c61b7ddedb971eddd23b92337fa124fa4
2023-11-29 20:02:23 <ncopa> they are reverting the patch in kernel?
2023-11-29 20:16:30 <Arnavion> That is someone's personal nix config
2023-11-29 20:16:45 <Arnavion> But yes nixos reverts the kernel commit to make the symbols available:   https://github.com/NixOS/nixpkgs/blob/2c01cd06afc2e327343b047e27e172ba488d98f8/nixos/modules/tasks/filesystems/zfs.nix#L713-L726
2023-11-29 20:17:15 <ncopa> is that even legal?
2023-11-29 20:17:16 <Arnavion> if you opt in to it by setting removeLinuxDRM
2023-11-29 20:17:30 <abby> ncopa: is it even legal to say an API is copyrighted?
2023-11-29 20:17:32 <Arnavion> The original commit that added it had a comment where they acknowledged it was illegal in some jurisdictions
2023-11-29 20:17:50 <Arnavion> Ah yes it's still there   https://github.com/NixOS/nixpkgs/blob/2c01cd06afc2e327343b047e27e172ba488d98f8/nixos/modules/tasks/filesystems/zfs.nix#L346-L347
2023-11-29 20:17:55 <ncopa> right, so its up to end user to build it themselves
2023-11-29 20:17:56 <omni> ncopa: the curious thing is that zfs 2.2.x built for armv7 with linux-lts but not linux-rpi
2023-11-29 20:19:46 <ncopa> abby: that is an excellent question. IIRC in the the SCO unix case they lost because you cannot copyright an API
2023-11-29 20:20:48 <abby> and also google v oracle
2023-11-29 20:57:53 <ncopa> ok here comes kernel 6.6
2023-11-29 20:58:17 <ikke> nice
2023-11-29 21:20:55 <ncopa> I wonder what you think about serial console enabled by default? apparently it creates problems for ppl https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/135
2023-11-29 21:22:06 <ncopa> im thinking we could maybe enable it by default for qemu at least
2023-11-29 21:22:54 <ncopa> but we need a way to disable that
2023-11-29 21:25:39 <ikke> How would that affect providers that use the serial console for OOB access?
2023-11-29 21:26:02 <ikke> I suppose they would need to make sure it's enabled for the relevant ttys
2023-11-29 21:27:07 <ncopa> before 3.18 they had to set console= boot option
2023-11-29 21:27:58 <ncopa> with 3.18 we started to add the serial console to inittab by default if any was detected, and connected
2023-11-29 21:28:10 <ncopa> which ofc creates problems for users who use it for other things
2023-11-29 21:28:48 <ncopa> i suppose we can enable it and autodetect it if there are no apkovl
2023-11-29 21:29:31 <ncopa> main problem is that it is not possible to disable the autodetection
2023-11-29 23:55:55 <tomleb> Any tricks for debugging kernel panics? My screen doesn't allow me to get enough information when it happens. I've tried to log kernel messages with rsyslog but that doesn't work. I've built a custom kernel with debugging symbols and vmcore but I get stuck not being able to compile the "crash" utility. Is there other ways I could try getting a stacktrace of the crash?
2023-11-29 23:59:12 <tomleb> Hum, just found out about netconsole, will try this out..
2023-11-30 00:08:51 <craftyguy> a few of us running postmarketOS (or using Alpine on desktops) are still hitting a segfault with firefox 120.0 on aarch64: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15512
2023-11-30 00:09:28 <craftyguy> is there anything I can do to help move debug forward? poking around with readelf is not something I'm particularly good at, and it's not clear to me what else we can try / poke at
2023-11-30 00:16:16 <craftyguy> oh is this supposed to help with that (merged 1hr ago lol) https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/56289
2023-11-30 00:54:37 <celie> Does anyone have any comments on !54828, i think it should go into 3.19 as upstream has already moved 4.96.x to old/ on downloads.exim.org
2023-11-30 01:08:36 <celie> craftyguy: If you're still around, have a look at https://build.alpinelinux.org/ , rbutil seems to be failing on ARM
2023-11-30 01:09:32 <craftyguy> hmm, weird, it passed in CI and I can build it on my aarch64 system...
2023-11-30 01:10:32 <celie> I think the issue is quazip-dev, it has both /usr/lib/libquazip1-qt5.so and libquazip1-qt6.so solinks, so the dependency tracer makes it depend on both qt5-qtbase-dev and qt6-qtbase-dev
2023-11-30 01:12:12 <craftyguy> oh, hmm
2023-11-30 01:12:27 <celie> So, you essentially get qt6 as well if you use quazip-dev, maybe there is a way to explicitly disable qt6 in rbutil so it doesn't go looking for it?
2023-11-30 01:12:40 <craftyguy> yeah let me check
2023-11-30 01:13:42 <celie> I think the problem may also be solved by adding qt6-qt5compat-dev to makedepends, but that should enable qt6, which is probably not what you want
2023-11-30 01:14:15 <craftyguy> right, I ran into some problems trying to use qt6 w/ the compat thing
2023-11-30 01:15:58 <craftyguy> I'm not sure how to actually test a possible fix since I can't reproduce that locally
2023-11-30 01:22:23 <craftyguy> it's ugly, but this seems hopeful: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/56296
2023-11-30 01:28:15 <celie> That will probably be good enough as a temporary fix, until we find out why the builder picks up Qt6 while the CI doesn't (it probably has to do with the additional packages the builder has installed)
2023-11-30 01:35:18 <TangentDelta> So...I think I have a better understanding of how U-Boot is structured and how to port it to a new board.
2023-11-30 01:37:21 <TangentDelta> I'm not really sure how to add support for my board though, if I should add it to the "generic" board that it is most similar to, or just make it its own thing.
2023-11-30 01:48:59 <celie> Hmm, now on further thought, i think it's not really the libquazip1-qt6.so solink that causes qt6-qtbase-dev to be added as dependency of quazip-dev, but rather quazip1-qt6.pc. i wonder if maybe quazip-dev needs to be split into qt5 and qt6 variants.
2023-11-30 01:53:33 <craftyguy> omni: thanks for merging that! are the builders able to recover/continue on their own?
2023-11-30 01:54:21 <celie> Yes, the builders are alright now
2023-11-30 01:54:40 <craftyguy> ah ok, great. sorry for breaking stuff :P
2023-11-30 01:55:43 <celie> Not really your fault since it was working fine on the CI :)
2023-11-30 02:00:29 <celie> and that's probably why testing/ is there, because there're still differences between CI and the builders.
2023-11-30 02:10:52 <omni> craftyguy: np, glad your fix was there =)
2023-11-30 02:12:03 <craftyguy> celie: yeah except when broken stuff in testing/ wedges the edge builders
2023-11-30 02:36:59 <celie> I may be wrong, but i think that's what "algitbot: retry master" is for, when you say that algitbot starts all over from main/ to community/ to testing/
2023-11-30 02:37:02 <celie> ...
2023-11-30 02:44:42 <craftyguy> ah
2023-11-30 12:06:22 <omni> https://www.phoronix.com/news/OpenZFS-Data-Corruption-Battle
2023-11-30 12:11:51 <indy> hi all, can i regenerate APKINDEX.tar.gz? i tried 'abuild -F -D "test" -P /packages/test/x86_64/ index' and no APKINDEX generated
2023-11-30 12:14:41 <indy> or exists another way to generate APKINDEX? close to what is used for generating indexes for alpine repositories, as much as possible 
2023-11-30 12:15:16 <ikke> That's done by abuild
2023-11-30 12:50:43 <ptrc> indy: you can just do `apk index ./*.apk -o APKINDEX.tar.gz`
2023-11-30 12:51:13 <ptrc> throw in a `--rewrite-arch=$(apk --print-arch)` as well to handle noarch packages in the same index
2023-11-30 12:51:33 <ptrc> and optionally `-x APKINDEX.tar.gz` if you have an existing index and you're just recreating it
2023-11-30 12:52:14 <ikke> and then abuild-sign as well
2023-11-30 12:55:20 <indy> ikke, ptrc thanks
2023-11-30 12:55:39 <ikke> but abuild index should do the same
2023-11-30 12:58:50 <indy> ptrc, --rewrite-arch is not needed, abuild generated APKINDEX is honoring architecture. i'm just writing reproducer for jfrog, which has problem with noarch packages, because package downloaded from edge/testing and uploaded to jfrog has in jrog's index A:noarch instead of A:x86_64
2023-11-30 13:03:35 <ikke> indy: the problem is that it would not include packages with arch=noarch
2023-11-30 13:17:12 <indy> ptrc, ha, i overlooked that you wrote "apk index" instead of "abuild index" :)
2023-11-30 13:18:44 <indy> ikke, so why in apkbuild is noarch and all binaries are built separately as they have different checksums?
2023-11-30 13:21:07 <indy> ikke, i mean noarch apks are built on each architecture 
2023-11-30 13:34:08 <ikke> indy: because at the moment we have no good way to build these noarch packages only once and have them available for all arches
2023-11-30 13:46:30 <bratkartoffel> the the on a.org for the latest release (and the mail) is wrong, the versions are all one patch too low
2023-11-30 13:46:41 <bratkartoffel> *the news
2023-11-30 13:46:54 <bratkartoffel> text is 3.15.10, should be 3.15.11 and so on
2023-11-30 13:48:39 <ikke> Oh, the body of the post
2023-11-30 13:51:13 <ikke> bratkartoffel: thanks, fixed
2023-11-30 14:08:07 <ncopa> ugh.. thanks!
2023-11-30 14:22:21 <omni> and on the main page
2023-11-30 14:25:39 <ikke> metadata
2023-11-30 14:31:41 <vkrishn> still shows 3.18.3 on https://alpinelinux.org/ (news section)
2023-11-30 14:31:52 <vkrishn> text, url is ok
2023-11-30 14:38:37 <omni> yes
2023-11-30 14:38:46 <omni> 2023-08-07 Alpine 3.15.10, 3.16.7, 3.17.5 and 3.18.3 released
2023-11-30 14:38:47 <omni> 2023-11-30 Alpine 3.15.10, 3.16.7, 3.17.5 and 3.18.3 released
2023-11-30 14:47:35 <ikke> fixed
2023-11-30 14:47:45 <ncopa> im sorry about that
2023-11-30 17:14:38 <indy> ikke, in fedora noarch packages are built using first free builder of any architecture (s390x, ppc64) and put to noarch folder. if package is mixed, noarch subpackages are built same way but only noarch packages are deployed to that folder. and consequently arch based builders deploys only arch dependent packages (noarch excluded)
2023-11-30 17:19:39 <ikke> I don't think that will work with our current build architecture. We don't have build job queue where the builders pick up jobs (and thus can make sure some jobs are only picked up by one builder)
2023-11-30 17:20:02 <ikke> In our case, when a new commit is pushed, all builders get notified and start building
2023-11-30 17:20:51 <ikke> At the end of a build cycle, the builders synchronize their local repos to the master rsync mirror
2023-11-30 17:24:06 <PureTryOut> A job queue sounds kinda nice tbh
2023-11-30 17:24:13 <indy> so there should be also one noarch builder
2023-11-30 17:25:34 <indy> and each builder will put only their arch (in other words, noarch builder will put noarch packages to noarch folder :) )
2023-11-30 17:27:33 <minimal> in a similar fashion Alpine can't build packages containing binaries for a different arch, specifically for EDK II (UEFI implementation) - the Alpine x86_64 package contains OVMF files for use with qemu-system-x86_64 and the aarch64 package contains AAVMF files for use with qemu-system-aarch64, if you want to run a aarch64 VM on a an Alpine x86_64 host via Qemu then you need to obtain the (aarch64) AAVMF files either from Alpine's aarch64 
2023-11-30 17:27:33 <minimal> package and extract them, or obtain them elsewhere; there is no package for Alpine x86_64 that contains these aarch64 files
2023-11-30 17:27:56 <indy> job notifier will evaluate all/noarch in APKBUILD, or builder itself and ends at start if package is noarch
2023-11-30 17:28:24 <indy> i see
2023-11-30 17:29:37 <indy> in fedora for that are cross-compilers packaged
2023-11-30 17:31:00 <indy> so you have noarch bootloader binaries (from edk ii / u-boot / etc) cross built on any architecture
2023-11-30 17:31:45 <indy> i think debian have similar solution
2023-11-30 17:31:47 <minimal> indy: EDK II isn't a bootloader - its the "firmware" that loads a bootloader
2023-11-30 17:32:13 <minimal> it's a (really "the") UEFI implementation
2023-11-30 17:35:06 <minimal> for Debian there is a qemu-efi-aarch64 package available on x86_64 systems that installs the AAVMF files needed to run UEFI-based aarch64 VMs
2023-11-30 17:35:35 <indy> i know
2023-11-30 17:36:04 <indy> and you have in deps cross-builders
2023-11-30 17:37:16 <indy> to build them
2023-11-30 17:38:02 <ikke> We don't have generic cross compilers
2023-11-30 17:39:32 <minimal> ikke: apart from EDK II I can't think of any other need/wish for Alpine cross-arch installable packages
2023-11-30 18:00:56 <omni> there are more xen-things that could be moved into a xen-openrc subpackage than just what was split into the xen-qemu-openrc one, right
2023-11-30 23:57:07 <omni> ikke: I didn't get who you were supposed to assign MRs to users not available in the drop-down