| - c-keen[m] (QUIT: Ping timeout: 245 seconds) (~c-keenner@2001:470:69fc:105::2:8760) | 00:32 | |
| - rafostar[m] (QUIT: Ping timeout: 245 seconds) (~rafostarm@2001:470:69fc:105::2:52da) | 00:32 | |
| - murph[m] (QUIT: Ping timeout: 245 seconds) (~murphhope@2001:470:69fc:105::d564) | 00:32 | |
| - charuto (QUIT: Ping timeout: 245 seconds) (~charutoca@2001:470:69fc:105::43f) | 00:32 | |
| - Assassink786[m] (QUIT: Ping timeout: 240 seconds) (~assassin7@2001:470:69fc:105::2:ac85) | 00:32 | |
| - scops (QUIT: Ping timeout: 246 seconds) (~scopstchn@2001:470:69fc:105::8da) | 00:36 | |
| - aynish (QUIT: Ping timeout: 246 seconds) (~aynish@2001:470:69fc:105::1:5f74) | 00:36 | |
| - JC[m] (QUIT: Ping timeout: 246 seconds) (~jclibremo@2001:470:69fc:105::2:ce68) | 00:36 | |
| - pandora[m] (QUIT: Ping timeout: 246 seconds) (~pandorami@2001:470:69fc:105::2:b5e8) | 00:36 | |
| - amospalla[m] (QUIT: Ping timeout: 246 seconds) (~amospalla@2001:470:69fc:105::3:8000) | 00:37 | |
| - mjw (QUIT: Ping timeout: 252 seconds) (~mjw@gnu.wildebeest.org) | 01:01 | |
| - mtm (QUIT: Ping timeout: 258 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 02:04 | |
| - nsc (QUIT: Ping timeout: 252 seconds) (~nicolas@39-98-142-46.pool.kielnet.net) | 03:11 | |
| + nsc (~nicolas@66-48-142-46.pool.kielnet.net) | 03:12 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 03:59 | |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 04:10 | |
| - yewscion (QUIT: Remote host closed the connection) (~yewscion@2601:547:1480:bc60:9da:d549:1885:c96c) | 04:58 | |
| + MajorBiscuit (~MajorBisc@62-110-179.netrun.cytanet.com.cy) | 06:49 | |
| - MajorBiscuit (QUIT: Quit: WeeChat 3.6) (~MajorBisc@62-110-179.netrun.cytanet.com.cy) | 08:54 | |
| - klardotsh (QUIT: Ping timeout: 244 seconds) (~klardotsh@98.97.36.213) | 09:01 | |
| + mjw (~mjw@gnu.wildebeest.org) | 09:37 | |
| - mjw (QUIT: Ping timeout: 260 seconds) (~mjw@gnu.wildebeest.org) | 10:03 | |
| * mark_ -> mjw | 10:03 | |
| + amospalla[m] (~amospalla@2001:470:69fc:105::3:8000) | 10:12 | |
| + scops (~scopstchn@2001:470:69fc:105::8da) | 10:15 | |
| + pandora[m] (~pandorami@2001:470:69fc:105::2:b5e8) | 10:15 | |
| + JC[m] (~jclibremo@2001:470:69fc:105::2:ce68) | 10:15 | |
| + aynish (~aynish@2001:470:69fc:105::1:5f74) | 10:15 | |
| - pinoaffe (QUIT: Quit: restarting for system updates) (~pinoaffep@2a01:4f9:c010:a00b:1337:1337:11be:10) | 10:36 | |
| Zaba | From my experience, receiving UPS packages to a residential address in Finland is _horrible_ | 11:46 |
|---|---|---|
| Zaba | If they bring it straight to a pickup location that is extremely lucky | 11:47 |
| Zaba | And it's likely that they were not even planning to attempt home delivery despite what tracking says | 11:47 |
| vkoskiv | I mean, the door code and my phone # were written on the box, *and* the downstairs door is broken and doesn't latch, so they 100% could have delivered it to my door if they tried. | 11:47 |
| vkoskiv | Luckily the UPS pickup point is a very short walk away, and I had grocery shopping to do anyways. | 11:48 |
| vkoskiv | Can't blame 'em. I wouldn't be surprised to hear they just don't give delivery drivers enough time to deliver everything door to door. | 11:49 |
| Zaba | My UPS pickup location has been steadily moving farther and farther away from my home during the last few years :D | 11:50 |
| Zaba | Oh I absolutely don't blame the drivers, but I do blame UPS itself | 11:50 |
| Zaba | I've had packages get stuck in mysterious limbo with them etc | 11:51 |
| Zaba | Their phone support person once complained to me that their operations are like a black hole, even | 11:54 |
| - mtm (QUIT: Ping timeout: 246 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 12:02 | |
| + pinoaffe (~pinoaffep@2a01:4f9:c010:a00b:1337:1337:11be:10) | 12:16 | |
| - buckket (QUIT: Quit: buckket) (~buckket@vps.buckket.org) | 12:24 | |
| + buckket (~buckket@vps.buckket.org) | 12:25 | |
| - iank (QUIT: Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) (~iank@fsf/staff/iank) | 12:30 | |
| + iank (~iank@fsf/staff/iank) | 12:30 | |
| - q66 (QUIT: Server closed connection) (~q66@q66.moe) | 12:38 | |
| + q66 (~q66@q66.moe) | 12:38 | |
| + Boostisbetter (4a410829d7@irc.cheogram.com) | 12:49 | |
| - iank (QUIT: Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) (~iank@fsf/staff/iank) | 13:25 | |
| + iank (~iank@fsf/staff/iank) | 13:27 | |
| + mark_ (~mjw@gnu.wildebeest.org) | 13:28 | |
| minute | we have clarified our warranty/repair policy, what do you think? https://mntre.com/faq.html#repairs-warranty | 13:37 |
| violet | seems straightforward to me! | 13:48 |
| minute | sorry, the warranty actually had to be 2 years, we fixed it now | 13:50 |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 14:08 | |
| josch | minute: i'd have two questions about what is written there | 14:11 |
| - mark_ (QUIT: Ping timeout: 260 seconds) (~mjw@gnu.wildebeest.org) | 14:13 | |
| josch | a) "You can repair yourself, but if you do, you will lose this free warranty." -- this is a laptop that encourages you to disassemble and re-essemble it. Usually hardware manufacturers say "if you open it up, the warranty is void". I have "repaired" my reform tons of time but i guess i haven't waived my warranty or have i? Maybe clarify this as the reform is a special case. | 14:13 |
| josch | b) "We charge 100 EUR/h for it, plus component costs" -- is that 100 eur per started our or do you also charge less than that if it's only half an hour or 45 minutes? | 14:13 |
| minute | josch: dis(assembly) according to the manual is fine, it's more about if people are soldering in the laptop, or are damaging it by not adhering to safety instructions | 14:20 |
| minute | josch: so we could clarify the language here, yup | 14:23 |
| vkoskiv | Could also mention that since all the schematics are freely available, it's very possible that a local company can do a repair. | 14:31 |
| minute | vkoskiv: we actually link to a US repair company there | 14:41 |
| vkoskiv | Yeah, but more like just emphasis on the fact that this isn't just any device, no hoops required for any company to attempt repairs. | 14:44 |
| minute | we plan to do some kind of more in-depth electronics repair guide soon | 14:50 |
| vkoskiv | Yeah. I *would* presume that any Reform 2 owner seeking warranty information would know a bit about how it's different already, but you never know. | 14:51 |
| vkoskiv | But openly available Schematics an BoM are a big deal, and should be bragged about wherever possible IMO :D | 14:51 |
| minute | all three production batches of keyboard, motherboard and ls1028a have "component status: in stock" now at pcbway, which is a big relief (many orders and packages were involved) | 14:52 |
| minute | rcm4 pcbs are also being made, but we'll assemble in house | 14:52 |
| vkoskiv | Do you source parts and send to pcbway, or do they source them? | 14:53 |
| minute | both, it's a mix | 14:53 |
| minute | depending on price | 14:53 |
| minute | and availability | 14:53 |
| unixpoet | the two year warranty is per EU regulations, right? does that apply to sales outside the EU? | 16:10 |
| Boostisbetter | Not legally. In the US market a year is required. Most companies drop their 2 year warranty to 1 there, for example. | 16:16 |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20) | 16:38 | |
| josch | minute: could you put on your todo list (low prio) to at some point investigate how to properly run "mmc bootpart enable 1 1 /dev/mmcblk0boot0" on the imx8m[qp] so that i can adjust reform-flash-uboot to flash uboot in a way that does not end up with a broken uboot in case of sudden powerloss? | 17:18 |
| josch | i would do it myself but i only have a single machine here so if that one breaks during my experiments i'm screwed XD | 17:18 |
| - mtm (QUIT: Remote host closed the connection) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 17:19 | |
| minute | josch: ok, will put in backlog :D | 17:28 |
| josch | minute: i'm reading your commits in the ls1028a-dev branch. The README states that u-boot has to be loaded with an offset of 4096 bytes. This is odd as GPT entries can easily grow beyond that. Does this mean that only MBR is supported? | 19:25 |
| josch | The answer to the question is interesting because systemd provides tools to automatically grow partitions if GPT is used. | 19:25 |
| josch | Currently we are still using MBR for the reform-system-image and I'm looking for reasons why we use those instead of GPT. | 19:25 |
| minute | josch: hmm, i have no experience with GPT, always using MBR for compat. reasons | 19:30 |
| josch | i never had a practical reason for GPT as I don't own any disk with more than 2 TB | 19:31 |
| josch | it's only systemd that now tells me not to use MBR anymore... | 19:31 |
| josch | but adding MBR support to systemd-repart is an existing TODO item: https://github.com/systemd/systemd/blob/main/TODO | 19:35 |
| josch | so maybe i'd spend less time by just submitting a patch... | 19:35 |
| q66 | what compat reasons are there to use mbr | 19:36 |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 19:36 | |
| q66 | spl and u-boot are loaded regardless of partition table as they are read from raw offsets | 19:36 |
| q66 | and u-boot itself supports gpt for ages | 19:36 |
| + mark_ (~mjw@gnu.wildebeest.org) | 19:37 | |
| josch | i'm reading this: https://source.mnt.re/reform/reform-system-image/-/commit/0c6bcea2710a4ce01b7efca6ce31e2cc7d785ead | 19:37 |
| josch | does this mean that the fat partition is read from the 4MB offset regardless of the partition table? | 19:37 |
| q66 | also don't use boot scripts | 19:37 |
| josch | if yes, then using gpt should indeed be no issue | 19:37 |
| q66 | use extlinux.conf | 19:38 |
| q66 | there is no reason to use boot scripts, it only complicates things | 19:38 |
| josch | q66: yes there is | 19:38 |
| josch | q66: i'm using an extlinux.conf on my own system but while i'd like to upgrade from a boot.scr to an auto-generated extlinux.conf, this would make systems unbootable that haven't upgraded their u-boot yet | 19:39 |
| q66 | set up some kind of upgrade path | 19:40 |
| josch | vagrantc knows more about this | 19:40 |
| josch | right now in Debian, there is no automatic u-boot installer | 19:40 |
| q66 | in my distro i have set up a sort of unified infrastructure, with an extlinux.conf generator set up as a kernel hook similarly to how grub is updated, + unified scripts for flashing and updating u-boot | 19:41 |
| q66 | and then each device package just installs some metadata how the device's u-boot is set up | 19:41 |
| q66 | and the generic scripts read it | 19:41 |
| josch | i'm not saying that it's not possible and i'm also not saying that it's not desirable | 19:42 |
| josch | i'm only saying that the work to do this hasn't been done yet | 19:42 |
| josch | q66: is your distro using some distro-specific flashing mechanism or an existing project to do the job? | 19:43 |
| q66 | it's a custom mechanism, i'm not aware of anything generic already existing | 19:43 |
| q66 | the only thing that is installed per-device is something like https://github.com/chimera-linux/cports/blob/master/contrib/u-boot-imx8mq_reform2/files/flash.sh or https://github.com/chimera-linux/cports/blob/master/contrib/u-boot-pinebook-pro-rk3399/files/flash.sh | 19:43 |
| q66 | the flaser looks like https://github.com/chimera-linux/cports/blob/master/contrib/u-boot-menu/files/install-u-boot.sh | 19:44 |
| q66 | the generator looks like https://github.com/chimera-linux/cports/blob/master/contrib/u-boot-menu/files/update-u-boot.sh | 19:44 |
| q66 | a config file looks like https://github.com/chimera-linux/cports/blob/master/contrib/u-boot-menu/files/u-boot | 19:44 |
| q66 | additionally each "device package" installs three files like https://github.com/chimera-linux/cports/tree/master/contrib/base-reform-imx8mq/files | 19:45 |
| q66 | which tell the generator/flasher about specifics like which fdt to use and whatever | 19:45 |
| q66 | these are just installed in the right places | 19:45 |
| josch | q66: how do you choose whether to write to eMMC or sd-card? | 19:45 |
| q66 | the user chooses that | 19:46 |
| q66 | and whether you boot from emmc or from sdcard depends on how the hardware is set up, so i'm not sure i understand | 19:46 |
| josch | ah via U_BOOT_DEVICE i guess | 19:46 |
| q66 | well, when you riun install-u-boot, you give it the device where to flash | 19:47 |
| josch | that flash.sh is missing writing 0 to /sys/class/block/mmcblk0boot0/force_ro | 19:47 |
| josch | sounds like a cool infrastructure! now somebody has to maintain this in Debian :) | 19:47 |
| q66 | possible, i don't have a reform so i only did it based on information i could find | 19:47 |
| josch | thank you for the links! | 19:48 |
| q66 | U_BOOT_DEVICE is just a variable which stores which installed u-boot binaries to use | 19:48 |
| josch | vagrantc: do you know other distros that have something similar to what q66 showed about chimera linux above? | 19:48 |
| q66 | the actual target device is what you give it | 19:48 |
| q66 | the base reform metapackage installs a metadata file which gives it the default | 19:48 |
| q66 | https://github.com/chimera-linux/cports/blob/master/contrib/base-reform-imx8mq/files/u-boot-device it looks like that | 19:49 |
| q66 | anyway the list of u-boot-using devices i have to support is growing, which means i wanted something that could be reused as much as possible between the deviecs | 19:49 |
| q66 | so that each device package only has to provide basic pieces of metadata + u-boot binaries in a specific place | 19:49 |
| q66 | and the rest of the mechanism, including boot entries etc is shared | 19:50 |
| josch | nice! | 19:50 |
| vagrantc | q66: fwiw, the offsets for sunxi/allwinner systems conflict with GPT (at least the defaults, there may be compatible fallback offsets) | 19:51 |
| q66 | ah, they overlap with the partition table data? | 19:51 |
| q66 | what offsets do they use ? | 19:51 |
| vagrantc | ACTION rummages around for a bug report | 19:52 |
| q66 | for my image generation infrastructure i tried to genericize that too so i now have partitioning information for each device in https://github.com/chimera-linux/chimera-live/tree/master/sfdisk | 19:52 |
| q66 | so far i only have mbr for raspberry pi | 19:53 |
| q66 | but from rpi4 onwards you can also use gpt | 19:53 |
| q66 | but i have a single image for rpi3+4, so | 19:53 |
| q66 | iirc for gpt you can use any space that is lba 34 onwards | 19:54 |
| vagrantc | all i found was https://bugs.debian.org/928643 https://salsa.debian.org/debian/u-boot/-/merge_requests/6/diffs ... which does not get at the heart of the issue | 19:54 |
| + klardotsh (~klardotsh@98.97.35.74) | 19:54 | |
| vagrantc | q66: yes, it actually overwrites the GPT partition table data | 19:54 |
| vagrantc | apparently you can specially craft a limited GPT partition table that does not conflict ... but that is obviously uncommon | 19:55 |
| q66 | interesting | 19:55 |
| q66 | classic allwinner :) | 19:55 |
| q66 | vagrantc: i think you should not have to do anything special depending on the offset | 19:59 |
| q66 | the partition table will take as many lbas as needed to store all the partitions | 19:59 |
| q66 | so if you don't have a lot of partitions it will not take a lot of space | 19:59 |
| vagrantc | well, the default recommended offset would definitely break GPT partition tables, i know that for a facty | 19:59 |
| vagrantc | even with few partitions ... the limited partition table thing was some weird hand-crafted thing | 20:00 |
| q66 | https://u-boot.readthedocs.io/en/latest/board/allwinner/sunxi.html | 20:00 |
| q66 | wtf sector 16 | 20:00 |
| q66 | well you should *still* be able to work with that in a limited way | 20:00 |
| q66 | the mandatory part of gpt only takes two LBAs | 20:01 |
| q66 | each partition in a GPT takes 128 bytes | 20:02 |
| q66 | so if you have base metadata in LBA 1 (512 bytes), you have 14 additional sectors for partitions, with 4 partitions per LBA, which means up to 56 partitions which will not interfere with the firmware | 20:03 |
| q66 | that said the metadata in LBA 1 still has to be adjusted i guess | 20:09 |
| q66 | shrug :) | 20:09 |
| q66 | i'd have to experiment to see how it behaves for real | 20:09 |
| q66 | maybe if an allwinner device gets in my hands someday | 20:09 |
| q66 | but yeah unfortunate hardware design choice | 20:10 |
| q66 | that said MBR is not any less limiting, you can only have up to 4 partitions :) | 20:12 |
| q66 | hm looking at it again, you don't actually have to adjust any metadata in lba 1, so as long as you don't actually go over the partition number limit, there will be no conflict | 20:13 |
| q66 | debian only had a problem because they do their own sanity checks | 20:13 |
| q66 | which is what those changes you linked are about | 20:13 |
| q66 | but strictly speaking, things will work, unless you go over the limit, then there is a problem | 20:14 |
| q66 | >Newer SoCs (starting from the H3 from 2014, and including all ARM64 SoCs), also look at sector 256 (128KB) for the signature (after having checked the 8KB location). Installing the firmware there has the advantage of not overlapping with a GPT partition table. | 20:16 |
| q66 | so everything allwinner that is 64-bit will also take firmware at LBA 256 | 20:16 |
| q66 | which allows no GPT conflicts regardless of how many partitions you have | 20:17 |
| q66 | so meaningfully the problem only exists for some very old 32-bit SoCs | 20:17 |
| josch | vagrantc: soo.... do you have motivation and capacity to package what chimera does to automatically flash u-boot in Debian? :) | 20:26 |
| vagrantc | in a bit of a strange juxtaposition of time crunch and abundant flexible time right now ... | 20:28 |
| josch | vagrantc: i've read the patch you posted -- i don't see any problem with the printf from dash or bash with respect to null bytes. What is the coreutils requirement for? | 20:30 |
| q66 | well if y'all wanna package infrastructure like that i'm willing to make it more distro-independent and give it a separate repo | 20:31 |
| q66 | would be nice to share some stuff | 20:31 |
| q66 | but no rush :) | 20:32 |
| josch | i'd like to get rid of my reform-flash-uboot script | 20:32 |
| vagrantc | q66: don't have the time to poke at it now, but i would like to consider it at some point! :) | 20:32 |
| q66 | in longer term i'd also like to work with debian a bit on initramfs-tools | 20:32 |
| josch | every board having their own custom flashing thing sucks... | 20:32 |
| q66 | because i use a fork of initramfs-tools | 20:32 |
| vagrantc | josch: maybe if you can help nudge it towards debian and i am happy to help with it? | 20:32 |
| q66 | i'd like to explore if it could be synchronized eventually | 20:32 |
| josch | vagrantc: i'm happy to do some of the initial work | 20:32 |
| josch | q66: you have an initramfs-tools patch stack that you keep rebasing? | 20:33 |
| q66 | yeah | 20:33 |
| q66 | also console-setup | 20:33 |
| q66 | but that's far lesser scope | 20:33 |
| q66 | my current patches are not upstreamable in any way, but i'd like to look into making them upstreamable when i find some time for it | 20:34 |
| josch | q66: if you find the time to put the u-boot flashing infrastructure in a seperate repo and make a tagged release, feel free to ping me so that i can do the initial Debian packaging for it :) | 20:34 |
| q66 | alright | 20:34 |
| josch | that'd be awesome | 20:35 |
| josch | it bugs me a lot that i cannot just "apt upgrade" my u-boot... | 20:35 |
| josch | it works with grub so why not with the u-boot binary | 20:35 |
| q66 | i ended up with initramfs-tools because it felt like the only option that was reasonable/usable, dracut is hostile redhatware and mkinitcpio is bashisms galore | 20:35 |
| q66 | initramfs-tools does the least weird magic while still being powerful + it's just sh | 20:36 |
| q66 | and i can actually understand what it does, which is always a bonus | 20:36 |
| q66 | it's pretty impossible to pick apart something like dracut when it comes to the internal workings of it | 20:36 |
| josch | nice to hear! i often only hear people complain about initramfs-tools XD | 20:36 |
| josch | but the grass is always greener on the other side i guess :) | 20:37 |
| q66 | it's not any worse than any of the other systems at very least | 20:37 |
| q66 | not depending on bash is also a plus because if my initramfs generator was to depend on bash it'd be the only thing depending on bash in a full system | 20:38 |
| q66 | as it is i don't even have bash installed and i run a complete system with gnome | 20:38 |
| q66 | but yeah e.g. dissecting cryptsetup/luks stuff of other initramfs generators is quite nasty because of all the autoconfiguration magic it has which has to handle all the possible edge cases to account for all the possible layouts people encrypt their disks with | 20:40 |
| q66 | debian chose the right way to do it, just use info from crypttab | 20:40 |
| josch | Debian has tried to remove bash from the essential packages set since 2011 XD https://wiki.debian.org/Proposals/RemoveBashFromEssential | 20:40 |
| q66 | the cryptsetup scripts are still quite massive but that's just something that nothing can be done about | 20:41 |
| q66 | it's just complex like that | 20:41 |
| q66 | yeah if you have existing dependencies then things are more complicated | 20:42 |
| q66 | i try to avoid writing infrastructure in shell if possible, and in other places stick with plain posix shell | 20:42 |
| q66 | there is still bash in the repositories of course, but it's user choice to have it | 20:42 |
| q66 | i don't want it mandatory because it's impossible to harden well | 20:42 |
| q66 | its test suite will crap itself with both ubsan and cfi | 20:43 |
| q66 | and i have better things to do with my life than to dissect bash | 20:44 |
| q66 | complicated shell scripts are also an endless source of vulnerabilities by themselves | 20:44 |
| q66 | and having a less complicated shell language generally limits how bad things can get | 20:45 |
| vagrantc | josch: well, comparing u-boot to grub is not fair. it is more like comparing it to grub+UEFI or grub+bios. | 20:47 |
| q66 | more like a small subset of grub + a small subset of uefi :) | 20:47 |
| vagrantc | well, as far as the flashing it bit ... | 20:48 |
| - klardotsh (QUIT: Ping timeout: 252 seconds) (~klardotsh@98.97.35.74) | 20:49 | |
| q66 | in some ways it would be nice if all the arm boards were serverready with full uefi+acpi | 20:49 |
| q66 | use the same generic iso for everything | 20:49 |
| q66 | but oh well, too large for a lot of boards :) | 20:49 |
| q66 | and the edk2 codebase is... quite a sight | 20:49 |
| josch | vagrantc: agreed | 21:00 |
| q66 | my biggest gripe with u-boot is that it cannot reasonably be compiled with clang | 21:04 |
| q66 | because it uses this massive and awful hack called global register variables | 21:04 |
| q66 | which llvm rightfully does not implement | 21:04 |
| q66 | all for the sake of meaninglessly smaller binaries | 21:05 |
| q66 | in u-boot's case it means picking a specific register (different for each architecture) where the address of u-boot's global data structure is stored, and then the compiler is artificially prevented from using that reg | 21:07 |
| sknebel | I thought it had a fallback when compiled with clang? | 21:11 |
| sknebel | (which then just uses a global variable) | 21:11 |
| q66 | only on arm32 | 21:12 |
| q66 | which is useless for all my usecases | 21:13 |
| q66 | which is aarch64 and riscv64 | 21:13 |
| sknebel | ah | 21:14 |
| sknebel | yeah, where I saw that was an arm32 target, didnt know it was only there | 21:14 |
| - mjw (QUIT: Killed (NickServ (GHOST command used by mark_!~mjw@gnu.wildebeest.org))) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 21:22 | |
| * mark_ -> mjw | 21:22 | |
| + mark_ (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 21:22 | |
| - sevan (QUIT: Ping timeout: 246 seconds) (~sevan@user/venture37) | 22:19 | |
| - jacobk (QUIT: Ping timeout: 264 seconds) (~quassel@47-186-126-199.dlls.tx.frontiernet.net) | 22:28 | |
| + sevan (~sevan@2001:470:1f1d:1d6:5a55:caff:fe24:ed4) | 22:45 | |
| - sevan (QUIT: Changing host) (~sevan@2001:470:1f1d:1d6:5a55:caff:fe24:ed4) | 22:45 | |
| + sevan (~sevan@user/venture37) | 22:45 | |
| sevan | fooling around: might be worth benchmarking if it's runable under dosbox https://thp.itch.io/supertrace :) | 23:03 |
| - sevan (PART: !!unknown attribute: msg!!) (~sevan@user/venture37) | 23:22 | |
| + sevan (~sevan@user/venture37) | 23:23 | |
| - jjbliss (QUIT: Remote host closed the connection) (~jjbliss@1464766-static.elnsmiaa.metronetinc.net) | 23:29 | |
| + jjbliss (~jjbliss@1464766-static.elnsmiaa.metronetinc.net) | 23:33 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!