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


Channel log from 24 December 2013   (all times are UTC)

00:08gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
00:15gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 272 seconds)
00:20willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Textual IRC Client: http://www.textualapp.com/)
03:02Fenuks has joined IRC (Fenuks!~Fenuks@5.128.82.13)
04:28shogunx has left IRC (shogunx!~shogunx@rrcs-67-79-182-229.se.biz.rr.com, Ping timeout: 272 seconds)
04:31alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
04:31gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
04:32
<alkisg>
It's the first time a build failure meant something really good... bb, cdpinger!
04:32
https://launchpadlibrarian.net/160565915/buildlog_ubuntu-lucid-amd64.ltspfs_0.9%2Bbzr162%2B201312240125-0ubuntu1%2B3~ubuntu10.04.1_FAILEDTOBUILD.txt.gz
04:36gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 264 seconds)
04:36
<alkisg>
vagrantc: $ grep -r cdpinger .
04:36
./man/Makefile.am:dist_man_MANS = lbmount.1 ltspfs.1 ltspfsd.1 ltspfsmounter.1 cdpinger.1 ltspfs_mount.1 ltspfs_umount.1
04:36
./man/cdpinger.1:.TH "cdpinger" "1" "20080825"
04:36
...
04:40shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-229.se.biz.rr.com)
05:21freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
05:33Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
05:44Fenuks has left IRC (Fenuks!~Fenuks@5.128.82.13, Ping timeout: 264 seconds)
05:44alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 248 seconds)
05:51Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 240 seconds)
05:55Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
05:55
<vagrantc>
huh. wonder why it built for me.
06:00Fenuks has joined IRC (Fenuks!~Fenuks@5.128.82.13)
06:05Fenuks has left IRC (Fenuks!~Fenuks@5.128.82.13, Ping timeout: 260 seconds)
06:34gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
06:37gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Read error: Operation timed out)
06:56Parker955_Away is now known as Parker955
06:56freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
07:10Parker955 is now known as Parker955_Away
07:12Parker955_Away is now known as Parker955
07:21Fenuks has joined IRC (Fenuks!~Fenuks@5.128.82.13)
08:00staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
08:07staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 272 seconds)
08:40Parker955 is now known as Parker955_Away
09:02bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 272 seconds)
09:03bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
09:03freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
09:16vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
09:38gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
09:43gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 272 seconds)
10:26workingcats has joined IRC (workingcats!~workingca@212.122.48.77)
10:35Fenuks has left IRC (Fenuks!~Fenuks@5.128.82.13, Ping timeout: 272 seconds)
10:40gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
10:45gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 246 seconds)
10:58mattcen has left IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au, Read error: Connection reset by peer)
10:59cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Read error: Connection reset by peer)
11:00mattcen has joined IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au)
11:01cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
11:08Gremble has joined IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net)
11:08Gremble is now known as Guest71983
12:02workingcats has left IRC (workingcats!~workingca@212.122.48.77, Quit: Leaving)
12:12gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
12:15gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
12:37Parker955_Away is now known as Parker955
12:59christophe_y2k has joined IRC (christophe_y2k!~christoph@man06-3-78-237-22-85.fbx.proxad.net)
13:08alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Read error: Operation timed out)
13:17alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
13:23khildin has joined IRC (khildin!~khildin@ip-213-49-87-240.dsl.scarlet.be)
13:25khildin has left IRC (khildin!~khildin@ip-213-49-87-240.dsl.scarlet.be, Read error: Connection reset by peer)
13:41khildin has joined IRC (khildin!~khildin@ip-213-49-87-240.dsl.scarlet.be)
13:48freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
14:06klausade has left IRC (klausade!~klaus@cm-84.215.153.179.getinternet.no, *.net *.split)
15:06j-gate has joined IRC (j-gate!3e4a17ae@gateway/web/freenode/ip.62.74.23.174)
15:10j-gate has left IRC (j-gate!3e4a17ae@gateway/web/freenode/ip.62.74.23.174)
15:34Parker955 is now known as Parker955_Away
15:35techsys has joined IRC (techsys!3edbe69b@gateway/web/freenode/ip.62.219.230.155)
15:35
<techsys>
how do i dfine ltsp on ubunto server?
15:48techsys has left IRC (techsys!3edbe69b@gateway/web/freenode/ip.62.219.230.155, Ping timeout: 272 seconds)
15:48gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
15:50
<khildin>
techsys explain 'define'?
15:50gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
15:51
<khildin>
if you want an easy way: get the Edubuntu desktop DVD and install from that....
15:51
LTSP will be a breeze to install then...
15:52
hmz... tech already split....
15:57staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
16:04staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 272 seconds)
16:30khildin has left IRC (khildin!~khildin@ip-213-49-87-240.dsl.scarlet.be, Quit: I'm gone, bye bye)
16:30khildin has joined IRC (khildin!~khildin@ip-213-49-87-240.dsl.scarlet.be)
16:48
<andygraybeal__>
khildin, you mkae it home ok?
16:49
<khildin>
hi andygraybeal__ yeah... I came home sunday morning...
16:49
<andygraybeal__>
:)
16:49
<khildin>
and ofc..... too little time there.... I could have used a few weeks more
16:50
but also glad I am back with my family
16:51
<andygraybeal__>
it is crazy that there is no way to do remote support!!
16:51
i can't imagine being disconnected
16:51
<khildin>
that's next step
16:54
<andygraybeal__>
they are going to get connected somehow?
16:55
<khildin>
I hope so....
16:55
implement a wifi stream to the mainland
16:55
<andygraybeal__>
that is cool
16:55
i'm effing around with phpbb forum software https://scytheforums.com
16:59
<khildin>
what is scythforums for?
17:08
<andygraybeal__>
for mowing and reaping
17:08
and learning
17:08
and tidying up around the house
17:12
<khildin>
ah ok....
17:12
hope it gets growded a bit then... :)
17:26gbaman_ has joined IRC (gbaman_!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
17:28gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 272 seconds)
17:33gbaman_ has left IRC (gbaman_!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 272 seconds)
17:39khildin has left IRC (khildin!~khildin@ip-213-49-87-240.dsl.scarlet.be, Quit: I'm gone, bye bye)
17:43vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
17:48christophe_y2k has left IRC (christophe_y2k!~christoph@man06-3-78-237-22-85.fbx.proxad.net, Quit: Leaving.)
17:59xcom has joined IRC (xcom!~wtf@pdpc/supporter/professional/seri)
18:09stgraber has left IRC (stgraber!~stgraber@ubuntu/member/stgraber, Ping timeout: 252 seconds)
18:11stgraber has joined IRC (stgraber!~stgraber@ubuntu/member/stgraber)
18:11Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.)
18:18gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
18:22Guest71983 has left IRC (Guest71983!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net, Quit: I Leave)
18:36xcom has left IRC (xcom!~wtf@pdpc/supporter/professional/seri, Quit: leaving)
18:55gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 246 seconds)
19:14alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
19:18
<alkisg>
vagrantc: time for a new branch? or should we first implement the new pxelinux.cfg/default configuration we were talking about?
19:19
Btw, the recipe failed because it's using an obsolete packaging branch that stgraber uploaded a few years ago
19:19
vagrantc, stgraber: should we change the ltsp daily builds to use vagrantc's packaging instead?
19:20
For ldm and ltspfs it's the same... for ltsp, /me prefers the debian packaging for testing even on ubuntu...
19:26
Old recipe contents:
19:26
# bzr-builder format 0.3 deb-version {debupstream}+bzr{revno}+{time}-0ubuntu1+{revno:packaging}
19:26
lp:ltsp/ltspfs-trunk
19:26
nest-part packaging lp:~ltsp-upstream/ltsp/ltspfs-trunk.daily-packaging debian debian
19:26
New recipe contents:
19:26
# bzr-builder format 0.3 deb-version {debversion}+r{revno}+p{revno:pkg}
19:26
lp:ltsp/ltspfs-trunk
19:26
nest pkg lp:~vagrantc/ltsp/ltspfs-debian-packaging debian
19:29
Same for ldm:
19:29
# bzr-builder format 0.3 deb-version 2:{debupstream}+bzr{revno}+{time}-0ubuntu1+{revno:packaging}
19:29
lp:ltsp/ldm-trunk
19:29
nest-part packaging lp:~ltsp-upstream/ltsp/ldm-trunk.daily-packaging debian debian
19:30
New:
19:30
# bzr-builder format 0.3 deb-version {debversion}+r{revno}+p{revno:pkg}
19:30
lp:ltsp/ldm-trunk
19:30
nest pkg lp:~vagrantc/ltsp/ldm-debian-packaging debian
19:32
...and finally, ltsp:
19:32
bzr-builder format 0.3 deb-version {debupstream}+bzr{revno}+{time}-0ubuntu1+{revno:packaging}
19:32
lp:ltsp
19:32
nest-part packaging lp:~ltsp-upstream/ltsp/ltsp-trunk.daily-packaging debian debian
19:32
New:
19:32
# bzr-builder format 0.3 deb-version {debversion}+r{revno}+p{revno:pkg}
19:32
lp:ltsp
19:32
nest pkg lp:~vagrantc/ltsp/ltsp-debian-packaging debian
19:33
All done :)
19:34
Results...
19:35
Building ltspfs on Lucid failed because debhelper 9 isn't available, https://launchpadlibrarian.net/160620277/buildlog.txt.gz
19:35
...removing Lucid from the build targets...
19:36
Saucy errored out too, Makefile.am: error: required file './ChangeLog' not found: https://launchpadlibrarian.net/160620477/buildlog_ubuntu-saucy-amd64.ltspfs_1.2-1%2Br164%2Bp136~ubuntu13.10.1_FAILEDTOBUILD.txt.gz
19:41
LDM goes better, except for Trusty: dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision
19:42
...and LTSP failed too :(
19:42
<vagrantc>
"works for me."
19:43
the missing ChangeLog file is because i generate the changelog when i build the .orig.tar.gz
19:44
so if building from bzr you basically need to do a: bzr log --short > ChangeLog
19:45
<alkisg>
vagrantc: would you accept packaging changes that would make it work with launchpad recipes?
19:46
<vagrantc>
alkisg: as long as they didn't violate debian policy :)
19:46andygraybeal__ has left IRC (andygraybeal__!~andy@h21.194.213.151.dynamic.ip.windstream.net, Ping timeout: 264 seconds)
19:46
<alkisg>
Sure
19:46
<vagrantc>
or do things that i balk at :)
19:47* alkisg is more worried about the "native packages cannot have a revision" message
19:48
<alkisg>
I.e. even if we find some way to say "we're building on launchpad so dynamically change the format to non-native", I'm worried you wouldn't accept that :)
19:48
<vagrantc>
make the revisioning not use a - in the version?
19:49
<alkisg>
~ is ok?
19:49
<vagrantc>
should be
19:49
or +
19:49
depending on how you want the versions to sort
19:50
<alkisg>
https://code.launchpad.net/~ltsp-upstream/+recipe/ldm-trunk-daily
19:50
It succeeded in most versions of ubuntu but failed on trusty
19:50
<vagrantc>
weird
19:50
<alkisg>
For example this was fine in Saucy: ldm_2.2.12-1+r1540+p957~ubuntu13.10.1_amd64.deb
19:51
<vagrantc>
i'm not really familiar with launchpad recipes
19:51
<alkisg>
I think the problem is the newer version of dpkg-source...
19:51* alkisg googles a bit
19:52
<vagrantc>
it shouldn't be a hard error... that should just be a warning
19:52
the - is valid in native package versions, it's just unconventional... unless policy changed...
19:53gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
19:55
<vagrantc>
alkisg: already found an issue with the cdpingerless ltspfsd...
19:56
<alkisg>
What?
19:56
<vagrantc>
alkisg: cd without media still shows up as a mount until you try to use it
19:56
think that could be fixed in the ltspfs_entry script somehow...
19:57gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 240 seconds)
19:59
<vagrantc>
alkisg: the cdpinger autobuilds only failed because of broken packaging, not the few things i missed in the upstream portions, right?
19:59andygraybeal__ has joined IRC (andygraybeal__!~andy@h250.204.213.151.dynamic.ip.windstream.net)
19:59
<alkisg>
vagrantc: they failed because of missing ./Changelog
20:01
<vagrantc>
could workaround that with "touch ChangeLog"
20:01
might even be able to get debhelper to only install a changelog if it's present
20:04
or maybe it's autotools that doesn't like the empty changelog
20:04
er, missing
20:04* alkisg starts with the "native packages can't have a revision" issue first, which affects all of our 3 recipes in Trusty...
20:05
<alkisg>
Ouch, launchpad sent 25 mails about failed builds...
20:05
<vagrantc>
alkisg: as far as forking, i'd like to at least get the "xprop -spy" changes into ltsp 5.4.x before forking
20:05
alkisg: it sure did :P
20:11
<alkisg>
vagrantc: what's the epoch 2: in the ldm packaging for?
20:15
This was successfully built, hope the version seems sane: ldm - 2:2.2.12+r1540+p957~ubuntu14.04.1
20:21
Hmm I could duplicate these recipes with me as the owner so that the other distro devs don't get annoyed by emails...
20:48
https://help.launchpad.net/Packaging/SourceBuilds/BzrBuilder => Note: Launchpad does not support the run command.
20:48
So it needs to be done from debian/rules...
20:50
(touching the Changelog)
20:51
Or, we could just commit an empty Changelog file
20:59
<vagrantc>
we used to have empty changelog files in some of our pprojects...
20:59
are there extra environment variables available to debian/rules to detect when to run the changelog stuff?
21:00
alkisg: the epoch was because ldm used to be part of ltsp 5.x, and when we split it into a separate project, it was ldm 2.x, so needed the epoch.
21:00
alkisg: should've just versioned ldm 2.x with 5.x or something, but now we're stuck with it
21:01gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
21:05
<alkisg>
vagrantc: it could check if Changelog is missing, and only touch it then?
21:22andygraybeal__ has left IRC (andygraybeal__!~andy@h250.204.213.151.dynamic.ip.windstream.net, Ping timeout: 264 seconds)
21:24
<vagrantc>
alkisg: guess so
21:25
alkisg: the empty changelog is a bit simpler...
21:25
<alkisg>
Sure
21:25
<vagrantc>
i think my tarball generating script handles that
21:26
or "This is a dummy changelog that should be generated by bzr log --short > Changelog"
21:26
or even make it executable :)
21:27
<alkisg>
We already have empty NEWS etc files, so an empty Changelog sounds more fitting...
21:27
<vagrantc>
do we need those other empty files?
21:27* vagrantc would like to get rid of whatever cruft can be gotten rid of
21:27
<alkisg>
Not sure... maybe they're there to silence some warnings of the build tools
21:27
<vagrantc>
and at least leaving a comment in them suggesting what should happen to them...
21:28
otherwise you might get someone committing changes to it
21:28* vagrantc wants to purge the ALTLinux po files
21:28
<vagrantc>
if not all of the ALTLinux cruft
21:29
<alkisg>
+1 :)
21:29
Let's do it on ltsp6 though, it'll make more sense there to remove stuff that hasn't been updated in ages
21:30
i.e. after the trunk cloning
21:34
<vagrantc>
so, we wanted to rewrite the pxelinux/*update-kernels stuff for one last time before forking ltsp6?
21:35andygraybeal__ has joined IRC (andygraybeal__!~andy@h41.207.213.151.dynamic.ip.windstream.net)
21:36
<alkisg>
vagrantc: yes, but I'm not sure if we want to do it before or after...
21:39
...probably "before" :)
21:40
http://irclogs.ltsp.org/?d=2013-11-26
21:42andygraybeal__ has left IRC (andygraybeal__!~andy@h41.207.213.151.dynamic.ip.windstream.net, Ping timeout: 264 seconds)
21:46bringar has joined IRC (bringar!~bringar@184-155-220-102.cpe.cableone.net)
21:47
<alkisg>
07:57<vagrantc> alkisg: so, what's now the update-kernels hook would merely become a symlink generator ... in /boot/ of the client chroot ? and ltsp-update-kernels would actually copy files from both the <chroot>/boot/ and <chroot>/etc/ltsp/pxelinux* ?
21:48
I think that's the main idea...
21:49
And, " Now, the chroot conffile doesn't have to be a pxelinux.cfg file. It can just list the default kernel parameters"
21:53
<vagrantc>
we hashed that out so many times...
21:53
would be good to finally implement it :)
21:54
also, i liked the idea of having ltsp-update-kernels put /opt/ltsp/i386/boot and /opt/ltsp/images/i386.img:/boot in different tftp dirs
21:54
that way you can have either.
21:56
alkisg: ltsp-update-kernels could just do as it does now, but also create <tftpdir>/ltsp/pxelinux.cfg/* in addition to <tftpdir>/ltsp/<arch>/pxelinux.cfg/*
21:56
and leave the client-side code alone...
21:56
or at least for an initial pass at an implementation
21:57
alkisg: this could also be implemented in a separate branch with multiple commits, and only merge it to trunk once it works...
21:57
ah, the symlink generator ... for vmlinuz-pae, vmlinuz-amd64, vmlinuz-x86, etc.
21:57
<alkisg>
I think we first need to sum up what we want to do... sync.in/ltsp, or wiki? :)
21:59
<vagrantc>
alkisg: what about a gobby instance?
21:59
<alkisg>
np, let me install it..
21:59
<vagrantc>
gobby-0.5, at least on wheezy
22:00
<alkisg>
OK I've opened it, then what? connect to server?
22:00* vagrantc wonders about a gobby server
22:01
<vagrantc>
alkisg: connect to server -> gobby.debian.org ?
22:30andygraybeal__ has joined IRC (andygraybeal__!~andy@h41.207.213.151.dynamic.ip.windstream.net)
22:34
<alkisg>
vagrantc: I don't think `ltsp-config pxe` does anything significant, I think we should put all the code in ltsp-update-kernels
22:35
<vagrantc>
alkisg: fair enough.
22:36gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
22:36
<alkisg>
ltsp-config could update the server configuration files for NBD/NFS if we want...
22:36
<vagrantc>
want.
22:37
with NFS, we just need /opt/ltsp/, since all the chroots share a single config.
22:37
but ltsp-config nfs would be great.
22:37gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
22:37
<vagrantc>
at least on debian, it just needs to add one line to /etc/exports.d/ltsp.export(s?)
22:38
yup, /etc/exports.d/ltsp.exports
22:38
<alkisg>
It could also prompt to install the necessary packages
22:38
<vagrantc>
sure.
22:38
we could do the thing with functions with distro-specific overrides for all of it
22:39
or stub functions
22:39
<alkisg>
Nice
22:39
<vagrantc>
since /etc/exports.d/ maybe be "debian"-specific
22:40
and the NBD configs are tied to specific nbd versions ...
22:42
<alkisg>
I think we should let all the ifcpu64 handling up to the user. We'd provide him with the symlinks, and even if they don't have standard names he could create a static default file that uses them
22:42
<vagrantc>
why leave ifcpu64 handling out?
22:43
<alkisg>
He could even use feature detection if he wanted, without restricting him to 32, 64, and pae
22:43
For simplicity
22:43
<vagrantc>
it's a lot more complicated for the user
22:43
<alkisg>
In the default case, he'd just copy an example file
22:43
<vagrantc>
then we may as well just have one symlink ... only reason i see to hvae the symlinks is to support thta
22:44
<alkisg>
symlinks == static pxelinux.cfg/default file
22:44
Without symlinks the user would need to edit it on each kernel upgrade
22:44
<vagrantc>
but having to specify 64 vs. pae vs. 32 ?
22:45
the template just defaults to 32 only? or what?
22:45bringar has left IRC (bringar!~bringar@184-155-220-102.cpe.cableone.net, Quit: Leaving)
22:45
<alkisg>
We'd have a wiki page. It would instruct him to install the kernels in the chroot and to edit pxelinux.cfg/default according to an example.
22:45
<vagrantc>
that seems more complicated to me.
22:46
when it's so easy to implement in code
22:46
<alkisg>
The always-generated pxelinux.cfg/ltsp file would contain a menu with all the symlinks (i.e. only the latest kernels) and a submenu with all the kernel versions
22:47
<vagrantc>
and the first entry is the "most compatible" symlink?
22:48
<alkisg>
Yeah in some order defined by update-kernels.conf
22:48
<vagrantc>
well, that's a per-chroot configuration file...
22:49
but we're talking about a global pxe configuration
22:50
if the always-generated pxelinux.cfg/ltsp included ifcpu64 always, what's the additional complexity?
22:50* alkisg checks what we can do with the existing update-kernels.conf... so that we at least keep compatibility with 12.04/wheezy...
22:50willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
22:50
<vagrantc>
12.04 and wheezy are totally different, aren't they?
22:50
ifcpu64 support is definitely in the code already
22:51
but i didn't enable it by default
22:51
<alkisg>
Ah, no I'm using the greek schools ppa... maybe 12.10 was the first one with the new update-kernels.conf
22:52
<vagrantc>
although really, the biggest advantage of ifcpu64 support, would be not just selecting kernel, but chroot/img
22:52
which we don't yet have.
22:52* alkisg would leave that up to the user too
22:53
<vagrantc>
i guess.
22:53
i guess it's not hard to write up ifcpu64 code.
22:54
<alkisg>
I'm a little worried about having consistent symlink names too
22:54
E.g. I may have 3 32-bit kernels...
22:54
real time, vm, generic...
22:55
Without touching much the current client code, we can have the symlinks like vmlinuz-generic, vmlinuz-generic-pae etc
22:55
The user then can just put those in ifcpu64...
22:57
Anyways. For my needs, the most significant part are the symlinks which then allow for static pxelinux.cfg/* files, other than that I don't mind so we can do it however you want :)
22:59
<vagrantc>
it seems like having 3 different types of 32-bit kernels is worth leaving to manual configuration
22:59
<alkisg>
How are you using ifcpu64 now?
22:59
Are you branching to different chroots?
23:00
<vagrantc>
alkisg: so, with the current code, we've got the ability to specify multiple 32-bit capable kernels in LIST_KERNELS_DEFAULT
23:00
er, LIST_KERNELS_32
23:00
alkisg: just a single chroot with amd64, 686-pae or 486 kernels
23:00
alkisg: all i386 chroot.
23:01
<alkisg>
Yup. In the new code, I wouldn't care at all about the LIST_KERNELS_* variants, one single LIST_KERNELS would be enough for me, I'd leave all the rest up to the user, but for the sake of compatibility (and to minimize code changes) I'd leave the LIST_KERNELS_* variants as they are now...
23:01
<vagrantc>
but i've seen sites that could use a different chroot for different arch ... i.e. mixed 64-bit fat clients and 32-bit thin clients
23:01
<alkisg>
We couldn't support that ^ with our current code... it doesn't handle multiple chroots with ifcpu64...
23:01
<vagrantc>
i think the LIST_KERNELS_DEFAULT was a way for the user to override the semi-hard-coded _64, _PAE and _32 options
23:02
alkisg: yes, i know the current code doesn't handle it
23:02
but ok, so re-implementing what we have now...
23:03
though the way we're reimplimenting it suggests to me these things that weren't really possible with the old way.
23:03
if we're moving everything server-side, automatic chroot detection becomes possible in ways it wasn't before
23:04
but anyways, there will need to be a menu entry for each chroot/img and kernel combination
23:04
<alkisg>
Btw, some of the update-kernels.conf variables should be on the server side, like PXELINUX_DEFAULT=menu, TIMEOUT...
23:04
<vagrantc>
yup
23:05
<alkisg>
We're not moving everything... we're basically splitting it in both server and client
23:06
<vagrantc>
right
23:06
<alkisg>
Let's make some decisions... so first, do we want to try standarized symlink names, or we just go with the distro kernel name and just remove the version?
23:06
vmlinuz-generic, vmlinuz-486...
23:07
...or vmlinuz-32 ?
23:07
vmlinuz-generic should be easy to support with the current code
23:08
<vagrantc>
the only reason i see to support -64, -pae, -32 is for cross-distro support.
23:08
otherwise, i'd say distro-specific naming conventions ...
23:08
i.e. -generic doesn't exist on debian for most architectures
23:09
or any current architectures, from the looks of it
23:10
alkisg: i guess the sorting rules to figure out the most-compatible variant are needed
23:11
<alkisg>
In 12.10+, there's no pae kernel, and the names of -32 and -64 are the same
23:11
<vagrantc>
heh.
23:11
<alkisg>
So I'm not even sure what to put in LIST_KERNELS_*
23:12
<vagrantc>
i guess you'd just put LIST_KERNELS_32='generic' LIST_KERNELS_PAE='generic' LIST_KERNELS_64='generic' ?
23:13
<alkisg>
(no pae ==> I mean that there's no -32 kernel, it's -pae by default)
23:13
<vagrantc>
orr leave LIST_KERNELS_32=''
23:14
or leave them as is, for backportability, it just won't find anything?
23:14
and generic is not quite right...
23:15
<alkisg>
Leave them as they are, or use LIST_KERNELS_32="lowlatency virtual generic", LIST_KERNELS_PAE="", LIST_KERNELS_64="lowlatency virtual generic"
23:15
<vagrantc>
i guess having all architectures use "generic" makes it simple for kernel selection... but sure makes it hard to have media that supports multiple variants.
23:15
<alkisg>
...but whatever I don't, I won't be able to make ifcpu64 work because it'll only work on different chroots
23:15
s/don't/do/
23:15willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Computer has gone to sleep.)
23:16willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
23:16
<vagrantc>
so ifcpu64 is only useful on (recent) ubuntu if it supports multiple chroots
23:16
alkisg: which you're not really likely to use?
23:16
<alkisg>
Right, and I would leave that up to the user then, completely ignoring ifcpu64 in the ltsp code...
23:17
But I don't mind, go ahead and implement that part however you like, it doesn't matter to ubuntu anyways
23:17
<vagrantc>
ok, let's do the initial implementation without ifcpu64 support.
23:17
should be easy enough to add later.
23:18
by those who want it :_)
23:18
<alkisg>
By ignoring ifcpu64, we also don't need to list all the kernel variants
23:19
E.g. now I see that 14.04 has -server, -goldfish and some other new variants
23:19
<vagrantc>
just use symlinks?
23:19
what do you mean by "list all the kernel variants" ?
23:20
i still think we should add entries for all available kernels.
23:20
the lists would just, at least in theory, affect sort order
23:20
<alkisg>
I think that if I install only the -server kernel, our code will completely ignore it
23:21
<vagrantc>
i'm pretty sure it currently adds an entry for it, defaulting to "vmlinuz"
23:21
<alkisg>
Let me check...
23:25
<vagrantc>
we should drop the gpxelinux.0 code ... some versions are rather outdated.
23:26
<alkisg>
Heh... by default we don't use any of the lists, ok :)
23:26
<vagrantc>
i think it uses them, but handles if nothing comes up
23:27
version=$(LIST_KERNELS="$LIST_KERNELS_DEFAULT $LIST_KERNELS_32 *" kernel_versions | head -n 1)
23:29
<alkisg>
True. OK, what I want is to put an "ln" inside for arch in ${LIST_KERNELS:-*}; do
23:29
...and I don't mind whatever else you do with ifcpu64 etc :)
23:32mystic has joined IRC (mystic!52d9348b@gateway/web/freenode/ip.82.217.52.139)
23:32
<mystic>
hi people
23:33
<vagrantc>
alkisg: what do you mean by 'put an "ln" inside' ?
23:34
<mystic>
i'm new to this and i got a test ltsp server running on my lan it works great. But now i'm wondering if i can connect to my ltsp sever with an NX client like Nomachine
23:34
<vagrantc>
alkisg: create a symlink for the newest version of any aailable kernel?
23:34
mystic: there's nothing in LTSP that forbids it
23:35
mystic: you'd just configure it like any other NX server...
23:36
<mystic>
vagrantc: this is not working "out of the box"?
23:37
<vagrantc>
mystic: NX has nothing to do with LTSP
23:37gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
23:38willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Computer has gone to sleep.)
23:38
<vagrantc>
mystic: at least, not specifically
23:38
<mystic>
i understand, but like i said i'm new to this :) so i'm just trying some stuff
23:39
<alkisg>
(01:34:29 πμ) vagrantc: alkisg: create a symlink for the newest version of any aailable kernel? => yup
23:39
<vagrantc>
mystic: sure. LTSP is mainly about network booting thin clients
23:40
it's an OS delivery mechanism, not necessarily tied to any specific protocol.
23:40
by default, it supports X over ssh.
23:40
<mystic>
the network booting is just working fine. now i'm wondering is i can connect trough the web, but if i understand correctly i have to install some more services to make this work correctly?
23:41Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
23:41
<vagrantc>
yup
23:41
probably also firewalling/port-forwarding rules
23:41
<alkisg>
!x2g0
23:41
<ltsp>
I do not know about 'x2g0', but I do know about these similar topics: 'x2go'
23:41
<alkisg>
!x2go
23:41
<ltsp>
x2go: x2go is an NX-based suite of applications that allow logging in to a remote X server from any OS. It's much more efficient than VNC over slow network. More info: http://www.x2go.org/
23:42
<mystic>
well i'm trying on my local network for now, so firewalls etc. is not a problem for now
23:42
<vagrantc>
alkisg: so, after all this, you just want a symlink?
23:42
<alkisg>
vagrantc: client side, yup
23:42
<vagrantc>
alkisg: and then more code server-side.
23:42
<alkisg>
Right
23:42
<vagrantc>
alkisg: what do you want the symlink to be named?
23:43
<alkisg>
I'd go with the distro kernel name without the version
23:43
<vagrantc>
alkisg: doesn't it already produce a "vmlinuz" symlink?
23:43
<alkisg>
I want a symlink for *each* kernel variant
23:43
<vagrantc>
got it.
23:43
<alkisg>
So that I can also install e.g. debian's -486
23:44
<vagrantc>
rather than hard-coding the version string in the generated config
23:44
<alkisg>
Yes, so that I can have static pxelinux.cfg files
23:44
<vagrantc>
you hard-code the symlink variannt.
23:44
<alkisg>
Yup
23:44
<vagrantc>
yeah, that's exactly what i do for my manually configured setup. :)
23:46* alkisg needs to wave goodnight for now... had fun, I'll get online in 6 hours or so again :)
23:47alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
23:55mystic has left IRC (mystic!52d9348b@gateway/web/freenode/ip.82.217.52.139, Quit: Page closed)