User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
2017-09:day-2017-09-28 [2017/09/28 18:36]
mikedep333 Add "Mike#2 contributing on behalf of his day job"
2017-09:day-2017-09-28 [2017/09/28 20:53] (current)
ionic Add raw chat log.
Line 126: Line 126:
 </​code>​ </​code>​
 ==== Raw Chat Log ==== ==== Raw Chat Log ====
 <​file>​ <​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 or 
 +[20:39:18] < h1mg> MeinNameIstRetro:​ go for it! 
 +[20:39:43] <​@MeinNameIstRetro>​ mikedep333: I'd actually love to call it, 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 
 +[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 
 +[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 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 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 
 +[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 - and since then, other changes accumulated that I'd like to get out as (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 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 
 +[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://​​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://​​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 
 +[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 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 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://​​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 at some point (maybe after mikedep333 gets his GNOME work done?) and then 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>​ 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, I need to make sure that an upgrade from 4.0.1.x to works smoothly on all supported distros 
 +[21:28:23] <​@MeinNameIstRetro>​ Ionic: so it's important that we get out asap 
 +[21:28:57] <​@Ionic>​ 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://​​wiki/​Datei:​Seehund2cele4.jpg 
 +[21:31:40] <​@MeinNameIstRetro>​ mikedep333: Sounds good. Ionic, should we have a "​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 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://​​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://​​2016/​12/​welcome-to-gitea/​ 
 +[21:41:22] <​@MeinNameIstRetro>​ Ionic: I would still prefer if we have a master bug for or 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 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 so far 
 +[21:43:51] <​@Ionic>​ exactly? 
 +[21:44:16] <​@Ionic>​ arctica'​s nx-libs only works with, but works with arctica'​s nx-libs and our legacy nx-libs 
 +[21:44:17] <​@MeinNameIstRetro>​ Ionic: Oh, so 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, and thus it warrants being called 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>​ 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 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://​​gitweb?​p=x2goclient.git;​a=commit;​h=d164a700ba7e243f5038ef925208872f48f9c757 
 +[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 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>​ </​file>​
2017-09/day-2017-09-28.txt · Last modified: 2017/09/28 20:53 by ionic