| sicelo | Wizzup: n900 bq27200 charge_full is always 2050560 when no calibration has taken place. this value will also be charge_now if battery reaches 100% full. it only starts becoming 'sane' once you have a full, uninterrupted discharge | 06:33 |
|---|---|---|
| sicelo | tldr; don't mind charge_* until you have calibrated | 06:33 |
| freemangordon | tmlind: is it acceptable to have sysfs attribute in cpcap_adc driver that controls single vs multi channels? otherwise I would have to have 8 more channels dedicated to single-channel ADC | 07:58 |
| freemangordon | IOW: when buffer support is implemented, one should enable the channels she would like to read. Having 4x2 single-channel read means 8 additional channels. | 08:00 |
| freemangordon | Unless I a missing something | 08:00 |
| tmlind | freemangordon: hmm yeah i don't know, best to ask the iio folks.. maybe IIO_CHAN_INFO_AVERAGE_RAW could be used? | 08:16 |
| freemangordon | ok | 08:16 |
| freemangordon | tmlind: https://pastebin.com/X1jFb5g7 | 09:55 |
| freemangordon | what is the current status of the driver? like, you said you will push changes upstream, but I didn;t follow | 09:56 |
| freemangordon | tmlind: do we really need to expose raw adc values to sysfs? | 11:08 |
| Wizzup | sicelo: ok, but I am not sure if my n900 is charging anymore even with empty battery | 12:13 |
| Wizzup | and the usb cable is fine | 12:13 |
| Wizzup | so something is off | 12:13 |
| Wizzup | I am wondering if it is maybe the module blacklist we did for pm | 12:13 |
| freemangordon | which module? | 12:16 |
| Wizzup | freemangordon: https://github.com/maemo-leste/leste-config/commit/f0de824b14ccf9070efae90d6dcb97b097ecb325 | 12:21 |
| freemangordon | ix isp1704 module loaded? | 12:24 |
| freemangordon | *is | 12:24 |
| Wizzup | yes | 12:26 |
| Wizzup | # ls /sys/class/power_supply/ | 12:26 |
| Wizzup | bq24150a-0 bq27000-battery bq27200-0isp1704 twl4030_ac twl4030_usb | 12:26 |
| Wizzup | but upower doesn't 'detect' charging | 12:26 |
| Wizzup | and the led doesn't pulsate orange | 12:26 |
| Wizzup | it seems to be charging, but the led doesn't show it, neither does status applet | 12:27 |
| Wizzup | it's kind of weird | 12:27 |
| Wizzup | # cat capacity | 12:27 |
| Wizzup | 8 | 12:27 |
| Wizzup | better than 1, I guess | 12:27 |
| freemangordon | sorry, no idea | 12:27 |
| freemangordon | better ask Pali or joerg | 12:27 |
| joerg | hm? | 12:27 |
| Wizzup | I think I might try to unblacklist a few modules first | 12:28 |
| Wizzup | and see if it's related at all | 12:28 |
| freemangordon | ok | 12:28 |
| freemangordon | joerg: something weird on n900, see backscroll if you have some spare time | 12:28 |
| joerg | please provide a anchor quote | 12:28 |
| freemangordon | " sicelo: ok, but I am not sure if my n900 is charging anymore even with empty battery" | 12:29 |
| Wizzup | it is charging now, I can see it, but it's a bit weird | 12:30 |
| freemangordon | ok | 12:30 |
| Wizzup | I'll have to check upower and our status applet code | 12:30 |
| joerg | the kernel module taking charge about 2translating" bq27200 data into sysnodes, it's... tricky. Pali implemented it for maemo | 12:32 |
| Wizzup | we had this working for sure | 12:32 |
| joerg | taking care about... | 12:32 |
| joerg | yes, it works IFFF | 12:33 |
| joerg | and e.g. my and speedevi's bq27k-detail.sh scriopts iirc only work when you unload the kernel module | 12:34 |
| Wizzup | I'll report back when I've figured this out, it might be a kernel change or just the module blacklist | 12:34 |
| joerg | something about I2C device exclusive open() | 12:34 |
| joerg | there are several mutually exclusive kernel midules which may try to access the bq27k stuff | 12:35 |
| joerg | and twl4030 iirc only involved regarding some A/D or USB-ID-pin or whatever | 12:36 |
| joerg | twl4030 can not emergency-charge | 12:36 |
| joerg | aka bootstrap-charge | 12:37 |
| Wizzup | freemangordon: battery_bq27200_0 has state charging, battery_bq24150a_0 has state charging (but is meaningless), DisplayDevice is state charging | 12:38 |
| Wizzup | both the displaydevice and the bq27200_0 seem ok info wise, so somehow our code decides not to use it | 12:38 |
| Wizzup | both mce and status applet | 12:38 |
| Wizzup | mce for led, status applet for gui | 12:38 |
| Wizzup | I'll check the code in a bit and see if I can find anything there | 12:38 |
| freemangordon | ok | 12:39 |
| joerg | to start with, the bq24150 charger chip needs D+/- short for bootstrap-charging (when the battery voltage is too low to bring up the CPU) | 12:40 |
| freemangordon | joerg: well, it seems kernel-wise it is fine | 12:41 |
| joerg | basically no USB wallwart charger supports this any more nowadays | 12:41 |
| freemangordon | some userspace issues | 12:41 |
| joerg | ok, then I'm probably out :-) | 12:41 |
| joerg | pali should know more details | 12:42 |
| freemangordon | yeah, thanks | 12:42 |
| joerg | yw | 12:42 |
| Wizzup | arno11: do you ever see the orange led when charging/ | 12:53 |
| Wizzup | or the battery charging animation | 12:54 |
| arno11 | Never seen the orange led since beowulf in 2021-2022 | 12:55 |
| arno11 | always troubles with battery animation | 12:55 |
| arno11 | but charging always works | 12:55 |
| arno11 | did you try to charge through fremantle to see any difference ? | 12:56 |
| arno11 | i mean with your current battery | 12:57 |
| Wizzup | arno11: yeah fremantle is fine I think | 13:00 |
| arno11 | maybe we have new issues if the battery is not already calibrated | 13:00 |
| Wizzup | arno11: in any case that is not normal, I think we had this working ok | 13:00 |
| Wizzup | (status applet and led) | 13:00 |
| arno11 | indeed | 13:00 |
| joerg | during early boot, NOLO/uBoot takes care about amber breathing indicator LED. Before even NOLO gets loaded to CPU, on batter_very_low the hardware BQ24150 enables the green and red (=amber) indicator LEDs on a mere hardware level | 13:02 |
| joerg | the latter mode is steady amber, not breathing | 13:03 |
| Wizzup | I think the problem here is just mce's upower module not picking up on this | 13:05 |
| joerg | if you don't see it on completely depleted battery durning the first fraction of a second on pluggin in USB, extending to a usually max ~20s until battery voltage got boosted up to a level where CPU can load NOLO and take over management of the indicator LED, then either you got no D+/- short in your USB wallwart charger, or your indicator LED and associated hardware is broken | 13:06 |
| Wizzup | yeah upower picks up something else | 13:09 |
| Wizzup | ok, I can fix this I think | 13:09 |
| Wizzup | https://bpa.st/H4LKC there are all of these, and only some are ignored | 13:10 |
| Wizzup | mce: xup_check_device: accepting device as line power twl4030_ac | 13:42 |
| Wizzup | mce: xup_check_device: accepting device as battery bq27200-0 | 13:42 |
| Wizzup | hm... I wonder if we simply miss some patch the report sysfs values over udev | 13:43 |
| Wizzup | unplugged cable makes the charging symbol start in battery applet | 13:43 |
| Wizzup | s/symbol/pattern/ | 13:43 |
| Wizzup | I guess it would be better to use isp1704 and not twl4030_ac | 13:45 |
| Wizzup | same logic in as mce as battery applet | 13:48 |
| Wizzup | will have a fix soon I hope | 13:48 |
| joerg | >>line power twl4030_ac<< hmmmm | 13:51 |
| Wizzup | the mce code just iterates over upower devices | 13:53 |
| Wizzup | and it picks the first line power device | 13:53 |
| Wizzup | (there are at least three) | 13:53 |
| joerg | afaik in N900 the twl4030 does zilch for power | 13:54 |
| Wizzup | eaxctly, this is the problem | 13:55 |
| Wizzup | it also rarely reports on udevadm monitor | 13:55 |
| Wizzup | yup | 13:56 |
| Wizzup | now it works again, with blacklist mod | 13:56 |
| joerg | :-D | 13:57 |
| Wizzup | the 'problem' we have with leste is that we support more than one device, so we need heuristics to find the right devices on a phone that exposes at least line power devices | 13:57 |
| Wizzup | and also several battery devices | 13:58 |
| Wizzup | it's possible the only thing that changed is the way the devices are loadeds or ordered in upower | 13:58 |
| Wizzup | uvos__: I assume you're not opposed to blacklisting two more n900 line power devices in mce's upower blacklist | 13:59 |
| Wizzup | isp1704, twl4030_ac and twl4030_usb are all 'power_supply: yes' and have a line-power property | 13:59 |
| Wizzup | I see nothing that we can distinguish them on in code | 13:59 |
| Wizzup | uvos: https://github.com/maemo-leste/mce/pull/57 | 14:15 |
| tmlind | freemangordon: i guess the idea with the raw values is that the data can be processed later on with little overhead during sampling | 14:18 |
| tmlind | freemangordon: getting the gsm support to mainline needs quite a bit of work, mostly to switch to serdev read and write for the virtual ports | 14:19 |
| Wizzup | freemangordon: (status-area-applet-battery) I rebased maemo/chimaera-devel and master on maemo/beowulf-devel, since there were some unmerged changes there, and I'm making a new release 1.5.5, with the blacklist added | 14:23 |
| freemangordon | tmlind: ok, but do we need in the particular driver? | 14:37 |
| freemangordon | Wizzup: yeah | 14:38 |
| tmlind | freemangordon: sorry care to clarify, not following you | 14:44 |
| freemangordon | cpcap_adc driver exposes both raw and processed values to sysfs. My question is - what is the usecase in exporting raw values from this particular driver and wouldn't it be better to remove BIT(IIO_CHAN_INFO_RAW) from .info_mask_separate? | 14:47 |
| freemangordon | thus exporting processed values only | 14:47 |
| freemangordon | BTW, I got buffer reads working (with made-up data, but still) | 14:48 |
| freemangordon | tmlind: ^^^ | 14:49 |
| Wizzup | uvos__: freemangordon: should we treat battery at 100% as full battery? right now n900 says battery-full-charging-symbolic with percentage at 100% but state is 'charging' | 14:57 |
| Wizzup | so the led never turns green | 14:57 |
| Wizzup | we check for UP_DEVICE_STATE_FULLY_CHARGED | 14:57 |
| tmlind | freemangordon: yeah maybe doable, the rate of data is very low volume for cpcap. nice that you got the buffer reads going | 14:57 |
| freemangordon | Wizzup: I don't think so | 14:58 |
| freemangordon | it is up to the driver/upower to set thta, no? | 14:58 |
| freemangordon | tmlind: sure it is doable, just that bit in question removed and we'll halve sysfs entries | 14:59 |
| freemangordon | not a biggie, but still | 14:59 |
| Wizzup | freemangordon: well, the icon state seems to imply it's full: battery-full-charging-symbolic | 15:01 |
| Wizzup | as in, charge_now == charge_full in sysfs | 15:03 |
| Wizzup | anyway, it's not important now | 15:03 |
| Wizzup | it just prevents green LED ;) | 15:03 |
| freemangordon | tmlind: https://pastebin.com/CW9WwP5F :) | 15:55 |
| freemangordon | this is real data | 15:55 |
| tmlind | freemangordon: cool, any idea on the sample rate? | 16:07 |
| freemangordon | no sample rate but sysfs trigger ;) | 16:07 |
| freemangordon | tmlind: see https://bootlin.com/blog/the-backbone-of-a-linux-industrial-i-o-driver/ | 16:08 |
| freemangordon | "As an example, here is how to create a sysfs trigger:" | 16:08 |
| freemangordon | so it is polled | 16:09 |
| freemangordon | "echo 1 > trigger_now" in /sys/bus/iio/devices/trigger1 | 16:10 |
| arno11 | Wizzup: just have dist-upgraded: working battery applet confirmed ;) | 16:10 |
| tmlind | freemangordon: oh ok | 16:10 |
| freemangordon | do we need constant sampling? | 16:11 |
| freemangordon | I don;t hink so | 16:11 |
| tmlind | with polling you need to be careful with the battery life | 16:12 |
| freemangordon | fyi: https://pastebin.com/u7H1Ps7J | 16:12 |
| tmlind | ideally you would request the 2x4 samples, then get an interrupt when it's ready | 16:12 |
| freemangordon | no, I think I didn;t explain it correctly | 16:13 |
| freemangordon | by 'polling' I mean - you request 4x2 samples and then wait | 16:13 |
| freemangordon | tmlind: see cpcap_adc_trigger_handler in the ^^^ patch | 16:14 |
| tmlind | yeah ok cool | 16:14 |
| freemangordon | so, when a diver or userspace needs data, it just triggers the trigger | 16:14 |
| freemangordon | and then gets the data when it is ready | 16:14 |
| freemangordon | the same as if you read from sysfs | 16:15 |
| tmlind | ok great | 16:15 |
| tmlind | so how do you now select between single channel and 2x4 data? | 16:15 |
| freemangordon | buffer is allowed only for single channel | 16:16 |
| tmlind | oh ok, but data shows both voltage and current? | 16:16 |
| freemangordon | because the way thje buffer channels are registered | 16:17 |
| freemangordon | yes, both voltage and current | 16:17 |
| tmlind | so what's the /dev/iio name to read the 2x4 voltage + current data? | 16:17 |
| freemangordon | /dev/iio\:device1 | 16:18 |
| freemangordon | /dev/iio:device1 | 16:18 |
| freemangordon | but this is not hard-coded I would say | 16:18 |
| freemangordon | but you can get that from uevent file | 16:19 |
| tmlind | sorry i mean the name for /sys/bus/iio, not /dev.. | 16:19 |
| freemangordon | no, you read from /dev | 16:19 |
| tmlind | ok | 16:19 |
| freemangordon | that's how buffers work | 16:19 |
| tmlind | ok makes sense | 16:19 |
| tmlind | so /sys/bus/iio can stay the same more or less | 16:20 |
| freemangordon | right | 16:20 |
| freemangordon | but I changed it a bit :D | 16:20 |
| tmlind | except for the broken channels 16 & 17 that don't show the full data | 16:20 |
| freemangordon | https://pastebin.com/Em3qfmCR | 16:20 |
| freemangordon | I removed those | 16:20 |
| freemangordon | also removed indexes and put 'labels' instead | 16:21 |
| tmlind | yeah makes sense if it's really 2x4 samples | 16:21 |
| freemangordon | now you know which channel is what | 16:21 |
| tmlind | cool | 16:21 |
| freemangordon | so, one select what to receive by enabling in scan_elements/ | 16:22 |
| tmlind | did you find any new interesting adc sources or names? | 16:22 |
| freemangordon | no, I reused your 'datasheet' ones | 16:22 |
| tmlind | ok | 16:22 |
| tmlind | some of them are still a bit of mystery | 16:22 |
| freemangordon | also see https://pastebin.com/JwMKsU1H | 16:22 |
| freemangordon | yeah | 16:23 |
| tmlind | ok nice | 16:23 |
| freemangordon | shall I split the changes before submitting? | 16:23 |
| tmlind | hmm so what are the *label names describing? | 16:24 |
| tmlind | a description for the channel if you cat it? | 16:24 |
| freemangordon | I was not able to remove those, they auto-appear if you set https://elixir.bootlin.com/linux/v6.3-rc3/source/include/linux/iio/iio.h#L221 | 16:24 |
| freemangordon | yes | 16:24 |
| Wizzup | arno11: good, mce will also work once uvos__ merges the pr | 16:25 |
| tmlind | ok cool | 16:25 |
| freemangordon | so, shall I split to 2 patches: 1. rename existing channels, 2. add buffer support? | 16:25 |
| tmlind | freemangordon: yeah makes sense since 16 & 17 are wrong | 16:26 |
| freemangordon | ok, will do that and will send them. | 16:26 |
| tmlind | great | 16:26 |
| tmlind | need to go, nice work! ttyl | 16:27 |
| freemangordon | ttyl | 16:27 |
| arno11 | Wizzup: ok | 16:27 |
| Wizzup | my phone still says 2040mAh but I guess over time that will settle | 16:28 |
| arno11 | calibration is quiete complicated | 16:28 |
| Wizzup | so for the image to work well ootb now we need to check why nokia-modem does not load | 16:28 |
| Wizzup | yeah | 16:28 |
| arno11 | several days needed | 16:29 |
| Wizzup | does not load automatically I mean | 16:29 |
| arno11 | good question | 16:29 |
| Wizzup | and swap | 16:30 |
| Wizzup | :D | 16:30 |
| arno11 | for the swap using a basic 1G file works great btw | 16:31 |
| Wizzup | I use the emmc swap that fremantle uses | 16:31 |
| arno11 | only problem: fragmentation | 16:31 |
| Wizzup | I think that might be better | 16:31 |
| arno11 | ok maybe | 16:31 |
| Wizzup | since it's a bit faster and usually present | 16:32 |
| Wizzup | only reason not to do it is if you fear to kill emmc | 16:32 |
| arno11 | yes | 16:32 |
| arno11 | definitly ! | 16:32 |
| arno11 | that's why i prefer basic file | 16:33 |
| arno11 | low battery ttyl | 16:35 |
| Wizzup | :) | 16:36 |
| Wizzup | my battery applet says I have about 22 hours left with wifi and modem on | 16:36 |
| arno11 | :) | 16:37 |
| arno11 | Wizzup: i found why modem refuse to load on boot... | 19:30 |
| arno11 | still blacklisted | 19:30 |
| Wizzup | where? | 19:30 |
| arno11 | in /etc/modprobe.d/nokia-modem.conf | 19:31 |
| arno11 | and /etc/modprobe.d/nokia-modem.conf.leste | 19:31 |
| Wizzup | # cat /etc/modprobe.d/nokia-modem.conf.leste | 19:32 |
| Wizzup | options nokia-modem pm=1 | 19:32 |
| arno11 | yep | 19:32 |
| Wizzup | that's not a blacklist | 19:32 |
| Wizzup | that's just an option for it I think | 19:32 |
| arno11 | sure | 19:32 |
| Wizzup | it has to say 'blacklist' in front of it in /etc/modprobe.d for it to be blacklisted afaik | 19:32 |
| arno11 | not sure iirc | 19:33 |
| arno11 | anyway i will try remove this option lol and see | 19:34 |
| arno11 | back in 10min | 19:34 |
| arno11 | Wizzup: apologies that's the opposite | 19:46 |
| arno11 | the file is suppose to load the option | 19:46 |
| arno11 | but it doesn't work | 19:47 |
| arno11 | with or without same result | 19:47 |
| Wizzup | hmm, ok | 19:52 |
| Wizzup | we could add it to modules-load.g | 19:53 |
| Wizzup | modules-load.d | 19:56 |
| Wizzup | unless this is systemd-only | 19:56 |
| arno11 | back in 20 min | 19:57 |
| arno11 | Wizzup: 'options nokia-modem pm' is linked with old issues wth ofono on startup. | 21:55 |
| arno11 | setting up the option after boot to load modem seems the safest | 21:56 |
| arno11 | according to old leste bug tracker issue | 21:57 |
| buZz | oooo update to battery applet? | 21:59 |
| arno11 | yes | 22:00 |
| Wizzup | arno11: I do not understand 'setting up the option after boot to load modem seems the safest' | 22:27 |
| arno11 | i mean loading the option manually or with script | 22:29 |
| arno11 | after boot | 22:30 |
| Wizzup | it might be worth to see if /etc/modules-load.d works | 22:31 |
| Wizzup | I don't know how to debug why udev does or does not load a module | 22:31 |
| Wizzup | let me try moddep -a | 22:32 |
| Wizzup | didn't help it seems | 22:52 |
| arno11 | and modules-load.d will not be possible | 22:53 |
| Wizzup | why is that? | 22:53 |
| arno11 | only systemd i think | 22:54 |
| Wizzup | ok | 22:54 |
| Wizzup | there is /etc/modules | 22:54 |
| Wizzup | but it's not a *.d :) | 22:54 |
| Wizzup | trying it now | 22:54 |
| buZz | does anyone else ever get the battery statusbar icon to 'blink' between 100% full and charging animation? | 22:57 |
| Wizzup | I mean, that will happen all the time when you're at full battery | 22:58 |
| buZz | i mean, its displaying -both- at the same time | 23:02 |
| buZz | maybe at ..2hz? | 23:03 |
| Wizzup | when the battery is full, the kernel reporting is nuts | 23:03 |
| Wizzup | so anything can happen | 23:03 |
| buZz | is that whats making upower misbehave? | 23:03 |
| Wizzup | it will switch between charging and discharging many times | 23:03 |
| buZz | yeah, thats what pavels patch was about | 23:03 |
| Wizzup | yes | 23:03 |
| buZz | still gotta try it :) | 23:03 |
| Wizzup | the n900 actually used to do this correctly, but I can't get it to do that currently, but maybe that's a calibration problem too | 23:04 |
| Wizzup | as in it would report fully charged and just power itself from the usb only | 23:04 |
| Wizzup | arno11: looks like it works :) | 23:06 |
| Wizzup | arno11: openrc also implements it | 23:06 |
| arno11 | really ? | 23:06 |
| Wizzup | yup | 23:06 |
| arno11 | well done | 23:06 |
| Wizzup | my n900 just asked me for a pin | 23:06 |
| Wizzup | I'll put it in leste-config for the n900 then | 23:06 |
| arno11 | coooooool | 23:06 |
| arno11 | ;) | 23:07 |
| Wizzup | swap will be harder, as there is no /etc/fstab.d | 23:08 |
| arno11 | true | 23:08 |
| arno11 | oh i forgot: did you try to use ofono then? | 23:09 |
| Wizzup | if it asks for the pin, it means ofono works | 23:09 |
| Wizzup | the modem doesn't seem to be online yet atm | 23:09 |
| arno11 | i asked because if the modem is loaded too early with pm=1 it could cause ofono troubles | 23:11 |
| Wizzup | what kind of trouble? | 23:11 |
| arno11 | segmentfault | 23:12 |
| Wizzup | ofono is still running | 23:12 |
| Wizzup | onlining the modem usually didn't take this long though | 23:12 |
| arno11 | maybe have a look in ofonod.log | 23:13 |
| Wizzup | yeah, looks like something is off, although it's not a segfault | 23:13 |
| arno11 | ok | 23:14 |
| Wizzup | so to test this we can have kmod depend on ofono, just as a test of course | 23:14 |
| Wizzup | then ofono will start before the module is loaded | 23:14 |
| Wizzup | but really it sounds like a bug we need to fix in ofono | 23:15 |
| arno11 | ah good idea | 23:15 |
| arno11 | yes but it seems to be an issue from the beginning | 23:15 |
| Wizzup | I don't even remember what the pm option does | 23:15 |
| Wizzup | do we need it still? | 23:16 |
| buZz | 'power management' sounds plausible? | 23:16 |
| Wizzup | buZz: .. that much is clear | 23:16 |
| arno11 | it was set to zero at the beginning | 23:16 |
| buZz | oh :) | 23:16 |
| arno11 | yes according to modinfo it is power management | 23:19 |
| arno11 | and per default it is set to 1 | 23:20 |
| arno11 | so why we need this command to start the modem ? | 23:20 |
| Wizzup | I imagine we probably set it to 0 in the past and then just changed the config to 1 | 23:22 |
| Wizzup | I suppose it might be able to do go | 23:22 |
| Wizzup | to go away* | 23:22 |
| arno11 | i think so | 23:22 |
| Wizzup | it won't change the bug at least | 23:24 |
| arno11 | indeed | 23:25 |
| Wizzup | but yeah, this will require a bit of debugging | 23:27 |
| Wizzup | there is OFONO_ISI_DEBUG and OFONO_ISI_TRACE for env vars, and indeed we can improve ofono debugging | 23:27 |
| Wizzup | maybe it is best to make an issue for this, I won't be able to look at this right now... | 23:27 |
| Wizzup | it's plugins/n900.c in ofono | 23:29 |
| Wizzup | arno11: what was the old issue you were looking it? | 23:29 |
| arno11 | bugtracker issue 61 i think | 23:30 |
| arno11 | with other links | 23:30 |
| arno11 | time to sleep. i'll have a look on this tomorrow | 23:30 |
| Wizzup | gn | 23:31 |
| Wizzup | and thanks | 23:31 |
| Wizzup | there should be a leste-config now btw | 23:31 |
| arno11 | :) gn | 23:32 |
| Wizzup | lol the ringtone on the n900 for incoming sms comes like 4 seconds after the vibration :D | 23:37 |
| Wizzup | when it's in cache it is better | 23:37 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!