IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 27 May 2019 (all times are UTC)
| 01:10 | SYS64738 has left IRC (SYS64738!~jhonny5@159.213.93.166, Ping timeout: 258 seconds) | |
| 02:21 | ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Ping timeout: 258 seconds) | |
| 05:34 | os_a has joined IRC (os_a!~Thunderbi@195.112.116.22) | |
| 05:55 | woernie has joined IRC (woernie!~werner@p57A0E866.dip0.t-ipconnect.de) | |
| 06:00 | os_a has left IRC (os_a!~Thunderbi@195.112.116.22, Quit: os_a) | |
| 06:08 | josefig has left IRC (josefig!~josefig@unaffiliated/josefig, Quit: Ping timeout (120 seconds)) | |
| 06:08 | josefig 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:48 | ricotz 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:41 | SYS64738 has joined IRC (SYS64738!~jhonny5@159.213.93.166) | |
| 07:42 | vagrantc 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:09 | woernie has left IRC (woernie!~werner@p57A0E866.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 08:15 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3106:1000:59a6:2f4c:44b9:f348) | |
| 08:28 | statler 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:24 | pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 258 seconds) | |
| 10:28 | pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme) | |
| 10:34 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 10:47 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 258 seconds) | |
| 10:49 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
| 12:03 | SYS64738 has left IRC (SYS64738!~jhonny5@159.213.93.166, Ping timeout: 268 seconds) | |
| 12:05 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 12:09 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 12:11 | kjackal has left IRC (kjackal!~quassel@2a02:587:3106:1000:59a6:2f4c:44b9:f348, Read error: Connection reset by peer) | |
| 12:34 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3106:1000:4999:dc41:a0a8:3e9c) | |
| 12:38 | SYS64738 has joined IRC (SYS64738!~jhonny5@159.213.93.166) | |
| 13:03 | ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 13:04 | ogra 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:58 | nehemiah 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:25 | pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 258 seconds) | |
| 15:27 | pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme) | |
| 15:32 | kjackal 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:10 | SYS64738 has left IRC (SYS64738!~jhonny5@159.213.93.166, Ping timeout: 246 seconds) | |
| 16:25 | kjackal 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:58 | kjackal 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:12 | kjackal 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:51 | Marlon_ 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:54 | Marlon_ 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:29 | kjackal has left IRC (kjackal!~quassel@2a02:587:3106:1000:4999:dc41:a0a8:3e9c, Ping timeout: 257 seconds) | |
| 18:49 | statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection) | |
| 20:09 | ricotz 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:29 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |