#archlinux-ports | Logs for 2026-08-07

Back
[00:01:57] -!- marmis has quit [Quit: Bye!]
[00:03:25] -!- marmis has joined #archlinux-ports
[01:29:44] -!- hch129071 has joined #archlinux-ports
[01:32:07] -!- hch12907 has quit [Ping timeout: 264 seconds]
[01:32:07] hch129071 is now known as hch12907
[02:01:08] -!- idealseal has quit [Ping timeout: 252 seconds]
[02:01:18] -!- idealseal has joined #archlinux-ports
[03:31:00] -!- hcmb_ has joined #archlinux-ports
[03:31:00] hcmb is now known as Guest5627
[03:31:00] hcmb_ is now known as hcmb
[03:31:58] -!- Guest5627 has quit [Ping timeout: 256 seconds]
[03:37:53] -!- drathir_tor has quit [Remote host closed the connection]
[03:38:26] -!- drathir_tor has joined #archlinux-ports
[05:52:13] <SpieringsAE_sff> the more you know lol, I also used dd always
[06:17:30] <solskogen|M> gromit: Did you manage to install it? :)
[06:51:39] -!- h|ignition has quit [Quit: WeeChat 4.10.0]
[07:05:49] -!- h|ignition has joined #archlinux-ports
[09:02:19] -!- drathir_tor has quit [Ping timeout: 252 seconds]
[09:03:27] -!- drathir_tor has joined #archlinux-ports
[10:21:31] -!- rafael_bento has joined #archlinux-ports
[10:21:31] -!- rafael_bento has quit [Client Quit]
[10:21:57] -!- rafael_bento has joined #archlinux-ports
[10:24:08] <phantomas> gehidore: dd also have some feature to deal with HW error, synchronized IO, and you can select the blocksize to use a size than the device can handle efficiently. cp just use whatever which can impact transfert time, and won't work on some devices
[10:26:49] <phantomas> but yeah cat & cp works as well most of the time, and when they don't dd usually can do the job better because you have finer control
[10:27:40] <solskogen|M> if cp fails due to a hw error... there's something wrong with the hardware that dd can't fix.
[10:39:47] <phantomas> well it depends why it failed
[13:07:51] -!- nl6720 has quit []
[13:09:24] -!- nl6720 has joined #archlinux-ports
[13:09:32] -!- nl6720 has quit [Client Quit]
[13:15:44] -!- nl6720 has joined #archlinux-ports
[14:46:55] -!- bschnei has quit [Remote host closed the connection]
[14:49:35] -!- bschnei has joined #archlinux-ports
[15:32:39] -!- Charon77|PC has joined #archlinux-ports
[15:38:07] -!- Charon77|PC has quit [Quit: Charon77|PC]
[15:39:02] -!- Charon77|PC has joined #archlinux-ports
[15:40:59] <solskogen|M> Not really.
[15:41:44] -!- Charon77|PC has quit [Client Quit]
[15:44:16] -!- Charon77|PC has joined #archlinux-ports
[16:03:55] -!- Charon77|PC has quit [Ping timeout: 264 seconds]
[17:05:57] -!- h|ignition has quit [Ping timeout: 252 seconds]
[17:08:13] -!- h|ignition has joined #archlinux-ports
[18:32:04] <SpieringsAE_sff> clover|M: just had dtbsync auto run after an update, however it failed. Partially because I am running my own patched kernel I think but yeah
[18:32:41] <SpieringsAE_sff> I think it incorrectly determined the uname causing it to try to look for dtbs in my own modules folder
[18:33:15] <SpieringsAE_sff> though it also didn't look in the one of the kernel I was actually running? It looked at my old modules which were no longer relevant
[18:33:41] <SpieringsAE_sff> need to read the actual code that generates that
[18:33:56] <SpieringsAE_sff> when I manually ran it after deleting the old modules it did work though
[18:45:54] -!- SpieringsAE has joined #archlinux-ports
[18:46:42] -!- SpieringsAE has quit [Client Quit]
[18:50:43] <clover|M> oof yeah, it expects only one entry in /usr/lib/modules
[18:51:09] <clover|M> can you explain how you had multiple? its an edge case i need to think about
[18:54:23] <clover|M> with upstream linux package, there is always one entry and it is replaced every time linux updates. e.g.,... (full message at <https://matrix.archlinux.org/ircmedia/v1/media/download/AcCdW4WmQQREAj9UGTKGCwKyEh8rZfWU_gJyvmdHvWyRYvD6er5Y7FuRo7Ukrkzf11gDg6sOYtb57gyXN473ugdCegJayXSAAGFyY2hsaW51eC5vcmcvRnZLRlh4THhIbGRUQ2tybVZhcFhzdkRh>)
[18:55:22] <deathmist> now imagine if one also has linux-lts installed, or literally any two different kernels at the same time
[18:57:37] <clover|M> ahh, i see
[18:59:47] <SpieringsAE_sff> that too
[19:00:03] <SpieringsAE_sff> I just manually have sftp'ed modules over from my build machine
[19:00:12] <clover|M> well, i'll need to only use the entry that doesn't have the suffix. since that would be upstream linux which packages linux-dtbs
[19:00:22] <clover|M> or bschnei's linux that is
[19:00:51] <SpieringsAE_sff> I have a /boot/test/ folder where I do some testing of patches from the mailing lists
[19:01:05] <SpieringsAE_sff> but the modules just also go into /lib/modules
[19:01:46] <SpieringsAE_sff> this is my /lib/modules/ right now: 7.1.6-arch1-1 7.2.0-rc5-next-20260731-00069-g165a20c35e59
[19:01:46] <clover|M> i guess im a pleb that only uses one linux kernel at a time XD
[19:02:13] <SpieringsAE_sff> regular arch kernel, and sketchy bleeding edge kernel with extra patches applied
[19:02:26] <SpieringsAE_sff> I need extra patches to get 4k60 on my tv lol
[19:02:27] <SpieringsAE_sff> so yeah
[19:02:59] <SpieringsAE_sff> waiting for this series to finally get merged https://lore.kernel.org
[19:03:00] <phrik> Title: [PATCH v10 00/69] Add HDMI 2.0 support to DW HDMI QP TX - Cristian Ciocaltea (at lore.kernel.org)
[19:05:53] <clover|M> * SpieringsAE_sffAnd does your 7.2.0-rc5-next-20260731-00069-g165a20c35e59 package linux-dtbs?
[19:06:26] <clover|M> SpieringsAE_sffDoe your next kernel package linux-dtbs?
[19:06:34] <SpieringsAE_sff> nope
[19:06:52] <SpieringsAE_sff> manually put it in /boot/test
[19:07:33] <clover|M> i'm not really sure the behavior you want out of dtbsync then. i made it to sync what is in linux-dtbs with /boot
[19:07:59] <SpieringsAE_sff> I think the difficulty is greating with what deathmist mentioned
[19:08:10] <SpieringsAE_sff> if you have regular and lts-dtbs
[19:08:15] <SpieringsAE_sff> greater*
[19:08:25] <SpieringsAE_sff> which do you put?
[19:08:59] <SpieringsAE_sff> do you get access to the package version in the pacman hook? I think you get something like that with the .deb install scripts
[19:10:33] <deathmist> not sure a one dtb solution is great, already had something similar and it bit me when I was testing patches as well and broke my previously booting kernel entry
[19:11:37] <deathmist> (well rather display output on it but still)
[19:12:06] <clover|M> i think if you are such an advanced user that you are using custom kernel packages, you can package your needed dtb yourself to wherever you want it
[19:12:15] <clover|M> and don't use dtbsync
[19:12:43] <SpieringsAE_sff> but the regular and lts kernel is not a very advanced usecase I think
[19:13:17] <clover|M> arch ports doesn't support lts kernel though, so it's not an existing usecase at the moment
[19:13:42] <deathmist> linux-mainline does exist though
[19:13:52] <clover|M> it doesn't package linux-dtbs.
[19:14:18] <clover|M> (maybe it should, idk)
[19:14:37] <clover|M> that would be up to maintainer
[19:20:08] <deathmist> that definitely sounds off and could lead to confusion due to missing newly added features or drivers no longer binding due to renamed nodes or similar
[19:24:54] <deathmist> maybe the driver would be rare but I've also not checked if e.g. https://github.com would break USB if used with older kernel (I think it would)
[19:24:56] <phrik> Title: arm64: dts: qcom: hamoa/purwa: Flatten usb controller nodes · torvalds/linux@4793de5 · GitHub (at github.com)
[19:28:19] <clover|M> if it ever happens it should probably use a similar convention and package linux-dtbs-mainline, and we can add a command line option to dtbsync or something
[19:36:38] * clover|M uploaded an image: (16KiB) < https://matrix.archlinux.org >
[19:36:41] <clover|M> something like this
[19:50:24] -!- hcmb has quit [Remote host closed the connection]
[19:51:25] -!- hcmb has joined #archlinux-ports
[19:52:42] <bschnei> hm how is stubble meant to handle multiple kernels/dtbs? I don't have to personally deal with this issue because I use u-boot with CONFIG_OF_CONTROL which bakes the dtb into U-Boot itself which then hands off the needed info to the next bootloader. In my case that's systemd-boot which then seamlessly handles multiple kernels.
[20:14:42] <deathmist> I'm finalizing stubble integration for another distro but you just embed them from the expected version into the kernel executables similar to UKI
[20:14:50] <SpieringsAE_sff> bschnei: that is ideally how it should work, firmware just gives dtb to os and the devicetree should be backwards compatible, which is mostly true but yeah
[20:15:12] <deathmist> too bad Windows on Snapdragon hardware exists lol
[20:45:59] -!- drathir_tor has quit [Read error: Connection reset by peer]
[20:51:22] -!- drathir_tor has joined #archlinux-ports
[22:10:13] -!- titus_livius has joined #archlinux-ports
[23:11:43] -!- filmroellchen has joined #archlinux-ports
[23:15:03] -!- filmroellchen has quit [Client Quit]
[23:33:19] -!- marmis has quit [Quit: Bye!]
[23:34:48] -!- marmis has joined #archlinux-ports
[23:39:57] -!- marmis has quit [Quit: Bye!]
[23:42:13] -!- marmis has joined #archlinux-ports
[23:44:26] -!- marmis has quit [Client Quit]
[23:45:57] -!- marmis has joined #archlinux-ports