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


Channel log from 26 July 2015   (all times are UTC)

01:30telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
01:32telex has joined IRC (telex!teletype@freeshell.de)
01:52AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-gskjudcituelpyfr, )
04:24vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
04:28lmds__ has left IRC (lmds__!~lmds@tui.pi-et-ro.net, Ping timeout: 246 seconds)
04:52gbaman has joined IRC (gbaman!~gbaman@82.20.71.114)
05:23ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
05:32gbaman has left IRC (gbaman!~gbaman@82.20.71.114, Remote host closed the connection)
07:34gehidore has left IRC (gehidore!~username@unaffiliated/man, Quit: WeeChat 1.2)
07:34Phantomas has joined IRC (Phantomas!~phantomas@ubuntu/member/phantomas)
07:34gehidore has joined IRC (gehidore!~username@unaffiliated/man)
10:10gbaman has joined IRC (gbaman!~gbaman@dab-ntm1-h-75-10.dab.02.net)
10:43gbaman has left IRC (gbaman!~gbaman@dab-ntm1-h-75-10.dab.02.net, Ping timeout: 244 seconds)
11:04warren_2 has joined IRC (warren_2!~warren@fedora/wombat/warren)
11:05kwmiebach has left IRC (kwmiebach!sid16855@gateway/web/irccloud.com/x-xqgxjwqqxlatxfjn, *.net *.split)
11:05warren has left IRC (warren!~warren@fedora/wombat/warren, *.net *.split)
11:05warren_2 is now known as warren
11:14kwmiebach has joined IRC (kwmiebach!sid16855@gateway/web/irccloud.com/x-rdpwbczlrlnabqbc)
11:15gdi2k has left IRC (gdi2k!~gdi2k@180.191.116.224, Remote host closed the connection)
11:33telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
11:34telex has joined IRC (telex!teletype@freeshell.de)
11:46work_alkisg has joined IRC (work_alkisg!~alkisg@clnt-dide.ioa.sch.gr)
11:49work_alkisg is now known as alkisg
11:51
<alkisg>
13:29 <Hyperbyte> work_alkisg, hey hey. Any idea about how LTSP works on Ubuntu MATE 15.04?
11:51
Hyperbyte: I'm on Ubuntu mate 14.04.2, it works fine with only a few fixable glitches
11:52
I've no idea about non-LTS Ubuntu versions though, I don't use them except sometimes for debugging
11:53
I'm guessing that it will have a few issues with overlayfs...
12:16FGXR6 has joined IRC (FGXR6!~phantom@ppp121-44-94-168.lns20.syd4.internode.on.net)
12:17F-GT has left IRC (F-GT!~phantom@ppp121-44-29-57.lns20.syd4.internode.on.net, Ping timeout: 244 seconds)
12:17adrianorg has left IRC (adrianorg!~adrianorg@186.215.16.42, Ping timeout: 246 seconds)
12:20adrianorg has joined IRC (adrianorg!~adrianorg@177.204.78.198.dynamic.adsl.gvt.net.br)
13:04
<Hyperbyte>
alkisg, overlayfs, why?
13:05
<alkisg>
Overlayfs has been upstreamed and it started using a different syntax
13:05
So the old Ubuntu syntax (without workdir=) is now incompatible
13:05
(upstreamed in the kernel)
13:06
<Hyperbyte>
mhmmmm
13:15alkisg has left IRC (alkisg!~alkisg@clnt-dide.ioa.sch.gr, Quit: Leaving.)
13:17work_alkisg has joined IRC (work_alkisg!~alkisg@srv1-dide.ioa.sch.gr)
13:38vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
13:42work_alkisg is now known as alkisg
13:42* alkisg waves to vagrantc
13:43
<alkisg>
Long time no see :)
13:43
Our time difference is starting to show, in the past it didn't matter much... :D
13:43
*timezone
13:45
<vagrantc>
heh
13:45
i've not been on irc as consistantly lately
13:46
<alkisg>
So, are we doing any ltsp hackfests around debcamp?
13:46
Or bug squashing, whatever...
13:57
<vagrantc>
yes, please!
13:58
august 9th through 14th is the debcamp portion, which i'll have the most flexibility on
13:58
less likely to be conflicting talks and such
13:59
<alkisg>
Cool, I'll try to reserve those dates for ltsp. Phantomas, will you also be available then?
13:59
vagrantc: any specific things that you'd like us to work on?
14:00
<vagrantc>
alkisg: i think the biggest blocker to ltsp moving forward is the lack of support for pam-based authentication
14:01
<alkisg>
True, but is it something that we can work on in the hackfest, or is it more of a one-man-show, to be solved by whoever has time to find and code a proper solution?
14:02
<vagrantc>
alkisg: so i don't know about figuring out how to hook the parts of libpam-sshauth into other pam modules that we need...
14:03
<alkisg>
Is libpam-sshauth the correct way to go, and we're only lacking a few integration info?
14:03
Or should we be looking into some more mature solution, like samba, ldap, whatever?
14:03
<vagrantc>
alkisg: honestly, anything we can do that's moving forward and showing innovation might be enough to rekindle interest in LTSP in general
14:03
<alkisg>
E.g. `ltsp-config nis` or `ltsp-config samba`...
14:03
<vagrantc>
alkisg: yeah, that's my question
14:04
i now have some experience with samba's AD support ... though i'm not sure that's a good approach either
14:04
<alkisg>
A couple of years ago I asked Phantomas to check samba 4, and he did, and he told me it could work fine as an authentication mechanism for ltsp
14:05
<vagrantc>
ah, so this gets to the idea of "support one authentication method by default out of the box without making it difficult to use others"
14:06
<alkisg>
Right, whoever knows how to configure ldap should be able to do so without ltsp getting in his way
14:06
<vagrantc>
i have a lot to learn about samba's authentication methods ... haven't really found ways to fully support it without running windows GUI tools, but i think that's just a matter of research.
14:07
<alkisg>
I think it's a very big topic to cover in debcamp though...
14:07
And, it's possible to keep working in ltsp ...5, without solving the authentication problem yet
14:07
<vagrantc>
other things like ltspd ...
14:08
<alkisg>
Right
14:08
<vagrantc>
i guess there just seems to be a lack of inspiration around LTSP... so i guess i'm grasping at what exciting new feature would get people excited
14:08
reinvigorate interest
14:09
(while at the same time re-using more existing code, rather than writing it ourself)
14:09
<alkisg>
I was thinking that a "boot configuration daemon" and a "boot configuration client" are more general concepts that should be separate by ltsp, but used by it
14:10
"flexible boot" could be a name for the sub-project
14:10
<vagrantc>
and so there's the rub. we could probably implement LTSP with ansible, puppet, chef, etc.
14:10
<alkisg>
Liveboot, casper, standalone computer labs could benefit from it
14:10
<vagrantc>
and people will be highly opinionated on which approaches to use
14:10
dracut, initramfs-tools, etc.
14:11
<alkisg>
I don't think ansible, puppel, chef etc can configure a system for different boot needs
14:11
They're mostly about post-boot configuration, aren't they?
14:11
<vagrantc>
yes, i've often thought live iage boot projects, such as deian-live and casper could really be merged into LTSP
14:11
alkisg: what exactly do you mean about "boot needs" ?
14:12
<alkisg>
Where is the root file system? nfs, nbd...
14:12
Where is /home?
14:12
Where is the swap?
14:12
<vagrantc>
they can be used to configure the server, which can tell the clients their initial boot setup
14:12
<alkisg>
What user authentication scheme should I use?
14:12
Which resolution? Which user to autologin?
14:12
All the things that ltsp-client currently implements, and more
14:13
<vagrantc>
all of those things seem very configurable with any of the above-mentioned tools
14:13
<alkisg>
You can tell ansible to configure a xorg mode?
14:13
<Hyperbyte>
alkisg, any tips upgrading 12.04 Gnome classic LTSP to 14.04 MATE LTSP (thin clients)? Can I just do upgrade of the OS and see everything work at once, or should I do a clean install?
14:13
<alkisg>
Hyperbyte: it should work, but it's ubuntu, sometimes it just breaks :)
14:14
Backup, upgrade, install mate-desktop, and test
14:14
(and rebuild chroot)
14:14
<vagrantc>
alkisg: i'm most familiar with ansible having worked with it a couple weeks now, but basically you tell it what state you want and possibly how to get there, and it checks that that state is present.
14:14
<alkisg>
vagrantc: the problem isn't how to get to some state, is how to define the state
14:15
With ansible, the ltsp users would have to re-write all the init-ltsp.d code themselves...
14:15
<vagrantc>
alkisg: it provides many modules that make it easier to define states, configuration, etc.
14:15
<alkisg>
Let's take one example, autologin
14:15
Suppose that we want to support lightdm and gdm
14:15
<vagrantc>
we could write a set of ansible bits that re-implement init-ltsp.d, yes.
14:16
<alkisg>
So there, the biggest part is to find which files to touch in which versions of lightdm and gdm
14:16
Once you have that, the implementation is trivial
14:16
I think ansible will only help us in the "trivial" part
14:16
Not in the real work, i.e. to find which files we need to configure and on what conditionals
14:17
<vagrantc>
sure, though it provides a fairly elegant way of defining those trivial bits.
14:17
<alkisg>
For example?
14:17
Things like "append that string to that file"?
14:17
<vagrantc>
as opposed to a bunch of random sed or shell scripts
14:17
yes, a lot of that sort of thing
14:17
<alkisg>
That's our coding decision, we could easily have a library instead
14:18
<vagrantc>
sure, but it handles a lot of the checks such as "file already contains that line" or "exactly where in the file should that line be" and such
14:18
<alkisg>
The real work is the parts that check if lightdm > xxx_version is installed, then modify that file, otherwise modify the other file, but if gdm is installed then modify yet another file...
14:18
<vagrantc>
right, that's the harder work
14:19
<alkisg>
I think the file "sed'ding" can be implemented with a small library, I don't think it's a big deal
14:19
<vagrantc>
i've even seen nightmarish things like gnome3 behaves badly when started from lightdm, so depending on the desired desktop, it should probably even start a different display manager...
14:19
<alkisg>
python has shell file parsers, ini-file parsers etc
14:19
<vagrantc>
yes, but ansible has already done a lot of that parsing
14:20
there are libraries to do all that stuff, but ansible is a reasonably nice user-interface to those libraries
14:20
<alkisg>
How would you say in ansible, "add or modify LDM_AUTOLOGIN=True under [mac:address:xxx] in the lts.conf file, which is ini-like"?
14:20
<vagrantc>
but, like i said, some people probably hate ansible and want chef, or puppet, or whatever, and i don't want to commit us to a single codebase ...
14:21
<alkisg>
I think we just need 10 such functions
14:21
<vagrantc>
but it does feel like we'll be reimplementing a lot of things
14:21
<alkisg>
I can implement them in python, you can implement them in ansible, and we can let others implement them however they want
14:21
I think that's a couple of days work, not a big deal
14:21
I don't think it's significant...
14:22
<vagrantc>
sure.
14:22
alkisg: although the example you give is exactly the sort of thing ansible is good at
14:22
i suspect puppet and chef also
14:22
<alkisg>
The hard work is finding which files to edit, not the editing part per se
14:22
<vagrantc>
or propellor! :)
14:22
<alkisg>
I think that's what "flexible-boot" should target
14:23
To define a set of directives that could come either from a server/daemon or from static files in /etc, and to transform them to file edits
14:23
Then ltsp, casper, liveboot, and even other distros could use it
14:24
And I think it should have minimal dependencies
14:25
I think that we can implement the daemon and the client part in a week, not all of it, but enough to be the ..new ltsp-client
14:25
<vagrantc>
minimal dependencies meaning what?
14:26
server-side python, client-side shell?
14:26
<alkisg>
I don't mind about client-side python either
14:26
But not xorg or gtk or other DE-specific things
14:27
Modifying ini files from shell doesn't sound like a good idea, so the sed'ding library would probably not be written in shell
14:27
<vagrantc>
so, essentially, just doing all the stuff we're doing in init-ltsp.d (or should be), and some server-client interaction ?
14:28
<alkisg>
Right
14:28
The server daemon will allow us for a lot more flexibility that lts.conf though
14:28
*than
14:28
It's essentially what we were planning about ltspd
14:29
<vagrantc>
sure
14:29
<alkisg>
So for example we can check server load balancing, we can keep track of which clients have booted and in which state they are,
14:29
and we can even loop-mount .vdi images and serve the kernel/initrd via http
14:30
(so ltsp-update-kernels wouldn't be necessary, tftp would only be needed to download undionly.kpxe)
14:30
<vagrantc>
ah, so it would even handle the OS boot?
14:30
<alkisg>
It's possible, if we want it to...
14:30
<vagrantc>
could even implement a tftp server in python, if we really needed to
14:30
<alkisg>
I don't think we need it though,
14:31
because it's mostly used for x86, where undionly.kpxe works fine,
14:31
<vagrantc>
we're seeing more and more interest in arm, with raspberry pi and some other things springing up
14:31
or perhaps i'm only seeing the parts i'm interested in :)
14:31
<alkisg>
while for e.g. pi the kernel/initrd is local to the sdcard, and once the initrd is loaded it can then access the configuration from http directly from the daemon...
14:32vervelak has left IRC (vervelak!~vervelak@139.91.248.3, Remote host closed the connection)
14:32
<alkisg>
The flexible-boot client can have a script to update the local kernel/initrd from the image, if it's newer
14:32
And automatically reboot to load the newer versions
14:32
<vagrantc>
there are a number of promising ARM LTSP clients that could network boot with only u-boot on local media, but would require tftp
14:33
<alkisg>
If they have local media, they can have a kernel/initrd there, automatically updated
14:33
Is there any non-x86 architecture that uses PXE and that doesn't need local media?
14:34
<vagrantc>
why download 1-20MB of files to local media when .5MB will do?
14:34
actually, even debian is a 3MB kernel with a 18MB initrd now...
14:35
<alkisg>
For example, ipxe supports 50 NICs. The linux kernel supports 500 NICs.
14:35
Putting ipxe on local media covers a lot less cases than putting the linux kernel on local media
14:35
And, it supports a lot less architectures
14:36
The kernel is what will drive the media; relying on its network drivers to access the network does make sense...
14:36
<vagrantc>
i guess i'm just talking about arm, which doesn't typically support PXE (although there's some PXE-like behavior implemented in u-boot for many boards).
14:36
<alkisg>
Is there any use cases where the client will have a 10 MB sdcard and not fit the kernel/initrd?
14:36
It's also faster for the clients to cache the slow tftp part locally...
14:37
<vagrantc>
it's just the local media is often very slow, so updates would take maybe a minute or two vs. a couple seconds
14:37
<alkisg>
The oldest sdcards have 10MB/sec, about 100 mbps, don't they?
14:37
<vagrantc>
and u-boot updates less often that the kernel ... mind you, i'm talking about some pretty niche stuff here
14:38
i don't think we should spend the bulk of the time discussing ARM booting, but i am interested in it and have a fair amount of experience at this point
14:38
<alkisg>
I think if we put code for automatic updates of a local kernel+initrd, we'll support all of the architectures while requiring only 30 mb of local media...
14:39
Anyway that's just one of the things the daemon might do in the future, if we want it to
14:39
<vagrantc>
oh, you mean as a standard practice?
14:39
<alkisg>
Yes, by an init-ltsp.d or initramfs script in the ltsp code base
14:39
ltsp.update-local-kernel=/dev/sda1 or something
14:40
<vagrantc>
i must say, one of the things i've always advocated for LTSP as being safe to try it out as it won't mess with your local filesystems by default ... so would want safeguards there
14:41
<alkisg>
Anyway, the main question is... we're looking to code ltspd and to update ltsp-client so that we remove all LDM_* directives etc. I think we should take the chance and re-develop them as a separate project, used by ltsp and possibly others.
14:41
Question, do we want to do that? If yes, I'll tell Phantomas to prepare so that we have something workable at the end of debcamp
14:42
It won't conflict with ltsp-client, both can be installed simultaneously
14:42
<vagrantc>
sounds good, although i'm not sure how likely we'll be integrating all the other projects that do some of that kind of thing
14:42
<alkisg>
So people can migrate in their own time
14:43
<vagrantc>
now you're talking! :)
14:44
<alkisg>
E.g. if we have init=/sbin/init-ltsp, we're calling ltsp-client which is using lts.conf, if we have init=/sbin/flexible-boot, then we're calling the newer client...
14:44
The newer client gets its configuration from the daemon, while ltsp-client will keep using lts.conf
14:44
<vagrantc>
alkisg: i'm almost wondering if we don't implement an API and then an implementation, which could be compatible with other backends...
14:44
makes sense to me!
14:45
<alkisg>
I think the implementation has 3 main parts:
14:45
<vagrantc>
we basically need hooks into the bootloader, the initramfs, and the init wrapper...
14:45
<alkisg>
1) define the directives that we want, and document them. E.g. AUTOLOGIN_USER=xxx, XRANDR_MODE_0=yyy
14:46
2) find the files that we need to edit in order to implement them
14:46
3) ...do the actual implementation
14:46
<vagrantc>
me would like to drop the ALL_CAPS trend
14:46
<alkisg>
The (3) part is actually the easiest... :)
14:47
I'd love to drop the caps as well, but that would mean that we switch to configuration files that don't have shell syntax anymore
14:47
I.e. directive != environment variable
14:47
<Phantomas>
Which is great :P (Hello)
14:48
I'll be available alkisg, yes
14:48
<alkisg>
With the proper sed'ding library, most of the directives implementation would be small... add that line to that file... the programming language wouldn't be significant there, we could easily use python without imposing a big learning curve
14:48
Hi Phantomas, nice!
14:50
The client implementation is mostly /usr/share/ltsp/init-ltsp.d/ and /usr/share/ldm/rc.d/. Most of them are small scripts. The large ones like X01-localapps shouldn't be shell scripts anyway...
14:52
vagrantc: so, do we have the OK to start coding flexible-boot? :)
14:54
<vagrantc>
alkisg: huh? shell doesn't require ALL_CAPS
14:55
alkisg: how did i get the hat of authority?
14:55
<alkisg>
Exported environment variables in shell are in CAPS, not because of syntax requirements but because of programming style...
14:55
vagrantc: you'll be the one to package it and push it to debian :D
14:55
<vagrantc>
aha.
14:56
alkisg: ok, this sounds good.
14:56
alkisg: and honestly, it will probably make it easier to move towards the pam auth stuff
14:56
<alkisg>
I think so too
14:57
vagrantc: if you have any good ideas about the project (flexible-boot) name... :)
14:57
<vagrantc>
alkisg: so, are you talking about the clients running code handed off from the server, rather than scripts on the filesystem?
14:57
<alkisg>
Scripts on the filesystem
14:57
<vagrantc>
alkisg: it would make things like NBD image regneration less necessary if we could pass the scripts dynamically
14:58
<alkisg>
Each script would implement *and* document (doxygen-style) a directive
14:58
We can send code to the client if we want to, but I also want to support server-less configuration, e.g. from cached files or from files in /etc/flexible-boot
14:58
<vagrantc>
alkisg: one thing that storing boot stuff in local media allows for is storing security certificates and actually having a secured network boot
15:00
another "desired feature" but we should support insecure booting too, of curse :)
15:01
<alkisg>
We can also have the server sign the scripts or files that it sends to the clients, if we want to
15:01
And even encrypt them...
15:01
<vagrantc>
right
15:02
<alkisg>
E.g. when the client arrives at the login manager, it can ask the server for the whole user list, and it can put it in passwd... authentication problem solved :P
15:02
and then we can use something like LDM_PASSWORD_HASH for the shadow entry, after login
15:02
<vagrantc>
alkisg: so basically we'll want to do a review of what's in init-ltsp.d and ldm/rc.d and decide what needs to be re-used, dropped or re-implemented
15:03
<alkisg>
OK I'm just joking, but it could help while moving to lightdm, and before a real solution is found...
15:03
Right
15:03
I think we should start with a wiki page that mentions the directives and what they're supposed to do
15:04* vagrantc wonders about authentication credentials for wiki.ltsp.org
15:04
<vagrantc>
alkisg: admittedly, my head has been in ansible so much the past few weeks, i can't help but thinking of re-implementing LTSP in ansible.
15:04
<alkisg>
I do have an account there, I think you have one too
15:04
<vagrantc>
i have one, i just don't remember if i know how to log in
15:04
<alkisg>
vagrantc: can you give me an example of ansible syntax?
15:05
It's quite possible that we can use the same syntax in our "scripts"...
15:05
<vagrantc>
https://docs.ansible.com/ansible/ini_file_module.html
15:05
it's mostly a lot of yaml entries
15:06
it uses all sorts of templating substitutions
15:07
<alkisg>
It seems fine to me
15:07
<vagrantc>
{{ variable }} {{ dictionary.foo.value }}
15:07
<alkisg>
Rewriting init-ltsp.d in ansible should only take an afternoon
15:07
And then rewritting it to "other-framework" another afternoon
15:08
I think it's one of the smallest tasks that we'll have to do...
15:08
vagrantc: is there any way to do conditionals, like, "if lightdm version is > xxx then do this, otherwise do that"?
15:09
conditionals based on the output of some command
15:09vmlintu_ has joined IRC (vmlintu_!~vmlintu@dsl-jnsbrasgw2-58c07e-86.dhcp.inet.fi)
15:14
<vagrantc>
alkisg: yes, there are conditionals
15:15
alkisg: there's "when" conditionals that can respond to values in variables, and you can set variables in earlier stanzas
15:16
or from other data sources
15:17
for a simple example, you'd have a stanza that sets the variable, a stanza that responds when variable == x, and a stanza that responds when variable == y ... and you can fire off additional stanzas when a particular line succeeds
15:17vmlintu_ has left IRC (vmlintu_!~vmlintu@dsl-jnsbrasgw2-58c07e-86.dhcp.inet.fi, Ping timeout: 240 seconds)
15:18khildin has joined IRC (khildin!~khildin@ip-80-236-214-53.dsl.scarlet.be)
15:19
<alkisg>
Cool. I wonder if sysadmins find it simpler than e.g. ...python code that uses a library
15:20
<vagrantc>
variables are defined like {{ foo }} and it supports lists and dicts.
15:21
it's certainly easier to read that shell code... :)
15:22
- name: add users to src group
15:22
user: name={{ item }} append=yes groups=src
15:22
with_items:
15:22
- vagrant
15:22
- alkisg
15:22
a lot of that sort of code.
15:25
<alkisg>
Well, it does save us from reimplementing and documenting a lot of stuff, so /me is fine with it
15:25* alkisg waves
15:25alkisg is now known as work_alkisg
15:26
<vagrantc>
yeah, not sure if it's a good fit or not, but it would be easy to do.
15:27
if written correctly, it's also idempotent, so you can re-run it multiple times
15:41khildin has left IRC (khildin!~khildin@ip-80-236-214-53.dsl.scarlet.be, Ping timeout: 246 seconds)
15:51vervelak has joined IRC (vervelak!~vervelak@139.91.248.3)
16:32Joito has joined IRC (Joito!3f87ff77@gateway/web/freenode/ip.63.135.255.119)
16:32
<Joito>
hello Im new
16:34
I made a computer lab in my school, and setting up edubuntu with ltps was very easy. But i wish to install LTSP in Xubuntu. Ive been trying for weeks and no luck.
16:34
does ltsp works only in 64 bit pc?
16:40
<vagrantc>
no, it works on any architecture
16:41
!ltsp-pnp
16:41
<ltsp>
ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
16:41khildin has joined IRC (khildin!~khildin@ip-80-236-214-53.dsl.scarlet.be)
16:41
<vagrantc>
Joito: check that out ^^
16:41
it's one of the easiest methods to do ltsp.
16:42
<Joito>
pnp = plug and play?
16:43
<vagrantc>
yeah, that's the idea
16:43
i fin the most important part of it is the chrootless image creation, but the whole "ltsp-pnp" idea also involves the dnsmasq proxydhcp configuration
16:44
<Joito>
ok thanks a lot i will try that now
16:56Joito has left IRC (Joito!3f87ff77@gateway/web/freenode/ip.63.135.255.119, Ping timeout: 246 seconds)
17:21Joito has joined IRC (Joito!3f87ff77@gateway/web/freenode/ip.63.135.255.119)
17:31khildin has left IRC (khildin!~khildin@ip-80-236-214-53.dsl.scarlet.be, Ping timeout: 244 seconds)
17:37gbaman has joined IRC (gbaman!~gbaman@host31-53-72-7.range31-53.btcentralplus.com)
17:42khildin has joined IRC (khildin!~khildin@ip-80-236-214-53.dsl.scarlet.be)
17:55gbaman has left IRC (gbaman!~gbaman@host31-53-72-7.range31-53.btcentralplus.com, Remote host closed the connection)
17:58Joito has left IRC (Joito!3f87ff77@gateway/web/freenode/ip.63.135.255.119, Ping timeout: 246 seconds)
18:52khildin has left IRC (khildin!~khildin@ip-80-236-214-53.dsl.scarlet.be, Ping timeout: 246 seconds)
20:10AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-vgpybdotbmhiawqg)
20:48ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)
20:49telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
20:50telex has joined IRC (telex!teletype@freeshell.de)
21:47AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-vgpybdotbmhiawqg, )
21:50gbaman has joined IRC (gbaman!~gbaman@host109-155-155-132.range109-155.btcentralplus.com)
22:04vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
23:04Phantomas has left IRC (Phantomas!~phantomas@ubuntu/member/phantomas, Quit: Leaving.)
23:21gbaman has left IRC (gbaman!~gbaman@host109-155-155-132.range109-155.btcentralplus.com, Remote host closed the connection)
23:30gbaman has joined IRC (gbaman!~gbaman@host109-155-155-132.range109-155.btcentralplus.com)
23:36gbaman has left IRC (gbaman!~gbaman@host109-155-155-132.range109-155.btcentralplus.com, Remote host closed the connection)