01:00 |
01:04:34 | | Quit wodz (Ping timeout: 252 seconds) |
01:04:50 | | Quit petur (Remote host closed the connection) |
01:31:01 | | Quit paulk-collins (Remote host closed the connection) |
01:33:34 | | Part ender` |
01:34:24 | | Part robertd1 |
01:44:25 | *** | Saving seen data "./dancer.seen" |
01:44:48 | | Quit ZincAlloy (Quit: Leaving.) |
02:00 |
02:13:47 | | Quit pamaury (Ping timeout: 260 seconds) |
02:30:53 | | Join khgkj [0] (252e275d@gateway/web/freenode/ip.37.46.39.93) |
02:31:35 | | Quit khgkj (Client Quit) |
02:35:53 | | Join sovereignentity [0] (~sidney--@73.106.79.116) |
02:39:45 | sovereignentity | Are there instructions on the site to uninstall rockbox |
02:43:38 | sovereignentity | ipod video |
02:55:36 | | Quit sovereignentity (Remote host closed the connection) |
02:24:25 | | Quit krnlyng (Ping timeout: 250 seconds) |
02:37:43 | | Join krnlyng [0] (~liar@178.114.88.2.wireless.dyn.drei.com) |
02:44:26 | *** | Saving seen data "./dancer.seen" |
02:55:59 | | Quit Demasis_ (Quit: Page closed) |
03:00 |
03:13:18 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
03:21:42 | | Quit __builtin (Ping timeout: 245 seconds) |
03:21:47 | | Join __builtin_ [0] (~xray@unaffiliated/franklin) |
03:57:36 | | Join JanC_ [0] (~janc@lugwv/member/JanC) |
03:58:49 | | Nick JanC is now known as Guest84922 (~janc@lugwv/member/JanC) |
03:58:49 | | Quit Guest84922 (Killed (niven.freenode.net (Nickname regained by services))) |
03:58:49 | | Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) |
04:00 |
04:37:24 | | Quit krabador (Remote host closed the connection) |
04:44:06 | | Quit michaelni (Read error: Connection reset by peer) |
04:44:29 | *** | Saving seen data "./dancer.seen" |
05:00 |
05:01:28 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
06:00 |
06:26:18 | | Quit [7] (Ping timeout: 245 seconds) |
06:26:56 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
06:44:32 | *** | Saving seen data "./dancer.seen" |
06:45:28 | | Quit Senji (Ping timeout: 245 seconds) |
06:48:36 | | Join Senji [0] (~Senji@95-43-84-247.ip.btc-net.bg) |
07:00 |
07:36:23 | duo8 | i just noticed the xduoo x3 update format is very similar to android's |
07:45:00 | dongs | can't wait to see what google does with fuscia |
07:45:08 | dongs | lunix needs to die a long painful death |
07:47:39 | duo8 | ha ha it won't |
08:00 |
08:44:35 | *** | Saving seen data "./dancer.seen" |
09:00 |
09:05:32 | | Join petur [0] (~petur@rockbox/developer/petur) |
10:00 |
10:04:53 | | Join paulk-collins [0] (~paulk@gagarine.paulk.fr) |
10:10:23 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
10:10:56 | pamaury | dongs: why do you want linux to die? what a troll |
10:24:49 | | Join wodz [0] (~wodz@89-77-223-98.dynamic.chello.pl) |
10:26:26 | dongs | pamaury: they had several decades to stop being dumb and gain vendor support. instead of making a stable API and encouraging vendors to develop drivers, they've alienated everyone, and final nail was UAPI split when they made it impossible to build most drivers out of kernel. |
10:28:07 | dongs | the other day there was a shitstorm about "lenovo blocking free/opnesores OS installation" which boiled down to the fact that lunix simply didn't fucking support some modern way of nvme/ahci passthrough |
10:28:49 | dongs | but the turds were quick to blame manufacturer, with ridiculous requests like "don't they ever test $distroX t o run with their hardware? how COULD THEY" |
10:29:30 | dongs | what sane manufacturer would want to be anywhere NEAR testing their hwardware with 1230421749823749823478923 lunix distros?! they could isntead spend time making quality hardware and drivers for an OS that 99.9999% of thier users will be using. |
10:31:16 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:c05c:afc6:d094:dc53) |
10:44:38 | *** | No seen item changed, no save performed. |
10:47:07 | | Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) |
11:00 |
11:35:31 | | Quit GeekShadow (Ping timeout: 260 seconds) |
11:56:05 | | Join GeekShadow [0] (~antoine@nzf.turmel.info) |
11:56:05 | | Quit GeekShadow (Changing host) |
11:56:05 | | Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow) |
12:00 |
12:04:04 | | Quit idonob (Ping timeout: 250 seconds) |
12:06:16 | | Join idonob [0] (~Owner@S010610c37b922980.vs.shawcable.net) |
12:27:48 | pamaury | dongs: that's a very unfair statement, you are are twisting the truth completely in my opinion |
12:29:28 | | Join robertd1 [0] (~as@201.208.225.40) |
12:29:29 | | Join robertd11 [0] (~as@201.208.225.40) |
12:30:55 | dongs | oh? |
12:31:08 | dongs | do tell |
12:32:53 | | Quit robertd1 (Remote host closed the connection) |
12:32:53 | | Quit robertd11 (Remote host closed the connection) |
12:36:04 | pamaury | well on lenovo problem, lenovo used an uncommon raid mode that is not supported by linux. Linux support ahci and supports nvme, truth is, you had never heard about this raid before I'm sure. On the stable API, just look at Windows, XP drivers mostly don't work Vista's that don't work on 7 that don't work on 10. So much for a stable API. When you don't have the source, drivers rot, that's a fact. Als oyou are confusing distribution with linux ( |
12:36:05 | pamaury | ie there this is ONE linux kernel and MANY distribution) |
12:38:27 | | Join robertd1 [0] (~as@201.208.225.40) |
12:39:14 | dongs | > Windows, XP drivers mostly don't work Vista's that don't work on 7 that don't work on 10. |
12:39:16 | pamaury | Hell your argument even applies to Rockbox: we have been dumb for a decode, couldn't gain vendor support, don't have a stable API, blalbla |
12:39:17 | dongs | holy shit waht planet are you on |
12:39:26 | dongs | drivers from 32bit win2k work all the way up to 32bit win10 |
12:39:46 | dongs | there's been changes in TWO places, both are not really relevant, that being gpu and printer drivers |
12:40:01 | dongs | but standard kernel mode pci/usb device drivers work exactly as-is with zero changes, even in binary form (and of course can be rebuilt) |
12:40:31 | dongs | lenovo thing would be a non-issue if intel simply could provide a driver |
12:40:59 | dongs | but there's a bullshit bureaucracy to get this kind of thing provided, and because its tightly coupled with ahci/nvme shit it cant be just a new driver that you load, it has to be changes to current shit |
12:41:17 | dongs | which means modifying/patching literally thousands of different bullshit kernel forks that each distor makes for themselves |
12:44:40 | *** | Saving seen data "./dancer.seen" |
12:49:34 | | Quit rogeliodh (Remote host closed the connection) |
12:49:51 | | Join rogeliodh [0] (~rogeliodh@ec2-52-90-241-120.compute-1.amazonaws.com) |
12:55:58 | pamaury | dongs: I understand you are not happy with my statement, you think it's not true. But see, that's exactly how I feel when you come in and throw random troll statement on that channel. So please so stop doing that, or throw them in other channels like #rockbox-community |
13:00 |
13:21:29 | wodz | dongs: The truth is that linux made pressure on vendors which was never seen before. It was unbelievable before that *vendor* contribute drivers and/or docs because he is interested in having support for new product on day zero. The knowledge gained is hard to evaluate. |
13:23:19 | | Quit idonob (Ping timeout: 260 seconds) |
13:25:13 | | Join idonob [0] (~Owner@S010610c37b922980.vs.shawcable.net) |
13:27:26 | | Quit petur (Quit: Leaving) |
13:27:48 | | Quit ZincAlloy (Quit: Leaving.) |
13:28:34 | pamaury | if only vendor could be better at releasing datasheets... |
13:30:02 | wodz | but still they are then 10 years ago |
13:30:26 | pamaury | at least now we have linux ports to extract code/headers from ;) |
13:31:21 | wodz | :P |
13:31:43 | pamaury | wodz: did you see that qualcomm bought nxp? |
13:32:14 | wodz | yes |
13:32:15 | pamaury | that sounds like bad news, qualcomm is has always been very open-source unfriendly |
13:32:33 | pamaury | and they don't publish datasheets |
13:32:52 | wodz | nxp also in their automotive division which is why qualcomm bought them actually |
13:37:33 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
13:45:07 | wodz | pamaury: Do you know any documentation explaining how to hack new SoC (or a board) in quemu? |
13:45:38 | pamaury | wodz: unfortunately no, some time go I had a look (I wanted to emulate some target) and it's very confusing |
13:46:03 | pamaury | there is a mix of old and new stuff, basically you ave to look at how the other soc work |
13:46:15 | wodz | yeah, I tried like 3 times to hack something in qemu and always failed |
13:49:21 | pamaury | wodz: which target do you want to emulate? |
13:50:04 | wodz | pamaury: this is not that important which. Something simple and (maybe) well documented |
13:51:06 | pamaury | it's just that if it's a target of interest, I'd be interested in helping you to learn about qemu, last time I had a look, I also failed :) |
13:53:49 | | Join einhirn [0] (~Miranda@p4FC11499.dip0.t-ipconnect.de) |
13:54:00 | wodz | In theory it could be jz SoC. This are somewhat documented, there is ancient port of qemu emulating 4740, could be usefull in X1 development BUT this are quite complicated SoCs |
13:56:31 | pamaury | ok we can do that |
13:56:51 | pamaury | altough there is something I don't quite understand about qemu: how does it handle periphals like lcd |
13:57:20 | pamaury | and input |
13:57:32 | pamaury | since those are not standard |
14:00 |
14:14:45 | pamaury | or do they have some virtual bus for that maybe? |
14:15:12 | | Join einhirn_ [0] (~Miranda@bsod.rz.tu-clausthal.de) |
14:16:41 | | Quit einhirn (Ping timeout: 256 seconds) |
14:18:50 | | Quit wodz (Ping timeout: 250 seconds) |
14:29:43 | | Join wodz [0] (~wodz@89-77-223-98.dynamic.chello.pl) |
14:44:43 | *** | Saving seen data "./dancer.seen" |
15:00 |
15:14:48 | | Quit einhirn_ (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
16:00 |
16:04:59 | | Quit krabador (Quit: Leaving) |
16:07:45 | | Quit Senji (Ping timeout: 256 seconds) |
16:44:44 | *** | Saving seen data "./dancer.seen" |
17:00 |
17:04:06 | | Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) |
17:16:38 | | Join petur [0] (~petur@rockbox/developer/petur) |
17:17:52 | rogeliodh | hi, I've started to play with the X1ii firmware and seeing that it is just a tgz with the kernel and a yaffs2 root fs, I've tried editing the root fs and repackaging it. It works. It is really easy to play with this firmware. My first modification was to run dmesg and get the output. This is my diff to its fs: rogeliodh/354de214e944e2c6faaa0e2ca74ba01a">https://gist.github.com/rogeliodh/354de214e944e2c6faaa0e2ca74ba01a and here it is the dmesg output |
17:17:52 | rogeliodh | rogeliodh/264cd5ff6cd435730364b90641e20875">https://gist.github.com/rogeliodh/264cd5ff6cd435730364b90641e20875 |
17:19:09 | wodz | now its time to ask fiio to fulfill gpl-2 :-) |
17:19:33 | rogeliodh | yep, I've emailed them two weeks ago, but no answer |
17:20:44 | wodz | :-) |
17:22:41 | rogeliodh | maybe someone from rockbox.org could contact them... |
17:23:23 | rogeliodh | I'll continue playing with the firmware. Let me know if you want me to test something |
17:29:07 | wodz | I think only asking on some big audio forum where fiio officials are present might help. |
17:33:29 | | Join ender` [0] (krneki@foo.eternallybored.org) |
17:40:41 | pamaury | rogeliodh: what would be more useful is to know whether they built drivers in out of tree modules or in the kernel |
17:43:54 | pamaury | rogeliodh: is there a firmware upgrade for the x1ii ? It's not listed here http://fiio.me/forum.php?mod=viewthread&tid=39932&extra=page%3D1 |
17:44:32 | | Join Senji [0] (~Senji@95-43-84-247.ip.btc-net.bg) |
17:59:21 | bluebrother^ | ok, current situation regarding Rockbox Utility: |
17:59:48 | bluebrother^ | Qt doesn't come with SSL (due to export restrictions as far as I understand) |
18:00 |
18:00:12 | bluebrother^ | so building Qt on Windows results in a non-ssl version unless you explicitly tell it to use openssl |
18:00:29 | bluebrother^ | I'm currently doing the latter, but there also seems to be an incompatibility with recent MinGW versions :( |
18:00:56 | bluebrother^ | apart from that, I can use mxe for building it (which works and also comes with ssl support), but that has broken accessibility. |
18:01:25 | bluebrother^ | I'm also rebuilding mxe, maybe the accessibility issue has been addressed in the meanwhile −− haven't followed development over there. |
18:20:03 | wodz | pamaury: Do you have by any chance linux-2.6.31/linux-2.6.31.3-jz-20110420-r821-add-jz4760B.patch.gz ? It was removed from ingenic ftp |
18:20:27 | pamaury | wodz: no |
18:22:38 | rogeliodh | wodz: I have it |
18:22:58 | wodz | rogeliodh: Could you upload it somewhere? |
18:23:05 | rogeliodh | yes, give me a minute |
18:27:15 | rogeliodh | rogeliodh.com/linux-2.6.31.3-jz-20110420-r821-add-jz4760B.patch.gz">http://www.rogeliodh.com/linux-2.6.31.3-jz-20110420-r821-add-jz4760B.patch.gz |
18:28:19 | rogeliodh | I found it last week in this mirror: ftp://grids.be/mirror/ftp.ingenic.cn/ (but it is not working today) |
18:35:17 | wodz | got it, thanks |
18:36:03 | rogeliodh | pamaury: yes, the firmware upgrade is at http://www.fiio.net/en/supports/41 bottom right |
18:36:57 | rogeliodh | direct link: https://www.dropbox.com/s/8x0fhctajqm0wt1/X1II-FW1.2.zip?dl=1 |
18:40:15 | pamaury | lol "Brand New X1" |
18:40:16 | pamaury | thanks |
18:41:19 | | Quit pamaury (Read error: Connection reset by peer) |
18:41:32 | duo8 | oh neat been looking for that too |
18:42:23 | duo8 | it's similar to the xduoo x3 i think, different fs however |
18:42:50 | duo8 | the shanling m1 looks very different though |
18:44:35 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
18:44:48 | *** | Saving seen data "./dancer.seen" |
18:45:25 | pamaury | duo8: the plan is to do a native port for all jz4760b though |
18:45:54 | pamaury | so even if the x1ii is linux-based, I think it's better to do a native port |
18:46:11 | duo8 | yeah i guess |
18:46:37 | duo8 | (though there's something neat about running linux) |
18:47:57 | pamaury | well linux ports often turn out to be annoying because you can't easily rebuild the kernel or modules so you are stuck with what the manufacturer installed |
18:50:00 | duo8 | i mean running your own port |
18:50:14 | duo8 | but that's not really practical unless it's mainlined |
18:51:22 | pamaury | yeah unless your push it upstream, that's lost work. And the ingenic kernel is ancient |
18:53:15 | rogeliodh | yes, but having Linux running on them could help to reverse engineer and make the port easier, right? |
18:54:51 | pamaury | well that really depends |
18:55:46 | pamaury | take the Sony NWZ for example, it's based on linux. A native port would be super hard because we miss most of the datasheets. But on the other hand, if you break anything on the device, a single wrong step, and the device is bricked and almost impossible to recover. |
18:56:37 | pamaury | And because it's based on linux, Sony installed binaries all over the place, that exchange message over unix sockets, not sure if that's really easier to reverse engineer |
18:56:55 | pamaury | it really depends on how the manufacturer installed its software |
18:57:45 | pamaury | I have already bricked my nwz twice when trying to port, I'd like to avoid revoming the emmc from the board another time ;) |
18:59:29 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
18:59:41 | pamaury | also Sony installed loads of out of tree modules that you use via undocumented ioctl, the GPL won't help you there :- |
18:59:43 | pamaury | :( |
19:00 |
19:00:09 | rogeliodh | :) yes of course it depends on the vendor... at least for the Fiio, it seems that the patch linux-2.6.31.3-jz-20110420-r821-add-jz4760B.patch.gz has most of the drivers in the Fiio X1ii |
19:00:35 | rogeliodh | looking at the patch and the dmesg output I got, messages match |
19:04:48 | pamaury | anyway, as soon as I have the booloader working on the Sony NWZ, I go back to the Fiio X1 |
19:23:09 | duo8 | pamaury maybe you can find points that connects to the emmc |
19:25:08 | pamaury | well it's kind of what I did: the emmec is on a separate board connect to the main one, if you pop it out, you can access the pin by putting small wires in the vias |
19:25:40 | pamaury | but you can't really put that without opening the player and removing the board, and even then it's not exactly a nice and simple operation |
19:27:57 | | Quit krabador (Read error: Connection reset by peer) |
19:28:51 | | Quit atsampson (Quit: new kernel time) |
19:31:18 | | Join Kruppt [0] (~Krupptus@50.111.43.108) |
19:32:44 | | Join atsampson [0] (~ats@cartman.offog.org) |
19:52:14 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:a8e5:71c9:3b39:30d6) |
20:00 |
20:06:04 | | Quit Kruppt (Quit: Leaving) |
20:44:49 | *** | Saving seen data "./dancer.seen" |
20:47:08 | pamaury | I need a suggestion: for nwz port, I need a "bootloader" that will either load rockbox or the main fw. Thing is, it's a linux userspace port and if I try to build a bootloader for a RaaA, it's fails become of the makefile wanting boot.lds (there migt be other things that break). What do you is best: not build it as a standard bootloader (ie like the dualboot stub for other targets) or fix the makefile ? |
20:47:16 | pamaury | gevaerts: wodz: ^ |
20:55:37 | cc___ | pamaury: "if only vendor could be better at releasing datasheets..." <- +++ |
20:58:51 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
21:00 |
21:02:45 | | Quit krabador (Client Quit) |
21:03:03 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
21:03:34 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
21:16:38 | | Quit krabador (Quit: Leaving) |
21:21:30 | | Join JanC_ [0] (~janc@lugwv/member/JanC) |
21:22:37 | | Quit JanC (Ping timeout: 250 seconds) |
21:22:45 | | Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) |
21:29:22 | | Quit wodz (Ping timeout: 252 seconds) |
21:30:29 | | Join wodz [0] (~wodz@89-77-223-98.dynamic.chello.pl) |
21:31:09 | * | pamaury tries to fix the makefile but this is tricky |
21:31:47 | wodz | pamaury: Is it easy to fix bootloader's makefile? |
21:32:03 | pamaury | well the thing is you don't want to use bootloader.make in this case |
21:32:21 | pamaury | hosted ports have their own makefile in firmware/target/hosted/<platform> |
21:32:28 | pamaury | which gets included in root.make |
21:32:36 | wodz | pamaury: How do we exactly build dualboot stubs? |
21:32:39 | pamaury | but only for main firmware, not bootloader |
21:33:03 | pamaury | wodz: we build them and produce a header file with the binary that gets included in the mk*boot |
21:33:24 | pamaury | I tnink fixing the makefile is a better approach in this case |
21:33:51 | wodz | Both ways are hacky |
21:34:21 | pamaury | wodz: which both ways? |
21:34:22 | wodz | Basically we never considered the need of bootloader on hosted targets |
21:34:29 | pamaury | yeah |
21:34:44 | wodz | pamaury: dualboot stub and hacking bootloader makefile |
21:35:10 | wodz | pamaury: Maybe new type of build would be in place then? |
21:35:19 | pamaury | well dualboot stub make sense, since those are not executable file, they are injected in a larger binary, so there is no way around it |
21:35:34 | pamaury | well I don't know, bootloader seems like the right place |
21:35:52 | pamaury | after all, it's a bootloader :) |
21:36:14 | pamaury | (for a proper definition of boot ;) ) |
21:37:07 | pamaury | it seems to me that the per-target makefile is a hack |
21:38:49 | wodz | program which gives a choice which other program to run is hardly bootloader. What about shell script? |
21:41:40 | pamaury | not really an option, you have to interact with the user |
21:42:33 | pamaury | you need to know if a key is pressed for example |
21:43:08 | pamaury | and it's unclear how usb is handled on this device, it might end up more work |
21:43:11 | wodz | I thought it is exposed though /proc or /sys or whatever interface is sexy today |
21:43:42 | pamaury | it uses the standard /dev/input/ stuff |
21:43:53 | pamaury | (in a non-standard way but I'll pass on that) |
21:44:13 | pamaury | actually I am not even sure if there is a way to read the key state |
21:44:31 | pamaury | I can wait for events but I haven't found a way to read the key state |
21:44:59 | pamaury | I need to study the driver more |
21:46:35 | pamaury | there is also a problem I haven't solved yet: I don't want the user to be able to browser system file, but the rockox interface will let the user do that if the whole fs is accessible |
21:47:50 | wodz | why do you want to restrict user? |
21:48:03 | pamaury | because the device is easily brickable |
21:48:37 | pamaury | and I don't want user to come on the channel and ask why their device is bricked because the deleted the kernel "by mistake" |
21:49:00 | wodz | ah, that |
21:49:29 | pamaury | I know how users are, they will try to execute random shell scripts or do crazy things |
22:00 |
22:15:07 | | Join paulk-collins_ [0] (~paulk@gagarine.paulk.fr) |
22:15:08 | pamaury | wodz: funny fact, the HOLD key is not reported as a key by Sony's driver, but as a led |
22:18:27 | | Quit paulk-collins (Ping timeout: 265 seconds) |
22:25:01 | pamaury | ah damn sony, they do everything wrong |
22:26:03 | | Quit GeekShadow (Ping timeout: 260 seconds) |
22:41:31 | | Quit lebellium (Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923]) |
22:42:21 | wodz | lol |
22:44:50 | *** | Saving seen data "./dancer.seen" |
22:54:34 | pamaury | also by using a nonstandard keycode encoding, I thing they broke the input susystem functionality of giving you the global key state |
22:57:58 | pamaury | and why on earth they change the press/released value?? Using 1 for release instead of pressed |
22:58:39 | pamaury | the global bitmap is half useful, now 1 means unpressed, and 0 pressed, except for key that don't exist, because then 0 means nothing |
23:00 |
23:00:29 | wodz | they definitely new YOU will be hacking their players and prepared a few lines of defence :-) |
23:01:43 | pamaury | well we can always read the adc value directly from the adc driver |
23:02:15 | pamaury | but that defeats the whole point and reduces portability, because we have to find the values for each player when sony driver can do all the job |
23:05:18 | pamaury | so basically the HOLD button is the only one that can reliability be read simply |
23:05:32 | pamaury | not a great button to choose between OF and RB |
23:08:54 | wodz | well we do use hold to select what to run on ipods |
23:10:48 | wodz | Damn, this ingenic patch for 4760b is *massive*. The interesting thing is that it provides separate 4760 and 4760b which may give some insight what the difference really is |
23:24:34 | | Quit petur (Remote host closed the connection) |
23:29:50 | pamaury | indeed |
23:32:43 | | Part robertd1 |
23:37:00 | | Quit wodz (Quit: Leaving) |
23:48:58 | | Nick vifino- is now known as oniifiv (~vifino@tty.sh) |
23:54:21 | | Quit ender` (Quit: If I burst into rebel headquarters and find it deserted except for an odd, blinking device, I will not walk up and investigate; I'll run like hell. — Evil Overlord List #159) |
23:58:22 | | Quit cc___ (Ping timeout: 245 seconds) |