2024-01-01 18:16:59 Can someone look at !58062 it Fixes CVE-2023-7101 a zero day that was used to exploit barracuda https://www.bleepingcomputer.com/news/security/barracuda-fixes-new-esg-zero-day-exploited-by-chinese-hackers/ 2024-01-01 18:17:15 anyone with this package installed is at risk... 2024-01-01 18:40:36 hi 2024-01-01 18:41:21 how do i upload a compiled binary apk package on alpine repo ?? 2024-01-01 18:42:50 ?/ 2024-01-01 18:45:24 howto? upload cmpiled apk binary on alpine repo ?? 2024-01-01 20:58:32 timlegge: I guess it should also be backported? 2024-01-01 21:10:59 I would say yes. It's a good idea, which probably means you'd like some merge requests for the older versions? 2024-01-01 21:17:11 And a # secfixes entry should be added as well, since there is no CPE match rules yet for the mentioned CVEs 2024-01-01 21:27:18 I wondered about that. It's not supported by apkbuild-cpan so I will add it manually 2024-01-01 22:33:18 ikke: please review !58062 if that looks fine I will send for the current supported 2024-01-01 23:59:13 timlegge: i think the version under secfixes should be 0.66-r0 instead of -0.66-r0 2024-01-02 01:10:03 celie: that should be better 2024-01-02 17:49:30 ncopa im circling back to that iproute2 'Elf64_Relr' on ppc64le and noticed this merge after adding the Efl*_Relr typedefs in commit ca7f2ab5 .... https://gitlab.alpinelinux.org/alpine/aports/-/commit/6e730c702c0a336b11584e8b7d250af95243e6a6/pipelines 2024-01-02 17:50:43 was there a new ppc64le build? 2024-01-02 18:51:19 In which cases -dbg subpackage is generated? 2024-01-02 18:55:45 when it is defined in APKBUILD to be created? 2024-01-02 21:14:51 Ermine: when there is a specific need 2024-01-02 21:48:56 I mean, is it automatic like -dev and -doc, or do I need to do it manually? 2024-01-02 21:49:44 You need to add the -dbg subpackage to the list of subpackages, everything else is automatic 2024-01-02 21:50:21 (except in some cases you need to explicitly disable stripping debug symbols during build 2024-01-02 21:50:22 ( 2024-01-03 08:41:11 mick_ibm: hi! yes. The problem was fixed in musl libc some time ago and it only needed a rebuild. 2024-01-03 08:41:55 mick_ibm: so that is solved. What is still an open issue is a bug in binutils' ld with LTO: https://sourceware.org/bugzilla/show_bug.cgi?id=30824 2024-01-03 08:43:10 I have a workaround already, where I have disabled LTO for ppc64le (c0e187f08f439bb51cbc39c2a176e850c355aaba). But it would be good to fix it properly. 2024-01-03 08:45:41 ok yea understood. ill bring it up in the right channels and see what i can do... im not super familiar with binutils 2024-01-03 19:47:40 looks like x86_64 CI builder is out of disk space 2024-01-03 20:18:24 Am I the only one anoyed restarting network restarts all kinds of services that really don't need to be restarted? 2024-01-03 20:18:45 Probably due to 'need net' 2024-01-03 20:25:19 use ifup instead? 2024-01-03 20:28:57 minimal: yeah, most of the time forget that can be used 2024-01-04 00:35:40 fabled: what do you think of !57498 and also backporting that to 3.19? #15628 2024-01-04 00:43:06 is the armv7 package builder stuck? 2024-01-04 00:48:00 and perhaps also build-3-17-x86_64? 2024-01-04 00:58:22 Could someone have a look at !57477, !56272 and !56157? 2024-01-04 00:59:08 It will soon be a month since i emailed the maintainers of those aports, and i have no heard anything back from them 2024-01-04 01:03:49 s/no/not/ 2024-01-04 01:05:16 have you checked if they have checked their spam folders? 2024-01-04 03:26:20 timlegge: is it really necessary to backport perl-spreadsheet-parseexcel 0.66 to 3.17-stable? That aport is in community, which is only officially supported for 1 stable release 2024-01-04 03:27:13 and 3.16-stable too 2024-01-04 03:27:43 cely: your call - I was looking at build that said those were supported for security fixes. 2024-01-04 03:28:04 looking at https://alpinelinux.org/releases/ 2024-01-04 03:28:44 I am good either way just wanted to make sure they were covered 2024-01-04 03:28:49 if needed 2024-01-04 03:28:50 Only applies only to aports in main/ 2024-01-04 03:28:57 s/Only/That/ 2024-01-04 03:29:11 okay, I will close 2024-01-04 03:38:12 otoh it's not a big change and covers an actively used hole 2024-01-04 03:43:08 The thing is, do we want to give users the impression that they can rely on aports in 3.16 and 3.17 community/ getting security fixes 2024-01-04 05:57:16 I think they should be able to rely on it if they make MRs for said fixes themselves 2024-01-04 06:08:00 Anyway, there're probably unpatched issues more serious than spreadsheet-parseexcel in 3.16 and 3.17 community/ that users still relying on that have to worry about 2024-01-04 06:11:43 yeah you're right 2024-01-04 06:17:09 fluix: It seems SQLAlchemy 2.0.25 wants the TypeAliasType typing extension that's only available in Python 3.12, so i switched to depending on py3-typing-extensions in !58378 2024-01-04 06:17:49 What do you think? Should we just delay that upgrade until Python 3.12 is merged? 2024-01-04 06:18:09 or is switching back to py3-typing-extensions alright 2024-01-04 06:19:27 probably fine to switch because we need to backport to 3.19, right? 2024-01-04 06:22:54 Well, according to the release notes it fixes some asyncio issue..so maybe a backport is needed 2024-01-04 06:23:53 I think SQLAlchemy follows semver pretty well so that makes sense 2024-01-04 07:05:19 cely: approved MRs, thanks! do you have two nicks on IRC btw? 2024-01-04 07:09:00 Yes, both celie and cely are me 2024-01-04 07:09:55 and you're welcome :) 2024-01-04 09:01:35 ncopa: thoughts on removing `need net` from syncthing? it listens on 0.0.0.0 or [::] by default and I'm not sure it errors out if it can't reach the network. 2024-01-04 09:50:51 a lot of people are updating my packages, if those see my message I'd like to thank you for doing that and I apologize that I'm not involved that much in these times, having hard times in my personal life 2024-01-04 09:51:32 markand_: sad to hear, but all the best! 2024-01-04 09:51:42 <3 2024-01-04 09:52:46 We'll keep your packages up-to-date :) 2024-01-04 11:06:09 fluix: dont know. what problem are we trying to solve by removing `need net`? 2024-01-04 11:06:38 it makes it restart if you restarting networking. just not ideal, really 2024-01-04 11:08:10 thought of it because ikke mentioned "Am I the only one anoyed restarting network restarts all kinds of services that really don't need to be restarted?" and I've been doing that occasionally 2024-01-04 11:08:35 *nod* 2024-01-04 11:08:47 slightly annoying at times 2024-01-04 11:09:09 alright, will take a closer look and send an MR 2024-01-04 11:09:20 but its simple and stupid. the alternative is to check the config if we bind to specific interface or address 2024-01-04 11:09:35 sshd seems to have logic for it 2024-01-04 11:10:15 sshd is kinda critical though as you'd get kicked out, so I think its worth the extra complexity 2024-01-04 11:10:29 for other servives im ok to do the stupid and simple 2024-01-04 11:10:50 even if it is slightly annoying 2024-01-04 11:11:42 stupid and simple as in leave `need net` or leave it to the user to add `need net` if they bind to non-0.0.0.0/[::] interfaces? 2024-01-04 11:14:40 I guess this means any software with configurable bind address/interfaces should have `need net`? 2024-01-04 11:22:35 I think I (and I assume ikke) prefer the latter. If you bind to specific interfaces you already need to be careful with need net because it's satisfied on any non-loopback interface 2024-01-04 11:31:51 i think most services that needs net already has 'need net'. What should the 'net' service be used for otherwise? 2024-01-04 11:32:19 it is a way to configure service to not start until network is up and running 2024-01-04 11:33:03 what harm does it do to restart syncthing even if it not needed? 2024-01-04 11:33:13 and what happens if we start syncthing before network is up? 2024-01-04 11:33:56 i would expect syncthing to go out and try sync with things, not jst apssively wait for connections, but I don't know 2024-01-04 11:35:21 if it passively just listens on 0.0.0.0[::] and only waits for incoming connections, then I'm ok with removing 'need net' 2024-01-04 11:35:43 but if it tries to open outgoing connections, then its probably better to leave it 2024-01-04 11:40:27 I guess that's my question too. I'm going based off https://github.com/OpenRC/openrc/blob/master/service-script-guide.md#be-wary-of-need-net-dependencies 2024-01-04 11:41:11 you're right that needless restarts aren't very harmful (mostly just time consuming) 2024-01-04 12:09:40 ncopa: isn't after better in that case? 2024-01-04 12:15:05 It causes things like docker (including all containers) to restart 2024-01-04 12:45:41 build-edge-armv7 is still stuck on py3-pebble? 2024-01-04 13:31:28 anyone else have boot failure after today's grub update? one of my systems now goes to "Welcom to Grub! 2024-01-04 13:31:32 and then resets 2024-01-04 13:32:46 damn 2024-01-04 13:33:01 I wanted to ask kind of the same question but was comparing files and it looked fine 2024-01-04 13:33:20 aquamo4k, what's your setup like? 2024-01-04 13:33:32 BIOS/EFI, what boot fs? 2024-01-04 13:34:04 intel x86_64 system; boot/root is ext4, rest of system on zpool 2024-01-04 13:34:55 going to get a usb stick and rescue this morning as I have time to debug further 2024-01-04 13:35:14 BIOS or EFI? 2024-01-04 13:35:37 UEFI 2024-01-04 13:45:30 ouch 2024-01-04 13:55:44 well, system is acting flakey now booting from USB stick so I think it's a HW problem i need to debug. 2024-01-04 13:55:54 will report back later today after work :-) 2024-01-04 14:16:50 aquamo4k: I'm seeing the same issues on a Chuwi minibook, apk upgraded right before I saw your message 2024-01-04 14:17:06 my system is also an x86_64 with UEFI 2024-01-04 14:21:21 I expect that you'd need to run "grub-install" (**with** the appropriate options after upgrading to the new Grub package... 2024-01-04 14:26:18 as the package update doesn't actually update the ESP bootx64.efi file (on UEFI) or the boot sector (on BIOS) or the modules in /boot/grub/ 2024-01-04 14:50:08 ncopa: why was Nomad also removed in https://gitlab.alpinelinux.org/alpine/aports/-/commit/234ade565c59592259d65fdb8909eaccf46be3bc, when it kept the MPL 2.0 license for 1.7 like it was for 1.6.4? 2024-01-04 14:50:59 filoozom: Nomad moved to BUSL with 1.7 2024-01-04 14:51:30 minimal: oh, hasn't been changed on GitHub then? https://github.com/hashicorp/nomad/blob/main/LICENSE 2024-01-04 14:51:33 BTW I was the Alpine Nomad package maintainer 2024-01-04 14:52:39 Ah well I see it in the code, my bad 2024-01-04 14:52:47 filoozom: look at that file again carefully 2024-01-04 14:52:57 especially lines 1-2 and 7-8 2024-01-04 14:53:12 and line 51 2024-01-04 14:53:14 filoozom: https://github.com/hashicorp/nomad/commit/b3e30b1dfa185d9437a25830522da47b91f78816 2024-01-04 14:54:21 I compared it with release/1.6.x where the file was already updated... My bad haha 2024-01-04 14:54:23 Thanks 2024-01-04 14:54:35 aquamo4k, quinq, durrendal: see my Grub comments 2024-01-04 14:54:51 I guess I'll have to build them locally then 2024-01-04 14:55:02 minimal: thanks for that tip. I was able to boot it up and view the root (ext4), and /boot/efi (vfat) ... 2024-01-04 14:55:12 filoozom: yeah that's what I'm doing. I'm also considering Incus as an alternative 2024-01-04 14:56:03 file in /boot like grub.cfg are new and a .backup exists but the x86_64 directory is stale, no updates 2024-01-04 14:56:45 aquamo4k: I *did* warn months ago that when Grub 2.12 came out for Alpine that there were likely to be update problems (as there recently on aarch64 for a Grub 2.06 revision). I did even propose a solution... 2024-01-04 14:57:26 aquamo4k: yes the Alpine package does run grub-mkconfig which regenerates grub.cfg on update 2024-01-04 14:57:43 minimal: cool, glad it is behaving as you predicted :-) 2024-01-04 14:58:14 okay, now I need to go back to #work office and have some meetings, will try manually rebuilding it up later or worse case just reinstall/restore 2024-01-04 15:00:26 15:26:18 minimal$ as the package update doesn't actually update 2024-01-04 15:00:32 That's good to know, thanks :) 2024-01-04 15:00:47 Installing for i386-pc platform. 2024-01-04 15:00:47 Installation finished. No error reported. 2024-01-04 15:03:13 minimal: interesting, I'll have a look at that. Do you mind sharing your APKBUILD for nomad? Do you have a repo somewhere maybe? 2024-01-04 15:03:38 You can find the latest version in the aports history 2024-01-04 15:03:43 quinq: you're using BIOS for booting - unless you run grub-install then the MBR (and adjacent sectors) won't be updated or the modules in /boot/grub/i386-pc/ directory and so you'll still be booting using Grub 2.06......but with a Grub 2.12 generated grub.cfg which may cause problems 2024-01-04 15:04:37 minimal, those are the messages output from grub-install :) 2024-01-04 15:04:56 Hence the “installation finished” :> 2024-01-04 15:05:16 quinq: oops, didn't read close enough, assumed that was grub-mkconfig output. Doh! 2024-01-04 15:05:41 No prob! 2024-01-04 15:06:26 !53133 was my attempt to come up with a solution for these sort of Grub update problems 2024-01-04 15:15:19 minimal: perhaps mention in #alpine-linux (again?) to give users a heads up and not have to repeat yourself too much, as others could point to that 2024-01-04 15:18:27 omni: I've been talking about this issue for many many months including in this channel... 2024-01-04 15:19:25 thanks for the fix suggestion minimal I'll give it a shot 2024-01-04 15:19:26 I actually feel that I've been banging my head against the wall as no-one seemed interested/concerned 2024-01-04 15:19:58 it's also pretty easy to miss things on IRC, I'm here most of the time but I don't think I saw anything about this personally. 2024-01-04 15:22:14 Is there a way do display (post) install messages with APK? 2024-01-04 15:22:22 Could be useful in this case 2024-01-04 15:22:46 quinq: yes, have the port-install script "echo" messages to the screen 2024-01-04 15:22:59 s/port/post/ 2024-01-04 15:23:35 that could be something to have in the meantime 2024-01-04 15:24:26 I've seen this mentioned before but, since I don't use grub myself, I haven't followed the issue and seen what has and hasn't been done to address it 2024-01-04 15:25:20 Thanks :) 2024-01-04 15:27:11 durrendal: from a quick glance of IRC logs, I mentioned the issue on Dec 20 & Oct 7 in alpine-linux, Dec 9 & Oct 11 in alpine-devel 2024-01-04 15:29:09 indeed this post to alpine-devel pointed out the potential for problems: "Oct 11 16:44:28 so when Grub 2.12 is finally released and packages for Alpine and it is installed then the grub trigger will update the grub config, which may potentially generate a config that does not work with someone's existing Grub 2.06 boottime code" 2024-01-04 15:32:59 quinq: the "problem" with having a post install message is "what exactly should it say"? something like "you need to run grub-install but you need to figure out yourself what options that you must pass to it"? Also for UEFI *as well as* running grub-install it is necessary to copy the EFI/efi/alpine/grubx64.efi file to EFP/efi/boot/bootx64.efi 2024-01-04 15:45:45 More like “Grub package was updated but not automatically installed on the boot medium” 2024-01-04 15:46:30 quinq: that wouldn't tell/help people what to do next though... 2024-01-04 15:46:42 That's not the purpose 2024-01-04 15:46:52 The purpose is to warn that the new version wasn't installed 2024-01-04 15:47:11 How to do it is their responsability (with the already existing help of the wiki, like a regular install) 2024-01-04 15:47:32 Separation of concerns, etc. 2024-01-04 15:47:40 I don't think there's anything on the Wiki that would help them figure out what exactly to do 2024-01-04 15:48:25 https://wiki.alpinelinux.org/wiki/Bootloaders 2024-01-04 15:48:30 as they need to use the correct grub-install options for their specific situation 2024-01-04 15:51:04 that document has generic instructions that doesn't, for example, match those used previously by setup-disk 2024-01-04 15:52:53 That's why it's not automatically done 2024-01-04 15:53:07 The user is in control, they just need to be warned it wasn't done automaticall 2024-01-04 15:53:10 y 2024-01-04 15:53:25 and also warned that they likely need to do something 2024-01-04 15:53:36 When there's an automatic solution, the notice can be removed 2024-01-04 15:54:31 telling them "Grub wasn't automatically installed" doesn't point out that there is a good chance they need to do SOMETHING to avoid boot problems 2024-01-04 15:55:36 "Grub was not automatically installed, if you do not run "grub-install" with the appropriate options, your system will fail to boot" 2024-01-04 15:55:39 and an automatically solution is hard to do, unless it only caters for systems installed by setup-disk with NO later boot-related changes/tweaks made by users 2024-01-04 15:55:59 honestly, something like that would have been enough to give me pause, not shut down my system after the upgrade, and figure it out. 2024-01-04 15:56:21 I don't know, it sounds logical to me that if somebody warns/notifies me about something, that means there's something to check/do 2024-01-04 15:57:14 i.e. some people have edited grub.cfg, /etc/default/grub, /etc/grub.d/ files in an attempt to batter Grub into working for LUKSv2 booting 2024-01-04 15:57:48 That's why there are the .apk-new files 2024-01-04 15:57:58 The notice implies that 2024-01-04 15:58:05 You can't point out everything in a notice 2024-01-04 15:58:18 If you want to do so, then write a new wiki page and point people to it 2024-01-04 15:58:26 But again, a notice is a notice, not a user manual 2024-01-04 15:58:47 And a notice is better than no notice at all 2024-01-04 15:59:05 My 2¢ 2024-01-04 15:59:39 and a mechanism to remember install-time settings and potentially use them automatically upon update is better still... 2024-01-04 16:00:04 Yes 2024-01-04 16:00:19 which is what my MR was intended to provide 2024-01-04 16:00:30 totally is, an automagic solution is the best future solution. The one that will prevent people from grumpily complaining about things in the IRC channel is a pkgrel with a post install message until that's in place 2024-01-04 16:05:18 How can I restart jobs? 2024-01-04 16:07:14 durrendal: "prevent people from grumpily complaining about things in the IRC channel is...a post install message" - that won't stop the (many) people who don't actually read any such messages that fly past during package updates 2024-01-04 16:08:28 nope it won't. It doesn't mean it doesn't have value though. 2024-01-04 16:08:53 you can lead a horse to water, you can't make it drink. That does not mean you should not try to take care of the horse. 2024-01-04 16:09:42 also, I think I should say, I am not grumpy about this. things break. a broken boot config isn't a big issue to me, but it could be to someone who's never dealt with it before 2024-01-04 16:09:54 and a simple message might stop them from rebooting before they can ask for help 2024-01-04 16:10:17 a "broken" bootloader is a different level of problem than an issue with an non-boot-related package 2024-01-04 16:13:03 Not sure if you're actually against adding a notice, and if so why 2024-01-04 16:13:32 Or just arguing that it exist some people who don't read 2024-01-04 16:13:39 quinq: I never considered months ago adding a notice as then I was trying to deal with the underlying problem 2024-01-04 16:14:08 But as it's been said several times already, those are not exclusive 2024-01-04 16:14:09 at which stage adding a notice didn't seem relevant (as Grub 2.12 hadn't come out yet) 2024-01-04 16:14:16 sure 2024-01-04 16:14:34 And also, it's not a complain, just a suggestion for improvement :) 2024-01-04 16:15:24 I guess I am grumpy as I've tried for some time to get this taken seriously to no avail 2024-01-04 16:15:44 I see, sounds fair :) 2024-01-04 16:16:44 and as I'm grumpy I'm not inclined to raise a MR to add such a post-install message, I'm not saying such a message wouldn't be (partially) helpful 2024-01-04 16:17:20 but rather I'm sayinbg that coming up with a solution would be more helpful/useful than adding a message 2024-01-04 16:17:22 I don't blame you at all, and also thank you for trying to get ahead of it. I'm not complaining about your work or you either. A post-install is literally just a bandaid here 2024-01-04 16:17:46 minimal gets a pass for being grumpy about anything, since their work is invaluable 2024-01-04 16:17:59 hahah agreed 2024-01-04 16:18:32 It's invaluable, that's why minimal doesn't get a raise 2024-01-04 16:18:55 durrendal: I was originally intended to get change into setup-disk *before* the 3.19 release last year so at least any new installs of 3.19 would have started "remembering" the grub-install settings used 2024-01-04 16:18:58 someone needs to pay first, in order for it to be raised 2024-01-04 16:18:59 minimal: is there anything left in your MR that would prevent it from being merged? if you're just waiting for the merge to occur, I understand why the post-install suggestion is frustrating 2024-01-04 16:19:43 durrenda: the MR's approach wasn't "accepted" but no alternative, or changes, were suggested 2024-01-04 16:20:18 it also required a MR for alpine-conf to change setup-disk which I didn't submit (was waiting to see reaction to the 1st MR) 2024-01-04 16:22:27 ah I see, without feedback this isn't going anywhere. And the changes that need to be made are bigger than just the one package. 2024-01-04 16:22:52 https://youtu.be/s1zTuwwO “Alpine Linux community react to minimal's grub change proposal” 2024-01-04 16:22:56 pj: unfortunately grumpyness (more frustration actually) is a negative factor in encouraging future work 2024-01-04 16:24:17 minimal: I'm well aware, I suffer from that sometimes 2024-01-04 16:24:35 durrendal: I did get feedback (not in the MR) and it wasn't positive 2024-01-04 16:24:39 I've been frustrated with alpine for a very long time :) 2024-01-04 16:25:27 pj: yes, I've considered giving up maintaining Alpine packages several times due to frustration about some things 2024-01-04 16:29:28 I think I never really considered giving up maintainership (unless it's package I don't use or plan to maintain and someone shows up to maintain it) 2024-01-04 16:30:10 but I do have an idea that has been floating around in my head for a very long time to "make own linux distro", with apk/musl 2024-01-04 16:31:54 a "make my own distro with apk/musl" idea i'd like is just lightweight isolated installs of apks from alpine or other dists, with no version-compat mess 2024-01-04 16:32:27 refcount and keep a master copy of library deps, then hard-link them into package-specific lib dirs 2024-01-04 16:33:08 so you can upgrade & install newer/bleeding-edge packages without breaking world or without breaking your own self-compiled apps that used stuff from -dev packages 2024-01-04 16:35:11 pj: unfortunately there have been some repeated Alpine dev "patterns/occurrences" in the past that frustrate me 2024-01-04 16:46:41 dalias: so nixos but apk/musl? :) 2024-01-04 16:46:44 or something similar 2024-01-04 16:46:59 fedora silverblue/ostree/guix 2024-01-04 16:48:43 pj, superficially maybe a little 2024-01-04 16:51:31 i'd really love to have a system where the "globally installed packages" are just system-level stuff needed to make everything work, and all the application software is also built, vetted, patched for policy, etc. by a distro (i.e. not like vendor provided snaps/flatpaks/etc. :vomit:) but isolated with its own lib ecosystem etc 2024-01-04 16:53:35 I kinda would like to see package manager that would have --user type of installation (akin to systemctl --user and user installation in macos/windows), sometimes I just want to install package from repos but don't have to worry about compiling etc. :) 2024-01-04 16:57:03 exactly 2024-01-04 16:57:19 there are two independent roles distros play that i want, just not together 2024-01-04 16:57:42 1. getting me a base system/platform up and running 2024-01-04 16:57:53 2. providing prebuilt application binaries from a source i trust 2024-01-04 16:58:36 and there would be a lot of value to having these two things versioned independently 2024-01-04 16:58:54 yeah that sounds a lot like system I would like to use 2024-01-04 16:59:15 (often it's desirable *not* to update applications unless you actually want new functionality, whereas system components are usually safe & beneficial to update) 2024-01-04 17:01:04 re: minimal gets a pass for being grumpy about anything, since their work is invaluable <---- that's a slippery slope 2024-01-04 17:01:22 'tis but a joke 2024-01-04 17:01:40 except for that last part of that message 2024-01-04 17:01:44 I totally agree in this instance, but just pointing out that all... suboptimal behavior shouldn't get a pass because someone is productive 2024-01-04 17:02:20 And why not? 2024-01-04 17:03:44 because then you end up with a very toxic environment that people are forced to deal with just because someone puts out a lot of work... I've seen distros basically fall apart because of that 2024-01-04 17:06:24 If someone valuable is frustrated by the state of the project, and their concerns are not addressed in any way I think it is perfectly fine for them to be in such "mood" 2024-01-04 17:07:11 even better, it doesn't have to be someone valuable, generally when any concern is ignored can and will make people discontent 2024-01-04 17:08:12 I just said a pass for anything was a slippery slope, not that it wasn't ever allowed 2024-01-04 17:10:50 anything too much is a bad thing 2024-01-04 17:31:36 ncopa was that binutils flto=auto bug happening on a power10? 2024-01-04 18:10:18 does apk handle apkindex and apk package each having different signing key fine (as long as both are trusted)? 2024-01-04 18:27:10 hi ikke, I'm talking with folks from opentofu, they are planning a first stable release on 10th, are there any plans to move it from testing :> asking since there are works to make script and update documentation before stable erlease 2024-01-04 18:27:28 install script* 2024-01-04 18:29:18 pj: yes, I was at least waiting for a stable release before moving it 2024-01-04 18:30:23 Not as critical, but 32-bits support would be nice, but I didn't take the time yet to figure out why the tests are taking it report it 2024-01-04 18:31:27 they do build for 32-bits on github, so it seems supported 2024-01-04 18:31:30 I could take a look 2024-01-04 18:40:24 It does build but there are some test failures 2024-01-04 18:51:18 thanks for all you do, it was my pre-coffee bad to type reboot before I noticed the grub update - I like the idea of dropping the initial grub install cmd line arguments on the disk somewhere for reference but in my case it's not hard to re-create. 2024-01-04 18:53:08 ikke: yeah, I see, investigating why and will forward build log to opentofu folks as well 2024-01-04 18:54:34 pj: thanks 2024-01-04 19:00:01 aquamo4k: that would work fine unless you (or whomever looks after an Alpine install) changed the way boot is configured after the initial installation, in which case any initial grub-install options won't necessarily match with the current reality and using them could in itself "break" booting 2024-01-04 19:02:45 ikke: https://github.com/opentofu/opentofu/issues/1069 (discussed on opentofu slack: there might be some flaky tests that rely on timing, and they will be most likely removed as those were inherited) 2024-01-04 19:03:10 pj: alright, thanks 2024-01-04 19:34:14 minimal: ack very true. i certainly had customizations i made over the last year or so myself. I might make a 'build-rescue.sh' service to run after each boot or something and see how I like it. 2024-01-04 19:53:13 my system returned to operation after i was able to re-run grub-install on my setup. Of course, this required me to : 1) mount my root and /boot/efi , bind and proc mount various things like /proc, /sys/ /dev /dev/pts etc. and then chroot into /mnt and run grub-install. I did this from the 3.19 extended iso file. 2024-01-04 19:54:16 yes would be almost impossible to do automatically without some remembering from setup and across all system changes over time. 2024-01-04 20:08:40 that's why my proposal was to (a) modify setup-disk to record the install-time settings to a config file, (b) introduce a command to run grub-install using that config file, (c) have grub's post-install *optionally* run the new command via a yes/no config setting, and (d) somehow "educate" users that if they want to use the new manual command or its automatic execution on grub upgrade then they would need to ensure that the config file 2024-01-04 20:08:40 settings were accurate (i.e. if they ever changed boot config in any way they'd need to update that config file) 2024-01-04 20:13:26 it sounds like a cool feature to me 2024-01-05 03:31:13 WhyNotHugo: testing/font-hanazono just had an empty maintainer field added in e054a5db (it didn't have one before that). However, looking through the git history, i see that you added that aport without listing yourself as maintainer, perhaps you would like to do that now? 2024-01-05 11:41:18 Is Carlo Landmeter around? 2024-01-05 11:41:48 i think so 2024-01-05 11:42:58 clandmeter: Oh hi! I created a aports-turbo version for OpenWrt and wanted to ask permission to use it http://evernet.duckdns.org:21001/packages 2024-01-05 11:43:08 right now we're using a dokuwiki cluster-fuck which is terrible 2024-01-05 11:46:19 clandmeter: I also found apkbrowser.git which I'd prefer over a Lua implementation, is there a reason it's not used instead? 2024-01-05 11:50:11 aparcar: the lua one is the initial version including some tools for update notifications 2024-01-05 11:50:47 the apkbrowser one is the py alternative made by the pmOS ppl 2024-01-05 11:50:59 its just the browser part 2024-01-05 11:52:03 clandmeter: so this here? https://pkgs.postmarketos.org 2024-01-05 11:52:08 i would also like to change to the py one, but it would mean we are missing the anitya integration 2024-01-05 11:52:25 yes thats the py one 2024-01-05 11:52:57 where did you find the apkbrowser.git repo? 2024-01-05 11:54:32 https://gitlab.alpinelinux.org/clandmeter/apkbrowser 2024-01-05 11:54:55 ah, i didnt know i pushed it 2024-01-05 11:55:59 so yes, use that intead if you dont need anitya 2024-01-05 12:03:41 thanks! 2024-01-05 12:06:19 aparcar: is this consuming apk3 pkgs? 2024-01-05 12:07:26 nope, opkg 2024-01-05 12:07:32 but we plan to migrate to apk eventually 2024-01-05 12:07:35 *I 2024-01-05 12:08:16 you modified it to read opkg? 2024-01-05 12:12:02 I created a script that polls our infrastructure and converts the OPKG package indexes to json and afterwards inserting it into the database 2024-01-05 12:12:26 OpenWrt does sadly no incremental building but rebuilds everything all the time so I'm not bothering downloading packages and checking contents etc 2024-01-05 12:12:47 I'll plan to extend the apkbrowser in case we use it, will let you know if that's of your interest\ 2024-01-05 12:13:12 for that matter I'd rename it to pkgbrowser but link to you pmos repository 2024-01-05 15:51:57 aparcar: sure, patches are welcome. 2024-01-05 17:01:37 for aports, should end to end tests ever be ran, or is it only unit tests? 2024-01-05 17:31:07 clandmeter: it's live now on a testing instance 2024-01-05 17:31:07 https://pkgs.staging.openwrt.org/packages 2024-01-05 17:31:21 but looks like you pmos and alpine versions diverged, is that for a reason? 2024-01-05 18:02:22 Kladky: up to you. generally tests involving significantly many dependencies aren't ran. 2024-01-05 18:53:41 aparcar: we are still running aports-turbo 2024-01-05 19:03:20 cely: please do. 2024-01-05 19:43:20 Can someone look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/58153 if it needs anything to be merged? 2024-01-05 19:50:10 pczerkas: I'm wondering if it's necessary to duplicate the squids 2024-01-05 19:50:15 Squid package 2024-01-05 19:52:13 also, if it were fine, you need provides="squid=$pkgver-$pkrel" right? 2024-01-05 19:52:43 or without the $pkgver-$pkgrel is fine since !squid is in depends 2024-01-05 20:00:20 ikke: those refresh_pattern options were removed some years ago from Squid. But using these options one can achieve very high cache ratios (assumming that he knows that it can violate HTTP). Occasionally people are asking on Squid mailing list to bring those options back, but main developers withstand. 2024-01-05 20:01:20 In some Squid installations having these options is highly desired 2024-01-05 20:06:58 > ignore-must-revalidate | that _does_ sound very broken 2024-01-05 20:08:42 what's the `linguas` list of languages used for? 2024-01-05 20:09:04 I know it's present in the squid APKBUILD (https://git.alpinelinux.org/aports/tree/main/squid/APKBUILD) but is it referenced somewhere? 2024-01-05 20:10:20 oh it's a compilation option 2024-01-05 20:26:21 pczerkas: i cannot compare it atm, but would a subpkg be an option? In the worst case, the subpkg can contain a separate build even 2024-01-05 20:27:57 well I have to digest it, it is my first alpine aport ;) 2024-01-05 20:28:39 I mean right now I don't know how to create subpkg 2024-01-05 20:38:55 pczerkas: can you explain what the differences are? 2024-01-05 20:39:56 ikke: main diff is that patches to Squid source are added 2024-01-05 20:40:12 so it needs to be compiled 2024-01-05 20:40:50 * re-adds ignore-must-revalidate and ignore-auth options in refresh_pattern config 2024-01-05 20:40:50 * fixes ignore-private option in refresh_pattern config for better cacheability 2024-01-05 20:40:50 > This patch makes following changes to Squid: 2024-01-05 20:41:04 yes, thanks fluix 2024-01-05 20:41:14 I think if we were to accept it, it should just be added to the main squid package 2024-01-05 20:43:49 fluix: you mean on Alpine side? Or on Squid project side? Because the latter is rather not possible ... 2024-01-05 20:43:56 Alpine side 2024-01-05 20:44:31 that would be great 2024-01-05 20:46:25 if you have any upstream links (like mailing list discussions about this feature's removal, etc.) could you link them in the MR? 2024-01-05 20:47:59 ok 2024-01-05 20:54:05 I'll that user has to opt-in (i.e. reconfigure Squid from its default settings in config files) to have that added code to be active runtime 2024-01-05 20:54:14 I'll add* 2024-01-05 20:58:29 so no probs for usuall Squid users should suffice 2024-01-06 01:18:38 WhyNotHugo: !58464 it seems downloading from OSDN is very slow, not sure what we can do about that, however the builders should use the cached file at distfiles.a.o 2024-01-06 02:09:52 https://pkgs.alpinelinux.org/packages?name=strongswan&branch=v3.17 2024-01-06 02:10:07 build-3-17-x86_64 is still stuck 2024-01-06 09:52:20 Just to make sure my quick skim through the log is correct: Alpine edge with grub on UEFI / x86_64 no longer booting is fixed by booting from alternative medium, chroot into the installed Alpine, reinstall grub using grub-install . Is that correct? 2024-01-06 09:53:15 yup 2024-01-06 09:53:21 I just did that on both my PC's 2024-01-06 09:56:07 Thx :-) It is actually surprising how stable edge is as daily driver :-) 2024-01-06 12:46:19 is there a standard/reccomended way of packaging things that have git submodules that arnt included in the release tarbal? 2024-01-06 13:44:15 amk: I only maintain a single package, so take my approach with a grain of salt, but you could take a look at testing/anki. 2024-01-06 13:48:20 Or community/netdata 2024-01-06 14:55:18 will do, thanks 2024-01-06 15:18:40 amk: if there are a few, just add each one as a source and move them to the right place. if there a lot, use git to clone them. 2024-01-06 15:19:45 For example, libsignal is a submodule here: https://git.alpinelinux.org/aports/tree/testing/mautrix-signal/APKBUILD#n26 2024-01-06 15:53:03 I don't know how to read this: https://gitlab.alpinelinux.org/fraolt/aports/-/jobs/1235246 2024-01-06 15:53:21 Is it failed, because it was queued for too long? 2024-01-06 15:53:58 fraolt: yes, the CI server for arm* arches is unavailable at the moment 2024-01-06 15:54:27 ok, thanks. 2024-01-06 16:05:24 aparcar: im not sure, its been some time since i played with it and eventually find out i could not get the anitya integration running easily 2024-01-06 16:06:10 not sure how different they are 2024-01-06 17:32:05 maribu: and if you're UEFI booting by the ALSO after running grub-install you copy EFI/alpine/grubx64.efi to EFI/boot/bootx64.efi 2024-01-06 17:32:20 s/the ALSO/then ALSO/ 2024-01-06 17:32:57 https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.20.0#EFI 2024-01-06 17:41:00 ikke: running update-grub shouldn't be necessary (as it was run by Grub post-upgrade already) 2024-01-06 18:16:24 Right 2024-01-06 18:16:40 I didnt saw any differences 2024-01-06 19:35:01 minimal, ikke: thx :) 2024-01-07 10:23:51 I guess the " is not needed here? --boot-directory="/boot https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.20.0#EFI 2024-01-07 10:24:12 shinobi57474858: correct 2024-01-07 10:24:15 I'll fix it, thanks 2024-01-07 10:24:55 ikke: cool thank you 2024-01-07 13:04:42 Regarding !56932 I received a reply from @fab he agreed that ansible can be moved to myself and other packages he is maintainer on can be released for others to take up 2024-01-07 13:15:45 smcavoy: 👍 2024-01-07 13:45:57 ikke: you even mentioned me in the wiki commit. how nice of you. :) 2024-01-07 13:53:51 :-) 2024-01-08 08:16:55 the grub thing seems to be pretty bad. should we revert or is it too late at this point? 2024-01-08 08:21:56 Too late 2024-01-08 08:22:29 I suppose 2024-01-08 08:25:54 Reverting it would probably break it again for those who have fixed it 2024-01-08 08:45:14 what i thought 2024-01-08 09:36:24 Is there a way to query the installation date of a package with apk? 2024-01-08 09:36:41 apk info $package doesn't seem to give it 2024-01-08 09:39:23 I don't think apk keeps track of that 2024-01-08 09:41:06 ok, thanks ikke 2024-01-08 09:41:16 As an alternative I suppose I can look at the actual files 2024-01-08 09:41:33 -rwxr-xr-x 1 root root 970432 Jan 4 12:18 /usr/sbin/grub-install 2024-01-08 09:41:39 10:41:35 up 11 days, 9:37, 0 user, load average: 2.16, 2.14, 2.11 2024-01-08 09:41:50 oh my, does that mean I shouldn't reboot? :D 2024-01-08 09:42:04 Where's that “grub issue” documented? 2024-01-08 09:43:32 https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.20.0 2024-01-08 09:46:53 Ahhh, ok, “that” issue 2024-01-08 09:46:57 Thanks again ikke 2024-01-08 10:43:23 clandmeter: both apkbrowser repos for alpine and pmOS are different, where should I send PRs? 2024-01-08 12:35:16 Hey, anyone here that made an APKBUILD file and packaged anything for Alpine? trying too myself but its whining the APKINDEX.tar.gz file has an untrusted signature 2024-01-08 12:44:55 Did you add the generated key to /etc/apk/keys? 2024-01-08 12:48:10 ikke: yeah the public key is there but not sure if i signed it correctly 2024-01-08 12:49:30 zestyluna: when you run abuild-keygen -ain, it should set everything correctly 2024-01-08 12:49:47 (that will generate a new key though) 2024-01-08 12:49:57 alright will try 2024-01-08 12:52:25 still whining about untrusted signature, how do i sign the package using that file? 2024-01-08 12:58:29 zestyluna: abuild signs the packages with PACKAGER_PRIVKEY, which is usually set in ~/.abuild/abuild.conf 2024-01-08 12:58:57 the corresponding pub key should be in /etc/apk/keys for apk to trust it 2024-01-08 12:59:20 alright first time i am trying to build an Alpine package so a n00b at this yet 2024-01-08 12:59:22 Is it ok if I bump package version and switch its source in one commit? 2024-01-08 12:59:47 i'd say yes 2024-01-08 13:01:16 ncopa: it is there but still getting ERROR: APKINDEX.tar.gz: UNTRUSTED signature when trying to run abuild -r 2024-01-08 13:12:59 is there any way to ignore signing the package? 2024-01-08 13:14:51 or can anyone else tries if this works https://pastebin.com/jcbffuP3 (trying to build hyfetch from pypi) 2024-01-08 13:22:57 got it too build now 2024-01-08 13:23:33 and it works 2024-01-08 13:42:43 aparcar: what you prefer, not sure which one you used now? 2024-01-08 13:42:50 i think both are pretty stale 2024-01-08 13:43:20 would be nice if we could incorporate differences as options 2024-01-08 14:13:55 will do 2024-01-08 14:40:37 stupid question but is there any Raspberry Pi images for Alpine edge? or do one have to download 3.19 and change the repos out? 2024-01-08 14:44:15 zestyluna: technically pmos is an alpine release with a rpi image :3 2024-01-08 14:45:15 novaandromeda: heh i tough pmos was mostly for phones? :p 2024-01-08 14:45:29 it is, but it also supports rpis 2024-01-08 14:47:41 i see whats the difference between postmarket os on a Pi4 and Alpine edge? just installed this system and set it up was just wondering if there was a more updated image 2024-01-08 17:02:22 so no comments so far on !58567? 2024-01-08 17:21:33 lgtm. was there a somewhat related change to setup-disk? i forget. 2024-01-08 17:22:42 invoked: this MR is just display a warning, so no setup-disk change required 2024-01-08 17:23:24 I don't want to be a pain… 2024-01-08 17:23:30 But this looks like a huge message 2024-01-08 17:23:50 Couldn't it be “simplified” into a shorter warning, and a file in /usr/share/doc maybe? 2024-01-08 17:23:54 quinq: well people then cannot claim they didn't see it? 2024-01-08 17:24:27 This doesn't look like it'll print what's intended: printf '*If* you installed Alpine originally via 'setup-disk' and you did NOT:\n\n' 2024-01-08 17:24:45 quinq: ? 2024-01-08 17:24:55 The single-quoting around setup-disk 2024-01-08 17:27:06 sigh, yes you're right, but rather than pointing out issues with the actual script it is more important for people to decide whether or not the principle is accepted or not.... 2024-01-08 17:27:34 That's not exclusive :) 2024-01-08 17:28:12 I mean now it does two things at once 1/ prepare the actual change 2/ warn 2024-01-08 17:28:19 Could be fine, but that's new 2024-01-08 17:28:23 quinq: ok, but the comments in the past few days in my other, older MR, all concentrated on "bugs" with it and no-one made any decisions about whether its "concept" was acceptable or not... 2024-01-08 17:29:25 fair enough 2024-01-08 17:29:29 quinq: it doesn't really "prepare the actual change", it suggests what it **thinks** is the correct command to fix things. However it is possible what it suggests could be wrong in a particular situation 2024-01-08 17:30:31 I suppose that if you came to the conclusion it cannot be fully automated, then it's good to generate a suggestion line, then tell about it 2024-01-08 17:30:44 But I don't think it needs to be that long and dramatic in the redaction ^^ 2024-01-08 17:30:52 minimal: just wanted to say, thank you for adding a post-installation message, and continually helping people troubleshoot this issue. I know it's frustrating as hell when you have a better solution pending, but it is appreciated 2024-01-08 17:32:07 i'm of the opinion that alpine ought not to get too much into trying to bubblewrap every footgun. but that's my view 2024-01-08 17:32:32 Maybe it could be shortened into (a less terse way) “New grub version that would need reinstalling it on disk / The script suggests this command: $cmd / Be careful that this command might not be accurate and should be verified before running” 2024-01-08 17:32:52 durrendal: I wouldn't say the other MR is necessarily a *better* solution, it's just the only solution that anyone has offered to date (beyond "do nothing, user's should know what they've doing") 2024-01-08 17:33:50 I think that ultimately yes they should, *but* it's nice to have it automated like you did, then we just need to check :D 2024-01-08 17:35:22 And I do mean that as “positive” criticism if it can be viewed that way, I join durrendal in his thanks to your work :) 2024-01-08 17:37:49 minimal: entirely fair, there's no such thing as a perfect solution anyways. But I mean it nonetheless, both solutions are better than just letting things break. 2024-01-08 17:42:18 invoked: I'd expect that bootloader-related issues are quite important to avoid compared to just "normal" package issues 2024-01-08 17:42:53 durrendal: true....but so far no sign of any solution being put into place 2024-01-08 18:48:19 as a side note to the Grub problem, I'm seeing fiddly issues relating to ESP being VFAT and mounted with case-insensitivity, e.g. a "install -d /boot/efi/EFI/alpine/grubx64.efi /boot/efi/EFI/boot/bootx64.efi" fails if there's a BOOTX64.EFI file in the destination 2024-01-08 18:49:44 as "install" seems to be treating bootx64.efi & BOOTX64.EFI as the same file, yet it won't replace "it" 2024-01-08 19:02:22 ncopa im still looking into that flto compile bug on ppc64le and hope to have updates soon. likely post in sourceware bug but didnt wanna leave you in the dark :) 2024-01-09 03:23:47 Hello all, with next version of Pinta planning to depend on dotnet8, I'd like to get dotnet8 into testing for further testing and eventual inclusion into community. Would someone be so kind as to review the MR? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49831. 2024-01-09 03:41:51 I'm looking at some of these patches: did dotnet think alpine was the only musl distro or something? 2024-01-09 03:47:23 Yes and no. Dotnet's build system is complicated, so when bootstrapping musl support, Alpine Linux was the only target that was initially planned for. Even then, until I arrived on the scene to get the dotnet6 aport going, it was still a second class citizen. I've since worked on improving upstream support, and now that void is working on their own 2024-01-09 03:47:23 package, some code is being refactored. Most of these patches are backports and will show up in later servicing releases. 2024-01-09 03:48:14 I see, thanks 2024-01-09 06:52:30 how can I set proxy for abuild, my network has banned some source website 2024-01-09 06:52:43 :( 2024-01-09 06:58:03 oh, I find it just support http proxy but not socks 2024-01-09 06:59:19 Where did you find that from? 2024-01-09 07:04:26 abuild uses curl/wget to fetch artifacts 2024-01-09 07:29:24 minimal: I usually interpret the "draft" status as "work in progress", "not ready yet" or "not ready for review yet" 2024-01-09 09:03:21 here is possible alternatives for critical upgrades. <- https://tpaste.us/YYj6 2024-01-09 10:31:09 Good morning, and happy new year if I haven't wished for it yet (or even if I have)! 2024-01-09 10:31:41 could someone please merge !58632 whenever convenient? tiny bugfix. Thanks! 2024-01-09 12:38:02 PureTryOut: hey o/ do you remember what was the "configuration issue" from https://github.com/flathub/com.valvesoftware.Steam/issues/1088 ? 2024-01-09 12:38:34 I encounter the same "failed to map segment from shared object" issue while starting Project Zomboid in native mode 2024-01-09 12:41:19 Pfew, sorry I honestly do not know. I should've probably given more information at the time lol 2024-01-09 12:41:30 :') 2024-01-09 12:41:40 I know that feeling 2024-01-09 12:42:15 today I got this crazy log line 2024-01-09 12:42:16 Exception in thread "main" ERROR: General , 1704803438170> java.lang.UnsatisfiedLinkError: /tmp/lwjglstacy/3.2.3-build-13/liblwjgl.so: /tmp/lwjglstacy/3.2.3-build-13/liblwjgl.so: failed to map segment from shared object 2024-01-09 12:42:43 so maybe there still is something wrongly configured with lwjgl? or our /tmp mount options 2024-01-09 12:45:37 and you did not created issue on aports before 31 mar and 01 jun 2023 2024-01-09 12:50:45 ncopa: It was a marked a Draft as it was waiting for *some* input/discussion... 2024-01-09 12:51:33 e.g. there's no point anything reviewing the code in the change if the principle behind it isn't going to be accepted 2024-01-09 12:51:43 s/anything/anyone/ 2024-01-09 14:24:48 minimal: understood. thanks! 2024-01-09 14:25:21 im not sure I like the approach, but I currently have no better alternatives. 2024-01-09 14:25:31 it feels complicated and fragile 2024-01-09 14:26:08 the warning is pretty scary, and threatening 2024-01-09 14:26:31 and I am curious how arch linux and others deals with this 2024-01-09 14:28:58 Arch just have a news post that users need to read 2024-01-09 14:29:32 https://archlinux.org/news/grub-bootloader-upgrade-and-configuration-incompatibilities/ 2024-01-09 14:33:11 ncopa: well one alternative was to (optional) automatically run grub-install on updates based on stored grub-install args recording during initial setup-disk run, as per my original MR... 2024-01-09 14:35:47 ikke: hmm, that Arch-described is a slightly different root cause than the ~"bli" issue - fwsetup was already present in Grub 2.06 but that sounds like the generated grub.cfg section regarding that also changed 2024-01-09 14:37:38 ikke: I guess they only saw that because they were using a 2.12RC that didn't include the new BLI stuff 2024-01-09 14:40:39 ncopa: re other distros there is also this: https://forum.endeavouros.com/t/attention-grub-update/36172 2024-01-09 14:44:43 ncopa: the warning text I used was intended to be "scary" so that users would be likely that actually read rather than just ignoring it and then later claiming they didn't see it 2024-01-09 14:48:48 ncopa: a warning doesn't really cater for things like automated management of systems by stuff like Ansible/Puppet/Chef/Salt rather than by users directly, which is why I believe some form of automated means to run grub-install upon updates is the only way forward 2024-01-09 14:54:30 minimal, ncopa, possible alternatives for critical upgrades. <- https://tpaste.us/YYj6 2024-01-09 14:56:23 what is a "critical upgrades"? The underlying situation being discussed is that grub-install should, in theory, be run on ANY updates of the Grub package, whether major or minor 2024-01-09 14:58:02 in that EndeavourOS link I posted the comment by "dalto" describes the situation well 2024-01-09 14:59:44 ok then re-phrase it, "for upgrades i could suggest pre-install checks" 2024-01-09 15:00:03 your is post-install check, this is a pre-install method 2024-01-09 15:00:37 what check(s) are you suggesting? 2024-01-09 15:46:35 its json file, so instructions like -- ifver <= 2.06 , can be one of data nodes 2024-01-09 15:46:56 "data structure of json can be normalized over time" 2024-01-09 15:54:37 update.apk is more of an extention to apk 2024-01-09 15:54:51 but this could help in centralizing all msgs 2024-01-09 16:52:15 is there any upstream documentation on this grub breakage? 2024-01-09 16:52:46 ncopa: It's not a breakage in that sense 2024-01-09 16:53:22 They added a new module, which is supposed to be installed with grub-install. 2024-01-09 16:55:50 is there any grub documentation telling that we need to run grub-install after each grub upgrade? 2024-01-09 16:55:56 exactly, there is no breakage as they expect grub-install to be run 2024-01-09 16:56:42 I guess it is a case of "why would you update the Grub software but then not actually 'install' it on the machine for booting?" 2024-01-09 16:57:26 i know they expect grub.cfg to be re-generated each kernel update or grub update 2024-01-09 16:57:26 "and have it regenerate the Grub config using the newer version of software but then not run the newer version of Grub during actual boot?" 2024-01-09 16:59:04 ncopa: it sounds like you're trying to find justification for doing nothing 2024-01-09 16:59:49 regardless of whether or not upstream Grub has documented it (whether properly" or not at all) the issue still exists and is understood 2024-01-09 17:04:10 well, im trying to understand how this is supposed to work 2024-01-09 17:04:20 and how fedora and debian implements it 2024-01-09 17:04:40 apparently arch linux just post an announcement that you need to manually run grub-install 2024-01-09 17:05:10 and so did EndeavourOS 2024-01-09 17:05:32 ncopa: minimal linked in the first MR to https://salsa.debian.org/grub-team/grub/-/blob/master/debian/postinst.in#L602 2024-01-09 17:05:35 for debian 2024-01-09 17:05:37 or was it you 2024-01-09 17:07:39 right, we just need a 802 lines long trigger script. easy peasy 2024-01-09 17:07:42 it was ncopa that posted that. For Debian (from memory) postinst is run for BOTH new installs and upgrades and, as that script is large, from a brief examination I didn't figure out if it ran grub-install only on initial install or on updates also 2024-01-09 17:08:05 yeah, and it also runs update-grub 2024-01-09 17:08:15 which is a short wrapper 2024-01-09 17:08:50 how does fedora? 2024-01-09 17:09:04 i see they have a script that generates the grub.cfg at least 2024-01-09 17:09:06 https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/grub2.spec#_347 2024-01-09 17:11:31 they do grub2-mkconfig: https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/99-grub-mkconfig.install#_55 2024-01-09 17:11:41 but I cannot find where they do the grub-install 2024-01-09 17:14:22 gotta go, havea nice evening 2024-01-09 18:12:53 @ncopa I see grub installing scripts for https://www.freedesktop.org/software/systemd/man/latest/kernel-install.html in /usr/lib/kernel/install.d/ directory 2024-01-09 18:13:28 so whenever kernel-install is triggered they will get executed 2024-01-09 18:14:07 see https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/20-grub.install and https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/99-grub-mkconfig.install 2024-01-09 18:14:36 these are the postinstall sort of scripts which get put into install.d dir 2024-01-09 18:16:22 ehm systemd :) 2024-01-09 18:47:26 but neither of 20-grub.install and 99-grub-mkconfig.install actually executes grub-install. They only generate the grub.cfg to find the installed kernel 2024-01-09 19:00:25 @ncopa I think grub-install is run by Fedora installer anaconda 2024-01-09 19:02:08 it can also be run manually if needed grub2-install /dev/sdb etc. 2024-01-09 19:08:26 see https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/storage/bootloader/grub2.py#L432 2024-01-09 19:25:02 so they don't run grub-install on every kernel or grub update, just like us. They will end up with unbootable system like we did then 2024-01-09 19:25:14 at some point... 2024-01-09 19:27:28 arch doesnt just have an announcement, post upgrade of thr grub package says you need to run grub-mkconfig and grub-install 2024-01-09 19:28:44 seems so 2024-01-09 19:29:23 i dont like this.... 2024-01-09 19:30:26 is the alpine issue that we don't install but *do* regenrate config? 2024-01-09 19:30:35 correct 2024-01-09 19:30:56 we re-generate config due to kernels may be added/deleted/updated 2024-01-09 19:31:45 fluix~: read the comment by "dalto" in this discussion for a simple explanation: https://forum.endeavouros.com/t/attention-grub-update/36172 2024-01-09 19:32:00 ok nvm, I was wondering if we can (1) disable that to prevent future issues while also (2) setting up thr automated fix for future installs (or letting people turn it on) 2024-01-09 19:32:29 ncopa: or that the updated Grub may have changed the templates used for configuration 2024-01-09 19:32:46 that's another reason that grub-mkconfig is autorun 2024-01-09 19:33:02 ncopa, with systemd-boot it always updates the bootloader along with config but ofcourse its not grub 2024-01-09 19:33:43 on my arch system I see that happening often with upgrades, although I grow nervous when it happens :) 2024-01-09 19:33:56 problem with automatically running grub-install is that its complicated to figure out how/where to install it 2024-01-09 19:33:56 khem: fundamentally this is not a Grub-specific issue, the same applies to syslinux and limine etc AFAIK 2024-01-09 19:34:11 isn't "Also, if you ever add/remove a kernel and run grub-mkconfig you will could cause the same situation as #2" still better that what happens now? 2024-01-09 19:34:12 yeah, i think we have had similar issue with syslinux 2024-01-09 19:34:26 yes its upto packaging and upgrade policy I guess 2024-01-09 19:34:45 ncopa: it is unlikely to be seen with syslinux as upstream dev has been dead for several years and so no new functionality appears 2024-01-09 19:35:07 true 2024-01-09 19:35:16 but the "theorectical" issue remains for syslinux 2024-01-09 19:35:30 it has happened in the past 2024-01-09 19:35:41 I read somewhere that grub-install and grub-efi do not work well together 2024-01-09 19:35:52 basically bootloaders are being installed at original installation time and never again being updated despite revised versions of the bootloader packages being installed 2024-01-09 19:36:07 so maybe its not a simple thing to just run grub-install and be done with it 2024-01-09 19:36:31 i suppose that is why arch lets user deal with it 2024-01-09 19:36:38 e.g. if you installed Alpine with Grub 5 years ago then your current booting Grub will NOT contain the security fixes made to Alpine's Grub since then 2024-01-09 19:36:46 correct 2024-01-09 19:36:56 khem: run it with WHICH specific arguments? 2024-01-09 19:37:30 it was on some internet article AFAICT dont have it stored 2024-01-09 19:37:36 let me find 2024-01-09 19:37:58 khem: don't bother, there IS NO one set of arguments to use in all cases 2024-01-09 19:39:06 nm browser history has it from months ago :) https://thomas-leister.de/en/repair-fedora-efi-bootloader/ 2024-01-09 19:39:08 minimal: the good thing with your https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/58567 is that it only warns, and give possible solution 2024-01-09 19:39:24 and it only executes on upgrades 2024-01-09 19:39:41 ncopa: that was a specific design intention 2024-01-09 19:40:31 the same way that my earlier proposal also didn't execute automatically and required the user to decide to enable it 2024-01-09 19:41:04 yeah I think a message on bootloader update is a good idea instead of trying to do it via some postinstall scripts automatically and rendering the system hosed. user will blame alpine for that :) 2024-01-09 19:41:53 khem: that article does NOI provide a single set of grub-install arguments to use in all situations 2024-01-09 19:42:19 yeah right, 2024-01-09 19:42:22 i think khem was referring to "I read somewhere that grub-install and grub-efi do not work well together" 2024-01-09 19:42:41 yep that was the context 2024-01-09 19:43:03 IRC is bad with contexts, we need threads like slack or matrix :) 2024-01-09 19:43:19 khem: some users will blame for anything - that there was no warning, that there was a warning but no mechanism to *force* them to read it, that they're using automated systems like Ansible etc to update their machines which obviously ignores any warnings, etc 2024-01-09 19:43:34 :) 2024-01-09 19:44:24 no way out I guess 2024-01-09 19:44:25 im starting to think about minimal's idea about storing the exact grub-install command, and execute it from trigger (on upgrades) 2024-01-09 19:44:28 "grub-install and grub-efi do not work well together" - that's confusing as grub-install is a script provided by Grub whereas grub-efi is an Alpine subpackage for part of grub 2024-01-09 19:44:52 ncopa: *optionally* execute it from trigger on upgrades ? 2024-01-09 19:44:54 grub is grubby 2024-01-09 19:45:01 yup, optionally ofc 2024-01-09 19:45:19 as some people (like me) don't use setup-disk at all 2024-01-09 19:45:55 as some people change their machines' "layout" after the initial install and using the original grub-install setting later could then break their machine 2024-01-09 19:45:55 I was thinking something along the lines: if /etc/grub-autoinstall exists, then execute it 2024-01-09 19:46:13 setup-disk could store the grub-install command there 2024-01-09 19:46:35 and if users have something weird, they can stuff in whatever they want to happen on grub updates 2024-01-09 19:46:40 ncopa: yupe, for my own case I have my disk image creation script populating the config values with the right settings 2024-01-09 19:46:54 the offical Alpine cloud image would need to do similar also 2024-01-09 19:48:10 of course modifying setup-disk only sorts the matter out going forward for new installs (which is why I'd hoped it would have been implemented in time for 3.19.0 last year) 2024-01-09 19:48:55 it wouldn't handle the problem for existing installs until users modify the stored config setting and enable the auto execution 2024-01-09 19:49:49 correct 2024-01-09 19:50:10 and it would make sense for setup-disk/setup-alpline to display some message to users after install about the settings being stored and perhaps to ask them if they want to enable future auto execution 2024-01-09 19:50:38 for setup-disk i'd say we can enable it by default 2024-01-09 19:50:55 user who don't want it can delete it 2024-01-09 19:59:10 ncopa: you'd have to "tweak" the values setup-disk stores though... 2024-01-09 19:59:24 it is installing Alpine in a chroot 2024-01-09 19:59:44 so the eventual device name is not used 2024-01-09 20:00:22 i.e. grub-install for *BIOS* requires the disk device name, /dev/sda, /dev/vda, /dev/nvme0n1 2024-01-09 20:01:28 whereas whilst booting the Alpine installer from USB stick could mean at that point in time /dev/sda is the installation media, not the new installed Alpine device ;-) 2024-01-09 20:01:41 it could be /dev/sdb 2024-01-09 20:12:27 yes ofc 2024-01-09 20:14:14 chromium crashes on me every 10 mins or so. annoying 2024-01-09 20:15:08 minimal: thank you for your help solving this. and for being so patient 2024-01-09 20:15:17 have a good evening! 2024-01-09 20:22:37 \o/ 2024-01-09 20:34:56 anyone mind taking a look at !58031 and letting me know if there's anything else that needs to be done on it? 2024-01-09 20:37:33 durrendal: I believe I packaged this and maintained it for Debian in the mid-to-late 90s ;-) 2024-01-09 20:38:58 the git repo ChangeLog file only goes back as far as 2000 though 2024-01-09 20:41:06 durrendal: note, for www.pilot-link.org mentioned in the APKBUILD file I'm seeing a "domain parking" page 2024-01-09 20:43:31 nice little throw back right? I recently repaired my tungsten t and noticed it wasn't in the repos, figured someone somewhere would appreciate having it since 20+ year old software isn't super fun to hand compile :) 2024-01-09 20:43:52 good catch, I can change that to the desrod repo, since it seems to be active 2024-01-09 20:47:14 I found my old Palm Pilot late year but it's faulty 2024-01-09 20:47:20 s/late/last/ 2024-01-09 20:50:14 honestly the fact that any of them still work at this point is pretty cool 2024-01-09 20:50:16 https://www.palmdr.com/ 2024-01-09 20:50:39 I've gotten parts from this guy in the past, super reliable. If for some reason you want to fix it haha 2024-01-09 20:52:18 minimal: thanks for taking the time to look :) I appreciate it 2024-01-09 20:57:27 Hey guys, I also posted this in #alpine-linux, but I feel like there's improvements to bring here: 2024-01-09 20:57:27 My issue is: I've got a PXE enivronment, booting an Alpine Netboot v3.19. One of the kernel params are ip=dhcp. The issue is that, if I try to boot a machine that has two NICs, I can't select which NIC will use DHCP. Sometimes, from the two NICs, Alpine picks the one that's disconnected so the DHCP fails => permanent DHCP request loop 2024-01-09 20:57:27 Does anyone know how to fix this? 2024-01-09 20:57:34 Does anyone 2024-01-09 20:58:21 Please don't cross-post, I've already answered you in #alpine-linux 2024-01-09 22:37:16 @hac3ru on Virtualbox there is option to set order of NICs --nic-boot-prioN=priority see https://www.virtualbox.org/manual/ch08.html#idm3991 2024-01-09 22:37:44 I am not sure if you are using VMs or bare metal 2024-01-10 02:34:36 I'm writing APKBUILD, do I need to add gcc and make to "makedepends"? 2024-01-10 02:34:48 nope 2024-01-10 02:34:54 they're in build base 2024-01-10 02:38:13 where can I check which package is in build base? 2024-01-10 02:49:00 apk info -R build-base 2024-01-10 02:49:55 or look at the aports/main/build-base/APKBUILD file 2024-01-10 03:43:47 thanks! 2024-01-10 03:51:29 Out of curiosity, what package are you writing the APKBUILD for? 2024-01-10 04:11:58 https://github.com/xmake-io/xmake 2024-01-10 04:27:58 Looks interesting, are you planning to submit it on Gitlab? 2024-01-10 04:42:07 yes, I'm still checking 2024-01-10 04:43:00 It is more like a Windows tool :P 2024-01-10 08:55:39 good morning! any tips how to debug chromium segfault? 2024-01-10 08:56:04 i have a backtrace that ends up in strlen, but no symbols in chromium binary 2024-01-10 08:57:09 so, no way to know what was passed to strlen? 2024-01-10 08:57:18 correct 2024-01-10 08:59:55 there's no way to know *who* called strlen, but if it's the musl function, you should be able to list locals IIRC 2024-01-10 09:04:03 seems like i can build chromium locally wit symbol_level=1 2024-01-10 09:06:13 ok, i caught it in gdb. I suppose I can find which binary it happens in 2024-01-10 09:06:20 (gdb) bt 2024-01-10 09:06:20 #0 0x00007ffff7fb5458 in strlen (s=) at src/string/strlen.c:17 2024-01-10 09:06:20 #1 0x00005555565e693d in ?? () 2024-01-10 09:08:21 and see where that is in /proc//maps 2024-01-10 09:09:50 555555554000-555556403000 r--p 00000000 fd:00 1966099 /usr/lib/chromium/chromium 2024-01-10 09:09:50 555556404000-555561057000 r-xp 00eaf000 fd:00 1966099 /usr/lib/chromium/chromium 2024-01-10 09:09:50 555561057000-55556183d000 r--p 0bb01000 fd:00 1966099 /usr/lib/chromium/chromium 2024-01-10 09:10:04 its in chromium. i need rebuild with symbols :-/ 2024-01-10 09:12:20 Days without chromium crashes: 0 2024-01-10 09:18:14 im counting the minutes here, not days 2024-01-10 09:34:36 wiki says this: "Maintainer" Name and email address of the maintainer of the project (not your package). 2024-01-10 09:35:10 Where? 2024-01-10 09:35:44 is this means upstream project's maintainer? 2024-01-10 09:35:50 https://wiki.alpinelinux.org/wiki/APKBUILD_Reference 2024-01-10 09:36:56 That is incorrect 2024-01-10 09:37:00 or just the same people who make the APKBUILD file 2024-01-10 09:37:17 https://wiki.alpinelinux.org/w/index.php?title=APKBUILD_Reference&diff=prev&oldid=25476 2024-01-10 09:38:21 The Maintainer field is not a variable either 2024-01-10 10:00:19 ncopa i was able to reproduce the freerdp bug on my ppc64le VM: https://sourceware.org/bugzilla/show_bug.cgi?id=30824 how can i view one of the build logs when flto=auto was removed? like when the build passed for that specific package... i still got some errors even tho freerdp package built and wanted to compare 2024-01-10 10:01:29 lemme ask a better way... is it normal to have some errors with abuild even if package builds? 2024-01-10 10:04:46 mick_ibm, out of curiosity, what machine is your ppc64le on which you run Alpine? 2024-01-10 10:06:15 quinq its running on a power9 box 2024-01-10 10:07:39 Nice, thanks :) 2024-01-10 10:30:07 mick_ibm: https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/freerdp/ 2024-01-10 10:30:52 I believe this one has the -flto removed: https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/freerdp/freerdp-2.11.4-r0.log 2024-01-10 10:31:49 mick_ibm: what error do you get? 2024-01-10 10:36:43 btw, what is the status of rust upgrades? 2024-01-10 10:39:35 oh, fun now chromium fails to build due to libxml upgrade(?) 2024-01-10 10:42:08 ncopa im not seeing the error on that build. thanks a lot for the link :) on my box im running as root and ran this command with latest alpine image: abuild -rFc and saw this: https://pastebin.com/kpgND7ej and echo $? was 1.. its been a while since ive used abuild so perhaps its just my setup. 2024-01-10 10:51:30 usually its best to not run as root 2024-01-10 10:51:52 but i dont think that is the problem here. I believe your filesystem you are building on does not support extended attributes 2024-01-10 10:52:27 what filesystem is your aports tree on? xfs? ext4? zfs? 2024-01-10 10:52:38 and what kernel 2024-01-10 10:54:09 re chromium build and libxml2-2.12: https://tpaste.us/D7Wl 2024-01-10 10:55:36 its running on rhel9 and i ran the image with podman. just loggin back in now 2024-01-10 10:57:54 seems like we backup/restore the xattrs when stripping 2024-01-10 10:57:58 ncopa xfs on 5.14.0-362.8.1.el9_3.ppc64le 2024-01-10 11:01:02 i bet that kernel does not support xattrs on xfs 2024-01-10 11:01:17 but i dont think it is needed for this specific case 2024-01-10 11:01:42 i think you can workaround it with: SETFATTR=true abuild .... 2024-01-10 11:04:17 ok ill give that a go right now, thanks :) 2024-01-10 11:15:29 ok sweet there we go, nearly same output from buildlogs and exit code was zero. now the real fun begins... thanks for the help! im gonna keep pluggin away at this 2024-01-10 11:15:47 ncopa: you mean rust 1.73/1.74/1.75? 2024-01-10 11:15:53 yup 2024-01-10 11:16:26 Someone needs to debug why it fails on 32-bits, I haven't had the time yet 2024-01-10 11:21:25 it was on arm only, right? 2024-01-10 11:23:18 yes 2024-01-10 11:23:22 armhf armv7 2024-01-10 11:23:55 it is SIGSEGVs when building stage 1 iirc 2024-01-10 13:01:56 alright! I have a backtrace for chromium 2024-01-10 13:06:43 https://gitlab.alpinelinux.org/alpine/aports/-/issues/15660 2024-01-10 13:10:37 I think electron has been failing on the builders due to the libxml2-2.12 issue 2024-01-10 13:12:42 cely: that's absolutely correct 2024-01-10 13:13:08 simple fix would be to just drop system libxml in favour of the bundled one 2024-01-10 14:51:11 Can I have package A depend on B, and B checkdepend on A? The build steps needed would be: 1) build and package B. 2) install B as dep for A 3) build, check and package A. 3) check B. 2024-01-10 14:56:20 No 2024-01-10 14:58:30 OK, thx. I'll add "options="!check" and a comment refering to the circular dep to B then. 2024-01-10 15:45:35 this fixes chromium build and should also fix electron and qt*web* https://tpaste.us/D7Wl 2024-01-10 16:00:52 ikke: hi, opentofu 1.6.0 has been released 2024-01-10 16:01:41 as for the 32bit stuff, it's still in progress 2024-01-10 16:03:24 pj: alright, thanks for the heads-up 2024-01-10 17:39:06 ncopa: I looked at the coredump, it says nothing, building rust in debug mode and it doesn't sigsegvs 2024-01-10 17:39:12 wonderful 2024-01-10 17:39:20 A heisenbug 2024-01-10 17:40:01 https://tpaste.us/b1eB 2024-01-10 17:48:51 pj: do you have an upstream issue? 2024-01-10 17:50:38 nope 2024-01-10 18:08:32 Somebody broke mupdf :( 2024-01-10 18:08:42 Error loading shared library libmupdf.so.: No such file or directory (needed by /usr/bin/mupdf-gl) 2024-01-10 18:09:22 !58663 2024-01-10 18:11:59 nmeum :D 2024-01-10 18:43:45 quinq: oospi, one sec 2024-01-10 18:44:53 ncopa i focused my debugging on where the freerdp build is failin at winpr/tools/makecert-cli/winpr-makecert, so i was digging around github and found this: https://github.com/openssl/openssl/issues/22854#issuecomment-1842785831 im wondering if i should open an aports issue on gitlab focused on removing that ppc64le case statement in APKBUILD of freerdp because the original bug was filed to binutils. or is the new issue not nec 2024-01-10 18:44:53 essary? 2024-01-10 18:47:09 im not a compile expert but this issue seems related "ppc64le, clang 17.x, musl libc; hardware is POWER9." and correlates to where the freerdp build was breaking 2024-01-10 18:49:41 hum. not sure 2024-01-10 18:49:51 it does smell like they are related indeed 2024-01-10 18:50:19 maybe post a comment to the openssl issue that we have similar issues with freerdp and -flto 2024-01-10 18:58:17 ok sounds good... ill keep investigating and post updates here if i discover something else important 2024-01-10 18:59:21 quinq: fixed in f8cea5ee96b4f3486cc55ac8044668522117d206 thanks 2024-01-10 19:00:28 nmeum, no, thank you for that fast fix! :) 2024-01-11 01:07:07 durrendal: Thanks for working on bringing hatchling to main/, if it doesn't work out, maybe you can consider reversing upstream's decision to use hatchling, like i did with py3-pygments 2024-01-11 01:10:31 Perhaps you could try moving everything with tests disabled first to lower the number of aports moved, then slowly re-enable them later on 2024-01-11 01:19:17 As py3-pytest depends upon py3-iniconfig, probably you'll have to disable tests anyway, to prevent circular dependencies 2024-01-11 01:20:00 or maybe try if those tests will work with unittest instead of pytest 2024-01-11 01:23:16 I think moving the dependencies to main/ first just solves the circular dependency problem this time, but that will occur again when everything is rebuilt for the next stable release 2024-01-11 01:28:27 ACTION 2024-01-11 01:38:39 timlegge: What do you think of https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/240 2024-01-11 01:39:09 I wonder if those empty directories serve a purpose 2024-01-11 01:39:47 It seems Arch Linux doesn't delete them 2024-01-11 01:44:47 celie: Are the directories left around? It would be interesting to know which modules package empty directories. tar files don't typically keep empty files 2024-01-11 01:45:21 s/empty files/empty directories/ 2024-01-11 01:46:04 I think it does, otherwise it wouldn't have annoyed the author of that MR so much that the MR was created to fix it 2024-01-11 01:49:24 However, as the empty directories have remained in the .apk files for so long, i don't think we should be removing them without knowing exactly why they're created 2024-01-11 01:49:52 Otherwise, they could turn out to be important later on, and the decision to delete them would have to be reversed 2024-01-11 01:53:25 celie: I would ask the author for clarification and some extra info. 2024-01-11 01:55:22 celie: you are @Celeste in gitlab right? 2024-01-11 01:56:07 Yes, and i am celie and cely on OFTC, as celeste has already been registered with NickServ 2024-01-11 01:56:51 I thought so - we didn't finish the MR we were working on... 2024-01-11 01:57:42 This might be related, the author of abuild!240 was also working on !58718 2024-01-11 01:58:08 algitbot got the first MR wrong :) 2024-01-11 02:05:09 celie: that's an interesting suggestion, I hadn't considered just reversing it or disabling tests to move it. I'm sure anyone looking at the MR can tell I'm fighting with dependencies there. It's a little more than I thought it would be 2024-01-11 02:05:25 But I'm determined! I'll chase down your suggestions, they're solid 2024-01-11 02:07:39 I'm over here now :) 2024-01-11 02:08:29 durrendal: i think all the dependencies of py3-hatcling/hatch-vcs have to switch to unittest or have tests disabled to prevent circular dependencies 2024-01-11 02:09:08 (as py3-pytest depends upon py3-iniconfig) 2024-01-11 02:09:26 and now py3-iniconfig depends upon py3-hatchling/hatch-vcs 2024-01-11 02:13:21 timlegge: Looking through the .apk files, i think pure Perl aports duplicate the directory structure from usr/share/perl5 under usr/lib/perl5 (and as they're pure Perl, the directories under usr/lib are empty) 2024-01-11 02:13:31 Hahaha I won the lottery on circular dependencies . okay, conversion of disabling tests initially sounds feasible, lots of little tweaks 2024-01-11 02:14:42 celie: looks like perl-strip-nondeterminism i only a part of the Debian build. Not really sure what the author is trying to do 2024-01-11 02:16:04 timlegge: Me neither, which is why i don't think abuild240 should be merged in haste without finding out why this issue of empty directories has been around for so long without being touched 2024-01-11 02:26:15 For the record, the empty directories issue was also mentioned in !52664 2024-01-11 02:32:50 I think i have an idea what creates those empty directories, looking at perl-io-prompter, perllocal.pod is created under usr/lib/perl5/core_perl and .packlist is created under usr/lib/perl5/vendor_perl/auto/IO/Prompter 2024-01-11 02:33:22 and the apkbuild-cpan template deletes those 2 files, leaving the directories empty 2024-01-11 02:35:46 The creation of perllocal.pod can be skipped with `make pure_install`, at least for aports using EUMM 2024-01-11 02:43:18 https://fedoraproject.org/wiki/Perl/Tips#Historical_notes_for_old_packages mentions that NO_PACKLIST=1 and NO_PERLLOCAL=1 can be used to suppress creation of .packlist and perllocal.pod 2024-01-11 02:50:14 yeah, I just noticed that. I is possible that the APKBUILD template should be modified to remove the - especially since it deletes a file 2024-01-11 02:50:27 or multiple files. 2024-01-11 03:15:33 omni: FYI I worked around the problem with ZFS. I explained it upstream. Still unclear if it is a bug or a problem with my dataset though: https://github.com/openzfs/zfs/issues/15666 2024-01-11 03:22:55 timlegge: I have updated https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/239 with a fix for the empty directories 2024-01-11 03:31:12 EvTheFuture: I'm happy that you found something that worked for you 2024-01-11 04:45:28 timlegge: While trying to update $package_mappings of apkbuild-cpan, i found that main/perl-date-format is a duplicate of main/perl-timedate, so i have removed the former in !58726 2024-01-11 04:46:47 Keeping the former and removing the latter would mean adding it to $package_mappings as it doesn't follow the convention of mapping CPAN distribution names to aport names 2024-01-11 04:52:15 When you have time, maybe you could leave a comment on that MR saying whether what i've done is reasonable 2024-01-11 05:03:05 I think the arm CI builders may have run out of diskspace again 2024-01-11 06:26:52 omni: it's not that they ran out of space, it's just that these don't have a lot to begin with, so larger builds may fail 2024-01-11 06:31:42 ikke: ok 2024-01-11 06:32:15 how about the arm package builders? 2024-01-11 06:37:28 I'm cleaning them up as we speak 2024-01-11 06:37:39 But they are on the same host 2024-01-11 06:37:41 atm 2024-01-11 06:39:57 ah 2024-01-11 07:05:21 ncopa: the qtwebengine-chromium we use were already patched for libxml2 2.12 in https://invent.kde.org/qt/qt/qtwebengine-chromium/-/commit/c98d28f2f0f23721b080c74bc1329871a529efd8 https://invent.kde.org/qt/qt/qtwebengine-chromium/-/commit/0ac7411195581d33bb07ead3ff2abc0610f96ff8 (87-based and 112-based) 2024-01-11 07:17:00 is recoll too a victim of the libxml2 2.12 changes? 2024-01-11 07:18:02 I wonder how many aports need to be patched 2024-01-11 11:42:01 i think we should do a 3.19.1 release soonish. here are the things I think we need to solve: https://gitlab.alpinelinux.org/groups/alpine/-/milestones/8#tab-issues 2024-01-11 11:42:23 various of them depends on comments from upstream (lxc, openrc specifically) 2024-01-11 11:44:50 we should also do 3.18.6 release: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15657 2024-01-11 12:38:59 ncopa: I think that your patch for openrc was merged 2024-01-11 12:39:42 https://github.com/OpenRC/openrc/pull/681 2024-01-11 13:33:25 wonderful! 2024-01-11 14:44:08 I want to build APKBUILD with `abuild rootbld` but got ERROR: : Could not find ./APKBUILD (PWD=/home/qaq/tbox) 2024-01-11 14:45:05 I have add myself to abuild group and just abuild -r is working 2024-01-11 14:46:09 Does it work if you put it one directory deeper? 2024-01-11 14:48:50 no, it error 2024-01-11 14:49:35 it errors after Installing 68 packages 2024-01-11 14:52:23 https://paste.opensuse.org/pastes/3349156c45ee 2024-01-11 15:12:29 qaqland: rootbld depends on very specific aports structure 2024-01-11 15:13:44 So, something like $HOME/testing/tbox/APKBUILD should work? 2024-01-11 15:16:58 might :p haven't actually tested 2024-01-11 15:17:33 not work :( 2024-01-11 15:19:56 How about passing the full path of the APKBUILD file in the APKBUILD environment variable? 2024-01-11 15:21:27 if the path is wrong, it should error at script-exec at once, not after install build-base packages 2024-01-11 15:26:09 cely: tried, same error 2024-01-11 15:26:33 qaqland: the issue is that abuild runs twice during rootbld 2024-01-11 15:26:45 as in, it re-executes itself in the chroot 2024-01-11 15:41:40 ptrc: do I need to new an issue to alpine/abuild? 2024-01-11 15:43:42 Probably you should find out more details first 2024-01-11 16:02:31 I find it 2024-01-11 16:03:39 in script here: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in?ref_type=heads#L2613 2024-01-11 16:05:38 it only bind aportsgit=${APORTSDIR:-${startdir}} (for me it is ~/aport) to rootbld 2024-01-11 16:09:59 Does setting APORTSDIR to the correct directory fix it? 2024-01-11 16:14:17 yes 2024-01-11 16:22:46 still strange, startdir=/home/qaq/testing/tbox is right but aportsgit=/home/qaq/aports is wrong 2024-01-11 16:23:08 abuild kind of assumes you are building in ~/aports 2024-01-11 16:23:18 for rootbld anyway 2024-01-11 16:24:13 maybe we can mark this on wiki 2024-01-11 16:24:32 thank you all! 2024-01-11 16:27:02 You're welcome 2024-01-11 19:43:49 Shouldn't the maintainer be tagged on issues when starting with repo/aport: in the title? #15667 2024-01-11 19:44:08 EvTheFuture: No, there is no automation in place for that 2024-01-11 19:44:49 EvTheFuture: Usually I assign the maintainer, but the maintainer for this is ScrumpyJack, which hasn't been active for quite some time 2024-01-11 19:45:21 So I didn't bother 2024-01-11 19:49:53 ikke: Ok, thank you, then I guess I have to take a look at why this happens. 2024-01-11 19:50:55 I also have an issue with ffmpeg which now is a bit of a hazzle for me. I say it was fixed and seems to be included in the next dot-release. Any idea on when that might happen? 2024-01-11 19:51:11 I saw* 2024-01-11 19:52:29 You can make it happen :P 2024-01-11 19:59:31 ikke: which one :) 2024-01-11 19:59:46 The ffmpeg bump 2024-01-11 20:01:31 ikke: i just compiled it plus wf-recorder from edge in order to get it to work for now. I'd be happy to learn how to help out creating releases 2024-01-11 20:02:06 EvTheFuture: check out a new branch, run abump ffmpeg-6.1.1 2024-01-11 20:02:13 push to your fork, make an MR 2024-01-11 20:02:57 As this is a patch release, I don't expect any soname change, so no rebuilds required 2024-01-12 01:39:52 ikke: But that has already been done right? !57209 I meant when it will be/how to make it available when doing an apk upgrade on an existing 3.19 installation. 2024-01-12 01:47:12 I think ffmpeg 6.1 is already available for 3.19: https://pkgs.alpinelinux.org/packages?name=ffmpeg&branch=v3.19 2024-01-12 01:51:19 celie: Should I see the fixes from !57209 when performing an apk upgrade ? 2024-01-12 01:52:54 You should 2024-01-12 02:00:52 celie: Well, I don't... Weird... I have to try to uninstall an reinstall all packages depending on ffmpeg then... 2024-01-12 02:01:46 Maybe you could try apk upgrade --available? 2024-01-12 02:02:23 cely: Yes, I ran with -a 2024-01-12 02:02:55 Now it appear, but 10 minutes ago it didn't 2024-01-12 02:04:58 Output from apk upgrade -as 10 minutes ago -> https://tpaste.us/7MY1 2024-01-12 02:05:21 Now -> https://tpaste.us/1XPe 2024-01-12 02:06:35 I don't see -a in https://tpaste.us/7MY1 2024-01-12 02:09:17 or a "-U" either... 2024-01-12 02:10:04 As you mentioned compiling your own ffmpeg, i guess it has the same pkgver/pkgrel (6.1-r1) as what's in repo, in that case it probably won't show up without -a 2024-01-12 02:13:28 I don't understand why your 2nd output shows ffmpeg updating from 6.1-r1 to 6.1-r1 (the same version) 2024-01-12 02:15:23 EvTheFuture: do you have any Edge repos in your /etc/apk/repositories file as well as 3.19 repos? 2024-01-12 02:16:51 The first 6.1-r1 is probably self-compiled, as mentioned earlier 2024-01-12 02:19:45 cely: ok, but as it has the same version I wouldn't expect it to be reinstalled 2024-01-12 02:20:04 if it had a different (older) version then that's a different matter 2024-01-12 02:25:22 minimal: It wouldn't be reinstalled even with -a? 2024-01-12 02:26:00 why would it be reinstalled? it would be upgraded if a newer version was available 2024-01-12 02:26:38 Maybe because it changed repositories? 2024-01-12 02:26:44 cely: why would it pick out ffmpeg to re-install the same version and not every other package already installed? 2024-01-12 02:27:31 cely: AFAIK apk compares versions across repos and "uses" the newest version of a package 2024-01-12 02:28:23 I might have misremembered, but i think i've seen packages being upgraded with --available when pkgrel remains the same but the packages was moved from testing/ to community/ 2024-01-12 02:29:07 cely: I've never seen that myself so far and I wouldn't expect that to happen if the version didn't change 2024-01-12 04:39:45 ncopa the freerdp build on ppc64le works with -Oz flag https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-Oz this could be a better patch because at least there will compile optimizations with all the architecures 2024-01-12 04:57:04 (as a work around for now...) 2024-01-12 05:08:20 isn't that the whole point of -a 2024-01-12 05:08:39 > Reset all packages to versions available from current repositories. This resets all versioned dependencies in world (see apk-world(5)). Additionally, packages are selected from active repositories if possible even if it means replacing or downgrading the package. 2024-01-12 05:09:10 guess it eould depend if tou hsd pkg@tag in etc/world or not 2024-01-12 05:09:27 would depend on if you had* 2024-01-12 09:51:43 what should be alpine's policy towards packages that do not bother to make releases, but are otherwise useful? previously i was aware of testing/pcsx2 which psykose updated extremely frequently, and now i feel like packaging https://github.com/dosemu2/dosemu2 . i feel that something like monthly bumps by default would be suitable 2024-01-12 10:29:23 ovf: see https://git.alpinelinux.org/aports/tree/testing/tree-sitter-dart/APKBUILD 2024-01-12 10:29:33 TL;DR: 2024-01-12 10:30:22 Make pkgver=0_git 2024-01-12 10:30:50 _gitrev= 2024-01-12 10:31:58 bte they do make releases, just the last one is two years old: https://github.com/dosemu2/dosemu2/tags 2024-01-12 10:34:04 thanks. i'm asking about policy, not how to create an apkbuild. i.e. what's an acceptable bump schedule and how this can be enforced. 2024-01-12 11:31:29 gitlab down for updates? 2024-01-12 11:31:58 yes 2024-01-12 11:32:16 good :) 2024-01-12 11:32:21 It's starting again 2024-01-12 11:32:42 indeed, the 502 has already become more colorful 2024-01-12 11:32:58 And back 2024-01-12 11:33:14 works 2024-01-12 12:15:28 when will we use new APKINDEX v3 2024-01-12 12:16:17 Uncertain 2024-01-12 12:16:19 likely when alpine switches to apk tools v3, no? 2024-01-12 12:19:44 how can I find the new reference for v3, there is only v2 2024-01-12 12:55:26 qaqland: https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/doc/apk-v3.5.scd 2024-01-12 13:01:57 thx 2024-01-12 13:37:52 ovf: re^ policy , isn't that dependant 80%+ on maintainer ? 2024-01-12 15:00:16 omni honestly I don't care if doc is outdated, I can always look up in internet, but if package is not available, I have no choice 2024-01-12 15:00:58 i'm going to revert your commit 2024-01-12 15:04:10 re: rtpengine 2024-01-12 15:13:26 is there something wrong with the CI? I have a MR with 2 new aports (the latter requiring the former) and the dependency is not found 2024-01-12 15:13:36 there's those lines 2024-01-12 15:13:37 > WARNING: opening /home/buildozer/packages/community: No such file or directory 2024-01-12 15:18:40 If you're talking about !58811, xtl-dev is installed when building xtensor, it's just that cmake looks for xtlConfig.cmake which is in xtl not xtl-dev, and xtl-dev does not depend upon xtl 2024-01-12 15:20:39 From a brief glance, xtl looks like a header-only package, so maybe it doesn't need to be split into -dev? 2024-01-12 15:23:15 Another header-only package i remember is utfcpp, perhaps you can see how it does things, i think it does not have a separate -dev subpackage 2024-01-12 15:23:38 i mananged to build it locally with xtl-dev 2024-01-12 15:24:08 Does your xtl-dev contain the xtlConfig.cmake file? 2024-01-12 15:24:34 theres a pkgconf but no cmake file 2024-01-12 15:24:52 oh wow the xtl package is _just_ the cmake file 2024-01-12 15:24:54 thats dumb 2024-01-12 15:25:13 yeah no need for dev package then 2024-01-12 15:26:48 I wonder if moving the cmake files to /usr/lib/cmake (utfcpp has a patch for that) will make abuild move them to xtl-dev, however that would mean the main xtl package is empty 2024-01-12 15:31:55 if its header only i dont see the need for a dev pkg tbh 2024-01-12 15:32:04 thanks for spotting the issue 2024-01-12 15:32:13 You're welcome 2024-01-12 15:33:45 Also, being header-only probably means it can be "noarch" 2024-01-12 15:33:59 good point 2024-01-12 15:35:50 i think xtensor is also header only 2024-01-12 15:38:51 Seems like it 2024-01-12 15:39:54 I guess that means the only thing it is building is the tests 2024-01-12 15:40:05 yeah, did a build locally 2024-01-12 15:48:31 CI already looking a lot greener 2024-01-12 15:52:49 but not on s390x, classic 2024-01-12 15:53:09 > logged: Dumping boolean NumPy file to string failed 2024-01-12 16:41:02 if anybody has time for a quick review on !58811, the 2 packages are very straightforward 2024-01-12 20:13:37 picat checksum fails on x86_64. Comparing it to the version built by the other arches, I see quite a lot of differences 2024-01-12 20:15:03 Seems like they released version 3.5 as 3.6 2024-01-12 20:15:11 - printf("Picat version 3.5#5\n"); 2024-01-12 20:15:13 + printf("Picat version 3.6\n"); 2024-01-12 20:17:58 ouch 2024-01-12 21:05:39 ikke, they = ? 2024-01-12 21:06:43 http://picat-lang.org/ 2024-01-12 21:08:42 https://distfiles.alpinelinux.org/distfiles/edge/picat-3.6-orig.tar.gz 2024-01-12 21:08:46 This is the original file 2024-01-13 01:23:22 to rnalrd, who doesn't seem to be here at the moment, I'm back and I'm sorry, I was in a hurry and didn't see that you had fixed the issue of making rtpengine build 2024-01-13 18:05:09 Is there a guide on how to create your own repository and is it possible to use a Git repository for this? 2024-01-13 19:18:17 Not that I'm aware, but I can say that I made my own repository using Gitlab and Git LFS: https://lab.ilot.io/ayakael/repo-apk 2024-01-13 19:18:58 This makes my user repo for v3.19 acessible via https://lab.ilot.io/ayakael/repo-apk/-/raw/v3.19/user for example 2024-01-13 19:19:20 accessible* 2024-01-13 19:19:30 ayakael0: they left 2024-01-13 19:19:42 Well, sadness 2024-01-13 19:20:45 ayakael: fyi, I'm looking at your dotnet8 mr, but also waiting until the builders are ready, there have been quite some large builds like chromium and electron 2024-01-13 19:22:32 ikke: many thanks :) 2024-01-14 00:47:04 Could someone have a look at !56270 and !57525? Thanks 2024-01-14 11:10:20 some package has 3rd source code, do I need to delete them 2024-01-14 11:11:02 this one: https://github.com/fastfetch-cli/fastfetch/tree/dev/src/3rdparty 2024-01-14 11:12:18 bluez isn't patched for cve-2023-45866 ? 2024-01-14 12:43:57 celie: are you packaging cpan.org? 2024-01-14 12:44:40 qaqland: system libraries should be used if available 2024-01-14 13:21:26 WhyNotHugo: it should be since bluez 5.71 https://github.com/bluez/bluez/commit/25a471a83e02e1effb15d5a488b3f0085eaeb675 2024-01-14 13:21:47 what archlinux used to patch 5.70 https://gitlab.archlinux.org/archlinux/packaging/packages/bluez/-/commit/47e9592b1b322c54bdb094238f52fa20513c624b 2024-01-14 13:32:39 so not patched in our stable releases 2024-01-14 14:49:20 Could someone look at !58540? 2024-01-14 14:51:21 Done 2024-01-14 14:51:33 Thanks! 2024-01-14 15:12:48 how to add optional dependencies 2024-01-14 15:13:50 program will auto load whew exist 2024-01-14 15:16:11 qaqland: do you mean in the APKBUILD? I don't think you do that, it is up to the user to `apk add $optional_dependency` 2024-01-14 15:58:32 make a post-instal script to tell user any optional dependency? 2024-01-14 15:59:34 and add them to pre-deinstall? 2024-01-14 16:04:20 I'm with you on your first point but the second may not be wanted if the user has installed the optional dependencies for other reasons, genereally speaking and not knowing what the optional dependencies are in this case 2024-01-14 19:08:24 cely: thanks for rebuilding tic-80 for the janet upgrade 2024-01-14 19:13:12 cely: only just noticed something similar for drawpile and libsodium (thanks for upgrading that too!) ... is this something maintainers of packages that depend on the libs should keep track of or is there a system in place whereby an upgrade to a lib will automatically trigger rebuilds for packages that depend on it? 2024-01-14 19:14:28 mio: it requires a pkgrel bump 2024-01-14 19:14:49 So when upgrading a package that has dependencies, those pkgrel bumps have to be included as well 2024-01-14 19:16:25 ikke: are the pkgrel bumps automated, or if not, should the maintainer of the dependent package be keeping track and bumping? 2024-01-14 19:17:48 The maintainer of the package that is depended upon should make sure they are included 2024-01-14 19:18:15 We have tools to help with that, but it's still a manual action 2024-01-14 19:19:21 ah, thanks a lot for clarifying! 2024-01-14 19:39:39 mio: at the end of each package built in CI, it runs checkapk, which tells you if there are soname differences. If there are, that's an indication dependencies need to be rebuilt 2024-01-14 19:48:47 ikke: okay, thanks ^^ 2024-01-14 23:20:32 could someone please look at !57300 2024-01-15 01:06:48 omni: thx :) 2024-01-15 05:08:51 I'm writing APKBUILD, wiki seems not work here 2024-01-15 05:09:01 giturl 2024-01-15 05:09:11 Git repository from which abuild checkout checks out 2024-01-15 05:15:07 sry I saw it wrong 2024-01-15 12:02:17 I'm implementing a flat btrfs subvolume layout for an Alpine downstream (PostmarketOS) 2024-01-15 12:03:20 Where does the apk database live, mentioned in https://github.com/alpinelinux/apk-tools/blob/acefa1acc1ce0e1871d17b4eafe4b1888f45d4d0/doc/apk.8.scd and in apk-tools source: https://github.com/alpinelinux/apk-tools/blob/acefa1acc1ce0e1871d17b4eafe4b1888f45d4d0/src/database.c 2024-01-15 12:04:53 Wondering if we can just put all of /var on its own subvolume, or if that would have unfortunate side-effects 2024-01-15 12:06:11 because / would be able to roll back to previous snapshots, but /var won't roll back 2024-01-15 12:18:23 /var/lib/apk 2024-01-15 14:58:01 thank you 2024-01-15 15:14:15 /var/lib/apk is empty on my Alpine and pmOS systems, will it be populated once we move to apk-v3? 2024-01-15 15:19:36 Oh, it's /lib/apk actually 2024-01-15 15:24:56 cool thanks, that makes things easier since we're keeping /lib as part of the / subvolume :) 2024-01-16 02:15:30 anybody has the link to the 3.20 release note 2024-01-16 02:15:35 i grubbed myself 2024-01-16 02:18:04 https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.20.0 ? 2024-01-16 02:19:18 I was almost going to say 3.20 hasn't been released yet, but decided to look on the wiki first :) 2024-01-16 02:19:27 ty 2024-01-16 02:23:43 Could someone quickly check out https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/58874 it's a very simple bugfix that has already been merged upstream, but releases tend to take a few months. 2024-01-16 02:25:13 grub-install complains about not finding modinfo in /usr/lib/grub/x86_64 but the folder is x86_64-efi 2024-01-16 02:26:37 Maybe you need to use --target=x86_64-efi ? 2024-01-16 02:27:43 huh 2024-01-16 02:27:45 thanks 2024-01-16 02:29:29 You're welcome 2024-01-16 02:33:03 hm no luck booting 2024-01-16 02:33:22 ikke: Thanks! :)) 2024-01-16 02:33:53 bl4ckb0ne: did you also copy the boot file over 2024-01-16 02:35:27 in EFI/boot/boot 2024-01-16 02:35:30 ? 2024-01-16 02:40:52 From EFI/alpine/ to EFI/boot/ 2024-01-16 02:42:18 thought i did 2024-01-16 02:43:06 hm straight to bios 2024-01-16 02:43:13 no error shown 2024-01-16 03:04:53 could someone have a look at !58741 !58751 and !58696 2024-01-16 03:05:31 if i install it from a live usb where the boot drice is mounted on /mnt, efi directory and boot directory args are /mnt right? 2024-01-16 03:09:19 i got it! 2024-01-16 03:09:29 live usb was stale, had an old version of grub 2024-01-16 03:16:40 is there something that alpine does that makes u-boot to now show up on a display during it's phase? 2024-01-16 03:17:03 ACTION is making a port of OLIMEX Teres-I in postmarketos and is running out of ideas to why the same definition doesn't work 2024-01-16 03:17:45 like the same version and package processing in APKBUILD -> no display vs other distros that have display and work without issues 2024-01-16 03:20:46 u-boot runs before alpine starts? 2024-01-16 03:38:59 iggy, ye 2024-01-16 03:39:17 i think i found a solution in mps's repo now so consider solved 2024-01-16 18:53:57 Hi, i would like to work on https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues/51 by first of all adding plain integritysetup/dm-integrity functionality 2024-01-16 18:54:49 I found that initramfs-init.in uses eval to set KOPT_* variables: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in?ref_type=heads#L435 2024-01-16 18:54:57 Why is eval needed here? 2024-01-16 18:55:27 Because the variable is dynamic 2024-01-16 18:56:34 ahh i see, the declaration part contains a variable 2024-01-16 19:18:14 https://dpaste.org/gpJA2#L484 why is it giving me this bad value err? 2024-01-16 19:18:39 i guess i am using wrong command for cross-compiling or something? 2024-01-16 19:18:49 ACTION is on x86_64 and wants to build it for aarch64 2024-01-16 19:19:22 KREYREN_oftc: We don't ship any cross-compilers 2024-01-16 19:19:37 how do you build the package then? 2024-01-16 19:19:49 All as native as possible 2024-01-16 19:20:04 How do you test the package to make sure it works on native then 2024-01-16 19:20:50 Becuase we compile native, we can in most cases run the tests of packages 2024-01-16 19:21:18 this is a bootloader that has to be tested on the device in practice 2024-01-16 19:22:15 you can build it in ci/cd and then install the package to your device by downloading the artifact 2024-01-16 19:22:31 or directly build it locally on your device 2024-01-16 19:22:37 chereskata, so just literally submit it to gitlab and develop it there? 2024-01-16 19:22:45 i personally no 2024-01-16 19:23:04 i have a personal vm and share the keys across all test devices 2024-01-16 19:23:07 chereskata, the building it locally would be preferred but the aarch64 device is too weak and i am trying to use x86_64 to optimize it to be able to build it on it 2024-01-16 19:23:24 or use qemu-user 2024-01-16 19:23:27 Yeah 2024-01-16 19:23:40 the idea of ikke and minimal is the best i think 2024-01-16 19:23:47 howddya do qemu-user? I am on nixos with binfmt configured 2024-01-16 19:23:57 I use qemu-user to locally build aarch64 and armv7 package for testing 2024-01-16 19:24:04 https://gitlab.alpinelinux.org/alpine/docker-abuild#configure-multi-arch-support this? 2024-01-16 19:24:07 KREYREN_oftc: qemu-user is an alpine package 2024-01-16 19:24:17 sorry. qemu-openrc is 2024-01-16 19:24:22 ikke, what it does 2024-01-16 19:24:29 Do you have qemu-user-aarch64 installed? 2024-01-16 19:24:39 KREYREN_oftc: qemu-openrc takes care of registring binfmt 2024-01-16 19:25:09 `$ apk list | grep qemu-user-aarch64` doesn't return anything -> I don't think it's installed 2024-01-16 19:25:14 oh i see 2024-01-16 19:25:40 qemu-user-aarch64 (no such package): 2024-01-16 19:25:48 you setup qemu-user on whatever OS you are building packages on 2024-01-16 19:26:12 https://pkgs.alpinelinux.org/package/edge/community/aarch64/qemu-aarch64 isn't it this? 2024-01-16 19:26:44 oh qemu-openrc 2024-01-16 19:27:50 yeah, it's qemu-aarch64 2024-01-16 19:27:56 You need both 2024-01-16 19:28:01 oh oke 2024-01-16 19:29:25 I have actually never used binfmt. I use libvirt and setup the vm by hand 2024-01-16 19:30:19 https://fedoraproject.org/wiki/Architectures/AArch64/Install_with_QEMU 2024-01-16 19:30:31 And inside it i compile the project 2024-01-16 19:30:58 i have libvirt too but binfmt is more comfortable on nix setup 2024-01-16 19:31:11 since i just cd in the aports dir and everything is set up for me 2024-01-16 19:31:13 qemu-user is slightly faster as it does not have the emulate the kernel 2024-01-16 19:31:19 but can have more bugs 2024-01-16 19:31:53 Interesting. Sounds good for rapid development 2024-01-16 19:32:08 We use it for our rv64 builder 2024-01-16 19:32:52 does anyone know how to use this? https://gitlab.alpinelinux.org/alpine/docker-abuild 2024-01-16 19:33:04 no 2024-01-16 19:33:13 ACTION has to do docker as the apk-tools on nixos need adjustments to run within the nix's sandbox 2024-01-16 19:34:03 no, I use something similar to that 2024-01-16 19:34:29 `docker run -it -v .:/src/aports alpinelinux/docker-abuild` seems to work 2024-01-16 19:40:59 Is it intentional that the arguments are not sorted in the man page?: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/mkinitfs-bootparam.7.in 2024-01-16 19:42:27 (man mkinitfs-bootparam) 2024-01-16 19:56:30 any update? Have been offline 2024-01-16 19:57:08 none 2024-01-16 19:57:15 ty 2024-01-16 20:34:17 ACTION gave up on trying to figure out how to build that on alpine and instead is building that on pmbootstrap to then submit to alpine 2024-01-16 20:39:46 KREYREN_oftc: so qemu user is not working for you? 2024-01-16 20:39:58 ikke, doesn't seem to work in docker 2024-01-16 20:40:09 the hypothesis is that there ain't no docker 2024-01-16 20:40:13 eh 2024-01-16 20:40:18 s/docker/openrc 2024-01-16 20:40:36 You'd run an aarch64 container 2024-01-16 20:40:46 where qemu-user would run on the host 2024-01-16 20:41:48 my host is NixOS though 2024-01-16 20:42:31 Can't you install qemu-user aarch64 there? (that's not alpine specific) 2024-01-16 20:42:34 and then binft 2024-01-16 20:44:05 like i have apk set up on my nixos, but it needs adjustments so the only solution is docker 2024-01-16 20:44:09 so like aarch64 docker? 2024-01-16 20:45:09 docker run -it --rm --platform linux/arm64/v8 alpine:edge 2024-01-16 20:45:22 If you setup qemu-user and binfmt, that should work 2024-01-16 21:02:31 checking 2024-01-16 21:03:24 docker run -it --rm --platform linux/arm64/v8 alpine:edge uname -m 2024-01-16 21:03:24 aarch64 2024-01-16 21:03:25 oooo 2024-01-16 21:11:51 ikke, that seems to work! thanks! <# 2024-01-16 21:11:57 cool 2024-01-16 21:36:45 where does abuild places the packages? 2024-01-16 21:36:59 KREYREN_oftc: ~/packages 2024-01-16 21:41:33 thanks 2024-01-16 22:10:00 So original u-boot from alpine and postmarketOS -> No display on teres, me forking u-boot, crust, arm-trusted-firmware and trying to adjust anything i can think of to get the display to work for the last 4 days -> No display, trying the u-boot from other distro that does the same thing packaging-wise (make teres_i_defconfig && make with SCP and BL31 exported as variables pointing to the same things) -> Display works no issue 2024-01-16 22:10:06 why is that broken on alpine? 2024-01-16 22:12:16 like the main difference seems to be that alpine's arm-trusted-firmware is setting `SUNXI_SETUP_REGULATORS=0 SUNXI_AMEND_DTB=1` for the platform but it doesn't work even with that removed 2024-01-16 22:14:19 and allegedly the same behavior happens on other AllWinner A64 SoCs e.g. pinebook and pinephone 2024-01-16 22:14:45 also alpine's at-f is using clang 2024-01-16 22:15:00 but even making that on gcc is not giving me the display 2024-01-17 15:50:19 > [15:48:49] WARNING: This device has a previous installation of pmOS. CONTINUE? (y/n) [n]: < is there a way to make it not ask me and just YOLO I MIGHT HUG UP YOUR FILESYSTEM 2024-01-17 15:51:41 KREYREN_oftc: that's a question for pmos 2024-01-17 15:51:52 oh sorry i though i am in pmos 2024-01-17 15:53:28 Np 2024-01-18 00:47:35 Could someone have a look at !57803? This release of Elixir can be built on all architectures, so i hope it can be merged soon. Thanks. 2024-01-18 00:49:34 (i've also run the CI on riscv64, and it passes, so there should be no problems there) 2024-01-18 00:53:52 This is a relatively straightforward adoption of an orphaned aport by a new contributor: !58403 2024-01-18 01:04:29 ah, yes, I already had a look at that, not sure why I didn't merge it yet 2024-01-18 01:08:28 Thanks :) 2024-01-18 13:18:13 Is the review queue for new packages big right now or did my MR get forgotten about? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/58087 2024-01-18 13:19:18 z3ntu1: it's big right now 2024-01-18 13:19:36 okay, I'll wait then :) 2024-01-18 13:21:25 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests?scope=all&state=opened¬[label_name][]=status%3Amr-stale&search=new+aport 2024-01-18 16:02:22 Why is freecad in alpine in such an outdated version 2024-01-18 16:03:39 maintainer not active i guess 2024-01-18 16:03:42 send patch 2024-01-18 16:03:45 and not available for aarch64.. kinda need that 2024-01-18 16:04:03 bl4ckb0ne, the maintainer is aiden grossman do they have irc 2024-01-18 16:04:37 ACTION shrugs 2024-01-18 16:05:01 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/testing/freecad/APKBUILD#L9 2024-01-18 16:06:27 it has been upgraded by "boomanaiden154" several time in the past 2024-01-18 16:06:27 boomanaiden154, u aiden_ 2024-01-18 16:06:44 s/_/? 2024-01-18 16:48:22 yes 2024-01-18 18:25:26 y'allt losers 2024-01-18 18:25:34 lmao 2024-01-18 19:27:15 if opencascade was the only arch limitation previously, freecad should be able to build on all but s390x 2024-01-18 20:55:04 Hi, could some of you merge !57634 !58958 !58964 !58965 !58966 2024-01-18 20:55:06 thanks 2024-01-18 21:08:35 KREYREN_: I haven't had the time or interest to get FreeCAD (or other packages, especially Cura) up to date recently. 2024-01-18 21:08:55 There was a patch on the Alpine Gitlab that updated it to something more recent. It was pretty much done, but the author never finished it up. 2024-01-18 21:09:57 Last I checked, aarch64 built, but didn't work at all due to issues with coin (some OpenGL issue I believe). I don't think they've been fixed at this point. I think I got it building on Aarch64 at one point, just the display didn't work. 2024-01-18 21:17:13 boomanaiden154, noted i try to look at it 2024-01-18 22:41:10 would someone mind looking at !57900 and !57899? 2024-01-18 23:18:45 Newbyte: how active are they? because the MRs looked alright but I had some nitpickery that I felt would be nice to get in from the start 2024-01-18 23:19:55 I assume this is currently for some specific 32b arm pmos target(s) 2024-01-19 04:43:45 qaqland: i think omni means you can include libtbox and libsv in !58696 right away, you don't need to wait for next time 2024-01-19 06:11:22 !59193 fails tests on ppc64le with "get_mempolicy: Function not implemented", "no numa support in kernel". Does this apply only to the CI runner's kernel, or should this aport be disabled for ppc64le now? 2024-01-19 06:12:53 Probably can't be disabled as lots of other aports depend on it 2024-01-19 06:16:11 cely: we only have one host for ppc64le atm, so would count for the builders as well 2024-01-19 06:16:36 Ok 2024-01-19 06:27:19 Just tested the previous version on the CI, and it fails in the same way, so i guess this means tests will have to be disabled for ppc64le 2024-01-19 08:21:17 cely: got it, i will do it 2024-01-19 08:31:45 "Newbyte: how active are they..." <- I'm sure Jenneron will respond to the feedback 2024-01-19 08:32:10 and yes it is for older Tegra SoCs 2024-01-19 14:56:54 ha you already took care of wayland-protocols 1.33 celie 2024-01-19 14:56:59 ill close mine 2024-01-19 17:50:47 I fail to rebase !53545 or `glab mr checkout 53545` 2024-01-19 17:51:33 404 not found 2024-01-19 17:52:26 omni: it's a private project 2024-01-19 17:56:39 huh 2024-01-19 19:16:14 https://github.com/coreutils/coreutils/commit/c4c5ed8f4e9cd55a12966d4f520e3a13101637d9 2024-01-19 19:16:30 I linked to it in #alpine-security 2024-01-19 19:16:40 roger that 2024-01-19 20:03:39 Thanks all for working on the merge request queue, I see a downwards trend :-) https://i.imgur.com/qgvLu13.png 2024-01-19 20:27:29 Good work! 2024-01-19 22:57:26 I need to step away from the keyboard for a bit but !59245 seems like it could be handled some other way 2024-01-20 11:57:29 wops, I just rebooted after sway crash and my grub seems broken 2024-01-20 11:59:01 I managed to boot a rescue pen and chroot my root, I only have grub-efi on apk world, is 'apk fix grub-efi' enough for fixing it? 2024-01-20 12:03:52 well, I have to go now, I will try reboot and come back later if fails :D 2024-01-20 12:12:03 donoban: no, check the alpine 3.20 release notes on the wiki 2024-01-20 13:16:24 hi! I'm getting "sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?" when trying to run the registry.alpinelinux.org/alpine/docker-abuild:edge from dabuild 2024-01-20 13:16:55 with DABUILD_ARCH=aarch64 (which changes the container platform to `linux/arm64/v8`). 2024-01-20 13:17:42 running `DABUILD_DOCKER=podman dabuild` has other issues re. mounted volume permissions. btw, my host is fedora 38 2024-01-20 13:19:46 I imagine it comes from the first invocation of sudo in `entrypoint.sh` (https://github.com/alpinelinux/docker-abuild/blob/master/entrypoint.sh#L42). Curiously, it does not happen if I don't run it with --platform=linux/arm64/v8. Any ideas? 2024-01-20 13:19:54 wihtout* 2024-01-20 14:08:56 `docker run --rm --privileged multiarch/qemu-user-static --reset -p yes` fixed it. Curious. 2024-01-20 20:53:30 ikke: ouch, I just tried but stills failing 2024-01-20 20:55:26 donoban: what steps did you do? 2024-01-20 20:57:22 well I chrooted my root (luks+btrfs) with ext4 /boot and vfat /boot/efi 2024-01-20 20:57:48 I run the grub-install 2024-01-20 20:57:51 uhmm 2024-01-20 20:58:10 maybe I downgraded grub before running it 2024-01-20 20:59:31 donoban: You also need to copy the grubx64.efi file 2024-01-20 20:59:48 (or what's relevant for your system) 2024-01-20 21:00:01 I have an error with 'update-grub' (cannot find a device for /) (is /dev mouonted) ? 2024-01-20 21:00:06 donoban: "maybe"? 2024-01-20 21:00:27 donodan, did you bind-mount /dev, /proc, /sys etc also into the chroot directory? 2024-01-20 21:00:28 for d in sys proc dev; do mount /$d //$d; done 2024-01-20 21:00:43 for d in sys proc dev; do mount --rbind /$d //$d; done 2024-01-20 21:00:49 yes, but it seems that / is not reported on mount output 2024-01-20 21:00:54 tmp and run too, for good measure 2024-01-20 21:01:25 I mount them with mount -o bind 2024-01-20 21:01:40 but I think that the problem is some mess with btrfs and the chroot 2024-01-20 21:02:10 well I'm gonna retype the grub-install with the last version 2024-01-20 21:04:22 https://tpaste.us/KEvB is the mount output 2024-01-20 21:06:23 so how did you mount the rootfs onto the chroot directory? 2024-01-20 21:06:38 I mounted the whole btrfs in /mnt 2024-01-20 21:06:42 so root is /mnt/@ROOT 2024-01-20 21:08:21 I know nothing about btrfs subvols 2024-01-20 21:08:54 but see mentions of "mount -o subvol=@ROOT" 2024-01-20 21:08:59 What's the output of `btrfs subvol list /` inside the chroot? 2024-01-20 21:09:47 or maybe subvol=ROOT 2024-01-20 21:09:59 ouch 2024-01-20 21:10:05 @ROOT is correct 2024-01-20 21:10:12 it seems that I did a typo on the path 2024-01-20 21:10:23 i put something like /boot/efi/EFI/grub/boot/boot.... 2024-01-20 21:10:31 Arnavion: I've found both forms mentioned 2024-01-20 21:10:51 ah no 2024-01-20 21:11:38 minimal: Whatever source told you that -o subvol=ROOT will mount a subvol named @ROOT is wrong 2024-01-20 21:12:24 well, the output of subvol list is very long 2024-01-20 21:12:27 it lists all the snapshots 2024-01-20 21:12:41 Sure, pastebin it 2024-01-20 21:13:54 https://tpaste.us/ogbL is enough with this? 2024-01-20 21:14:26 Okay, and did you mount the first three inside your chroot too? 2024-01-20 21:14:56 uhM, no, I only mounted /boot and /boot/efi 2024-01-20 21:15:04 which are different partitions 2024-01-20 21:15:17 Is @ROOT supposed to be / or /root ? 2024-01-20 21:15:28 is / 2024-01-20 21:15:41 Right, then what did you do to mount it? 2024-01-20 21:16:51 ie did you do `mount /dev/whatever /mnt` or `mount -o subvol=@ROOT /dev/whatever /mnt` ? The latter is correct if @ROOT is supposed to be / 2024-01-20 21:17:21 the first 2024-01-20 21:17:45 outside the chroot i have /mnt/@ROOT 2024-01-20 21:18:03 should I try the second? 2024-01-20 21:18:05 Right, so you've mounted the root volume instead. Don't do that 2024-01-20 21:18:16 yes 2024-01-20 21:18:25 ok let's umount everythibgn 2024-01-20 21:21:06 ooouuhhh 2024-01-20 21:21:25 I rebooted because I messed everything trying to umount and wala, it booted fine this time 2024-01-20 21:21:51 it seems that I downgraded grub before follow the wiki steps 2024-01-20 21:21:52 ikke: .....and this is why automatically running grub-install upon package updates will be problematic for people who have changed aspects of their booting arrangement from that of the installer... 2024-01-20 21:22:10 thanks for the help guys :) 2024-01-20 21:22:25 minimal: You don't have to convince me 2024-01-21 05:47:58 Anyone who knows cargo, any reason why compilation would not create target/release/deps folder? I'm trying to debug an upgrade to a package of mine that decided to start bootstraping rust code. 2024-01-21 05:48:49 Error goes as such: 2024-01-21 05:48:49 No such file or directory (os error 2) 2024-01-21 05:48:49 error: error writing dependencies to 2024-01-21 05:48:49 `/var/lib/gitlab-runner/builds/ayakael/user-aports/user/gitlab-foss/src/gitlab-foss-v16.7.3/vendor/bundle/ruby/3.2.0/gems/prometheus-client-mmap-1.0.2/ext/fast_mmaped_file_rs/target/release/deps/regex_syntax-f27b073a54f87689.d`: 2024-01-21 05:48:49 ``` 2024-01-21 05:48:51 ``` 2024-01-21 13:37:18 mr-hold, the new Draft: 2024-01-21 15:04:58 I thought lld was working on s390x since it built and check() passed 2024-01-21 15:05:11 maybe someone would like to look at https://github.com/llvm/llvm-project/pull/75643 2024-01-21 16:52:10 anyone an idea why the serial console would suddenly change? https://tpaste.us/BJdR 2024-01-21 16:52:15 looks like it changes the speed 2024-01-21 16:57:11 well it looks like it misidentifies the speed/baud rate 2024-01-21 17:00:50 what about setting "console=ttyS1,115200" on cmdline? 2024-01-21 17:01:03 oops ttyS0 2024-01-21 17:32:28 That’s already set 2024-01-21 17:33:34 is it using DeviceTree? perhaps that has the wrong speed defined 2024-01-21 17:45:43 ayakael: what is that path 2024-01-21 18:03:58 yes it has devicetree 2024-01-21 18:04:08 maybe i should look into it 2024-01-21 18:04:39 !59347 finally in a bit of better mental to do things 2024-01-21 18:04:44 but still weird the first part runs fine 2024-01-21 18:05:17 and the cmdline in kernelog has the right serials settings 2024-01-21 18:05:28 this pioneer box is so much fun... 2024-01-21 18:06:30 RiscV? 64 cores? wow looks like a more realistic RiscV system 2024-01-21 18:07:02 yes i received two of them 2024-01-21 18:07:06 double headache 2024-01-21 18:07:08 :) 2024-01-21 18:07:40 UEFI booting? 2024-01-21 18:08:30 nope 2024-01-21 18:09:04 the bootchain is a bit weird 2024-01-21 18:09:11 strange, I'd thought a more "standard" MB like this would use UEFI 2024-01-21 18:09:40 it can they say 2024-01-21 18:10:41 it first used zsbl which then runs sbi which will exec a kernel (from spi or sd) and then will load nvme to kexec the kernel on it 2024-01-21 18:11:50 on and the first kernel has linuxboot as initrd 2024-01-21 18:11:56 oh* 2024-01-21 18:12:08 apparently they're working on UEFI (EDKII) 2024-01-21 18:12:36 for Arm UEFI has become part of the spec for server-class boards, I'd assume the same for RiscV 2024-01-21 18:12:50 edk2 has support for this board already 2024-01-21 18:13:36 not quite the same as UEFI out-of-the-box though 2024-01-21 18:14:26 it will not run efi out of the box, zsbl and sbi is what most (or all?) rv boards use 2024-01-21 18:14:35 https://sprunge.us/mmGjey 2024-01-21 18:14:48 this is the bootlog, first is fedora, and second is alpine 2024-01-21 18:30:49 clandmeter: note how Alpine kernel says "IRQ sharing enabled" with regard to the serial driver, whereas Fedora says "IRQ sharing disable", they also show differing base_baud values 2024-01-21 18:32:30 yes, i can see that 2024-01-21 18:32:38 but i dont know why it is different 2024-01-21 18:32:52 the cmdline has similar values 2024-01-21 18:36:26 I assume the sharing/not sharing relates to different kernel config of CONFIG_SERIAL_8250_SHARE_IRQ 2024-01-21 18:39:40 there are also cmdline setting mention in the help for CONFIG_SERIAL_8250_CONSOLE that you could try to fix the speed problem 2024-01-21 18:44:35 also does your kernel have CONFIG_SERIAL_OF_PLATFORM=y ? 2024-01-21 18:46:06 yes 2024-01-21 18:46:18 From what i read now there seems to be some MCU inbetween 2024-01-21 18:46:23 its arm based 2024-01-21 18:47:48 I thought RiscV was supposed to be out to replace Arm........strange way to do it by using Arm chips lol 2024-01-21 19:41:49 pj: Gitlab started using rust in some of its gems. It fails to install as /var/lib/gitlab-runner/builds/ayakael/user-aports/user/gitlab-foss/src/gitlab-foss-v16.7.3/vendor/bundle/ruby/3.2.0/gems/prometheus-client-mmap-1.0.2/ext/fast_mmaped_file_rs/target/release/deps does not exist. This is what causes the No such file or directory bug 2024-01-21 19:42:22 clandmeter: Very jealous, I would love to play with those Pioneer boxes 2024-01-21 19:42:49 clandmeter: Plan on getting the Milk-V Oasis, which is a 16 core board slated to come out this summer 2024-01-21 19:44:01 did you get it to work or still need help? 2024-01-21 19:44:21 ayakael: I don't know what unholy combination of build systems is triggering a Rust build as part of a Ruby build, but does a manual `cargo build --release` under the .../fast_mmaped_file_rs directory work? 2024-01-21 19:44:46 Arnavion: There are gems that want to build native code, some gems are switching to rust to do that 2024-01-21 19:45:06 prometheus-mmap-client is one of them 2024-01-21 19:45:06 Yes, I get that. I'm talking about the build system specifically 2024-01-21 19:45:16 gem install 2024-01-21 19:45:21 or bundle 2024-01-21 19:45:29 Basically if a manual `cargo build --release`, then the next suspect would be how the Ruby build is triggering the Rust build 2024-01-21 19:45:43 eg if it's setting CARGO_TARGET_DIR or other CARGO_* env vars in a bad way 2024-01-21 19:45:47 Isn't really different from npm/pip doing native stuff 2024-01-21 19:45:49 https://gitlab.com/gitlab-org/ruby/gems/prometheus-client-mmap/-/blob/master/Rakefile?ref_type=heads 2024-01-21 19:46:06 Just like cargo/go can build c/c++ stuff or even js/python/etc 2024-01-21 19:46:46 Yes, again, I'm not talking about the "general concept" of invoking builds 2024-01-21 19:47:37 https://gitlab.com/gitlab-org/ruby/gems/prometheus-client-mmap/-/blob/master/bin/setup 2024-01-21 19:48:33 https://gitlab.com/gitlab-org/ruby/gems/prometheus-client-mmap/-/blob/master/ext/fast_mmaped_file_rs/extconf.rb 2024-01-21 19:52:53 pj: I gave up yesterday after an hour of trying to reproduce it locally. It builds fine on both my laptop and alpine edge lxc, but every time I do it in CI, it fails with that error. It's a very strange one. The rust code expects rust 1.73, when 1.72 is what's on edge, so maybe cargo had some changes on 1.73? Seems like a stretch. 2024-01-21 19:54:36 Gonna try another run at it now. 2024-01-21 19:54:53 Probably should try building it with 1.72 locally then 2024-01-21 19:56:08 Both locally and on CI uses rust 1.72 2024-01-21 19:56:48 I might just workaround by pre-emptively creating a folder there, but what an odd one this bug is. 2024-01-21 19:57:08 There's another gem that has rust code now, and it has the exact same problem 2024-01-21 19:57:52 ayakael: do you only have these issues on 16.8, or didn't you use rust with 16.7? 2024-01-21 19:58:20 I presume it uses rustc directly without cargo? 2024-01-21 19:59:22 It needs cargo 2024-01-21 19:59:27 The build manifest tries rustc 2024-01-21 19:59:30 It executed the following command: cargo rustc --manifest-path ./Cargo.toml --target-dir target --lib --profile release -- -C linker=gcc -L native=/usr/lib -C link-arg=-Wl,--as-needed,-O1,--sort-common -C 2024-01-21 19:59:30 link-arg=-Wl,-z,pack-relative-relocs -C link-arg=-lm -l pthread -l ucontext 2024-01-21 19:59:45 hm 2024-01-21 20:00:08 do you have ci job? 2024-01-21 20:00:25 ikke: both 16.7 and 16.8 has the same issue. I tried cutting out prometheus in 16.7, but your patch didn't work. Other components was looking for that code 2024-01-21 20:00:42 pj: here's the failing job: https://lab.ilot.io/ayakael/user-aports/-/jobs/7664 2024-01-21 20:00:45 I'm testing to build 16.7 with the gem on our CI now 2024-01-21 20:01:09 https://gitlab.alpinelinux.org/alpine/infra/docker/gitlab/-/jobs/1251129 2024-01-21 20:01:36 o, it's not alpine runner 2024-01-21 20:01:40 can't help then 2024-01-21 20:02:09 pj: let me get a build going on Alpine infra 2024-01-21 20:06:25 it would be so nice to have a way for package to lag in updates 2024-01-21 20:09:06 *on specific architectures 2024-01-21 20:09:38 Technically you can lag one version behind :P 2024-01-21 20:14:04 bleh 2024-01-21 20:24:05 ikke: is there a way to connect to github in the container? 2024-01-21 20:24:15 our lovely GH still doesn't have ipv6 2024-01-21 20:24:29 ask nu[m] 2024-01-21 20:24:49 probably a topic for alpine-infra so I'll move there 2024-01-21 20:33:25 win 22 2024-01-21 20:34:12 catch 22 2024-01-21 20:36:13 pj: here it is reproduced on Alpine's CI: https://gitlab.alpinelinux.org/ayakael/aports/-/jobs/1251176 It is on 3.19-stable as that one has ruby v3.2. 2024-01-21 20:36:52 cd .. 2024-01-21 20:37:25 This is my build: https://gitlab.alpinelinux.org/alpine/infra/docker/gitlab/-/jobs/1251129 2024-01-21 20:37:29 succeeded 2024-01-21 20:37:38 #10 10.06 (49/57) Installing rust (1.71.1-r0) 2024-01-21 20:37:47 Still on Alpine 3.18 2024-01-21 20:38:11 ikke: yeah I saw that. Gonna try to target Alpint 3.18 2024-01-21 20:38:34 I'm hoping something got funky with 1.72 2024-01-21 20:53:07 I don't see any changes between those versions 2024-01-21 20:56:32 Sigh, indeed, same error. I'm gonna put this aside for now, and come back to this later in the week. Thanks for y'all's help! 2024-01-21 21:19:20 Well, setting BUNDLE_JOBS=1 does the trick. I guess bundler loses track of directory creation? 2024-01-21 21:20:31 that's.... extremely weird 2024-01-21 21:21:02 I'm confused as well 2024-01-21 21:21:28 Smells like a race condition 2024-01-21 21:24:11 Mayhaps, but it explains why it was hard to reproduce. My compilation server has 48 cores, my laptop and devel lxc has 8 2024-01-21 21:24:22 At some point it just can't keep up with itself. 2024-01-21 21:25:02 race conditioins are often causes of these issues in build systems where dependencies are not properly handled 2024-01-21 23:33:18 I put up some MRs to drop maintainership, if someone wants to take over something 2024-01-21 23:33:19 !59371 2024-01-21 23:33:27 !59370 2024-01-21 23:34:51 ncopa: I'm dropping maintainership for rust, !59369 2024-01-22 11:47:27 ncopa: what do we do with #15309 2024-01-22 11:48:28 That's that ARM issue with gcc 2024-01-22 11:57:59 as I remember it, it was considered infeasible to rebuild all the aports on aarch64 for all the stable releases, so 3.19-stable is the only one where this is taken care of 2024-01-22 11:58:26 but still, couldn't gcc be patched for earlier stable releases? 2024-01-22 11:59:05 probably, but it would also mean nothing :P 2024-01-22 11:59:58 well, some packages receive upgrades and rebuilds from time to time, like linux-lts 2024-01-22 12:00:30 and if you're building something yourself on that architecture on those releases 2024-01-22 12:36:26 omni: true 2024-01-22 17:13:29 im going to rebuild binutils in order to test freerdp for ppc64le: https://sourceware.org/bugzilla/show_bug.cgi?id=30824 just thought id share here incase someone else was already rebuilding and testing but i assume not :) 2024-01-22 17:14:19 last rebuild of binutils was last november 2024-01-22 17:18:34 oh that’s interesting because aports looked like it was using the latest available version of binutils: https://sourceware.org/pub/binutils/snapshots/ and https://github.com/alpinelinux/aports/blob/master/main/binutils/APKBUILD#L4 2024-01-22 17:18:59 i guess that doesnt matter cause it wont have the patch that was added last week... out of curiosity, when are the packages rebuilt? 2024-01-22 17:19:28 mick_ibm: It requires a commit that either changes the version or the pkgrel 2024-01-22 17:19:29 mick_ibm: thank you for following it up. 2024-01-22 17:20:00 The last rebuild was to disable gdb: cbd94c5336c5f6f0c9c6f0851b546fc2d060eca6 2024-01-22 17:21:19 oh ok, thanks! well ill post my updates in that bug once ive rebuilt the binutils apk and then try the freerdp build again 2024-01-22 17:21:42 technically, packages are rebuilt when a commit is pushed, which has different $pkgver-r$pkgrel from what APKINDEX has 2024-01-22 17:21:42 👍 2024-01-22 17:22:11 oh ok, thats good to know. thanks for the info. 2024-01-22 18:19:51 boomanaiden154, heads-up https://github.com/FreeCAD/FreeCAD/issues/12074 i will be packaging and helping maintain freecad in alpine 2024-01-22 18:56:27 how do you feel about making cargo-* packages not depend on cargo? this would allow them to be used in `rust:alpine` images without pulling in the alpine rustc/cargo packages. The docker image already has cargo, but apk doesn't know about this. :) 2024-01-22 19:18:32 kpcyrd: you could mention that in !55123 that seems to want to do the opposite 2024-01-22 19:20:51 do all these cargo-* packages add sub-commands to cargo? 2024-01-22 19:22:31 kpcyrd: it's a work-around, but you could run apk add -t cargo to make cargo a virtual package and make apk consider the dependency being met 2024-01-22 19:24:05 that is pretty neat 2024-01-22 19:38:15 That's what abuild uses to create those .makedepend virtual packages where all the makedepends are added as dependency 2024-01-22 19:38:35 abuild -t .makedepends-.. pkg1 pkg2 pkg3 2024-01-22 20:21:39 ikke: thanks, I'll probably just go with that instead :) 2024-01-22 20:30:23 and all it does is adding a line to /etc/apk/world with package=timestamp? 2024-01-22 20:32:59 It also adds the package to /lib/apk/db 2024-01-22 20:33:55 That's where the dependencies are stored 2024-01-22 20:41:30 👍 2024-01-22 21:00:41 I think !53545 is ready (I'd probably word the commit message a bit differently but that is not important) but I still can't rebase and merge it 2024-01-22 21:13:59 omni: "resolve all conflicts" 2024-01-22 21:15:34 "people and goodwill to all mankind" ;-) 2024-01-22 21:15:46 s/people/peace/ 2024-01-22 21:18:29 heh 2024-01-22 21:19:35 ^^ 2024-01-22 22:20:05 throwing this here for people to look at and hopefully approve :p https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/59366 2024-01-22 22:20:26 i'd tag @team/developers but gitlab is showing me a scary warning that it would ping 24 people and send an email to every single one of them 2024-01-22 23:10:43 ikke: yes, but I didn't manage to `glab mr checkout 53545` 2024-01-23 03:09:37 I don't follow how qt5-qtwayland is packaged 2024-01-23 03:15:44 git branch --contains 3a8613b91d2239aebc73b43562f929aa71af0de5 2024-01-23 03:15:53 returns nothing, what are we tracking here? 2024-01-23 03:17:20 PureTryOut: halp 2024-01-23 03:20:25 ..or most of the qt5 aports... 2024-01-23 03:34:29 somehow follow https://invent.kde.org/qt/qt/qt5 ? 2024-01-23 03:59:58 https://invent.kde.org/qt/qt/qtwayland/-/commit/3a8613b91d2239aebc73b43562f929aa71af0de5 2024-01-23 04:01:06 (Arch's spec makes it more obvious https://gitlab.archlinux.org/archlinux/packaging/packages/qt5-wayland/-/blob/f03d9d13735e1702ce7959e156a455196438eb0a/PKGBUILD#L8-17 ) 2024-01-23 04:08:45 https://www.theregister.com/2024/01/22/rust_project_burnout/ 2024-01-23 04:18:45 Arnavion: I wouldn't say more obvious, and it wasn't as if I couldn't find the commit or `git log 3a8613b91d2239aebc73b43562f929aa71af0de5` 2024-01-23 04:18:56 if anything this https://gitlab.archlinux.org/archlinux/packaging/packages/qt5-wayland/-/blob/f03d9d13735e1702ce7959e156a455196438eb0a/PKGBUILD#L22 but still... 2024-01-23 04:36:15 I want to understand why 3a8613b91d2239aebc73b43562f929aa71af0de5, for example, was chosen 2024-01-23 04:37:27 Obvious as in the source of the tarball, I meant 2024-01-23 04:37:44 Yeah why that commit is used is a question for PureTryOut 2024-01-23 04:41:53 but the same one is used here https://gitlab.archlinux.org/archlinux/packaging/packages/qt5-wayland/-/blob/f03d9d13735e1702ce7959e156a455196438eb0a/PKGBUILD#L8 it must come from somewhere 2024-01-23 04:42:58 had it been a commit in the 5.15 branch between the v5.15.10-lts-lgpl and v5.15.11-lts-lgpl tags I would have got it 2024-01-23 06:00:25 It used to be a commit on https://invent.kde.org/qt/qt/qtwayland/-/tree/kde/5.15?ref_type=heads but they've since rebased that branch on newer Qt versions so I'm guessing that specific hash got lost in favour of a different one. 2024-01-23 06:00:25 It's about time to update our Qt to the rebased versions anyway 2024-01-23 06:06:50 timlegge: I have opened !59444 to standardize the CPAN aports to _pkgreal, after that is merged, i think we should be able to simplify the code in apkbuild-cpan as we no longer need to account for all the old variants of _pkgreal 2024-01-23 14:50:05 cely: I have done: make dependencies together in !58696 2024-01-23 14:50:31 thankyou for suggestions~ 2024-01-23 14:53:40 You're welcome 2024-01-23 14:54:12 celie: any reason you closed the colord mr? 2024-01-23 14:55:29 Tests segfault, and i didn't really have time to look into it 2024-01-23 14:57:15 I can look into it tomorrow if you want me to 2024-01-23 15:01:57 Ah ok, np 2024-01-23 15:19:30 ikke: opentofu merged few fixes for 32-bit platforms, should be available in 1.6.1, https://github.com/opentofu/opentofu/pull/1154 2024-01-23 15:20:19 pj: great 2024-01-23 15:44:40 cely: I need to get back to getting the merge request completed and in, but you're right that will make a big difference in reducing the complexity of that script 2024-01-23 15:51:55 We need new rust maintainer 2024-01-23 15:56:55 timlegge: i have added some fixes to my apkbuild-cpan MR, so you can have a look at that and tell me what you think when you find time to go back working on the script 2024-01-23 19:35:03 ncopa: could it be handled by a team rather than an individual, or is there a fear of no-one taking responsibility of it then? 2024-01-23 19:36:10 I opened !59470 in an attempt at getting things moving again 2024-01-23 20:02:22 * wonders if the matrix-IRC bridge has issues, or if the mass exodus has other reasons 2024-01-23 20:03:56 I saw that in another channel 2024-01-23 20:04:49 I think all the matrix users decided to collectively rage quit on us 2024-01-23 20:08:28 Or maybe just stale subscriptions got garbage collected? (I'm actually using the matrix bridge here, so this not affecting all users.) 2024-01-23 20:09:17 🐈 2024-01-23 20:09:40 🐈 2024-01-23 21:17:33 aarch64 in CI run out of disk space https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1253449 2024-01-23 21:25:05 andypost[m]: not really, just a big build (those builders don't have that much space) 2024-01-23 21:25:32 But there is another machine with more space, so retrying would probably help 2024-01-23 21:27:29 send to retry with both py3s) 2024-01-23 21:28:34 andypost[m]: I did clean up some space on that builder 2024-01-23 21:29:27 thank you! somehow python 3.12 issue with tests is resolved so huge rebuilds coming 2024-01-23 21:30:13 oh, interesting 2024-01-23 21:32:33 exciting! andypost[m] can you ping me whenever you'd be doing those? i'm thinking of switching all remaining setup.py stuff to gpep517, but there's like a thousand of them, so it would be more convenient to run the CI just once :p 2024-01-23 21:39:28 ptrc: as I see tests passed so it's matter of schedule to bump all py3* in mian/community/... and somehow find all other dependencies to script update 2024-01-23 21:45:07 btw apk search -r so:libpython3.11.so returns 4991 aports in all 3 repos 2024-01-23 21:46:44 But not all python packages will link against python, right? 2024-01-23 21:51:05 but all python packages depend on python3 2024-01-23 21:51:11 and it somehow works 2024-01-23 21:51:19 `apk list -d 'python3*'` works as well :p 2024-01-23 21:51:30 ( and is more convenient to get all origins ) 2024-01-23 21:52:41 2527 on edge btw, unless i'm miscounting something by accident 2024-01-23 21:55:17 ah, 2525, i had two removed packages installed locally and forgot to do `--from repositories` ( really neat feature as well! ) 2024-01-23 21:58:01 yeah, that's indeed a nice one, also recently discovered that 2024-01-23 23:35:50 ptrc: please remember NOT to switch cloud-init to gpep517 as it won't work (as previously mentioned) 2024-01-24 01:12:33 celie: It will likely be this weekend before I can do much with apkbuild-cpan. I will try to look at your changes and make sure we are in sync before then if I can 2024-01-24 01:16:02 Alright, thanks 2024-01-24 05:51:37 let me know if there is something else to address with https://sourceware.org/bugzilla/show_bug.cgi?id=30824 the patch from alan applied cleanly just by including it in APKBUILD file so should be pretty easy to test on your ppc64le boxes :) 2024-01-24 07:31:03 mick_ibm: alright, will test it 2024-01-24 07:34:26 sweet, thanks! 2024-01-24 07:37:03 mick_ibm: something else, not sure if you are the right person, but our ppc64le box is still running an old version of alpine, and it would be nice if we could upgrade it 2024-01-24 07:37:11 (not necessary now, but at some point) 2024-01-24 07:38:13 ikke: i dont have that kind of access there but i can send you a link to open a support ticket 2024-01-24 15:22:05 ncopa: i would like to contribute more to alpine linux if there is anything specific to ppc64le i can help out with :) 2024-01-24 15:24:19 mick_ibm: One thing you may be able to help with is with https://github.com/ncopa/alpine-installer-testsuite 2024-01-24 15:27:53 cool ill take a look, thanks 2024-01-24 15:42:30 mick_ibm: another idea is to look at the packages that are disabled (or have disabled functionality) on ppc64le 2024-01-24 16:51:39 i grep'ed main/*/APKBUILD and found that for tests for varnish for example is disabled for ppc64le. maybe you could try enable that again and see if it passes now 2024-01-24 16:51:46 and fix if it still fails 2024-01-24 16:53:50 ok yea i see that. ill take a look at those. thanks! 2024-01-24 16:55:59 thanks! 2024-01-24 17:37:38 ncopa: do you think we could remove bluez-firmware? it' 2024-01-24 17:37:59 ...it's been added in 2011 and then barely touched, and now source returns 404 2024-01-24 17:38:23 ( darn you, ansi keyboards ) 2024-01-24 18:00:58 ptrc: that's probably a good idea 2024-01-24 18:08:55 mick_ibm: I'm the .net maintainer for alpine. I've been having persistent issues with getting it stable on linux-musl-{s390x, ppc64le}. Anyone in IBM who works with that codebase that can help me improve linux-musl-{s390x, ppc64le} support? 2024-01-24 18:21:18 ayakael: is there a link for an issue or a specific patch to address? i dont know anything about .net but can take a look 2024-01-25 08:35:37 hi, how would I go about upgrading the kernel on a raspberry pi from 6.6.4 (in newest official 3.19 tarball) to 6.6.12 (newest currently in 3.19 branch)? all instructions i found refer to grabbing the kernel and modules from the newest tarball 2024-01-25 08:36:36 there's a bug i stumbled upon and kernel upgrade is supposed to fix it 2024-01-25 08:37:22 forgot to add i'm talking about diskless mode 2024-01-25 09:00:25 krystianch: there is this update-kernel for that 2024-01-25 09:00:47 But i recall that may take quite some memory 2024-01-25 09:05:04 ikke: thanks! but yeah, not enough memory on a pi 1B+ 2024-01-25 09:05:39 i'll probably wait for 3.19.1 release then 2024-01-25 10:31:58 ikke: update-kernel worked, thanks for pointing me to this script; i had to run in on another pi in sys mode and set TMPDIR to non-tmpfs and then copy the output 2024-01-25 15:48:13 I think our setup-disk's grub-install is wrong. it first runs grub-install --no-nvram and then copy the installed file to fallback boot*.efi 2024-01-25 15:48:41 the grub-install'ed efi is not used by anything 2024-01-25 15:48:46 only the fallback is used 2024-01-25 15:49:46 so we should probably have done grub-install --removable instead, which will install the fallback for us 2024-01-25 16:01:29 minimal: I wonder what you think about this stupid and simple "solution" for grub auto install? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/59584 2024-01-25 16:02:16 users who want can: echo "grub-install .... " > /etc/grub-autoinstall 2024-01-25 16:02:39 and they will have a working grub on each upgrade 2024-01-25 16:03:35 ncopa: sorry, meant to reply to that MR. Yes it's fine - the major work is creating a valid script in that file for new installs - I have been (slowly) working on this by modifying setup-disk 2024-01-25 16:05:52 ncopa: as for the non-fallback file - well you can specify options to grub-install to ONLY create the fallback file, that's what I do for my own setups. However there is a risk with that approach in that if someone later installs/reinstalls another OS then the fallback file may be "zapped" (i.e. replaced) by another OS and then without having the grubx64.efi to copy over then it would be harder to fix a non-bootable system 2024-01-25 16:06:35 yeah 2024-01-25 16:06:54 but right now, the non-fallback is not used at all 2024-01-25 16:07:45 my general thinking is to not install it at all if its not used. better to install when intend to use 2024-01-25 16:08:53 so we could probably change the setup-disk script to just do a single `grub-install .... --removable` 2024-01-25 16:09:02 either that or install it with efivars 2024-01-25 16:09:11 "the non-fallback is not used at all" - not used by the boot setup created by setup-disk for new installs 2024-01-25 16:09:22 exactly 2024-01-25 16:09:32 but some people with existing installs may have created EFI boot entries referring to the grubx64.efi file 2024-01-25 16:09:53 yup 2024-01-25 16:10:23 "or install it with efivars" - may not necessarily work in some VMs... 2024-01-25 16:11:00 e.g. for qemu on the cmdline you have to specify a file to store EFI vars, if not specified then a system relying on boot vars won't boot 2024-01-25 16:12:07 i know 2024-01-25 16:12:30 I don't know exactly what happens if qemu doesn't have somewhere to store vars, unclear whether it silent fails or gives errors whne something tries to write them 2024-01-25 16:12:37 I can test 2024-01-25 16:13:20 the Cloud images basically have to rely on fallback 2024-01-25 16:13:45 though some cloud providers/hypervisors do provide mechanisms to "import" EFI vars to a VM 2024-01-25 16:14:18 I saw it may also be possible to add a start.nsh something, for efi shell 2024-01-25 16:14:33 but I don't know if that works for everybody either 2024-01-25 16:14:45 I have some local "draft" packaging for tools to import EFI vars to AWS and QEMU 2024-01-25 16:16:20 nope, startup.nsh is a different matter - it *can* be used for kernel EFISTUB booting (rather than EFI boot vars) however it has limitations - it requires there to be an EFI Shell (which some motherboards' UEFI does not provide, though you can add an EFIShell EFI to ESP instead), also it is not supported by some hypervisors 2024-01-25 16:16:42 ok 2024-01-25 16:17:04 i boot my home desktop machine with kernel efistub directly 2024-01-25 16:17:08 i.e. specifically Virtualbox does NOT support startup.nsh without manual intervention (they used to but considered it a "test" feature and changed its support in recent releases) 2024-01-25 16:17:32 you're using EFI boot vars for the efistub? 2024-01-25 16:17:39 yes 2024-01-25 16:17:44 efibootmgr 2024-01-25 16:18:26 right, so try and boot via EFISTUB a pre-prepared disk image (i.e. on a VM) ;-) 2024-01-25 16:18:59 like one of the Cloud images - without EFI boot vars then the only other way to provide cmdline entries etc is via startup.nsh 2024-01-25 16:20:19 also startup.nsh where supported is slow to boot - it is check AFTER things like network booting etc, it's a "last resort" mechanism 2024-01-25 16:20:37 been there, done that ;-) 2024-01-25 16:22:07 right 2024-01-25 16:22:31 sounds like the best solution is to install the fallback 2024-01-25 16:22:44 from setup-disk 2024-01-25 16:24:08 ~I guess the main question would be whether or not EFI boot vars should be used (where possible)? 2024-01-25 16:24:36 yeah 2024-01-25 16:24:42 currently they are not used 2024-01-25 16:24:59 i.e look at the recent Grub issues and various "randomly" running grub-install with various options to try and fix it 2024-01-25 16:25:17 some of these attempts would have resulting in EFI boot vards being created 2024-01-25 16:25:43 which would then "block" the use of fallback booting 2024-01-25 16:26:56 but EFI vars are "dangerous" in general - definately if there is more than a single OS installation on a disk 2024-01-25 16:27:52 as the fallback file is a Highlander - "there can only be one!" (per disk that is) 2024-01-25 16:31:39 ncopa: another alternative to EFISTUB booting would be UKI, but that's "problematic" currently on Alpine 2024-01-25 16:38:59 ncopa: The non-fallback EFI fulfils the role of a backup in case that another OS deleted/overwrites the fallback. 2024-01-25 16:39:25 Not saying it's indispensable, but it does provide a simple restoration mechanism. 2024-01-25 16:40:01 yupe, I already mentioned this 2024-01-25 18:33:10 could I get some expert eyes on this patch? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/59590 2024-01-25 18:33:44 I'm not sure if that is the right approach. in any case, we're unable to build things on pmOS that use mesa on aarch64 since mesa-asahi is wrongly pulled in 2024-01-25 20:58:21 gitlab will be restarted in 2 minutes for security patching 2024-01-25 21:56:17 hmm, no delve on armv7 :( 2024-01-25 22:06:58 ikke: I'm not sure why... we could try enabling it to see if it builds 2024-01-25 22:07:09 I'll try that 2024-01-25 22:08:06 https://github.com/go-delve/delve/issues/2051 2024-01-25 22:08:24 so no upstream support 2024-01-25 22:15:01 ah 2024-01-25 22:15:24 are you trying to debug something that only fails on armv7? 2024-01-25 22:15:36 well, it also fails on x86, so I can try that 2024-01-26 13:06:04 ncopa or anybody else, do we have some policies regarding vendor kernels? 2024-01-26 13:07:08 i guess i could put the pioneer kernel in testing for now 2024-01-26 13:12:16 seems like linux 6.6.x has turned longterm now 2024-01-26 13:21:23 im ok with that. we have a vision five kernel too that I think we could move to testing 2024-01-26 13:51:42 im about to tag new stable release(s). can we please hold any bigger builds? 2024-01-26 13:52:07 https://gitlab.alpinelinux.org/alpine/aports/-/issues/15718 2024-01-26 13:56:06 any holdups on !58894? or just waiting for reviewer capacity? 2024-01-26 13:59:49 Habbie: merged 2024-01-26 13:59:53 thanks! 2024-01-26 13:59:58 yay! 2024-01-26 14:00:02 thanks hawk and ncopa :) 2024-01-26 14:00:29 Habbie: I wonder if you have enough privileges to press the "approve" button? 2024-01-26 14:00:41 would make it visible in the list that it is approved 2024-01-26 14:00:46 not last time i checked 2024-01-26 14:00:54 where would it be? 2024-01-26 14:01:17 (maybe nowhere, now that it is merged) 2024-01-26 14:01:50 now nowhere indeed 2024-01-26 14:01:59 it is usually under the pipeline box 2024-01-26 14:02:01 i think hawk has another one coming 2024-01-26 14:02:16 but semi-recently somebody in here told me to just post LGTM 2024-01-26 14:03:08 I think that's fine too 2024-01-26 14:03:15 yes, thats all we need. problem is that we easily miss them unless it becomes more visible that its ACKed 2024-01-26 14:03:32 since the approve button is not available to everyone (anymore?) 2024-01-26 14:03:38 a friendly ping here is also ok 2024-01-26 14:04:13 just pressing the thumbs-up button won't bump the MR and is easier to miss though 2024-01-26 14:04:23 but a comment will 2024-01-26 14:06:04 i wonder if we could have a role in gitlab for this, for maintainers 2024-01-26 14:07:25 but otoh, would probably be good if we could give merge privileges too 2024-01-26 14:07:44 ncopa, right, understood 2024-01-26 14:07:49 now i get why these pings are often so effective :D 2024-01-26 14:08:36 i think the challenge is, anybody can claim maintainership for a package, and we cannot give everybody merge privileges. there needs to be some trust gained first 2024-01-26 14:10:08 ncopa: we can add users as guests to aports 2024-01-26 14:10:23 That allows them to approve MRs 2024-01-26 14:10:27 aha 2024-01-26 14:10:43 that might be a good idea 2024-01-26 14:10:47 for maintainers 2024-01-26 14:10:54 Many have already been added 2024-01-26 14:11:04 i think we can add Habbie 2024-01-26 14:11:08 Certainly 2024-01-26 14:11:31 we need some process how to get on this list, and how/when get out of it 2024-01-26 14:11:52 i think ideally the flow would be something like this: 2024-01-26 14:12:04 - user creates MR 2024-01-26 14:12:17 - maintainer reviews, and follows up with any needed changes 2024-01-26 14:12:31 - maintainer approve when its ready to merge 2024-01-26 14:12:47 - asap, someone with enough privs merges it 2024-01-26 14:13:03 where 'asap' works a lot better because you can see the approval in the MR list 2024-01-26 14:13:15 exactly 2024-01-26 14:13:30 question - who approves my MRs to the ports i maintain? 2024-01-26 14:13:41 ha 2024-01-26 14:13:44 good question 2024-01-26 14:13:50 Yes, sadly many maintainers do not respond to MRs assigned to them. 2024-01-26 14:13:56 you can approve them yourself :) 2024-01-26 14:14:01 ncopa, that sounds right 2024-01-26 14:14:04 Habbie: no need for approval 2024-01-26 14:14:31 These MRs are unassigned and easy to filter out 2024-01-26 14:14:31 i think we need some auto label or similar to flag that it is a maintainer update/MR 2024-01-26 14:14:37 ikke, ah, right 2024-01-26 14:14:40 whatever works visually 2024-01-26 14:15:13 ikke: so basically i can just list unassigned MRs to help merge those? 2024-01-26 14:15:34 ncopa: you can click on the MR search field and there's a filter called Assignee 2024-01-26 14:15:43 Yes, though not all users have their maintainer addresses in their profile 2024-01-26 14:15:47 and it accepts a value of None 2024-01-26 14:15:49 So those are unassigned 2024-01-26 14:16:32 ikke: i feel like most of those are users who didn't ever have an account on redmine/gitlab, either because they submitted their change through ML, or they removed their account 2024-01-26 14:16:49 The problem right now is the large list of MRs waiting for maintainer feedback 2024-01-26 14:17:03 ptrc: yes, that's an issue as well 2024-01-26 14:17:58 i think we want encourage maintainers to review their packages 2024-01-26 14:18:14 Yes 2024-01-26 14:18:14 and reward those who does one way or the other 2024-01-26 14:18:50 like prioritize merging those 2024-01-26 14:19:00 The MRs that are approved one way or another are usually quickly merged 2024-01-26 14:19:07 That's what I do 2024-01-26 14:22:11 Habbie: feel free to continue ping us here on IRC when you have approved MRs you maintain, and thank you for helping maintaining stuff for us 2024-01-26 14:22:22 ncopa, will do, thank you! 2024-01-26 15:18:40 do we have any policy specifically preventing top-level exec in APKBUILDs, or is that just a "please don't do that"? 2024-01-26 15:26:35 is there a way to skip tests for a specific arch? 2024-01-26 15:27:42 case "$CARCH" in ... options="$options !check" ... esac 2024-01-26 15:27:52 ty 2024-01-26 16:52:05 ptrc: as in outside of func? 2024-01-26 16:53:46 is it possible to use `ap` to change a dependency name? 2024-01-26 16:54:23 ap is read-only 2024-01-26 16:54:44 bl4ckb0ne: what do you want ot do? 2024-01-26 16:54:59 i modified the glm package, there's no glm-dev anymore 2024-01-26 16:55:10 it was header only 2024-01-26 16:55:45 i also removed the -doc package since it was a bunch of outdated html files and a big pdf 2024-01-26 17:00:52 git grep and sed did the work 2024-01-26 17:01:02 cool 2024-01-26 17:01:05 I also have apkgquery 2024-01-26 17:01:13 (also read-only though) 2024-01-26 17:02:07 apkgquery 'any(pkg.Makedepends, {.Pkgname == "glm-dev"})' 2024-01-26 17:07:37 ptrc: https://tpaste.us/WxVx 2024-01-26 17:12:59 ptrc: it's not written down, but it does impact the performance of tools like ap 2024-01-26 17:13:10 so it should be avoided if possible 2024-01-26 17:47:21 @ncopa did you see my recent comment in !59584? 2024-01-26 17:51:04 i did 2024-01-26 17:53:20 hmm ok....I've never sourced a script to run it 2024-01-26 17:53:36 only to define vars and functions 2024-01-26 17:53:53 i tagged 3.19.1 2024-01-26 17:55:16 minimal: the down side is if you do "exit" or similar there, then it never returns 2024-01-26 17:56:02 actually, also if the command you put there exits with error, the post-upgrade will return error too 2024-01-26 17:56:11 and apk upgrade will fail 2024-01-26 17:59:44 right, isn't that a reason to run the script then rather than source it? 2024-01-26 18:00:14 it is 2024-01-26 18:00:23 the script I'll be using myself I intended to be more than just 1 or 2 simple lines 2024-01-26 18:00:40 i.e. for software machines it needs to run grub-install multiple times 2024-01-26 18:00:52 s/machines/RAID/ 2024-01-26 18:01:07 but what would be the expected outcome if the script fails? I think its ok that apk fails 2024-01-26 18:01:38 so in this case it does not make any significant difference 2024-01-26 18:02:21 ok 2024-01-26 18:02:45 so I'll have to remember not to use "exit" anywhere in my script 2024-01-26 18:27:20 pj[m]: yeah, running executables outside of any functions 2024-01-26 18:27:30 ikke: that's exactly the one i was referring to 2024-01-26 18:27:35 well, two 2024-01-26 18:27:41 heh 2024-01-26 18:27:45 didn't even realize 2024-01-26 18:27:54 I have commits to fix it 2024-01-26 18:28:07 s/referring to/thinking about/? :p dunno, but i noticed it and i wanted to open an issue about it 2024-01-26 18:28:30 I'll open an MR with the changes 2024-01-26 19:26:07 !59674 2024-01-27 00:21:35 okay i know i'm missing something simple -- i added a manpage to yx, installs into /usr/share/man/man1, and now i'm trying to figure out how to split that into a separate "yx-doc" package in APKBUILD -- though there was some automagic to make it happen if i just said subpackages="yx-doc::noarch" but it's complaining ">>> ERROR: yx-doc*: Missing 2024-01-27 00:21:35 /home/tomalok/git/alpinelinux/aports/main/yx/pkg/yx-doc" 2024-01-27 00:25:27 not sure it's your issue, but just subpackages="$pkgname-doc" ? 2024-01-27 00:28:27 yeah, that was the original attempt - figured i should specify "noarch", but no difference in output 2024-01-27 01:35:53 celie: I have been reviewing the changes and things look good. I had squashed some of my early commits so https://gitlab.alpinelinux.org/timlegge/abuild/-/tree/improvements2?ref_type=heads has your changes cherry-picked on top of it. 2024-01-27 01:36:13 s/has/have/ 2024-01-27 01:39:45 I think this needs to get merged - If you want I can create a MR from my tree - or if you want to do yours - but a couple of mine should be squashed for sure 2024-01-27 01:40:26 Sure, go ahead to create an MR 2024-01-27 01:51:13 done https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/243 2024-01-27 01:59:43 Thanks, i look forward to seeing more template 4 CPAN aports after that's merged 2024-01-27 02:00:45 Off the top of my head, template 4 brings: perl-dev is no longer added as makedepends unconditionally, no more empty directories due to .packlist and perllocal.pod being created and then deleted, and *.pod files are now moved to the -doc subpackage 2024-01-27 02:06:34 Also, options, arch, and patches are carried over on a recreate, and dependencies are now sorted (instead of having a random order due to using hashes) :) 2024-01-27 02:10:26 cely: sorted deps are great - I originally kept the original order of the old apkbuild but it should really have been sorted 2024-01-27 02:21:40 Ouch, i think i just found a bug 2024-01-27 02:28:15 timlegge: Just pushed a commit to https://gitlab.alpinelinux.org/alpine/abuild/-/merge_request/239 which can be squashed to the commit with the corresponding message 2024-01-27 02:29:19 I think after adding that, you can take this opportunity to rebase your MR against master which has 1 new commit 2024-01-27 02:31:07 Sorry about that 2024-01-27 02:33:16 After you mentioned sorted deps, i wondered if recreate resorts the deps (it doesn't), but i just happened to pick AnyEvent::XMPP, which has no deps in META.json, so a recreate actually deleted all deps (probably something to address later on) 2024-01-27 02:35:38 cely: done 2024-01-27 02:35:44 So, i deleted META.json/yml, and forced the code to generate MYMETA.json/yml (which has the deps), and that's when i found the bug 2024-01-27 02:35:46 Thanks :) 2024-01-27 02:35:58 np 2024-01-27 08:29:28 ikke: looking at the alpine go package and I don't see anything that would take a directory and fill in a ApkIndex... is this something you think should exist outside that package or has it just not been implemented there yet? 2024-01-27 09:03:52 iggy: I think it can has merrit to be added, but it should be done in such a way that there is no assumption that the files live on disk 2024-01-27 09:09:53 ikke: yeah, I was picturing something that used the fs interface that was added recently... my personal desire is to use it with something like https://github.com/C2FO/vfs or https://github.com/viant/afs 2024-01-27 12:40:05 should I replace upstream's pkg-config file from '-Ixxx' to '-I/usr/include/xxx' 2024-01-27 12:48:39 Better would be to send a patch 2024-01-27 12:49:04 But most likely yes, the original -I looks like an error, depending on what's xxx 2024-01-27 12:52:45 source: https://gitlab.com/jobol/mustach/-/blob/master/pkgcfgs?ref_type=heads#L5 2024-01-27 13:43:25 hi 2024-01-27 13:46:57 I've cloned aports and I've made commit locally. Then, I've run git remote add cristian_ci https://gitlab.alpinelinux.org/cristian_ci/aports.git and finally I've tried to run git push --set-upstream cristian_ci nameofthebranch 2024-01-27 13:47:29 last command returns: fatal: unable to access 'https://gitlab.alpinelinux.org/cristian_ci/aports.git/': Could not resolve host: gitlab.alpinelinux.org 2024-01-27 13:48:01 Where are you running this command? 2024-01-27 13:48:34 (I can enter cristian_ci via webinterface on gitlab.alpinelinux.org) 2024-01-27 13:48:43 ikke, in a terminal 2024-01-27 13:48:54 What OS? 2024-01-27 13:49:04 alpine 2024-01-27 13:49:18 What does getent hosts gitlab.alpinelinux.org 2024-01-27 13:49:18 (now, edge) 2024-01-27 13:50:20 ikke, hex string too? 2024-01-27 13:50:46 You mean you get an ipv6 address? 2024-01-27 13:50:51 ikke, ok, I paste the full line 2024-01-27 13:51:19 (I get an ipv6 address, it seems but I use ipv4 for connection) 2024-01-27 13:51:53 ikke, yes 2024-01-27 13:52:14 2a01:7e01:e001:15a:1::2 gitlab.alpinelinux.org gitlab.alpinelinux.org 2024-01-27 13:52:25 (it's not my ip) 2024-01-27 13:52:33 Not, that's the ip address of gitlab 2024-01-27 13:52:34 no* 2024-01-27 13:52:47 yeah, I've compared in connection information 2024-01-27 13:53:10 Can you ping that address? `ping 2a01:7e01:e001:15a:1::2` 2024-01-27 13:53:49 I can ping that 2024-01-27 13:54:29 And curl -v https://gitlab.alpinelinux.org/ 2024-01-27 13:55:45 done 2024-01-27 13:55:53 And that works? 2024-01-27 13:55:56 I had to install curl 2024-01-27 13:56:30 yeah, I get information, it seems ok 2024-01-27 13:57:04 connected to gitlab.alpinelinux.org ... port 2024-01-27 13:57:52 connection #0 to host gitlab.alpinelinux.org left intact 2024-01-27 13:57:54 and git ls-remote https://gitlab.alpinelinux.org/cristian_ci/aports.git 2024-01-27 13:59:20 remote: HTTP Basic: Access denied. The provided password or token is incorrect or your account has 2FA enabled and you must use a personal access token instead of a password. See https://gitlab.alpinelinux.org/help/topics/git/troubleshooting_git#error-on-git-fetch-http-basic-access-denied 2024-01-27 14:00:35 maybe https://gitlab.alpinelinux.org/-/profile/personal_access_tokens 2024-01-27 14:00:55 cristian_c: I don't see your fork 2024-01-27 14:00:58 Did you fork aports? 2024-01-27 14:01:25 yes 2024-01-27 14:01:33 https://gitlab.alpinelinux.org/users/cristian_ci/projects 2024-01-27 14:01:37 and git remote add command works 2024-01-27 14:01:51 That only sets up git configuration 2024-01-27 14:01:53 ikke, I've added fork through command line 2024-01-27 14:01:58 cristian_c: how? 2024-01-27 14:02:00 Apparently not 2024-01-27 14:02:06 git remote add does not fork the repoi 2024-01-27 14:03:47 ikke, i mean, before these two commands, I've made the git changes locally (including checkout branch, add, commmit, ...) 2024-01-27 14:04:06 You need to go here: https://gitlab.alpinelinux.org/alpine/aports/ 2024-01-27 14:04:09 and click on the fork button 2024-01-27 14:04:19 ikke, ok, I try to fork aports via webinterface 2024-01-27 14:04:34 You can do it through the CLI, but then you need something like glab 2024-01-27 14:05:03 You can't push or pull repositories using SSH until you add an SSH key to your profile. 2024-01-27 14:05:15 Your account is authenticated with SSO or SAML. To push and pull over HTTPS with Git using this account, you must set a password or set up a Personal Access Token to use instead of a password. For more information, see Clone with HTTPS. 2024-01-27 14:05:42 ikke, both required? 2024-01-27 14:05:44 To clone it, you don't need it, but before you can push, you need to create a personal access token 2024-01-27 14:05:46 No, just one 2024-01-27 14:06:00 ok 2024-01-27 14:06:04 Either an ssh key, if you clone through ssh, or a personal access token if you use https 2024-01-27 14:08:23 I think only 'master' branch to fork (there are 41 branches) 2024-01-27 14:09:03 yeah, that's fine 2024-01-27 14:12:33 ikke, forked. Now, if I try to create a token, I see Select scopes 2024-01-27 14:12:50 *personal access token 2024-01-27 14:13:28 there are a bunch of choices 2024-01-27 14:13:37 At least read/write_repository 2024-01-27 14:14:07 Grants read-write access to repositories on private projects using Git-over-HTTP (not using the API). 2024-01-27 14:17:33 ikke, I've added personal access token but git push still fails 2024-01-27 14:17:45 Does it ask for a password? 2024-01-27 14:17:52 yes 2024-01-27 14:17:58 Did you provide that token? 2024-01-27 14:18:39 the git command misleaded me 2024-01-27 14:19:11 enumerating objects 2024-01-27 14:21:27 ikke, I suppose it's going to sync/add the new branch with gitlab alpine fork 2024-01-27 14:24:01 writing objects 2024-01-27 14:32:56 remote resolving deltas seems stuck 2024-01-27 14:51:00 ikke, thanjs 2024-01-27 14:51:04 *thanks 2024-01-27 15:44:52 cely, timlegge: a suggestion for apkbuild-cpan https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10129 2024-01-27 15:54:15 Fine with me, but i'm heading out, and we're using timlegge's MR now, so if he's alright with it, he can make the change 2024-01-27 15:54:24 I'll update apkbuild-pypi tomorrow 2024-01-27 16:11:48 omni: done - does that sort it for you? 2024-01-27 16:31:58 It does not move it on recreate though. I will take another look 2024-01-27 18:59:44 actually, it seems to do that correctly now that I look at it closer 2024-01-27 19:01:25 <3 2024-01-28 03:30:29 timlegge: i have left a comment on your apkbuild-cpan MR regarding a new bug i fixed (found this bug while running `apkbuild-cpan upgrade`) 2024-01-28 03:42:51 Thanks I will look in the morning, 2024-01-28 10:40:52 for one package, I update its version, enable check and add pkg-config.patch, how should I write this commit message 2024-01-28 10:41:36 And do I need to splite three commit? 2024-01-28 10:46:03 qaqland: Just a single commit can suffice. The subject would mention the upgrade, in the body you can mention details about the pkg-config patch 2024-01-28 10:49:01 got it, thx~ 2024-01-28 13:17:42 one arch test failed for Segmentation fault !59786, should I disable this arch or disable check? 2024-01-28 13:24:06 qaqland: if you have a strong suspicion it's just the tests that's the issue you can disable the tests, but otherwise disable the arch 2024-01-28 14:14:33 I disable check because it is disable before :) also waiting upstream fix 2024-01-28 14:39:57 cely: merged and pushed to the MR 2024-01-28 14:51:17 Thanks :) 2024-01-28 15:25:24 I am running recreate against all of main at the moment. I will review the results to see if there are any issues 2024-01-28 15:25:53 ...that I can see by eye-balling the diff 2024-01-28 15:26:59 I have a script that does an abuild for each recreated APKBUILD too as it runs so I will review that too 2024-01-28 15:34:19 Alright, hopefully it will work well enough for most aports 2024-01-28 18:49:45 cely: see https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/243#note_373406 2024-01-29 00:12:29 is there an 'optional dependency' feature in apkbuild? I thought there was but can't find it in the wiki. 2024-01-29 00:32:47 elagost: nope, at least not yet 2024-01-29 01:17:37 timlegge: it seems you're looking at moddata not distdata to decide that, a potential issue i can see is if the module in question doesn't have pod but other modules in the distribution do 2024-01-29 01:30:04 celie: I was trying to find some method to determine if pod exists - distdata does not have it. I just remembered though that the module is extracted so in theory greping it for "=head' would indicate it 2024-01-29 01:30:53 The only affected module I know of in main is perl-astro-suntime 2024-01-29 01:33:53 Ok 2024-01-29 01:37:35 I think, for `recreate`, we should consider keeping the old subpackages, but that would involve also carrying over the split functions that create those subpackages, which may complicate things 2024-01-29 01:41:38 my latest is https://paste.debian.net/1305599/ 2024-01-29 01:42:27 not enough testing to push yet but should work 2024-01-29 01:55:25 I'm trying that change out 2024-01-29 02:01:10 timlegge: This may be a very contrived example, but `apkbuild-cpan create Types::Standard::Tuple` illustrates the issue i was thinking about 2024-01-29 02:02:37 $moddata contains the results of looking up `Types::Standard::Tuple`, which contains no POD, but other modules in the distribution (Type-Tiny) do 2024-01-29 02:08:38 There may be 2 issues here: (1) using `create` with a module that isn't the main module/the module the distribution is named after, (2) the main module not having POD while other modules in the distribution do 2024-01-29 02:13:49 celie: yes, it looks like that will not work (or needs more research). It might be easier for me to get COMAINT on Astro::SunTime and add pod... 2024-01-29 02:20:24 I do wonder why perl-astro-suntime and perl-x10 are in main though... 2024-01-29 02:43:32 I took a closer look, and found that write_apkbuild is called before prepare_tree, so the files are not available then, and we can't grep them for "=head" 2024-01-29 02:47:46 Maybe we could do that later on and delete '$pkgname-doc' with regex if no POD is found, or just work with the $distdata we have in write_apkbuild and look through all the modules it contains for $moddata->{pod} 2024-01-29 02:50:58 However, that would add quite a bit of complexity to the script, and i think abuild doesn't error out if you need a -doc but don't have that in subpackages= 2024-01-29 02:51:32 So, it's probably better to have a -doc and let abuild error out if it is not needed 2024-01-29 02:55:00 celie: abuild does fail for perl-astro-suntime if subpackage is defined... 2024-01-29 02:56:29 Yes, i mean it is better for it to fail, and the maintainer removes -doc manually, rather than -doc being needed and it doesn't fail, which would result in the man pages going into the main package 2024-01-29 02:57:42 I mean, if the script makes a decision to remove -doc from subpackages=, it could turn out that it is actually needed, and IIRC, in that case, abuild will not error out 2024-01-29 03:01:37 So, the issue now becomes, we should probably keep subpackages= from the old APKBUILD, so it doesn't fail during `recreate` 2024-01-29 03:02:51 It will fail during `create` and the maintainer will then remove -doc from subpackages=, so we want to keep that decision during `recreate` 2024-01-29 03:04:02 However, this is only for -doc, if there are any other subpackages, we cannot carry them over without also carrying over the split functions that create them 2024-01-29 09:49:56 hey 2024-01-29 09:50:01 i am #chimera-linux dev 2024-01-29 09:50:02 lwae 2024-01-29 09:50:03 rlewa 2024-01-29 09:50:03 ewa 2024-01-29 09:50:04 rewa; 2024-01-29 09:50:04 re; 2024-01-29 09:50:05 ewa;r 2024-01-29 09:50:06 'wa;'rwa 2024-01-29 09:50:06 e;r'ewa 2024-01-29 09:50:07 ';ewa 2024-01-29 09:50:08 rewa 2024-01-29 09:50:09 ;waewa 2024-01-29 09:50:09 w 2024-01-29 09:50:11 ew 2024-01-29 09:50:11 qw 2024-01-29 09:50:13 e 2024-01-29 09:50:13 ewq 2024-01-29 09:50:15 ewq 2024-01-29 09:50:15 q 2024-01-29 09:50:17 ewq 2024-01-29 09:50:17 wq 2024-01-29 09:50:19 ewq 2024-01-29 09:50:19 ewq 2024-01-29 09:50:21 ewq 2024-01-29 09:50:21 ewq 2024-01-29 09:50:23 ewq 2024-01-29 09:50:23 wqe 2024-01-29 09:50:25 ewq 2024-01-29 09:50:25 ewq 2024-01-29 09:50:27 wq 2024-01-29 09:50:27 ewq 2024-01-29 09:50:29 qwe 2024-01-29 09:50:29 eq 2024-01-29 09:50:31 WQ 2024-01-29 09:50:31 wq 2024-01-29 09:50:33 A/ 2024-01-29 09:50:35 A/ 2024-01-29 09:50:35 A/ 2024-01-29 09:50:37 A/ 2024-01-29 09:50:37 A/A/ 2024-01-29 09:50:39 A 2024-01-29 09:50:39 A 2024-01-29 09:50:41 A 2024-01-29 09:50:41 A 2024-01-29 09:50:43 A 2024-01-29 09:50:43 A 2024-01-29 09:50:45 A 2024-01-29 09:50:45 A 2024-01-29 09:50:47 A 2024-01-29 09:50:47 A 2024-01-29 09:50:49 A 2024-01-29 09:50:49 A 2024-01-29 09:50:51 A 2024-01-29 09:50:51 A 2024-01-29 09:50:53 A 2024-01-29 09:50:53 A 2024-01-29 09:50:55 OK 2024-01-29 09:50:55 USE #ok 2024-01-29 09:50:57 i am q66 2024-01-29 09:50:57 #chimera-linux 2024-01-29 09:50:59 you all is troller 2024-01-29 09:50:59 i am #chimera-linux main devs 2024-01-29 09:51:01 use #chimera-linux 2024-01-29 09:51:01 alpine is trash project 2024-01-29 09:51:03 no GNU 2024-01-29 09:51:06 #chimera-linux 2024-01-29 09:51:10 go all is troller 2024-01-29 09:51:16 by q66 2024-01-29 09:51:20 #chimera-linux 2024-01-29 10:50:05 lol 2024-01-29 11:36:55 o_O 2024-01-29 11:37:44 o_o 2024-01-29 11:38:03 he's on #chimera-linux too xD 2024-01-29 11:38:07 as q66isgay 2024-01-29 11:46:32 Is there any alpinelinux qemu image for package test? 2024-01-29 11:47:49 question from here: https://gitlab.com/jobol/mustach/-/issues/50 2024-01-29 11:49:13 qaqland: you could pull just the standard image no? 2024-01-29 11:51:00 oh well, qemu image, then the rootfs should be fine 2024-01-29 12:29:54 we have qemu images? 2024-01-29 12:42:19 timlegge: I've given it some more thought, and i think the lack of `subpackages="$pkgname-doc"` should be copied from the old APKBUILD during `recreate`, just like `options="!check"` is copied (the former prevents `doc()` from running, and the latter prevents `check()`) 2024-01-29 12:44:34 That sounds ok. Although I often think of recreate as undoing past configurations that are no longer required. That one is likely find, especially if the version hasn't change. 2024-01-29 12:45:04 s/find/fine/ 2024-01-29 12:51:15 timlegge: Will you implement that change or should i do it? I think i will let you do this one as i'm currently trying to find out why the regex in read_assignments_from_file fails when `options` comes after `sources` 2024-01-29 12:57:53 s/sources/source/ 2024-01-29 13:00:39 hello, is there a way to get a shell in the container used by `abuid rootbld`? A command which would download the sources, install the deps and then give you a prompt so you can test build methods without having to rebuild the container at each try. 2024-01-29 13:02:08 cely: I can probably take a look tonight if I have time, but it might be a little later this week 2024-01-29 13:04:50 ncopa, i checked on !59739 now - no approve button for me 2024-01-29 13:04:57 (i did not review the work yet) 2024-01-29 13:10:03 timlegge: No problem, take your time 2024-01-29 13:14:00 Habbie: I've added you as guest, you should be able to approve it now 2024-01-29 13:14:04 ncopa, a button has appeared 2024-01-29 13:14:06 thank yuou 2024-01-29 13:14:08 *you 2024-01-29 13:15:15 cely: No good reason that regex should have an issue. Which package are you seeing the issue with? 2024-01-29 13:16:56 timlegge: i didn't look for an actual APKBUILD, i just placed `options` after `source`, and tried to recreate it 2024-01-29 13:17:15 If `options` comes before `source`, then everything is fine 2024-01-29 13:17:44 Lol. Don't do that ;-). If I get a few minutes I'll look at a couple of things that doesn't make a lot of sense. the fact that it fails 2024-01-29 13:19:47 Yes, i know the template places `options` before `source`, but i think `options` is always written by humans and the script doesn't write it 2024-01-29 13:21:10 So, it will have to start somewhere, and that means it could come after `source` (running `recreate` after that would move it to its place according to the template) 2024-01-29 13:27:52 cely: I have been giving some thoughts to whether some of the script would make sense to be pulled into some cPan modules. Things like parsing the APKBUILD etc. it also done some work a year ago on using the metacpan client for querying the API. At the time it was not accepted because there were too many dependencies that would need to be pulled into main 2024-01-29 13:32:51 timlegge: Having them as CPAN modules would also mean less duplicate code in apkbuild-pypi. Has the dependency situation for MetaCPAN client changed? i mean, i think it will still pull many dependencies into main, so probably still not acceptable. 2024-01-29 13:35:05 I don't think that has improved but I will take another look. The cPan modules part could be done though 2024-01-29 13:57:48 Wait a minute, i've been looking at read_assignments_from_file for a while, and only now noticed that it checks for a requires= field (i assumed it was replaces=)...do we even have such a field in APKBUILD? 2024-01-29 13:58:53 No 2024-01-29 14:00:08 Thanks 2024-01-29 14:02:04 i've also been thinking about !59459, and i might want to implement this (removing man pages from modules already bundled with Perl) in apkbuild-cpan later on 2024-01-29 14:02:30 So, which is the better way to do it, rm'ing the man pages, or adding a replaces= 2024-01-29 14:04:26 main/perl-compress-raw-zlib and perl-compress-raw-bzip2 rm the man page, and i've followed that in my MR, but as i mentioned in my MR description, i found 5 aports that use `replaces="perl-doc"` instead 2024-01-29 14:16:07 omni: Thanks for merging !59398 😃 2024-01-29 15:40:12 timlegge: i think the `options` after `source` issue has something to do with using the /g regex modifier, so i've changed /mg to just /m, and pushed a commit to my branch which seems to solve the problem for me, you may take a closer look at the issue when you are free 2024-01-29 15:41:16 Weird. The g is just greedy so it should find all the matches but in theory there should only be one match in the file 2024-01-29 15:45:29 The error i originally got while moving `options` after `source` was "can't use undefined value as an ARRAY reference", and so i added an else branch that always initializes $hash{patches} to an array ref (also in the commit i pushed) 2024-01-29 15:45:54 However, that made the problem worse, as instead of erroring out, apkbuild-cpan would then silently drop all patches 2024-01-29 15:46:47 It seems like removing /g prevents that, but you may be able to find a better solution 2024-01-29 15:48:37 Anyway, this probably needs to be fixed, as there is no standardized position for `options` (and apkbuild-cpan only touches this during `recreate` not `create`), so maintainers are free to place it after `source` 2024-01-29 16:00:42 So, this issue is triggered while recreating an APKBUILD that has patches in `source` and has `options` below `source` (and if it matters, the aport i tried this out with was perl-anyevent-xmpp, it doesn't have `options`, but i added it in) 2024-01-29 16:01:51 papiris[m]: hope it's useful! 2024-01-29 16:05:56 cely: requires looks to be unnecessary - not really sure why I added it in https://gitlab.alpinelinux.org/timlegge/abuild/-/commit/b60dd09b3b1d80529249a28f419644f1f66bc0e0 2024-01-29 16:06:49 Yes, you were probably thinking about replaces but typed requires instead 2024-01-29 16:09:23 and maybe you added that to deal with having a comment after provides/replaces, if you compare the regex in https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/apkbuild-pypi.in#L72 with what's in apkbuild-cpan 2024-01-29 16:10:09 you'll see that the apkbuild-pypi one matches (but doesn't capture) comments 2024-01-29 16:11:53 Hmm, but there is also the duplicated double quotes in the regex: \"(.*)\"".* 2024-01-29 16:11:57 so they are never used anyway 2024-01-29 16:16:18 s/used/matched/ 2024-01-29 16:35:31 ~/aports/community/perl-event recreate shows: Can't use an undefined value as an ARRAY reference at /home/tim/abuild/apkbuild-cpan line 158 2024-01-29 16:36:13 adding a check for if defined $apkbuild->{patches} and scalar ... fixes the issue 2024-01-29 16:36:31 options is after source for that APBBUILD and works fine 2024-01-29 16:36:48 s/APBBUILD/APKBUILD/ 2024-01-29 16:36:53 cely: ^ 2024-01-29 16:38:05 Yes, but that doesn't have patches 2024-01-29 16:38:14 ah 2024-01-29 16:38:15 If you have patches, i think they would be dropped 2024-01-29 20:53:49 cely: wow that source/options thing is weird... I am testing with perl-xml-easy by adding the options - above sources its fine below breaks 2024-01-30 00:07:14 cely: https://paste.debian.net/hidden/6de91742/ 2024-01-30 00:08:01 a couple of things - read_assignments_from_file is reused for multiple files so I added a return early if not APKBUILD 2024-01-30 00:12:11 I am not totally convinced about the new source regex but it does seem to work. It assumes no comment after the source which is *probably* ok 2024-01-30 00:31:42 Typo: unanble => unable 2024-01-30 00:37:49 For apkbuild-pypi, i've decided to just reuse $hash{'source'} (that's matched by the %mline regex), instead of trying to match it again with a new regex, but i guess either way is fine, as long as patches don't get silently dropped 2024-01-30 00:54:59 timlegge: By the way, for apkbuild-pypi, i also had some problems with provides and replaces, their /g regex seems to cause lines coming after them to not match, so i just ended up removing /g for most of the regex in read_assignments_from_file in my apkbuild-pypi MR 2024-01-30 00:59:14 For Python aports, i've noticed that provides and replaces usually come after source and builddir (and i've moved them there in the template so `recreate` keeps their positions), so maybe this won't be triggered if they are placed before source like in the apkbuild-cpan template 2024-01-30 01:10:50 celie: good point - $hash{'source'} works great - this script has "evolved" over time so it likely does things it should not.. in inefficient ways 2024-01-30 01:25:51 timlegge: Have you looked at the duplicated double quotes in the provides and requires (which probably should be replaces) regex in read_assignments_from_file? 2024-01-30 01:26:36 just looking at whether those are needed at all 2024-01-30 01:27:00 the sline/mline should get things unless we need/want comments 2024-01-30 01:29:13 Yes, but those only match if there are no comments 2024-01-30 01:31:05 Anyway, i've removed the duplicate double quotes, and now i see the /g problem, options with a comment will be dropped if provides comes after it 2024-01-30 01:34:10 It's like /g forces the order of the lines to follow what's in the source code, as in the match for `options` comes before `source` in apkbuild-cpan, so when both had /g, `options` after `source` in APKBUILD causes problems 2024-01-30 01:35:34 After removing the duplicate double quote, `provides` would match before `options` in apkbuild-cpan, and if it the order is switched in APKBUILD, it doesn't work 2024-01-30 01:35:57 I think the duplicate is unnecessary for sure 2024-01-30 01:36:34 Of course, it would actually need to match the `options` regex, so if there is no options comment, then this isn't triggered 2024-01-30 02:12:35 I need to contribute an EFI configuration for linux-lts how could i do that and test the kernel to make sure it works without issues for https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4743 ? 2024-01-30 02:12:56 namely this https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4774 but for linux-lts 2024-01-30 02:56:05 celie: https://wiki.alpinelinux.org/wiki/APKBUILD_Reference only reference comments after the options (if its !check) 2024-01-30 02:56:40 one could decide that they are not supported at all on multi-line values 2024-01-30 03:16:40 celie: https://paste.debian.net/1305700 neither of those provides or requires are necessary - there are no current packages that include comments on those settings 2024-01-30 03:18:12 Alright, but it's different for apkbuild-pypi, as there are comments associated with those 2024-01-30 03:22:41 I don't think the current use of `$hash{source}` or your previous regex for matching `source=` address the case when the first line is empty 2024-01-30 03:23:49 community/perl-crypt-random and perl-html-tidy5 that you maintain are examples of that 2024-01-30 03:24:40 I will look 2024-01-30 03:25:39 not sure the comments that grep -r 'replaces=' ./*/py3-*/APKBUILD | grep -v '#.*ackward' are really necessary 2024-01-30 03:26:12 the grep '#.*ackward' really aren't... 2024-01-30 03:28:12 My apkbuild-pypi MR handles those comments 2024-01-30 03:28:46 ah... 2024-01-30 03:35:30 I think once this change that fixes `options` after `source` and empty lines in `source` is pushed to your MR, it should be ready to merge (unless some other bug is found that needs an urgent fix) 2024-01-30 03:36:07 As for the -doc subpackage issue, that can come later, or you can put in a quick fix 2024-01-30 03:36:48 Later, because as i said about half a day ago, i may plan to implement a standardized way of removing conflicting man pages 2024-01-30 03:37:08 I think that would also involve removing -doc 2024-01-30 03:37:35 unless there are arguments for using `replaces="perl-doc"` instead 2024-01-30 03:38:13 yeah, I will look at subpackage in the future 2024-01-30 03:39:20 It will be tomorrow for sure. I see the issue with community/perl-crypt-random and perl-html-tidy5 2024-01-30 03:39:41 Sure, take your time 2024-01-30 03:40:01 simple enough to naively fix but I need to think on it while I sleep - good night 2024-01-30 03:41:21 Good night 2024-01-30 14:09:33 ncopa, btw. I am on IRC if you want to talk about https://gitlab.alpinelinux.org/alpine/aports/-/issues/15732 2024-01-30 15:52:38 ikke: so much for the idea of creating a *draft* MR to flag WIP and prevent someone else creating a "rival" MR... 2024-01-30 16:07:28 @ncopa: there needs to be some formal mechanism for people to "flag" new aports they are working on so they don't waste their time when others (with merge permissions) can come along and suddenly create & merge a new aport without warning...so meaning the original person has wasted their time 2024-01-30 16:10:07 agreed, it's a problem across most projects actually. 2024-01-30 16:10:27 i've had that done to my work numerous times to the point where i stopped doing mrs altogether 2024-01-30 16:10:32 (not here, but elsewhere) 2024-01-30 16:11:16 it's demoralizing for people outside the main committers 2024-01-30 16:12:42 i'm not sure it's something you solve with software, though 2024-01-30 16:13:46 I believe for example Debian have their "intent to package" list which avoids this 2024-01-30 20:09:07 minimal: I'm curious how that list avoids these kinds of issues. From what I can see it's still just a list someone must manually consult? 2024-01-30 20:09:49 yes but at least it represents some form of "process" 2024-01-30 20:10:39 whereas currently it seems to be a case of either "first to MR wins" or else "second to MR but has merge privs wins" 2024-01-30 20:11:41 we all have limited time, I don't want to "waste" a large amount of time working on a new aport if someone else is also working on it 2024-01-31 13:20:05 timlegge: i left a comment on your apkbuild-cpan MR regarding one last change i would like included, please take a look when you have time, after adding that and briefly addressing the pragmas and warnings, i think the MR should be quite ready to merge :) 2024-01-31 15:59:26 Forrest flame that looks great. I will merge tonight 2024-01-31 16:00:25 s/Forrest flame/First glance/ 2024-01-31 16:10:06 :D 2024-01-31 16:15:55 that's exactly what an arsonist would say 2024-01-31 18:02:25 skarnet: lol... Normally I blame speech to text for my failings when typing but this was all on me 2024-01-31 19:38:16 lol 2024-01-31 19:43:22 minimal: I'm sorry about the incus thing. You did all correctly by both communicate it on IRC and creating a draft MR. 2024-01-31 19:45:29 I would think creating a draft MR should be enough, but I am open for ideas on better suggestions 2024-01-31 19:46:00 ncopa: what annoys me so much about that is that I took the time to carefully work on Incus, read upstream's packaging guidelines and tried to follow them, trying to work do break existing LXD (by packaging forked raft separately and emailing both lxd and lxd-feature maintainers to discuss the matter) etc 2024-01-31 19:46:27 I didn't just do a quick "it builds so trow it in testing and forget about it" approach 2024-01-31 19:47:37 I also discusses things with upstream over a time period, I found an intermittent testing bug in cowsql's raft and they fixed it in a newer release, etc 2024-01-31 19:47:56 and then you almost got overrun by ikke 2024-01-31 19:48:04 and steamrolled by larena 2024-01-31 19:48:17 so I invested quite a lot of time into getting this packaged 2024-01-31 19:48:33 but that doesn't appear to be the Alpine way it seems 2024-01-31 19:49:41 well, I think it should be 2024-01-31 19:50:35 Just one detail is that we _do_ have a testing repository, so it doesn't have to be completely perfect right from the start 2024-01-31 19:50:42 but it is also a trade off 2024-01-31 19:50:45 yeah 2024-01-31 19:51:41 that was the original idea with the testing repo, to give access to early testing 2024-01-31 19:51:52 but that was from a time before CI 2024-01-31 19:53:00 minimal: for the record, I'm not trying to downplay your effort in any way 2024-01-31 19:53:21 i dont think anyone is trying that 2024-01-31 19:54:13 and I think everybody wants to and tries to avoid stepping on each others toes 2024-01-31 19:56:15 ikke: a "problem" with testing repo is that once stuff arrives there people may start using it, so make *fundamental* changes hard to do later - so I believe the fundamental layout etc of new aports should be "firmed up" before going into testing 2024-01-31 19:56:26 but its difficult to avoid completely 2024-01-31 19:56:44 to avoid to otherwise have to then start adding "upgrade" compatability 2024-01-31 19:56:48 minimal: imo, as long as it's still in testing, people should expect breaking changes 2024-01-31 19:57:08 ikke: should, but doesn't mean they don't complain 2024-01-31 19:57:25 ncopa: and I wouldn't use the word "steamrolled" 2024-01-31 19:57:27 Well, now people complained that incus was not available 2024-01-31 19:57:53 minimal: there is value in getting feedback 2024-01-31 19:57:57 ikke: and people complained that opentofu was not available before it had a release... 2024-01-31 19:58:17 what we absolutely should avoid is that it is always the same person that get the toes stepped on so they get all blue 2024-01-31 19:58:32 ikke: I'm not sayoing a package had to be perfect before going into testing, but at least it should be more-or-less functional 2024-01-31 19:59:15 minimal: that's reasonable 2024-01-31 19:59:30 and the whole question of "do we replace the raft package using the new fork or do we create raft-cowsql" was a fundamental question that needed to be resolved before getting incus into testing 2024-01-31 20:00:11 and now that first option has been done - and I haven't even seen whether the maintainer of lxd-feature knows or is happy about that change affecting *their* package... 2024-01-31 20:00:58 i.e. both lxd and lxd-feature, which have different maintainers, have had a dep changed by the maintainer of 1 of those packages, I assume without discussion with the other maintainer 2024-01-31 20:01:34 minimal: They know eachother pretty well 2024-01-31 20:03:18 ikke: ok, but lxd-feature hasn't been (re)built since mid Dec.......so however unlikely it is possible it might have issues with the raft change 2024-01-31 20:04:03 I haven't looked at the incus package or your draft yet, so I dont want comment that 2024-01-31 20:04:10 have had a few days off recently 2024-01-31 20:04:30 but could consider revert the merged stuff 2024-01-31 20:05:05 also I intended to raise my Incus MR earlier this month but I ended up wasting a week or so then dealing with the whole Grub fiasco 2024-01-31 20:22:19 ncopa: just forget about my Incus MR, I'm not looking for the other one to be reverted. I really think I've reached the point of giving up maintainership of Alpine packages and of active involvement in Alpine and instead just quietly continue using Alpine (as I haven't found any suitable alternative) myself and not give anything back 2024-01-31 22:47:11 minimal: I respect that. If you no longer find joy in contributing it might be better to take a break. 2024-01-31 22:48:01 and hopefully you find something you can contribute with, that you find fun 2024-01-31 22:52:48 ncopa: it is not about joy or fun about things to contribute in - I have been contributing in things I enjoy (cloud-init etc), it is the organisation or indeed disorganisation and "politics" around Alpine that has been getting to me 2024-01-31 22:54:21 I usually is 2024-01-31 22:54:46 I mean, dealing with tech is easy. dealing with people is hard 2024-01-31 22:55:49 dealing with people can be exhausting 2024-01-31 22:55:55 it doesn't help when you're made ot feel that some of your contribution are, how should I say, almost "unwanted" or at least looked down on 2024-01-31 22:57:04 yup. I completely understand that 2024-01-31 22:58:03 or when downstream users demands fix things you maintain, ASAP, without saying thanks. and then complain that it took too long time 2024-01-31 22:58:30 or when they get angry that you are not willing to spend your free time giving them support 2024-01-31 22:59:46 well I'm not thinking in terms of users but rather Alpine devs 2024-01-31 22:59:48 or when companies making money on what you give them for free, send you a machine generated list of CVEs they expect you to analyse and fix 2024-01-31 23:00:04 and half of them are bogus 2024-01-31 23:00:30 in theory Alpine devs are all on the same team 2024-01-31 23:00:44 right 2024-01-31 23:01:06 politics between devs happens in lot of distros...its tiring for sure 2024-01-31 23:01:33 dealing with people is what burns you out in the end 2024-01-31 23:02:09 and that applies to dealing with users or other devs 2024-01-31 23:02:21 that why I say that dealing with people is the hard part 2024-01-31 23:03:08 i've contributed small fixes to many projects now, i've had great interactions and horrible ones, its just how it goes 2024-01-31 23:03:45 and when those issues keep you up at night, and disturbs your sleep, then it may be worth consider taking a break, or do something about it 2024-01-31 23:04:23 i have more than once considered taking a break from alpine 2024-01-31 23:04:28 what is they to "do" from an Alpine perspective? there's no really rules or processes formally defined etc 2024-01-31 23:04:35 s/they/there/ 2024-01-31 23:05:16 to "do"? 2024-01-31 23:05:34 ah sorry 2024-01-31 23:05:36 "do something about it" 2024-01-31 23:06:25 heh, you know what just hit me 2024-01-31 23:07:03 that's the reason why there are so few rules and formal processes 2024-01-31 23:07:33 dealing with the policies and process etc is the boring part 2024-01-31 23:07:40 nobody wants to do it 2024-01-31 23:08:08 I remember several occasions when I first started with Alpine raiding some MRs and having them reject as I didn't follow policy but when I asked where the policy I was told "it is not written down anywhere" 2024-01-31 23:08:14 s/raiding/raising/ 2024-01-31 23:08:50 that's stupid. how are contributors supposed to know that? 2024-01-31 23:08:58 exactly my point 2024-01-31 23:09:26 hopefully we have added some contributing guidelines and code style guides 2024-01-31 23:09:37 ..since then 2024-01-31 23:10:22 I think what to "do" from alpine perspective 2024-01-31 23:10:35 or more like, what can be done 2024-01-31 23:10:42 is to improve documentation 2024-01-31 23:11:16 and that is in general 2024-01-31 23:11:33 we had a discussion the other week on how to improve docs 2024-01-31 23:11:57 it's more than just lack of docs though 2024-01-31 23:12:14 yeah, but its a starting point 2024-01-31 23:13:02 "why did you...? we expect you to behave like this... " 2024-01-31 23:13:13 it seems that the issues brought up recently is more that stuff stalls and nothing happens 2024-01-31 23:13:15 how are the devs supposed to know that if its not documented 2024-01-31 23:13:37 stuff stalls? 2024-01-31 23:13:47 the Grub situation is a perfect example: see a problem before it happens, flag the problem, draft a potential solution for the problem but not have it accepted..........problem then hits several months later, provide a 2nd draft solution, also have that "rejected", be expected to come up with a 3rd partial potential solution... 2024-01-31 23:13:48 the Grub MRs 2024-01-31 23:14:23 I may have missed the past week or two, but it seems like there were comments on both with some discussion and then things kind of went nowhere 2024-01-31 23:14:48 as minimal said, he flagged it months ago and nothing happened 2024-01-31 23:15:01 and then it broke again, as minimal predicted 2024-01-31 23:15:20 I'm talking about just the MRs and indeed I missed your last changes a week ago 2024-01-31 23:16:04 before that it felt like we were at a point where either could go forward but nobody could decide. I'm not an Alpine dev so I don't feel like I should push anywhere, minimal is submitting the MR so they aren't really the one to choose, so what is supposed to happen? 2024-01-31 23:16:07 so the grub thing was communication challenges 2024-01-31 23:16:24 and I am the one to blame there 2024-01-31 23:16:26 I've been slow to come up with a 3rd solution because (a) I lost at least a week at the start of the month dealing with the Grubn stuff which affected/delayed other stuff I had planned (like the Incus MR), and also unfortunately I've been halfhearted at doing the 3rd solution as I was predicting it to also be "rejected" 2024-01-31 23:17:08 the grub problem was that when it first hit, it only hit aarch64 users 2024-01-31 23:17:33 I had problems understanding what the real problem was 2024-01-31 23:17:44 or had problems understanding the proposed solutions 2024-01-31 23:17:49 I don't know how things run, but I would have guessed that this was something the TSC would bring up and a direction would be chosen that devs and others would do will happen 2024-01-31 23:17:56 maybe that's not the point of the TSC at all, I don't know 2024-01-31 23:18:07 i was not even able to reproduce the problem 2024-01-31 23:18:40 well, grub thing would have been a good thing for the TSC 2024-01-31 23:18:48 well the "real" problem as originally explained regarding Grub was "no-one gets updated Grub code after their initial installation which means any security fixes, bug fixes, or new functionality is not actually in use" 2024-01-31 23:18:48 thats true 2024-01-31 23:19:28 so even without any obvious update breaks there was still quite an important issue 2024-01-31 23:19:37 yes, but im stupid 2024-01-31 23:19:52 I could not understand why this only appears to happen every 10-15 years 2024-01-31 23:20:01 or if it also affects ppc64 2024-01-31 23:20:09 or if it also affects bios 2024-01-31 23:20:23 does MBR need to be updated? 2024-01-31 23:20:43 I could not understand why this was something that only hit Alpine 2024-01-31 23:20:54 or how other distress solved it 2024-01-31 23:21:03 what is the "recommended" way to deal with it 2024-01-31 23:21:15 the same logical problem also impact on other bootloader package such as Syslinux........it's just that Syslinux is "dead" upstream and basically no functional changes have happened in years 2024-01-31 23:21:45 syslinux has broken once as far I can remember 2024-01-31 23:21:51 once in 10-15 years 2024-01-31 23:22:17 and also that the Alpine syslinux package also doesn't actually *build* syslinux, it uses pre-compiled binary files apart from building the *installer* 2024-01-31 23:22:19 and also there I have never seen any "good" solution. everybody only seemed to ignore the problem 2024-01-31 23:23:19 and the proposed solutions looked over engineered. I wanted a simpler solution 2024-01-31 23:23:31 I did not communicate that well enough 2024-01-31 23:24:27 i also didn't understand the setup-disk parts that ran grub-install 2024-01-31 23:24:33 a simpler solution is something that actual solves things in a simple fashion, if something is simple but doesn't solve things then it's not a solution 2024-01-31 23:24:53 why was the grub*.efi copied? why was not grub-install ... --removable used? 2024-01-31 23:25:31 I assume because someone also wanted a grubx64.efi around in case the fallback file got replaced by another OS 2024-01-31 23:25:48 why is the grub*.efi installed under EFI/ but no efi vars updated? 2024-01-31 23:25:57 which efi is actually used when booting 2024-01-31 23:26:08 was this only affecting efi? 2024-01-31 23:26:42 I did not understand 2024-01-31 23:27:20 I should have taken the time to investigate what the problem was, and how things work properly 2024-01-31 23:27:29 because "--no-nvram" tells Grub not to set EFI variables 2024-01-31 23:27:37 I know all that now 2024-01-31 23:27:49 but you didn't seem to "trust" what I was telling you 2024-01-31 23:28:03 what im saying is, back then I did not understand 2024-01-31 23:28:20 it felt like I had to explain everything in minute detail to you as you had no trust in my competence 2024-01-31 23:29:20 well, that's partially true. I did understand that there is a problem. I did understand that something needed to be done about it 2024-01-31 23:29:32 even if I kinda hoped we could get away with just documenting it 2024-01-31 23:29:48 and hoped that it was a once in a decade kind of issue 2024-01-31 23:30:31 but I could not understand why all the proposed solutions had to be so complicated 2024-01-31 23:31:42 because there are 1001 scenarios for booting? encryption yes/no? LVM yes/no? BIOS/UEFI? which fstype? Software RAID? "FDE" yes/no? 2024-01-31 23:32:16 "standard" / non/-standard partitioning layouts 2024-01-31 23:32:33 (in the larger context) what about gitlab/org stuff is worth changing to address this kind of thing 2024-01-31 23:34:57 and it does not help that I dont like grub to begin with. does not help with motivation 2024-01-31 23:35:21 ok, but it is the only "official" bootloader for EFI in Alpine... 2024-01-31 23:35:33 yeah, and I dont like it :) 2024-01-31 23:36:27 its the only booloader that works on almost every arch we support 2024-01-31 23:36:46 and in that regard about motivation, it does still "rankle" with my as cloud-init maintainer that in the past you've made it clear you don't really like cloud-init/have a degree of "distain" for it 2024-01-31 23:37:42 let me put it this way: im happy that you take care of it so I don't have to :) 2024-01-31 23:38:06 well I've been left feeling that you'd rather not have it in Alpine at all 2024-01-31 23:38:38 some of us talk shit about grub and cloud-init but i for one think it's important that they exist and work well. 2024-01-31 23:39:00 there are lots of things I'd rather not have in alpine at all 2024-01-31 23:39:35 but I also understand that there are people who use and need stuff that I don't care for 2024-01-31 23:39:56 when it comes to cloud-init, I'd rather say I have mixed feelings about it 2024-01-31 23:40:24 there are some nice things with it 2024-01-31 23:41:21 and i do think it has its place in alpine 2024-01-31 23:42:04 but please also understand that there is *alot* of stuff in alpine. I cannot deal with all of it 2024-01-31 23:42:10 that, perhaps unfortunately, is not the impression I was left with 2024-01-31 23:42:25 I simply dont have resources to deal with all of it 2024-01-31 23:43:12 so when someone steps up and takes care of parts, so I dont have to deal with it, im happy 2024-01-31 23:43:15 agreed, but there seems to be hesitance to hands off some responsibilities to others 2024-01-31 23:43:33 yeah, i suppose that's my problem 2024-01-31 23:45:19 re trust your competence 2024-01-31 23:45:20 but regarding the Grub stuff, if you don't understand how it works shouldn't you rely on someone who does for advice? 2024-01-31 23:45:40 i dont doubt that you are competent. I know you are 2024-01-31 23:46:02 and you do know stuff I dont. you understand stuff I dont 2024-01-31 23:47:13 but there are areas where I feel we think different 2024-01-31 23:47:21 that does not need to be a bad thing 2024-01-31 23:47:44 I agree 2024-01-31 23:48:58 but when someone submits several solutions and gets them knocked back and no alternative are suggested it's all very one-way and feels frustrating 2024-01-31 23:49:14 I totally get that 2024-01-31 23:50:15 it's easy to say "I don't like that solution", especially if you aren't suggesting alternatives 2024-01-31 23:50:24 ha 2024-01-31 23:50:27 indeed 2024-01-31 23:51:15 and its frustrating when its not well communicated why the presented solution is not liked 2024-01-31 23:52:53 but there's other signs of Alpine "disorganisation" 2024-01-31 23:53:12 ok? 2024-01-31 23:53:20 i.e. the lxd and lxd-feature packages are separately maintained and don't have the same sub-package layouts 2024-01-31 23:53:37 the linux-lts and linux-edge complete disconnect in configuration 2024-01-31 23:54:18 nobody bothered to coordinate 2024-01-31 23:54:21 I've though more than once of creating a linux-current package which maps config with linux-lts......but decided this would likely result in "issues" 2024-01-31 23:54:45 probably yes 2024-01-31 23:54:57 re linux edge 2024-01-31 23:55:00 i mean 2024-01-31 23:55:07 that's not a co-ordination issue, it's a specific decision not to co-ordinate 2024-01-31 23:55:26 I cannot speak about lxd, because I dont know what happened there or who takes care of it 2024-01-31 23:55:54 but I do know what happened with linux-its and edge 2024-01-31 23:56:33 I did say what I thought 2024-01-31 23:56:48 but there was a disagreement 2024-01-31 23:56:50 or various 2024-01-31 23:56:59 i.e. lxd has "vm" and "client" subpackages but lxd-feature doesn't, lxd-feature has a "doc" subpackage which lxd doesn't 2024-01-31 23:57:00 how it should be configured 2024-01-31 23:57:30 and there is/was even a disagreement on what the purpose of the linux-edge should be 2024-01-31 23:57:33 I noticed this when I started workig on incus packaging and looked at both lxd packages 2024-01-31 23:57:43 I did express what I wanted from the linux-edge 2024-01-31 23:58:04 but the maintainer said he did have time to follow the lts way of doing things 2024-01-31 23:58:14 and he had different goals 2024-01-31 23:58:26 for the linux-edge package 2024-01-31 23:59:00 i dont have resources to maintain another kernel. I can barely keep up with -lts 2024-01-31 23:59:02 right, which seems to be "outside" of the Alpine goals 2024-01-31 23:59:16 do we have a 'genkernel' (gentoo reference) kind of thing in alpine anywhere 2024-01-31 23:59:35 invoked: no. (not yet at least) 2024-01-31 23:59:58 that might help.