於 星期三,2018-06-06 於 15:21 +0100,Philip Withnall 提到: > On Wed, 2018-05-30 at 00:59 +0800, 藍挺瑋 wrote: > > 於 星期一,2018-05-28 於 12:09 -0400,xclae...@gmail.com 提到: > > > Hi, > > > > > > We now have 6 arch tested for glib, all with Meson. > > > > > > - macosx-10.13-meson-x86_64 > > > * Native macosx 10.13 build > > > * Fails to build with --werror, if anyone wants to take a look. > > > * Some unit tests fails and are ignored, if anyone wants to take > > > a > > > look. > > > * Machine currently hosted at Collabora Montreal office, will > > > setup > > > another runner on another machine we have in a proper data center. > > > > It looks like this one was temporarily removed. > > > > > Missing, if someone wants to contribute: > > > - Some autotools runners? IMHO (I'm not maintainer) we should > > > recommend meson for 2.58 and drop autotools for 2.60. > > > - Some 32 bits archs? > > > - More macosx/android/windows/distros versions? > > > - *BSD > > > > After spending a few days on fixing GLib tests, I finally get all > > tests pass on > > FreeBSD: https://gitlab.gnome.org/lantw/glib/-/jobs/38840 > > > > The test ran in a jail with FreeBSD 11.1-RELEASE-p10 userland on > > FreeBSD 11.2- > > BETA3 amd64 kernel. > > > > In fact, 'collate' test fails but it is marked as 'SKIP' because of > > lacking > > en_US locale, 'testfilemonitor' is modified to allow some missing > > events because > > kqueue isn't as good as inotify on file monitoring. Even if not all > > tests work > > perfectly, running these tests already let me find a few bugs and fix > > problems > > in GKqueueFileMonitor. The code and commits in my GLib fork are just > > for quick > > testing and I will make them look better before submitting a merge > > request. > > > > However, the runner I use in my GLib fork runs in a VM whose host is > > very > > unreliable and not suitable for use as an official CI runner. This > > host crashes > > often and its uptime is usually less than 2 weeks. It also gives me > > random > > segfault and corrupted files sometimes. I can document steps required > > to run > > GitLab CI runner on FreeBSD, so people who are able to provide > > machines can > > setup a runner quickly. It is easy and can be done in about 5 > > commands. > > What are those 5 commands?
1. Install GitLab CI runner # pkg install gitlab-runner 2. Register GitLab CI runner # service gitlab_runner register 3. Install dependencies for GLib # pkg install dbus desktop-file-utils gettext libiconv meson pkgconf python3 shared-mime-info 4. Generate D-Bus /var/lib/dbus/machine-id file # service dbus onestart 5. Start GitLab CI runner # service gitlab_runner onestart For people who didn't have any experience on using FreeBSD, there are a few things which may be useful to know: 1. FreeBSD package manager 'pkg' isn't pre-installed on new installations, so it is expected to see messages such as 'package management tool is not yet installed' when you run 'pkg' the first time. Simply type 'y' at the prompt to install the real 'pkg'. 2. The default repository is 'quarterly' which may be slightly out of date. If it turns out to be a problem, you can switch it to the 'latest' repository. # mkdir -p /usr/local/etc/pkg/repos # echo 'FreeBSD: { url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest" }' > /usr/local/etc/pkg/repos/FreeBSD.conf 3. The above 'service <name> onestart' is used to start the service only one time. To start a service on boot, type 'sysrc <name>_enable=YES' or manually edit /etc/rc.conf. After that, you can use 'service <name> start/stop/status' instead of 'service <name> onestart/onestop/onestatus'. # service gitlab_runner status Cannot 'status' gitlab_runner. Set gitlab_runner_enable to YES in /etc/rc.conf or use 'onestatus' instead of 'status'. # service gitlab_runner rcvar gitlab_runner_enable="NO" # sysrc gitlab_runner_enable=YES # service gitlab_runner status gitlab_runner is running as pid 1135. > I think it should be possible to use a > separate Docker image for the FreeBSD CI, but run it on the same Docker > hosts as the Fedora image which we use for the Linux CI and > crossbuilds. I never tried to setup a cross build environment for compiling FreeBSD binaries on Linux, but maintaining an environment may be harder than installing a FreeBSD host if it has to be done by manually extracting things from FreeBSD images and packages. Even if we really have a cross build environment, how can you run tests on Linux? QEMU without KVM is likely to be slow. > > See https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#defin > e-image-and-services-from-gitlab-ci-yml. > > Philip _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list