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


Channel log from 13 August 2018   (all times are UTC)

00:06Helenah has left IRC (Helenah!d49f2d5f@gateway/web/freenode/ip.212.159.45.95, Ping timeout: 252 seconds)
00:31GodFather has joined IRC (GodFather!~rcc@24.sub-97-34-3.myvzw.com)
00:41GodFather has left IRC (GodFather!~rcc@24.sub-97-34-3.myvzw.com, Ping timeout: 240 seconds)
00:54GodFather has joined IRC (GodFather!~rcc@2600:1015:b114:c8c8:9dbf:a633:8259:aa3b)
01:43GodFather has left IRC (GodFather!~rcc@2600:1015:b114:c8c8:9dbf:a633:8259:aa3b, Ping timeout: 240 seconds)
02:02vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
02:20lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-236.isotelco.net.br)
02:23lucas__ has joined IRC (lucas__!~lucascast@138.68.106.79)
02:26lucascastro has left IRC (lucascastro!~lucascast@177-185-139-236.isotelco.net.br, Ping timeout: 248 seconds)
02:51bcg has joined IRC (bcg!~b@2001:2003:54f9:42f6::1)
02:55bcg has left IRC (bcg!~b@2001:2003:54f9:42f6::1, Ping timeout: 240 seconds)
03:04ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Ping timeout: 240 seconds)
04:15lucas__ has left IRC (lucas__!~lucascast@138.68.106.79, Remote host closed the connection)
04:22alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
04:53alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
05:49ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
08:10bcg has joined IRC (bcg!~b@2001:2003:54f9:42f6::1)
08:33alkisg 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:50ogra 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:09alkisg has left IRC (alkisg!3e01e013@ubuntu/member/alkisg, Quit: Page closed)
10:16alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
10:22Helenah 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:24alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
11:09vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
11:37Da-Geek has joined IRC (Da-Geek!~Da-Geek@135.196.42.4)
12:20Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:20Helenah has left IRC (Helenah!d49f2d5f@gateway/web/freenode/ip.212.159.45.95, Ping timeout: 252 seconds)
12:24Helenah has joined IRC (Helenah!d49f2d5f@gateway/web/freenode/ip.212.159.45.95)
12:24
<Helenah>
hmm
12:55lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-236.isotelco.net.br)
13:32alkisg has joined IRC (alkisg!3e01e013@ubuntu/member/alkisg)
13:33GodFather has joined IRC (GodFather!~rcc@2600:1015:b119:d350:9dbf:a633:8259:aa3b)
13:39ltsp has joined IRC (ltsp!bot@ltsp.org)
13:46Helenah has left IRC (Helenah!d49f2d5f@gateway/web/freenode/ip.212.159.45.95, Quit: Page closed)
13:53Helenah has joined IRC (Helenah!~s98259@unaffiliated/iveeee)
13:53
<Helenah>
hmm
13:55alkisg has left IRC (alkisg!3e01e013@ubuntu/member/alkisg, Quit: Page closed)
14:20lucas__ has joined IRC (lucas__!~lucascast@138.68.106.79)
14:23lucascastro has left IRC (lucascastro!~lucascast@177-185-139-236.isotelco.net.br, Ping timeout: 260 seconds)
14:40gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
15:17Da-Geek has left IRC (Da-Geek!~Da-Geek@135.196.42.4, Quit: Leaving)
15:23lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-236.isotelco.net.br)
15:25lucas__ has left IRC (lucas__!~lucascast@138.68.106.79, Ping timeout: 268 seconds)
15:45vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:27lucascastro has left IRC (lucascastro!~lucascast@177-185-139-236.isotelco.net.br, Quit: Leaving)
17:06lucascastro has joined IRC (lucascastro!~lucascast@200.141.207.18)
17:13lucascastro has left IRC (lucascastro!~lucascast@200.141.207.18, Read error: Connection reset by peer)
17:14lucascastro has joined IRC (lucascastro!~lucascast@200.141.207.18)
17:23alkisg 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:37alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
17:38alkisg 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:45gvy 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:11danboid 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:39alkisg 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:46alkisg 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:25bitchecker 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:17lucascastro has joined IRC (lucascastro!~lucascast@186.193.178.113.jupiter.com.br)
20:24ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
20:26lucascastro has left IRC (lucascastro!~lucascast@186.193.178.113.jupiter.com.br, Quit: Leaving)
20:45alkisg has left IRC (alkisg!3e01e013@ubuntu/member/alkisg, Quit: Page closed)
20:53GodFather has left IRC (GodFather!~rcc@2600:1015:b119:d350:9dbf:a633:8259:aa3b, Ping timeout: 240 seconds)
20:57Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
21:12GodFather has joined IRC (GodFather!~rcc@2600:1015:b11b:a3d0:9dbf:a633:8259:aa3b)
21:22adrianor1 is now known as adrianorg
23:09lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-236.isotelco.net.br)
23:21lucascastro has left IRC (lucascastro!~lucascast@177-185-139-236.isotelco.net.br, Quit: Leaving)
23:32danboid has left IRC (danboid!~dan@cpc126962-macc4-2-0-cust227.1-3.cable.virginm.net, Remote host closed the connection)