x2go-commits September 2017

x2go-commits@lists.x2go.org

3 participants
165 discussions

[[X2Go Wiki]] page changed: 2017-09:day-2017-09-28
by wiki-admin＠x2go.org 28 Sep '17

28 Sep '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/09/28 20:53 Browser : Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 IP-Address : 178.162.222.163 Hostname : 178.162.222.163.adsl.inet-telecom.org Old Revision: https://wiki.x2go.org/doku.php/2017-09:day-2017-09-28?rev=1506623794 New Revision: https://wiki.x2go.org/doku.php/2017-09:day-2017-09-28 Edit Summary: Add raw chat log. User : ionic @@ -124,8 +124,372 @@ … [View More]required Documentation for testers -> Should be as simple as updating sources.list to a heuler+timestamp entry and running update, upgrade, dist-upgrade </code> ==== Raw Chat Log ==== - FIXME + <file> - ...log... + [20:38:02] < h1mg> OK, first Topic on the List: X2GoServer code updates in preparation of the upcoming release + [20:38:45] < h1mg> Who is the author of this topic? + [20:39:00] <@MeinNameIstRetro> h1mg: I guess I will just do the introductions + [20:39:13] < mikedep333> Is this 4.0.1.21 or 4.1.0.0? + [20:39:18] < h1mg> MeinNameIstRetro: go for it! + [20:39:43] <@MeinNameIstRetro> mikedep333: I'd actually love to call it 5.0.0.0, but the version number is the least of our issues. ;) + [20:39:44] <@Ionic> that's a good question + [20:39:58] < mikedep333> MeinNameIstRetro: Regardless of the version number, we have to branches. + [20:40:16] < mikedep333> release/4.0.1.x is 4.0.1.21 + [20:40:18] <@MeinNameIstRetro> So. We're aiming for a release by early December, so we can release in time for the Ubuntu 18.04 LTS freeze. + [20:40:24] < mikedep333> master is 4.1.0.0 + [20:40:37] <@MeinNameIstRetro> Of course, if we can get the release out sooner, that's even better. + [20:40:55] < mikedep333> I really want to shore up support for GNOME Flashback before then. + [20:41:18] <@MeinNameIstRetro> To keep track of the release status, I would suggest creating a "master bug" and have the other release-critical bugs added as blockers to this bug. + [20:41:37] < mikedep333> It relies on sysadmins disabling GLX in /etc/x2go/x2goagent.options but still. + [20:42:04] <@MeinNameIstRetro> Thing is, I'm not exactly skilled with our bugtracker. So can I assign creating these bugs to Ionic, or do we have another volunteer? + [20:43:03] < h1mg> *silence* -> I assume nobody? + [20:43:05] <@Ionic> that's quite easily done (a normal bug report with others set to block it AFAIK) + [20:43:31] <@Ionic> but the real question is whether you'd like to have 4.0.1.x or 4.1.0.0 released + [20:43:49] <@MeinNameIstRetro> I see that we have changes in Xinerama, plus several new features: "Keyboard Cloning", "Auto-Grab", "Input Lock" + [20:43:50] <@Ionic> arctica's nx-libs is only compatible with 4.1.0.0 so far + [20:43:56] < h1mg> Ionic: as it is a feature update and not only maintainance... + [20:44:06] < mikedep333> Ionic: Arctica's nx-libs is what's in debian & ubuntu. + [20:44:16] <@MeinNameIstRetro> Ionic: I want Arctica NX-Libs and thus I'd say 4.1.0.0 + [20:44:41] <@Ionic> so two releases then + [20:44:51] < mikedep333> brb + [20:44:51] <@MeinNameIstRetro> Ionic: Explain? + [20:45:06] <@Ionic> since there are still unreleased fixes (and fixes that don't really fix issues yet) in the current 4.1.0.x branch + [20:45:55] <@MeinNameIstRetro> Ionic: I don't think I understand what you're trying to tell me ... + [20:45:57] <@Ionic> keyboard cloning, autograb and input lock are currently WIP features that aren't part of arctica's nx-libs (neither release nor nightly builds) + [20:46:30] <@MeinNameIstRetro> Ionic: Yes, and the goal would be to get them ready by early December 2017, if not sooner, so we can include them. + [20:47:02] <@MeinNameIstRetro> Is uli421 "our" Uli? + [20:48:00] <@Ionic> the current release branch of x2goserver is 4.0.1.20 - and since then, other changes accumulated that I'd like to get out as 4.0.1.21 (which would probably also go with mikedep333's GNOME support changes) + [20:48:21] <@Ionic> yes, he is + [20:48:36] <@Ionic> note that the autograb feature is currently broken + [20:48:43] <@MeinNameIstRetro> I see, so 4.0.1.21 would be using NX-Libs "classic"? + [20:48:43] <@Ionic> at least with certain window managers + [20:48:49] <@Ionic> yeah + [20:49:03] <@MeinNameIstRetro> I think I'm beginning to understand ;) + [20:49:14] <@Ionic> but releasing it wouldn't take a lot of effort + [20:49:29] <@Ionic> well, maybe on mikedep333's part + [20:49:30] <@MeinNameIstRetro> So what would be a realistic time frame to release 4.0.1.21? + [20:49:36] <@MeinNameIstRetro> mikedep333: ? + [20:50:22] <@Ionic> there is one bug (the systemd session bug) that I've made a commit for, but I'm not convinced it really fixes the bug *shrug* + [20:51:01] <@MeinNameIstRetro> Ionic: Who reported the bug? + [20:51:02] <@Ionic> in any case, it would be stupid to not release the current changes before a big feature release + [20:51:31] <@Ionic> AFAIK Orion as a downstream maintainer + [20:51:56] <@Ionic> oh no, somebody else entirely, but he's also been getting bug reports for that + [20:51:57] <@Ionic> https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1198 + [20:52:07] <@MeinNameIstRetro> Ionic: I'd say it would make sense to set up those snapshotted repos ASAP. That way you can point testers at a point in time for a test, that doesn't change as you continue working on the code + [20:53:21] <@MeinNameIstRetro> Ionic: So, set up the snapshot repos, point the bug submitter at the snapshot repo that should contain the fix, have them report back + [20:53:27] < mikedep333> WRT 1198, the user said he deleted the line. If that is the default behavior, then deleting it is insufficient. + [20:53:46] <@Ionic> there are currently not builds for 4.0.1.x anyway, other than the release builds + [20:53:58] < mikedep333> https://www.freedesktop.org/software/systemd/man/logind.conf.html Defaults to "yes" + [20:54:04] <@Ionic> deleting what line? + [20:54:33] < mikedep333> KillUserProcesses + [20:54:34] <@MeinNameIstRetro> Ionic: So heuler doesn't point at what approximates 4.0.1.x? + [20:54:42] <@Ionic> no + [20:54:49] <@Ionic> it points at 4.1.0.0 + [20:55:18] < mikedep333> Actually, never mind. + [20:55:23] < mikedep333> The user said he did set it to "no" + [20:55:23] <@Ionic> mikedep333: loginctl enable-linger seems to have worked for him + [20:55:43] <@Ionic> we can't change KillUserProcesses directly since that's a global configuration option + [20:56:10] <@Ionic> we can only try to disable it on a case-by-case basis via the lingering feature + [20:56:30] <@Ionic> but of course, system administrators can disable this very feature, in which case x2go sessions will still be terminated + [20:56:40] <@Ionic> but I guess that's their problem then + [20:56:57] <@MeinNameIstRetro> Ionic: but we could detect if the admin disabled it and warn the user? + [20:57:09] < mikedep333> Never mind, I didn't read the entire convo. + [20:57:18] < mikedep333> MeinNameIstRetro: We need a warning system in general. + [20:57:33] < mikedep333> For example, if we aren't going to disable GLX for GNOME Flashback, then we need to warn users to disable it. + [20:57:37] <@MeinNameIstRetro> Danger, mikedep robinson! + [20:57:53] < h1mg> Alex is not online? + [20:57:59] < mikedep333> Implementing a warning system means picking a graphical toolkit or utility like zenity though. + [20:58:01] <@Ionic> neither is sunweaver + [20:58:07] <@MeinNameIstRetro> h1mg: He's on vacation, is he not? + [20:58:10] < mikedep333> NX used xdialog IIRC. + [20:58:27] <@Ionic> right - and it requires an already running X server + [20:58:39] < h1mg> MeinNameIstRetro: yes in france - i forgotten that + [20:59:07] <@MeinNameIstRetro> Ionic: Hmm, I can see sunweaver in the list and he's not tagged as away + [20:59:09] <@Ionic> it doesn't make sense to warn in that case since we'd need the functionality before even starting nxagent, which makes it overly complicated to pass around + [20:59:18] * MeinNameIstRetro pokes sunweaver + [20:59:33] <@Ionic> he's been away for 13 hours + [20:59:39] <@Ionic> or at least idle + [21:00:04] <@MeinNameIstRetro> Ionic: Is there no way to trigger a client-side popup from within x2goclient? + [21:00:07] < h1mg> yes - xmessage would be unsufficiant... + [21:00:21] <@Ionic> no, we don't have such a backchannel + [21:00:48] < mikedep333> I was thinking of a zenity message or custom message GUI within the session on the server. + [21:00:59] <@MeinNameIstRetro> Ionic: sunweaver showed me a command that would report X2GoServer's available features. No way of using that? + [21:01:15] <@MeinNameIstRetro> Ionic: (or something similar, at a similarly early stage) + [21:01:22] < h1mg> mikedep333: or an alert using freedesktop.org stuff? + [21:01:23] <@Ionic> that's a server-side CLI command that loops through files and prints it out + [21:01:49] <@Ionic> guys, we *don't have* that functionality yet + [21:02:10] <@Ionic> if you insist on it, the release won't happen any time soon + [21:02:12] < h1mg> Ionic: OK. Stop then. + [21:02:32] < h1mg> Ionic: go on + [21:02:42] < h1mg> :) + [21:02:51] < h1mg> this makes no sense :) + [21:03:12] < h1mg> sorry for that - /me should not using the kyeboard while thinking... + [21:03:24] <@Ionic> it sounds like a worthwhile addition but requires development + [21:04:16] < h1mg> will there be a api/command from mikes artica architecture? + [21:04:45] < h1mg> if this all is to far away: Get back on: What needs to be done? + [21:04:46] <@Ionic> my point probably is that I haven't heard of users telling me whether the current fix using loginctl enable-linger actually works + [21:05:28] <@Ionic> but since the user reported that setting that mode helped once, I guess that's good enough for me + [21:06:07] <@Ionic> arctica is supposed to provide a well-defined protocol (including for stuff like this) - X2Go doesn't have one + [21:06:34] <@MeinNameIstRetro> oh Ionic, quick question, do we have an x2go session log that ends up in the user homedir on the server? + [21:06:52] <@Ionic> define "session log" + [21:07:22] <@MeinNameIstRetro> Ionic: a file that remains in the user's homedir, at least when a session hasn't been terminated cleanly + [21:08:49] <@MeinNameIstRetro> Ionic: Because if we have such a file, or could create one easily, we could drop a notice into that when we're unable to suspend sessions due to a system administrator blocking it. + [21:09:25] <@MeinNameIstRetro> Ionic: So if a user complains that their sessions are terminating instead of suspending, we could tell them to post the content of that log or search for a certain message there. + [21:09:29] <@Ionic> server-side, we have the a.) syslog (verbosity defined in /etc/x2go/x2goserver.conf), b.) a session directory with some log files in ~/.x2go/, but mostly the nxagent log which mostly doesn't contain much information + - this stuff is being put in /tmp and symlinked to ~/.x2go with x2goserver 4.1.0.0 though, so it's not really "home dir"-based any longer and c.) the xsession file, which contains information from + [21:09:29] <@Ionic> a desktop session (iff the user started a desktop session) + [21:10:04] <@MeinNameIstRetro> so ~/.x2go/ sounds like a place where we could drop a warning notice. + [21:10:55] <@Ionic> though depending on the debug level this could be scrubbed by x2gocleansessions for terminated sessions, so the best option would be to log to syslog in x2go-suspend-session + [21:11:17] <@MeinNameIstRetro> Ionic: but regular users can't read syslog, can they? + [21:11:39] <@Ionic> that depends upon the system configuration + [21:12:06] <@Ionic> though typically not, no + [21:12:21] <@MeinNameIstRetro> Ionic: how does the "scrubber" in x2gocleansessions work? Could it be told not to remove the warning message? + [21:12:26] < h1mg> same with jouralctl + [21:12:43] <@Ionic> so in that case we probably don't have a user-accessible persistent log storage + [21:13:02] < h1mg> but I would search for the issuses in syslog/journalctl + [21:13:23] <@MeinNameIstRetro> how about just doing "touch ~/.x2go-session-suspend-unavailable"? + [21:14:18] <@Ionic> and how to you tell users to look for that file? + [21:14:19] <@MeinNameIstRetro> h1mg: yes, but you are an admin. We have got to consider people that aren't admins, merely users that expect suspend/resume to work $SOMEWHERE because that's what it does at their own installation at home. + [21:14:56] <@Ionic> hint: users typically don't read project announcements or wikis + [21:14:58] <@MeinNameIstRetro> Ionic: You tell them when they come to the ML or #x2go and complain about their suspend/resume not working, plus you put it in the FAQ + [21:15:03] < mikedep333> The simplest solution is to call zenity within the x2go session. + [21:15:30] <@Ionic> if they complain, we can tell them to check that on case-by-case basis + [21:15:35] <@MeinNameIstRetro> mikedep333: So we'd have to add a dependency for zenity + [21:15:43] < mikedep333> Yes + [21:15:59] < mikedep333> And put an option to disable it in /etc + [21:16:12] < mikedep333> https://pkgs.org/download/zenity + [21:16:14] <@MeinNameIstRetro> Ionic: I'd say touch a file in the homedir that doesn't get scrubbed + [21:16:20] < mikedep333> zenity seems universal nowadays + [21:16:23] < h1mg> Maybe we should spend some time on research: I really don't know if there is a official dbus freedesktop call for the running desktop? + [21:16:34] <@Ionic> and even that's not simple, since you need a working nxagent instance for this + [21:16:37] < h1mg> zenety would then be a requirement + [21:16:42] < mikedep333> yes, I know + [21:17:06] < mikedep333> Let me put it this way, it is the simplest for us to implement. + [21:17:40] <@MeinNameIstRetro> my gut feeling is that we need a simple, quick way to tell what's going on if someone comes to the ML or the channel and complains about sessions getting terminated. + [21:17:40] <@Ionic> the simpliest thing is to do nothing and handle bug reports by telling them to check if they disabled lingering support + [21:18:17] <@MeinNameIstRetro> Ionic: "touch ~/.x2go-session-suspend-unavailable" would be how much work? + [21:18:35] <@Ionic> well no could do that + [21:18:47] <@MeinNameIstRetro> ? + [21:20:40] <@Ionic> hm, although I can't find a way to disabling lingering right now + [21:21:20] <@Ionic> *disable + [21:22:23] <@Ionic> so I guess that makes the problem invalid anyway + [21:22:28] < h1mg> just tried: + [21:22:28] < h1mg> # notify-send "test" + [21:22:28] < h1mg> fopr a bubble + [21:22:32] <@Ionic> even better + [21:23:11] < h1mg> from package: Notify-OSD + [21:23:22] <@Ionic> h1mg: libnotify isn't useful - won't work for non-DE sessions + [21:23:35] < h1mg> Ionic: true... + [21:23:51] <@Ionic> but I just determined that it's a non-problem and we don't need this functionality anyway, since lingering can't be disabled + [21:25:00] < h1mg> ok; so the result for this topic would be? + [21:25:59] <@MeinNameIstRetro> ionic? + [21:26:00] <@Ionic> well, I'd like to release 4.0.1.21 at some point (maybe after mikedep333 gets his GNOME work done?) and then 4.1.0.0 will follow at a later point + [21:26:27] <@MeinNameIstRetro> okay, mikedep333 - any timeframe, ETA, on your intended fix/commit(s)? + [21:26:57] <@Ionic> 4.1.0.0 still needs changes to support the mentioned keyboard cloning, input lock features, but since they aren't part of nx-libs yet we're blocked anyway + [21:28:03] <@Ionic> and more importantly, before I can release 4.1.0.0, I need to make sure that an upgrade from 4.0.1.x to 4.1.0.0 works smoothly on all supported distros + [21:28:23] <@MeinNameIstRetro> Ionic: so it's important that we get 4.0.1.21 out asap + [21:28:57] <@Ionic> 4.0.1.21 isn't a big deal, just a bit time-consuming just like every release is + [21:29:22] <@Ionic> h1mg: task for you: come up with a new LTS name + [21:30:11] * MeinNameIstRetro pokes mikedep333 re: ETA + [21:30:47] < h1mg> mikedep333: are there "Phoca vitulina" near to your? -> coastline? + [21:30:50] < mikedep333> MeinNameIstRetro: Within a month. + [21:30:58] < h1mg> https://de.wikipedia.org/wiki/Datei:Seehund2cele4.jpg + [21:31:40] <@MeinNameIstRetro> mikedep333: Sounds good. Ionic, should we have a 4.0.1.21 "master bug" as well? + [21:31:45] <@Ionic> no + [21:32:23] <@MeinNameIstRetro> h1mg, Ionic - I'd veto calling it LTS, I'm OK with calling it ESR though. + [21:32:24] <@Ionic> I'm not even sure we need a 4.1.0.0 master bug since it's only three things + [21:32:35] <@Ionic> or ESR + [21:32:59] <@Ionic> just something we can provide as a "legacy" release + [21:34:20] <@MeinNameIstRetro> *test* + [21:34:26] <@Ionic> works + [21:34:33] <@MeinNameIstRetro> ok, my chat still works, sorry for the test but I had a screen freeze + [21:35:09] <@Ionic> any other questions regarding x2goserver? + [21:35:20] < h1mg> a generic name, but even specific would be "düne" -> Germanys only off shore island... + [21:35:53] < h1mg> http://osm.org/go/0HODqrg0 + [21:36:07] <@Ionic> h1mg: we should avoid special characters + [21:36:08] <@MeinNameIstRetro> I'd just like to remind you all again that the changes to X2GoServer take priority; if there's still time left, we can tackle X2GoClient. + [21:36:16] < h1mg> Ionic: Duene :) + [21:36:22] <@MeinNameIstRetro> Dune + [21:36:26] <@MeinNameIstRetro> Desert Planet + [21:36:41] < h1mg> MeinNameIstRetro: No... not the spice wars! + [21:36:57] < h1mg> ok,.. get back... I'll think about it + [21:37:23] <@MeinNameIstRetro> h1mg: X2Go vs. Spice would be a theme ... + [21:37:33] <@Ionic> the last name we had was baikal + [21:37:56] <@Ionic> I don't know the names before that + [21:38:00] < mikedep333> lol + [21:38:26] < mikedep333> Kessel (Star Wars has the "Spice mines of Kessel") + [21:39:22] <@MeinNameIstRetro> mikedep333: Uh, no, we won't use that. Reason -> IM in a few minutes + [21:39:28] <@Ionic> but that doesn't fit well with the sea-(mammal-)related names we've had in the past, I'm sure h1 can come up with something fitting + [21:39:50] < mikedep333> I am just joking. + [21:39:53] < h1mg> Trischen, oland, tertius... + [21:40:00] < mikedep333> Kessel would be perfect for a SPICE-related project. + [21:40:11] < h1mg> all of them sand based islands... + [21:40:35] < h1mg> again: we'll find some name! + [21:40:45] <@MeinNameIstRetro> okay. + [21:40:47] < h1mg> -> task [ ] find name + [21:40:58] < h1mg> so... GOGS... + [21:41:20] < h1mg> please have a look on that blog post: + [21:41:20] < h1mg> https://blog.gitea.io/2016/12/welcome-to-gitea/ + [21:41:22] <@MeinNameIstRetro> Ionic: I would still prefer if we have a master bug for 4.1.0.0. or 5.0.0.0 or whatever we are going to call it. I would really call it 5.x because of the NX-Libs swap. + [21:41:33] <@MeinNameIstRetro> h1mg: standby,please + [21:41:55] <@Ionic> the nx-libs swap is part of nx-libs and not x2goserver though + [21:42:04] <@MeinNameIstRetro> h1mg: before discussing gogs, the next item on the agenda is an X2GoClient release + [21:42:34] < h1mg> MeinNameIstRetro: Sorry... its getting cold in here! + [21:42:52] <@MeinNameIstRetro> Ionic: yes, but you said 4.1.0.0 is incompatible with our current NX-libs version + [21:42:57] <@Ionic> (just a quick reminder that we've already been discussing for more than an hour) + [21:43:01] <@Ionic> it's not + [21:43:07] <@Ionic> it's compatible to both currently + [21:43:19] <@Ionic> 4.0.1.x is incompatible with arctica's version + [21:43:34] <@MeinNameIstRetro> Ionic: (20:43:51) Mihai Moldovan: arctica's nx-libs is only compatible with 4.1.0.0 so far + [21:43:51] <@Ionic> exactly? + [21:44:16] <@Ionic> arctica's nx-libs only works with 4.1.0.0, but 4.1.0.0 works with arctica's nx-libs and our legacy nx-libs + [21:44:17] <@MeinNameIstRetro> Ionic: Oh, so 4.1.0.0 will work with NX-Libs classic and NX-Libs Arctica? + [21:44:40] <@Ionic> currently yes + [21:44:59] <@MeinNameIstRetro> Ionic: but the big change is that we support Arctica's NX-Libs with 4.1.0.0, and thus it warrants being called 5.0.0.0 IMHO + [21:45:18] <@Ionic> if arctica's nx-libs makes breaking changes that we can't easily wrap around then at some point we'll need to drop legacy nx-libs support + [21:45:36] <@MeinNameIstRetro> Ionic: That is acceptable, IMHO + [21:46:13] <@MeinNameIstRetro> 5.0.0.0 is a "transition release", as in "move to Arctica NX ASAP, let us know if it doesn't work for you" + [21:47:22] < mikedep333> Yeah + [21:47:26] <@MeinNameIstRetro> anything else regarding the server release or can we move on to the next item, the X2GoClient release? + [21:47:27] <@Ionic> when x2goserver went from 3.0 to 4.0, that related to incompatible changes with the client IIRC + [21:47:54] <@Ionic> and there's no breakage this time, so I'd opt for 4.1 + [21:48:13] < mikedep333> Based on what Ionic said, I also suggest 4.1. + [21:48:48] <@MeinNameIstRetro> okay. The numbering is the least important thing, we can discuss that another time. + [21:50:16] <@Ionic> we'll have to see if a 4.1.0.0 release is possible by end of december + [21:50:35] <@Ionic> no questions from my side + [21:50:52] <@MeinNameIstRetro> Ionic: EARLY December is the deadline + [21:51:02] <@MeinNameIstRetro> Ionic: Else, no Ubuntu 18.04 LTS + [21:51:51] <@MeinNameIstRetro> Ionic: this means 1st or 2nd week of December + [21:51:54] <@Ionic> again, it requires thoughtful testing of the upgrade path + [21:52:04] <@MeinNameIstRetro> Ionic: that's why we have to hurry ;) + [21:52:33] <@MeinNameIstRetro> Okay. Anything else regarding the Server release? + [21:52:40] <@Ionic> I'd rather not have it in ubuntu 18.04 LTS than make a rushed release that breaks on people's machines while upgrading, but it's your call + [21:53:23] <@MeinNameIstRetro> Ionic: Again, with the snapshotted repos we'll be able to provide a safer testing possibility + [21:53:46] <@MeinNameIstRetro> Ionic: so make them available early, drop a "prerelease" into a snapshotted repo, have people test + [21:54:14] <@Ionic> users can already test today + [21:54:44] <@Ionic> they just typically don't + [21:54:46] <@MeinNameIstRetro> Ionic: We've discussed this at the Gathering before. No, they can't do it as safely and as easily as if we had snapshot repos. + [21:55:27] <@MeinNameIstRetro> Ionic: You can continue discussing this with me privately later on or some other time - for now, we should let mikedep333 have the stage regarding the Client release + [21:55:48] <@Ionic> sure, go on mikedep333 + [21:56:13] < mikedep333> Ionic: what? + [21:56:38] <@MeinNameIstRetro> mikedep333: our agenda says: Upcoming X2GoClient stable release any questions, vetos, …? What needs to be done? Mike#2 will be available for Q&A + [21:57:09] < h1mg> Notebook: [#------] - switching2tablet + [21:57:56] <@MeinNameIstRetro> mikedep333: So I guess you have some changes that are supposed to go into X2GoClient that aren't in the current stable release yet, and you'd like to release one? + [21:58:17] <@Ionic> ah yes, the PATH change + [21:59:02] <@Ionic> okay, let's make that quick: I can release a new client version in a few weeks, after making a call for translations and waiting for translations to come in + [21:59:06] < mikedep333> Yes, that change + [21:59:18] < mikedep333> Ionic: Yes, let's do that please. + [21:59:19] <@Ionic> there are currently no known regressions I know about + [21:59:25] <@MeinNameIstRetro> Ionic: --verbose re: PATH change? + [21:59:51] <@Ionic> mikedep333 pushed a change that doesn't override PATH in user sessions + [21:59:58] < mikedep333> https://code.x2go.org/gitweb?p=x2goclient.git;a=commit;h=d164a700ba7e243f50… + [22:00:07] <@Ionic> he and some other users are keen on seeing that in a released version + [22:00:29] < mikedep333> Yeah. Basically, another sysadmin here hates telling home / offsite users to install a pre-release. + [22:00:47] <@Ionic> (essentially so that PATH can be modified through, e.g., a user's ~/.bashrc file or similar) + [22:01:08] < h1Org2> re... + [22:01:14] <@MeinNameIstRetro> mikedep333: I can totally relate to your sysadmin + [22:01:16] <@Ionic> mikedep333: what he doesn't understand is that the pre-release version is just like the release version + [22:01:22] <@Ionic> *shrug* + [22:01:45] < mikedep333> Another thing is that we would rather install x2goclient from EPEL. + [22:01:48] < mikedep333> It saves us time. + [22:02:09] <@Ionic> well yeah and EPEL doesn't provide nightly builds, that's understandable + [22:02:13] <@MeinNameIstRetro> mikedep333: oh, so it's not about the Windows Client in particular, but the Client in general. + [22:02:20] < mikedep333> Yes. + [22:02:20] <@Ionic> yes + [22:02:26] <@MeinNameIstRetro> gotcha + [22:02:28] < mikedep333> We run all 3 clients platforms here at my new job. + [22:02:37] <@Ionic> there are no windows-specific changes in that release + [22:02:48] <@MeinNameIstRetro> wait, that should say <mike number="2">gotcha</mike> ;) + [22:02:52] < mikedep333> And we have remote users at universities, homes, etc where we have no control over their clients. + [22:03:22] < mikedep333> We can only provide them with instructions and hope they follow them. + [22:03:54] <@MeinNameIstRetro> mikedep333: would the "in a few weeks" release date set by Ionic work for you? + [22:04:04] < mikedep333> Yes + [22:04:24] <@Ionic> another problem is that I don't know how much time to give translators + [22:04:51] <@MeinNameIstRetro> Ionic: Anything blocking the CfT? If not, send it out today. + [22:04:54] <@Ionic> whatever I do, they only (mostly) seem to supply translations at the very end of the deadline - and some even past that + [22:05:17] <@Ionic> are 2 weeks enough? or 3 weeks? + [22:06:15] <@MeinNameIstRetro> Ionic: give them 1 week, poke them after another, then report the ones that still didn't deliver to me, and I shall flog^Wnudge them gently + [22:06:46] <@Ionic> we don't even have a full list of active translators + [22:07:15] <@MeinNameIstRetro> Ionic: well we have a list of people that provided translations previously, we can ping them + [22:07:15] <@Ionic> a week sounds too short + [22:07:26] <@MeinNameIstRetro> Ionic: Of course it is, that's the plan ;) + [22:08:20] <@MeinNameIstRetro> Ionic: the *real* deadline is 2 weeks, but tell them it is 1 week so they reply faster. Those that read the chat log are the lucky ones ;)) + [22:08:45] <@Ionic> meh, my gut feeling is that nothing will come in after a week, but okay + [22:09:11] <@MeinNameIstRetro> Ionic: yes, but we will have them by the second week, that's the idea behind it + [22:09:59] <@Ionic> okay, I'll prepare that tomorrow + [22:10:35] <@MeinNameIstRetro> okay. Anything else that needs to be said regarding the Client release? Anyone vetoing the release? + [22:10:44] <@Ionic> so gogs, if h1 isn't frozen yet + [22:11:14] * MeinNameIstRetro tosses a few burning logs in h1Org's general direction + [22:11:41] <@MeinNameIstRetro> no one else is speaking up, so - next topic: gogs. + [22:12:11] <@MeinNameIstRetro> At X2Go: The Gathering 2017, there has been some constructive criticism regarding our current bugtracker. + [22:12:28] <@MeinNameIstRetro> The initial idea was a self-hosted gitlab instance, h1Org2 suggested using gogs instead. + [22:12:51] <@MeinNameIstRetro> Anyone willing and able to explain the advantages of gogs in a few short sentences? + [22:13:16] <@MeinNameIstRetro> IOW, what does gogs do/do better than our current bugtracker? + [22:13:58] <@Ionic> gogs is a clone of github written in go, which provides source code and issue report management + [22:14:22] <@Ionic> I guess h1 is having connectivity problems currently + [22:14:56] <@Ionic> the workflow for bug reports is pretty much like in github, with a user-visible web interface + [22:15:29] <@Ionic> h1 has been using that system previously and thus got some experience with it + [22:16:14] <@MeinNameIstRetro> Ionic: is it still possible to use E-Mail commands to edit bugs? + [22:16:21] <@Ionic> I don't think so + [22:16:39] < mikedep333> Fedora developed Pagure and Debian is adopting it, but it isn't as general-purpose as gitlab. + [22:16:52] < mikedep333> We are using gitlab happily here at work btw (internally.) + [22:17:19] <@Ionic> but gitlab doesn't support that either IIRC + [22:18:09] <@Ionic> github itself supports adding comments to bug report via email and provides a mailing list of bug reports and comments per-repository + [22:18:21] <@MeinNameIstRetro> Okay, but the only hardcore edit-bugs-by-e-mail users were sunweaver and Alex, I think - and sunweaver has already indicated he's happy with gogs + [22:18:22] <@Ionic> I don't know if gitlab and gogs support this + [22:18:52] <@Ionic> we've been using the github workflow extensively within arctica + [22:19:05] <@MeinNameIstRetro> Ionic: do you know how to migrate the bug database from our debbugs based tracker to gogs? + [22:19:26] <@Ionic> that's a problem for sure + [22:19:57] <@MeinNameIstRetro> Ionic: So I guess we better do not attempt to switch from debbugs to gogs before the new release is done. + [22:20:02] <@Ionic> I don't believe there's anything readily available for transfering this data from a debian bug tracker instance to gogs (or to anything else, for that matter) + [22:20:52] <@Ionic> the debian BTS stores bug reports in an mbox-like format on the file system with per-issue-report subdirectories + [22:21:06] <@MeinNameIstRetro> Ionic: h1 contacted me via instant messenger, I've relayed the question to him + [22:21:17] <@MeinNameIstRetro> he says there's no way to do it automatically + [22:21:28] <@Ionic> well, we can't do it manually + [22:22:16] <@Ionic> we've got more than 1200 bug reports, so this must be automated + [22:22:58] <@MeinNameIstRetro> Ionic: Ooooor ... we sunset the debbugs bug tracker, as in, we don't accept new gubs in it + [22:22:59] <@Ionic> even if we don't import closed bug reports, the number is still high + [22:23:16] < mikedep333> I am checking if Pagure accepts email commands to manage bugs. + [22:23:17] <@MeinNameIstRetro> *bugs, even + [22:24:11] <@Ionic> and then we keep working with two systems simultaneously which is probably even worse + [22:24:54] < mikedep333> I am trying to find out if Debian is migrating only source code hosting to pagure, or their bugs tracking also. + [22:24:55] <@MeinNameIstRetro> Ionic: Well, we can still migrate important bugs manually + [22:25:14] < mikedep333> MeinNameIstRetro: Good point. Since most bugs do not get addressed quickly. + [22:25:37] <@MeinNameIstRetro> h1 just suggested we talk to "Mr. FreeRDP" Bernhard Miklauz. He's been using a lot of different bug trackers and has the best overview, in h1' view + [22:26:34] <@Ionic> I prefer a full automatic data migration + [22:26:55] <@MeinNameIstRetro> Ionic: so do I ... + [22:27:18] < mikedep333> looks like debian will keep debbugs along side pagure. + [22:27:40] <@Ionic> of course, their database is even bigger + [22:28:11] <@Ionic> plus they are used to it (although not totally happy) and it's not like debbugs is deprecated or unmaintained + [22:28:12] <@MeinNameIstRetro> h1 believes there is NO tool at all to migrate away from debbugs. No matter what you want to migrate to. + [22:28:58] <@Ionic> yes, I know + [22:29:06] <@Ionic> I'll have to write one up + [22:29:22] <@MeinNameIstRetro> So the question is: Who would be most suited to research if there are migration tools for debbugs -> $something, where $something is a "github-like tool that can be self-hosted" + [22:29:53] <@MeinNameIstRetro> Ionic: could you ping Bernhard if he has any idea? + [22:30:10] <@Ionic> AFAIK there is no tool for migrating debbugs data to anything else + [22:30:35] <@MeinNameIstRetro> Ionic: as far as YOU and h1 know ... but as far as Bernhard knows? + [22:31:58] <@Ionic> debbugs isn't widely used + [22:32:16] <@Ionic> debian, GNU and we are pretty much the only users + [22:33:34] <@MeinNameIstRetro> Ionic: still,can't hurt to ping him - can you do that? + [22:33:45] <@Ionic> I can + [22:33:56] <@MeinNameIstRetro> Ionic: Then please do so :) + [22:34:09] <@MeinNameIstRetro> okay, h1 has signed off for the day + [22:34:38] <@MeinNameIstRetro> I think we can all agree that we won't be moving off of debbugs to $SOMETHING_ELSE before the next release. + [22:34:48] <@Ionic> certainly not + [22:35:14] <@MeinNameIstRetro> that means we have sufficient time to have people chime in/research how a migration might work, and to what target. + [22:35:27] <@MeinNameIstRetro> (gogs, self-hosted gitlab, ...) + [22:36:23] <@MeinNameIstRetro> So - last topic on the agenda: When shall we meet again? The regular schedule would call for another meeting in 3 months. Do we want to meet again sooner, due to the upcoming release? + [22:37:22] <@Ionic> it would probably make sense to schedule a meeting in mid nov + [22:38:06] < rgregory> iconic: i agree. + [22:38:14] <@MeinNameIstRetro> Ionic: November 9 is our IT-Kongress Booth/Talk, so that one is out. + [22:39:03] <@MeinNameIstRetro> Ionic: November 16 should work. + [22:39:38] <@Ionic> it doesn't really make sense to schedule it now, since we're pretty much alone + [22:40:31] <@Ionic> nov 16 sounds sensible, so propose that as the next date and let people chime in + [22:40:56] <@MeinNameIstRetro> Ionic: November 9 doesn't work because it's IT-Kongress time, November 23 doesn't work because it's Stuttgart Fair time, so if mid-November is our goal, it's Nov 16 or bust + [22:42:13] <@MeinNameIstRetro> We could go for Nov 2 instead. + [22:42:35] <@Ionic> we could schedule it earlier as well + [22:43:10] <@Ionic> mid nov pretty much is the latest we can do if the 4.1.0.0 deadline is early dec + [22:43:25] <@MeinNameIstRetro> Oct 19 or Oct 26 would work too, for a DevMeeting. + [22:44:52] <@MeinNameIstRetro> Okay, let's leave it at that for tonight, I'd say. </file> -- This mail was generated by DokuWiki at https://wiki.x2go.org/ [View Less]

1 0

[[X2Go Wiki]] page changed: 2017-09:day-2017-09-28
by wiki-admin＠x2go.org 28 Sep '17

28 Sep '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/09/28 18:36 Browser : Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36 IP-Address : 140.208.1.15 Hostname : ldt-4295261.gfdl.noaa.gov Old Revision: https://wiki.x2go.org/doku.php/2017-09:day-2017-09-28?rev=1506607623 New Revision: https://wiki.x2go.org/doku.php/2017-09:day-2017-09-28 Edit Summary: Add "Mike#2 contributing on behalf of his day … [View More]

1 0

[[X2Go Wiki]] page changed: 2017-09:day-2017-09-28
by wiki-admin＠x2go.org 28 Sep '17

28 Sep '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/09/28 14:07 Browser : Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 IP-Address : 78.43.91.217 Hostname : HSI-KBW-078-043-091-217.hsi4.kabel-badenwuerttemberg.de Old Revision: https://wiki.x2go.org/doku.php/2017-09:day-2017-09-28?rev=1506607546 New Revision: https://wiki.x2go.org/doku.php/2017-09:day-2017-09-28 Edit Summary: User : stefanbaur @@ -1,6 +1,6 @@ - =… [View More]

1 0

[[X2Go Wiki]] page changed: 2017-09:day-2017-09-28
by wiki-admin＠x2go.org 28 Sep '17

28 Sep '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/09/28 14:05 Browser : Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 IP-Address : 78.43.91.217 Hostname : HSI-KBW-078-043-091-217.hsi4.kabel-badenwuerttemberg.de Old Revision: https://wiki.x2go.org/doku.php/2017-09:day-2017-09-28?rev=1506607450 New Revision: https://wiki.x2go.org/doku.php/2017-09:day-2017-09-28 Edit Summary: Added another "Who" User : stefanbaur … [View More]

1 0

[[X2Go Wiki]] page changed: 2017-09:day-2017-09-28
by wiki-admin＠x2go.org 28 Sep '17

28 Sep '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/09/28 14:04 Browser : Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 IP-Address : 78.43.91.217 Hostname : HSI-KBW-078-043-091-217.hsi4.kabel-badenwuerttemberg.de Old Revision: https://wiki.x2go.org/doku.php/2017-09:day-2017-09-28?rev=1506607431 New Revision: https://wiki.x2go.org/doku.php/2017-09:day-2017-09-28 Edit Summary: User : stefanbaur @@ -15,9 +15,9 @@ … [View More]

1 0

[[X2Go Wiki]] page changed: 2017-09:day-2017-09-28
by wiki-admin＠x2go.org 28 Sep '17

28 Sep '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/09/28 14:03 Browser : Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 IP-Address : 78.43.91.217 Hostname : HSI-KBW-078-043-091-217.hsi4.kabel-badenwuerttemberg.de Old Revision: https://wiki.x2go.org/doku.php/2017-09:day-2017-09-28?rev=1506607340 New Revision: https://wiki.x2go.org/doku.php/2017-09:day-2017-09-28 Edit Summary: reordered topics, added gogs User : … [View More]

1 0

[[X2Go Wiki]] page changed: 2017-09:day-2017-09-28
by wiki-admin＠x2go.org 28 Sep '17

28 Sep '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/09/28 14:02 Browser : Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 IP-Address : 78.43.91.217 Hostname : HSI-KBW-078-043-091-217.hsi4.kabel-badenwuerttemberg.de Old Revision: https://wiki.x2go.org/doku.php/2017-09:day-2017-09-28?rev=1506606302 New Revision: https://wiki.x2go.org/doku.php/2017-09:day-2017-09-28 Edit Summary: Added Topic List & Raw Meeting Minutes … [View More]from Gathering 2017 User : stefanbaur @@ -1,21 +1,122 @@ ==== 6th ΞX2Go Development Meeting ==== ===== Who is taking part? ===== * <todo @all>h1, Mike#1, Mike#2, Mihai, Stefan, Alex</todo> - === Research === - * FIXME + === Topics === + * Upcoming X2GoClient stable release + * any questions, vetos, ...? + * What needs to be done? + * Mike#2 will be available for Q&A + * X2GoServer code updates in preparation of the upcoming release + * release is scheduled for early December 2017, but the sooner, the better + * We need a "master bug" for the release, that will/can be blocked by the bugs created for the individual tasks + * Who will file these bugs, and who will mark them as blockers? + * New release will bring changes on server and client side + * mostly regarding xinerama + * keyboard handling ("Keyboard cloning" feature) + * "autograb"/Input-Lock for windowed desktop sessions + * server-side changes must come first, client-side changes could be delayed into early 2018 if we're low on resources + * Date for Next DevMeeting + * Regular schedule: Once per quarter + * Might need to take place more often in the next few months, due to the release schedule - === Retrospective === - * FIXME - - === Planning === - * FIXME + === "Raw" Meeting Minutes from X2Go: The Gathering 2017 release planning session === + (will be moved to a different Wiki page later) + <code> + X2Go Next Major Release - === Out-of-band Topic === - * <todo @orkun?>Pardus National Operating System Distribution offers help to X2Go </todo> + Server-Side: + Phase that allows 3.5 && 3.6 + 3.6 is in experimental, could co-exist with 3.5 + Xinerama is not done + Needs Server-side and Client-Side changes + New Servers need to be able to function with older Clients + and vice versa + + Current (old) approach: xinerama.conf is generated on the client + file gets copied to server regularly + + Mode 1: NXagent is in fullscreen - xinerama.conf shows geometry of your output device layout + + Mode 2: X2Go session is in windowed mode and there is a multi-device layout on the client + ->it's possible to move the client window across screens (with overlap) + -> that's why on each resize/move event, xinerama.conf needs to be updated when using the "old" method + + Now, with current X2Go-Libs and X2GoClient, xinerama.conf gets pushed to the server -> if file is present, we enable xinerama mode. + + When does that happen? Before or after the xgostartagent call? + + New Client, New Server: + ->Idea: keep creating xinerama.conf, but fill it with "auto" or a similar magic value + -> "X2GOAGENT_RANDRXINERAMA" + * present -> xinerama.conf with "auto" + not present -> xinerama.conf with required values + + New Client, Old Server: + -> x2gofeaturelist / x2gofeature <feature_name> + -> "X2GOAGENT_RANDRXINERAMA" + present -> xinerama.conf with "auto" + * not present -> xinerama.conf with required values + + Old Client, New Server: + Old clients will generate a xinerama.conf and upload it to the server + New Server should check file + -> If file exists, enable xinerama + -> If not, do not enable xinerama + --> Won't work because xinerama.conf is created too late + --> New Client + + Old Client, Old Server: Unchanged + + ->Idea: Have New X2Go *Client* report its list of features *to the Server* + --> Empty list = old client + ->This info should be stored in a file on the server (in the session directory) + --> x2gosuspend-/-terminate-session should remove this file + + -- + + Keyboard: + + (Uli) + Plan: Change NX so keyboard handling works out of the box. + Unsure if this works. + Future NX-libs should block keyboard changes within sessions. + But: X2Go is currently changing keyboard settings within sessions. + + -->New Feature "Keyboard Cloning" + + (Mike#1) + Plan: Keep old behavior in the code, but switch the default: + - New way of handling things becomes default + - command line parameter/option allows fallback + + -- + + Auto-Grab: + X2GoClient needs a checkbox to enable/disable auto-grab + + Same goes for Input-Lock + + -- + + Focus on Server-Side implementation first + (Timing/Limited Resources-> Ubuntu Freeze, Dec 2017 deadline) + + + Step-by-step plan, dependencies, (wishlist?) bugs -> Master Bug, blocked by the individual (wishlist) bugs + + If we do a "LTS-like" release, it should clearly state the date when it will be removed from the download servers + ESR instead of LTS? + Remove LTS/ESR packages from download servers if there is no support contract + + ->Mihai will introduce snapshot archives for heuler + -->hopefully increases amount of testers + + required Documentation for testers -> Should be as simple as updating sources.list to a heuler+timestamp entry and running update, upgrade, dist-upgrade + </code> ====== Raw Chat Log ====== FIXME <file> ...log... </file> -- This mail was generated by DokuWiki at https://wiki.x2go.org/ [View Less]

1 0

[[X2Go Wiki]] page added: 2017-09:day-2017-09-28
by wiki-admin＠x2go.org 28 Sep '17

28 Sep '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/09/28 13:45 Browser : Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 IP-Address : 188.194.114.165 Hostname : 188.194.114.165 Old Revision: --- New Revision: https://wiki.x2go.org/doku.php/2017-09:day-2017-09-28 Edit Summary: created User : h1 ==== 6th ΞX2Go Development Meeting ==== ===== Who is taking part? ===== * <todo @all>h1, Mike#1, Mike#2, Mihai, Stefan, … [View More]

1 0

[[X2Go Wiki]] page changed: wiki:development:planning:start
by wiki-admin＠x2go.org 28 Sep '17

28 Sep '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/09/28 13:43 Browser : Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 IP-Address : 188.194.114.165 Hostname : 188.194.114.165 Old Revision: https://wiki.x2go.org/doku.php/wiki:development:planning:start?rev=15066061… New Revision: https://wiki.x2go.org/doku.php/wiki:development:planning:start Edit Summary: [Calendar] User : h1 @@ -17,10 +17,10 @@ ==== Planning ==== … [View More]

1 0

[[X2Go Wiki]] page changed: wiki:development:planning:start
by wiki-admin＠x2go.org 28 Sep '17

28 Sep '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/09/28 13:42 Browser : Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 IP-Address : 188.194.114.165 Hostname : 188.194.114.165 Old Revision: https://wiki.x2go.org/doku.php/wiki:development:planning:start?rev=14541016… New Revision: https://wiki.x2go.org/doku.php/wiki:development:planning:start Edit Summary: [Calendar] User : h1 @@ -17,9 +17,9 @@ ==== Planning ==== … [View More]

1 0

← Newer
1
2
3
4
5
6
7
...
17
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

x2go-commits September 2017