IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 18 August 2019 (all times are UTC)
| 01:29 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Remote host closed the connection) | |
| 01:35 | jgee7 has joined IRC (jgee7!~jgee@190.159.118.121) | |
| 03:56 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 04:55 | <alkisg> vagrantc: I'm going to merge all configuration into a single file, ltsp.conf. [default] will be replaced by [server], [client] and/or [common]. So for example to run a service (RCFILE) on both the server and clients, you'd write:
| |
| 04:55 | [common] SERVICE_x="program"
| |
| 04:55 | My only reservation is if it would be better in 3 separate files, server.conf, client.conf, and common.conf...
| |
| 04:56 | The new lts.conf syntax is very powerful, so I don't want a simple shell-sourceable script for the server settings; I want to be able to put debug hooks from a .conf file on PRE/POST even on server applets etc
| |
| 04:58 | <vagrantc> running arbitrary services on the server? trying to compete with systemd? :P
| |
| 04:58 | <alkisg> We 'll have a services applet anyway, to emulate RCFILE for the clients, run jetpipe etc
| |
| 04:58 | And we want one for the server too, to do NAT when needed, disable flow control etc
| |
| 04:59 | So, it makes sense to just offer a common/services applet, that is run by a systemd unit in both cases
| |
| 04:59 | <vagrantc> i can see why you might want it, but that seems to be growing in scope quite a bit
| |
| 04:59 | <alkisg> And then the user can very easily add RCFILE lines for either the server or the clients
| |
| 04:59 | So, *after* implementing this, the question is if you want to deliberately disable RCFILE for the server
| |
| 05:00 | (we do need the implementation to do nat, flow control etc)
| |
| 05:01 | <vagrantc> going that route, you may as well implement dhcp and tftp and nfs all that way too...
| |
| 05:01 | <alkisg> I think you misunderstood
| |
| 05:01 | I'm talking about a single systemd unit file
| |
| 05:01 | That we need for our internal implementation
| |
| 05:02 | I.e. we'll ship /usr/lib/systemd/ltsp.service
| |
| 05:02 | That service will run on multi-user.target, after network-online
| |
| 05:02 | On the clients, this service will implement RCFILE
| |
| 05:02 | Because rc.local isn't used anymore
| |
| 05:02 | We do want to offer RCFILE in our new lts.conf, right?
| |
| 05:03 | So up to this part, it's the same as ltsp5
| |
| 05:03 | <vagrantc> ok
| |
| 05:03 | <alkisg> Now, we can reuse that ltsp.service to do NAT/flow control on the server as well; this was previously handled by the sch-scripts ifupdown script, which doesn't work without ifupdown
| |
| 05:04 | This can be opt-in, by a setting in ltsp.conf
| |
| 05:04 | <vagrantc> there are lots of services that could implement NAT ...
| |
| 05:04 | <alkisg> Or auto, no problem there
| |
| 05:04 | We can also automatically update the server ip in ltsp.img when needed, to help the clients find the server ,etc etc
| |
| 05:05 | A "run these things when the server boots" hook is good to have, even if everything is opt in
| |
| 05:05 | It's just a small service, that by default may do nothing, or may do a few things, whatever we want
| |
| 05:05 | <vagrantc> sure, i'm just wondering how broad in scope "these services" might get
| |
| 05:06 | <alkisg> Now, *if* we want, we can allow the user to use RCFILE for the server too, instead of him having to find out how to create systemd units or create/enable rc.local
| |
| 05:06 | <vagrantc> worried about reinventing a wheel or maybe a whole multiwheeled vehicle, is all :)
| |
| 05:06 | <alkisg> To disable RCFILE on the server, we'll need additional code
| |
| 05:07 | To allow it, we won't need any more code than what we'll already have to implement RCFILE for the client
| |
| 05:07 | <vagrantc> sure, i get that
| |
| 05:07 | <alkisg> I.e. we're not reinventing anything; it's just an eval "env | grep ^RCFILE" thing; the related code is minimal
| |
| 05:08 | So, having said all these, you want RCFILE on the clients, and you want it disabled on the server? Did I understand you correctly?
| |
| 05:08 | <vagrantc> nothing as specific as that
| |
| 05:08 | <alkisg> Or you don't want an ltsp.service on the server at all?
| |
| 05:09 | <vagrantc> mostly reacting to: < alkisg> [common] SERVICE_x="program"
| |
| 05:09 | <alkisg> The difference there would be, [client] SERVICE_x="program" instead of common
| |
| 05:09 | <vagrantc> and worried that it might become yet another way of configuring arbitrary services
| |
| 05:10 | <alkisg> I.e. we would document that: "the SERVICE_x parameter goes under [common] and replaces the RCFILE parameter which went under [Default]"; no change in functionality at all
| |
| 05:11 | or, under [client] noly
| |
| 05:11 | *only
| |
| 05:11 | <vagrantc> RCFILE was always a quick hack
| |
| 05:11 | useful, of course
| |
| 05:12 | <alkisg> Would you prefer to completely avoid it, and tell the users to learn how to write systemd services when they want to run jetpipe or something at boot?
| |
| 05:13 | <vagrantc> maybe it's just a matter of documenting something along the lines of "for simple one-liner services only ... for more complicated things use systemd services or other appropriate service management from your init system."
| |
| 05:13 | if that's indeed where it's going...
| |
| 05:14 | <alkisg> Sure, that should be clearly explained
| |
| 05:14 | <vagrantc> the other downside is then systemctl stop ltsp"
| |
| 05:14 | will have no granularity
| |
| 05:14 | <alkisg> It would already be stopped
| |
| 05:14 | <vagrantc> or similar start ... if one of the actions fails, will all of them fail?
| |
| 05:14 | <alkisg> As it'll be an "oneshot" unit
| |
| 05:15 | It doesn't fail; all actions are separate
| |
| 05:15 | <vagrantc> ok
| |
| 05:15 | <alkisg> It's just a quick replacement to rc.local
| |
| 05:15 | <vagrantc> so it actually generates onshot services for each entry?
| |
| 05:15 | <alkisg> As it's no longer provided
| |
| 05:15 | No
| |
| 05:15 | It's a single oneshot entry, that evals the SERVICE_x ltsp.conf parameters
| |
| 05:16 | It's a static unit
| |
| 05:16 | No generation of multiple units, nothing
| |
| 05:16 | <vagrantc> so if SERVICE_x fails but SERVICE_y doesn't ?
| |
| 05:16 | <alkisg> eval "all" || true
| |
| 05:16 | We don't care at all if they fail or not
| |
| 05:16 | <vagrantc> just as ugly as rc.local always was :)
| |
| 05:17 | <alkisg> Right, it's more of like rc.local.d, one file for each SERVICE_x parameter
| |
| 05:17 | So one SERVICE doesn't care if the other SERVICE_y fails
| |
| 05:18 | If the user wants he can write SERVICE_y=/path/to/my-service.sh, and do failures and conditionals etc there
| |
| 05:19 | <vagrantc> it sounds a reasonable forward-port of an existing feature ... seems like it might be an opportunity to actually generate systemd units and/or services appropriately ... not sure how crazy that would be.
| |
| 05:19 | <alkisg> No, *that* would be reinventing the wheel :)
| |
| 05:20 | Anyone that knows about systemd units can write his own, and quickly add it to the clients with `ltsp initrd`
| |
| 05:20 | * vagrantc shrugs | |
| 05:20 | ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Remote host closed the connection) | |
| 05:21 | <alkisg> In other news, I'm ready for an alpha release,
| |
| 05:21 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 05:21 | <vagrantc> yay!
| |
| 05:21 | <alkisg> I'll write the gsoc deliverable, which will also be the alpha release announcement,
| |
| 05:21 | then squash-merge the pull request, and move development to the ltsp branch
| |
| 05:22 | <vagrantc> merging it into the existing ltsp branch?
| |
| 05:22 | <alkisg> No, I mean I'll merge it to github.com/ltsp without preserving the gsoc history
| |
| 05:22 | <vagrantc> ah.
| |
| 05:22 | <alkisg> As it involved a lot of experiments and moving around stuff that I don't want in public history
| |
| 05:22 | The list of currently supported ltsp.conf parameters is at: https://github.com/eellak/gsoc2019-ltsp/blob/master/docs/ltsp.conf.5.md
| |
| 05:23 | We're missing jetpipe, swap and autologin parameters (autologin works but isn't exposed in ltsp.conf yet)
| |
| 05:24 | I really liked this parameter: For example, if you name your clients pc01, pc02 etc, and your users a01, a02, b01, b02 etc, then the following line only shows/allows a01 and b01 to login to pc01: PWMERGE_SUR=".*${HOSTNAME#pc}"
| |
| 05:25 | This gives a very clean DM list of users per client :)
| |
| 05:27 | vagrantc: lastly, I'll announce that all ltsp19 discussions happen on the ltsp-community github issues, while ltsp-discuss will be ltsp5 only; hope noone will object to that
| |
| 05:27 | Someone at #debian-edu complained that not all countries have access to github, dunno
| |
| 05:27 | <vagrantc> hadn't you already proposed that with little comment?
| |
| 05:27 | oh, yeah
| |
| 05:28 | i know cuba was recently blocked from github
| |
| 05:28 | <alkisg> Eh, we can make an exception for them and answer ltsp19 questions in ltsp-discuss. Or add stackexchange etc in the future if many users join
| |
| 05:28 | * alkisg hasn't had any questions from cuba for a while, in any list :) | |
| 05:29 | <vagrantc> they've had a history of little to no internet access, so ...
| |
| 05:29 | (and then once they get it, sites start to block them)
| |
| 05:29 | <alkisg> Haha
| |
| 05:29 | It's a good thing we ship much documentation in man pages then
| |
| 05:30 | <vagrantc> yeah. keeping everything self-contained is a good thing
| |
| 05:30 | shipping so much less has a lot of advantages!
| |
| 05:31 | adrianorg has joined IRC (adrianorg!~adrianorg@177.156.225.126) | |
| 05:31 | <vagrantc> alkisg: also, people can still file bugs in their distro bug tracker if they somehow don't have access to github
| |
| 05:32 | <alkisg> True
| |
| 05:32 | <vagrantc> not perfect, but it's something
| |
| 05:32 | though often people seem more willing to make forum or list posts instead of use bug trackers...
| |
| 05:33 | <alkisg> ltsp.img (the transferred ltsp code and everything) is currently at 236k uncompressed, 40k compressed. I don't expect it to grow more than twice that size. It's fine both for network transfer speed and tmpfs ram consumption...
| |
| 05:33 | <vagrantc> awesome!
| |
| 05:33 | adrianor1 has left IRC (adrianor1!~adrianorg@186.215.20.35, Ping timeout: 245 seconds) | |
| 05:33 | <alkisg> So after all, I think this new design is a big step up, kind of like what init-ltsp.d was at the time
| |
| 05:34 | And the re() functions (run or display code that failed and exit) make debugging very very easy
| |
| 05:34 | <vagrantc> oh, i forgot to follow-up about that fish shell bug...
| |
| 05:34 | <alkisg> E.g. testing updated ltsp code needs 1 minute per vm now, no need to update each vm separately...
| |
| 05:34 | * alkisg didn't even test that | |
| 05:35 | <alkisg> Does it really happen in default installations? :/
| |
| 05:35 | It'd be nice to fix it before we stop maintaining ltsp5 :)
| |
| 05:35 | <vagrantc> it's not unreasonable for a user to install some other shell
| |
| 05:35 | weather it actually happens, i haven't even verified
| |
| 05:35 | <alkisg> It also doesn't require admin rights, which is scary
| |
| 05:35 | <vagrantc> or at least confirmed
| |
| 05:36 | normally, user's can only change their shell to shells the system considers as valid shells, at least on debian
| |
| 05:37 | but fish is actually a very nice shell for commandline ...
| |
| 05:37 | <alkisg> I think he said that any other shell would do
| |
| 05:37 | So, any of the existing shells in /etc/shells
| |
| 05:37 | I.e. in a default installation...
| |
| 05:37 | <vagrantc> i knew tcsh used to just crash
| |
| 05:37 | been a bug about that for ages
| |
| 05:38 | i find it hard to believe, but it's easy enough to test
| |
| 05:38 | <alkisg> Not for me, I don't have an ltsp5 installation handy :P
| |
| 05:39 | In September when schools open, sure
| |
| 05:39 | <vagrantc> i probably have a few lying around somewhere
| |
| 05:39 | not a real-world one ... but surely one i can test with
| |
| 05:40 | alkisg: really excited to hear about the progress!
| |
| 05:40 | <alkisg> vagrantc: what happens if you upload ltsp to testing?
| |
| 05:40 | Can it go to backports, since it doesn't conflict, but it has the same source name?
| |
| 05:40 | <vagrantc> alkisg: well, basically you never upload to testing
| |
| 05:40 | <alkisg> source: ltsp, binary: ltsp, doesn't conflict with any ltsp5 package
| |
| 05:41 | I mean, upload to unstable, it migrates to testing; does that need ltsp5 removal?
| |
| 05:41 | <vagrantc> alkisg: it would get stuck because it doesn't provide any of the existing ltsp5 packages in testing and would be flagged as a regression, so yeah, ltsp-client, ltsp-server, etc. would need to be removed
| |
| 05:42 | alkisg: i might be able to upload an ltsp5 source package that takes over all the other binary packages, and then upload ltsp19 as ltsp
| |
| 05:42 | <alkisg> Aaaah that would be awesome
| |
| 05:42 | It would allow ubuntu 20.04 users to choose
| |
| 05:43 | And after that, we can drop ltsp5 whenever we want
| |
| 05:43 | <vagrantc> probably the order would be upload ltsp to experimental, upload ltsp5 to unstable, upload ltsp to unstable
| |
| 05:43 | * alkisg bows to vagrantc's experience on these matters | |
| 05:43 | <vagrantc> and eventually ask for ltsp5 removal
| |
| 05:43 | alkisg: glad i'm good for something :)
| |
| 05:43 | <alkisg> You're awesome for a lot of things :)
| |
| 05:43 | <vagrantc> heh
| |
| 05:44 | i make a great rubber ducky
| |
| 05:44 | it might end up being more complicated than the above (something might land in NEW for review)
| |
| 05:45 | <alkisg> vagrantc: would it allow buster-backports to get ltsp19?
| |
| 05:45 | <vagrantc> yes, eventually
| |
| 05:45 | <alkisg> That's great too
| |
| 05:46 | <vagrantc> i think no matter what, i can start by uploading ltsp to experimental
| |
| 05:46 | <alkisg> OK, on to writing that gsoc deliverable/release announcement... as always, thanks for your thoughts! :)
| |
| 05:48 | <vagrantc> look forward to waking up to the news :)
| |
| 05:48 | * vagrantc waves | |
| 05:48 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 07:23 | <alkisg> To all: this is an example of a new lts.conf: https://termbin.com/ii8t
| |
| 07:23 | Can someone read it and tell me if the new section organization is understandable? It's powerful, but I'm not sure if it's understandable... :D
| |
| 07:23 | E.g. if you can answer this quiz question, it's fine: "what is the equivalent of the [Default] section now?"
| |
| 07:29 | woernie has joined IRC (woernie!~werner@vpn23b.hotsplots.net) | |
| 08:17 | <quinox> I'd say [client/]
| |
| 08:18 | I suppose this means [server] [client] [common] refer to machines with server/client/common as hostname
| |
| 08:24 | woernie has left IRC (woernie!~werner@vpn23b.hotsplots.net, Remote host closed the connection) | |
| 09:28 | ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 09:29 | <alkisg> quinox: right, that was the initial idea, and also so that they're similar to applet/host, e.g. [initrd-bottom/pc01] would be evaluated at the initrrd-bottom phase, but only on pc01,
| |
| 09:29 | but... I'm thinking maybe it's better to avoid the slashes there and just use [server] [client] [common]; if someone really wants to name his client "client", eh, it'll just source that section, no big deal...
| |
| 09:29 | ogra has joined IRC (ogra!~ogra_@ubuntu/member/ogra) | |
| 09:29 | * alkisg simplifies the example ltsp.conf accordingly... | |
| 09:29 | <alkisg> Thanks :)
| |
| 09:39 | Simplified result: https://termbin.com/38pl
| |
| 09:49 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 13:27 | <alkisg> !ltsp-image
| |
| 13:27 | <ltsp> I do not know about 'ltsp-image', but I do know about these similar topics: 'ltsp-ipxe'
| |
| 13:27 | <alkisg> !ltsp-ipxe
| |
| 13:27 | <ltsp> ltsp-ipxe: Install iPXE binaries and configuration in TFTP: https://github.com/ltsp/ltsp/blob/master/man/ltsp-ipxe.8.md
| |
| 13:27 | <alkisg> !forget ltsp-ipxe
| |
| 13:27 | <ltsp> The operation succeeded.
| |
| 13:27 | <alkisg> !ltsp.conf
| |
| 13:27 | <ltsp> I do not know about 'ltsp.conf', but I do know about these similar topics: 'lts.conf'
| |
| 13:27 | <alkisg> !learn ltsp.conf as Configuration file for LTSP: https://github.com/ltsp/ltsp/blob/master/docs/ltsp.conf.5.md
| |
| 13:27 | <ltsp> The operation succeeded.
| |
| 13:27 | <alkisg> !ltsp-dnsmasq
| |
| 13:27 | <ltsp> ltsp-dnsmasq: Configures dnsmasq for LTSP: https://github.com/ltsp/ltsp/blob/master/man/ltsp-dnsmasq.8.md
| |
| 13:28 | <alkisg> !forget ltsp-dnsmasq
| |
| 13:28 | <ltsp> The operation succeeded.
| |
| 13:28 | <alkisg> !learn ltsp-dnsmasq as Configure dnsmasq for LTSP: https://github.com/ltsp/ltsp/blob/master/docs/ltsp-dnsmasq.8.md
| |
| 13:28 | <ltsp> The operation succeeded.
| |
| 13:28 | <alkisg> !ltsp
| |
| 13:28 | <ltsp> ltsp: LTSP is the Linux Terminal Server Project, the open source thin/fat client solution. You can find it at http://www.ltsp.org
| |
| 13:28 | <alkisg> !forget ltsp
| |
| 13:28 | <ltsp> The operation succeeded.
| |
| 13:29 | <alkisg> !learn ltsp as LTSP is the Linux Terminal Server Project, the open source thin/fat client solution. You can find it at https://ltsp.github.io
| |
| 13:29 | <ltsp> The operation succeeded.
| |
| 13:29 | <alkisg> !learn ltsp.8 as Entry point to Linux Terminal Server Project applets: https://github.com/ltsp/ltsp/blob/master/docs/ltsp.8.md
| |
| 13:29 | <ltsp> The operation succeeded.
| |
| 13:29 | <alkisg> !ltsp-image
| |
| 13:29 | <ltsp> Error: "ltsp-image" is not a valid command.
| |
| 13:30 | <alkisg> !learn ltsp-image as Generate a squashfs image from an image source: https://github.com/ltsp/ltsp/blob/master/docs/ltsp-image.8.md
| |
| 13:30 | <ltsp> The operation succeeded.
| |
| 13:30 | <alkisg> !ltsp-info
| |
| 13:30 | <ltsp> ltsp-info: please run ltsp-info and paste the output to https://pastebin.com and post the link here
| |
| 13:30 | <alkisg> !forget ltsp-info
| |
| 13:30 | <ltsp> The operation succeeded.
| |
| 13:31 | <alkisg> !learn ltsp-info as Gather support information about the LTSP installation: https://github.com/ltsp/ltsp/blob/master/docs/ltsp-info.8.md - To show us that info, run this and tell us the URL: sudo ltsp info | nc termbin.com 9999
| |
| 13:31 | <ltsp> Error: "nc" is not a valid command.
| |
| 13:32 | <alkisg> !learn ltsp-info as `Gather support information about the LTSP installation: https://github.com/ltsp/ltsp/blob/master/docs/ltsp-info.8.md - To show us that info, run this and tell us the URL: sudo ltsp info | nc termbin.com 9999`
| |
| 13:32 | <ltsp> The operation succeeded.
| |
| 13:32 | <alkisg> !ltsp-info
| |
| 13:32 | <ltsp> ltsp-info: (#1) Gather support information about the LTSP installation: https://github.com/ltsp/ltsp/blob/master/docs/ltsp-info.8.md - To show us that info, run this and tell us the URL: sudo ltsp info, or (#2) Gather support information about the LTSP installation: https://github.com/ltsp/ltsp/blob/master/docs/ltsp-info.8.md - To show us that info, run this and tell us the URL: sudo ltsp info | nc termbin.com 9999
| |
| 13:32 | <alkisg> !forget ltsp-info 1
| |
| 13:32 | <ltsp> The operation succeeded.
| |
| 13:32 | <alkisg> !ltsp-info
| |
| 13:32 | <ltsp> ltsp-info: Gather support information about the LTSP installation: https://github.com/ltsp/ltsp/blob/master/docs/ltsp-info.8.md - To show us that info, run this and tell us the URL: sudo ltsp info | nc termbin.com 9999
| |
| 13:32 | <alkisg> !ltsp-initrd
| |
| 13:32 | <ltsp> ltsp-initrd: Creates the ltsp.img initrd add-on: https://github.com/ltsp/ltsp/blob/master/man/ltsp-initrd.8.md
| |
| 13:32 | <alkisg> !forget ltsp-inird
| |
| 13:32 | <ltsp> Error: There is no such factoid.
| |
| 13:32 | <alkisg> !forget ltsp-initrd
| |
| 13:32 | <ltsp> The operation succeeded.
| |
| 13:33 | <alkisg> !learn ltsp-initrd as Create the ltsp.img initrd add-on: https://github.com/ltsp/ltsp/blob/master/docs/ltsp-initrd.8.md
| |
| 13:33 | <ltsp> The operation succeeded.
| |
| 13:33 | <alkisg> !ltsp-ipxe
| |
| 13:33 | <ltsp> I do not know about 'ltsp-ipxe', but I do know about these similar topics: 'ltsp-pnp', 'ltsp-image', 'ltsp-info', 'ltsp-pam', 'ltsp-site'
| |
| 13:33 | <alkisg> !learn ltsp-ipxe as Install iPXE binaries and configuration in TFTP: https://github.com/ltsp/ltsp/blob/master/docs/ltsp-ipxe.8.md
| |
| 13:33 | <ltsp> The operation succeeded.
| |
| 13:34 | <alkisg> !ltsp-kernel
| |
| 13:34 | <ltsp> Error: "ltsp-kernel" is not a valid command.
| |
| 13:34 | <alkisg> !learn ltsp-kernel as Copy the kernel and initrd from an image to TFTP: https://github.com/ltsp/ltsp/blob/master/docs/ltsp-kernel.8.md
| |
| 13:34 | <ltsp> The operation succeeded.
| |
| 13:34 | <alkisg> !ltsp-nfs
| |
| 13:34 | <ltsp> I do not know about 'ltsp-nfs', but I do know about these similar topics: 'ltsp-info'
| |
| 13:34 | <alkisg> !learn ltsp-nfs as Configure NFS exports for LTSP: https://github.com/ltsp/ltsp/blob/master/docs/ltsp-nfs.8.md
| |
| 13:34 | <ltsp> The operation succeeded.
| |
| 13:34 | <alkisg> !ltsp-
| |
| 13:34 | <ltsp> I do not know about 'ltsp-', but I do know about these similar topics: 'ltsp-upstream', 'ltsp-discuss', 'ltsp-developer', 'ltsp-update-image', 'ltsp-update-sshkeys', 'ltsp-sources', 'ltsp-bug', 'ltsp-update-kernels', 'ltsp-docs', 'ltsp-pnp-debian', 'ltsp-git', 'ltsp-manager', 'ltsp-manager-source', 'ltsp-config-bug', 'ltsp-source', 'ltsp-pnp', 'ltsp-pam', 'ltsp-login', 'ltsp-site', 'ltsp-wiki', 'ltsp-issues', 'ltsp- (1 more message)
| |
| 13:34 | <alkisg> !ltsp-upstream
| |
| 13:34 | <ltsp> ltsp-upstream: Comitters to the LTSP upstream branch on launchpad: https://launchpad.net/~ltsp-upstream
| |
| 13:34 | <alkisg> !forget ltsp-upstream
| |
| 13:34 | <ltsp> The operation succeeded.
| |
| 13:35 | <alkisg> !learn ltsp-upstream as LTSP development happens in https://github.com/ltsp
| |
| 13:35 | <ltsp> The operation succeeded.
| |
| 13:35 | <alkisg> !ltsp-sources
| |
| 13:35 | <ltsp> ltsp-sources: at https://code.launchpad.net/~ltsp-upstream/ltsp/
| |
| 13:35 | <alkisg> !forget ltsp-sources
| |
| 13:35 | <ltsp> The operation succeeded.
| |
| 13:35 | <alkisg> !ltsp-bug
| |
| 13:35 | <ltsp> ltsp-bug: To file a bug report for upstream LTSP, go to https://bugs.launchpad.net/ltsp
| |
| 13:36 | <alkisg> !forget ltsp-bug
| |
| 13:36 | <ltsp> The operation succeeded.
| |
| 13:36 | <alkisg> !learn ltsp-issue as To file an LTSP issue: https://github.com/ltsp/ltsp/issues
| |
| 13:36 | <ltsp> The operation succeeded.
| |
| 13:36 | <alkisg> !ltsp-pam
| |
| 13:36 | <ltsp> ltsp-pam: The new focus for LTSP client authentication: documentation: http://wiki.ltsp.org/wiki/Dev:LTSPPamNotes, code: https://git.launchpad.net/~ltsp-upstream/ltsp/+git/ltsp-pam
| |
| 13:36 | <alkisg> !forget ltsp-pam
| |
| 13:36 | <ltsp> The operation succeeded.
| |
| 13:37 | <alkisg> !ltsp-issues
| |
| 13:37 | <ltsp> ltsp-issues: https://github.com/ltsp/ltsp/issues is where you file bug reports or feature requests that can be addressed from the LTSP code base. See also !community-issues for more general LTSP questions or discussions
| |
| 13:37 | <alkisg> !forget ltsp-issue
| |
| 13:37 | <ltsp> The operation succeeded.
| |
| 13:37 | <alkisg> !ltsp-git
| |
| 13:37 | <ltsp> ltsp-git: https://code.launchpad.net/~ltsp-upstream/+git
| |
| 13:37 | <alkisg> !forget ltsp-git
| |
| 13:37 | <ltsp> The operation succeeded.
| |
| 13:37 | <alkisg> !forget ltsp-pnp
| |
| 13:37 | <ltsp> The operation succeeded.
| |
| 13:37 | <alkisg> !ltsp-site
| |
| 13:37 | <ltsp> ltsp-site: the main ltsp site is https://ltsp.github.io; now it's just an index of resources, but it'll be updated later on, so use that when you want to link to ltsp19+
| |
| 13:37 | <alkisg> ltsp-
| |
| 13:37 | !ltsp-
| |
| 13:37 | <ltsp> I do not know about 'ltsp-', but I do know about these similar topics: 'ltsp-discuss', 'ltsp-developer', 'ltsp-update-image', 'ltsp-update-sshkeys', 'ltsp-update-kernels', 'ltsp-docs', 'ltsp-pnp-debian', 'ltsp-manager', 'ltsp-manager-source', 'ltsp-config-bug', 'ltsp-source', 'ltsp-login', 'ltsp-site', 'ltsp-wiki', 'ltsp-issues', 'ltsp-dnsmasq', 'ltsp-image', 'ltsp-info', 'ltsp-initrd', 'ltsp-ipxe', 'ltsp-kernel', 'ltsp- (1 more message)
| |
| 13:37 | <alkisg> !more
| |
| 13:37 | <ltsp> nfs', 'ltsp-upstream'
| |
| 13:51 | <alkisg> !learn announcements as To subscribe to LTSP announcements: https://github.com/ltsp/ltsp/issues/1
| |
| 13:51 | <ltsp> The operation succeeded.
| |
| 14:32 | woernie has joined IRC (woernie!~werner@vpn23b.hotsplots.net) | |
| 15:57 | statler has joined IRC (statler!~Georg@p5489731F.dip0.t-ipconnect.de) | |
| 16:33 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 16:57 | <alkisg> vagrantc: how's your git-fu? I want to do a pull-request from github:gsoc2019 to github:ltsp, and end up with a squashed merge. I.e. github:ltsp should only have a single commit.
| |
| 16:58 | Currently these two repos are identical; and git doesn't allow me to undo all history and do a pull request... and if I create a new repo, I'm afraid it won't have any common history and it won't allow me to do a PR..
| |
| 16:59 | <vagrantc> i would create a new branch locally, squash it, and merge the new branch
| |
| 17:00 | and if needed, rename a branch
| |
| 17:00 | <alkisg> vagrantc: you mean without a pull request? Isn't that the same as just copying the files and doing an "initial commit" thing?
| |
| 17:00 | <vagrantc> ah, both repositories have no history?
| |
| 17:01 | no history you don't intend to squash away?
| |
| 17:01 | <alkisg> Currently both have 3 months of history, they're identical
| |
| 17:01 | I want to make git:ltsp empty, like if it has not history at all,
| |
| 17:01 | and then merge git:gsoc in a single commit to git:ltsp
| |
| 17:01 | In the end, git:ltsp should have one commit
| |
| 17:01 | <vagrantc> don't know how to do that with github, just from the commandline
| |
| 17:01 | <alkisg> How would you do it?
| |
| 17:02 | (say it with more words :D)
| |
| 17:03 | <vagrantc> i'd just fiddle with it till i got what i wanted ... but probably start out with "git branch ltsp-new ; git rebase --squash INITIAL_COMMIT"
| |
| 17:03 | <alkisg> Thanks, googling about that rebase/squash...
| |
| 17:04 | <vagrantc> not sure it even works :)
| |
| 17:05 | there's also "git rebase -i" and then replace all but the first "pick" with "fixup"
| |
| 17:27 | * alkisg gives up and just copies the files into an initial commit :/ | |
| 17:28 | <alkisg> Github considers the repositories unrelated, not forks, so it doesn't allow pull requests
| |
| 17:43 | pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv) | |
| 17:43 | pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Read error: Connection reset by peer) | |
| 17:43 | pavars has joined IRC (pavars!~pavars@105.235.144.22) | |
| 17:59 | <quinox> I think that's a git thing, you need at least 1 commit shared between both
| |
| 18:00 | if you squash everything until you only have 1 commit left you'll destroy the shared commit
| |
| 18:12 | pavars_ has joined IRC (pavars_!~pavars@balticom-198-107.balticom.lv) | |
| 18:13 | <alkisg> quinox: I think it's more than that; I think they have an internal "git uuid", and it's already different
| |
| 18:15 | pavars has left IRC (pavars!~pavars@105.235.144.22, Ping timeout: 244 seconds) | |
| 18:19 | pavars has joined IRC (pavars!~pavars@105.235.144.22) | |
| 18:23 | pavars_ has left IRC (pavars_!~pavars@balticom-198-107.balticom.lv, Ping timeout: 268 seconds) | |
| 18:32 | <alkisg> ...announcement sent :)
| |
| 18:32 | https://github.com/ltsp/community/issues/4
| |
| 18:34 | * vagrantc cheers | |
| 18:51 | <quinox> awesome
| |
| 19:02 | shored has left IRC (shored!~shored@87-92-64-8.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 19:02 | shored has joined IRC (shored!~shored@87-92-64-8.bb.dnainternet.fi) | |
| 19:11 | shored has left IRC (shored!~shored@87-92-64-8.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 19:11 | shored has joined IRC (shored!~shored@87-92-64-8.bb.dnainternet.fi) | |
| 19:52 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 20:01 | statler has left IRC (statler!~Georg@p5489731F.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 20:22 | pavars_ has joined IRC (pavars_!~pavars@balticom-198-107.balticom.lv) | |
| 20:23 | pavars__ has joined IRC (pavars__!~pavars@105.235.144.22) | |
| 20:24 | pavars has left IRC (pavars!~pavars@105.235.144.22, Ping timeout: 246 seconds) | |
| 20:26 | pavars_ has left IRC (pavars_!~pavars@balticom-198-107.balticom.lv, Ping timeout: 245 seconds) | |
| 20:34 | woernie has left IRC (woernie!~werner@vpn23b.hotsplots.net, Remote host closed the connection) | |
| 21:16 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 21:54 | pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv) | |
| 21:55 | pavars__ has left IRC (pavars__!~pavars@105.235.144.22, Read error: Connection timed out) | |
| 21:57 | kjackal has joined IRC (kjackal!~quassel@ppp-94-66-220-70.home.otenet.gr) | |
| 21:58 | pavars_ has joined IRC (pavars_!~pavars@105.235.144.22) | |
| 22:02 | pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Ping timeout: 272 seconds) | |
| 22:03 | kjackal has left IRC (kjackal!~quassel@ppp-94-66-220-70.home.otenet.gr, Ping timeout: 248 seconds) | |
| 22:11 | shored has left IRC (shored!~shored@87-92-64-8.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 22:11 | shored has joined IRC (shored!~shored@87-92-64-8.bb.dnainternet.fi) | |
| 22:11 | pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv) | |
| 22:13 | pavars__ has joined IRC (pavars__!~pavars@105.235.144.22) | |
| 22:13 | pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Read error: Connection reset by peer) | |
| 22:14 | pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv) | |
| 22:14 | pavars_ has left IRC (pavars_!~pavars@105.235.144.22, Ping timeout: 244 seconds) | |
| 22:15 | pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Remote host closed the connection) | |
| 22:16 | pavars has joined IRC (pavars!~pavars@105.235.144.22) | |
| 22:18 | pavars__ has left IRC (pavars__!~pavars@105.235.144.22, Ping timeout: 258 seconds) | |
| 23:11 | pavars has left IRC (pavars!~pavars@105.235.144.22, Ping timeout: 248 seconds) | |
| 23:14 | pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv) | |
| 23:21 | pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Ping timeout: 248 seconds) | |