| minute | josch: yes, if there was output it would be much better @ usability | 00:18 |
|---|---|---|
| minute | artfwo: sweet! | 00:19 |
| josch | minute: packages are allowed to put configuration into /etc/dkms/framework.conf.d/*.conf in case you'd like to have verbose=1 shipped by reform-tools | 00:20 |
| minute | josch: nice | 00:45 |
| minute | btw i tested the qcacld package auto update post install script method locally on my laptop (just out of curiosity), and it works. but the script file needs to be executable. | 00:47 |
| minute | for testing i logged the output to a file, it repeats 3 times "Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 27555 (apt)..." and then starts installing | 00:48 |
| josch | good to know! | 00:49 |
| josch | i think for debian stable (on reform.d.n) i'll go the ezurio-qcacld-2.0-dkms route as that will allow installing the dkms modules for arbitrary kernels (stable, stable backports, ...) and not just the kernels for which mntre.com built the binaries | 00:52 |
| minute | josch: btw i'm sorry that somehow i didn't understand you were so disappointed with this solution (.ko in a .deb). i wish it had occured to me that this might have been solvable with the dkms binary mechanism back then, but i really have a hard time understanding the dkms documentation | 00:52 |
| minute | josch: yes, i think that's fine | 00:52 |
| minute | when i was looking for dkms on the web and found the Dell repo a few hours ago, i thought this must be some different DKMS project | 00:53 |
| minute | but it is actually a dell project | 00:53 |
| josch | yup | 00:53 |
| josch | i wish i were more of a dkms expert, then i could actually be more constructive rather than saying why things might not work XD | 00:53 |
| minute | i guess there are not super many packages using dkms (which is a good thing) | 00:54 |
| josch | that and that it's just a big bash project | 00:56 |
| josch | the dkms files are essentially bash scripts that get sourced | 00:56 |
| josch | and docs are lacking | 00:56 |
| josch | (as you also experienced) | 00:57 |
| josch | it took me reading the dkms source to figure out that i had to use BUILD_EXCLUSIVE_ARCH="^(aarch64|x86_64|riscv64)$" to limit qcacld to 64bit architectures | 00:57 |
| minute | oof | 00:58 |
| josch | nowhere does it say that this is a regex | 00:58 |
| josch | or what kind of architecture names those are (it's the uname -m output) | 00:58 |
| josch | anyways, hitting the pillow now -- good night! | 01:01 |
| minute | josch: n8n8! | 01:06 |
| - bluerise (QUIT: Ping timeout: 272 seconds) (~bluerise@pc19f8ee5.dip0.t-ipconnect.de) | 01:08 | |
| + bluerise (~bluerise@pc19f819b.dip0.t-ipconnect.de) | 01:09 | |
| noam | minute: if you have a second, can you confirm that https://www.digikey.com/en/products/detail/ezurio/NIT8MQ-SOM-4R16E/13146013 is the correct module for the Reform? And, what's an unbricking board? :) | 01:41 |
| minute | noam: it is correct, but for me it says > Due to temporary constrained supply, DigiKey is unable to accept backorders at this time. | 01:44 |
| noam | minute: that would be because I ordered the last one :P | 01:53 |
| noam | it's probably arriving tomorrow ;P | 01:53 |
| + Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 02:09 | |
| minute | noam: ha! | 02:23 |
| - Ar|stote|is (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~linx@149.210.0.13) | 02:25 | |
| + Ar|stote|is (~linx@149.210.0.13) | 02:26 | |
| - mjw (QUIT: Ping timeout: 252 seconds) (~mjw@gnu.wildebeest.org) | 03:25 | |
| - kop316 (QUIT: Remote host closed the connection) (m-6f6zq6@static.138.159.90.157.clients.your-server.de) | 04:02 | |
| + kop316 (m-6f6zq6@static.138.159.90.157.clients.your-server.de) | 04:03 | |
| - kop316 (QUIT: Remote host closed the connection) (m-6f6zq6@static.138.159.90.157.clients.your-server.de) | 04:04 | |
| + kop316 (m-6f6zq6@static.138.159.90.157.clients.your-server.de) | 04:05 | |
| + chomwitt (~chomwitt@2a02:587:7a21:2700:1ac0:4dff:fedb:a3f1) | 07:32 | |
| - artfwo (QUIT: Quit: Client closed) (~artfwo@2a02:8109:8511:1800:6623:20ce:3860:f0f5) | 08:08 | |
| - colinsane (QUIT: Quit: bye) (~colinunin@97-113-136-129.tukw.qwest.net) | 08:10 | |
| + colinsane (~colinunin@97-113-136-129.tukw.qwest.net) | 08:13 | |
| josch | minute: do you have an idea what could make the reform-setup-wizard look like this? https://salsa.debian.org/debian/reform-setup-wizard/-/jobs/5781482/artifacts/file/debian/output/debci/artifacts/screenshots/00test.png | 09:49 |
| - chomwitt (QUIT: Ping timeout: 255 seconds) (~chomwitt@2a02:587:7a21:2700:1ac0:4dff:fedb:a3f1) | 10:21 | |
| minute | josch: this looks like a default bright theme and default font | 10:22 |
| josch | minute: also, fixed ezurio-qcacld-2.0-dkms is now in unstable ezurio-qcacld-2.0-dkms -- you could echo verbose=1 > /etc/dkms/framework.conf.d/reform.conf and see how that looks like | 10:26 |
| josch | also, are these dots printed when the build takes longer? https://ci.debian.net/packages/e/ezurio-qcacld-2.0-dkms/testing/arm64/47056995/#L524 | 10:26 |
| josch | Building module(s)........................................................................... | 10:26 |
| minute | josch: thanks for taking care of it! i can test it today and record the time ^^ | 10:48 |
| josch | on the Debian CI systems, building it takes 3:40 minutes but those are *very* fast machines and even with as little as 3 minutes i'd like at least some progress indicator to know that the system doesn't hang but is still doing something | 10:50 |
| minute | josch: yeah... | 10:57 |
| - jacobk (QUIT: Ping timeout: 260 seconds) (~quassel@47-186-109-194.dlls.tx.frontiernet.net) | 10:59 | |
| - erle (QUIT: Ping timeout: 255 seconds) (~erle@user/erle) | 11:05 | |
| + mjw (~mjw@gnu.wildebeest.org) | 11:51 | |
| + erle (~erle@2a02:8109:da01:6400::1b36) | 12:38 | |
| - erle (QUIT: Changing host) (~erle@2a02:8109:da01:6400::1b36) | 12:38 | |
| + erle (~erle@user/erle) | 12:38 | |
| minute | josch: btw one of the worst things in terms of UX is update-initramfs | 12:56 |
| minute | always takes a very long time and doesn't output any progress, and outputs an error about zsts | 12:56 |
| josch | yes, i wish that one had quite a bit more verbosity as well | 12:58 |
| josch | and the zstd warning is super confusing | 12:58 |
| minute | yeah :/ | 12:58 |
| minute | also i have doubts that the performance is optimal | 12:58 |
| josch | you called it an error (which it is not) but most people i talked to (yes, this is so annoying that this is a conversation topic) also interpret it as an error | 12:59 |
| minute | yeah | 12:59 |
| minute | btw the postinst hook i made last night works, i reran the build_qcacld and reprepro steps of the last pipeline of reform-debian-packages and the auto-install on kernel upgrade works on device | 13:00 |
| josch | \o/ | 13:00 |
| minute | there are of course edge cases, i.e. if you went offline exactly after the upgrade, it wouldn't work | 13:01 |
| josch | i should've taked to ben last week about update-initramfs XD | 13:04 |
| josch | *talked | 13:04 |
| minute | ohh yeah :D | 13:05 |
| minute | need to benchmark what is so slow there... maybe the compression? | 13:07 |
| minute | we already installed around 140 more devices with the older version of system image and qcacld2 package... updating the packages would take a long time due to update-initramfs | 13:13 |
| minute | so we should probably put a note in the box that people should run apt update && apt upgrade after connecting to the network | 13:13 |
| minute | we could also put that in the next CS update post | 13:13 |
| josch | i have good news and bad news | 13:15 |
| josch | good news: it's not the compression that makes mkinitramfs slow | 13:15 |
| josch | bad news: it's tons and tons of lines of shell and modinfo calls | 13:16 |
| josch | minute: this is how verbose update-initramfs output would look like: https://termbin.com/qdw9 | 13:22 |
| - amk (QUIT: Ping timeout: 260 seconds) (~amk@user/amk) | 13:23 | |
| minute | josch: :D | 13:24 |
| minute | josch: that looks better than being quiet though | 13:24 |
| minute | josch: is it adding those files one-by-one or collecting them into a list and then adding them at-once? somehow it is really hard for me to imagine that making an archive/fs image that is only 10s of MB should take this long on a modern computer | 13:25 |
| minute | ah sorry, i should have looked at the timestamps m) | 13:30 |
| - mjw (QUIT: Ping timeout: 264 seconds) (~mjw@gnu.wildebeest.org) | 13:41 | |
| * Guest9054 -> mjw | 13:43 | |
| + amk (~amk@user/amk) | 13:49 | |
| + chomwitt (~chomwitt@2a02:587:7a21:2700:1ac0:4dff:fedb:a3f1) | 15:00 | |
| + mark_ (~mjw@gnu.wildebeest.org) | 16:24 | |
| + jacobk (~quassel@47-186-109-194.dlls.tx.frontiernet.net) | 17:22 | |
| josch | minute: in case the mkinitramfs situation interests you, i have dug a bit into it | 19:06 |
| josch | of the 40 seconds that it takes over here on a311d, only 5 seconds are spent on the actual zstd compression | 19:06 |
| josch | another 4 seconds are spent on running the hooks | 19:07 |
| josch | but all of the rest is just slow because a) shell and b) 824 calls to modinfo -k, 465 calls to cp and 174 calls to mkdir | 19:07 |
| josch | fixing this would likely be a rewrite | 19:08 |
| Twodisbetter | yo yo yo, what up folks? Have any of you heard of Bluefin OS? Had a chance to take it for a spin? I wonder if something like that could one day be considered on the Reform? I ask because imutable nature of the OS is great, in that things just don't break anything in updates either. I'm trying it on the Framework 13 now, but just wondering if anyone here has kicked the tires with it? | 19:25 |
| + gustav28 (~gustav@c-2834524e.019-141-67626730.bbcust.telenor.se) | 20:02 | |
| - ericsfraga (QUIT: Quit: ERC 5.6-git (IRC client for GNU Emacs 30.0.50)) (~user@2.28.216.161) | 20:04 | |
| + ericsfraga (~user@2.28.216.161) | 20:07 | |
| minute | josch: it totally interests me! | 20:08 |
| noam | imx module arriving shortly :D | 20:09 |
| minute | josch: sounds like an interesting candidate for rewriting in a faster language | 20:09 |
| minute | josch: also those modinfo calls sound expensive | 20:10 |
| josch | the modinfo calls are for figuring out which kernel module requires firmware | 20:10 |
| josch | there are likely some low-hanging fruits | 20:14 |
| josch | i'm putting it on my todo list | 20:14 |
| minute | josch: cool! | 20:15 |
| + reform3633 (~nasendack@p200300ddaf0ddf00a0e62a77a34e2177.dip0.t-ipconnect.de) | 20:33 | |
| erle | josch if you give me a link to the shell scripts in question, i can look at it. i have previously optimized shell scripts (for my redo implementation). | 20:34 |
| reform3633 | Hi, i delete the partitions of the emmc and now i try restore. the pocket has been booted by sd ... hope its okay to ask here | 20:35 |
| erle | also, shell scripts aren't necessarily slow, but invoking subshells is, definitely. every pipe and $([…]) or `[…]` might be a speed bump. | 20:39 |
| - reform3633 (QUIT: Quit: Leaving) (~nasendack@p200300ddaf0ddf00a0e62a77a34e2177.dip0.t-ipconnect.de) | 20:39 | |
| + reform1455 (~nasendack@p200300ddaf0ddf00a0e62a77a34e2177.dip0.t-ipconnect.de) | 20:39 | |
| - reform1455 (QUIT: Remote host closed the connection) (~nasendack@p200300ddaf0ddf00a0e62a77a34e2177.dip0.t-ipconnect.de) | 20:40 | |
| erle | to get a quick idea of subshell overhead, you can compare these two commands: | 20:41 |
| erle | /usr/bin/time -p sh -c 'for i in $(seq 999); do echo $(echo hello); done >/dev/null' | 20:41 |
| erle | /usr/bin/time -p sh -c 'for i in $(seq 999); do echo hello; done >/dev/null | 20:41 |
| erle | (second one should print 0.00 on most systems, first one can probably take up to a third of a second) | 20:43 |
| - hairu (QUIT: Remote host closed the connection) (m-uotkmd@user/hairu) | 21:14 | |
| + hairu (m-uotkmd@user/hairu) | 21:15 | |
| josch | erle: run "sudo update-initramfs -u" and see the slowness yourself | 22:01 |
| josch | you will see that the slowness comes from mkinitramfs | 22:02 |
| josch | and that in turn calls functions in /usr/share/initramfs-tools/hook-functions | 22:02 |
| - gustav28 (QUIT: Quit: Quit) (~gustav@c-2834524e.019-141-67626730.bbcust.telenor.se) | 22:15 | |
| erle | josch i'm on a non-reform system. the code there is similar i guess? | 22:31 |
| erle | (still debian) | 22:31 |
| erle | oh yeah, that looks gnarly | 22:33 |
| josch | erle: the reform repo mainly patches the linux kernel | 22:34 |
| josch | erle: there are no patches to initramfs-tools | 22:34 |
| * mjw -> Guest8519 | 22:52 | |
| - Guest8519 (QUIT: Killed (zinc.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 22:52 | |
| * mark_ -> mjw | 22:52 | |
| + Guest8519 (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 22:52 | |
| - GNUmoon2 (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 23:18 | |
| + GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) | 23:20 | |
| erle | josch i have identified a few places where the hook-functions can be made marginally faster already with the same functionailty (like preventing path lookups and using case instead of if because it is faster), but without stracing the thing i would not know if that has an actual impact – because it has a LOT of subshell invocations. | 23:27 |
| erle | i am not going to do that right now – but if you want to refactor those functions, i'd be glad to assist. it's certainly possible to make this faster, i just don't know how much. | 23:29 |
| - chomwitt (QUIT: Ping timeout: 260 seconds) (~chomwitt@2a02:587:7a21:2700:1ac0:4dff:fedb:a3f1) | 23:31 | |
| - mesaoptimizer (QUIT: Quit: mesaoptimizer) (~mesaoptim@user/PapuaHardyNet) | 23:40 | |
| + mesaoptimizer (~mesaoptim@user/PapuaHardyNet) | 23:40 | |
| erle | just to be explicit: shell scripts are not inherently slow due to the programming language. forkrun for example claims to be faster than parallel(1) and xargs(1): https://github.com/jkool702/forkrun | 23:54 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
