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

Request log from specific day:

Channel log from 10 March 2016 (all times are UTC)

00:48	teknkik_ has joined IRC (teknkik_!tek@kapsi.fi)
00:48	yanu_ has joined IRC (yanu_!~yanu@178-116-58-90.access.telenet.be)
00:49	teknkik has left IRC (teknkik!tek@kapsi.fi, Ping timeout: 248 seconds)
00:49	yanu has left IRC (yanu!~yanu@178-116-58-90.access.telenet.be, Ping timeout: 248 seconds)
00:49	quinox has left IRC (quinox!~quinox@ghost.qtea.nl, Ping timeout: 248 seconds)
00:49	quinox has joined IRC (quinox!~quinox@ghost.qtea.nl)
01:18	vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 264 seconds)
02:06	dtcrshr has left IRC (dtcrshr!~datacrush@unaffiliated/datacrusher, Ping timeout: 260 seconds)
02:10	dtcrshr has joined IRC (dtcrshr!~datacrush@unaffiliated/datacrusher)
05:16	vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
05:34	vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
05:56	ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Remote host closed the connection)
05:56	ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
06:01	alkisg_away is now known as alkisg
06:01	ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 268 seconds)
06:01	ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
06:49	ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:10	mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
07:58	Vlad__ has joined IRC (Vlad__!c2e28421@gateway/web/freenode/ip.194.226.132.33)
08:22	<Vlad__> Hello, I'm trying to config iPXE with LTSP on Debian 7, it works, but clients do not want to use lts.conf; seems they can't download it
08:22	lts.conf is located in the default /srv/tftp/ltsp/i386, tftp-server is up and running
08:22	<alkisg> Vlad__: are you sure it doesn't have syntax errors? Can you put its contents to pastebin?
08:23	<Vlad__> i just want to change color depth : [Default] X_COLOR_DEPTH=24
08:23	<alkisg> Is that on the same line?
08:23	Or in 2 lines?
08:24	<Vlad__> 2 lines
08:24	it works with default pxe but not with iPXE
08:24	<alkisg> Run this:
08:24	ltsp-localapps xterm
08:24	cat /proc/cmdline
08:24	(on a thin client)
08:24	and paste the result here, when you boot it with ipxe
08:24	So that we see the exact command line that you use
08:25	<Vlad__> init=/sbin/init-ltsp root=/dev/nbd0 nbdroot=192.168.25.1:/opt/ltsp/i386
08:26	<alkisg> OK, and: cat /var/cache/ltsp/net-*.conf
08:26	Put that one in pastebin
08:26	Actually, what's the ROOTPATH there?
08:27	The rest aren't important
08:27	Ah, and filename
08:27	So basically, what's the output of this command: grep -A1 ROOTPATH /var/cache/ltsp/net-*.conf
08:29	kjackal has joined IRC (kjackal!~kjackal@onopfy.static.otenet.gr)
08:29	<Vlad__> mmm... there are no such files in /var/cache/ltsp, only ltsp_config and ltsp_config_env, none of them have ROOTPATH
08:31	<alkisg> Vlad__: find /var -name 'net*.conf'
08:31	Maybe debian put it in run instead of cache
08:32	If you have root access to the client, you can also try this: sudo /usr/lib/klibc/bin/ipconfig -n eth0
08:33	This will ask for a fake ip lease, so that we can look at rootpath/filename from there
08:33	<Vlad__> there is /run/net-eth0.conf with empty ROOTPATH=''
08:33	<alkisg> And filename?
08:34	<Vlad__> ipxe/undionly.kpxe
08:34	<alkisg> OK, so the client tries to get lts.conf from /srv/tftp/ipxe/lts.conf
08:34	Either symlink it there or change the filename that you send to ipxe
08:35	...to ipconfig,not to ipxe
08:35	Somewhere in your dhcpd.conf you have an "if" for the boot filename
08:35	There are 3 things that ask for the filename
08:35	PXE, iPXE, and Linux ipconfig in the initramfs
08:36	PeperPots has left IRC (PeperPots!sid1218@gateway/web/irccloud.com/x-hpnzkgdlcnichswm, Ping timeout: 268 seconds)
08:36	<alkisg> The last one should be pointed to lts.conf, not to "ipxe/undionly.kpxe"...
08:36	riddle has left IRC (riddle!riddle@us.yunix.net, Ping timeout: 244 seconds)
08:38	<Vlad__> i made a symlink in ipxe folder and it works now
08:38	thanks a lot!
08:38	<alkisg> You're welcome
08:38	Vlad__ has left IRC (Vlad__!c2e28421@gateway/web/freenode/ip.194.226.132.33)
08:38	riddle has joined IRC (riddle!riddle@us.yunix.net)
08:44	PeperPots has joined IRC (PeperPots!sid1218@gateway/web/irccloud.com/x-aodyqbphqxbtjpxm)
09:00	kjackal has left IRC (kjackal!~kjackal@onopfy.static.otenet.gr, Remote host closed the connection)
09:02	kjackal has joined IRC (kjackal!~kjackal@onopfy.static.otenet.gr)
09:03	NeonLicht has joined IRC (NeonLicht!~NeonLicht@darwin.ugr.es)
09:10	NeonLicht has left IRC (NeonLicht!~NeonLicht@darwin.ugr.es)
09:15	<alkisg> !kvm
09:15	<ltsp> kvm: Virtual thin client: kvm -vga-vmware -ctrl-grab -no-shutdown -net nic,model=virtio -net user,tftp=/var/lib/tftpboot,bootfile=/ltsp/i386/pxelinux.0
09:21	<alkisg> !nbd-clients
09:21	<ltsp> I do not know about 'nbd-clients', but I do know about these similar topics: 'nbd-client'
09:21	<alkisg> !client-list
09:21	<ltsp> client-list: to get a list of all nbd-clients (which sometimes is the same as ltsp clients), run: netstat -tn \| sed -n 's/.:10809 $[0-9.]$:./\1/p' \| sort -Vu
09:40	Sathya has joined IRC (Sathya!90313201@gateway/web/freenode/ip.144.49.50.1)
09:40	<Sathya> Hi
09:40	<alkisg> Hi
09:40	<Sathya> I have a bunch of embedded systems
09:41	I need to connect to them via the internet
09:41	through different ports
09:41	But the same IP
09:41	I was just wondering if this is possible through LTSP?
09:42	<alkisg> LTSP is about netbooting linux systems
09:42	Not about connecting to them
09:43	Maybe you're interested in epoptes instead
09:43	!epoptes
09:43	<ltsp> epoptes: Epoptes is a computer lab administration and monitoring tool. It works on Ubuntu and Debian based labs with LTSP or non-LTSP servers, thin and fat clients, standalone workstations, NX clients etc. More info: http://www.epoptes.org
09:43	<Sathya> Will check that,
09:43	thanks :)
09:44	robb_nl has joined IRC (robb_nl!~robb_nl@ip-213-49-244-173.dsl.scarlet.be)
09:44	Sathya has left IRC (Sathya!90313201@gateway/web/freenode/ip.144.49.50.1, Client Quit)
11:08	<Hyperbyt1> alkisg, actually, what he's interested in I think is setting ip_forward to 1
11:08	Or maybe I misunderstand
11:09	ANYWAY HI!
11:09	How's Greece today?
12:14	kjackal has left IRC (kjackal!~kjackal@onopfy.static.otenet.gr, Ping timeout: 244 seconds)
12:30	robb_nl has left IRC (robb_nl!~robb_nl@ip-213-49-244-173.dsl.scarlet.be, Ping timeout: 240 seconds)
12:31	robb_nl has joined IRC (robb_nl!~robb_nl@ip-213-49-244-173.dsl.scarlet.be)
12:38	robb_nl has left IRC (robb_nl!~robb_nl@ip-213-49-244-173.dsl.scarlet.be, Ping timeout: 252 seconds)
12:44	Hyperbyt1 is now known as Hyperbyte
12:47	Faith has joined IRC (Faith!~paty_@unaffiliated/faith)
13:00	kjackal has joined IRC (kjackal!~kjackal@2a02:587:3110:5800:cca9:866f:3437:83c2)
13:00	kjackal has left IRC (kjackal!~kjackal@2a02:587:3110:5800:cca9:866f:3437:83c2, Remote host closed the connection)
13:00	kjackal has joined IRC (kjackal!~kjackal@2a02:587:3110:5800:cca9:866f:3437:83c2)
13:02	gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
13:29	Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
14:08	cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 252 seconds)
14:15	Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
14:37	robb_nl has joined IRC (robb_nl!~robb_nl@ip-213-49-244-173.dsl.scarlet.be)
14:48	mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
14:56	ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
15:45	vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:06	<alkisg> Hyperbyte: I thought he was interested to connect from the internet (e.g. his home), to the remote embedded systems, when they're all behind NAT. That could be done with one port forwarding per device on the router, or with reverse connections, like epoptes does.
16:06	Greece is fine, a bit of rain, a bit of sun... :)
16:19	<sbalneav> Well. That's been a productive bit of hacking that will help LTSP
16:19	https://github.com/sbalneav/pty
16:19	So, now you can do a:
16:20	(sleep 2; echo "password") \| pty ssh user@host
16:26	robb_nl has left IRC (robb_nl!~robb_nl@ip-213-49-244-173.dsl.scarlet.be, Ping timeout: 252 seconds)
16:28	<alkisg> Can't `ssh -tt` do that?
16:29	<vagrantc> depends on how many -t arguments and the phases of the moon and the alignment of invisible forces
16:29	<alkisg> :)
16:30	<sbalneav> alkisg: No, ssh -tt will never read purely from stdin, it'll complain if it loses a controlling terminal
16:30	however, what this does is actually fork a pty, which becomes the child process' controlling terminal.
16:32	<vagrantc> sbalneav: so, we don't need sleepy echo passwords ... how would you propose to use it?
16:33	<sbalneav> well, here's what I want... I hate that right now, we're having to write the password out to a file in libpam-sshauth. It's gross. Especially since libpam_exec can expose the password via stdin.
16:33	So here's what I want to modify.
16:34	in libpam_sshauth, I'll add in the code to do a "id -u" and "id -t", and set a pam environment variable.
16:36	then in the libpam_exec, we can just do a (su - $uid pty ssh user@server <args>) once, get the password from stdin, and bingo, we've got our user-owned ssh in one call, rather than doing the two ssh's and saving the password like we do now.
16:37	<vagrantc> ok, that sounds better in principle...
16:37	although knowing the right time to send the password to ssh seems ... tricky.
16:39	<sbalneav> Well, the sleep thing's just a quicky. I'll script things so that I wait to see the ":" before sending the passwd
16:39	<vagrantc> "please enter your authentication details which will be published in cleartext on the internet:"
16:39	like that? :)
16:40	<sbalneav> Yeah :D
16:40	CIA's already got your password anyway, so what's the big deal? :D
16:40	<vagrantc> moar acronyms
16:40	robb_nl has joined IRC (robb_nl!~robb_nl@ip-213-49-244-173.dsl.scarlet.be)
16:42	<sbalneav> I used that pty thing to write a pygtk password changer that's just a shell around the "passwd" program, that ALSO doesn't talk nicely to stdin/out.
16:42	I'll pop that up on github later today, too.
16:43	vagrantc: While I'm at it, would you be willing to sponsor two packages into debian sid? We're getting ready to release lightdm-webkit-greeter and lightdm-webkit2-greeter soon.
16:43	I've worked my *ss off for the last several months. The webkit greeters are currently the only ones in which it's possible to see all the pam messages in.
16:43	<vagrantc> sbalneav: entirely different codebase for the two?
16:44	<sbalneav> -webkit2's based off -webkit, but with lots of changes based on the different way webkit2 acts. But functionally, they do the same thing. Have all the same features.
16:44	https://launchpad.net/lightdm-webkit-greeter
16:45	https://github.com/Antergos/lightdm-webkit2-greeter
16:45	I took over maintainership of -webkit, then I approached the -webkit2 port guys with my changes/fixes/improvements, and started syncing the two, function-wise.
16:47	robb_nl has left IRC (robb_nl!~robb_nl@ip-213-49-244-173.dsl.scarlet.be, Remote host closed the connection)
16:47	<sbalneav> I'd love to see 'em both make their way into debian proper. Into the next release would be awesome, but I don't know if it's too late for that or not.
16:47	<vagrantc> it's pretty infeasible to integrate them into a single project with different build flags?
16:48	<sbalneav> I'd say, yeah. webkit's a standalone program, -webkit2's a plugin
16:48	<vagrantc> sbalneav: also, not sure what the lifespan of webkit vs. webkit2 is ... if it's deprecated, it might not be proper to push to debian
16:49	<sbalneav> AFAIK, both are still supported; in Jessie, only webkit's available, the version of webkit2 in jessie is buggy.
16:49	but the webkit2 in sid works fine.
16:50	So if you only wanted to do that one, I'd be cool with it.
16:51	the idea is that, at some point, the -webkit one will just die on the vine as webkit reaches EOL, and webkit2'll be the go-forward one.
16:51	So if there's a chance for lightdm-webkit2-greeter to be in the next debian stable, then forget -webkit and just do the webkit2 one.
16:53	Personally, I'd like to see us use it for the big "lightdm" conversion; we can very easily theme an "ltsp" greeter, and we know we'll have the ability to see all the pam messages we may need to deal with when we eventially move to libpam-sshauth
16:53	<vagrantc> sbalneav: not real familiar with webkit, so just brought up some of my quick thoughts on the matter
16:54	kind of kills the original goal of arbitrary display managers
16:54	but if it reduces how much code to maintain, it might still be a good thing
16:55	<alkisg> The problem with other pam-aware display managers is that they don't pass the password to the ssh-auth pam hooks?
16:56	<sbalneav> No, they should all work fine... the issue is, lots of display managers and/or greeters do a very sloppy job of handling the full range of pam messages.
16:57	Here's the problem; for me, in a corporate environment, we have password strength checkers, password expiry, and we're using the ldap password policy thing to handle password history
16:58	so when your password expires, it's going to do LOTS of things, like tell you if a password you've typed is too short, a dictionary word, etc.
16:58	<alkisg> Ah, and the other display managers don't show the whole chat in their UI?
16:58	<sbalneav> we're using pam-passwdqc, which spits out pam messages like this:
16:59	(current) LDAP Password:
16:59	You can now choose the new password or passphrase.
16:59	A valid password should be a mix of upper and lower case letters,
16:59	digits, and other characters. You can use a 9 character long
16:59	password with characters from at least 3 of these 4 classes, or
16:59	an 8 character long password containing characters from all the
16:59	classes. An upper case letter that begins the password and a
16:59	digit that ends it do not count towards the number of character
16:59	classes used.
16:59	A passphrase should be of at least 3 words, 12 to 40 characters
16:59	long, and contain enough different characters.
16:59	Alternatively, if no one else can see your terminal now, you can
16:59	pick this as your password: "trace!rise!censor".
16:59	Enter new password:
16:59	lightdm-gtk-greeter has one status line for messages :D
16:59	so you don't see all of that help text.
17:00	And I think GDM just throws that stuff away entirely
17:00	Don't even get me started on kdm :D
17:00	<alkisg> Haha
17:00	So, in regular cases without ldap etc etc, the other display managers may also work fine with ssh-auth?
17:00	<sbalneav> sure.
17:00	They all work in "simple" cases.
17:01	i.e. "enter your username, enter your password, thanks you're logged in"
17:01	<alkisg> That's much better, at first I was thinking they wouldn't work at all
17:02	<sbalneav> It's just when you start wanting to do "complicated" things with pam, then the number of options goes way down, because lots of DM's just don't handle the full range of stuff that pam's capable of doing.
17:02	but
17:02	<vagrantc> sbalneav: thanks for the extended explanation ... that's a lot clearer :)
17:03	<alkisg> sbalneav: have you thought about the hooks that ltsp will need from the DM or the PAM? Like all the ACTIONs in /usr/share/ldm/ldm-script? init/pressh/start/xsession/stop?
17:03	<sbalneav> lightdm + webkit[2]-greeter get's ALL the messages, and can handle them all. So, if you're looking for one DM + greeter combo that will absolutely, positively, work no matter HOW COMPLICATED your pam setup is... that's the one to use.
17:03	<alkisg> (err sorry, finish with the but first :))
17:04	<sbalneav> alkisg: yeah, we'll have to cook that in somehow.
17:04	<alkisg> Got it, so ltsp could Recommend lightdm + webkit2, but also allow users to select other DMs if they want
17:04	<sbalneav> I think it's all doable.
17:04	alkisg: exactly.
17:05	Plus, you've got the advantage that your greeter's... just an html page with some javascript.
17:06	bbiab
17:06	<alkisg> And all the broken parts of lightdm, like breaking the keyboard layout etc etc :D
17:07	<sbalneav> ahhhh, but I'm now "in good with" lightdm's author, Robert Ancell
17:07	So if something's broken, let's fix it :D
17:07	<alkisg> That's a great asset :)
17:07	<sbalneav> bbiab
17:07	<alkisg> bb
17:08	<vagrantc> wow, there are a sea of libwebkit packages in debian
17:09	sbalneav: are you testing with the libwebkitgtk-dev packages?
17:12	looks like webkitgtk3 for lightdm-webkit-greeter
17:13	and webkit2gtk-4.0 for lightdm-webkit2-greeter
17:18	well, lightdm-webkit-greeter still seems to build with the packaging from when i last touched it in november
17:19	here's to properly done build systems.
17:30	<sbalneav> back
17:30	Here's one of the key things I think we're missing that we'll need.
17:32	We want to be able to pass arbitrary data back and forth from the greeter to other parts of the pam stack; i.e. have a drop-down on the greeter page with a list of servers to log into, and then have that be able to be picked up elsewhere.
17:32	The way to do that is with pam environment variables; i.e. set a pam env variable at auth, that would be available later on.
17:33	lightdm currently doesn't have that, but I think I could add that easily to lightdm... I'll talk to Robert about it.
17:35	<alkisg> Maybe we could also do it the windows way, \\server\user, whenever there are multiple servers and the default isn't the one the user wants?
17:35	I.e. type the server as part of the username, not sure about the exact syntax there
17:36	<sbalneav> Well, sure, but the issue is, there's no way to pass that "server" back up the pam stack to be used later on in the login process by the ltsp scripts
17:36	aluno has joined IRC (aluno!b154a939@gateway/web/freenode/ip.177.84.169.57)
17:36	<sbalneav> within lightdm. But I could add that.
17:37	aluno has left IRC (aluno!b154a939@gateway/web/freenode/ip.177.84.169.57, Client Quit)
17:38	<alkisg> Maybe the local username can keep the "server" part in it
17:38	Imagine multiple logins, user@server1 and user@server2, simultaneously
17:39	...shouldn't those map to 2 different local users?
17:39	Meh, messy
17:40	cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
17:40	gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving)
17:46	<vagrantc> as the one who originally pushed for multiple login servers ... do we need to continue to support it?
17:47	<sbalneav> I don't use it personally; but that don't mean bupkis :D
17:47	* alkisg votes no... only with some automatic load-balancer script that rotates the "server" hostname
17:48	<vagrantc> and libpam-sshauth only provides one auth server currently, right?
17:49	<sbalneav> Yes, but the auth is fast; presumably, once you've authed the session can be spawned anywhere.
17:50	<vagrantc> hrm. lightdm-webkit2-greeter is failing to autogenerate it's makefiles
17:51	sbalneav: as in, authenticate on one server, and then sshfs mount the homdir (and/or log in to alternate server as a thin client) from an alternate server with the same credentials?
17:52	oh, maybe i need cmake?
17:52	<alkisg> Different servers might have different (or same) $HOME for the same user. A complete mess...
17:53	Multiple logins would only make sense with a different $HOME per user
17:54	Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
17:54	<vagrantc> multiple concurrent logins from the same machine seem like a nightmare, yes ...
17:55	but simply logging into different servers?
17:55	<alkisg> Personally I wouldn't want to ever have to work on DMs, greeters etc
17:56	So since they usually don't expose the server there, I'd prefer it if we either didn't support it at all, or with the \\server\user syntax
17:56	...i.e. anything that doesn't require us to touch DM/greeter code
17:57	I understand that maintaining our own greeter gives us a lot of flexibility, and I wouldn't mind defaulting to that, but I wouldn't want to _depend_ on that...
17:58	<vagrantc> the \\server syntax is awful
17:58	sbalneav: i'm getting configure.ac:115: error: required file 'themes/antergos/css/vendor/Makefile.in' not found
17:59	<alkisg> alkisg@server2 might be a better syntax
17:59	<vagrantc> sbalneav: any idea how that is supposed to be generated?
17:59	<sbalneav> vagrantc: gaaaaaah
17:59	<vagrantc> alkisg: breaks on systems that have @ in the username
17:59	<sbalneav> I know exactly what that is.
17:59	He's got a git submodule in there for his antergos theme.
17:59	<vagrantc> meh.
17:59	* sbalneav whispers
18:00	<vagrantc> can we ditch that theme?
18:00	<sbalneav> I want him to remove it, yes.
18:00	I'll talk to him about it.
18:00	<vagrantc> any other submodules?
18:00	<sbalneav> No, only that one.
18:01	<vagrantc> i think i can just patch it out of themes/Makefile.am ?
18:01	<sbalneav> Yes, probably
18:01	Might need to touch configure.ac as well
18:01	Better option would be for upstream to make it a separate package
18:02	<vagrantc> sure
18:02	but in the meantime...
18:02	<sbalneav> Sure, patch now, I'll wheedle in the meantime :D
18:15	<vagrantc> huzzah! lightdm-webkit2-greeter built!
18:30	sbalneav: are the .la files needed at runtime, or can they be excluded?
18:31	<sbalneav> Needed, i believe, due to webkit2's plugin nature.
19:13	<alkisg> So, on fat clients with ancient graphics cards, setting X_COLOR_DEPTH=16 makes things 3+ times faster, youtube watchable vs unwatchable etc
19:16	E.g. trident: 8bpp => 50 putimage/sec, 16bpp => 20 putimage/sec, 24 bpp => 6 putimage/sec
19:16	8bpp is crashing many apps, so 16bpp is the best option there
19:22	* quinox will check that out
19:39	<quinox> http://www.inktechnologies.com/blog/wp-content/uploads/2011/04/Color-Depth.jpeg hardly noticeable
19:45	<alkisg> 16bpp is usable as a color depth, sure. It's just strange that it makes such a big difference on fat clients graphics speed though.
19:58	<\|\|cw> its' 50% per bandwidth, and if that's all that's needed to saturate the link...
19:58	per/more/
19:59	in the case of old graphics cards, the link is pci, and often RAM constrained
20:02	<alkisg> Back in 1995 I was doing graphics in assembly, it was easy to get 60fps etc. I can't understand how e.g. x11perf -putimagexy500 can only do 0.7 putimages per second in e.g. nvidia vanta
20:03	Maybe too much copying around between buffers, dunno what they're doing wrong
20:05	http://www.nvidia.com/page/vanta.html => 200 million pixels per second, 1 GB / sec bandwidth etc
20:05	<\|\|cw> vanta's a name I haven't heard in a while
20:06	<alkisg> More than enough for HD video :)
20:06	Not 1 fps :)
20:09	putimagexy500 in 32bpp = 1 MB. So the bandwidth is enough for 1000 putimages per second, not 0.7...
20:10	Even if the pci bus limits that to e.g. 133 MB/sec, it should be 200 times faster than what it is
20:13	Faith has left IRC (Faith!~paty_@unaffiliated/faith, Ping timeout: 252 seconds)
20:18	Faith has joined IRC (Faith!~paty_@143.107.231.49)
20:28	ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 260 seconds)
20:28	ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
20:42	Faith has left IRC (Faith!~paty_@143.107.231.49, Changing host)
20:42	Faith has joined IRC (Faith!~paty_@unaffiliated/faith)
21:01	Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving)
21:11	ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:17	Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
22:24	<alkisg> vagrantc: ...could you give me a command to build a wheezy chroot with your ltsp backports, from a stretch server? :)
22:24	<vagrantc> alkisg: not at this second, gotta run!
22:25	vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
22:25	<alkisg> np, paste it whenver you have time, bb
22:37	deb https://cascadia.debian.net/~vagrant/debian wheezy-backports-sloppy-UNRELEASED main
23:06	Goodies it booted fine with a 16.04 server
23:30	ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)