x2go-commits

x2go-commits@lists.x2go.org

1 participants
37910 discussions

[[X2Go Wiki]] page changed: events:start
by wiki-admin＠x2go.org 06 Oct '17

06 Oct '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/10/06 14:50 Browser : Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.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/events:start?rev=1507300324 New Revision: https://wiki.x2go.org/doku.php/events:start Edit Summary: added X2Go: The Gathering 2017 pictures User : stefanbaur @@ -34,8 +34,10 @@ ===== Past Events ===== ==== X2Go: The Gathering 2017, Location: Adventure Campus, Treuchtlingen, Germany 2017-09-22 to 2017-09-24 ==== * As in the previous years, there's a sub-page with all the details: [[events:x2go-gathering-2017|Read more here...]] + {{:events:img_20170923_120133.jpg?169|Mike#1 explaining some things}} {{:events:img_20170923_114908.jpg?300|Presents from one of our sponsors}} {{:events:img_20170923_161157.jpg?300|People coding away}} {{:events:img_20170923_155456.jpg?300|People coding away, from behind}} + ==== TUEBIX 2017, Tuebingen, Germany (2017-06-24) ==== * http://www.tuebix.org/ * Booth & Talk confirmed -- This mail was generated by DokuWiki at https://wiki.x2go.org/

1 0

[[X2Go Wiki]] file uploaded: events:img_20170923_161157.jpg
by wiki-admin＠x2go.org 06 Oct '17

06 Oct '17

A file was uploaded to your DokuWiki. Here are the details: File : https://wiki.x2go.org/lib/exe/fetch.php/events:img_20170923_161157.jpg Old revision: --- Date : 2017/10/06 14:36 Browser : Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0 IP-Address : 78.43.91.217 Hostname : HSI-KBW-078-043-091-217.hsi4.kabel-badenwuerttemberg.de Size : 2 MB MIME Type : jpg User : stefanbaur -- This mail was generated by DokuWiki at https://wiki.x2go.org/

1 0

[[X2Go Wiki]] file uploaded: events:img_20170923_114908.jpg
by wiki-admin＠x2go.org 06 Oct '17

06 Oct '17

A file was uploaded to your DokuWiki. Here are the details: File : https://wiki.x2go.org/lib/exe/fetch.php/events:img_20170923_114908.jpg Old revision: --- Date : 2017/10/06 14:36 Browser : Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0 IP-Address : 78.43.91.217 Hostname : HSI-KBW-078-043-091-217.hsi4.kabel-badenwuerttemberg.de Size : 2.4 MB MIME Type : jpg User : stefanbaur -- This mail was generated by DokuWiki at https://wiki.x2go.org/

1 0

[[X2Go Wiki]] file uploaded: events:img_20170923_155456.jpg
by wiki-admin＠x2go.org 06 Oct '17

06 Oct '17

A file was uploaded to your DokuWiki. Here are the details: File : https://wiki.x2go.org/lib/exe/fetch.php/events:img_20170923_155456.jpg Old revision: --- Date : 2017/10/06 14:35 Browser : Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0 IP-Address : 78.43.91.217 Hostname : HSI-KBW-078-043-091-217.hsi4.kabel-badenwuerttemberg.de Size : 1.9 MB MIME Type : jpg User : stefanbaur -- This mail was generated by DokuWiki at https://wiki.x2go.org/

1 0

[[X2Go Wiki]] file uploaded: events:img_20170923_120133.jpg
by wiki-admin＠x2go.org 06 Oct '17

06 Oct '17

A file was uploaded to your DokuWiki. Here are the details: File : https://wiki.x2go.org/lib/exe/fetch.php/events:img_20170923_120133.jpg Old revision: --- Date : 2017/10/06 14:35 Browser : Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0 IP-Address : 78.43.91.217 Hostname : HSI-KBW-078-043-091-217.hsi4.kabel-badenwuerttemberg.de Size : 2.1 MB MIME Type : jpg User : stefanbaur -- This mail was generated by DokuWiki at https://wiki.x2go.org/

1 0

[[X2Go Wiki]] page changed: events:start
by wiki-admin＠x2go.org 06 Oct '17

06 Oct '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/10/06 14:32 Browser : Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.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/events:start?rev=1506504405 New Revision: https://wiki.x2go.org/doku.php/events:start Edit Summary: updated LinuxDay.AT info User : stefanbaur @@ -12,9 +12,9 @@ * tentative booth staff: * ferdnand * Franz * Stefan#2 - * Application for talk still lacking topic + * Application for talk sent * Linux Expo Ulm 2017/LPD 2017.2 Ulm - Date 2017-11-18, if it takes place at all - still lacking volunteers for the entire event, not only X2Go * Modell & Technik <del>Hobby & Elektronik</del>, Stuttgart, Germany (2017-11-23 - 2017-11-26) - Probably a "split" event as last year, with one or two X2Go volunteers taking turns per day ==== IT-Kongress 2017, Neu-Ulm, Germany (2017-11-09) ==== * As one of the X2Go core team members is on the planning committee, we'll have a small booth again, as in the previous years -- This mail was generated by DokuWiki at https://wiki.x2go.org/

1 0

[x2goclient] branch master updated (7ca9d71 -> 0ac3ade)
by git-admin＠x2go.org 06 Oct '17

06 Oct '17

This is an automated email from the git hooks/post-receive script. x2go pushed a change to branch master in repository x2goclient. from 7ca9d71 res/i18n/x2goclient_es.ts: fixup Spanish translation file. new a0de3f5 res/i18n/x2goclient_et.ts: update Estonian translation file. new 0ac3ade res/i18n/x2goclient_et.ts: fixup some typos in the Estonian translation file. The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: debian/changelog | 3 + res/i18n/x2goclient_et.ts | 180 ++++++++++++++++++++++++++-------------------- 2 files changed, 104 insertions(+), 79 deletions(-) -- Alioth's /srv/git/code.x2go.org/x2goclient.git//..//_hooks_/post-receive-email on /srv/git/code.x2go.org/x2goclient.git

1 2

[x2goclient] branch master updated (1061c95 -> 7ca9d71)
by git-admin＠x2go.org 05 Oct '17

05 Oct '17

This is an automated email from the git hooks/post-receive script. x2go pushed a change to branch master in repository x2goclient. from 1061c95 res/i18n/: regenerate translations. new ba0d051 res/i18n/x2goclient_sv.ts: update Swedish translation file. new 4bfb045 res/i18n/x2goclient_es.ts: update Spanish translation file. new 7ca9d71 res/i18n/x2goclient_es.ts: fixup Spanish translation file. The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: debian/changelog | 9 +++++++ res/i18n/x2goclient_es.ts | 60 +++++++++++++++++++++++------------------------ res/i18n/x2goclient_sv.ts | 56 +++++++++++++++++++++---------------------- 3 files changed, 67 insertions(+), 58 deletions(-) -- Alioth's /srv/git/code.x2go.org/x2goclient.git//..//_hooks_/post-receive-email on /srv/git/code.x2go.org/x2goclient.git

1 3

[x2goclient] branch master updated (8613150 -> 1061c95)
by git-admin＠x2go.org 30 Sep '17

30 Sep '17

This is an automated email from the git hooks/post-receive script. x2go pushed a change to branch master in repository x2goclient. from 8613150 src/onmainwindow.cpp: fix up main window position check; use QRect.intersects (). new 07ce91e src/pulsemanager.{cpp,h}: rename shutdownState to shutdown_state_, reorder in initializer list. new 1061c95 res/i18n/: regenerate translations. The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: debian/changelog | 3 + res/i18n/x2goclient_da.ts | 1213 ++++++++++++++++++++++------------------- res/i18n/x2goclient_de.ts | 1211 ++++++++++++++++++++++------------------- res/i18n/x2goclient_es.ts | 1221 ++++++++++++++++++++++------------------- res/i18n/x2goclient_et.ts | 1230 ++++++++++++++++++++++-------------------- res/i18n/x2goclient_fi.ts | 1211 ++++++++++++++++++++++------------------- res/i18n/x2goclient_fr.ts | 69 ++- res/i18n/x2goclient_nb_no.ts | 69 ++- res/i18n/x2goclient_nl.ts | 1211 ++++++++++++++++++++++------------------- res/i18n/x2goclient_pt.ts | 1215 ++++++++++++++++++++++------------------- res/i18n/x2goclient_ru.ts | 1213 ++++++++++++++++++++++------------------- res/i18n/x2goclient_sv.ts | 1211 ++++++++++++++++++++++------------------- res/i18n/x2goclient_tr.ts | 1213 ++++++++++++++++++++++------------------- res/i18n/x2goclient_zh_tw.ts | 1213 ++++++++++++++++++++++------------------- src/pulsemanager.cpp | 10 +- src/pulsemanager.h | 2 +- 16 files changed, 7320 insertions(+), 6195 deletions(-) -- Alioth's /srv/git/code.x2go.org/x2goclient.git//..//_hooks_/post-receive-email on /srv/git/code.x2go.org/x2goclient.git

1 2

[[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 @@ 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/

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

x2go-commits