IRC chat logs for #ltsp on irc.libera.chat (webchat)


Channel log from 5 June 2019   (all times are UTC)

00:18vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
00:21
<Sleaker>
hmm my old ltsp setup had an asound.conf.
00:21
I don't think this is correct anymore.
00:24
oh hmm, maybe it is.
00:58
ah nevermind it's working just like before, just have to change the configured device
01:37gdi2k_ has joined IRC (gdi2k_!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com)
01:39gdi2k__ has left IRC (gdi2k__!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com, Ping timeout: 245 seconds)
02:05josefig has left IRC (josefig!~josefig@unaffiliated/josefig, Quit: Ping timeout (120 seconds))
02:06josefig has joined IRC (josefig!~josefig@unaffiliated/josefig)
02:19Sleaker has left IRC (Sleaker!quasselcor@2604:880:a:7::e1b, Ping timeout: 252 seconds)
02:19Sleaker has joined IRC (Sleaker!quasselcor@2604:880:a:7::e1b)
02:19ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Ping timeout: 246 seconds)
02:56adrianor1 has joined IRC (adrianor1!~adrianorg@177.156.226.14)
02:59adrianorg has left IRC (adrianorg!~adrianorg@177.18.179.192, Ping timeout: 272 seconds)
04:28kjackal has joined IRC (kjackal!~quassel@2a02:587:3106:1000:a895:839f:87b0:61d8)
04:40quinox has left IRC (quinox!~quinox@ghost.qtea.nl, Quit: WeeChat 2.4)
04:42quinox has joined IRC (quinox!~quinox@ghost.qtea.nl)
05:09os_a has joined IRC (os_a!~Thunderbi@195.112.116.22)
05:12alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
05:46alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 248 seconds)
06:03ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
06:37woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de)
06:43alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
08:42ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
09:44statler has joined IRC (statler!~Georg@gwrz3.lohn24.de)
09:45Jose__ has joined IRC (Jose__!53384ca6@gateway/web/freenode/ip.83.56.76.166)
09:45
<Jose__>
How do I install the hard drive on the client?
09:47
hola?
09:48Jose__ has left IRC (Jose__!53384ca6@gateway/web/freenode/ip.83.56.76.166, Client Quit)
09:48Jose__ has joined IRC (Jose__!53384ca6@gateway/web/freenode/ip.83.56.76.166)
09:48
<Jose__>
hola
09:49
queria preguntar como hago para auto montar el disco duro local en el cliente?
09:49
I wanted to ask how do I auto mount the local hard drive on the client?
09:50ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
09:50ogra has joined IRC (ogra!~ogra_@ubuntu/member/ogra)
09:51
<alkisg>
Hi Jose__
09:51
<Jose__>
hello
09:52
I wanted to ask how do I auto mount the local hard drive on the client?
09:52
<alkisg>
You can put an FSTAB_0="xx" command in lts.conf
09:52
Is it a thin or a fat client?
09:53
<Jose__>
client fat
09:54
<alkisg>
OK, use FSTAB_0="/dev/sda1 /mnt ext4 errors=remount-ro 0 1" etc then
09:54
An fstab line there
09:54
<Jose__>
gracias
09:54
<alkisg>
Normally, users in the sudo group can mount internal disks by just clicking on them in the file manager
09:54
You're welcome
09:55
<Jose__>
Would this serve for all customers?
09:55
<alkisg>
If they all have sda1 and not different partitions
09:55
What do the internal disks have?
09:55
Windows? Ntfs? linux? ext4? home?
09:57
<Jose__>
the discs are clean, it's just so they can use them. I'm doing a school project
09:57
<alkisg>
If they're clean, you can't mount them
09:57
You need to format them first
09:57
How are you going to format them, ntfs, ext4?
09:57
<Jose__>
I have them in ext4
09:58
<alkisg>
OK then the FSTAB_0 line above should work
09:58
<Jose__>
the problem is that to mount them it asks for the root account
09:58
<alkisg>
It's because they're not in the "sudo" group; use FSTAB_0
09:58
<Jose__>
in the client
10:01
I have put the line FSTAB_0 = "/ dev / sda1 / mnt ext4 errors = remount-ro 0 1" etc then and it does not load the disk
10:02
<alkisg>
You didn't put it correctly, you used spaces
10:03
<Jose__>
Spaces are added when copying
10:05
<alkisg>
Did you put this in lts.conf, and did you reboot the client?
10:06
<Jose__>
yes
10:07
<alkisg>
What's the output of this command, from the client? cat /etc/fstab | nc termbin.com 9999
10:09
<Jose__>
it was sda0, the disk is mounted but it does not appear in the file manager
10:10
<alkisg>
There's no sda0
10:10
Numbering starts from 1
10:11
<Jose__>
sorry sda
10:11
<alkisg>
OK, please paste what I asked
10:12
<Jose__>
what?
10:12
<alkisg>
(01:07:28 PM) alkisg: What's the output of this command, from the client? cat /etc/fstab | nc termbin.com 9999
10:12
Run this command on the client and tell me the output
10:14
<Jose__>
nc: getaddrinfo: Temporary failure in name resolution
10:14
<alkisg>
Internet doesn't work on the clients?
10:15
<Jose__>
yes
10:15
<alkisg>
Do you have epoptes installed?
10:16
<Jose__>
yes
10:16
<alkisg>
OK, vnc to me to help you
10:16
!vnc-edide
10:16
<ltsp>
vnc-edide: To share your screen with me, open Epoptes → Help menu → Remote support → Host: srv1-dide.ioa.sch.gr, and click the Connect button
10:16
<alkisg>
From the server
10:21
Jose__: everything is fine
10:21
Internal disks that are mounted in fstab don't show up like external disks in nautilus
10:21
They show up where you mounted them, e.g. now you mounted it in /mnt
10:22
(I closed VNC)
10:22Jose__ has left IRC (Jose__!53384ca6@gateway/web/freenode/ip.83.56.76.166, Quit: Page closed)
10:25antares_ has joined IRC (antares_!c1929682@gateway/web/freenode/ip.193.146.150.130)
10:30
<alkisg>
...you're welcome :)
11:08GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net)
11:37woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Remote host closed the connection)
11:53Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
13:00gdi2k__ has joined IRC (gdi2k__!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com)
13:02gdi2k_ has left IRC (gdi2k_!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com, Ping timeout: 252 seconds)
13:59os_a has left IRC (os_a!~Thunderbi@195.112.116.22, Quit: os_a)
15:58GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 245 seconds)
16:52vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
17:04lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-187.isotelco.net.br)
17:12
<Sleaker>
alkisg: what's the remote support thing in epoptes?
17:14
oh hmm.
17:14
does it only support VNC and console?
17:14
<alkisg>
Sleaker: nah, telepathy too
17:14
:P
17:14
Yeah, just graphics and terminal, nothing more
17:14
<Sleaker>
doesn't work with RDP though?
17:14* vagrantc thought telepathy fell out of favor
17:15
<alkisg>
Nope, it's about screen sharing, not remote desktop
17:15
rdp is mostly remote desktop, not screen sharing
17:15
<Sleaker>
ahh ok
17:16
seems like it's getting pretty close to having the same functionality as like teamviewer.
17:17
<alkisg>
Eh, it's not commercial, so it mostly have the basics; but the best parts are that it doesn't involve a teamviewer server, and that it supports handling multiple clients at once (e.g. launching a URL in 20 clients)
17:18
vagrantc: I have two options: (1) nfsroot=/srv/ltsp/vm, and put the squashfs image in /srv/ltsp/vm/ltsp.img, or (2) nfsroot=/srv/ltsp, and put the squashfs image e.g. in /srv/ltsp/images/vm.img
17:18
<vagrantc>
alkisg: i think i like the latter
17:18
<alkisg>
I went for option (1); when using chroot, it's a bit annoying to have ltsp.img in your root dir, but I think it's better than (2)
17:18
<vagrantc>
hah
17:18
:)
17:19
<alkisg>
Because (2) isn't intuitive for chroots; the nfsroot should be /srv/ltsp/vm, not /srv/ltsp
17:19
<vagrantc>
hmmm..
17:19
<alkisg>
And, we'll mostly be using VMs not, not chroots
17:19
<Sleaker>
yah just reminded me that I was wanting to look for a free tool that mirrored a lot of the functionality of teamviewer
17:19
<alkisg>
So it'll be e.g. /srv/ltsp/buster/buster.vbox and /srv/ltsp/buster/ltsp.img
17:20
<vagrantc>
alkisg: sounds fine too
17:20
<Sleaker>
alkisg: so how does the remote assistance thing work. what's the requirement on the host side?
17:21
<alkisg>
Great; so now the command line is just root=/dev/nfs nfsroot=${srv}:/srv/ltsp/${img}, and it automatically uses chroot/vm/squashfs; if automatic isn't desired, one can specify ltsp.mount=path/to/image
17:21
<vagrantc>
all the epoptes clients connect to a server you've configured, so you need epoptes-client installed on all the clients
17:21
<alkisg>
Sleaker: I spent a couple of days writing documentation; try it! http://www.epoptes.org/installation
17:22
<vagrantc>
alkisg: have you used epoptes over a WAN ?
17:22
<alkisg>
vagrantc: I overview my schools that way
17:22
<Sleaker>
alkisg: I'm specifically talking about the remote-assistance menu
17:22
doesn't seem to connect to a host.
17:22
<alkisg>
Sleaker: you installed it and it doesn't work?
17:23
<Sleaker>
I already have an install working with ltsp clients
17:23
<alkisg>
!vnc-edide
17:23
<ltsp>
vnc-edide: To share your screen with me, open Epoptes → Help menu → Remote support → Host: srv1-dide.ioa.sch.gr, and click the Connect button
17:23
<alkisg>
Try it ^
17:23
<Sleaker>
sorry, that definitely violates company stuff.
17:23
<alkisg>
I'm running this: (port forward 5500): xvnc4viewer -listen
17:23
<Sleaker>
ahhh ok
17:24
so you have to run vnc in listen mode
17:24
<alkisg>
So you just reverse connect with your x11vnc -connect to me
17:24
Right
17:24
<Sleaker>
that's the missing piece
17:24
<vagrantc>
alkisg: so the new code searches for various images and falls back to just using the NFS mount?
17:25
<alkisg>
vagrantc: priority: chroot (if /proc exists), then image, then vm; that's only in "simple" mode, this is an advanced example:
17:25
root=/dev/nfs nfsroot=${srv}:/srv/ltsp/cd ltsp.loop=ubuntu-mate-18.04.1-desktop-i386.iso,fstype=iso9660,loop,ro,,casper/filesystem.squashfs,fstype=squashfs,loop,ro
17:25
This loop mounts two things, one inside the other
17:25
<vagrantc>
alkisg: why default to chroot ?
17:25
alkisg: why mostly it won't be used?
17:26
<alkisg>
It's just the priority; of course the others will be automatically used too
17:26
So if someone has a chroot and an image, I assume he'd want to use the chroot, for fast testing, and then specify the image when he switches to production
17:26
<Sleaker>
alkisg: cool, working
17:26
<vagrantc>
alkisg: so you've got loop mounts within loop mounts? :)
17:27
<alkisg>
Right, and that way I'm able to boot an iso with ltsp code, or boot my computer from a vbox vm image!
17:27
<vagrantc>
very nice
17:27
<alkisg>
Or from an older installation at /srv/older-ubuntu
17:28
Now the syntax there is a bit tricky, but I didn't find anything better
17:28
commas for mount options; two commas to separate mount commands; and special fstype=xxx options instead rootfstype, as now I support multiple commands so one rootfstype isn't enough
17:29
<vagrantc>
alkisg: why not ltsp.loopN where it mounts them in increasing order?
17:29
<alkisg>
The same command can be used in ltsp-update-image
17:29
And in the ltsp-update-image.conf configuration file
17:30
<vagrantc>
alkisg: the double-comma seems like the ugliest part
17:30
<alkisg>
I thought about colon, but it's used in ipv6, in protocols etc
17:30
<vagrantc>
semicolon?
17:31
<alkisg>
ltsp image bla;bla
17:31
that second bla is a command, I hope noone names his image rm :P
17:31
<vagrantc>
right
17:31
<alkisg>
Same for |, &, >...
17:32
<vagrantc>
still a little shaky in my understanding as to why you can't pass multiple arguments ... ?
17:32
<alkisg>
ltsp image one two, usually would mean "update two images", not "find image two inside image one"
17:33
The most important part is to keep this simple: ltsp image i386
17:33
For the advanced things, they can just copy/paste from the docs
17:33
<vagrantc>
"ltsp image" does what now?
17:34
<alkisg>
That's ltsp-update-image
17:34
`ltsp kernel` is ltsp-update-kernels etc
17:34
<vagrantc>
it generates the cpio archive to append to the initramfs ?
17:34
<alkisg>
The squashfs image
17:34
ltsp image = ltsp-update-image
17:34
ltsp kernel = ltsp-update-kernels
17:34
<vagrantc>
oh, i thought if you're mounting a loop device within a loop device, you wouldn't generate a squashfs image
17:35
since you'd just copy the iso from your distro of choice
17:36
<alkisg>
I can't change the syntax depending on the use case; what you're saying is true if one wants to boot an .iso, but not if one wants to create a squashfs out of it for some reason
17:36
E.g. suppose that I want to create a squashfs image from the second partition of my fedora-vm; it still needs a tricky syntax
17:36
<vagrantc>
just trying to wrap my head around the issues
17:37lucascastro has left IRC (lucascastro!~lucascast@177-185-139-187.isotelco.net.br, Quit: Leaving)
17:37* alkisg did spend a lot of days on this; and he's happy that the simple cases are very simple: nfsroot=/srv/ltsp/vm, and `ltsp image vm`
17:37
<vagrantc>
ok, so you wouldn't necessarily just copy the partition wholesale ... you might want to make a sanitized image that they actually boot
17:37
<alkisg>
Right; with cleanup and everything
17:37
<vagrantc>
alkisg: yeah, just trying to catch up with you :)
17:38
<alkisg>
The same code is used for extracting kernels, for generating squashfs images, and for nfsroot mounting
17:38
And, in kernel cmdline, bash cmdline, and configuration files
17:38
So there's a lot of different demands from all these
17:38
<vagrantc>
right
17:39
<alkisg>
So to boot a different image than the defaults, it would be e.g.: nfsroot=/srv/ltsp/vm ltsp.image=vm-flat.vmdk
17:39
What sounds better there? ltsp.image, ltsp.loop, or ltsp.mount=xxx?
17:39
Usually it'll be a simple image, but the same parameter will also support crazy multiple commands
17:40
<vagrantc>
i think loop is too specific ... image or mount
17:40
<alkisg>
+1, I'm between those too
17:40
<vagrantc>
are there anything that would be mounted that isn't an image?
17:40
<alkisg>
Sure, for example to boot from a subdirectory, one can specify that one
17:41
<vagrantc>
then i'd lean towards mount
17:41
<alkisg>
E.g. if you have /srv/old-ubuntu in some partition, you can specify that in some submount
17:41
Great
17:41
Although `ltsp image [mount]` sounds a bit worse than `ltsp image [image]`
17:41
<vagrantc>
hmmmm...
17:42
<alkisg>
Tricky :P
17:42
<vagrantc>
they both have their challenges
17:42
<alkisg>
I'd love to use "root" there, but noone uses "root"; when we have a root in a subdir, we even call it "chroot", not "root"...
17:43
<vagrantc>
well, "root" is an overloaded word already
17:43
could mean the user root, could mean the rootfs
17:44
<alkisg>
Yeah
17:44
<vagrantc>
now i'm waffling and preferring ltsp.image=...
17:45
<alkisg>
set nfs_image root=/dev/nfs nfsroot=${srv}:/srv/ltsp/${img} ltsp.image=ltsp.img
17:45
That's what I currently settled on too :)
17:45
And in the extreme case someone needs a double loop, oh well, he'll understand
17:45
<vagrantc>
a chroot can be thought of as an image anyways ... it's not a huge leap
17:46
if they're doing multiple layers of loop mounts, let's just say they had better be able to understand what they're doing
17:46
<alkisg>
`ltsp image chroot` actually means " generate a squashfs image from that root", so it's ok,
17:46
while in kernel cmdline, it's just nfsroot=${srv}:/srv/ltsp/${img}, without specifying ltsp.image
17:46
<vagrantc>
ltsp.image is just for the complicated multi-level loop mounts?
17:46
<alkisg>
Right
17:47
That's why I default to chroot first
17:47
This whole ltsp image thing was strange; I spend a few days writing man pages, then code commends, then walking and thinking... and after that, coding was done in a day
17:47
Design time >>> programming time
17:47
<vagrantc>
so you call "ltsp image chroot" it builds an image in /srv/ltsp/chroot/chroot.img ?
17:48
<alkisg>
/srv/ltsp/chroot/ltsp.img
17:48
<vagrantc>
always named ltsp.img ?
17:48
<alkisg>
And I put ltsp.img in ltsp-update-image.excludes
17:48
Yes
17:48
And there's ltsp.old too (or ltsp.img~ if you prefer)
17:48
<vagrantc>
earlier you had mentioned /srv/ltsp/buster/buster.img ?
17:48* vagrantc prefers .old
17:48
<alkisg>
buster-flat.vbox is the vm, if one uses vbox fms
17:48
*vms
17:49
so it's chroot, squashfs = ltsp.img, or vm = chroot-flat.vm
17:49
Since vbox names it that way by using the GUI, I special-cased it
17:49
If someone asks for qemu/libvirt/whatever names, I can special-case them too
17:49
<vagrantc>
and the correlary to "ltsp-update-image --cleanup /" ?
17:50
they're usually just DISK.img
17:50
<alkisg>
I'm between `ltsp image --cleanup /` or forcing them to use a symlink first, to have a name
17:50
Not very important, code-wise...
17:52
About special dirs, I support 3 of them, BASE_DIR (the VMs/chroots), EXPORT_DIR (the nfs export+squashfs), and the TFTP_DIR; they all default to /srv/ltsp
17:53
I may rename BASE_DIR to IMAGE_DIR
17:55
Btw, if someone feels like triaging bugs that affect ltsp... https://bugs.busybox.net/show_bug.cgi?id=11941
18:00
(08:50:05 PM) vagrantc: they're usually just DISK.img ==> ok another reason to prefer ltsp.img then, to avoid clashes
18:00
<vagrantc>
where DISK could be any arbitrary thing
18:01
including "ltsp"
18:01
<alkisg>
if they do want to shoot themselves in the foot, we can't prohibit that
18:01
<vagrantc>
typically whatever you named the virtual machine
18:01
<alkisg>
One could also name their vbox vm /opt/ltsp/images/i386.img, and try to generate a squashfs to overwrite it :P
18:02
<vagrantc>
well, i don't think it's unreasonable for a virtual machine that is your LTSP server to be named "ltsp"
18:02
<alkisg>
/srv/ltsp/ltsp is the tftp dir
18:02
So they'd overwrite the tftp dir there
18:02
<vagrantc>
well, these images will typically be in /var/lib/libvirt/images/ anyways
18:02
<mwalters>
alkisg: a while back I was mucking about with uefi booting and had an issue where after loading grub, it was suuuuuuper slow to boot, and you pointed me at something and that fixed it... any chance you remember what that "something" was??? ;)
18:02* vagrantc mostly uses LVM anyways
18:03
<vagrantc>
alkisg: so if the images aren't typically stored in the /srv/ltsp/ tree, is it even an issue?
18:03
<alkisg>
Ah, btw, for images I'll only support flat images for now; no qcow, no lvm
18:04
<mwalters>
Basically: I've got that wireless site set up... but as right after selecting the OS from the grub menu, it only hits at most 50Mbps, where I know the link is capable of much more (and once fully booted, is waaaay faster)
18:04
<vagrantc>
lvm are just partitions like any other
18:04
<alkisg>
No not at all; one would just have to define BASE_DIR or pass it as a parameter to ltsp
18:04
vgchange isn't available by default in initramfs's
18:04
Additional code is needed to handle lvm
18:04
It's not just losetup + mount
18:04
<vagrantc>
alkisg: it is if the machine it's booting uses lvm
18:05
<alkisg>
Yes, but ltsp image may not have it
18:05
We're not strictly inside an initramfs now
18:06
<vagrantc>
alkisg: the hard part is you've been in this so deep you may have specific mental terminology that i'm not sharing :)
18:06
so i'm having a hard time following
18:06
overall i trust where it's going, though
18:07
<alkisg>
I started with using qemu-nbd, which supports lvm and qcow and all, but it got too complicated too fast
18:07
So I thought I'd start with plain flat images first, and we might add support for lvm etc later
18:07
<vagrantc>
well, i'm thinking you could generate the image from an lvm volume no different than if you generated it from a raw partition ... am i missing something?
18:08
are we talking about the same thing?
18:08
<alkisg>
The lvm volume isn't loop0p1, it's /dev/mapper/things
18:08
And it can't be unmounted with umount/losetup, it needs lvchange and things
18:09
It can be done, but I think that if we're going there at some point, we'd better use qemu-nbd or libguestfs
18:09
So as to support compression and different image types too, vdi, qcow and all
18:10
<vagrantc>
i'm not sure at what phase in the process you're saying it can't be done, if the system has /dev/mapper/PARTITION, then you can use it just like /dev/sda ... no other code required
18:11
are you talking about an image that contains partitions that contain lvm volumes?
18:12
right now, i can run "ltsp-update-image --cleanup /" on a system where /dev/mapper/SOMENAME is mounted as /
18:12
are you saying that is non-trivial?
18:12
or something else?
18:14
and of course, feel free to postpone this :)
18:22statler has left IRC (statler!~Georg@gwrz3.lohn24.de, Remote host closed the connection)
18:30
<alkisg>
vagrantc: I'm saying that managing /dev/mapper needs code
18:30
Once it's there, it's trivial; but to mount/unmount it, it needs different commands
18:30
E.g. lvchange -an or something to unmount it, if I remember well
18:31
ltsp image needs to mount and umount everything inside the image, so it needs lv* commands
18:32
<vagrantc>
you just use mount and umount on the /dev/mapper/NAME
18:32
lvchange is used to make them active or inactivate them
18:33
<alkisg>
Of course if someone writes a wrapper that sets up /dev/mapper/*, then runs `ltsp image`, then umounts /dev/mapper/*, it'll work
18:33
So you can do it with just losetup and mount, without using lv* ?
18:33
<vagrantc>
you run your own udev inside the image? how do you get normal device nodes?
18:33
<alkisg>
I tried it with the fedora vm and it needed vg*
18:34
Let's focus on `ltsp image`; this runs outside the vm
18:34
<vagrantc>
i'm just wondering about the simple case where the server is using lvm, and you currently do "ltsp-update-image --cleanup /" and it doesn't need any special mounting
18:35
all the device nodes are already populated, etc.
18:35
<alkisg>
/ is a dir, it doesn't involve the loop code
18:35
I'm talking about `ltsp image /path/to/vm-with-lvm.img`
18:35
<vagrantc>
ok
18:36
yes, supporting lvm inside of an image will be harder, but such images should already have all the tools needed to handle itself ... but not activation of the nodes and such.
18:36
<alkisg>
They'll have the code inside the image, not on the server where it will be needed
18:37
<vagrantc>
ok, after all that, i get what you're saying now
19:18ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
20:44Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
21:37pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 258 seconds)
21:39GodFather has joined IRC (GodFather!~rcc@143.59.184.72)
21:41pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)
21:51pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Excess Flood)
21:52pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)