IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 31 October 2018 (all times are UTC)
| 00:49 | zama has left IRC (zama!~zama@unaffiliated/stryx/x-3871776, Ping timeout: 252 seconds) | |
| 00:58 | zama has joined IRC (zama!~zama@unaffiliated/stryx/x-3871776) | |
| 01:16 | josefig has left IRC (josefig!~josefig@unaffiliated/josefig, Ping timeout: 250 seconds) | |
| 02:19 | adrianor1 has joined IRC (adrianor1!~adrianorg@177.18.49.220) | |
| 02:20 | adrianorg has left IRC (adrianorg!~adrianorg@179.187.25.94.dynamic.adsl.gvt.net.br, Ping timeout: 245 seconds) | |
| 02:43 | adrianor1 has left IRC (adrianor1!~adrianorg@177.18.49.220, Ping timeout: 244 seconds) | |
| 02:49 | adrianorg has joined IRC (adrianorg!~adrianorg@186.215.21.64) | |
| 03:12 | adrianorg has left IRC (adrianorg!~adrianorg@186.215.21.64, Ping timeout: 268 seconds) | |
| 03:19 | adrianorg has joined IRC (adrianorg!~adrianorg@177.18.173.141) | |
| 06:55 | <cemc> quinox, alkisg: thanks, it is working now
| |
| 06:55 | <alkisg> np
| |
| 09:13 | enaut[m] has left IRC (enaut[m]!enautmatri@gateway/shell/matrix.org/x-tylptccdomvnrmtf, Read error: Connection reset by peer) | |
| 09:23 | enaut[m] has joined IRC (enaut[m]!enautmatri@gateway/shell/matrix.org/x-rytdoqkgudkpdosx) | |
| 10:01 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3101:400:8c1b:8441:9019:ed7a) | |
| 10:05 | Natureshadow has left IRC (Natureshadow!45d1515d22@commu.teckids.org, Read error: Connection reset by peer) | |
| 10:25 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 11:16 | GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net) | |
| 11:47 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 14:50 | GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 245 seconds) | |
| 15:06 | GodFather has joined IRC (GodFather!~rcc@2600:1007:b12b:f6ac:7d36:a71a:fdad:eaec) | |
| 15:07 | rubberduck77 has joined IRC (rubberduck77!~rubberduc@gk8.condor-edv.de) | |
| 15:10 | <rubberduck77> Hello LTSP! First of all, I would like to say thanks to the really impressive work on this project. I have installed the LTSP, now beeing impressed but already have some questions to maybe unsupported features. Someone out there who might have some deep insights?
| |
| 15:12 | <||cw> just ask. several are in and out this time of day
| |
| 15:13 | but do keep in mind that LTSP is glue for several normal linux tools, so quite often the answer is simple "how would you do that on any multiuser linux system"
| |
| 15:13 | <rubberduck77> Thnx...
| |
| 15:14 | ...the "question" is... how (and when) does the ldm process add the getent <user> to the "local" passwd/shadow?
| |
| 15:16 | I have a problem from that, since the mate-desktop wont unlock the screensaveer with my installation... but I already hacked the LTSP quite a bit, to be able to run from a "local" img file. So I would like to understand, how authorisation is implemented.
| |
| 15:17 | Hacked might be wrong wording.. simply using a local disk; not only for the kernel and initrd but also the root.img looped to the kernel. Required only two small parameters for the cmdline, and now the "thinclient" is much faster on a remote network.
| |
| 15:23 | <mwalters> rubberduck77: can't answer the technical aspects, but adding the following line to lts.conf will resolve the screensaver issue: LDM_PASSWORD_HASH=True
| |
| 15:23 | (for fat clients)
| |
| 15:26 | <rubberduck77> Thnx... that seems to disable the screensaver, right?
| |
| 15:33 | <mwalters> no... trying to think of how to word it correclty
| |
| 15:34 | end result is a properly functioning screen lock... creates a shadow entry for the logged in user?
| |
| 15:34 | (locally)
| |
| 15:35 | "Will create a proper shadow entry on the client, allowing for screen locking, and other things which require authentication to work"
| |
| 15:35 | <rubberduck77> Ah, Ok. That seems to be what I would need. I will give it a try. Side-Effect would be, that on a local vty a user also would be able to logon, right
| |
| 15:36 | <mwalters> from lts.conf manpage
| |
| 15:36 | probably, let me test
| |
| 15:36 | yes, logging into vty works
| |
| 15:36 | (I'm on a fat client right now ;) )
| |
| 15:36 | <rubberduck77> sound good
| |
| 15:37 | <mwalters> also to note from man: This lets users change their password locally, but does not change it on the server... you'd want to use like, `ltsp-remoteapps passwd` for it to be persistent
| |
| 15:38 | lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-186.isotelco.net.br) | |
| 15:41 | GodFather has left IRC (GodFather!~rcc@2600:1007:b12b:f6ac:7d36:a71a:fdad:eaec, Ping timeout: 260 seconds) | |
| 15:41 | lucascastro has left IRC (lucascastro!~lucascast@177-185-139-186.isotelco.net.br, Remote host closed the connection) | |
| 15:50 | lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-186.isotelco.net.br) | |
| 15:57 | GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net) | |
| 16:12 | Natureshadow has joined IRC (Natureshadow!45d1515d22@commu.teckids.org) | |
| 16:14 | josefig has joined IRC (josefig!~josefig@unaffiliated/josefig) | |
| 16:43 | GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 260 seconds) | |
| 17:24 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 18:16 | kjackal has left IRC (kjackal!~quassel@2a02:587:3101:400:8c1b:8441:9019:ed7a, Ping timeout: 252 seconds) | |
| 19:14 | josefig has left IRC (josefig!~josefig@unaffiliated/josefig, Ping timeout: 244 seconds) | |
| 19:29 | lucascastro has left IRC (lucascastro!~lucascast@177-185-139-186.isotelco.net.br, Read error: Connection reset by peer) | |
| 19:30 | lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-186.isotelco.net.br) | |
| 19:32 | GodFather has joined IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net) | |
| 19:43 | <rubberduck77> @mwalters: thanks... testet and works like a charm
| |
| 19:44 | <mwalters> :D
| |
| 19:45 | <rubberduck77> Is there anyout else, who prefers using a local cache disk instead of nbd'ing everything always over the net?
| |
| 19:45 | <vagrantc> i would get tired of updating the disk
| |
| 19:46 | but i guess if the caching was transparent in the background...
| |
| 19:46 | <rubberduck77> @vagrantc: your rght, but maybe one can sctipt the needed updates
| |
| 19:46 | <mwalters> dunno other people's workloads, but generally I open chrome and leave it open all day ;)
| |
| 19:46 | <vagrantc> i haven't seen a public example, but yes, it's theoretically possible
| |
| 19:46 | <mwalters> same with mate-terminal
| |
| 19:47 | <rubberduck77> Currently my grub can choose to boot from net or local disk... I now would need to implement the cache update "script". So thats the reason for my question... maybe someone else already did this.
| |
| 19:48 | you're right... the terminals wont need to load that much stuff if they get up and running. But until loaded over a "small" uplink to the server, the local cache saves a lot of time
| |
| 19:49 | <vagrantc> and what are you doing to cache locally?
| |
| 19:49 | just dd to the disk?
| |
| 19:51 | <rubberduck77> I currently use the amd64.img, place it on a separate partition and use kernel looping
| |
| 19:52 | <alkisg> !local-boot
| |
| 19:52 | <ltsp> local-boot: If you want LTSP fat clients on a low-speed network, you can put i386.img on e.g. C:\Boot\LTSP\i386.img and use this command line in pxelinux.cfg: APPEND ro initrd=ltsp/i386/initrd.img init=/sbin/init-ltsp root=/dev/sda1 rootflags=ro loop=/Boot/LTSP/i386.img; IPAPPEND 3
| |
| 19:52 | <alkisg> mwalters: ^
| |
| 19:52 | ah, sorry, rubberduck77 ^
| |
| 19:53 | <rubberduck77> I use something similar:
| |
| 19:53 | <alkisg> I used it in a couple of schools, and gave a command to the teacher to use via epoptes
| |
| 19:53 | Like, dd if=/dev/nbd0 of=/path/to/amd64.img
| |
| 19:54 | So he typed it once in the epoptes dialog, and all clients updated, and auto-shutdown after they were done
| |
| 19:54 | <vagrantc> the killer feature would be something that just did that dynamically when you boot to the network
| |
| 19:54 | <alkisg> That would be a good task for a caching file system, with dmcache possibly
| |
| 19:54 | <vagrantc> right
| |
| 19:55 | <alkisg> And it would be even greater if all nbd traffic was broadcasted and automatically cached by all clients
| |
| 19:55 | <rubberduck77> menuentry "LTSP local image" {
| |
| 19:55 | loopback loop "(hd0,1)/amd64.img"
| |
| 19:55 | set root='(loop)'
| |
| 19:55 | linux /boot/vmlinuz ro quiet splash init=/sbin/init-ltsp forcepae root=/dev/sda1 nbdroot=DHCP ltsp.SERVER=192.168.198.15 loop="amd64.img"
| |
| 19:55 | initrd /boot/initrd.img
| |
| 19:55 | loopback -d loop
| |
| 19:55 | }
| |
| 19:55 | <vagrantc> especially if it could be opportunistic and just sync in the background
| |
| 19:55 | <alkisg> rubberduck77: eh, no need to keep the kernel locally, it's just a few mb...
| |
| 19:55 | <vagrantc> alkisg: but it's already in the image
| |
| 19:56 | <alkisg> Yeah, but it requires grub on the client
| |
| 19:56 | <vagrantc> ah
| |
| 19:56 | <alkisg> While in my case i didn't want to "upset" the local windows installations
| |
| 19:56 | And, netbooting allows to get the newest kernel each time, not the one from the image, which might have issues
| |
| 19:56 | <vagrantc> so if the network was down, the client wouldn't function... though without a homedir i guess it doesn't matter
| |
| 19:56 | <alkisg> Right
| |
| 19:57 | !epoptes
| |
| 19:57 | <ltsp> epoptes: Epoptes is a computer lab administration and monitoring tool. It works on Ubuntu and Debian based labs with LTSP or non-LTSP servers, thin and fat clients, standalone workstations, NX clients etc. More info: http://www.epoptes.org
| |
| 19:57 | <alkisg> rubberduck77: in case you don't know it, it's handy for running tasks in all clients easily ^
| |
| 19:57 | <rubberduck77> @alkisg: already installed this handy tool
| |
| 19:57 | <alkisg> nice
| |
| 19:58 | * alkisg waves, 'night all... | |
| 19:58 | <rubberduck77> I already said it a couple of hours ago... really impressed of all the LTSP-Stuff around!
| |
| 19:58 | <vagrantc> for the right niche, it's pretty amazing :)
| |
| 19:59 | <rubberduck77> Works easily and covers many tasks already... never the less... I do not understand, why here in germany it a (at least seems) to be not that heaviliy used...
| |
| 20:00 | ...we were evalutating for quite some time now some solutions to upgrade some "old" SunRay installations...
| |
| 20:00 | ...come accross some "cheap" and also some "expensive" commercial solutionss...
| |
| 20:01 | ...but only the "free" solution "LTSP" seems to cover all of our needs!
| |
| 20:01 | <vagrantc> glad to hear it's working for you!
| |
| 20:02 | there are (were?) a number of deployments of LTSP in germany using the Debian-Edu project; not sure if they're still in use or not
| |
| 20:02 | <rubberduck77> We are still evalutiation... but it is on a good way... we need it for a hospital e.g. with around 500 thinclients and citrix on top
| |
| 20:02 | <vagrantc> heh. with citrix on top, just about anything could be underneathe
| |
| 20:05 | <rubberduck77> well... not quite eveything... the openthinclient project (also in germany maintained) uses debian wheezy... so our "brand new" IntelNUCs are not supported... and also wont be in the early next release the told be. At least for mutli monitor solution or with 4K resoltuion.
| |
| 20:07 | and ubuntu 18... latest xorg with latest intel... works without any problems from scratch
| |
| 20:10 | I would also prefer to drop citrix .. but the customer insists on that, cause the manager has been familar with it at a former workplace. so... I need to provide a solution for 4K, multi-monitor with "cheap" thin-client hardware.
| |
| 20:10 | Is there anything on how we can support the project?
| |
| 20:17 | <quinox> $$$
| |
| 20:17 | ;)
| |
| 20:23 | <vagrantc> LTSP has been stalled for some years on some new feature development ... it's largely been in maintenace mode, and could use some updates
| |
| 20:23 | or at the very least, cleaning out some cruft ...
| |
| 20:24 | but it really needs some model that can sustain development over time
| |
| 20:25 | there's a bit of drive-by interest now and then, but it's been a while since there's been an active developer community
| |
| 20:25 | <rubberduck77> I already saw something about "clustering" the server... dont know if we already need it for our planned installatioones... but seems to outdated?? Or already not really needed any longer?
| |
| 20:25 | <||cw> rubberduck77: they're using citrix for linux desktops?
| |
| 20:25 | <vagrantc> the ltsp-cluster stuff is a perfect example of things that are no longer maintained or suported, that still have bits of code all over the place
| |
| 20:26 | <rubberduck77> @vagrantc ... sorry... quite new here... is there a list "public" visible of the people which one would call a ltsp developer?
| |
| 20:27 | @cw no--- citrix to access windows-terminal-servers over some small uplinks from several locations.
| |
| 20:27 | <||cw> will their apps work on linux?
| |
| 20:27 | <vagrantc> rubberduck77: you can look at the commit history
| |
| 20:27 | <rubberduck77> @cw: no...
| |
| 20:27 | <vagrantc> rubberduck77: mostly alkisg these days with the occasional contribution from myself or someone else
| |
| 20:28 | in fact, i really should make sure it works ok with the upcoming Debian freeze...
| |
| 20:28 | <||cw> ltsp is linux terminal server. it's not really comparable to citrix.
| |
| 20:28 | <rubberduck77> @cw we only need a "platfrom" to laucnh the citrix receiver
| |
| 20:29 | <||cw> however, you can use ltsp in a bare bones way to run xfreedrp to connect to windows terminal servers or virtual machines (VDI style)
| |
| 20:29 | Natureshadow has left IRC (Natureshadow!45d1515d22@commu.teckids.org, Read error: Connection reset by peer) | |
| 20:29 | <||cw> so does that work on linux with 4K multi display?
| |
| 20:30 | in that use, ltsp is just a nice way to make the clients diskless.
| |
| 20:30 | <rubberduck77> we have testet with ubu18... and with our intel nuc it works without any problems from scratch
| |
| 20:30 | <alkisg> How much ram do the clients have?
| |
| 20:30 | <rubberduck77> 8G
| |
| 20:31 | <alkisg> Eh, didn't you also say you had some old clients?
| |
| 20:31 | Or ltsp is just for the nucs?
| |
| 20:31 | <rubberduck77> the old clients we are going to replace are sunray2... but they will be replaced completly
| |
| 20:31 | ltsp is the "operation system" for the new nucs
| |
| 20:31 | <vagrantc> there was an attempt to port ltsp to sunray at one point... but too locked down
| |
| 20:32 | <alkisg> So you want ltsp just to netboot the nucs and run citrix on top? The users won't work on linux at all?
| |
| 20:32 | <vagrantc> i'm guessing citrix won't use much of that 8GB of ram
| |
| 20:32 | honestly, if that's all you're doing ... just load the NBD image into RAM
| |
| 20:33 | <rubberduck77> @alkisg: at least for the hospital installation that is right. on some other nstallations where we need to "upgrade" the old thinclient hardware, there are also local-browers that have to be sused.
| |
| 20:33 | @vagrantc we already thought of only using 4G
| |
| 20:33 | <vagrantc> how much ram does citrix eat?
| |
| 20:33 | <rubberduck77> then the complete nuc would cost aroung 145@
| |
| 20:33 | <alkisg> And I'm guessing you won't need linux-authentication either (users etc), since the users will authenticate against citrix?
| |
| 20:33 | <rubberduck77> @alkisg: right
| |
| 20:34 | <alkisg> OK, then yeah you can have a kiosk-like session that only offers citrix
| |
| 20:34 | <rubberduck77> @vagrantc: i haven't measured until now
| |
| 20:34 | <alkisg> The kiosk plugin in ltsp could use a rewrite, but it should be easily implementable
| |
| 20:34 | <rubberduck77> @alkisg... that would suffer the hospital needs, riught
| |
| 20:35 | Natureshadow has joined IRC (Natureshadow!45d1515d22@commu.teckids.org) | |
| 20:49 | <rubberduck77> Another question (not tested until now): do you know, if hospital keyboards like "eHealth-BCS Tastatur G87-1504" will work?
| |
| 20:50 | Not the keybord itself in question, but the card readers contained in?
| |
| 20:51 | <alkisg> If they work on linux, they work on ltsp too
| |
| 20:52 | <rubberduck77> Ok; I'll give it a try
| |
| 20:53 | So to focus on e.g. citrix-kiosk mode... what would be needed?
| |
| 20:53 | <vagrantc> look at the various scripts in /usr/share/ltsp/screen.d/
| |
| 20:54 | xfreerdp/rdesktop might be the most similar use-case
| |
| 20:54 | or the kiosk script, but i suspect that is overkill
| |
| 20:54 | not very familiar with citrix, so maybe there's more to it than i realize
| |
| 20:56 | * alkisg has used citrix in 2006, right before jumping on the ltsp wagon in 2007 | |
| 20:56 | <alkisg> ...ltsp was a looooooooot faster/efficient :)
| |
| 20:57 | At some point we tried to combine them, ltsp + citrix on top, but then we realized noone wanted citrix after working with ltsp :)
| |
| 20:57 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
| 20:57 | <vagrantc> :)
| |
| 20:59 | <rubberduck77> do you know working installations over slow uplinks??
| |
| 21:01 | <alkisg> I think at that point we had adsl with 256 download / 64 upload or so, I don't remember. It was working for a couple of clients, but not for the whole classroom of 8+1 clients
| |
| 21:01 | <vagrantc> there's NX and that other project that's forked and updated it
| |
| 21:02 | the name slips my mind
| |
| 21:02 | <alkisg> x2go
| |
| 21:02 | <vagrantc> x2go
| |
| 21:02 | hah
| |
| 21:02 | <alkisg> !x2go
| |
| 21:02 | <ltsp> x2go: x2go is an NX-based suite of applications that allow logging in to a remote X server from any OS. It's much more efficient than VNC over slow network. More info: http://www.x2go.org/
| |
| 21:03 | <vagrantc> i should really experiment with it sometime
| |
| 21:04 | <alkisg> It very frequently has issues because of stale sessions
| |
| 21:04 | <rubberduck77> @vagrantc the screen kiosk... what parameters will be $1 $2??
| |
| 21:04 | <alkisg> So me and others that have tried it, switched to plain ssh + reverse vnc...
| |
| 21:11 | <vagrantc> alkisg: i've let the ltsp-docs package pretty much fall through the cracks assuming it won't be in debian buster ... but now i'm realizing that's the source of the lts.conf manpage
| |
| 21:12 | the documentation is out of date enough ... i figured it was worth letting it go
| |
| 21:12 | but now i'm not so sure
| |
| 21:12 | <alkisg> vagrantc: it's still useful,I think we shouldn't make any big changes there and let it be until ltsp6 comes along where we replace it
| |
| 21:13 | E.g. I'm frequently saying "read about LDM_HASH_PASSWORD" in `man lts.conf`; I don't think we document things like that elsewhere
| |
| 21:13 | <vagrantc> i think there are a handful of patches for it floating around in the debian bug tracker and/or launchpad ... should apply those then and get it back into buster
| |
| 21:13 | alkisg: yeah, waiting for ltsp6 has been part of my hesitance to spend any significant energy on updating it
| |
| 21:14 | but that's turning out to be a long wait :/
| |
| 21:14 | * alkisg hopes we'll find funding for that some day :) | |
| 21:14 | <alkisg> Maybe in a future gsoc...
| |
| 21:22 | <rubberduck77> Is there a roadmap available for ltsp6?
| |
| 21:23 | <alkisg> Hyperbyte: wth? http://wiki.ltsp.org/wiki/6_Solutions_To_Increase_Penis_Size
| |
| 21:23 | spam bots?
| |
| 21:24 | rubberduck77: there are some dev: pages in the wiki, e.g. http://wiki.ltsp.org/wiki/Dev:GSoC
| |
| 21:24 | But nothing concrete
| |
| 21:24 | <||cw> yeah you need captcha on any wiki these days
| |
| 21:24 | <alkisg> This page was last modified on 15 October 2018, at 22:32.
| |
| 21:27 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 21:29 | <rubberduck77> @alkisg: sound like a "complete" reimplementaiton...!?!
| |
| 21:34 | <vagrantc> rubberduck77: pretty much
| |
| 21:34 | <rubberduck77> do you have a time schedule on that?
| |
| 21:35 | and development resources?
| |
| 21:35 | <vagrantc> a lot of the current LTSP codebase is generating an ltsp chroot, which has been discouraged for years in favor of the chrootless model
| |
| 21:35 | it would greatly simplify a lot of things
| |
| 21:36 | rubberduck77: no schedule and not really any resources beyond a few volunteers here and there
| |
| 21:44 | josefig has joined IRC (josefig!~josefig@unaffiliated/josefig) | |
| 21:46 | <vagrantc> there have been a few GSoC and Outreachy projects, but they are limited in duration, so don't sustain long-term maintenance
| |
| 21:49 | the good news is it morely works despite all that! :)
| |
| 21:50 | <quinox> it works great
| |
| 21:50 | <vagrantc> er, more-or-les
| |
| 21:50 | s
| |
| 21:50 | <quinox> I have been using it for 8 years now, really happy with it
| |
| 21:50 | <vagrantc> or mostly .. hah.
| |
| 21:51 | <rubberduck77> The other listed developers no longer involved in further development plans, or all busy ?
| |
| 21:52 | <vagrantc> several busy with other things, or changed companies, etc.
| |
| 21:53 | the ltsp-cluster stuff mentioned earlier was largely the work of a few of the ltsp developers at a specific company, that eventually changed it's business model and no longer used ltsp, for example
| |
| 21:53 | <rubberduck77> with ltsp6 is seems, that cluster-stuff in the old manor is no longer needed, right?
| |
| 21:54 | <vagrantc> right
| |
| 21:54 | a lot of stuff isn't needed
| |
| 22:02 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3101:400:8c1b:8441:9019:ed7a) | |
| 22:07 | <rubberduck77> dnsmasq and tftp is needed to support out-of-the-box configurations, right?
| |
| 22:13 | as I saw in another thinclient implementation; they are using LDAP to send/recv configuration etc.
| |
| 22:30 | <vagrantc> dnsmasq can server both tftp and dhcp and most interestingly, proxy dhcp where it can inject additional information needed to network boot
| |
| 22:31 | tftp is kind of the lowest common denominator for a download protocol for network boot... it's widely supported
| |
| 23:10 | Natureshadow has left IRC (Natureshadow!45d1515d22@commu.teckids.org, Read error: Connection reset by peer) | |
| 23:30 | josefig has left IRC (josefig!~josefig@unaffiliated/josefig, Ping timeout: 272 seconds) | |
| 23:31 | kjackal has left IRC (kjackal!~quassel@2a02:587:3101:400:8c1b:8441:9019:ed7a, Remote host closed the connection) | |
| 23:31 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3101:400:8c1b:8441:9019:ed7a) | |
| 23:39 | kjackal has left IRC (kjackal!~quassel@2a02:587:3101:400:8c1b:8441:9019:ed7a, Ping timeout: 252 seconds) | |
| 23:44 | josefig has joined IRC (josefig!~josefig@unaffiliated/josefig) | |