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


Channel log from 14 October 2012   (all times are UTC)

00:16Parker955_Away is now known as Parker955
00:41Parker955 is now known as Parker955_Away
01:29vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
01:34darthanubis has joined IRC (darthanubis!~darthanub@cpe-66-61-35-95.neo.res.rr.com)
04:28telex has left IRC (telex!~telex@freeshell.de, Ping timeout: 260 seconds)
04:35telex has joined IRC (telex!~telex@freeshell.de)
04:40telex has left IRC (telex!~telex@freeshell.de, Ping timeout: 260 seconds)
04:45Parker955_Away is now known as Parker955
04:50telex has joined IRC (telex!~telex@freeshell.de)
05:13Parker955 is now known as Parker955_Away
05:26alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
05:35alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Read error: Connection reset by peer)
05:35alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg)
05:39mmetzger has left IRC (mmetzger!~mmetzger@99-71-214-196.lightspeed.mdldtx.sbcglobal.net, Ping timeout: 248 seconds)
05:41mmetzger has joined IRC (mmetzger!~mmetzger@99-71-214-196.lightspeed.mdldtx.sbcglobal.net)
06:21alkisg1 has left IRC (alkisg1!~alkisg@ubuntu/member/alkisg, Ping timeout: 255 seconds)
06:37alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
07:05alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg)
07:06alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 265 seconds)
07:20alkisg1 is now known as alkisg
07:44ricotz has joined IRC (ricotz!~rico@p5B2AB992.dip.t-dialin.net)
07:44ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
07:51alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
07:57bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
08:26highvoltage has left IRC (highvoltage!~highvolta@ubuntu/member/highvoltage, Read error: Connection reset by peer)
08:27highvoltage has joined IRC (highvoltage!~highvolta@ubuntu/member/highvoltage)
08:41klausade has joined IRC (klausade!~klaus@cm-84.215.156.145.getinternet.no)
08:46andygraybeal_ has joined IRC (andygraybeal_!~andy@h82.200.130.174.dynamic.ip.windstream.net)
08:47markit has joined IRC (markit!~marco@88-149-177-66.v4.ngi.it)
08:54komunista has joined IRC (komunista!~slavko@adsl-195-168-234-074.dynamic.nextra.sk)
09:17bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 272 seconds)
09:51alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
10:06alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
10:22
<muppis>
What?
10:22
I powered ltsp server off by mistake. Powered on and client just asked root's password and continued working like nothing happened.
10:23
Well, it's a fat client.
10:49alkisg_android has joined IRC (alkisg_android!~AndChat66@athedsl-152587.home.otenet.gr)
10:54komunista has left IRC (komunista!~slavko@adsl-195-168-234-074.dynamic.nextra.sk, Quit: Leaving.)
11:00alkisg_android has left IRC (alkisg_android!~AndChat66@athedsl-152587.home.otenet.gr, Ping timeout: 245 seconds)
11:05
<andygraybeal_>
muppis, the network shares might have been disconnected
11:05
i mean, i don't know.. but i would worry about that ;)
11:21andygraybeal_ has left IRC (andygraybeal_!~andy@h82.200.130.174.dynamic.ip.windstream.net, Ping timeout: 245 seconds)
11:29alkisg_android has joined IRC (alkisg_android!~AndChat66@athedsl-152587.home.otenet.gr)
11:33
<muppis>
andygraybeal, actually afterwards happened what I expected. As nbd disconnected, it didn't re-establish connection and nothing new was unable to start.
11:34alkisg_android has left IRC (alkisg_android!~AndChat66@athedsl-152587.home.otenet.gr, Ping timeout: 265 seconds)
11:57komunista has joined IRC (komunista!~slavko@adsl-195-168-234-074.dynamic.nextra.sk)
12:03alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
12:06
<alkisg>
muppis: the problem mostly isn't nbd but sshfs. nbd can reconnect / if the server is only missing for a little bit, but sshfs won't reconnect /home/username, so apps that require ~ access will fail.
12:17
<markit>
alkisg: just to know... is this coming week that you (hopefully) can have a look at KDE with ltsp, or the next one (22-28 october)?
12:19
<muppis>
alkisg, so if I got a root shell in screen 02 I should be able to reconnect sshfs as well?
12:45bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
13:00alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
13:03Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
13:16komunista has left IRC (komunista!~slavko@adsl-195-168-234-074.dynamic.nextra.sk, Quit: Leaving.)
14:08alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
14:10risca has joined IRC (risca!~risca@193.11.200.69)
14:22
<alkisg>
markit: I think that adding "-threads" to vnc increases performance a lot
14:22
Can you try it in your schools some time?
14:23
(I'm talking about broadcasting teacher screen from epoptes)
14:23
I tried it at work with only 2 clients, and the bandwidth has gone from 120 mbps to 180 mbps
14:24
file: /usr/share/pyshared/epoptes/ui/gui.py
14:24
self.vncserver = subprocess.Popen(['x11vnc', '-noshm', '-nopw', '-threads'
14:24
That's the change you need to do to test it, and open epoptes after that
14:29FGXR6 has left IRC (FGXR6!~phantom@ppp121-44-8-89.lns20.syd6.internode.on.net, Ping timeout: 240 seconds)
14:32Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 252 seconds)
14:45
<markit>
alkisg: thanks a lot, but my main problem now is KDE as fat... without that I have nothing to deploy and use with epoptes ;P
14:46
in any case I will test your suggestion as soon as possible too... is an interesting jump in performances
14:46
<alkisg>
Hmm it will take me some hours to install kde, ltsp-pnp etc and debug fat clients... let me see when I can fit that in my schedule... :-/
14:47
<markit>
alkisg: yep, I'm sorry to put that burden on you, but I've tried to understand what's going wrong and I stopped to the permission stuff
14:48
and probably if help me fix it will take much more time ;P
14:48
I'm a bit ashamed of asking you, sincerely
14:49* alkisg might do that today, otherwise I'm afraid I'll postpone it too far in the future :D
14:49
<markit>
but I'm in a impasse
14:49
oh, I cross my fingers then and stop talking distracting you ;P
14:49Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
14:52
<alkisg>
markit: will you be around in case I have questions about what's wrong with your setup?
14:53
(to put me up to speed with the problems and the paths you've tried so far...)
14:53
<markit>
as much as I can.. I've to go out with my wife for about 30 minutes (later), the rest I'm here
14:53
<alkisg>
Cool
14:53
OK, starting...
14:54
<markit>
hahaha, would be ridicolous overwise
14:54risca has left IRC (risca!~risca@193.11.200.69, Ping timeout: 272 seconds)
15:00
<alkisg>
markit: on a typical KDE system (non LTSP), where is the big user cache stored? Under $HOME or in /var/cache?
15:00
<markit>
in /var/tmp
15:00
and has kdecache-username
15:00
<alkisg>
Ty, checking...
15:00
<markit>
while in $HOME/.kde you have a symlink
15:00
in the form of cache-HOSTNAME to that
15:01
so if you connect from a different host each day, you will have many symlink but everyone pointing to the same /var/tmp
15:01
<alkisg>
markit: and you prefer to use nfs or sshfs?
15:02
<markit>
well, nfs should put less pressure on CPU
15:02
so nfs
15:02
<alkisg>
markit: I've got /var/tmp/kdecache-artemis, but also many /tmp/var/ kdecache-artemisri8ZZk, with some random chars
15:02
Any idea why those are there?
15:03
<markit>
yep, more or less the /var/tmp is intended to survive reboots
15:03
while /tmp not
15:03
<alkisg>
But why multiple dirs for the same user?
15:03
Sorry
15:03
I meant /var/tmp
15:04
Instead of /tmp/var/kdecache-artemisri8ZZk, I meant var//tmp/kdecache-artemisri8ZZk
15:04
I.e. in the /var/tmp/ folder, I have 5 directories for the same user, artemis
15:04
<markit>
because if you put under /var/tmp it will stay there
15:04
kde wants /tmp stuff to be very "temp", so don't survive reboot
15:05
<alkisg>
No I'm talking about something different
15:05
<markit>
while in /var/tmp they put "optimizations"
15:05
<alkisg>
Forget about /tmp, it was a typo
15:05
<markit>
ok
15:05
<alkisg>
I was always talking about /var/tmp
15:05
<markit>
oh
15:05
I see
15:05
ok, if it fails
15:05
<alkisg>
So, I have 5 kdecache-artemis* folders for the same artemis user
15:05
<markit>
tries a different random name
15:05
<alkisg>
Meh
15:05
<markit>
if you boot stand alone
15:05
you have ONLY /var/tmp/kdecache-artemis
15:05
if the process fails using it
15:06
<alkisg>
It's my daughter's netbook, it's standalone
15:06
<markit>
it generates a random /var/tmp/kdecache-artemis8sdfa
15:06
I've only kdecache-marco
15:06
in my debian sid... I've seen that behaviour only with ltsp
15:06
<alkisg>
So for some reason it failed sometime... ok, anyway, moving on...
15:06
<markit>
you can safely remove that stuff
15:07
(of course not while you are logged in kde)
15:07
and remove .kde links to it, when you relog, will be generated
15:07
or create a new user
15:07
so you will see a "clean" situation
15:07
<alkisg>
I'm trying with a new user, yeah... it got 94Mb on the first login
15:08
<markit>
(most of what I'm saying are my guesses based of what I saw, nothing documented AFAIK)
15:08
<alkisg>
That's too much to have for _every_ login, yeah, we need to reuse that caching
15:08
<markit>
it's reused if everything works (I mean in normal desktop, no ltsp)
15:09
but there is something broken, so in ltsp I think is regenerated multiple times -> 600MB
15:09
of network traffic
15:09
<alkisg>
I'll try with the default sshfs first because I've already ran `ltsp-update-image -c /` and I forgot to install nfs-comon...
15:09
<markit>
sure, I'm happy with everything that works fine
15:09
I think that when you will find the problem, will apply to nfs as well
15:11
<alkisg>
Meh, /home/user/.local/share/akonadi => 150 Mb on first loign
15:11
login
15:11
Anyways
15:14
Wow also vnc has problems with kwin, it first clears the whole background with black and then draws the screen again
15:20
<markit>
alkisg: I've disabled akonadi with a global setting, let me find it
15:20
<alkisg>
markit: nah, don't bother
15:20
https://bugs.kde.org/show_bug.cgi?id=283921
15:20
Bother with that one instead :D
15:20
81mb for caching theme settings?!!!
15:20
Comment there, have people vote for it etc
15:21
<markit>
sigh! and more and more devs will have SSD, so the problem will only become bigger and bigger I fear
15:21
<alkisg>
No, it's the opposite of that
15:21
If they use tmpfs and cache grows too large, they'll bump into problems themselves
15:21
<markit>
FOSS is not driven by rational priorities, but devs moods and "what looks cool" too much
15:22
<alkisg>
Sure, but sometimes they see the problems that are caused, and take time to solve them
15:22* markit takes note
15:22
<markit>
alkisg: well, isn't ridicolous that they had too much I/O, and the solution was not to reduce "un needed I/O" but to create a cache?
15:22
that's why I'm not optimistic
15:22
<alkisg>
E.g. you might find that this doesn't happen with upstream KDE, but only when using custom themes, e.g. kubuntu
15:22
<markit>
but let's go on
15:23
ok
15:23
<alkisg>
So if it doesn't happen for them because they use upstream KDE, they won't care much
15:23* alkisg is waiting for ltsp-update-image to finish in the atom-based notebook...
15:24
<alkisg>
markit: what's happenning with nfs and cross-mount symlinks?
15:24
<markit>
that cross-mount does not work, AFAIR
15:25
even if you try with ln -s
15:25
<alkisg>
E.g. /home/artemis/.kde/cache-pc pointing to /var/tmp/kdecache-artemis, that won't work?
15:25
Even if both of them are mounted from the same server etc?
15:25
<markit>
not as far as I remember, and sure not in the ..../startkde that uses lnusertemp command
15:25
<alkisg>
Can I manually run lnusertemp?
15:26
<markit>
and my conclusion (and the log I got putting a > /tmp/logme) was that the files are owned by 65585 and not user id
15:26
yep, let me find it
15:26
(is not in the path, in starkde you see how it's pat is got)
15:26
<alkisg>
Yup got it
15:26
markit: ok &
15:26
^
15:27
<markit>
alkisg: /usr/lib/kde4/libexec/lnusertemp
15:27
<alkisg>
markit: lnusertemp creates the dir and the symlinks, right?
15:27
And then the programs like plasma put their cache in it...
15:27
<markit>
not sure, seems so
15:28
yes, should be so
15:28
I've put a if "$lnusertemp" $resource >> /tmp/lnuser.log 2>&1; then
15:28
and then checked the content of that log file
15:28
<alkisg>
Hmm no there needs to be some suid program that creates the dir
15:28
<markit>
root@ltsp102:~# cat /tmp/lnuser.log
15:28
Error: "/home/marco/.cache/kdecache-marco" is owned by uid 65534 instead of uid 1001.
15:28
Error: "/home/marco/.cache/kdecache-marcoKLWL71" is owned by uid 65534 instead of uid 1001.
15:29
<alkisg>
One idea there:
15:29
They might have a daemon create the dir as root, and then chown it
15:29
If so, when you export with nfs and root_squash, the file won't be owned by root
15:29
It will be owned by nobody
15:30
So to make KDE work better over nfs, they should create the file directly with the correct owner
15:30
markit: do you have your /etc/exports handy?
15:30
Or is it at school?
15:31
<markit>
it's on the VM of the PC my children is using with the second boot
15:31
but I have some note about it
15:31
<alkisg>
OK no worries it doesn't matter much
15:31
<markit>
maybe...
15:31
and to avoid 2 NFS mounts I've done
15:31
<alkisg>
I'm guessing you're using root_squash, and it's the right thing to do
15:32
The problem is in the KDE code, they'd need to fix that
15:32
<markit>
in /etc/profile
15:32
export KDEVARTMP="$HOME/.cache"
15:32
<alkisg>
What does that do?
15:32
Can you control that you want to use $HOME/.cache instead of /var/tmp?
15:32
<markit>
it should create kdecache-user in $HOME/.cache
15:32
instead of in /var/tmp
15:32
<alkisg>
Cool, let me try...
15:33
<markit>
but seems not to work much better
15:33
<alkisg>
That sounds much better than messing with symlinks
15:33
<markit>
(of course, you better remove .kde and /var/tmp if you try, to be sure that something different happens)
15:33
<alkisg>
I'll try that one first
15:33
<markit>
good
15:34
<alkisg>
Yup, works fine
15:36
<markit>
good, but iftop traffic?
15:37
(btw, as far as I remember, it did not worked fine and kdecache-user was created under .kde and not under .cache... but I could be wrong if there works fine)
15:38
(and I had still the permission problem, so 600MB of iftop traffic)
15:40
<alkisg>
.profile might be too late for it
15:40
I'm putting it to /etc/environment so that it's read by pam
15:41* markit ignores all this stuff... what a bad sysadmin he is
15:41
<alkisg>
Nah $HOME doesn't work in /etc/environment.... will look for some other pam-based way that also sets $HOME...
15:42
<markit>
ah, yes, that's a problem too... $HOME must be set
15:42
I'm wondering why kde doc says about environ variables, but does not spend just one line of doc telling WHERE is the proper location to change
15:43
maybe is so obvious... :(
15:45
<alkisg>
For the test, I'm putting it to ~/.pam_environment
15:45
I'll look later for the proper file to put that
15:46
But there I'm pretty sure it gets set early enough
15:46
Without $HOME, completely hardcoded, /home/artemis/.cache
15:47
ltsp-update-image done, rebooting...
15:49
${HOME} isn't yet available in pam_env.conf either... I'll check if ${USER} is, so that we set it to /home/${USER}/.cache
15:50
markit: so, the target is: first login => 60 seconds or whatever, second login => less than 30 seconds, right?
15:50
From a fat client...
15:52
<markit>
yep, that would be more or less desktop performance
15:52
but also a network traffic of < 100MB would be a 6x improvement
15:52
now it generates 600MB at EVERY login
15:52
<alkisg>
From pxelinux to kdm, 45 seconds
15:53
<markit>
kdm to plasma could take as much then
15:54
the problem is that with 600MB traffic, one or 2 clients are "fast enough", but when you have 10 or 24, it takes... 30 minutes or more
15:55
<alkisg>
110 secs, 450 mb traffic or more, I didn't measure the traffic for the first few seconds
15:56
Let's see the cache path, although I forgot to do the pam change in the chroot...
15:56
Meh no it's still causing traffic, at 700mb now
15:56
Stopped at 765
15:57
<markit>
yep, like here
15:57
at least we have the same situation, is a good starting point (want to be optimistic, lol)
15:58
<klausade>
markit: a few years ago we looked at upgrading thousands and thousands of thin- and diskless-clients from kde3 to kde4. We gave up. what ever we did, performance was horrible, compared to kde3. We switched to xfce4, the best thing ever.
15:58
<alkisg>
Ermmm...
15:58
Cache is fine, all under .kde, nothing in /var/tmp
15:58
/tmp is also almost empty
15:58
...I don't know what cause the traffic!
15:58
...trying second login...
15:59
Ah btw since I put it to /home/username/.pam_environment, it's valid for both server+fat client, and that's why it worked for me without setting it globally somewhere
16:00
<markit>
klausade: the problem is that I installe kde everywhere in 3 schools, from smartboard to teacher's laptop etc and trained them to use it. I can't say "oh, was just a joke, let's change UI" now :(
16:01
klausade: in thin works like a charm, and in fat too.... in my test lab with 2 clients! I deploied the first time in a 24 class and was a nightmare, but was only 2 months ago
16:01
<alkisg>
markit: success, second login at 25 seconds, 50mb traffic
16:01
<markit>
wow!!!
16:01
<alkisg>
Ah after login it's climbing again, let me see where it stops...
16:01
<markit>
I do hope is something easy to setup and does not require kde re-desigh from the ground up ;P
16:02
<alkisg>
151mb
16:02
<markit>
mmm
16:02
<alkisg>
But that's not about the cache
16:02
That's when the sound is played
16:02
<markit>
maybe nepomuk?
16:02
you did not disabled?
16:02
<alkisg>
No I'm using default installation
16:02
<markit>
I've seen a lot of traffic by kmix in the past
16:02
mmm default install should have nepomuk ENABLED
16:03
if you check the systemsettings
16:03
write "nepomuk" and see in what panel is set up
16:03
<alkisg>
OK, let me google for nepomuk first...
16:03
<markit>
(desktop search)
16:04
by default it uses mysql, and it generates a 100MB database
16:04
ops, that is akonadi sorry
16:04
I set akonadi to use sqlite3 instead
16:04
dropping the wasted space a lot
16:04
<alkisg>
Nepomuk also is a meta-info caching framework... ok let me check the disk usage
16:05
<markit>
yep, akonadi is a sort of "storage backend"
16:05
<alkisg>
95M .cache, 23M .kde, 149M .local
16:05
<markit>
(and we are back to those "cool features" only 2% uses and afflict 98% of users)
16:06
sudo aptitude install akonadi-backend-sqlite
16:06
edit /etc/akonadi/akonadiserverrc
16:06
[eneral]
16:07
Driver=QSQLITE3
16:07
and remove .kde in the user home so takes that global parameter
16:07
<alkisg>
nepomuk => soprano-virtuoso.db => 10 mb
16:07
<markit>
since .local/share/akonadi has a 100MB usage, right?
16:07
yep, but I think nepomuk keeps hunting for files and content to reindex
16:08
so makes no good to performance as well
16:08
<alkisg>
markit: any easy way to completely disable akonadi and nepomuk?
16:08
<markit>
from systemsettings?
16:08
in any case, the .local usage should be for the first login only
16:08
<alkisg>
Sure, if they can be completely disabled there...
16:08
Going there to check
16:09
<markit>
well, I think that they survive as processes, but don't do any work
16:09
<alkisg>
No something else is updating its files on subsequent logins as well
16:09
<klausade>
markit: /me thinks of dead horses and flying pigs when someone mentions kde4 ....
16:09
<markit>
ah :(
16:09
klausade: lol
16:09
<alkisg>
So I don't see /home/username growing, but I do see 150 mb traffic on logins, which is a bit much
16:09
Nothing terrible though, it's not 750mb anymore
16:10
<markit>
yep, is a good starting point for further refinement
16:10
since kde people hearing of 700MB think that something on the LTSP side is broken
16:10
and don't take it in consideration
16:11
btw, in nepomukserverrc under (somewhere .kde or home, don't remember) you can set
16:11
[Basic Settings]
16:11
Start Nepomuk=false
16:11
if you disable akonadi (process does not run) a lot of programs could complain
16:12
they are (sigh!) increasing dependencies upon that storage backend
16:12
(not only PIM programs)
16:13
<alkisg>
Ah ok let me try just nepomuk then
16:15
<markit>
and change akonadi backend?
16:15
<alkisg>
22 sec to login (see the panel), 40 or so to hear the login sound, 70 mb for login
16:15
<markit>
let's wait until it stabilizes...
16:15
don't want see a 200MB jump ;P
16:15
<alkisg>
It did
16:15
70 mb
16:15
Ah
16:15
<markit>
GREAT!
16:15
:(
16:15
<alkisg>
Wait it raises again... :P
16:15
<markit>
lol
16:15
I know the beast ;P
16:16
<alkisg>
93 mb
16:16
So nepomuk saved 50mb
16:16
<markit>
is 30% :)
16:16
<alkisg>
I think all that is acceptable now
16:16
<markit>
just find other 3 bottleneck, and will boot in 0 seconds ;P
16:16
<alkisg>
You can optimize a bit more, but it should work even for multiple clients
16:16
Haha
16:16
<markit>
YES, sure!!!
16:17
but what did you did to fix it?
16:17
<alkisg>
OK so your basic problem was that you didn't set the environment variable from the correct place
16:17
<markit>
yep, since default settings is "LTSP allergic"
16:17
<alkisg>
We could fix that in ltsp though
16:17
<markit>
I mean, default is to /var/tmp and this will NEVER work AFAIU
16:18
oh, that would be great
16:18bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 245 seconds)
16:18
<alkisg>
OK let me think... you only need that for KDE fat clients, nowhere else
16:19
So it should check for the session name
16:19
<markit>
mm markit started troubleshooting 30 days ago... result, nothing works fine. alkisg started troubleshooting at 16.53... result after 1 hour and some minute: problem fixed
16:19
<alkisg>
Haha
16:19
<markit>
don't know if I must be happy or depressed ;P
16:19
<alkisg>
It depends on if you want to be a programmer or a floss advocator :D
16:20
<markit>
lol, I would love to take both
16:20
and I do hope to be a better foss advocator than a sysadmin
16:23
alkisg: I've to go outside with my wife (that has been so patient so far...), could you drop me a line by email with the solution and a brief description of the problem (I've wasted so much time that I would love to see what really was wrong and why)?
16:23
<alkisg>
markit: sure
16:23
Have a great time
16:24
<markit>
I do thank you SOOOOO MUCH
16:24
you are great technically and so helpful and friendly
16:24
what about cloning you?
16:24alkisg2 has joined IRC (alkisg2!59d28d19@gateway/web/freenode/ip.89.210.141.25)
16:24
<alkisg2>
done :P
16:25
<markit>
hahahaha
16:25
do hope I will not clone myself too ;P
16:25alkisg2 has left IRC (alkisg2!59d28d19@gateway/web/freenode/ip.89.210.141.25, Client Quit)
16:25
<alkisg>
Haha
16:25
<markit>
see you later :)
16:25markit has left IRC (markit!~marco@88-149-177-66.v4.ngi.it, )
16:25
<alkisg>
bb
16:31Pinguin123 has joined IRC (Pinguin123!~smuxi@biton.xs4all.nl)
16:32
<alkisg>
Doh no sshfs mount for /home/username, fun
16:33
Maybe it took too long to be unmounted, and then wasn't mounted again on second login...
16:42
No, stuff was left behind under /home/username locally... weird how it was created by kde before the sshfs mount...
16:56
Stopping nepomuk made that problem go away, ok
17:00Pinguin123 has left IRC (Pinguin123!~smuxi@biton.xs4all.nl, Remote host closed the connection)
17:13andygraybeal_ has joined IRC (andygraybeal_!~andy@h82.200.130.174.dynamic.ip.windstream.net)
17:16khildin has joined IRC (khildin!~khildin@ip-83-134-214-146.dsl.scarlet.be)
17:29ltspuser_50 has joined IRC (ltspuser_50!5c2cc70e@gateway/web/freenode/ip.92.44.199.14)
18:16Parker955_Away is now known as Parker955
18:25bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
18:25Parker955 is now known as Parker955_Away
18:31
<Hyperbyte>
What a jump... wow! #stratos
18:43Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 260 seconds)
18:58Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
19:14vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net)
19:14vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
19:16Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
19:47ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)
20:04alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
20:10Mava has left IRC (Mava!~Mava@ip-45-201.dhcp.opintanner.fi, Remote host closed the connection)
20:36mmetzger has left IRC (mmetzger!~mmetzger@99-71-214-196.lightspeed.mdldtx.sbcglobal.net, Quit: leaving)
20:39khildin_ has joined IRC (khildin_!~khildin@ip-80-236-212-198.dsl.scarlet.be)
20:42khildin has left IRC (khildin!~khildin@ip-83-134-214-146.dsl.scarlet.be, Ping timeout: 245 seconds)
21:19FGXR6 has joined IRC (FGXR6!~phantom@ppp121-44-8-89.lns20.syd6.internode.on.net)
21:30FGXR6 has left IRC (FGXR6!~phantom@ppp121-44-8-89.lns20.syd6.internode.on.net, Read error: Operation timed out)
22:10andygraybeal_ has left IRC (andygraybeal_!~andy@h82.200.130.174.dynamic.ip.windstream.net, Ping timeout: 245 seconds)
22:12ltspuser_50 has left IRC (ltspuser_50!5c2cc70e@gateway/web/freenode/ip.92.44.199.14, Ping timeout: 245 seconds)
22:16bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 255 seconds)
22:45khildin_ has left IRC (khildin_!~khildin@ip-80-236-212-198.dsl.scarlet.be, Quit: I'm gone, bye bye)
22:59Parker955_Away is now known as Parker955
23:31shogunx has left IRC (shogunx!~shogunx@2001:4978:106:1:694c:87d6:c68a:a1de, Quit: Fnord)