| - pomel0 (QUIT: Remote host closed the connection) (~pomel0@user/pomel0) | 00:03 | |
| + pomel0 (~pomel0@user/pomel0) | 00:03 | |
| minute | <JPEW> I couldn't find a reason why PIPE_TEXTURE_TRANSFER_BLIT wasn't enabled for panfrost, so I made https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38433 . | 00:27 |
|---|---|---|
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 00:40 | |
| - Gooberpatrol66 (QUIT: Quit: Konversation terminated!) (~Gooberpat@user/gooberpatrol66) | 01:01 | |
| + Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 01:06 | |
| - Svp (QUIT: Quit: Gateway shutdown) (~svp@host-79-7-240-189.business.telecomitalia.it) | 01:46 | |
| + Svp (~svp@host-79-7-240-189.business.telecomitalia.it) | 01:48 | |
| - mjw (QUIT: Ping timeout: 246 seconds) (~mjw@gnu.wildebeest.org) | 01:48 | |
| - paperManu (QUIT: Ping timeout: 255 seconds) (~paperManu@107.159.15.124) | 03:47 | |
| - manis (QUIT: Quit: Gateway shutdown) (01a66df340@185.72.67.185) | 04:02 | |
| + manis (01a66df340@185.72.67.185) | 04:07 | |
| - paperManu_ (QUIT: Ping timeout: 256 seconds) (~paperManu@107.159.15.124) | 04:18 | |
| + cow321 (~deflated8@user/meow/deflated8837) | 04:27 | |
| - _justin_kelly71 (QUIT: Quit: The Lounge - https://thelounge.chat) (~justinkel@user/justin-kelly/x-6011154) | 05:04 | |
| + cow321_ (~deflated8@user/meow/deflated8837) | 06:04 | |
| - aelius (QUIT: Remote host closed the connection) (~aelius@user/aelius) | 06:05 | |
| + aelius (~aelius@user/aelius) | 06:05 | |
| - cow321 (QUIT: Ping timeout: 256 seconds) (~deflated8@user/meow/deflated8837) | 06:06 | |
| * cow321_ -> cow321 | 06:06 | |
| - AshCurry (QUIT: Remote host closed the connection) (~AshCurry@user/AshCurry) | 06:06 | |
| + AshCurry (~AshCurry@user/AshCurry) | 06:06 | |
| + chomwitt (~chomwitt@2a02:85f:9a5f:900:1ac0:4dff:fedb:a3f1) | 06:35 | |
| - aelius (QUIT: Ping timeout: 256 seconds) (~aelius@user/aelius) | 07:29 | |
| * f_ -> funderscore | 08:01 | |
| * funderscore -> f_ | 08:01 | |
| - chomwitt (QUIT: Quit: WeeChat 3.8) (~chomwitt@2a02:85f:9a5f:900:1ac0:4dff:fedb:a3f1) | 08:11 | |
| + colinsane (~colinunin@97-113-95-252.tukw.qwest.net) | 08:50 | |
| + gidzit (~gidzit@gidzit.org) | 08:55 | |
| - colinsane (QUIT: Quit: bye) (~colinunin@97-113-95-252.tukw.qwest.net) | 09:35 | |
| + colinsane (~colinunin@97-113-95-252.tukw.qwest.net) | 09:56 | |
| + Arra (~arra@85.255.235.27) | 09:58 | |
| minute | huh https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38401 | 10:17 |
| + mjw (~mjw@gnu.wildebeest.org) | 10:28 | |
| - amospall1 (QUIT: Remote host closed the connection) (~jordi@user/amospalla) | 11:06 | |
| + amospalla (~jordi@user/amospalla) | 11:06 | |
| - mjw (QUIT: Ping timeout: 264 seconds) (~mjw@gnu.wildebeest.org) | 11:15 | |
| - Arra (QUIT: Remote host closed the connection) (~arra@85.255.235.27) | 11:17 | |
| + Arra (~arra@85.255.235.27) | 11:17 | |
| - Arra (QUIT: Read error: Connection reset by peer) (~arra@85.255.235.27) | 11:22 | |
| + Arra (~arra@85.255.235.27) | 11:27 | |
| * Guest4048 -> mjw | 11:36 | |
| + paperManu (~paperManu@107.159.15.124) | 12:06 | |
| + paperManu_ (~paperManu@107.159.15.124) | 12:22 | |
| + gustav25 (~gustav@c-78-82-54-137.bbcust.telenor.se) | 13:02 | |
| - paperManu (QUIT: Ping timeout: 240 seconds) (~paperManu@107.159.15.124) | 13:39 | |
| + Serve0925 (~msahmed@90.242.67.123) | 13:53 | |
| - Arra (QUIT: Ping timeout: 264 seconds) (~arra@85.255.235.27) | 13:58 | |
| - paperManu_ (QUIT: Ping timeout: 256 seconds) (~paperManu@107.159.15.124) | 14:08 | |
| + anacleto (~Anacleto@2804:31d4:219:4001:61ea:9435:27ae:1946) | 14:19 | |
| - anacleto (PART: Leaving) (~Anacleto@2804:31d4:219:4001:61ea:9435:27ae:1946) | 14:21 | |
| cwebber | minute: "Draft! Panvk" | 14:27 |
| cwebber | my favorite robot-hemet-wearing band | 14:28 |
| cwebber | (just riffing off the PR title) | 14:28 |
| - Serve0925 (QUIT: Quit: Konversation terminated!) (~msahmed@90.242.67.123) | 14:37 | |
| minute | cwebber: haha | 14:40 |
| minute | draft punk | 14:40 |
| minute | josch: we're discussing EFI here again and i'm looking at https://source.mnt.re/reform/reform-system-image/-/merge_requests/141/diffs?commit_id=5a52e0b52945c63dc556fbbcd916fd3b72049118 | 14:41 |
| + paperManu (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 14:42 | |
| minute | josch: casey was also like, why do you need 3 partitions? and i'm like, well, fat32 and such. but they said uboot can do efi boot from ext4. and i'm no longer keen on edk2 (which they agreed with) | 14:42 |
| minute | josch: so maybe having /boot as ext4 as before and bolting EFI/ESD into there would be the most painless next step and still work with your tooling? | 14:43 |
| * onepict -> tisiphone | 14:44 | |
| minute | josch: also https://packages.debian.org/sid/systemd-boot | 14:47 |
| Zaba | for what it’s worth, there is nothing limiting edk2 to fat32 either, it’s just the only file system that’s *mandated* by the spec - there are lots of UEFI drivers for all kinds of file systems out there (and indeed most PCs support at least NTFS as well) | 14:52 |
| Zaba | a cursory search turns up https://efi.akeo.ie/ for example | 14:53 |
| - paperManu (QUIT: Read error: Connection reset by peer) (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 14:59 | |
| - bleb (QUIT: Ping timeout: 260 seconds) (~cm@user/bleb) | 14:59 | |
| + paperManu (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 15:01 | |
| + bleb (~cm@user/bleb) | 15:11 | |
| josch | minute: the commit you linked is not related to how many partitions we have -- it's the commit which switches from msdos partition table to guid partitioning | 15:45 |
| + wielaard (~mjw@gnu.wildebeest.org) | 15:46 | |
| josch | minute: if u-boot can load efi from ext4 then i'm not attached to 3 partitions either. Having two partitions would be much simpler and if that works for u-boot then i'd be happy with not bolting on a third fat32 partition | 15:46 |
| josch | minute: systemd-boot is exactly what i use to create the efi payload using systemd-ukify and kernel-install | 15:47 |
| minute | josch: perfect | 15:48 |
| + ericsfraga (~user@2a00:23cc:b475:7c01:9e1e:89bc:9e7f:dae0) | 15:48 | |
| josch | but you wanted efi boot for amd64 and not for arm64, right? | 15:48 |
| josch | that was the original motivation | 15:48 |
| josch | you say that u-boot is fine with ext4 but is whatever you use on amd64 also fine with ext4? | 15:49 |
| minute | josch: yeah but now it's suddenly more relevant for arm64 :D | 15:49 |
| minute | josch: ignore amd64 for now on that front | 15:49 |
| josch | what makes efi more relevant for arm64? | 15:49 |
| Zaba | if you ever end up making a custom edk2 build you can just incorporate an ext4 driver into it | 15:50 |
| minute | josch: we're setting up the whole tooling for quasar for efi | 15:50 |
| josch | different bootloader on quasar? | 15:50 |
| minute | josch: no, uboot so far | 15:51 |
| josch | what motivates efi then? | 15:51 |
| minute | josch: "being standards compliant" | 15:52 |
| minute | :D | 15:52 |
| minute | josch: and "uboot capsule updates" | 15:52 |
| josch | oh i had not heard about capsule updates before, cool | 15:53 |
| josch | i rebased MR 141 on main | 15:53 |
| minute | josch: casey is pushing the idea of using UKI files too | 15:53 |
| josch | this is the first step towards efi and needs testing | 15:53 |
| josch | i can do that tonight | 15:53 |
| minute | josch: but i guess you were working on that already? :D (i just didn't "get" them yet) | 15:54 |
| minute | josch: cool! | 15:54 |
| josch | my other MR uses /boot/EFI/Linux/*-$kver-$FLAVOUR.efi and sets | 15:54 |
| josch | layout=uki | 15:54 |
| josch | is that what casey means? | 15:54 |
| minute | Zaba: right, that shouldn't be too hard | 15:54 |
| minute | josch: i think casey will join here soon | 15:56 |
| josch | great :) | 15:56 |
| + Arra (~arra@85.255.235.27) | 15:57 | |
| + kcxt (~kcxt@postmarketOS/casey) | 15:58 | |
| kcxt | o/ | 15:58 |
| minute | josch: meet kcxt | 15:58 |
| kcxt | heyo, yeah i think putting UKI's on the ESP and having systemd-boot be able to select them is sensible | 15:58 |
| kcxt | although we don't have display support in u-boot..... yet | 15:59 |
| josch | this is the commit which might do what casey means: https://source.mnt.re/reform/reform-system-image/-/merge_requests/133/diffs?commit_id=a22857bda743e8e624f8a286fb210d7881a53447 | 15:59 |
| josch | kcxt: _o/ | 16:00 |
| josch | kcxt: so i have a local poc which uses systemd-ukify systemd-boot systemd-boot-efi -- is that what you would MNT system images to use? | 16:02 |
| kcxt | josch: yeah that sounds perfect | 16:06 |
| josch | good because i'm an efi noob and it works but i have no clue if that's how it "should" work :) | 16:06 |
| kcxt | josch: im going to push some tooling for kernel development and u-boot changes so you'll be able to build the kernel, pack it into a UKI (with some dev ramdisk) and then boot the UKI directly with fastboot | 16:07 |
| kcxt | josch: if the UKI's show up in systemd-boot then it's all good :) | 16:07 |
| josch | kcxt: i'll just pretend that i understood everything you just said -- there is a lot to learn from me. In any case it helps if you say that we are moving in the right direction with the system images. Epecially since adding it seems to not have downsides for existing systems/bootloaders that we have deployed because we can have the image include multipe boot options at the same time. | 16:11 |
| kcxt | josch: yep! I'm definitely in favour of moving more towards following standards, like being able to easily boot stock fedora (for example) from a USB drive, or have multiple OS's and change which one you boot via the eficonfig menu | 16:18 |
| + spew (~spew@user/spew) | 16:20 | |
| josch | kcxt: "the standard" being https://uapi-group.org/specifications/specs/boot_loader_specification/ I assume? | 16:21 |
| - spew (QUIT: Client Quit) (~spew@user/spew) | 16:25 | |
| - wielaard (QUIT: Ping timeout: 240 seconds) (~mjw@gnu.wildebeest.org) | 16:28 | |
| + spew (~spew@user/spew) | 16:30 | |
| kcxt | josch: the standard being EFI :D | 16:39 |
| jfred | Whatever the implementation ends up being, I'm very interested as a user in being able to easily boot from generic live USB images on the various Reforms. That would massively simplify the process of playing around with different distros on these things | 16:42 |
| - Arra (QUIT: Remote host closed the connection) (~arra@85.255.235.27) | 16:43 | |
| + Arra (~arra@85.255.235.27) | 16:44 | |
| josch | jfred: right but this is more of a question which bootloader you have flashed to your emmc | 16:47 |
| josch | right now you already can boot various life images *if* they come with a boot.scr or an extlinux.conf | 16:47 |
| josch | the debian live systems do the latter | 16:48 |
| josch | as do the debian installer images | 16:48 |
| josch | fedora could also provide that and then it would be bootable | 16:48 |
| josch | filling a textfile with information which lets u-boot find uImage, initrd and dtb is not rocket science | 16:49 |
| josch | jfred: the "playing around with other distros" is not so much blocked by the boot method (it's trivial to set up, see above) but by the fact that not everything is upstreamed yet and we still sadly need a patched kernel for most platforms | 16:51 |
| jfred | noted - does the installed u-boot automatically discover boot.scr or extlinux.conf on a connected USB drive? | 17:03 |
| jfred | ACTION really needs to find the time to take another look at some of the work that's been done on reform guix images | 17:04 |
| josch | jfred: yes, u-boot prefers usb to sd-card and emmc | 17:09 |
| josch | jfred: that's how i install debian from reform.debian.net | 17:10 |
| josch | the debian-installer is loaded from a usb thumb drive | 17:10 |
| josch | the official debian installer also works but you only get serial (unless you use the patched kernel from reform.debian.net) | 17:10 |
| - spew (QUIT: Quit: WeeChat 4.6.3) (~spew@user/spew) | 17:25 | |
| - pomel0 (QUIT: Ping timeout: 252 seconds) (~pomel0@user/pomel0) | 17:26 | |
| * robin_ -> robin | 17:26 | |
| + pomel0 (~pomel0@user/pomel0) | 17:26 | |
| - pomel0 (QUIT: Read error: Connection reset by peer) (~pomel0@user/pomel0) | 17:29 | |
| + pomel0 (~pomel0@user/pomel0) | 17:29 | |
| jfred | josch: You mentioned telling u-boot where to find the dtb in boot.scr/extlinux.conf. What does that look like for a generic image? | 17:30 |
| - pomel0 (QUIT: Read error: Connection reset by peer) (~pomel0@user/pomel0) | 17:32 | |
| + pomel0 (~pomel0@user/pomel0) | 17:32 | |
| josch | jfred: u-boot stores a setting called ${fdtfile} and then what you put into extlinux.conf is the *directory* where it should look for that platform specific file on your fs | 17:36 |
| josch | this is how we distribute the reform-system-any image which boots on all the platforms (unless you have ancient u-boot for imx8mq or imx8m+) | 17:36 |
| - pomel0 (QUIT: Ping timeout: 256 seconds) (~pomel0@user/pomel0) | 17:37 | |
| + pomel0 (~pomel0@user/pomel0) | 17:37 | |
| - ericsfraga (QUIT: Quit: ERC 5.6.1-git (IRC client for GNU Emacs 31.0.50)) (~user@2a00:23cc:b475:7c01:9e1e:89bc:9e7f:dae0) | 17:41 | |
| jfred | josch: Hm. So if e.g. Fedora were to build a generic image that would boot on the Reforms and other aarch64 devices, am I right to think that they would need to ship dtbs for all supported platforms on those images? (e.g. their image would need to include rockchip/rk3588-mnt-reform2.dtb, rockchip/rk3588-mnt-pocket-reform.dtb, and so on?) | 17:48 |
| josch | jfred: yes but i don't know how this requirement is any different with efi boot. The dtb is still baked into the uki image depending on the platform. | 17:50 |
| jfred | I wonder if that is required to be in the uki image... this doc seems to indicate that the firmware can pass the device tree to the kernel via the efi configuration table: https://www.kernel.org/doc/html/latest/admin-guide/efi-stub.html#the-dtb-option | 17:54 |
| jfred | I admit that I am far out of my depth though | 17:55 |
| josch | indeed but now we have kcxt who can probably answer this question :) | 17:58 |
| kcxt | jfred: josch: if no dtb is included in the UKI the the firmware provided one is used. | 18:00 |
| jfred | \o/ that's what I was hoping was the case | 18:01 |
| josch | aha! then i'm still doing something wrong | 18:01 |
| josch | (currently dtb is bundled with the rest) | 18:01 |
| - gidzit (QUIT: Ping timeout: 256 seconds) (~gidzit@gidzit.org) | 18:01 | |
| josch | but we also do not yet have a firmware that provides a dtb | 18:01 |
| josch | also a problem with doing that is, that our dtbs are kernel version specific | 18:02 |
| josch | how would you handle that? | 18:02 |
| josch | kcxt: ^ | 18:08 |
| + wielaard (~mjw@gnu.wildebeest.org) | 18:11 | |
| - Ar|stote|is (QUIT: Ping timeout: 264 seconds) (~linx@149.210.1.212) | 18:49 | |
| + Ar|stote|is (~linx@149.210.39.70) | 18:54 | |
| - paperManu (QUIT: Ping timeout: 256 seconds) (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 19:22 | |
| + paperManu (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 19:24 | |
| + chomwitt (~chomwitt@2a02:85f:9a5f:900:1ac0:4dff:fedb:a3f1) | 19:41 | |
| - pomel0 (QUIT: Remote host closed the connection) (~pomel0@user/pomel0) | 19:49 | |
| minute | josch: heh, i just found a comment by you https://github.com/ptitSeb/box64/issues/3089#issuecomment-3432029330 | 20:12 |
| minute | josch: did you push that fixed version to debian? :D | 20:12 |
| josch | minute: there has not yet been a new release with commit f65b57bfac1c507a979d7a478c6dd4b5043f3215 | 20:13 |
| minute | josch: i have 0.3.8+dfsg-1 and still having that issue... aahhh ok so i'll have to build from source | 20:14 |
| josch | minute: but if you like, i can patch the debian version with f65b57bfac1c507a979d7a478c6dd4b5043f3215 tonight | 20:14 |
| minute | josch: that would be awesome | 20:15 |
| minute | josch: because right now, steam always crashes after a few minutes | 20:15 |
| bremner | play faster! ;) | 20:16 |
| josch | minute: would you like to test a .deb from me now instead of waiting for the next Debian mirror push? | 20:16 |
| minute | josch: sure, then i don't have to do a full build | 20:17 |
| josch | Great! Now you just have to wait for A311D to finish compiling this. :D | 20:19 |
| josch | (I promise I switch to rk3588 soon XD) | 20:19 |
| minute | josch: ah, well then it almost makes more sense for me to build on rk3588 :D except if you want me to betatest your deb | 20:23 |
| josch | if you would not mind the wait, then i'd appreciate that, yes :) | 20:23 |
| josch | (but yes of course you would be faster on rk3588 :P) | 20:23 |
| josch | the patch has to be modified a bit to apply to the latest release, so i'd like to confirm that it does the right thing | 20:24 |
| josch | and i don't have steam installed, so testing is a bit more involved for me | 20:24 |
| josch | (but i'm already flashing sd-cards again :D) | 20:24 |
| + AnimaInvicta (~AnimaInvi@88-120-179-216.subs.proxad.net) | 20:25 | |
| minute | josch: ok, i will wait and test your deb! | 20:26 |
| josch | thank you :) | 20:26 |
| josch | oh no... i'll flash rk3588 and build there -- it's taking too long | 20:27 |
| josch | (i combine it with testing MR 141) | 20:28 |
| josch | in the meantime: unfortunately i had no luck with using the Quectel EM06 modem via USB-only | 20:30 |
| josch | dmesg says: https://mister-muffin.de/p/SWqS.txt | 20:30 |
| josch | my theory was that maybe there was not enough juice supplied via usb but the above log is with motherboard 3.0 and rk3588 which is even able to drive my dvd-drive without problems from a single usb port | 20:30 |
| Zaba | device trees are inherently kernel-version-specific because they may specify devices that need drivers that only exist in certain kernel versions (or their parameters may change names etc.). just like the device tree used by u-boot has to match what drivers that version of u-boot supports, etc. there’s of course always a chance it works somewhat across different versions but I don’t think | 20:31 |
| Zaba | anyone provides any compatibility guarantees | 20:31 |
| josch | Zaba: that is also what my experience in practice is but then i wonder how it should be possible for one device tree being provided by the bootloader and then i am suddendly supposed to boot "any" system image? | 20:33 |
| Zaba | well, I think predictable per-kernel fdtdir locations + device free file *name* being supplied by the firmware is probably the closest you can get to a “good” solution | 20:37 |
| Zaba | and this is just a gap in the integration work of the platform because most embedded Linux systems don’t have this issue. this isn’t like the PC platform where mostly microsoft and intel did the legwork to make this all work somewhat clumsily but consistently from the perspective of the OS through ACPI and so on | 20:39 |
| Zaba | in theory, having the device tree tightly coupled to the kernel gives you *more* flexibility, since it’s not some kind of intransparent blob that you have to work around. but in terms of deployment, yeah there are gaps | 20:40 |
| josch | Zaba: i'm a noob when it comes to this so please feel free not to spare on the details. I greatful for your explanations so that I can learn more. And then I learned about stubble which can create efi boot stubs which automatically select the dtb. See this Debian ITP and my naive mails in it: https://bugs.debian.org/1112063 | 20:56 |
| josch | minute: your box64.deb is now building on rk3588 :) | 20:56 |
| minute | josch: noice! | 20:57 |
| josch | good news: the image built with GUID partitions instead of MS boots just fine | 20:57 |
| minute | josch: nice! | 20:57 |
| josch | there are some bugs with the first boot scripts but i fix them next | 20:57 |
| minute | cool | 20:57 |
| josch | okay, that commit is not enough, it's missing includes | 21:04 |
| josch | but rk3588 already overtook a311d and i saw the error there now while a311d is still building :D | 21:04 |
| minute | woops | 21:05 |
| josch | minute: okay, sorry for the holdup. Please build box64 from git locally for yourself. | 21:08 |
| josch | minute: the commit which fixes the problem needs del_xcb_connection32 and other functions which are part of an earlier commit over half a thousand lines of diff | 21:09 |
| josch | that's too much to backport | 21:09 |
| minute | josch: ohh ok. will do, thanks for the update | 21:09 |
| josch | we take away from this that i could've told you sooner had i already switched to rk3588 XD | 21:10 |
| minute | right :D | 21:19 |
| - Arra (QUIT: Ping timeout: 246 seconds) (~arra@85.255.235.27) | 21:30 | |
| + Arra (~arra@148.252.141.197) | 21:36 | |
| minute | josch: i can say that the latest git from box64 no longer has this issue on the device at least. it downloaded fallout4 now | 21:39 |
| - Arra (QUIT: Read error: Connection reset by peer) (~arra@148.252.141.197) | 21:39 | |
| + Arra (~arra@148.252.141.197) | 21:39 | |
| josch | awesome :) | 21:41 |
| josch | the box64 developer is super determined | 21:42 |
| josch | interesting how steam didn't choose it | 21:42 |
| josch | i mean valve | 21:43 |
| - Arra (QUIT: Ping timeout: 256 seconds) (~arra@148.252.141.197) | 21:44 | |
| sigrid | never managed to get box* to work on alpine | 21:44 |
| + Arra (~arra@185.69.144.175) | 21:44 | |
| josch | isn't alpine using a different libc? | 21:45 |
| sigrid | yes | 21:45 |
| josch | sigrid: are you using fex instead? | 21:46 |
| sigrid | nope | 21:50 |
| sigrid | I never tried fex | 21:50 |
| sigrid | I just spent a lot of time bashing my head at the box* stuff and gave up :') | 21:50 |
| josch | if you have a github account maybe open an issue with box64 -- the developer is *extremely* responsive | 21:51 |
| sigrid | having steam work on aarch64 ootb wouldn't be so bad btw | 21:51 |
| jfred | josch: I'm discovering when reading up on this that there have been long-standing disagreements on the extent to which device trees should be expected to have a stable ABI (e.g. https://lwn.net/Articles/561462/) | 22:05 |
| - gustav25 (QUIT: Quit: Quit) (~gustav@c-78-82-54-137.bbcust.telenor.se) | 22:15 | |
| jfred | this doc on kernel.org was interesting, though I don't know how much of this is, ah, aspirational: https://www.kernel.org/doc/html/v6.15-rc4/devicetree/bindings/writing-bindings.html | 22:16 |
| Zaba | josch: stubble seems to be canonical's attempt to solve this issue as part of their efforts to make linux run normally on the snapdragon-equipped PC laptops, so yeah that seems quite relevant. no reason why it wouldn't work in theory I guess. | 22:16 |
| josch | okay, good -- the description of the package got me interested because we would like to have this auto-selection for the reform-system-any image | 22:18 |
| josch | jfred: even with the words of the "strongest advocate" russel king -- this is not where we are | 22:18 |
| josch | jfred: our device trees fluctuate because we are using patch stacks which are long way from being included in a stable kernel release | 22:18 |
| josch | and the collabora patch stack is renaming things | 22:19 |
| Zaba | (looks like it falls back to using the 'compatible' string from the firmware-provided device tree in absence of SMBIOS so it should work for 'normal' embedded linux systems too) | 22:19 |
| josch | (that nwn article is also 12 years old by now) | 22:20 |
| josch | *lwn | 22:20 |
| - Arra (QUIT: Ping timeout: 264 seconds) (~arra@185.69.144.175) | 22:30 | |
| + Arra (~arra@185.69.144.175) | 22:31 | |
| * mjw -> Guest8812 | 22:37 | |
| - Guest8812 (QUIT: Killed (copper.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 22:37 | |
| * wielaard -> mjw | 22:37 | |
| + Guest8812 (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 22:38 | |
| - paperManu (QUIT: Ping timeout: 256 seconds) (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 23:00 | |
| - Arra (QUIT: Remote host closed the connection) (~arra@185.69.144.175) | 23:05 | |
| + Arra (~arra@185.69.144.175) | 23:06 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20) | 23:17 | |
| + vkoskiv_ (~vkoskiv@109-204-186-7.cust.valoonet.fi) | 23:36 | |
| + paperManu (~paperManu@107.159.15.124) | 23:37 | |
| + wielaard (~mjw@gnu.wildebeest.org) | 23:38 | |
| - mjw (QUIT: Killed (tungsten.libera.chat (Nickname regained by services))) (~mjw@gnu.wildebeest.org) | 23:38 | |
| * wielaard -> mjw | 23:38 | |
| + bleb_ (~cm@user/bleb) | 23:40 | |
| + paperManu_ (~paperManu@107.159.15.124) | 23:40 | |
| - bleb (QUIT: Ping timeout: 256 seconds) (~cm@user/bleb) | 23:40 | |
| - manis (QUIT: Ping timeout: 256 seconds) (01a66df340@185.72.67.185) | 23:40 | |
| - schalken (QUIT: Ping timeout: 256 seconds) (~schalken@117-118-178-69.gci.net) | 23:40 | |
| * bleb_ -> bleb | 23:40 | |
| - Svp (QUIT: *.net *.split) (~svp@host-79-7-240-189.business.telecomitalia.it) | 23:41 | |
| - Gooberpatrol66 (QUIT: *.net *.split) (~Gooberpat@user/gooberpatrol66) | 23:41 | |
| - qbit (QUIT: *.net *.split) (~qbit@user/qbit) | 23:41 | |
| - vkoskiv (QUIT: *.net *.split) (~vkoskiv@109-204-186-7.cust.valoonet.fi) | 23:41 | |
| - rwa_ (QUIT: *.net *.split) (0a82deb4eb@2a03:6000:1812:100::41b) | 23:41 | |
| + schalken1 (~schalken@117-118-178-69.gci.net) | 23:44 | |
| + Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 23:44 | |
| + qbit (~qbit@user/qbit) | 23:44 | |
| + rwa_ (0a82deb4eb@2a03:6000:1812:100::41b) | 23:44 | |
| - Gooberpatrol66 (QUIT: Max SendQ exceeded) (~Gooberpat@user/gooberpatrol66) | 23:44 | |
| + Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 23:44 | |
| - Arra (QUIT: Ping timeout: 264 seconds) (~arra@185.69.144.175) | 23:57 | |
| + Svp (~svp@2002:4f07:f0bd:0:95e7:dc62:c203:a24) | 23:59 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!