Re: GitLab CI runners for non-Linux systems
於 星期三，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 onestart' is used to start the service only one
time. To start a service on boot, type 'sysrc _enable=YES' or manually
edit /etc/rc.conf. After that, you can use 'service start/stop/status'
instead of 'service 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
Re: GitLab CI runners for non-Linux systems
於 星期一，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. > - Solaris > - cygwin > > Regards, > Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] Projects moved and 'tips of the week'
Tobias Mueller 於 西元2018年01月23日 00:46 寫道: > Hi. > > On Tue, 2018-01-23 at 00:09 +0800, 藍挺瑋 wrote: >> Is it possible to get a private bug migrated to GitLab? I have a bug >> report which was marked as private by a libgtop developer, but there >> is >> no confidential information in the bug and I don't know why it became >> private. >> >> https://bugzilla.gnome.org/show_bug.cgi?id=744890 >> > I've unchecked the private box. > Thanks. So the remaining issue is that whether it is possible to do the migration for only one bug. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Release team now using gnome-build-meta repository, not JHBuild
mcatanz...@gnome.org 於 西元2018年01月22日 21:34 寫道: > > > On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote: >> Were you actually using JHBuild to run integrated system components >> (gnome-shell, gnome-session)? If so, how? I was not aware that that >> was even possible nowadays. >> >> When developing these components, > > Sorry, trying again > > When developing components like gnome-shell and gnome-session, I've > found myself working in a VM and installing directly into /usr/bin. It's > the only way I'm aware of that works. (You can try /usr/local, but then > you have to hack executable paths in several projects) > > Since it was already not possible to run these components with JHBuild, > this does not seem like a regression to me. Tristan mentioned the future > goal is to create a VM image, but one step at a time. It is not possible to run GDM, but it is possible to run gnome-shell, gnome-session, gnome-keyring in JHBuild without the help from a display manager. JHBuild gnome-session is the primary desktop environment on my FreeBSD desktop machine because packages provided by FreeBSD tend to be out of date. Features requiring GDM or polkit don't work in JHBuild, but I don't really care them because they are not essential for basic functionality of desktop. > > If you are aware of some way that you can successfully run gnome-shell > or gnome-session or gdm or similar components using JHBuild, I would > love to know! gnome-shell used to be possible using 'jhbuild build > gnome-shell' and 'jhbuild run gnome-shell -r', but the last time that > worked for me was many years ago. Even trying different combinations of > undocumented args like --nested and --wayland, I've yet to see it work > in recent times. Here are my steps to run GNOME session on X11 on FreeBSD. 1. Login from a text console. I usually use VT 2 to avoid seeing messages from the kernel and daemons. It is also possible to login from ssh, but it seems the a local session works better with ConsoleKit. 2. Run 'screen' so we can see messages sent to stdout and stderr without switching VT. We can re-attach the screen session from gnome-terminal. 3. Run 'screen Xorg'. It will be started on VT 9 on FreeBSD. 4. Run 'screen jhbuild run env DISPLAY=:0 gnome-session'. It will prompt for gnome-keyring password because we don't use a display manager. It is also possible to run JHBuild GNOME session on a remote server with TigerVNC. 'jhbuild run gnome-session' usually works for me. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products
於 週三，2016-10-05 於 09:33 +0200，Milan Crha 提到： > Hello, > this is a heads up that the evolution-data-server, evolution, > evolution-ews and evolution-mapi products will switch from Autotools > to > CMake for the 3.23.1 release. Each of them has created a wip/cmake > branch, which builds and even runs. I tried to keep things as close > as > they were with the Autotools, but I made some cleanup changes here > and > there (the evolution installs more shared libraries, evolution-ews > and > evolution-mapi have some installed libraries renamed and/or added; > header and pkg-config files for the evolution-ews and evolution-mapi > are not provided any more), thus some tweaks in packaging (apart of > calling CMake instead of autotools) will be required. > Can we have a common way to enable GTK-Doc installation in modules using CMake? In modules using Autotools, we have --enable-gtk-doc which is recognized by every module supporting generating documentation with GTK-Doc . However, we have two important modules using CMake, Evolution (including Evolution-Data-Server) and WebKitGTK+, but they require different options to enable GTK-Doc. Evolution only recognizes -DENABLE_GTK_DOC=ON and WebKitGTK+ only recognizes -DENABLE_GTKDOC=ON. I think it will be better to have single way to do it, so users don't have to remember to use different options when building different modules, and jhbuild users can write single cmakeargs instead of many module_cmakeargs in jhbuildrc when they want to install GTK-Doc documentation. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.14 Blocker Report (week 36)
Andre Klapper 於 2014/09/04 05:42 寫道: == mutter == crashes related to modal windows on 2nd screen https://bugzilla.gnome.org/show_bug.cgi?id=735333 Reporter provided more feedback; needs to get replied to. Gnome+Wayland can't resize windows https://bugzilla.gnome.org/show_bug.cgi?id=735717 Needs further investigation; cursor theme related? This mutter bug is also not resolved although it has been marked as resolved. https://bugzilla.gnome.org/show_bug.cgi?id=729490 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.14 Blocker Report (week 36)
Jasper St. Pierre 於 2014/09/04 10:18 寫道: It should be resolved. I landed some more commits to fix the issue. If you still can't compile without Wayland, please let me know. It's not easy for me to test compiling without Wayland right now, so I'd appreciate your help on this. It still doesn't work ... gmake[4]: Entering directory `/home/lantw44/gnome/source/mutter/src' CC x11/events.lo In file included from x11/events.c:39: ./wayland/meta-wayland-private.h:23:10: fatal error: 'wayland-server.h' file not found #include wayland-server.h ^ 1 error generated. gmake[4]: *** [x11/events.lo] Error 1 On Wed, Sep 3, 2014 at 7:02 PM, 藍挺瑋 lant...@gmail.com mailto:lant...@gmail.com wrote: Andre Klapper 於 2014/09/04 05:42 寫道: == mutter == crashes related to modal windows on 2nd screen https://bugzilla.gnome.org/show_bug.cgi?id=735333 Reporter provided more feedback; needs to get replied to. Gnome+Wayland can't resize windows https://bugzilla.gnome.org/show_bug.cgi?id=735717 Needs further investigation; cursor theme related? This mutter bug is also not resolved although it has been marked as resolved. https://bugzilla.gnome.org/show_bug.cgi?id=729490 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org mailto:desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.13.2
於 西元2014年05月29日 07:09, Javier Jardón 提到: The second release of the GNOME 3.14 development cycle is here. See [1] for the new features that have been proposed for this cycle. To compile GNOME 3.13.2, you can use the jhbuild [2] modulesets [3] (which use the exact tarball versions from the official release). Note that as part of Wayland development, 3.13.2 temporarily depends on systemd. This is needed because Wayland support in GNOME depends on systemd, but before 3.14 is released Wayland support will be made optional. When will Wayland and systemd dependencies become optional? This have caused mutter and gnome-shell fail to build on FreeBSD. [1] https://wiki.gnome.org/ThreePointThirteen/Features/ [2] http://library.gnome.org/devel/jhbuild/ [3] http://download.gnome.org/teams/releng/3.13.2/ The release notes that describe the changes between 3.13.1 and 3.13.2 are available. Go read them to learn what's new in this release: core - http://download.gnome.org/core/3.13/3.13.2/NEWS apps - http://download.gnome.org/apps/3.13/3.13.2/NEWS The GNOME 3.13.2 release itself is available here: core sources - http://download.gnome.org/core/3.13/3.13.2 apps sources - http://download.gnome.org/apps/3.13/3.13.2 WARNING! WARNING! WARNING! -- This release is a snapshot of early development code. Although it is buildable and usable, it is primarily intended for testing and hacking purposes. GNOME uses odd minor version numbers to indicate development status. For more information about 3.13, the full schedule, the official module lists and the proposed module lists, please see our colorful 3.13 page: http://www.gnome.org/start/unstable For a quick overview of the GNOME schedule, please see: http://live.gnome.org/Schedule Enjoy, Javier Jardón Cabezas GNOME Release Team ___ gnome-announce-list mailing list gnome-announce-l...@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-announce-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libgsystem build failure on FreeBSD
於西元2014年05月02日 (週五) 21時13分06秒,Colin Walters寫到: Hi, On Thu, May 1, 2014 at 11:51 PM, 藍挺瑋 lant...@gmail.com wrote: Build log: http://jhbuild.csie.org:9080/20140502/libgsystem.html#configure There is no libattr on FreeBSD. Can we make -DGSYSTEM_CONFIG_XATTRS optional through a configure option? I'd prefer if gnome-shell lost the dependency on it and copied the gsystem-log.[ch] files internally along with the systemd detection for now. Right now there's other API in libgsystem that's only going to work on Linux, and I'm not really interested in making it a portability mess right now. OK, I has reported this problem on gnome-shell bugzilla. https://bugzilla.gnome.org/show_bug.cgi?id=728449 However, gnome-shell currently does not build on non-Linux system because mutter hard-depends on systemd. The long term vision is that at least the logging functionality migrates to glib. There's some research that needs to be done for that, so it makes sense to prototype it out higher in the stack before migrating down. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
