- mjw (QUIT: Killed (NickServ (GHOST command used by mark_!~mjw@gnu.wildebeest.org))) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 00:37 | |
* mark_ -> mjw | 00:37 | |
+ mark_ (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 00:38 | |
- arminweigl (QUIT: Quit: ZNC - https://znc.in) (~arminweig@sourcehut/user/arminweigl) | 01:07 | |
+ arminweigl (~arminweig@sourcehut/user/arminweigl) | 01:07 | |
- klardotsh (QUIT: Ping timeout: 245 seconds) (~klardotsh@98.97.36.213) | 01:35 | |
- mjw (QUIT: Ping timeout: 246 seconds) (~mjw@gnu.wildebeest.org) | 01:53 | |
- S0rin (QUIT: Quit: WeeChat 3.8) (~S0rin@user/s0rin) | 02:02 | |
- mtm (QUIT: Ping timeout: 245 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 02:02 | |
+ klardotsh (~klardotsh@98.97.36.213) | 02:23 | |
+ bkeys (~Thunderbi@static-198-54-130-101.cust.tzulo.com) | 02:53 | |
+ S0rin (~S0rin@user/s0rin) | 03:04 | |
+ sl (~sl@contrib.inri.net) | 03:13 | |
- nsc (QUIT: Ping timeout: 245 seconds) (~nicolas@39-98-142-46.pool.kielnet.net) | 03:37 | |
+ nsc (~nicolas@88-48-142-46.pool.kielnet.net) | 03:39 | |
+ mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 04:08 | |
- nsc (QUIT: Ping timeout: 246 seconds) (~nicolas@88-48-142-46.pool.kielnet.net) | 04:11 | |
- S0rin (QUIT: Ping timeout: 246 seconds) (~S0rin@user/s0rin) | 04:12 | |
+ nsc (~nicolas@195-48-142-46.pool.kielnet.net) | 04:13 | |
- klardotsh (QUIT: Ping timeout: 245 seconds) (~klardotsh@98.97.36.213) | 04:26 | |
+ S0rin (~S0rin@user/s0rin) | 04:29 | |
josch | minute: i just noticed that the source.mnt.re CI re-uses the directory /ramdisk/builds/reform/reform-debian-packages for its builds and keeps its contents | 04:44 |
---|---|---|
josch | minute: was this a deliberate decision? this means that the build artifacts from one run are able to influence others | 04:44 |
josch | so if you have one branch where you do experiments, that may have an effect on runs on other branches | 04:45 |
josch | minute: to prevent this from happening, we can run "git clean -fdx" before every pipeline run | 04:45 |
josch | minute: but i think recently you said you wanted to avoid re-building packages that are already built? | 04:46 |
josch | i'm just running "git clean -fdx" for now just to make sure that each pipeline run starts from a clean slate | 04:46 |
josch | doing everything inside /ramdisk/builds/reform/reform-debian-packages also means that the CI can only do sequential builds but i see that jobs are not run in parallel anyways | 04:47 |
- S0rin (QUIT: Ping timeout: 246 seconds) (~S0rin@user/s0rin) | 05:04 | |
+ S0rin (~S0rin@user/s0rin) | 05:06 | |
- sl (QUIT: Quit: Leaving...) (~sl@contrib.inri.net) | 05:20 | |
- S0rin (QUIT: Ping timeout: 246 seconds) (~S0rin@user/s0rin) | 05:58 | |
+ S0rin (~S0rin@user/s0rin) | 06:01 | |
- Gooberpatrol66 (QUIT: Ping timeout: 264 seconds) (~Gooberpat@user/gooberpatrol66) | 06:03 | |
Boostisbetter | josch: baby had you burning the midniight oil? | 06:52 |
josch | after two years the word "night" lost its original meaning ;) | 06:52 |
Boostisbetter | josch I know exactly what you mean. Of course my three are older now and sleep through the night. Then we got a dog.... | 06:54 |
+ Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 07:18 | |
+ amospalla (~amospalla@212.231.228.113) | 10:44 | |
amospalla | josch: thank you, I'm planning on move my desktop to the same system as my future pocket reform. | 10:51 |
amospalla | What has been your experience guys with running debian unstable? | 10:52 |
josch | amospalla: I'm a Debian Developer so I usually know what to do when things break. And things break very often. I would not recommend using unstable for a system that is not meant to do bleeding-edge development. | 10:53 |
amospalla | Thank you, very concise answer. | 10:54 |
josch | for the use-case of "I want the very latest stuff" I'd rather recommend using "testing" | 10:55 |
josch | which (if there are no bugs) is usually only 5 days behind unstable | 10:55 |
amospalla | Oh, much better. I already used all of them when younger, but a lot of time has passed since then. | 10:56 |
josch | amospalla: I think it should be possible to run Debian stable on the pocket reform *if* one runs a kernel newer than stable (6.4+) | 10:57 |
josch | I'm currently in the process of setting up https://reform.debian.net where I will serve a (GPG signed) package repository for Debian stable as well as downloadable system images (all based on stable) | 10:57 |
amospalla | Sometimes I look on forums (just for fun) how moving to something more related to rolling-release would be. And I look at Debian testing/unstable, being that the most familiar to me. Lot of times people prefers running unstable to testing on these forums, but I never really understood why. | 10:58 |
amospalla | Well, regarding the Pocket, I will end using what you guys tell is the best platform for it. | 10:58 |
josch | Me neither. I think testing is perfectly fine (unless one really is a Debian Developer and develops directly on unstable) | 10:58 |
josch | amospalla: I'm sure that just like with the big reform there will be many options besides Debian as well | 10:59 |
josch | Debian is just the default chosen by MNT but that doesn't imply it's the best choice :) | 10:59 |
amospalla | Anyway, the "official" images for the Pocket will be mostly Stable or Unstable right? No Testing, I guess. | 10:59 |
josch | yes | 11:00 |
josch | the reason is, that we want to find bugs in unstable *before* they transition to testing | 11:00 |
amospalla | Yes, I know. Anyway my thinkering times passed, now I am an old boring LTS user for my daily uses/work hehe. | 11:00 |
josch | but even when you download the official image from unstable, you are free to do s/unstable/testing/ in your /etc/apt/sources.list | 11:00 |
josch | boring can also be very nice :) | 11:01 |
amospalla | Oh nice, with that said, I think I may try testing :) | 11:01 |
amospalla | Besides deb systems, my heart always was with Gentoo. That distribution is the funniest thing I've known. I miss it :') | 11:02 |
josch | I hear some people are running Gentoo on their reform. They posted on the forums. | 11:02 |
amospalla | Every now and then I launch some VM, install Gentoo, play with it for some hours and then I realize I must come to real life hehe | 11:02 |
amospalla | Ok, I'll move my current laptop (a GPD pocket 2 with a dead battery) to Debian testing today. I already moved from ubuntu LTS to debian unstable when I bought the Pocket Reform. | 11:04 |
amospalla | Thank you very much for your feedback josch ! | 11:04 |
amospalla | I never enter here to chat except when I want to ask something, but I am daily reading the logs to be up to date with what's being done here. I guess I'm a perfect lurker. | 11:05 |
josch | you broke your perfect record then ;) | 11:06 |
amospalla | I stopped using IRC also time ago, some day I'll setup some client. | 11:06 |
josch | don't forget to install the apt-listbugs package when you run testing or unstable | 11:06 |
amospalla | yes hehe :) | 11:06 |
josch | that package, when installed, will check if any of the package you install or upgrade to have release critical bugs and if yes, you can abort the installation or upgrade | 11:06 |
amospalla | Yes, that is a must, I already installed it, thank you ! | 11:07 |
josch | nice :) | 11:10 |
- amospalla (QUIT: Quit: Client closed) (~amospalla@212.231.228.113) | 11:45 | |
+ mjw (~mjw@gnu.wildebeest.org) | 12:33 | |
- [tj] (QUIT: Ping timeout: 240 seconds) (~tj]@188.166.156.159) | 12:41 | |
josch | minute: could you accept https://source.mnt.re/reform/reform-handbook/-/merge_requests/11 | 13:21 |
josch | minute: I restructured the reform-debian-packages pipeline and this is a blocker for that | 13:22 |
- Boostisbetter (QUIT: Ping timeout: 246 seconds) (4a410829d7@irc.cheogram.com) | 13:43 | |
+ Boostisbetter (4a410829d7@irc.cheogram.com) | 13:46 | |
- mtm (QUIT: Ping timeout: 246 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 14:03 | |
minute | josch: done! | 14:06 |
josch | oh the reform-handbook CI is also broken... | 14:10 |
minute | josch: pip install complaint... can you override it? i am on a phone atm | 14:11 |
josch | yes, i'll fix it up in a bit and send another MR | 14:12 |
minute | thank you!! | 14:18 |
Boostisbetter | minute: If I see grammatical errors on the website, who would I talk to let them know? | 14:19 |
- Asmadeus (QUIT: Quit: moving client) (~asmadeus@240b:13:8c80:d300::42:10) | 14:21 | |
+ Asmadeus (~asmadeus@240b:13:8c80:d300::42:13) | 14:23 | |
Boostisbetter | minute: nothing big, but depending on your audience it could be a distraction. | 14:25 |
minute | Boostisbetter: do tell | 14:33 |
- Asmadeus (QUIT: Ping timeout: 246 seconds) (~asmadeus@240b:13:8c80:d300::42:13) | 14:34 | |
- mjw (QUIT: Ping timeout: 246 seconds) (~mjw@gnu.wildebeest.org) | 14:41 | |
Boostisbetter | Ok, https://mntre.com/reform.html | 14:44 |
Boostisbetter | On the hand "to restore, to return to its original state"; on the other, "to form, to shape". | 14:45 |
Boostisbetter | On one hand "to restore, to return to its orginal state"; on the other, "to form, to shape". | 14:45 |
+ Asmadeus (~asmadeus@p83d5e266.hkidnt01.ap.so-net.ne.jp) | 15:00 | |
- xktr (QUIT: Quit: leaving) (~xktr@2602:fe3d:c01:10ca:1050:1ace:0:b) | 15:10 | |
- Asmadeus (QUIT: Ping timeout: 245 seconds) (~asmadeus@p83d5e266.hkidnt01.ap.so-net.ne.jp) | 15:16 | |
+ Asmadeus (~asmadeus@240b:13:8c80:d300::42:13) | 15:18 | |
+ xktr (~xktr@2602:fe3d:c01:10ca:1050:1ace:0:b) | 15:23 | |
josch | minute: thank you for merging the reform-handbook fixes. It works now. Could you have a look at this merge request and decide whether you like the split into the individual jobs: https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/8 | 15:27 |
+ mjw (~mjw@gnu.wildebeest.org) | 15:30 | |
Boostisbetter | You know minute, if you would like someone to make those changes for you, I would be happy to. I could proof all of the texts, etc. | 15:30 |
Boostisbetter | However, I am not really suggesting the need is so great for that. What is there is very good, with only minor things. | 15:31 |
josch | minute: nooo! don't merge so quickly! we need to wait until the pipeline finished to see if it works XD | 15:34 |
josch | and I see you are happy with the splitci branch ;) | 15:34 |
josch | okay nice, the pipeline succeeded after all | 15:50 |
- Asmadeus (QUIT: Read error: Connection reset by peer) (~asmadeus@240b:13:8c80:d300::42:13) | 16:00 | |
+ Asmadeus (~asmadeus@240b:13:8c80:d300::42:13) | 16:05 | |
+ mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 16:09 | |
- jacobk (QUIT: Ping timeout: 264 seconds) (~quassel@47-186-122-163.dlls.tx.frontiernet.net) | 16:28 | |
minute | Boostisbetter: thank you for raising that error! | 17:12 |
- _nrb_ (QUIT: Remote host closed the connection) (~nrbnrb@2a01:4f8:172:299c:1::29) | 17:13 | |
+ _nrb_ (~nrbnrb@2a01:4f8:172:299c:1::29) | 17:17 | |
Boostisbetter | minute: I just want MNT to shine as best it can. I think you are doing great work!! | 17:42 |
- Asmadeus (QUIT: Read error: Connection reset by peer) (~asmadeus@240b:13:8c80:d300::42:13) | 17:58 | |
+ Asmadeus (~asmadeus@240b:13:8c80:d300::42:13) | 18:03 | |
josch | minute: earlier today I talked about CI using /ramdisk/builds/reform/reform-debian-packages. This also is a problem with the current serial builds. Because if one pipeline is already running and then another one gets queued before the last job of the first pipeline is run, then the first job of the new pipeline will get run before the last job of the first pipeline runs. | 18:09 |
josch | minute: so we must be very careful that we do not push commits before exsting pipelines succeeded | 18:09 |
josch | this especially is a problem when the pipeline runs from the main branch | 18:09 |
josch | because if jobs from another branch run before the last job for the main branch runs, then the last job from the main branch will make the repo contain packages from any random other branch | 18:10 |
josch | this problem just happened in practice: https://source.mnt.re/reform/reform-debian-packages/-/pipelines | 18:11 |
josch | the last job of pipeline #1061 failed because the first job of pipeline #1062 was run first | 18:12 |
josch | the first job of pipeline #1062 cleaned up the build space and as a result, the last job of pipeline #1061 didn't find any files it could add to the repo | 18:12 |
pandora[m] | Shouldn’t they be serialised and trigger each other? Sounds like some pipelines run in parallel that shouldn’t | 18:29 |
pandora[m] | Or those depend Jobs should all be in one pipeline and independent steps that run after each other with a test step in the end | 18:31 |
pandora[m] | Tho I haven’t had a look at the current setup yet | 18:32 |
josch | pandora[m]: jobs do not run in parallel. But a job from a later pipeline can get queued before the last job of a previous pipeline started. | 18:33 |
josch | pandora[m]: i guess usually that is no problem because jobs do not have access to a shared underlying filesystem location | 18:34 |
pandora[m] | Hmm… I need to have a look to understand the problem. Normally the pipelines should not affect each other and the jobs should be queued accordingly but it sounds like the file system is shared? Isn’t the build system some independent do jet container that runs and then gets discarded? | 18:37 |
Boostisbetter | pandora[m], have you noticed that this channel is out of sync on your end? Are you using the Matrix.org bridge? | 18:38 |
pandora[m] | Yes I do but it seems synced? I don’t use matrix.org bridge but one from milliways. I don’t have an irc client to check if it is really in sync | 18:39 |
josch | pandora[m]: the jobs are run inside docker containers but they evidently share the same underlying filesystem for their git clones | 18:39 |
Boostisbetter | pandora[m], the crazy thing is that I host my own matrix instance. I have no irc bridge setup, and I was able to join through my Matrix account. But it was desynced all the time. I have no idea how it was working or what bridge I was using. | 18:40 |
pandora[m] | Weird … maybe ur instance came with some pre-configured bridge? | 18:41 |
pandora[m] | josch: Was just curious bc i had similar issues at work. But there it was a scheduling issue where the jobs wrote files into an s3 bucket. If those jobs were not scheduled correctly they crashed because some files were no existent at this time | 18:42 |
josch | okay. | 18:42 |
josch | no, the jobs get scheduled in the correct order | 18:43 |
pandora[m] | But I will have a look at the pipelines later on to (maybe) understand the issue better | 18:44 |
josch | minute: the linux kernel build with the pocket reform patches fails for kernel 6.4: https://source.mnt.re/reform/reform-debian-packages/-/jobs/1457/raw | 19:07 |
josch | minute: there seem to be problems with arch/arm64/boot/dts/freescale/imx8mp.dtsi | 19:08 |
minute | josch: unfortunately i can't look at it today. it's fine for me if you just move the pocket patches away temporarily | 19:09 |
+ Booster[m] (~boosterbo@2001:470:69fc:105::3:3d99) | 19:09 | |
Booster[m] | pandora: Actually I think it is because Libera.chat has some kind of bridging functionality built into the IRC server itself. | 19:09 |
Boostisbetter | pandora[m], but I think the sync is just because i am piggy backing on the IRC bridge from the IRC server itself. Nice that they offer that, but it doesn't seem to aggressively sync or poll for new messages. | 19:18 |
q66 | libera, oftc and some other networks have a bridge | 19:19 |
q66 | the transparent bridging may not last though https://libera.chat/news/matrix-irc-bridge-updates | 19:20 |
q66 | because it's janky as hell | 19:20 |
Booster[m] | q66: Mighty nice of them. | 19:20 |
q66 | yeah, so nice of them to run a janky bridge that keeps losing messages and shits itself to the point of killing off all the users at least once a month | 19:20 |
q66 | almost makes me think that it's some kind of EEE scheme to lure IRC users into using matrix and eventually making them drop IRC because of the unmanageable jank :p | 19:21 |
Booster[m] | Hmmm EMS is behind it, and that message was from the 7th of last month. So I mean if they really were planning to just dump the bridge, I think it would have happened already by now. | 19:23 |
Booster[m] | So far things are working on this, so I wonder if they have quite improved the bridge? | 19:23 |
q66 | kinda doubt it | 19:24 |
Booster[m] | Either way, the thing that annoys me about how Matrix is able "bridge" to a lot of chat platforms it does so by basically using a proxy user on that chat platform. Super annoying. It is the equivalent of running the server you are bridging to as one of your own servers as well. I don't see that really as bridging honestly. | 19:24 |
q66 | >In the interest of giving you as much time possible to prepare, on July 30th 2023 we will be taking one of the following actions: | 19:24 |
q66 | it says july 30 | 19:24 |
Booster[m] | yeah that was the next article. | 19:26 |
Booster[m] | I'm reading it now. | 19:26 |
Booster[m] | Guess, I'll just use XMPP for now. | 19:27 |
- Booster[m] (PART: !!unknown attribute: msg!!) (~boosterbo@2001:470:69fc:105::3:3d99) | 19:27 | |
Boostisbetter | xmpp bridging via cheogram is typically VERY good. | 19:28 |
Boostisbetter | cheogram in general is a great service. Phone calls and SMS work great through it. | 19:36 |
pandora[m] | <Booster[m]> "pandora: Actually I think it..." <- oh yeah... u r right... i am implicitly using the libera.chat bridge by joining https://matrix.to/#/#mnt-reform:libera.chat | 20:22 |
pandora[m] | "https://matrix.to/#/#mnt-reform:libera.chat" | 20:22 |
pandora[m] | <Boostisbetter> "pandora, but I think the sync is..." <- i am not having any issues or at least i am not noticing them . it took a few minutes to join the room the very first time through the bridge. that was kinda weird | 20:23 |
pandora[m] | <q66> "the transparent bridging may not..." <- uff ... i didnt' know . i am kinda afraid i am gonna get disconnect august 1st. but i don't feel like running my own irc bouncer to get all the messages all the time :/ | 20:28 |
+ ajr (uid609314@user/ajr) | 20:30 | |
Boostisbetter | me neither, does this just mean that you'll only get messages when you are connected? | 20:40 |
Boostisbetter | That wouldn't be so bad, becuase you could always use the logs to catch up for the times you can't be connected. | 20:40 |
Boostisbetter | Meh, I just rejoined, and tried sending a few things. Nothing showed up here in my XMPP client, and nothing in the IRC log. So janky is probably the best way to classify the libera.chat bridge. | 20:47 |
pandora[m] | My I should check the logs what i am missing🙈😅 | 20:50 |
Boostisbetter | I went through a different route, and am trying to join again, will see if it works. | 20:53 |
Boostisbetter | I would like to go through Matrix because that would be one less chat client I would need, but honestly xmpp is pretty good as well. | 20:53 |
Allie | ACTION earperks | 22:21 |
Allie | if there are questions about how switching off portalling will affect this community, i am available to answer | 22:21 |
Boostisbetter | Just kind of interested in the solution taking its place. Will bridging still work, we just get room history from times we are not connected? | 22:25 |
Allie | portalled channels are going away completely | 22:34 |
Boostisbetter | yeah you said that before. | 22:50 |
- bluerise (QUIT: Changing host) (~bluerise@pc19f889e.dip0.t-ipconnect.de) | 22:53 | |
+ bluerise (~bluerise@user/bluerise) | 22:53 | |
+ vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 22:57 | |
josch | is anybody able to spot the error message in this linux kernel build log? | 23:28 |
josch | https://source.mnt.re/reform/reform-debian-packages/-/jobs/1472/raw | 23:29 |
- bkeys (QUIT: Remote host closed the connection) (~Thunderbi@static-198-54-130-101.cust.tzulo.com) | 23:29 | |
Boostisbetter | that would be a needle in a haystack for me. Give me a few months and that should be different. | 23:29 |
Boostisbetter | minute: here is some feedback I got from the L5 devs: Booster | 23:44 |
Boostisbetter | : the mnt reform has an eDP encoder after imx8s nwl bridge (where the L5 attaches the DSI panel). I'd look there rather than etnaviv if the display stays also black on the consoles and you don't see any hung gpu in the logs. Also switching the internal panel from mxsfb to dcss (or the other way around depending from what you use atm) could change things a lot (and might provide more data where th | 23:44 |
Boostisbetter | ings fail) | 23:44 |
Boostisbetter | the mnt reform has an eDP encoder after imx8s nwl bridge (where the L5 attaches the DSI panel). I'd look there rather than etnaviv if the display stays also black on the consoles and you don't see any hung gpu in the logs. Also switching the internal panel from mxsfb to dcss (or the other way around depending from what you use atm) could change things a lot (and might provide more data where thin | 23:45 |
Boostisbetter | gs fail) | 23:45 |
Boostisbetter | Posted it again as it seemed to clip some of the response. I do wonder if the edp encoder is the source of the issue. They claim that if it was etaniv that the issue would affect the L5 as well. | 23:45 |
+ klardotsh (~klardotsh@98.97.115.75) | 23:52 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!