| amospalla | minute: I see, thank you :) | 00:02 |
|---|---|---|
| - sevan (QUIT: Changing host) (~sevan@2001:470:1f1d:1d6:5a55:caff:fe24:ed4) | 00:07 | |
| + sevan (~sevan@user/venture37) | 00:07 | |
| - mjw (QUIT: Ping timeout: 252 seconds) (~mjw@gnu.wildebeest.org) | 00:32 | |
| + reform16771 (~nano@71.212.136.219) | 01:24 | |
| * reform16771 -> nanocodebug2 | 01:24 | |
| nanocodebug2 | minute: the current keyboard drops the f12 key - it eats it for the wakeup command, i put a pr out for a patch that lets the f12 key reach the SoM | 01:24 |
| - jacobk (QUIT: Ping timeout: 260 seconds) (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 01:41 | |
| + jacobk (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 01:50 | |
| + staticbunny (~staticbun@76-223-253-78.lightspeed.frokca.sbcglobal.net) | 01:56 | |
| - mtm (QUIT: Ping timeout: 246 seconds) (~textual@c-71-228-84-213.hsd1.fl.comcast.net) | 02:04 | |
| - staticbunny (QUIT: Ping timeout: 248 seconds) (~staticbun@76-223-253-78.lightspeed.frokca.sbcglobal.net) | 02:04 | |
| + staticbunny (~staticbun@76-223-253-78.lightspeed.frokca.sbcglobal.net) | 02:04 | |
| + mtm (~textual@c-71-228-84-213.hsd1.fl.comcast.net) | 02:05 | |
| - nanocodebug2 (QUIT: Remote host closed the connection) (~nano@71.212.136.219) | 02:32 | |
| - paperManu (QUIT: Ping timeout: 252 seconds) (~paperManu@198.16.214.40) | 02:55 | |
| + murphnj (~murph@user/murphnj) | 03:05 | |
| - nsc (QUIT: Ping timeout: 260 seconds) (~nicolas@28-96-142-46.pool.kielnet.net) | 03:12 | |
| + nsc (~nicolas@i5C74DCB5.versanet.de) | 03:13 | |
| jfred | How does the Pocket Reform scale up the TTY text? I seem to have somehow made mine scale up the text and then scale it back down again later during the boot process | 03:31 |
| jfred | (my cursor in sway is also small and I wonder if that's related; I think I've pulled in all of the theme-related changes from the pocket's default sway config into mine...) | 03:32 |
| staticbunny | minute: are the dotfiles from your pocket screenshots on the website available? | 03:57 |
| - staticbunny (QUIT: Ping timeout: 260 seconds) (~staticbun@76-223-253-78.lightspeed.frokca.sbcglobal.net) | 04:53 | |
| ^alex | jfred, it loads a larger font during boot | 04:59 |
| * robin -> lispwitch | 05:52 | |
| * lispwitch -> robin | 05:52 | |
| - _justin_kelly (QUIT: Quit: The Lounge - https://thelounge.chat) (~justinkel@user/justin-kelly/x-6011154) | 08:18 | |
| + _justin_kelly (~justinkel@user/justin-kelly/x-6011154) | 08:20 | |
| _hramrach | jfred: the tty text is 'scaled' by loading a big font AFAIK. if that gets unloaded again that sounds like a bug | 08:45 |
| _hramrach | sway seems to use some scaling factor, running waybar in terminal gives you the dimensions of the bar, and it shows dimensions that are half the screen size | 08:46 |
| _hramrach | regarding the automated fwupdate thing and how to accomodate custom firmware: this is Debian so it has debconf. Can ask the user which firmware to upgrade, and can be reconfigured later in a standardized way | 08:50 |
| minute | super interesting walkthrough of how hibernate works in the kernel https://tookmund.com/2024/09/hibernation-preparation | 08:52 |
| _hramrach | I am not sure I want to know that. hibernation in Linux can't be a nice thing, it's not built to support it | 08:56 |
| vkoskiv | I love articles like this! | 08:59 |
| vkoskiv | I've been messing around with ELKS, which is a 16-bit no-MMU fork of (early) Linux for 8086 machines. | 09:01 |
| vkoskiv | I wrote a new console driver that supports two monitors simultaneously, so I can have two consoles up on my IBM 5150 | 09:01 |
| vkoskiv | It relies on the fact that old IBM MDA and CGA adapters were designed such that their resources don't conflict. | 09:02 |
| minute | _hramrach: so far everything looked sensible. but it's only part 1 | 09:05 |
| minute | vkoskiv: nice | 09:05 |
| + mjw (~mjw@gnu.wildebeest.org) | 09:34 | |
| _hramrach | pro tip: if you use hibernation use whatever feature your package manager has to hold the kenrel on the current version, and never upgrade it. Your system won't wake from hibernation otherwise. | 09:40 |
| josch | _hramrach: what kernel version would that be? | 09:43 |
| [tj] | I'm pretty sure the hibernation logic hashes the kernel version and attached devices and fails a resume if they change | 09:44 |
| [tj] | so that sounds like it would be a bug | 09:44 |
| vkoskiv | Fun file to cat on x86 linux: /proc/driver/nvram | 09:50 |
| vkoskiv | My Z170 motherboard reports the selected graphics adapter as CGA, 40 column mode | 09:50 |
| gsora | "FPU : not installed" < oh no! | 09:51 |
| _hramrach | and if you upgrade the kernel either the logic manages to detect it and the resum fails, or you manage to defeat the logic and corrupt the kernel internal data structures | 10:00 |
| josch | ah i got tripped up by you saying "and never upgrade it" -- you mean, do not upgrade it if you plan to hibernate later or reboot after upgrading | 10:05 |
| [tj] | hibernate is just a fancy boot, so you need to make sure the default kernel doesn't change on hibernate otherwise it will fail | 10:09 |
| _hramrach | Also the 'flush filesystems to disk' is a lie. It does not really do that. If you use os-prober it will coppupt the filesystems of other hibernated OSes by mounting them 'readonly'. Linux cannot mount a linux-native filesystem on a readonly medium. It always replays the journal (which is not flushed in that flush step), and that requires write access, and modifies the filesystem. | 10:17 |
| - jacobk (QUIT: Ping timeout: 248 seconds) (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 11:04 | |
| + jacobk (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 11:04 | |
| josch | minute: you just merged https://source.mnt.re/reform/reform-system-image/-/merge_requests/109 -- if you have a bit of time for that topic, could you please also have a look at https://source.mnt.re/reform/reform-system-image/-/issues/27 and say nay or yay for the tools listed there? | 11:50 |
| josch | zstd was one of them :) | 11:50 |
| minute | ohhh | 11:57 |
| minute | josch: commented! | 12:05 |
| josch | thank you! | 12:07 |
| josch | ch: what do you mean? mdns-scan and blktool have the same version since old-old-stable and no bugs -- the software is not abandoned, it is just finished! :) | 12:08 |
| ch | josch: ... | 12:08 |
| ch | josch: you probably had usecases in mind for these bits. my feeling is we could pick sth better, if the usecases are known :) | 12:09 |
| josch | _hramrach: i read your comment i'm include to include all of them except for mdns-scan and blktool. Your comment is valid but the tools only require very little extra space, so i think it's okay to include them if it makes debugging issues for some people used to these tools easier. | 12:10 |
| ch | example: i install avahi on my machines, because i want .local to work on them. but i'm also guessing this may not be part of the design goal for the image | 12:11 |
| ch | (and recently i started replacing avahi by resolved) | 12:11 |
| josch | yes, hence i don't feel bad not including mdns-scan | 12:12 |
| josch | but as _hramrach noted, picotool should probably be shipped on the image for firmware flashing purposes | 12:13 |
| _hramrach | josch: sure, having some basic tools is useful when something breaks. eg. if you need to recover from bad firmware version it's useful to only need the firmware zip file, and not also the tools to make use of it. fdisk falls intosimilar space. Others might be optional, and easy ton install if needed. | 12:13 |
| josch | "the firmware zip file" -- you mean the one that was published for the pocket? | 12:14 |
| ch | picotool sure | 12:14 |
| _hramrach | I expect anything publieshed from the gtlab CI would be a zip file | 12:14 |
| amospalla | josch: are latest kernel versions available on Debian stable? | 12:15 |
| josch | amospalla: yes, via backports | 12:16 |
| amospalla | Nice, I guess, that is the most important software to have latest updates right? | 12:16 |
| amospalla | Thank you josch. | 12:17 |
| _hramrach | on a reform you would need a reform kernel, anyway | 12:18 |
| - mjw (QUIT: Ping timeout: 246 seconds) (~mjw@gnu.wildebeest.org) | 12:18 | |
| josch | yes, unless you are using imx8mq or ls1028a for which i heard vanilla linux is sufficient | 12:18 |
| _hramrach | josch: the thing that really looks random on that list is xz-utils. In what situation would you need that and could not install it? | 12:22 |
| josch | amospalla: in the past, a lot more packages from testing/unstable were needed to have things working like ffmpeg, mesa, xorg (for xwayland) or gstreamer -- these days, bookworm ships most of it (except flash-kernel) | 12:22 |
| _hramrach | progress \o/ | 12:23 |
| ch | minute: could you also merge https://source.mnt.re/reform/pocket-reform/-/merge_requests/9 ? thanks :) | 12:23 |
| josch | _hramrach: i must admit, xz-utils is my own addition and i totally forgot what exactly it was for when i had need for it in the system image. | 12:25 |
| josch | i usually boot them up on my (big) reform to test new things and i did $something that needed unxz | 12:25 |
| minute | ch: thank you, merged! | 12:28 |
| ch | thanks! | 12:28 |
| ch | sigh, fails | 12:30 |
| * Guest888 -> mjw | 12:31 | |
| _hramrach | if xz-utils makes testing new images easier, whatever ¯\_(ツ)_/¯ | 12:32 |
| _hramrach | that said, it's probably still useful to make a separete commit for it with separate reasoning so that it can be dropped when the reason is no longer valid | 12:33 |
| ch | minute: would you agree to switching pico-sdk,extras and tinyusb to git submodules instead of having shell and ci scripts picking different versions? :) | 12:34 |
| ch | minute: (if yes, i'll make an MR for that) | 12:34 |
| _hramrach | eg. the unzip tool is critical while updates are published from gitlab CI but would become nearly useless if that's changed | 12:34 |
| josch | ch: or... apt install them? :) | 12:35 |
| ch | josch: that's what i really want to avoid | 12:35 |
| josch | why? | 12:35 |
| ch | josch: firmware builds want more control over their deps, not less | 12:35 |
| _hramrach | ch: git submodules still need shell script to explicitly check out, not much improvvement, and uses obscure, error-prone and broken-by-design git feature | 12:36 |
| ch | _hramrach: gitlab ci can deal with submodules just fine | 12:36 |
| ch | _hramrach: right now we have a shell script that does thing A and a gitlab ci script that does thing B | 12:36 |
| ch | _hramrach: and the pico-sdk -already- uses submodules | 12:36 |
| josch | ch: my goal is to get these firmware bits into debian -- for that to happen it would be useful to have long-term testing of building them with stuff that is in debian | 12:36 |
| ch | so its not like we avoid submodules | 12:36 |
| josch | ch: or in other words: minimize the diff between what source.mntre.com CI does and what gets shipped in debian | 12:38 |
| ch | josch: interesting, but i have no idea how what the bugfix/breakage policy is for the involved parts and/or how to do automated qa on the results | 12:38 |
| ch | josch: and i'm not keen on the idea of 'debian bumped lib X' resulting in 'building the keyboard firmware still works but the result is silently broken' | 12:39 |
| ch | but thats just me | 12:39 |
| minute | ch: yes, would agree, the only issue when i tried that last time picosdk was missing usb support or sth and then the system controller could not be flashed again because it didn't expose the bootloader. so this has to be made sure to work | 12:39 |
| _hramrach | he general idea is that 'lib X' API should be stable enough that this would not happen. If that is feasible in specific cases is another qestion. | 12:40 |
| ch | _hramrach: "hahahaha" | 12:40 |
| ch | minute: i see. i'll make an mr now to fix the build (sorry, but hard to test without a ci runner) and then look into submodules for a later mr | 12:40 |
| josch | _hramrach: pico-sdk and picotool got updated to version 2.0 -- i have been working for about 2 weeks on getting them built and updated but a lot of things changed so this can take a while... | 12:41 |
| josch | (in my free-time, so not 2 work-weeks) | 12:41 |
| _hramrach | so it sounds like sticking to a specific version is preferable | 12:42 |
| josch | yes, unfortunately, like we saw with binutils recently, even sticking to the same version is dangerous | 12:43 |
| josch | in binutils case, recompiling src:linux made the resulting kernel unbootable | 12:43 |
| josch | the source stayed the same but binutils changed | 12:43 |
| josch | we learn from this: never update anything :) | 12:43 |
| ch | "not wrong" x) | 12:44 |
| josch | this is why i'm still running bookworm | 12:45 |
| josch | but then, to find bugs, somebody needs to run the buggy version, unfortunately... :/ | 12:45 |
| josch | ch: i agree with the "avoid surprise updates" reasoning but can we then agree that it would be best if we could build the firmware in debian-stable and to do that we should continue building it with unstable so that we find bugs and make sure that this definitely works once trixie is released? | 12:46 |
| josch | once trixie is released, we switch the CI to use that and get reliable firmware builds without surprises | 12:47 |
| ch | josch: unsure what that means for post-trixie | 12:47 |
| + paperManu (~paperManu@198.16.214.40) | 12:49 | |
| josch | ch: i think that's for minute to decide whether they want to ship stuff built with unstable and the "built with random version X problem" or built with stable and thus no clue whether things will still work with stable+1 | 12:49 |
| ch | yeah | 12:50 |
| josch | either way it's a trade-off | 12:50 |
| ch | i know what my choice would be if it were my logo on the hardware (: | 12:50 |
| josch | ch: join me on reform.d.n where we can make different choices than MNT does :) | 12:51 |
| ch | tinyusb helpfully has no branches and only very old tags | 12:51 |
| ch | josch: unsure about the firmware pieces for that. but if thats a goal, maybe it should also influence how the fw describes itself | 12:53 |
| ch | josch: so that not just it will have a flag for 'this is a custom build for this specific user' but actually some form of vendor tag | 12:53 |
| ch | (sounds like a lot of work tho) | 12:54 |
| josch | yuuuuuup | 12:54 |
| ch | (but without it we'll be in hell) | 12:54 |
| ch | minute: https://source.mnt.re/reform/pocket-reform/-/merge_requests/11 (sorry again) | 13:10 |
| ryukazou | How’s the battery life on classic reform or pocket reform? | 13:14 |
| josch | ryukazou: with a311d i have 5 hours of doing work on the terminal and 4 hours of watching a video in full screen on youtube via firefox | 13:16 |
| josch | ryukazou: that's with the big reform | 13:16 |
| minute | ch: maybe for tinyusb we should specifiy some tag/branch to clone? | 13:29 |
| ch | minute: tinyusb's last tag is from 2023, and there are no release branches | 13:30 |
| ch | minute: i'll investigate later if we can reuse the tinyusb that pico-sdk pulls in | 13:31 |
| minute | ch: ohh ok | 13:32 |
| ch | minute: but yeah, i was also worried about that :-/ | 13:32 |
| - ptrc (QUIT: Remote host closed the connection) (~ptrc@ptrc.gay) | 13:46 | |
| + ptrc (~ptrc@ptrc.gay) | 13:46 | |
| - mtm (QUIT: Ping timeout: 245 seconds) (~textual@c-71-228-84-213.hsd1.fl.comcast.net) | 14:02 | |
| ryukazou | josch: sorry, I forgot to mention battery specify for rk3588. I’m curious whether battery life of rk3588 on pocket reform would be too short. | 14:02 |
| josch | ryukazou: nobody outside of MNT has an rk3588 yet | 14:02 |
| - NanoCodeBug (QUIT: Ping timeout: 248 seconds) (~NanoCodeB@c-73-35-191-67.hsd1.wa.comcast.net) | 14:03 | |
| + NanoCodeBug (~NanoCodeB@c-73-35-191-67.hsd1.wa.comcast.net) | 14:03 | |
| + mtm (~textual@c-71-228-84-213.hsd1.fl.comcast.net) | 14:06 | |
| ryukazou | josch: understood. Thank you. | 14:14 |
| - natalie- (QUIT: Quit: quit) (~natalie@user/natalie) | 15:20 | |
| + natalie (~natalie@user/natalie) | 15:20 | |
| + mark_ (~mjw@gnu.wildebeest.org) | 15:59 | |
| minute | pocket rj45 dongle! https://mastodon.social/@mntmn/113107929644728183 | 16:01 |
| ch | doh. i ordered a micro-hdmi to mini-hdmi cable! how useless | 16:17 |
| ch | minute: nice | 16:18 |
| - mesaoptimizer (QUIT: Quit: mesaoptimizer) (~mesaoptim@user/PapuaHardyNet) | 16:19 | |
| + mesaoptimizer (~mesaoptim@user/PapuaHardyNet) | 16:19 | |
| - NanoCodeBug (QUIT: Remote host closed the connection) (~NanoCodeB@c-73-35-191-67.hsd1.wa.comcast.net) | 16:38 | |
| + NanoCodeBug (~NanoCodeB@c-73-35-191-67.hsd1.wa.comcast.net) | 16:38 | |
| NanoCodeBug | yessss that rj45 dongle looks great | 16:39 |
| minute | it is definitely rugged | 16:41 |
| _hramrach | that looks good, did not find one that can plug directly into a RJ45 cable | 16:58 |
| jfred | ch: hahah, oh no | 17:00 |
| minute | https://mntre.com/media/reform_md/2024-09-09-introducing-mnt-reform-next.html | 17:37 |
| jn | \o/ | 17:38 |
| - mark_ (QUIT: Ping timeout: 246 seconds) (~mjw@gnu.wildebeest.org) | 17:40 | |
| ^alex | minute, oh yay | 17:43 |
| jfred | woohoo! | 17:52 |
| jfred | multi-chemistry battery charging system, interesting - I'll probably still use LiFePO4 cells because I appreciate their lack of spiciness and lack of cobalt, but useful option | 17:54 |
| jfred | minute: Will we be able to order it without a CPU module installed? I already have the rk3588 module preordered for my current Reform but would probably swap it over to the Next and switch back to the a311d in my Reform 2 if so | 17:57 |
| jfred | but I don't really need two rk3588 modules, haha | 17:58 |
| minute | jfred: good point | 17:59 |
| + gustav28 (~gustav@c-2337524e.019-141-67626730.bbcust.telenor.se) | 18:32 | |
| NanoCodeBug | very cool, love how modular the boards are, lets people get creative with custom peripherals | 18:33 |
| grimmware | I’d be interested in just a pocket mobo at some point so I can use my imx8mp as a desktop. | 18:39 |
| minute | grimmware: yeah, hoping to have all that (cases for reform+pocket mobos) sorted out soon | 18:50 |
| josch | "MNT Research opposes this hypercapitalist and destructive concept in any way possible" | 18:54 |
| josch | that's why i'm here +1 | 18:54 |
| - digitalrayne (QUIT: Ping timeout: 252 seconds) (~digitalra@vps-446f4f39.vps.ovh.ca) | 18:55 | |
| minute | :D | 18:59 |
| + mark_ (~mjw@gnu.wildebeest.org) | 19:02 | |
| minute | lmao coincidentally (i swear) there's also apple keynote today | 19:02 |
| jn | Apple Silicon CPU module for Reform? ;) | 19:04 |
| + staticbunny (~textual@76-223-253-78.lightspeed.frokca.sbcglobal.net) | 19:08 | |
| jfred | imagine Apple doing that. they would never, but it would be very cool haha | 19:20 |
| ryukazou | Will reform next have purchase option without cpu module? | 19:24 |
| ryukazou | I plan to purchase reform next to my dad, I can put imx8mp to reform next.(since I already ordered rk3588 cpu module) | 19:25 |
| - amospalla (QUIT: Quit: WeeChat 4.4.1) (~jordi@user/amospalla) | 19:26 | |
| jn | jfred: apple wouldn't, but some highly skilled hobbyists? maybe | 19:29 |
| ryukazou | Does de-solder a cpu from laptop mainboard even possible? If yes, it would be great. | 19:35 |
| jfred | jn: perhaps - that would be quite a hack though haha | 19:35 |
| jfred | honestly I feel like the Reform's module system is a pretty good way to retain some modularity despite having an integrated CPU/GPU/RAM/etc as Apple does | 19:36 |
| jn | yea | 19:37 |
| jfred | (but it makes the machine thicker and we can't have that :P) | 19:37 |
| jn | if i had infinite money, i'd try to put some obscure SoCs on Reform modules | 19:37 |
| jfred | not that I actually want this (the Reform Next is plenty thin enough and the mechanical switches in a laptop are glorious) but I do wonder if it'd be possible to shave off a little extra headroom with scissor keyswitches or if the CPU module is the constraining factor there now | 19:38 |
| jfred | as in, if someone like Apple were to make a Reform enclosure aiming for more thinness, how low could you go? | 19:40 |
| ch | it looked like the batteries define most of the height? | 19:40 |
| ryukazou | Yeah reform next still use LiFePO4 cell | 19:41 |
| ryukazou | It’s nice but thickness is a trade off | 19:41 |
| jfred | yeah, you could go with pouch cells to slim down the sides there - but looking at the photos the mobo + CPU module seem to be almost as tall | 19:42 |
| ch | josch: you don't happen to know a convenient "file format" to describe Debian dependencies, thats not a d/control? | 19:44 |
| ch | josch: ie something i can put into git, that both .gitlab-ci.yml and install-deps.sh could read? | 19:44 |
| ch | josch: short of DEPS="..." in a .sh file | 19:44 |
| ch | well maybe i'll just do that | 19:46 |
| + amospalla (~jordi@user/amospalla) | 19:49 | |
| josch | ch: you want just a list of package names or you want a list of dependencies (which includes virtual packages, version restrictions etc) | 20:23 |
| ch | josch: right now just a list suffices | 20:24 |
| josch | ch: for another project i use text files that i feed to equivs | 20:25 |
| josch | advantage being, that i can express arbitrary dependency constraints and then apt takes care of resolving them for me | 20:25 |
| josch | and due to equivs that works even for apt versions that do not have the satisfy subcommand | 20:25 |
| ch | tinyusb is many things, but not tin | 20:35 |
| ch | y | 20:35 |
| josch | ch: if you want to have some fun, look at its Files-Excluded list: https://sources.debian.org/src/tinyusb/0.16.0%2Bdfsg-3/debian/copyright/ | 20:38 |
| josch | which is, in my opinion, another reason to not git clone upstream | 20:38 |
| josch | by using the stuff that is packaged in debian, you get more assurance that what you build is indeed free and not contains tons of non-free-ness | 20:38 |
| josch | in case of tinyusb this has everything from "auto-generated and no sources", "auto-generated using proprietary tool", "license non-free because disallows distribution" to "license non-free because restricts usage to products of company X" | 20:39 |
| + digitalrayne (~digitalra@vps-446f4f39.vps.ovh.ca) | 21:31 | |
| - gustav28 (QUIT: Quit: Quit) (~gustav@c-2337524e.019-141-67626730.bbcust.telenor.se) | 22:15 | |
| - jacobk (QUIT: Ping timeout: 248 seconds) (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 22:37 | |
| henesy | is the reform next a trackpad only or is it compatible with the trackball modules? | 23:07 |
| henesy | jfred-linode: i imagine achieving more thinness also hurts amateur maintainability, inevitably resulting in less modular components, more soldering, and a lower pool of parts that can possibly go into a given unit | 23:08 |
| henesy | i quite enjoy a bit of thickness in a laptop, reassures me that it wont suffer damage from pressures in a pack or otherwise if for no other reason | 23:09 |
| josch | henesy: the reform-next is too thin for the trackball | 23:09 |
| henesy | sad | 23:09 |
| bluerise | minute: happy that's it's brcmfmac! | 23:10 |
| josch | henesy: in the classic reform, the trackball module touches the bottom plate | 23:10 |
| josch | henesy: the classic reform can not be thinner literally because of the trackball | 23:10 |
| henesy | my x1 carbon would develop warping and pixel dead spots from pressures in a backpack - which while never irreparable, are inconvenient and tedious to deal with | 23:10 |
| henesy | josch: gotcha | 23:10 |
| josch | henesy: with a trackball you have another problem -- i have a veeeery slight gray spot on my screen from where the trackball touches it when the lid is closed :) | 23:12 |
| josch | barely visible -- i have to have my screen all white and then look very hard at the position where the spot should be | 23:12 |
| henesy | ah but the joy of trackball | 23:12 |
| henesy | wheeeeeeeeeeee | 23:12 |
| josch | yes | 23:12 |
| henesy | i think i also noticed The Spot | 23:12 |
| josch | i like the form factor of the classic reform and i find it an interesting project of trying to fit the reform-next components into the classic reform to combine the advantages of both :) | 23:15 |
| ch | picotool seems to hide the reboot-into-bootsel mode behind a vid/pid check, and the pid specifically must be the stdio_usb pid. that seems not very reusable :( | 23:19 |
| josch | ch: maybe report it as a bug? i found picotool upstream very quick to respond to everything i threw at them | 23:20 |
| ch | josch: on github or elsewhere? | 23:21 |
| amospalla | ch: did I talk with you about wifi on pocket/debian/stable ? | 23:21 |
| ch | amospalla: yes | 23:21 |
| amospalla | this is what you need for wireless to work: https://community.mnt.re/t/debian-bookworm-stable/2529/2 | 23:21 |
| josch | ch: i'd say on their github at https://github.com/raspberrypi/picotool/issues/new | 23:21 |
| ch | amospalla: yeah i took josch's bins from salsa. https://salsa.debian.org/reform-team/reform-debian-packages/-/issues/2 etc | 23:22 |
| amospalla | good! | 23:22 |
| josch | oh no... | 23:23 |
| josch | ch: sorry, apparently i forgot to manually turn on notifications for those repos and never got an email notification about them... | 23:23 |
| ch | oh | 23:25 |
| ch | well i didn't submit any patches yet anyway | 23:26 |
| ch | apart from the system-image changes, but that got merged via sources.mnt.re | 23:26 |
| josch | that's the best way :) | 23:27 |
| - NanoCodeBug (QUIT: Remote host closed the connection) (~NanoCodeB@c-73-35-191-67.hsd1.wa.comcast.net) | 23:33 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!