LTSP 5 is in minimal maintenance mode
The new LTSP is hosted at https://ltsp.github.io

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


Channel log from 27 May 2019   (all times are UTC)

01:10SYS64738 has left IRC (SYS64738!~jhonny5@159.213.93.166, Ping timeout: 258 seconds)
02:21ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Ping timeout: 258 seconds)
05:34os_a has joined IRC (os_a!~Thunderbi@195.112.116.22)
05:55woernie has joined IRC (woernie!~werner@p57A0E866.dip0.t-ipconnect.de)
06:00os_a has left IRC (os_a!~Thunderbi@195.112.116.22, Quit: os_a)
06:08josefig has left IRC (josefig!~josefig@unaffiliated/josefig, Quit: Ping timeout (120 seconds))
06:08josefig has joined IRC (josefig!~josefig@unaffiliated/josefig)
06:39
<alkisg>
vagrantc: on the server or the chroot?
06:39
Meh anyway will be rewritten... :P
06:43
<vagrantc>
alkisg: on the server
06:44
i think /usr/share/ltsp/cleanup is only in the client packages or something
06:44
<alkisg>
I think ltsp-cleanup is shipped from the client
06:44
Right, because people might want to run this while the client boots
06:44
E.g. to clean up a VM
06:44
<vagrantc>
it's a confusing error, took me a moment to figure out what was wrong
06:44
<alkisg>
It needs better error messages then; I don't think it needs arch changes
06:45
<vagrantc>
but, as you say, it is limited duration
06:48ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
06:53
<alkisg>
vagrantc: go-md2man doesn't really do a good job at converting man pages; what if we manually run ronn periodically to avoid it as a build dependency? I think that was the reason you didn't like ronn?
06:53
We may even keep the pages in the wiki, and wget+ronn them before releases, and only ship the man pages, not the sources
07:01
<vagrantc>
i think i liked go-md2man's bugs better than ronn's
07:01
or at least found workarounds for them
07:02
you're finding ronn to produce better output?
07:04
i'd *much* rather edit markdown files in git than try to maintain them in a wiki...
07:04
<alkisg>
github wikies are git
07:05
You can edit them locally and push them with git push, or online
07:05
vagrantc: I only took a quick look, but I couldn't even get go-md2man to align the OPTIONS
07:05
It insisted on putting extra ident in the first option, it didn't highlight options etc; ronn worked out of the box
07:05
If you think it works, I can give go-md2man another look...
07:06
Or file a bug report and see if upstream is active
07:06
<vagrantc>
i don't know what you're trying to do ... i thought it worked well enough for lts.conf
07:08
<alkisg>
This looks nice with ronn, awful with md: https://termbin.com/l7tc
07:08
<vagrantc>
maybe i'm not as fussy with the output
07:08
<alkisg>
go2md insisted on putting --help 2 spaces to the right, even before adding bullets there, and I couldn't get it to align with the others
07:09
Re: wiki/git: we'll have 2 wikies; one for the developers and one for the community
07:10
I intent on keeping the developers wiki very well maintained, by limiting the pages there to 20 or so
07:11
So does it sound OK if we pull the man pages from that wiki (which is a git repository) and run ronn or sphinx or the other one that I don't remember, and just have the man pages in the ltsp source repository?
07:12
We can also keep them in the ltsp source repository; the idea is that we manually convert to man when we need to, to avoid the build dependencies that you don't like
07:13
<vagrantc>
alkisg: leave out the bullets?
07:13
<alkisg>
That's how I had it initially, and got the alignment issue
07:14
<vagrantc>
what alignment issue?
07:15
<alkisg>
-h going 2 spaces to the right
07:15
<vagrantc>
looks nice and aligned here.
07:18
<alkisg>
...I'll give "go" another go...
07:18
<vagrantc>
heh
07:18
instead of bullets, just having the --help text indented a bit, and then the explanation for --help indented a bit more looks fine to me
07:20
and keeping --OPTIONS indented at the same indent
07:25* alkisg checks if it appears readable online... https://github.com/eellak/gsoc2019-ltsp/blob/master/man/ltsp-kernel.8.md
07:26
<alkisg>
Oh well ok good enough I suppose; ronn also has html output, but I guess we can just link to the distro manpages
07:28
<vagrantc>
that's why i like markdown ... it's pretty readable as plain text
07:30
although i'm guessing github is rendering something there...
07:32
definitely...
07:33
<alkisg>
It's standard md to html, yueah
07:33
It's why ronn used bullets in options, to have them appear in html bullets too
07:34
But ok man to html is more readable than md to html anyway
07:34
So we can just link to the distro online manpages
07:41SYS64738 has joined IRC (SYS64738!~jhonny5@159.213.93.166)
07:42vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
07:56
<alkisg>
Hmm mate-terminal doesn't show bold in man pages; xterm shows them better
08:09woernie has left IRC (woernie!~werner@p57A0E866.dip0.t-ipconnect.de, Remote host closed the connection)
08:15kjackal has joined IRC (kjackal!~quassel@2a02:587:3106:1000:59a6:2f4c:44b9:f348)
08:28statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
09:57
<uumas>
Why does ltsp-docs conflict with ltsp-server when using the greek schools ppa on ubuntu 18.04 now?
10:00
<alkisg>
uumas: ltsp-docs have been deprecated, the lts.conf manpage now is shipped via ltsp-server
10:00
So it's ok for ltsp-docs to be purged
10:01
<uumas>
Ok. apt upgrade didn't want to update ltsp-server because of that. Had to manually install the new version.
10:02
<alkisg>
uumas: it's wrong to use apt upgrade; use apt full-upgrade
10:02
(or apt-get dist-upgrade in older releases)
10:03
Whatever tutorial told you to use apt upgrade, is broken, blacklist that site :D
10:03
<uumas>
I wouldn't call using apt upgrade "wrong". It just doesn't remove packages.
10:03
<alkisg>
It should not be used to maintain installations
10:04
It might be helpful in extreme cases where something specific is needed
10:04
But it's wrong advice to give to people to maintain their boxes with it
10:04
<uumas>
Is removing packages the only difference?
10:05
<alkisg>
And installing new ones
10:05
So if package X now grows a new dependency Y, apt upgrade will fail to upgrade, and the sysadmin will be "wth"
10:05
<uumas>
I'm quite certain upgrade does install new dependecies
10:06
<alkisg>
I think it only installs new versions of existing dependencies; not new ones; but it's been years since I last used apt upgrade, so not 100% sure
10:07
New packages will be installed if required to satisfy dependencies, but existing packages will never be removed.
10:07
You're right; maybe they changed that in recent versions with apt vs apt-get; because I think that I say was true previously
10:08
man apt-get => or packages not already installed retrieved and installed
10:08
So what I said is true for `apt-get upgrade`, and what you said was true for `apt upgade`
10:08
They "fixed" it a bit in that regard
10:09
<uumas>
Yeah, ok. I don't remember official ppas ever requiring deletion of packages for anything but release upgrades and there's 'do-release-upgrade' in ubuntu for that.
10:09
<alkisg>
uumas: note that "greek school ppa" is the same as "debian"
10:09
Nothing "ppa-related" about it
10:10
The exact same thing would happen in recent debian, and in the next version of ubuntu
10:10
If a maintainer wants to conflict with a previous version of his packages, it's considered normal upgrade procedure and `apt upgrade` breaks it; just don't use that
10:10
<uumas>
Ok, good to know
10:10
<alkisg>
Btw the change was done by vagrantc on debian, not on the ppa
10:11
I just use the latest upstream+debian version in the ppa; I don't have any custom code at all there
10:11
<uumas>
So, the same packages used in debian sid?
10:12
<alkisg>
When debian releases, they match the ppa. A bit later, the ppa gets even newer versions.
10:12
Sometimes then vagrant backports them to debian, if the fixes are important enough
10:12
But the important part is that the ppa has no custom code; it's debian+upstream; so it'll eventually reach debian and ubuntu too
10:13
(by debian i mean vagrant's debian/ packaging dir, and by upstream I mean the ltsp git code)
10:14
Example: https://git.launchpad.net/ltsp/log/ ==> vagrant released on the yellow tag there; at that point debian matched the ppa
10:15
So the fixes that I uploaded after the yellow tag, are not in debian yet, but they're there in the ppa
10:24pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 258 seconds)
10:28pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)
10:34ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
10:47vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 258 seconds)
10:49vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
12:03SYS64738 has left IRC (SYS64738!~jhonny5@159.213.93.166, Ping timeout: 268 seconds)
12:05Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:09vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
12:11kjackal has left IRC (kjackal!~quassel@2a02:587:3106:1000:59a6:2f4c:44b9:f348, Read error: Connection reset by peer)
12:34kjackal has joined IRC (kjackal!~quassel@2a02:587:3106:1000:4999:dc41:a0a8:3e9c)
12:38SYS64738 has joined IRC (SYS64738!~jhonny5@159.213.93.166)
13:03ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
13:04ogra has joined IRC (ogra!~ogra_@ubuntu/member/ogra)
13:27
<alkisg>
vagrantc: ok other than this one, go-md2man mostly worked: https://github.com/cpuguy83/go-md2man/issues/27
13:28
I.e. can't get word wrapping to work in OPTIONS (neither in your lts.conf)
13:58nehemiah has left IRC (nehemiah!~nehemiah@156.19.21.242, Remote host closed the connection)
14:12
<alkisg>
Hmm wouldn't it be better if you created a debian/buster branch at the point when you diverged from upstream (i.e. inserted patches that are already upstream)?
14:12
I think now I won't be able to build to the ppa anymore, with the debian branch
14:12
I'll have to fork it into another, debian/upstream or something branch
14:25
<vagrantc>
the "Debian" branch needs to be at a consistant location
14:25
i consider debian/master the packaging branch for Debian.
14:25
<alkisg>
but it's not; it's just only for the debian subcase
14:25
it doesn't apply for upstream, for all distros
14:25
<vagrantc>
no, it only applies for Debian.
14:26
we've gone over this so many times and just disagree.
14:27
<alkisg>
I have it better in my mind now though
14:28
It's like you want to be the "upstream" for debian, while you're not; I commit there too, and I use it too
14:28
It blocks cooperation
14:29
<vagrantc>
would it be better if it were named packaging-branch-for-the-proper-noun-Debian-with-a-capital-D-Debian/master ?
14:29
<alkisg>
it would be better if we agreed on a COOPERATIVE debian branch
14:29
not one for you
14:30
whatever the name
14:30
one that i could use for UPSTREAM packaging
14:30
where my changes weren't a patch
14:32
<vagrantc>
it's not practical to have a branch that is both used for Debian packaging and also use for other debian-based distros ; it should be simple enough to cherry-pick relevent changes from each branch
14:33
<alkisg>
since many distros share the debian/ branch and many contribute to the same dir, it's practical to have a master version that matches upstream and has no patches
14:34
and each distro/release that needs patches, can fork it when it needs
14:34
<vagrantc>
i don't see any reason for people who want that to maintain that
14:34
or, don't see any reason for people who want to do that to maintain it
14:35
having a new branch every time it diverges from upstream would require changing debian/control: Vcs-* every time, which is not practical.
14:36
<alkisg>
vagrantc: but your branch doesn't build with upstream now; it builds only with your branch
14:36
<vagrantc>
yes.
14:36
<alkisg>
OK let's rephrase
14:36
I want to release ubuntu now
14:36
Where should I push to the debian dir?
14:37
<vagrantc>
ubuntu/master ?
14:37
<alkisg>
Don't tell me to fork, it's like saying "your branch is less significant than mine"
14:37
No, I want to push code in debian with the same rights as you
14:37
I don't want to be a "lesser maintainer" of forks
14:37
<vagrantc>
you don't have to be
14:38
you can maintain debian/upstream, ubuntu/master, whatever you want. they're all forks of upstream.
14:38
<alkisg>
But the "master debian" branch has patches that I never needed in ubuntu
14:38
<vagrantc>
then don't merge those patches.
14:38
<alkisg>
Why would I want these, and how would merging work
14:38
It's not at all practical
14:39
While if you just do the same thing that you just proposed to me, it all works
14:39
<vagrantc>
except that it doesn't work at all.
14:39
<alkisg>
I.e. if we have a debian dir with no patches, and you apply patches in a fork whenever you want, same as I'd do now with ubuntu
14:40
So, we'll end up having two branches, and keep fighting over them?
14:40
E.g. when you push to debian, I'll have to merge with ubuntu, then undo your changes, THEN build?
14:40
And you say this is practical?
14:40
And then the opposite, whatever changes I make, you'd merge/undo/cherrypick them?
14:41
Isn't that a complete waste of time and git history?
14:42
<vagrantc>
the main complaint it seems you have so far is i merge upstream patches into the debian packaging branch that you don't want in some conceptual upstream packaging branch
14:42
<alkisg>
I can't click "build recipe" now
14:42
It's broken; that's the complain
14:42
<vagrantc>
so those should be trivial to not cherry pick.
14:42
<alkisg>
I don't want to have to undo your distro-specific changes anytime I want to build packages against upstream
14:42
You enforce me to do work whenever time you apply patches
14:43
<vagrantc>
and you're demanding work from me
14:43
<alkisg>
No; I just ask that you don't enforce ME to do work
14:43
Yesterday I could build the recipe; today I can't; I have to do work; why?
14:44
I can create an ubuntu branch and we can diverge; but is that nice?
14:44
<vagrantc>
it's certainly nicer than continuing to have this debate endlessly
14:44
<alkisg>
:(
14:45
OK I'll move the sources to github and build from there
14:45
You can continue the ones in launchpad
14:45
<vagrantc>
i could also maintain my packaging in debian's git repoisitories
14:45
<alkisg>
Or that; then I could push debian upstream in launchpad git
14:45
That way it would always be buildable
14:46
<vagrantc>
why does it matter to maintain it in github vs. launchpad? this seems like a separate issue?
14:46
<alkisg>
I need some place where I can keep the debian upstream branch
14:46
The one that is not debian specific, but "upstream" to all distros that use the .deb format
14:46
So it'd be nicer if it was close to upstream
14:47
<vagrantc>
if that's what you want, i won't bother to stop you, but it will certainly strain a long history of collaboration
14:48
which is really unfortunate, as i've been actually quite excited about the recent development!
14:48
<alkisg>
That's just my complaint; that there's no collaboration in debian/... it's like you say "that's my dir for debian/, fork it and do what you want"
14:48
While I don't want to maintain a fork for ubuntu; I care for the ltsp debian packaging for all deb distros
14:48
It'll be the same for ltsp19 too
14:48
Or with epoptes; where I wrote most of the packaging (and it will be the same in ltsp19 too)
14:49
I can't maintain a fork there
14:49
ltsp5 doesn't matter much, but if we're to cooperate in those other 2 projects, we'll need to find a method where I don't maintain a debian/ fork
14:50
Where I don't have to do work each time debian needs patches and breaks the recipe builds
14:51
<vagrantc>
you're basically asking either to fork or to fork
14:51
<alkisg>
I'm saying "each release, on any distro, is a snapshot; a fork"
14:51
you're saying "my release is the master one"
14:52
<vagrantc>
i'm saying the fork for Debian is the fork for Debian
14:52
<alkisg>
And release equals "needing patches that already exist upstream"
14:52
Can we agree to have one for cooperation then?
14:52
A master one?
14:53
Or you want to be "downstream debian" without caring for a debian dir where we two can collaborate?
14:55
<vagrantc>
this really seems to be 99% about applying upstream patches to a packaging branch ... i suspect there is little other issue
14:55
<alkisg>
Yup
14:55
<vagrantc>
ok, finally we're back to agreeing on something :P
14:55
<alkisg>
Haha
14:55
We'll make it, you'll see :D
14:58
<vagrantc>
the only other differences that would make merging between packaging branches difficult would be debian/changelog
14:58
my workflow has typically been to only edit debian/changelog for each released packaging version
14:59
<alkisg>
bb in 15', sry...
15:25pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 258 seconds)
15:27pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)
15:32kjackal has left IRC (kjackal!~quassel@2a02:587:3106:1000:4999:dc41:a0a8:3e9c, Ping timeout: 252 seconds)
15:42
<alkisg>
vagrantc: to sum up: in any project where I care to maintain a debian dir, I don't want to have to remove patches in order to build against upstream; i want that debian dir to be used in upstream build recipes
15:42
So in projects where we cooperate in debian/ maintenance, let's have a master dir with no applied patches. I don't care how it's called.
15:42
If you want, you can use that to tag changelog, release for debian, release again etc, as long as there are no patches, which would break upstream builds. But if you ever need patches, you'd need to fork it to e.g. debian/buster.
15:42
Now, if you don't like that method, and you don't have any other ideas that would allow me to build against upstream (I don't), then I'll maintain my own debian dir in the upstream tree, and you can maintain yours wherever you like.. I can't think of any other solution...
15:43
This goes for ltsp19 and epoptes; I don't mind about ltsp5 much, I can just fork it now and never update it
15:48
<vagrantc>
alkisg: there needs to be a specific debian packaging branch that represents the current debian packaging, so forking debian/buster only needs to happen once buster releases or i start packaging experimental
15:49
alkisg: but i'll still want a branch that may have patches in it that isn't appropriate to what you want
15:49
<alkisg>
For point (2), I haven't seen that yet; let's talk about that if I see it,
15:49
for point (1), can't you just sync with upstream instead of using debian/patches? is it against the freeze process?
15:50
<vagrantc>
yes, it's not possible to import new upstream versions during a freeze (more-or-less)
15:50
additionally, changes may land upstream during a freeze and only some of which are appripriate
15:50
hence having to pick specific patches
15:51
and apply then to a specific version
15:51
<alkisg>
OK; that means that you'd have to fork debian/buster at that point when you want to apply patches; unless you don't want us to cooperate in a debian dir
15:52
In which case, no need to fight over it, each of us can maintain his own; I'll maintain the upstream one and you maintain the debian one
15:52
<vagrantc>
alkisg: i've definitely forked the debian packaging for a specific release in the past while continuing to update another version that has patches on top
15:52
<alkisg>
I think all arguments have been heard; it's just about the decision now; if you prefer to fork when you need patches, or for us to maintain separate debian dirs...
15:53
<vagrantc>
every debian packaging release will have to fork from upstream (with or without debian packaging)
15:54
<alkisg>
I understand that you fork the code, yup. I didn't understand the final decision though.
15:54
<vagrantc>
if there's an upstream packaging branch, then the debian packaging might be able to fork from that when needed
15:54
but it might become unmanageable
15:55
i can't predict the future, but based on past experience, i would think i'll end up maintaining a debian packaging forked branch like i always have, which might have significant overlap with upstream packaging
15:56
it would be most helpful if the upstream debian packaging wasn't in the upstream branch in that case. e.g. it's own branch.
15:56
<alkisg>
Whatever you prefer; but I can't maintain a debian dir the way you propose, for ltsp19/epoptes, so it needs to be either collaboration or separate; not removing the debian patches whenever I need to build; I do that a lot with the ppa, it's somewhat like a rolling release
15:56
<vagrantc>
but i get the impression you don't want that
15:56
<alkisg>
I don't mind about taht
15:57
If it helps you, I can have the debian-upstream branch in a branch, not a folder
16:02
<vagrantc>
so, it pretty much sounds like the status quo with one more packaging branch ... ?
16:10SYS64738 has left IRC (SYS64738!~jhonny5@159.213.93.166, Ping timeout: 246 seconds)
16:25kjackal has joined IRC (kjackal!~quassel@2a02:587:3106:1000:4999:dc41:a0a8:3e9c)
16:55
<alkisg>
vagrantc: right; I just hope we won't diverge so much that I won't be able to support debian/ubuntu users, and I'll only be able to support PPA users :D
16:55
Now, wrt branch naming, in order to avoid confusion on debian/master vs debian/upstream or whatever the names are, maybe it would be best for you to move to salsa?
16:56
That way I can just undo the last commits (when you're done) that contain the patches, and keep using the same recipes
16:58kjackal has left IRC (kjackal!~quassel@2a02:587:3106:1000:4999:dc41:a0a8:3e9c, Ping timeout: 250 seconds)
16:59
<alkisg>
Or, if it's easy for you if I have a debian/ folder upstream, I'd rather do that and simplify everything even more
17:09
<vagrantc>
please no
17:10
given that a stable release containing the current revision control history exists ... i'd like to keep debian/master as is on launchpad, and debian/upstream or something for the new packaging?
17:11
or rather, buster is about to release with the current Vcs information
17:11
i'd prefer not to have that information be outdated before it
17:11
s released
17:11
honestly, i'm not in best form today, either
17:12kjackal has joined IRC (kjackal!~quassel@2a02:587:3106:1000:4999:dc41:a0a8:3e9c)
17:18
<alkisg>
Hey there's no hurry; I last uploaded to the PPA 3 days ago; if nothing breaks, I won't have to upload for a few weeks
17:19
I'm mostly trying to resolve this for ltsp19 and epoptes; not for ltsp5
17:21
<vagrantc>
has epoptes had any recent updates?
17:21
been a while since i've checked
17:21
<alkisg>
No I think after 1.0 things have been quiet, I didn't have any significant issues to resolve
17:24
<vagrantc>
*sometimes* it's a good sign when software doesn't make releases all the time :)
17:24
<alkisg>
I don't release all the time. Only when bugs are found or new features are implemented that people want to use the next day
17:25
I don't even release when new features are implemented that people won't use for weeks; I wait until they need them
17:25* vagrantc isn't making accusations :)
17:25
<alkisg>
It's similar to flatpaks/appimages etc; I just think .deb is better for that, I don't like their infrastructure
17:25
And I really hope distributions grew a better way to collaborate with upstream package maintainers better
17:26
Even if we moved all schools here to debian, I'd still have a repository similar to the PPA
17:26
It's not about ubuntu; it's about good support
17:26* vagrantc really was just trying to pass a compliment to the epoptes team :)
17:26
<alkisg>
Haha
17:27* alkisg is usually trying to hyper-optimize procedures, and misses lots of things that happen while he does that
17:27
<vagrantc>
too often people assume if something doesn't get weekly updates that upstream is dead
17:28
<alkisg>
The next big update that I'm eyeing for epoptes, is wayland compatibility; that'll need a while...
17:28
<vagrantc>
the world is moving fast, though ... it's kind of a challenge for distribution models to strike a balance between solid best practices and supporting software of highly variable quality
17:28
all of which may have difference release cycles and cadences
17:29
<alkisg>
True; yet they're doing it for flatpaks and appimages etc; I don't know why they don't want to do that for .debs
17:30
<vagrantc>
it's a tradeoff of models; they bundle whatever is needed to make it work, and don't need any integration between different flatpaks
17:31
which means you have bundled dependencies which may have bugs or security issues that aren't the primary interest of a particular image maintainer ....
17:31
<alkisg>
Yup, that's one of the many reasons I don't like that flatpak/appimage model
17:32
*snap too
17:32
I knew I was forgetting one of them
17:32
<vagrantc>
there are some interesting things kind of in-between, like Nix and Guix
17:32
which have their own problems...
17:33
<alkisg>
I'd love a debian-upstream repository, similar to debian-backports etc, that one could enable for selective .deb updates, where the upstream developers would be allowed to push
17:33
It's almost the same like having thousands of PPAs etc, except now you know that debian verified that the committer is the upstream developer
17:33
<vagrantc>
similar things have been discussed at length within debian, with lots of unresolved issues
17:34
although that's a very particular take on the general idea i hadn't heard before
17:34
making it "upstream only"
17:35
<alkisg>
Well, the debian maintainer would use the other repositories, security, updates, backports etc
17:35
This one would be for upstreamers
17:35
<vagrantc>
big issue is licensing compliance and trust path verification
17:36
<alkisg>
Upload rights to upstream VCS should be ok for trust path; licensing => they'd need to offer the packaging in some foss license; the rest can be contrib or whatever, as long as they agree it's redistributable... things like that
17:36
Like google, "upload this file to your web server to enable analytics"
17:37
<vagrantc>
but that still requires a common understanding about what foss licenses are
17:37
and common dilligence to follow-up on it, and commitment to resolve issues with it...
17:37
<alkisg>
I don't think upstream would care much about the packaging code license; it's supposed to be small
17:38
<vagrantc>
yes, but debian cares about what it distributes under it's name and infrastructure
17:38
<alkisg>
I mean, debian can define the terms there
17:38
<vagrantc>
though the "contrib" and "non-free" sections are ... weird.
17:38
<alkisg>
Re: quality, users would know not to use an upstream package if it didn't have quality; even upstream wouldn't bother with that repository if they didn't have commitment
17:41
<vagrantc>
if someone had the free time, it would be plausible to test the waters by registering "upstream.debian.net"
17:43* alkisg hasn't even had enough free time to commit/apply for DD yet... :/
17:43
<vagrantc>
setting up the infrastructure, etc.
17:43
indeed
17:43
and that's perhaps the biggest blocker to ideas like this ... though this does have an interesting angle on it
17:43
the main idea has more-or-less just been reimplementing ubuntu's PPAs
17:44
which is almost a free-for-all
17:44
<alkisg>
Unfortunately now that ltsp/epoptes/sch-scripts have few devs, I spend a lot of time there
17:44
<vagrantc>
wish i had more practical use to be more involved again
17:45
really have been enthused at the progress you've been making!
17:45
<alkisg>
I love the "no ltsp-client package" idea; and except for the authentication I haven't found any blockers yet, it'll be fun to materialize this
17:46
For the authentication, in the distant future, I hope we'll implement a libpam-sshauth .c package, and get it to all distros, and even have liveboot/casper support that a bit
17:51
<vagrantc>
the python implementation seemed a little easier to work with ... but it depended on something that doesn't seem to be moving to python3
17:51Marlon_ has joined IRC (Marlon_!8acc19c6@gateway/web/freenode/ip.138.204.25.198)
17:51
<vagrantc>
libpam-python also didn't want people to use it for serious things...
17:52
maybe we shouldn't write it in C, but in rust or golang
17:53
something security-sensitive might be worth using a language a little more security-focused
17:54
and are also languages that might draw in new developers
17:54Marlon_ has left IRC (Marlon_!8acc19c6@gateway/web/freenode/ip.138.204.25.198, Client Quit)
18:02
<alkisg>
What I like about libpam-sshauth, is that it will be stable, not a moving target like GUI apps
18:03
So I don't care much about attracting more developers there; one that will write it should be enough :D
18:04
And if we have the stable authentication bit in ltsp-client, we can easily then update everything on the server
18:05
Unfortunately ltsp needs frequent updates, e.g. just last week a netplan update broke ltsp booting; so that ^ model should be much easier, I hope
18:06
<vagrantc>
sure
18:07
C is certainly a baseline available everywhere ... but there are some easy-to-make mistakes in C that result in vulnerabilities that some of the newer languages have basically designed to avoid
18:10
<alkisg>
No worries there, whatever the developer wants/knows. Some tricky kernel calls will be needed, as long as the interfaces are available, no problem (e.g. python doesn't have them)
18:10
*libc calls
18:10
About tty management
18:14
<vagrantc>
python might be more feasible to inject into an arbitrary initramfs, though :)
18:14
<alkisg>
I don't have my hopes up for libpam-python, it looks kind of dead
18:15* vagrantc nods
18:19
<vagrantc>
oh, i think i met the developer of libpam-python last year...
18:23
<alkisg>
libpam-python isn't preinstalled in live cds anyway
18:23
And I think it would be easier to convince them to include libpam-sshauth than libpam-python
18:24
I.e. including python code in the initramfs wrt authentication won't help if we need to install a binary package in the image anyway; we can just install our own, stable and maintained one
18:24
<vagrantc>
libpam-python is all written in C, so yeah.
18:25
<alkisg>
In my mind, I have 3 authentication/home models for ltsp:
18:26
1) shadow + nfs3 => can be done with existing live cds; fastest; least secure
18:26
We could encrypt shadow with gpg etc, but it doesn't really help much with nfs3
18:26
2) libpam-sshauth + sshfs => secure, relies on us, sshfs has some quirks, easy to set up
18:27
3) nfs4, kerberos, ldap, etc etc => secure, others are upstream, hard to set up
18:27
I think at the end of this gsoc we'll have (1), and hopefully (2) next year; (3) can only be documented by someone that actually uses taht
18:28* alkisg would also like to see if puevo-ltsp has anything else to offer there...
18:29kjackal has left IRC (kjackal!~quassel@2a02:587:3106:1000:4999:dc41:a0a8:3e9c, Ping timeout: 257 seconds)
18:49statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection)
20:09ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
20:32
<alkisg>
https://github.com/opinsys/puavo-ltsp/blob/master/client/puavo-ltsp-init-nfs
20:33
<vagrantc>
yeah, i remember looking at that project a few times before...
20:33
looks like they've got kerberos and nfsv4!
20:34
and cifs homedir...
20:36
<alkisg>
Btw, pam_exec is usually preinstalled, and says: expose_authtok
20:36
During authentication the calling command can read the password from stdin(3). Only first
20:36
PAM_MAX_RESP_SIZE bytes of a password are provided to the command.
20:36
<quinox>
I'm going to test out (3)
20:37
<alkisg>
So if the initramfs wrote passwd but not shadow, and we somehow configured lightdm+pam to accept whatever password, we could authenticate it after lightdm has logged the user in, and disconnect if it doesn't work with ssh
20:37
...all those interpreted
20:37
quinox: that'd be excellent!
20:38
If we can have even a rough wiki page about that, then I suppose (1) and (3) wouldn't be that bad for a first ltsp19 release
20:38
<quinox>
I already have a non-LTSP server that serves NFS3, I'm planning on moving it to LDAP+NFS4 soonish so I'm all prepared for the new LTSP
20:39
<alkisg>
Awesome; we can cooperate, I write the code, you test + write a small how-to for others, so people that need security won't complain with the additional overhead
20:40
quinox: you prefer to maintain the client with chroot or vm?
20:41
(or chrootless...)
20:41
<quinox>
currently I use chroot, but I'm fine either way
20:41
I don't like chrootless, our LTSP server does loads of things our LTSP clients don't do
20:42
<alkisg>
Right; you could only use chrootless if that server was only serving nfs/nbd, and the "template ltsp client == chrootless" was in a vm...
20:42
Since you have no issues with maintaining chroots/VMs, no need to do chrootless
20:46
<quinox>
sounds like a plan ��
20:46
(ugh, unicode thumbs-up via Windows ConEmu)
20:46
<alkisg>
Hehe
20:51
https://wiki.archlinux.org/index.php/LightDM#Enabling_interactive_passwordless_login
20:52
That could work somewhat too; they'd select the user in lightdm, login with passwordless login, in a special ltsp session, that would ask them for the password, authenticate them etc, set up sshfs, and then exec the real session
20:52
Like half-ldm :P
20:52
It avoids the need to mess with screen scripts, wayland etc
20:53
<vagrantc>
whoah.
20:53
what could ... possibly ... go ... wrong! :)
20:53
<alkisg>
Hahahaa
20:53
Don't be negative!
20:54
<vagrantc>
what could possibly go right!
20:54
<alkisg>
:D :D
20:54
<vagrantc>
it sure has the appeal of some semblance of immediacy and achievability
20:55
<alkisg>
And it should be easy to replace it with libpam-sshauth, when it's ready
20:56
I wonder if some greeter allows passwordless login after the user actually typed a password, so that we could get it from there to pam_exec without any GUI of our own
20:56
<vagrantc>
i think you could do that with pam
20:57
<alkisg>
No gui => much better!
20:57
<vagrantc>
if i'm remembering correctly ...
20:57
<alkisg>
Since we'll already have the user geometry, and we'll already be logged in as the user, and we'll already have the password, it should be doable
20:57
<vagrantc>
you can have a step pass and fall on to the next step i think
20:57
<alkisg>
Just an "ssh + sshfs + exec the real session; exit if failed"
20:58
<vagrantc>
so you can prompt for a password but default to success in one phase, and then fail later if the auth doesn't work ... at least, that would be the dream, wouldn't it
20:58
<alkisg>
Sure, but I don't think we can fail with pam_exec, can we?
20:59
We can kill all user processes though :)
20:59
<vagrantc>
we can epic fail!
21:00
<alkisg>
I think "epic" would be if we managed to get 10 CVEs or so :P
21:00
Whoops, midnight. Bye guys, see you tomorrow.
21:07* vagrantc waves
21:21
<josefig>
hello my friends :)
21:29Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)