Update patch with changes:

• lang/spidermonkey115 update to 115.7.0
• lang/spidermonkey102 adjust versions for rust ports

Update lang/spidermonkey115 to 115.6.0

Sync after commits 672f0463c7 and b83d0f2

In D43247#987762, @pauamma_gundo.com wrote:

Almost there, just one remaining nit.

BTW, I prefer the name "Pau Amma". It's a single name in 2 words, not a first name+last name pair.

Apply last comment from Pau Amma.

Apply suggestions from Pau and Lorenzo.

Replace GNOME_VER variable by _gnome_ver

Update diff, applies suggestions proposed by @rene.

In D37679#901489, @rnagy wrote:

In D37679#886005, @duchateau.olivier_gmail.com wrote:

In D37679#885916, @arrowd wrote:

All right, we should probably get this in. Olivier, maybe you can create a fork repository containing all these patches, so we (desktop@) may participate in supporting this? I imagine this would be a non-trivial effort.

Why not. I think in the future, src/libaccountsservice/act-user-manager.c patch will be smaller, because @rnagy has already added these functions in development branch of consolekit2. Perhaps he knows when stable release will be published.

consolekit2 already has all the systemd shim functions which can be used by accountsservice. So I suggest you look into that. All the required information is in
the OpenBSD ports tree and the ConsoleKit2 git repo.

I've just submitted patch in order to have the latest release (23.13.9) , bug #270881.

In D37679#885916, @arrowd wrote:

All right, we should probably get this in. Olivier, maybe you can create a fork repository containing all these patches, so we (desktop@) may participate in supporting this? I imagine this would be a non-trivial effort.

Just to inform you, Budgie desktop is now in ports tree, with commit 1ccad74cc8c19d8a0fa0ab573604db5c3484d90d.

Update patches, nothing new compared to diff 117645 except a fix to avoid core of gnome-settings daemon when clock panel is clicked (this is disabled by default in budgie-control-center, because it requires org.freedesktop.timedate1 service).

In D37224#880605, @arrowd wrote:

@duchateau.olivier_gmail.com Can you please either address all comments in this diff or reply to them why you think they shouldn't be addressed?

Update x11/budgie-desktop to 10.7.1

Update diff:

Update patch:

In D37679#874625, @arrowd wrote:

I didn't look into these changes yet, but why not just revert upstream commit that removed CK2 support and then build on that?

Apply @arrowd's suggestions:

This is massive update, the desktop runs fine, a screenshot made with the new screenshot tool.

Update x11-themes/budgie-backgrounds to 1.0

Update patch without 'budgie' category in Mk/bsd.ports.mk

No, everything is up to date. Thanks!

In D37679#856724, @arrowd wrote:

I'd try upstreaming this first.

Pass maintainership for budgie.mk to the desktop@ team as suggested by @rene.

Update import diff, for update of deskutils/budgie-trash-applet to 2.1.2 (my patch has been merged by upstream).

In D37224#849152, @tcberner wrote:

Also, how about a taking back your commit bit, and pushing it in yourself?

Update patch (it contains):

• Fix build dependencies
• Fix indentation in x11-wm/budgie/files/xprofile.in
• Add URL for temporary documentation in x11-wm/budgie/files/pkg-message.in → some sections in handbook need to be re-organized

Fix build textproc/intltool package was missing in some ports.

Nothing new, except update x11/budgie-screensaver to 5.1.0

In D37286#847067, @fernape wrote:

Hi Olivier,

I'm confused. That Uses file is not in the FreeBSD repo. Is this some personal project you are working on?

Apply comments suggested by @pauamma

Update, switch to DISTVERSION

Apply Tobias's comments

Add desktop@ team, because devel/libgee should be maintained by them (as lang/vala).

I have just submitted 2 merge requests to upstream:

Below a screenshot of polkit agent in action with the Pantheon desktop

In D37137#843885, @vishwin wrote:

Personally I've been dogfooding, albeit an earlier version, with duktape, and so far some rather important (sub-)commands have crashed. Need to examine more, though with this version.

In D37137#843508, @tcberner wrote:

Moin moin

Have you been using it with ducktape for a while yourself?

mfg Toibas

In Makefile there are 2 URLs for MASTER_SITES, because tarball is not (yet) available for the first.

Update diff:

Why did you removed __pycache__/ directory?

In D21278#466627, @madpilot wrote:

In D21278#466552, @duchateau.olivier_gmail.com wrote:

I also noticed (on my laptop) compositor is not functional (it was functional with the previous stable release).

Previous stable release of what? Have you changed your X11 setup? Are you using an xorg.conf file or letting it autodetect everything? Is hardware acceleration working with other software?

[1] http://pix.toile-libre.org/upload/original/1566927773.png

In D21278#466622, @madpilot wrote:

In D21278#466552, @duchateau.olivier_gmail.com wrote:

I made some tests (on 12.0-STABLE):

Libepoxy and XPresent are required for support of vblank (Vertical blanking interval). Currently only GL backend (via libepoxy) is used. I get these warnings (.xession-errors)

(xfwm4:1092): xfwm4-WARNING **: 16:28:42.750: Unsupported GL renderer (llvmpipe (LLVM 8.0, 128 bits)).

(xfwm4:1092): xfwm4-WARNING **: 16:28:42.751: Screen is missing required GL renderer, GL support disabled.

This property (vblank) is by default on 'auto' xfconf-query -c xfwm4 -p /general/vblank_mode

Have you tested setting that to off?

According to compositor documentation, we can disable this property. If I use the kernel mode-setting port, borders are not well formed [1] (same result when vblank_mode is on 'auto'), but with Xorg drivers everything is fine (not checked warnings in .xsession-errors).

Then I tried with libXpresent (no update since 2015, but still uses by linux distributions), 2 backends are enabled, in my .xsession-errors messages related to xfwm4 disappeared. Render of borders (when I use the drm-kmod port) is always identical even if Xpresent is installed or not.

Presence of libXpresent avoids warnings for xfwm4. I can provide this port (and diff for x11-wm/xfce4-wm) if someone is interested.

If I understand the docs I read, the mere presence of libXpresent could not be enough. The window manager by default tries to autodetect what to use and could not even try using libXpresent by itself.

To be sure to test libXpresent you should run:

xfwm4 --vblank=xpresent --replace

I also noticed (on my laptop) compositor is not functional (it was functional with the previous stable release).

[1] http://pix.toile-libre.org/upload/original/1566927773.png

I have no idea what is causing this at this point.

Now first a personal note. My poudriere machine died just today. I was testing a libXpresent port. I could not fully test it but here is the XFCE 4.14 diff including this port and adding it as a dependency for xfwm:

https://people.freebsd.org/~madpilot/xfce414-libXpresent.diff

I made some tests (on 12.0-STABLE):

In D21278#466058, @madpilot wrote:

In D21278#466034, @duchateau.olivier_gmail.com wrote:

In D21278#465974, @ltning-freebsd_anduin.net wrote:

Has the new xfwm4 been tested with the modesetting X driver? When I do, all window decorations are black. That is - buttons and title shows up, also the corner pieces of windows, but the rest is just black. Switching to intel driver does not show this problem. Other window managers (windowmaker tested so far) do not seem to exhibit any such issues.

I haven't had a chance to test with the previous xfce version yet, sorry.

And yes, I prefer modesetting - it's much faster than Intel, especially with compositing turned on. :) Also, the intel driver cannot resume from suspend after more than ~30 minutes.

ThinkPad X1, 6th gen, last years model - so pretty recent.

I have same issue with the latest stable release 4.14 (and before, with 4.13.x development releases). I use X11 drivers and everything works fine.

I think problem comes from xfwm4, by default we use the GL backend (libepoxy), because XPresent was removed in our ports tree (merged into x11 library). Sometimes if fails (xfwm4 is rather complex). Some linux distribution still provide this library that's why there are 2 backends.

I don't have more recent hardware to test with.

Can you specify exactly which driver is creating problems?

In D21278#465974, @ltning-freebsd_anduin.net wrote:

Has the new xfwm4 been tested with the modesetting X driver? When I do, all window decorations are black. That is - buttons and title shows up, also the corner pieces of windows, but the rest is just black. Switching to intel driver does not show this problem. Other window managers (windowmaker tested so far) do not seem to exhibit any such issues.

I haven't had a chance to test with the previous xfce version yet, sorry.

And yes, I prefer modesetting - it's much faster than Intel, especially with compositing turned on. :) Also, the intel driver cannot resume from suspend after more than ~30 minutes.

ThinkPad X1, 6th gen, last years model - so pretty recent.

Documention of GObject Introspection is available here.

In D21278#465839, @ltning-freebsd_anduin.net wrote:

In D21278#465837, @duchateau.olivier_gmail.com wrote:

Your log is related to ibus, not xfce4-conf. Xfconf does not depend of dbus-glib anymore, only of gdbus through gio.

I'm very sorry - managed to pick the wrong address from all the open tabs. Here is the log in question:
https://pkg.osl3.modirum.com/data/120amd64-default-wmaker/2019-08-24_21h36m29s/logs/errors/xfce4-conf-4.14.1.log

I'm builng ibus because it's pulled in by gnome3(-lite), so that's unrelated to xfce. It did give me a nasty dependency loop though, but that's unrelated.

In D21278#465836, @ltning-freebsd_anduin.net wrote:

In D21278#465772, @madpilot wrote:

In D21278#465745, @ltning-freebsd_anduin.net wrote:

x11/xfce4-conf fails to build because it need dbus, but this has been removed from the Makefile.

The following needs adding back before it will build (using poudriere):
LIB_DEPENDS= libdbus-1.so:devel/dbus \

libdbus-glib-1.so:devel/dbus-glib

This isn't failing for me in poudriere. It builds fine(I've been testing all the xfce ports with poudriere with various FreeBSD versions and OPTIONS combinations for some time) and the resulting binaries are not linked with libdbus, which is the reason why I removed the dependency.

Also xfce components have been migrated away from dbus-glib to gdbus, which, if I'm correct, is included in glib, so the new versions don't need that library.

Could you provide a full build log for the failure so this can be investigated?

Can you access this?
https://pkg.osl3.modirum.com/data/120amd64-default-wmaker/2019-08-25_09h03m05s/logs/errors/ibus-1.5.20.log

I wonder, why debug option is set in sysutils/xfce4-settings (I did not see history).

I submitted (in madpilot's repository) a new pull request, against x11-wm/xfce4-panel. Because when we change icons theme, the applications menu is not automatically reloaded.

In D8416#444072, @madpilot wrote:

I merged in the suggestions from mat into the patch from olivierd.

It works fine for me. my testing has been making my machine perform "make checksum" on all affected ports after cleaning the distcache.

I ssee this simplification as useful and I'd like to get it in the tree soon, before XFCE 4.14 is released, so the two big commits don't overlap.

If any other changes are required or problems identified I'll try to addresss those.

In D18840#404669, @mat wrote:

The only thing that comes to mind that might not work and require a slave port is the dependency of some flavors to another, but I don't think it is the case, I don't remember if I ever tested that.

Make Gtk3 default flavor is bad idea, because its support is not good shape. There are lots of warnings due to deprecated methods. Moreover import of exo (from Xfce project) is very old too (taken from 0.10.x branch, upstream needs to use the 0.12.x branch, it is compatible with both version).