00:31 | adrianorg has joined IRC (adrianorg!~adrianorg@186.213.159.184) | |
00:34 | adrianor1 has left IRC (adrianor1!~adrianorg@187.113.251.145, Ping timeout: 258 seconds) | |
02:27 | adrianor1 has joined IRC (adrianor1!~adrianorg@179.179.77.59) | |
02:30 | adrianorg has left IRC (adrianorg!~adrianorg@186.213.159.184, Ping timeout: 272 seconds) | |
02:51 | adrianor1 has left IRC (adrianor1!~adrianorg@179.179.77.59, Ping timeout: 258 seconds) | |
02:57 | adrianorg has joined IRC (adrianorg!~adrianorg@177.18.97.153) | |
03:19 | <vagrantc> alkisg: well, ltsp-build-client is biting again ... options for how to specify an unsigned apt repository have changed. :/
| |
03:20 | and now ltsp needs to be updated to handle it...
| |
03:20 | * vagrantc sighs | |
03:20 | <vagrantc> alkisg: mostly just more encouragement to keep moving forward! :)
| |
04:19 | <alkisg> Morning all!
| |
04:20 | vagrantc: I've been thinking, maybe this will work for both of us? I keep a packaging/debian dir upstream, and a symlink debian -> packaging/debian. Since I'll never touch the symlink, rebasing with upstream should be easy every time you need to do it, right?
| |
04:28 | (trying to see what I'll need to do in a couple of days/weeks when I'll need to upload to the PPA again, so that we won't have to go through it yet another time :))
| |
04:31 | <vagrantc> maybe
| |
04:31 | makes it a lot harder to cherry-pick your packaging changes, though
| |
04:32 | <alkisg> Should I try to keep the commits to packaging/debian separate from the respective code commits? Will that help?
| |
04:32 | (and to the fedora packaging etc)
| |
04:33 | <vagrantc> it just requires manual work to merge, rather than relying on git to handle what git is reasonably good at
| |
04:33 | <alkisg> Why? You can just merge ALL the commits, no need to cherry pick
| |
04:33 | You can discard the packaging folder why building
| |
04:34 | git merge start..end, where start==the last time you merged
| |
04:34 | The debian symlink will never be referenced there
| |
04:34 | <vagrantc> if you make a packaging change i want, then i have to manually merge it, git won't do it for me
| |
04:34 | <alkisg> Sure, but that will be true wherever I maintain the packaging
| |
04:35 | It's caused because you don't want a common collaborative debian folder; not by cvs
| |
04:35 | <vagrantc> if you maintained the packaging separately, i could just cherry-pick and/or merge
| |
04:35 | <alkisg> But don't you need to merge both upstream and packaging anyway?
| |
04:35 | Why does it help if they are 2 separate repositories?
| |
04:35 | *both code...
| |
04:35 | <vagrantc> upstream never conflicts and requires no thought to merge
| |
04:36 | <alkisg> It wouldn't conflict now either, since it'd use a different dir
| |
04:36 | <vagrantc> git merge v5.x -> done!
| |
04:36 | <alkisg> And then after you merge the code, in both cases, you need to cherrypick debian
| |
04:36 | No difference there either
| |
04:37 | <vagrantc> yes, but then i would have to look at what packaging changes you made and use the amazing vcs "cp" and loose history.
| |
04:37 | <alkisg> Because I would use a different path?
| |
04:37 | <vagrantc> you do make changes i think are worth merging the vast majority of the time
| |
04:38 | <alkisg> While if it were a separate repository, I'd use debian/, which would be in the same path?
| |
04:38 | *using
| |
04:38 | <vagrantc> yes, i can't "git cherry-pick packaging/debian into debian/"
| |
04:38 | but because it's git, i can just "git merge the whole branch, possibly.
| |
04:39 | <alkisg> That makes it very hard for upstream to manage packaging though; the history is split between repositories, and each commit can't reference the respective debian or fedora commit
| |
04:39 | So upstream history is hindered, just to keep a downstream debian history
| |
04:39 | I'd much rather prefer the loss of history using "cp" than to lose the upstream history
| |
04:40 | <vagrantc> this is well known
| |
04:40 | <alkisg> :D
| |
04:41 | To be clear, you'd still prefer packaging/debian upstream, vs debian/ folder upstream, right?
| |
04:41 | <vagrantc> not entirely sure.
| |
04:41 | which eye would you like the hot poker in?
| |
04:42 | i mean, i don't like either option, and you don't like the status quo
| |
04:42 | so ... here we are
| |
04:42 | <alkisg> For ltsp5, you've been the main contributor to debian/; of course I'll respect that, and do it your way; I'll use a different repository
| |
04:43 | For ltsp19 and epoptes, where I'll be the main contributor to debian/, I don't want to lose the main history in order to keep a downstream one,
| |
04:43 | so ok we can postpone that decision until then...
| |
04:43 | <vagrantc> i get that ...
| |
04:44 | i wish dgit worked better, as that would solve most of this.
| |
04:44 | <alkisg> So for now I'll cp debian/ into a new repository in launchpad (I don't want the source there too); I'll lose all history; and I'll be maintaining that one
| |
04:45 | <vagrantc> you'd think git could be smart enough to implement a copy operation so history could be preserved
| |
04:46 | alkisg: out of all the workflows proposed ... separate debian dir was the most frustrating to me
| |
04:46 | but we have different aims
| |
04:47 | <alkisg> But if I'm maintaining the upstream debian/ dir, there's no point in having a temp copy of upstream code too
| |
04:47 | I'd have to spend hours to next contributors to explain why all this is done to cover some debian tool inefficiency
| |
04:48 | <vagrantc> what i like about the workflow i've been doing is it's clear what packaging changes are relevent to an upstream release ... but with builds not from tagged releases, that isn't as attractive and it makes sense to merge the packaging changes with the upstream changes
| |
04:48 | <alkisg> I think you're not using to having upstream contributors to the debian/ dir
| |
04:48 | It was distro-specific all along
| |
04:48 | *not used
| |
04:48 | <vagrantc> i've survived such scenarios and they formed my opinions :P
| |
04:48 | <alkisg> And a solo work too
| |
04:49 | E.g. if you had to maintain debian, ubuntu, kali, linuxmint etc releases, your workflow would change
| |
04:49 | Now you only focus on debian, while i focus in central maintenance
| |
04:49 | <vagrantc> perhaps
| |
04:50 | <alkisg> You wouldn't be able to have a "frozen debian dir" for months, while you'd need to do releases for other distros
| |
04:51 | <vagrantc> back when ltsp was more active, i did maintain multiple concurrent debian dirs for debian
| |
04:51 | <alkisg> And did you have a "master" one?
| |
04:51 | <vagrantc> and it was so nice once i settled on this workflow
| |
04:51 | <alkisg> Or was "master == sid"?
| |
04:51 | <vagrantc> debian/master is typically sid or experimental, whichever is newest
| |
04:52 | <alkisg> But now you have master=buster, while ppa (considering it another distro temporarily) needs to release, hence the issue
| |
04:52 | <vagrantc> typically fork off a debian/CODENAME branch around the time of the freezes, depending on upsteam release cycles
| |
04:53 | <alkisg> I.e. you don't allow for a collaborative debian branch, where all maintainers can contribute, and distro-maintainers can then fork when they have releases or need to backport patches
| |
04:53 | It's because you were only doing solo work, without debian/ contributors
| |
04:53 | <vagrantc> haven't had a project where people didn't balk at debian policy requirements
| |
04:54 | mostly, sure
| |
04:54 | <alkisg> I find debian policy well written and a means to increase software quality
| |
04:55 | <vagrantc> i mostly haven't had much time and energy for this particular project as a volunteer, either
| |
04:55 | could change, as it gets exciting again
| |
04:55 | so workflows that don't increase my workload and how i spend my free time also have value
| |
04:56 | <alkisg> True; but imposing twice as much work to people that maintain upstream packaging isn't good for development either
| |
04:56 | OK to sum up and leave it behind, around July we'll need to decide if ltsp19 will have debian/ or packaging/debian.
| |
04:56 | For now, I'll just do that debian/ repository in launchpad
| |
04:57 | * alkisg puts aside all those hard negotiations and tries to get some coding done! :) | |
04:57 | <vagrantc> just stick it in debian for now
| |
04:57 | <alkisg> I can't; I can't build the recipes
| |
04:57 | <vagrantc> for ltsp19 ?
| |
04:57 | <alkisg> I'd have to undo your commits to build
| |
04:57 | Ah sorry
| |
04:57 | <vagrantc> i'm not touching it
| |
04:57 | <alkisg> I though you were talking about ltsp5
| |
04:57 | OK, great
| |
04:57 | <vagrantc> yeah, ltsp5, let's be more cautious
| |
04:58 | <alkisg> OK, for ltsp19 I'll start with debian/, in a month or so when I'll be ready,
| |
04:58 | for ltsp5, a debian/ repository in launchpad
| |
04:58 | <vagrantc> for me, having upstream code and packaging in the same branch is so much less painful than a packaging-only branch
| |
04:59 | so i'll figure out a way to manage it
| |
04:59 | presuming i'm still around :)
| |
04:59 | <alkisg> Let's hope so :)
| |
05:00 | <vagrantc> might swear off computers, never know :)
| |
05:08 | <alkisg> vagrantc: ...although now ltsp-client will need to be inherently cross-distro, as the same ltsp.img will be used in all distros
| |
05:09 | Even if that means adding "if distro == xx then else" in the code
| |
05:09 | <vagrantc> that's going to be very interesting...
| |
05:12 | <alkisg> Btw, go-md2man doesn't align options properly; but OK no big deal... https://github.com/cpuguy83/go-md2man/issues/45
| |
05:13 | Whoops, this link instead: https://github.com/cpuguy83/go-md2man/issues/27
| |
05:26 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
05:30 | * vagrantc isn't too fussy about manpages, but ok | |
05:34 | * vagrantc waves | |
05:34 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
05:35 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3106:1000:a895:839f:87b0:61d8) | |
06:03 | os_a has joined IRC (os_a!~Thunderbi@195.112.116.22) | |
07:25 | woernie has joined IRC (woernie!~werner@p57A0E866.dip0.t-ipconnect.de) | |
07:53 | statler has joined IRC (statler!~Georg@gwrz.lohn24.de) | |
08:40 | josefig has left IRC (josefig!~josefig@unaffiliated/josefig, Ping timeout: 244 seconds) | |
08:53 | zavag has joined IRC (zavag!506ab707@ouxe21.static.otenet.gr) | |
08:53 | <zavag> alkisg καλημέρα
| |
08:53 | <alkisg> Καλημέρα zavag
| |
08:54 | Κάνε λίγο vnc να δω:
| |
08:54 | !vnc-edide
| |
08:54 | <ltsp> vnc-edide: To share your screen with me, open Epoptes → Help menu → Remote support → Host: srv1-dide.ioa.sch.gr, and click the Connect button
| |
08:55 | <zavag> δεν τρεχει ...
| |
08:56 | <alkisg> Δοκίμασε αυτό:
| |
08:56 | !vnc-dide
| |
08:56 | <ltsp> vnc-dide: To share your screen with me, run this: sudo apt-get --yes install x11vnc; x11vnc -connect srv1-dide.ioa.sch.gr - this is a reverse connection, it doesn't need port forwarding etc.
| |
08:56 | <alkisg> x11vnc -noshm -connect srv1-dide.ioa.sch.gr
| |
08:56 | Σκέτο αυτό ^
| |
09:55 | zavag has left IRC (zavag!506ab707@ouxe21.static.otenet.gr) | |
11:40 | spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut) | |
11:48 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
11:53 | woernie has left IRC (woernie!~werner@p57A0E866.dip0.t-ipconnect.de, Ping timeout: 258 seconds) | |
11:53 | woernie has joined IRC (woernie!~werner@p57A0E866.dip0.t-ipconnect.de) | |
12:14 | josefig has joined IRC (josefig!~josefig@unaffiliated/josefig) | |
14:16 | <uumas> I'm also using nfs3 for homedirs and going to switch to kerberized nfs4 soon, so lmk if some help is needed to test it
| |
14:19 | There are also a few schools around here using opisys/puavo ltsp
| |
14:33 | kjackal has left IRC (kjackal!~quassel@2a02:587:3106:1000:a895:839f:87b0:61d8, Ping timeout: 258 seconds) | |
14:33 | kjackal has joined IRC (kjackal!~quassel@ppp-2-86-50-83.home.otenet.gr) | |
14:43 | <alkisg> uumas: thanks; ltsp19 won't have any integrated support for nfs4/kerberos, but what would need testing is, that it will work once the user has set up nfs4/kerberos/ldap by himself
| |
14:44 | If someone can write a small how to, I could do the initial testing + preparation myself, and once I have something running, make it public for more testing
| |
14:44 | re: puavo, since ltsp19 will be a rewrite, if they rely on upstream ltsp, they'll need to update their codebase somewhat
| |
14:47 | <uumas> I already have freeipa (ldap+kerberos) setup and am going to reinstall our nfs server (running freebsd 10) with debian and set it up to use kerberos.
| |
14:47 | Will see how that works then
| |
14:49 | I guess opinsys are aware of ltsp19 already (I'm sure they follow the mailing lists), but based on past experience with them I believe they may take more than a year to switch over.
| |
15:09 | josefig has left IRC (josefig!~josefig@unaffiliated/josefig, Quit: Ping timeout (120 seconds)) | |
15:12 | josefig has joined IRC (josefig!~josefig@unaffiliated/josefig) | |
16:49 | kjackal has left IRC (kjackal!~quassel@ppp-2-86-50-83.home.otenet.gr, Ping timeout: 246 seconds) | |
17:04 | statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection) | |
17:40 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
18:51 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3106:1000:a895:839f:87b0:61d8) | |
19:41 | kjackal has left IRC (kjackal!~quassel@2a02:587:3106:1000:a895:839f:87b0:61d8, Ping timeout: 258 seconds) | |
19:41 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3106:1000:a895:839f:87b0:61d8) | |
20:11 | woernie has left IRC (woernie!~werner@p57A0E866.dip0.t-ipconnect.de, Remote host closed the connection) | |
20:53 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
21:41 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
21:45 | kjackal has left IRC (kjackal!~quassel@2a02:587:3106:1000:a895:839f:87b0:61d8, Ping timeout: 252 seconds) | |
23:43 | GodFather has left IRC (GodFather!~rcc@143.59.184.72, Ping timeout: 258 seconds) | |