00:08:08 | *** | Saving seen data "./dancer.seen" |
00:20:26 | | Quit kadoban (*.net *.split) |
00:20:26 | | Quit edhelas (*.net *.split) |
00:20:26 | | Quit michaelni (*.net *.split) |
00:20:26 | | Quit shrizza (*.net *.split) |
00:26:48 | | Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) |
00:26:48 | | Join shrizza [0] (~shrizza@oki-180-131-209-187.jptransit.net) |
00:41:24 | | Join kadoban [0] (kadobanemp@gateway/shell/matrix.org/x-zvjltlxvjsvasrie) |
01:00 |
01:21:08 | | Quit copper (Ping timeout: 252 seconds) |
01:21:15 | | Join copper [0] (~copper@unaffiliated/copper) |
01:26:38 | | Quit ac_laptop (Ping timeout: 268 seconds) |
02:00 |
02:08:12 | *** | Saving seen data "./dancer.seen" |
02:36:25 | braewoods | speachy: i see. well it'd help if we had one... |
02:39:58 | | Join Rower- [0] (~Rower@84.17.55.53) |
02:42:18 | | Quit Rower (Ping timeout: 240 seconds) |
02:49:02 | braewoods | i suspect we're not going to be testing either mpio port |
02:54:13 | braewoods | gevaerts: you got any of the harder to find targets in your collection? mpio hd200, hd300? iriver H110 or H115? |
02:54:37 | braewoods | if you do, repairing those may be our best option for testing them |
02:54:53 | braewoods | or for that matter either of the m:robe ports, 100 or 500 |
03:00 |
03:05:10 | | Quit S|h|a|w|n (Read error: Connection reset by peer) |
03:32:44 | | Join TheSphinX_ [0] (~briehl@srv001.nosupamu.de) |
03:33:43 | | Quit TheSphinX^ (Ping timeout: 260 seconds) |
03:33:43 | | Nick TheSphinX_ is now known as TheSphinX^ (~briehl@srv001.nosupamu.de) |
03:59:04 | | Join edhelas [0] (9d94237298@2a03:4000:51:f44:4e1:2ff:fe00:4257) |
04:00 |
04:08:13 | *** | Saving seen data "./dancer.seen" |
04:10:58 | gevaerts | braewoods: I have the m:robes (assuming their batteries haven't effectively killed them). What exactly do we need tested? |
04:17:15 | braewoods | gevaerts: speachy wanted to test that our builds are working basically |
04:17:25 | braewoods | it appears someone tested the 100 already |
04:17:38 | braewoods | the 500 is having issues they say |
04:17:57 | braewoods | so we'd need a unit to find out what the issue is |
04:19:43 | gevaerts | Someone else has a working 500 still? :) |
04:20:07 | braewoods | apparently |
04:20:13 | braewoods | they are available on ebay |
04:20:15 | braewoods | but |
04:20:21 | braewoods | why do we want to pay $80 just to test this? |
04:20:37 | braewoods | especially one that doesn't appear to have many users |
04:20:57 | gevaerts | I mean, I have one here. I'll start by seeing if it still boots before thinking about testing |
04:21:03 | braewoods | ok |
04:21:09 | braewoods | you live in Europe if I recall? |
04:21:13 | gevaerts | yes |
04:21:16 | braewoods | ok... |
04:21:34 | braewoods | it'd be nice if we had someone with time in Europe to troubleshoot it |
04:21:37 | braewoods | :) |
04:21:46 | braewoods | assuming it even still works well enough to test |
04:22:11 | braewoods | but i was surprised to see how big the m:robe 500 is |
04:22:18 | braewoods | it looks like a modern tablet |
04:22:20 | gevaerts | It's a weird device |
04:23:02 | braewoods | is it touch screen only? |
04:23:26 | gevaerts | It is |
04:23:31 | braewoods | i thought so |
04:23:47 | braewoods | how'd we ever manage to support it? i thought we didn't work well with TS |
04:24:11 | gevaerts | It never got out of "unstable" |
04:24:30 | braewoods | i see |
04:24:35 | braewoods | weird in any case |
04:26:28 | braewoods | i guess speachy mainly wants to ensure no serious regressions |
04:26:36 | gevaerts | ok, the build that's on there still works |
04:26:44 | gevaerts | That's a start |
04:27:09 | braewoods | ok i'd get in touch with speachy then, since i think he's in a better position to debug it |
04:27:43 | braewoods | i just wish we could find the rare H110 or H115 |
04:27:51 | braewoods | to test the new bootloader and such |
04:27:55 | braewoods | it should work since it works in the H120+ |
04:27:57 | braewoods | but |
04:28:06 | gevaerts | Yes, those are the dangerous ones... |
04:28:18 | braewoods | the rare units? |
04:28:44 | gevaerts | Well, those flashed bootloader ones without easy recovery |
04:29:02 | braewoods | i actually found one but maybe just luck |
04:29:26 | braewoods | it only works if the OF is still present and you have an original HDD installed |
04:29:41 | braewoods | i used it to save my bacon when i was debuggin the H320 bootloader |
04:29:58 | braewoods | thank you whoever wrote the reset cookie to try to boot the OF if boot hang occurred |
04:31:49 | braewoods | gevaerts: you can update your H120s and H320s if you want. the latest bootloader has been out for awhile and works. |
04:32:04 | braewoods | it fixes CF compatibility. |
04:34:04 | gevaerts | ok, I can confirm that the current build doesn't boot on mr500 |
04:34:39 | braewoods | ok |
04:34:51 | braewoods | speachy can troubleshoot the rest |
04:35:04 | braewoods | first thing we should check is if the problem is similar to the gigabeat S one we patched |
04:35:09 | gevaerts | I'll try to bisect soon |
04:35:21 | braewoods | try from before the toolchain last year |
04:35:29 | braewoods | then if it boots check the stack usage of threads |
04:35:46 | braewoods | the gigabeat S failed to boot because of stack overflow |
04:35:54 | braewoods | may as well check it here just to be sure |
04:35:57 | braewoods | it's easy to check if you can boot |
04:35:59 | | Join vmx [0] (~vmx@ip5f5ac633.dynamic.kabel-deutschland.de) |
04:36:47 | braewoods | it's likely either a toolchain issue, lcd issue, or both |
04:39:52 | gevaerts | Oh, right... toolchains were bumped "recently", right? |
04:40:55 | braewoods | yes |
04:41:04 | braewoods | bilgus also redid LCDs which broke some stuff |
04:41:16 | braewoods | hard to say which is at fault here |
04:41:39 | braewoods | around october is when these hit |
04:41:43 | braewoods | of last year |
04:41:48 | gevaerts | I think I'll try the current revision with old gcc to start witj |
04:41:56 | braewoods | that's not advisable |
04:42:05 | braewoods | we started using new GCC features |
04:42:11 | gevaerts | I'll see :) |
04:42:20 | braewoods | i presume it'll fail |
04:42:24 | braewoods | but ok |
04:42:38 | gevaerts | I mean, it depends on where the failures are |
04:42:41 | braewoods | you can also try dialing back optimizations |
04:42:51 | braewoods | the gigabeat S worked on -O1 but not -Os |
04:43:05 | gevaerts | Well, I don't have the new gcc yet, so might as well try this first before upgrading that |
04:43:08 | braewoods | indeed it does |
04:43:17 | braewoods | i'd start from a revision before GCC bump |
04:43:22 | braewoods | just to be sure that works |
04:43:31 | braewoods | the build you had is probably really old |
04:43:57 | gevaerts | the gigabeat S fix is in a device-specific thread stack, so that fix isn't copyable |
04:44:03 | braewoods | i know |
04:44:08 | braewoods | but it could be a similar problem here |
04:44:21 | braewoods | but no way to know until you start finding out where it first broke |
04:45:16 | gevaerts | oh, right, the reset pin on this thing needs opening the case... |
04:45:36 | braewoods | ... wow that's stupid |
04:45:47 | braewoods | depending on where it was |
04:45:54 | braewoods | i might just drill a hole in the case to acces it |
04:45:56 | braewoods | X) |
04:46:55 | gevaerts | worth considering :) |
04:47:51 | braewoods | yea if i was developing fori t |
04:48:03 | braewoods | i'd consider it if the reset thing was easy to access |
04:48:17 | braewoods | might install a button just to short the pins when i need to reset |
04:49:15 | gevaerts | Or didn't it have one? Oh well, it's open, I can disconnect the battery :) |
04:51:12 | gevaerts | Yes, running 7f4c696-120226... That's not a new build exactly :) |
04:58:14 | braewoods | _bilgus: it seems like the fixes you applied boosted the H10's write speed by about 50% |
04:58:16 | braewoods | weird |
04:59:31 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
04:59:49 | braewoods | i was getting like 5MB/s |
04:59:52 | braewoods | now it's like 7.5MB |
05:00 |
05:00:05 | | Quit ccf-100 (Quit: Idle for 30+ days) |
05:57:40 | _bilgus | braewoods, thats a pretty good boost |
06:00 |
06:08:17 | *** | Saving seen data "./dancer.seen" |
06:12:23 | | Quit Acou_Bass (Ping timeout: 260 seconds) |
06:21:30 | | Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
06:32:54 | gevaerts | Looking for boot-breaking bugs does have the advantage that testing doesn't take too much time :) |
06:42:37 | speachy | gevaerts: it's the only tms320 target that even made it to the "unstable" list, with daily builds and everything. |
06:44:25 | speachy | It's debatable whether or not it's worth even trying to fix this but if not, there's a pile of other targets that are equally undeserving |
06:44:41 | gevaerts | I should have a breaking revision soon. It's definitely from before the gcc update |
06:45:21 | gevaerts | It's probably worth having a look at, but given its unstable status it shouldn't be a factor for a release decision |
06:45:59 | speachy | well, it's obviously been the first report of anyone using a build less than a year old on this thing. |
06:48:59 | speachy | all known issues so far are on unstable targets, or aren't regressions (eg the SSD issues on the ipods) |
06:49:46 | speachy | speaking of which, seems the ipod6g still has SSD issues. probably because it has its own ATA driver and also powers down the ATA hardware/interface. |
06:51:29 | gevaerts | Hmmm |
06:54:01 | gevaerts | Oh, bah. I wish we'd looked earlier... |
06:54:05 | gevaerts | I found https://www.rockbox.org/irc/log-20200512#20:03:06 again :) |
06:55:17 | gevaerts | That concludes that the new toolchain doesn't have the problem I think? |
06:56:08 | gevaerts | speachy: you may remember that better. I'm a bit confused after reading those logs |
06:56:13 | speachy | I suppose so. But I obviously completely forgot about that too |
06:56:32 | speachy | must have been from when I still had both toolchains sitting around |
06:56:59 | gevaerts | But the report is that the current build doesn't work, so it presumably broke again after that? |
06:57:22 | speachy | so that seems like some sort of linking problem |
06:58:01 | gevaerts | Well, time to upgrade toolchains then :) |
06:58:39 | speachy | the problematic commit was never reverted. |
06:59:25 | speachy | (and that also explains the provenence of that build cereal_eater was using. it's something I built for him..) |
06:59:46 | gevaerts | No, but the toolchain was upgraded, so if that fixed it the first time either something was shuffled again to break things the annoying way, or something else broke |
07:00 |
07:02:27 | * | speachy nods. |
07:03:46 | speachy | re-reading this log makes me wonder if the -1 build I supplied (new toolchain, then-git master) was actually booted up. |
07:04:49 | braewoods | it may seem weird but i build my test builds on a server with ECC RAM |
07:04:57 | braewoods | i'm a bit paranoid about consistency |
07:05:00 | braewoods | with this kind of stuff |
07:12:03 | speachy | on my systems with ECC, I average less than one detected error a year |
07:13:19 | speachy | I suspect most of our builders aren't equipped with ECC. Though 2 of my 3 are. |
07:13:25 | speachy | (and the main server) |
07:13:58 | speachy | I take that back, all 3 are; the third is unbuffered ECC. |
07:16:27 | braewoods | unlikely but i like it |
07:16:55 | braewoods | i personally don't want to chase a phantom issue that was due to a flipped bit or something |
07:18:08 | braewoods | speachy: you know what i find funny on ebay? |
07:18:26 | braewoods | people selling stuff at inflated prices and then seeing that for the most part only the modestly priced ones sell |
07:18:40 | braewoods | do they not care about holding inventory indefinitely? |
07:18:51 | * | braewoods boggles |
07:19:34 | speachy | depends on how much they paid for it. and, especially after a certian point, if you need something specific, you're going to NEED it at any price. |
07:20:54 | braewoods | i see these old Dell mp3 players |
07:20:56 | braewoods | 20GB |
07:21:07 | braewoods | probably some PP derivative |
07:23:26 | | Part edhelas |
07:23:34 | braewoods | interesting |
07:23:40 | braewoods | they still provide the OF |
07:23:43 | braewoods | let's check the firmware |
07:24:14 | | Join edhelas [0] (9d94237298@2a03:4000:51:f44:4e1:2ff:fe00:4257) |
07:27:26 | braewoods | oh |
07:27:30 | braewoods | not a set of files... |
07:27:34 | braewoods | some flash program? |
07:33:14 | braewoods | interesting |
07:33:28 | braewoods | seems someone already did research on it |
07:35:24 | braewoods | possible port here but probably not worth it at this point |
07:53:42 | gevaerts | speachy: if I revert b0de98ad and build current master it boots, so still the same issue. I have no idea why there was a working build in that debug session last year... |
07:53:56 | gevaerts | (with a fresh toolchain) |
07:54:54 | braewoods | https://www.ebay.com/itm/SmartDisk-FlashTrax-Gray-20-GB-Digital-Media-Player-Lightly-used/373279744026 |
07:54:59 | braewoods | the gba sp of mp3 players |
07:56:47 | braewoods | gevaerts: sounds like we need a port specific workaround |
07:56:55 | braewoods | since nothing else seems to be bothered by it |
07:56:55 | gevaerts | Maybe |
07:57:30 | braewoods | reminds me of when i was debugging H320 bootloader |
07:57:39 | braewoods | it was an LCD optimization that broke it |
07:58:09 | braewoods | since i'm not an expert on the port i ended up reintroducing the original code but only enabled for bootloader builds |
07:58:26 | braewoods | since i didn't know how else to fix it |
08:00 |
08:08:21 | *** | Saving seen data "./dancer.seen" |
08:08:35 | | Quit pamaury (Ping timeout: 260 seconds) |
08:09:09 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
08:14:31 | gevaerts | https://paste.debian.net/1193318/ fixes the issue for me, while still having working thumb builds (which is what b0de98ad fixed). The effect is that -lfirmware is now in the link cmdline twice |
08:14:53 | gevaerts | Of course all of this is magic, so I don't know if it breaks anything else now... |
08:15:11 | speachy | hmm, I never did like that thumb-cc hack |
08:16:13 | gevaerts | My worry isn't thumb so much as knowing that link order broke the mr500 so I'm not sure changing link order again won't break something else |
08:16:44 | speachy | as Isaid in that earlier log all of this is a canary.. the RealProblem(tm) is something else |
08:16:53 | gevaerts | Indeed |
08:17:13 | speachy | maybe some sort of symbol collision |
08:17:28 | speachy | so the ordering of linked libraries matters |
08:19:11 | braewoods | speachy: is it time to move our python scripts to 3? |
08:19:26 | braewoods | python2 is being phased out |
08:19:29 | speachy | everything in the normal build path is python3 clean |
08:19:48 | braewoods | i see |
08:19:50 | speachy | I retired server-side python2-specific stuff |
08:20:02 | braewoods | ok |
08:20:21 | braewoods | seems my H10 got scratched somehow during shipment or w/e |
08:20:25 | braewoods | weird |
08:20:31 | braewoods | i'll try buffing it out of the metal |
08:26:58 | speachy | huh, we only use that thumb script on the original clip, m200v4 and c200v2. Ie onr remaining 2mb targets. |
08:27:12 | speachy | and all it ultimately does is try compiling with and without thumb, to see which is smaller. |
08:32:14 | gevaerts | A naive search (objdump -t and then look for g or F) finds one "duplicate" symbol between libfirmware and libunwarminder, data_abort_handler, which is weak in libfirmware.a so I would expect the later one to be used anyway? |
08:33:20 | gevaerts | And I'd hope we're not hitting a data abort anyway |
08:34:24 | gevaerts | So my guess is it's something else again |
08:47:21 | _bilgus | braewoods probably more likely its time on my desk |
08:49:17 | _bilgus | I vaguely remember doing it for the clip+ as well? |
08:49:24 | _bilgus | @speachy |
08:50:41 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-d434-eae4-7f89-3e99.res6.spectrum.com) |
08:53:15 | speachy | _bilgus: hmm? |
08:59:30 | braewoods | _bilgus: it just looked like someone took a razor blade to it |
08:59:59 | braewoods | oh well, the problem is solved so small price to pay |
09:00 |
09:00:37 | braewoods | huh seems the PPs that load entirely from their drives... |
09:00:45 | braewoods | don't even need the OF the way we pack it up |
09:00:52 | braewoods | only the rom bootloader remains OF |
09:01:05 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
09:01:25 | braewoods | _bilgus: i was just thinking though, if not for the iPod using PP so heavily, i doubt we'd have any support for it |
09:01:48 | braewoods | we have no cpu datasheet |
09:02:03 | braewoods | if not for the ipods being such a big deal back in the day |
09:02:15 | braewoods | we probably would have been unable to progress with it |
09:02:50 | braewoods | we've had to make guesses about how it works just to get what we have |
09:03:06 | braewoods | which makes it hard to support some targets fully depending on how they choose to use IO pins |
09:08:53 | _bilgus | no I didn't use any metal to open it up I assume it arrived sealed with packing tape on the box and duct tape on the player bubble wrap? |
09:09:47 | braewoods | _bilgus: yea |
09:09:56 | braewoods | _bilgus: in any case, don |
09:09:59 | braewoods | don't worry about it |
09:10:03 | braewoods | i don't really know how it happened |
09:10:53 | braewoods | the issue is solved and that's what matters |
09:11:09 | braewoods | i can always buy a better one if i cared that much |
09:11:37 | _bilgus | the ipods are still a big deal for now |
09:11:51 | _bilgus | still no data sheets |
09:12:10 | braewoods | which is funny considering the PPs we care about are no longer really used |
09:12:20 | braewoods | so what does holding onto them datasheets do for them |
09:13:22 | | Join chris_s [0] (02cdf09c@dslb-002-205-240-156.002.205.pools.vodafone-ip.de) |
09:16:33 | chris_s | Maybe it's just my filter bubble, but I feel like iPods (and possibly Rockbox) are having at least a little bit of a revival. It's all relative of course. Pretty much everybody is streaming...or listening to vinyl I guess ;) |
09:17:09 | braewoods | hahaha streaming... |
09:17:14 | * | braewoods goes into a tunnel |
09:17:20 | braewoods | "Why did my audio cut out!?" |
09:17:39 | braewoods | rockbox still has a niche |
09:17:46 | braewoods | streaming isn't going to work everywhere |
09:21:05 | braewoods | plus i don't want to waste my cellular data on audio streaming given how they price it in the US |
09:21:54 | chris_s | tbf, you can download tracks using Wifi on Spotify/Apple Music for offline listening, but yeah, there's some advantages still to "owning" your music... |
09:23:19 | braewoods | same reason chrome books aren't going to replace PCs for everyone |
09:23:33 | braewoods | or similar |
09:24:30 | | Join ats_ [0] (~ats@cartman.offog.org) |
09:24:49 | | Quit atsampson (Ping timeout: 258 seconds) |
09:30:18 | braewoods | very interesting |
09:30:34 | braewoods | the iriver h100 remote also works in a CD/MP3 player hybrid |
09:30:36 | braewoods | iriver slimx |
09:47:46 | | Quit chris_s (Quit: Ping timeout (120 seconds)) |
10:00 |
10:08:23 | *** | Saving seen data "./dancer.seen" |
10:22:29 | | Quit massiveH (Quit: Leaving) |
10:39:56 | | Quit akaWolf (Read error: Connection reset by peer) |
10:40:18 | | Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) |
10:46:22 | | Nick ats_ is now known as ats (~ats@cartman.offog.org) |
10:50:16 | | Quit akaWolf (Read error: Connection reset by peer) |
10:51:02 | | Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) |
12:00 |
12:08:26 | *** | Saving seen data "./dancer.seen" |
12:09:46 | | Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) |
12:56:12 | | Join Soap [0] (~Soap@rockbox/staff/soap) |
13:00 |
13:17:01 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
13:42:18 | | Quit vmx (Quit: Leaving) |
14:00 |
14:04:35 | speachy | c |
14:06:40 | | Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) |
14:08:27 | *** | Saving seen data "./dancer.seen" |
14:19:15 | fs-bluebot | Build Server message: New build round started. Revision b6fce99046, 298 builds, 10 clients. |
14:33:03 | fs-bluebot | Build Server message: Build round completed after 828 seconds. |
14:33:05 | fs-bluebot | Build Server message: Revision b6fce99046 result: All green |
14:49:47 | | Join MrZeus__ [0] (~MrZeus@2a02:c7f:a0aa:4400:49fc:7eea:1fa3:615) |
15:00 |
15:04:30 | | Join MrZeus [0] (~MrZeus@2a02:c7f:a0aa:4400:49fc:7eea:1fa3:615) |
15:05:19 | | Quit MrZeus__ (Ping timeout: 260 seconds) |
15:05:49 | | Quit dweeber (Ping timeout: 260 seconds) |
15:07:43 | | Join dweeber [0] (~dweeber@c-73-52-129-219.hsd1.ut.comcast.net) |
15:27:29 | | Join MrZeus_ [0] (~MrZeus@194.37.96.137) |
15:27:43 | | Quit MrZeus (Ping timeout: 260 seconds) |
15:39:51 | | Join lebellium_ [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
15:40:16 | | Quit lebellium (Ping timeout: 252 seconds) |
15:58:23 | | Quit speachy (Quit: WeeChat 3.0.1) |
16:00 |
16:08:28 | *** | Saving seen data "./dancer.seen" |
17:00 |
17:43:14 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
17:55:06 | fs-bluebot | Build Server message: New build round started. Revision c0a49d9bdf, 298 builds, 10 clients. |
18:00 |
18:00:58 | | Quit lebellium_ (Quit: Leaving) |
18:06:24 | | Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) |
18:07:37 | | Quit ZincAlloy (Quit: Leaving.) |
18:08:28 | fs-bluebot | Build Server message: Build round completed after 802 seconds. |
18:08:30 | *** | Saving seen data "./dancer.seen" |
18:08:30 | fs-bluebot | Build Server message: Revision c0a49d9bdf result: All green |
18:12:52 | | Quit beencubed (Quit: Leaving) |
19:00 |
19:03:36 | | Quit MrZeus_ (Read error: Connection reset by peer) |
19:04:04 | | Join MrZeus_ [0] (~MrZeus@2a02:c7f:a0aa:4400:49fc:7eea:1fa3:615) |
19:38:33 | | Quit pamaury (Ping timeout: 240 seconds) |
19:56:13 | | Join beencubed [0] (~beencubed@209.131.238.248) |
20:00 |
20:03:32 | | Quit ac_laptop (Ping timeout: 240 seconds) |
20:08:33 | *** | Saving seen data "./dancer.seen" |
20:29:55 | | Quit paulk-leonov (Ping timeout: 252 seconds) |
20:30:41 | | Join paulk-leonov [0] (~paulk-leo@leonov.paulk.fr) |
20:36:11 | | Quit MrZeus_ (Ping timeout: 260 seconds) |
20:36:46 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
20:39:41 | | Quit paulk-leonov (Ping timeout: 240 seconds) |
20:40:59 | | Join paulk-leonov [0] (~paulk-leo@leonov.paulk.fr) |
21:00 |
21:16:41 | | Quit ac_laptop (Ping timeout: 240 seconds) |
21:23:34 | | Quit cockroach (Quit: leaving) |
22:00 |
22:08:36 | *** | Saving seen data "./dancer.seen" |
22:23:24 | | Quit Ckat (Ping timeout: 268 seconds) |
22:29:05 | | Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g) |
22:31:40 | | Join f1reflyylmao [0] (~f1refly@2a01:c23:905e:7e00:9b6c:a2fe:4a40:53af) |
22:34:21 | | Quit f1refly (Ping timeout: 260 seconds) |
22:34:21 | | Nick f1reflyylmao is now known as f1refly (~f1refly@2a01:c23:905e:7e00:9b6c:a2fe:4a40:53af) |
22:52:22 | | Join ufdm_ [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
22:52:35 | | Quit ufdm (Ping timeout: 248 seconds) |
23:00 |
23:14:44 | | Quit Saijin_Naib (Ping timeout: 258 seconds) |
23:29:04 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |