| josch | minute: i managed to reproduce the issue | 00:03 |
|---|---|---|
| josch | minute: https://mnt.re/system-image now links to the latest job from the "staging" branch | 00:03 |
| - hairu (QUIT: Remote host closed the connection) (m-uotkmd@user/hairu) | 00:09 | |
| - f_ (QUIT: Ping timeout: 268 seconds) (~AUGESOUND@fases/developer/funderscore) | 00:12 | |
| minute | bluerise: neat | 00:29 |
| minute | josch: argh @ that link | 00:29 |
| + f_ (~AUGESOUND@fases/developer/funderscore) | 00:30 | |
| josch | minute: i have a theory about why this is happening which i'm testing right now | 00:33 |
| - jacobk (QUIT: Ping timeout: 260 seconds) (~quassel@129.110.242.173) | 00:40 | |
| + hairu (m-uotkmd@user/hairu) | 00:57 | |
| josch | minute: theory confirmed: https://mntre.com/reform-debian-repo/pool/main/r/reform-tools/ | 01:00 |
| josch | the mntre.com repo now has reform-tools 1.38 in it even though the latest job of the main branch of reform-debian-packageshas reform-tools 1.37 | 01:01 |
| josch | minute: can you check from which branch the job is that your script that updates the mntre.com repo ends up downloading artifacts from? | 01:02 |
| josch | it is probably "staging" even though it shouldn't be | 01:02 |
| - mtm (QUIT: Ping timeout: 264 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 01:02 | |
| - mjw (QUIT: Ping timeout: 264 seconds) (~mjw@gnu.wildebeest.org) | 02:01 | |
| - cobra (QUIT: Ping timeout: 255 seconds) (~cobra@user/Cobra) | 02:06 | |
| + cobra (~cobra@user/Cobra) | 02:19 | |
| - vagrantc (QUIT: Ping timeout: 255 seconds) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 03:03 | |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 03:09 | |
| - Guest2246 (QUIT: Ping timeout: 240 seconds) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 03:19 | |
| + Guest2246 (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 03:32 | |
| - nsc (QUIT: Ping timeout: 260 seconds) (~nicolas@201-48-142-46.pool.kielnet.net) | 03:41 | |
| + nsc (~nicolas@186-99-142-46.pool.kielnet.net) | 03:43 | |
| + jacobk (~quassel@64.189.201.150) | 05:55 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 05:56 | |
| - jacobk (QUIT: Ping timeout: 268 seconds) (~quassel@64.189.201.150) | 06:38 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 06:48 | |
| + anzu (~anzu@melkki.cs.helsinki.fi) | 08:55 | |
| - mesaoptimizer (QUIT: Quit: nyaa~) (~mesaoptim@user/PapuaHardyNet) | 09:28 | |
| + mesaoptimizer (~mesaoptim@user/PapuaHardyNet) | 09:30 | |
| + mjw (~mjw@gnu.wildebeest.org) | 09:53 | |
| - erle (QUIT: Quit: Democracy must always be better armed than tyranny.) (~erle@2a02:3102:4286:16:be:bdbd:2409:d4a5) | 10:04 | |
| + erle (~erle@2a02:3102:4286:16:be:bdbd:2409:d4a5) | 10:15 | |
| * mesaoptimizer -> mesaoptimizer2 | 10:19 | |
| + Christoph__ (~Christoph@p4fe73884.dip0.t-ipconnect.de) | 10:57 | |
| + Christoph_ (~Christoph@p4fe73d7c.dip0.t-ipconnect.de) | 11:11 | |
| - Christoph__ (QUIT: Ping timeout: 268 seconds) (~Christoph@p4fe73884.dip0.t-ipconnect.de) | 11:13 | |
| - erle (QUIT: Quit: Democracy must always be better armed than tyranny.) (~erle@2a02:3102:4286:16:be:bdbd:2409:d4a5) | 11:28 | |
| digitalrayne | hey bluerise, was curious if you've tested imxspi under OpenBSD on reform before? or if it was another imx board? | 11:37 |
| - colinsane (QUIT: Quit: bye) (~colinunin@97-113-159-4.tukw.qwest.net) | 11:38 | |
| digitalrayne | i've been messing around with it and have been seeing some strange behaviour which i'm sure is just me, or clocking, or incorrect spi mode, but thought i'd ask | 11:39 |
| + colinsane (~colinunin@97-113-159-4.tukw.qwest.net) | 11:40 | |
| - mjw (QUIT: Ping timeout: 252 seconds) (~mjw@gnu.wildebeest.org) | 12:01 | |
| * Guest2246 -> mjw | 12:11 | |
| - Christoph_ (QUIT: Quit: Christoph_) (~Christoph@p4fe73d7c.dip0.t-ipconnect.de) | 12:20 | |
| + Christoph_ (~Christoph@p4fe73d7c.dip0.t-ipconnect.de) | 12:20 | |
| bluerise | digitalrayne: I wrote imxspi(4) myself in 2018 | 12:42 |
| bluerise | Add imxspi(4), a driver for the i.MX SPI controller. This is the first | 12:42 |
| bluerise | SPI controller in our tree. Add a basic generic SPI infrastructure as | 12:42 |
| bluerise | well. | 12:42 |
| bluerise | It's quite possible that there are issues on other boards | 12:42 |
| bluerise | On the i.MX8MQ-based board I worked on back then, I was able to use it for SSD1306/SSD1309 and TPM 2.0 | 12:42 |
| - mjw (QUIT: Remote host closed the connection) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 12:46 | |
| + mjw (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 12:50 | |
| - mtm (QUIT: Ping timeout: 252 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 13:03 | |
| minute | yo i seemed to have missed out on "refmon" by vkoskiv, where can i find that to try? | 13:44 |
| - colinsane (QUIT: Quit: bye) (~colinunin@97-113-159-4.tukw.qwest.net) | 14:08 | |
| + colinsane (~colinunin@97-113-159-4.tukw.qwest.net) | 14:12 | |
| + mark_ (~mjw@gnu.wildebeest.org) | 14:23 | |
| - mark_ (QUIT: Ping timeout: 272 seconds) (~mjw@gnu.wildebeest.org) | 15:07 | |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 15:09 | |
| + jacobk (~quassel@64.189.201.150) | 15:35 | |
| - jacobk (QUIT: Ping timeout: 268 seconds) (~quassel@64.189.201.150) | 15:57 | |
| josch | minute: were you able to verify my finding that the mnt.re debian repo is getting poisoned by CI artifacts from other branches than what gets merged to main? | 16:34 |
| josch | minute: i now know why this happens but i'd like to undo this as quickly as possible but am waiting for you to see it yourself | 16:34 |
| minute | josch: yes, acknowledged. | 16:51 |
| minute | josch: why does it happen? | 16:51 |
| josch | minute: the theory that is backed by my observations during the past days and the pipeline runs i've triggered is as follows (i didn't find this in the documentation though): if you link to https://source.mnt.re/reform/reform-system-image/-/jobs/artifacts/main/browse?job=build then you get to the latest pipeline run of the top commit of the main branch. If the same commit hash is found in other branch, | 17:37 |
| josch | then that will be treated as being the exact same thing and thus it can also show you stuff from other branches as long as the top commit is the same as in the branch you requested. The problem appears if you trigger a pipeline run with some variables set to non-default values. Because gitlab seems to not make a difference between a pipeline run with all variables at their default values and pipeline | 17:37 |
| josch | runs where something got manually changed. So if I copy the "main" branch as "staging" and then do a run of the "staging" branch with a custom reform-tools version, then gitlab will look up that pipeline because it has the same top commit as the main branch even though the branch name is different and the pipeline variables are different. | 17:37 |
| josch | i have no idea whether there is a way to adjust this link to avoid this behaviour and as a quick fix i amended the variables.sh file such that your mnt.re repo mirror script can find out whether the stuff it downloaded came from the main branch or some other branch and abort updating if it's the latter. | 17:37 |
| josch | this approach of course cannot work for the reform-system-image repo. Maybe instead of linking to https://source.mnt.re/reform/reform-system-image/-/jobs/artifacts/main/browse?job=build you should manually put a link to the latest reform-system-image release or regularly update the job id once it is known that a certain job X produced images that are known to work | 17:39 |
| josch | another solution would be, to revert all the changes that allow running the gitlab pipeline with custom variables. In that case, building custom reform-tools, reform-debian-packages and reform-system-image would require a commit that changes the respective variable in which case the top commit would not be equal to main anymore and thus the problem would not appear anymore | 17:40 |
| + jacobk (~quassel@utdpat241106.utdallas.edu) | 17:40 | |
| josch | another solution would be to not allow forks in the main reform-tools, reform-debian-packages and reform-system-image repositories with a top commit equal to "main" and force those custom pipeline runs in the forked repositories but never run them in the "reform" group | 17:40 |
| + mark_ (~mjw@gnu.wildebeest.org) | 18:06 | |
| josch | i did another run of the reform-debian-packages pipeline for main so that the mntre.com repo is fixed again and ships reform-tools 1.37 as it should | 18:09 |
| hramrach | technically the branch name is a label, and if a commit has multiple labels it can be found under all of them. However, the job is run for a specific branch, and gitlab looking it by the commit id rather than branch name is probably a bug in gitlab. | 18:26 |
| + tretinha_ (3a571d9f43@2a03:6000:1812:100::1151) | 18:39 | |
| + cmahns_ (8fe824803c@2a03:6000:1812:100::10cd) | 18:39 | |
| + f__ (~AUGESOUND@fases/developer/funderscore) | 18:39 | |
| + kensanata9 (~alex@user/kensanata) | 18:40 | |
| + klardotsh_ (~klardotsh@c-67-170-115-80.hsd1.wa.comcast.net) | 18:41 | |
| + noam_ (81879d1ffa@2a03:6000:1812:100::dfc) | 18:41 | |
| + nsc_ (~nicolas@186-99-142-46.pool.kielnet.net) | 18:41 | |
| + buckket1 (~buckket@vps.buckket.org) | 18:42 | |
| - nsc (QUIT: *.net *.split) (~nicolas@186-99-142-46.pool.kielnet.net) | 18:46 | |
| - f_ (QUIT: *.net *.split) (~AUGESOUND@fases/developer/funderscore) | 18:46 | |
| - klardotsh (QUIT: *.net *.split) (~klardotsh@c-67-170-115-80.hsd1.wa.comcast.net) | 18:46 | |
| - kensanata (QUIT: *.net *.split) (~alex@user/kensanata) | 18:46 | |
| - buckket (QUIT: *.net *.split) (~buckket@vps.buckket.org) | 18:46 | |
| - tretinha (QUIT: *.net *.split) (3a571d9f43@2a03:6000:1812:100::1151) | 18:46 | |
| - cmahns (QUIT: *.net *.split) (8fe824803c@2a03:6000:1812:100::10cd) | 18:46 | |
| - noam (QUIT: *.net *.split) (81879d1ffa@2a03:6000:1812:100::dfc) | 18:46 | |
| * noam_ -> noam | 18:46 | |
| * f__ -> f_ | 18:46 | |
| * tretinha_ -> tretinha | 18:46 | |
| * cmahns_ -> cmahns | 18:46 | |
| * kensanata9 -> kensanata | 18:47 | |
| - colinsane (QUIT: Quit: bye) (~colinunin@97-113-159-4.tukw.qwest.net) | 18:52 | |
| * mjw -> Guest9745 | 19:40 | |
| - Guest9745 (QUIT: Killed (platinum.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 19:40 | |
| * mark_ -> mjw | 19:40 | |
| + Guest9745 (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 19:41 | |
| digitalrayne | oh yeah bluerise - i noticed you wrote it which is why i asked :) - do you have any code which uses spi_read handy? no trouble if not, it just might help with the debugging i'm doing | 19:55 |
| digitalrayne | writes seems to be working just fine btw, and i've been using ssdfb as a reference | 19:56 |
| - jacobk (QUIT: Ping timeout: 260 seconds) (~quassel@utdpat241106.utdallas.edu) | 20:21 | |
| minute | https://patchwork.freedesktop.org/patch/584645/ | 20:43 |
| josch | oh wow you really tracked that 32bit panthor thing down! | 21:14 |
| minute | well, bbrezillon did, i only supplied the apitrace | 21:23 |
| minute | but yeah, the fix works!! | 21:23 |
| josch | sweeeeeet :) | 21:27 |
| minute | josch: can you add this version of the patch to your rk3588 patchstack? (where does that live btw?) https://patchwork.freedesktop.org/patch/584696/?series=131585&rev=1 | 21:27 |
| josch | minute: it is now in main! :) | 21:29 |
| josch | oh no wait | 21:29 |
| josch | not the rk3588 stuff | 21:29 |
| minute | yeah there's no patches-3.8 yet | 21:29 |
| josch | the collabora patch stack applied to linux 6.8 | 21:29 |
| josch | and there is no Debian linux kernel release for 6.8 yet | 21:29 |
| josch | so there is nothing for rk3588 in the reform-debian-packages repo yet | 21:30 |
| minute | ok :3 | 21:31 |
| minute | josch: do you have the recipe on how to make a debian package from that 3.8 stack for me again? i'll put it in my todo list so i don't lose it | 21:32 |
| minute | josch: btw thank you very much for your thorough feedback on the handbook, we went through it in a call today and most of the feedback made it into the handbook | 21:32 |
| josch | happy i could help! | 21:32 |
| josch | minute: building the debian package is just building the .dsc | 21:33 |
| josch | do you have sbuild set up on your machine? | 21:33 |
| minute | josch: i have sbuild set up on my work pc if i'm not mistaken, for building reform-debian-packages / only the linux package from it | 21:33 |
| josch | about Debian linux 6.8, Diederik de Haas packaged it but then gave up because of the included GPL violation: https://salsa.debian.org/kernel-team/linux/-/merge_requests/1047 | 21:33 |
| minute | i have a little build-linux.sh helper there | 21:33 |
| minute | it's basically: . common.sh; export VERSUFFIX; env --chdir=linux BUILD_ARCH=amd64 HOST_ARCH=arm64 BASESUITE=unstable OURSUITE=reform ./build.sh | 21:34 |
| josch | essentially you would run dget http://mister-muffin.de/reform/linux6.8/...dsc; sbuild -d unstable linux.dsc | 21:34 |
| josch | minute: that's the recipe for reform-debian-packages | 21:34 |
| josch | the kernel i built you is not doing any of the fancy reform-debian-packages stuff | 21:34 |
| josch | it's a regularl debian source package | 21:35 |
| minute | ok, i'll try that | 21:36 |
| minute | now | 21:36 |
| minute | it goes brrr | 21:38 |
| josch | let me go see the log how fast that was on my a311d | 21:38 |
| minute | looks like it needs more .dsc files > E: Could not find linux.dsc | 21:38 |
| minute | ah no | 21:38 |
| minute | my mistake | 21:38 |
| josch | okay, your rk3588 needs to beat 3:20 h to build it :) | 21:41 |
| minute | ahh haha :D i don't have the setup on my rk3588 though (yet) | 21:42 |
| josch | pffff... ;) | 21:43 |
| minute | my i9-9900 does it now :D | 21:43 |
| josch | not sure if i want to know how much faster that thing is XD | 21:43 |
| minute | i think maybe a bit more than double the speed of the rk3588 | 21:43 |
| minute | https://browser.geekbench.com/processors/intel-core-i9-9900k | 21:44 |
| minute | vs https://browser.geekbench.com/v6/cpu/5452433 | 21:45 |
| josch | minute: you should run this geekbench thing on the other SoMs as well :) | 21:45 |
| minute | yeah :D | 21:45 |
| minute | but... i9-9900k needs 95W TDP for that result | 21:45 |
| josch | i think there was some data on openbenchmarking phoronix test suite but i cannot find it anymore | 21:45 |
| josch | yeah i was about to point that out :) | 21:45 |
| josch | you don't want that in a laptop :) | 21:45 |
| minute | nope... | 21:46 |
| minute | it also goes to 5ghz... | 21:46 |
| minute | ok, sbuild fails with a lot of > ModuleNotFoundError: No module named 'yaml' | 21:50 |
| minute | i do have python3-yaml installed though | 21:51 |
| josch | can you pastebin a build log for me? | 21:51 |
| minute | hmm also... the filename looks like it's maybe not a crossbuild? | 21:53 |
| minute | josch: http://dump.mntmn.com/linux_6.8~rc7-1_amd64-2024-03-25T20-39-12Z.build | 21:53 |
| minute | i can run this on the rk3588 tomorrow... | 21:53 |
| josch | minute: my instructions above were assuming you are building natively :) | 21:54 |
| josch | if you want to cross-build you have to also pass this to sbuild: | 21:54 |
| josch | --build=amd64 --host=arm64 --profiles=cross,nodoc,pkg.linux.nokerneldbg,pkg.linux.nokerneldbginfo | 21:55 |
| josch | the yaml issues should go away once you build with nodoc | 21:56 |
| josch | it's yaml missing inside the chroot, not on the outside | 21:56 |
| minute | oh thanks :3 | 22:00 |
| * mesaoptimizer2 -> mesaoptimizer | 22:00 | |
| + jacobk (~quassel@utdpat241106.utdallas.edu) | 22:11 | |
| - jacobk (QUIT: Ping timeout: 268 seconds) (~quassel@utdpat241106.utdallas.edu) | 22:43 | |
| - Christoph_ (QUIT: Quit: Christoph_) (~Christoph@p4fe73d7c.dip0.t-ipconnect.de) | 23:22 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!