2024-02-01 00:00:15 well, my concern was more like that edge would easily be misunderstood 2024-02-01 00:01:06 I think it is misunderstood by newer users who expect same/similar config, just newer version 2024-02-01 00:01:26 so the choice was to either shut linux-edge down, because it was not aligned or coordinated with -lts, 2024-02-01 00:01:49 or allow it, and accept that we do not always need to do it my way 2024-02-01 00:02:31 at the cost of potential confusion and mis-coordination 2024-02-01 00:03:49 that's why it happened that way 2024-02-01 00:04:04 I don't mean to be "that person in the corner always complaining" but much of what I've raised in the past or tried to fix is stuff no-one else seems to want to bring up 2024-02-01 00:05:17 yeah I know you mean well 2024-02-01 00:05:42 and it is appreciated that someone push things in the right direction, even if its frustrating 2024-02-01 00:06:11 indeed, I'm not trying to create arguments, I'm actually trying to make Alpine better 2024-02-01 00:06:36 and I do have a lot of respect for you and for not simply giving up 2024-02-01 00:06:41 i know 2024-02-01 00:07:14 but it feels like its a pattern where I'll raise stuff, some "reassuring" words will be said, and then things will continue as usual 2024-02-01 00:07:22 ha 2024-02-01 00:07:34 yeah, they most likely will :) 2024-02-01 00:08:21 but hopefully slightly improved, and slightly nudged in a good direction 2024-02-01 00:08:28 minimal mentioned Alpine goals, but i don't think this is codified anywhere 2024-02-01 00:09:00 I think we have mission statement somewhere 2024-02-01 00:09:06 small simple secure something 2024-02-01 00:09:18 as in, explicitly, what is Alpine trying to do, and what is Alpine trying not to do 2024-02-01 00:09:34 the scope 2024-02-01 00:10:03 "hopefully slightly improved, and slightly nudged in a good direction" - its not particularly healthy for people to have to get repeatedly frustrated for things to move along though 2024-02-01 00:10:10 "Alpine Linux is an independent, non-commercial, general purpose Linux distribution designed for power users who appreciate security, simplicity and resource efficiency." 2024-02-01 00:10:44 if people have wrong assumptions about what work will be accepted for alpine, that will create some hard feelings 2024-02-01 00:10:49 best to have it clear up front 2024-02-01 00:11:06 minimal: thats true 2024-02-01 00:11:45 y'all are describing my dayjob 2024-02-01 00:12:20 and I do worry about peoples health, but ultimately, we need to trust that people take care of their own health. 2024-02-01 00:12:38 i'm a manager so delegating (or, phrased better, not delegating) is a continuous issue for me 2024-02-01 00:13:06 it is difficult 2024-02-01 00:13:19 as I said, dealing with people is the hard part 2024-02-01 00:13:37 and I have tremendous respect for people who are good at it 2024-02-01 00:14:06 re: grub/syslinux, my Alpine install got utterly destroyed due to a grub upgrade about a month ago, and it was easier to reinstall than try to recover from it, I was pleasantly surprised that the new install used syslinux 2024-02-01 00:14:29 I hate grub 2024-02-01 00:14:31 one thing we all can do, is be better at give positive feedback, and express appreciation 2024-02-01 00:14:32 always have 2024-02-01 00:14:41 valerius: Syslinux is always used for BIOS by default 2024-02-01 00:14:56 i'm not sure minimal needs appreciation as much as less gatekeeping 2024-02-01 00:15:19 yeah I'm not looking for appreciation 2024-02-01 00:15:58 noted 2024-02-01 00:18:31 ncopa: communication is key, from reading the earlier grub discussion a lot of this sounds like it could of been avoided if more time was taken to clear up what parts where not understood 2024-02-01 00:18:40 *were 2024-02-01 00:19:08 *nod* 2024-02-01 00:19:56 i can totally get why merging code only one person understands even if they are trusted can be problematic down the line, especially if its inherently complicated stuff like grub 2024-02-01 00:21:05 I think in my case, communication is what gets sacrificed early when Im under pressure, when there is too much on my plate 2024-02-01 00:21:15 and i strigle with keeping the head above the surface 2024-02-01 00:21:21 yea, only can be in so many places at once 2024-02-01 00:23:33 minimal knows what to do. the problem seems to be when work being submitted is not being reviewed and accepted. it leaves people hanging 2024-02-01 00:23:42 this is for anything, not just for the grub issue 2024-02-01 00:23:54 solution seems obvious, give minimal god powers 2024-02-01 00:24:28 so like, the clock should run out on review, and then it should go through (mea culpa on anybody who missed the window) 2024-02-01 00:25:07 ncopa: fwiw I know how frustrating it can be for the other person too when their hard efforts get ignored for reasons that may not be entirely clear, just as its likely hard for the distro devs to keep up with everything all of the time 2024-02-01 00:26:31 yup. I think we all have our share in contributing to various open source projects 2024-02-01 00:26:52 i never appreciated how the slackbuilds.org maitainers kept up with EVERYTHING once a week until I tried other distros :P 2024-02-01 00:26:58 *maintainers 2024-02-01 00:29:12 things that worries me right now: rust maintenance, follow up on llvm and clang test failures. binutils' ld change to 4k page alignment that broke user space for 32k page size kernels 2024-02-01 00:29:55 ncopa: the binutils 4k change also broke gummiboot and stubby boot for aarch64 back then, I've tried several times unsuccessfully to fix them 2024-02-01 00:29:56 and backporting security fixes for gcc 2024-02-01 00:30:45 the mentioned issues are things that would require some undisturbed time to focus on 2024-02-01 00:31:54 well not broke them currently as gnu-efi (which gummiboot and stubbyboot depend on) hasn't been rebuilt since binutils was updated 2024-02-01 00:32:23 bjut after a rebuild they'll break 2024-02-01 00:33:04 not sure exactly which binutils 4k change you are referring to now. Then one Im thinking about is for arm 32 specifically 2024-02-01 00:34:33 let me check the release notes 2024-02-01 00:35:01 oh, one thing minimal, that I think could have helped in the grub case, was a clear bug report with a good description explaining the exact problem 2024-02-01 00:35:45 if you have a specific issue with binutils, please file an issue with the details and references to relevant upstream issues, upstream commits etc 2024-02-01 00:36:28 what I'm referring to is a mess as gnu-efi upstream is a mess - the "relevant" discussion in their repo was a flamewar 2024-02-01 00:38:22 right. a clear summary of it is always appreciated. so I dont need to read 100 angry posts to be able to understand what the problem is about, or what the conclusion ended with 2024-02-01 00:39:09 I mean, that helps 2024-02-01 00:39:33 I'd have to dig through notes from several month ago, the background to it was quite confusing but basically a binutils change regarding aarch64 (which I though was "page size") objtools broke aspects of gnu-efi 2024-02-01 00:39:58 those are difficult 2024-02-01 00:40:00 and then the way upstream gnu-efi fixed it caused more problems from memory 2024-02-01 00:40:20 sigh... not surprised there 2024-02-01 00:40:28 as now other software using gnu-efi have to pass an additional objtool flag to build correctly 2024-02-01 00:41:38 but my attempts to locally fix this using current gnu-efi and gummiboot/stubbyboot (for UKI booting) went *backwards* i.e. as well as aarch64 versions of those not working also x86_64 no longer worked for me :-( 2024-02-01 00:43:09 but it was also possible that ZBOOT compressed aarch64 may also be a factor - I don't think either gummiboot or stubbyboot support those 2024-02-01 00:43:28 oh well 2024-02-01 00:43:38 s/aarch64/aarch64 kernel/ 2024-02-01 00:44:58 it that's the root cause then we've got a problem as linux-lts aarch64 IS ZBOOT compressed (that's what caused the Grub aarch64 issue last Nov as the running Grub didn't have ZBOOT support as grub-install wasn't being run) 2024-02-01 00:46:31 so it might rule out the use of UKI booting for aarch64 in future 2024-02-01 00:47:16 UKI == UEFI booting where the EFI file is a combined EFI stub, kernel, initramfs, cmdline entries, and firmware all in a single file 2024-02-01 01:04:59 minimal: re grub-install hook, after I merged my /etc/grub-autoupdate "fix" and started to look at the setup-disk script, I thought that we maybe should go for something you have suggested all along 2024-02-01 01:07:08 the script needs to autodetect what to do i.e. find out which underlying device /boot directory exists on 2024-02-01 01:07:11 but I wonder if we could look for /boot/{efi/,}alpine/grub*.efi and .../EFI/boot/boot*.efi 2024-02-01 01:07:39 yeah I wonder if we can sidestep that by looking for **/alpine/grub*.efi 2024-02-01 01:08:01 and for things like BIOS booting with software RAID then grub-install needs to be called *twice*, once per real disk, to write the MBR 2024-02-01 01:08:33 if found we run grub-install --no-nvram 2024-02-01 01:09:07 and if EFI/boot/boot*.efi found we run grub-install ... --removable 2024-02-01 01:09:32 would cover the efi case at least 2024-02-01 01:10:04 but if someone on UEFI has *ever* run grub-install without "--no-nvram" then a EFI boot variable will have been created which will take preference over the fallback file 2024-02-01 01:10:24 yeah, I think that's expected 2024-02-01 01:10:40 so would you be adding a new (potentially extra) booting variable or replacing an existing one? 2024-02-01 01:10:45 I mean, we dont need update the efi boot variable, right? 2024-02-01 01:11:24 as if they didn't specify "--bootloader-id=alpine" then that would create a boot variable (and EFI file) with a different name 2024-02-01 01:12:10 I've seen in alpine-linux people blindly running "grub-install" with no options to try and fix things 2024-02-01 01:12:20 which may result in extra boot vars 2024-02-01 01:12:25 im thinking it may be wise to not do anything in that case 2024-02-01 01:12:52 i.e only try auto fix what was created by setup-disk 2024-02-01 01:13:05 there may also be dual-boot 2024-02-01 01:13:16 and if someone has installed Alpine twice (e.g. different versions) on different disks then they would possibly be 1 or 2 differing boot vars... 2024-02-01 01:13:17 with windows, or other linux distros 2024-02-01 01:13:41 dual-boot means it is risky to touch bootx64.efi file at all 2024-02-01 01:13:55 yup 2024-02-01 01:14:14 as it might be a Windows file (and they're booting Alpine via a manually created boot var pointing to grubx64.efi) 2024-02-01 01:14:23 yup 2024-02-01 01:14:30 good point 2024-02-01 01:15:19 what if we compare it with alpine/grub*.efi? 2024-02-01 01:15:30 before running grub-install 2024-02-01 01:15:42 which is why unless you state "the ways that the installer sets stuff up are the only supported mechanisms and if you change ANYTHING relating to that and a later update/upgrade breaks your booting then tough luck and don't complain to us" 2024-02-01 01:15:53 it will always be complicated 2024-02-01 01:15:59 yeah exactly 2024-02-01 01:16:08 but I think that is what we should do basically 2024-02-01 01:16:19 you mean checksum both grubx64.efi and bootx64.efi files? 2024-02-01 01:16:26 limit the scope where we try to fix 2024-02-01 01:16:32 auto fix 2024-02-01 01:16:49 or simply run `cmp` 2024-02-01 01:17:15 I think we should somehow limit what we try to autofix 2024-02-01 01:17:36 that tells you if they're the same grub version, but then running grub-install will replace one of them (which one depends on the options) 2024-02-01 01:17:39 test if this was something we (eg setup-disk) did, and try to cover that 2024-02-01 01:18:05 and back out if unsure 2024-02-01 01:18:33 well deviations from setup-disk *will* happen - at the very least unless you remove the MD setup from setup-disk 2024-02-01 01:19:28 im thinking efi only right now. I haven't thought about bios boot yet 2024-02-01 01:19:30 nor tested it 2024-02-01 01:19:37 as if I want software RAID the 1st thing I'm going to (manually) do after setup-disk installed to disk is to manually add a 2nd disk to software RAID and need (if BIOS booting) to run grub-install to write to MBR of 2nd drive 2024-02-01 01:19:57 otherwise I wouldn't have uses software in the 1st place 2024-02-01 01:20:00 re bios. i dont think we need to update the MBR (the 404 bytes at the disk start) 2024-02-01 01:20:22 why not? without that nothing boots (from that drive) 2024-02-01 01:21:15 because it should be enough to do it once. I dont think there are ever any significant updates there 2024-02-01 01:21:21 MBR Grub booting *also* means it write to additional sectors after the 1st (MBR) sectors - that's why your 1st BIOS partition is at least 1MB from start of disk... 2024-02-01 01:21:59 is you din't run grub-install then *none* of those sectors (including but not limited ot MBR) are written to (updated) 2024-02-01 01:23:04 also for software RAID I don't remember if setup-disk sets that up for ESP partition or not 2024-02-01 01:23:11 right, im thinking of the 404 first bytes that only look for which partition to boot from 2024-02-01 01:23:42 I haven't read up on how grub bios boot work 2024-02-01 01:23:52 if it doesn't then manually adding a 2nd disk would require manually intervention to setup ESP part/fs on 2nd disk and copy stuff across 2024-02-01 01:24:56 BIOS = (from memory) stage 1 is 1st (MBR) sector, stage 2 is 2 and subsequent sectors, then config and extra modules are loaded from /boot fs 2024-02-01 01:25:07 s/2 and/2nd and/ 2024-02-01 01:25:46 right, stage 1 should not need be updated. it just finds the partition to boot from 2024-02-01 01:25:58 the stage 2 sectors are what are replaced by the boot partition (with no filesystem) on GPT disk 2024-02-01 01:26:21 well grub-install (from memory) doesn't let you specify to just write stage 2 2024-02-01 01:26:26 right 2024-02-01 01:27:17 we could maybe look for that stage 2 sector 2024-02-01 01:27:36 to do what? 2024-02-01 01:27:39 not sure how grub deals with that with madam raid 2024-02-01 01:28:03 my software raid mention was NOT Grub-specific 2024-02-01 01:28:41 to look if the trigger should try run grub-install at all or just back out 2024-02-01 01:28:44 rather to point out a typical scenario where someone is highly likely to change things after initial install (to mirror to another disk) 2024-02-01 01:29:57 but to look at/compare with what exactly? I believe grub-install (by calling grub-mkimage) *creates* what is written as stage when you run it so there's nothing to compare against in advance 2024-02-01 01:30:08 s/as stage/as stage 2/ 2024-02-01 01:30:18 im thinking we should verify if the current grub install was done by alpine at all, and if we are sure it was, we try autoupdate 2024-02-01 01:30:31 if we cannot be sure, then better back out 2024-02-01 01:30:44 as it has to assemble the stage 2 to include the Grub modules *necessary* to access the /boot filesystem in order to read config and load additional modules 2024-02-01 01:31:24 grub could also be installed by other distro, and alpine is dual booted 2024-02-01 01:31:33 so if you're using LVM and I'm using LUKS then our stage 2 contents will differ 2024-02-01 01:31:43 in which case we probably should try fix things for the other distro 2024-02-01 01:32:13 shoudnt 2024-02-01 01:32:32 we should not try fix grub installed by other distro 2024-02-01 01:32:48 the efi case is relatively safe I think 2024-02-01 01:33:16 you're referring to EFI I assume as for BIOS there is only ONE Grub installed (in MBR and further sectors) 2024-02-01 01:34:07 in which case those other distros will have their own EFI file inside their own ESP EFi/ subdirectory.....unless they're using fallback 2024-02-01 01:34:21 if alpine/grub*.efi exists we are relatively sure that it was installed by alpine, and user would appreciate what ever issue it causes is managed by alpine 2024-02-01 01:34:41 right 2024-02-01 01:35:10 you're expect Debian to be in EFI/debian/ and Ubuntu to be in EFI/ubuntu/ etc 2024-02-01 01:35:39 the only potential confusion is with EFI/boot/bootx64.efi 2024-02-01 01:36:21 if efi/boot/boot*.efi exists and is identical with alpine/grub*.efi (pre any grub-install), then we can safely also update that 2024-02-01 01:36:31 BTW side note re the aarch64 binutils thing I mentioned earlier: "Newer binutils use a 64K alignment for aarch64 by default" 2024-02-01 01:36:34 otherwise we better leave it unmodified 2024-02-01 01:37:19 for BIOS grub, we dont know if it was installed by other distro, right? 2024-02-01 01:37:43 as you said, there can only be one single BIOS grub 2024-02-01 01:37:51 "Use 4K to save space in the .elf file. UEFI uses 4K for aarch64 anyway"" 2024-02-01 01:38:56 im thinking the case where user installs Debian or ubuntu, uses grub for bios, and installs alpine as second OS, and uses the ubuntu installed grub boot alpine 2024-02-01 01:39:11 in that case, alpine should not try tup update grub, right? 2024-02-01 01:39:20 but let ubuntu handle it 2024-02-01 01:39:21 yeah there's no easy way to determine anything about the MBR and subsequent sectors' contents 2024-02-01 01:39:43 so, in that case we cannot really be sure, and better leave it alone 2024-02-01 01:39:54 in that scenario I'd assume the user should uninstall grub/grub-bios.....but they likely won't 2024-02-01 01:40:09 "apk del grub-bios" 2024-02-01 01:40:47 well, they could install grub-bios to create bootable USB sticks or disk images on loop back devices or whatever 2024-02-01 01:40:54 which is all fine 2024-02-01 01:41:46 and what about people who used setup-disk to install ZFS and then start "mucking around" with snapshots, encryption, etc? 2024-02-01 01:41:58 i dunno 2024-02-01 01:42:11 and the same I guess for BTRFS regarding snapshots 2024-02-01 01:42:21 i dont think we should try auto fix those scenarios 2024-02-01 01:42:22 I've not looking into how those interact with Grub 2024-02-01 01:42:29 neither have I 2024-02-01 01:43:11 im thinking, first check for and run /etc/grub-autoinstall 2024-02-01 01:43:31 those corner cases can be handled there 2024-02-01 01:43:46 BTW the new BLF module that came with Grub 2.12 (that caused these visible problems) is designed to provide a means for a bootloader to sign to the OS which bootloader it is (and version) ;-) 2024-02-01 01:44:16 BLF came from Systemd as a means to make "intelligent" decisions based on knowing about the bootloader 2024-02-01 01:44:34 s/sign/signal/ 2024-02-01 01:45:16 if /etc/grub-autoinstall does not exist, then look for alpine/grub*.efi (and boot*.efi), and run grub-install if sure it was managed by alpine 2024-02-01 01:45:24 otherwise just back out 2024-02-01 01:46:59 if we somehow can detect that the grub bios was installed by alpine, then we could try out fix that as well, but I dont think there are any safe way to detect that 2024-02-01 01:47:14 so probably better to leave it alone 2024-02-01 01:47:36 (and document it) 2024-02-01 01:48:10 i also dont know what to do with ppc64le, which has its own grub thingy 2024-02-01 01:48:23 maybe leave that for /etc/grub-autoinstall too 2024-02-01 01:48:49 thats my current thinking at least 2024-02-01 01:49:36 I should create an issue with the details 2024-02-01 01:50:38 for powerpc grub-install is run twice, once for each "PREP" from memory 2024-02-01 01:51:42 to summarize: I think we should try auto fix grub for at least some users, where we can be sure grub was installed by and is expected to be managed by alpine. so far this only applies to grub efi. 2024-02-01 01:52:18 for EFI, *I* think that in some RAID scenarios (e.g. with encryption) that ESP part/fs and boot part/file are NOT the same partition and so whilst /boot would be mirrored that EFI would not be and so EFI files in both physical disks would need to synced outside of software RAID 2024-02-01 01:52:39 with that we can avoid unbootable systems for at least some users, hopefully the majority 2024-02-01 01:52:40 s/that EFI/that ESP/ 2024-02-01 01:53:27 i suppose we can rely on /etc/grub-autoinstall for that case? 2024-02-01 01:54:07 potentially 2024-02-01 01:54:15 what im saying is that I dont think we should try automatically fix grub for everybody everywhere. only where we can do so safely 2024-02-01 02:01:24 it would be impossible to fix for everyone as there's almost an unlimited set of scenarios 2024-02-01 02:02:24 basically people need to understand that one they deviate from the "norms" they're on their own 2024-02-01 03:46:20 cely: I pulled in your latest commit and added a commit of my own to standardize the output of the "source" 2024-02-01 04:02:52 timlegge: That's great :) 2024-02-01 04:07:10 However, this adds empty lines even when there are no patches 2024-02-01 04:07:16 Not sure if this is a good idea 2024-02-01 04:07:42 Thought I checked that 2024-02-01 04:08:53 Perhaps this can be solved by adding an early return if $orig_src is undefined, that will also solve the uninitialized value warning 2024-02-01 04:10:27 You mean on create? Or on witn no patches it still makes source three lines? 2024-02-01 04:11:33 Yes, on create, it makes source with 3 lines 2024-02-01 04:12:12 I did have an early return but refinished it to keep the format the same. I am good either way I can change the tomorrow 2024-02-01 04:12:42 s/refinished/changed/ 2024-02-01 04:12:57 I don't think we should be making the source 3 lines long if there are no patches 2024-02-01 04:14:10 I think the one-thing-per-line formatting is for things that are expected to change, like dependencies and patches 2024-02-01 04:14:19 I do prefer the ones line but some of the current APKBUILD use multiple 2024-02-01 04:14:45 which is why the source URL usually starts does not start with a newline, as in it's `source="https://...` 2024-02-01 04:14:49 instead of `source=" 2024-02-01 04:14:52 https:///... 2024-02-01 04:14:53 ` 2024-02-01 04:15:05 because the source URL is not expected to change 2024-02-01 04:15:30 Of course on CPAN things are a little different, and the URL can change if a different author uploads the release 2024-02-01 04:16:04 Sounds good I will sort it tomorrow 2024-02-01 04:16:12 Great :) 2024-02-01 04:16:45 and after that will you be looking into the pragmas and the "uninitialized value $command" warning that is shown when the script is ran with no arguments? 2024-02-01 04:17:35 Those 2 should be just quick fixes 2024-02-01 04:18:49 Though while looking through the code yesterday, i found something else that probably needs to be deleted: the $cpanid variable in write_apkbuild 2024-02-01 04:19:09 It's not used anywhere, and i think the value is wrong anyway 2024-02-01 04:19:45 Yes, added a print statement, and the value is wrong 2024-02-01 04:20:24 because the id field in the JSON returned by MetaCPAN is some other id (i can't tell what on a first glance), not the author id 2024-02-01 04:24:50 The author id is in the `author` field, but we don't really need that, as there's already a `download_url` field that gives us the complete source URL 2024-02-01 11:40:31 I fixed the multi-line issue and push the commit I will try to look at the other ones tonight 2024-02-01 11:58:06 Alright, thanks :) 2024-02-01 12:28:52 Can I interest anyone in this MR? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/59850 (Beware, though: It will take a few hours to build.) 2024-02-01 12:31:24 There is nothing urgent atm, so I don't think that's an issue 2024-02-01 15:05:19 am i expected to type "lgtm" for package updates Celeste sends where i'm maintainer? 2024-02-01 15:08:14 kaey: You can approve them now 2024-02-01 15:10:12 kaey: make it easier to see that the package has been looked at and should be merged 2024-02-01 15:10:20 ye, but am i expected to do that or it doesn't matter? 2024-02-01 15:11:14 approving has preference since that's the most clear from the issue list 2024-02-01 15:11:23 but you need to be at least a guest in the aports project to do that, which I just did 2024-02-01 15:11:38 oke 2024-02-01 16:50:25 has anybody looked into packaging nvk yet? 2024-02-01 16:51:25 never heard of it 2024-02-01 16:51:36 mesa nvidia vulkan driver 2024-02-01 16:52:02 its slowly leaving the "here be dragons" state 2024-02-01 16:52:50 with mesa 24.0.0 released yesterday it might be a good time to start packaging it 2024-02-01 17:05:56 we're waiting for 24.0.1 before updating it right? 2024-02-01 17:41:31 wild. that's only turing cards, though, iirc 2024-02-01 18:01:35 turing and ampere iirc 2024-02-01 18:01:57 targetting turing indeed, ampere in the works 2024-02-01 19:00:09 Upgrading gitlab, it will be briefly unavailable 2024-02-01 19:04:33 Back again 2024-02-01 19:05:42 that was brief 2024-02-01 19:28:30 no migration, just stop and start containers 2024-02-01 19:28:57 not that I know what happens on gitlab nowadays =) 2024-02-01 19:29:13 there are migrations, but they run automatically 2024-02-01 19:29:22 so yes, just docker compose up -d 2024-02-01 20:58:16 Hi! I would be interested in plain dm-crypt encrypted root partition. It seems, that currently mkinitfs init script don't support plain dm-crypt. What would be best method of implementing plain support - change initramfs-init or work on nlplug-findfs? 2024-02-01 21:05:17 what do you mean by "plain dm-crypt"? isn't that just cryptsetup stuff? if so, that should be already supported with params cryptroot=... cryptdm=device-name root=/dev/mapper/device-name 2024-02-01 21:12:55 Yes, cryptsetup, but there is LUKS mode and plain mode. In LUKS - special header with encryption information is written to beginning of partition or somewhere else. In plain mode, user is providing encryption params, including cipher, key size, passphrase, offsets etc. From what I've found, there is no method of passing all those params through kernel command line. Of course, I 2024-02-01 21:12:57 might be missing something. 2024-02-01 21:24:22 The kernel itself wouldn't do anything. It would be initramfs's job to set up the dm node using `dmsetup table`, ie manually do what `cryptsetup` does 2024-02-02 00:20:10 cely: all done - there are a couple of commits that do not start with apkbuild-cpan.in: I wonder if I should reword them... 2024-02-02 00:38:12 ikke: re: generating apkindex from a dir in the go package... sadly the io.fs interface is read-only currently and I can't find any packages that implement that interface and support writing, so to be able to generate the apkindex you'd have to use 2 separate packages. I'll keep an eye on the upstream ticket to add write functionality and revisit it then 2024-02-02 01:46:17 timlegge: Thanks. i don't think it's necessary to reword those commits, but it's up to you 2024-02-02 01:47:54 I already gave up on the idea :-) I think it is in pretty good shape now - its the biggest improvement on it in a number of years thanks for the great work and prodding me to look at it again 2024-02-02 01:48:12 No problem 2024-02-02 01:48:52 By the way, is there any reason you just commented the 2 unnecessary pragmas instead of removing them? 2024-02-02 02:06:53 my bad, did that to test. Let me fix that 2024-02-02 02:08:53 celie: fixed 2024-02-02 02:11:04 Great, shall we start pinging developers about merging the MR? 2024-02-02 02:12:31 who has merge permissions on that repo 2024-02-02 02:15:00 Not really sure, but i think it's mostly ncopa who's been merging the MR's 2024-02-02 02:16:04 quite a few I guess but ncopa has merged my stuff in the past. I will mention him on the MR 2024-02-02 02:38:39 you have url and I'll have a look 2024-02-02 02:44:32 found it. thanks! 2024-02-02 02:44:48 Thank you 2024-02-02 02:45:19 ncopa: I think https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/235 is also ready for merging 2024-02-02 03:33:25 thanks ncopa 2024-02-02 03:43:36 Speaking of running tests for apkbuild-cpan, are the dependencies (mainly perl-libwww and perl-json) available when tests are ran? 2024-02-02 04:40:10 ncopa: re: ^ I could not understand why this only appears to happen every 10-15 years 2024-02-02 04:40:29 refering to grub life cycle :), kinda intrigued 2024-02-02 04:41:29 which means current being the 3rd cycle, 20yrs+ 2024-02-02 06:24:35 iggy: what about the function taking a list of filenames + io.readers? 2024-02-02 06:25:45 Or even repository.Package 2024-02-02 14:32:00 cely: usually run-time dependencies need to be available when tests are run 2024-02-02 14:32:43 Yes, but i think the apkbuild-cpan ones are declared in the subpackage, not the main abuild package 2024-02-02 14:36:17 However, i'm testing a change that will allow apkbuild-cpan to depend only upon modules that are bundled together with Perl, so maybe it won't matter that much if this works :) 2024-02-02 14:54:51 > *** 53 packages linked against libSDL2-2.0.so.0 need to be rebuild! 2024-02-02 14:54:52 weeeee 2024-02-02 15:57:53 sdl2 on ppc64le failed, should it be reported and fixed or deactivate the package on the platform? 2024-02-02 16:02:59 in sdl2's case i would suspect a toolchain bug, maybe 2024-02-02 16:08:57 its not an endianness problem right? 2024-02-02 16:11:17 i should probably check the reference and output images 2024-02-02 16:12:43 i have to move the folder test output into $pkg right? 2024-02-02 16:12:49 pkgdir* 2024-02-02 16:31:47 ikke: the problem would be writing out the subsequent apkindex. I think there's probably a very small subset of use cases that would need to generate the ApkIndex struct and not need to write it out. I could still do the minimal "scan files, fill ApkIndex struct" I'm just not sure how useful it would be on it's own 2024-02-02 23:14:55 where do you even get ppc64le hardware to run alpine on? :P 2024-02-02 23:18:28 honda asimo robot ;) 2024-02-02 23:18:57 lol, that would be fun to see running alpine 2024-02-02 23:45:02 bl4ckb0ne: mick_ibm probably could take a look 2024-02-03 00:20:54 i would not mind, i had absolutely no time investigating it today 2024-02-03 00:21:57 You can ping mtarsel on gitlab 2024-02-03 01:27:40 ptrc: you should have credit for doing the work https://code.rocket9labs.com/tslocum/cview/releases/tag/v1.5.9 2024-02-03 01:28:15 once you write enough patches, you get used to not being credited :p 2024-02-03 01:28:30 ( i'm joking, but i genuinely don't mind ) 2024-02-03 09:44:14 I want to give you credit for your work anyway 2024-02-03 12:46:14 hey PureTryOut: any idea why weechat-matrix{,-pyc} packages are empty? 2024-02-03 12:50:32 I don't sorry, I don't maintain or use them 2024-02-03 13:29:28 oh my bad! bad ping 2024-02-03 13:29:34 craftyguy: ^ 2024-02-03 13:49:35 hi 2024-02-03 13:49:53 I',m trying to build a package but a weird thing happens 2024-02-03 13:50:42 whatever I do, when I run abuild checksum, I always get the old sha512sum value 2024-02-03 13:51:01 where is the old value is stored and how to delete that? 2024-02-03 13:51:11 any ideas? 2024-02-03 13:55:30 cristian_c: it's not the hash that is cached but the source 2024-02-03 13:55:39 which is stored is /var/cache/distfiles 2024-02-03 13:55:46 you can clean it with abuild cleancache 2024-02-03 13:55:51 (for the current package, that is) 2024-02-03 13:57:06 ah, ok 2024-02-03 13:59:35 you're right, thanks 2024-02-03 14:00:24 indeed, it didn't download the .tar.gz again. Just deleting the cache, it does that again 2024-02-03 14:18:12 staceee uhh... no idea.. I'll have to take a look later. would you file an issue about it? 2024-02-03 15:32:52 craftyguy: done! 2024-02-03 19:06:17 PureTryOut: have you had the chance to look into this? https://github.com/illiliti/libudev-zero/issues/26#issuecomment-1848802791 2024-02-03 19:06:40 i've had someone report a pipewire issue to me, and this sounds vaguely related 2024-02-03 19:33:21 uh no I don't think I've heard of it 2024-02-03 20:33:33 Flutter apps on pinephone are empty. We can just see the header. Known issue? 2024-02-03 20:35:19 Haven't heard any issues 2024-02-03 20:35:23 lnl: ^? 2024-02-03 20:41:27 tested fluffychat and intiface 2024-02-03 20:41:31 https://dav.missbanal.net/259800b7-43e5-4bd0-92f4-5a90183c459a.png 2024-02-03 20:43:19 staceee: known upstream issue on lima and etnaviv, LIBGL_ALWAYS_SOFTWARE=1 needed, sorry 2024-02-03 20:45:18 lnl: a ticket I can track? 2024-02-03 20:47:17 not sure, it's not like upstream gives a shit anyway 2024-02-03 20:48:26 okay :) 2024-02-03 20:48:28 thanks! 2024-02-03 22:25:18 could some other alpine dev look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/55954? IMO it's a bit sketchy to add a tool for your own service ( that isn't even that widely used ) 2024-02-03 23:26:35 also, hah, apparently requesting review on a change from multiple people is supported, but it's paywalled 2024-02-03 23:28:28 since a year they have testing/ip2location, authored by sales@ip2location.com, 6a14381238ab2a4699d8a63f7e178c9582e491da 2024-02-03 23:30:17 I think I'll stay passive in this 2024-02-03 23:35:33 oh, so it was in fact merged(?), lol 2024-02-03 23:35:41 ah, no 2024-02-03 23:35:43 that's something else 2024-02-03 23:36:12 that one is a C library, this is a CLI 2024-02-03 23:42:26 would someone mind merging !60182 so we can show it off at Fosdem tomorrow more easily? 2024-02-03 23:42:56 though, I'm not the maintainer of the Phosh package, so maybe it'd be rude 2024-02-03 23:49:36 may the demo goddess be with you 2024-02-04 08:28:01 How could I setup a multi-arch build environment like aports' cicd locally 2024-02-04 08:59:32 qaqland: I use chroot and qemu: https://wiki.alpinelinux.org/wiki/How_to_make_a_cross_architecture_chroot 2024-02-04 09:05:36 thx 2024-02-04 09:06:48 docker-abuild works if you don't mind containers 2024-02-04 12:36:14 i think the maintainer of swi-prolog has given !60023 the thumbs up 2024-02-04 12:46:10 Thanks 2024-02-05 11:46:02 it's probably not as intended, but i have a debian package of apk-tools: http://sid.ethz.ch/debian/apk-tools/ 2024-02-05 14:37:50 I would like to get to the bottom with what is going on rather than just disabling the tests !60262 2024-02-05 14:37:57 does anyone have any clues? 2024-02-05 15:40:32 thanks celie & ptrc 2024-02-05 15:42:35 glad it worked :) 2024-02-05 15:42:37 still not sure why it would fail only on the package builders of those three architectures, but not the others, though 2024-02-05 15:42:53 perhaps the builders are configured ever so slightly differently? 2024-02-05 15:43:01 You're welcome, thanks to you too for making the changes, and insisting that we should get to the bottom of this :) 2024-02-05 15:48:35 i have to move the build folder to pkgdir to have it as an artifact right? 2024-02-05 18:20:39 bl4ckb0ne: $CI_PROJECT_DIR/packages/ or $CI_PROJECT_DIR/log 2024-02-05 18:21:52 thanks, i always forget that 2024-02-05 18:21:58 is there an entry about it in thewiki? 2024-02-05 18:28:56 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/.gitlab-ci.yml?ref_type=heads#L34 2024-02-05 18:33:16 ncopa: ptrc edge is a bit broken now because of libc-dev / libc-utils removal https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60185#note_375211 2024-02-05 18:33:27 uhhh yes just noticed the email 2024-02-05 18:33:34 overlooked the -utils subpackage somehow 2024-02-05 18:34:51 do you have a fix or do we revert? 2024-02-05 18:35:09 make musl-utils provide libc-utils as well, just like with -dev 2024-02-05 18:35:12 pushed to edge 2024-02-05 18:37:01 z3ntu: thanks! 2024-02-05 18:37:33 thanks for fixing so quickly :) 2024-02-05 18:52:22 thanks to both of you 2024-02-05 19:21:34 ncopa: "bluez-firmware also figures in the deprecated category:" https://www.bluez.org/download/ 2024-02-05 19:31:57 git.a.o does not provide .bz2 and tar.gz files to download anymore ? 2024-02-05 19:40:26 Hi Folks, I've got system with a crusty Intel "Quark SoC X1000", which is a 486-ish 32-bit CPU. Alpine 3.17 seems OK, but Alpine 3.18 has a bunch of CMOV* and SSE instructions compiled in that are throwing this poor guy for a loop. 2024-02-05 19:41:12 I did a _quick_ grep through the git logs between the versions but didn't see anything obvious that would have caused this. Any ideas? 2024-02-05 19:41:57 dhansen: 8f820025bcf606a5adc1bcc970b5a67b33c236c6 2024-02-05 19:42:27 ahh, that'd do it :) 2024-02-05 19:42:43 https://gitlab.alpinelinux.org/alpine/tsc/-/issues/20 2024-02-05 19:43:35 dhansen: the problem is that many projects already required sse2, so in practice, some packages worked, and others didn't 2024-02-05 19:43:53 yeah, I completely understand 2024-02-05 19:45:16 I knew it was a matter of time. Guess I can ride on 3.17 until I replace the hardware 2024-02-05 19:48:02 Anyway, thanks a bunch for the quick answer! And thanks for the nice little distro that kept my clunky hardware working for quite a few years! 2024-02-05 19:48:30 you're welcome, and sad to hear it is no longer supported 2024-02-05 19:50:55 vkrishn: it was causing load issues due to scrapiong 2024-02-05 19:50:59 scraping* 2024-02-05 19:53:50 ok, understand, thanks 2024-02-05 23:01:26 ikke ncopa: I put some MRs to the aports-qa-bot some time ago to help with maintenance 2024-02-05 23:01:40 Mostly you wanted ways to signal that MRs are approved or have received feedback from maintainers 2024-02-05 23:02:24 I got a bit creative and sent some MRs related to that. But was release time and I guess they got overlooked 2024-02-05 23:02:27