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


Channel log from 25 November 2013   (all times are UTC)

02:42Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
02:49bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Remote host closed the connection)
03:24
<vagrantc>
hrm.
03:25Parker955 has left IRC (Parker955!~parker@74.112.203.151, Ping timeout: 245 seconds)
03:28
<vagrantc>
udev only appears to generate udev events on cd insertion/removal when cdpinger is running
03:32Parker955 has joined IRC (Parker955!~parker@74.112.203.151)
03:35telex has left IRC (telex!~telex@freeshell.de, Remote host closed the connection)
03:36Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 246 seconds)
03:36telex has joined IRC (telex!~telex@freeshell.de)
03:41bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
03:47gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com)
03:51gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Ping timeout: 246 seconds)
03:52Fenuks has joined IRC (Fenuks!~Fenuks@109.202.25.212)
04:05alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
04:10
<alkisg>
Wow, tagging a new version don't produce any changes in the ldm.pot file, cool, we probably won't have to re-upload it :)
04:10
...we'll know for sure in 2 hours
04:12* vagrantc waves to alkisg
04:12
<alkisg>
Hi vagrantc! /me prepares to upload the new epoptes version to the PPA....
04:12
<vagrantc>
alkisg: so, i've uploaded ltsp, epoptes and now ldm in the last 24 hours...
04:12
alkisg: and then looking at ltspfs, i really want to kill cdpinger
04:12
<alkisg>
That was quite the busy weekend for all 3 of us :)
04:13
<vagrantc>
alkisg: but i don't get the udevadm monitor events .... except when cdpinger is running! :/
04:13
<alkisg>
Cool! Let's bug sbalneav until he tells us the appropriate udev rule! :D
04:13
Ah..!.... why?!!!
04:13
<vagrantc>
i'm so-so with udev, so i figured i'd give it a go
04:13
alkisg: i also was able to get the events by using "eject"
04:14
but simply inserting or ejecting a CD didn't do it.
04:14
i've only tried with libvirt/qemu-kvm machines ...
04:15
i guess i could try with a real hardware client...
04:15
<alkisg>
Virtualbox did produce notifications for me
04:15
Let me try with kvm...
04:16
!kvm
04:16
<ltsp>
kvm: To boot a virtual thin client with kvm: kvm -vga vmware -ctrl-grab -net nic,model=virtio -net user,tftp=/var/lib/tftpboot,bootfile=/ltsp/i386/pxelinux.0
04:17
<vagrantc>
alkisg: might be able to get a much simplified cdpinger, that triggers the udev events, and then a udev rule ...
04:17
but insertion and removal are both "change" events ... so there's no clear "add" or "remove" like with USB devices.
04:18
<alkisg>
vagrantc: if it appears that we do need cdpinger, then I vote we migrate to udisks + udisks-glue
04:21bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Quit: http://www.twelvetribes.org)
04:21clepto has joined IRC (clepto!~chadlepto@c-71-237-229-76.hsd1.or.comcast.net)
04:21clepto has joined IRC (clepto!~chadlepto@unaffiliated/chadlepto)
04:21
<vagrantc>
alkisg: i should test on wheezy, just to see if that produces different results
04:22
<alkisg>
vagrantc: http://paste.ubuntu.com/6472203/
04:22
On the kvm client I just started... Ubuntu 12.04
04:23
<vagrantc>
alkisg: with LOCALDEV=false ?
04:23
<alkisg>
Ah, sorry
04:23ChadLepto has left IRC (ChadLepto!~chadlepto@unaffiliated/chadlepto, Ping timeout: 264 seconds)
04:24
<vagrantc>
i'm hoping it's just a glitch in jessie, we've got 11 months to get that fixed :)
04:25
<alkisg>
Hmmm I have some configuration issues with kvm, it doesn't find lts.conf so let me try with vbox first, and localdev=false...
04:25
<vagrantc>
although not so many months to fix ubuntu 14.04
04:25* vagrantc needs to report a bug about changed behavior of "pgrep -l -f"
04:29
<alkisg>
vagrantc: http://paste.ubuntu.com/6472211/
04:29
All seem fine, let me try with vbox + wheezy chroot...
04:30
vagrantc: will you backport the newer ltsp/ldm to wheezy?
04:31
<vagrantc>
alkisg: i usually do, yes.
04:32* vagrantc keeps forgetting to add -updates support in the archive.
04:32
<vagrantc>
er, in ltsp-build-client
04:32
<alkisg>
vagrantc: whoops, no event on wheezy... I'll try to see what's different between ubuntu and debian
04:32
<vagrantc>
and i need to re-write the backports handling.
04:32
alkisg: my hunch is some additional process running that's polling or something
04:33
or maybe upstart vs. sysvinit
04:33
<alkisg>
I don't think so, I think I have all non-essential services disabled... it might be an udev rule missing from wheezy... let's see
04:34
<vagrantc>
i bet it's upstart.
04:34
i've occasionally tried upstart on debian ...
04:36
<alkisg>
http://paste.ubuntu.com/6472211/
04:36
Sorry
04:37
http://paste.ubuntu.com/6472240/
04:37
That's /lib/udev/rules.d/50-udev-default.rules from 12.04
04:38
It contains a block for cdroms that's not present on wheezy
04:38* alkisg tries to copy it to his wheezy chroot...
04:40
<alkisg>
...nope, didn't do the trick...
04:43
The processes running on the thin client - I'll try to minimize them: http://paste.ubuntu.com/6472257/
04:43
(on ubuntu, where it works)
04:45
<vagrantc>
upstart didn't fix it
04:45
but runs fine, it seems.
04:46
alkisg: wonder about kernel modules loaded or something
04:46
<alkisg>
Possibly... either that, or udev rules, I can't think of anything else
04:48
<vagrantc>
alkisg: i also ran with SCREEN_07=shell ...
04:48
that'd knock a few processes off
04:49gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com)
04:50
<alkisg>
Still works with minimized processes: http://paste.ubuntu.com/6472275
04:50
lsmod: http://paste.ubuntu.com/6472278/
04:51
vagrantc: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713877
04:51* alkisg reads that...
04:53gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Ping timeout: 252 seconds)
04:54
<alkisg>
If it's an udev ubuntu-specific hack, then it does make sense...
04:56
<vagrantc>
yup.
04:58
<alkisg>
vagrantc: I tried copying all of /lib/udev/rules.d from ubuntu to wheezy, and then it worked
04:59
So if it's as simple as an udev rule, then we can do it from ltsp, when needed
04:59
(from init-ltsp.d) so, you won't even need to wait for the udev patch to be accepted ;)
05:02* alkisg reboots wheezy and checks 60-persistent-storage.rules ...
05:03
<vagrantc>
whoah.
05:04
<alkisg>
I think it'll be a single-line change...
05:07
<vagrantc>
that'd be cool.
05:09
alkisg: so, launchpad just committed another seemingly pointless po update to ltsp...
05:09
<alkisg>
Meh
05:12
<vagrantc>
it seems to always want jim mcquillan as the last-translator... jim seems to do *all* of the translations according to launchpad.
05:13
<alkisg>
Where did you see that?
05:15
<vagrantc>
http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2503
05:15
in pt_BR.po
05:16
notably, jim is also listed as the last-translator for the other two in that branch
05:16
s,branch,commit,
05:17
<alkisg>
vagrantc: $ pastebinit /lib/udev/rules.d/80-udisks.rules
05:17
http://paste.ubuntu.com/6472329/
05:17
Put that in your wheezy or jessie chroot
05:17
<vagrantc>
the vast majority of ltsp-trunk/po/*.po list jim as the last-translator, though oddly not every single one
05:17
<alkisg>
Then retry udevadm monitor
05:17
It might need service udev restart
05:18
vagrantc: I think that when there are translations originating from launchpad, then it keeps the authors there on its internal database (per string), and it then changes the translator to the author
05:19
That does make a bit sense, since if I translate something, and then someone overwrites my translation, why would I be listed in the .po file?
05:19
It's not easy to do such refined control with .po headers...
05:19
<vagrantc>
launchpad requires logging in in order to download the file?!
05:19
er, paste.ubuntu.com
05:20
<alkisg>
Ouch, sorry, my pastebinit defaults
05:20
vagrantc: http://paste.debian.net/67614/
05:21
<vagrantc>
alkisg: but, i know jim is a man of the world, but i'm not sure he's fluent in *that* many languages :)
05:21
<alkisg>
:)
05:23
<vagrantc>
some of them are marked launchpad something somethin
05:25
first try failed, dropping in /etc/udev/rules.d/
05:26* vagrantc tries /lib/udev/rules.d
05:27
<alkisg>
Try also to restart udev, and verify that you have udisks installed
05:27
<vagrantc>
no dice there
05:28
<alkisg>
AFAIK my wheezy chroot is "clean", no extra programs installed except for epoptes-client...
05:28
<vagrantc>
udisks wasn't installed
05:28
<alkisg>
Wait, neither in my wheezy chroot...
05:28
<vagrantc>
i'm going to try installing udisks
05:29
and not use your rules
05:29
<alkisg>
It shouldn't be needed though, my wheezy chroot doesn't have udisks installed and it works
05:29
Maybe something kvm-related now?
05:30
<vagrantc>
didn't try in wheez
05:30
but i could
05:30* alkisg tries a clean reboot + only copying the 80-udisks file...
05:32
<alkisg>
vagrantc: nope, it's not working,
05:33
while previously, I copied all of the files, restarted udev,
05:33
restored all of the files, copied only 80-udisks, restarted udev,
05:33
and it worked,
05:33
so I believe that some of the other udev files I copied changed some kernel parameter
05:33
That continued to be applied even after I restored the original udev rules
05:34
So I'll need to dig more to find the exact rules that are needed
05:38
bb in 1h
05:38alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
05:43
<vagrantc>
"udisks --poll-for-media /dev/sr0" worked for me
05:51gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com)
05:52freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
05:56gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Ping timeout: 264 seconds)
05:56
<vagrantc>
got it responding to change events...
06:08Fenuks has left IRC (Fenuks!~Fenuks@109.202.25.212, Ping timeout: 248 seconds)
06:10Fenuks has joined IRC (Fenuks!~Fenuks@109.202.25.212)
06:29work_alkisg is now known as alkisg
06:32
<vagrantc>
alkisg: so, i've got a udev rule that sort of works with "udisks --poll-for-media /dev/sr0"
06:32
i still need to figure out how to distinguish between valid and invalid disks
06:32
er, between change events that are removals, and change events that are insertions
06:33* alkisg thought we already did that somewhere in our udev hooks...
06:33
<alkisg>
I'll try to pinpoint the exact udev rule needed in wheezy, so that udisks isn't needed
06:34
<vagrantc>
alkisg: we have add and remove, but both insertion and removal are "change" aactions
06:34
i think the change distinction will still be needed, though...
06:35
both are ACTION=="change", SUBSYSTEM=="block", ENV{ID_TYPE}="cd", RUN+="ltspfs_entry add_disc %k iso9660,udf"
06:35
there's gotta be some value that sets them apart
06:36
<alkisg>
vagrantc: I just got the epoptes update in Trusty :D
06:36
<vagrantc>
but that does add entries in /var/run/ltspfs_fstab ...
06:36
alkisg: nice!
06:36
alkisg: ppa, or the real deal?
06:36
<alkisg>
Real deal
06:37
<vagrantc>
cool.
06:37
so i guess with the version needing to match, it's pretty much always going to involve some epoptes backports, eh?
06:37
someday it should report features rather than version :)
06:38
<alkisg>
We're using an approach where the server sends the shell code for the client to get executed!
06:38
So when we do break compatibility, it's also time to stop backporting stuff :)
06:40
<vagrantc>
heh
06:42
meh. udevadm doesn't appear to like it's output being redirected.
06:43
oh, it's working
06:47
just confusing is all
06:48alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 246 seconds)
06:54
<vagrantc>
both are ACTION=="change", SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", ENV{ID_FS_TYPE}="?*", RUN+="ltspfs_entry add_disc %k iso9660,udf"
06:54
for insertion: ACTION=="change", SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", ENV{ID_FS_TYPE}="?*", RUN+="ltspfs_entry add_disc %k iso9660,udf"
06:55
for removal: ACTION=="change", SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", ENV{ID_FS_TYPE}="", RUN+="ltspfs_entry remove_disc %k iso9660,udf"
06:55
that kind of sort of almost seems to be working
06:56
<alkisg>
Ah, so it depends on ID_FS_TYPE not being empty...
06:56
<vagrantc>
well, that's what my rule does
06:56
i can't find much else that's distinguishing
06:56
<alkisg>
All that now without cdpinger, right?
06:56
<vagrantc>
yup
06:57
<alkisg>
Cool!
06:57
<vagrantc>
basically those two udev rules plus udisks --poll-for-media /dev/sr0
06:57
<alkisg>
I'll find you an udev rule to bypass the need for that ;)
06:57
<vagrantc>
but it's... not quite working
06:57
<alkisg>
...once I get vbox running on trusty...
06:58
<vagrantc>
the mount fails and it falls over or something
06:59
it's really hard to read the logs ... the insertion and removal events don't really look different
06:59
ID_FS_TYPE isn't always available on insertion, either...
07:00
<alkisg>
The epoptes upgrade didn't update the symlinks as expected, they're still on 20*
07:01
<vagrantc>
it's a deprecated interface...
07:02
all this work with udev, and i hear talk of udev going away...
07:04alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
07:05
<vagrantc>
DISK_EJECT_REQUEST ... now that looks interesting
07:06
<alkisg>
udev going away?! Not just merged inside the kernel?
07:06
<vagrantc>
i can never keep track of all the changes, too much time doing real things :)
07:22mikkel has joined IRC (mikkel!~mikkel@80-199-146-42-static.dk.customer.tdc.net)
07:36* alkisg finally got vbox and his tftproot folder in a working state...
07:37
<vagrantc>
heh.
07:37
almost got some new rules
07:37
why do CDs have to be *so* different.
07:39
i cannot find values that distinguish insertion from removal.
07:39
ID_FS_TYPE is not consistant.
07:39
DISK_MEDIA_CHANGE==1 for both
07:41
ACTION=="change" for both.
07:41
this is insanity.
07:46
maybe ID_CDROM_MEDIA ...
07:47khildin has joined IRC (khildin!~khildin@ip-213-49-83-180.dsl.scarlet.be)
07:49
<vagrantc>
that pretty much did it, except i still end up with two mounts
07:50* alkisg was about to propose ID_CDROM_MEDIA to vagrantc :)
07:51
<vagrantc>
ok, well, i'll post what i have to the bug report
07:52
<alkisg>
vagrantc: two mounts? ah, one for udisks?
07:52
*from
07:52
<vagrantc>
well, two entries in ltspfs_fstab
07:53gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com)
07:53
<alkisg>
I'll post the udev rules needed for debian in the bug report
07:53
vagrantc: our udev hooks work even without a user logged in, right?
07:53
<vagrantc>
yes
07:54* alkisg will also need to find out a way to disable the stupid zram on 14.04...
07:57
<alkisg>
ram used: 1445728 with zram, vs 1422400 without => 23 MB wasted... I _do_ have a swap partition, why do they do this in my case?! :(
07:58alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 245 seconds)
08:05
<alkisg>
vagrantc: to test, I put LOCALDEV=False, and then manually symlink ltspfsd.rules?
08:07
<vagrantc>
alkisg: i actually was using LOCALDEV=True, and editing out calls to cdpinger in lib/udev/ltspfs_entry
08:07
and manually starting "udisks --poll-for-disk /dev/sr0"
08:08
i just rebooted to ensure a clean satate
08:08
state
08:13
i get two duplicates in /var/run/ltspfs_fstab, but otherwise it seems to be working
08:14
i tried starting udisks from ltspfs_entry instead of cdpinger, but it never worked.
08:14
i think it didn't have access to dbus or something
08:15
i've only tested on jessie so far, haven't tried wheezy
08:19gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Ping timeout: 245 seconds)
08:23
<vagrantc>
alkisg: well, time to pass the torch :)
08:23
<alkisg>
vagrantc: moment,
08:23
a few more pointers on how to test please!
08:23
<vagrantc>
oh
08:23
<alkisg>
I just remove the calls to cdpinger and put LOCALDEV=True?
08:23
(or just symlink cdpinger to /bin/true?)
08:24
<vagrantc>
i removed the calls to cdpinger in lib/udev/ltspfs_entry
08:24
but symlinking it might work too
08:25
sbalneav: we need to drag you back into this...
08:25
sbalneav: :)
08:26
<alkisg>
vagrantc: thanks, if that's all, you'll have news in the bug report when you wake up ;)
08:26
<vagrantc>
alkisg: hope so
08:29
<alkisg>
Bah the console doesn't work properly in 14.04 with ltsp.break=50-fstab... damn plymouth et al...
08:29
The keystrokes do not appear, the output of commands do
08:30lmds_ has joined IRC (lmds_!~lmds@tui.pi-et-ro.net)
08:37
<alkisg>
vagrantc: can I implement an lts.conf directive to run commands at init-ltsp.d?
08:37
What should I name it?!
08:37
INIT_CMDS_xx?
08:38
Like RCFILE_xx, but it would run from init-ltsp.d...
08:42
<vagrantc>
alkisg: INIT_LTSP_COMMAND_XX ?
08:42
alkisg: you can of course implement whatever you want :)
08:43
i haven't tried out the ltsp.VAR stuff lately...
08:44
can do some pretty fun stuff with that ... ltsp.screen_07=shell ...
08:44
<alkisg>
vagrantc: I don't think we should be using LTSP in the directive names much
08:44
Those are supposed to be internal to ltsp, not exported to the general environment
08:45
...so why not avoid the long names...
08:45
<vagrantc>
alkisg: i was just naming it after "init-ltsp", the script that would presumably be executing it
08:46
<alkisg>
...but then we'd want to name it INIT_LTSP_NBD_SWAP=False...
08:47* alkisg is probably too used to the namespaces of "real" programming languages and tries to bring that to the shell..
08:48
<vagrantc>
INIT_COMMAND_XX then?
08:48
<alkisg>
Thanks :)
08:48* vagrantc worries a bit about variable names that are a bit too generic getting exported into the environment
08:49
<vagrantc>
but instead of worrying, i should let others work while i sleep! :)
08:49* vagrantc waves
08:49
<alkisg>
vagrantc: we shouldn't export anything to the environment (in the future), except for the client session
08:49
bb!
08:50vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
08:50
<alkisg>
All those lts.conf directives should be internal to the ltsp scripts, not exported to the environment...
08:51freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
08:55
<alkisg>
Ah finally, openvt allows for a command prompt
08:59alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
09:14speygee has joined IRC (speygee!4523d3f4@gateway/web/freenode/ip.69.35.211.244)
09:17
<speygee>
hello all, I was wondering how one could sync the users of multiple clusters together?
09:32speygee has left IRC (speygee!4523d3f4@gateway/web/freenode/ip.69.35.211.244, Quit: Page closed)
09:51
<Hyperbyte>
!ldap
09:51
<ltsp>
I do not know about 'ldap', but I do know about these similar topics: 'ldm', 'ltsp'
09:51
<Hyperbyte>
:(
09:54gbaman has joined IRC (gbaman!~gbaman@host86-171-227-31.range86-171.btcentralplus.com)
10:16mmetzger has left IRC (mmetzger!~mmetzger@99-71-214-196.lightspeed.mdldtx.sbcglobal.net, Ping timeout: 272 seconds)
10:19mattcen has joined IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au)
10:21
<mattcen>
Hi all. I'm basically an LTSP newbie (I played with it very briefly several years ago) and I'm unclear on a few things: Does LTSP trivially support multiple client SOEs with different local apps, and if so, are these SOEs easily assigned to different groups of clients?
10:22
<alkisg>
What is SOE?
10:23
<mattcen>
Sorry, an image
10:23
Whatever you call the thing in /opt/ltsp/i386/ or similar
10:23
(SOE stands for Standard Operating Environment)
10:30
<alkisg>
You can have multiple images and selectively send them via mac address
10:31
But usually, one is enough, you can even have hooks to adjust it to your needs (e.g. rm -rf certain apps that you don't want shown)
10:38gbaman has left IRC (gbaman!~gbaman@host86-171-227-31.range86-171.btcentralplus.com, Ping timeout: 252 seconds)
10:46
<mattcen>
alkisg: Thanks.
10:51freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
10:58workingcats has joined IRC (workingcats!~workingca@212.122.48.77)
11:01gbit has joined IRC (gbit!~chatzilla@unaffiliated/gbit)
11:03bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
11:04
<gbit>
alkisg: hello, about that translation, I copied the .mo file to the directory but still in english, what else is need to get it running?
11:07Fenuks has left IRC (Fenuks!~Fenuks@109.202.25.212, Ping timeout: 248 seconds)
11:08Fenuks has joined IRC (Fenuks!~Fenuks@109.202.25.212)
11:11
<alkisg>
gbit: sudo chroot /opt/ltsp/i386 gettext -d ldm 'Password'
11:11
Does that return the translated string?
11:13
<gbit>
alkisg: It does return in portuguese from portugal instead of Brazilian portuguese.
11:13
<alkisg>
Then your locale is not set up correctly
11:13
You can use LDM_LANGUAGE=xx and LANG=xx in lts.conf to bypass your wrong configuration
11:13willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
11:14
<gbit>
alkisg: I did it already: lts.conf http://pastebin.com/ufysVx0x
11:16
<alkisg>
gbit: what do you have in /etc/default/locale, in both your server and your chroot?
11:16
<gbit>
alkisg: ah in server I do have pt_BR and in ltsp I have english . Think you find it :)
11:17
<alkisg>
gbit: check also /etc/default/keyboard,
11:18
and maybe, run dpkg-reconfigure keyboard-configuration in the chroot
11:18
<gbit>
alkisg: but for keyboard I have some users that use the american keyboard, and some use the brazilian one.
11:18Fenuks has left IRC (Fenuks!~Fenuks@109.202.25.212, Ping timeout: 272 seconds)
11:19
<gbit>
still in english the login screen
11:19
<alkisg>
gbit: the default keyboard layout in your server and your chroot should be the one that most users are using
11:19
For the rest, there is lts.conf...
11:19
<gbit>
ok
11:19
<alkisg>
Did you reboot the client?
11:19
<gbit>
sure
11:20
<alkisg>
Try SCREEN_07=xterm
11:20
Reboot the client and then check the gettext ^ command on that xterm
11:20
<gbit>
ok
11:21
The output is: Password
11:21
<alkisg>
And what's the output of this?
11:21
env | grep ^L
11:23
<gbit>
http://pastebin.com/J2zvgMBP
11:24
<alkisg>
You have a wrong LANGUAGE set
11:26khildin has left IRC (khildin!~khildin@ip-213-49-83-180.dsl.scarlet.be, Remote host closed the connection)
11:27
<gbit>
OK its working now, but looks like portuguese from portugal. I dont remember had translated in that way. Maybe I need to check my .mo files
11:27rkwesk has joined IRC (rkwesk!c23fefe7@gateway/web/freenode/ip.194.63.239.231)
11:27
<alkisg>
gbit: LANGUAGE=pt_BR ?
11:28
<gbit>
LANGUAGE="pt_BR.UTF-8"
11:28
<rkwesk>
γεια σας από Richard
11:28
<alkisg>
Γεια σου Richard
11:28
!greek
11:28
<ltsp>
greek: Στο παρόν κανάλι μιλάνε μόνο Αγγλικά, για υποστήριξη στα Ελληνικά από την υπηρεσία Τεχνικής Στήριξης ΣΕΠΕΗΥ διαβάστε το http://ts.sch.gr/wiki/IRC και στη συνέχεια πληκτρολογήστε /j #ts.sch.gr
11:29
<alkisg>
gbit: that's wrong
11:29
<gbit>
ok
11:29
<alkisg>
LANGUAGE can't contain the UTF-8 suffix
11:29
gbit: ah I think that's a bug committed in ltsp by someone of the ltsp devs... ok ignore that
11:29
<rkwesk>
είμαι σε ένα σχολείο με server με δύο κάρτες δικτύου
11:30
<gbit>
ok np, I'm correcting anyway
11:30
<rkwesk>
στο fat δεν έχει dns
11:30
<alkisg>
rkwesk: either talk in english, or type this command to join the greek channel: /j #ts.sch.gr
11:30
<gbit>
alkisg: I think I copy some pt from portugal .mo file when testing,
11:31
alkisg: this make any sense?
11:31
<alkisg>
rkwesk: it's the english channel here, so we need to speak in english only
11:31
gbit: dunno, there's an msg unformat command to convert from .po back to .mo so that you can see what you did
11:32
msgunfmt, I think
11:32bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
11:34
<alkisg>
rkwesk: you need to do NAT on your ltsp server, see this thread for the solution: http://alkisg.mysch.gr/steki/index.php?topic=5106.0
11:35
sudo sysctl net.ipv4.ip_forward=0; sudo iptables -t nat -D POSTROUTING -s 192.168.67.0/24 -j MASQUERADE
11:39
<muppis>
alkisg, should that be net.ipv4.ip_forward=1, not net.ipv4.ip_forward=0 ?
11:40
<alkisg>
Whoops sorry I copied the command for the "remove nat" part :)
11:40
<muppis>
:D
11:40
<alkisg>
Good catch ;)
11:41
<muppis>
Few times done that, so likely comes from backbone. :D
11:41
<rkwesk>
I thought the network-manager did all that as default
11:41
<alkisg>
rkwesk: no, NAT is for connection sharing, network manager doesn't share you internet connection by default
11:43
<rkwesk>
what about dnsmasq? Can nat be enabled there?
11:43
<alkisg>
What for?
11:43
<rkwesk>
so all clients get internet
11:45
<alkisg>
rkwesk: what's wrong with the solution in the forum thread?
11:45
It's 2 commands that you need to run...
11:45gbaman has joined IRC (gbaman!~gbaman@host86-171-227-31.range86-171.btcentralplus.com)
11:45
<alkisg>
dnsmasq is used for dns services, but the clients cannot access the internet without connection sharing
11:45
And that part is done with iptables etc, the commands I wrote in the forum thread
11:46
<rkwesk>
ok. I'll look there. It's just that I supposed that all would work by default
11:46
<alkisg>
rkwesk: no, ltsp fat clients don't get internet connection without you doing something on the ltsp server
11:46
...if you're using 2 nics
11:46
With 1 nic, which is the default setup, they work fine
11:47
<rkwesk>
ok thank you
11:47
<alkisg>
In the next sch-scripts version we'll have a dialog for connection sharing, it's almost done
11:47
It'll be ready in a couple of weeks...
11:47
<rkwesk>
I look forward to seeing it!!
11:47
<alkisg>
:)
11:48clepto is now known as ChadLepto
11:48
<rkwesk>
As always, Alki, thank you!!
11:49
signing off
11:49rkwesk has left IRC (rkwesk!c23fefe7@gateway/web/freenode/ip.194.63.239.231, Quit: Page closed)
11:54Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
12:00khildin has joined IRC (khildin!~khildin@ip-213-49-83-180.dsl.scarlet.be)
12:26
<gbit>
alkisg: it worked, thank you again!
12:26Phantomas1 has joined IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas)
12:27Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Read error: Operation timed out)
12:27gbaman has left IRC (gbaman!~gbaman@host86-171-227-31.range86-171.btcentralplus.com, Remote host closed the connection)
12:29
<alkisg>
You're welcome
12:31gbaman has joined IRC (gbaman!~gbaman@host86-171-227-31.range86-171.btcentralplus.com)
12:46gbaman has left IRC (gbaman!~gbaman@host86-171-227-31.range86-171.btcentralplus.com, Remote host closed the connection)
12:46gbaman has joined IRC (gbaman!~gbaman@host86-171-227-31.range86-171.btcentralplus.com)
12:52gbaman has left IRC (gbaman!~gbaman@host86-171-227-31.range86-171.btcentralplus.com, Remote host closed the connection)
13:00
<alkisg>
highvoltage, stgraber: in Trusty thin clients with gnome-flashback I'm getting the user's desktop, but empty. If I create a ~/Desktop/gnome-terminal.desktop launcher I can then manually start metacity and gnome-panel. Do you experience this?
13:01alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 272 seconds)
13:05Phantomas1 has left IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.)
13:08
<lifeboy>
I see stgraber is not here at the moment, but does anyone know what happened to https://help.ubuntu.com/community/UbuntuLTSP/UseStgraberPPA? The PPA doesn't exist anymore
13:14willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Read error: Connection reset by peer)
13:15
<alkisg>
lifeboy: it's because it hasn't been updated for years, what where you looking for?
13:15
That wiki page should be deleted
13:18alkisg is now known as work_alkisg
13:24
<Hyperbyte>
weekee
13:43gvy has left IRC (gvy!~mike@altlinux/developer/mike, Read error: Connection reset by peer)
13:52gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
13:57alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
14:34bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Quit: http://www.twelvetribes.org)
14:34cliebow has joined IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us)
14:35brunolambert has joined IRC (brunolambert!brunolambe@nat/revolutionlinux/x-hsoxchgnltxfudff)
14:46
<cliebow>
sbalneav..still fighting this fileserver issue..comes down it seems to Primary Group Sid..smbldap-usershow and pdbedit give different valeues for this
14:57brunolambert has left IRC (brunolambert!brunolambe@nat/revolutionlinux/x-hsoxchgnltxfudff, Quit: Leaving.)
14:57brunolambert has joined IRC (brunolambert!brunolambe@nat/revolutionlinux/x-oaheeminmmughjxh)
15:02alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
15:08cliebow has left IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us, Ping timeout: 245 seconds)
15:13bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
15:13gbit has left IRC (gbit!~chatzilla@unaffiliated/gbit, Ping timeout: 272 seconds)
15:21cliebow has joined IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us)
15:30PhoenixSTF has joined IRC (PhoenixSTF!~rudi@78.29.159.239)
15:33mikkel has left IRC (mikkel!~mikkel@80-199-146-42-static.dk.customer.tdc.net, Quit: Leaving)
15:38bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 245 seconds)
15:44bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
15:54willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
16:17alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 248 seconds)
16:29Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
16:32lns has joined IRC (lns!~lns@pdpc/supporter/professional/lns)
16:35alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
16:40vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
16:49
<vagrantc>
alkisg: so you found the magic one-liner? :)
16:53GrembleBean has joined IRC (GrembleBean!~Ben@bmex-gw.bristolwireless.net)
16:58ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 246 seconds)
16:59
<lifeboy>
Sorry, Alkisg, I was out for a while. I'm looking for any updates that can make 10.04 (udhcpc) get a lease from dnsmasq after the initial ip is assigned to a pxe booting thin client.
16:59gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com)
16:59ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
17:02
<lifeboy>
I did what I wrote in http://pastebin.com/1AThMgPt, but I still don't get past the second dhcp request. The client doesn't display the udhcp error anymore, but the log is the same (since I updated udhcpc and busybox to the latest I could find for 10.04
17:03
<vagrantc>
alkisg: three udev rules ... wonder if the placement really matters...
17:03GrembleBean has left IRC (GrembleBean!~Ben@bmex-gw.bristolwireless.net, Quit: I Leave)
17:04
<vagrantc>
alkisg: it's working great for me! :)
17:05
i should test this on a clean install, though ...
17:09
<alkisg>
vagrantc: I didn't manage to get trusty ltsp thin clients working, so I couldn't properly test the cdpinger stuff
17:10
ipappend | echo lifeboy:
17:11
<vagrantc>
alkisg: it's working great on jessie so far
17:11
<alkisg>
vagrantc: no duplicate mounts?
17:11
<vagrantc>
alkisg: also, i just dropped it into ltspfsd.rules
17:11
alkisg: yeah, single mount
17:11
<alkisg>
Cool
17:11
Very cool, actually :D Go ahead and commit it!
17:12
<vagrantc>
even without further testing?
17:12gbit has joined IRC (gbit!~chatzilla@unaffiliated/gbit)
17:13
<vagrantc>
oh, i haven't tried with media already inserted... but hopefuully
17:14
ah, that didn't work.
17:14
because it's not a change event, i guess.
17:16
maybe if i remove the exclusion of cd devices from the initial udev rule
17:18laprag has joined IRC (laprag!~laprag@ti0071a380-dhcp1620.bb.online.no)
17:19* vagrantc waves to laprag
17:20
<vagrantc>
this commit is going to be awesome.
17:20
a whole mess of code removed, only three lines added
17:23
<laprag>
Hi vagrantc! Mr Tidy!
17:23
<vagrantc>
you couldn't tell by the condition of my sweater.
17:23
<cliebow>
Stronger than Dirt!
17:24
<laprag>
Hehe. The beauty of IRC. No smell no sight
17:25Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.)
17:26
<vagrantc>
alkisg: do you think the extra udev rules would cause problems on ubuntu?
17:27
alkisg: i figured i'd add a conditional to only apply to CD devices
17:33
<alkisg>
(07:20:59 μμ) vagrantc: a whole mess of code removed, only three lines added => yey! vagrantc do you have a .diff that I could test here in 12.04?
17:34
Both for the extra udev rule, and in general, if it works without cdpinger...
17:35
Or, we could add the rule from init-ltsp.d conditionally, only if it's not already where we expect it
17:36
Btw... we named it /sbin/init-ltsp because plymouth looked for "init" at the start of the string... Now in 14.04 it's looking for "sh" at the end, to match e.g. /bin/bash :P
17:36
<vagrantc>
huh?
17:37
re: sh
17:37
<alkisg>
So to be able to get a vt and type stuff at ltsp.break=50-fstab, one needs this hack: init=/sbin/init-ltsp init=/sbin/init-ltsp-sh :D
17:37
<vagrantc>
that hurts.
17:37
diff up and coming
17:37kev_j has joined IRC (kev_j!~Kevin@web.ta-realty.com)
17:38
<alkisg>
vagrantc: next cleanup, xatomwait to xprop -spy? :D
17:39
It's a good thing we're not paid by code lines... we'd have to give money back
17:39
<vagrantc>
alkisg: http://paste.debian.net/67695
17:39
<alkisg>
Ty, testing...
17:41* vagrantc fires up a wheezy chroot
17:43
<vagrantc>
this will be so much simpler
17:43* alkisg won't have to disable localdevs anymore to save ram :)
17:44cliebow has left IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us, Quit: Ex-Chat)
17:46
<vagrantc>
cdpinger ate some ram, eh?
17:47
<alkisg>
With 128 Mb, resulting in just 4 MB free, every MB matters...
17:48
<vagrantc>
sure
17:48
i'm sure updates in the OS more than make up the difference, though :(
17:49
<alkisg>
Whoops, I don't have ltspfs in my ltsp-pnp installation... installing
17:50
<vagrantc>
heh
17:50
<alkisg>
True, that about the updates...
17:51
<vagrantc>
alkisg: works on wheezy, too!
17:51
who's going to test other distros?
17:56alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 272 seconds)
17:57
<vagrantc>
alkisg: added patch to the launchpad bug.
17:57* alkisg is waiting for ltsp-update-image to finish...
17:57* vagrantc never did like waiting
17:58
<alkisg>
Ah, I should also do an ubuntu PPA build for the new ltsp/ldm versions you uploaded
17:58* alkisg always finds things to do while waiting :)
17:58
<vagrantc>
4 files changed, 6 insertions(+), 212 deletions(-)
17:59
alkisg: ldm should include all changes from ubuntu, so ubuntu should sync it
17:59
ltsp is still a bit of a different story.
17:59
<alkisg>
vagrantc: for 12.04, to push to greek schools after testing
18:00
<vagrantc>
stgraber: you should sync ldm from ubuntu, all changes have been merged.
18:00
<alkisg>
So your cdpinger diff will get a _lot_ of testing in a couple of weeks :D
18:00
<vagrantc>
heh
18:00
<alkisg>
I think it's automatically pulled at this point of the release cycle
18:01
<vagrantc>
alkisg: it contains an ubuntu diff, so i don't think it'll sync
18:01
<alkisg>
Ah wasn't the ldm package the same?
18:01
Meh, ubuntuX :(
18:01
<vagrantc>
there were a couple ubuntu patches
18:01
apparently ltspfs has some changes too...
18:02
<alkisg>
Hmm maybe I should wait until we finish both cdpinger and xatomwait, before widely deploying new ltsp/ldm/ltspfs versions
18:03
<vagrantc>
oh, caution is getting the best of you :)
18:04
so far none of the changes have required interoperability between each
18:04
i'm glad i insisted on making sure everything was in the appropriate places back in 2006
18:05
<alkisg>
cdpinger is in the ltspfs tree?
18:05
<vagrantc>
yes
18:05
so you can update ltsp, and it makes no difference which ltspfs is behind the scenes
18:05
<alkisg>
vagrantc, you're an oracle... :)
18:05
<ogra_>
cdpinger cudl be replaced by a five line upstart job :P
18:06
<vagrantc>
ogra_: how about three lines of udev rules? :)
18:06
<ogra_>
without external scripts ?
18:06
<vagrantc>
yup.
18:06
<ogra_>
wow
18:06* vagrantc dances
18:06* ogra_ bows in front of vagrantc
18:06
<alkisg>
We're dropping .c files one by one :P
18:06
<vagrantc>
ogra_: well, we still have the regular ltspfs scripts
18:07
<ogra_>
vagrantc, aha
18:07
<vagrantc>
but relative to what it was before
18:07
the diff basically adds three lines of udev and removes cdpinger entirely.
18:07
<ogra_>
well, upstart could replace these too
18:08
but would indeed add a dep on upstart ... which i.e. gentoo or fedora likely dont want
18:08
<dberkholz>
indeed
18:08
<vagrantc>
and it's hotly debated in debian right now, and i don't want to get in the middle of that :)
18:08
<ogra_>
heh, yeah
18:08* ogra_ knows whats going on :)
18:08
<vagrantc>
i prefer to stay mostly agnostic on backend things.
18:08
<dberkholz>
we're gradually sliding the systemd route, more via user gravity than anything else since folks get to choose.
18:09
<ogra_>
poor you
18:09
<vagrantc>
dberkholz: hey! long time no see!
18:09
<dberkholz>
indeed!
18:10
<alkisg>
https://code.launchpad.net/~vagrantc/ltsp/ltsp-debian-packaging => failed to import again :(
18:10
<vagrantc>
hrm.
18:11
alkisg: alioth was down most of last week, so it may have disabled syncing
18:11
<dberkholz>
turns out my gentoo highlight is pretty reliable for triggering a response =)
18:11
<vagrantc>
heh
18:11
<alkisg>
vagrantc: I requested a "retry sync"
18:12
<vagrantc>
alkisg: probably the same for ldm-debian-packaging
18:12
<alkisg>
Doing so...
18:12
vagrantc: no https://code.launchpad.net/~vagrantc/ltsp/ltspfs-debian-packaging ?
18:13
Oh well I'll sync it from trusty when it lands
18:18
<lifeboy>
Would it be in order with all here if I removed the https://help.ubuntu.com/community/UbuntuLTSP/UseStgraberPPA? page or should I just remove the stgraber PPA information and leave the revolution-linux PPA since that is still there?
18:18
<alkisg>
lifeboy: go ahead, but I doubt you have the privileges to do so
18:18
I think it needs someone from the doc team to remove pages
18:18
<lifeboy>
I can edit pages...
18:18
<vagrantc>
alkisg: know how i can change the mirror URL, short of starting a new branch?
18:19
<alkisg>
lifeboy: that's not enough... try it, you should see "delete" disabled
18:19
vagrantc: nope
18:19
<lifeboy>
Yeh, you're right, Alkisg, it is greyed out.
18:21
<vagrantc>
wow.
18:22
i can't even delete the branch, because someone else has a recipe on it.
18:22* alkisg knows that someone else
18:22
<vagrantc>
https://code.launchpad.net/~rsarramera-b/+recipe/ltsp-daily ?
18:22
<alkisg>
Ah sorry
18:22
I used to use your branch for my recipes,
18:23
but when it started failing, I uploaded one of my own...
18:24
<vagrantc>
alkisg: the URL needs to be changed from bzr.debian.org to anonscm.debian.org
18:24
then i think it would work.
18:25
<alkisg>
vagrantc: I've been changing that many times, that too fails frequently
18:25
I remember changing from bzr to anonscm then back to bzr etc
18:25* vagrantc nods
18:26
<alkisg>
vagrantc: I have one weird delay on boot with the new changes, but I also did numerous other updates, did you notice any delays? E.g. 10-20 seconds at some point before ldm?
18:27
<vagrantc>
alkisg: all seemed fine to me
18:27
<alkisg>
I'll test without the duplicate udev line, to see if it causes loops or anything...
18:27
[ 34.935699] intel8x0: clocking to 48000
18:27
[ 88.479763] init: udev-fallback-graphics main process (1684) terminated with status 1
18:28
<vagrantc>
that would be frustrating if it did
18:28
<alkisg>
There are 50 seconds inbetween those 2 lines in dmesg
18:28
I'm hoping it's completely unrelated
18:28
<vagrantc>
it would be trickier to maintain a separate patch for debian and ubuntu to use the same source
18:29
even though it would be a trivial patch
18:29freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
18:30
<alkisg>
vagrantc: instead of symlinking an udev rule, we can just create a file dynamically, >> rule, from init-ltsp.d
18:30
<vagrantc>
true enough
18:31
alkisg: although currently ubuntu ships all the same plugins
18:31
<alkisg>
We can do "feature detection" like we say in web development, and check if the line is already there, without caring about the distro... (and hoping that the same file name would be used by other distros too)
18:31
<vagrantc>
i guess you can do an override
18:31
alkisg: i wonder if we can query udev about the values instead
18:31
alkisg: that way it wouldn't be filename dependent
18:32
<alkisg>
True... but probably it doesn't hurt to have it twice, and my delay is irrelevant
18:33
Results of testing in 12.04: the delay (will test if it goes away with localdev=false), when booting with an inserted cdrom I see it in the session, and changes also happen OK,
18:33
although for 1 second I saw 2 entries for the CD I inserted, I clicked on the first one, got a "does not exist" message,
18:33
then that first one was gone and only the second remained, which was working
18:34
I rarely use localdevs so I don't know if that's usual or not
18:34
<vagrantc>
that can happen sometimes, but not a lot
18:34
or rather, it shouldn't happen all the time
18:34* alkisg reboots with localdev disabled to test the delay...
18:36
<alkisg>
vagrantc: no delay with localdev disabled... don't push yet, /me will test more later on tonight
18:36
<vagrantc>
aww.
18:36
<lifeboy>
alkisg: I have appended "ipappend 2", which seems to be the option I should use, but it doesn't alter the behaviour.
18:41
There are various references some uppercase "IPAPPEND=2" and other not. Is that relevant?
18:41
<alkisg>
lifeboy: ipappend 3
18:42
2=mac, 3=both mac and ip
18:42
That way you'll stop using udhcpc completely :D
18:42
<lifeboy>
Ah, ok, thanks.
18:46
<alkisg>
The boot delay is consistantly reproducible when I enable/disable localdev
18:48
<lifeboy>
Great, that works! Now just to see how I tell ltsp-update-image to add that to the pxe boot file.
18:52
<alkisg>
vagrantc: When the cdrom is already inserted when the client boots, the volume label is shown as "cdrom" instead of the actual label
18:53lns has left IRC (lns!~lns@pdpc/supporter/professional/lns, Quit: Leaving)
18:53
<alkisg>
vagrantc: the problem with the duplicate entries etc happens because of vbox, I select another iso directly so the events happen too fast,
18:54
while if I slowly select "remove, ok", "insert, ok", instead of "replace CD, ok", then they don't happen
18:54
So I don't think they're due to our changes
18:55gbaman_ has joined IRC (gbaman_!~gbaman@host81-130-48-226.in-addr.btopenworld.com)
18:57gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Ping timeout: 272 seconds)
18:58
<lifeboy>
I see the -I option allows the ipaddend option to be specified when running ltsp-update-image, but it's not in the manpage, as are quite a few others. I filed bug https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1254832 to address this.
18:58
<alkisg>
vagrantc: I think there's a problem with this udev rule:
18:58
ACTION=="change", SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", ENV{ID_CDROM_MEDIA}=="1", RUN+="ltspfs_entry add %k iso9660,udf"
18:58
Add is called twice because of the above rule in line 11:
18:58
ACTION=="add", SUBSYSTEM=="block", ENV{ID_TYPE}!="floppy", RUN+="ltspfs_entry add %k"
18:59groeg has joined IRC (groeg!~georg@dslb-092-074-045-028.pools.arcor-ip.net)
18:59
<alkisg>
lifeboy: these options have been removed in newer ltsp versions
18:59
<groeg>
hi @all
19:00
<alkisg>
We can't bug fix obsolete ltsp versions...
19:00
Hi groeg
19:00
vagrantc: instead of all those complicated rules, why don't we just pass the ID_TYPE to ltspfs_entry, and let it decide what to do? And only use one rule for add, one for remove, and one for change?
19:05
<groeg>
I'd like to ask you a question:
19:05
<vagrantc>
alkisg: that's reasonable.
19:05
<alkisg>
vagrantc: Removing the extra add entry solved the delay. It was not due to the duplicate polling line, but due to the duplicate add'ing
19:05
<groeg>
I set up ltsp on a gentoo box
19:06
<vagrantc>
alkisg: change needs to handle both remove and add events
19:06
<alkisg>
vagrantc: when a CD is inserted, does it produce both change and add events?
19:07
<groeg>
is it the usual way to create an ltsp user by adding it to the host system? I mean outside the ltsp chroot?
19:07
<alkisg>
groeg: that's the correct way to do it, yup
19:07
<vagrantc>
alkisg: i only see change events when a CD is inserted
19:08
<groeg>
okay, thats all, thank you very much! You do a great work
19:08
<vagrantc>
alkisg: or rather, i only see change events related to CD insertion or removal
19:08
alkisg: i don't see add events related to CD insertion, and don't see remove events related to CD removal
19:08
that's why this seems so crazy.
19:09
<alkisg>
vagrantc: Hmm same here
19:09
<vagrantc>
alkisg: with USB devices, there's a clear add and remove, but with media insertion, it's more complicated
19:10
<alkisg>
Although I don't know why I'm getting 2 kernel events for 1 removal
19:10
They appear exactly the same except for a few msec in their timestamp
19:10
<vagrantc>
media removal?
19:10
<alkisg>
Ah no I didn't put --property there
19:11
<vagrantc>
i started doing udevadm monitor --udev --property
19:11
so as not to get spam from kernel events
19:11
<alkisg>
vagrantc: I'm getting add/remove events
19:12
Debian probably needs a couple of more udev rules
19:12
(from ubuntu)
19:12groeg has left IRC (groeg!~georg@dslb-092-074-045-028.pools.arcor-ip.net, Quit: Verlassend)
19:12
<lifeboy>
:-( Oh well, at least I know the options are there and I have the notes so I can maintain the "old" thin clients till the die and are replaced.
19:12
<alkisg>
vagrantc: I think the correct thing to do is --kernel
19:12
To see the original events, not the ones which might be even caused by us
19:12
bbl
19:14
<vagrantc>
but i don't see the double-events, myself.
19:14
well, i should check a little more clearly
19:15
<alkisg>
vagrantc: what I think happens is:
19:15
<vagrantc>
i guess a fast insert/removal might trigger it... but the UI for virt-manager makes that hard.
19:15
<alkisg>
In the bug report, I gave you a line from ubuntu to enable kernel polling
19:15
Ubuntu probably has more lines to map change events to add/remove events
19:15
So here I'm getting both change + add/remove events for CDs
19:16
While on debian, you don't get those, because you lack the ubuntu rules that do that mapping
19:16
So you probably need 2 more lines from ubuntu to map the "change" events to "add/remove" events,
19:16willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Textual IRC Client: http://www.textualapp.com/)
19:16
<alkisg>
and after that, we can use only add/remove events on our ltspfsd.rules, no change events at all
19:17
That's why I was getting the duplicate ltspfs entries too, because of the duplicate change+add events
19:18
<vagrantc>
when i was using udisks --poll-for-media it also had double-mounts isues
19:19
wonder if that was doing something similar
19:28hachque has left IRC (hachque!james@2600:3c01::f03c:91ff:fe96:5060, Read error: Connection reset by peer)
19:29hachque has joined IRC (hachque!james@2600:3c01::f03c:91ff:fe96:5060)
19:30alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
19:32workingcats has left IRC (workingcats!~workingca@212.122.48.77, Quit: Leaving)
20:10gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com)
20:13gbaman_ has left IRC (gbaman_!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Ping timeout: 272 seconds)
20:23vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Ping timeout: 264 seconds)
20:31khildin has left IRC (khildin!~khildin@ip-213-49-83-180.dsl.scarlet.be, Quit: I'm gone, bye bye)
20:35vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
21:16lifeboy has left IRC (lifeboy!~roland@105-236-171-186.access.mtnbusiness.co.za, Quit: Ex-Chat)
21:35
<vagrantc>
alkisg: well, almost got "xprop -spy" working...
21:35
except that it doesn't.
21:36
<alkisg>
Wow, things are going fast today :)
21:36
Why?
21:36
(why it doesn't?)
21:37
<vagrantc>
xprop -spy -notype -root LTSP_COMMAND | while read a b LTSP_COMMAND ; do ...
21:37
but LTSP_COMMAND lands with some cruft in it
21:38* vagrantc wonders how "read a b c" works when there is only A B
21:39* alkisg tries to find out where he put that code he was working on with xprop...
21:39
<vagrantc>
so ltsp-localapps xterm ... lands with LTSP_COMMAND=\"xterm\ \"
21:40
read a b c works as i want it to, it seems
21:40laprag has left IRC (laprag!~laprag@ti0071a380-dhcp1620.bb.online.no, Remote host closed the connection)
21:43
<vagrantc>
got it
21:43* vagrantc dances
21:43* alkisg applauses :)
21:47
<alkisg>
vagrantc: xprop -spy -notype -root 8s '=$0+\n' LTSP_COMMAND | while IFS='=' read junk val; do val=${val#\"}; val=${val%\"}; echo "$val"; done
21:47
<vagrantc>
http://paste.debian.net/67744
21:47
<alkisg>
Or read a b c without IFS, ok
21:48
vagrantc: I think it's more readable with "while xprop..."
21:48
Instead of while true, then xprop, then check the return code...
21:48
<vagrantc>
while true is the old code...
21:49
<alkisg>
Whoops sorry
21:49
vagrantc: also, see my code above ^ instead of using tr
21:49
Because tr will delete " even inside the command
21:49
While we only want to delete the first and the last one
21:50
<vagrantc>
ah.
21:50* vagrantc nods
21:50
<vagrantc>
what was that you said about readable? :P
21:50
<alkisg>
When you're saving a program call in a loop, it's worth it :D
21:50
<vagrantc>
alkisg: wouldn't your code also break with = in the command?
21:50
<alkisg>
No, but OK use read a b c
21:51
When there are less variables than read data, the last var gets all the data without separators being considered
21:51
<vagrantc>
oh, the val=${val#\"} ... yeah, i can try that
21:52
alkisg: if that's the output, then it should loop through empty
21:52
<alkisg>
Err, rephrase, I didn't get "through empty"
21:52
The first time it's empty
21:53
Because we just set it, and we don't want to execute an empty command
21:53
(we need an xprop set command before the loop)
21:53
<vagrantc>
hence the empty check
21:53
<alkisg>
Right
21:54
And also, for any time we reset it to empty again
21:54bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Quit: Goin' down hard)
21:54
<alkisg>
vagrantc: finally, why use 2 atoms?
21:55
The LTSP_COMMAND could start with some special character, and save an atom and an xprop call...
21:55* alkisg is talking about LTSP_COMMAND_WAIT
21:57* vagrantc wonders if LTSP_COMMAND_WAIT could just disappear
21:57
<vagrantc>
it was my first crude attempt at fatclients that i wrote it for
21:57
but i guess it could be useful to know a command has finished executing
21:58
<alkisg>
ltsp-localapps --wait could set LTSP_COMMAND="--wait $@"
21:58
then we check if LTSP_COMMAND starts with --wait, and act accordingly
22:01
<vagrantc>
reasonable.
22:01
<alkisg>
But anyway we shouldn't spend too much time on rethinking this, as we'll reimplement it in the future via the ssh socket
22:02
ltsp-trunk$ find . -name '*.c'
22:02
./client/nbd-proxy/src/nbd-proxy.c ./client/getltscfg/getltscfg.c ./client/localapps/src/xatomwait.c
22:02
...we probably won't have any .c files at all for ltsp6... :)
22:05
<vagrantc>
http://paste.debian.net/67746
22:06
alkisg: the new --wait would break compatibility with old chroots, so like you say, it's probably not worth re-doing.
22:07
<alkisg>
Good thinking
22:07
So I won't go into the space handling that ltsp-localapps does :)
22:07
<vagrantc>
would probably take you to other worlds.
22:08
alkisg: think that last paste is commit-worthy?
22:08
<alkisg>
vagrantc: if it runs, sure
22:08
<vagrantc>
works for me
22:08
<alkisg>
You'll remove xatomwait with the same commit?
22:09
Ah, it's needed for remoteapps too?
22:10
<vagrantc>
bah!
22:10
<alkisg>
OK, same deal there
22:10
<vagrantc>
well, the same could should work
22:11gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Remote host closed the connection)
22:12
<vagrantc>
could probably get rid of the return code check ...
22:13
<alkisg>
Yup
22:13
It will always be true, otherwise it won't enter the loop
22:15
# If LOCAL_APPS_APPS_WHITELIST is defined, reject anything not listed. Otherwise allow by default.
22:15
Two APPS there
22:20
<vagrantc>
7 files changed, 18 insertions(+), 210 deletions(-)
22:21
that includes the autofoo.
22:21
<alkisg>
A good day today for ltsp :)
22:25
<vagrantc>
it gets even better.
22:25freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
22:27
<vagrantc>
alkisg: so still more research for killing off cdpinger?
22:27
<alkisg>
vagrantc: for now, we have a solution that involves different rules for debian/ubuntu
22:28
<vagrantc>
alkisg: which part do you leave out for ubuntu?
22:28
<alkisg>
debian gets the change events, ubuntu gets the add/remove events
22:28
I'll search on how to make debian get add/remove events too
22:29
But starting from tomorrow I'll be pretty busy this week, so... more from me next week :)
22:29
<vagrantc>
i'll be out much of this week as well
22:30
alkisg: so you got it working by commenting out the extra events on ubuntu?
22:31
<alkisg>
I didn't exactly try it, but it appeared so
22:31
It did work, it just had the delay + double mounting problems
22:32
<vagrantc>
alkisg: and that's with 12.04 ?
22:32
<alkisg>
And by removing a line, the problems went away, but then real life called me and I didn't complete the testing
22:32
Yup
22:32
<vagrantc>
i should set up a few VMs and see how it goes.
22:32adrianorg has left IRC (adrianorg!~adrianorg@177.156.230.206, Ping timeout: 245 seconds)
22:34* alkisg would like to "collect" a few thin chroots from all distros for such tests
22:34adrianorg has joined IRC (adrianorg!~adrianorg@177.132.221.238)
22:36
<vagrantc>
i had at one time pondered seting up a chroot autobuilder ...
22:37* vagrantc ponders what it would take to kill off nbd-proxy
22:37
<vagrantc>
xnbd?
22:38
<alkisg>
Yup
22:38
Or, a newer version of nbd-client
22:38
I saw that wouter committed a fix about --persistent
22:39
It should be on jessie + 14.04
22:40* alkisg waves goodnight
22:40
<vagrantc>
alkisg: night!
22:42gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com)
22:45alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 245 seconds)
23:14alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 272 seconds)
23:16gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Ping timeout: 272 seconds)
23:40willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
23:54freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Read error: Operation timed out)