Last update I had was it was always in sleep mode, any advancements?

So, has the Mac mini found a home and is going to be a dedicated host for OSX builders now?

It's still in my flat and it can be used to be set up, at least. (my internet connection isn't all that great)

There's the suspend issue that needs to be solved before it's brought to its final destination, that's all.

I thought it was in a computing center somewhere?

What suspend issue is there?

not yet.
when I turn off the screen, the system goes to suspend eventually, even though I disabled all the suspend checkboxes on settings.

Did you check the setting

Prevent computer from sleeping automatically when the display is off

in

System Preferences/Energy Saver

?

Yes, of course. That's the one I was talking about.

Which OSX version are you running? El Capitan?

http://www.cnet.com/news/how-to-prevent-sleep-in-os-x/

Have you tried not letting the display go to sleep, which is a different setting from the screensaver? You can still turn off your display with the power button, the computer (probably) won't notice that.

The system has been moved, need to assess that we will keep control over the system if it gets rebooted.

You mean somebody should do a sudo shutdown -r now (or yank the power cord)? :)

Or power goes down. We need a plan there.

I'll respond to your mail regarding that shortly.

Hi, how is the status regarding the OSX build host?

@kaning are you offering yourself for help? If so, I'll be happy to explain.

I thought this is about the missing physical access to the host, no?

As you perhaps remember I have been quite active a year ago, but I am not yet up to speed w.r.t. ramping up my KDE/CI support really. I was just asking out of curiosity. :) Leaving it up to you whether you want to explain anyway. Since this is an open ticket you might also write a PM instead, if you don't want to spread "confidential" stuff publicly.

Well the problem is that we access the device through a VPN and this is set up upon login. At the moment if the systems gets rebooted, we'll be disconnected from the host until somebody gets physical access. This needs fixing because we won't always have an operator around.

I'm pleased to report that the system seems to be able to handle the VPN server going down (more than once) and reconnects itself without issue. This hasn't been the case in the past.

Which solution was installed to provide OpenVPN functionality?

The VPN server is a different machine than the Mini, I take it?

OS X has built-in VPN support AFAIK, but I've never used it. It also has built-in VNC support ("Desktop Sharing"), and that works fine. I've spent quite a bit of time doing test-builds on an OS X VM running on a Mini somewhere on the US West Coast, and apart the effective 300baud or so communication rate that worked well enough. I think Scarlett knows the host, as it ran (runs?) a CI system too.

The VPN server runs on the same machine as build.kde.org. It provides a VPN server which allows for all the CI physical hosts to communicate as needed.

In T2250#38594, @bcooksley wrote:

Which solution was installed to provide OpenVPN functionality?

I can't remember and I can't log in the system anymore. Do you think it's safe to have it moved?

I've had a look at the Tunnelblick configuration - and it appears to be setup to launch the VPN connection "When computer starts" (which sounds right to me).

Next time someone has physical access to it, could they reboot it so we can check whether it auto reconnects to the VPN? If that works fine, I think we can go ahead with the move.

Ok, we need to test anyway, one can easily assume the computer starts after login.
It will be easier for me to test if you give me access to the vpn.

I've emailed you the necessary OpenVPN certificates now.
The Mac is currently running at 10.150.80.34.

Hi folks,
any progress here?
Greets,
Marko

No progress on OSX?

No, maybe you could take over the task?

I am really sorry, but no, not at the moment. We're flat-out busy with Qt5/KF5 on MacPorts still...

Plus, there needs to be made a decision on how KDE is going to install its KF5 libs and apps on Apple's operating systems.

From our POV it's not feasible to have every app shipping all required KF5 libs in its associated bundle.

That's a completely separate issue!

But since you raise it: the only thing that is really important in that decision is how it's going to be implemented. We wouldn't want to impose one build approach over the other, but what we can reasonably ask for is that there be a dedicated option. Just like X11 builds are not made impossible on Mac, the ECM could declare an option (say, APPLE_BUILD_STANDALONE_BUNDLE) in order to set things up for autonomous app bundle builds. Individual applications projects could then be incited to check that option instead of the APPLE platform token in their CMake files (as Krita and Marble do currently).

Hi folks, especially @apol, @bcooksley and @scarlettclark,

instead of letting our Mac mini age w/o anything to do, I'd herewith like to suggest, that we could make good use of it for our (@rjvbb and my) quite lively ongoing KF5 activities on MacPorts.

ATM we haven't yet submitted a Pull Request to MacPorts' central ports git repo, but moving into that direction (since a year now) and are confident that we're getting closer to publication. If the mini could be a host for various virtualized OSX/macOS versions we would gain quite a bit of speed there as well as give other KDE devs the opportunity to chime in.

The final mechanism regarding how to deploy KF5 libs and apps from KDE into the world can still be defined while we're on the go. René has brought KF5 as a whole so much forward in the past year, that this kind of activity would be worth the power the mini would otherwise idling away on.

A more KDE'ish CI instance for OSX/macOS could still be developed and hosted in parallel.

What do you think about that?

I think what Marko is asking for is something like this, and is evidently relevant only if the host is sufficiently powerful to serve for additional tasks:

MacPorts have their own CI system that doubles as a binary package builder, the so-called build-bots. It would be nice if we could adapt that system so it builds just the "ports" we would like to introduce to provide an easy way to install KF5 software to anyone who's already using MacPorts. This would concern the KF5 ports that currently exists, the customised Qt5 port plus a handful of dependencies that either require adaptations or do not yet exist in MacPorts.

We both realise this is a delicate request because not everyone in the KDE community has a benevolent opinion of attempts to deploy KF5 in ways they perceive as "not native".

Sorry, @rjvbb, for not making perfectly clear what we intend to implement, even if it could only be a temporary solution, as many KDE devs might see MacPorts as unneeded overhead here. Yet for us it is the easiest way to fulfill all dependencies required to get Qt5/KF5 to run on Apple's OSes.

@apol, how powerful is that mini actually? I think it should be strong enough for quite a bit of load.

Apple, unfortunately, allows to run only 2 virtual instances of their OSes on a host, which is why we'd have to restrict ourselves one way or the other.

Have ye seen Craft coming: https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Mac ??

Don't know whether it's in anyway usable for CI on OSX/macOS.

Is that really relevant here? There is already a KDE CI system (plus something comparable on the MacPorts side, as far as *that* is relevant).

If Craft is intended primarily to individual users it could well require quite a bit of additional wrappers before it's suitable to be deployed as a CI system on a host to which you don't have physical access.

In T2250#66865, @kaning wrote:

Apple, unfortunately, allows to run only 2 virtual instances of their OSes on a host, which is why we'd have to restrict ourselves one way or the other.

I can make an effort and pretend I never saw that ;)

In T2250#67052, @rjvbb wrote:

Is that really relevant here?

Maybe not so much.

There is already a KDE CI system (plus something comparable on the MacPorts side, as far as *that* is relevant).

I know, but currently there is no OSX/macOS'ish flavour of the KDE/CI system maintained.

If Craft is intended primarily to individual users it could well require quite a bit of additional wrappers before it's suitable to be deployed as a CI system on a host to which you don't have physical access.

Yeah, of course, I only mentioned it, because I found it interesting that there is actually a cross-platform approach for KDE's package management available with it. This might be interesting, but surely won't integrate with Ben's and Scarlett's KDE/CI system.

@apol, so, what do you think about our suggestion to use KDE's mini as a MacPorts-based buildbot?

I know that Scarlett planned to use it according to what was discussed in Randa and I'd like to continue with the plan. If she's busy I'd say it's up to sysadmin to decide what to do meanwhile.

BTW, I'll pay it a visit tomorrow, to see how come it went down and what can we do to make sure it doesn't happen again. If you guys can give me a good idea about how to figure it out, I'll appreciate it.

That's a bit hard to say without being in front of the machine, but you have all the logs in /var/log like on Linux. There's a Console.app application for viewing them that lives in /Applications/Utilities, but you can also use a terminal emulator of course.

Note that if the "it" that went down is the CI server software you'll probably want to use the quick access to the various application crash logs under Console.app's File menu, supposing the reason is not listed in the software's logs themselves.

Is the machine hooked up to a UPS? If so and if the UPS can be connected to the host over USB the OS will most likely recognise it and give you additional configure options in the Energy System Preference.

Hi folks, I had a longer chat with Scarlett tonight and it turns out that she's going to deal with OSX/macOS builders soonish! :-)

So, we can bury our idea to "abuse" KDE's mini for our MacPorts endeavor. But hey, good to know that OSXBUILDERs are coming back online.

@apol, please report on what happened to the mini!

Why did it go down?

Do you personally have access to that hardware and can inspect it?

In T2250#68787, @kaning wrote:

@apol, please report on what happened to the mini!

Why did it go down?

Do you personally have access to that hardware and can inspect it?

It's currently in an office in my city, I can take the subway and get there in about 30'. It wasn't necessary nevertheless.

What happened was there was an Internet connection cut and we rely on the Internet to get to the device.

So, that means, the mini is after all fully functional and doesn't reboot or shut down anymore on its own?! That would be good news!

It has been functional and hasn't rebooted on its own that I know of.

The system appears to be fine from what I can tell:

7:28 up 4 days, 13:54, 1 user, load averages: 1.50 1.51 1.51

At this stage not much needs to be done here.

Do you know the reason for its recent reboot? Not that it's a bad idea to have a regular reboot cycle if not only so that fsck can do its job, but 4 days is short for OS X.

No idea. I assume it was an automatic update.

I was assuming that too. Are the Linux and other *n*x bots set to apply updates automatically too? (It's a feature I have always been uncomfortable with after recovering from BSOD experiences they caused but I can imagine it's a feature one might want to some extent on remote servers.)

I rebooted manually the device, I was in the area last week and wanted to make sure it would survive it, I triggered a reboot.

Our Linux systems are all manually managed in terms of updates.

I have zero experience setting up things like this and my main interest in building KDE is with a patched QStandardPaths so I'm not going to volunteer. Marko could be a better candidate but he seems to be MIA.

Either way, I think the QSP problem will become much less of an obstacle if the buildsystem were slightly modified (extended is a better term). AFAI see it, the main hurdle posed by QSP is the fact that the dynamic/runtime locations are not the same as those inferred (presumed) by the buildsystem. The latter are basically hardwired XDG-compliant locations while the former are not. The result is that libraries and applications expect to find the various files they need in locations where they're not installed.

If the buildsystem were to determine the actual install (= writable?) locations via a simple QSP wrapper utility (could be qtpaths!) this part of the QSP problem ought to become moot.

The nice thing is that this approach would make the difference between my (MaPorts/XDG-compliant) way of building and a more native approach largely if not completely disappear. And I think there are other platforms that would benefit from this approach, too.

R.