Update patch with changes:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 3 2024
Jan 31 2024
Jan 28 2024
- lang/spidermonkey115 update to 115.7.0
- lang/spidermonkey102 adjust versions for rust ports
Jan 17 2024
Update lang/spidermonkey115 to 115.6.0
Jan 7 2024
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.
Jan 5 2024
Apply suggestions from Pau and Lorenzo.
Dec 30 2023
Dec 29 2023
Dec 28 2023
Replace GNOME_VER variable by _gnome_ver
Dec 26 2023
Sep 26 2023
Aug 27 2023
Jun 14 2023
Update diff, applies suggestions proposed by @rene.
Jun 11 2023
Apr 17 2023
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.
Apr 16 2023
I've just submitted patch in order to have the latest release (23.13.9) , bug #270881.
Mar 5 2023
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.
Feb 28 2023
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).
Feb 21 2023
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?
Feb 20 2023
Update x11/budgie-desktop to 10.7.1
Feb 12 2023
Update diff:
Feb 11 2023
Update patch:
Feb 10 2023
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:
Feb 5 2023
This is massive update, the desktop runs fine, a screenshot made with the new screenshot tool.
Jan 28 2023
Jan 7 2023
Update x11-themes/budgie-backgrounds to 1.0
Dec 29 2022
Dec 21 2022
Update patch without 'budgie' category in Mk/bsd.ports.mk
Dec 18 2022
No, everything is up to date. Thanks!
Dec 13 2022
In D37679#856724, @arrowd wrote:I'd try upstreaming this first.
Dec 12 2022
Dec 11 2022
Pass maintainership for budgie.mk to the desktop@ team as suggested by @rene.
Nov 28 2022
Update import diff, for update of deskutils/budgie-trash-applet to 2.1.2 (my patch has been merged by upstream).
Nov 14 2022
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
Nov 10 2022
Fix build textproc/intltool package was missing in some ports.
Nov 7 2022
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
Nov 6 2022
Nov 2 2022
Update, switch to DISTVERSION
Nov 1 2022
Apply Tobias's comments
Oct 31 2022
Add desktop@ team, because devel/libgee should be maintained by them (as lang/vala).
I have just submitted 2 merge requests to upstream:
Oct 28 2022
Below a screenshot of polkit agent in action with the Pantheon desktop
Oct 27 2022
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
Oct 26 2022
In Makefile there are 2 URLs for MASTER_SITES, because tarball is not (yet) available for the first.
Aug 30 2022
Update diff:
Jul 15 2022
Sep 25 2020
Why did you removed __pycache__/ directory?
Aug 28 2019
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
Aug 27 2019
I made some tests (on 12.0-STABLE):
Aug 26 2019
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.
Aug 25 2019
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.logI'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-glibThis 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
Aug 22 2019
I wonder, why debug option is set in sysutils/xfce4-settings (I did not see history).
Aug 21 2019
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.
Jun 8 2019
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.
Jan 24 2019
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.
Jan 19 2019
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).