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


Channel log from 2 November 2015   (all times are UTC)

00:17Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
00:17fede2 has joined IRC (fede2!~alvaro@186.176.20.162)
00:22FrozenZia has left IRC (FrozenZia!pbrown@evo.paivola.fi, Ping timeout: 260 seconds)
00:23FrozenZia has joined IRC (FrozenZia!pbrown@evo.paivola.fi)
00:24fede2 has left IRC (fede2!~alvaro@186.176.20.162, Ping timeout: 256 seconds)
02:18work_alkisg is now known as alkisg
02:19
<alkisg>
vagrantc: I don't get it. set_lts_var was invented in order to save a variable, and that's why I updated the code to use it, instead of >>ltsp_config
02:20
Why do you think that reimplementing set_lts_var is better in this case?
02:24
ltsp_config.d scripts calculate and store variables to be used later on in various boot/login phases of ltsp clients. init-ltsp.d is one of the phases. init-ltsp.d scripts don't store variables, they use them to do a one-time initialization.
02:25
So, storing the value of LTSP_CLIENT_MAC belongs in ltsp_config.d, not in init-ltsp.d. Right?
02:27
Sure, the distinction there is a bit fuzzy, and it would be better if the scripts for all phases were allowed to calculate and store configuration values (i.e. if we completely merged ltsp_config.d into init-ltsp.d), but that's not how it is now, there's no "set_lts_var" in init-ltsp.d scripts at all...
02:28
<vagrantc>
it seems like a static, non-changeable thing, like the root server ... so it doesn't seem like configuration in the same way that lts.conf is...
02:29
ltsp_config.d is basically an extension of lts.conf
02:30
when ltsp5 happened, mdz basically implemented "eval $(getltscfg -a)" and poof, all the variables are now always exported ...
02:30
in ltsp4, VAR1=$(getltscfg VAR1) was used more ...
02:31
alkisg: set_lts_var seemed needlessly complex ...
02:31
<alkisg>
$ grep set_lts_var 45nc-q-compat
02:31
set_lts_var nc_q_param "$nc_q_param"
02:31
<vagrantc>
alkisg: so i guess i've never been convinced of it's need
02:31
<alkisg>
How is the mac address different than e.g. nc_q_param?
02:31
They're both "static"...
02:32
I'm all in for removing ltsp_config.d. But that's what we have now, there's no point in re-implementing set_lts_var in all scripts where we want to save state...
02:34
In the future, I'd like it if the server was sending code to the clients instead of .ini-style configuration values (even if the code was just VAR=value)
02:34
Our "run-parts" function at various boot phases would have one step for loading state, and one in the end for saving it
02:34
And the "set_lts_var" function would store the state in a variable, until it's saved in a file at the end of the phase
02:35
i.e. it would be more efficient, and allowed in any of the boot/login phases
02:35
But I see no point in the code doing >>file to save the state instead of using a function
02:36
<vagrantc>
i suppose the function could then change the backend more easily
02:36
so sure.
02:37
but it was really a one-line diff to get it working where it was
02:41
<alkisg>
But I was wrong to put it in init-ltsp.d when I implemented it, and I fixed my mistake...
02:41
Having a small line diff is not better than improving the code
02:43
At the time, I hadn't realized what set_lts_var was designed for, that's why I wrongly re-implemented it and put it in init-ltsp.d
02:50* alkisg thinks that in this case vagrantc is thinking more like a debian maintainer, minimizing the diff in patches, rather than as an upstream programmer, maintaining/increasing the code quality... :)
02:52* vagrantc doesn't see a move from init-ltsp.d as improving code quality
02:52
<vagrantc>
seems like a regression to a deprecated mechanism
02:53
<alkisg>
So, if I did the opposite, i.e. took all the code from ltsp_config.d that uses set_lts_var and put it to init-ltsp.d and made it use >>ltsp_config, it would improve quality?! :)
02:53
<vagrantc>
the code used to just set and export the variables... then someone wanted to make it complicated and cache the variables for a virtually unmeasurable performance increase
02:55
and then someone wanted to change the variables at every run ...
02:55
<alkisg>
When we have 10 places that uses function_x and 1 place that reimplements function_x, merging those improves the code.
02:55
If function_x is badly designed, that a different issue that needs to be addressed in all 11 places at once, or maybe at 1 point in a library
02:55
<vagrantc>
so it needed a way to ignore the cache...
02:56
<alkisg>
So my commit is not about endorsing set_lts_var, it's about consistency. If we don't want set_lts_var we can remove it in a separate commit for wherever it's used.
02:56
But I think set_lts_var is nice, it's the ltsp_config.d that shouldn't exist
02:56
(dir)
02:58
I don't think set_lts_var is deprecated, I think ltsp_config.d/ should become deprecated when ltspd is implemented.
02:58
<vagrantc>
ltsp_config.d should have become deprecated when we implemented init-ltsp.d ...
02:59
but that's when we lost steam and development slowed...
02:59
<alkisg>
Gadi implemented set_lts_var exactly at that time though
02:59* vagrantc shrugs
02:59
<alkisg>
When I proposed init-ltsp.d, that's exactly when Gadi implemented set_lts_var
02:59
But it's not a bad thing, we don't have to change it
03:00
When we standarize the ltsp phases, we'll see that we have e.g. 10 places where ltsp code runs
03:01
In the initramfs, in init-ltsp.d, when services start, when xorg starts, before login, etc etc
03:01
All those dirs will be similar to init-ltsp.d, and will be ran by something like run-parts
03:01
<vagrantc>
after working with it for years, and having to figure out what does what every time i look at that part of the code, i can't really agree that it doesn't need a complete rethinking
03:02
<alkisg>
So, that run-parts function will automatically load/save the state we want
03:02
<vagrantc>
alkisg: that sounds good, though, yes.
03:02
<alkisg>
No ltsp-config.d necessary. I think that's where we have the problem, in the fact that ltsp_config.d exists.
03:02
<vagrantc>
you should have seen it before ltsp_config.d existed
03:03
one big file with all those hacks
03:03
<alkisg>
set_lts_var will still be there, we won't change the calls. We'll only change the implementation a bit for efficiency, to temporarily use RAM instead of files, and let the run-parts function then use files.
03:03
<vagrantc>
figuring out what the difference between cache/ltsp_config and cache/ltsp_config_env are has always baffled me
03:03
didn't have that confusion prior to set_lts_var
03:04
<alkisg>
So what I'm saying is that I don't think using set_lts_var/ltsp_config.d now is a bad thing or a regression. ltsp_config.d should be removed in the future, yes, but that's a completely different step.
03:04
Using set_lts_var now makes it easier to remove ltsp_config.d in the future.
03:05
The ltsp_config file should probably be removed, the initramfs can use ltsp_config_env instead
03:11
Eh. We removed its use from the initramfs. We can just remove the 3 files that still use it and replace it with set_lts_var.
03:13
So we just need 3 more commits like the one I did yesterday :D
03:16
I think that initially, cache/ltsp_config was designed to pass values from the initramfs to ltsp_config.d and init-ltsp.d
03:16
Because it was possible that ltsp_config_env would be there since ltsp-build-client/ltsp-chroot, and it might contain invalid values
03:17
Then cache/ltsp_config was misunderstood/remembered wrongly by a few developers (myself included) and misused to store stuff from init-ltsp.d/ltsp_config.d
03:17
Those commits should be fixed. The mac thing was one of them.
03:18
Then, to go back a step and solve the initramfs issue, we should completely stop using /var/cache and switch to /run
03:18
We don't want that state remembered across reboots, /var/cache is the wrong place to put it
03:19
That also means that we don't need 01-clean-cache, /run is always cleared, only the initramfs can store things there
03:23
this helps to visualize the issues I'm talking about: ltsp-trunk$ grep -r /var/cache/ltsp/ltsp_config .
03:25
Better yet, $ grep -r /var/cache/ltsp .
03:25
/client/Debian/share/initramfs-tools/scripts/init-bottom/ltsp:mkdir -p "$rootmnt/var/cache/ltsp/"
03:25
./client/Debian/share/initramfs-tools/scripts/init-bottom/ltsp: cp "$netconf" "$rootmnt/var/cache/ltsp/"
03:26
See, these lines only exist because we're using the wrong dir, cache instead of run, where netconf is already there and automatically moved
03:26
all the bind-mount things also are not needed if we switch to /run
03:27
And all the init-ltsp.d that use cache, should be changed to use set_lts_var
03:27
*scripts
03:32
vagrantc: if you agree, I'll file a bug report about switching /var/cache/ltsp to /run/ltsp and another one about dropping /var/cache/ltsp/ltsp_config, and we can implement them when we have time.
03:35* alkisg waves for now, later... :)
03:35alkisg is now known as work_alkisg
03:44
<vagrantc>
work_alkisg: sounds fine
03:44
it's historical ... /var/cache/ltsp predates the existance of /run
03:45
arguably, /var/run might have been a better place for that stuff ... which would mean we'd still be in a better position
03:45
since in think /var/run is just a symlink to /run
04:46vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
05:36work_alkisg is now known as alkisg
06:08ricotz has joined IRC (ricotz!~ricotz@p5B2A89EE.dip0.t-ipconnect.de)
06:08ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:04
<alkisg>
!raspberrypi
07:04
<ltsp`>
raspberrypi: (#1) LTSP with raspberry pi: http://cascadia.debian.net/trenza/Documentation/raspberrypi-ltsp-howto/, or (#2) To use a similar environment to LTSP on the raspberry pi http://berryterminal.com/, or (#3) https://github.com/gbaman/RaspberryPi-LTSP, or (#4) https://pi-ltsp.net
07:04
<alkisg>
!forget raspberrypi 2
07:04
<ltsp`>
The operation succeeded.
07:07
<alkisg>
!raspberry pi
07:07
<ltsp`>
I do not know about 'raspberry pi', but I do know about these similar topics: 'raspberrypi'
07:07
<alkisg>
!raspberrypi
07:07
<ltsp`>
raspberrypi: (#1) Ubuntu/LTSP on Pi 2: https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi, or (#2) Debian/LTSP (with raspbian chroot) on Pi: http://cascadia.debian.net/trenza/Documentation/raspberrypi-ltsp-howto/, or (#3) unofficial Ubuntu/LTSP (with raspbian chroot) on Pi: http://pinet.org.uk/
07:49mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
08:13yanu has joined IRC (yanu!~yanu@178-116-58-90.access.telenet.be)
08:17adrianorg has left IRC (adrianorg!~adrianorg@179.187.28.197.dynamic.adsl.gvt.net.br, Ping timeout: 244 seconds)
08:18adrianorg has joined IRC (adrianorg!~adrianorg@187.113.244.122)
08:30sutula has left IRC (sutula!~sutula@207-118-152-139.dyn.centurytel.net, Ping timeout: 240 seconds)
08:35sutula has joined IRC (sutula!~sutula@207-118-162-188.dyn.centurytel.net)
08:42alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 250 seconds)
08:44alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
08:55gdi2k has left IRC (gdi2k!~gdi2k@180.191.106.186, Quit: Ex-Chat)
09:02alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 256 seconds)
09:09yanu has left IRC (yanu!~yanu@178-116-58-90.access.telenet.be, Quit: Lost terminal)
09:17eemeli has joined IRC (eemeli!3e94cd0c@gateway/web/freenode/ip.62.148.205.12)
09:17eemeli has left IRC (eemeli!3e94cd0c@gateway/web/freenode/ip.62.148.205.12, Client Quit)
09:19yanu has joined IRC (yanu!~yanu@178-116-58-90.access.telenet.be)
09:24alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
09:49schlady has joined IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de)
10:00schlady has left IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de, Read error: Connection reset by peer)
10:00schlady has joined IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de)
10:01schlady has left IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de, Read error: Connection reset by peer)
10:02schlady has joined IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de)
10:07schlady has left IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de, Remote host closed the connection)
10:29schlady has joined IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de)
10:34schlady has left IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de, Ping timeout: 244 seconds)
10:36nataraj has joined IRC (nataraj!7aa6e4aa@gateway/web/freenode/ip.122.166.228.170)
10:37
<nataraj>
Hi
10:37
where do I put ltsp-x86_64.ks, in rhel7?
10:38
<alkisg>
Unfortunately not many people are using rhel with ltsp these days... mostly .deb-based distros
10:39
<nataraj>
well, what about this kickstart thing? will it install the server and client?
10:39
<alkisg>
No idea, but I haven't heard of anyone succeeding with installing ltsp on rhel here for the few past years
10:40
.deb-based distros don't have kickstart files so personally I don't even know what that is...
10:40
I do know that we didn't have any upstream commits for fedora/rhel in years... so it should be very broken now
10:43
<nataraj>
itc, where do i start for building the server ? ltsp-5.4.5.tar.xz
10:44
<alkisg>
You won't be able to, unless you plan to be an ltsp developer + maintainer for rhel
10:44
You'll need to change your distribution to use ltsp
10:45
<nataraj>
well, wont it work on any kinda linux?
10:45
<alkisg>
No
10:45
<nataraj>
need to get source and compile. Right?
10:45
<alkisg>
No
10:45
It has much distro-specific code
10:45
It's not an application. It's a glue to make the distro netboot
10:46
So distributions that want to support ltsp, have "ltsp maintainers"
10:46
<nataraj>
what about the fedora stuff?
10:46
<alkisg>
The last rhel ltsp maintainer left years ago
10:46
Only .deb-based distros are supported currently. And opensuse has something similar, kiwi-ltsp.
10:46
<nataraj>
ok, you already told
10:46
<alkisg>
No fedora, no rhel support.
10:46
(I already told that as well :))
10:47
<nataraj>
what about archlinux?
10:47
<alkisg>
Does it use .deb?
10:47
Nope
10:47
So no, not supported.
10:47
Debian, Ubuntu, LinuxMint, that stuff.
10:47
<nataraj>
what if i have a vm that runs debian? will ltsp do pxe from the vm debian?
10:48
<alkisg>
Yes
10:48
<nataraj>
any particular debian?
10:49
<alkisg>
Nope, debian stable or ubuntu 14.04 are fine
10:49
!ltsp-pnp
10:49
<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
10:49
<alkisg>
That one is quite easy to follow.
10:51
brb
10:51alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
10:51alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
10:54
<nataraj>
alkisg, you suggest the ubuntu install over debian?
10:54
<alkisg>
nataraj: I maintain the greek schools ppa (mentioned in that page), so I'm certain that it works and I can support users more easily there
10:55
Debian is fine as well, but yes, I suggest Ubuntu first
10:55
<nataraj>
ok
10:55
is there a kinda minimal install for ubuntu?
10:56
<alkisg>
I'm not sure that you'll want that, better start with telling us about your use case
10:56
<nataraj>
i used to work on debian till 2010. Switched to archlinux since
10:56
<alkisg>
How many clients, what's their cpu/ram?
10:56
<nataraj>
well, presently its for a testing purpose of just 10 clients
10:57
<alkisg>
CPU/RAM of the clients?
10:57
<nataraj>
cpu/ram are decent
10:57
<alkisg>
Then my suggestion is this:
10:57
create a vm in archlinux in bridged mode,
10:57
and follow the ltsp-pnp page exactly
10:58
You'll get a full ubuntu environment, both in the vm and on the clients, with minimal downloading + size
10:58
<nataraj>
i3/4G
10:58
<alkisg>
They'll work as "ltsp fat clients", meaning that they'll load the OS from the VM server, but they'll run it locally, with only /home persistent on the server
10:59
This is the best mode for decent clients. You can fall back to thins by specifying a directive in a configuration file, LTSP_FATCLIENT=False in lts.conf.
10:59
<nataraj>
that seems good enough
11:02
go for Ubuntu 12.10?
11:03
<alkisg>
No, use only LTS releases
11:03
And 12.10 is very old
11:03
Use 14.04
11:04
LTS releases are: 12.04 (older), 14.04 (current), 16.04 (not ready yet)
11:04
<nataraj>
may i have a link, if you dont mind :)
11:04
<alkisg>
Is there a chance that you'll want to netboot an i386 client? Not amd64 capable?
11:05
http://www.ubuntu.com/download/desktop
11:05
<nataraj>
yeah, i might need
11:05
<alkisg>
Ubuntu 14.04.3 LTS => i386 => download
11:07
http://releases.ubuntu.com/14.04.3/ubuntu-14.04.3-desktop-i386.iso
11:09
<nataraj>
yum, gone for it. In about one hour
11:09
typo, yup not yum
11:10
old habits dont die soon ;)
11:10
<alkisg>
apt-get install haha! :)
11:15
<nataraj>
:D
11:18schlady has joined IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de)
11:34schlady has left IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de, Read error: Connection reset by peer)
11:34schlady has joined IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de)
11:40schlady has left IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de, Read error: Connection reset by peer)
11:41alkisg is now known as work_alkisg
11:42schlady has joined IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de)
12:02administrator has joined IRC (administrator!5e478477@gateway/web/freenode/ip.94.71.132.119)
12:02administrator is now known as Guest34559
12:17danau11 has joined IRC (danau11!~durban@66.251.57.114)
12:19danau11 has left IRC (danau11!~durban@66.251.57.114)
13:07andygraybeal has joined IRC (andygraybeal!~andy@h52.205.189.173.dynamic.ip.windstream.net)
13:14
<larryni>
Hi guys
13:21
Trying to get the display of our HP t5570 thin clients. They should support 1366x768, but insist on starting in 1024x768. The only way I can get a login screen is with XSERVER=vesa. I've tried adding the full res with XRANDR_COMMAND_x, but no success.
13:22
glxinfo gives me the client glx vendor string "Mesa Project and SGI"
13:22
I've tried so many different combinations now...
13:25nataraj has left IRC (nataraj!7aa6e4aa@gateway/web/freenode/ip.122.166.228.170, Ping timeout: 246 seconds)
13:47
<muppis>
Have anyone tried to use Odroid C1 as client?
13:51
<ogra_>
is there a usable graphics driver for it ?
13:52
(beyond fbdev)
13:55
<muppis>
More than OpenGL ES 2.0 required?
14:06
<ogra_>
i doubt desktop make much use of it
14:07
*desktops
14:07
or flash ...
14:07
or whatever you want to display
14:07
you need 2D accel more than 3D accel there ... and for that you need a proper xserver
14:12
<muppis>
Seems like there is X11 driver for Mali GPU.
14:24FrankBlues has joined IRC (FrankBlues!~alex@c-67-171-127-41.hsd1.ut.comcast.net)
14:38gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
14:50work_alkisg is now known as alkisg
14:50
<alkisg>
larryni: what's the output of `xrandr`?
14:50
Can you set 1366x768 with xrandr commands?
14:56ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
14:57
<larryni>
alkisg: here's the output http://paste.debian.net/319271 - I managed to add the resolution with --newmode and --addmode lines using XRANDR_COMMAND_n lines in lts.conf. I've also got a line with "--output default", but get an error message that the screen cannot be configured as soon as I log on. The login screen is shown in 1024x768 as well.
14:58
When I try to set manually with xrandr I get the same error.
14:58
<alkisg>
larryni: is that a crt or a tft monitor?
14:58
And, are you using a kvm switch?
14:58
<larryni>
tft
14:58
<alkisg>
or a splitter?
14:59
<larryni>
no kvm or splitter
14:59
<alkisg>
which graphics driver? lspci -nn -k | grep -A2 VGA on the client, not on a user session
14:59
<larryni>
The machine has a DVI to VGA adapter though
14:59
<alkisg>
!localxterm
14:59
<ltsp`>
localxterm: Any applications that you launch on a thin client actually runs on the server, not on the client itself. If you want to open a program on the client locally, you can type 'ltsp-localapps <program>' in a run dialog or in a terminal. For example, 'ltsp-localapps xterm' to open a terminal running on the client.
15:00
<alkisg>
Do you have a way to connect it directly, e.g. vga to vga or dvi to dvi?
15:01
The problem seems to be that it's not reading the edid information, it should say so in your xorg.conf
15:01
And you can use a premade edid or a custom X_HORIZSYNC/X_VERTREFRESH
15:02
<larryni>
The clients have a VGA port, but male instead of female - I guess that's why my predecessor used the adapters in the first place.
15:02* alkisg assumes that's a serial port...
15:02
<alkisg>
rs232, not vga
15:02
2 lines of pins, not 3
15:04
<ogra_>
well, if you squeeze hard enough ...
15:05
<alkisg>
:)
15:05
<ogra_>
(you might only get a serial console on screen if you actually manage to plug it in though :P ... )
15:06mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
15:07
<larryni>
Here's the output of lspci http://i.imgur.com/F5ILW3w.png
15:08
<alkisg>
Ah, via, lovely
15:08
<larryni>
Is that a good or bad lovely? ;o)
15:08
<alkisg>
Which ubuntu version is that?
15:08
very bad lovely :)
15:08
<larryni>
14.04
15:08
dang
15:09
<alkisg>
You're very lucky you get a display, some months ago it was just segfaulting
15:09
<larryni>
The screens worked on our previous ltsp which ran on 10.04
15:09
<alkisg>
OK then if you got the xrandr commands working, just put those in lts.conf
15:09
Yes, xaa was removed in 10.10
15:09
and sis has broken exa implementation
15:10
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-sis/+bug/1066464
15:12
So, use XRANDR_COMMAND_01, 02, 03 to define the newmode, add it etc
15:12
<larryni>
This is what I have in my lts.conf for the HP thin clients http://paste.debian.net/319274
15:12
<alkisg>
You can include the initial xrandr there in the command
15:12
If you run those inside a user session, do you get 1366x768?
15:13
Aren't you missing a --mode in the last command?
15:16
<larryni>
No, it adds the option to my resolutions list, but then errors when I try to apply it.
15:16
Tried with and without --mode in the last line - same results
15:20
I've also tried XSERVER=via instead of vesa - but then I just get a black screen instead of a login screen
15:26schlady_ has joined IRC (schlady_!~schlady@141-53-32-98.ip.uni-greifswald.de)
15:30Hyperbyt1 has joined IRC (Hyperbyt1!jan@middelkoop.cc)
15:34fiesh_ has joined IRC (fiesh_!~fiesh@hq.wsoptics.de)
15:34schlady_ has left IRC (schlady_!~schlady@141-53-32-98.ip.uni-greifswald.de, Remote host closed the connection)
15:35schlady has left IRC (schlady!~schlady@141-53-32-98.ip.uni-greifswald.de, *.net *.split)
15:35alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, *.net *.split)
15:35cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, *.net *.split)
15:35fiesh has left IRC (fiesh!~fiesh@hq.wsoptics.de, *.net *.split)
15:35PeperPots___ has left IRC (PeperPots___!sid1218@gateway/web/irccloud.com/x-bxscbxjpbujssqeg, *.net *.split)
15:35Hyperbyte has left IRC (Hyperbyte!jan@5.9.150.98, *.net *.split)
15:39
<larryni>
Another problem I have is with our Acer Veritrons. They insist on activating the built-in LVDS1 and VGA1. Even though my lts.conf says "xrandr --display LVDS1 --off --output VGA1 --mode 1366x768" it only seems to apply to the login screen. Once the desktop loads I have an extended desktop again.
15:40
When I enter xrandr --display LVDS1 --off in a terminal it switches to single desktop with the right res.
15:42cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
15:42alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
15:46
<alkisg>
larryni: gnome saves desktop settings in ~/.config/monitors.xml, delete those to have the login screen resolution stick inside the user session
15:46
Also, I got disconnected and this didn't reach the channel:
15:46
(05:31:35 μμ) alkisg: larryni: didn't you say that you managed to get the correct resolution via the command line?
15:46PeperPots___ has joined IRC (PeperPots___!sid1218@gateway/web/irccloud.com/x-arxxlwfsixnswrup)
15:46
<larryni>
alkisg: I prese
15:47
oops
15:47
<alkisg>
You can also disable outputs via the kernel command line
15:47
<larryni>
I presume the last one you posted was in relation to the HP clients?
15:47
<alkisg>
Something like video:lvds-1:disabled, I think we even have a !factoid here for it...
15:47
Yes
15:48
video=LVDS-1:d
15:48
!video
15:48
<ltsp`>
I do not know about 'video', but I do know about these similar topics: 'video-without-flash', 'video-test'
15:48
<alkisg>
!lvds
15:48
<ltsp`>
I do not know about 'lvds', but I do know about these similar topics: 'ldm', 'logs'
15:48
<alkisg>
!i915
15:48
<ltsp`>
I do not know about 'i915', but I do know about these similar topics: 'ipxe'
15:48
<larryni>
No, no luck with the HP ones whatsoever - only 1024x768
15:48
<alkisg>
Then try with X_HORIZSYNC and X_VERTREFRESH, you should have an example lts.conf with those
15:49Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
16:00alkisg is now known as work_alkisg
16:16vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:46work_alkisg is now known as alkisg
16:49cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 240 seconds)
16:52
<alkisg>
!raspberrypi
16:52
<ltsp`>
raspberrypi: (#1) Ubuntu/LTSP on Pi 2: https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi, or (#2) Debian/LTSP (with raspbian chroot) on Pi: http://cascadia.debian.net/trenza/Documentation/raspberrypi-ltsp-howto/, or (#3) unofficial Ubuntu/LTSP (with raspbian chroot) on Pi: http://pinet.org.uk/
16:52
<alkisg>
vagrantc: ^ :)
17:00Parker955_Away has left IRC (Parker955_Away!~parker@2607:5300:60:8425::2d62:a8e6, Ping timeout: 246 seconds)
17:00Tyrantelf has left IRC (Tyrantelf!~tyrantelf@2607:5300:60:48bd::1, Ping timeout: 246 seconds)
17:08Parker955_Away has joined IRC (Parker955_Away!~parker@167.114.7.167)
17:17
<vagrantc>
alkisg: nice
17:19
alkisg: ubuntu ships a raspi2 kernel?
17:19
<alkisg>
Yes, from 15.10 onwards, and I copied it to the greek schools ppa for 14.04
17:24
<ogra_>
vagrantc, yep ... mainline with Pi patches on top
17:27
<vagrantc>
hrm. packages.ubuntu.com doesn't include armhf ...
17:30
<alkisg>
https://launchpad.net/ubuntu/+source/linux-raspi2
17:30cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
17:31stgraber has left IRC (stgraber!~stgraber@ubuntu/member/stgraber, Ping timeout: 250 seconds)
17:32stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org)
17:32
<vagrantc>
oddly enough, it does include armel ...
17:32* vagrantc wonders how hard it would be to add the same patchset to unofficial Debian kernels
17:33
<ogra_>
packages.u.c is maintained by debian :P
17:33
<vagrantc>
ogra_: do you have any links documenting using u-boot on raspberry pi?
17:33
<ogra_>
vagrantc, should be fine for unofficial kernels
17:33
no, not yet, i still have a task to document oour uboot setup in snappy
17:34
<vagrantc>
ogra_: you had said something about the .dtb needing to come from some strange location
17:34
<ogra_>
it needs to sit next to the blob bootloader
17:34
<vagrantc>
ogra_: ok, i'd love to read over that documentation once it exists, or a draft, etc.
17:35
<ogra_>
yeah, only in my head currently :)
17:35
snappy keeps me busy
17:35
<vagrantc>
ah, so i just have to snap my fingers? :)
17:36schlady has joined IRC (schlady!~schlady@ip1f111023.dynamic.kabel-deutschland.de)
17:36
<alkisg>
vagrantc: we managed to boot with u-boot at #raspberrypi
17:36
Using the dtb and all
17:36
(to netboot)
17:36
<vagrantc>
alkisg: oh!
17:37
<alkisg>
u-boot supports an fdt directive in its pxelinux emulation
17:37
<vagrantc>
right
17:37
fdt_dir as well
17:37
<alkisg>
In my tests, the kernel was hanging because I didn't provide the blob
17:37
<vagrantc>
i've managed to boot it... but video resolution was awful ... and maybe some devices were unreliable ... but it's been a while
17:38
also with the 3.18 kernel from raspbian
17:38
so maybe the 4.2 kernel works more sanely
17:38
<ogra_>
you need the blob to chainload uboot
17:38
the blob reads the dtb and loads it to 0x100 in ram
17:38
<vagrantc>
yeah ... and you need the right blob
17:38
<alkisg>
Local firmware loads u-boot, which then loads the device tree from tftp
17:38
<ogra_>
uboot needs to load it from there with the fdt command
17:39
else your kernel wont boot
17:39
it only works properly if the blob can load the dtb loacally from its dir
17:39
<vagrantc>
alkisg: that sounds more like what i'm looking for
17:39
<ogra_>
uboot cant override the dtb
17:39
<alkisg>
vagrantc: we booted with that this morning
17:39
local firmware, kernel and initrd and device tree from tftp
17:39stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 250 seconds)
17:40
<ogra_>
the kernel will automatically switch back to ATAGs if you try loading the dtb via usboot
17:40
<alkisg>
I'll test more tomorrow and update the wiki page to use that
17:40
<ogra_>
which means only basic HW works
17:41
s/usboot/uboot/
17:48stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org)
17:49
<alkisg>
ogra_: could you explain to me in a few words what the device tree is about? From what I've heard so far, the GPU gets started first, then I assume it executes the code from some ROM that can initialize the SD card and read the fat partition and load the firmware from there,
17:49
then the firmware loads e.g. config.txt, cmdline.txt and loads e.g. u-boot or the kernel
17:49schlady has left IRC (schlady!~schlady@ip1f111023.dynamic.kabel-deutschland.de, Remote host closed the connection)
17:49
<alkisg>
Where is the device tree needed? Why isn't the firmware enough?
17:50
<ogra_>
when it loads config.txt it also loads the devicetree and all the overlays you define in there
17:50
<alkisg>
What are the overlays? Code? Or just description of the hardware?
17:51
I'm missing the essential information, what's their purpose...
17:51
<vagrantc>
.dtb/device-tree describes hardware configuration that isn't probeable
17:51
<alkisg>
So they don't contain code, right?
17:52* vagrantc doesn't understand the distinction
17:52
<alkisg>
Isn't it possible to manually load them at run time, assuming you know what your hardware is?
17:52
like, force_load_module my-hardware...
17:53stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 268 seconds)
17:53
<alkisg>
Are they passed to the kernel like the initramfs?
17:53stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org)
17:53
<alkisg>
Or are they system functions like the pc interrupt/bios services?
17:54
<ogra_>
overlays are to enable additional HW
17:55
like PWM or I2C ... if you have a sound cape/hat attached you need the drivers ... so you load the matching overlay for the sound hat and it will give you sound
17:55
<alkisg>
Why can't the kernel load them after it starts?
17:56
<ogra_>
the beaglebone can do such stuff ... but via a kernel hack called capemgr ... the rpi kernel sadly cant
17:56
(dynamic loading i mean)
17:56
<alkisg>
OK, so they exist because of bad firmware design... :)
17:57
<ogra_>
there is no firmware design :P
17:57
<alkisg>
Hehe
17:57
<ogra_>
its only a first stage bootloader
17:57
dtb's are a kernel thing ... to prevent devs from having to re-build their kernels and get more standardization into arm
17:57
<vagrantc>
they exist because of hardare decisions to reduce price
17:57
<ogra_>
right
17:57
<alkisg>
How hard would it be for the firmware to provide a hook to "load overlay"
17:58
<ogra_>
and in the past pepole just built one kernel per board
17:58
<alkisg>
That the kernel could call at runtime...
17:58
<ogra_>
with dtbs it is possible to se the same kernel for multiple boards
17:58
with different dtbs
17:58
<vagrantc>
the kernel needs to know how to configure the memory and cpu
17:58
for example
17:58
<ogra_>
right
17:58
it needs to do that on startup
17:58
<vagrantc>
you don't want to run with those settings wrong
17:59
<ogra_>
same goes for initializing the peripherial HW
17:59
<vagrantc>
so in the time it takes to load those settings you might fry your ram or cpu
17:59
and device-tree is the way to build a single kernel that supports multiple disparate boards...
17:59
<alkisg>
It's the same with pcs, and it's been solved well enough years ago
18:00
<ogra_>
http://paste.ubuntu.com/13084133/ ...
18:00
alkisg, no, it had never to be solved by PCs because there the BIOS does all this
18:00
<alkisg>
E.g. nvidia starts with low frequency, and it supports uploading a firmware dynamically, that gives you the option to run it at higher rates
18:00
<vagrantc>
alkisg: it was solved by BIOS...
18:00
<alkisg>
The bios doesn't know about nvidia
18:00
<ogra_>
the bios does know about the right INT call to enable the card
18:00
it wont configure it futher
18:01
but will give you basic graphics support
18:01
<vagrantc>
alkisg: maybe you should take this to the linux list :P
18:01
<ogra_>
haha
18:01
anyway, see my paste above
18:01
<alkisg>
ogra_: it's the same one that I'm using to boot rpi here
18:01
<vagrantc>
alkisg: basically, that's how it is ... it's kind of pointless to argue here :P
18:01
<ogra_>
that is what your fat partition (first partition on the SD) needs to contain
18:01
<alkisg>
I'm not arguing, i'm trying to understand
18:02
<vagrantc>
alkisg: there are more busses that are probe-able on x86 architecture
18:02
<alkisg>
Could you guys comment on what the person that helped with u-boot siad?
18:02
I asked him if there are any drawbacks to netbooting rpis with uboot as opposed to with a local kernel/initrd, and then netboot. He said:
18:02
"there is one: you can't do device tree parameters easily with u-boot, because as i learned yesterday, those are specific to the pi bootloader
18:03
<vagrantc>
alkisg: x86 architecture is far more standardized ... so they solved the issue by building hardware that was virtually identical ... in the ARM world, you have to have a definition somewhere to describe what you're booting, rather than auto-probing a lot of things...
18:03
<ogra_>
the boot goes: start.elf -> fixup.dat (they are the blob) -> load config.txt and basic dtb (bcm2709-rpi-2-b.dtb for the rpi2) -> load dtbs from overlay dir if config.txt defined them -> laod uboot.bin (teh binary needs to be padded with the rpi kernel script) ... then switch to uboot ...
18:03
<alkisg>
He later said that users could do it by "or you can build a whole new device tree blob" and passing that one to u-boot
18:03
...but I didn't quite understand if there are real drawbacks in booting with u-boot or not
18:04
<vagrantc>
alkisg: ARM is far less standardized from a hardware point of view, basically.
18:04
<ogra_>
in uboot you need to call "fdt addr 0x100" at some point to load the dtb from ram where the blob has placed it
18:05
<alkisg>
ogra_: we can also tell u-boot to download an fdt via tftp and pass it to the kernel. Does that mean that I don't need an overlay dir in the sd card?
18:05
<ogra_>
and as i said, loading another dtb via uboot will make the kernel switch back to ATAGs and disable dtb support altogether
18:05
<vagrantc>
ogra_: and loading to ram from u-boot itself to the same address doesn't work?
18:05
<ogra_>
so tftp'ing it isnt an option
18:05
vagrantc, failed for me every time i tried
18:05
<alkisg>
The raspberrypi person there did it with fdt from tftpd
18:06
<ogra_>
not sure what the blob does to it exactly but it seems to be different to how uboot does it
18:06
<vagrantc>
so the binary blob firmware is probably mangling it in some bizarre way
18:06
<ogra_>
alkisg, and you are 100% it didnt just switch back to ATAGs ?
18:06
<alkisg>
I've no idea what ATAGs are
18:06
<ogra_>
it would still boot but with degraded peripherials
18:07
<alkisg>
ogra_, so basically do you think that I shouldn't bother with u-boot, and let the kernel+initrd in the sd card for netbooting ltsp in rpi?
18:07
Because of those ^ issues that you pointed?
18:08
<vagrantc>
nothing quite like experimentation to figure it out for sure :)
18:08
<ogra_>
either that or tftp the dtb, fatwrite and reboot again to get the dtb in the right places
18:08
*place
18:09
<vagrantc>
hrm... apparently the raspi2 kernel doesn't have the patches separated out ...
18:09
<alkisg>
vagrantc: I wouldn't know how to distinct between normal and degraded peripherals mode. If the screen, keyboard and network work, I don't know what else to test, I've no experience with I2C bus or touch screens etc etc...
18:09* vagrantc just dumps a patchset from git
18:10
<vagrantc>
alkisg: it was rather obvious to me ... resolution was 640x480 max on a 1280x720 screen
18:10
(and the screen worked fine when booting without u-boot)
18:12
<ogra_>
vagrantc, it has a git tree somewhere on kernel.ubuntu.com
18:12
<vagrantc>
probably also reading the kernel boot logs it would say something obvious, moreorless
18:12
<ogra_>
the base should be the ubuntu generic kernel (which we use for all other arm arches )
18:12
like the debian multiarm kernel
18:15* vagrantc nods
18:18
<ogra_>
well, the resolution is passed to the blob from config.txt ... so if you want higher resolution you will have to define it there
18:19stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 268 seconds)
18:19
<alkisg>
Meh when I put the u-boot.bin that that person gave me, I get a blank screen. Is it possible that it needs a different firmware version? I have the one from ubuntu, and he used the one from raspbian/jessy afaik...
18:23
<vagrantc>
it's very possible that you need a different firmware version.
18:26FrankBlues has left IRC (FrankBlues!~alex@c-67-171-127-41.hsd1.ut.comcast.net, Ping timeout: 252 seconds)
18:28stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org)
18:32
<alkisg>
Nah, I give up on u-boot for now. His files/documentation are in http://al.robotfuzz.com/~al/random/rpipxe.tar.bz2 in case anyone wants to try netbooting rpi2 with u-boot.
18:32
Automatic kernel upgrades work fine, good enough for me, both for rpi and for cases where ipxe doesn't support the nic
18:32
vagrantc: ah, about the other thing with the alternate dhcp ports etc
18:33
How would you feel if we supported some method of using ipv6 only in the initramfs?
18:33
I.e. if we passed some parameter in the cmdline, "i-have-no-control-over-the-dhcp", then it could use the classic static ipv6 addresses, and locate the server again in a static ipv6 address
18:34
After it contacts the server and gets ROOTSERVER, ROOTPATH etc, it would continue with ipv4, the ipv6 part would only be there to help in initramfs
18:35stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 252 seconds)
18:38
<vagrantc>
alkisg: using ipv6 did cross my mind ... but if you have a network that actually uses ipv6 ... then what?
18:40
<alkisg>
vagrantc: then don't use the i-have-no-control-over-the-dhcp flag
18:40
And use a real dhcp server
18:40
vagrantc: also, we don't support ipv6 booting anyway, do we?
18:41
The static ipv6 addresses in the initramfs would be valid
18:41
We wouldn't break his network...
18:41
<vagrantc>
the addresses would be valid, but if the network has dhcpv6 or something configured ... what methods are we using to discover the ip address of the server?
18:42
<alkisg>
wget <static-server-ip> ==> gives us the dynamic ipv4 server ip
18:42
<vagrantc>
do we have a static server ip address that will be valid?
18:43
<alkisg>
In ipv6, we can have a lot of static ipv6 addresses, like the extended version of 192.168.67.1
18:43
And multiple IPs etc as well
18:43
<vagrantc>
having more ip addresses doesn't seem to resolve the issue
18:43
<alkisg>
I'll check for the exact address/private range that we can use
18:43FrankBlues has joined IRC (FrankBlues!alex@2601:681:4401:1c00:75d4:62e4:e3b2:e5f1)
18:44* vagrantc didn't think ipv6 had private ranges
18:44
<alkisg>
I read about them a while ago, but I've never used ipv6 so I don't remember all that I've read
18:46
Hyperbyt1: I think you're good with networks, do you have ipv6 experience?
18:46* alkisg reads https://en.wikipedia.org/wiki/Private_network#Private_IPv6_addresses ...
18:47
<alkisg>
actually link-local was a better match for our case if I remember correctly
18:47stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org)
18:48Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
18:49
<alkisg>
https://en.wikipedia.org/wiki/Link-local_address#IPv6
18:50
<vagrantc>
but link-local addresses are automatically assigned and cannot, by definition, be static.
18:50
<alkisg>
hey may be assigned by automatic (stateless) or stateful (e.g. manual) mechanisms.
18:55danau111 has joined IRC (danau111!~durban@66.251.57.114)
18:55stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 240 seconds)
19:00danau111 has left IRC (danau111!~durban@66.251.57.114)
19:01gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: mv /proc/self $HOME)
19:02
<alkisg>
When the client is at `break=mount`, I can do from the server: `ping6 -I eth1 fe80::5054:ff:fe25:e337`, and it replies fine, i.e. ipv6 is already initialized at that stage by ipconfig
19:02
busybox wget claims to support ipv6 since many years ago, that's ok too...
19:08FrankBlues has left IRC (FrankBlues!alex@2601:681:4401:1c00:75d4:62e4:e3b2:e5f1, Ping timeout: 240 seconds)
19:14
<alkisg>
Hrm, it might actually make sense to use ipv6 local addresses for the nbd connection as well
19:16
They don't need leases etc, they're not routable, they might even persist if one does "dhclient eth0" to re-initialize networking...
19:17stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org)
19:25stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 268 seconds)
19:26stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org)
19:28
<alkisg>
The bandwidth dropped from 94.1 to 92.8, ok the overhead is small...
19:28
!nbd-client
19:28
<ltsp`>
nbd-client: To try mounting the NBD image from the client initramfs: nbd-client 192.168.67.1 -N /opt/ltsp/i386 /dev/nbd0
19:37* vagrantc seems to recall some surprises with link-local addresses
19:38
<vagrantc>
maybe you can only reach link-local addresses on the same switch ... chained switches or something had issues?
19:39
doesn't seem to be the case here...
19:40FrankBlues has joined IRC (FrankBlues!~alex@c-67-171-127-41.hsd1.ut.comcast.net)
19:42
<alkisg>
I can't make nbd-server listen on ipv6, while it's supposed to do that by default
19:43
It's listening on 0.0.0.0 only, that doesn't include ipv6, right? E.g. sshd listens on :::22 as well...
19:50
<quinox>
our nbd only does ipv4 as well ATM
19:52
<vagrantc>
IPv6 support was supposedly added to NBD in 2.9.15
19:54bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy)
20:00danau11 has joined IRC (danau11!~durban@66.251.57.114)
20:03
<vagrantc>
confirmed on debian stretch ...
20:03* vagrantc reports a bug
20:04* vagrantc wonders if it would listen on a network with routeable ipv6
20:14
<alkisg>
quinox: "our nbd", which one do you mean?
20:15
The normal nbd-server in your local installation, or some other nbd-server variant?
20:16
<vagrantc>
https://bugs.debian.org/803795
20:17
<alkisg>
Thanks vagrantc :)
20:17
<vagrantc>
if it's a relatively easy fix, wouter will probably have it fixed in a few days ... though that doesn't really help older versions.
20:18
<alkisg>
preparing for ltsp6... :D
20:19* vagrantc would love for ltsp6 to support ipv6
20:19
<vagrantc>
it only seems natural.
20:20
<alkisg>
ouch, it will take a lot of time for epoptes to support ipv6 then :D (epoptes v6...)
20:23
<vagrantc>
well, we worked hard to support IPv6 when we released LTSP5.
20:23
er, oops.
20:23* vagrantc broke a joke.
20:23
<vagrantc>
well, we worked hard to support IPv5 when we released LTSP5.
20:23
<alkisg>
So I'm guessing that if we're using ipv6 link local addresses to access the root disk and swap, we could even let dhclient and network manager do their job normally, similar to aoe
20:23
<vagrantc>
of course, excellent projects sometimes add support before their time
20:24
as long as they don't died when reconfiguring other parts of the network interface...
20:24
<alkisg>
ltsp is a mostly a glue for other people's projects, so we can only support ipv6 when all of those other projects do
20:25* vagrantc nods
20:25klausade has joined IRC (klausade!~klaus@cm-84.215.169.187.getinternet.no)
20:27
<alkisg>
Goodnight all :)
20:27alkisg is now known as work_alkisg
20:28
<quinox>
I meant "the nbd that we have running"
20:29
it's whatever Ubuntu ships
20:35
so if I want to upgrade the server and clients to 15.10, what would be the best way to get LTSP working again?
20:35
the last 6 or so upgrades using the default LTSP package worked great, except for the very last one (15.04)
20:36
the overlayfs thingy
20:37
with your help (greatly appreciated) we managed to make it working again by hacking the early boot-mount-script-thingies
20:41
with <15.04 I would upgrade the server, delete /opt/ltsp/amd64, run ltsp-build-client, manually fix a few custom things (LDM skin, packages such as skype) and voilà
20:43
(actually, with 14.10 I had to switch to the ltsp-build-client from trunk to fix the 'missing file' error #1387773)
20:46
We've been happily using LTSP since before 2010-10-12 :D
20:47
that's the date of our first proper LTSP documentation entry, before that we had some misconfigured / hacked LTSP that couldn't be upgraded without a lot of voodoo
20:51stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 264 seconds)
21:02stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org)
21:08stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 268 seconds)
21:28stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org)
21:33stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Ping timeout: 268 seconds)
21:35ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:51stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org)
21:57stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Changing host)
21:57stgraber has joined IRC (stgraber!~stgraber@ubuntu/member/stgraber)
21:57bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Remote host closed the connection)