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 18 August 2019   (all times are UTC)

01:29jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Remote host closed the connection)
01:35jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
03:56vagrantc 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:20ogra 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:21ogra_ 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:31adrianorg 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:33adrianor1 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:48vagrantc 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:29woernie 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:24woernie has left IRC (woernie!~werner@vpn23b.hotsplots.net, Remote host closed the connection)
09:28ogra_ 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:29ogra 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:49ricotz 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:32woernie has joined IRC (woernie!~werner@vpn23b.hotsplots.net)
15:57statler has joined IRC (statler!~Georg@p5489731F.dip0.t-ipconnect.de)
16:33vagrantc 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:43pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv)
17:43pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Read error: Connection reset by peer)
17:43pavars 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:12pavars_ 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:15pavars has left IRC (pavars!~pavars@105.235.144.22, Ping timeout: 244 seconds)
18:19pavars has joined IRC (pavars!~pavars@105.235.144.22)
18:23pavars_ 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:02shored has left IRC (shored!~shored@87-92-64-8.bb.dnainternet.fi, Read error: Connection reset by peer)
19:02shored has joined IRC (shored!~shored@87-92-64-8.bb.dnainternet.fi)
19:11shored has left IRC (shored!~shored@87-92-64-8.bb.dnainternet.fi, Read error: Connection reset by peer)
19:11shored has joined IRC (shored!~shored@87-92-64-8.bb.dnainternet.fi)
19:52vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
20:01statler has left IRC (statler!~Georg@p5489731F.dip0.t-ipconnect.de, Remote host closed the connection)
20:22pavars_ has joined IRC (pavars_!~pavars@balticom-198-107.balticom.lv)
20:23pavars__ has joined IRC (pavars__!~pavars@105.235.144.22)
20:24pavars has left IRC (pavars!~pavars@105.235.144.22, Ping timeout: 246 seconds)
20:26pavars_ has left IRC (pavars_!~pavars@balticom-198-107.balticom.lv, Ping timeout: 245 seconds)
20:34woernie has left IRC (woernie!~werner@vpn23b.hotsplots.net, Remote host closed the connection)
21:16ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:54pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv)
21:55pavars__ has left IRC (pavars__!~pavars@105.235.144.22, Read error: Connection timed out)
21:57kjackal has joined IRC (kjackal!~quassel@ppp-94-66-220-70.home.otenet.gr)
21:58pavars_ has joined IRC (pavars_!~pavars@105.235.144.22)
22:02pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Ping timeout: 272 seconds)
22:03kjackal has left IRC (kjackal!~quassel@ppp-94-66-220-70.home.otenet.gr, Ping timeout: 248 seconds)
22:11shored has left IRC (shored!~shored@87-92-64-8.bb.dnainternet.fi, Read error: Connection reset by peer)
22:11shored has joined IRC (shored!~shored@87-92-64-8.bb.dnainternet.fi)
22:11pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv)
22:13pavars__ has joined IRC (pavars__!~pavars@105.235.144.22)
22:13pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Read error: Connection reset by peer)
22:14pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv)
22:14pavars_ has left IRC (pavars_!~pavars@105.235.144.22, Ping timeout: 244 seconds)
22:15pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Remote host closed the connection)
22:16pavars has joined IRC (pavars!~pavars@105.235.144.22)
22:18pavars__ has left IRC (pavars__!~pavars@105.235.144.22, Ping timeout: 258 seconds)
23:11pavars has left IRC (pavars!~pavars@105.235.144.22, Ping timeout: 248 seconds)
23:14pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv)
23:21pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Ping timeout: 248 seconds)