於 星期三，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
