A page in your DokuWiki was added or changed. Here are the details: Date : 2017/12/13 20:36 Browser : Mozilla/5.0 (X11; Linux x86_64; rv:52.9) Gecko/20100101 Goanna/3.4 Firefox/52.9 PaleMoon/27.6.2 IP-Address : 134.3.37.90 Hostname : HSI-KBW-134-3-37-90.hsi14.kabel-badenwuerttemberg.de Old Revision: https://wiki.x2go.org/doku.php/2017-12:day-2017-12-13?rev=1512886159 New Revision: https://wiki.x2go.org/doku.php/2017-12:day-2017-12-13 Edit Summary: Added Chat Log User : stefanbaur @@ -10,6 +10,413 @@ ==== Raw Chat Log ==== <file> - TBD + (19:37:50) Stefan Baur: h1Org: feel free to start, my main machine is booting up, I'll just move the remote session over once it's ready - and until then, I'm attending more or less passively + (19:38:26) h1Org: 8th ΞX2Go Development Meeting + (19:38:38) Stefan Baur: Ionic: topic change pls + (19:38:40) h1Org: Again: + (19:38:46) 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! + (19:39:20) h1Org: The corresponding page this meeting will be: https://wiki.x2go.org/doku.php/2017-12:day-2017-12-13 + (19:40:09) h1Org: The chatlog of this meeting will be available on the same page after the meeting + (19:40:10) Ionic hat das Thema zu X2Go is a suite to build Linux based terminal farms. The channel's language is English. For further info on X2Go please visit: http://www.x2go.org This channel is currently used for the 8th Developer Meeting. abgeändert + (19:41:08) h1Org: MeinNameIstRetro: I think we should start with the topic "next release"? + (19:41:15) Stefan Baur: So the big question is: are we ready to release? And this depends on the answers of a few questions that will mainly be directed at Uli .... + (19:41:55) Stefan Baur: though the first one probably involves ionic as well .... + (19:42:10) Mihai Moldovan: none of these are critical for a release + (19:42:30) Stefan Baur: Updated Xinerama support needs server- and client-side changes. My understanding is that you, uli, only worked on the server-side part(s). + (19:42:54) uli422: no, I worked on the nx parts. + (19:43:02) Stefan Baur: so, are your changes done, uli? And did anyone - ionic, maybe - make the corresponding changes in x2goclient? + (19:43:37) Mihai Moldovan: changes within NX are done; I haven't had time to update x2goclient yet + (19:43:39) uli422: afaik we have been talking about the necessary changes for x2go + (19:45:09) uli422: as I told you on the gathering we lose the xrandr feature with activated xinerama. We need to see if that is a problem for the user's + (19:45:13) uli422: users + (19:45:44) Stefan Baur: okay - just for clarification - do we need changes in NX-libs AND in X2GoServer AND in X2GoClient? Or NX-libs && X2GoClient? + (19:46:03) Mihai Moldovan: nx-libs, x2goserver and x2goclient, yes + (19:46:37) Mihai Moldovan: in x2goserver, we need to enable +xinerama, nx-libs is done and x2goclient needs to stop doing its old xinerama workarounds with the new version + (19:46:40) Stefan Baur: okay, so uli is done on the NX-libs side. ionic, you said you haven't had time to take care of x2goclient, how about the server side? + (19:46:41) Stefan Baur: ah + (19:47:11) uli422: IOnic: rrxinerama is on by default, you'd need --rrxinerama to turn it OFF + (19:47:16) Mihai Moldovan: ah + (19:47:19) Stefan Baur: so for x2goserver, it's only the possibly changed default in the config? + (19:47:26) Stefan Baur: No code changes? + (19:48:11) Mihai Moldovan: no, right, rrxinerama is turned on by default, we just need the client to turn it off if the user disables that option essentially + (19:48:12) uli422: MeinNameIstRetro: no, x2goclient has to take care of the nx version of the server side. If it is 3.6 it must behave different than for 3.5. + (19:49:23) Mihai Moldovan: uli422: what happens if it doesn't take that into account yet? + (19:49:29) Stefan Baur: uli422: yes, I understand X2GoClient must be adapted to work with both old and new implementations. But on the X2GoServer side, all that needs to be changed is the config option, and only if it is the wrong default at the moment? + (19:50:34) uli422: ATM x2goclient will a) create a xinerama.conf on the server and b) permanently update that and c) set LD_LIBRARY_PATH for nxagent to make it load the modified libXinerama. + (19:51:23) uli422: for 3.6 it will need nothing of that. But it will need to set --rrxinerama if the user does not want to have xinerama and deactivates the option in the client side session config, + (19:52:35) Mihai Moldovan: uh, wait, LD_LIBRARY_PATH is set by x2goserver - and only if 3.6 isn't used + (19:53:17) Stefan Baur: uli422: what does losing the xrandr feature mean for the user? Does it make resizing the screen on a session resume impossible, so the user is stuck with a viewport vs. zoom view (like in session shadowing mode)? + (19:53:27) Mihai Moldovan: and you likely mean -rrxinerama + (19:53:48) uli422: Am I must correct myself: the LD_LIBRARY_PATH must be set for the _clients_ on the server, not for nxagent + (19:54:08) uli422: Ionic: yes, one - + (19:54:35) Mihai Moldovan: yes, but that's handled by x2goserver and that's already doing the right thing™ + (19:54:56) Mihai Moldovan: (checking if x2goserver-x2goagent is installed and either skipping LD_LIBRARY_PATH or setting it) + (19:54:56) Mike#1: MeinNameIstRetro: missing randr support can lead to non-function desktop sometimes. As they expect it to be present these days. + (19:55:28) Stefan Baur: sunweaver: Hey! Glad to have you aboard, I thought you were unable to make it! + (19:55:29) ***Mike#1 is half present and highlightable... + (19:55:34) uli422: MeinNameIstRetro: currently you can use xrandr 1200x800 and nxagent will resize. This will not work with the new xinerama code being active. I have re-implemented the old bahviour for the -rrxinerama case, but I am not sure if that already made it in the code. Checking... + (19:55:59) Mike#1: it's there, uli422. + (19:56:07) Stefan Baur: sunweaver: Can you give more details on the "sometimes"? + (19:57:38) Mike#1: oh wait, this is about xrandr command API working correctly. + (19:57:59) Mike#1: ignore me. + (19:58:21) Mike#1: uli422: do you know any GUIs troubling you with that one issue? + (19:58:37) Mike#1: Or is it just that the xrandr command line tool does not produce correct results. + (19:58:44) ***Mike#1 thinks this issue is minor... + (19:58:45) uli422: no, but people that are using some custom setup might struggle + (19:58:57) ***uli422 agrees + (19:59:39) Mike#1: minor as in it will not bother 99% of the people... + (19:59:53) Stefan Baur: I don't want to dive into the gory details here, but would it be possible to give the xrandr command line tool "something to talk to" that just returns a dummy value? i.e. one that is wrong, but harmless? + (20:00:18) Mike#1: you are diving into the gory details... + (20:00:26) Mike#1: we have other concerns more pressing. + (20:00:30) Stefan Baur: *dons scuba gear* + (20:00:52) uli422: MeinNameIstRetro: that's what I thought but I can't seem to getting it running right now + (20:01:22) Stefan Baur: okay, so, to sum it up for Xinerama, one minor issue that's not release critical, and work needs to be done on X2GoClient. Right? + (20:01:40) Mihai Moldovan: yes, but even the x2goclient issue isn't really critical + (20:02:34) Stefan Baur: I understand and am for releasing the server even if the client-side changes can't be done in time, but I would prefer if we can get the updated client out this month as well + (20:02:56) Mihai Moldovan: probably, I've just had other things to do + (20:03:08) Mihai Moldovan: but it doesn't terribly matter, users are using outdated client versions anyway + (20:03:12) uli422: sunweaver: AFAIKs the code I was referring to ist NOT included. + (20:03:22) Stefan Baur: Okay, so, next item for Uli: What's the state of autograb and keyboard lock? + (20:03:26) Mihai Moldovan: for example, both debian and ubuntu ship x2goclient directly in their repositories and that's what these users are mostly using + (20:03:34) Mihai Moldovan: autograb and input lock are still WIP + (20:03:46) uli422: MeinNameIstRetro: neither is working cleanly and I cannot seem to get it working. I need help here. + (20:04:20) Mihai Moldovan: but, also not relevant for a release + (20:04:26) Stefan Baur: uli422 that was the last feedback we got from you, and you were referring to sunweaver as the one that would be the right candidate to help you. Did he try? + (20:05:18) uli422: well, anyone that has sufficient X knowledge. The problem is the fullscreen switch that is nor working cleanly on all window managers. + (20:05:20) Stefan Baur: Ionic: Yes, maybe, but we need a feature list and as the community manager and lead evangelist I would like to know what I can promise the users for the upcoming release and what not, so I do need to ask ;) + (20:06:02) uli422: MeinNameIstRetro: we can implement both as technological previews. But I cannot promise that it will ever work cleanly. + (20:06:18) Mihai Moldovan: yes, but don't confuse this post-release points with release-critical ones + (20:06:20) Stefan Baur: uli422 did you ask sunweaver about it? Did he reply? + (20:06:33) uli422: you can block your whole local desktop by using these and will not get out anymore if you are unlucky + (20:06:52) Stefan Baur: uli422 in that case these features should stay in heuler until properly matured. + (20:06:53) uli422: MeinNameIstRetro: yes, he wanted to check that, but he has tons of tasks... + (20:07:28) Stefan Baur: uli422 okay, see, that's a statement I can work with. I mean, another option could have been that he did look at it and was out of ideas ... + (20:07:47) uli422: But generally I am against including them. Just because I see 3.6 as a drop-in replacement that shoudl not be overloaded with such stuff. + (20:08:13) Mihai Moldovan: uli422: it's a feature highly asked for by users + (20:08:31) Stefan Baur: uli422 so, we'll keep autograb and input lock out of the upcoming release. + (20:08:36) Mihai Moldovan: mainly because they have problems with local DE's capturing key combos that are also used within sessions + (20:09:09) uli422: Ionic: well, as logn as the are not using intermediate switches to fullscreen it is quite usable + (20:09:13) Mike#1: uli422: https://github.com/ArcticaProject/nx-libs/pull/475/files -> right... not in. + (20:09:21) Mike#1: why did we loose track of it. + (20:09:51) Mike#1: about distro and RC bugs... + (20:10:00) Stefan Baur: Ionic: I'm not sure if there's a standard for this, but e.g. I'm using Trinity, the KDE3-fork, and I added custom key combinations as *alternates* for when I'm logged in via X2Go. Trinity (and KDE at least in KDE3) offers a secondary mapping. + (20:10:07) uli422: sunweaver: exactly, but not the full PR, just one poart + (20:10:12) Mike#1: into Debian, I can get any RC bug fix, be it unstable - testing - stable - oldstable or LTS. + (20:10:37) Stefan Baur: Ionic: So maybe we could provide users with recommended secondary mappings they could add to their sessions? + (20:10:41) Mike#1: for Ubuntu, we need someone with MOTU status (Master Of The Universe) in order to get bug fix uploads into an already release Ubuntu component. + (20:10:58) uli422: MeinNameIstRetro: that's a feature of trinity and maybe other DEs, autograb is a generic solution + (20:11:09) Mihai Moldovan: MeinNameIstRetro: they can of course re-map most things themselves in remote sessions, but that's painful + (20:11:25) Mike#1: we need to get autograb in, too... + (20:11:35) Stefan Baur: uli422 yes, I'm not talking about ditching your solution completely, just about offering a stop-gap measure until your solution is mature enough for a stable release. + (20:11:39) uli422: Ionic: plus there are keys the cannot map because the local DE will capture them + (20:11:49) Mike#1: I'd even say that we get it in in slightly broken state (KWin and Openbox are tricky). + (20:12:15) Mike#1: MeinNameIstRetro: don't waste time on work-arounds. + (20:12:22) Stefan Baur: sunweaver: wait, are you saying autograb is release-critical from an X2Go stable release point of view? + (20:12:39) Mike#1: nope, but a really cool feature!!! + (20:12:41) uli422: So, plan for me: extract the xinerama fallback patch from #475 and make a separate PR + (20:12:50) Mike#1: uli422: yep. + (20:12:52) Mihai Moldovan: no, it's not + (20:13:11) Mike#1: the max res PR should be merged, too. + (20:13:18) Mike#1: but it's good to have them separate. + (20:13:34) Stefan Baur: sunweaver: I'd rather we release without autograb, and if uli can get it to work in time before the Ubuntu LTS release we want to get in, we can do a minor release. + (20:13:35) uli422: sunweaver: ok, I'll take care of that + (20:13:37) Mihai Moldovan: I mostly haven't looked into that one because it was tagged WIP + (20:13:50) Mihai Moldovan: and because there were other PRs awaiting attention + (20:13:54) uli422: Ionic: your are welcome! + (20:14:27) Mihai Moldovan: autograb isn't part of the current 3.5.99 series, so yeah, of course without it + (20:14:29) Stefan Baur: uli, sunweaver, regarding autograb, what I absolutely don't want is that we ship something as "stable" that worsens a situation for some users. + (20:14:38) Mike#1: MeinNameIstRetro: agreed. + (20:15:01) uli422: we can add a -experimental switch + (20:15:07) Mike#1: Ionic: w-i-p PRs should not bother you until they are non-w-i-p. + (20:15:20) Stefan Baur: uli422 I wouldn't. Whoever wants to toy with it can use heuler. + (20:15:55) uli422: MeinNameIstRetro: well, we do not have nx-libs-heuler packages with that feature(s) + (20:15:57) Mike#1: uli422: nope. + (20:16:43) Stefan Baur: uli422, well, we're doing a release soon. After that release, you could add the feature to the nx-libs in heuler. + (20:17:08) Mihai Moldovan: the features only land in the unstable code after reviews and a merge + (20:17:29) Stefan Baur: ah, our mergemaster speaks ;) + (20:17:53) Mihai Moldovan: since they are only part of a PR so far, there aren't any builds with it + (20:18:26) Mike#1: no jokes!!! + (20:18:45) Mike#1: without Ionic, the quality of nx-libs would be far worse... + (20:18:59) Mike#1: none of us is as good a code reviewer as Ionic is. + (20:19:08) uli422: MeinNameIstRetro: Ionic can build a test release for you (I think), so you cn have look at the features and judge about the quality yourself + (20:19:26) ***uli422 absolutely agrees + (20:19:29) Stefan Baur: sunweaver: are you going to rat me out to the geheime witzpolizei? ;) + (20:19:30) Mihai Moldovan: the same goes for keyboard cloning, still only part of a PR and that's my fault + (20:19:31) Mike#1: uli422: Ionic: we will work on two branches after the release... + (20:19:42) Mike#1: 3.6.0.x and 3.6.x (targetting 3.6.1.0). + (20:19:53) Mike#1: The 3.6.x branch will be built by Arctica build server. + (20:20:02) Mike#1: the 3.6.0.x is appropriate for X2Go heuler. + (20:20:11) Mihai Moldovan: hum + (20:20:35) Mihai Moldovan: well, for the upcoming release in a few days or so, I'll sync up arctica's nx-libs repo with x2go's + (20:20:44) Stefan Baur: Okay, again summing up... + (20:20:44) Stefan Baur: Xinerama: All critical issues done, Client release TBD, delay non-critical + (20:20:44) Stefan Baur: autograb, input lock -> not going into the next release + (20:21:04) Mike#1: Ionic: yep. + (20:21:13) Stefan Baur: keyboard cloning - since it's also still only part of a PR, how are the chances of getting that into the release? + (20:21:30) Mike#1: we possibly will be working some time via 3.6.x branch, but for merges like the devPrivates ABI PR, we need two switch branches. + (20:21:31) Mihai Moldovan: non-existent, it's a huge PR + (20:21:32) uli422: regaring keyboard cloning: it is working, but Ionic is not happy with some code duplication (to be honest: I agree) and there is no automatic keyboard update if it changes on the client side + (20:21:44) Stefan Baur: okay, out with it then. + (20:21:49) Mihai Moldovan: plus it would also require changes in x2goserver + (20:22:07) Mike#1: -> 3.6.1.x + (20:22:09) Stefan Baur: tag "rnext+1" + (20:22:21) uli422: Ionic: it's TWO no so huge PRs now:, see #591 + (20:22:31) Stefan Baur: So what's new on the MESA/OpenGL/GLX front? + (20:22:32) Mihai Moldovan: uli422: yeah, true + (20:22:51) Mihai Moldovan: dunno, GLX is still old and uli has been working on updating MESA within nxagent + (20:22:59) Mihai Moldovan: in general, the plan is to drop the bundled copy anyway + (20:23:04) Mihai Moldovan: since that's what X.Org did + (20:23:15) Mike#1: leave as is for upcoming release. + (20:23:18) uli422: MeinNameIstRetro: we have a version with Mesa 7,7 (instead of 6.4.2), but just yesterday I discoverd that it does not compile, something is broken there. + (20:23:20) Mike#1: -> 3.6.1.x + (20:23:23) Mihai Moldovan: as far as our tests went, at least glxgears works + (20:23:44) Stefan Baur: better GLX support would be really nice in the new release ... + (20:23:46) Mike#1: also doom and extrem tux racer. + (20:23:54) Mihai Moldovan: for some reason, we also have direct rendering available as reported by glxinfo + (20:23:54) Mike#1: it is not better. + (20:23:59) Mike#1: it is basically the same. + (20:24:19) Stefan Baur: IDDQD IDKFA 5 <Ctrl> + (20:24:21) uli422: sunweaver: well, it reports some newer versions and probably includes some fixes + (20:24:21) Mike#1: but once we have switch X2Go to nx-libs 3.6, we can inject it without heavy changes in X2Go Server. + (20:24:22) Stefan Baur: whoops sorry ;) + (20:24:24) Mike#1: nor client + (20:24:41) akik: any idea why having opengl enabled on the client side creates those graphics artifacts? + (20:24:54) uli422: akik: ? + (20:24:55) Mihai Moldovan: akik: in TB? + (20:25:07) Mihai Moldovan: ah akik talks about something else + (20:25:11) Mihai Moldovan: he means compositing + (20:25:31) Mihai Moldovan: compositing leads to weird artifacts that can be avoided if disabling it in MATE + (20:25:32) Stefan Baur: sunweaver: what uli422 just said - wasn't it mikedep333 who said something about a newer DE needing GLX for something? + (20:25:38) akik: on plasma 5 with opengl as the "rendering backend" i get graphics artifacts + (20:25:39) Mike#1: uli422: if you can get 7.7 work without devPrivates, I am happy to take another shot at merging. + (20:25:48) akik: this is the client side ui + (20:25:52) Mike#1: btw. you did not rebase that branch, but merge 3.6.x in. + (20:25:59) Mike#1: very bad and inappropriate for mergin. + (20:26:08) uli422: sunweaver: you wanted to cleanup/flatten the pr and then merge + (20:26:44) uli422: sunweaver: aehm, are you referring to #534? + (20:27:06) Mike#1: uli422: ok, I'll take over... + (20:27:19) Mike#1: Hope I get that done on Friday. + (20:27:25) uli422: sunweaver: ah, you mean the stuff I did yesterday? I have thrown that away again... + (20:27:45) Mike#1: uli422: yes. + (20:27:48) uli422: sunweaver: just playing with the github GUI + (20:27:54) Mike#1: ok. + (20:28:56) Stefan Baur: gentlemen, can I get a quick lay-person explanation as to why we should not include updated GLX code even though uli explained that we report a newer version and have some fixes in there? + (20:29:22) Mike#1: we will include the newer code (me, on Friday). + (20:29:27) Mihai Moldovan: there are not really any fixes in there, it's not required and won't make anything better, MeinNameIstRetro + (20:29:36) uli422: MeinNameIstRetro: for a real progress in OpenGL we need to integrate DRI. And for that to work we need to backpot devPrivates and ACE. Both are complicated tasks. sunweaver already started working on them, but no ETA + (20:30:05) Mike#1: nope, I really need to be left alone at Uni to do that. + (20:30:23) uli422: Ionic: we step from mesa 6.4.2 to 7.7, there are surely fixes included in such a range. + (20:30:28) ***Mike#1 also got slightly side tracked by working on Ayatana Indicators recently. + (20:30:52) Mihai Moldovan: uli422: probably, but I don't think that users will notice that + (20:31:13) Mihai Moldovan: plus the integrated MESA software renderer is only used for indirect context, everything else goes via system MESA's libGL + (20:31:15) ***Mike#1 neither... + (20:31:19) uli422: Ionic: maybe, maybe not + (20:31:52) Mihai Moldovan: *shrug* + (20:31:56) uli422: Ionic: which, BTW, is not working for me (Intel graphics) + (20:32:00) akik: Ionic: i needed to change opengl->xrender in client side ui. after that it didn't matter what settings i had in x2go mate session + (20:32:20) Mihai Moldovan: akik: hum, okay, no idea why that happens + (20:32:31) Stefan Baur: and again for someone that isn't knee-deep in the de^Wcode, the three items MESA, OpenGL, GLX are not that interconnected that it's an all or nothing? + (20:33:00) uli422: MeinNameIstRetro: yes, they are. + (20:33:14) Mike#1: we do the 7.7 merge and this should leave functionality as is, plus posibly fixes. + (20:33:22) uli422: sunweaver: right + (20:33:23) Mike#1: and they are interconnected. + (20:33:27) Stefan Baur: (dang, sunweaver, next time you mention Doom, give me a trigger warning, so I can control my urges to type Doom references. ;)) + (20:33:33) Mike#1: but nothing will be different from what we have with 3.5 + (20:33:40) akik: Ionic: but it has the bad side effect that e.g. glxgears doesn't open its window. glxinfo still works + (20:34:05) Mike#1: akik: that problem need to be discussed later. + (20:34:12) Stefan Baur: sunweaver: so we're pulling in new versions of all three? + (20:34:21) Mike#1: file a good bug report, that makes it possible to reproduce your phenomenon. + (20:34:42) Mike#1: we are updating Mesa and adapt the GLX extension. + (20:34:42) uli422: MeinNameIstRetro: yes + (20:35:04) Mike#1: that provides the GLX extension (indirect GL rendering) + (20:35:21) Mike#1: indirect as in GL -> X11 -> nx-proto -> client X11 + (20:35:23) uli422: MeinNameIstRetro: you need mesa to build the GLX extension. And you need to update the GLX extension code to work with the updated mesa code. + (20:35:33) Mike#1: which is badly slow as before, but work. + (20:35:36) Stefan Baur: sunweaver: so assuming you start on Friday as intended, how long will that take? I'm asking because of the looming release deadline ... + (20:37:04) Mike#1: I will update the PR and then it is on uli42 or Ionic to revisit my changes. Ideally Ionic. So that all three of us have gone over it. + (20:37:26) Mike#1: the rebasing / flattening effort (my part) is not so intense and time consuming. + (20:38:43) uli422: sunweaver: add some time to fix the compliation problems I encountered yesterday. It's mostly about a broken patch and a missing PUBLIC define. I haven't found out why I stopped working + (20:38:53) Stefan Baur: Is there anything else we need to discuss regarding the upcoming release? Any open issues anyone sees that haven't been mentioned so far? + (20:39:12) Mihai Moldovan: sunweaver: did 3.5.99.10 have the connection problems that were only fixed by later commits by uli/salva? + (20:39:32) Mihai Moldovan: i.e., would releasing 3.5.99.10 in x2go be a bad idea? + (20:39:55) uli422: Ionic: yes, it would be bad. + (20:40:15) Mihai Moldovan: okay, so I'm hold up waiting for .11 anyway + (20:40:15) Mike#1: we could do 3.5.99.11 tomorrow. + (20:40:36) uli422: sunweaver: have we any clues regarding mbecroft's reports? + (20:40:44) Mike#1: nope. + (20:40:46) Mihai Moldovan: .11 might also be wonky due to mario's reports but we'll have to take the chances I guess + (20:41:06) Mihai Moldovan: AFAIK there's only one thing left, but I have no idea what happened there + (20:41:08) Mike#1: improvement goes through spirals... + (20:41:14) uli422: Ionic: I am using HEAD since monday or tuesday and it is damn stable + (20:41:17) Mihai Moldovan: the crash that happened while reconnecting + (20:41:29) Mihai Moldovan: uli422: for him, nxagent crashed during reconnecting the client side + (20:41:30) Mike#1: Ionic: would it be an option to not do any logging during signal handling? + (20:41:41) uli422: Ionic: reconnection problems happen from time to time, but verrrry rarely + (20:41:43) Mihai Moldovan: in a location that doesn't even make sense + (20:42:47) Mihai Moldovan: sunweaver: the current code logs in signal handlers... we could remove that of course. the whole situation is messed up anyway, since signal handlers should *only* atomically update a variable and do nothing else + (20:42:58) Mihai Moldovan: nomachine had other ideas, though + (20:43:15) uli422: Ionic: is that solvable? Or too intrinsic? + (20:43:31) Mihai Moldovan: currently? nope + (20:43:54) Stefan Baur: Can I entrust you (sunweaver, uli422, ionic) to take care of the MESA/OpenGL/GLX issue and get the X2Go release out as soon as you're done (possibly waiting for ionic's changes to X2GoClient, maybe, but still...)? Or should we schedule another dev meeting maybe next week or so? Problem is, we're getting awfully close to the christmas holidays, so we should try to release next week. + (20:45:19) uli422: hmmm + (20:45:39) Mihai Moldovan: whatever, it doesn't really matter + (20:46:26) uli422: next Wednesday I won't be available + (20:46:42) uli422: nor next Friday + (20:46:50) Stefan Baur: Tuesday maybe? If we need a meeting at all ... + (20:47:10) Mihai Moldovan: other than that, I've created https://wiki.x2go.org/doku.php/download:saimaa + (20:47:16) uli422: Tuesday is possible + (20:47:22) Mihai Moldovan: the new ESR series we've been talking about + (20:47:30) Stefan Baur: Thank you, Ionic + (20:47:37) akik: saimaa <3 nice finnish touch? + (20:47:39) Mihai Moldovan: note that it only includes core server and client packages, without additional packages (like bindings) + (20:48:05) Mihai Moldovan: so users who want to stay on the currently stable server version can do so via switching to saimaa + (20:48:34) Stefan Baur: akik: keeping with the seal theme + (20:48:42) Mihai Moldovan: if they use any other package (like desktopsharing, bindings, cups-x2go, ...) they'll run into problems, but I don't want to support non-core packages as ESR's + (20:49:05) Stefan Baur: Ionic: I guess desktop-sharing and maybe cups-x2go might need to go in there as well + (20:49:32) Mihai Moldovan: I do not want to support them as ESR's, like I said + (20:49:55) Mihai Moldovan: cups-x2go has a high probability of having vulnerabilities as-is and desktop sharing is using the deprecated Qt4 toolkit + (20:50:20) Mihai Moldovan: committing to that in the long-run doesn't make sense + (20:50:32) Mihai Moldovan: I will need to slowly transfer all software using Qt4 to Qt5 + (20:51:07) Stefan Baur: hmm, we'll see how many complaints we get. Would it be possible to pull desktopsharing in via pinning? + (20:51:16) Mihai Moldovan: yes + (20:51:26) Mihai Moldovan: users can mix saimaa and main via pinning if they chose to + (20:51:32) Stefan Baur: okay, so maybe a wiki page explaining how to do that would help + (20:51:46) Mihai Moldovan: they just have to make sure that packages in saimaa overrides stuff in other repositories + (20:52:52) Mihai Moldovan: currently the repository wiki pages that only one component may be active at a time, but that's only because I didn't have time to figure out instructions for giving priorities to specific repositories (or using pinning) on all platforms + (20:54:13) Stefan Baur: okay. Not a priority, but keep it in mind that it would be a welcome addition. + (20:54:22) ***Mike#1 is gone 10 days starting on the 19th. + (20:54:52) Stefan Baur: uh-oh ... + (20:54:52) Mike#1: I can take care of the GLX / Mesa stuff on Friday, but nothing else. + (20:55:18) Stefan Baur: sunweaver: How "gone" is "gone"? Plunger-Worthy gone? + (20:55:49) Mihai Moldovan: MeinNameIstRetro: you're a system administrator experienced with pinning and have wiki editing rights... + (20:56:09) Mihai Moldovan: (all Saimaa packages have been built, btw) + (20:56:18) Stefan Baur: Experienced with pinning? I don't think so ... I know that it exists ... + (20:56:25) Mihai Moldovan: currently they are just a copy of our current release packages, but that will change of course + (20:56:45) Mihai Moldovan: debian, ubuntu, fedora, epel, opensuse, sle (but no ppc64 versions yet) + (20:57:15) Mihai Moldovan: I still need to actually write up an announcement + (20:59:32) Stefan Baur: so, I guess that means we won't have another dev meeting before the release, if it happens this month - which I hope. + (21:00:56) Mihai Moldovan: sunweaver: I sadly think that marios crash might have been a hard to trace unreproducible thing + (21:01:08) Mike#1: MeinNameIstRetro: Lappland, no electricity... + (21:01:14) Mike#1: no joke + (21:01:40) Stefan Baur: sunweaver: Any critical infrastructure that only you have access to? + (21:02:34) Mike#1: amospalla: has root access on Arctica servers. + (21:02:44) Mike#1: you find him on Arctica. + (21:02:47) Stefan Baur: sunweaver: Any server contracts expiring? + (21:02:52) uli422: Ionic: probably. this makes it even more important to fix all the leaks we find + (21:03:02) Stefan Baur: sunweaver: Any IPs changing? + (21:03:11) amospalla: _/ + (21:03:41) Mihai Moldovan: uli422: my current fear is that this may have either been caused by stack or heap corruptions or bad hardware... though I cannot rule out a programming error completely + (21:03:54) Mihai Moldovan: but it would be weird, since we didn't touch any of this code since .10 + (21:04:39) Mike#1: Ionic: I'll provide you access to the VM host hosting ymir. + (21:04:51) Mike#1: and the creds for the Hetzner UI. + (21:04:53) uli422: Ionic: borken RAM was my suspision from the beginning, but the logging code turned out as the main culprit + (21:05:21) Mihai Moldovan: okay, thanks + (21:05:26) Mihai Moldovan: uli422: yeah, but only for the leak + (21:05:30) Mihai Moldovan: "leak" + (21:05:40) Mihai Moldovan: since it wasn't a real leak, the memory was cleaned up at program exit... + (21:05:54) Stefan Baur: sunweaver: sounds like someone has either learned their lesson or is running out of storage space for more plungers ;)) + (21:06:41) Mihai Moldovan: uli422: the crash happened while calling SyncHandle() in code using Xlib within nxagent + (21:06:52) Stefan Baur: ionic: what are your plans for tomorrow and Friday? + (21:07:29) Mihai Moldovan: obviously because _XPrivSyncFunction was called multiple times... which shouldn't be possible + (21:08:18) Mihai Moldovan: MeinNameIstRetro: I don't know, I could probably update x2go's nx-libs master branch to arctica's 3.6.x branch and then do testing in VMs + (21:08:39) Mihai Moldovan: i.e., stable -> nightlies upgrade testing in VMs + (21:09:03) Stefan Baur: you mean stable -> nextstable, so to speak? + (21:09:21) Mihai Moldovan: well, the nightlies are nextstable, yes... + (21:10:12) Mihai Moldovan: the other possibility is to release the new x2goserver version without also updating to arctica's nx-libs + (21:10:30) Stefan Baur: sounds like a good idea. Do you think you could wedge in the Xinerama-X2GoClient-Changes as well? Because if sunweaver won't work on MESA/OpenGL/GLX before Friday, you won't be needed there before Friday, either. + (21:10:40) Mihai Moldovan: technically that would be totally okay (and what nightlies user are already using) + (21:11:03) Stefan Baur: no, let's get arctica NX in there, please. + (21:11:16) Stefan Baur: *3.6 + (21:11:18) Mihai Moldovan: the most critical component is x2goserver + (21:11:25) Mihai Moldovan: that's what we want to have in ubuntu lts + (21:11:33) Mihai Moldovan: arctica's nx-libs already are there + (21:11:39) Mihai Moldovan: at least in debian experimental + (21:12:25) Stefan Baur: yes, but if we include them as our stable nx-libs, they'll hopefully be considered stable enough for the Ubuntu LTS release + (21:12:31) ***Mike#1 could upload 3.5.99.11 to unstable with the next Debian upload. + (21:12:38) Mike#1: So they will be in Ubuntu then. + (21:12:56) Stefan Baur: As for Debian, their next release is still way in the future ... + (21:13:00) Mike#1: MeinNameIstRetro: noone will consider that on the Ubuntu side. + (21:13:07) Mihai Moldovan: I have no idea if just marking them stable in an upstream project is enough for the distro + (21:13:12) Mike#1: you need to get past me and that's it... + (21:13:18) Mike#1: as I maintain the stuff in Debian. + (21:13:32) Mihai Moldovan: well you and the ubuntu MOTU + (21:13:36) Mike#1: Ionic: it is enough. + (21:13:58) Mike#1: the MOTUs are highly understaffed these days. + (21:14:27) Mike#1: I can get Martin Wimpress to some stable-updates uploads, I guess, in Ubuntu. + (21:14:42) Mike#1: In case we discover severe flaws post-Ubuntu-release. + (21:15:13) Stefan Baur: okay, so ... Ionic - arctica 3.6.x nx-libs->x2go master && test. Tomorrow and Friday. sunweaver: MESA/OpenGL/GLX starting Friday. + (21:17:20) Mike#1: yep + (21:17:28) uli422: MeinNameIstRetro: so you are expexting nx-3.6 these days? + (21:17:32) Stefan Baur: sunweaver: If anything crops up that you can't get things done before your vacation, please remember to do a hand-over with uli422 and ionic so they know where to pick up + (21:17:43) Mike#1: yep + (21:18:21) Stefan Baur: uli422: would you veto that and suggest 3.5.99.something instead? If so, why? + (21:19:07) Mike#1: we will stay with 3.5.99. for some little more time. + (21:19:07) uli422: MeinNameIstRetro: yes, I'd veto. We have lot's of open issues that need to be fixed before release + (21:19:17) Mike#1: thanks, uli422. + (21:19:53) Stefan Baur: Ionic: in that case, I guess, your testing isn't as important as I thought. + (21:19:59) Mike#1: the version is just a name and it denotes, that we are good, but not ready, yet. + (21:19:59) Mihai Moldovan: ? + (21:20:07) Mihai Moldovan: 3.5.99.x *is* the 3.6.x branch + (21:20:10) Stefan Baur: uuuh + (21:20:16) Stefan Baur: now you're confusing me + (21:20:18) Mike#1: while we don't hold back stuff until 3.6.0, but we do releases, often and regularly. + (21:20:32) Mike#1: 3.5.99.x is the 3.6.x branch. + (21:20:37) Mihai Moldovan: our arctica 3.6.x branch in git is currently hosting 3.5.99.x + (21:20:39) Mike#1: but the release is not yet 3.6.0 + (21:20:42) Mihai Moldovan: yep + (21:20:53) Mike#1: as we are not done enough, yet. + (21:21:12) Stefan Baur: so Ionic, you actually meant you wanted to update x2go's nx-libs master branche to arcita's 3.5.99.x branch? + (21:21:21) Mihai Moldovan: yes + (21:21:25) Mike#1: 3.6.x branch!!!! + (21:21:25) Mihai Moldovan: which is called 3.6.x + (21:21:32) uli422: (but we should re-check the milestones for some of the issues) + (21:21:41) ***Mike#1 nods. + (21:21:52) ***Mike#1 can't do that before next year, though. + (21:21:56) Stefan Baur: I already know one thing I don't like about arctica, and that's their numbering scheme. *g* + (21:22:04) ***Mike#1 welcomes uli422 and Ionic to go over the most evident. + (21:22:19) Mike#1: also adapting the milestoning in Github's UI... + (21:22:21) Mihai Moldovan: well, we initially wanted to have 3.6.x out soon, but this backfired + (21:22:24) Mike#1: and the README.md. + (21:22:33) Mihai Moldovan: so we stayed on 3.5.99.x + (21:22:35) Mike#1: maybe March 2017 -> final 3.6.0.0 release? + (21:22:38) Stefan Baur: sooo ... the branch is called 3.6.x but the files in it are currently 3.5.99.x? + (21:22:42) Mihai Moldovan: yes + (21:22:59) Mike#1: MeinNameIstRetro: the branch name is given by our goal!!! + (21:23:18) uli422: MeinNameIstRetro: and the latest numbered release it 3.5.99.10 (from September, IIRC), but this is not the current development HEAD, + (21:23:36) Stefan Baur: well at least it wasn't given to you by some watery tart. *g* + (21:24:08) Mike#1: I'll do a 3.5.99.11 if there is not veto here. + (21:24:10) Mike#1: tomorrow. + (21:24:30) Mihai Moldovan: yeah, go ahead I guess and we'll see how it fares + (21:24:37) Mike#1: yep. + (21:24:39) Stefan Baur: okay, so, 3.5.99.11 tomorrow by sunweaver, then Ionic gets to upgrade and test + (21:24:46) Stefan Baur: and GLX on Friday + (21:25:28) Stefan Baur: let's hope that there aren't any major showstoppers and Ionic can get the Client updated next week as well. + (21:26:05) uli422: sunweaver: 3.5.99.11 is long due, I'd say + (21:26:47) Mike#1: yep + (21:26:56) Stefan Baur: do you think you could send me a short status update via e-mail each day, sunweaver, Ionic, and possibly uli422 as well? + (21:27:15) Mike#1: MeinNameIstRetro: for the client, it needs an i18n call for translations. + (21:27:23) Mike#1: or wait... no. + (21:27:27) Mike#1: ignore me. + (21:27:51) Mike#1: I want to get the Xinerama switch into PyHoca-GUI and that needs an i18n cycle. + (21:27:54) Stefan Baur: just one or two lines like "all proceeding as planned" vs. "ran into issue, need time/need to discuss with .../out of ideas, we're all going to die" + (21:28:00) Mike#1: but not as part of the server release. + (21:28:25) Mike#1: MeinNameIstRetro: why not IRC? + (21:28:47) Stefan Baur: sunweaver: /msg is okay, too + (21:28:52) Mike#1: ack. + (21:29:56) Stefan Baur: okay then, I guess we're done for today, unless anyone else wants to bring up something release-related that needs to be discussed today ... + (21:30:23) Stefan Baur: *dramatic pause so anyone can speak up* + (21:30:30) h1Org: MeinNameIstRetro: I lost 3 times the connection thanks to my isp... can anybody else paste the chatlog + (21:30:37) ***Mike#1 plans to have the Python3 X2Go Broker ready for Ubuntu 18.04, too. + (21:30:37) Stefan Baur: h1Org: will do + (21:30:38) h1Org: my buffer would be incomplete + (21:30:44) Mike#1: Will do that in Jan 2018. + (21:30:58) h1Org: thanks! + (21:31:01) ***Mike#1 stuffed those protocols into an envelope while we spoke. + (21:31:10) Stefan Baur: sunweaver: thank you + (21:31:35) Stefan Baur: Thank you for attending, everyone! + (21:31:42) Stefan Baur: especially sunweaver + (21:31:50) Mihai Moldovan: h1Org: please remember to some day upload the image + (21:31:54) h1Org: The channel is now open for questions again! + </file> -- This mail was generated by DokuWiki at https://wiki.x2go.org/