| kfx | wayland is forever in the future :/ | 00:35 |
|---|---|---|
| - S0rin (QUIT: Ping timeout: 255 seconds) (~S0rin@user/s0rin) | 00:56 | |
| + S0rin (~S0rin@user/s0rin) | 01:01 | |
| - erle (QUIT: Ping timeout: 252 seconds) (~erle@ip5f5af7e0.dynamic.kabel-deutschland.de) | 01:25 | |
| + erle (~erle@ip5f5af7e0.dynamic.kabel-deutschland.de) | 01:37 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:20) | 01:38 | |
| - qwer (QUIT: Ping timeout: 268 seconds) (~qwer@89.24.43.78) | 01:57 | |
| - mtm (QUIT: Ping timeout: 245 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 02:02 | |
| + qwer (~qwer@78-80-120-110.customers.tmcz.cz) | 02:02 | |
| + GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) | 03:21 | |
| - GNUmoon2 (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 03:34 | |
| + GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) | 03:34 | |
| + mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 04:08 | |
| - Ar|stote|is (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~linx@149-210-4-98.mobile.nym.cosmote.net) | 05:14 | |
| + Ar|stote|is (~linx@149-210-4-98.mobile.nym.cosmote.net) | 05:14 | |
| - Ar|stote|is (QUIT: Client Quit) (~linx@149-210-4-98.mobile.nym.cosmote.net) | 05:15 | |
| + Ar|stote|is (~linx@149-210-4-98.mobile.nym.cosmote.net) | 05:15 | |
| - Ar|stote|is (QUIT: Client Quit) (~linx@149-210-4-98.mobile.nym.cosmote.net) | 05:16 | |
| + Ar|stote|is (~linx@149-210-4-98.mobile.nym.cosmote.net) | 05:16 | |
| - ajr (QUIT: Quit: WeeChat 3.6) (~ajr@user/ajr) | 05:41 | |
| + bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 05:57 | |
| + reform3823 (~inhji@ip-178-203-147-114.um48.pools.vodafone-ip.de) | 06:17 | |
| - reform3823 (QUIT: Client Quit) (~inhji@ip-178-203-147-114.um48.pools.vodafone-ip.de) | 06:18 | |
| - bkeys (QUIT: Ping timeout: 245 seconds) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 06:47 | |
| - erle (QUIT: Ping timeout: 245 seconds) (~erle@ip5f5af7e0.dynamic.kabel-deutschland.de) | 07:33 | |
| + simba (~simba@2001:a61:1154:c001:f743:7589:8478:148f) | 07:35 | |
| - GNUmoon2 (QUIT: Read error: Connection reset by peer) (~GNUmoon@gateway/tor-sasl/gnumoon) | 07:37 | |
| + GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) | 07:39 | |
| + chomwitt (~chomwitt@2a02:587:dc00:5a00:c97f:27e8:7d82:f5a7) | 08:15 | |
| - chomwitt (QUIT: Ping timeout: 264 seconds) (~chomwitt@2a02:587:dc00:5a00:c97f:27e8:7d82:f5a7) | 08:34 | |
| - GNUmoon2 (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 08:38 | |
| + GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) | 08:40 | |
| - GNUmoon2 (QUIT: Write error: Broken pipe) (~GNUmoon@gateway/tor-sasl/gnumoon) | 09:22 | |
| + GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) | 09:22 | |
| - qwer (QUIT: Remote host closed the connection) (~qwer@78-80-120-110.customers.tmcz.cz) | 09:25 | |
| + qwer (~qwer@78-80-120-110.customers.tmcz.cz) | 09:27 | |
| + chomwitt (~chomwitt@2a02:587:dc00:5a00:46c5:b74b:2b21:d09f) | 09:42 | |
| + erle (~erle@ip5f5af7e0.dynamic.kabel-deutschland.de) | 09:45 | |
| - GNUmoon2 (QUIT: Ping timeout: 268 seconds) (~GNUmoon@gateway/tor-sasl/gnumoon) | 10:03 | |
| + MajorBiscuit (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 10:09 | |
| + GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) | 10:16 | |
| Boostisbetter | If the Reform has shown us what the benefits of Wayland are on somewhat limited systems, I'm not sure it will ever click to people. Wayland is just far more efficient. | 10:19 |
| - GNUmoon2 (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 10:20 | |
| + GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) | 10:20 | |
| Asmadeus | Except this isn't so much 'far more efficient' as 'nobody bothered to implement the glue for drivers on xorg' in this case :D | 10:23 |
| Boostisbetter | Meh, I think just understanding the architecture of the two systems is enough to say definitively that Wayland is more efficient. | 10:27 |
| Boostisbetter | but I am not against Xorg. I know many people that think it is never dying and that Wayland is dumb. From a purely technical standpoint I think Wayland is superior. | 10:35 |
| - eery (QUIT: Ping timeout: 255 seconds) (~eery@172.97.103.152) | 10:48 | |
| + eery (~eery@172.97.103.152) | 10:53 | |
| kfx | I don't really know much about them, or care which one I use... until I need color calibration, or I keep accidentally scrolling on crap because libinput broke the emulatewheel feature :/ | 10:59 |
| - MajorBiscuit (QUIT: Quit: WeeChat 3.5) (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 11:02 | |
| kfx | I'm sure they'll catch up eventually | 11:03 |
| - eery (QUIT: Ping timeout: 245 seconds) (~eery@172.97.103.152) | 11:05 | |
| + MajorBiscuit (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 11:08 | |
| + Christoph_ (~Christoph@p54bf62e9.dip0.t-ipconnect.de) | 11:16 | |
| Boostisbetter | for sure, the catching up is difficult for Wayland, because the chance in architecture puts the odis back in the hands of the application developers. Finding people to update the mountain of xorg software is a chore that may never seen completion. | 11:24 |
| Boostisbetter | for sure, the catching up is difficult for Wayland, because the change in architecture puts the odis back in the hands of the application developers. Finding people to update the mountain of xorg software is a chore that may never seen completion. | 11:25 |
| + eery (~eery@172.97.103.152) | 11:45 | |
| - mjw (QUIT: Killed (NickServ (GHOST command used by wielaard!~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440))) (~mark@gnu.wildebeest.org) | 12:12 | |
| * wielaard -> mjw | 12:12 | |
| + mark_ (~mark@gnu.wildebeest.org) | 12:12 | |
| erle | Boostisbetter the thing with wayland is though that it usually needs KMS. i am right now typing from a system that does not have KMS. i can not use wayland on debian. | 12:45 |
| erle | i appreciate architectural changes though | 12:45 |
| Boostisbetter | erle: why is KMS bad? Sorry I don't know what that is. | 12:46 |
| erle | kernel mode setting | 12:46 |
| erle | setting display resolution and other things in the kernel instead of userspace | 12:47 |
| erle | it is not bad | 12:47 |
| erle | it is good, but not as widely available in hardware that dose not have up-to-date 3d capabilities | 12:47 |
| erle | https://wiki.archlinux.org/title/Kernel_mode_setting | 12:47 |
| erle | the thing is, X can do it on hardware where the kernel can not do it | 12:47 |
| erle | the mode setting, i mean | 12:47 |
| erle | anyway – architecture-wise using wayland instead of X11 is about the same level of simplification than using redo instead of make. you are still doing the same thing (very broadly speaking), but the approach allows for a simpler system. | 12:48 |
| erle | Boostisbetter given that wiki page, i *should* be able to have KMS though. | 12:49 |
| erle | anyways, the argument is “the minimum requirements for wayland are higher than the ones for X11” | 12:49 |
| erle | this does not concern reform | 12:50 |
| erle | which obviously does have wayland | 12:50 |
| erle | and exceeds the minimum requirements by quite a bit | 12:50 |
| erle | Boostisbetter, was that an acceptable explanation? | 12:50 |
| erle | anyway, i assume Xorg will never truly die the same way that ANSI terminal escape codes are a forever-liability. lots of stuff will just need it and never be updated and a compatibility layer is feasible and already exists. | 12:53 |
| erle | so it will just be frozen mainly ig | 12:53 |
| - buckket (QUIT: Read error: Connection reset by peer) (~buckket@pdp8.buckket.org) | 13:13 | |
| + buckket (~buckket@pdp8.buckket.org) | 13:16 | |
| - qwer (QUIT: Ping timeout: 252 seconds) (~qwer@78-80-120-110.customers.tmcz.cz) | 13:24 | |
| - mark_ (QUIT: Ping timeout: 244 seconds) (~mark@gnu.wildebeest.org) | 13:34 | |
| minute | erle: which GPU do you have which does not have modesetting? | 13:51 |
| - mtm (QUIT: Ping timeout: 268 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 14:03 | |
| - erle (QUIT: Ping timeout: 252 seconds) (~erle@ip5f5af7e0.dynamic.kabel-deutschland.de) | 14:05 | |
| - qbit (QUIT: Quit: WeeChat 3.6) (~qbit@h.suah.dev) | 14:18 | |
| + erle (~erle@ip5f5af7e0.dynamic.kabel-deutschland.de) | 14:43 | |
| - erle (QUIT: Remote host closed the connection) (~erle@ip5f5af7e0.dynamic.kabel-deutschland.de) | 14:43 | |
| + erle (~erle@ip5f5af7e0.dynamic.kabel-deutschland.de) | 14:44 | |
| erle | minute i have several thinkpad T60s that use an intel GMA495. but i have seen a youtube video of people running wayland on it. maybe it is just debian being stupid about it? | 14:45 |
| erle | minute this is the kind of GPU that trips up graphics programmers because it supports openGL 1.4 but also shaders and openGL ES 2.0, probably the oldest or second-oldest on which any modern 3D application should run (but usually doesn't). same boat as mali 400 GPU, it conforms to specs, but programmers exceed the guaranteed spec minimums because their own GPU supports more shader instructions etc. | 14:47 |
| erle | which also leads me to a reform-specific question: do you have any idea about the GLSL shader instruction limit on the GPU and how to find out how many instructions a shader uses? | 14:47 |
| + bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 14:48 | |
| erle | minute the problem i am trying to solve here is “minetest uses more instructions per shader than the minimum of OpenGL ES 2.0 allows and the devs seem to mostly test on their own hardware, which are supercomputers relative to a typical laptop” | 14:49 |
| erle | by the way: if you compile minetest with openGL ES, you can probably gain 10 to 15 fps on reform 2 | 14:50 |
| minute | erle: "GMA495" gets me only 4 google hits, typo? | 14:50 |
| erle | the desktop GL fixed pipeline thing seems to be just slow. maybe it is CPU-bound, i don't know much about 3D stuff anyway. | 14:50 |
| erle | minute 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller]) | 14:51 |
| erle | probably a typo yes, the A | 14:51 |
| erle | or maybe it stands for “graphics media accelerator” | 14:52 |
| minute | 945, not 495 | 14:52 |
| erle | oh lol | 14:52 |
| erle | mea maxima culpa | 14:53 |
| erle | anyways, this is not a channel for old thinkpads ;) but if you have one, you can easily see the difference that more modern graphics cards make – the performance characteristics for desktop OpenGL vs OpenGL ES are reversed between old thinkpad and reform 2 | 14:54 |
| minute | erle: you should totally have a drm/kms driver | 14:56 |
| erle | josch minute do you think that it would make more sense for debian to ship minetest-ogl and minetest-ogles packages or to ask the maintainers to switch to building using openGL ES aarch64 to get more fps on reform2? | 14:56 |
| erle | minute how did you determine that? also then i guess it's debians or my fault. | 14:56 |
| minute | erle: you can also run sway/wlroots using a PIXMAN rendering option to avoid the gpu | 14:56 |
| erle | thanks, i did not know! | 14:57 |
| erle | and given that the older a machine becomes the more likely it is that mesa software rendering outperforms the GPU, i'm very grateful for it | 14:57 |
| erle | for shaders in particular, hilariously, a shader that exceeds the instruction limit of a GPU may perform *better* with software rendering than hardware-accelerated at all | 14:58 |
| minute | erle: do you have a card in /dev/dri? then you should have modesetting | 15:01 |
| erle | ; ls /dev/dri/ | 15:01 |
| erle | by-path card0 renderD128 | 15:01 |
| erle | indeed | 15:01 |
| erle | i can remember it not working though the last time i tried. should have not asserted stuff without trying it again i guess (after all i do update my system). | 15:03 |
| minute | erle: the env var for sway is WLR_RENDERER=pixman | 15:03 |
| erle | thank you very much minute, i'll try to have wayland on all on my machines eventually that way | 15:03 |
| minute | erle: to test kms you can run kmscube btw | 15:03 |
| minute | in the console | 15:04 |
| - erle (QUIT: Remote host closed the connection) (~erle@ip5f5af7e0.dynamic.kabel-deutschland.de) | 15:06 | |
| + erLe17 (~erLe17@2a02:8109:aa40:3ecc::f67a) | 15:11 | |
| erLe17 | ow | 15:11 |
| erLe17 | minute how to exit kmscube? it works but locks up my machine | 15:13 |
| erLe17 | i think then KMS did not work at install time | 15:13 |
| erLe17 | but it works now | 15:13 |
| josch | erLe17: we've had a 109 messages mega-thread on debian-devel about building software with opengles on arm64 and opengl everywhere else -- this is a touchy topic but it's a bit easier for minetest because it's not a library that anything depends on. In the end, it's up to the minetest maintainer whether they are willing to maintain the additional complexity in their package. I guess a patch would help | 15:13 |
| josch | them with that choice. :) | 15:13 |
| erLe17 | josch minetest coredevs are not *especially* fond of giving them advice about building software. | 15:13 |
| erLe17 | e.g. i have made a PR that makes the build reliable (it currently is only if you rebuild everything all the time) and it is unlikely to get merged ;) | 15:14 |
| erLe17 | anyway, how am i going to get my computer out of rotating cube mode? | 15:15 |
| erLe17 | ctrl + alt + f-key obviously does not work anymore | 15:15 |
| erLe17 | josch library-wise, minetest is good due to the decision by the devs to fork irrlicht, delete everything they do not use, then delete the unit tests after they did not work anymore ;) | 15:16 |
| josch | great... | 15:17 |
| erLe17 | i have an opinion on that, but it's not pretty :P | 15:17 |
| erLe17 | anyways how to kill kmscube? :( | 15:18 |
| erLe17 | i'll be more careful next time ig | 15:20 |
| minute | erLe17: press return or space i think | 15:22 |
| erLe17 | nope | 15:22 |
| erLe17 | https://gitlab.freedesktop.org/mesa/kmscube/-/blob/master/kmscube.c | 15:22 |
| minute | erLe17: it was some key i think... or maybe left mouse button? but that would be strange | 15:22 |
| erLe17 | also kmscube flashes the terminal for a few frames | 15:23 |
| erLe17 | which i'd count as “KMS does not work” | 15:23 |
| erLe17 | or maybe it is kmscube that does not work | 15:23 |
| erLe17 | but yeah, i can't input anything | 15:23 |
| minute | so you don't see a rotating cube? | 15:24 |
| erLe17 | i do see one – and that's different than error messages about not having KMS i got last time i tried wayland stuff, but i can't get out of that mode. | 15:24 |
| erLe17 | but every few seconds or so it flashes a picture of the linux console on which i started kmscube | 15:25 |
| erLe17 | this would be annoying if it happened with wayland | 15:25 |
| minute | idk sounds borked | 15:26 |
| minute | maybe it's overdraw from the console | 15:26 |
| erLe17 | wait, did “erle” leave here? if so, it killed everything else on the machine | 15:26 |
| erLe17 | yep, seems i have to reboot | 15:26 |
| minute | the solution is to use mnt reform instead | 15:27 |
| erLe17 | minute thanks for the tip nevertheless. i basically checked once if i have KMS and did not have it. | 15:27 |
| erLe17 | hehe | 15:27 |
| erLe17 | btw, do PRs for the SD card image scripts use the CI for their branches? | 15:28 |
| josch | erLe17: no | 15:28 |
| erLe17 | why not? | 15:29 |
| erLe17 | like how can you be so sure the PR even works then | 15:29 |
| josch | erLe17: we don't have a CI runner that would be able to handle arbitrarily many builds -- the current runner keeps state between runs | 15:29 |
| erLe17 | oh | 15:30 |
| josch | erLe17: the CI runner cannot test the result on the reform anyways -- but yes, it would be useful to see if a change at least keeps it buildable | 15:30 |
| josch | erLe17: i've looked into using what other gitlab instances use for CI but that will not work for us because of this bug: | 15:31 |
| josch | erLe17: https://gitlab.com/gitlab-org/gitlab/-/issues/339567 | 15:31 |
| erLe17 | i am asking because after working on https://github.com/minetest/minetest/pull/12592 i have realized that i should pick up my idea to use redo in the sd card build scripts | 15:31 |
| erLe17 | with the goal of faster incremental builds | 15:32 |
| josch | creating the image requires that you execute aarch64 code and the CI runner is x86_64, so we need qemu which doesn't work because of above issue | 15:32 |
| erLe17 | that is unfortunate | 15:32 |
| erLe17 | minute btw, do you have a good intro to GLSL maybe? the minetest shaders are really slow and mesa lets you inject shaders, so i thought maybe i could cargo-cult my own. | 15:33 |
| minute | i do not, sorry | 15:34 |
| erLe17 | for reference: the trick to make your GLSL shaders work everywhere is a) make sure you use the *ARB functions introduced in openGL 1.4 if available, they work the same as the openGL 2.0 shader functions. b) keep to the limits of shader model 2, not shader model 3 (that is direct X language, but openGL 1.4 cards are basically direct X 9 cards and | 15:35 |
| erLe17 | openGL 2.0 cards are basically shader model 3 cards if i have understand it correctly) | 15:35 |
| erLe17 | alternatively, if you care about openGL ES, get something with a mali 400 GPU and make it run there. | 15:37 |
| erLe17 | or grab an old thinkpad that has an intel 9xx GPU that barely supports OGLES, i think they might even be a bit more limited. | 15:38 |
| erLe17 | miinute btw, another cool and simple demo application for 3d gaming included in debian is stoormbaancoureur. if you like impossibly hard racing games, try it out some time. | 15:40 |
| josch | erLe17: the problem with incremental image builds is, that dpkg, apt, debootstrap/mmdebstrap do not produce bit-by-bit identical results when comparing the installation of packages A+B versus first installing A and then B. To fix this you have to change the package manager (dpkg and apt) at its core. | 15:40 |
| erLe17 | it's the only game in debian for which i have seen a bug “the game is too hard” in the bug tracker and the dev responding with making it easier ;) | 15:41 |
| erLe17 | i mean, i am not sure if that was the thing that caused it, but the dev did make it easier | 15:41 |
| erLe17 | josch but you can make sure the package installation order is deterministic, would that not help? | 15:42 |
| josch | erLe17: no and the answer why is very long and out-of-topic for this channel | 15:42 |
| erLe17 | oh okay | 15:42 |
| josch | i would like if this was different but making this happen will be a very hard uphill battle and would require difficult changes everywhere in Debian package management which includes 20+ software packages handling package installation, upgrades and management | 15:44 |
| josch | i'm not saying it's a bad idea but the world is currently against you and this will probably a 10+ year effort to implement | 15:44 |
| erLe17 | does this mean debian installation images are by necessity not reproducible? | 15:44 |
| josch | they are but not when compared to the same image created incrementally | 15:44 |
| erLe17 | or is this speciall-cased somewhere? | 15:45 |
| josch | and you want incremental builds | 15:45 |
| erLe17 | well, i do want incremental builds, but maybe not the way you imagine it ;) | 15:45 |
| josch | right now, if you want bit-for-bit reproducible images you have to rebuild the whole thing | 15:45 |
| josch | sure, maybe i misunderstand your goal | 15:45 |
| erLe17 | my goal is to avoid stuff that is *currently* avoidable to do on incremental builds, by inserting maybe a dozen calls to redo-ifchange | 15:46 |
| erLe17 | you can see in the minetest PR how that can transform an “always rebuild everything” shell script into an incremental build, as long as the build is recursive and top-down | 15:47 |
| erLe17 | maybe you are already doing that,i haven't checked in a while | 15:48 |
| erLe17 | just look at the minetest PR (or just build minetest using it) and you can see what i mean | 15:49 |
| josch | i know how redo works | 15:49 |
| erLe17 | then i guess you either have already optimized it so that it is unnecessary or know that it does not help here. | 15:49 |
| erLe17 | correct? | 15:50 |
| josch | but i have no idea how you see it possible to integrate this into the image creation process | 15:50 |
| josch | maybe i'm still wrong but then maybe just suggest what you would change? | 15:50 |
| erLe17 | i am looking for an example suggestion | 15:51 |
| erLe17 | give me a minute or so | 15:51 |
| josch | no stress -- i'm here all day :D | 15:51 |
| erLe17 | josch take mkuserland.sh – if the package list has not changed and the package versions in debian have not changed, there is no reason to do this step again | 15:52 |
| erLe17 | or is there? | 15:53 |
| josch | erLe17: but what do you depend on? | 15:53 |
| erLe17 | the package list and the package versions in debian | 15:53 |
| erLe17 | oh | 15:53 |
| erLe17 | maybe you don't know redo-stamp? | 15:53 |
| erLe17 | basically, you can depend on the stdin of redo-stamp. redo will then abort the build of that target if the input was the same as last time. | 15:54 |
| erLe17 | so you can make a build rule that is always out of date and then use redo-stamp with some input you gathered from the network or the environment or so to make it abort successfully here, not building the target, but still marking it up to date. | 15:54 |
| erLe17 | it was a bit tricky to implement it, but “decide at runtime that the target you wanted to rebuild is actually good” is a thing that is very useful a lot of the time, because you may not even have that information at the start of the build or it might change during the build even | 15:55 |
| josch | erLe17: so you suggest to first run a simulation to figure out whether versions changed and only if they did change run the actual build? | 15:56 |
| erLe17 | for example, if you have a target for which the dofile begins with “redo-always; date -Imin |redo-stamp; date” and call redo once a second, it will only rebuild that target with the current date and time once “date -Imin” updates its output, so about once per minute | 15:57 |
| erLe17 | sorry for highligthing minute ;) | 15:57 |
| - GNUmoon2 (QUIT: Ping timeout: 268 seconds) (~GNUmoon@gateway/tor-sasl/gnumoon) | 15:58 | |
| josch | erLe17: but how do you suggest to get the information whether package versions changed or not? that task in itself is computationally intensive and imho not worth the cost | 15:58 |
| erLe17 | does it take longer than building the thing? | 15:58 |
| josch | no | 15:58 |
| josch | but it will increase the build time as well as the overall complexity | 15:59 |
| erLe17 | “running a simulation” is the bottom-up build system way. the thing where you always have to build at least twice. | 15:59 |
| erLe17 | in top-down recursive building you can figure it out during the build | 15:59 |
| + GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) | 16:00 | |
| erLe17 | the complexity increase is very modest and just have to figure out the magic incantation to get the current version numbers to begin with | 16:00 |
| erLe17 | you will of course always pay the penalty for correct dependency tracking in the first build, to enable followup builds to be cheaper | 16:01 |
| josch | but you cannot do a follow-up build after having completed the task of figuring out the versions which avoids doing the same thing again | 16:02 |
| erLe17 | wdym? | 16:02 |
| josch | maybe ask a concrete technical question that you need to know to write a patch | 16:02 |
| erLe17 | you figure out the version numbers on the first build and then do the task (which has to take longer than figuring out the version numbers, or else it is not worth it) | 16:02 |
| josch | currently i don't see a way to do it that would be worth the trouble | 16:03 |
| erLe17 | okay, i can write a proof-of-concept of a target that rebuilds every time a debian package changes if you give me a command that tells me the current version of a package that mmdebstrab would pull in | 16:03 |
| josch | that's where the trouble starts -- code to do that doesn't exist | 16:04 |
| erLe17 | i did not know! | 16:04 |
| erLe17 | but for the record, i would just pipe the output of that command to redo-stamp, add a redo-always in the line above and call it done | 16:05 |
| erLe17 | joeyh does this mean that debian rebuilds everything all of the time? | 16:06 |
| erLe17 | sorry, i meant josch | 16:06 |
| erLe17 | tab completion + low contrast name coloring in webchat | 16:06 |
| josch | erLe17: i don't understand the question "debian" does nothing when it comes to creating reform system images | 16:06 |
| erLe17 | well, they do create system images | 16:07 |
| josch | you mean CD images? the live CDs? | 16:07 |
| erLe17 | for example. so i figured if debian does not have a way to get that dependency information, maybe either a) they use different tooling than mmdebstrab b) they rebuild everything and do not handle this step in a way that it can be skipped | 16:08 |
| erLe17 | or c) both | 16:08 |
| + mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 16:08 | |
| josch | they don't "build" anything and neither does the reform-system-image script | 16:08 |
| josch | packages get downloaded and installed from scratch | 16:08 |
| josch | in both cases: for the official Debian CDs as well as for creating the Reform system image | 16:08 |
| erLe17 | “build” in the sense that you run some software and it creates an artifact you want | 16:08 |
| josch | yes | 16:09 |
| josch | the tooling that creates the official Debian CDs starts from scratch every time | 16:09 |
| erLe17 | i see | 16:09 |
| erLe17 | but maybe there is another way. for example, depending on caching headers in the HTTP download of packages, in case they are downloaded via HTTP. you could do HEAD requests before. | 16:10 |
| josch | sure, maybe -- but code to do that doesn't exist as far as i know | 16:10 |
| erLe17 | i have actually done this, used curl to depend on an ETag | 16:10 |
| erLe17 | but it requires you to know the URL | 16:11 |
| erLe17 | i guess maybe that step is not too much usually | 16:11 |
| josch | you mean to just want to avoid re-download? then you can do that today already by using apt-cacher or apt-cacher-ng | 16:12 |
| erLe17 | no,. i want to avoid build steps in abstract and tried to give you a useful example but failed | 16:12 |
| erLe17 | i can give you a useless example | 16:12 |
| erLe17 | if you change the uboot part, you have to rebuild everything again right now, corerct? | 16:13 |
| josch | yes | 16:13 |
| erLe17 | it seems evidently possible for me to separate that out if dependencies were tracked correctly | 16:13 |
| josch | yes, i agree | 16:14 |
| erLe17 | and then you'd just depend on flash.bin for the main image | 16:14 |
| josch | yup | 16:14 |
| josch | that's easy | 16:14 |
| erLe17 | and to as little work as possible, i.e. one dd | 16:14 |
| josch | yes | 16:14 |
| erLe17 | see, that's the kind of thing i mean that i assumed people would already do, without redo sometimes even | 16:14 |
| erLe17 | but it does not save you much | 16:14 |
| erLe17 | whereas if you can manage the *full* dependency tree (like i do in the minetest example) you will at some point always get a minimum rebuild that is correct | 16:15 |
| + flowy (~flowy@2a01:4f8:c0c:1a8f::1) | 16:15 | |
| erLe17 | and with ”at some point” i mean “when the build scripts are correct” | 16:15 |
| josch | you will, if you manage to find a way to get the package versions upfront (which is not trivial) and if you manage to find a way to use that information to just change the packages that changed (very, very, very hard) | 16:16 |
| erLe17 | of course i do not expect it to go into “i add one more package and an incremental build will handle that bit-exact” territory | 16:16 |
| erLe17 | but i wonder, could you actually separate this the way docker does, for example? | 16:17 |
| erLe17 | i.e. have overlay filesystems stacked together | 16:17 |
| erLe17 | i'm not doing that | 16:17 |
| josch | i don't think that this is possible today and would require great changes in apt and dpkg | 16:17 |
| erLe17 | i think it may be possible without changing that stuff, but at the cost of horrible complexity. | 16:18 |
| josch | but if you want to start working on this i can give you a few ideas how you can get package versions | 16:18 |
| erLe17 | the stupidest idea: create X overlay mounts for each set of X packages that interact with each other. make a merging build step that depends on all of them. | 16:19 |
| - MajorBiscuit (QUIT: Ping timeout: 268 seconds) (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 16:19 | |
| erLe17 | that would mean that each overlay filesystem could be separately out of date | 16:19 |
| josch | this cannot work with Debian packages | 16:19 |
| erLe17 | why? | 16:19 |
| erLe17 | do they all interact with some global shared state? | 16:19 |
| josch | you circumvent the package manager and thus break assumptions of dpkg and apt | 16:19 |
| josch | yes | 16:20 |
| erLe17 | the idea would be to merge it in the way that these assumptions hold and i think that is the hard part | 16:20 |
| erLe17 | GyrosGeier has explained the usrmerge mess to me | 16:20 |
| josch | oh god... | 16:20 |
| erLe17 | and i do not intend to side-step package management any time soon | 16:20 |
| - bkeys (QUIT: Ping timeout: 240 seconds) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 16:21 | |
| josch | if you don't then you have to add this ability to dpkg and apt proper | 16:21 |
| erLe17 | enpecially given the ”fun” error cases he brought up | 16:21 |
| josch | yeah... "fun" | 16:21 |
| erLe17 | just to be clear: was there no policy about packages never ever messing with packages owned by another package? | 16:22 |
| erLe17 | because that's the weirdest thing about it | 16:22 |
| erLe17 | for me | 16:22 |
| erLe17 | i mean messing with files | 16:22 |
| erLe17 | sorry | 16:22 |
| erLe17 | like i could not find anyone pointing to a policy that says you have to get approval or conflict with another package if you want to scramble their files or move them somewhere | 16:23 |
| erLe17 | but it looks like a thing that should have come up earlier | 16:23 |
| josch | you cannot even mess with files your own packages owns | 16:23 |
| josch | this doesn't need policy -- it's a property of our package manager | 16:23 |
| erLe17 | then how was usrmerge ever approved? it seems like it sholud not pass QA. | 16:23 |
| josch | dpkg will break if you try this | 16:23 |
| josch | that is another long topic | 16:24 |
| erLe17 | i see | 16:24 |
| erLe17 | well, then let's not discuss it here | 16:24 |
| erLe17 | and i'll keep my opnion of “same as with systemd, some devs break stuff because clearly everyone else is wrong and not them” | 16:24 |
| erLe17 | :P | 16:24 |
| erLe17 | btw, “doesn't need policy” for me means “no jerk ever tested it” | 16:25 |
| erLe17 | anyways, if you play minetest, try my build rules. maybe you can see how to optimize them. | 16:25 |
| + qbit (~qbit@h.suah.dev) | 16:26 | |
| erLe17 | i can beat 4000 lines of cmake build scripts with a <400 lines patch that is mostly shell scripts on correctness, but the cherry on top would be beating cmake on speed | 16:26 |
| erLe17 | which may be impossible for a full rebuild, but it is already possible for incremental builds (and so i thought it could be as well for the reform sd card image) | 16:27 |
| erLe17 | anyway, rebooting my other machine | 16:28 |
| + erle (~erle@ip5f5af7e0.dynamic.kabel-deutschland.de) | 17:00 | |
| - erLe17 (QUIT: Quit: Client closed) (~erLe17@2a02:8109:aa40:3ecc::f67a) | 17:01 | |
| erle | minute thank you for educating me about KMS, i think it may not have worked the last time i tried it and now it does. that's great. | 17:02 |
| erle | meanwhile, my i3 configuration does not work on sway. sway complains about the “bind” command. anyone knows about that? | 17:02 |
| erle | i thought sway was meant to work EXACTLY as i3 | 17:02 |
| sigrid | it's bindsym, I think | 17:15 |
| - chomwitt (QUIT: Ping timeout: 260 seconds) (~chomwitt@2a02:587:dc00:5a00:46c5:b74b:2b21:d09f) | 17:19 | |
| minute | erle: afaik there is a configuration import thing | 17:34 |
| minute | erle: i3 does not have a `bind` command either, it's bindsym as sigrid says | 17:35 |
| minute | erle: https://github.com/swaywm/sway/wiki/i3-Migration-Guide | 17:35 |
| minute | typing this on pocket reform keyboard/trackball | 18:03 |
| minute | hmm it is quite interesting to get used to ortho typing | 18:04 |
| erle | bind 107 exec xfce4-screenshooter | 18:06 |
| erle | that is in my i3 config | 18:06 |
| + MajorBiscuit (~MajorBisc@2a02-a461-129d-1-6d4c-38a4-18b7-4b48.fixed6.kpn.net) | 18:10 | |
| - MajorBiscuit (QUIT: Client Quit) (~MajorBisc@2a02-a461-129d-1-6d4c-38a4-18b7-4b48.fixed6.kpn.net) | 18:15 | |
| minute | erle: what's 107? | 18:20 |
| - GNUmoon2 (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 18:24 | |
| erle | minute the print key | 18:26 |
| erle | print screen | 18:26 |
| erle | i press it to do a screenshot | 18:26 |
| sigrid | run "wev" (it's like xev, but for wayland) and see what "sym: ..." for that key is | 18:29 |
| erle | the problem is that the bind command does not work | 18:30 |
| erle | but thanks | 18:30 |
| erle | what was the magic incantation again to let sway use the correct keyboard layout? | 18:30 |
| erle | it has neither the one i use in X11 nor the one i use on the terminal (both neo2) | 18:31 |
| erle | i remember having had this problem before | 18:31 |
| sigrid | 17:15 < sigrid> it's bindsym, I think | 18:31 |
| erle | well, in i3, bind and bindsym work | 18:31 |
| erle | it seems sway is not 100% compatible, but colud be, if the wev thing is as easy as you xev | 18:31 |
| erle | as you say | 18:31 |
| erle | sorry | 18:31 |
| erle | i am more curious about if this is even useful, given that i can't imagine wayland giving access to the whole screen to some random X11 app | 18:32 |
| erle | i should probably use slurp or so | 18:33 |
| + ajr (~ajr@user/ajr) | 18:56 | |
| - chartreuse (QUIT: Ping timeout: 240 seconds) (~chartreus@node-1w7jr9ql2247t9azo97sze19g.ipv6.telus.net) | 19:08 | |
| + mark_ (~mark@gnu.wildebeest.org) | 20:29 | |
| - mjw (QUIT: Killed (NickServ (GHOST command used by mark_!~mark@gnu.wildebeest.org))) (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 20:31 | |
| * mark_ -> mjw | 20:31 | |
| + wielaard (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 20:31 | |
| Boostisbetter | I don't know, xwayland is pretty good these days. | 20:34 |
| + bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 20:41 | |
| technomancy | i haven't had good luck with xwayland | 20:48 |
| + Nulo_ (~Nulo@user/nulo) | 21:40 | |
| - Nulo (QUIT: Ping timeout: 268 seconds) (~Nulo@user/nulo) | 21:41 | |
| * Nulo_ -> Nulo | 21:41 | |
| + chomwitt (~chomwitt@2a02:587:dc00:5a00:7b16:6292:46ec:6d6d) | 21:53 | |
| Boostisbetter | minute: the pocket reform keyboard and trackball is awesome! keep up the awesome work! Super excited! | 21:55 |
| - ajr (QUIT: Ping timeout: 244 seconds) (~ajr@user/ajr) | 22:12 | |
| - bkeys (QUIT: Remote host closed the connection) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 22:19 | |
| + ajr (~ajr@user/ajr) | 22:39 | |
| - ajr (QUIT: Client Quit) (~ajr@user/ajr) | 22:43 | |
| + ajr (~ajr@user/ajr) | 22:43 | |
| - simba (QUIT: Ping timeout: 240 seconds) (~simba@2001:a61:1154:c001:f743:7589:8478:148f) | 23:13 | |
| + bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 23:30 | |
| - bkeys (QUIT: Remote host closed the connection) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 23:41 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!