2023-12-01 01:31:33 <celie> omni: I think he meant you could do it directly with /assign if you knew their usernames
2023-12-01 01:49:09 <omni> celie: I think that's what he said, but I didn't get where and how to use "/assign"
2023-12-01 01:49:47 <omni> also, s/who/how/ above
2023-12-01 01:54:17 <ayakael0> omni: Thanks for merging my py3 omnibus MR :)
2023-12-01 01:55:04 <ayakael0> omni: If I should want to get these packages into community, should I do so one at time? At the same time I'll make sure they all use the same build system.
2023-12-01 02:02:15 <omni> ayakael0: I think if it's just "move a bunch of aports that I maintain from testing", with minor to no changes other than the move, then it's fine to lump them together in the same MR
2023-12-01 02:03:29 <ayakael0> omni: awesome! I'll move the majority that are compliant right now.
2023-12-01 02:04:04 <omni> but other changes, like upgrades etc, should probably be split up to be more easily reviewed
2023-12-01 02:04:34 <ayakael0> Absolutely, will do for future releases 
2023-12-01 02:04:38 <omni> so I guess that one was a bit of an exception, but they were all your aports and also in testing
2023-12-01 02:06:08 <omni> if changes are related, like dependencies that need to be rebuilt or things that ned to be upgraded together, then it's preferred that they go into the same MR
2023-12-01 02:08:48 <ayakael0> I see, makes sense!
2023-12-01 02:12:35 <omni> not least to see that everything build as intended through the CI pipelines
2023-12-01 02:16:14 <ayakael0> What's the standard for python package names? Intuitively, those who use '_' character should become '-', but then there's py3-setuptools_scim. Do y'all name the package exactly as it is in pypi?
2023-12-01 02:19:36 <ayakael0> And then there's django related libraries that aren't named django-something (like channels , as it is on pypi, which intuitively I'd name py3-django-channels)
2023-12-01 02:26:02 <celie> omni: Sorry for the late reply, you're looking for Gitlab quick actions: https://docs.gitlab.com/ee/user/project/quick_actions.html
2023-12-01 02:27:56 <celie> ayakael0: You'll have to move all the dependencies of your aports to community as well (and will have to ask their maintainers about whether they're alright with that move)
2023-12-01 02:32:39 <celie> I noticed that your py3-django-drf-spectacular depends upon my py3-django-oauth-toolkit, and i've taken care of that in !56082 (also asked prspkt for permission to move py3-jwcrypto, which is a dependency of both py3-django-drf-spectacular and py3-django-oauth-toolkit)
2023-12-01 02:34:32 <ayakael0> Good point, thanks for sharing that. Also, should py3-django-drf-spectacular omit django? In pypi it's simply drf-spectacular.
2023-12-01 02:36:37 <celie> omni: Perhaps you might want to ping staceee here regarding splitter, from https://git.sr.ht/~stacyharper/splitter/log i see there are 2 commits after 0.1.0, perhaps they will fix the build errors
2023-12-01 02:39:45 <celie> ayakael0: I think that's up to you, it's probably alright to follow the pypi name, but if there are any aports that depend upon the old name, you'll have to add a "replaces" to your APKBUILD (and maybe a "provides" too)
2023-12-01 02:45:27 <celie> Hmm, reading https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#replaces again, it seems "replaces" will be needed regardless of whether there are any aports that depend upon the old name
2023-12-01 02:46:44 <celie> So, the old name thing would need to be solved by either renaming it to the new name (easy to do if all aports involved are maintained by you), or adding a versioned provides
2023-12-01 02:53:17 <ayakael0> Gotcha, most of these got merged in september, I doubt any of them are depended on, will check to make sure before renames. But yeah, I'll match pypi, it'll avoid any risk of having duplicate aports
2023-12-01 02:54:06 <omni> celie: ah
2023-12-01 02:54:19 <omni> staceee: sorry about splitter, I disabled the aport for now
2023-12-01 03:02:15 <celie> ayakael0: It seems you have hit the first case of a "provided" aport, py3-celery is provided by testing/celery, and it has no maintainer, so perhaps you'll want to adopt it first before moving it to community together with your aports that depend upon it
2023-12-01 03:04:24 <ayakael0> celie: Indeed, I've dropped the complicated aports just now, and will adopt it.
2023-12-01 03:15:10 <celie> By the way, not saying you should make this change now (could be later on as no pkgrel bump is needed, could be never, i personally think it's ok), but i think there's a reason Maintainer is below Contributor (and there is no new line between those 2 lines and pkgname), it's been mentioned briefly before
2023-12-01 03:16:36 <celie> From what i understand, it has to do with the 3 line context git diff shows, whenever pkgver is updated, the 3 line context will also include the Maintainer line, so it's easier to see who the maintainer is
2023-12-01 05:01:30 <celie> omni: I have also wondered why rtx MRs are never re-used, it probably has something to do with the maintainer using the version as part of the source branch name
2023-12-01 05:19:26 <omni> yeah, something
2023-12-01 05:34:29 <ayakael0> Okay, thanks for bearing with me, all of the community move MRs are done. I see the following changes that I propose doing all at once after merging due to affecting all of my python packages: (1) remove _pyname mentions in sources; (2) replace dist with .dist; (3) remove py3-installer due to being pulled in by py3-gpep517. It'll be a few simple
2023-12-01 05:34:30 <ayakael0> grep statements that'll avoid the whole git branch labour.
2023-12-01 05:35:16 <ayakael0> omni: just took note of your comment, that works!
2023-12-01 05:37:38 <omni> and Maintainer below Contributor lines, with no separating newline, does make it easier to quickly spot the maintainer, as celie said
2023-12-01 05:37:59 <omni> but that could perhaps be done when fixing the source urls too
2023-12-01 05:41:46 <ayakael0> Seeing as though it affects all of my packages (for the longest while I though Maintainer was first), indeed better to do that in one go as above.
2023-12-01 05:43:10 <ayakael0> thought*
2023-12-01 05:45:36 <omni> and also no $_pyname in url= line
2023-12-01 05:46:24 <ayakael0> Noted
2023-12-01 07:25:01 <staceee> celie, omni: yap exactly. The last bump of hare might broke it. I'll double check and flag a minor to fix this
2023-12-01 07:26:06 <staceee> This is still very common with hare libraries and programs. I'm impatient we stabilise the api
2023-12-01 07:37:00 <ajhalili2006> working on packaging hadolint behind the scenes on my personal packaging recipes repo rn, may submit my patch soon
2023-12-01 08:00:43 <celie> ayakael0: I think you've accidentally removed a space separating the sha512sum from the filename for py3-goodreads in !56413
2023-12-01 08:03:54 <ayakael0> I messed a few things up on there haha. Should be ready for review now
2023-12-01 08:08:14 <ajhalili2006> ayakael0: currently looking into the patch right more, might take a bit longer due to amount to changes
2023-12-01 08:09:28 <celie> If trying to follow pypi so closely (using _pyname in pkgname) results in name changes, perhaps you shouldn't do that
2023-12-01 08:10:26 <celie> If you want _pyname in the APKBUILD, it's fine (apkbuild-cpan also uses _pkgreal), but don't substitute it into pkgname
2023-12-01 08:10:41 <ayakael0> Usually it's correct, but then you've got edge cases like djangorestframework-guardian that is actually django-rest-framework-guardian.
2023-12-01 08:11:11 <ayakael0> Oh I see re: pkgname substitution
2023-12-01 08:11:27 <celie> I think i've seen _ changed to - between different versions
2023-12-01 08:12:59 <ayakael0> Yeah, those were most of the name changes, because upstream they used _ while on pypi it's -
2023-12-01 08:13:22 <celie> So, if you want a consistent naming scheme, probably you should just choose between _ and - and fix pkgname at that
2023-12-01 08:13:58 <ayakael0> Yeah, that's the smart thing to do.
2023-12-01 08:16:27 <celie> If you want _pyname to remain to make it easier to look up the package on pypi, that's fine, but following the pypi name changes, that's probably not.
2023-12-01 08:17:26 <ayakael0> I'm gonna push a new commit in a few moments to decouple pkgname
2023-12-01 08:23:07 <ayakael0> I've also apparently missed a few packages
2023-12-01 08:35:27 <ayakael0> Pushed and CI is green.
2023-12-01 09:53:36 <ajhalili2006> Can anyone have a quick review of my APKBUILD for hadolint for any issues: https://mau.dev/andreijiroh.dev/devops-tools/ppa/-/blob/937609796a61e054329062fbd3399b3b6d0c9c1a/alpine/testing/hadolint/APKBUILD
2023-12-01 09:54:31 <ajhalili2006> I tried build it locally but experiencing errors related to dependency-related conflicts (build log: https://paste.sr.ht/~ajhalili2006/e1bbb21168e73d25426489d2d6e1438316922b61)
2023-12-01 11:06:14 <papiris[m]> Seems like it tries pulling a local, old version of spdx? 
2023-12-01 11:06:14 <papiris[m]> Could you try building using 'abuild  rootbld'?
2023-12-01 11:06:56 <papiris[m]> Disclaimer: pretty new to alpine-dev
2023-12-01 12:42:39 <indy> ptrc, ikke: follow-up from yesterday - i uploaded noarch apks to "test/3.18/noarch" path in jfrog and they got indexed, removed also noarch apks from "test/3.18/x86_64". run apk update and apk add worked
2023-12-01 12:42:49 <singham> librepcb crashes on start in RPI3
2023-12-01 12:43:01 <indy> so it looks like apk itself is ready for noarch
2023-12-01 12:43:02 <singham> It is a faulty package
2023-12-01 12:43:39 <indy> except complaints about missing APKINDEX.tar.gz in x86_64
2023-12-01 12:43:52 <singham> aah nvm
2023-12-01 12:44:04 <singham> I'm on void, not alpine
2023-12-01 12:49:09 <vkrishn> is noarch being planned ? if that works it can save disk space on CDNs
2023-12-01 12:54:12 <ncopa> vkrishn: we thought about that years ago. but its sort of complicated as the different arch builders needs to coordinate. all of them does not need to build noarch, so which buildr should do that?
2023-12-01 12:54:29 <ncopa> then the other may need to wait on that builder before they can start, in case there are noarch deps
2023-12-01 12:54:49 <ncopa> the whole thing becomes a lot more complex
2023-12-01 12:58:27 <vkrishn> or, possible solution, all builders can skip noarch build except the lead builder
2023-12-01 12:59:08 <vkrishn> in which case a lead builder needs to run a bit ahead and rest follow or stop when needed
2023-12-01 12:59:29 <vkrishn> still complex ;)
2023-12-01 13:00:03 <vkrishn> i mean, but still bit complex
2023-12-01 13:02:33 <vkrishn> lead builder puts mqtt msg when it builds pkg of noarch
2023-12-01 13:03:25 <ikke> We want more decentralization, not more centralization
2023-12-01 13:04:20 <vkrishn> yes, true, lead builder can become 'point of failure/delay' for all
2023-12-01 13:08:37 <minimal> ncopa: I think *some* of the removed Hashicorp packages (like envconsul, consul-template, conul-replicate, terraform-ls) did *not* change license
2023-12-01 13:10:44 <ncopa> minimal: can you find out exactly which, and create an issue?
2023-12-01 13:13:51 <minimal> ok
2023-12-01 13:15:37 <minimal> also notice that consul packages still appear on pkgs.alpinelinux.org for Edge
2023-12-01 13:26:52 <celie> It seems consul's APKBUILD wasn't removed in the "drop HashiCorp" commit
2023-12-01 13:27:26 <celie> https://git.alpinelinux.org/aports/tree/community/consul
2023-12-01 13:29:47 <minimal> ncopa: #15531
2023-12-01 13:31:19 <minimal> ncopa: BTW did you notice that the mkinitfs check had to be disabled yesterday as the tests were failing?
2023-12-01 13:47:24 <ncopa> minimal: nope. i didnt notice that
2023-12-01 13:48:04 <ncopa> where were they failing? on which arch?
2023-12-01 13:48:10 <minimal> all archs AFAIK
2023-12-01 13:48:29 <minimal> #15524
2023-12-01 13:53:06 <omni> oh, consul wasn't removed?
2023-12-01 13:53:10 <omni> my bad
2023-12-01 13:53:21 <omni> I'll open an MR for it
2023-12-01 13:53:54 <omni> we also reasoned why they should be removed even though some where still at the acceptable license
2023-12-01 13:54:23 <minimal> omni: what was the reason for that?
2023-12-01 14:03:05 <vkrishn> hmm, another possible solution, have all builder build noarch, but only one uploads, rest upload them locally with corresponding local entry in /etc/repositories
2023-12-01 14:03:17 <minimal> omni: I referring to Hashicorp software where there appears to be NO intention by them to relicense, not to software that hasn't yet had a release under the new license
2023-12-01 14:03:17 <vkrishn> this also means having to cache those noarch pkgs on builders, still a bit mess
2023-12-01 14:03:55 <omni> minimal: it's all in !52139 and #15193 but the main reason is that, even if we stayed at versions with acceptable license, upstream bug and security fixes would be under an unacceptable license and not usable by us
2023-12-01 14:04:29 <omni> ok, I really thought they were relicensing it all
2023-12-01 14:04:45 <omni> and I think most of us did
2023-12-01 14:05:10 <omni> but if they wont for some software, that's great news
2023-12-01 14:05:17 <minimal> omni: no, that's the point, if the master branch in any of their repos does not have an updated/changed license file then that was not relicensed
2023-12-01 14:05:50 <minimal> check the MR I raised, #15531
2023-12-01 14:06:09 <minimal> these all still have MPL in their master repo
2023-12-01 14:06:41 <ncopa> minimal: thanks! im fixing the tests
2023-12-01 14:06:56 <minimal> they appear to have only relicensed "primary" software (consul, nomad, packer, terraform, vagrant), not "secondary" software/tools
2023-12-01 14:11:00 <omni> oh, now I'm with you, they did relicense all of their primary software, I guess the others were considered unusable without the "primaries"
2023-12-01 14:11:15 <omni> and I properly read your issue with the list of those software
2023-12-01 14:11:17 <omni> sorry about that
2023-12-01 14:11:46 <ncopa> no, i think we just didnt pay attention
2023-12-01 14:11:54 <omni> minimal: do you have an MR for this or should I create one?
2023-12-01 14:12:05 <omni> to re-instate those unproblematic aports
2023-12-01 14:12:06 <minimal> no MR, just that Issue
2023-12-01 14:12:29 <omni> I'll do it, as I feel a bit guilty for this
2023-12-01 14:13:57 <ncopa> thanks omni! appreciated
2023-12-01 14:15:06 <ncopa> did community/rakudo-star-2023.11-r0 hang on the armhf builder?
2023-12-01 14:15:15 <ncopa> i'd like to tag -rc2 soonish
2023-12-01 14:29:10 <minimal> ncopa: *might* be at least 1 issue with current kernel config, not 100% sure yet
2023-12-01 14:29:32 <ncopa> ok! let me know how it goes
2023-12-01 14:30:09 <minimal> doing some testing and booting via x86_64 UEFISTUB isn't currently working for me
2023-12-01 14:30:48 <ncopa> intereseting i think I boot my machine with UEFISTUB
2023-12-01 14:31:10 <minimal> with UEFI variables for config?
2023-12-01 14:31:33 <minimal> I'm not using EFI variables (as it's a VM), using startup.nsh file
2023-12-01 14:33:01 <omni> !56432
2023-12-01 14:33:47 <ncopa> yes with UEFI variables
2023-12-01 14:34:16 <ncopa> how does that startup.nsh work? do you have any docs/refs about it?
2023-12-01 14:34:36 <minimal> it'll be documented in the UEFI specs
2023-12-01 14:35:00 <minimal> it is read if present and it's a text file where I put the cmdline args
2023-12-01 14:35:05 <minimal> it is read by the EFI Shell
2023-12-01 14:35:23 <minimal> when it can't find EFI variables
2023-12-01 14:37:07 <ncopa> i thikn I saw it in the UEFI spec but the spec is ... heavy t read
2023-12-01 14:39:05 <minimal> well I just create it in /boot/esp/ with contents like: "vmlinuz-virt initrd=initramfs-virt rootfstype=ext4 console=tty0 tiny_power_butto
2023-12-01 14:39:05 <minimal> n.power_signal=12 consoleblank=0 root=UUID=00000000-0000-0000-0000-000000000000"
2023-12-01 14:39:33 <minimal> and kernel and initramfs are also in same directory
2023-12-01 14:39:47 <minimal> and it boots without needing any EFI variables
2023-12-01 14:40:20 <minimal> anyway that doesn't release to the currently issue I'm seeing, need to investigate more (UKI booting is fine)
2023-12-01 14:40:37 <minimal> which means that gummiboot is fine
2023-12-01 14:42:13 <minimal> s/release/relate/
2023-12-01 14:43:58 <minimal> for startup.nsh the format is basically a single line of form: "<name of file to load> <options to pass to the loaded file>"
2023-12-01 14:44:16 <minimal> where the file to loaded is the kernel which is a valid EFI file
2023-12-01 14:58:02 <minimal> ncopa: I'm starting to suspect my problem is due to kernel functionality removed between 6.1.x and 6.6.x :-( The setting CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER no longer exists
2023-12-01 14:58:59 <ncopa> oh, why was that removed?
2023-12-01 14:59:30 <minimal> no idea, that setting is marked deprecated in 6.1.x kernel, obviously then later removed
2023-12-01 14:59:55 <minimal> "Select this config option to add support for the initrd= command line parameter"
2023-12-01 15:00:52 <minimal> so in the startup.nsh I specify a EFI file to run (kernel) and then "initrd=initramfs-virt" so now with 6.6.x once the kernel loads it ignored the "initrd=" reference to the initramfs filename
2023-12-01 15:02:34 <ncopa> https://gitlab.com/linux-kernel/stable/-/commit/cf6b83664895a5c7e97710df282e220bd047f0f5
2023-12-01 15:02:51 <minimal> I might have spotted this issue some time ago if Alpine had a non-LTS kernel package that tracked linux-lts/linux-virt's config (linux-edge is no use as its config is completely different to linux-lts)
2023-12-01 15:06:40 <minimal> hmm, I'll have to see if there's another way around this. I'll have to tell jirutka that this also breaks one of his scripts
2023-12-01 15:06:50 <ncopa> yeah
2023-12-01 15:08:07 <minimal> separately I haven't raised an issue that UKI booting is broken for aarch64 as it has already been broken in Edge for some time (due to a binutils-related change). I've burned quite a bit of time over the past month trying to get it working
2023-12-01 15:09:45 <minimal> ncopa: the reason for using startup.nsh is that for some hypervisors it is a not possible to import EFI variables when importing a disk image
2023-12-01 15:10:53 <ncopa> you may want report that to upstream kernel
2023-12-01 15:11:53 <ncopa> I would even call it a bug. its not working as documented: https://docs.kernel.org/admin-guide/efi-stub.html#the-initrd-option
2023-12-01 15:12:22 <minimal> I'll not bother, the last time I questioned a change I got an auto email back from the particular maintainer (who made a change) that it was rude to email him directly rather than that raising it directly on the kernel lisrt
2023-12-01 15:13:19 <ncopa> i kinda understand that. I prefer that users ask the alpine mailing list than ask me directly
2023-12-01 15:14:20 <minimal> I understand also but still the way the auto-email was worded came off somewhat rude to me
2023-12-01 15:15:09 <minimal> that was regarding the removal of MICROCODE disabling setting - it makes no sense for microcode loading to be enabled for VMs but that switch was removed (in 6.5? 6.6?)
2023-12-01 15:27:07 <ncopa> maybe send an email the the kernel mailing list
2023-12-01 15:27:30 <ncopa> according the docs it is supposed to work: https://docs.kernel.org/admin-guide/efi-stub.html#the-initrd-option
2023-12-01 15:29:24 <ncopa> hi khem! have you heard/seen anything about the CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER removal? apparently they removed that option and it breaks booting for users that load kernel via startup.nsh https://docs.kernel.org/admin-guide/efi-stub.html#the-initrd-option
2023-12-01 15:37:43 <ncopa> minimal: 75e1a2460d79566bf1e43e5a3a7a9039510a82e0
2023-12-01 15:38:48 <ncopa> and e346bebbd36b1576a3335331fed61bb48c6d8823
2023-12-01 15:39:36 <ncopa> minimal: they did not remove it. they un-deprecated it and always enabled it (and removed CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER)
2023-12-01 15:45:48 <minimal> ncopa: ok, I misread the code from a quick glance at it. Anyway something has changed with the move to 6.6 for linux-virt kernel as this worked previously. Will have to investigate more over the weekend
2023-12-01 15:46:15 <ncopa> did you try with backslash? inird=\initramfs-virt?
2023-12-01 15:46:34 <minimal> nope, but it worked as-is previously
2023-12-01 15:46:45 <ncopa> let me know how it goes and what you find out
2023-12-01 15:47:32 <minimal> it could be some other kernel settings, have looked at a diff between linux-virt 6.1.62 and 6.6.3 and there's a lot to go through
2023-12-01 15:47:42 <ncopa> yeah
2023-12-01 15:47:52 <ncopa> or a default setting that changed
2023-12-01 15:48:35 <minimal> well I'm diffing /boot/config-* so the end results rather than the Alpine default config changes file
2023-12-01 15:59:56 <ncopa> i think we may need to let mkinitfs trigger look for /lib/modules/*
2023-12-01 16:02:02 <minimal> and booster trigger, and dracut trigger then
2023-12-01 16:03:05 <minimal> what's the issue with using /usr/share/kernel/*/kernel.release?
2023-12-01 16:04:15 <ncopa> the issue is that when we update zfs (or other 3rd party kernel module) the trigger is not run. and that may cause problems if initramfs has old kernel modules
2023-12-01 16:04:48 <omni> for earlier stable-releases, should zfs be patched for dnode_is_dirty or upgraded to 2.1.14?
2023-12-01 16:05:50 <minimal> ncopa: ah right, surely that's been an issue for some time then and not just for zfs? (don't call me Shirley)
2023-12-01 16:07:10 <ncopa> been an issue for some time. just got reminded about it now
2023-12-01 17:08:37 <khem> https://www.irccloud.com/pastebin/jlnH1z9U/
2023-12-01 17:08:54 <khem> enable in defconfig 
2023-12-01 18:08:12 <ncopa> i think we have that
2023-12-01 18:48:46 <mio> what's the process for requesting a rebuild of .apks for a package? the source tarball was temporarily unavailable for some time so all the apks except riscv64 were removed, but the source is available again
2023-12-01 18:50:00 <mio> the version number hasn't changed, would it be easiest to send a MR with a pkgrel bump or ...?
2023-12-01 18:55:46 <ncopa> 3.19.0_rc2 tagged
2023-12-01 18:56:17 <ncopa> the 3.19.0 will be released early next week unless something critical shows up
2023-12-01 19:27:31 <ayakael0> Excellent work!
2023-12-01 19:32:28 <mio> thanks!
2023-12-01 19:47:03 <mio> (question resolved, sent an MR)
2023-12-01 22:38:29 <mio> ptrc: does tic-80 need to be rebuilt with each upgrade of janet, or only major point versions?
2023-12-01 22:39:48 <mio> confirming based on this comment https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51805#note_341992
2023-12-01 22:42:34 <mio> currently janet is 1.32.1, last update tic-80 was built with 1.32.0
2023-12-01 23:16:33 <ajhalili2006> I'm a bit struggling with rootbld with "read-only file system" when attempting to mkdir parents
2023-12-02 00:15:59 <celie> mio: The soname is libjanet.so.1.32, so i would say only major versions
2023-12-02 00:20:10 <celie> Unless tic-80 fails to start due to some runtime version check (i think that's what happened with mupdf, which resulted in encoding the full version in its soname)
2023-12-02 00:25:06 <mio> celie: great, thanks
2023-12-02 00:25:33 <celie> You're welcome
2023-12-02 00:27:50 <celie> konimarti: For !56431, i don't think aports accepts precompiled binaries. As far as i can remember, we've always been told to build things from source.
2023-12-02 00:55:38 <celie> mio: i think you'll have to add an `install="bsd-games.post-install"` line to !56452
2023-12-02 01:16:54 <mio> celie: thanks, fixed. should have known something didn't look quite right ^^"
2023-12-02 01:19:00 <mio> not really sure a post-install notice is the best way, but at least the user is informed
2023-12-02 02:33:38 <hyphae> Hi! How do I adopt a package without a maintainer? The package is lxappearance - it's something I use relatively often, but it's currently stuck in testing without a maintainer.
2023-12-02 02:34:17 <hyphae> I'm more than willing to maintain it, especially seeing as it hasn't had a major release in six years
2023-12-02 02:43:02 <celie> hyphae: Just open a merge request changing the Maintainer line to your contact details, and bumping pkgrel forward by 1
2023-12-02 02:44:03 <celie> Unless it's also an upgrade (changes pkgver), then it doesn't matter, and pkgrel can be reset to 0
2023-12-02 02:44:36 <celie> Oh, ok, no major release, so probably not an upgrade
2023-12-02 02:45:08 <hyphae> Where do I open that merge request? Is it somewhere on GitLab?
2023-12-02 02:45:54 <celie> Yes
2023-12-02 02:46:07 <omni> https://gitlab.alpinelinux.org/omni/aports/-/blob/master/README.md
2023-12-02 02:46:19 <omni> uhm
2023-12-02 02:46:53 <omni> I meant https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/README.md
2023-12-02 02:46:58 <omni> hyphae: ^^
2023-12-02 02:47:13 <hyphae> omni: no worries, thanks for the help
2023-12-02 02:48:02 <hyphae> what would need to be done to get it into community?
2023-12-02 02:56:00 <celie> Make sure it roughly follows what is outlined under the community section in README.md, then just open another merge request for that
2023-12-02 14:20:11 <ncopa> sweet! alpine 3.19.0 rc2 runs find on raspberry pi 5.
2023-12-02 14:20:15 <ncopa> *fine
2023-12-02 14:23:04 <ncopa> we need figure out which issues we need to fix before the final release, and we need to write release notes
2023-12-02 15:01:15 <omni> alpine-ipxe on x86_64?
2023-12-02 15:58:45 <z3ntu1> Could I get some feedback on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/56210 ?
2023-12-03 14:57:45 <singham> Folks, has riscv32 arrived in gcc mainstream compiler?
2023-12-03 14:58:14 <singham> It was quite a lot of pain to get premade binaries etc from xpack and stuff
2023-12-03 14:58:27 <singham> Now, it's been quite some time since then
2023-12-03 15:05:31 <ichernev[m]> hey guys, according to this page https://pkgs.alpinelinux.org/packages?name=py3-dt-schema&branch=edge&repo=&arch=&maintainer= the package I'm maintaining (py3-dt-schema) is not built for riscv64 (latest version). Is there a reason for that?
2023-12-03 15:18:17 <ikke> The builder is behind 
2023-12-03 15:41:52 <singham> 
ACTION was afk

2023-12-03 16:19:09 <Kladky> So if you maintain a package in community, do you update it to feature releases or just bug-fix releases?
2023-12-03 16:19:59 <ikke> Primarily bug fix releases 
2023-12-03 16:21:31 <Kladky> Good to know
2023-12-03 16:37:51 <fluix> *for packages in stable branches. on edge, you should update everything
2023-12-03 17:33:22 <liske> can we get !53148 merged for 3.19? it already was on automatic merge but got interrupted :-(
2023-12-03 18:49:13 <ikke> liske: merged
2023-12-03 18:51:49 <liske> ikke: thanks!
2023-12-04 10:20:45 <omni> is anyone interested in keeping this wayland on-screen keyboard? !56546
2023-12-04 20:53:29 <omni> https://www.djangoproject.com/weblog/2023/dec/04/django-50-released/
2023-12-04 20:57:07 <bl4ckb0ne> i had a talk in #wayfire about that recently, i think only the maintainer uses it
2023-12-04 20:57:16 <bl4ckb0ne> no objection to get rid of it
2023-12-04 21:18:55 <ncopa> drats, the mkinitfs trigger is way more complicated than I anticipated
2023-12-04 21:21:57 <ikke> algitbot is so considerate
2023-12-04 22:23:55 <omni> do we have a Year 2038 issue on 32b with rust or is it some crate? !56650
2023-12-04 22:47:47 <Arnavion> Rust itself. Its libc crate binds to old musl which has 32-bit time_t
2023-12-04 22:52:01 <Arnavion> so its libstd will also be affected
2023-12-04 22:53:13 <Arnavion> https://github.com/rust-lang/libc/issues/1848   and   https://github.com/rust-lang/libc/pull/3068
2023-12-04 23:29:08 <ncopa> ok, i hope I have fixed the mkinitfs trigger now....
2023-12-04 23:29:59 <dari> so no more error exit after upgrading linux kernel which doesnt exist? :P
2023-12-04 23:30:53 <dari> I just upgraded 3.18 to 3.19 and got same like that guy before, mkinitfs trigger wanted do something with lib modules of kernel which was already removed during apk -a upgrade
2023-12-05 00:25:44 <omni> Arnavion: thanks!
2023-12-05 00:35:23 <celie> omni: Since you've asked me about running Synapse tests before in !53975, what do you think about !56253?
2023-12-05 00:37:55 <celie> I think both the maintainer of synapse and py3-jsonschema417 are aware and okay with the changes i'm proposing there
2023-12-05 00:51:27 <omni> celie: they did not reply to !55950 that you said should probably be merged first
2023-12-05 00:52:02 <omni> btw, why is py3-setuptools a dependency and not a makedependency?
2023-12-05 01:01:45 <celie> because as ptrcnull mentioned in the MR description, there is a pkg_resources import, and pkg_resources is provided by py3-setuptools
2023-12-05 01:03:05 <celie> Anyway, tests and setuptools are probably separate issues, and i mentioned that it probably should be merged first only to avoid merge conflicts
2023-12-05 01:06:26 <celie> It would be a shame if we have to maintain synapse for a stable release without having tests enabled (they are enabled, at least for x86*, in Alpine 3.18), but i think i've done my part, now trying tests out in !56620 with the new py3-jsonschema 4.20 that was merged yesterday
2023-12-05 01:06:39 <celie> Oops, wrong MR, !55620
2023-12-05 01:07:40 <celie> Seems like it's the same thing as jsonschema 4.19, fails on x86*, and takes longer to complete on the other archs
2023-12-05 01:07:57 <omni> ah, right, but maybe I'm not the right person to decide to merge it then... ;)
2023-12-05 01:08:12 <omni> I'll add 3.19 label to it
2023-12-05 01:08:18 <celie> Thanks
2023-12-05 07:00:05 <ncopa> good morning! here comes -rc3
2023-12-05 08:09:14 <omni> morning!
2023-12-05 08:09:33 <omni> !56674 how about https://github.com/microsoft/cpprestsdk/blob/master/ThirdPartyNotices.txt ?
2023-12-05 08:10:12 <omni> and since there is no -doc subpackage, should the license file(s) go into the main package or the -dev subpackage?
2023-12-05 12:56:49 <ncopa> grub is being grubby again
2023-12-05 12:57:15 <ncopa> bumped into this: https://lore.kernel.org/all/1889442.tdWV9SEqCh@lichtvoll.de/T/
2023-12-05 13:39:53 <ncopa> do we have any other blockers for 3.19 release?
2023-12-05 13:57:52 <minimal> ncopa: Grub git has a patch relating to this: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=aa7c1322671eef48ba72d3b733da37e63eb37328
2023-12-05 13:59:14 <ncopa> Yeah. I’m adding it + one of the ones before so it applies cleanly
2023-12-05 13:59:58 <ncopa>  also fixing the “disable grub trigger” issue while at it. And fix the fgrep warning
2023-12-05 14:00:49 <minimal> still no sign of a Grub 2.12 release (rc1 was in June/July from memory)
2023-12-05 14:01:39 <bl4ckb0ne> is there a policy on package removal? like a few days to let people speak or whatever
2023-12-05 14:11:26 <ncopa> i dont think we have any formal policy. I'd say use common sense
2023-12-05 14:12:32 <bl4ckb0ne> i guess people can track the MR on gitlab and complain there
2023-12-05 14:12:39 <ncopa> yeah
2023-12-05 14:13:11 <bl4ckb0ne> plus I believe this package has no user, even the maintainer stopped using it
2023-12-05 15:06:20 <ncopa> yay! tests passes! 183 passed, 73 skipped in 636.84s (0:10:36)
2023-12-05 15:40:13 <ncopa> im finding more bugs. when using DISKLABEL=gpt with bios boot
2023-12-05 19:20:38 <quinq> ncopa, /usr/sbin/grub-probe: error: compression algorithm inherit not supported
2023-12-05 19:21:06 <quinq> fgrep: warning: fgrep is obsolescent; using grep -F
2023-12-05 19:21:21 <quinq> Not sure if that's supposed to be already fixed or not (saw you commenting about it)
2023-12-05 19:25:49 <dari> Upgrading grub (2.06-r14 -> 2.06-r17) and didn't see the warning
2023-12-05 19:33:02 <quinq> That's with a zfs /boot
2023-12-05 19:33:32 <quinq> And lz4 compressed initrds
2023-12-05 19:38:06 <ncopa> sounds like grub cannot handle zfs
2023-12-05 19:40:22 <abby> grub requires a very specific feature set
2023-12-05 19:40:54 <abby> thus, the typical recommendation is to make a pool just for /boot with that feature set, then make a pool for / with whatever features you want
2023-12-05 19:41:06 <abby> this is overly complex and fragile
2023-12-05 19:42:55 <abby> there are alternatives, though, like zfsbootmenu, which is just a linux initrd with a little application in it, so it works fine on a single pool with any feature set and can be launched from refind/syslinux/directly </shill>
2023-12-05 19:43:02 <minimal> yeah there's been a lot of changes made to Grub git (aka 2.12 "eventually") over the past 2+ years, I'd guess you'd need that for some of the ZFS "features"
2023-12-05 19:55:07 <quinq> Well, grub handles zfs, maybe not fully
2023-12-05 19:56:46 <minimal> that what I meant, it is likely they've added ZFS features and fixed ZFS bugs in GIT
2023-12-05 19:57:22 <minimal> they just seem to be incapable of making a release.....2.12 rc1 (or rc2?) came out in June/July timeframe
2023-12-05 20:02:02 <quinq> Yeah :/
2023-12-05 20:18:28 <ncopa> quinq: did that use to work? could you please file an issue if you expect grub to be able to handle that?
2023-12-05 20:33:30 <ncopa> minimal: im trying to get grub boot with gpt with bios, but I get this error:
2023-12-05 20:33:33 <ncopa> grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
2023-12-05 20:34:06 <ncopa> this is the partition table: https://tpaste.us/b1jJ
2023-12-05 20:34:23 <ncopa> but I suppose that it is sfdisk that cannot do a hybrid partition
2023-12-05 20:36:58 <minimal> I use parted myself so let me check how sfdisk shows the partitions I have
2023-12-05 20:37:32 <ncopa> i think maybe it is a limitation in sfdisk. i have some vauge memory about that
2023-12-05 20:37:55 <minimal> I don't think this is class as "hybrid", I associate that with having a mixed BIOS/UEFI bootable setup
2023-12-05 20:40:10 <minimal> I don't have the LegacyBIOSBootable attrs set on the partition, indeed no attrs
2023-12-05 20:40:33 <minimal> the "type" value is different
2023-12-05 20:41:11 <minimal> I used parted to do "set 1 bios_grub on"
2023-12-05 20:41:27 <minimal> which then AFAIK sets the "type" value accordingly
2023-12-05 20:44:07 <ncopa> i give that up for now
2023-12-05 20:46:04 <minimal> ncopa: the partition type/GUID needs to be: 21686148-6449-6E6F-744E-656564454649
2023-12-05 20:46:44 <minimal> this is NOT a BIOS boot partition, rather it is a partition for Grub to place code that in a MBR/MSDOS partitioned disk would be stored on sectors after the 1st one
2023-12-05 20:48:16 <minimal> I guess you can use "--part-type" option of sfdisk to set this
2023-12-05 20:51:38 <quinq> ncopa, I haven't rebooted yet :D
2023-12-05 20:51:55 <quinq> Will do that tomorrow see if it broke anything and will report :)
2023-12-05 20:59:52 <ncopa> minimal: thanks!
2023-12-05 21:16:38 <Kladky> It seems inside abuild make seems to run asyncronously (targets will run at the same time). Is there a way to disable this?
2023-12-05 21:17:10 <ncopa> Kladky: set JOBS=1 in your ~/.abuild/abuild.conf
2023-12-05 21:17:34 <ncopa> or run `JOBS=1 abuild ...`
2023-12-05 21:18:00 <ncopa> actually, maybe it is MAKEOPTS=-j1
2023-12-05 21:18:15 <ncopa> or both...
2023-12-05 21:19:16 <Kladky> The package requires tasks be run in order.
2023-12-05 21:19:24 <Kladky> Neither work inside the APKBUILD
2023-12-05 21:19:47 <ncopa> is it make? you can do `make -j1` in APKBUILD
2023-12-05 21:20:14 <ncopa> cmake and ninja builds has somethign corresponding
2023-12-05 21:20:38 <Kladky> Works, thanks!
2023-12-05 21:26:18 <ncopa> minimal: with grub and guid 21686148-6449-6E6F-744E-656564454649, qemu just ends up with  a loop "GRUB loading" and the reboot 
2023-12-05 21:26:25 <ncopa> still missing something i suppose
2023-12-05 21:26:31 <ncopa> but getting closer
2023-12-05 21:27:30 <minimal> does the grub.cfg look ok? (i.e. with "insmod part_gpt" rather than "insmod part_mbr")
2023-12-05 21:29:21 <ncopa> it does. but I dont think it is able to read the grub.cfg. I think it reboots before that
2023-12-05 21:30:33 <ncopa> oh...
2023-12-05 21:30:57 <ncopa> this is not the /boot partition. it is an additional partition
2023-12-05 21:32:43 <minimal> yes, with MBR the initial code is in the 1st (512 byte) sector and the rest of the Grub code is in subsequent sectors, with GPT the code (that used to be in raw disk sectors) goes in the bios_grub partition - it is NOT a filesystem
2023-12-05 21:33:49 <minimal> for my test VM here I just have the bios_grub and root partition (which includes /boot)
2023-12-05 21:49:27 <ncopa> yay! i got it working!
2023-12-05 21:58:58 <ncopa> minimal: thanks alot for helping me not give up!
2023-12-06 00:47:28 <minimal> I have a MR, !56758 that is failing for x86 & x86_64. It contains 2 commits and the failure is that it is building the 2 package in the wrong order and so the efi-mkuki fails due to missing efistub which is a new virtual package added by the gummiboot commit
2023-12-06 00:47:42 <minimal> suggestions how to resolve this?
2023-12-06 06:25:29 <ikke> minimal: left a comment on the MR
2023-12-06 11:19:13 <ncopa> here comes 3.19.0 rc4
2023-12-06 11:44:55 <liske> In edge no package seems to provide /etc/iproute2/rt_protos (or the other ones in this directory) any more. In 3.18 it is provided by iproute2-minimal. Is this intentional?
2023-12-06 11:51:24 <celie> The files in /etc/iproute2 were moved to /usr/lib/iproute2 with iproute2 6.5.0
2023-12-06 11:51:59 <liske> oh ok, missed that
2023-12-06 12:23:04 <donoban> any clue about how to debug this https://gitlab.alpinelinux.org/alpine/aports/-/issues/15506 ?
2023-12-06 12:24:07 <donoban> uhmmm
2023-12-06 12:24:35 <donoban> i found some errors
2023-12-06 12:25:03 <donoban> time="2023-12-06T13:24:16.342954071+01:00" level=error msg="failed to enable controllers ([cpuset cpu io memory hugetlb pids])" error="failed to write subtree controllers [cpuset cpu io memory hugetlb pids] to \"/sys/fs/cgroup/docker/cgroup.subtree_control\": write /sys/fs/cgroup/docker/cgroup.subtree_control: operation not supported"
2023-12-06 12:25:06 <donoban> time="2023-12-06T13:24:16.343183220+01:00" level=warning msg="error from *cgroupsv2.Manager.EventChan" error="failed to add inotify watch for \"/sys/fs/cgroup/docker/c0658731be9a81bdc6639ea5442a3fbf7a11b677208465cc9179360dfcf0e856/memory.events\": no such file or directory"
2023-12-06 13:22:09 <elly> lnl: do you want to take on community/chromium? you are maintaining it more than I am
2023-12-06 14:03:09 <lnl> elly: oh god, sure
2023-12-06 14:20:01 <elly> haha sucker
2023-12-06 14:20:30 <elly> thank you :) I'm happy to provide advice or help landing stuff upstream but I evidently don't have time to do a good job actually maintaining it
2023-12-06 14:33:10 <lnl> funny thing is I actually use firefox
2023-12-06 14:41:51 <vkrishn> or just pretend ur fixing firefox, s,chromium,firefox,g - do all fixing - s,firefox,chromium,s
2023-12-06 15:23:44 <ncopa> i have started on the 3.19 release process https://gitlab.alpinelinux.org/alpine/aports/-/issues/15546
2023-12-06 15:30:30 <ikke> So release notes next
2023-12-06 15:41:46 <ncopa> what do I write about KDE release?
2023-12-06 15:42:25 <ncopa> last tiem we wrote KDE plasma 5.27
2023-12-06 15:42:49 <ncopa> now it says: KDE applications 23.08, KDE frameworks 5.112
2023-12-06 15:43:16 <ncopa> or is this KDE 5 as usual. nothing to see here
2023-12-06 15:46:50 <vkrishn> "Kde framework was updated to v5.112 alongwith its applications"
2023-12-06 15:47:51 <PureTryOut> ncopa: there is no new KDE Plasma major nor minor release, so those are the only interesting things
2023-12-06 15:48:06 <PureTryOut> Next release will have KDE6 which includes Plasma 6 however
2023-12-06 15:48:23 <ncopa> yeah, better wait with mentioning KDE til then
2023-12-06 15:48:31 <PureTryOut> KDE applications has a ton of applications though
2023-12-06 15:48:33 <PureTryOut> What? No
2023-12-06 15:48:37 <PureTryOut> These are interesting to mention
2023-12-06 15:48:38 <PabloCorreaGomez[m]> Not sure if too late, I just wrote a bit for GNOME
2023-12-06 15:48:41 <elly> lnl: wait, why do you maintain chromium then? just for fun?
2023-12-06 15:49:17 <lnl> I also maintain electron so it's almost the same
2023-12-06 15:51:04 <ncopa> what is the difference between kde gear and kde applications?
2023-12-06 16:01:36 <ncopa> https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/68
2023-12-06 16:01:50 <elly> lnl: wow, heroic work
2023-12-06 16:02:18 <ncopa> anything else worth mentioning? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/586267c9a6be9bbdcddb8e250483a7254f257134/posts/Alpine-3.19.0-released.md
2023-12-06 16:07:29 <ncopa> oh, webkit was pushed. I suppose we do the release tomorrow then
2023-12-06 16:07:51 <ikke> :(
2023-12-06 16:25:31 <ncopa> I woudl appreciate comments or "apporoves" for this. https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/68
2023-12-06 16:25:40 <ncopa> this is what will be mentioned in media
2023-12-06 16:31:19 <omni> ncopa: sorry 'bout that!
2023-12-06 16:31:23 <vkrishn_> "Kde framework was updated to v5.112 alongwith its applications"
2023-12-06 16:31:30 <vkrishn_> oops, sorry
2023-12-06 16:32:46 <donoban> ncopa: could you wait a little for found was happening in !15506 ?
2023-12-06 16:32:54 <donoban> ouch sorry #15506
2023-12-06 16:33:46 <ncopa> donoban: any idea whats going on?
2023-12-06 16:34:07 <donoban> I saw someing on 'docker-err.log'
2023-12-06 16:34:38 <donoban> I'm not sure what docker tries to set, if I do it 'echoing >' it seems to work
2023-12-06 16:36:30 <ncopa> does strace give any hints?
2023-12-06 16:36:55 <donoban> uhM, what I should strace? the 'docker' process?
2023-12-06 16:37:12 <elly> btw, lnl (or anyone else who cares) there is a big problem approaching for chromium and electron:
2023-12-06 16:37:14 <ncopa> probably? or containerd? I dont know
2023-12-06 16:37:29 <elly> chromium (and therefore electron) will soon start *requiring* rust to build, and they use rust nightly, not rust stable
2023-12-06 16:37:45 <elly> we will have to either package a recent enough rust nightly, or build rust nightly as part of the build process
2023-12-06 16:38:22 <donoban> it seems that there is no memory.events inside the '/sys/fs/cgroup/docker/1e78318fxxxxx' ->  https://tpaste.us/1XZZ
2023-12-06 16:38:28 <elly> I can start an email thread if that's better than IRC :)
2023-12-06 16:39:55 <donoban> but there is a memory.events on /sys/fs/cgroup/docker
2023-12-06 16:41:42 <donoban> if I try to launch a container with limited memory it fails too
2023-12-06 16:42:35 <ncopa> i wonder if it is a missing kernel feature, an openrc bug or docker bug
2023-12-06 16:43:07 <ncopa> maybe we should file it upstream at docker. they can probably help us figure out whats going on
2023-12-06 16:44:32 <donoban> I could try some older kernels
2023-12-06 16:45:43 <donoban> and enable some docker debging..
2023-12-06 16:52:39 <lnl> elly: it looks like the nightly is just for a bunch of -Zflags?
2023-12-06 16:54:02 <lnl> gentoo is just removing them https://gitlab.com/Matt.Jolly/chromium-patches/-/blob/120/chromium-120-compiler.patch?ref_type=tags#L94
2023-12-06 16:55:32 <elly> lnl: so, most of them can be just removed but I'm concerned that -Zdep-info-omit-d-target is needed for correct dep graphs in ninja
2023-12-06 16:56:03 <donoban> no luck trying different kernels...
2023-12-06 16:57:32 <lnl> anyway, I have a bigger worry for now, something is adding to the build command -D_LIBCPP_ENABLE_HARDENED_MODE=1 and it appears absolutely nowhere
2023-12-06 17:01:15 <elly> lnl: meaning it appears in the .ninja files but you can't find where from?
2023-12-06 17:01:27 <lnl> yes
2023-12-06 17:04:21 <elly> lnl: hm, build/config/compiler/build.gn has some extremely related stuff like _LIBCPP_HARDENING_MODE
2023-12-06 17:06:29 <ncopa> stepping out for a couple of hours. i'll push release if builders are done when im back
2023-12-06 17:06:33 <ncopa> but i doubt
2023-12-06 17:06:41 <lnl> elly: not on my machine, I'm looking at 120.0.6099.62 rn
2023-12-06 17:06:42 <ncopa> otherwise i push early tomorrow morning
2023-12-06 17:06:52 <elly> lnl: ah, I'm looking at trunk
2023-12-06 17:09:31 <elly> lnl: thakis@chromium.org or hans@chromium.org are the right people to email if you can't figure it out
2023-12-06 17:13:25 <donoban> ncopa: I'm asking for help on #docker too many noise on github issues
2023-12-06 17:16:54 <minimal> donoban: "memory.events	A read-only flat-keyed file which exists on non-root cgroups."
2023-12-06 17:17:38 <minimal> from https://www.kernel.org/doc/Documentation/cgroup-v2.txt
2023-12-06 17:17:44 <donoban> uhmm
2023-12-06 17:17:54 <donoban> maybe it's messing non-root with yes-root? :\
2023-12-06 17:19:55 <donoban> minimal: look this -> https://github.com/containerd/containerd/blob/194a1fdd2cde35bc019ef138f30485e27fe0913e/cmd/containerd-shim-runc-v2/task/service.go#L290
2023-12-06 17:21:27 <donoban> I thought that it does somethign different depending on 'RunningInUserNS' but seems that it changes the error level only
2023-12-06 17:26:40 <minimal> ikke: so it's ok to add a "makedepends: gummiboot-efistub" even that that will be only one of the packages providing the virtual package?
2023-12-06 17:26:51 <minimal> s/that that/though that/
2023-12-06 17:27:11 <ikke> You need to select one at build time
2023-12-06 17:27:50 <donoban> well it seems that "/sys/fs/cgroup/cgroup.subtree_control" has "cpuset cpu io memory hugetlb pids" 
2023-12-06 17:28:17 <donoban> but /sys/fs/cgroup/docker/cgroup.subtree_control only has "cpuset cpu pids"
2023-12-06 17:28:27 <donoban> and I get "write error" if try to echo > it
2023-12-06 17:40:59 <HRio> ncopa: should we not mention something about the Hashicorp packages in the release notes?
2023-12-06 17:42:46 <minimal> it's already mentioned
2023-12-06 17:43:50 <HRio> not in this MR https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/68/diffs
2023-12-06 17:44:23 <ikke> HRio: you can mention it in the MR
2023-12-06 17:45:12 <HRio> ikke: done
2023-12-06 17:47:31 <minimal> This had it: https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.19.0
2023-12-06 17:54:46 <HRio> that wiki seems to miss listing the fact that we now have Linux 6.6
2023-12-06 18:22:24 <minimal> ikke: that makedepends doesn't work as the dependant package is only needed and only exists for x86 & x86_64
2023-12-06 18:22:38 <ikke> minimal: then you do the same as you do for the depends
2023-12-06 18:26:25 <minimal> ikke: doh! of course...
2023-12-06 18:55:13 <craftyguy> PureTryOut: nitropy seems to be broken now for me on edge, do you also see this? https://bpa.st/A5AA
2023-12-06 18:55:32 <PureTryOut> I had not, thanks for the notify will look into it right now
2023-12-06 18:56:21 <craftyguy> np, thanks!
2023-12-06 19:44:34 <PureTryOut> craftyguy: I just pushed a fix, give the builders a bit to build it and then update your system 😉
2023-12-06 20:13:59 <craftyguy> PureTryOut: nice, thanks!!
2023-12-06 20:15:24 <craftyguy> fyi this seems to have gotten lost, any chance it could get reviewed/merged in time for 3.19? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/56440
2023-12-06 20:18:47 <craftyguy> PureTryOut: fyi fix works great :)
2023-12-06 20:19:03 <PureTryOut> Awesome 👍️
2023-12-06 20:43:26 <donoban> uhm... despite it shows 'memory' as controller available, it produces an error when I try to enable it https://tpaste.us/pa8E
2023-12-06 20:46:46 <bratkartoffel> I think I found a solution to get OpenJDK17 again for ppc64le, although I'm not sure if I'm doing something i should not do... I have to install openjdk17 from v3.16, any other "clean" way to do so? !56811
2023-12-06 22:38:59 <ptrc> hm
2023-12-06 22:39:02 <ptrc> i seem to be losing my mind
2023-12-06 22:39:15 <ptrc> why doesn't py3-importlib-resources exist in any index?
2023-12-06 22:39:30 <ptrc> it is in community, with arch=noarch
2023-12-06 22:43:53 <omni> that is odd
2023-12-06 22:45:30 <pj> did it build?
2023-12-06 22:46:51 <ptrc> oh, it was added literally today
2023-12-06 22:47:24 <pj> it did build https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/py3-importlib-resources/py3-importlib-resources-6.1.1-r0.log
2023-12-06 22:47:42 <ptrc> guess it's gonna be available in a sec
2023-12-06 22:48:50 <pj> hmm, alpine-commits wasn't bridged to matrix?
2023-12-06 22:51:11 <pj> nvmd, I was kicked apparently
2023-12-07 00:55:16 <minimal> donoban: have you tried echo "+memory" >> cgroup.subtree_control? (">>" rather than ">")
2023-12-07 00:59:49 <Hello71> from the rest of the document, presumably "non-root" means "not the initial cgroup created at boot", not "not owned by uid 1"
2023-12-07 02:34:01 <celie> omni (or any other developer): Could you have a look at !56372 please? it's been 10 days, and i don't think i'll be receiving a reply from @vaka
2023-12-07 02:37:30 <celie> and last on my wishlist for 3.19: !56818
2023-12-07 02:38:00 <celie> Running tests in parallel makes the build complete much faster :)
2023-12-07 02:42:22 <EvTheFuture> PureTry: regarding #15547 I looked into this a while ago but was not able to figure out what was going on. Any ideas on how to fix this problem?
2023-12-07 02:42:27 <celie> Though there is a missing file (tests/errorcodes.pl) in curl 8.5.0, and from Github, i see the release notes for 8.5.1 have been committed, but it hasn't been tagged (not sure what they're waiting for, perhaps they want to rename that file as there is already a tests/error-codes.pl in the tarball)
2023-12-07 02:45:33 <celie> Anyway, we probably shouldn't wait for curl 8.5.1 as the security fix is more important, so i have added errorcodes.pl to source and moved it into tests/ in prepare()
2023-12-07 03:04:50 <celie> Hmm, looking through the curl commit history, i see that a version bump in release notes may not indicate that the new version will be released soon
2023-12-07 08:55:07 <omni> I tagged !56809 3.19 so that, if we move it now, we aren't expected to maintain it for two years after release
2023-12-07 08:55:38 <donoban> Hello71: I get same error, I built a kernel with CONFIG_CGROUP_DEBUG enabled, hopefully there is something useful on dmesg
2023-12-07 08:58:49 <omni> when merging !54530 sometime after 3.19 is released, I think the commit message should be adjusted and, maybe also, bumped it to a later point release
2023-12-07 09:00:18 <ikke> omni: ncopa already indicated it has little advantage to upgrade it for 3.19
2023-12-07 09:01:26 <ncopa> and it is risky
2023-12-07 09:02:40 <omni> sure, that's why I added "sometime after 3.19 is released"
2023-12-07 09:04:36 <omni> but !56810 wasn't just a dupe, it didn't have " # Follow the latest Linux stable" in the commit message and was an upgrade to 6.6.4
2023-12-07 09:26:46 <ncopa> are there any differences in headers from 6.6.0 to 6.6.4?
2023-12-07 09:29:31 <ncopa> im gonna tag 3.19 now. (in 5 mins). please hold your git pushes. at least things that takes more than 10min of the builders
2023-12-07 09:29:38 <omni> tbh, I didn't check, it was mostly to get a correct commit message
2023-12-07 09:30:01 <ncopa> 👍
2023-12-07 09:30:13 <ncopa> ill handle that after 3.19 release
2023-12-07 09:31:55 <omni> ncopa: what do you think about moving nikto to community first?
2023-12-07 09:32:21 <ncopa> does it take more than 10 mins of the buidlers?
2023-12-07 09:32:48 <ncopa> no idea what nikto is...
2023-12-07 09:33:13 <omni> 30-40sec
2023-12-07 09:33:22 <omni> I think it's in main due to legacy
2023-12-07 09:33:23 <ncopa> then push is. but push it now
2023-12-07 09:34:19 <omni> done
2023-12-07 09:34:20 <omni> thanks
2023-12-07 09:37:32 <omni> it went faster on the package builders than the CI builders so they're all done now
2023-12-07 09:41:08 <ncopa> alright. im tagging it now. please hold your git pushes for the next 15-30 mins
2023-12-07 09:51:27 <omni> \o/
2023-12-07 09:57:50 <donoban> o/
2023-12-07 10:01:21 <ncopa> is this ok? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/d9faa63ae469ecf3aad67f75d463e8ddd6378013/posts/Alpine-3.19.0-released.md
2023-12-07 10:01:36 <ncopa> I added a line about python's externally managed dir
2023-12-07 10:10:21 <vkrishn> openrc was updated last minute, cross-fingers
2023-12-07 10:10:35 <ikke> User may -> Users may 
2023-12-07 10:10:39 <omni> I wonder if zfs 2.2 should be mentioned too in highlights
2023-12-07 10:11:02 <ncopa> yeah, openrc update fixes issue with linux 6.6
2023-12-07 10:11:26 <omni> vkrishn: it was not a big change, but could possibly affect people using /sbin/rc for some reason
2023-12-07 10:11:49 <omni> and also what ncopa said
2023-12-07 10:11:50 <ncopa> not sure we want promote zfs. its problematic due to license fights
2023-12-07 10:12:01 <ncopa> funny thing with openrc update
2023-12-07 10:12:04 <omni> ah, ok, nvm then =)
2023-12-07 10:12:14 <ncopa> it did break buid-3-19-x86_64
2023-12-07 10:12:27 <ncopa> the builder had /sbin/rc in inittab
2023-12-07 10:12:32 <ncopa> that should be mentioned
2023-12-07 10:13:36 <omni> under "Upgrade notes"?
2023-12-07 10:18:57 <ncopa> yeah
2023-12-07 10:21:52 <ncopa> ok now? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/ea3abefe0e8e0b6f938d8da3995934b017c30ab7/posts/Alpine-3.19.0-released.md
2023-12-07 10:28:47 <dne> Pythons -> Python’s
2023-12-07 10:29:47 <omni> =)
2023-12-07 10:31:18 <ncopa> hum x86 did not build the release
2023-12-07 10:32:22 <ncopa> please continue hold your git push til I have resolved that
2023-12-07 10:32:30 <macmpi> date is 2023-12-07 today ;-)
2023-12-07 10:32:37 <ncopa> ah
2023-12-07 10:32:38 <ncopa> thanks!
2023-12-07 10:33:36 <ncopa> both are fixed.
2023-12-07 10:33:40 <ncopa> (release notes)
2023-12-07 10:34:06 <ncopa> ok now? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/74ff36a61e88133155aec32196cac8b62fb6b800/posts/Alpine-3.19.0-released.md
2023-12-07 10:34:19 <ncopa> I really appreciate the help of reviewing this
2023-12-07 10:37:19 <macmpi> yaml branch date is till 2023-12-06
2023-12-07 10:40:02 <ncopa> also fixed now. thanks!
2023-12-07 10:42:05 <omni> I could add gcompat and ifupdown comments to the wiki
2023-12-07 10:43:36 <ncopa> omni: i woulld appreciate that. Thanks!
2023-12-07 10:51:47 <donoban> !\_o_/!
2023-12-07 10:51:54 <dne> yay!
2023-12-07 10:54:34 <ncopa> alright, i'll post the release notes
2023-12-07 10:58:26 <omni> uhm... https://pkgs.alpinelinux.org/contents?branch=edge&name=busybox-ifupdown&arch=x86_64&repo=main
2023-12-07 10:58:44 <omni> is busybox-ifupdown empty?
2023-12-07 11:02:20 <omni> "placeholder package"
2023-12-07 11:02:33 <omni> maybe I just don't understand how it's packaged
2023-12-07 11:02:51 <omni> I'm sure I've used it, I just always miss something and install ifupdown-ng
2023-12-07 11:03:24 <macmpi> omni: https://pkgs.alpinelinux.org/packages?name=busybox-ifupdown&branch=edge&repo=main&arch=&maintainer=
2023-12-07 11:05:27 <ncopa> last chance to fix anything: https://wwwtest.alpinelinux.org/posts/Alpine-3.19.0-released.html
2023-12-07 11:06:20 <omni> macmpi: if you click "Contents of package" you'll get "No item found...", is what tripped me off
2023-12-07 11:07:43 <omni> ncopa: some odd linebreaks in the Highlights list, or is that just over here in my browser?
2023-12-07 11:08:31 <macmpi> ncopa: maybe, in upgrade notes, if it matters, just that raspberrypi-bootloader-common now generates config.txt?
2023-12-07 11:11:20 <ncopa> omni: indeed. thanks!
2023-12-07 11:12:14 <ncopa> macmpi: i'm not sure it matters. the config.txt comment says that it will be overwritten, so it is kind of expected
2023-12-07 11:13:06 <ncopa> https://alpinelinux.org/ now published
2023-12-07 11:13:30 <omni> \o/
2023-12-07 11:13:46 <omni> macmpi: maybe you could add a comment about it to https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.19.0#Raspberry_pi
2023-12-07 11:15:03 <macmpi> omni: yes it is there
2023-12-07 11:16:54 <omni> ah, yes, of course :D
2023-12-07 11:21:22 <omni> I haven't paid much attention to rpi lately, I have a few (no later models than rpi3) and the only one I'm currently using isn't running alpine, I should do something about that
2023-12-07 11:22:49 <omni> btw, I'm very happy about zfs in alpine, it was one of my checkboxes when looking for a distribution to move to... seven years ago(?!), the other two were xen and !systemd
2023-12-07 11:28:34 <ncopa> omni: glad to hear. license problems are in upstream linux kernel. we had to disable neon support in zfs driver for aarch64 due to license fights
2023-12-07 11:28:40 <Ermine> 
ACTION throws release confetti

2023-12-07 11:29:14 <ikke> ncopa: I'm invalidating latest-stable now
2023-12-07 11:29:25 <ncopa> ikke: awesome! thanks!
2023-12-07 11:31:11 <ikke> ncopa: I restarted pkgs.a.o, so it now shows 3.19
2023-12-07 11:33:01 <ncopa> great! thanks!
2023-12-07 11:33:50 <macmpi> ikke: pkgs does not seem to show things after 2023-12-06 16:01:15. Some caching issue?
2023-12-07 11:34:21 <ikke> macmpi: no, I stopped the sync script to do a manual import for 3.19 (which takes a long time)
2023-12-07 11:34:25 <ikke> I just restarted it again
2023-12-07 11:35:09 <macmpi> ikke: thanks
2023-12-07 11:36:52 <ikke> macmpi: it should already be up-to-date aagain
2023-12-07 11:37:15 <ikke> let me know if you still think things are missing
2023-12-07 11:41:44 <macmpi> ikke: 3.19 versions seem pre-release, i.e. https://pkgs.alpinelinux.org/packages?name=alpine-base&branch=v3.19&repo=&arch=&maintainer=
2023-12-07 11:44:12 <macmpi> ikke: in sync now: thanks
2023-12-07 11:57:23 <skarnet> ncopa: grats on the release!
2023-12-07 11:58:24 <indy> hi all, is there any howto for packaging non-free-firmware?
2023-12-07 12:01:44 <omni> indy: you mean for yourself? because I don't think it can be included in the distribution
2023-12-07 12:18:08 <ptrc> just realised 3.19 is out 🎉 thanks everyone <3
2023-12-07 12:23:07 <omni> +1
2023-12-07 12:23:16 <omni> #15550
2023-12-07 12:23:23 <omni> 3.18
2023-12-07 12:23:55 <ikke> Yeah I saw it. I think we can just backport ovpn 2.6.8
2023-12-07 12:24:49 <omni> I'll look at it
2023-12-07 12:27:40 <omni> !56849
2023-12-07 12:27:57 <omni> wait, what?
2023-12-07 12:29:37 <omni> I managed to get the wrong MR topic for some reason
2023-12-07 12:29:43 <omni> !56849
2023-12-07 12:34:49 <raspbeguy> hello, congrats on the release 🎉️
2023-12-07 12:37:17 <raspbeguy> now that it's done, would it be possible to have a look on the following MR please? !53681 !53868 !55326 !55791 !56782
2023-12-07 15:09:56 <tlndarfzyr[m]> I think its always good to have a report from potential users who after a look at alpine Linux choose against using it. In my case its simple. I do arduino things and liked to have a distro with the default thing arduino people work with: Arduino IDE version 2.2.1. I checked for it here, did not find it, and probably now move on to some other distro:
2023-12-07 15:09:56 <tlndarfzyr[m]> https://pkgs.alpinelinux.org/packages?name=arduino&branch=edge&repo=&arch=&maintainer=
2023-12-07 15:11:24 <ikke> tlndarfzyr[m]: Thanks for the feedback. In the end, it would require someone being able to maintain it. As a distro, we already have lots of things to take care of, so we cannot always ensure all software is available ourselves
2023-12-07 15:14:09 <indy> omni, now if there are guidelines how to publicly for all package something necessary for hw
2023-12-07 15:14:18 <tlndarfzyr[m]> Thanks for the fast and not angry reply at my message. Also thanks for not writing "then write the package code by yourself and be a maintainer" to a person who just took a 5 minute look into a distro.
2023-12-07 15:14:42 <indy> in this case it is rkbin with tpl binaries for various socs
2023-12-07 15:28:31 <Habbie> tlndarfzyr[m], that said, i suspect you would be very much welcomed if you did!
2023-12-07 16:03:02 <omni> there is #14857
2023-12-07 16:14:25 <minimal> ncopa: no mention of the Hashicorp packages removal in release notes...
2023-12-07 16:17:13 <ikke> minimal: Only in the wiki
2023-12-07 16:17:15 <ikke> see the MR
2023-12-07 16:17:57 <minimal> would make sense to mention it in the Release Notes though...
2023-12-07 16:18:45 <minimal> at the very least in the "Upgrade Notes" section...
2023-12-07 16:24:41 <durrendal> I'd second a mention of it in the release notes. It's more visible, and it's a disruptive change if you rely on the tools.
2023-12-07 17:04:21 <omni> firefox seem to segfault under sway (a ff+wayland issue?) when Ctrl+S/Save As..
2023-12-07 17:06:27 <dalias> yay
2023-12-07 17:13:55 <PureTryOut> I use Firefox on Wayland, KDE Plasma to be exact, and that doesn't happen for me
2023-12-07 17:14:01 <PureTryOut> Running a beta version of Plasma even
2023-12-07 17:15:48 <omni> maybe it's opening something else to show you the file listings etc then?
2023-12-07 17:16:11 <vkrishn> maybe, conflicting key-bindings? 
2023-12-07 17:18:13 <smcavoy> could someone look at merging: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/56677
2023-12-07 17:18:20 <omni> they also had the issue with meld and meld isn't working great for me either
2023-12-07 17:18:29 <ikke> !56677 
2023-12-07 17:19:14 <PureTryOut> omni: KDE has it's own XDG file portal, and I think Sway does too. So maybe the issue is in the Sway XDG file portal?
2023-12-07 17:19:24 <omni> maybe
2023-12-07 17:19:44 <omni> meld worked better when starting with files as arguments
2023-12-07 17:29:36 <omni> so I cannot get meld to segfault and I can open files
2023-12-07 17:29:55 <omni> but it spams a lot with
2023-12-07 17:29:57 <omni> AttributeError: 'NoneType' object has no attribute 'get_allocation'
2023-12-07 17:30:01 <omni> etc
2023-12-07 17:51:22 <c7s> do some packages need to be rebuilt for icu 74.1? I think the version got bumped but most packages don't use the new one, but some that happened to be updated now do (qt6-qtwebengine for example)
2023-12-07 17:53:01 <ikke> c7s: Most things should have been rebuilt
2023-12-07 17:55:31 <ikke> c7s: qt6-qtwebengine links against icu 74
2023-12-07 18:04:51 <c7s> thanks
2023-12-07 18:05:44 <c7s> not sure what was happening, I just uninstalled some stuff and it worked
2023-12-07 18:07:41 <ikke> Probably something was keeping it back
2023-12-07 18:18:35 <HRio> hmm "apk version -v" seems to have a problem with the long package names for the sub packages of abseil-cpp
2023-12-07 18:27:17 <HRio> https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/app_version.c?ref_type=heads#L118
2023-12-07 18:27:47 <ikke> 40 characters apparently
2023-12-07 18:33:39 <HRio> abseil-cpp-flags-commandlineflag-internal is 41  and in thye version -v printout there is also the version example "python3-3.11.5-r0"
2023-12-07 21:19:34 <ncopa> The hashicorp removal could be mentioned in release notes. But there is a political aspect there and I wanted avoid that in media 
2023-12-07 21:20:11 <ncopa> one thing I forgot was to check apk  index errors
2023-12-07 21:20:27 <ncopa> apk dot —errors
2023-12-07 21:21:20 <ncopa> we should add that to ci one somehow 
2023-12-07 21:21:55 <ikke> As a job per branch?
2023-12-07 21:22:27 <ncopa> Something yes
2023-12-07 21:22:46 <ncopa> a job per branch sounds good
2023-12-07 21:25:55 <ncopa> maybe we should let apkbuild linter warn about long names
2023-12-07 21:26:14 <ncopa> pkgname
2023-12-07 21:58:31 <thresh> I've just upgraded by VMWare Fusion aarch64 VM to 3.19, and it seems I got bit by https://gitlab.alpinelinux.org/alpine/aports/-/issues/15263 - grub-install after booting from a cd/chrooting fixed the issue.
2023-12-07 21:59:00 <thresh> I assume the "proper" fix that wouldnt involve user interaction didnt make it to 3.19.0?
2023-12-07 21:59:22 <thresh> I've upgraded from 3.17, if that matters
2023-12-07 21:59:47 <ncopa> thresh: ah! I think we should have mentioned that in the upgrade notes
2023-12-07 21:59:50 <ncopa> i forgot
2023-12-07 21:59:52 <ncopa> sorry
2023-12-07 22:00:13 <thresh> no worries, but indeed mentioning in the upgrade notes would likely save some time for me
2023-12-07 22:00:25 <ncopa> we need to add it
2023-12-07 22:00:56 <ncopa> thanks for letting us know
2023-12-07 22:01:31 <thresh> you're welcome
2023-12-07 22:04:36 <ncopa> please feel free to ping me again on Monday if I forget, or create an issue. need to go to bed now.
2023-12-07 22:04:40 <ncopa> again, thanks!
2023-12-07 22:12:50 <PabloCorreaGomez[m]> Congrats everybody on the release!! So cool to have it out!
2023-12-07 22:20:08 <ncopa> in case anybody has time to create a MR: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/issues/17
2023-12-07 22:20:17 <ncopa> we need this asap
2023-12-07 22:20:21 <ncopa> good night!
2023-12-07 22:42:55 <omni> https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/69 ?
2023-12-07 23:04:00 <omni> upgrading glib to 2.78.3 seems to fix the firefox segfault issue under sway !56879
2023-12-08 01:27:22 <celie> !55002 finally got approved, not in time for 3.19 though :(
2023-12-08 01:31:40 <ayakael0> QubesOS Alpine Linux v3.19 templates are up: https://lab.ilot.io/ayakael/qubes-builder-alpine Congrats on the release everyone!
2023-12-08 01:35:45 <omni> nice
2023-12-08 01:38:32 <ayakael0> All of my user-aports are also built for v3.19 on x86_64 and aarch64, for those who use my gitlab aport.
2023-12-08 02:29:47 <ajhalili2006> currently reviewing alpine/aports!56881 rn, any advise when should bundling libxx vs patching to work with libstdc++?
2023-12-08 02:56:10 <sam_> yeah it sucks hard
2023-12-08 02:56:12 <sam_> we suspect one of the issues is a gcc bug but need someone to reduce it first
2023-12-08 02:56:14 <sam_> someone on our end hopes to look at it over the weekend (but no promises)
2023-12-08 02:56:16 <sam_> (our end being gentoo)
2023-12-08 02:56:20 <sam_> because the v8 failure goes away if you try build that specific file w/ clang + libstdc++
2023-12-08 07:59:47 <celie> raspbeguy: For why GOMODCACHE and GOTMPDIR are important, have a look at https://irclogs.alpinelinux.org/%23alpine-commits-2023-10.log . Look for the conversation at around 2023-10-14 16:30
2023-12-08 08:03:09 <raspbeguy> celie, if I read correctly, in that case it was making CI failing. Here CI is fine
2023-12-08 08:37:03 <celie> My interpretation is that an aport without those exports was built on the builders, leaving something in the global cache, which later on caused some Go test to fail
2023-12-08 08:38:15 <celie> I don't think the failing Go test was caught by the CI, which is what made it so difficult to debug
2023-12-08 08:40:24 <celie> Anyway, someone else will probably see this conversation, and give a more affirmative answer as to why almost all Go aports have those exports defined in their APKBUILDs
2023-12-08 08:59:16 <raspbeguy> celie, in any case it sure doesn't hurt to add this so I will
2023-12-08 13:09:58 <omni> I'll take a look at jq in 3.18-stable
2023-12-08 13:14:16 <omni> ncopa: !56922
2023-12-08 14:30:21 <omni> I see this at the end of build logs:
2023-12-08 14:30:23 <omni> curl: (1) Protocol "http" not supported or disabled in libcurl
2023-12-08 15:53:52 <orbea> regarding this comment about a bluetooth vulnerability, what fix is this that is not enabled in alpine or other distros? https://www.schneier.com/blog/archives/2023/12/new-bluetooth-attack.html/#comment-429647
2023-12-08 15:54:18 <orbea> or is that not true?
2023-12-08 15:55:39 <ikke> What would have to be enabled?
2023-12-08 15:56:13 <orbea> that is what im wondering
2023-12-08 15:57:37 <orbea> i see now its actually this register article making the claim https://www.theregister.com/2023/12/06/bluetooth_bug_apple_linux/
2023-12-08 15:59:25 <orbea> and this is supposed to mitigate it, but i don't see what needs to be enabled or is that already done? https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/profiles/input?id=25a471a83e02e1effb15d5a488b3f0085eaeb675
2023-12-08 16:02:59 <ikke> ClassicBondedOnly=true
2023-12-08 16:03:15 <ikke> But that appears to be the default 
2023-12-08 16:03:28 <orbea> yea, maybe the article is testing older kernels before the fix?
2023-12-08 16:05:22 <orbea> or rather that is in bluez...
2023-12-08 16:07:01 <orbea> the fix is not in the most recent bluez release https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/profiles/input/input.conf?h=5.70#n20
2023-12-08 16:08:00 <orbea> but it is in the master https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/profiles/input/input.conf#n20
2023-12-08 16:46:44 <ikke> #15557
2023-12-08 22:54:48 <omni> can't find the dua upgrade in gitlab, 32b architectures seem to fail tests on the package builders
2023-12-08 22:56:02 <omni> ok, so it's downgraded again due to this
2023-12-08 23:01:33 <ikke> what?
2023-12-08 23:07:27 <omni> I wanted to see if 283bcd6976692ec8cbeef4804faabaf3d3d9c4c3 had also fail on our CI builders but I think it was pushed directly
2023-12-08 23:07:42 <omni> here it was downgraded again f34224bdb2049a28db1cb9ba5ba5ebf96b9aaf1c
2023-12-08 23:10:51 <omni> that EFI+grub+aarch64 issue.. =(
2023-12-09 00:47:28 <celie> I've been thinking a bit more about !56253, and it seems there will be another issue with Synapse on 3.19 besides not having tests enabled
2023-12-09 00:48:23 <celie> Click on the release notes, and you'll see the notice..that they will be changing the license to AGPL-3.0 (from Apache-2.0)
2023-12-09 00:49:07 <celie> So, what is our policy of aports changing licenses in the stable branches?
2023-12-09 00:52:30 <celie> There will very likely be some security fix later on and in the past, we just backported the upgrade, but what if the upgrade also changes the license?
2023-12-09 00:53:11 <minimal> omni: what about the grub issue?
2023-12-09 00:57:43 <omni> minimal: it doesn't feel great that people are having issues during upgrade to our latest release
2023-12-09 01:04:14 <minimal> omni: well I did point out potential Grub problems arrox 1+ months ago and I raised a MR for an attempt to deal with this but it wasn't accepted
2023-12-09 01:05:11 <minimal> omni: basically the Grub package has never handled updated/upgrades correctly, it's just that problems were not observed until recently
2023-12-09 01:07:38 <minimal> omni: what do you use if you don't use Grub?
2023-12-09 01:23:25 <omni> syslinux
2023-12-09 01:24:29 <omni> on x86_64
2023-12-09 01:24:58 <minimal> Syslinux potentially has a similar problem, it's just that Syslinux development effectively stopped several years ago and so no changes happen to the Syslinux code and so the fact that the Syslinux code is never updated from when the initial install is done isn't apparent
2023-12-09 01:32:41 <minimal> Hashicorp Vault fork appears: https://www.theregister.com/2023/12/08/hashicorp_openbao_fork/ and https://wiki.lfedge.org/display/OH/OpenBao+%28Hashicorp+Vault+Fork+effort%29+FAQ
2023-12-09 01:51:30 <omni> good news
2023-12-09 08:43:04 <celie> To anyone with merge access: !56956 !56954
2023-12-09 08:43:35 <celie> (an issue has been opened upstream, but the problem is actually on our end, and solved by a simple rebuild)
2023-12-09 11:00:06 <omni> ah, that's the issue that made me disable prowlarr in 2ecfec904abdaee121aace1918a6684f68a2f983
2023-12-09 11:00:29 <omni> later rebuilt with nodejs-current instead in f7d994b89958ccf84edd9c76023f26e152e5dd80
2023-12-09 12:02:06 <celie> Yes, it's the "million dollar question" :)
2023-12-09 12:14:27 <clandmeter> it looks like qemu ships its own version of ovmf firmware, is this new and is there any difference compared to the ovmf pkg?
2023-12-09 12:15:10 <omni> something should probably be added to https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.19.0#Raspberry_pi about the image/file downloads, #15559
2023-12-09 12:16:29 <omni> and this updated https://wiki.alpinelinux.org/wiki/Raspberry_Pi
2023-12-09 12:31:44 <omni> I'm looking at updating both
2023-12-09 12:56:13 <omni> done
2023-12-09 12:56:17 <omni> please check for errors etc
2023-12-09 13:27:27 <omni> lnl: <3 "it's my problem now"
2023-12-09 13:58:15 <omni> https://discourse.llvm.org/t/llvm-17-0-6-released/75281 maybe the last 17.x release
2023-12-09 15:49:02 <andypost[m]> Maybe it will fix rv64
2023-12-09 20:47:33 <iggy> has anyone ever tried to make an installer that's more than a bunch of shell scripts that are configured using (sometimes incorrectly documented) env vars?
2023-12-09 20:49:24 <ikke> I have not seen any serious attempts
2023-12-09 20:49:34 <minimal> iggy: rather than use an installer I instead went down the root of automating the creation of disk images that can be then put in place (i.e. dd'ed for physical machines)
2023-12-09 20:50:48 <minimal> also there is limited tiny-cloud support in the Alpine ISOs for automated installation
2023-12-09 20:55:56 <iggy> I went the make image route for some of my !amd64 machines, but that's pretty standard in that space
2023-12-09 20:56:02 <Hello71> iggy: many alpine users like the minimal installer. it's fast, modular, and fairly easily debuggable without language-specific tooling
2023-12-09 21:00:03 <iggy> yeah, I think my main gripe is with setup-disk... it makes some assumptions that I always find myself disagreeing with and it's kind of a pain to customize without looking through code... I love the esoteric stuff as much as the next person, but having to go look that stuff up every time isn't my favorite
2023-12-09 21:01:24 <iggy> I was mostly curious whether something was tried and failed or just not tried
2023-12-09 21:07:40 <Hello71> I don't think there's anything for alpine specifically other than minimal's cloud-init/tiny-cloud work. theoretically it should be possible to share something with other distros, but I'm not sure it's possible to design a UI to generate non-trivial (i.e. not whole disk) layouts and is actually simpler to use than cfdisk+mkfs+mount
2023-12-09 21:11:25 <minimal> iggy: setup-disk is not intended to support every possible way to set things up, i.e. it doesn't support UKI, EFISTUB booting, multi-OS/distro booting, etc
2023-12-09 21:11:57 <minimal> the more features it adds the harder/more compilcated it would be to test and debug
2023-12-09 21:15:10 <minimal> whereas for my own experimentation in my own script I added a 1001 options for creating disk images - e.g. you want X filesystem type with Y bootloader and LVM and/or LUKS for Z physical machine/hypervisor/Cloud? there's an option for that...
2023-12-09 21:30:03 <iggy> yeah, I get that what exists fills the void for some large set of users. I've personally used the installer plenty of times without needing to do any sort of customization and it's great. I aplaud the work that's been done thus far. I was mostly just curious about if anything else had ever been tried
2023-12-09 21:31:56 <minimal> iggy: well I mentioned the Alpine ISO having tiny-cloud that can do some automation, it's similar as to how Ubuntu Server's subiquity uses cloud-init for auto-installs
2023-12-09 21:36:30 <iggy> I've heard of it, but never considered how it might be useful outside of a strictly cloud image context, thanks for the mention to get my brain thinking outside the box
2023-12-09 21:47:36 <minimal> iggy: it is mentioned in the Alpine 3.18.0 Release Notes in the "Experimental headless installer" section
2023-12-09 23:18:58 <ikke> Ext4 corruption in stable linux kernels before 6.5 https://lwn.net/Articles/954285/
2023-12-10 01:14:03 <minimal> ikke: yeah Isaw that earlier, wondered if it affected Alpine < 3.19 but didn't see a clear list of affected kernels (i.e. does 6.1.66 in 3.18 contain a fix?)
2023-12-10 01:15:39 <minimal> no obvious mention of fix in 6.1.66 notes: https://lwn.net/Articles/954112/
2023-12-10 01:16:45 <dne> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843 says 6.1.66 fixes it
2023-12-10 12:39:24 <ysionneau> dne: I can confirm 6.1.66 is fixed. I tested few days ago
2023-12-10 12:39:41 <ysionneau> in 6.1 branch I think the only affected are 6.1.64 and 6.1.65
2023-12-10 16:06:15 <donoban> ouch, I was just thinking on migrate a server from btrfs to ext4
2023-12-10 16:09:45 <invoked> it's triggered on direct io writes
2023-12-10 16:10:27 <invoked> more of an indictment on kernel mgmt backporting stuff to stable
2023-12-10 17:43:35 <sicelo> ncopa: hi. regarding i3wm, i was wondering if it would be alright to make it depend on dbus-x11, and change the Exec line for its xsession to `dbus-launch --exit-with-x11 i3`. this will allow programs that need a session bus to work ootb
2023-12-10 17:44:12 <sicelo> otoh, i understand some people may feel they do not want dbus autolaunching in this way. what options would you suggest?
2023-12-10 17:59:56 <omni> some sub-package that does this?
2023-12-10 21:43:18 <PabloCorreaGomez[m]> Does anybody have any clue of what's going on with the RISC-V builder? 
2023-12-10 21:43:40 <PabloCorreaGomez[m]> We enabled xdg-desktop-portal-wlr on the 20th Nov, and it's still not uploaded
2023-12-10 21:43:55 <PabloCorreaGomez[m]> Is it really that far back?
2023-12-10 21:44:08 <ikke> PabloCorreaGomez[m]: qemu has been blocking it for the longest time
2023-12-10 21:44:31 <omni> I disabled qemu for riscv64 earlier
2023-12-10 21:44:54 <PabloCorreaGomez[m]> So that means we're expecting it to catch up at some point soon?
2023-12-10 21:44:55 <omni> !57030
2023-12-10 21:45:08 <ikke> 10 / 14 (71%) of community
2023-12-10 21:45:26 <ikke> If they all pass, it will upload community
2023-12-10 21:45:36 <PabloCorreaGomez[m]> Ok, thanks a lot, that makes sense
2023-12-10 21:45:58 <omni> currently building wpewebkit that... will probably take a while
2023-12-10 21:46:02 <ikke> yup
2023-12-10 21:46:22 <PabloCorreaGomez[m]> Yes, no issue waiting at all. I was a bit worried that something unexpected or unknown was happening
2023-12-10 21:46:41 <PabloCorreaGomez[m]> but you're amazing as always :D
2023-12-10 21:47:01 <omni> :*
2023-12-10 21:49:08 <ikke> Before qemu, it was hanging on packages. It seems to happen with cmake/coq regularly, and especially during 3.19 building, it can get unnoticed
2023-12-10 21:51:47 <omni> currently seems to be lld issues?
2023-12-10 21:51:55 <omni> also on s390x?
2023-12-10 21:52:25 <ikke> possibly, yes
2023-12-10 22:18:50 <sam_> keep in mind newer libuv at least automagically uses liburing
2023-12-10 22:18:54 <sam_> which cmake then picks up (because it uses libuv)
2023-12-10 22:18:59 <sam_> we've hit a bunch of bugs because of it in the kernel
2023-12-10 22:19:07 <sam_> you may want to explore that avenue if you've got no other ideas
2023-12-10 22:19:21 <sam_> you can also i think disable the libuv use of liburing via an env var or similar
2023-12-11 05:31:02 <EvTheFuture> I tried to upgrade my laptop from 3.18 to 3.19 and I have all storage on ZFS. After upgrade to 3.19 I get a kernel PANIC during boot (I guess when the initramfs tries to mount the root filesystem). The message is: PANIC: rpool: blkptr at XXXXXXXXXXXXXX has invalid TYPE 95
2023-12-11 05:31:19 <EvTheFuture> Does anyone seen this or have a clue on what could fix this?
2023-12-11 05:31:45 <EvTheFuture> This happens just after "Seeding ranom number generator" in the boot process
2023-12-11 05:47:44 <ikke> EvTheFuture: haven't heard about that yet 
2023-12-11 05:48:44 <EvTheFuture> ikke: I hope it's just something here so it wont be some upcoming upgrade issue
2023-12-11 06:01:17 <EvTheFuture> What worries me is the fact that I have three different root and boot datasets (six) in total. I always clone the current one and boot into the cloned one and then upgrade it in order to be able to roll back. So before upgrade it boots and I can also boot the previous dataset running 3.18 all on the samze zfs pools.
2023-12-11 08:11:45 <omni> EvTheFuture: can you access the data when booting 3.18?
2023-12-11 08:16:13 <omni> I haven't used clones like that myself, if I read correctly what you describe, only snapshots for the purpose of being able to roll back to a previous one
2023-12-11 08:18:49 <omni> there could be something in that we have, with 3.19, gone from zfs 2.1.x to 2.2.x, but it could also be something else
2023-12-11 08:22:28 <omni> EvTheFuture: I would open an upstream issue at https://github.com/openzfs/zfs/issues and describe the problem, mention that you run alpinelinux and what versions of zfs etc before and after upgrade
2023-12-11 09:58:54 <omni> win 22
2023-12-11 09:59:03 <omni> lose 23
2023-12-11 12:19:17 <EvTheFuture> omni: Yes I can access all data and everythong works as expected when booting in 3.18
2023-12-11 12:21:43 <EvTheFuture> omni: I'll file an upstream issue, thank you
2023-12-11 13:33:48 <abby> EvTheFuture: any LUKS involved? 
2023-12-11 13:34:42 <abby> the panics on zfs 2.2 I've heard about have all been luks related 
2023-12-11 17:41:57 <omni> I use luks+zfs without issues, but may be doing things differently
2023-12-11 17:42:28 <omni> ncopa: let's upgrade to kernel of the beast!
2023-12-11 21:57:05 <ikke> Anoyone able to review #57077, especially regarding some of the removed patches
2023-12-11 21:57:10 <ikke> !57077
2023-12-11 21:57:47 <ikke> libswrescale minor was bumped in 6.1, but major remained the same
2023-12-12 00:25:59 <EvTheFuture> omni: not LUKS, but the zfs root pool is encrypted and the initramfs asks for the passkey and successfully unlocks the root pool which is encrypted.
2023-12-12 00:55:43 <omni> EvTheFuture: how do you boot? do you have a sepearate /boot partition/device?
2023-12-12 01:01:01 <omni> not sure I would have any ideas atm even if I knew.. =/
2023-12-12 01:52:46 <EvTheFuture> omni: I have three partitions on the SSD, EFI, ZFS unencrypted containing a pool with a dataset for boot and finally a partition with an encrypted zfs pool containting root filesystem and other data datasets.
2023-12-12 01:55:04 <EvTheFuture> omni: BIOS boot into EFI which in turn load the configuration from the zfs boot dataset. the EFI grub config file can be found here: https://tpaste.us/d195
2023-12-12 01:56:26 <minimal> "BIOS boot into EFI?" - you mean UEFI boot into ESP partition I assume
2023-12-12 01:57:24 <EvTheFuture> minimal: fdisk report the partition type to "EFI System"
2023-12-12 01:57:45 <minimal> yes, ESP == EFI System Partition
2023-12-12 01:57:59 <minimal> so the partition is ESP, not EFI
2023-12-12 01:58:19 <minimal> terminology is important
2023-12-12 02:01:21 <EvTheFuture> You are correct, my bad. However this part works and have always worked fine. Grub then load the config from the plain text (not encrypted) dataset located in the second partition on the SSD which contain zfs boot datasets. This also works just fine and the initramfs in Alpine asks for a password to unlock the root dataset located on the third partition which contain an
2023-12-12 02:01:23 <EvTheFuture> encrypted zfs pool. 
2023-12-12 02:04:45 <EvTheFuture> The two last lines before it fails are: * Setting keymap ... and * Seeding random number generator ...
2023-12-12 02:05:44 <EvTheFuture> So it feels like there might be something with zfs 2.2 that is problematic here...
2023-12-12 02:11:20 <minimal> what do you mean "it fails" ?
2023-12-12 02:12:03 <minimal> so you see "Saving 256 bits of creditable seed for next boot"?
2023-12-12 03:42:26 <EvTheFuture> minimal: take a look at: https://github.com/openzfs/zfs/assets/66333723/e0fab57d-8a71-41e6-8761-db77d49ffc0f
2023-12-12 03:43:41 <EvTheFuture> It is an image of the screen when it fails
2023-12-12 03:44:24 <EvTheFuture> It might be more easy to understand compared to me trying to explain in an unclear way :)
2023-12-12 03:45:34 <EvTheFuture> Now when I think of it, it ooks like it actually mounts the root filesystem but fails a bi further down the road...
2023-12-12 09:21:18 <raspbeguy> Hello, could you give an eye to 53681! please?
2023-12-12 09:21:35 <raspbeguy> !53681
2023-12-12 10:01:29 <ncopa> i just pushed linux kernel 6.6.6
2023-12-12 10:06:37 <omni> \m/
2023-12-12 11:00:13 <EvTheFuture> ~
2023-12-12 11:11:38 <omni> does anyone successfully run docker with cgroups v2?
2023-12-12 11:12:40 <omni> people seem to have issues since 3.19 as the default in openrc was changed from "hybrid" (v1 & v2) to "unified" (v2)
2023-12-12 11:20:44 <ikke> I have no idea, I have never explicitly set it to v2 myself
2023-12-12 11:26:31 <omni> I (sometimes) use podman myself, never docker
2023-12-12 11:27:41 <omni> I have updated the wiki https://wiki.alpinelinux.org/wiki/OpenRC#cgroups_v2
2023-12-12 11:31:04 <ikke> omni: maybe mention it on the v3.19 release notes on the wiki as well?
2023-12-12 11:33:02 <omni> yes
2023-12-12 11:47:40 <ncopa> i have user unified/v2 for a while and it sort of works
2023-12-12 11:47:51 <ncopa> seems like memory controller does not work as expected though
2023-12-12 12:09:20 <donoban> omni: I've tried to check what is commeted here https://lore.kernel.org/cgroups/rare3lakkfrp7lkcfosuhivot6vuwuuwkgj74bbzmsjjpgwkt7@udo2e6layb3d/T/#u , but didn't have enough time for understand it deeply
2023-12-12 12:10:16 <donoban> I feel that something is wrong because I can't enable memory controller for seatd or svnserve cgroups also but I hadn't time for elabore a reply yet
2023-12-12 12:10:41 <donoban> root@localhost /sys/fs/cgroup/svnserve # echo +memory > cgroup.subtre
2023-12-12 12:10:43 <donoban> e_control
2023-12-12 12:10:45 <donoban> echo: write error
2023-12-12 12:10:47 <donoban> :\
2023-12-12 12:11:15 <ikke> donoban: the reply they gave seems to imply docker itself is doign something incorrectly if I understand it correctly
2023-12-12 12:11:23 <donoban> here cgroup.type is only 'domain', not threated
2023-12-12 12:11:38 <donoban> yes I thought it, but after reading docker source and testing on another cgroups
2023-12-12 12:11:48 <donoban> I feel that the reply is not accurated or I didn't understand it properly
2023-12-12 13:05:25 <omni> I wonder if it's an issue with runc (I use crun with podman)
2023-12-12 13:06:25 <omni> this may be related https://github.com/opencontainers/runc/issues/4097
2023-12-12 14:41:03 <Kladky> In most tree sitter grammars, the check option is disabled with the reason "no tests for shared lib", even though most grammars do have tests. Considering all the issues we have with tree-sitter grammars, should I enable the tests?
2023-12-12 15:17:59 <celie> timlegge: When you find some free time, could you give https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/235 a review? Thanks
2023-12-12 15:18:31 <timlegge> celie will do
2023-12-12 18:06:55 <mio> can someone please take a look at !56452 and comment if there's anything else needed to be merge-ready? thanks
2023-12-12 18:47:55 <khem> mio: lgtm
2023-12-12 18:55:07 <mio> khem: thanks!
2023-12-12 19:00:49 <omni> mio: I guess I, and others, didn't follow your link to !52069 and instead waited for approval by the assignee
2023-12-12 19:02:47 <mio> omni: okay, no problem. wasn't sure who's managing the reassignments of packages on the drop list
2023-12-12 19:03:58 <mio> picked up another package on the list at another reviewer's suggestion, didn't seem to require explicit approval from the assignee in that instance
2023-12-12 19:05:05 <mio> (or if anyone was managing it, sorry for the confusion)
2023-12-12 19:10:52 <omni> no worries, it was jsut a guess on my part on why it wasn't merged earlier
2023-12-12 20:08:30 <khem> I am on archlinux and was wondering if https://gitlab.alpinelinux.org/alpine/docker-abuild will work on it 
2023-12-12 20:08:44 <khem> right now I am running into some issues
2023-12-12 20:09:20 <khem> https://snips.sh/f/fOe5lEswB2
2023-12-12 20:17:46 <khem> nm figured it, it should be run inside a package dir with APKBUILD file in it
2023-12-12 23:23:10 <quinq> Seems like epiphany is utterly broken
2023-12-12 23:26:14 <quinq> It's missing dependency on dbus-x11
2023-12-12 23:26:20 <quinq> Then on xdg-dbus-proxy
2023-12-12 23:26:46 <quinq> And even then, it fails and respawns in an infinite loop
2023-12-12 23:27:03 <quinq> (epiphany:8446): epiphany-WARNING **: 00:22:54.678: Web process crashed
2023-12-12 23:27:03 <quinq> (process:2): libportal-CRITICAL **: 00:22:55.283: Failed to create XdpPortal instance: Failed to execute child process “dbus-launch” (No such file or directory)
2023-12-12 23:27:37 <quinq> (though dbus-launch is available after manually installing dbus-x11)
2023-12-13 01:30:47 <omni> are there arm CI builder issues?
2023-12-13 01:48:27 <ptrc> omni: yeah, they seem to be offline
2023-12-13 01:48:47 <ptrc> > gitlab.alpinelinux.org: [problem] | Gitlab Runner shared-runner gitlab-runner-aarch64.che-ci-1 offline
2023-12-13 05:43:24 <ikke> They are back
2023-12-13 06:54:54 <Kladky> When I try to sign into gitlab, I am met with HTTP 422
2023-12-13 06:59:09 <ikke> Kladky: "Can't verify CSRF token"
2023-12-13 09:20:17 <bratkartoffel> I've missed the alpine 3.19 release with my signal-cli. May I move it from testing to community although 3.19 is already released? !57204
2023-12-13 09:58:17 <ncopa> bratkartoffel: do we have it in edge? I think we can make exception unless it breaks things
2023-12-13 10:02:07 <bratkartoffel> testing is edge only, isn't it?
2023-12-13 10:03:27 <ikke> Yes
2023-12-13 10:11:57 <bratkartoffel> ncopa: yes, after !57203 it is available in edge/community, so the mentioned MR is some kind of a backport to 3.19. It shouldn't break anything as nothing depends on this aport (or the java-libsignal-client dependency which is also included in this MR)
2023-12-13 13:01:29 <afofu> omni I run successfully docker with cgroups v2 for over a year. On Alpine the trick is to define your own cgroup for your docker containers. This can be done in “/etc/docker/daemon.json” e.g “"cgroup-parent": "/someName"” globally.  Or for each container individually e.g. in docker-compose.yml  with “cgroup_parent: "/dockerMinecraft".
2023-12-13 13:01:29 <afofu> Then everything works like expected on Alpine with cgroups V2 enabled. It took me a while to recognize this too :-). Back when I faced this issue I did a test on Ubuntu and there this was not necessary. The standard v2 cgroup of docker on Alpine behaves different than on Ubuntu.
2023-12-13 13:05:24 <omni> afofu: would you mind also sharing in #15506 or #15570 ?
2023-12-13 13:06:12 <ncopa> was thinking the same. maybe we should even ship a default cgroup-parent in default config
2023-12-13 13:06:13 <omni> yesterday I looked a bit at how docker, containerd and runc are packaged in gentoo, as they too use openrc, and it is a bit different
2023-12-13 13:50:37 <afofu> omni: You just made me do my first comment on gitlab ;-) https://gitlab.alpinelinux.org/alpine/aports/-/issues/15570
2023-12-13 14:05:35 <afofu> ... the comment is here https://gitlab.alpinelinux.org/alpine/aports/-/issues/15506 an not in 15570 (sorry)
2023-12-13 16:12:24 <ptrc> uhhh, what the heck happened with ffmpeg 6.1
2023-12-13 16:12:52 <ikke> it happened
2023-12-13 16:13:02 <ptrc> apparently none of the ffmpeg subpackages have any version constraints, so they just do partial upgrades
2023-12-13 16:13:13 <ptrc> and also, the version for libswresample went.. down?
2023-12-13 16:13:21 <ptrc> ffmpeg-libswresample-6.1-r0 provides:
2023-12-13 16:13:21 <ptrc> ffmpeg-libswresample-6.0.1-r1 provides:
2023-12-13 16:13:21 <ptrc> so:libswresample.so.4=4.12.100
2023-12-13 16:13:21 <ptrc> so:libswresample.so.5=5.0.100
2023-12-13 16:14:30 <ikke> It matches the upstream version
2023-12-13 16:15:43 <ptrc> also, there's a lot of rebuilds missing?
2023-12-13 16:16:15 <ptrc> at least 30 packages that now look for a .so that doesn't exist :/
2023-12-13 16:16:36 <ptrc> hopefully the rebuild would suffice
2023-12-13 16:16:43 <ptrc> and that's gonna fix the issue with missing symbols
2023-12-13 16:17:26 <ikke> I'll bump the depending packages
2023-12-13 16:17:27 <minimal> ptrc: there WAS a libswresample patch removed from the Alpine packaging that previously modified the minor/major versions
2023-12-13 16:17:41 <minimal> libswrescale-5.patch
2023-12-13 16:17:43 <ptrc> oh huh
2023-12-13 16:17:55 <ikke> fyi, the MR was from me
2023-12-13 16:18:21 <minimal> "this wasn't bumped for ffmpeg6, so dump it ourself to not conflict with ffmpeg 5."
2023-12-13 16:18:41 <ikke> But it was bumped a major version, while upstream in 6.1 only bumped the minor
2023-12-13 16:19:20 <minimal> that old patch bumped both major and minor
2023-12-13 16:19:33 <ikke> Yeah, I meant, a major version as well
2023-12-13 16:19:43 <ptrc> the issue doesn't exist though, because we no longer have ffmpeg5-libs
2023-12-13 16:19:49 <ptrc> so it makes sense to remove the patch
2023-12-13 16:20:18 <ikke> I'll work on the bumps
2023-12-13 16:20:44 <ikke> ncopa noticed it as well now
2023-12-13 16:21:27 <ikke> But except for  librewescale, there were no soname bumps
2023-12-13 16:23:51 <ptrc> ( funnily enough, the libswresample patch is named 'libswrescale' and that confused me quite a bit )
2023-12-13 16:24:40 <ikke> right
2023-12-13 16:27:21 <ptrc> hah, it looks like they broke ABI compatibility...?
2023-12-13 16:27:28 <ptrc> the newer version does have that symbol that's missing
2023-12-13 16:27:32 <ptrc> but they both have the same SONAME
2023-12-13 16:28:05 <ikke> ugh
2023-12-13 16:28:11 <ikke> so rebuilds required
2023-12-13 16:28:59 <minimal> Canonical have changed the LXD license to AGPLv3 and added a CLA as of the latest release.
2023-12-13 16:29:27 <ikke> yes
2023-12-13 16:34:50 <ncopa> re ffmpeg: i dumped what I figure out here: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15577
2023-12-13 16:35:16 <ikke> #15577
2023-12-13 16:36:18 <ncopa> the libswrescale-5.patch was questionable. it was a hack so we could have both ffmpeg5 and ffmpeg6 installed at the same time
2023-12-13 16:36:42 <ncopa> it was the correct thing to remove it, but we need to rebuild - I am doing that as we speak
2023-12-13 16:36:50 <ikke> ncopa: ok, thanks
2023-12-13 16:36:57 <ncopa> the bigger question is what to do with 3.19-stable
2023-12-13 16:37:10 <ikke> There are patches available for the CVEs
2023-12-13 16:37:15 <ikke> I can try to make an MR to do those
2023-12-13 16:37:57 <ncopa> might be better to use patches for ffmpeg. or we could keep the libswscal-5.patch for 3.19-stable
2023-12-13 16:39:04 <ikke> But you still have the missing symbol in libavcodec, right?
2023-12-13 16:39:27 <ncopa> i think it was introduced in 6.1
2023-12-13 16:39:38 <ikke> yes, that's what I mean, if we upgrade to 6.1 in 3.19
2023-12-13 16:39:56 <ikke> But maybe I'm misunderstanding what you meant
2023-12-13 16:40:30 <ncopa> i mean the symbol. the problem here was that apk upgrade did not upgrade all due to so version change
2023-12-13 16:40:46 <ncopa> so I had lib* 6.0
2023-12-13 16:41:01 <ncopa> and I assume something was updated
2023-12-13 16:41:13 <ncopa> not sure.
2023-12-13 16:41:32 <ptrc> your specific case is that libavcodec stayed on 6.0.1, but libavformat got upgraded to 6.1
2023-12-13 16:41:38 <ncopa> yeah
2023-12-13 16:42:18 <ncopa> so upgrading to 6.1 for 3.19-stable should be ok, as long as we keep the  libswrescale-5.patch 
2023-12-13 16:50:58 <omni> aaaaa sorry!
2023-12-13 16:52:06 <ikke> omni: it's not your fault
2023-12-13 16:52:17 <omni> no, but I backported the upgrade to 3.19
2023-12-13 16:52:29 <ikke> but the MR is still open :)
2023-12-13 16:52:51 <omni> oh *phew*
2023-12-13 16:53:13 <omni> I thought I had went ahead and merged that
2023-12-13 16:53:29 <omni> was away for a bit and haven't fully read up yet
2023-12-13 16:54:55 <ikke> so if you reinstate the swrescale patch, it should be fine
2023-12-13 16:55:16 <ikke> (and rebase it)
2023-12-13 16:55:24 <omni> I can do that
2023-12-13 16:55:44 <ikke> it conflicted because upstream did a minor version bump
2023-12-13 17:14:32 <omni> there, I think
2023-12-13 17:37:47 <ptrc> is someone doing the pkgrel bump for libswresample?
2023-12-13 17:39:21 <ikke> ncopa mentioned he was working on it
2023-12-13 17:40:40 <ptrc> ah, okay
2023-12-13 18:42:01 <ikke> lnl: deblob fails on rv64 against a newer hare. I saw upstream already fixed it in master
2023-12-13 19:15:35 <lnl> will look into it when I get home
2023-12-13 19:17:04 <ikke> 👍
2023-12-13 19:23:02 <ikke> lnl: should I just bump it to master?
2023-12-13 19:25:46 <lnl> sure
2023-12-13 19:28:11 <ncopa> pushed rebuilds for ffmpeg. sorry. I had to step out for a couple of hours
2023-12-13 19:29:06 <ncopa> testing repo is more work, but thats due to lfs64
2023-12-13 19:33:52 <somercet> just heading out for an errand, but mpv needs an update against ffmpeg-libavformat: "Error relocating /usr/lib/libavformat.so.60: av_packet_side_data_add: symbol not found"
2023-12-13 19:34:03 <somercet> back in half an hour or so
2023-12-13 19:34:59 <khem> ncopa: it seems master branch on forked aports repo is not allowed to be force pushed is that intentional ?
2023-12-13 19:35:24 <khem> https://www.irccloud.com/pastebin/LXC7EKKp/
2023-12-13 19:36:52 <ptrc> khem: that's just gitlab automatically protecting it
2023-12-13 19:37:04 <ptrc> you can just go to repository settings and remove it from "protected branches"
2023-12-13 19:37:15 <khem> yeah ok, I kind of should not used for creating a MR 
2023-12-13 19:38:54 <khem> this time I did once MR is merged I will re-enable it, its good to have it in general 
2023-12-13 19:54:30 <khem> I was playing with docker setup for building edge  aports on latest archlinux and ran into few issues, pull is here - https://gitlab.alpinelinux.org/alpine/docker-abuild/-/merge_requests/69
2023-12-13 19:54:52 <khem> would be interested in reviews 
2023-12-13 19:58:14 <ikke> khem: those warnings are just that though, warnings
2023-12-13 19:58:50 <ikke> On my build system, I get `WARNING: opening /home/build/packages/main: No such file or directory`, because I have not built anything for testing yet, but everything works fine
2023-12-13 19:58:51 <khem> warnings are fine, look at the ERROR: piece 
2023-12-13 19:59:24 <khem> I took the whole log to add some context but perhaps I could have just added the ERROR line 
2023-12-13 20:00:18 <ikke> I formatted it to make the error stand out more
2023-12-13 20:01:28 <khem> @ikke ty !
2023-12-13 22:06:58 <staceee> qutebrowser seems broken: Error relocating /usr/lib/libavformat.so.60: av_packet_side_data_add: symbol not found
2023-12-13 22:07:43 <staceee> ah, probably needing a rebuild against ffmpeg
2023-12-13 22:13:40 <omni> the riscv64 builder is almost there, but I don't get why it is failing on testing/sentinel-minipot
2023-12-13 22:14:20 <staceee> adding another mirror allowed me to upgrade some packages. Now qutebrowser starts
2023-12-14 00:18:57 <omni> not sure if my laptop is broken or something else is going on but I can't seem to use the SD-card slot anymore
2023-12-14 01:03:16 <omni> never mind, I turned on something in bios that  I didn't think was related and it works now
2023-12-14 11:26:22 <omni> did the riscv64 builder get stuck on buildah?
2023-12-14 11:27:13 <ikke> omni: let me check
2023-12-14 11:27:49 <ikke> seems to be stuck on tests
2023-12-14 11:29:18 <ikke> https://tpaste.us/NBpw 
2023-12-14 13:39:44 <celie> ptrc: Is there anything you want me to do in !57244?
2023-12-14 13:44:31 <ptrc> ah, sorry, maybe my comment wasn't too clear; since the CVE numbers have proper version constraints, we don't need to include them in aports :p
2023-12-14 13:45:14 <celie> Oh, ok, so remove them from secfixes?
2023-12-14 13:47:05 <ptrc> mhm
2023-12-14 13:55:07 <omni> is testing/py3-duniterpy failing on the riscv64 builder due to poetry changes or other?
2023-12-14 14:09:37 <celie> ptrc: Done, i've removed the CVE numbers
2023-12-14 14:10:18 <celie> omni: I'm a bit confused regarding !53519 vs !57280
2023-12-14 14:10:26 <ptrc> celie: thanks!
2023-12-14 14:11:34 <celie> I tried to diff 3.0.2 and 3.0.3, but couldn't find any difference in pngquant code (hopefully i didn't miss anything obvious), what i could find is that 3.0.3 includes tests, but we don't run them anyway
2023-12-14 14:13:45 <celie> Upstream is confusing us (me, at least) by releasing 3.0.2 on Crates.io and 3.0.3 on Github
2023-12-14 14:14:50 <celie> Anyway, i've closed my MR, hopefully when 3.0.4 (or whatever comes after 3.0.3) is released, it is not exclusive to Crates.io, or it'll be the same thing all over again
2023-12-14 14:26:49 <omni> celie: idk either
2023-12-14 14:29:05 <omni> I don't know why libimagequant was upgraded to the 4.1.0 commit in 93e107f578cfb0e176029f4e9dbbe305b2084052 but since it already wasn't at 4.0.3 I bumped it to the latest release too in my MR
2023-12-14 14:44:34 <celie> It seems 4.0.3 is the version of https://github.com/ImageOptim/libimagequant/tree/main/imagequant-sys
2023-12-14 15:06:00 <omni> yes
2023-12-14 16:16:53 <omni> should we get !57209 in?
2023-12-14 16:33:36 <omni> oh-no, did I merge 28976de375c32cbdd6e267023498028ab8ee17c4 ? =(
2023-12-14 16:53:42 <khem> ptrc: omni https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/57190 is finally ready to merge 
2023-12-14 16:54:34 <ptrc> except that it's on the master branch, so nobody can rebase it except for gitlab admins :p
2023-12-14 16:54:47 <ptrc> you'd need to go to your fork's settings and disable branch protection for master
2023-12-14 16:56:37 <omni> w00t! riscv64 is finaly idle
2023-12-14 16:56:49 <ptrc> ooh, nice!
2023-12-14 16:57:51 <omni> khem: it should have been lowercase "upgrade to"
2023-12-14 17:01:47 <ptrc> yeeah, but we've had quite a bit of capitalised "Upgrade", so i'd rather merge / amend the commit message by myself whenever possible
2023-12-14 17:03:19 <khem> hmm thanks will keep that in mind in future, usually I have seen Uppercase letter used at the beginning of summary sentence in commits. Infact in Yocto we sort of recommend it :)
2023-12-14 17:05:54 <omni> ptrc: yeah, smaller changes like that I now often correct myself than have the author do it, but it helps if it's correct to begin with
2023-12-14 17:06:14 <omni> and I often make mistakes to, as my "oh-no" earlier
2023-12-14 17:06:22 <omni> referred to
2023-12-14 19:15:40 <bratkartoffel> omni: thanks for merging my previous openjdk MRs, can you please merge !57283? then i can finish the self-bootstrap stuff today
2023-12-15 01:08:40 <omni> arm builders ran out of space again?
2023-12-15 02:46:14 <khem> omni: I am curious what does alpine build farm looks like what kind of machines does it have
2023-12-15 10:45:50 <ikke> omni: I freed up space
2023-12-15 10:50:56 <omni> nice!
2023-12-15 11:01:42 <omni> the linter says: MC:[AL49]:./APKBUILD:29:invalid option 'bigdocs'
2023-12-15 11:01:51 <omni> but it is valid, isn't it?
2023-12-15 11:05:33 <ikke> It's a relative new option, so it hasn't been added to atools yet
2023-12-15 11:13:31 <omni> ok
2023-12-15 11:41:54 <EvTheFuture> omni: Upstream issue for ZFS for reference https://github.com/openzfs/zfs/issues/15666
2023-12-15 11:53:08 <omni> but nothing new =/
2023-12-15 12:48:34 <omni> EvTheFuture: and that's not on you, just that you haven't gotten any replies yet
2023-12-15 13:11:25 <Habbie> !57342 - what do I do? click "Mark as done"? is that "approve"?
2023-12-15 13:15:01 <omni> Habbie: you can write a comment like "lgtm" or something that will indicate to us that you approve
2023-12-15 13:15:22 <Habbie> great - i think that's what i did before, but suddenly i wondered :)
2023-12-15 13:15:23 <Habbie> thanks
2023-12-15 13:52:46 <bratkartoffel> i'm currently thinking about boostraping openjdk21 for riscv64. would it be possible if i manage to cross-compile it locally, then copy the result to the builders and use it there to bootstrap the build?
2023-12-15 13:59:14 <omni> how does that work when we cut a new release?
2023-12-15 14:01:29 <bratkartoffel> i think the openjdk packages form edge are copied ot the builder, as the build depends on itself (e.g. !57302)
2023-12-15 14:02:11 <bratkartoffel> so the difference is only within the inital bootstrap, as you have to copy locally built (und thus untrusted) binaries to the builders
2023-12-15 14:08:02 <omni> someone other than me should answer your question
2023-12-15 14:08:21 <omni> ncopa: speaking of riscv64, should linux-lts be enabled for it again?
2023-12-15 14:09:37 <ikke> bratkartoffel: things have been bootstrapped in a similar way before
2023-12-15 15:27:47 <bratkartoffel> ikke: thought so, but good to hear. it seems the riscv64 openjdk is quite straight forward to cross compile. just required a minor patch to remove an include and the first pass using temurin 21.01 x86_64 as bootjdk compiled without issues
2023-12-15 15:28:31 <bratkartoffel> fingers crossed that the second build works just as flawless
2023-12-15 16:11:59 <bratkartoffel> i've managed to bootstrap riscv64 openjdk21. can someone please take a look at !57351, download the bootstrap jdk from my server and trigger the build?
2023-12-15 17:57:17 <ncopa> i finally figured out what goes wrong with docker under openrc with cgroup2
2023-12-15 17:57:30 <ncopa> https://github.com/OpenRC/openrc/pull/681
2023-12-15 17:58:11 <ncopa> I think we'd like to backport that to 3.19, but users should probably reboot after that update.
2023-12-15 17:59:55 <donoban> wow great!
2023-12-15 18:00:34 <ncopa> just want to hear what openrc people says about it before I backport the patch to our aports
2023-12-15 18:02:22 <ncopa> have a nice weekend everyone!
2023-12-15 18:03:58 <donoban> thanks, u too
2023-12-15 19:50:17 <ikke> In 10 minutes I will upgrade gitlab to 16.5
2023-12-15 20:05:06 <ikke> all done
2023-12-15 20:33:47 <vkrishn> community/rtx, url=https://rtx.pub, goes to 404
2023-12-15 20:34:55 <ikke> http://distfiles.alpinelinux.org/distfiles/edge/rtx-1.35.8.tar.gz
2023-12-16 03:28:34 <craftyguy> fyi there's a CVE fixed in this bluez update: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/57273
2023-12-16 03:29:00 <craftyguy> https://nvd.nist.gov/vuln/detail/CVE-2023-45866
2023-12-16 10:57:02 <papiris[m]> haha https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/libfetch/fetch.cat3 is soo weird
2023-12-16 11:03:24 <papiris[m]> How can an apk-commit hook parse/redirect the output of the parent apk command (e.g. apk add emacs) to a temporary file?
2023-12-16 11:08:00 <papiris[m]> says here (line 18) that all apk commands which modify the database are logged to /var/log/apk.log , but that file doesn't exist on two of my systems (both edge, one aarch64, one x86_64) https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/doc/apk.8.scd
2023-12-16 11:09:54 <papiris[m]> one system is in a distrobox container, and the other one is postmarketOS, for clarity
2023-12-16 11:11:11 <ikke> papiris[m]: The master branch of apk-tools is apkv3, while Alpine is still on apkv2 
2023-12-16 11:12:34 <papiris[m]> ooooh
2023-12-16 11:39:30 <papiris[m]> How do we use the 'apk --progress-fd' option?
2023-12-16 11:39:30 <papiris[m]> I've tried giving a file descriptor to a file by 'exec 3 > apk.log' and doing 'apk add emacs --progress-fd 3', but the apk.log file remains empty
2023-12-16 11:40:08 <papiris[m]> 'exec 3>apk.log' I meant
2023-12-16 15:32:48 <z3ntu1> Anyone have an idea what could be going wrong here? https://gitlab.alpinelinux.org/lucaweiss/aports/-/jobs/1215246#L1768 CI for this package is only failing on armv7 because it's trying the zink driver from mesa but libvulkan.so.1 would come from the vulkan-loader package, which isn't a dependency of anything mesa-related it seems
2023-12-16 15:33:29 <z3ntu1> Not sure if adding vulkan-loader as checkdepend (on at least armv7) would be a good solution for that, or actually something on the mesa side is a bit funky
2023-12-16 16:03:29 <z3ntu1> Okay, in any case adding vulkan-loader as checkdepends doesn't make it better:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/mwlZUDRmBjDPBPHDyfSWPUVQ>)
2023-12-16 16:04:06 <z3ntu1> I wonder why it chooses to run zink and not just swrast like (presumably) on all the other architectures
2023-12-17 11:54:37 <Reinhilde> teh
2023-12-17 13:45:58 <nmeum> few days ago wifi (iwlwifi) stopped working for me on both my t490 and my x230. it seems iwlwifi is no longer able to bring up the interface (i.e. the interface remains down after `ip link set dev wlan0 up`). anyone else experiencing issues with iwlwifi?
2023-12-17 13:49:13 <quinq> nmeum, I had a problem, worked after unloading and reloading the module(s)
2023-12-17 13:49:28 <quinq> (on the X230)
2023-12-17 13:49:51 <quinq> running 6.6.6 right now, it works
2023-12-17 13:56:35 <nmeum> hm, nope that doesn't fix it for me
2023-12-17 14:14:23 <nmeum> nvm, I messed up my wpa_supplicant config
2023-12-17 14:17:54 <quinq> Meaning it's working now?
2023-12-17 14:34:53 <nmeum> yea (I have a custom wpa_supplicant package with syslog support and that was accidentially overwritten with the package in aports.git and then it would fail to start but wouldn't do proper error logging)
2023-12-17 14:35:02 <nmeum> should probably also just upstream syslog support
2023-12-17 14:36:41 <nmeum> !57439
2023-12-17 16:06:38 <omni> uhm... new gitlab and "Are you sure you want to rebase?" popup...
2023-12-17 16:06:43 <omni> do we need that?
2023-12-17 16:09:45 <ikke> hmm
2023-12-17 18:42:50 <ikke> omni: not really no
2023-12-17 18:43:21 <Kladky> Are files installed to /usr/share/man automatically compressed to gzip?
2023-12-17 18:43:52 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1961
2023-12-17 18:44:40 <Kladky> They should also be installed to the correct subdir depending on their number, right?
2023-12-17 18:44:52 <Kladky> Or is that done manually?
2023-12-17 18:45:16 <ikke> Most build systems already take care of that
2023-12-17 18:45:56 <Kladky> So do I install files to /usr/share/man or /usr/share/man/man[1-8] ?
2023-12-17 18:46:13 <Kladky> This package does not do it automatically.
2023-12-17 18:48:31 <ikke> You'd need to install it in the correct place yourself then
2023-12-17 18:53:23 <Kladky> Ok, thanks!
2023-12-17 19:56:36 <Kladky> Is it possbile to have a subpackaged named "prefix-$pkgname"?
2023-12-17 19:57:13 <ikke> a subpackage can have any name
2023-12-17 19:57:33 <ikke> doesn't even have to have the original package in it
2023-12-17 19:57:58 <Kladky> Ok.
2023-12-17 19:58:27 <Kladky> It seems for me it is executing a subpackage function before all other functions
2023-12-17 19:58:36 <Kladky> idk if it is because it is called cargo
2023-12-17 19:59:14 <Kladky> Yep that is the reason.
2023-12-17 19:59:42 <ikke> you are overriding the cargo command
2023-12-17 19:59:52 <Kladky> So how would I go about having a subpackge called "cargo-$pkgname"?
2023-12-17 20:00:05 <ikke> Kladky: you can override the splitfunction name
2023-12-17 20:00:22 <ikke> cargo-$pkgname:<name> (in subpackages)
2023-12-17 20:00:57 <Kladky> Thanks!
2023-12-17 20:23:24 <ikke> omni: was added here: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112356
2023-12-17 20:27:14 <omni> can it be disabled?
2023-12-17 20:28:18 <ikke> I guess only by patching it out
2023-12-17 20:31:44 <omni> it is annoying if you have to see it and click it away everytime you want to rebase an MR to try the pipelines one more time before merging
2023-12-17 20:32:23 <ikke> I use glab to do that
2023-12-17 20:32:31 <omni> yeah
2023-12-17 20:32:46 <omni> I guess I should change my workflow do be less in the browser anyway
2023-12-17 20:33:31 <omni> I haven't used glab much, I used to use lab to follow CI pipeline output back when it worked
2023-12-17 20:34:24 <ikke> https://gitlab.alpinelinux.org/-/snippets/1100
2023-12-17 21:03:41 <ikke> omni: rebase without pipeline btw does not show the popup
2023-12-17 21:06:35 <omni> yeah, I noticed, that's what I do most of the time
2023-12-17 21:07:07 <omni> but I've taken to sometimes also rebase, if it was some time since the pipelines were last run
2023-12-17 21:08:06 <ikke> yup, not a bad idea to do
2023-12-17 21:48:13 <Kladky> How come it seems I cannot approve merge requests I am assigned?
2023-12-17 22:31:02 <fluix> you need a gitlab role
2023-12-17 22:40:13 <Kladky> Oh, ok.
2023-12-17 22:55:48 <ptrc> z3ntu1: lomiri-system-settings has been failing tests on builders, see https://build.alpinelinux.org/buildlogs/build-edge-x86/testing/lomiri-system-settings/lomiri-system-settings-1.0.2-r0.log
2023-12-17 22:55:52 <ptrc> disabling tests for now
2023-12-18 08:30:34 <z3ntu1> ptrc: bah, spent extra much effort on that package to make them work.. too bad
2023-12-18 08:32:19 <raspbeguy> Hello, would it be possible to look at !53681 please?
2023-12-18 08:42:11 <ncopa> morning! if you use edge and upgrade today, please run `apk fix openrc` to ensure you have network next reboot.
2023-12-18 08:47:03 <ikke> alpine-conf and alpine-base keep ifupdown-ng-openrc installed for me
2023-12-18 08:48:03 <ikke> ah, --available
2023-12-18 14:24:03 <invoked> WhyNotHugo: i believe you asked about whether wlr-protocols is in repo (and it isn't) and i'm curious whether you are working on that.
2023-12-18 14:24:42 <invoked> i've just got it installed manually (for building drawterm manually) but one of us should probably get it in there
2023-12-18 14:24:52 <invoked> or whomever is maintaining wayland-protocols now
2023-12-18 15:02:52 <WhyNotHugo> invoked: I'm not working on it; feel free to package it. Should be simple to use wayland-protocols as a base reference.
2023-12-18 15:12:51 <invoked> doing it is easy. i'm probably not a good candidate to maintain anything, though
2023-12-18 15:33:05 <omni> ncopa: I saw that you merged !55860, do you plan to move on to related MRs? because I just opened !57498 and was thinking of incorporating on or two in that
2023-12-18 15:35:11 <omni> thinking of !56982, !57485 and !56641
2023-12-18 18:34:09 <bratkartoffel> can someone with access to builders please take care of !57351?
2023-12-19 02:45:09 <celie> danieli: Could you please have a look at !57212 and !57125? Thanks
2023-12-19 05:19:23 <danieli> celie: I replied to both
2023-12-19 08:38:23 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/57507 I think we have an issue with binutils on ppc64le. Do we have anyone from IBM that could help with that?
2023-12-19 08:39:28 <ptrc> IBM would be s390x, wouldn't it?
2023-12-19 08:39:56 <ncopa> ibm is also ppc64le
2023-12-19 08:40:01 <ptrc> ah, no, you're right
2023-12-19 11:06:52 <ncopa> 'm tagging an edge snapshot release
2023-12-19 13:22:39 <omni> win 22
2023-12-19 13:29:08 <ncopa> I finally took over cogitri's packages and pushed it. If anyone is interested in help maintain any of those packages, just create an MR
2023-12-19 13:41:17 <omni> gnome team some of them?
2023-12-19 13:50:20 <ncopa> they already took some, but did not want take all
2023-12-19 14:09:09 <omni> ok!
2023-12-19 14:58:51 <aparcar> where do I find the source code of https://pkgs.alpinelinux.org/?
2023-12-19 15:25:04 <ptrc> aparcar: https://gitlab.alpinelinux.org/alpine/infra/aports-turbo/
2023-12-19 15:25:05 <clandmeter> aparcar: https://gitlab.alpinelinux.org/alpine/infra/aports-turbo
2023-12-19 15:25:27 <clandmeter> at least its clear now
2023-12-19 15:30:10 <aparcar> Thanks
2023-12-19 15:32:11 <clandmeter> aparcar: what is the status of apk on openwrt?
2023-12-19 15:35:52 <aparcar> clandmeter: "ongoing"
2023-12-19 15:36:08 <aparcar> clandmeter: if you want to be involved, let me know 🙂
2023-12-19 15:36:34 <clandmeter> im interested, but not eager to join forces
2023-12-19 15:36:44 <clandmeter> we had a discussion about apk3 recently
2023-12-19 15:38:09 <clandmeter> i mean in our tsc meeting we brought apk3 up and were interested in knowing other projects experience with it. 
2023-12-19 15:43:45 <aparcar> Oh well let’s get in contact
2023-12-19 15:44:21 <aparcar> Would be nice if alpine switches to apk3 so we have the same codebase to work with
2023-12-19 16:16:52 <omni> ncopa: I've rebased and reassigned his MRs to you
2023-12-19 16:19:06 <ncopa> thanks!
2023-12-19 16:25:52 <omni> np
2023-12-19 17:53:01 <bratkartoffel> something is wrong with docker-abuild, it cannot find the image for x86, armhf, armv7 and aarch64: https://tpaste.us/yYzd
2023-12-19 17:56:51 <bratkartoffel> x86_64, ppc64le, s390x and riscv64 are fine though
2023-12-19 20:32:36 <bl4ckb0ne> is tsan supposed to work on alpine? i get a segfault in `libc_start_main_stage2` 
2023-12-19 20:36:56 <khem> IIRC it did work in past 
2023-12-19 20:38:36 <khem> https://reviews.llvm.org/D93848
2023-12-19 20:38:51 <bl4ckb0ne> asan/ubsan works fine
2023-12-19 20:42:53 <bl4ckb0ne> reproducing with https://github.com/google/sanitizers/wiki/ThreadSanitizerCppManual#usage
2023-12-19 20:46:07 <bl4ckb0ne> opened https://github.com/google/sanitizers/issues/1713
2023-12-19 23:47:57 <ptrc> bl4ckb0ne: iirc we already have an issue open that tsan is segfaulting?
2023-12-19 23:48:09 <ptrc> but i don't remember much progress being done on it
2023-12-19 23:55:19 <bl4ckb0ne> havent thought about looking into the opened issues on aport
2023-12-19 23:55:33 <bl4ckb0ne> aports*
2023-12-20 02:28:06 <smcavoy> Could someone take a look at MR !56932
2023-12-20 02:36:33 <mio> when a package is upgraded where filenames have changed in the new version, does the install process automatically remove the older files (like uninstall and install) or does it have to be done manually in a pre-install script?
2023-12-20 02:37:04 <mio> done manually as in, specified in a pre-install script to detect old ones and remove
2023-12-20 05:09:54 <ikke> mio: if the files are owned by the package, apk takes care of it
2023-12-20 06:52:04 <Cogitri> ncopa: Thanks for taking care of my MR :)
2023-12-20 09:15:28 <ncopa> sorry for taking time
2023-12-20 10:17:33 <donoban> yesterday I notice a broken 'Dockerfile' due python "exernally managed", altough pipx seems a interesting alternative for hosts/desktops... I think that it doesn't fit very well on container env
2023-12-20 10:18:42 <donoban> could I add '--break-system-packages' or the '/usr/local/' venv to the releases notes? it could save some minutes for people on the same problem
2023-12-20 10:19:00 <abby> on void we just don't extract the externally managed flag file in the container images we ship
2023-12-20 10:19:13 <abby> because it's a throwaway environment
2023-12-20 10:19:46 <abby> https://github.com/void-linux/void-containers/commit/b51f6068d429945826692be1d4a6cfd96ee18083
2023-12-20 10:20:21 <donoban> for me that would be fine but I feel that there was some motivation for maintain it on official images too
2023-12-20 10:20:32 <donoban> there was some discussion, revert & restore...
2023-12-20 11:20:24 <Kladky> In an APKBUILD, if the program statically links against software with a "stricter" license, should the project's license or that "stricter" license be put as the license?
2023-12-20 11:21:22 <Kladky> Because mautrix-signal (AGPL-3.0-or-later) statically links against libsignal (AGPL-3.0-only)
2023-12-20 11:50:51 <Habbie> i'm no expert but i would put -only in
2023-12-20 14:26:18 <ncopa> why does pipx not fit will with container env?
2023-12-20 14:28:23 <ikke> I guess it's annoying having to activate a venv before you can execute your application 
2023-12-20 14:29:07 <ikke> Although you can probably execute it directly with python from the venv 
2023-12-20 14:29:08 <abby> you don't need to activate anything with pipx
2023-12-20 14:29:19 <abby> it's designed to be transparent
2023-12-20 14:29:49 <abby> but also yes, you could just use path/to/venv/bin/python
2023-12-20 15:20:52 <mio> ikke: cool, thanks for the explanation ^^
2023-12-20 18:27:17 <donoban> wops, day of connection problems
2023-12-20 18:27:33 <donoban> there was some comment about pip?
2023-12-20 18:29:31 <ikke> donoban: pipx
2023-12-20 18:30:08 <ikke> donoban: ncopa asked why pipx would not work in Docker
2023-12-20 18:35:57 <donoban> well, I don't really tested but first it install things on ~/.local/share/pipx... which is pretty uggly for a container where maybe there are no users defined
2023-12-20 18:37:03 <donoban> but most important is that it only works for cli or "executable" programs, not libs... so if you have a container with some local python code which depends on some libs that you install via 'pip install...', then pipx is probably not useful
2023-12-20 18:48:13 <donoban> I feel that it doesn't help in the container use-case and just breaks retro-compatiblity :\
2023-12-20 19:11:23 <ncopa> was introduced with 6c2a300f6787544f3194e7f6cc19058baf9b7419
2023-12-20 19:11:49 <ncopa> which claims that debian and ubuntu does the same. how do they solve it?
2023-12-20 19:12:24 <ncopa> I think adding `--break-system-packages` to release notes makes sense
2023-12-20 19:12:30 <ncopa> for docker usecase
2023-12-20 19:19:53 <ncopa> or: printf "%s\n%s\n" "[global]" "break-system-packages = true" > /etc/pip.conf
2023-12-20 20:54:04 <donoban> ncopa: I just tried on a fresh ubuntu container and 'pip install xxx' works
2023-12-20 20:54:29 <donoban> let's see debian..
2023-12-20 20:55:26 <abby> does /usr/lib*/python*/EXTERNALLY-MANAGED exist in the container?
2023-12-20 20:56:01 <donoban> let's see..
2023-12-20 20:56:26 <donoban> debian doesn't let you install
2023-12-20 20:57:19 <donoban> it has EXTERNALLY-MANAGED, I'm reinstalling on ubuntu
2023-12-20 20:58:18 <donoban> ubuntu doesn't have it
2023-12-20 21:01:19 <abby> docker run --rm ghcr.io/void-linux/void-musl sh -c 'xbps-install -Sy python3 2>&1 >/dev/null; ls /usr/lib/python3.12/ | grep -q EXTERNAL; echo $?'
2023-12-20 21:01:19 <abby> 1
2023-12-20 21:01:42 <abby> another for your tally
2023-12-20 21:03:37 <clandmeter> ncopa: any specific reason you did not implement by-path in mdev-conf?
2023-12-20 21:21:55 <ncopa> clandmeter: i dont remember
2023-12-20 21:22:07 <ncopa> it was probably not needed at the time
2023-12-20 21:22:22 <ncopa> YAGNI
2023-12-20 21:23:15 <clandmeter> nod
2023-12-20 21:23:55 <clandmeter> seems somebody does, and eudev is causing issues with by-path
2023-12-20 21:23:57 <minimal> clandmeter: missing utils (that udev has) from mdev...
2023-12-20 21:24:04 <clandmeter> need to debug it
2023-12-20 21:24:40 <clandmeter> s/causing/having
2023-12-20 21:24:49 <minimal> same reason some of the other by-* entries aren't implements (yet) for mdev
2023-12-20 21:25:32 <clandmeter> is there an issue regarding this missing x?
2023-12-20 21:26:15 <minimal> what "x"?
2023-12-20 21:27:22 <clandmeter> x utils
2023-12-20 21:31:08 <minimal> nope, no issue, it is functionality that mdev just doesn't have
2023-12-20 21:40:14 <skarnet> by-x is udev-specific, ISTR having taken a quick glance at what would be needed to implement it and the abyss gazed back
2023-12-20 21:43:58 <clandmeter> we have some basic support via mdev-conf
2023-12-20 21:54:47 <minimal> skarnet: I already last year implemented (some) of the by-id, by-label, by-partuuid stuff for mdev
2023-12-20 21:55:26 <skarnet> I'm looking at mdev-conf and don't see anything of the sort
2023-12-20 21:57:23 <minimal>   /lib/mdev/persistent-storage
2023-12-20 21:58:30 <skarnet> ah indeed, there's some by-id and by-uuid there
2023-12-20 21:58:53 <skarnet> that must have been a pain to get right, thanks for diving into it XD
2023-12-20 21:59:32 <minimal> https://gitlab.alpinelinux.org/alpine/mdev-conf/-/commit/e58f7e17c9313085125a565ab1bcc101f47bf061
2023-12-20 22:00:24 <minimal> I had some more changes that were reject, regarding device mapper links.....you might remember that let to the discussion about mdev not supporting "drop in" files unlike udev
2023-12-20 22:01:12 <minimal> Alpine packages the likes of device mapper udev rules separately (as they're provided by packages like lvm2 rather than eudev)
2023-12-20 22:02:09 <minimal> so the adding of equivalent entries to mdev-conf was rejected as then behaviour wouldn't be consistent - you'd have those entries in "stock" mdev but only have them with eudev if the other packages for the rules were installed
2023-12-20 22:03:19 <minimal> fixing /dev/mapper behaviour to be the same for mdev and eudev was a mess so I gave up on that
2023-12-20 22:04:03 <skarnet> all of this, and a lot of similar issues, could be solved with /etc/mdev.conf.d/* and a preprocessor at apk add/remove time
2023-12-20 22:05:59 <minimal> skarnet: some of it yes, but not all of it - on most Linux distros /dev/mapper entries are symlinks to /dev/dm-* devices.....but not on Alpine....because the initramfs' init uses mdev ;-)
2023-12-20 22:06:47 <skarnet> yeah I'm not even sure what /dev/mapper is
2023-12-20 22:07:12 <minimal> device mapper = things like LVM and LUKS devices
2023-12-20 22:07:27 <Ermine> devices of device-mapper subsystem?
2023-12-20 22:08:29 <skarnet> if it's only a question of creating the symlinks, a small early one-shot should be able to do it
2023-12-20 22:08:53 <minimal> e.g. during boot of Alpine if your rootfs is on a LVM LV or on a LUKS encrypted device then the device mapper libraries are used to handle them and device-mapper devices are created
2023-12-20 22:09:09 <skarnet> yeah, got it
2023-12-20 22:10:06 <minimal> e.g. the *default* behaviour for LVM devices is for /dev/mapper/ entries to be files not symlinks *UNLESS* the LVM code is able to contact the udevd in which case INSTEAD they are created as symlinks to /dev/dm-* devices
2023-12-20 22:10:36 <skarnet> okay I regret ever having asked
2023-12-20 22:10:49 <minimal> now Alpine uses mdev in initramfs regardless of whether the actual booting OS uses mdev or eudev.........
2023-12-20 22:11:04 <skarnet> or mdevd
2023-12-20 22:11:06 <minimal> there's no way for the LVM stuff to talk to a udevd duroing initramfs......
2023-12-20 22:11:39 <minimal> and so you end up with the actual files............whereas on pretty much every other distro its udev alone and they are created as symlinks
2023-12-20 22:12:50 <minimal> there is a "workaround" for this to build LVM2 with certain options and (from memory) add a config file also to the initramfs.......I *think* I got this working...........then I thought about LUKS and having to try and do a similar bit of "magic" for it.........and gave up ;-)
2023-12-20 22:13:21 <skarnet> sounds like a design bug in lvm and luks tbh
2023-12-20 22:13:37 <minimal> skarnet: mdevd? but it's not in the initramfs..... ;-)
2023-12-20 22:13:45 <skarnet> there's no reason why they should ever try to contact a specific implementation of a device manager in the initramfs
2023-12-20 22:14:09 <minimal> skarnet: I'm referring to the LVM2 stuff....
2023-12-20 22:14:20 <skarnet> yes
2023-12-20 22:14:30 <minimal> it's written the way it's written
2023-12-20 22:14:57 <skarnet> yes, and from your description, it sounds like it's doing something wrong
2023-12-20 22:17:07 <minimal> skarnet: quickly found reference: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/logical_volume_manager_administration/udev_device_manager#udev_dm_integration
2023-12-20 22:18:41 <minimal> LVM2 has things like "#define DEFAULT_UDEV_SYNC 1" lol
2023-12-21 11:15:00 <skarnet> Happy winter solstice! Could someone please take a look at !57695 and merge it? thanks :)
2023-12-21 11:23:43 <skarnet> ptrc: thanks!
2023-12-21 11:24:19 <ptrc> ^^
2023-12-22 01:02:23 <dalias> the alpine spdlib package seems broken
2023-12-22 01:02:54 <dalias> it should be setup to have SPDLOG_FMT_EXTERNAL always defined, since it does not ship the 'bundled fmt lib' headers included
2023-12-22 01:17:04 <omni> PureTryOut: ^
2023-12-22 01:17:28 <omni> spdlog*
2023-12-22 01:40:56 <dalias> (it has a dep on fmt, so the intended usage is to use the separate fmt package)
2023-12-22 02:23:31 <dalias> uhg fmt-dev is missing a .a
2023-12-22 02:23:36 <dalias> i think it used to have it
2023-12-22 02:23:45 <dalias> or else fmt just used to not have any lib, header only
2023-12-22 07:49:45 <PureTryOut> it already has SPDLOG_FMT_EXTERNAL=ON though 🤔
2023-12-22 07:50:16 <PureTryOut> and already tries to make sure it's defined in the header files as well
2023-12-22 12:16:59 <fraolt> Does somebody have the chance to look at !55276, it's been dormant for > 3 weeks now, but there is really nothing left to do IMO. I know everyone has been busy with 3.19, but maybe now is a good time?
2023-12-22 12:17:51 <fraolt> I've been using the build for my daily flashcard reviews for a couple of weeks now. :)
2023-12-22 17:21:42 <omni> oh https://github.com/asterisk/asterisk/compare/20.5.1...20.5.2
2023-12-22 20:10:16 <abby> is the openjdk maintainer around? https://git.alpinelinux.org/aports/tree/community/openjdk21/APKBUILD#n2
2023-12-22 20:10:42 <ikke> brattkartofel is not here atm
2023-12-22 20:14:18 <abby> i'm mostly just trying to find where oracle says it doesn't support 32bit anymore
2023-12-22 20:14:26 <abby> so if anyone else knows
2023-12-22 20:21:08 <Arnavion> abby: Back in JDK 10 apparently   https://wiki.openjdk.org/display/Build/Supported+Build+Platforms#SupportedBuildPlatforms-JDK9and10buildplatformssupportedbyOracle
2023-12-22 20:21:38 <abby> huh
2023-12-22 20:21:42 <Arnavion> and   https://stackoverflow.com/questions/49976684/java-10-and-following-on-32-bit-systems
2023-12-22 20:23:24 <abby> looks like adoptium stopped arm32 in 20
2023-12-23 22:09:52 <no_maam> Hi, I have a small issue with Postfix. Version 3.8.4 was released a few days ago, which is a security update. It's in edge, but not in 3.19 right now. Is there something I can do to get it in 3.19? Or will that just happen automatically the next days?
2023-12-23 22:17:17 <Arnavion> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/57760
2023-12-23 22:23:47 <no_maam> Ah thanks, I didn't see this one. So someone needs to rebase it?
2023-12-23 23:43:07 <Arnavion> No
2023-12-23 23:44:05 <Arnavion> Whoever gets around to merging it can rebase it at that point
2023-12-24 03:09:13 <ptrc> was there any discussion about qt5-qtwebengine being disabled on armv7? half of kde is broken there now
2023-12-24 03:27:14 <celie> omni: I see you reran the pipeline on !57766. However, i think it failed due to the `mv` in package(), maybe you should remove that first.
2023-12-24 03:29:29 <celie> I'm also wondering what removing --prefix would do, but i would have to open a separate MR to see the diff
2023-12-24 06:35:06 <omni> celie: yeah, I didn't look properly before I did that
2023-12-24 12:21:55 <Ermine> Merry Christmas!
2023-12-24 18:10:14 <telmich> ikke: i saw https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/57734, but don't have the right to rebase or merge, update looks good to me
2023-12-24 18:12:19 <ikke> You should be able to approve it now
2023-12-24 19:13:38 <Kladky> Could anyone please take a look at !57577 !57172
2023-12-24 19:24:30 <Kladky> For the latter tell me when it is reviewed so I can bump the version.
2023-12-24 19:25:10 <Kladky> It uses git commit as 0.4.3 cannot register new devices cause the py library they use is unmaintained
2023-12-25 16:46:10 <vkrishn> q
2023-12-25 18:20:56 <vkrishn> shouldn't /etc/services now have normalized port 6697 for ircd ?
2023-12-25 18:23:16 <abby> 6697 is typically the standard port for irc with tls 
2023-12-25 18:23:25 <abby> 6667 is without
2023-12-25 18:33:01 <vkrishn> i mean, it should be added, like http and https both have an entry
2023-12-25 18:34:14 <vkrishn> unless its still in acceptance (standardizing) phase
2023-12-25 18:36:37 <abby> huh void's etc/services has that but it comes from the iana-etc package. dunno how alpine does it
2023-12-25 18:36:38 <omni> this https://salsa.debian.org/md/netbase/-/blob/master/etc/services is where we pull our /etc/services file from (see main/alpine-baselayout/APKBUILD)
2023-12-25 19:10:18 <humm> there are entries for both ircd and ircs-u
2023-12-25 19:46:20 <vkrishn> yes, thanks
2023-12-25 23:00:48 <Kladky> Thank you ptrc!
2023-12-26 19:51:37 <mick_ibm> ncopa hey im online briefly today and saw some merges for Efl_Relr for ppc64le from here: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15478
2023-12-26 19:56:12 <mick_ibm> just following up cause i was told Elf64_Relr was added to musl almost 7 weeks ago https://git.musl-libc.org/cgit/musl/commit/include/elf.h?id=6be76895f6863100a311d474a42abdbb6466189d the kernel team recommended maybe building a newer version but i saw the merge just now and seemed like tests passed :) 
2023-12-27 00:18:41 <c7s> how does downgrading a package interact with pkgrel?
2023-12-27 01:57:30 <fluix> wdym?
2023-12-27 02:06:27 <c7s> if you downgrade a package, how should you change pkgrel? reset it to 0? add 1? add 1 to whatever the last pkgrel of that version was before it was upgraded?
2023-12-27 02:11:35 <fluix> I don't think you can downgrade packages in the repos. you'd have to keep the current version and just bump pkgrel even if the version is wrong
2023-12-27 02:13:46 <fluix> c7s: nvm, see https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/COMMITSTYLE.md?ref_type=heads#downgrade
2023-12-27 02:14:19 <c7s> aha
2023-12-27 02:15:08 <c7s> I suppose that means the old pkgrel +1, but it's worded weirdly
2023-12-27 02:16:01 <c7s> yeah it can't mean anything else, ok thanks
2023-12-27 02:29:46 <smcavoy> can someone take a look at merging !56932
2023-12-27 08:26:12 <vkrishn> ikke: is it ok to have local "partial" copy of repositories, coz i don't need full /community, and net is not ok sometimes ?
2023-12-27 08:27:09 <ikke> You'd need to at least make sure dependencies match
2023-12-27 08:28:09 <vkrishn> yes, i will, i have full /main coz is small 
2023-12-27 08:28:39 <vkrishn> rest is via script that reads output from apk add ... msg and downloads it
2023-12-27 08:30:02 <ikke> How does the script know what dependencies to download?
2023-12-27 08:31:09 <vkrishn> pls have look here, https://tpaste.us/6MyW 
2023-12-27 08:31:35 <vkrishn> trick is, apk fix > a.lst 2>&1
2023-12-27 08:32:56 <vkrishn> i am thinking of writing an article (kinda tips and tricks page), hope its something ok to suggest users
2023-12-27 08:33:27 <vkrishn> i run "apk add ..... pkgs...."
2023-12-27 08:33:35 <vkrishn> then generate list, apk fix > a.lst 2>&1
2023-12-27 08:36:13 <vkrishn> repo /main is already fully downloaded
2023-12-27 08:38:24 <vkrishn> it should also work with partial /main, but kinda messy
2023-12-27 08:48:30 <vkrishn> its also possible to use /cache dir downloads, run script to rename it and move to main or community, but its way more hacky
2023-12-27 08:48:36 <fluix> what are you trying to save on exactly?
2023-12-27 08:49:05 <ikke> Yeah, wondering the same
2023-12-27 08:49:19 <vkrishn> my alpine reboots (ram based installs) on intranet
2023-12-27 08:49:35 <fluix> all package contents are not downloaded when you add a repository to /etc/apk/repositories. only apkindex is fetched
2023-12-27 08:50:30 <vkrishn> i understand, its only the intranet that becomes a pain
2023-12-27 08:50:35 <fluix> ah so you're setting up a local mirror essentially
2023-12-27 08:50:44 <vkrishn> not fully, partial
2023-12-27 08:50:51 <fluix> yep, got it
2023-12-27 08:51:17 <vkrishn> 24Gb of community, burp...
2023-12-27 08:52:27 <fluix> might be possible to come up with some transparent caching setup so you don't need the script (basically fetch packages slowly from internet the first time and then serve from cache next time)
2023-12-27 08:52:57 <fluix> gl whichever way you go!
2023-12-27 08:53:00 <vkrishn> yes, been there, ditched it, but open for new ideas
2023-12-27 08:53:35 <vkrishn> i even have script that converts /cache to main and community
2023-12-27 08:58:12 <vkrishn> there is "apk fetch -R"
2023-12-27 08:59:00 <vkrishn> but it re-downloads full set required
2023-12-27 09:19:17 <vkrishn> other possible solution is folder wise download in /cache/[main|community] dir
2023-12-27 11:11:19 <liske> vkrishn: I build my own alpine iso's using the scripts in aports, but with a custom profile containing all packages I'm going to use (dependencies are handled by the build scripts)
2023-12-27 11:12:25 <liske> and I don't use any online repository... upgrades are shipped by using `setup-bootable -u` with a fresh image
2023-12-27 11:12:36 <vkrishn> yes that's one way, but would you suggest that to a new al user
2023-12-27 11:13:48 <vkrishn> using online repo is just one way to script, it can be /media/usb/apks2/alpine/v3.19/community
2023-12-27 11:14:16 <vkrishn> where /media/usb/apks is default
2023-12-27 11:15:28 <vkrishn> is short a small ram-based install that has what you need on the disk
2023-12-27 11:15:44 <vkrishn> even after reboot
2023-12-27 11:17:27 <vkrishn> one problem with new users are they often try to apk -U even during phase of learning basic installs
2023-12-27 11:18:09 <vkrishn> rather then install once, reboot it and see how it works and progressively enhance skill
2023-12-27 17:22:24 <vkrishn> ikke: around ?
2023-12-27 17:30:48 <durrendal> anyone mind taking a look at !56479 and !57453?
2023-12-27 18:09:19 <tomalok> hopefully qq -- is there a tool/command that can be run to check if a particular file was installed from an APK?
2023-12-27 18:18:29 <minimal> tomalok: apk info -W /full/path/to/file
2023-12-27 18:18:59 <minimal> you'll get "ERROR: /full/path/to/file: Could not find owner package" if not provided by any package
2023-12-27 18:19:09 <minimal> with exit code = 1
2023-12-27 18:20:50 <tomalok> minimal: thx
2023-12-27 18:21:49 <nu[m]> so cool, ty too
2023-12-27 18:44:27 <adhawkins> Making an update to one of my package for the first time since upgrading the Debian box I do the work on. 'git commit' isn't filling in the commit log as it used to do. Anything obvious I should check?
2023-12-27 18:46:50 <adhawkins> Looking in .git/hooks, all the files have a '.sample' extension, which I suspect prevents them from running. I didn't deliberately change this. Is there something I need to do?
2023-12-27 18:49:08 <skarnet> not unless you want something specific to happen on given git commands
2023-12-27 18:50:14 <skarnet> as for your initial question, this is probably better suited for a Debian support channel ;)
2023-12-27 18:51:02 <adhawkins> skarnet: Not really. Previously when I ran 'git commit' in the aports directory, the commit message had the repository and packagename filled in for me.
2023-12-27 18:52:17 <fluix> if you're using abump I think it creates the commit for you
2023-12-27 18:52:40 <fluix> unless there's an error which it'll show
2023-12-27 18:53:13 <adhawkins> fluix: I don't know what abump is. I've just edited the APKBUILD file, done a 'git add' on it, and now I'm running 'git commit'
2023-12-27 18:54:12 <fluix> that won't fill anything in (and I'd be surprised if it ever did unless you wrote your own scripts)
2023-12-27 18:54:24 <adhawkins> fluix: It certainly did :)
2023-12-27 18:54:45 <fluix> nothing in those steps makes commit messages for you, unless there's a git setting for this
2023-12-27 18:54:46 <adhawkins> I've found a prepare-commit-msg hook at https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Commit_your_work, but that doesn't seem to work.
2023-12-27 18:55:39 <fluix> yeah that makes sense (it's also what I meant to cover in the part in parenthesis of my previous message)
2023-12-27 18:55:47 <vkrishn> adhawkins: is this about aports ?
2023-12-27 18:55:53 <adhawkins> vkrishn: Yes.
2023-12-27 18:55:56 <vkrishn> check https://git.alpinelinux.org/aports/tree/.githooks
2023-12-27 18:56:27 <adhawkins> Aha, that looks favourite vkrishn. One sec.
2023-12-27 19:04:30 <adhawkins> Ok, so I linked those scripts in and it still wasn't working. Think I've tracked it down to the regex in the cast statement.
2023-12-27 19:04:52 <adhawkins> I've changed it from '[^.]*/*' to '*/*' and it now seems to be working...
2023-12-27 19:05:13 <adhawkins> Debian's default shell is dash, it could be that I guess. Let me check.
2023-12-27 19:05:46 <adhawkins> Yep, that seems to be it.
2023-12-27 19:14:29 <fluix> nice, here's some info about abump in case you're curious: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Bumping_a_package_version
2023-12-27 19:14:45 <fluix> part of the abuild package
2023-12-28 21:33:09 <aparcar> Anyone from the alpine community at the Chaos Congress?
2023-12-28 21:51:04 <smcavoy> Can anyone merge !56932
2023-12-28 22:06:24 <ikke> smcavoy: maybe you can take over maintainership of ansible?
2023-12-28 23:12:31 <smcavoy> ikke: sure. Should I add that to the existing MR or create a new one?
2023-12-28 23:59:58 <minimal> from a brief sampling of packages with the same Maintainer as ansible he doesn't appear to have been active in Alpine since early 2019...
2023-12-29 01:38:37 <fluix> last activity was a little over half a year ago: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/34621
2023-12-29 02:29:29 <timlegge> #58062 fixes CVE-2023-7101
2023-12-29 02:29:41 <timlegge> !58062 fixes CVE-2023-7101
2023-12-29 04:25:10 <smcavoy> I have updated !56932 with myself as the maintainer now
2023-12-29 14:32:42 <EvTheFuture> omni: I've built linux-lts and zfs-lts fromm Alpine 3.18 and installed those two packagfes in Alpine 3.19. Then i do not get any panic during the startup process... So it seems to be something with ZFS 2.2. I have updated the upstream issue with versoin information of the installed packages... Unfortunately no one has touched the issue upstream so I'm not sure how to resolv this
2023-12-29 14:32:44 <EvTheFuture> issue. Ideas are welcome. Upstream Issue can be found here: https://github.com/openzfs/zfs/issues/15666
2023-12-29 15:07:52 <vkrishn> ikke: i now use 'apk policy' to figure out where to download the apk from, while creating "partial mirror"
2023-12-29 15:08:32 <vkrishn> any hint if it can be done via 'apk only' or any better method would be appreciated
2023-12-29 15:09:47 <vkrishn> i think this method can help create, "curated packages for run-from-ram or a sys-installer master disk" for schools/students
2023-12-29 15:20:23 <vkrishn> https://tpaste.us/9Mv7 - still WIP though
2023-12-29 15:22:09 <ikke> vkrishn: apk fetch --recursive
2023-12-29 15:22:37 <vkrishn> but how to sort the downloaded file into /community and /main ?
2023-12-29 15:23:55 <vkrishn> and it will try to re-download all, including busybox
2023-12-29 15:28:18 <vkrishn> this can also be used to - generate downloadable list for sharing with new users.
2023-12-29 15:28:53 <vkrishn> i noticed user asking "how can i make run-from-ram installs permanent ?"
2023-12-29 15:30:12 <minimal> what exactly do you mean by "permanent"? "lbu" stores changes
2023-12-29 15:30:34 <vkrishn> but not when you have no internet
2023-12-29 15:31:11 <vkrishn> check, dest=/media/usb/apks2/alpine/${VER}/${branch}/${ARCH}/
2023-12-29 15:31:49 <minimal> "lbu" needs Internet connection?
2023-12-29 15:31:50 <vkrishn> files in /cache here is not in question
2023-12-29 15:32:03 <vkrishn> reboot will
2023-12-29 15:32:49 <minimal> how does a reboot require Internet?
2023-12-29 15:33:00 <vkrishn> minimal: "my question/objective is how to create a partial mirror ?"
2023-12-29 15:33:08 <vkrishn> with all deps
2023-12-29 15:33:24 <vkrishn> help me there
2023-12-29 15:33:36 <minimal> vkrishn: I'm commenting on you saying "how can i make run-from-ram installs permanent ?"
2023-12-29 15:33:51 <minimal> to which I mentioned the lbu tool
2023-12-29 15:34:14 <vkrishn> ok, got it, thanks will come to it later
2023-12-29 15:35:01 <vkrishn> any suggestion on "partial mirroring"
2023-12-29 15:35:06 <vkrishn> ?
2023-12-29 15:35:53 <vkrishn> coz, i am wanting to push the script on my wiki page(live)
2023-12-29 15:37:18 <minimal> nope, I don't use run-from-ram
2023-12-29 16:03:19 <vkrishn> script will get simplified if, apk outputs ERROR msgs like,
2023-12-29 16:03:35 <vkrishn> ERROR: community/ttf-opensans-1.10-r1: package mentioned in index not found (try 'apk update')
2023-12-29 16:29:33 <vkrishn> will leave it here, will see how apk-tools v3 code comes out, and do a feature request if needed
2023-12-29 16:29:43 <vkrishn> thanks
2023-12-29 16:30:33 <vkrishn> will publish the script soonish
2023-12-29 22:52:55 <smcavoy> please review !56932
2023-12-29 23:00:17 <ptrc> fab's been inactive in alpine for quite a while, maybe we should just message him once about dropping maintainership of all the packages and then redistribute them to active people
2023-12-30 00:37:21 <celie> A few more candidates: @ScrumpyJack, Alex Yam (@ay), Roberto Oliveira (@rgdoliveira), Stuart Cardall (@itoffshore), Valery Kartel (@vaka)
2023-12-30 00:39:31 <celie> ScrumpyJack's inactivity has been mentioned before in !40273 and !49636
2023-12-30 00:40:52 <celie> I currently want to adopt FLTK from ScrumpyJack as i have a few aports using that: !56995
2023-12-30 00:47:17 <celie> As for Alex Yam, he maintains a few IRCds, unrealircd was already adopted by Willow earlier this year, and now i'm trying to arrange for SadieCat (who's the upstream) to adopt inspircd: !57855
2023-12-30 00:50:29 <celie> I've emailed @ay about inspircd, but have received no reply so far
2023-12-30 13:22:07 <ptrc> i.. think glab is doing some "funny" things to gitlab when using `glab merge --auto-merge=false`
2023-12-30 13:22:49 <ptrc> by which i mean, by trying to merge, it rebased the thing 10 times into the exact same commit
2023-12-30 13:23:15 <ptrc> https://ptrc.gay/OAFufXNZ
2023-12-30 13:25:37 <skarnet> if it's worth rebasing once, it's worth rebasing 10 times
2023-12-30 13:45:49 <humm> What’s better than a rebase? Ten rebases!
2023-12-30 17:03:26 <smcavoy> ptrc: if that gets ansible 9.1.0 merged sure :) Should I or someone with commit access email him?
2023-12-30 17:42:41 <ikke> smcavoy: you can
2023-12-30 23:25:55 <smcavoy> ikke: sent
2023-12-31 07:34:05 <fluix> how to go about debugging "ERROR: guikal-nginx-0_git20231231-r0.apk: package file format error"
2023-12-31 07:35:07 <fluix> APKBUILD and log here: https://paste.sr.ht/~fluix/0023c8f16c8b62dd4c7ba5f25816015e469e99c3
2023-12-31 08:05:04 <fluix> fixed it, had `install_if="$pkgname=$pkgname-r$pkgver nginx"` when it should be $pkgver-r$pkgrel
2023-12-31 09:26:18 <ikke> fluix: I saw you already found the issue I created for this
2023-12-31 09:26:39 <fluix> yep :)
2023-12-31 16:23:38 <konimarti> hi all, can someone give me a pointer on how to best proceed with !56431 ?
2023-12-31 16:23:45 <konimarti> first timer here
2023-12-31 16:25:07 <ikke> konimarti: we require (with only a few exceptions) all packages to be built from source 
2023-12-31 16:25:28 <ikke> So repackaging binaries is not acceptable 
2023-12-31 16:26:35 <konimarti> ikke thanks! I must have overlooked this but that clarifies the next steps.