| uvos__ | rafael2k_: theres nothing to debug | 09:28 |
|---|---|---|
| uvos__ | its as designed | 09:28 |
| uvos__ | https://github.com/maemo-leste/maemo-statusmenu-volume/blob/b205df8ce10fc03ada25c7baff538d46ebf07923/src/item.c#L499 | 09:30 |
| uvos__ | you could add support for a special value here "default" that makes the applet query pa for the default sink and use that | 09:31 |
| rafael2k_ | but it is ok it does not work? | 09:36 |
| rafael2k_ | volume just does not change | 09:36 |
| rafael2k_ | if it changed the default I would be happy | 09:37 |
| uvos__ | rafael2k_: yes because the stream it changes is set in that config file | 09:46 |
| uvos__ | and that stream only exists on mapphones | 09:46 |
| uvos__ | moveing that config file into leste-config is one option, but just asking pa what the correct stream is is better (since it gets that from ucm) | 09:47 |
| uvos__ | however support for the config file must remain | 09:47 |
| uvos__ | since pa might not allways know in voice call mode | 09:47 |
| uvos__ | depending on how the device implements voice calls | 09:47 |
| rafael2k_ | I think using default would be fine as a start, no? | 10:03 |
| rafael2k_ | (or add some setup to a pinephone specific config?) | 10:03 |
| rafael2k_ | I don't really get it | 10:04 |
| uvos__ | change should be: query pa for the default sink if the key it checks on the line linked above dosent exist | 10:05 |
| rafael2k_ | right | 10:05 |
| uvos__ | you can check the sphone pa module on how to query pa for defaults | 10:05 |
| rafael2k_ | tks | 11:05 |
| Wizzup | we need to make the volume applet better in any case | 11:08 |
| Wizzup | we need separate streams for speaker, headphone, bt sets, in call audio (speaker), in call audio (hp/earpiece) | 11:15 |
| Wizzup | s/streams/volumes/ | 11:16 |
| Wizzup | uvos__: any suggestions for a partition to install leste on, on the tablets? | 12:45 |
| uvos__ | not really | 12:49 |
| uvos__ | you can user userdata but that breaks android | 12:49 |
| uvos__ | or you can use emtstorage | 12:49 |
| uvos__ | but then android breaks mainline by trying to format it fat | 12:49 |
| uvos__ | either way it sucks | 12:50 |
| uvos__ | all other partitons are to small really | 12:50 |
| Wizzup | ok, so I'd have to override android install then | 12:52 |
| uvos__ | yeah and im not even sure you can flash to any of these | 12:54 |
| uvos__ | i dimmly remember flashing linux to some small 200mb partition | 12:54 |
| uvos__ | to then have it shuffle itself over to emtstorage | 12:54 |
| uvos__ | either way its painfull | 12:54 |
| Wizzup | so which partition do we need to keep? | 12:54 |
| uvos__ | well mbm and mbmloader for one xD | 12:55 |
| uvos__ | i think the partion i used initally was cdrom | 12:56 |
| uvos__ | its small 200 mb or so | 12:56 |
| uvos__ | but android dosent need it at all | 12:56 |
| uvos__ | http://uvos.xyz/maserati/stockinfo/partitions/xt894.txt | 12:56 |
| uvos__ | mz617 layout is simmular | 12:56 |
| uvos__ | android needs eveything above system and userdata to boot | 12:57 |
| uvos__ | besides cdrom and bpsw (dosnt exist on mz617) | 12:57 |
| Wizzup | right, I think I might just nuke android from this flash and install leste for testing | 12:58 |
| uvos__ | above logo.bin is permanent brick territory | 12:58 |
| uvos__ | problem with nukeing android is | 12:58 |
| uvos__ | that mainline cant really charge the tablet | 12:58 |
| Wizzup | no? | 12:58 |
| uvos__ | the tablets have another chargeing chip | 12:58 |
| uvos__ | you can charge it via the same cpcap charger | 12:59 |
| uvos__ | but its really slow | 12:59 |
| uvos__ | and on mz617 cant make it | 12:59 |
| uvos__ | power consumption is higher than cpcap-chargers current limit | 12:59 |
| uvos__ | becasue we cant turn off the pannel | 12:59 |
| uvos__ | i would recommend goint with emt | 13:00 |
| uvos__ | since android charge mode will still work | 13:00 |
| Wizzup | emt = emstorage? | 13:02 |
| Wizzup | I suppose the other thing I can do is hook it up to a lab supply, but yeah, then I need to take it apart | 13:02 |
| uvos__ | Wizzup: btw volumes | 13:41 |
| uvos__ | Wizzup: not the applet is fine | 13:41 |
| uvos__ | Wizzup: none of that is the applets concern | 13:41 |
| uvos__ | that was extream nokia anti pattern | 13:41 |
| uvos__ | the applet just changes whatever is the currently active stream | 13:42 |
| uvos__ | pa is resposable (and dose) restore volumes | 13:42 |
| uvos__ | now we do need some settings applet or so to change specific volumes even when not active | 13:43 |
| uvos__ | but thats not the status applet | 13:43 |
| uvos__ | and pavucontrol-qt is fine for this purpose for now anyhow | 13:43 |
| uvos__ | the noika setup was particually insane | 13:43 |
| uvos__ | because the status applet only restored the call volumes | 13:44 |
| Wizzup | but quite prctical for the user | 13:44 |
| Wizzup | but yeah | 13:44 |
| uvos__ | all other volumes where somehwere else | 13:44 |
| uvos__ | thats just insane implementation | 13:44 |
| uvos__ | not sure how the user case who restores volumes | 13:44 |
| uvos__ | *cares | 13:44 |
| Wizzup | sure, who is not a problem | 13:45 |
| uvos__ | right an its pa | 13:45 |
| uvos__ | (dose so allready :) | 13:45 |
| uvos__ | ) | 13:46 |
| uvos__ | so the volume applet needs no changes | 13:46 |
| Wizzup | ok | 13:46 |
| rafael2k | our tentative camera app: https://github.com/piggz/harbour-pinhole/ | 14:34 |
| rafael2k | will test it at night after my daughter sleeps | 14:34 |
| freemangordon | uvos: afaik stock nokia pplet restores all volumes | 14:42 |
| freemangordon | not only call volume | 14:42 |
| Wizzup | rafael2k: sweet | 14:50 |
| uvos__ | freemangordon: no | 14:54 |
| uvos__ | it only stores call volume | 14:54 |
| uvos__ | it stores no other volumes | 14:54 |
| uvos__ | look in git history | 14:54 |
| uvos__ | idk who dose everything else | 14:54 |
| Wizzup | that is re'd applet | 14:54 |
| uvos__ | but its not the applet | 14:54 |
| freemangordon | well, this is REed code | 14:54 |
| Wizzup | not necessarily what nokia did | 14:54 |
| Wizzup | right | 14:54 |
| uvos__ | ok | 14:54 |
| uvos__ | well then it was re'd wrong | 14:55 |
| uvos__ | at the very least | 14:55 |
| uvos__ | anyhow pa dose it so it dosent matter | 14:55 |
| freemangordon | which was using module StreamRestore2 which was missing in upstream PA | 14:55 |
| uvos__ | sure | 14:55 |
| freemangordon | so I had no option but to remove that | 14:55 |
| uvos__ | remove where? | 14:55 |
| freemangordon | also, in fremantle various streams are tagged with 'maemo-...' | 14:56 |
| freemangordon | remove from the code | 14:56 |
| uvos__ | it works in practice on leste right now for call audio | 14:56 |
| uvos__ | pa restores stream volume on ucm switch | 14:56 |
| uvos__ | also port switch | 14:56 |
| uvos__ | but thats less important | 14:56 |
| freemangordon | ok | 14:56 |
| freemangordon | that's great | 14:57 |
| freemangordon | we also somehow have to imlement support for volume stepa | 14:57 |
| freemangordon | *steps | 14:57 |
| uvos__ | hmm | 14:57 |
| uvos__ | steps? | 14:57 |
| Wizzup | can't it just step 5%? | 14:57 |
| uvos__ | thats what the volume applet dose | 14:58 |
| uvos__ | in its code | 14:58 |
| freemangordon | yes | 14:58 |
| uvos__ | not sure what else would be needed | 14:58 |
| freemangordon | but it should take the parameters to calculate the number of steos from the stream | 14:58 |
| freemangordon | *steps | 14:58 |
| uvos__ | pretty sure this is what happens | 14:58 |
| freemangordon | not really, as I am not aware anybody setting those parameters | 14:58 |
| freemangordon | unless I am missing something | 14:59 |
| freemangordon | sec, will show you what I mean | 14:59 |
| freemangordon | ugh, seems someone removed the code | 15:00 |
| freemangordon | this: https://github.com/maemo-leste/maemo-statusmenu-volume/blob/d6c3ffa8de080e82fe66881163594da2ca73ce19/src/item.c#L973 | 15:02 |
| uvos__ | this is unnesscary | 15:02 |
| uvos__ | since ucm tels pa how manny steps there are | 15:02 |
| uvos__ | and it translates this into a 0-1 float | 15:02 |
| uvos__ | so the applet dosent have to care about this at all | 15:02 |
| freemangordon | so it is in UCM? | 15:02 |
| uvos__ | (i remove it) | 15:02 |
| freemangordon | so, we have 5 steps while in call and 20 otherwise(for example)? | 15:03 |
| freemangordon | uvos__: ^^^ ? | 15:03 |
| uvos__ | yes - no, so in ucm you can set how manny steps there are | 15:04 |
| uvos__ | but this affects alsa only | 15:04 |
| uvos__ | pa just gives 0-1 range | 15:04 |
| uvos__ | and rounds to the nearest alsa step | 15:04 |
| uvos__ | but if you want that behavior you only need to have the applet set 0.2 0.4 etc | 15:04 |
| uvos__ | when in call | 15:04 |
| freemangordon | and how do you control that? | 15:04 |
| freemangordon | hardcode? | 15:04 |
| uvos__ | same way as that code, check what stream your controlling | 15:05 |
| uvos__ | the applet allready and still knows if its call audio or not | 15:05 |
| freemangordon | yes, but how does applet know on how many steps to divide that range per particular stream? | 15:06 |
| uvos__ | i could check what alsa control pa is using, pa exposes this | 15:07 |
| freemangordon | because the code you removed was getting that info from stream properties | 15:07 |
| uvos__ | then it comes from ucm | 15:07 |
| freemangordon | so, if ucm supports custom properties per stream, then we shall restore the removed code in some shape to get it from there | 15:08 |
| uvos__ | no | 15:08 |
| uvos__ | im pretty sure you can change pas behavior anyhow | 15:08 |
| freemangordon | instead of hardcoding the number of steps per stream | 15:08 |
| freemangordon | ok, if that's the case yes | 15:08 |
| uvos__ | pa rounds | 15:09 |
| uvos__ | need to check what happens to the volume of the stream | 15:10 |
| freemangordon | but please, do POC and try to make a configuration in which we have to press volume up only 5 times to go from 0 to 100% while in call and 20 times when not | 15:10 |
| uvos__ | well chanigng call audio volume dosent work anyhow | 15:10 |
| uvos__ | so | 15:10 |
| uvos__ | that should work first | 15:10 |
| freemangordon | ugh | 15:10 |
| uvos__ | before we deal with this comperatively unimportant detail | 15:10 |
| freemangordon | any idea why? | 15:10 |
| uvos__ | yes | 15:10 |
| freemangordon | sure, not something urgent | 15:10 |
| uvos__ | pa has no idea there is any audio | 15:10 |
| freemangordon | heh | 15:10 |
| uvos__ | so it refuses to change anything | 15:10 |
| freemangordon | passtrough | 15:11 |
| uvos__ | since there is nothing to change | 15:11 |
| freemangordon | I guess thats some alsa thing | 15:11 |
| uvos__ | its the same thin as allways | 15:11 |
| uvos__ | the omap4 has no idea call audio is active on mapphones | 15:12 |
| uvos__ | since its not involved | 15:12 |
| freemangordon | ok | 15:12 |
| freemangordon | but, this is d4 specific, no? | 15:13 |
| uvos__ | sure | 15:13 |
| uvos__ | and pp | 15:13 |
| freemangordon | ah | 15:13 |
| uvos__ | so everywhere call audio works in the first place | 15:13 |
| uvos__ | d4 + freinds ofc | 15:13 |
| uvos__ | they are alle the same | 15:13 |
| freemangordon | so, do we need some PA module that is aware of USB audio? or? | 15:14 |
| uvos__ | there is no usb audio | 15:14 |
| freemangordon | ah | 15:14 |
| uvos__ | the audio dosent enter the procesor at all | 15:14 |
| freemangordon | directly from the modem to the earpiece? | 15:14 |
| uvos__ | yes | 15:14 |
| uvos__ | we need some module that fakes a active stream i gues | 15:14 |
| freemangordon | omg | 15:14 |
| freemangordon | yeah | 15:14 |
| freemangordon | but, we already have kernel modem audio device on d4, no? | 15:15 |
| uvos__ | no not really | 15:15 |
| freemangordon | I would say it should take care of that | 15:15 |
| uvos__ | not like that | 15:15 |
| uvos__ | no idea if fakeing a active stream is ok in alsa | 15:15 |
| freemangordon | ok, I admit this is out of my area of expertise | 15:16 |
| uvos__ | the kernel framework is kinda not ready for this | 15:16 |
| uvos__ | we have this problem alle the time there | 15:16 |
| freemangordon | maybe we shall ask upstream how to proceed | 15:16 |
| uvos__ | it dosent uderstand that its mixer is controlling audio that its not playing or reciveing | 15:17 |
| freemangordon | umm, wait, is that what all HW mixers do? | 15:17 |
| freemangordon | *isn;t | 15:17 |
| uvos__ | no | 15:17 |
| uvos__ | hw mixers allways have a stream that comes from the kernel somewhere | 15:18 |
| freemangordon | analog mixers I mean | 15:18 |
| uvos__ | oh sure, but those old devices dont use asoc | 15:18 |
| uvos__ | if you have a classic alsa driver you can just implement random controlls | 15:18 |
| freemangordon | don;t tell me upstream kernel has no support for analog mixer/amplifier | 15:18 |
| uvos__ | im not | 15:19 |
| freemangordon | can;t we use that? | 15:19 |
| uvos__ | but in the asoc framework no | 15:19 |
| uvos__ | we have asoc driver | 15:19 |
| uvos__ | :P | 15:19 |
| freemangordon | umm | 15:19 |
| freemangordon | what about another driver? | 15:19 |
| uvos__ | sure you can write another driver | 15:20 |
| uvos__ | or rather replace the asoc one | 15:20 |
| freemangordon | hmm | 15:21 |
| freemangordon | we have simple amplifier for start | 15:22 |
| freemangordon | it won;t help | 15:22 |
| freemangordon | but, at least might give us a clue how to write a driver that has analog ports only | 15:22 |
| freemangordon | uvos__: what about if we add volume support to simple-audio-amplifier? | 15:32 |
| freemangordon | how is volume actually controlled? | 15:32 |
| freemangordon | AT commands? | 15:32 |
| freemangordon | also, I see no such requirement that asoc component must be digital only | 15:33 |
| freemangordon | see simple-audio-amplifier/simple-audio-mux | 15:33 |
| uvos__ | freemangordon: this isent the problem at all | 15:35 |
| uvos__ | the mixer is there | 15:35 |
| uvos__ | its just linux thinks its not active | 15:35 |
| uvos__ | because it is connected to the omap4 | 15:35 |
| uvos__ | its jsut also connected to something else entirely that might need it | 15:36 |
| uvos__ | this is about pm purposes | 15:36 |
| uvos__ | and then we have pa | 15:36 |
| uvos__ | that only thinks streams are active it it is involved | 15:36 |
| uvos__ | it has no concept at all of a stream that isent inside of pa | 15:36 |
| freemangordon | uvos__: see simple amplifier | 15:36 |
| freemangordon | you can attach vcc to it | 15:37 |
| uvos__ | no | 15:37 |
| uvos__ | you can not | 15:37 |
| freemangordon | yes, see the bindiongs | 15:37 |
| freemangordon | *bindings | 15:37 |
| freemangordon | https://elixir.bootlin.com/linux/v6.1.6/source/Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml#L24 | 15:37 |
| uvos__ | yes but then you broke audio pm | 15:37 |
| uvos__ | its not that simple | 15:37 |
| freemangordon | why? vcc is enabled for as long as amplifier is needed in the cirrent routing, no? | 15:37 |
| freemangordon | *current | 15:38 |
| freemangordon | I am not saying it is simple | 15:38 |
| uvos__ | yes but there are manny manny devices and there are coplex interactions when witch are needed | 15:38 |
| uvos__ | the problem is we can tell this system that chain is needed because of the modem | 15:38 |
| uvos__ | *that a chain | 15:38 |
| uvos__ | we could just reimplement this system (that the asoc frame work provides) | 15:39 |
| uvos__ | by writeing a classic alsa driver but we absolutly do not want to need to do that | 15:39 |
| freemangordon | ok, but that we shall describe the chains in DTS, no? | 15:39 |
| uvos__ | no | 15:40 |
| freemangordon | *but then | 15:40 |
| uvos__ | the chains are created in the cpcap driver | 15:40 |
| uvos__ | dts is only tangentally involved | 15:40 |
| freemangordon | right, but you can attach simple amplifier in DT | 15:40 |
| freemangordon | to the cpcap driver output sptream | 15:40 |
| freemangordon | *stream | 15:40 |
| uvos__ | there is no stream | 15:40 |
| freemangordon | oh, wait | 15:40 |
| uvos__ | the amp is cpcap | 15:41 |
| freemangordon | do you say that nobody knows when a call audio is started? | 15:41 |
| uvos__ | yes | 15:41 |
| uvos__ | alsa dosent know | 15:41 |
| uvos__ | or asoc rather | 15:41 |
| freemangordon | I see | 15:41 |
| uvos__ | and there is no standart way to tell it | 15:41 |
| Wizzup | unless we activatie something in alsa with ucm | 15:41 |
| uvos__ | no | 15:41 |
| Wizzup | can it not flip some call switch? | 15:42 |
| uvos__ | the problem is that the asoc framework has no concept of a stream being active unless its activate by a root dai | 15:42 |
| uvos__ | afaik | 15:42 |
| freemangordon | I see | 15:42 |
| freemangordon | umm... maybe we can fake a microphone? | 15:43 |
| freemangordon | microphone input that is | 15:43 |
| uvos__ | maybe something like that | 15:43 |
| uvos__ | anyhow this is a different problem than pa | 15:43 |
| uvos__ | even if the kernel knows | 15:43 |
| freemangordon | and attach amplifier to it | 15:43 |
| uvos__ | pa dosent care | 15:43 |
| uvos__ | pa just cares about its own streams | 15:43 |
| freemangordon | yeah, I am talking about kernel | 15:43 |
| uvos__ | it wont let you just change volumes of hw mixers | 15:43 |
| uvos__ | it dosent have support for hw mixing at all | 15:43 |
| Wizzup | why do all banks require android apps now grrrrr | 15:44 |
| freemangordon | how that works in fremanlte on n900? | 15:44 |
| Wizzup | sorry offtopic | 15:44 |
| uvos__ | freemangordon: no idea | 15:44 |
| freemangordon | it has analog amplifier for sure | 15:44 |
| uvos__ | freemangordon: presumably they had pa modules that do unnatural stuff | 15:44 |
| freemangordon | I don;t think so | 15:45 |
| freemangordon | like, they had | 15:45 |
| freemangordon | but not in that regard | 15:45 |
| uvos__ | also on n900 its not so hard | 15:45 |
| freemangordon | come on | 15:45 |
| uvos__ | since the audio allways passes though pa | 15:45 |
| uvos__ | and the cpu | 15:45 |
| freemangordon | right, but you have preamplifiers and whatnot | 15:45 |
| uvos__ | so | 15:45 |
| freemangordon | exposed as alsa controls | 15:45 |
| uvos__ | on n900 you need only feed modem audio into pa as a mic | 15:46 |
| uvos__ | and it will work | 15:46 |
| uvos__ | since the cpu gets the audio | 15:46 |
| freemangordon | right | 15:46 |
| uvos__ | and the modem is just a dai | 15:46 |
| uvos__ | so its "easy" | 15:46 |
| freemangordon | well, it does not work like that on fremantle (thay have pa module for the modem afaik) | 15:46 |
| freemangordon | that feeds the data to pa | 15:47 |
| uvos__ | ok but the point is pa sees the audio | 15:47 |
| uvos__ | on d4 there is no audio to see | 15:47 |
| freemangordon | right | 15:47 |
| freemangordon | I agree | 15:47 |
| freemangordon | but, imagine if you have an analog amplifier you have to control with alsa | 15:47 |
| freemangordon | you have a register that controls the volume | 15:47 |
| freemangordon | how would you present that to the kernel? | 15:48 |
| freemangordon | no dai, nothing | 15:48 |
| uvos__ | well if you do it via asoc | 15:48 |
| uvos__ | the kernel wont care unless you also tell it some dai is feeding it and that dai is playing | 15:49 |
| uvos__ | or you can write a classic alsa driver | 15:49 |
| freemangordon | so, why do we have asoc driver then if it is not fit for the purpose? | 15:50 |
| freemangordon | tell me again, why don;t we want to write alas driver for the modem? | 15:53 |
| freemangordon | *alsa | 15:53 |
| uvos__ | how would that help | 15:53 |
| uvos__ | who would controll the registers? the "modem" driver or the asoc audio drivers | 15:54 |
| freemangordon | mhm | 15:54 |
| freemangordon | modem driver | 15:54 |
| uvos__ | they need to control the same registers at different times | 15:54 |
| uvos__ | thats insane | 15:54 |
| freemangordon | ok, no idea then | 15:55 |
| uvos__ | just have a modem driver that fakes a dai | 15:55 |
| uvos__ | but no idea if thats ok | 15:55 |
| freemangordon | how android kernel does it? | 15:55 |
| uvos__ | for upstream | 15:55 |
| uvos__ | userspace just walks over registers | 15:56 |
| freemangordon | I don;t think we can fake a dai | 15:56 |
| freemangordon | like, kernel will expect audio data at some point I guess | 15:56 |
| uvos__ | no idea | 15:57 |
| uvos__ | i think you might be able to get away with this | 15:57 |
| uvos__ | major hack ofc | 15:57 |
| freemangordon | hmm, I wonder how mcbsp is supposed to work | 15:57 |
| freemangordon | iirc it has the same 'pass-through' mode | 15:57 |
| uvos__ | no idea | 16:31 |
| SuperMarioSF | Hello there. | 17:47 |
| SuperMarioSF | I'm back from Shenzhen, and I have a established way to send package globally now. | 17:47 |
| SuperMarioSF | Wizzup, plz check email | 17:47 |
| Wizzup | will do in a bit :) | 17:48 |
| SuperMarioSF | ;) | 17:48 |
| Wizzup | uvos: maybe mz615 is easier testing wise (because it has microsd card slot) | 19:00 |
| vandys | Just posted https://github.com/maemo-leste/bugtracker/issues/695 but will close if somebody here can help. How to enable telephony on Pinephone w. install of latest nightly build? | 19:23 |
| norayr | i found flickrdemo program that comes with nokia license. | 19:28 |
| norayr | i read it but i didn't understand if i can derive from it and publish. | 19:28 |
| norayr | i really need a flickr app on maemo. | 19:29 |
| bencoh | http://maemo.org/packages/view/quickflickr/ maybe? seems free/opensource | 19:31 |
| bencoh | it's quite old though, I'd be kinda surprised if the same API still works | 19:32 |
| Wizzup | we have no libsharing yet | 19:48 |
| Wizzup | jfyi | 19:48 |
| Wizzup | vandys: let's see, did you install beowulf or chimaera? | 19:49 |
| Wizzup | as in, what was the image name? | 19:49 |
| dsc_ | https://plak.infrapuin.nl/selif/xpfzjbxu.mp4 | 20:28 |
| dsc_ | this is using neural machine translation for local translations | 20:30 |
| dsc_ | so works without internet | 20:30 |
| dsc_ | it was a bit annoying to get this to run on this old hardware... | 20:31 |
| dsc_ | xD | 20:31 |
| dsc_ | seems like I forgot the word 'is' -- too tired :D | 20:36 |
| uvos | dsc_: awsome | 20:36 |
| uvos | dsc_: care to package that? | 20:36 |
| dsc_ | sure thing its here: https://github.com/maemo-leste-extras/maemo-translate | 20:37 |
| dsc_ | but still creating proper packages atm., should be in the repos tomorrow (?) | 20:37 |
| uvos | dsc_: that would be great | 20:37 |
| uvos | i use gt on d4 often | 20:37 |
| dsc_ | nice, this one doesnt require any internet ^^ | 20:38 |
| uvos | yeah it sounds sweet :) | 20:38 |
| dsc_ | it uses a library I created earlier: https://github.com/kroketio/kotki | 20:39 |
| dsc_ | brb sleeping | 20:40 |
| bencoh | dsc_: kotki looks awesome :) | 21:45 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!