IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 13 August 2018 (all times are UTC)
| 00:06 | Helenah has left IRC (Helenah!d49f2d5f@gateway/web/freenode/ip.212.159.45.95, Ping timeout: 252 seconds) | |
| 00:31 | GodFather has joined IRC (GodFather!~rcc@24.sub-97-34-3.myvzw.com) | |
| 00:41 | GodFather has left IRC (GodFather!~rcc@24.sub-97-34-3.myvzw.com, Ping timeout: 240 seconds) | |
| 00:54 | GodFather has joined IRC (GodFather!~rcc@2600:1015:b114:c8c8:9dbf:a633:8259:aa3b) | |
| 01:43 | GodFather has left IRC (GodFather!~rcc@2600:1015:b114:c8c8:9dbf:a633:8259:aa3b, Ping timeout: 240 seconds) | |
| 02:02 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 02:20 | lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-236.isotelco.net.br) | |
| 02:23 | lucas__ has joined IRC (lucas__!~lucascast@138.68.106.79) | |
| 02:26 | lucascastro has left IRC (lucascastro!~lucascast@177-185-139-236.isotelco.net.br, Ping timeout: 248 seconds) | |
| 02:51 | bcg has joined IRC (bcg!~b@2001:2003:54f9:42f6::1) | |
| 02:55 | bcg has left IRC (bcg!~b@2001:2003:54f9:42f6::1, Ping timeout: 240 seconds) | |
| 03:04 | ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Ping timeout: 240 seconds) | |
| 04:15 | lucas__ has left IRC (lucas__!~lucascast@138.68.106.79, Remote host closed the connection) | |
| 04:22 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 04:53 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 05:49 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 08:10 | bcg has joined IRC (bcg!~b@2001:2003:54f9:42f6::1) | |
| 08:33 | alkisg has joined IRC (alkisg!3e01e013@ubuntu/member/alkisg) | |
| 08:33 | <alkisg> vagrantc: pull request filed, https://github.com/Epoptes/epoptes/pull/64
| |
| 08:34 | If you don't have the time for it, I can just ping fotis to approve instead,
| |
| 08:34 | but there's no hurry involved
| |
| 08:35 | He insisted that we stick to the old versioning btw, so I dumped the year.month one
| |
| 08:40 | <vagrantc> :9
| |
| 08:41 | er, :(
| |
| 08:41 | it all looks fine, although it would of course depend on merging the relevent upstream version before updating most of the packaging
| |
| 08:50 | ogra has joined IRC (ogra!~ogra_@ubuntu/member/ogra) | |
| 09:02 | <alkisg> vagrantc: ah, i was wondering about that, when you update the upstream version
| |
| 09:03 | vagrantc: do you want me to merge it myself? Or will you do it? Or do you want to comment in the pull request?
| |
| 09:04 | <vagrantc> alkisg: basically i only merge it when it's relevent ... typically only new upstream versions, but in this case, since it's in-development, you might want to merge sooner
| |
| 09:05 | <alkisg> vagrantc: yeah, I started the packaging work around 3 months before the upstream release
| |
| 09:05 | <vagrantc> alkisg: i'll try to comment on the pull request
| |
| 09:06 | <alkisg> OK; my basic question is if you'll merge, or if i should merge before the packaging (i.e. redo the whole branch), or if I should merge after the packaging (i.e. as it is now)
| |
| 09:07 | (for the pull request comment, that is)
| |
| 09:12 | <vagrantc> alkisg: merge 1.0.0 (or current master), then apply the relevent packaging updates
| |
| 09:12 | alkisg: e.g. redo the whole branch :/
| |
| 09:12 | you probably can just cherry-pick it all
| |
| 09:12 | since there won't be any conflicts
| |
| 09:12 | alkisg: i was curious about dynamically editing the __version__ string
| |
| 09:15 | * vagrantc can't seem to comment on individual patches | |
| 09:19 | <vagrantc> hrm. i seem to have tried to make a comment on a specific patch, but it doesn't look like it gave any context
| |
| 09:21 | i can't even reply to my comment
| |
| 09:21 | * vagrantc urgs | |
| 09:28 | <alkisg> [12:12] <vagrantc> alkisg: i was curious about dynamically editing the __version__ string ==> meaning? that it's a bad thing to do?
| |
| 09:28 | You'd prefer it this was in the "makefile" instead of in debian/rules?
| |
| 09:28 | *if
| |
| 09:29 | <vagrantc> alkisg: i guess i don't have a checked out branch to compare to
| |
| 09:29 | <alkisg> vagrantc: does the online comparison from the pull requst github tab help?
| |
| 09:29 | <vagrantc> and don't the client and server need to have matching version? that patch only patches the server
| |
| 09:29 | <alkisg> https://github.com/Epoptes/epoptes/pull/64/files
| |
| 09:30 | Both the client and the server get the version at build time
| |
| 09:30 | sed "s/\(__version__\).*/\1 = '$(DEBVERS)'/" -i "$(CURDIR)"/debian/epoptes/usr/lib/python*/dist-packages/epoptes/__init__.py
| |
| 09:30 | sed "s/\(VERSION=\).*/\1'$(DEBVERS)'/" -i "$(CURDIR)"/debian/epoptes-client/usr/sbin/epoptes-client
| |
| 09:31 | <vagrantc> at least from 462094d47f5376e3295da3a0c41e096df3b58ce6 it just had it hard-coded with new upstream release
| |
| 09:32 | <alkisg> vagrantc: so in general how are you working with packaging, you have a seperate "development" tree that you work on, then when an upstream release happens you merge it to debian/master, and then you merge your development branch on top of it?
| |
| 09:32 | <vagrantc> i'm guessing you'll want only the upstream version though, not the debian revision, otherwise you can have a mix of ubuntu and debian clients, for example
| |
| 09:32 | <alkisg> Or you just don't do any packaging development when there's no new upstream version? (which wouldn't match the workflow here...)
| |
| 09:32 | <vagrantc> alkisg: generally the last, i typically don't change things without a new upstream version
| |
| 09:33 | <alkisg> I think debversion is fine there, no need for 'debupstream'
| |
| 09:33 | vagrantc: ah, that doesn't match epoptes development though
| |
| 09:33 | <vagrantc> or any changes would need to be relevent for both new and old branch
| |
| 09:33 | <alkisg> So we need to follow some other workflow
| |
| 09:33 | I want to be able to work on packaging while I'm concurrently working on code as well
| |
| 09:34 | Because otherwise I wouldn't e.g. be able to develop support for systemd for both the code and the packaging
| |
| 09:34 | <vagrantc> in those cases, i would just merge the upstream development branch and make the required changes
| |
| 09:34 | <alkisg> Merge it how many times? E.g. I've been working 3 months on it
| |
| 09:35 | So I'd have to merge it like 10 times or so...
| |
| 09:35 | E.g. updated to python3 => merge, to gtk3 => merge, to python3-twisted => merge, to systemd => merge
| |
| 09:35 | <vagrantc> sounds fine
| |
| 09:36 | unless you're averse to merging...
| |
| 09:36 | <alkisg> Why is "merging when done" bad?
| |
| 09:36 | If there's a reason for it, sure
| |
| 09:36 | But if there's no reason to merge sooner, and it only has downsides, why do it that way...
| |
| 09:37 | <vagrantc> alkisg: it leaves the branch in an unusable state
| |
| 09:37 | <alkisg> E.g. suppose that now that both branches are ready, we merge the code on top of the packaging
| |
| 09:37 | No need to merge 10 times that way; is there something wrong with it?
| |
| 09:37 | <vagrantc> alkisg: if you merge the python3 changes before the upstream code is merged, then you have a package that won't work
| |
| 09:37 | <alkisg> Right, it's the development version that only works with the upstream development branch
| |
| 09:38 | It's not a released version
| |
| 09:38 | Noone would want to run that version anyway
| |
| 09:38 | It would be a snapshot with e.g. python3 and gtk2, with a lot of broken things etc
| |
| 09:39 | For released versions, don't we do debian-jessie etc branches anyway?
| |
| 09:39 | <vagrantc> there are tools in debian which checkout the git repo and expect a buildable branch, for example
| |
| 09:39 | presuming the Vcs-* headers are set correctly
| |
| 09:40 | <alkisg> Tools for versions that aren't even in experimental? OK, those should merge the upstream dev branch with the debian dev dir; like I do with the launchpad recipes
| |
| 09:41 | https://code.launchpad.net/~alkisg/+recipe/gsoc2018-epoptes
| |
| 09:41 | # git-build-recipe format 0.4 deb-version {debupstream}~t{revtime} lp:~alkisg/epoptes/+git/gsoc2018 master nest-part debian lp:~alkisg/epoptes/+git/gsoc2018 debian debian gsoc2018-debian
| |
| 09:41 | <vagrantc> i don't see how each tool in debian can support an arbitrary number of upstream projects with any hope of it being correct
| |
| 09:41 | <alkisg> So debian designed a workflow with 2 separate branches but can only work with 1 branch?
| |
| 09:41 | <vagrantc> but it's pretty straightforward to have it do "git checkout -b ..."
| |
| 09:41 | <alkisg> Isn't that silly?
| |
| 09:42 | That is the same as I was suggesting initially, to only use one branch for both code and packaging...
| |
| 09:42 | <vagrantc> debian evolved more workflows than you can probably imagine over the years...
| |
| 09:42 | <alkisg> Could you name such a tool so that I can look into it?
| |
| 09:42 | <vagrantc> debcheckout
| |
| 09:43 | <alkisg> Is it used on epoptes?
| |
| 09:43 | <vagrantc> it's intended to be used with any package with proper Vcs-* headers
| |
| 09:43 | <alkisg> But if we have a real use case, and we break it because there's somewhere a tool that we don't use...?!! does that make sense?
| |
| 09:44 | <vagrantc> it's not a tool for us to use, it's a tool for other members of the debian community to use so as to not have to learn every single workflow for each and every of 25-30k source packages
| |
| 09:44 | <alkisg> That's what I'm asking, does ANYONE use it with epoptes?
| |
| 09:44 | If not, why would we care about it?
| |
| 09:45 | <vagrantc> it's the wrong question
| |
| 09:45 | <alkisg> Maybe the tool is wrong
| |
| 09:45 | I find it completely sane that tools can do what the launchpad recipes do
| |
| 09:45 | * vagrantc sighs | |
| 09:45 | <alkisg> So if there's some tool that just doesn't, and we don't use it, and it might even do what we're asking in a year or two...
| |
| 09:46 | why would we ever care that this tool now doesn't do what we'd want, if noone uses it with epoptes anyway?
| |
| 09:46 | <vagrantc> it's also the debian policy
| |
| 09:47 | <alkisg> I'm confused. The debian packaging guidelines recommend that we keep the packaging on a separate branch from upstream, and the policy says to mix them?
| |
| 09:47 | OK let's change the question
| |
| 09:48 | <vagrantc> alkisg: the point is providing a standard for someone not already familiar with epoptes to, say, work on fixing a bug in the package, and simply download the correct starting point to test a fix
| |
| 09:48 | <alkisg> So, what if we have development branches for ourselves, that we don't want the vcs tools to keep an eye on
| |
| 09:48 | <vagrantc> alkisg: then don't reference your development branches in the Vcs-* headers
| |
| 09:48 | <alkisg> Great. Maybe that's the solution then.
| |
| 09:49 | So, maybe we can point them to specific versions there where we know that they build and all
| |
| 09:50 | <vagrantc> and then you get into the mess of merging the development branches cleanly... sounds like a lot more work
| |
| 09:50 | and also people checkin it out might have to re-patch your work in progress ... but whatever
| |
| 09:50 | <alkisg> Isn't that what I'm doing right now, merging gsoc-debian into debian?
| |
| 09:51 | <vagrantc> sure
| |
| 09:51 | <alkisg> So, same thing, I'd just be merging debian-dev into debian-for-vcs
| |
| 09:51 | <vagrantc> most of the time, the packaging changes are relatively small and infrequent ... for major rewrites, a different workflow may make more sense, sure.
| |
| 09:52 | <alkisg> I think the problem is that a packager is also an upstream developer that needs frequent changes
| |
| 09:52 | <vagrantc> that's also an issue of great concern to you :P
| |
| 09:52 | <alkisg> Maybe the recommended workflow is only for packagers that work for a couple of days after an upstream release, not for people working upstream too
| |
| 09:53 | The debian branch history would be a mess if I had to merge the source code each week of development even when the development branches weren't even ready
| |
| 09:53 | I'm not sure if it would even be syncable with the resulting upstream code after the PR merges
| |
| 09:54 | I had to change my recipe to point to the feature-branch that I was working on, each week
| |
| 09:54 | <vagrantc> well, if the merges are only one-way, and you're merging only things that were merged upstream already, it *should* consistantly merge correctly
| |
| 09:54 | <alkisg> So if I had to merge that feature-branch periodically into debian, and then another feature-branch was merged first upstream... it would be chaotic
| |
| 09:55 | <vagrantc> yes
| |
| 09:55 | at times selecting rebasing or cherry-picking would make more sense than merging
| |
| 09:56 | <alkisg> I really can't understand why. "merge when ready" sounds so much saner to me.
| |
| 09:56 | <vagrantc> i don't know what you mean
| |
| 09:57 | <alkisg> I work on feature1-branch + the debian packaging. Then, before it's ready, I switch to working on feature2-branch + the debian packaging, which is finished and merged upstream before feature1.
| |
| 09:57 | <vagrantc> i also tend to find upstreams that maintain a debian dir often don't maintain a debian dir that would be acceptible for debian
| |
| 09:57 | <alkisg> Then I merge the feature1-branch, then I merge the debian packaging.
| |
| 09:57 | <vagrantc> which makes merging the branches a pain to work with
| |
| 09:58 | <alkisg> This is a very nice git history. But if I do it like you're recommending, it would be chaotic, I might even have to undo all the feature1 commits if it ended up a bad feature
| |
| 09:58 | <vagrantc> you'll end up with a chaotic history either way
| |
| 09:58 | debian/changelog, for example, will always create merge conflicts
| |
| 09:58 | <alkisg> I don't see why. Because now I merge when they're ready, so I know I'll use them.
| |
| 09:59 | vagrantc: I'm not talking about keeping debian upstream
| |
| 09:59 | <vagrantc> if your feature branches are always linearly developed one after the other
| |
| 09:59 | <alkisg> I've already agreed to do it "your way" there; this is only about when to merge
| |
| 10:00 | You're recommending that I merge a development branch to the debian dir even before it's ready
| |
| 10:00 | I think that's bad, e.g. I might even need to throw it away
| |
| 10:01 | I'd like a workflow that allows me to merge to the main branches (master and debian/master) only branches that are ready for merging, not in progress ones
| |
| 10:01 | <vagrantc> do your development however you want, but please keep the "debian" branch in a consistant state with the upstream code it has merged.
| |
| 10:02 | <alkisg> Hmm how about this:
| |
| 10:02 | I work on master and on debian-development. When I'm done, I first merge master and then debian-development.
| |
| 10:03 | That means that you can just pull master now in debian/, and then accept the PR, which only touches debian/, so it should be mergeable
| |
| 10:03 | I.e. I don't need to do anything in the PR, "you" just need to sync with master before approving it
| |
| 10:03 | <vagrantc> might work.
| |
| 10:04 | i've just had enough of these go horribly wrong in the past and become a nightmare to detangle
| |
| 10:05 | i fear we've spent more time debating workflows than i've spent doing anything useful for ltsp and epoptes for the last year :/
| |
| 10:05 | <alkisg> Btw sorry if any of my wording comes out bad; sometimes when thinking/typing fast, english don't come out very well
| |
| 10:06 | OK, so maybe you can just merge upstream first, then merge debian-gsoc?
| |
| 10:06 | <vagrantc> that should work fine
| |
| 10:06 | <alkisg> I think it should work without any changes in any of our workflows
| |
| 10:06 | Great!
| |
| 10:07 | <vagrantc> but upstream hasn't merged your upstream proposed changes yet?
| |
| 10:07 | <alkisg> And the vcs should be happy as long as it's pointed to the debian-master dir there
| |
| 10:07 | I'll ping fotis to do it today
| |
| 10:07 | I think it might be better if I don't do it myself, wrt gsoc
| |
| 10:07 | <vagrantc> and tag it with a version to merge?
| |
| 10:07 | <alkisg> Great
| |
| 10:07 | <vagrantc> yeah, makes sense
| |
| 10:08 | <alkisg> Thanks vagrantc, see, all this debate did end in both of us having a workflow that we can live with :)
| |
| 10:08 | <vagrantc> admittedly, most of the projects i've worked on i've been the sole debian maintainer for most of the time i've worked on them
| |
| 10:09 | alkisg: we've been doing this a long time, plenty of trust to fall back on :)
| |
| 10:09 | <alkisg> :)
| |
| 10:09 | <vagrantc> even if i'm jetlagged and wide awake when i should be sleeping :)
| |
| 10:09 | <alkisg> Thanks + bye for now, kids time! :)
| |
| 10:09 | Haha
| |
| 10:09 | Have a good rest!
| |
| 10:09 | alkisg has left IRC (alkisg!3e01e013@ubuntu/member/alkisg, Quit: Page closed) | |
| 10:16 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 10:22 | Helenah has joined IRC (Helenah!d49f2d5f@gateway/web/freenode/ip.212.159.45.95) | |
| 10:22 | <Helenah> alkisg: Thank you very much, you are a big help.
| |
| 10:22 | <alkisg> np
| |
| 10:24 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 11:09 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 11:37 | Da-Geek has joined IRC (Da-Geek!~Da-Geek@135.196.42.4) | |
| 12:20 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 12:20 | Helenah has left IRC (Helenah!d49f2d5f@gateway/web/freenode/ip.212.159.45.95, Ping timeout: 252 seconds) | |
| 12:24 | Helenah has joined IRC (Helenah!d49f2d5f@gateway/web/freenode/ip.212.159.45.95) | |
| 12:24 | <Helenah> hmm
| |
| 12:55 | lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-236.isotelco.net.br) | |
| 13:32 | alkisg has joined IRC (alkisg!3e01e013@ubuntu/member/alkisg) | |
| 13:33 | GodFather has joined IRC (GodFather!~rcc@2600:1015:b119:d350:9dbf:a633:8259:aa3b) | |
| 13:39 | ltsp has joined IRC (ltsp!bot@ltsp.org) | |
| 13:46 | Helenah has left IRC (Helenah!d49f2d5f@gateway/web/freenode/ip.212.159.45.95, Quit: Page closed) | |
| 13:53 | Helenah has joined IRC (Helenah!~s98259@unaffiliated/iveeee) | |
| 13:53 | <Helenah> hmm
| |
| 13:55 | alkisg has left IRC (alkisg!3e01e013@ubuntu/member/alkisg, Quit: Page closed) | |
| 14:20 | lucas__ has joined IRC (lucas__!~lucascast@138.68.106.79) | |
| 14:23 | lucascastro has left IRC (lucascastro!~lucascast@177-185-139-236.isotelco.net.br, Ping timeout: 260 seconds) | |
| 14:40 | gvy has joined IRC (gvy!~mike@altlinux/developer/mike) | |
| 15:17 | Da-Geek has left IRC (Da-Geek!~Da-Geek@135.196.42.4, Quit: Leaving) | |
| 15:23 | lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-236.isotelco.net.br) | |
| 15:25 | lucas__ has left IRC (lucas__!~lucascast@138.68.106.79, Ping timeout: 268 seconds) | |
| 15:45 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 16:27 | lucascastro has left IRC (lucascastro!~lucascast@177-185-139-236.isotelco.net.br, Quit: Leaving) | |
| 17:06 | lucascastro has joined IRC (lucascastro!~lucascast@200.141.207.18) | |
| 17:13 | lucascastro has left IRC (lucascastro!~lucascast@200.141.207.18, Read error: Connection reset by peer) | |
| 17:14 | lucascastro has joined IRC (lucascastro!~lucascast@200.141.207.18) | |
| 17:23 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 17:35 | <Helenah> alkisg: If I'm correct EXTRAMOUNTS only does read-only mountpoints, or do I have a permissions related problem? I've mounted /srv/common, however nobody can write to it.
| |
| 17:36 | <alkisg> Helenah: no, it doesn't do read only mouns
| |
| 17:36 | If you type `mount` you'll see that it's rw
| |
| 17:36 | So yeah, sounds like you're having permission issues, try to login to the server with a user
| |
| 17:36 | And to access /srv/common from there
| |
| 17:36 | E.g. from a server terminal, run: su - user1
| |
| 17:36 | And then touch /srv/common/blabla
| |
| 17:37 | bbiab
| |
| 17:37 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 17:38 | alkisg has joined IRC (alkisg!3e01e013@ubuntu/member/alkisg) | |
| 17:39 | <alkisg> vagrantc: fotis merged gsoc to epoptes master, so now it's ready to be merged to debian/master, so that then debian-gsoc can be merged to debian/master too
| |
| 17:40 | <Helenah> alkisg: What I'm wanting is any users in the common group have rw access to /srv/common
| |
| 17:40 | I also got Permission Denied
| |
| 17:41 | <alkisg> Helenah: you first need to find a unix solution, and THEN apply it to ltsp. What is your unix solution for this?
| |
| 17:41 | If you can't make it work locally on a single pc (= the server), ltsp can't help you...
| |
| 17:43 | <Helenah> I tried: chown -hR nobody:common /srv/common/
| |
| 17:44 | <alkisg> it's not as simple as you think; ask in #ubuntu or in #linux about it
| |
| 17:44 | <Helenah> hmm
| |
| 17:44 | <alkisg> Here we ended up writing our own software for this, a service called "shared folders"
| |
| 17:45 | <Helenah> Aaaah
| |
| 17:45 | <alkisg> Which uses "bindfs" to make it work correctly, as unix groups and ACLs don't do it properly
| |
| 17:45 | But this isn't related to #ltsp at all
| |
| 17:45 | <Helenah> I'll use that instead.
| |
| 17:45 | gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving) | |
| 17:46 | <alkisg> (it's part of ltsp-manager)
| |
| 17:49 | <Helenah> Are there any plans for Ubuntu 18.04?
| |
| 18:11 | danboid has joined IRC (danboid!~dan@cpc126962-macc4-2-0-cust227.1-3.cable.virginm.net) | |
| 18:12 | <danboid> Hi all!
| |
| 18:13 | I've got a PNP style install of 16.04 and I want to change the default kernel of the clients. I found this guide http://wiki.ltsp.org/wiki/Tips_and_Tricks/Maintenance#Upgrade_Client_Kernel but I don't think I understand it as its not worked for me
| |
| 18:14 | PNP style install of LTSP running under 16.04
| |
| 18:15 | It's not really explained what you are supposed to do at that link but I presumed the idea is to uncomment PXELINUX_DEFAULT= then place the name of the kernel after that?
| |
| 18:16 | I did that, then recreated my image but it still boots the old kernel
| |
| 18:18 | I might be using the wrong name for the kernel? I just stuck the full filename (but not including the path) of the kernel (as stored under /boot ) after PXELINUX_DEFAULT=
| |
| 18:18 | That wiki page is a bit lean on the details here
| |
| 18:19 | Maybe there is a better guide / set of docs?
| |
| 18:20 | My LTSP server is booting the latest 16.04 HWE kernel by default but the clients are not
| |
| 18:21 | is the easiest way to phrase my issue :)
| |
| 18:22 | vagrantc, ^^
| |
| 18:22 | <Helenah> alkisg: With them not being any Ubuntu 18.04 support in regards to ltsp-manager, would it be best if I manaually implemented bindfs?
| |
| 18:22 | Hi danboid, you been here before?
| |
| 18:23 | <danboid> Helenah, I have, yes
| |
| 18:23 | I've been in most Linux / open source IRC channels before :)
| |
| 18:24 | I'm new to LTSP tho
| |
| 18:24 | <Helenah> hmm
| |
| 18:24 | I'm er semi-new
| |
| 18:25 | I used it a year or so ago, it was very different
| |
| 18:25 | <danboid> Have you not tried adjusting the default kerne for clients then?
| |
| 18:25 | <Helenah> Didn't use it much, and here I am using it again.
| |
| 18:25 | No
| |
| 18:26 | <danboid> The docs on this are a bit vague
| |
| 18:26 | <Helenah> Yeah, I had the same issue, it's hard to find information.
| |
| 18:26 | <danboid> I'm sure vagrantc would tell us instantly
| |
| 18:26 | <alkisg> Helenah: yeah sure, you can manually implement bindfs, I have no plans to upgrade ltsp-manager to 18.04 unless there's big demand for it
| |
| 18:26 | <Helenah> I thought the only active person here was alkisg and sometimes Hyperbyte ?
| |
| 18:26 | <alkisg> danboid: you want the hwe kernel for the server, and the non-hwe for the clients?
| |
| 18:27 | <Helenah> alkisg: I'll look into doing it.
| |
| 18:27 | <danboid> I want to use hwe / latest on both
| |
| 18:27 | <alkisg> danboid: and? why don't you?
| |
| 18:27 | danboid: what's the output of this? ls -l /var/lib/tftpboot/ltsp/*/vmlinuz* | nc termbin.com 9999
| |
| 18:27 | <danboid> but after updating both the server and the image, the image is still booting 4.4.x
| |
| 18:27 | <alkisg> That sounds like you still have both kernels
| |
| 18:27 | While you should have removed the old ones
| |
| 18:28 | <danboid> Its as simple as that eh? Just remove all the older kernels :)
| |
| 18:28 | <alkisg> And run ltsp-update-image, yeah
| |
| 18:28 | <danboid> I didn't even think of it :)
| |
| 18:28 | <alkisg> Or do a manual symlink in tftp, if you prefer
| |
| 18:28 | But removing the kernels is easier
| |
| 18:28 | <danboid> Seems too obvious now
| |
| 18:29 | <Helenah> alkisg: Is there anything LTSP-specific I need to know about bindfs?
| |
| 18:30 | <alkisg> Nope
| |
| 18:32 | <danboid> Is there an existing script(s) for configuring 16.04 to work with or without the non-free Nvidia driver booting from one LTSP image?
| |
| 18:32 | So you'd have the nonfree driver installed but only enabled if the user is using a Nvidia fat client
| |
| 18:33 | otherwise mesa
| |
| 18:34 | <Helenah> mesa will make your graphics card mostly redundant
| |
| 18:34 | <danboid> mesa is official for intel and works v.well for most modern AMD cards now too
| |
| 18:34 | Often as well as the non-free AMD driver now
| |
| 18:35 | Its just nouveau thats shit :)
| |
| 18:36 | I've pretty much wrote said script script but its not quite finished yet s just wondering if there is already a working, tested version
| |
| 18:39 | <alkisg> danboid: afaik it works out of the box in 18.04
| |
| 18:39 | They said it would, so I didn't bother writing such a script
| |
| 18:39 | I.e. you can have nvidia installed and it's only used if the pc has nvidia
| |
| 18:39 | * alkisg waves, later... | |
| 18:39 | alkisg has left IRC (alkisg!3e01e013@ubuntu/member/alkisg, Quit: Page closed) | |
| 18:39 | <danboid> Is 18.04 working fine under LTSP now?
| |
| 18:39 | As both server and client?
| |
| 18:41 | Is 18.04 recommended over 16.04 now?
| |
| 18:44 | <||cw> there's still a a couple issues, but I think the workarounds are known and on the bug lists
| |
| 18:45 | <danboid> Any big issues?
| |
| 18:45 | <||cw> I would stick to 16.04 if it's your first install
| |
| 18:45 | I don't recall, I know the issues are being worked on, slowly
| |
| 18:46 | alkisg has joined IRC (alkisg!3e01e013@ubuntu/member/alkisg) | |
| 18:46 | <alkisg> !install
| |
| 18:46 | <ltsp> install: http://wiki.ltsp.org/wiki/Installation/Ubuntu for Ubuntu, or http://wiki.ltsp.org/wiki/Installation for other distributions
| |
| 18:46 | <alkisg> danboid: if you install using this guide (i.e. the greek schools ppa), ltsp is more stable in 18.04 compared to 16.04
| |
| 18:47 | <||cw> ah, that's new then
| |
| 18:47 | 2 weeks makes a big difference i guess
| |
| 18:47 | <danboid> alkisg, Interesting. Thanks
| |
| 19:13 | <Helenah> I just don't understand the logic in using the mesa driver with an nvidia card.
| |
| 19:13 | It's a very generic driver.
| |
| 19:25 | bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, *.net *.split) | |
| 19:48 | <Helenah> alkisg: bindfs looks complicated, though I'm gonna proceed to learn.
| |
| 20:17 | lucascastro has joined IRC (lucascastro!~lucascast@186.193.178.113.jupiter.com.br) | |
| 20:24 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 20:26 | lucascastro has left IRC (lucascastro!~lucascast@186.193.178.113.jupiter.com.br, Quit: Leaving) | |
| 20:45 | alkisg has left IRC (alkisg!3e01e013@ubuntu/member/alkisg, Quit: Page closed) | |
| 20:53 | GodFather has left IRC (GodFather!~rcc@2600:1015:b119:d350:9dbf:a633:8259:aa3b, Ping timeout: 240 seconds) | |
| 20:57 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
| 21:12 | GodFather has joined IRC (GodFather!~rcc@2600:1015:b11b:a3d0:9dbf:a633:8259:aa3b) | |
| 21:22 | adrianor1 is now known as adrianorg | |
| 23:09 | lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-236.isotelco.net.br) | |
| 23:21 | lucascastro has left IRC (lucascastro!~lucascast@177-185-139-236.isotelco.net.br, Quit: Leaving) | |
| 23:32 | danboid has left IRC (danboid!~dan@cpc126962-macc4-2-0-cust227.1-3.cable.virginm.net, Remote host closed the connection) | |