[01:22] <dgroos> ping: sbalneav
[02:18] <sbalneav> Evening all
[02:18] <stgraber> hey sbalneav
[02:20] <sbalneav> dgroos_: Boo
[02:20] <dgroos_> hoo?
[02:20] <dgroos_> ;)
[02:21] <dgroos_> I'm currently trying to get the data collection interface software working on thin clients.  et tu?
[02:22] <sbalneav> Writing up the wiki page on the user management tool.
[02:22] <dgroos_> Cool.  as mentioned I'll want to add my 2 centavos
[02:24] <dgroos_> I need libgtkmm-2.4-1c2a.  What should I download from this page: http://packages.debian.org/search?keywords=libgtkmm-2.4-1c2a ?  Any thing?
[02:34] <sbalneav> Found it quite surprising that the one educator indicated that teachers WOULDN'T want to be in the same channel as us "talking geek"
[02:35] <sbalneav> I guess community building doesn't include the people who are putting together your distro :)
[03:08] <dgroos> sbalneav: ???
[03:29] <sbalneav> dgroos: I was just saying that I was surprised that the one teacher responded to your mail saying that teachers WOULDN'T want to be in this channel where we'd be "speaking geek" :)
[03:40] <dgroos> sbalneav: I'm working through them, trying to summarize and respond--there's ton's of good/wise info there.
[03:42] <dgroos> Ahhh... fear of geek-speak!  Perhaps. and, perhaps it's not all bad for non-techies to be exposed to the labor, the inspiration and knowledge involved in the creation of this 'free' software.
[04:07] <sbalneav> https://wiki.ubuntu.com/Edubuntu/NewUserAdminTool
[04:15] <dgroos> gtg, thanks I'll finish up my response tomorrow and check out the page! g'night all!
[13:48] <dgroos> Good Morning All
[13:49] <dgroos> I'm trying to install a program into the chroot and it gives the message:
[13:50] <dgroos> "/var/lib/dpkg/info/vstloggerpro.postinst: 40: update-desktop-database: not found" and I googled the latter part of this message and came with nothing helpful...  Ideas?
[13:59] <ogra> dgroos, apt-get install desktop-file-utils in the chroot
[14:00] <dgroos> ogra: Thanks!
[14:01] <dgroos> Is it OK to control + C in the middle of rebuilding with ltsp-update-image?
[14:04] <ogra> you have to do it again and you should look for idling mounts after doing that
[14:04] <ogra> i'm not sure the script has proper trap handling builtin
[14:05] <highvoltage> when I isually press ^C there it just stops the mksquashfs part and the unmounting and the rest of the stuff still happens fine
[14:07] <ogra> ok
[14:07] <ogra> i wasnt sure we added a trap function to the script
[14:08] <highvoltage> I think it's mksquashfs that does it, because it you press ^C during it then it says you have to press it again to stop the process
[14:09] <ogra> well there are tmp mounts in the script the script itself needs to care for iirc
[14:09] <dgroos> Hmmm... I decided patience was a virtue at the moment :)
[14:10] <ogra> usually scripts should have a trap function that cleans up after it if signals are recieved
[14:10] <ogra> be it from kill or from keypresses
[14:10] <ogra> i'm doing such trap functions in all my scripts nowadays but didnt do that when i did ltsp development, so there they might still be missing
[14:11] <dgroos> OK, it finished.  I tried the apt-get install desptio-file-utils in the chroot and got the message that "can not write loge, openpty () failed (/dev/pts not mounted)".  Did I miss something?
[14:11] <highvoltage> I should adopt that habbit too
[14:11] <ogra> no, just ignore that
[14:11] <alkisg> Is there anything mounted while ltsp-update-image is running?
[14:11] <dgroos> desptio=desktop
[14:12] <ogra> alkisg, as i said, i'm not sure (its so long ago that i saw that code) but its good practice to have a trap function anyway
[14:12] <alkisg> Sure, I do that too
[14:13] <dgroos> alkisg: were you asking me?  Not sure what you mean by 'anything mounted'?
[14:13] <alkisg> dgroos: no no ignore the question :)
[14:13] <ogra> dgroos, he meant me :)
[14:13] <dgroos> :) great!
[14:14] <alkisg> Wow, squid-deb-proxy... nice catch, ogra ;)
[14:14] <alkisg> I have that as part of my sch-scripts, but it'd be nice to have it by default in ubuntu
[14:14] <dgroos> Install worked!  thanks :)
[14:16] <dgroos> I was wondering, shouldn't the 'desktop-file-utils' be automatically installed into the chroot?  It sounds like it's a rather basic package.  At least, shouldn't there be a message when dpkg -i fails to do so?
[14:17] <ogra> dgroos, btw, "apt-cache search update-desktop-database" would have told you the package name ;)
[14:18] <dgroos> ahhhh, I'll have to remember that for next time! ;)
[14:18] <alkisg> dgroos: you may want to file a bug on the package that you tried to install, to put desktop-file-utils in its dependencies
[14:20] <dgroos> Excellent, I'll do that!
[14:25] <dgroos> As I'm writing to them, I'd like to address their concern with adding thin client support, that: "If you are using USB, make sure the environment is set up so the clients address local USB ports rather than those on the server."
[14:25] <dgroos> If we use a program as a localapp, will it address the USB port locally?
[14:28] <ogra> it cant reach any othert usb port :)
[14:28] <ogra> *other
[14:29] <dgroos> ogra: ? makes sense, then why do they say this: http://www.vernier.com/til/1071.html ?
[14:31] <ogra> no idea, i dont know the software
[14:31] <ogra> but if you install in the chroot all the app can see is local usb anyway
[14:32] <dgroos> OK  I'll get back to them with the inadequacy of that page and ask for clarification.  I'm about to try the software as localapp.  I'll let y'all know how it works :)
[14:33] <ogra> they probably dont know about localapps :)
[14:51] <dgroos> speaking about localapps... I can't get this new program to launch in localapps.  I've got firefox, openoffice and others working in localapps.  I've followed the directions on the LTSPLocalAppsJaunty page in the wiki and my own notes on my blog.  I'm missing something.  Can anyone help?
[14:54] <alkisg> dgroos: does this program have a name?
[14:54] <alkisg> :)
[14:54] <dgroos> indeed!  loggerpro :) I added both 'loggerpro' and the location in the chroot: /usr/local/bin/loggerpro...
[14:55] <dgroos> (added that to the .lts)
[14:56] <dgroos> when I try 'ltsp-localapps loggerpro' or 'ltsp-localapps /usr/local/bin/loggerpro' I get nary a visible burp from the system.
[14:59] <alkisg> dgroos: try ltsp-localapps xterm, and then run loggerpro from that xterm
[14:59] <alkisg> dgroos: is there a linux version of that program? I don't see it here: http://www.vernier.com/downloads/lp3demo.html
[15:00] <dgroos> do I just type in, 'loggerpro' in that terminal window?
[15:00] <alkisg> In that black xterm, yes. Or whatever the command is.
[15:01] <alkisg> This way you'll see the errors, if any.
[15:01] <alkisg> But is that a WINE program?!
[15:01] <dgroos> here's the address: http://www2.vernier.com/linux/lpl.beta.tar
[15:01] <alkisg> Ah, linux public beta... nice http://www.vernier.com/soft/lpl/
[15:03] <dgroos> to get to the link I sent, you register and they send it to you.
[15:03] <dgroos> right, not wine.
[15:03] <dgroos> I get the error:
[15:03] <dgroos> "Working dir /home/dgroos
[15:03] <dgroos> Top Level Folder: '/usr/local/share/LoggerPro/'
[15:04] <dgroos> Our runtime support folder is: /tmp/VST_Support_SqClX2/
[15:04] <dgroos> terminate called after throwing an instance of 'std::logic_error'
[15:05] <dgroos>    what(): basic_string::_S_construct NULL not valid
[15:05] <dgroos> Aborted
[15:05] <dgroos> then went back to the prompt...  Does this mean anything to you?
[15:10] <sbalneav> Morning all
[15:11] <sbalneav> highvoltage: No, the person to talk to about theat would be CAN-o-SPAM in #ltsp
[15:11] <highvoltage> sbalneav: I found one on the competition page, thanks
[15:11] <sbalneav> cool
[15:11] <alkisg> Good morning sbalneav... dgroos: does the program run normally if you install it on the server?
[15:11] <ogra> dgroos, i guess thats a binary ? seems like its compiled for a different libc version or so
[15:13] <dgroos> Good morn sbalneav.
[15:13] <sbalneav> highvoltage: Could you move that for me?
[15:14] <dgroos> alkisg: I was using it beautifully on my karmic machine at home last night, if that's what you mean?  It simply installed and worked.
[15:14] <highvoltage> sbalneav: hmm?
[15:14] <dgroos> ogra: worked on karmic--does that answer?
[15:15] <alkisg> dgroos: well see what ogra said. Or maybe it's still missing some library. I'd just mail the company, mentioning the output....
[15:15] <ogra> dgroos, then some lib is likely missing
[15:15] <ogra> smells like QT
[15:16] <sbalneav> highvoltage: Wiki police post.
[15:16] <ogra> or other C++ crap
[15:16] <highvoltage> sbalneav: ah! yes
[15:17] <dgroos> I'll try to run on jaunty server to make sure it isn't a jaunty/karmic issue, then I can guess it is a thin client or perhaps localapp issue.  Thanks so much for your time alkisg and ogra.
[15:18] <dgroos> ... and good day to you all... students on their way in 7 minutes... :)
[15:18] <alkisg> dgroos: if you can use a modern PC as a thin client, with e.g. 2 Gb of ram on it,
[15:18] <alkisg> then you could try installing things on it live, to verify that it's a library thing
[15:18] <ogra> dgroos, i'd start with a check if libstdc++6 is installed (and install that if its not)
[15:18] <alkisg> (e.g. alt+ctrl+f2 => apt-get install ubuntu-standard)
[15:19] <ogra> libstdc++6 usually provides such basic C++ stuff
[15:25] <dgroos> will try/checkout!
[15:50] <alkisg> highvoltage: you would mind if I: (1) stored somewhere in the chroot that the user selected to build a fat client, (2) use that value to deside if LTSP_FATCLIENT should default to True or False, and (3) of course allow the user to override the "autodetected" LTSP_FATCLIENT value from lts.conf?
[15:51] <alkisg> highvoltage: the goal is to be able to use fat clients without *always* requiring an lts.conf.
[15:51] <sbalneav> On the wiki, how do you see diff's from a previous version?
[15:51] <sbalneav> I'm more used to foswiki, that provides the history
[15:51] <alkisg> Which wiki? sf or ubuntu?
[15:51] <sbalneav> ubuntu
[15:52] <alkisg> Look for "page history"
[15:52] <alkisg> There you can then compare versions
[15:52] <highvoltage> alkisg: hmm, as far as I understand it's purposely designed so that you can mix fat and thin clients and that it would use thin by default
[15:52] <sbalneav> It's not under page actions
[15:52] <alkisg> sbalneav: link to the page that you want?
[15:52] <sbalneav> https://wiki.ubuntu.com/Edubuntu/NewUserAdminTool
[15:53] <alkisg> highvoltage: in that case you would *require* an lts.conf
[15:53] <highvoltage> alkisg: I guess it's probably something to discuss with sbalneav/stgraber/vagrant, I could live with it either way
[15:53] <alkisg> So why not allow for an extra case that would work without lts.conf?
[15:54] <alkisg> stgraber, sbalneav, some opinion in this? ^^^
[15:54] <ogra> alkisg, admins wouldnt like if the user could select by default, make that optional
[15:54] <alkisg> ogra, select?
[15:54] <ogra> i.e. based on an lts.conf option
[15:55] <ogra> your (3) case above
[15:55] <ogra> "and (3) of course allow the user to override the "autodetected" LTSP_FATCLIENT value from lts.conf"
[15:55] <alkisg> ogra, I meant "sysadmin", not user. My mistake.
[15:55] <ogra> ah
[15:55] <alkisg> The users can't modify lts.conf.
[15:55] <ogra> no, it sounded like you wanted to bring up some selection in front of the user :)
[15:56] <sbalneav> ogra: On the ubuntu wiki, do you know how to view page history?
[15:56] <ogra> sbalneav, info
[15:56] <highvoltage> alkisg: since it's still very new, it would be better to change it now rather than later, there's probably a good reason why there's an LTSP_FAT_CLIENT in lts.conf, let's check first
[15:57] <sbalneav> ah, thanks
[15:57] <sbalneav> that was.... non intuitive
[15:58] <sbalneav> https://wiki.ubuntu.com/Edubuntu/NewUserAdminTool?action=diff&rev2=3&rev1=2
[15:58] <alkisg> highvoltage: well, to enable the sysadmin to select if he wants the fat client of the thin client behavior
[15:58] <sbalneav> heh, guy added another button, doesn't explain what he wants it to do
[15:58] <sbalneav> "migrate/backup"
[15:58] <ogra> migrate a backup :)
[15:59] <sbalneav> Backups aren't part of an adduser tool.
[15:59] <ogra> or migrate to a backup :)
[15:59] <sbalneav> backups are backups
[15:59] <ogra> backups are automatically taken if you use std distro tools, look in /var/backups :)
[15:59] <ogra> especially for passwd and the like
[16:00] <sbalneav> Let me come over to your place with a hammer and smash your hard drive.  They you can get your backups from /var/backup and restore them :)
[16:00] <alkisg> highvoltage: There are 3 cases: (1) full thin => we don't touch it, we don't care, (2) mixed thin/fat, (3) full fat.
[16:00] <alkisg> Right now, in (2) and (3) we *require* an lts.conf.
[16:00] <alkisg> With my "autodetection proposal" we will only require an lts.conf in (2)...
[16:00] <ogra> sbalneav, pfft
[16:00]  * ogra goes back to u-boot
[16:01] <alkisg> highvoltage: so I think we gain something without losing anything
[16:02] <highvoltage> alkisg: that does sound reasonable
[16:03] <alkisg> highvoltage: ok, I'll do it / commit it, and if you see that you don't like it for some reason, we can remove it afterwards. We still have time until feature freeze ;)
[16:03] <highvoltage> alkisg: ok, thanks
[16:03] <alkisg> Thank you :)
[16:34] <stgraber> alkisg: I wouldn't turn on LTSP_FATCLIENT to True by default when built with --fat-client as regular thin client is still supported even with fat client support turned in
[16:35] <stgraber> alkisg: I'd probably show a message at the end of ltsp-build-client instead telling the user to write a lts.conf
[16:35] <alkisg> stgraber: "as regular thin client is still supported" ? Sorry I don't understand the meaning of that, could you elaborate?
[16:36] <alkisg> If the user specifically requests to build a fat client chroot, what advantage do we have to not turn LTSP_FATCLIENT on by default?
[16:38] <alkisg> (btw, here's the code for what I'm proposing: http://paste.ubuntu.com/359609/ )
[16:39] <stgraber> well, my use case for fat clients is multimedia labs
[16:40] <stgraber> obviously I don't have all my thin clients in that lab so I want all of them to boot as regular thin client and only a few powerful ones to start everything locally (fat client)
[16:40] <alkisg> stgraber: and? how does that default give you any trouble?
[16:41] <alkisg> [Default]
[16:41] <alkisg> LTSP_FATCLIENT=False
[16:41] <alkisg> [PowerFullPC]
[16:41] <alkisg> LTSP_FATCLIENT=True
[16:41] <alkisg> You're in case (2), mixed mode setup. You HAVE to have an lts.conf
[16:41] <alkisg> Why should you force someone with ONLY fat clients to have an lts.conf as well?
[16:47] <stgraber> alkisg: hmm, ok, perhaps doing something like: touching some file when --fat-client is used, checking in ltsp_config for that file and if it's there, then set LTSP_FATCLIENT to True + displaying a warning in ltsp-build-client that all thin clients will actually boot as fat client
[16:48] <alkisg> stgraber: ok, I've done all that (except for the warning), see the link above
[16:48] <alkisg> I'll put a warning and commit (I'm currently testing)
[16:53] <alkisg> Is that ok?
[16:53] <alkisg>         # Notify the user about the different defaults
[16:53] <alkisg>         echo "--fat-client was specified, all clients will boot as fat clients by default."
[16:53] <alkisg>         echo "To modify this behavior, put LTSP_FATCLIENT=False in lts.conf."
[17:08] <alkisg> Commited.
[17:11] <stgraber> alkisg: you'd need to use the gettext functions to have that translated though
[18:04] <Lns> sbalneav: re: ldap tools... imho there will never be a nice, easy ldap UI that is infinitely customizable...that's the same with a LOT of really good linux tools
[18:04] <Lns> Maybe the only thing we *can* do is cookie-cutter it, for our scenarios (education/school setups)...if someone needs/wants more, they need to learn the real tools
[18:15] <alkisg> Also, in big schools with lots of users, LDAP etc, they'll also have real sysadmins which should be able to learn the real tools ;)
[18:16] <Lns> hey alkisg
[18:16] <alkisg> Hey Lns, how's it going?
[18:16] <mhall119|work> alkisg: I wouldn't bank on that
[18:16] <Lns> Not too bad
[18:16] <mhall119|work> I don't think there's a "real" sysadmin in my entire school district
[18:16]  * Lns concurs with mhall119|work 
[18:17] <alkisg> mhall119|work: so who's handling ldap?
[18:17] <mhall119|work> If anything, they're on AD
[18:17] <mhall119|work> but likely not even that
[18:19] <Lns> alkisg: potentially nobody.. someone might come along and say "wow ldap would be nice, then everyone could log into everything with one account!" and then everyone else says "hmm" and goes to ldap.org or whatever...then they forget about it ;)
[18:20]  * alkisg is no longer worried about ldap, now with the fat clients plugin :D
[18:22] <Lns> alkisg: ?
[18:59] <stgraber> MEETING TIME
[19:00] <Lns> what?
[19:00] <Lns> for us?
[19:01] <highvolt1ge> oh wow
[19:01] <stgraber> it's 7pm UTC, Edubuntu meeting in #ubuntu-meeting
[19:01] <highvolt1ge> what happened to the last 20 minutes!?
[19:01] <stgraber> mgariepy: ^
[19:01] <mgariepy> hi everyone
[19:02] <stgraber> sbalneav: ping
[19:02] <stgraber> alkisg: ping
[19:02] <stgraber> nixternal: ping
[19:02] <alkisg> pong
[19:02] <alkisg> Oooh meeting :)
[19:29] <sbalneav> stgraber: pong
[19:59] <vmlintu> I had not noticed the edubuntu-menu-editor before. Is there some way planned to distribute the menus to large number of machines?
[20:00] <stgraber> vmlintu: there'll be profile import/export as .tar.gz
[20:00] <stgraber> vmlintu: for bigger deployment, you can package the profiles
[20:00] <vmlintu> stgraber: so it'll be matter of distributing the profile.tar.gzs?
[20:01] <stgraber> vmlintu: yep, the user can then import it and assign the menu to a system group
[20:01] <highvoltage> I stopped taking notes about 20 minuts into the meeting so I'll just scroll back and finish it up for the list :)
[20:01] <stgraber> highvoltage: hehe, thanks a lot for taking care of that.
[20:01]  * sbalneav staggers back in, props himself up at the bar.
[20:02]  * Lns puts the lamp shade back on sbalneav's head
[20:02] <sbalneav> Barkeep!  A nice Stout on tap for myself, and a round for everyone else in here!
[20:02] <Lns> woo! beer at noon for me!
[20:02] <sbalneav> It's always noon somewhere
[20:03] <Lns> (T)alk to bartender, (H)ear Seth Able, ...
[20:03] <sbalneav> Winding your way down on Baker Street
[20:03] <sbalneav> Light in your head, and dead on your feet
[20:04] <sbalneav> Well another crazy day
[20:04] <sbalneav> You drink the night away
[20:04] <sbalneav> And forget about everything
[20:04] <sbalneav> ....anyone?
[20:04]  * sbalneav sings alone
[20:05]  * Lns picks up a bass
[20:08] <Lns> moodlecommons.org looks promising, but not a whole heck of a lot of content yet
[20:17] <highvoltage> stgraber: heh, I guess all of us are getting a bit sleepy:
[20:17] <highvoltage> 21:22 < stgraber> As most of you probably have read, I became an Ubuntu Membership Board member yesterday and
[20:17] <highvoltage> none of us even picked up that that should've been Ubuntu Developers Board :)
[20:18] <highvoltage> or developers membership board, even
[20:21] <vmlintu> stgraber: We've experimenting with some scripts that create menus on the fly when user logs in. The menu rules are distributed from a web server so that the same rules can be used in multiple systems
[20:22] <vmlintu> stgraber: I think there was also a test to distribute sabayon profiles with the same thing
[20:31] <stgraber> highvoltage: hehe ;) though I then used DMB in the next sentence :)
[20:32] <stgraber> vmlintu: yeah, either you use some custom scripts of yours or use an actual configuration manager like puppet to do it
[20:34] <vmlintu> stgraber: yeah, I've been using puppet for that too..
[20:37] <vmlintu> What's the status of the menu-editor? Is it ready for use yet if I give it a try?
[20:38] <stgraber> mgariepy: ^ Is that only the profile manager that's not working yet ?
[20:40] <mgariepy> huh i need to do some cleanup. everything seam to work. (i'm doing the clean up right now.)
[20:40] <mgariepy> vmlintu, i can ping you when my code is cleaner,
[20:41] <mgariepy> in maybe 30 minutes or so if i don't have an emergency
[20:42] <vmlintu> mgariepy: thanks, I'll have to see if how our experiments might work with it
[20:45] <sbalneav> Goldarnit, how the heck do you print decimals in python without the 'Decimal(13,2)'
[20:45] <mgariepy> vmlintu, you associate menus from groups or something like that or on a user basis ?
[20:45] <sbalneav> I just want 13.2
[20:45] <mgariepy> out of curiosity ;)
[20:47] <vmlintu> mgariepy: The currently running system has menu profiles and those are assigned to groups.. The experiments are based on tags - tags can be associated with users, groups, terminals etc, but this is all experimental and proof-of-concept
[20:47] <stgraber> sbalneav: can you give more details ?
[20:49] <mgariepy> vmlintu, ok, have you ever used desktop-profiles before ?
[20:49] <sbalneav> I've got a number that's a Decimal type in python
[20:49] <sbalneav> as in Decimal(13.2)
[20:49] <vmlintu> mgariepy: what you mean with desktop-profiles?
[20:50] <sbalneav> When I print it as a %s, I get 'Decimal(13.2)'
[20:50] <sbalneav> as opposed to just 13.2
[20:51] <mgariepy> desktop-profiles is a set of script to manage different profiles ( menu, gconf, kde, etc.. ) for users on a system.
[20:51] <mgariepy> it's a package in the repos.
[20:52] <stgraber> >>> print("test %s" % Decimal(10))
[20:52] <stgraber> test 10
[20:52] <stgraber> sbalneav: ^
[20:53] <stgraber> >>> print("test %s" % Decimal('10.3'))
[20:53] <stgraber> test 10.3
[20:53] <vmlintu> mgariepy: I think we tried it ages ago, but back then it didn't work for us. I haven't checked it recently.
[20:53] <stgraber> >>> print("test %s" % 10.3)
[20:53] <stgraber> test 10.3
[20:54] <sbalneav> Hmm, why isn't that working for me :(
[20:54] <mgariepy> vmlintu, ok, i use this to manage menu for schools district and it's rock-solid :)
[20:54] <sbalneav> nm, my value was in a list. duh
[20:55] <sbalneav> needed a [0] :)
[20:56] <vmlintu> mgariepy: I'll have to check how it'd work now. Our biggest problem is that the admins at school have never seen command line and they should be able to modify their menus and desktops..
[20:56] <mgariepy> ok, i see.
[20:58] <vmlintu> mgariepy: that's why we created some web based tools to do that and now I'm just trying to get rid of those.. It actually turned out that the most important feature of the tool was the ability to put web links in the menu easily..
[21:04] <alkisg> highvoltage: "• edubuntu-desktop doesn't currently work in fat client chroot (hmm, do we have a bug for this?)" ==> it does work fine, just with the -l in umount
[21:04] <alkisg> So we're OK as long as we keep the -l there...
[21:08] <vmlintu> mgariepy: are you using gnome or kde desktops?
[21:08] <mgariepy> vmlintu, gnome
[21:08] <mgariepy> kde4 doen't work so great with ltsp :)
[21:09] <mgariepy> for now, with hardy we were using kde3.
[21:10] <mgariepy> but the menus are the same. it's in the freedesktop sandard
[21:10] <vmlintu> yup, kde4 got a bit out of hand..
[21:10] <alkisg> What exactly are the problems with KDE and LTSP?
[21:10] <vmlintu> I just updated the hardy boxes to firefox 3.5.8 and openoffice 3.1.1
[21:13] <highvoltage> alkisg: aah, the -l isn't necessary if we add "ls -l /proc/[0-9]*/exe 2>/dev/zero | grep $ROOT | awk '{print $8}' | cut -d / -f3 | xargs kill -9 2>/dev/zero || true" before the unmount command
[21:13] <alkisg> highvoltage: I've been trying that all day yesterday. No sugar.
[21:14] <highvoltage> alkisg: I tested it earler (not with edubuntu but with ubuntu-desktop), and it could unmount just fine without -l
[21:14] <highvoltage> alkisg: I'll check again with edubuntu-desktop then to see what doesn't unmount...
[21:14] <highvoltage> I mean, what locks it
[21:14] <alkisg> highvoltage: yes, I know, I've done tens of tests in the last days
[21:14] <highvoltage> alkisg: I believe you!
[21:14] <alkisg> highvoltage: see the logs in #ltsp, you'll see what we tried yesterday with stgraber + ogra
[21:15] <alkisg> Bottom line, I killed almost everything in sight (including X and many services) but still $CHROOT/proc refused to umount
[21:15] <highvoltage> alkisg: are you sure you used $CHROOT/proc?
[21:15] <highvoltage> alkisg: because that will try to unmount the server's /proc
[21:15] <alkisg> Yes, I have detailed logs of everything I tried
[21:16] <alkisg> highvoltage: no that was just a shortcut here to avoid writing /opt/ltsp/i386/proc :)
[21:16] <highvoltage> ok
[21:16] <mgariepy> alkisg, the kde4 interface was sluggy because of visual effect, usb key aren't showing on the desktop
[21:17] <alkisg> mgariepy: ok, I imagine it won't be very hard to disable the effects. I knew about the usb devices, I don't know any workarounds. Is there anything more?
[21:17] <alkisg> (thanks, btw)
[21:17] <mgariepy> alkisg, stuff like this. it's been a while since i last tested it. i think that the last release i tested was intrepid.
[21:18] <highvoltage> alkisg: yep, I trust and believe you, I still just want to take a look at it
[21:18] <alkisg> highvoltage: sure, do that, I hope you'll get somewhere.
[21:18] <alkisg> I think stgraber tried on an lxc, I didn't hear of any better news....
[21:20] <alkisg> highvoltage: I have a feeling it might be that the chroot is trying to start hal and it's reusing the server's existing daemon or something like that. So what I want to try next is to modify $PATH and to provide fake upstart wrappers, so that upstart daemons do not start in the chroot.
[21:21] <stgraber> alkisg: it worked in LXC, so it's something in Edubuntu desktop that must be causing the issue for you
[21:21] <alkisg> stgraber: was that with an edubuntu chroot?
[21:21] <stgraber> yep
[21:22] <alkisg> OK, so it takes both of them (server+chroot) to cause the problem... :-/
[21:22] <highvoltage> alkisg: ah, I'm doing it on a machine that's only a server
[21:23] <highvoltage> alkisg: I'll let you know what happens...
[21:23] <alkisg> highvoltage: does it have hal installed? I wonder what would happen if you started it...
[21:25] <highvoltage> alkisg: I'll try without it first, and then with it
[21:28] <dgroos> alkisg: the kids have gone... :)
[21:29] <dgroos> I just got access to 'the room' where the server is, tried the program, loggerpro, locally on the server, and it worked great.
[21:29] <alkisg> Well... when my wife tells me that, I understand its meaning, now I don't know what to think :P
[21:30] <dgroos> hmmm... probably not the same thing!!!
[21:30] <dgroos> :)
[21:30] <mhall119|work> ew
[21:32] <dgroos> OK, so, I've been trying to make it work as a localapp, but I'm not famous for being able to take some program, put it on the chroot, update the chroot, add the address of the program to the .lts file, and then launch it with a, 'ltsp-localapps program-address'.
[21:34] <dgroos> I can't even get a hiccup from the computer when I type 'ltsp-localapps loggerpro'.  However, 'ltsp-localapps firefox-3.5' will launch ff 3.5 quite nicely as a local app.  Am I missing something?
[21:34] <Lns> vmlintu: I dunno if this would help but a while back I wrote a simple script to create a URL based .desktop file (for distribution on user desktops)...I can pastebin it if you want
[21:34] <Lns> It uses Zenity so it has pretty dialogue boxes and all
[21:37] <vmlintu> Lns: it asks for url and creates the desktop file?
[21:37] <Lns> yeah
[21:37] <alkisg> dgroos: start with ltsp-localapps xterm, and then run that logerapp from inside the xterm
[21:40] <mgariepy> vmlintu, i just pushed the code on LP
[21:41] <vmlintu> Lns: I've got scripts doing the same, but it'd be interesting to see as there's no gui in them
[21:41] <dgroos> (is there a way to get the error message to print to something I can just copy and paste?  This doesn't work inside the xterm)
[21:42] <Lns> vmlintu: it doesn't put them in the xdg menu hierarchy or anything but it could be easily done by extending the script, i'm sure..  http://pastebin.com/m2b07c491
[21:43] <dgroos> OK, it says:
[21:43] <dgroos> I'll put in pastebin...
[21:46]  * alkisg demonstrates the beauty of the cat command to Lns: http://pastebin.com/m36498480
[21:47] <Lns> alkisg: :) ty!
[21:47] <alkisg> ;)
[21:47] <Lns> so it cats until it sees the string EOF?
[21:47] <Lns> weird, i've only seen < used in reference to a file
[21:48] <highvoltage> it's quite common in scripts
[21:48] <vmlintu> Lns: thanks
[21:49] <highvoltage> Lns: are you familiar with the concept of Useless Use of Cat? (UUoC)
[21:49] <alkisg> Lns: man sh => press slash to start searching => write: here-document and press enter
[21:49] <Lns> brb
[21:54] <vmlintu> mgariepy: Just pulled it and menueditor seems run and do something.. Cancelling the save seems not to work (don't know if it should..)
[21:57] <mgariepy> oops ;)was an indentation problem ;)
[21:57] <mgariepy> rev41 correct it hehe
[21:58] <vmlintu> python is not meant for me..
[21:58] <vmlintu> I never get the indentations right
[21:59] <highvoltage> heh, that for me is the best part of python
[21:59] <Lns> highvoltage: oh ha ha =p
[22:00] <Lns> alkisg: thx for that =)
[22:00]  * Lns is still learning
[22:01] <alkisg> np... one tip per day, in two months you'll be an upstream hacker :)
[22:01] <vmlintu> mgariepy: is some kind of setup needed for profilemanager?
[22:02] <mgariepy> yeah some directory need to be created. : /etc/edubuntu-menueditor, /usr/share/edubuntu-menueditor/menus
[22:03] <mgariepy> and desktop-profile should be installed too
[22:03] <Lns> alkisg: ;) Also I'm reading this awesome guide: http://mywiki.wooledge.org/BashGuide
[22:03] <vmlintu> I better leave that for tomorrow.. or later today, however you put it..
[22:04] <mgariepy> maybe tomorrow i'll have the time to package it.
[22:04] <alkisg> Lns: try not to become a bashist :D (it has a lot of stuff not supported by other shells) https://wiki.ubuntu.com/DashAsBinSh
[22:05] <mgariepy> by the weekend it's gonna be in a ppa or something. i'll post an edubuntu-user post when it's done.
[22:06] <dgroos> alkisg: finally! many interruptions... http://pastebin.ubuntu.com/359775
[22:06] <alkisg> dgroos: yeah, that's the same error you posted some hours ago...
[22:06] <alkisg> Did you try installing libs etc?
[22:07] <vmlintu> yuhuu, finally I got oauth consumer libraries to obey my code..
[22:07] <Lns> alkisg: =) I take it all with the intention of being portable, of course
[22:07] <alkisg> Lns, yup
[22:09] <dgroos> Yes.  Why would it give the same error, trying to run it on the thin client, not as localapp, and on thin client as a localapp.  If the issue was thin client (not localapp), shouldn't running as local app have done something different?
[22:14] <mgariepy> cya another day everybody.
[22:31] <highvoltage> dgroos: worked fine with edubuntu-desktop on a plain server, I'll install hal and let it run again
[22:32] <highvoltage> oh,
[22:32] <highvoltage> hal is already the newest version.
[22:32] <highvoltage> dgroos: I have hal installed on the server
[22:36] <alkisg> highvoltage: I guess you mean me... :)
[22:37] <alkisg> highvoltage: my test environment where I have the problem is edubuntu lucid server + edubuntu lucid chroot.....
[22:39] <alkisg> Goodnight all
[22:47] <highvoltage> dgroos: yes sorry I did mean alkisg :)
[22:49] <dgroos> and to all, a good eve (morning, night, afternoon, etc)