IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 17 February 2017 (all times are UTC)
| 01:02 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 04:04 | deepbook5broo has joined IRC (deepbook5broo!~gk.1wm.su@2a03:4a80:2:2d4:2d4:e830:6db2:a7d4) | |
| 04:04 | deepbook5broo has left IRC (deepbook5broo!~gk.1wm.su@2a03:4a80:2:2d4:2d4:e830:6db2:a7d4) | |
| 05:18 | Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 245 seconds) | |
| 05:23 | Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack) | |
| 06:40 | url_work has left IRC (url_work!~url_work@220-128-110-82.HINET-IP.hinet.net, Ping timeout: 240 seconds) | |
| 06:43 | url_work has joined IRC (url_work!~url_work@220-128-110-82.HINET-IP.hinet.net) | |
| 07:13 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 07:22 | Statler has joined IRC (Statler!~Georg@p579FE927.dip0.t-ipconnect.de) | |
| 07:34 | mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk) | |
| 07:46 | lunz has joined IRC (lunz!~gwd@190.213.49.89) | |
| 07:47 | lunz has left IRC (lunz!~gwd@190.213.49.89) | |
| 07:59 | lunz has joined IRC (lunz!~gwd@190.213.49.89) | |
| 08:00 | lunz has left IRC (lunz!~gwd@190.213.49.89, Quit: Leaving.) | |
| 09:01 | Statler has left IRC (Statler!~Georg@p579FE927.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 09:41 | Statler has joined IRC (Statler!~Georg@mail.lohn24.de) | |
| 09:58 | markus_e92 has left IRC (markus_e92!~markus_e9@62-46-97-156.adsl.highway.telekom.at, Ping timeout: 255 seconds) | |
| 10:01 | markus_e92 has joined IRC (markus_e92!~markus_e9@80-121-123-63.adsl.highway.telekom.at) | |
| 10:23 | lurky_work has joined IRC (lurky_work!~url_work@220-128-110-82.HINET-IP.hinet.net) | |
| 10:25 | url_work has left IRC (url_work!~url_work@220-128-110-82.HINET-IP.hinet.net, Ping timeout: 260 seconds) | |
| 11:07 | Faith has joined IRC (Faith!~paty_@unaffiliated/faith) | |
| 11:19 | * alkisg just bumped into the unshare command, e.g. sudo unshare -f -p --mount-proc bash -c 'ps aux' | |
| 11:19 | <alkisg> stgraber, ogra_, sbalneav, would it be a good idea to use `unshare` whenever we use `chroot` too? So that the pid and mount namespaces don't mix while installing programs or restarting services etc?
| |
| 11:20 | For example, we could easily do a `killall` while exiting the chroot, to make sure nothing remains and affects the server operation...
| |
| 11:25 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 11:33 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 12:34 | lurky_work has left IRC (lurky_work!~url_work@220-128-110-82.HINET-IP.hinet.net, Read error: Connection reset by peer) | |
| 12:42 | <al-geo> hello my saviors. i cant figure out where to write down on server my networks default gateway for my fat client. for now route writes my ltsp-servers ip
| |
| 12:45 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
| 13:13 | <alkisg> al-geo: what are you using, dnsmasq or isc-dhcp-server?
| |
| 13:13 | And I assume that you don't have an external dhcp server like a router, right?
| |
| 13:14 | kjackal_ has joined IRC (kjackal_!~quassel@2a02:587:3108:3100:48c7:5851:ea72:7e16) | |
| 13:46 | <al-geo> apt-get install ltsp-server-standalone - i install with this. i think its isc-dhcp-server
| |
| 13:47 | and for now i am testing but in future i must use router as dhcp server
| |
| 14:02 | <alkisg> al-geo: then use dnsmasq in proxy-dhcp mode. Problem solved.
| |
| 14:02 | !ltsp-pnp
| |
| 14:02 | <ltsp> ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
| |
| 14:02 | <alkisg> !proxydhcp
| |
| 14:02 | <ltsp> proxydhcp: A proxy DHCP server is defined by the PXE specification as a server which sends auxiliary boot information to clients, like the boot filename, tftp server or rootpath, but leaves the task of IP leasing to the normal DHCP server. More info: https://help.ubuntu.com/community/UbuntuLTSP/ProxyDHCP
| |
| 14:02 | <alkisg> Those are docs about the default proxydhcp mode
| |
| 14:19 | <al-geo> thank you very much
| |
| 14:19 | <sbalneav> Morning all
| |
| 14:19 | TatankaT has joined IRC (TatankaT!~tim@193.190.253.114) | |
| 14:22 | <alkisg> Heya Scotty
| |
| 14:24 | <sbalneav> Hey alkisg
| |
| 14:24 | I don't know much about "unshare", I'll read up on it.
| |
| 14:56 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 15:44 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 15:56 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
| 15:57 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 16:45 | dtcrshr has joined IRC (dtcrshr!~datacrush@2801:88:f7a:100:cd0e:4045:cabe:7462) | |
| 16:45 | dtcrshr has joined IRC (dtcrshr!~datacrush@unaffiliated/datacrusher) | |
| 16:50 | kjackal_ has left IRC (kjackal_!~quassel@2a02:587:3108:3100:48c7:5851:ea72:7e16, Ping timeout: 255 seconds) | |
| 17:10 | kjackal_ has joined IRC (kjackal_!~quassel@2a02:587:3108:3100:48c7:5851:ea72:7e16) | |
| 17:11 | forum has joined IRC (forum!~Icedove@212-183-50-240.adsl.highway.telekom.at) | |
| 17:15 | forum has left IRC (forum!~Icedove@212-183-50-240.adsl.highway.telekom.at, Ping timeout: 240 seconds) | |
| 17:17 | kjackal_ has left IRC (kjackal_!~quassel@2a02:587:3108:3100:48c7:5851:ea72:7e16, Ping timeout: 255 seconds) | |
| 19:14 | <alkisg> vagrantc: heya
| |
| 19:14 | Got time to talk about the daily builds?
| |
| 19:20 | One method that I can think of, is to name the patches with some special name, e.g. -upstreamed.patch, and then have autogen.sh or debian/control delete them before build, when the build environment has some launchpad-specific variable
| |
| 19:21 | If that will work for you, I can search the specific env var that we can check
| |
| 19:23 | <vagrantc> alkisg: anything that actually requires changes in the build system don't sound too pleasant
| |
| 19:23 | <alkisg> vagrantc: how so? we have conditionals for "if building on ubuntu", why daily builds are an issue?
| |
| 19:23 | forum has joined IRC (forum!~Icedove@212-183-50-240.adsl.highway.telekom.at) | |
| 19:23 | <vagrantc> alkisg: applying and unapplying patches manually is a mess
| |
| 19:24 | <alkisg> I didn't propose that
| |
| 19:24 | <vagrantc> alkisg: there's no way to run an arbitrary command in the recipe to strip the patches out of the series before they're applied?
| |
| 19:24 | <alkisg> I proposed deleting the files that we don't want, before the debuild process
| |
| 19:25 | <vagrantc> alkisg: you'll also have to patch debian/patches, and it won't work correctly if the package was built from .dsc, in fact, it would likely cause a FTBFS
| |
| 19:25 | <alkisg> Recipes can't run commands afaik, but I can put a script somewhere else and merge it, and still, some existing code will need to call it
| |
| 19:26 | Building from .dsc will work if one patches debian/patches from a recipe but not from a script's code?
| |
| 19:26 | <vagrantc> so, my other proposal is to have a the branch/repository you merge from strip the things you don't want
| |
| 19:27 | <alkisg> Let's split this into 2 tasks, I think I'll understand easier
| |
| 19:27 | <vagrantc> alkisg: if you simply patch the files out of debian/patches/series in the launchpad build, it should generate a .dsc that will build the same.
| |
| 19:27 | forum has left IRC (forum!~Icedove@212-183-50-240.adsl.highway.telekom.at, Ping timeout: 240 seconds) | |
| 19:28 | <vagrantc> alkisg: but if you patch the files after it's been unpacked by dpkg-source or quilt or whatever, then there will be applied patches that are ignored for the build
| |
| 19:28 | alkisg: presuming launchpad doesn't automatically apply the patches as part of the build outside of dpkg-buildpackage or whatever it calls
| |
| 19:29 | it's essentially a state caching problem
| |
| 19:30 | depending on how you build the debian package, the patches may be applied or unapplied, and they might get applied at build time
| |
| 19:30 | (if not already applieD)
| |
| 19:30 | so, if we can implement a mechanism to ensure they're unapplied, strip out the patches we don't want, and then run the build, it should work.
| |
| 19:31 | you can do that in a separate git repository or branch, but then you need to handle rebasing it all the time... unless you can generate a throwaway branch.
| |
| 19:32 | <alkisg> I'm lost. I think this should be simpler than that. Let's have a look at the launchpad build process log: https://launchpadlibrarian.net/306804382/buildlog.txt.gz
| |
| 19:33 | Committed revision 1592. Applying quilt patches
| |
| 19:34 | Are you saying that the build process applies the patches without even getting yet to debian/control?
| |
| 19:34 | <vagrantc> i'm not sure why you're talking about debian/control... that doesn't have to do with debian/patches/
| |
| 19:35 | that log is so full of meaningless noise... gah.
| |
| 19:35 | <alkisg> What part is applying the patches, isn't it some debhelper component?
| |
| 19:35 | Sorry, debian/rules, I meant
| |
| 19:36 | <vagrantc> alkisg: it looks to me like launchpad is doing it.
| |
| 19:37 | alkisg: it looks like launchpad is merging the contents of the debian dir into the top-level source dir, and then applying quilt patches...
| |
| 19:38 | alkisg: so, in that sense, it's emulating what "dpkg-source -x" would do...
| |
| 19:38 | alkisg: i don't think it will be possible to fix in the packaging if that's true
| |
| 19:38 | <alkisg> I was thinking that patches would be applied when building, not when extracting the source...
| |
| 19:39 | <vagrantc> alkisg: it's typically both, in modern packaging
| |
| 19:39 | alkisg: if they're unapplied, they get applied when building the package, but they're typically applied when the source tree is unpacked as well
| |
| 19:40 | at least with debian/source/format: 3.0 (quilt)
| |
| 19:40 | old-school systems applied them from debian/rules, but it's really error prone
| |
| 19:40 | <alkisg> OK, so, will any of the ideas that you said work with launchpad?
| |
| 19:41 | If it chokes while still extracting/merging the code... it's too early, we can't run anything to omit patches...
| |
| 19:41 | <vagrantc> alkisg: only way i can see is to merge from a branch that has the unwanted patches in debian/patches/series edited/comment out
| |
| 19:42 | alkisg: which, if we rename the patches systematically, like dropping them all in debian/patches/upstream/* that part should be easy and automatable
| |
| 19:42 | but then you need a branch that's forcibly rebased all the time
| |
| 19:43 | or something like that
| |
| 19:43 | <alkisg> Which is exactly what I'm trying to avoid...
| |
| 19:44 | I would need to monitor when you push something to your branch, and then make another just to avoid breaking the daily builds
| |
| 19:44 | <vagrantc> well, i think it's automatable.
| |
| 19:44 | <alkisg> To have some cron job somewhere check all that, and update some branch on launchpad?
| |
| 19:44 | Maybe it can be added as a script to your workflow?
| |
| 19:45 | Like, when pushing, run that script too?
| |
| 19:45 | <vagrantc> i guess i could even set up a hook in the git commit stuff to handle that
| |
| 19:45 | server-side...
| |
| 19:45 | what other import methods does launchpad support?
| |
| 19:45 | e.g. tarball?
| |
| 19:46 | Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving) | |
| 19:46 | <alkisg> I don't think so, I've seen git, bzr, and cvs...
| |
| 19:46 | Let me check again
| |
| 19:46 | https://code.launchpad.net/+code-imports/+new
| |
| 19:47 | <vagrantc> creating a single-commit git branch that's always overwritten with the latest upstream patches removed shouldn't be too hard.
| |
| 19:47 | <alkisg> bzr, git, subversion, cvs
| |
| 19:47 | <vagrantc> and really, should be fine to leave the patches in debian/patches ... just needs to be removed from debian/patches/series
| |
| 19:48 | while i say... not too hard... i probably won't have time to work on it till april
| |
| 19:48 | <alkisg> Hrm. I wonder then if I could merge a single file that would override that
| |
| 19:48 | Ouch, without testing trunk until april?
| |
| 19:49 | <vagrantc> we've gone how many months without it working?
| |
| 19:49 | alkisg: i guess you could merge without any patches fairly simply that way.
| |
| 19:50 | <alkisg> I haven't tested ltsp in all those months
| |
| 19:50 | ltsp-trunk, that is
| |
| 19:51 | ltsp - 5.5.7~r2732+p1249+201603261524~ubuntu16.04.1 (Newer version available) (changes file) no signer 2016-03-27 Published Xenial Misc
| |
| 19:51 | ...so, it's been about a year without testing ltsp-trunk in real world
| |
| 19:52 | <vagrantc> rough times
| |
| 19:55 | <alkisg> (09:54:48 μμ) dobey: alkisg: yes, so there is a different debian/ tree for experimental than for stable. you can't avoid that
| |
| 19:55 | I think that's what I'm looking for, a debian/ tree that corresponds to experimental...
| |
| 19:55 | <vagrantc> as in "debian experimental" ?
| |
| 19:56 | as that may still contain additional patches...
| |
| 19:56 | <alkisg> Whatever, as long as it can build against upstream code
| |
| 19:56 | <vagrantc> what you need is a separate branch for that purpose.
| |
| 19:57 | as there's no guarantee that debian/experimental will build with upstream either
| |
| 19:57 | <alkisg> So we're back to having to maintain a different ltsp for ubuntu...
| |
| 19:57 | *packaging
| |
| 19:57 | well actuall for upstream...
| |
| 19:57 | <vagrantc> right... technically, we've always been there, just sometimes it works by pure luck
| |
| 19:59 | right... ubuntu's been following debian's ltsp packaging just fine
| |
| 19:59 | <alkisg> Oh well... would you mind if I pushed a debian/ dir upstream in ltsp?
| |
| 19:59 | <vagrantc> ever since they've been synced.
| |
| 19:59 | <alkisg> I really don't like to maintain forks
| |
| 19:59 | <vagrantc> alkisg: that would cause conflicts on every merge
| |
| 19:59 | alkisg: please not that :)
| |
| 20:00 | <alkisg> It would be the upstream debian dir, and you can then keep your own in debian...
| |
| 20:00 | :D
| |
| 20:00 | <vagrantc> i would fork.
| |
| 20:00 | right now i have the packaging working quite nicely for debian
| |
| 20:01 | <alkisg> But we can't test ltsp for a year now
| |
| 20:01 | With a debian/ dir upstream like it is in epoptes, we would be able to
| |
| 20:01 | <vagrantc> we fixed that in epoptes.
| |
| 20:02 | <alkisg> And then you can keep snapshots and local modifications for every debian release
| |
| 20:02 | And the ubuntu maintainer can keep snapshots for ubuntu releases
| |
| 20:02 | <vagrantc> seriously, it's going to create merge nightmares.
| |
| 20:02 | <alkisg> But upstream would always build
| |
| 20:02 | <vagrantc> it's not the way to do it.
| |
| 20:03 | <alkisg> Epoptes worked fine for years. LTSP can't have daily build for a year. Which one of those 2 works? :
| |
| 20:03 | :(
| |
| 20:03 | <vagrantc> i had to fork epoptes a few times, and then spend a huge amount of time to re-merge them.
| |
| 20:04 | <alkisg> Why? Aren't debian releases essentially snapshots of the debian/ dir?
| |
| 20:04 | And the source dir too?
| |
| 20:05 | <vagrantc> alkisg: because the source dir got out of sync with the debian dir
| |
| 20:05 | <alkisg> That should never happen upstream
| |
| 20:05 | I can understand this work flow: "some debian-based distro wants to release. OK, clone the whole tree, with src/ and debian/ in it, and it should work fine at that point; otherwise it's an error",
| |
| 20:06 | <vagrantc> it happened every time there was a commit upstream that didn't get updated in the debian dir
| |
| 20:06 | <alkisg> "then, if new patches need to be backported, they would be backported to that fork"
| |
| 20:06 | I never do such commits
| |
| 20:06 | I would consider them an error that should be fixed immediately
| |
| 20:07 | <vagrantc> sure, and that works as long as upstream doesn't break the debian dir
| |
| 20:07 | <alkisg> Which is what we do when we are both upstream and debian maintainers
| |
| 20:07 | * vagrantc sighs | |
| 20:07 | <alkisg> I wouldn't mind forking the debian/ dir for someone else's project; I mind having to keep a fork for my own projets
| |
| 20:08 | And more importantly, a fork of an older version!
| |
| 20:10 | <vagrantc> just keep an upstream branch for packaging, and there's no issue...
| |
| 20:10 | <alkisg> Sure. I'd love to have an upstream branch for packaging, one that would be forked whenver debian or ubuntu or any other debian-based distro wants to release ltsp
| |
| 20:11 | Can we have that, with both of us as committers?
| |
| 20:11 | <vagrantc> a split branch? bah.
| |
| 20:11 | <alkisg> What do you mean "split branch"?
| |
| 20:12 | <vagrantc> basically, as long as there's an upstream branch without a debian dir, it works well for me. if there's a separate branch with debian packaging with just the debian dir, or with upstream+debian dir, that's fine.
| |
| 20:13 | <alkisg> So we can settle with a branch in git format in launchpad, which would contain the latest version of the debian/ dir?
| |
| 20:13 | <vagrantc> i may not use the "upstream" packaging dirs at all in debian
| |
| 20:14 | <alkisg> Then I wouldn't use them either, because ubuntu would get the debian/ folder from debian, not from "upstream"
| |
| 20:15 | I can understand that you don't want to maintain a debian/ dir that builds against ltsp-trunk,
| |
| 20:15 | but can't we find some way that I can maintain that, without having to fork older versions each time?
| |
| 20:15 | <vagrantc> what do you mean by "fork older versions" ?
| |
| 20:15 | <alkisg> Something like me maintaining debian-experimental, and you maintaining stab/stable, testing etc
| |
| 20:16 | When I would want to test debian-experimental, I would have to fork your last tree from debian-testing or debian-stable, and remove the patches that were applied upstream
| |
| 20:16 | The opposite of what feels normal to me
| |
| 20:16 | <vagrantc> alkisg: there's no difference to supporting debian stable, debian unstable/testing and debian experimental ... they all require manual care and feeding
| |
| 20:17 | <alkisg> For me, the latest upstream code and latest packaging code should work fine in the latest debian and ubuntu versions
| |
| 20:17 | <vagrantc> yeah, sure, but what you really want is debian-based-distro-upstream
| |
| 20:17 | <alkisg> I can't have that now
| |
| 20:18 | <vagrantc> alkisg: i think what you want is for me to maintain a packaging branch for upstream :P
| |
| 20:18 | <alkisg> I don't mind if I maintain debian in ltsp
| |
| 20:18 | I do mind if someone else maintains it, and I need to fork all the time
| |
| 20:18 | So yes, please maintain a packaging branch for upstream :)
| |
| 20:19 | <vagrantc> i still think it's possible to do in a mostly automated way
| |
| 20:19 | though there will still be occasions where packaging needs to change in more ways that simply excluding upstream patches
| |
| 20:20 | <alkisg> It's like flashplugin-installer
| |
| 20:20 | The maintainer needs to have a cron job to check for new versions, and download them from the internet and build them
| |
| 20:21 | <vagrantc> at any rate, i think we'll be able to come up with something, but i need to put some focus on other things today
| |
| 20:21 | <alkisg> It's ok to do it if you're not adobe. It's a shame to do it if you are upstream...
| |
| 20:22 | vagrantc: thanks for your thoughts. Sorry if I was a bit too anxious about it. :
| |
| 20:22 | <vagrantc> most upstreams just ship a Makefile or something
| |
| 20:22 | and then let the distributions do their thing
| |
| 20:23 | <alkisg> Imagine having to sync your debian/ dir with the opensuse packaging all the time, while you're both upstream and debian maintainer
| |
| 20:23 | <vagrantc> if the Makefile (or other build system) is done right, then the packaging is trivial
| |
| 20:23 | <alkisg> That's how bad it sounds to me, that I want to care for both src/ and debian/, but I can't, I need a fork
| |
| 20:25 | <vagrantc> alkisg: in general, i see what you're saying ... the main issue is when a debian freeze hits
| |
| 20:25 | alkisg: then it becomes more than i want to deal with to have to maintain upstream packaging separately
| |
| 20:25 | <alkisg> Freezes happen all the time. For debian, for ubuntu, and every week or month that I release to the ppa for 1000+ schools
| |
| 20:25 | <vagrantc> then i commit patches upstream, and include them in the packaging patches
| |
| 20:26 | <alkisg> That's why there should be a packaging-trunk version, not a packaging-for-a-specific-distro version, and -trunk would fork from it!
| |
| 20:26 | Here's an idea:
| |
| 20:27 | If I implement that hook for your workflow, would you be able to test it before april?
| |
| 20:27 | (the one that would push 2 branches, one for debian and one without the upstream patches)
| |
| 20:29 | <vagrantc> alkisg: i'm a bit nervous to send you off on a project like that
| |
| 20:30 | <alkisg> OK. Let's close it for now then, I'll do a fork once; but please think about it for the future, there has to be some way that I can help you maintain a packaging-trunk
| |
| 20:31 | <vagrantc> yeah, i'll think about it
| |
| 20:32 | <alkisg> ty! :
| |
| 20:33 | <vagrantc> got a couple conference talks in the coming two weeks, middle of debian freeze, so my focus isn't so much on upstream at the moment
| |
| 20:33 | which reminds me of that stupid nbd bug where it strips the leading /
| |
| 20:34 | gah. really want to get that fixed for stretch
| |
| 20:35 | kjackal_ has joined IRC (kjackal_!~quassel@2a02:587:3108:3100:48c7:5851:ea72:7e16) | |
| 20:42 | <alkisg> vagrantc: does it also break with ROOTPATH=/opt/ltsp/i386 or with nbdroot=/opt/ltsp/i386, or only with nbdroot=192.168.67.1/opt/ltsp/i386 ?
| |
| 20:43 | <vagrantc> alkisg: it strips the first /
| |
| 20:43 | <alkisg> Because in the first 2 cases, it's clearly a bug
| |
| 20:43 | <vagrantc> and a bug has been filed...
| |
| 20:43 | <alkisg> In the last case, / is a separator
| |
| 20:43 | In the first 2 cases, it's not, so it needs to be included in the requested export name
| |
| 20:44 | <vagrantc> well, it's nbdroot=192.168.67.1:/opt/ltsp/i386
| |
| 20:44 | <alkisg> But LTSP users don't use that normally
| |
| 20:44 | While they do use the ROOTPATH syntax by default
| |
| 20:45 | So, is the default installation broken too? Or only user-modified ones?
| |
| 20:45 | <vagrantc> default is broken
| |
| 20:45 | <alkisg> That is clearly a bug then, as ROOTPATH doesn't contain a port, it doesn't need a separator there
| |
| 20:46 | <vagrantc> it's a shell globbing issue
| |
| 20:46 | or, maybe not globbing specifically
| |
| 20:46 | <alkisg> In theory, can one define ROOTPATH=192.168.67.1:/opt/ltsp/i386, either in nfs or in nbd?
| |
| 20:46 | <vagrantc> but all the various ${VAR%%"value"} style variable
| |
| 20:47 | <alkisg> Or that goes in ROOTSERVER/next-server?
| |
| 20:47 | <vagrantc> i think the ROOTPATH is used if the commandline variables aren't passed
| |
| 20:47 | it just sets the variable and it's the same codepath otherwise
| |
| 20:47 | <alkisg> No, I mean the definition of ROOTPATH as used by nfs and DHCP, I'm not asking about how wouter implemented its parsing
| |
| 20:48 | Because if the definition of ROOTPATH can't contain a server, then we can easily send a patch for that to wouter
| |
| 20:48 | <vagrantc> can't contain a port?
| |
| 20:49 | but then ROOTPATH=192.168.67.1:/opt/ltsp/1234 would also break
| |
| 20:49 | as the / is being used as a separator to define the port
| |
| 20:49 | <alkisg> Is this a valid ROOTPATH for NFS?
| |
| 20:49 | <vagrantc> no
| |
| 20:49 | er, yes
| |
| 20:49 | <alkisg> I thought that the server was defined in next-server...
| |
| 20:49 | <vagrantc> but the /1234 is a path, not a port
| |
| 20:49 | it's also valid there
| |
| 20:50 | in fact, i think it overrides next-server
| |
| 20:50 | at least, in all implementations i've seen for many many years
| |
| 20:50 | <alkisg> OK, if ROOTPATH is allowed to contain a server, yeah the default ltsp installation has the same issue...
| |
| 20:50 | <vagrantc> really, it's a just a bug that was introduced when wouter added a configurable port, using the "/" as a separator
| |
| 20:51 | and then it was "fixed" by stripping the leading slash...
| |
| 20:51 | well, maybe that wasn't the intention
| |
| 20:52 | https://bugs.debian.org/846998
| |
| 20:52 | which refers to the bug that "fixed" the previous problem
| |
| 20:52 | <alkisg> "- We change the definition of the ip:port/exportname syntax so that the / is only stripped if an IP address and/or a port was specified, too; i.e., if you don't specify anything before a /, then it is assumed that the / is part of the export name, rather than it being a separator. Not sure whether that fixes the issue for LTSP (in fact, not even sure whether it's valid currently to specify only the exportname, but ignoring that), but if so,
| |
| 20:52 | That would make the default ltsp installation work
| |
| 20:52 | But anyone that wanted to specify a server as well, would have to use 2 slashes
| |
| 20:53 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
| 20:57 | <vagrantc> case nbdroot in
| |
| 20:57 | ^/*|*:/*) nbdpath= ...
| |
| 20:57 | i think that should solve all the use-cases i can think of
| |
| 20:57 | syrius has joined IRC (syrius!syrius@thunder.stormtek.net) | |
| 20:59 | <vagrantc> i need to bump that on my priority list
| |
| 21:02 | * vagrantc waves and wanders off to other things | |
| 21:03 | <syrius> having a difficult time finding straight-forward information for using NX through LTSP instead of X11. anyone had success? i'm on opensuse 13.2 atm
| |
| 21:11 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 255 seconds) | |
| 21:14 | kjackal_ has left IRC (kjackal_!~quassel@2a02:587:3108:3100:48c7:5851:ea72:7e16, Ping timeout: 255 seconds) | |
| 21:27 | kjackal_ has joined IRC (kjackal_!~quassel@2a02:587:3108:3100:48c7:5851:ea72:7e16) | |
| 21:41 | <||cw> syrius: should be kinda similar to using rdp or vnc. you're basically using very little of ltsp that way
| |
| 21:42 | <syrius> sure.. at this point i'm looking to improve performance with thin clients
| |
| 21:42 | <||cw> what are you client specs?
| |
| 21:43 | if faster than P4's you might look into fat client or ltsp-pnp
| |
| 21:43 | <syrius> yeah, newer than that
| |
| 21:43 | haven't heard of ltsp-pnp
| |
| 21:43 | <||cw> which is far better supported on ubuntu, not sure any real suse effort has been done
| |
| 21:43 | <syrius> hmm
| |
| 21:43 | <||cw> !ltsp-pnp
| |
| 21:43 | <ltsp> ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
| |
| 21:44 | <syrius> i'll take a look at that
| |
| 21:44 | another issue could be the network speed, but we really only have a couple simultaneous clients
| |
| 21:44 | the ltsp nic is separate and it's just a 100mbit
| |
| 21:44 | <||cw> basically makes everything run local, but with a remote disk, so still diskless and PXE booted
| |
| 21:45 | <syrius> oh interesting
| |
| 21:45 | <||cw> far less server resources needed, but you can't disconnect and resume a session like you can with NX
| |
| 21:46 | <syrius> yeah that's not required functionality
| |
| 21:57 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 22:18 | kjackal_ has left IRC (kjackal_!~quassel@2a02:587:3108:3100:48c7:5851:ea72:7e16, Ping timeout: 255 seconds) | |
| 22:44 | <syrius> ||cw: sorry i was debugging the nx stuff.. how is ltsp-pnp different from a thin client?
| |
| 22:44 | i mean i see the description says it's not chrooted
| |
| 22:44 | but i don't see our current implementation doing that for the thin clients
| |
| 22:59 | <||cw> pnp uses the server's root to build the image, the based on client specs or your lts.conf overrides chooses thin or fat client mode.
| |
| 23:00 | Statler has left IRC (Statler!~Georg@mail.lohn24.de, Remote host closed the connection) | |
| 23:36 | <syrius> gotcha
| |