I've been running this with no defects for quite some time.

Refresh patch, so it applies cleanly.

In D21278#470180, @sbruno wrote:

Is the raw patch updated so I can test it?

Is the raw patch updated so I can test it?

Update patch to apply to latest tree.

Really remove old patch integrated upstream in sysutils/xfce4-wavelan-plugin.

Update patch to remove the xfce4-vala port.

Update patch.

Update diff after recent tree changes (no functional change).

Exp run requested here:

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 know this may sound obvious, but just to make sure, have you tried changing window manager theme?

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'm posting this patch just in case someone could test it.

I will need a little time to fix or rebuild the failed machine before I can do much work on ports.

Apart from this we need some plan to get ahead on this. I'm personally out of ideas and unable to test it since it does not show on my hardware.

I'd like to understand if this is an xfce problem, an x11 problem or a driver problem. I'm asking someone with hardware showing the problem to run another compositing window manager, to check what happens.

I also need to decide if I should push to commit this update anyway, or wait for a solution. Keeping XFCE not updated indefinitely does not look like a good thing to me. Also because now I have problems updating the old ports. I'd need to build a brand new testing environment. I was hoping to update everything at once with this big update.

Does someone has a suggestion on how to address or manage this issue? Is it really a showstopper?

In D21278#466552, @duchateau.olivier_gmail.com 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

I made some tests (on 12.0-STABLE):

In D21278#466240, @madpilot wrote:

In D21278#466236, @madpilot wrote:

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

Another thing to try iis disabling the compositing functionality in xfwm. I found this:

https://www.reddit.com/r/GlobalOffensiveLinux/comments/6b3cs5/is_it_possible_to_disable_compositing_in_xfce_for/

Could you try this and see if the problem goes away?

I have disabled compositing, it doesn't make a difference at all. Used the "Window manager tweaks" panel to do so.

This is an hard issue to fix. I really don't have a solution right away. And I can't if it's a specific xfwm problem, a driver problem, a compositing problem. I'd like someone experiencing this to try another compositing window manager, so we can understand if it's specific to xfwm or a general compositing problem. I'm at odds with this. Keeping xfce at 4.12 isn't acceptable though.

In general newer hardware (especially laptop hardware) s more problematic.

Could you post a screenshot of the problem? So I get a better idea what we're against?

I'm not sure if disabling compositing from the config (or command line) actually disables the usage of hardware acceleration and is able to mitigate the problem, looks like it's not enough. It was worth a try.

Also, I'm on head, which has newer in kernel drivers. Which FreeBSD version are you using?

I'm using 12-STABLE.

This could also be a relevant difference. The drivers on 13 are newer and could not have this problem.

There are too many factors, and we need to exclude at least some. If I was experiencing the bug I'd try myself, but I cant reproduce it.

I found this further guidance. trying the "off" option described here could be worth it:

https://forum.xfce.org/viewtopic.php?id=13233

In D21278#466236, @madpilot wrote:

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

Another thing to try iis disabling the compositing functionality in xfwm. I found this:

https://www.reddit.com/r/GlobalOffensiveLinux/comments/6b3cs5/is_it_possible_to_disable_compositing_in_xfce_for/

Could you try this and see if the problem goes away?

I have disabled compositing, it doesn't make a difference at all. Used the "Window manager tweaks" panel to do so.

This is an hard issue to fix. I really don't have a solution right away. And I can't if it's a specific xfwm problem, a driver problem, a compositing problem. I'd like someone experiencing this to try another compositing window manager, so we can understand if it's specific to xfwm or a general compositing problem. I'm at odds with this. Keeping xfce at 4.12 isn't acceptable though.

In general newer hardware (especially laptop hardware) s more problematic.

Could you post a screenshot of the problem? So I get a better idea what we're against?

I'm not sure if disabling compositing from the config (or command line) actually disables the usage of hardware acceleration and is able to mitigate the problem, looks like it's not enough. It was worth a try.

Also, I'm on head, which has newer in kernel drivers. Which FreeBSD version are you using?

I'm using 12-STABLE.

This could also be a relevant difference. The drivers on 13 are newer and could not have this problem.

There are too many factors, and we need to exclude at least some. If I was experiencing the bug I'd try myself, but I cant reproduce it.

• Add USES=xorg
• Import upstream patch to fix regression in worspace switcher panel plugin [1]
• Updated xfce4-screenshooter-plugin
• Changed defaults to an "unthemed" xfce, more similar to what old ports did

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

Another thing to try iis disabling the compositing functionality in xfwm. I found this:

https://www.reddit.com/r/GlobalOffensiveLinux/comments/6b3cs5/is_it_possible_to_disable_compositing_in_xfce_for/

Could you try this and see if the problem goes away?

I have disabled compositing, it doesn't make a difference at all. Used the "Window manager tweaks" panel to do so.

In D21278#466181, @madpilot wrote:

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

Can you specify exactly which driver is creating problems?

It is AMD Radeon R2.

vgapci0@pci0:0:1:0:     class=0x030000 card=0x108a1025 chip=0x98531002 rev=0x40 hdr=0x00
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Mullins [Radeon R2 Graphics]'
    class      = display
    subclass   = VGA

Xorg loads the Vesa driver (amdgpu is also installed, but not loaded).

If I follow this documentation, I have same problem as Eirik.

So it depends on the hardware.

I'm almost sure it has to do with the compositing functionality. shadows, transparencies and the like. I'm sorry I have no idea how to "fix" this.

Could you try using some other compositing window manager and check if the problem appears with them too? (compiz for example)

Another thing to try iis disabling the compositing functionality in xfwm. I found this:

https://www.reddit.com/r/GlobalOffensiveLinux/comments/6b3cs5/is_it_possible_to_disable_compositing_in_xfce_for/

Could you try this and see if the problem goes away?

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

Can you specify exactly which driver is creating problems?

It is AMD Radeon R2.

vgapci0@pci0:0:1:0:     class=0x030000 card=0x108a1025 chip=0x98531002 rev=0x40 hdr=0x00
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Mullins [Radeon R2 Graphics]'
    class      = display
    subclass   = VGA

Xorg loads the Vesa driver (amdgpu is also installed, but not loaded).

If I follow this documentation, I have same problem as Eirik.

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#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.

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.

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.

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'm planning a few more changes.

Fix build of xfce4-conf when PERL option is enabled.

I discovered now a regression in the workspace switcher. It looks like an upstream bug.

Documention of GObject Introspection is available here.

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

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#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 building 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.

Your problem comes from PERL option. You should disable this option. Perl bindings has not been tested by upstream since the 4.13.0 release (port to gdbus).

In the past there was soname change, but upstream decided to keep this field untouched for backwards-compatibility. Personally I wish this option to be removed.

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#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.

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

[...]

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

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

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?

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

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

Remove debugging option from default CONFIGURE_ARGS in xfce4-settings.

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

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

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

Fix xfce4-settings plist.

Update patch. Changes:

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

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 D21278#464648, @sbruno wrote:

Huh ... Settings->Keyboard->Typing Settings->Repeat Speed was reset to "1". I've bumped it locally back to 50 so I don't throw my keyboard across the room. :-)

In D21278#464643, @sbruno wrote:

Ugh, no. It does repeat but its on a 3 second or so output delay.

Huh ... Settings->Keyboard->Typing Settings->Repeat Speed was reset to "1". I've bumped it locally back to 50 so I don't throw my keyboard across the room. :-)

Ugh, no. It does repeat but its on a 3 second or so output delay.

Does anyone else notice that holding a key in xfce-terminal and waiting for a repeat of characters doesn't seem to happen with this update?

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 D21278#464161, @sbruno wrote:

I've applied and compiled all this and it seems to do the right thing. A few icons on my tool bars lost their icons, but that was easily fixed.

I'm not the biggest fan of the color scheme changes in the default, but that's my "opinion". :-)

This is what I have installed currently for the record.

sbruno@alice:~ % pkg info |grep xfce
libxfce4menu-4.14.1            Widgets library for the Xfce desktop environment
libxfce4util-4.14.0            Extension library for the Xfce desktop environment
xfce-4.14                      meta-port for the Xfce Desktop Environment
xfce-icons-elementary-0.13.1   Elementary icons, extended and maintained for Xfce
xfce4-appfinder-4.14.0         Application launcher and finder
xfce4-conf-4.14.1              D-Bus-based configuration storage system
xfce4-desktop-4.14.1           Xfce's desktop manager
xfce4-mixer-4.11.0_5           Volume control for the Xfce desktop
xfce4-notifyd-0.4.4_1          Visually-appealing notification daemon for Xfce
xfce4-panel-4.14.0             Xfce's panel
xfce4-screenshooter-plugin-1.9.5_1 Application and panel plugin to take screenshots
xfce4-session-4.14.0           Xfce's session manager
xfce4-settings-4.14.0          Xfce 4 settings application
xfce4-terminal-0.8.8_1         Terminal emulator for the X windowing system
xfce4-tumbler-0.2.7            Thumbnail service for Xfce desktop
xfce4-wm-4.14.0                Xfce's window manager

I've applied and compiled all this and it seems to do the right thing. A few icons on my tool bars lost their icons, but that was easily fixed.

Remove some files directories containing old patches.

Allrighty, thank you. This applied and I'm rebuilding now. I'll report back on behavior.

Add forgotten gtk2 argument to USES=xfce in xfce4-bsdcpufreq-plugin.

In D21278#463018, @madpilot wrote:

In D21278#463004, @kevans wrote:

To be clear to non-sbruno people that may glance over this... arc diff (and default svn diff without --show-copies-as-adds) is generating a diff against the version that this was repocopied from, since it's being revived from history. patch(1) cannot do the right thing with this, as it doesn't have the svn history available for context. svn patch can probably do the right thing, but it's not clear to me that the markings needed for it to get it right are preserved when it hits Phab.

Exactly what I did to resuscitate the port without loosing history as required.

In D21278#463004, @kevans wrote:

In D21278#463000, @sbruno wrote:

In D21278#462738, @madpilot wrote:

In D21278#462737, @sbruno wrote:

Hrm ... phabricator and patch really don't like to apply this to my local tree. It chokes on adding new stuff and I can't seem to work around it. Any suggestions?

Strange, I generated it using arc from command line.

You can grab a ports overlay here:

https://github.com/madpilot78/FreeBSD-xfce4.13

it's the same as the patch.

I also uploaded the result of svn diff here:

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

Can you regenerate the svn diff with "--show-copies-as-adds"? The xfce4-places-plugin directory is very confused in the diff. It shows that it was copied from somewhere, but its not clear where it was copied from.

In D21278#463000, @sbruno wrote:

In D21278#462738, @madpilot wrote:

In D21278#462737, @sbruno wrote:

Hrm ... phabricator and patch really don't like to apply this to my local tree. It chokes on adding new stuff and I can't seem to work around it. Any suggestions?

Strange, I generated it using arc from command line.

You can grab a ports overlay here:

https://github.com/madpilot78/FreeBSD-xfce4.13

it's the same as the patch.

I also uploaded the result of svn diff here:

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

Can you regenerate the svn diff with "--show-copies-as-adds"? The xfce4-places-plugin directory is very confused in the diff. It shows that it was copied from somewhere, but its not clear where it was copied from.

In D21278#462738, @madpilot wrote:

In D21278#462737, @sbruno wrote:

Hrm ... phabricator and patch really don't like to apply this to my local tree. It chokes on adding new stuff and I can't seem to work around it. Any suggestions?

Strange, I generated it using arc from command line.

You can grab a ports overlay here:

https://github.com/madpilot78/FreeBSD-xfce4.13

it's the same as the patch.

I also uploaded the result of svn diff here:

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

In D21278#462738, @madpilot wrote:

In D21278#462737, @sbruno wrote:

Hrm ... phabricator and patch really don't like to apply this to my local tree. It chokes on adding new stuff and I can't seem to work around it. Any suggestions?

Strange, I generated it using arc from command line.

You can grab a ports overlay here:

https://github.com/madpilot78/FreeBSD-xfce4.13

it's the same as the patch.

I also uploaded the result of svn diff here:

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

In D21278#462737, @sbruno wrote:

Hrm ... phabricator and patch really don't like to apply this to my local tree. It chokes on adding new stuff and I can't seem to work around it. Any suggestions?

Hrm ... phabricator and patch really don't like to apply this to my local tree. It chokes on adding new stuff and I can't seem to work around it. Any suggestions?

Fine by me. +1 to what @mat said.

Note that Mk/Uses/xfce.mk is maintained by xfce@FreeBSD.org, not portmgr.

Testing with non default options showed that disabling the GTK2 option causes failures in other XFCE ports, so I made it a non option.

Works fine for me.

In D7199#173297, @woodsb02 wrote:

ehaupt: What do you think about marking deskutils/xfce4-notification-daemon as deprecated and then removing it from ports 1 month later? My understanding is that it is no longer maintained and is fully replaced by deskutils/xfce4-notifyd?

It is also worth noting that deskutils/xfce4-notification-daemon is already marked deprecated due to USE_XFCE=libgui:
https://svnweb.freebsd.org/ports/head/Mk/Uses/xfce.mk?revision=411970&view=markup#l101

Please also include test results in the test plan section, not just a description/list of what will/has been run

@woodsb02 Please use the SUMMARY field as the proposed commit log (i've updated it this time to provide example).

ehaupt: What do you think about marking deskutils/xfce4-notification-daemon as deprecated and then removing it from ports 1 month later? My understanding is that it is no longer maintained and is fully replaced by deskutils/xfce4-notifyd?

In D7199#173225, @olivierd wrote:

Why to accept this changes, without informed the maintainer (ehaupt)?

Why to accept this changes, without informed the maintainer (ehaupt)?

In D6981#160113, @olivierd wrote:

UNOFFICIAL term is not good word (imho), because it contains unmaintained applications, so we must inform users these ports (in a future) can be removed.

UNOFFICIAL term is not good word (imho), because it contains unmaintained applications, so we must inform users these ports (in a future) can be removed.

You may fire when ready.

olivierd - what are your thoughts on deprecating deskutils/xfce4-notification-daemon?

Update diff inline with comments from olivierd

Hi olivierd, thanks for you review. I have updated my patch and responded to your comments below.