[16:00] <h1Org> ok,... then we should start... [16:00] <h1Org> our 9th ΞX2Go Development Meeting: [16:00] <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! [16:00] <h1Org> This will be our TOC today: [16:00] --> rgregory (~email@example.com) hat diesen Kanal betreten. [16:01] <h1Org> https://wiki.x2go.org/doku.php/2018-01:day-2018-01-22 [16:01] <h1Org> The chatlog of this meeting will be available on the same page after the meeting [16:01] <uli42> Hi [16:01] <-- rgregory (~firstname.lastname@example.org) hat diesen Server verlassen (Client Quit). [16:01] <MeinNameIstRetro> hi uli42 [16:02] --> rgregory (~email@example.com) hat diesen Kanal betreten. [16:02] <rgregory> Hi All [16:02] <h1Org> MeinNameIstRetro: so we should start with the report on nx-libs [16:02] <MeinNameIstRetro> h1Org: yes, please. Let Ionic_ take the stage. [16:02] <uli42> MeinNameIstRetro: I will have to leave after ~30 minutes [16:03] <Ionic_> since I've merged arctica's version to the x2go repo's master branch in late december, I've had to fix up several issues [16:04] <MeinNameIstRetro> uli42 that's OK, just have a look at the log tomorrow [16:04] <-- kfleten (~Thunderbi@83-88-107-98-dynamic.dk.customer.tdc.net) hat diesen Server verlassen (Quit: kfleten). [16:05] <Ionic_> all RPM builds have been failing (fixed), nxagent and nxproxy were leaking like crazy (fixed), something within Xinerama was so broken that the initial window size of 800x600 had always been used in a weird way, but stretched up to the resolution provided via x2goclient (or any other client) - MATE tried to make the best out of a confusing situation and changed the DPI to a very high value (fixed) [16:06] <Ionic_> also I've been ripping x2gostartagent and x2goresume-session apart during the holidays, which lead to session startup and resume being broken, but both should be fixed now [16:07] <Ionic_> since I lack a second display, xinerama testing is difficult for me, but in theory it should work using the new randr-based xinerama feature in nxagent. I'm passing new values to x2gostartagent and x2goresume-session for that with newer x2goclient versions (only) [16:08] <Ionic_> there is a slight incompatibility in the sense that for older x2goclient versions, xinerama will ALWAYS be turned off, but that's really the best I can do on that front [16:08] <MeinNameIstRetro> Ionic_: You can delegate Xinerama testing to me. [16:09] <Ionic_> uli fixed X clients crashing within nxagent in a pretty reproducible manner and I've reworked the way we use RPATH/RUNPATH in the libraries and binaries, so that we're free of any LD_LIBRARY_PATH wrapping now [16:10] <uli42> I have also fixes many memory leaks [16:10] <uli42> fixed [16:10] <MeinNameIstRetro> Ionic_: So with Xinerama off in older clients, they will see the multiple displays as one large screen, but don't know about the individual screen borders, right? [16:10] <Ionic_> there are still a few open bug reports by uli, mainly valgrind reports and x11perf/the cairo test suite are crashing nxagent, but that's not a new bug [16:10] <Ionic_> yep [16:10] <uli42> Ionic_: the x11perf is fixed, via my PR from yesterday [16:11] <Ionic_> uli42: I haven't checked it yet... is it big? [16:11] <uli42> yep [16:11] <Ionic_> so probably not going in for the release then [16:11] <Ionic_> but good that we have that [16:12] <uli42> (in theory it is updating fb only but the way I worked here lead to 4 components being required, at least) [16:13] <Ionic_> in general I guess all grave problems have been fixed already and session management also seem to work okay again, though only tested on opensuse tumbleweed [16:14] <Ionic_> one last point I might need to look into is the xinerama handling when upgrading to the new/nightly version with sessions created by the old release version [16:15] <uli42> I am observing problems with RHEL7 (unrelated to x2go): there's slowness (keys often have a long delay) and clipboard is not working most of the time [16:15] <MeinNameIstRetro> Ionic_: Sounds like $SOMEONE (feel free to assign this to me) should test it on Stretch/Heuler? [16:16] <Ionic_> all in all I'm way more comfortable with a release now than a month ago [16:16] <Ionic_> MeinNameIstRetro: well, I have to test on whatever release -> heuler with running sessions [16:16] <Ionic_> probably going to do this in my opensuse tw VM [16:17] <Ionic_> just testing isn't enough because I think that there still is something I have to work around [16:18] <Ionic_> like, old options string do not have a xinerama component, while the resume script expects one now [16:18] <Ionic_> not a huge problem to do, though [16:18] <MeinNameIstRetro> Ionic_: Wait, I meant Buster/Heuler, as Ubuntu 18.04 LTS is pulling in Buster. [16:18] <Ionic_> oh, and sunweaver made a new nx-libs release with all our changes in and uploaded it to debian exp as well [16:20] <MeinNameIstRetro> Ionic_: Do we have any critical new, open bugs that were introduced by the new NX-libs, that are of the "the sky is falling and the world is going to end" type? Like certain session types not working, sessions terminating when they shouldn't, suspended sessions not resuming, etc.? [16:20] <Ionic_> guess that's it so far [16:20] <MeinNameIstRetro> Ionic_: Thank you for shouldering all that "grunt work" that was needed. [16:20] <Ionic_> MeinNameIstRetro: not that I'm aware of [16:20] <uli42> MeinNameIstRetro: we have occasional reports from windows users about flickering windows right after connect. That settles after some time. [16:21] <uli42> MeinNameIstRetro: I guess this is linked to xinerama. [16:21] <MeinNameIstRetro> Ionic_: So to me it sounds like a Buster/Heuler test setup would be good. [16:21] <Ionic_> MeinNameIstRetro: the migration path is sid -> ubuntu AFAIK btw [16:22] <-- micw (~firstname.lastname@example.org) hat diesen Kanal verlassen ("Leaving"). [16:22] <MattW> Yes, thank you Ionic_ for all the hard work - and thank you to the testers for putting these new builds through testing [16:22] <MeinNameIstRetro> Ionic_: Well, Ubuntu probably has a repo for "this-will-become-18.04", so I could set up an Ubuntu box with that and heuler ... [16:23] <MattW> FWIW: I did a brief test with AMD64 Debian 9 stretch and Heuler x2go and didnt see any issues [16:23] <Ionic_> MeinNameIstRetro: we do have ubuntu 18.04 heuler packages already [16:23] <MeinNameIstRetro> MattW: That's good to know, thanks! [16:24] <MeinNameIstRetro> Ionic_: one thing I was wondering - is Saimaa available to CentOS/RHEL/Fedora users, too? [16:24] <Ionic_> yes [16:24] <MattW> Ive got a slightly unusal LDAP and Kerb login setup via PAM that I need to try next [16:25] <Ionic_> for all currently supported distros and versions, but I will not add new ones (like whatever comes after buster) [16:25] <MeinNameIstRetro> Ionic_: Mike#1 said something about Desktop Sharing and X2GoClient still relying on Qt4. Any chance we can get them to Qt5 $SOON? [16:25] <Ionic_> (minus debian unstable, fedora rawhide and opensuse tumbleweed) [16:26] <MeinNameIstRetro> Ionic_: sounds good enough; I was merely worried about a few commercial CentOS/RHEL users that might not want to migrate to the new NX-Libs that soon. [16:26] <Ionic_> MeinNameIstRetro: one step after another, I haven't had time for that yet [16:27] <MeinNameIstRetro> Ionic_: IIRC, you said the coding wordk on it was done and you need to integrate it $SOMEWHERE - was it automatic builds, or packaging? [16:27] <MeinNameIstRetro> *work [16:27] <Ionic_> back in september I started playing with qt5 on windows, but never finished that [16:28] <MeinNameIstRetro> Ionic_: I am less worried about Windows, it's more the Linux version because some Distros are dropping support for Qt4, Mike#1 said (I think ...) [16:28] <Ionic_> for x2goclient, it's packaging; I haven't checked the other qt applications yet (x2godesktopsharing, x2goadmincenter, pinentry-x2go [which also badly needs an update]) [16:29] <MeinNameIstRetro> Ionic_: So my question is, if you are busy ironing out the last few kinks out of NX-Libs before the release, could the Qt4-Qt5 work be delegated to someone else; Alex maybe? [16:30] <Ionic_> I need a working qt5 build with openssl support for Windows (AFAIK we use that for HTTPS-based broker connections) [16:30] <Ionic_> last time I worked on this I haven't been able to let qt properly find openssl or something like that [16:31] <MeinNameIstRetro> Ionic_: But why do you need that *now*? Couldn't we stay on Qt4 for a little longer when it comes to the Windows releases, and focus on Qt5 support for the Linux releases first? [16:31] <gratuxri> +1 [16:32] <Alex|2> I built X2Go Client for Mac with Qt5 long time ago. I don't see any problem there. [16:32] <Ionic_> for consistency, but yeah, we'll also still have qt4 versions around [16:33] <MeinNameIstRetro> Ionic_: I would prefer seeing a Qt5-based X2GoClient and X2GoDesktopSharing in Ubuntu LTS. [16:33] <Alex|2> I think, the reason why we still building x2goclient with qt4 is that not all supported distros already have qt5, right? [16:34] <Ionic_> MeinNameIstRetro: maybe, but no promise on that [16:34] <MeinNameIstRetro> Ionic_: While I wouldn't mind if these programs, as well as pinentry-x2go, stay on Qt4 for older releases. pinentry-x2go in Ubuntu doesn't sound *that* important to me at the moment. [16:34] <Ionic_> Alex|2: mainly because of all the other stuff going on, really [16:35] <MeinNameIstRetro> Alex|2: Could you imagine volunteering here so it's not only Mihai doing all the work? [16:35] <uli42> Once x2go is in ubuntu 18.04 how are updates done? I am asking to get an insight about what's really necessary _now_ and what can be done later [16:36] <Ionic_> uli42: probably not at all or only security patches [16:36] <uli42> Ionic_: should we offer an easy way to switch to x2go repos? [16:36] <Ionic_> that is, after the release [16:36] <MeinNameIstRetro> uli42 The idea is that we should have X2GoServer and -Client in a working state with the LTS release. Bugfixes and security patches will go into the same Ubuntu release, as far as I know - while new features are not [16:37] <Ionic_> uli42: we already have the ppas? [16:37] <MeinNameIstRetro> s/are/will [16:38] <Ionic_> sadly repository pinning isn't easy on ubuntu or debian [16:38] <Alex|2> MeinNameIstRetro: not before mid of Feb, for sure. No chance for me before [16:38] <uli42> Ionic_: yes, I mean adding the ppas automatically or something like that [16:38] <Ionic_> uh no, that would be a bad idea [16:38] <Ionic_> we don't mess with people's systems [16:38] <MeinNameIstRetro> Alex|2: Okay, in that case, we'll check back mid-february and see how far Ionic has come [16:40] <MeinNameIstRetro> Mike#1 has asked that if we DO run into any critical bugs with NX-libs, we absolutely should add a bug on Arctica's bugtracker for it before starting to work on a fix. [16:41] <Ionic_> that's the official nx-libs bug tracker anyway [16:41] <uli42> ok, I have to leave, good bye [16:42] <h1Org> bye uli; thank you for joining! [16:42] <Ionic_> generally testing xinerama would be very appreciated [16:43] <Ionic_> cross-version regarding client and server versions [16:43] <MeinNameIstRetro> So ... to sum it up: [16:43] <MeinNameIstRetro> 1) We should be release-ready, but some additional testing of Server and Client can't hurt [16:43] <MeinNameIstRetro> 2) To ease testing, we should have a Wiki page explaining how to test, and how to select the timestamped repositories for that [16:43] <MeinNameIstRetro> 3) Around Mid-February, we should check how far Ionic has come with Qt4->Qt5, and if there are open tasks, we should check if we can delegate them [16:43] <Ionic_> (with the restriction knowing that xinerama will always be disabled for older client versions) [16:43] <MattW> Great work on x2go - there have been huge huge huge improvements in the last few years - this x2go system is used daily by dozens of my customers and they really like it - thank you!!!! -Matt [16:44] <MeinNameIstRetro> Ionic_: Please ping me over the next few days so that I can be your guinea pig for testing, and for cross-checking the instructions [16:45] <Ionic_> I guess I could fire off releases... sometime next week or so, give or take, if I fix the xinerama thingy [16:45] <Ionic_> one *big* problem there is, is the windows client, though... [16:45] <Ionic_> people are asking for the 184.108.40.206 release [16:46] <Ionic_> I figure mikedep333 is busy, so the only thing I can do is to tell them that it isn't ready yet [16:46] <MeinNameIstRetro> Ionic_: Remember, we don't want to release on a Friday, though. So maybe February 5th? [16:46] <Ionic_> MeinNameIstRetro: whenever it's done and tested™ [16:47] <MeinNameIstRetro> ... unless that happens on a Friday or Weekend. [16:47] <MattW> What is up with the windows client - is something broken? [16:47] <MattW> oh sorry, I see: "I need a working qt5 build with openssl support" [16:47] <Ionic_> the newest version is not available for windows yet, since mikedep333 has found Kerberos/GSSApi to be broken [16:47] <Ionic_> no, that's a development thing, Matt [16:48] <MattW> ok thanks [16:48] <Ionic_> the windows client is currently lagging behind one version compared to the linux releases [16:49] <MeinNameIstRetro> Ionic_: Does that mean we don't have Nightlies either? I mean, people that don't need Kerberos/GSSApi could use a 220.127.116.11 Nightly otherwise ... [16:49] <Ionic_> we do have nightlies, but no proper release yet [16:50] <MeinNameIstRetro> Okay. [16:50] <MeinNameIstRetro> Does anyone have further questions/comments? [16:50] <gratuxri> mellum migration for me ? [16:51] <MeinNameIstRetro> h1Org: That sounds like a topic for you. [16:53] * MeinNameIstRetro pokes h1Org with a 10 ft pole [16:53] <h1Org> MeinNameIstRetro: just a moment; telephone [16:55] <h1Org> MeinNameIstRetro: OK back... [16:56] <gratuxri> We have fresh installed mellum with all updates from proxmox (stretch) what should got to this machine? [16:56] <gratuxri> *go [16:56] <Ionic_> the wiki for now probably [16:57] <h1Org> I'm looiking at my calendar at the moment [16:57] <h1Org> gratuxri: the first step shoud be the apache proxy I assume [16:58] <h1Org> maybe we should create a wiki page for the migration [16:58] <gratuxri> good idea [16:58] <h1Org> so if the apache proxy is up, other container can follow [16:58] <MeinNameIstRetro> h1Org, gratuxri - Question: would it be possible to create an LXC container on mellum that does X2Go-TCE builds and offers them for download, along with the corresponding source packages? I'm slowly running out of disk space on my web server, so would appreciate having an official build server for them. Possibly with the images *sum'ed and gpg-signed with an official X2Go key, too. [16:59] <h1Org> maybe this would be a asynchronous aproach [17:00] <gratuxri> If it's OK, than I would migrate things manually and somewhere create ansible playbooks for it. [17:00] <h1Org> MeinNameIstRetro: IThe traffic is limited [17:00] <MeinNameIstRetro> [muffled cursing] [17:00] <gratuxri> I would prefer git repo for x2go specific infrastructur. What do you think about it? [17:01] <h1Org> gratuxri: with documentation on the wikisite... please install etckeeper [17:01] <Ionic_> we do have git repositories for the buildscripts and a maintenancescripts repo for git hooks mostly [17:01] <h1Org> MeinNameIstRetro: Do we offer build images at the moment? [17:01] <MeinNameIstRetro> h1Org: I offer unofficial ones ... [17:03] <h1Org> MeinNameIstRetro: This would mean responsibility... for a whole image and everything in it [17:03] <gratuxri> Maybe is https://fai-project.org/FAIme/ alternative for it [17:04] <h1Org> MeinNameIstRetro: netcup has unlimited traffic [17:04] <-- Hybrid (~email@example.com) hat diesen Server verlassen (Ping timeout: 268 seconds). [17:04] * h1Org is looking up the mellum specs [17:06] <h1Org> ok; I have to ask hetzner about, but I think the traffic is unlimited [17:07] <h1Org> MeinNameIstRetro: the archive (collection of outdated images) would be a bigger problem on mellum (space) [17:07] <gratuxri> I think it was 30TB, but I cannot login to hetzner any more with log *527* :( [17:08] <h1Org> gratuxri: I already have send a mail to hetzner... [17:08] <MeinNameIstRetro> h1Org: I wouldn't want to provide an archive. We provide image and source at the same time, so no need for a 3-year backlog. New image, new source files, done. [17:09] <h1Org> I think, we should discuss this question afer the migration of the containers is done [17:09] <gratuxri> +1 [17:09] <MattW> Thanks for opening up the meeting invite. Good to hear what is going on. Im signing off. Thanks everyone for moving this forward [17:09] <MeinNameIstRetro> h1Org: Well, this isn't a migration, this is an entirely new service, so it obviously doesn't have any dependencies wrt/ the migration [17:10] <MeinNameIstRetro> Bye MattW :) [17:10] <h1Org> MeinNameIstRetro: so migration first, new services afterwards... [17:10] <MeinNameIstRetro> h1Org: or in parallel ... [17:10] <h1Org> MeinNameIstRetro: we need to choose the lxcsized wisely! [17:11] <h1Org> MeinNameIstRetro: we need to choose the lxc sizes wisely! [17:11] <MeinNameIstRetro> h1Org: basically, if you set me up with a root account inside such an LXC container, I could take care of the installation. [17:11] <h1Org> I really would feel better to see everything is up und runnig and then talk about a new service which binds manpower [17:12] <MeinNameIstRetro> h1Org: it would only bind my manpower, and I can't be of help with the migration anyway. [17:13] <h1Org> MeinNameIstRetro / gratuxri: lets start with the wiki page. At the moment, there is NO container working at all [17:13] <h1Org> so we can set up the infrastruction hosts and then have a look on the whishlist and serve todos [17:14] <MeinNameIstRetro> This wasn't a scheduled topic, and we're almost 15 minutes past the hour the meeting was supposed to last. [17:14] <MeinNameIstRetro> So: Should we have another meeting $SOON, that isn't a dev- but a mig-meeting? [17:14] <h1Org> infrastructure [17:14] <h1Org> MeinNameIstRetro: I wonT be available on Thursday evenings... [17:15] <h1Org> MeinNameIstRetro: so maybe it is an idea to find out, when to meet in future... What about a wiki page with doodle questions? [17:15] <MeinNameIstRetro> h1Org: Pick any weekday except Tuesday. [17:15] <MeinNameIstRetro> (And even some Tuesdays will work for me) [17:16] <h1Org> MeinNameIstRetro: I would ask the audience! [17:16] --> Hybrid (~firstname.lastname@example.org) hat diesen Kanal betreten. [17:17] <MeinNameIstRetro> h1Org: Please set up a doodle, then. Or a dudle: https://dudle.inf.tu-dresden.de/?lang=de [17:17] <h1Org> MeinNameIstRetro: this can be done with the help of our wiki [17:17] <h1Org> as we did for the first Devmeetings [17:18] * h1Org is checking the calendar... [17:18] <MeinNameIstRetro> h1Org: Or that. "Choose the form of your destroyer", as Gozer said in Ghostbusters [17:19] <h1Org> february, 14th would be the next possible time for me; [17:19] <MeinNameIstRetro> That's valentine's day, h1Org - I doubt your significant other will be happy with that [17:20] <Ionic_> it's not a holiday so he'll have to work anyway... [17:20] <h1Org> MeinNameIstRetro: let's talk tomorrow (phone) about the possible dates - and thank you about the hint. We'll arrive back here so maybe it'll be a bit... [17:20] <MeinNameIstRetro> okay. [17:21] <gratuxri> Any suggestions for reverse proxy lxc name? rprox? [17:21] <h1Org> So - there will be a doodle (whereever) and a new page on the wiki in the next days about mellum and the organisation of the next developer meetings [17:22] <h1Org> gratuxri: go for it [17:23] <h1Org> MeinNameIstRetro: I'll paste the raw log of thos conversation to the todays wiki page; and I'll add tomorrow the links to ne pages [17:23] <MeinNameIstRetro> h1Org: Okay, then I won't ;) [17:23] <-- Hybrid (~email@example.com) hat diesen Server verlassen (Ping timeout: 240 seconds). [17:24] <h1Org> MeinNameIstRetro: shall we close the meeting now? [17:25] <MeinNameIstRetro> h1Org: yes, please.