ToDos for the Next Meeting:
[20:14] <h1Org> 7th ΞX2Go Development Meeting [20:15] <h1Org> Please respect that this chatroom will be used as conference room for the next hour and make sure that this communication will not be disturbed by any off topic questions until the meeting is over! [20:15] <h1Org> This will be our TOC today: [20:15] <h1Org> https://wiki.x2go.org/doku.php/2017-11:day-2017-11-02 [20:15] <h1Org> The chatlog of this meeting will be available on the same page after the meeting [20:15] <h1Org> First topic: [20:15] <h1Org> X2GoClient release [20:16] <h1Org> I think thos was a question of MeinNameIstRetro... -> proceeding as planned/already done? [20:16] <h1Org> So lets beginn with the first topic -> MeinNameIstRetro [20:17] <MeinNameIstRetro> Mihai, since Mike#2 seems to be away, could you give a quick feedback if the last Client release is the one Mike#2 had in mind? [20:17] <Ionic> the release as such is done, windows builds are missing, but I'll let mikedep333 get to that eventually [20:17] <Ionic> yes it is [20:18] <h1Org> I assume mikedep333 isn't online at the moment? [20:19] <MeinNameIstRetro> I tried to ping him on jabber, he's not responding :( [20:19] <Ionic> given that he hasn't chimed in... [20:19] <Celmor> apparently my issues regarding java/jdownloader in an x2go session have to do with java bugs: http://bugs.java.com/view_bug.do?bug_id=8133723 and http://bugs.java.com/view_bug.do?bug_id=7172749 [20:20] <h1Org> OK,... so we do have the release - and the builds for linux? [20:20] <Ionic> yes, a full release, linux and OS X builds [20:20] <Ionic> as announced on the mailing list [20:20] <MeinNameIstRetro> but the windows builds are missing. [20:21] <Ionic> yeah, I'm sure mikedep333 will eventually get to that as well [20:21] <MeinNameIstRetro> Ionic: What's the problem that Mike#2 has to do these builds? [20:21] <h1Org> MeinNameIstRetro: ist it ok, to switch to the second topic "Snapshot Repo implementation" because, we won't get an answer to the open task? [20:22] <MeinNameIstRetro> h1Org: I would like to hear from Ionic re: necessity of waiting for mike#2 to get around to it [20:22] <Ionic> MeinNameIstRetro: he normally updates all bundled dependencies and runs a short series of tests from different windows machines [20:23] <h1Org> MeinNameIstRetro: sure! I thought, windows is not part of our jenkins.x2go.org [20:24] <Ionic> we do have nightly builds for windows [20:24] <-- Statler (~Georg@gwrz3.lohn24.de) hat diesen Server verlassen (Remote host closed the connection). [20:24] <MeinNameIstRetro> h1Org: My understanding is that we do have automated windows builds for nightlies, but the release still requires manual work [20:24] <Ionic> yes, but that part can't be automated [20:24] <MeinNameIstRetro> Ionic: That's arguable, but not a topic for tonight. ;) [20:26] <h1Org> MeinNameIstRetro: so we can't change anythin on that topic at the moment... [20:26] <MeinNameIstRetro> I think Mike#2 once said he wanted to document all the steps, are you aware of such a documentation being publicly available yet? [20:26] <MeinNameIstRetro> @ Ionic [20:27] <Ionic> should be part of the wiki: https://wiki.x2go.org/doku.php/wiki:development:build-howto-mswin:x2goclient [20:29] <MeinNameIstRetro> Ionic: Well that's the build process, but the tests? [20:30] <Ionic> uhm, the tests are "connect to servers using the new client build" [20:30] <MeinNameIstRetro> I see. [20:31] <MeinNameIstRetro> Okay, not much we can do here with Mike#2 missing. h1Org -> next topic. [20:31] <h1Org> Snapshot Repo implementation [20:32] <MeinNameIstRetro> Ionic: I would like to emphasize again how important the snapshot repo feature is especially for early testing of heuler packages. [20:33] <Ionic> noted [20:33] <MeinNameIstRetro> Ionic: Would you please tell us about the current implementation level (nn % done)? [20:33] <h1Org> snapshots.packages.x2go.org is an alias for ymir.das-netzwerkteam.de. [20:33] <Ionic> I can't give a percentage, but we already have http://snapshots.packages.x2go.org/ in a usable state [20:33] <MeinNameIstRetro> Ionic: Anything currently blocking further implementation, or all chugging on nicely, merely a matter of time? [20:34] <Ionic> the only thing missing is replacing the dirvish-managed time-based removal of archives with a quota-based solution [20:34] <Ionic> no, it's purely a matter of time [20:34] <MeinNameIstRetro> Ionic: http://snapshots.packages.x2go.org/20171101/ gives me a blank page. While it says that's intentional, it does seem a bit odd. [20:34] <Ionic> yes, that's normal [20:34] <Ionic> just like https://packages.x2go.org does [20:35] <Ionic> remember that it's a full snapshot of the whole package repository [20:35] <MeinNameIstRetro> Okay. So what's the URL one should use in a sources.list to pull a snapshot? [20:35] <Ionic> access it alike to packages.x2go.org [20:35] <Ionic> deb http://snapshots.packages.x2go.org/20171101/debian series codename, as always [20:37] <h1Org> *spinner* [20:38] <h1Org> so I would change into the next topic if there are no further questions... [20:38] <h1Org> “small” X2GoServer release [20:38] <MeinNameIstRetro> Indeed, please do. @ h1Org [20:39] <h1Org> loginctl,... as open issue... [20:39] <MeinNameIstRetro> Ionic: You said you wanted to do a small release before the big one. Any ETA on that, or has it already happened and I just didn't notice? [20:39] <Ionic> that isn't an open issue as we determined last time [20:39] <Ionic> no, I haven't done a release yet, but I've been working on it the last few days [20:40] <Ionic> it looks like upgrading both nx-libs and x2goserver in tandem is possible without errors, so I'm happy with that [20:40] * mikedep333 is here now [20:41] <mikedep333> and is reading the chatlog [20:41] <Ionic> whenever I do the release, I'll have to release both packages shortly after another and take the package repository offline until that's done [20:41] <MeinNameIstRetro> Ionic: okay, so again, it's all chugging along, no unexpected issues, just taking its time? [20:41] <mikedep333> I intend to do the formal windows release this weekend. [20:41] <mikedep333> The entire process is documented. [20:41] <MeinNameIstRetro> Thank you @ mikedep333 [20:41] <Ionic> luckily I caught a problem with x2goserver that I introduced yesterday [20:41] <Ionic> yep [20:41] <h1Org> mikedep333: Thank you for joining! [20:41] <mikedep333> It does involve a git reset on the windows release branch though. [20:41] <mikedep333> Yeah, sorry, I forgot to set a reminder. [20:42] <Ionic> mikedep333: yeah, the usual procedure :) [20:42] <Ionic> I'll have to reset the mswin branch to the current build-main branch, right? [20:42] <h1Org> mikedep333: np! [20:42] <MeinNameIstRetro> mikedep333: Ionic indicated that you do some tests before declaring a build a release. [20:42] <mikedep333> Yes [20:43] <mikedep333> I usually connect to a few different distros and desktop environments. [20:43] <Ionic> + update dependencies [20:43] <MeinNameIstRetro> mikedep333: any idea how that could be automated? [20:43] <mikedep333> Every time I update PuTTY I also do a test of kerberos auth with it. [20:43] <mikedep333> Well, we'd have to do automated GUI testing I suppose. [20:44] <mikedep333> it's not like pyhoca-cli where we could start a session on the command line, and verify it runs on the command-line. [20:44] <mikedep333> I was involved with automated GUI testing at my last job, but we went with a proprietary solution. [20:44] <MeinNameIstRetro> h1Org: please put this on the ToDo for "the first meeting after the big X2Go Server release", that we should investigate methods of automating tests of the windows client [20:45] <mikedep333> There is openqa developed by suse for testing their ISOs and basic desktop functionality in VMs. [20:45] <mikedep333> Since It reads the graphics output of the hypervisor, that would probably work. [20:45] <MeinNameIstRetro> mikedep333: Sounds cool, h1Org please add that as a first idea to the todo item [20:45] <h1Org> MeinNameIstRetro: I'l add an tag to the meeting [20:47] <mikedep333> I have something important to mention. I am trying to find the link right now. [20:47] <MeinNameIstRetro> h1Org: in the same vein - for the next meeting *after* the big release - please add https://www.heise.de/newsticker/meldung/Google-belohnt-OpenSource-Projekte-die-Fuzzing-erlauben-3708136.html to the ToDo (sorry, it's in German), basically, it's a news report that Google offers financial incentives for OSS projects that allow fuzzing. [20:49] <mikedep333> Reportedly there's a patch for nx-libs that can fix 3d support to the point that clutter-based apps (like empathy and gnome-control-center) can work without you having to disable GLX. http://lists.x2go.org/pipermail/x2go-dev/2015-December/010774.html [20:50] <h1Org> MeinNameIstRetro: added to the page of today: https://wiki.x2go.org/doku.php/2017-11:day-2017-11-02 will be moved to the new page after the date is set [20:50] <MeinNameIstRetro> thx @ h1Org [20:50] <MeinNameIstRetro> Ionic: regarding mikedep333's link: "Options!" [20:51] <mikedep333> All it does is declare it as a dependency in debian control file. [20:51] <Ionic> so we're just missing a dependency? [20:51] <mikedep333> It seems so. [20:51] <mikedep333> I haven't tested it. [20:51] <Ionic> well and quite some (invasive) x2goserver patches... [20:51] <mikedep333> I have gnome flashback mostly working on the x2goserver master branch. [20:52] <mikedep333> Most of the things mentioned by Eugene San in that email were already done by me. I wish I had seen it; it would have saved me time. [20:53] <Ionic> what does mostly mean? is it starting and working okay, minus issues with applications that require a newer GLX version or such? [20:53] <mikedep333> 1. We currently have to disable GLX so clutter apps can work. [20:53] <mikedep333> 2. I didn't modify ~/.config/monitors.xml like Eugene San said to do. I didn't see a need for it; maybe there is. [20:54] <mikedep333> 3. "gnome-session was crashing due to bug in gnome-session" - I did not observe this. Maybe it affects very specific versions of it. [20:54] <Ionic> THAT patch looks really dodgy [20:54] <mikedep333> 4. Following variables had to be added: XDG_CURRENT_DESKTOP and BASESESSION - I don't think I added BASESESSION. [20:55] <mikedep333> 5. I don't think I added "XSESSION_PARAM" either. [20:55] <Ionic> it's essentially replacing this file with a hardcoded 1024x768 resolution version, that didn't seem right [20:55] <mikedep333> 6. PATH had to be synced with /etc/environment for upstart to work - I modified the PATH if the affected version of ubuntu is detected instead. [20:56] <mikedep333> yeah [20:56] <mikedep333> Well we totally cannot overwrite that programatically. Maybe append to it programatically. [20:56] <mikedep333> It is a very important file for people who access systems locally. Possibly with remote desktop solutions in general. [20:57] <Ionic> it's probably the same issue as we've seen with kscreen2 [20:57] <Ionic> I figure the session will resize automatically to the resolution written in the config file - even though nxagent has been started with a different resolution [20:57] <mikedep333> yeah. I have a partial workaround at work (disable kscreen2 for servers that are only accessed remotely. Workstations which are accessed both locally and remotely still have it enabled.) [20:57] <mikedep333> yeah [20:58] <Ionic> well, the workaround for kscreen2 works mostly fine, I'm just pointing out that GNOME 3 might have a similar issue [20:58] <mikedep333> yeah [20:58] <-- dgandhi (~dan@wsip-68-107-176-242.ph.ph.cox.net) hat diesen Server verlassen (Quit: Leaving.). [20:59] <mikedep333> But I would need a way to disable kscreen2 for only x2go sessions (or something like that) in order to satisfy about half of my users at work. [21:00] <Ionic> I don't think this can easily be done [21:00] <mikedep333> Never mind then. [21:00] <Ionic> if KDE honors XDG_ variables, we could set a different run time dir [21:00] <Ionic> so that local and remote session configurations are decoupled [21:00] <Ionic> but that requires KDE to honor this, I have no idea if it does or if the configuration path is hardcoded [21:01] <mikedep333> Also, just to make it clear, I have the windows release process on a separate page from the windows build process: https://wiki.x2go.org/doku.php/wiki:development:release-howto-mswin [21:01] <Ionic> also, you'll get the ususal problems that making changes to the kde config in x2go won't reflect the change for local sessions [21:02] <Ionic> the same approach could be used for GNOME if that's totally required and supported [21:02] <Ionic> but as of right now, getting GNOME3 session to start up is arguably more important [21:02] <mikedep333> Yes. I hope to work more on that this weekend. [21:02] <Ionic> so that work isn't finished yet, right? [21:03] <h1Org> what is the offical way from freedesktop.org? [21:03] <Ionic> h1Org: for what? decoupling remote vs. local config data? [21:03] <Ionic> I'd be surprised if FDO even has an "official way" for that [21:04] --> Statler (~Georg@p579FE1CB.dip0.t-ipconnect.de) hat diesen Kanal betreten. [21:05] <h1Org> Ionic: maybe they should have ! /mv/orca/ [21:05] <Ionic> XDG* variables are a FDO thing, though [21:06] <h1Org> so, first hour, shall we proceed? [21:07] <MeinNameIstRetro> I guess we should. [21:07] <Ionic> mikedep333: I guess you can't give an ETA for the GNOME3 stuff? re: the "small" x2goserver release: wait for this to be finished (including a backport), or just continue without GNOME3-related changes? [21:08] <mikedep333> I'd say there's a 25% chance I'll have improved gnome3 support in the master branch of x2goserver and the 3.5.x branch of nx-libs by the end of this weekend. [21:09] <Ionic> *master branch of nx-libs, the 3.5.x branch points to the last commit before the latest release [21:09] <MeinNameIstRetro> How far are we from the "small" server release if we don't incorporate mikedep333's intended changes? [21:10] <Ionic> mostly good to go, I guess [21:10] <mikedep333> Well, I think all of my changes are small and safe. [21:10] <mikedep333> They are based on conditions like "Are we running Ubuntu 14.04 or later, or is GNOME 3.8 or later detected?" [21:10] <h1Org> MeinNameIstRetro: and the issue about “How do we notify the user of $THINGS that are server-side issues” [21:11] <mikedep333> If those conditions are met, GNOME never worked anyway. [21:11] <Ionic> I've tested upgrading the current stable builds against the to-be-released nx-libs and x2goserver versions on debian stretch and fedora 26 and both times it worked [21:11] <mikedep333> So they are safe to release. [21:11] <Ionic> h1Org: drop that please, this is not a trivial task. if we block releases based on that we won't have a release any time soon [21:12] <MeinNameIstRetro> mikedep333: yeah, I was just wondering if we should wait for your changes or maybe do another small release between the intended small and big releases if you manage to come up with something $SOON, but not by this weekend [21:12] <Ionic> I'll still have to run actual tests by connecting to such a machine, but unless something unexpectly happens it should also be good [21:13] <h1Org> Ionic: no problem: Alex would like to take part in this discussion too (notification) [21:14] <Ionic> okay? [21:15] <h1Org> Ionic: seems so... *spinner* [21:15] <h1Org> So the notification issue is dropped for the small release. [21:16] <MeinNameIstRetro> Indeed. [21:16] <Ionic> it's a valid point for improvement, but shouldn't be a release blocker [21:16] <h1Org> Should it be added to the "big release" as called by MeinNameIstRetro? [21:17] <h1Org> is it Ok to switsch now to the big release, as it would be the next topic? [21:17] <MeinNameIstRetro> h1Org: I'm guessing BigRelease+1, because we have about 4 weeks left for reaching release status [21:17] <Ionic> no, not even to that. the "big release" is too important to be blocked by this [21:17] <h1Org> Ionic: Ay! [21:18] <h1Org> so would it be OK for the #X2go people to give the new release a name now? [21:19] <h1Org> I would suggest Saimaa (https://en.wikipedia.org/wiki/Saimaa_ringed_seal), to keep in the line with places where you can find qute seals [21:19] <Ionic> well to give an ESR bundle a name, yes [21:19] <Ionic> the new x2goserver release doesn't need a name [21:19] <-- MeinNameIstRetro (~Stefan_Ba@ip-109-42-3-118.web.vodafone.de) hat diesen Server verlassen (Read error: Connection reset by peer). [21:19] <h1Org> It would be again a very exotic place for seals [21:20] --> MeinNameIstRetro (~Stefan_Ba@ip-109-42-3-118.web.vodafone.de) hat diesen Kanal betreten. [21:20] <MeinNameIstRetro> Sorry, LoC [21:20] <MeinNameIstRetro> Phoca hispida saimensi is the name [21:20] <h1Org> japsand -> baikal -> saimaa [21:20] <MeinNameIstRetro> so we should probably call it saimensi? [21:20] <MeinNameIstRetro> ah [21:21] <Ionic> makes sense [21:21] <MeinNameIstRetro> I do wonder if the "aa" might be confusing potential users. [21:21] <h1Org> MeinNameIstRetro: The place [21:21] <MeinNameIstRetro> Wait, I have a native finnish speaker next to me [21:21] <Ionic> I guess it can lead to misspellings... [21:24] <MeinNameIstRetro> Okay, Finnish speaker says "Saimaa" is the proper place name ... [21:24] <MeinNameIstRetro> Saimaan would be "of Saima" [21:24] <MeinNameIstRetro> *Saimaa [21:25] <h1Org> MeinNameIstRetro: Thanks to your friend! [21:26] <h1Org> Ionic: It is not that easy to find places arround the world where the seals are "safe"... [21:26] <Ionic> I figure :) [21:26] <Ionic> the name is fine by me [21:26] <h1Org> Ionic: ok, you'll find a lot of sands in Germany, but they are called Trischen or Südersand,... [21:27] <h1Org> ..Düne... :) [21:27] <h1Org> So if you'ra all ok with it... ? [21:27] <h1Org> *spinner* [21:27] <h1Org> with saimaa... [21:27] <h1Org> of cause [21:28] <Ionic> sure, why not [21:28] <MeinNameIstRetro> Yes, Saimaa it is [21:29] <h1Org> Ok, then back to the issues/whishes about saimaa [21:29] <h1Org> and the thrilling date [21:30] <MeinNameIstRetro> so saimaa would be our ESR and thus the "small" release [21:30] <Ionic> again, saimaa won't be the new x2goserver release but the name for the ESR [21:30] <Ionic> right [21:30] <h1Org> true [21:31] <Ionic> regarding the big x2goserver release: I've also tested upgrading from x2go stable to heuler on these machines and on ubuntu and it worked (mostly) fine [21:32] <MeinNameIstRetro> Do we need a name for the big release too? [21:32] <Ionic> no, we don't [21:32] <MeinNameIstRetro> (is there a mythical monster seal we could name it after?) [21:32] <MeinNameIstRetro> (mothseala) [21:32] <Ionic> we typically have never given names to specific package versions [21:32] <Ionic> other than the bundles [21:33] <MeinNameIstRetro> alright. [21:33] <h1Org> “Master Bug” created? -> MeinNameIstRetro [21:34] * MeinNameIstRetro dodges the question and watches it hit Ionic [21:34] <Ionic> no, I haven't created a master bug yet [21:35] <MeinNameIstRetro> Ionic: Could you update us on the status of the intended patches/additions that Uli had brought forth as blockers? [21:35] <Ionic> but I've got the info that out cutoff date is march 1st 2018 [21:35] <Ionic> *that our cutoff [21:35] <MeinNameIstRetro> our cutoff date for Ubuntu LTS? [21:35] <Ionic> yep [21:36] <MeinNameIstRetro> That sounds unlikely [21:36] <Ionic> the earlier freeze relates to something we don't care about [21:36] <Ionic> but it is [21:36] <MeinNameIstRetro> Mike#1 mentioned a freeze in early December [21:36] <Ionic> yes, but he interpreted that wrongly [21:36] <MeinNameIstRetro> I'd still aim for that release date [21:37] <MeinNameIstRetro> I know we have customers eagerly waiting for the new release because they expect it to solve certain issues for them [21:37] <Ionic> that is the "feature" freeze date - determines what packages will be included on the release media [21:37] <Ionic> we don't care about that [21:37] <MeinNameIstRetro> Ionic: Yes so we should have our features ready by then, no? [21:37] <Ionic> no, because we don't want to be part of release media [21:38] <MeinNameIstRetro> doesn't Ubuntu include us in their own repo and thus on their release media? [21:38] <Ionic> that's two different things [21:38] <Ionic> release media strictly are the ISOs that accompany a release [21:39] <MeinNameIstRetro> Yes, and ...? [21:39] <Ionic> the package repository is way bigger [21:39] <Ionic> and not part of that [21:39] <MeinNameIstRetro> And you are 100% sure that at present, X2Go is not part of their release media, and there is no chance of getting on it either? [21:39] <Ionic> the ISOs contain a very limited set of packages (mostly to make live image usage work) and even differs between versions [21:40] <MeinNameIstRetro> Well but surely there is a full DVD ISO, or set of ISOs, for offline installation? [21:40] <Ionic> why would you want x2go packages on the release media? [21:40] <MeinNameIstRetro> Larger potential user base, easier to install in "offline" situations, and on low-bandwidth links [21:41] <Ionic> no, there isn't [21:41] <Ionic> just the usual -desktop and -server DVD images [21:42] <Ionic> getting x2go on that media isn't something we should care about [21:42] <Ionic> even less so x2goserver [21:42] <Ionic> it might sense to have x2goclient available on release media, but even that's difficult to accomplish because what package makes it onto the DVD image is a matter of popularity and usefulness [21:42] <MeinNameIstRetro> Ionic: Yes, but we have announced the early December release date already in various places, I'm not going to push that to March 1st, 2018 without a very very good reason [21:43] <Ionic> MeinNameIstRetro: I strongly suggest not announcing stuff that isn't finished [21:44] <Ionic> early december is still the target date, but if it doesn't work out we at least have a chance to land into ubuntu 18.04 LTS still [21:44] <MeinNameIstRetro> Ionic: Well the announcement is "Early December, unless feces -> fan" [21:45] <h1Org> MeinNameIstRetro: Maybe a new Meeting in early December can help here? [21:45] <Ionic> but remember that it's already november [21:45] <MeinNameIstRetro> so let's aim for early December, because if we miss that date, then Mid-January 2018 is the earliest do-able next option. [21:46] <MeinNameIstRetro> h1Org: We need uli's and mike#1's input here, too bad they both didn't attend today. I'm not sure, maybe we should have another meeting in a week or two with them? [21:46] <MeinNameIstRetro> no, in a week won't work [21:46] <h1Org> I would suggest to meet again in december and discuss the date then [21:46] <MeinNameIstRetro> in two weeks, maybe [21:46] <Ionic> regarding the new feature uli has been working on: no news on that front [21:46] <h1Org> Ok - so it can't be decided now in any way... [21:47] <MeinNameIstRetro> h1Org: Meeting in early December is too late IMHO, in two weeks from now is when we should meet again. [21:47] <Ionic> no news as in "I haven't looked into it" [21:47] <h1Org> MeinNameIstRetro: So 2 Meetings [21:47] <h1Org> ? [21:47] <Ionic> he's waiting on me to get this straightened out [21:47] <MeinNameIstRetro> possibly 2, yes @ h1Org [21:47] <h1Org> MeinNameIstRetro: Ok, would it be a good idea then, to have a doodle again on our wiki? [21:48] <h1Org> for the dates? [21:49] <MeinNameIstRetro> h1Org: Nah, let's just set them at November 16 and December 7 right now. [21:51] <MeinNameIstRetro> Ionic: did you see any commits by uli lately? [21:51] <Ionic> in what sense? [21:51] <Ionic> he has been working on MESA stuff in nx-libs [21:51] * h1Org will be not available in Nov 16 [21:52] <MeinNameIstRetro> Ionic: and that needs to go into the big release or is for BR+1? [21:52] <gratuxri> Just make more dates, so that people can choose right one [21:52] <Ionic> MeinNameIstRetro: no, that's completely decoupled [21:53] <Ionic> none of the features that are on the list are critical for BR [21:53] <MeinNameIstRetro> Ionic: and regarding the open bugs he listed as BR-blockers, any commits? [21:53] <Ionic> which open bugs that are BR-blockers? [21:53] <Ionic> it's only xinerama, really, that needs implementation in x2goclient [21:53] <MeinNameIstRetro> Ionic: According to our TOC, these are: Changes in Xinerama, “Keyboard Cloning”, “Auto-Grab”, “Input Lock” [21:54] <Ionic> keyboard cloning is not a feature we need for the big release - we already have keyboard handling [21:54] <Ionic> if the feature is merged into nx-libs then I'll have to adapt this [21:54] <MeinNameIstRetro> well it's listed as "needs to go into BR" since the Gathering [21:55] <Ionic> auto-grab is something that is still WIP [21:55] <h1Org> MeinNameIstRetro: Let's inform the list about the new dates - it isn't even possible for me to get Dec7 save at the moment. Maybe a we discuss a doodle later. [21:55] <Ionic> and input lock goes with the keyboard settings cloning [21:55] <MeinNameIstRetro> And this is allstuff only Uli can take care of, no one else? [21:56] <Ionic> no, but he's spearheading it [21:56] <Ionic> currently he's still waiting on my feebdack [21:57] <Ionic> but I've been busy to get the client release out and x2goserver and our legacy nx-libs version into shape for a release, as well as the snapshots stuff [21:57] <MeinNameIstRetro> wait, let me check when uli returns from vacation [21:59] <h1Org> Ok - is it OK to end our 7th Developer Meeting after 2h? [22:00] <Ionic> probably, yes [22:00] <h1Org> We sould meet again soon - and the open tasks will be moved to the next meeting [22:00] <MeinNameIstRetro> okay, Uli will be back next week, and is not available on November 23rd [22:00] <h1Org> Thank you very much for your time, the discussion and passion! [22:01] <h1Org> The channel is now open for questions again!