|00:13||killermike has joined IRC (email@example.com)|
|00:57||risca has joined IRC (firstname.lastname@example.org)|
|01:12||adrianorg__ has left IRC (email@example.com, Ping timeout: 260 seconds)|
|01:13||map7 has left IRC (firstname.lastname@example.org, Quit: Leaving)|
|02:31||vagrantc has left IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net, Ping timeout: 260 seconds)|
|02:32||GodFather has joined IRC (GodFatheremail@example.com)|
|03:28||Parker955_Away is now known as Parker955|
|04:03||shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, Ping timeout: 272 seconds)|
|04:04||Parker955 is now known as Parker955_Away|
|04:25||risca has left IRC (firstname.lastname@example.org, Quit: Lämnar)|
|04:55||cheapie has joined IRC (cheapie!4bada746@gateway/web/freenode/ip.18.104.22.168)|
I have LTSP set up on Debian, but when the clients try to boot, they can't mount the NBD filesystem and drop me to BusyBox. Can anyone here help me with this?
|04:59||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
|05:39||shogunx has left IRC (email@example.com, Read error: No route to host)|
|05:44||shogunx has joined IRC (firstname.lastname@example.org)|
|06:50||freedomrun_ has left IRC (freedomrun_!~quassel@BSN-176-160-182.dial-up.dsl.siol.net, Ping timeout: 246 seconds)|
cheapie: i don't think i can help specifically (not using debian or nbd)
but it would help to be more specific
like error and log outputs and such
cheapie, also, Debian doesn't use NBD by default, did you specifically wanted to switch from NFS to NBD?
|07:13||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)|
|07:26||ry has left IRC (email@example.com, Ping timeout: 245 seconds)|
|07:35||komunista has joined IRC (firstname.lastname@example.org)|
|07:39||ry has joined IRC (email@example.com)|
|07:43||Llama_be has left IRC (Llama_be!~Llama@94-226-90-169.access.telenet.be, Ping timeout: 260 seconds)|
|08:29||freedomrun has joined IRC (freedomrun!~quassel@BSN-176-160-182.dial-up.dsl.siol.net)|
OK... I managed to get my old problem fixed, but now I get "No response from server: restarting..." whenever I try to log in. I can SSH to the server OK though.
|08:32||killermike has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|08:46||freedomrun has left IRC (freedomrun!~quassel@BSN-176-160-182.dial-up.dsl.siol.net, Remote host closed the connection)|
|08:49||freedomrun has joined IRC (freedomrun!~quassel@BSN-176-160-182.dial-up.dsl.siol.net)|
|08:49||komunista has left IRC (email@example.com, Ping timeout: 248 seconds)|
|08:52||komunista has joined IRC (firstname.lastname@example.org)|
|09:42||loather has left IRC (email@example.com, Quit: This computer has gone to sleep)|
|09:59||komunista has left IRC (firstname.lastname@example.org, Quit: Leaving.)|
|10:08||komunista has joined IRC (email@example.com)|
|10:31||Llama_be has joined IRC (Llama_be!~Llama@94-226-90-169.access.telenet.be)|
|10:33||cheapie has left IRC (cheapie!4bada746@gateway/web/freenode/ip.22.214.171.124, Quit: Page closed)|
Llama_be: good morning
how did the install go?
|11:07||LoveStorm has left IRC (LoveStorm!Storm@gateway/shell/trekweb.org/x-cehhecaakiiftkvm, Ping timeout: 252 seconds)|
|11:13||LoveStorm has joined IRC (LoveStorm!Storm@gateway/shell/trekweb.org/x-wppmdzpwtrbqntot)|
|11:22||adrianorg__ has joined IRC (firstname.lastname@example.org)|
|11:52||komunista has left IRC (email@example.com, Ping timeout: 252 seconds)|
|12:27||khildin has joined IRC (firstname.lastname@example.org)|
|12:28||komunista has joined IRC (email@example.com)|
|12:33||shawnp0wers has joined IRC (firstname.lastname@example.org)|
|12:33||shawnp0wers has joined IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers)|
|12:41||freedomrun has left IRC (freedomrun!~quassel@BSN-176-160-182.dial-up.dsl.siol.net, Read error: Connection reset by peer)|
|12:43||freedomrun has joined IRC (freedomrun!~quassel@BSN-176-160-182.dial-up.dsl.siol.net)|
knipwim: sorry, didn't notice this morning. Some other stuff has come up, and haven't had much time yet. Will continue during the next days, and report back to you.
|13:35||freedomrun has left IRC (freedomrun!~quassel@BSN-176-160-182.dial-up.dsl.siol.net, Read error: Connection reset by peer)|
|13:38||freedomrun has joined IRC (freedomrun!~quassel@BSN-176-160-182.dial-up.dsl.siol.net)|
|13:40||bakytn has joined IRC (email@example.com)|
about printers. Using PRINTER_0_* settings require JetDirect capable printers right?
I have a question. What kind of JetDirect? Does it suport? As far as I know, there two types of JetDirect servers
300 and 500
(may be more)
thanks in advance..
|13:57||alexqwesa has left IRC (firstname.lastname@example.org, Ping timeout: 245 seconds)|
|13:58||alexqwesa has joined IRC (email@example.com)|
|14:24||bakytn has left IRC (firstname.lastname@example.org, Quit: Leaving)|
|14:40||GodFather has left IRC (GodFatheremail@example.com, Quit: Ex-Chat)|
|14:44||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
|14:52||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)|
|15:02||freedomrun_ has joined IRC (freedomrun_!~quassel@BSN-176-160-182.dial-up.dsl.siol.net)|
|15:03||freedomrun has left IRC (freedomrun!~quassel@BSN-176-160-182.dial-up.dsl.siol.net, Ping timeout: 244 seconds)|
|15:12||monteslu has left IRC (firstname.lastname@example.org, Ping timeout: 255 seconds)|
|15:24||monteslu has joined IRC (email@example.com)|
|15:44||Parker955_Away is now known as Parker955|
|15:51||freedomrun has joined IRC (freedomrun!~quassel@BSN-143-157-51.dial-up.dsl.siol.net)|
|15:52||freedomrun_ has left IRC (freedomrun_!~quassel@BSN-176-160-182.dial-up.dsl.siol.net, Ping timeout: 240 seconds)|
|16:16||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
|16:40||vagrantc has joined IRC (firstname.lastname@example.org)|
alkisg: i woke up a little too early this morning thinking about how to configure pxelinux ...
it seemed so clear while i was trying to sleep.
essentially, the client chroot needs to communicate what it supports to the server, and the server needs to pick which it can support...
and then generate a pxelinux.cfg that supports all the versions the client supports...
with ifcpu64.m32 if available, to detect 64 vs 32 bit ... yaboot configurations with powerpc and powerpc64, etc.
ifcpu64.m32 can be used to detect a 486 vs. pae vs 64-bit kernel (i have actual use-cases for all 3 in a 32-bit chroot, believe it or not)
would be nice to integrate into syslinux directly, but could start out within the ltsp codebase or as it's own source package
|16:55||* vagrantc stumbles across pxe-kexec, as a curiosity|
so extlinux has some sort of system to do this, but it's entirely monolothic ... no plugin system.
|17:03||alexqwesa_ has joined IRC (email@example.com)|
|17:04||alexqwesa has left IRC (firstname.lastname@example.org, Ping timeout: 245 seconds)|
i'd really like something more like grub.d, where you can drop plugin files into place
but there are some cool features in extlinux-update
|17:06||khildin_ has joined IRC (email@example.com)|
Unfortunately I spend half of the weekend debugging a twisted bug in epoptes
So I didn't get to move on with the ltsp-mount/ltsp-export-image stuff
|17:10||khildin has left IRC (firstname.lastname@example.org, Ping timeout: 276 seconds)|
The pxelinux configuration seems very far for me... first, make it easy to administer LTSP fat clients with vbox, then a configuration system for ltsp, similar to the ltsp-cluster one...
vagrantc: does debian also only install ltsp-client-core to S25?
I haven't tried a clean ubuntu ltsp installation the last weeks, but I think that the nbd-disconnect script doesn't get called on shutdown...
Btw, qemu-nbd rocks, I don't know why the vdfuse people don't use that instead
alkisg: the current debian init system rewrites where it installs ltsp-client-core every time you install an enabled feature.... it's dependency based.
vagrantc: but is it called on shutdown?
don't think so, since it never did anything before.
If it was, it would just show some syntax errors about missing functions d_stop etc
(or was that in "restart"? not sure)
alkisg: i just noticed you released epoptes 0.4.3
vagrantc: yes to make it for "ui freeze" for ubuntu
But we have a bug so don't bother releasing anything yet
Wait for 0.4.4
i suppose i should set up watch files to point to ubuntu? you're not releasing tarballs "upstream" ?
vagrantc: I've no idea what you just said, but I'm not planning on releasing any other -0ubuntux versions, it was just for the ui freeze
stgraber walked me through the "source tarball" phase, but I'm not sure I completely understood all of it
alkisg: debian/watch files are used to track new releases for upstream versions which is one of the ways i find out about new upstream versions to package
I'm still wondering why isn't "debian native" better for epoptes... :D
alkisg: i need to update mkdst to support basically what i've been doing with a little script of mine.
alkisg: there's nothing inherrently debian about it?
Ah, that's reserved for packages developed *only* for debian?
alkisg: and if you make minor changes to packaging, it uses the same tarball in the archive
Not the deratives too?
well, derivatives do whatever they want, but it makes it harder for derivatives to release differing versions
i.e. the -0ubuntuX versions
Yeah my plan is that I'm too stupid to understand all that so I want the derivatives to tell me what they want to do different so I can put "if"s in the code and release a new version with those :P
Kidding aside, will that mkdst thing also help in getting the version from the changelog and putting it to the source code for e.g. epoptes-client --version to work without manually changing it each time?
alkisg: might be simple enough to set up a bzr-release target in (ironically) debian/rules that creates the new upstream tarball.
as long as it's not automatically called during build.
Sounds fine to me
alkisg: you could have the build process dump a version file somewhere
Is that better than sed'ing the version in the source?
(thinking of python's __init__.py, which also contains the version...)
epoptes/__init__.py:__version__ = "0.4.3"
Maybe setup.py could do all that?
tcos-configurator has code for that... it even uses __VERSION__ in its headers, I suppose it's substituted by setup.py automatically
|17:33||bmonkj has left IRC (email@example.com, Ping timeout: 248 seconds)|
alkisg: that would only work if debian/changelog was there ... traditionally, it's better if debian/changelog isn't shipped upstream.
out of all the problems in epoptes, this one seems to get under your skin :)
vagrantc: so the bzr-release target could create the upstream source by reading debian/changelog and sed'ing wherever needed?
actually, epoptes works pretty well.
alkisg: yes, although then you'd want to build from the source tarball rather than from the bzr dir.
...as long as a launchpad recipe can do that, I'm fine with it :D
|17:38||* alkisg stopped building locally!|
|17:39||* vagrantc *sighs*|
The main problem of epoptes now is that it doesn't tell people that their chroot certificate is different than the one of the server :-/
long ago, when we split ltsp-client-core out of ltsp-client ... i renamed the ltsp-client-core init script ... but if i had known better, i wouldn't have had to.
alkisg: i.e. the certificate handling is broken?
alkisg: does it silently work? or does it silently fail?
|17:40||Mobe has joined IRC (Mobe!~Mobe@adsl-85-217-42-202.kotinet.com)|
If a user has a wrong certificate, it's the user's fault,
and epoptes-client correctly fails to connect, but the problem is that it doesn't notify the user
In order to notify the user I'd have to have another sh process as a wrapper for the socat call, wasting 1 more mb of ram
There's also a socat bug there, I reported it to the author, but I don't think the fix will make it for precise and not sure about wheezy either
Nothing too serious, people that read the instructions should be fine, but those who don't, then complain why epoptes doesn't work for them...
alkisg: there's no way to check the status of socat from whatever's calling it without another shell wrapper?
I'm doing `exec socat` there, to save the ram of the caller script
And I don't think it has an option to "fork and return success or failure"
socat then runs a shell, so I could do that:
outer script => calls socat => calls inner script, which kills outer script
...but I think in that case I get a sh <defunct>
knipwim: i had to work around the ssh-hostchecker not being executable as well, simple chmoding it at build time, but that should be fixed upstream, probably.
hm. epoptes related mail needs it's own folder now, it seems.
|17:51||* alkisg just hardcodes VERSION=xxx in epoptes-client too for now, will automate it in the future when he reads more about all that mkdst/bzr-release stuff...|
btw, gentoo has a functional ltsp-client-5.3!
i was wondering though, about dependencies of the ltsp-client package
and requirements during the boot process
a saw for instance, debian didn't have a dep on cron, although it's configured in an initscript
in the 5.2 situation, the build proces took care of any of those dependencies
knipwim: debian has an indirect recommends on cron, but it should probably have a straight dependency
how does debian make sure the cron service is actually started in the ltsp client boot?
|18:11||* vagrantc wonders the status of aufs/overlayfs on obscure architectures|
knipwim: it doesn't.
it's a work in progress :)
shouldn't it? at least, i was wondering about that for gentoo, making sure to call the required services in 50-rcfiles
like cron and syslog
in fact, it's actualy explicitly disabled now, due to init-ltsp.d/Debian/50-rm-system-services ... hrm.
ah, work in progress :)
oh, no, it's just in comments
What is disabled?
We delete some of the cron jobs, but not the cron service
And if cron isn't there, the scripts shouldn't fail
So why would we need cron as a hard dependency?
alkisg: it's mentioned in the comments, but not actually disabled
alkisg: i put it as a suggests in ltsp-client-core and a depends in ltsp-client
For the shutdown lts.conf directive?
because of all the cron related lts.conf options.
Wouldn't "recommend" be better?
this brings us to the existance of ltsp-client-core....
E.g. we also have an lts.conf for numlock, but it only works if one manually installs that package...
most of the ltsp-client-core dependencies could be represented as recommends on ltsp-client ...
but recommends aren't handled well on upgrades.
also, disabling recommends is annoying, and it'd be hard to selectively disable recommends.
alkisg: cron is a dependency for SHUTDOWN_TIME
knipwim: yes, but not all people use that option, so why make it a dependency?
knipwim: if so, we should put the X_NUMLOCK dependency too
|18:17||killermike has joined IRC (firstname.lastname@example.org)|
alkisg: so yes, the case for recommends can be made, but i'd prefer depends.
that is the question, package ltsp-client to include all options by default, or not
alkisg: if you really don't want it, install ltsp-client-core and all the dependencies.
|18:18||loather has joined IRC (email@example.com)|
In ubuntu it's a dependency of ltsp-client-core :)
ltsp-client-core Depends: busybox-static, console-setup, cron, initramfs-tools (>= 0.11), kbd, lsb-base, lsb-release, mkelfimage, nbd-client (>= 1:2.9.25-2), numlockx, pciutils, python, python-daemon, python-serial, syslinux, tftp-hpa, udhcpc, usbutils, libc6 (>= 2.7), libpopt0 (>= 1.14), libx11-6
i'll make it a dependency of ltsp-client, but only a suggests for ltsp-client-core
Yeah that sounds reasonable
alkisg: that's basically what i do, for most features, i'll have ltsp-client depend on it and ltsp-client-core suggest it.
anything that's core to getting it to boot at all is a dependency for ltsp-client-core.
so that's one area wheere debian and ubuntu diverge a bit.
I don't mind having cron and other packages installed in my chroot, I'll even use vbox and the desktop ubuntu CDs instead of calling ltsp-build-client from now on, I was just wondering why...
I'd like it if the ltsp packaging in ubuntu and in debian got a little closer in the future
and i stick with depends for ltsp-client-core to ensure that upgrades pull in new features.
You mean ltsp-client there, right?
well, both, but yes :)
i should really experiment with using depends/suggests variables for this stuff.
Hmm the lts.conf manpage needs a bit of updating
sure does, probably.
ltsp-docs needs some serious review
knipwim: added cron as a depends/suggests for the next debian upload, thanks for the bug report! :)
vagrantc, knipwim, so should we add x11-xserver-utils for xrandr?
|18:30||Parker955 is now known as Parker955_Away|
|18:46||duff has joined IRC (firstname.lastname@example.org)|
|18:47||duff has left IRC (email@example.com)|
btw, i see another run_rcfiles() in ltsp-init-common, a different one than the common/50-rcfiles
the cleanup is also part of the work in progress probably :)
|19:07||Parker955_Away is now known as Parker955|
|19:08||killermike has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|19:09||killermike has joined IRC (email@example.com)|
knipwim: Gadi copied parts of ltsp-init-common to init-ltsp.d, but he didn't remove them from there, in case other distros wanted to use them as functions
So any parts you don't need anymore, remove them...
I think in ltsp-init-common we should only keep stuff that ltsp-client(-core) needs
I.e. parts that need services up and running to work, and can't go in init-ltsp.d
in my case that would only be start_screen_sessions and start_sound
some are called from init-ltsp.d scripts
They should be moved there then
configure_sound_volume => called from udev
configure_localdev => from udev
configure_swap => init-ltsp.d
was gentoo the last distro to move to init-ltsp.d?
I think gentoo and opensuse move to that at the same time,
while fedora and altlinux... no idea
configure_printer => init-ltsp.d (copy)
configure_scanner => init-ltsp.d
fedora doesn't look too well: http://www.redhat.com/archives/k12osn/2011-May/msg00054.html
configure_serial_mouse => ...let's drop that
set_time => I think we should drop that too, there are distro initscripts for that
configure console, resolver, fstab, home, cron => init-ltsp.d
bind_mounts, unmounts => I think they can be dropped
nbd_sendsigs_protection => init-ltsp.d
So yeah most of ltsp-init-common can go
i can start on some of those, copying stuff
What warren says about LTSP there isn't really true, fat clients support compositing and youtube videos and everything
And an atom may be borderline powerfull to run spice, but it can surely run most apps as a fat client
|19:25||bobby_C has joined IRC (bobby_Cfirstname.lastname@example.org)|
i can't even run unity on my atom
Really? My daughter's atom, 3 years old, runs it fine (intel card)
maybe it's the graphics card then
Although she didn't like it at all and asked for the old gnome instead
So we compromised on KDE
In my laptop (intel again), unity makes 3d apps work very slow
So I've switched to gnome-shell
|19:28||bmonkj has joined IRC (email@example.com)|
|19:34||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)|
|19:41||bmonkj has left IRC (firstname.lastname@example.org, Ping timeout: 252 seconds)|
|19:43||pem725 has left IRC (pem725!60ff4152@gateway/web/freenode/ip.126.96.36.199, Ping timeout: 245 seconds)|
no wonder fedora support is lacking, berating the community for not helping doesn't really inspire people to work together.
too bad, i was hoping to collaborate on the dracut initramfs stuff
|20:20||khildin_ has left IRC (email@example.com, Read error: Connection reset by peer)|
|20:21||khildin has joined IRC (firstname.lastname@example.org)|
|20:24||komunista has left IRC (email@example.com, Quit: Leaving.)|
oh, look, we're famous: https://en.wikipedia.org/wiki/Ltsp
probably could use some updating, though
|21:31||komunista has joined IRC (firstname.lastname@example.org)|
That one was hard for now.. To get nvidia working with dual monitors.
|22:04||LoveStorm has left IRC (LoveStorm!Storm@gateway/shell/trekweb.org/x-wppmdzpwtrbqntot, Changing host)|
|22:04||LoveStorm has joined IRC (LoveStorm!Storm@unaffiliated/lovestorm)|
|22:04||LoveStorm has joined IRC (LoveStorm!Storm@gateway/shell/trekweb.org/x-wppmdzpwtrbqntot)|
|22:36||vagrantc has left IRC (email@example.com, Quit: leaving)|
|22:41||komunista has left IRC (firstname.lastname@example.org, Quit: Leaving.)|
|23:05||freedomrun has left IRC (freedomrun!~quassel@BSN-143-157-51.dial-up.dsl.siol.net, Remote host closed the connection)|
|23:06||freedomrun has joined IRC (email@example.com)|
|23:11||freedomrun has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|23:15||freedomrun has joined IRC (freedomrun!~quassel@BSN-143-157-51.dial-up.dsl.siol.net)|
|23:24||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
|23:27||freedomrun has left IRC (freedomrun!~quassel@BSN-143-157-51.dial-up.dsl.siol.net, Remote host closed the connection)|
|23:36||bobby_C has left IRC (bobby_Cemail@example.com, Quit: Goin' down hard)|
|23:40||khildin has left IRC (firstname.lastname@example.org, Quit: I'm gone, bye bye)|
Shouldn't we remove configure_sound_volume from ltsp-core now that it's called by udev?
Also I think that the following ltsp-init-common functions should be removed:
configure_localdev (moved to udev), configure_swap configure_resolver configure_fstab configure_home run_rcfiles (moved to init-ltsp.d), configure_serial_mouse bind_mounts bind_unmounts (obsolete)
And the following scripts should be deleted: ltsp-setup ltsp-bindmounts (or is gentoo still using it?)
So the only functions remaining in ltsp-init-common would be: warn, start_sound, start_screen_sessions
...and in the future start_sound should actually start pulseaudio as user, while logging in in thin sessions only. Not from an initscript.
|23:59||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)|