Re: XFCE terminal + utempter
On 20/04/21 12:48, Daniel O'Connor wrote: Great :) Committed in hash 4e648b520916 -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE terminal + utempter
On 20/04/21 09:57, Daniel O'Connor wrote: On 20 Apr 2021, at 17:14, Guido Falsi wrote: On 20/04/21 04:56, Daniel O'Connor via freebsd-xfce wrote: Just looking at the xfce4-terminal configure file I'm not sure how you got it working though, since the configure file does not look for the correct library on FreeBSD. ( at least according to utempter_add_record(3) ) Yes, I was a bit confused about that too, however it works in practise. I found out we do have a link from libutempter to libulog, so this explains how it can compile and run. Please notice I am not an expert on utmp/wtmp/utmpx and such so I'm not sure of the implications right away, I need research to get a clear understanding. Anyway I can do some testing, but I'd rather avoid any default behaviour changes, so I'd evaluate adding this as an option turned off by default. Even if it is compiled in it is still off until the user enables in the preferences window. I noticed. I'm proceeding with some testing, I'm now convinced that turning this on is the correct thing to do. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE terminal + utempter
On 20/04/21 09:44, Guido Falsi via freebsd-xfce wrote: On 20/04/21 04:56, Daniel O'Connor via freebsd-xfce wrote: Hi, I had to recompile xfce4-terminal for a client because they weren't getting UPS notifications (via wall) - I had to add '--with-utempter' to 'CONFIGURE_ARGS'. [...] This system is a bit old but it seems the current port does not have that flag either (although I am not sure if perhaps it would be auto detected in the latest ports). If it isn't picked up, can the flag be added to the port? With that done it because a user configuration item (defaults to off though it seems). [...] Please notice I am not an expert on utmp/wtmp/utmpx and such so I'm not sure of the implications right away, I need research to get a clear understanding. For some context: https://bugzilla.xfce.org/show_bug.cgi?id=13710 After reading this I'm less worried about enabling the feature. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE terminal + utempter
On 20/04/21 04:56, Daniel O'Connor via freebsd-xfce wrote: Hi, I had to recompile xfce4-terminal for a client because they weren't getting UPS notifications (via wall) - I had to add '--with-utempter' to 'CONFIGURE_ARGS'. While I understand the need this looks like an ancient way of doing such things. Also if I have ten terminal windows open I'd get ten notifications? This system is a bit old but it seems the current port does not have that flag either (although I am not sure if perhaps it would be auto detected in the latest ports). If it isn't picked up, can the flag be added to the port? With that done it because a user configuration item (defaults to off though it seems). It is not automatically detected. Upstream has the flag off by default and the port is simply leaving it there. Just looking at the xfce4-terminal configure file I'm not sure how you got it working though, since the configure file does not look for the correct library on FreeBSD. ( at least according to utempter_add_record(3) ) Please notice I am not an expert on utmp/wtmp/utmpx and such so I'm not sure of the implications right away, I need research to get a clear understanding. Anyway I can do some testing, but I'd rather avoid any default behaviour changes, so I'd evaluate adding this as an option turned off by default. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
libgtop and network load (xfce4-systemlooad-plugin r569103 related)
Hi, The xfce4-systemlooad-plugin panel plugin added libgtop support to get network load information. I tried enabling it by default adding an option to the port. It compiles fine, but then fails to run. a backtrace from the core dump I got shows it failing here: #5 0x000802aad581 in glibtop_get_netload_l (server=0x802ab9bb0 <_glibtop_global_server>, buf=0x7fffd4c0, interface=0x803e00cf8 "re0") at lib.c:876 But at that code line there is an unconditional error. What I gather is on FreeBSD it expects some server process, running setgit kmem to actually read the data and report it back. This is not happening though and it falls back to unconditional error. I have noticed a libgtop_server2 binary but manually launching it is not enough. Am I missing something? Is some configuration required? Is this documented somewhere? At present I committed the port with libgtop support disabled unconditionally, since it only makes the plugin crash on start. I'd like to understand things better before enabling libgtop support in this plugin in the port tree. Thanks in advance! -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: [CFT] Upstream patch fixing keys grabbing in xfce (bug 244290)
On 20/02/21 16:31, Guido Falsi via freebsd-xfce wrote: On 20/02/21 16:13, Guido Falsi via freebsd-xfce wrote: Hi! I'm sending this message to ask for people experiencing the issue described in bug 244290 [1] and willing to test the patch I posted in that bug report. I've also created an already patched port as an archive here [2] Unluckily I'm not experiencing the issue, so I'm unable to confirm to the upstream the patch works. What is needed is someone having the issue confirming this patch fixes it. Or confirming that the patch makes no difference. I'd really like to solve that issue, but upstream, (reasonably) asks for some report about the patch actually working before committing it to their tree. I just got information from upsstream that a revised and improved version of the patch is going to be published in a few days, so, no hurry to test this version right now. I'll followup once I get the new patch. Upstream updated it's patch, so testing is strongly needed now. The new patch (or tarball) are available in the bug report and link posted there: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244290#c76 Thanks in advance! -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: [CFT] Upstream patch fixing keys grabbing in xfce (bug 244290)
On 20/02/21 16:13, Guido Falsi via freebsd-xfce wrote: Hi! I'm sending this message to ask for people experiencing the issue described in bug 244290 [1] and willing to test the patch I posted in that bug report. I've also created an already patched port as an archive here [2] Unluckily I'm not experiencing the issue, so I'm unable to confirm to the upstream the patch works. What is needed is someone having the issue confirming this patch fixes it. Or confirming that the patch makes no difference. I'd really like to solve that issue, but upstream, (reasonably) asks for some report about the patch actually working before committing it to their tree. I just got information from upsstream that a revised and improved version of the patch is going to be published in a few days, so, no hurry to test this version right now. I'll followup once I get the new patch. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
[CFT] Upstream patch fixing keys grabbing in xfce (bug 244290)
Hi! I'm sending this message to ask for people experiencing the issue described in bug 244290 [1] and willing to test the patch I posted in that bug report. I've also created an already patched port as an archive here [2] Unluckily I'm not experiencing the issue, so I'm unable to confirm to the upstream the patch works. What is needed is someone having the issue confirming this patch fixes it. Or confirming that the patch makes no difference. I'd really like to solve that issue, but upstream, (reasonably) asks for some report about the patch actually working before committing it to their tree. Thanks in advance! [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244290 [2] https://people.freebsd.org/~madpilot/libxfce4menu.txz -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: xfce4-mixer -> gtk-mixer
On 01/02/21 12:35, Rozhuk Ivan wrote: On Mon, 1 Feb 2021 12:04:14 +0100 Guido Falsi wrote: At the same time upstream is working on reviving the project, so, if you have time, you can also contribute there. https://gitlab.xfce.org/apps/xfce4-mixer I know, but: 1. Before I found that xfce4-mixer under construction - I already done most of work. 2. gtk-mixer have different design, it can not be "upstreamed" back :) 3. There is a few of cool features that I want to implement here. I understand, Just wanted to make sure you knew XFCE guys are actually doing something about this. I'm going to test it, there should not be any problem adding it to the tree. Thanks! Committed it earlier tot he tree. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: xfce4-mixer -> gtk-mixer
On 01/02/21 10:23, Rozhuk Ivan wrote: Hi! I am was very dissapointed that xfce4-mixer is deprecated, so I am rewrite it to new app - GTK-Mixer. Unluckily the project was abandoned upstream and never ported to GTK3, so it fails to compile at present. At the same time upstream is working on reviving the project, so, if you have time, you can also contribute there. https://gitlab.xfce.org/apps/xfce4-mixer GUI mostly same, but many features now work: - show all sound cards - handle sound card connect/disconnect - handle default device change - allow switch default sound device - tray icon (like audio/volumeicon / audio/gvolwheel) It does not require nothing but gtk3. If some one want - feel free to write ALSA/sndio/... sound backend plugins. I'm going to test it, there should not be any problem adding it to the tree. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: polkit not running after update
On 27/01/21 08:13, Gerrit Kuehn wrote: On Tue, 26 Jan 2021 17:29:14 +0100 Guido Falsi wrote: --- [1/1] Extracting polkit-0.118: 100% You may need to manually remove /usr/local/etc/dbus-1/system.d/org.freedesktop.PolicyKit1.conf if it is no longer needed. --- And indeed, the file is gone again. So the state of the system above was as designed (whithout the file), but it didn't work for me. So something's fishy here. Either the system should work without the file, or the message is wrong. That message is a standard message from pkg about configuration files. Any file marked as a configuration file in the port will trigger that message when the port is removed (upgrading entails removing the port and reinstalling). So printing this under "extracting" is misleading, and the message is rather caused before when deinstalling the old package version? You can file a bug report/change request in pkg repo on github if you think this should be changed. pkg should leave the file there and only modify the .sample one on upgrade. It simply informs you you can remove configuration files for software you no longer use. Don't know why you end up missing the file. It should definitely be there and is needed as long as you use polkit. It is reproducible for me. This file isn't installed when installing the port. Same ass above. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: polkit not running after update
On 26/01/21 16:21, Gerrit Kühn wrote: Am Mon, 18 Jan 2021 15:33:44 +0100 schrieb Guido Falsi : Especially the file /usr/local/etc/dbus-1/system.d/org.freedesktop.PolicyKit1.conf, is it unmodified from what the port installs? There should be a .sample file you can try a diff from. The file isn't there at all, it is simply missing (for whatever reason). Even reinstalling polkit before obiously didn't produce it. Anyway, now I just copied over the .sample file manually, restarted... and everything is working again as expected. Sometimes wild guesses do reach the point! After pondering about this a bit more, I found the following note when reinstalling polkit once more: --- [1/1] Extracting polkit-0.118: 100% You may need to manually remove /usr/local/etc/dbus-1/system.d/org.freedesktop.PolicyKit1.conf if it is no longer needed. --- And indeed, the file is gone again. So the state of the system above was as designed (whithout the file), but it didn't work for me. So something's fishy here. Either the system should work without the file, or the message is wrong. That message is a standard message from pkg about configuration files. Any file marked as a configuration file in the port will trigger that message when the port is removed (upgrading entails removing the port and reinstalling). pkg should leave the file there and only modify the .sample one on upgrade. It simply informs you you can remove configuration files for software you no longer use. Don't know why you end up missing the file. It should definitely be there and is needed as long as you use polkit. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: extreme window open delay, missing menu highlight
On 26/01/21 15:57, Gerrit Kühn wrote: Am Tue, 26 Jan 2021 15:37:12 +0100 schrieb Guido Falsi : --- Error creating proxy: Timeout was reached (g-io-error-quark, 24) --- This definitely comes from glib GIO, 24 is the numerical value for G_IO_ERROR_TIMED_OUT (if I correctly counted lines in the relevant include file, it makes sense though). Can you check the options on the gvfs port? the GOA option should be disabled, but I suggest you match the defaults on the port. If you're using the official binary packages the options should be correct, anyway you can try forcing reinstallation of gvfs and glib. I'm using the binary package: --- sh/2 276 % pkg info gvfs gvfs-1.46.1_2 Name : gvfs Version: 1.46.1_2 Installed on : Thu Jan 21 15:12:42 2021 CET Origin : devel/gvfs Architecture : FreeBSD:12:amd64 Prefix : /usr/local Categories : gnome devel Licenses : GPLv2 Maintainer : gn...@freebsd.org WWW: http://www.gnome.org/ Comment: GNOME virtual file system Options: AFC: off AVAHI : on BLURAY : on CDDA : on FUSE : off GOA: off GOOGLE : off GPHOTO : on MTP: on NFS: on SMB: on --- But I'll see if reinstalling changes something... The program where I can reproduce this issue most reliably appears to be claws-mail (which does not depend on gvfs as far as I can see, just glib/libgio). Most probably reinstalling will not fix this then. But sat this point I'm convinced the network is somewhat involved. Any remote file systems involved in all this? The update could be showing this symptom while it was not before. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: extreme window open delay, missing menu highlight
On 26/01/21 13:33, Gerrit Kühn wrote: Am Thu, 21 Jan 2021 19:53:26 +0100 schrieb Guido Falsi : also add /usr/local/lib/gtk-20 Nothing there apart from what gtk2 installed, I think. However, meanwhile I was able to get an actual error message on the long startup delay I described earlier. It reads --- Error creating proxy: Timeout was reached (g-io-error-quark, 24) --- No idea who is waiting for what here, and why. Google doesn't come up with anything useful, either. Any ideas? This error stirred my memory. that error is from glib GIO parts, and those use gvfs as a backend. Some time ago these two commits were made: https://svnweb.freebsd.org/ports?view=revision=552836 https://svnweb.freebsd.org/ports?view=revision=552839 Maybe I'm wrong and this is unrelated but there are similarities. Can you check the options on the gvfs port? the GOA option should be disabled, but I suggest you match the defaults on the port. If you're using the official binary packages the options should be correct, anyway you can try forcing reinstallation of gvfs and glib. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: extreme window open delay, missing menu highlight
On 21/01/21 19:51, Guido Falsi via freebsd-xfce wrote: I can't remember the systemwide gtk customization files location, but I'd look into: /usr/local/share/gtk-2.0 /usr/local/share/gtk-engines also add /usr/local/lib/gtk-20 -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: extreme window open delay, missing menu highlight
On 21/01/21 18:12, Gerrit Kuehn wrote: Hello, I've been "lucky" again and found another machine behaving strangely after updating to the latest xfce4 (4.16 on 12.2). I see two different issues, but I cannot say if they're independent or not. 1. Some programs take very long until they actually start and open up a visible window. Once the program runs, more of the same windows open up quickly. I've seen this issue most notably with xscreensaver. After typing the name in a terminal or clicking on the item in the start menu, it takes about *1* *minute* until the window opens up. This feels like there is some timeout involved, but I cannot get any error message. 2. Some programs don't show a "highlight" for the menu item the mouse pointer is currently set to. The menues still work as expected, but you don't see what entry is actually selected. Concerned programs are claws-mail and lxterminal. If there should be a single root cause: all affected software appears to still use gtk2, so maybe the issue is buried somewhere there? Is there an easy way to reset gtk2 settings (while keeping everything else)? First I thought that xfce4-terminal might also be affected as it took ages to re-open my saved session. However, maybe it is just trying to start something else before, and that is blocking everything else. Menu highlighting definitely works fine for it. Any hints are greatly appreciated. XFCE itself removed all support for gtk 2. But maybe after upgrading you still have some gtk theme? try grepping your packages for "engine" and "gtk", most probably you can just remove any gtk theme/engine you find. Pay caution anyway, obviously. Also check in ~/.config/gtk-2.0 if you have any custom configurations there. I can't remember the systemwide gtk customization files location, but I'd look into: /usr/local/share/gtk-2.0 /usr/local/share/gtk-engines -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: polkit not running after update
On 18/01/21 12:44, Gerrit Kühn wrote: Am Mon, 18 Jan 2021 12:19:00 +0100 schrieb Guido Falsi : Especially the file /usr/local/etc/dbus-1/system.d/org.freedesktop.PolicyKit1.conf, is it unmodified from what the port installs? There should be a .sample file you can try a diff from. BINGO! ;-) The file isn't there at all, it is simply missing (for whatever reason). Even reinstalling polkit before obiously didn't produce it. Anyway, now I just copied over the .sample file manually, restarted... and everything is working again as expected. Sometimes wild guesses do reach the point! Thank you very much for your support! I try to help when I can. cu Gerrit -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: polkit not running after update
On 18/01/21 11:58, Gerrit Kühn wrote: Am Mon, 18 Jan 2021 11:41:07 +0100 schrieb Guido Falsi : --- Jan 18 10:58:57 beastie dbus-daemon[36795]: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out (service_start_timeout=25000ms) --- However, I'm unable to find out /why/ this happens and how to fix it. Any hints? Not easy to guess. Also, while I do work on xfce ports I know little about polkit details. xfce uses it, but it's not part of xfce. Thanks for your time. Is there any better place where I could ask about this? Well, the polkit port is maintained by desktop@, so you could write to desk...@freebsd.prg too, that would at least widen your audience. You could also try launching polkitd by hand as a user or as root and see what it says It should also have a --debug flag. Turns out, it rather has a --no-debug flag. ;-) With debugging enabled I get the following: --- root@beastie:~ # /usr/local/lib/polkit-1/polkitd Successfully changed to user polkitd 11:52:18.901: Loading rules from directory /usr/local/etc/polkit-1/rules.d 11:52:18.901: Loading rules from directory /usr/local/share/polkit-1/rules.d 11:52:18.901: Finished loading, compiling and executing 1 rules Entering main event loop Connected to the system bus 11:52:18.903: Lost the name org.freedesktop.PolicyKit1 - exiting Shutting down Exiting with code 0 --- Searching about this, this looks like the communication with dbus is not working properly. This matches the error message I previously got from the other end (dbus) in /var/log/messages. Somehow the two processes fail to cumminucate with each other. I'd take a look at the policyd and dbus policies in /usr/local/etc/polkit-1 and /usr/local/etc/dbus-1. If something changed there recently, do you have any customizations in those files? Especially the file /usr/local/etc/dbus-1/system.d/org.freedesktop.PolicyKit1.conf, is it unmodified from what the port installs? There should be a .sample file you can try a diff from. Since there is a .sample file, if in the past this one was modified from any reason, upgrading or reinstalling the port would not update it. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: polkit not running after update
On 18/01/21 11:20, Gerrit Kühn wrote: Hello all, I don't quite know where to take this, hopefully I'm not completely wrong here. I've just updated a couple of machines using xfce from 12.1 to 12.2. Most work fine after the update, but one is slightly broken now. Here are some issues I see: XCFE starts just fine but refuses for open the xfce terminal (nothing happens). Also, logging out is not possible anymore (desktop gets dark, but not logout selection appears). As written in the subject, I think the main reason for this is that polkitd isn't running. Sometimes I can see various error windows popping up complaining about things that point into this direction, also ps doesn't show a polkitd like on the systems that work fine. In /var/log/messages I see the following error message from dbus: --- Jan 18 10:58:57 beastie dbus-daemon[36795]: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out (service_start_timeout=25000ms) --- However, I'm unable to find out /why/ this happens and how to fix it. Any hints? Not easy to guess. Also, while I do work on xfce ports I know little about polkit details. xfce uses it, but it's not part of xfce. Some things you could check: look into .xsession-errors, that's where output from user X11 session goes, maybe you can find some hint there. Do expect various scary warnings there, but most are really just noise. Check if you have any core dumps from polkit laying around. I think the root directory is the most likely place. You could also try launching polkitd by hand as a user or as root and see what it says It should also have a --debug flag. Trying to reinstall it (via ports if using ports o with pkg upgrade -f if using binary packages) could help. Same for it's requirements, I get: > pkg info -d polkit-0.118 polkit-0.118: expat-2.2.10 spidermonkey78-78.6.0_1 glib-2.66.4_1,1 gettext-runtime-0.21 dbus-1.12.20_3 So pkg upgrade -f (or rebuilding from ports if that's your method) for all those is worth a try. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE upgraded to 4.16
On 09/01/21 22:31, Andrea Venturoli wrote: On 1/9/21 10:29 PM, Andrea Venturoli wrote: Of course this should be fixed upstream, but in the meantime I'm attaching a patch that solves for me. Sorry. The patch was removed by the list. Submitted upstream here: https://gitlab.xfce.org/xfce/xfce4-settings/-/merge_requests/42 I'm going to commit the fix to the ports tree shortly. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE upgraded to 4.16
On 09/01/21 22:29, Andrea Venturoli wrote:
On 1/9/21 11:59 AM, Andrea Venturoli wrote:
Right now I reached an usable config on my desktop, but I will try and
get suck a backtrace and I'll come back if I succeed.
Here it is:
(gdb) bt
#0 0x000800e95287 in g_filename_from_uri () at
/usr/local/lib/libglib-2.0.so.0
#1 0x002103a7 in install_theme (widget=0x80361c3f0,
uris=0x80463bf98, builder=0x802d504e0) at main.c:881
#2 0x0020f949 in appearance_settings_install_theme_cb
(widget=0x803631180, builder=0x802d504e0) at main.c:1000
#3 0x000800db2486 in () at /usr/local/lib/libgobject-2.0.so.0
#4 0x000800dc8488 in g_signal_emit_valist () at
/usr/local/lib/libgobject-2.0.so.0
#5 0x000800dc8ee6 in g_signal_emit () at
/usr/local/lib/libgobject-2.0.so.0
#6 0x0008008ab72e in () at /usr/local/lib/libgtk-3.so.0
#7 0x000800db2486 in () at /usr/local/lib/libgobject-2.0.so.0
#8 0x000800dc8488 in g_signal_emit_valist () at
/usr/local/lib/libgobject-2.0.so.0
#9 0x000800dc8ee6 in g_signal_emit () at
/usr/local/lib/libgobject-2.0.so.0
#10 0x0008008abd36 in () at /usr/local/lib/libgtk-3.so.0
#11 0x000800b8dc18 in () at /usr/local/lib/libgtk-3.so.0
#12 0x000800db2486 in () at /usr/local/lib/libgobject-2.0.so.0
#13 0x000800dc8488 in g_signal_emit_valist () at
/usr/local/lib/libgobject-2.0.so.0
#14 0x000800dc8ee6 in g_signal_emit () at
/usr/local/lib/libgobject-2.0.so.0
#15 0x0008009817f1 in () at /usr/local/lib/libgtk-3.so.0
#16 0x000800db588c in g_cclosure_marshal_VOID__BOXEDv () at
/usr/local/lib/libgobject-2.0.so.0
#17 0x000800db2486 in () at /usr/local/lib/libgobject-2.0.so.0
#18 0x000800dc8488 in g_signal_emit_valist () at
/usr/local/lib/libgobject-2.0.so.0
#19 0x000800dc8ee6 in g_signal_emit () at
/usr/local/lib/libgobject-2.0.so.0
#20 0x00080097f69e in () at /usr/local/lib/libgtk-3.so.0
#21 0x000800983395 in () at /usr/local/lib/libgtk-3.so.0
#22 0x00080094341c in gtk_event_controller_handle_event () at
/usr/local/lib/libgtk-3.so.0
#23 0x000800b35d9c in () at /usr/local/lib/libgtk-3.so.0
#24 0x000800b882c1 in () at /usr/local/lib/libgtk-3.so.0
#25 0x000800db2486 in () at /usr/local/lib/libgobject-2.0.so.0
#26 0x000800dc8488 in g_signal_emit_valist () at
/usr/local/lib/libgobject-2.0.so.0
#27 0x000800dc8ee6 in g_signal_emit () at
/usr/local/lib/libgobject-2.0.so.0
#28 0x000800b35ad9 in () at /usr/local/lib/libgtk-3.so.0
#29 0x0008009d1c5f in gtk_propagate_event () at
/usr/local/lib/libgtk-3.so.0
#30 0x0008009d17ef in gtk_main_do_event () at
/usr/local/lib/libgtk-3.so.0
#31 0x0008002e43a1 in () at /usr/local/lib/libgdk-3.so.0
#32 0x000800319877 in () at /usr/local/lib/libgdk-3.so.0
#33 0x000800eb9a7e in g_main_context_dispatch () at
/usr/local/lib/libglib-2.0.so.0
#34 0x000800eb9e24 in () at /usr/local/lib/libglib-2.0.so.0
#35 0x000800eba17a in g_main_loop_run () at
/usr/local/lib/libglib-2.0.so.0
#36 0x0008009d111b in gtk_main () at /usr/local/lib/libgtk-3.so.0
#37 0x0020cb2d in main (argc=1, argv=0x7fffe660) at
main.c:1307
In frame #1 (install_theme) we have:
static void
install_theme (GtkWidget *widget, gchar **uris, GtkBuilder *builder)
{
...
for (i = 0; uris[i] != NULL; i++)
{
...
However in the caller (at frame #2, i.e.
appearance_settings_install_theme_cb):
gchar **uris;
GtkFileChooser *chooser = GTK_FILE_CHOOSER (dialog);
uris = g_new0 (gchar *, 1);
filename = gtk_file_chooser_get_filename (chooser);
uris[0] = g_filename_to_uri (filename, NULL, NULL);
install_theme (window, uris, builder);
So what I think happens is that the loop processes uri[0], which holds
the filename, but fails to find a NULL after it, since it was never
allocated.
Guess it should read:
uris = g_new0 (gchar *, 2);
Of course this should be fixed upstream, but in the meantime I'm
attaching a patch that solves for me.
I need to take a better look to be sure, but yes, your patch looks
correct at first sight.
I'm going to test it and also submit upstream (with attribution, obviously!)
--
Guido Falsi
___
freebsd-xfce@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xfce
To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE upgraded to 4.16
On 09/01/21 11:59, Andrea Venturoli wrote: On 1/8/21 8:33 PM, Guido Falsi wrote: So, in the end, I think the messages about chflags were just warnings and could be ignored; the problem lies elsewhere. I agree. There is no way then to diagnose this any further without a backtrace. Right now I reached an usable config on my desktop, but I will try and get suck a backtrace and I'll come back if I succeed. I can try that, since I am almost sure the bug you hit is easily reproducible. But to do that I need some time to rebuild ports with debug symbols enabled and setup a VM. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE upgraded to 4.16
On 09/01/21 12:14, Guido Falsi wrote: On 09/01/21 12:09, Andrea Venturoli wrote: On 1/8/21 8:42 PM, Guido Falsi wrote: ANyway, thinking about it, if the chflag errors are just warnings like you say above, then setting a custom TMPDIR will not be needed even with your setup. So there is no need for a warning anyway. Guido, you are losing sight with the heart of the problem, i.e. without TMPDIR, xfce4-appearance-settings tries to create a temporary directory in / (and obviously fails). This has nothing to do with where home is or what filesystem it's using. I've proposed a patch upstream to fix this where it should be fixed. Depending on the existence of a variable and not having a sensible default is an upstream bug. Ref: https://gitlab.xfce.org/xfce/xfce4-settings/-/merge_requests/41 Forgot to mention, I plan to integrate this patch in the ports tree, but I need to better test it before doing that. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE upgraded to 4.16
On 09/01/21 12:09, Andrea Venturoli wrote: On 1/8/21 8:42 PM, Guido Falsi wrote: I don't agree. Using a network file system for home directory if problematic at present. Most software uses sqlite databases for configurations which explicitly does not support networked file systems. and other problems could arise. >> >> Such a note should be attached to most software in the ports tree. >> Firefox and thunderbird (and most other browsers AFAIK) just to name >> two which use sqlite DBs heavily. (This is going OT, but Sqlite, in their FAQ, only suggest against *multiple processes* accessing the same database over NFS. ThunderBird works perfectly in such a setup as it's only one user/program accessing the database.) Thunderbird will work fine until it will have problems. Anyway you are obviouslt free to run your system any way you'd like to. ANyway, thinking about it, if the chflag errors are just warnings like you say above, then setting a custom TMPDIR will not be needed even with your setup. So there is no need for a warning anyway. Guido, you are losing sight with the heart of the problem, i.e. without TMPDIR, xfce4-appearance-settings tries to create a temporary directory in / (and obviously fails). This has nothing to do with where home is or what filesystem it's using. I've proposed a patch upstream to fix this where it should be fixed. Depending on the existence of a variable and not having a sensible default is an upstream bug. Ref: https://gitlab.xfce.org/xfce/xfce4-settings/-/merge_requests/41 IMVVHO, if TMPDIR is something a FreeBSD will most probably NOT have, then it should be changed into something else. Or at least the user should know it must be set. I made a mistake saying that it would have to be set. I said that because I thought that /tmp (a sensible fallback default and what I propose upstream) would not have been a working one on your setup, but that's not the case. So patching upstream to fallback on /tmp is more reasonable. bye av. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE upgraded to 4.16
On 08/01/21 20:33, Guido Falsi wrote: On 08/01/21 17:02, Andrea Venturoli wrote: On 1/8/21 4:00 PM, Guido Falsi wrote: The script does require a change to accomodate for not having any of the variables it checks set, but you will need to define TMPDIR anyway in your setup most probably to have it working. I've got no problem with that, altough I suggest specifying this in pkg-message. I don't agree. Using a network file system for home directory if problematic at present. Most software uses sqlite databases for configurations which explicitly does not support networked file systems. and other problems could arise. Such a note should be attached to most software in the ports tree. Firefox and thunderbird (and most other browsers AFAIK) just to name two which use sqlite DBs heavily. ANyway, thinking about it, if the chflag errors are just warnings like you say above, then setting a custom TMPDIR will not be needed even with your setup. So there is no need for a warning anyway. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE upgraded to 4.16
On 08/01/21 17:02, Andrea Venturoli wrote: On 1/8/21 4:00 PM, Guido Falsi wrote: My home is on NFS4 in case it matters. If you want other info or would like me to do some tests, just ask. It definitely matters. chflags is not supported by NFS. I thought so... But I have no idea why and where chflags is performed. I suspect it's mv(1) doing that Does mv ever change flags? There's no mention of it in the man page and I thought it didn't. In any case I'd be curious which flags the script would want to set. Not sure, maybe the archive you are using when extracted causes some flag to be activated and mv tries to replicate it. COuld you try creating a temporary directory in your home and pointing TMPDIR there? Sure. Now it just dumps core without giving any message. A subfolder briefly appears in TMPDIR, but then it's gone. ~/.themes gets populated (as it did when TMPDIR was on local ZFS). The theme is then selectable in "Window Manager" settings, but doesn't appear in xfce4-appearance-settings' list. So, in the end, I think the messages about chflags were just warnings and could be ignored; the problem lies elsewhere. I agree. There is no way then to diagnose this any further without a backtrace. The script does require a change to accomodate for not having any of the variables it checks set, but you will need to define TMPDIR anyway in your setup most probably to have it working. I've got no problem with that, altough I suggest specifying this in pkg-message. I don't agree. Using a network file system for home directory if problematic at present. Most software uses sqlite databases for configurations which explicitly does not support networked file systems. and other problems could arise. Such a note should be attached to most software in the ports tree. Firefox and thunderbird (and most other browsers AFAIK) just to name two which use sqlite DBs heavily. My personal opinion is home directories on NFS made sense in the ninties, but now disks are big and inexpensive and using syncronization software (syncthing, unison) to replicate them locally makes much more sense and avoids many issue. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE upgraded to 4.16
On 08/01/21 15:53, Andrea Venturoli wrote:
On 1/8/21 3:37 PM, Guido Falsi wrote:
Well, I just proposed what I use daily, everyone has his own preferences.
Of course :)
That doesn't mean I didn't appreciate your suggestion.
Looking at sources xfce4-settings uses a script to perform the
operation at one point it executes this line of code:
tmpdir=`TMPDIR="${XDG_CACHE_HOME:-$TMPDIR}" mktemp -d`
Could you check with env in a terminal if you have any of those two
env vars set?
I have none.
I tried "env TMPDIR=/tmp xfce4-appearance-settings", that brings me a
step further, but in the terminal I see:
(xfce4-appearance-settings:7941): Gtk-WARNING **: 15:49:23.317:
Content added to the action area of a dialog using header bars
(xfce4-appearance-settings:7941): Gtk-WARNING **: 15:49:23.317:
Content added to the action area of a dialog using header bars
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/menu-prelight.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/maximize-inactive.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/title-5-inactive.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/title-3-active.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/maximize-toggled-prelight.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/title-4-inactive.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/close-prelight.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/shade-inactive.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/hide-prelight.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/bottom-right-inactive.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/menu-active.xpm: Operation
not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/right-active.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/stick-toggled-prelight.xpm: Operation
not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/top-left-active.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/shade-toggled-inactive.xpm: Operation
not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/close-active.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/title-2-inactive.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/bottom-left-active.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/title-3-inactive.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/maximize-pressed.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/maximize-active.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/title-1-inactive.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/maximize-toggled-pressed.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/bottom-inactive.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/hide-active.xpm: Operation
not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/title-4-active.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/title-1-active.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/stick-prelight.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/maximize-toggled-active.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/top-right-active.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/stick-active.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/stick-pressed.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/close-pressed.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/stick-toggled-pressed.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/shade-pressed.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/maximize-prelight.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/bottom-active.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/menu-inactive.xpm:
Operation not supported
mv: chflags:
/home/andrea/.themes/Snowblind-Sunset/xfwm4/stick-toggled-active.xpm:
Operation not supported
mv: ch
Re: XFCE upgraded to 4.16
On 08/01/21 15:22, Andrea Venturoli wrote:
On 1/4/21 6:02 PM, Guido Falsi wrote:
I was also using sysutils/xfce4-kbdleds-plugin (since my laptop has
no indicators): any replacement for this?
Please do some searches on freshports, I'm quite sure there are some
ports there creating tray icons. Google is your friend too.
I din't find anything, but I'll try again.
In the meantime I upgraded my desktop:
For this kind of stuff (and also the previous point) I'm using
sysutils/conky
Doesn't conky show a widget on the desktop? I want that on a panel.
Well, I just proposed what I use daily, everyone has his own preferences.
Now one more question:
I can't quite cope with the deafult themes (Clearlooks which I was using
previously, now has changed in some way), so I downloaded some extra
ones and I'm trying to install them.
However, when I press "+ Add" in xfce4-appearance-settings and choose
the tarball, it tries to create a temporary directory in / (e.g.
"mktemp: mkdtemp failed on /tmp.G9yLe4V3: Permission denied").
Is this normal???
Is it a bug? Or am I trying to do things the wrong way?
Looking at sources xfce4-settings uses a script to perform the operation
at one point it executes this line of code:
tmpdir=`TMPDIR="${XDG_CACHE_HOME:-$TMPDIR}" mktemp -d`
Could you check with env in a terminal if you have any of those two env
vars set?
I do not have any, so the script would obviously end up using the root
directory, which is definitely wrong.
I need to think a little what the best solution could be in this case. I
also need to check the full script to create a sensible patch.
--
Guido Falsi
___
freebsd-xfce@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xfce
To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE upgraded to 4.16
On 05/01/21 12:53, Andrea Venturoli wrote: On 1/4/21 10:57 PM, Guido Falsi wrote: _ sysutils/xfce4-kbdleds-plugin was left untouched. This one builds fine and links with gtk3, are you sure it is not working? AFAIK it should work correctly. It doesn't for me. I thought about opening a bug report, but, then again, if you say it works, maybe it's something in my setup? Notice I'm on 2021Q1 branch, but AFAICT that should make no difference, should it? I'm sorry I did read the wrong port name. the kdeleds plugin is also abandoned upstream. I simply forgot to mark it broken and deprecate it. Thanks for reporting this, I'll do that shortly. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE upgraded to 4.16
On 04/01/21 19:43, Andrea Venturoli wrote: On 1/4/21 6:51 PM, Guido Falsi wrote: They are marked BROKEN, so not being build anyway. At least in theory port rules require a deprecation period for ports before removal, including BROKEN ones. Sorry, this makes sense, they should have been marked BROKEN, not removed. However, of the ports I cited: _ audio/xfce4-mixer was removed This one was marked as deprecated in r540614 on Jun 27. AN expiration date was NOT set because the exact date of release of XFCE 4.16 was unknown. Also even having a slight idea when it would be (the release slipped two times anyway) I could not know for sure when I would have had the port of the release ready. _ deskutils/xfce4-generic-slider was marked BROKEN; This one is not maintained by xfce@. The decision to mark it as BROKEN was taken together with the maintainer. It's his call if he wants to remove it, deprecate it or whatever. _ sysutils/xfce4-kbdleds-plugin was left untouched. This one builds fine and links with gtk3, are you sure it is not working? AFAIK it should work correctly. Someone could step in and fix them, for example, this is easier if the port is not actually removed. The way I understand it, they are not fixable (of course short of a major rewriting). This does not mean that nobody could step in. If they are supposed to be fixable, I might even try and see if I can help (although I won't promise anything). We have already been informed that work is ongoing to revive mixer. Unluckily it is improbable it will be ready in less than a month. Anyway Broken ports in the tree don't cause any strain and cost nothing. The package builder simply skips them. Since we are using a revision control removing them saves no disk space. I don't see a problem in having them stay in the tree deprecated for a few weeks until they are (semi)automatically removed. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE upgraded to 4.16
On 04/01/21 18:44, Andrea Venturoli wrote: On 1/4/21 6:22 PM, Guido Falsi wrote: On 04/01/21 18:02, Guido Falsi wrote: On 04/01/21 17:43, Andrea Venturoli wrote: P.S. Just out of curiosity: why weren't these ports removed, since we all know they were going to stop working? Why remove them while they are still working fine? BTW, some already had a deprecation notice. I know. What I meant was not to remove them early; I was just curious why they weren't removed at the same time XFCE 4.16 was introduced, since they stopped working on that same day. Rationale is: don't waste time trying to build them, since it's useless. They are marked BROKEN, so not being build anyway. At least in theory port rules require a deprecation period for ports before removal, including BROKEN ones. Someone could step in and fix them, for example, this is easier if the port is not actually removed. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE upgraded to 4.16
On 04/01/21 18:02, Guido Falsi wrote: On 04/01/21 17:43, Andrea Venturoli wrote: P.S. Just out of curiosity: why weren't these ports removed, since we all know they were going to stop working? Why remove them while they are still working fine? BTW, some already had a deprecation notice. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE upgraded to 4.16
On 04/01/21 17:43, Andrea Venturoli wrote: On 1/3/21 7:04 PM, Guido Falsi wrote: Now, to raise the bar a little :) I was also using sysutils/xfce4-kbdleds-plugin (since my laptop has no indicators): any replacement for this? Please do some searches on freshports, I'm quite sure there are some ports there creating tray icons. Google is your friend too. And finally, I'm using deskutils/xfce4-generic-slider, which is also broken to monitor the temperature of my desktop. Any suggestion here for a replacement? For this kind of stuff (and also the previous point) I'm using sysutils/conky bye & Thanks av. P.S. Just out of curiosity: why weren't these ports removed, since we all know they were going to stop working? Why remove them while they are still working fine? -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE upgraded to 4.16
On 03/01/21 19:15, Olivier Duchateau wrote: Le Sun, 3 Jan 2021 19:04:28 +0100, Guido Falsi via freebsd-xfce a écrit : On 03/01/21 17:41, Andrea Venturoli wrote: On 1/2/21 5:42 PM, Guido Falsi via freebsd-xfce wrote: Hi, I have just committed the update to xfce 4.16 as r559953 [1] Hello Guido and, first off, thanks for your work. Just a question (while I'm choosing which packages to build with Poudriere)... I used audio/xfce4-mixer: I see it's gone. audio/xfce4-pulseaudio-plugin is suggested as a replacement. Does this mean I have to run pulseaudio daemon on my laptop just to be able to set the volume??? If so, is there any other alternative? With the update to the new XFCE libraries the mixer plugin fails to compile. it requiress GTK2 support, which was dropped from the panel. Support for it was also dropped years ago and the fix is not trivial (major rewrite would be required). Upstream replacement is using pulsed. XFCE, like many other desktop environments, by default uses pulsed for managing audio. Actually a lot of software uses and prefers pulsed, and I would not be surprised if pulsed is actually running in the background on your system without you even noticing. Apart from this XFCE does not provide a replacement. Although, the ports tree does have some other p0orts which could be useful, for example I see audio/volumeicon which should put an icon in your system tray with which to set various audio parameters. audio/gtmixer also provides a tray icon. There are others which, I think< are worth a try. Hi, There is new maintainer for xfce4-mixer [1] (see multiple-backends branch), and OpenBSD developer add sndio support too. I don't know, when it will be available. Regards, [1] https://gitlab.xfce.org/apps/xfce4-mixer/-/tree/multiple-backends Thanks for the news. When it will be available I'll make a port for sure. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE upgraded to 4.16
On 03/01/21 17:41, Andrea Venturoli wrote: On 1/2/21 5:42 PM, Guido Falsi via freebsd-xfce wrote: Hi, I have just committed the update to xfce 4.16 as r559953 [1] Hello Guido and, first off, thanks for your work. Just a question (while I'm choosing which packages to build with Poudriere)... I used audio/xfce4-mixer: I see it's gone. audio/xfce4-pulseaudio-plugin is suggested as a replacement. Does this mean I have to run pulseaudio daemon on my laptop just to be able to set the volume??? If so, is there any other alternative? With the update to the new XFCE libraries the mixer plugin fails to compile. it requiress GTK2 support, which was dropped from the panel. Support for it was also dropped years ago and the fix is not trivial (major rewrite would be required). Upstream replacement is using pulsed. XFCE, like many other desktop environments, by default uses pulsed for managing audio. Actually a lot of software uses and prefers pulsed, and I would not be surprised if pulsed is actually running in the background on your system without you even noticing. Apart from this XFCE does not provide a replacement. Although, the ports tree does have some other p0orts which could be useful, for example I see audio/volumeicon which should put an icon in your system tray with which to set various audio parameters. audio/gtmixer also provides a tray icon. There are others which, I think< are worth a try. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE upgraded to 4.16
On 02/01/21 17:42, Guido Falsi via freebsd-xfce wrote: Hi, I have just committed the update to xfce 4.16 as r559953 [1] Due to a mistake on my part, please use r559955 or newer, which fixes the xfce4 metaport I overwrote by mistake with xfce4-goodies! -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
XFCE upgraded to 4.16
Hi, I have just committed the update to xfce 4.16 as r559953 [1] It should also be included in the next quarterly package set! IMPORTANT NOTE: Please read UPDATING entry 20210102! There is a problem with pkg getting confused and it could insstall the new version of libexo and later uninstall the old one, causing files to end up missing. If you happen to notice after the fact a simple "pkg upgrade -f libexo" will fix everything. People upgrading via ports should not be affected. [1] https://svnweb.freebsd.org/changeset/ports/559953 -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: Thunar icons are messed up
On 23/12/20 14:32, bran.damon via freebsd-xfce wrote: Hi, I installed XFCE from packages on a FreeBSD VirtualBox guest OS, on a Windows host. It is the latest version: FreeBSD my-freebsd 12.2-RELEASE FreeBSD 12.2-RELEASE r366954 GENERIC amd64 When I open the Thunar file manager, I see that some icons look messed up, like the Home and Refresh icons, see the attached image. I don't think you can attach images to mailing lists. Can you share via a link somewhere? Does anyone know how to fix this? If I get it correctly I have been seeing this in some instances, in my case it is happening with lightdm-gtk-greeter. I don't have a solution but it could be a cache thing. I;m not sure where these are cached, but ~/.cache/thumbnails could be a good guess. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: Bus error in xfce4-color-settings
On 09/10/20 16:06, Guido Falsi via freebsd-xfce wrote: Could you compile xfce ports with debugging symbols and file a bug BTW considering the backtrace you got also gtk, gdk and glib would need to be compiled with debugging symbols, since almost all the frames in your backtrace happen in these tree libraries. It's quite possible you actually hit a bug in one of these. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: Bus error in xfce4-color-settings
On 09/10/20 12:11, Morten Bo Johansen via freebsd-xfce wrote: Hi Could I report a bug in xfce4 by writing to this address rather than using bugzilla? You can report it, but this belongs more to the upstream, so to xfce gitlab instance. FreeBSD ports provide ports, but actual bugs in the upstream project should be reported there. While I can try to help and debug things, and sometimes also fix them, I actually have little understanding of the xfce software internals, so fixing such a bug (which as I state later loooks more GTK related) goes beyond my abilities. I have inserted a paste from the output of a backtrace of the core that the program dumped. There are no debugging symbols, but sometimes developers find such a backtrace useful all the same. My system: FreeBSD 12.1-RELEASE-p10 amd64 xfce4-color-settings 4.14.3 (Xfce 4.14) The backtrace does not help especially because none of the frames references an xfce part, everything seems to happen in gtk and its dependencies. Could you describe what you were doing when the crash happened? Could you compile xfce ports with debugging symbols and file a bug report at the xfce gitlab instance also describing exactly what you were doing? Another factor that could be important, are you using a loocale setting different from the default C or english ones? -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: FreeBSD Port: x11-wm/xfce4
On 29/02/20 16:27, Pedro Giffuni wrote: > > On 29/02/2020 06:35, Guido Falsi wrote: >> On 29/02/20 01:06, Pedro Giffuni wrote: >>> Hello; >>> >>> I've recently tried Xfce, and it's very nice. Just thought I'd suggest, >>> please set this file as executable: >>> >>> /usr/local/etc/xdg/xfce4/xinitrc >>> >>> I ended up doing chmod +x to that file in order to get it working in >>> xinit. >> I'll have a look at that. >> >> I'm using xfce from a display manager (lightdm) so I'm not using that >> file. > > Ah yes, for the record I am following the handbook: > > https://www.freebsd.org/doc/handbook/x11-wm.html > > Where it says "Unlike GNOME or KDE, Xfce does not provide its own login > manager ..." While it's technically correct most linux distributions providing XFCE as a default pair it with lightdm, so, with the latest update to 4.14, I made lightdm it's default display manager in the metaport. You should give it a spin. > >>> While here, I am having trouble as both mouse and the keyboard stop >>> working in X. Curiously both worked find in KDE. >> Maybe this is caused by the recent Xorg-server port change from devd >> baackend to udev backend? > > It's likely. I had it working at a time but the up arrow key stopped > working after the update. I then removed all the packages and started > from scratch. > > >> If that's the case the solution if installing xf86-input-evdev and >> restarting Xorg. > > That was certainly missing but I might have missed some configuration, > as it still doesn't work. > > I also lost the acceleration (ati-legacy) with the update. I'll figure > it out ;). > >> BTW xf86-input-evdev should be a dependency of the xorg-drivers >> metaport, so maybe forcing a reinstallation of that one will fix the >> issue. > > I started using xorg-minimal which explains some missing stuff. > I don't know the details about sorg-minimal, but yes the migration to udev may require some reconfiguration, especially if you have a customized setup. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: FreeBSD Port: x11-wm/xfce4
On 29/02/20 01:06, Pedro Giffuni wrote: > Hello; > > I've recently tried Xfce, and it's very nice. Just thought I'd suggest, > please set this file as executable: > > /usr/local/etc/xdg/xfce4/xinitrc > > I ended up doing chmod +x to that file in order to get it working in xinit. I'll have a look at that. I'm using xfce from a display manager (lightdm) so I'm not using that file. > > While here, I am having trouble as both mouse and the keyboard stop > working in X. Curiously both worked find in KDE. Maybe this is caused by the recent Xorg-server port change from devd baackend to udev backend? If that's the case the solution if installing xf86-input-evdev and restarting Xorg. BTW xf86-input-evdev should be a dependency of the xorg-drivers metaport, so maybe forcing a reinstallation of that one will fix the issue. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: XFCE 4.14 window manager improperly drawn decorations
On 30/01/20 19:35, Greg Veldman wrote: > Hi, I realize I'm probably late to the party as the next round > of quartly reports are already coming out, but I found this note > in the ones from last year > > https://www.freebsd.org/news/status/report-2019-07-2019-09.html#XFCE-4.14-update > > With a note to contact xfce@ if I'm experiencing the problem > with improperly drawn window decorations in XFWM 4.14 (this > appears to also be bug #240887). > > I have hardware on which I am able to reliably reproduce this > issue. This is using a card which identifies as a Caicos PRO > [Radeon HD 7450] in pciconf, though this is the exact card I > purchased for this machine: > > https://www.amazon.com/gp/product/B004X8EO6Q Hi, Sorry for the late answer! Unluckily this is a complicated bug to fix. I'm unable to reproduce it on my hardware and also have little knowledge of the internals of xfwm4 and also the libraries it uses (looks like cairo has an important role in this) This problem is being tracked upstream here: https://bugzilla.xfce.org/show_bug.cgi?id=15990 If you have time you could post a followup there with your findings, this at least would show the bug is alive and maybe attract some attention. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: [package - head-i386-default][sysutils/catfish] Failed for catfish-1.4.13 in stage
On 16/01/20 11:41, pkg-fall...@freebsd.org wrote: > You are receiving this mail as a port that you maintain > is failing to build on the FreeBSD package build server. > Please investigate the failure and submit a PR to fix > build. > > Maintainer: x...@freebsd.org > Last committer: madpi...@freebsd.org > Ident: $FreeBSD: head/sysutils/catfish/Makefile 523103 2020-01-15 > 11:34:57Z madpilot $ > Log URL: > http://beefy17.nyi.freebsd.org/data/head-i386-default/p523196_s356767/logs/catfish-1.4.13.log > Build URL: > http://beefy17.nyi.freebsd.org/build.html?mastername=head-i386-default=p523196_s356767 Ugh, sorrry for the breakage. I'm going to fix it ASAP. The breaking issue seems to be cause by man pages, and I suspect it has to do with the recent man page changes which landed shortly after my commit. Also I did not notice zeitgast is non functional at present, I'll see if it can be fixed without going back to python 2, otherwise I'll need to disable the option at present and mark it broken until a better fix is found. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: [CFT] Tester needed for XFCE window manager bug (broken decorations) - PR 241219
On 13/10/19 18:23, Guido Falsi wrote: > One test I'd like to perform is recompile the graphics/cairo port with > the OPENGL option disabled. Just while I was writing this a user performed this test and reported the results on XFCE bugzilla. Unluckily nothing changed so I'm still at a loss at an easy solution/workaround. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
[CFT] Tester needed for XFCE window manager bug (broken decorations) - PR 241219
Hi, As some of you may know the recent update to XFCE 4.14 caused a regression in the window manager which now, on some hardware and using certain drivers, causes the window decorations to appear black whatever the theme chosen. This has been also reported in our bugzilla at [1], and I reported it upstream at [2]. Also there is an independent bug report upstream [3], from a linux user which looks quite similar and could indicate the problem is not FreeBSD or driver specific. Fro information there and looking at the source code I got an idea this could be related to xfwm4 migrating to using the cairo library to draw the window decoration (commit at [4]). To try to at least workaround the problem some test are needed, but unluckily I'm not experiencing this issue on any of my PCs, so I can't perform these tests myself. Some volunteer experiencing the issue with a little time and ability to compile ports/packages with custom options and also maybe some patches is needed. One test I'd like to perform is recompile the graphics/cairo port with the OPENGL option disabled. The OPENGL backend in cairo 1.16 is experimental according to upstream and is used dynamically if available, but it may be causing the issue on certain driver/hardware combinations. User who filed the bug report at [3] seems to suggest this. If this "fixes" the issue maybe file a bug report with cairo project, and this would also require to perform a test with the newer 1.17.2 version. Another test requested upstream is to check if the issue appears both with modesetting drivers and with older X11 drivers (like x11-drivers/xf86-video-intel), without the modesetting kernel module loaded, or appears only with the modesetting driver. So, is there anyone wiling to spare a little time trying these tests and see if at least a workaround can be found, and maybe help upstream developers fix the underlying issue? Thanks in advance. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241219 [2] https://bugzilla.xfce.org/show_bug.cgi?id=15990 [3] https://bugzilla.xfce.org/show_bug.cgi?id=16032 [4] https://git.xfce.org/xfce/xfwm4/commit/?h=xfce-4.14=c1b720f018f8942a361cf9ad68bf308161effa8d -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: Welcome XFCE 4.14
On 27/09/19 18:55, Olivier Duchateau wrote: > Le Thu, 26 Sep 2019 17:53:40 +0200, > Guido Falsi a écrit : > >> On 24/09/19 11:13, Marko Cupać wrote: >>> On Sun, 22 Sep 2019 08:38:15 +0200 >>> Olivier Duchateau wrote: >>> >>>> Le Sat, 21 Sep 2019 23:29:48 +0200, >>>> Marko Cupać a écrit : >>>>> ...a few problems: >>>>> - I was using greybird theme on 4.12 as well, but now after the >>>>>upgrade I have ugly black background in title bar of each >>>>> window (window manager). It seem to affect other themes as well. >>> >>>> Are you using DRM kernel module? Or X.org drivers? >>> >>> Sorry for late reply, took me a few days to come back to office from >>> this year's eurobsdcon. >>> >>> I'm using latest DRM kernel module, >>> drm-fbsd12.0-kmod-4.16.g20190814. >>> >>> This is on FreeBSD 12.0-RELEASE-p10 GENERIC amd64, with yesterday's >>> ports (I build them myself in poudriere). My hardware is ThinkPad >>> T440, here's how display adapter looks to pciconf: >>> >>> vgapci0@pci0:0:2:0: class=0x03 card=0x220c17aa >>> chip=0x0a168086 rev=0x0b hdr=0x00 vendor = 'Intel Corporation' >>> device = 'Haswell-ULT Integrated Graphics Controller' >>> class = display >>> subclass = VGA >>> >>> Regards, >>> >> >> Hi, >> >> I was skimming upstream commits, to try to see if there is something >> that could affect us. Sometimes this gives hints and solutions some >> others it does not. >> >> While this is a complex issue and it's difficult to find a fix without >> specific knowledge, I noticed a recent commit [1] that maybe could >> help. >> >> This is a shot in the dark, but worth a try, so, someone affected >> should apply the patch at [2] to x11-wm/xfce4-wm and report back. I >> only tested this patch in poudriere and it compiles. >> >> Thanks in advance. >> >> [1] >> https://github.com/xfce-mirror/xfwm4/commit/e5462de37a4b0a18c051e9a92ea6dce7cd7b79a8 >> >> [2] https://people.freebsd.org/~madpilot/xfce4-wm.diff >> > > Hi Guido, > > I've just tested your patch, and I've still black borders with drm-kmod > (on 12.0-RELEASE-p10). With Xorg drivers it is ok. > > I noticed, build stage complains because libXpresent is missing (in > ports tree too). > > You can see my patch [1] (based on yours). I need to add xpresent support soon. I have been busy and sitting on the patch. I'll do that soon. No need to commit the other patches at present if they don't fix the issue. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: Welcome XFCE 4.14
On 24/09/19 11:13, Marko Cupać wrote: > On Sun, 22 Sep 2019 08:38:15 +0200 > Olivier Duchateau wrote: > >> Le Sat, 21 Sep 2019 23:29:48 +0200, >> Marko Cupać a écrit : >>> ...a few problems: >>> - I was using greybird theme on 4.12 as well, but now after the >>>upgrade I have ugly black background in title bar of each window >>>(window manager). It seem to affect other themes as well. > >> Are you using DRM kernel module? Or X.org drivers? > > Sorry for late reply, took me a few days to come back to office from > this year's eurobsdcon. > > I'm using latest DRM kernel module, drm-fbsd12.0-kmod-4.16.g20190814. > > This is on FreeBSD 12.0-RELEASE-p10 GENERIC amd64, with yesterday's > ports (I build them myself in poudriere). My hardware is ThinkPad T440, > here's how display adapter looks to pciconf: > > vgapci0@pci0:0:2:0: class=0x03 card=0x220c17aa chip=0x0a168086 rev=0x0b > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Haswell-ULT Integrated Graphics Controller' > class = display > subclass = VGA > > Regards, > Hi, I was skimming upstream commits, to try to see if there is something that could affect us. Sometimes this gives hints and solutions some others it does not. While this is a complex issue and it's difficult to find a fix without specific knowledge, I noticed a recent commit [1] that maybe could help. This is a shot in the dark, but worth a try, so, someone affected should apply the patch at [2] to x11-wm/xfce4-wm and report back. I only tested this patch in poudriere and it compiles. Thanks in advance. [1] https://github.com/xfce-mirror/xfwm4/commit/e5462de37a4b0a18c051e9a92ea6dce7cd7b79a8 [2] https://people.freebsd.org/~madpilot/xfce4-wm.diff -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: Welcome XFCE 4.14
On 25/09/19 10:30, Guido Falsi via freebsd-xfce wrote: > > The XFCE bug I filed is visible here: > > https://bugzilla.xfce.org/show_bug.cgi?id=15990 > I already got some feedback about this, so if anyone experiencing the issue could go there and perform the requested tests it would be very appreciated. If you don't want to register in their bugzilla, please tell me the test results and I'll do the reporting. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: Welcome XFCE 4.14
On 25/09/19 10:21, Guido Falsi via freebsd-xfce wrote: > On 24/09/19 11:13, Marko Cupać wrote: >> On Sun, 22 Sep 2019 08:38:15 +0200 >> Olivier Duchateau wrote: >> >>> Le Sat, 21 Sep 2019 23:29:48 +0200, >>> Marko Cupać a écrit : >>>> ...a few problems: >>>> - I was using greybird theme on 4.12 as well, but now after the >>>>upgrade I have ugly black background in title bar of each window >>>>(window manager). It seem to affect other themes as well. >> >>> Are you using DRM kernel module? Or X.org drivers? >> >> Sorry for late reply, took me a few days to come back to office from >> this year's eurobsdcon. >> >> I'm using latest DRM kernel module, drm-fbsd12.0-kmod-4.16.g20190814. >> >> This is on FreeBSD 12.0-RELEASE-p10 GENERIC amd64, with yesterday's >> ports (I build them myself in poudriere). My hardware is ThinkPad T440, >> here's how display adapter looks to pciconf: >> >> vgapci0@pci0:0:2:0: class=0x03 card=0x220c17aa chip=0x0a168086 rev=0x0b >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Haswell-ULT Integrated Graphics Controller' >> class = display >> subclass = VGA >> >> Regards, >> > > I'm filing a bug report in the XFCE bugzilla. I'll report what I know > about this. > > Could you open a bug report on our bugzilla, so I can add it as a > reference for them? > > If you could attach there a screenshot of the issue it would be great. > The XFCE bug I filed is visible here: https://bugzilla.xfce.org/show_bug.cgi?id=15990 -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: Welcome XFCE 4.14
On 24/09/19 11:13, Marko Cupać wrote: > On Sun, 22 Sep 2019 08:38:15 +0200 > Olivier Duchateau wrote: > >> Le Sat, 21 Sep 2019 23:29:48 +0200, >> Marko Cupać a écrit : >>> ...a few problems: >>> - I was using greybird theme on 4.12 as well, but now after the >>>upgrade I have ugly black background in title bar of each window >>>(window manager). It seem to affect other themes as well. > >> Are you using DRM kernel module? Or X.org drivers? > > Sorry for late reply, took me a few days to come back to office from > this year's eurobsdcon. > > I'm using latest DRM kernel module, drm-fbsd12.0-kmod-4.16.g20190814. > > This is on FreeBSD 12.0-RELEASE-p10 GENERIC amd64, with yesterday's > ports (I build them myself in poudriere). My hardware is ThinkPad T440, > here's how display adapter looks to pciconf: > > vgapci0@pci0:0:2:0: class=0x03 card=0x220c17aa chip=0x0a168086 rev=0x0b > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Haswell-ULT Integrated Graphics Controller' > class = display > subclass = VGA > > Regards, > I'm filing a bug report in the XFCE bugzilla. I'll report what I know about this. Could you open a bug report on our bugzilla, so I can add it as a reference for them? If you could attach there a screenshot of the issue it would be great. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: Welcome XFCE 4.14
On 25/09/19 09:01, Andrea Venturoli wrote: > On 2019-09-24 19:46, Olivier Duchateau wrote: > >> I think the linuxkpi is too old with 12.0-RELEASE (or switch to >> -CURRENT). Gtk3 is not able to operate properly with OpenGL libraries. > > Not sure what you mean here; maybe I'm not getting it... > > I've upgraded two 11.3 systems (one with ATI Radeon HD 4250 and one > Intel(R) HD Graphics 2000) and I'm seeing no such problems. I'm not either, I'm almost sure this is something showing up only on specific hardware. The fact that the problem is showing int he window decorations only puts the blame on the window manager. > > The Radeon one seems to feel slightly slower (than it was with XFCE > 4.12), but, then again, it might just be an impression. > I've yet to test the Intel one properly. > > (On the Intel notebook I've always had some screen corruption here and > there and I guess it won't go away with an XFCE upgrade; it's not what > the OP described, though). I've always had some screen corruption with the intel driver, even back to when I was using FVWM2 as a window manager. That's something beyond the window manager control. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: Welcome XFCE 4.14
On 24/09/19 19:46, Olivier Duchateau wrote: > Le Tue, 24 Sep 2019 11:13:09 +0200, > Marko Cupać a écrit : > >> On Sun, 22 Sep 2019 08:38:15 +0200 >> Olivier Duchateau wrote: >> >>> Le Sat, 21 Sep 2019 23:29:48 +0200, >>> Marko Cupać a écrit : >>>> ...a few problems: >>>> - I was using greybird theme on 4.12 as well, but now after the >>>>upgrade I have ugly black background in title bar of each >>>> window (window manager). It seem to affect other themes as well. >> >>> Are you using DRM kernel module? Or X.org drivers? >> >> Sorry for late reply, took me a few days to come back to office from >> this year's eurobsdcon. >> >> I'm using latest DRM kernel module, drm-fbsd12.0-kmod-4.16.g20190814. >> >> This is on FreeBSD 12.0-RELEASE-p10 GENERIC amd64, with yesterday's >> ports (I build them myself in poudriere). My hardware is ThinkPad >> T440, here's how display adapter looks to pciconf: >> >> vgapci0@pci0:0:2:0: class=0x03 card=0x220c17aa >> chip=0x0a168086 rev=0x0b hdr=0x00 vendor = 'Intel Corporation' >> device = 'Haswell-ULT Integrated Graphics Controller' >> class = display >> subclass = VGA >> >> Regards, > > I think, you should use the X.org driver for the moment > (xf86-video-intel) and one of fallback drivers (VESA if your computer > uses BIOS, or SCFB with UEFI). > > I think the linuxkpi is too old with 12.0-RELEASE (or switch to > -CURRENT). Gtk3 is not able to operate properly with OpenGL libraries. > Sorry I could not reply earlier. This is unfortunate. I hope with FreeBSD 12.1 things could get better, but I fear that the KPI will not change. I'm using head and did not see any issue, this corroborates what Olivier suggests. I could anyway file a bug report in XFCE bugzilla just to track the issue. Could you provide a screenshot of the broken display? -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Welcome XFCE 4.14
Hi, I have just committed XFCE 414 to the ports tree, so it will be included in the next quarterly. This new XFCE version has all core parts updated to use GTK3. Due to this x11-themes/gtk-xfce-engine is not up to the task anymore, since it only supports GTK 2. XFCE 4.14 from the ports tree installs unthemed, but by default it depends on greybird, which can be manually enabled in the configuration. Also a few other themes are available in the ports tree. Same goes for icon themes. Another big change regards the Display Manager. the xfce meta port used to depend on slim. This has changed and now xfce depends on lightdm by default. I'd personally suggest all users to perform the switch, since slim has not been developed for some time, while lightdm is a modern display manager. Please report if you encounter any problem with this update! -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: FreeBSD ports you maintain which are out of date
On 12/08/19 13:38, Olivier Duchateau wrote: > On Mon, 12 Aug 2019 11:30:07 +0200 > Guido Falsi wrote: > >> On 12/08/19 10:07, portsc...@freebsd.org wrote: >>> Dear port maintainer, >>> >> [...] >>> +-+ >>> x11-wm/xfce4-desktop| 4.12.5 | 4.14.1 >>> +-+ >>> x11-wm/xfce4-session| 4.12.1 | 4.14.0 >>> +-+ >>> x11-wm/xfce4-wm | 4.12.5 | 4.14.0 >>> +-+ >>> >> >> As you may know XFCE 4.14 has been released. >> >> I'm working on the update, have patches in testing and am actually >> running XFCE 4.13 (soon to be updated to the official 4.14) on my desktop. >> >> The patches I'm working with are available here: >> >> https://github.com/madpilot78/FreeBSD-xfce4.13 >> >> >> I still need to test the latest versions and there are a few edges which >> need smoothing, but I'm on track to submitting the update for approval >> (to portmgr) and commit it soonish. >> >> -- >> Guido Falsi >> ___ >> freebsd-xfce@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-xfce >> To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org" > > Hi, > > On my side, it is fine. > > Here screenshot of my laptop [1]. I still have testing to do and I'm not home these days so things are a little slow. I want "formal" testing to be ok(that is adherence to ports rules, portlint where possible, everything building fine on poudriere). After that I'll test running things on my laptop and desktop. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: FreeBSD ports you maintain which are out of date
On 12/08/19 10:07, portsc...@freebsd.org wrote: > Dear port maintainer, > [...] > +-+ > x11-wm/xfce4-desktop| 4.12.5 | 4.14.1 > +-+ > x11-wm/xfce4-session| 4.12.1 | 4.14.0 > +-+ > x11-wm/xfce4-wm | 4.12.5 | 4.14.0 > +-+ > As you may know XFCE 4.14 has been released. I'm working on the update, have patches in testing and am actually running XFCE 4.13 (soon to be updated to the official 4.14) on my desktop. The patches I'm working with are available here: https://github.com/madpilot78/FreeBSD-xfce4.13 I still need to test the latest versions and there are a few edges which need smoothing, but I'm on track to submitting the update for approval (to portmgr) and commit it soonish. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: Fw: Re: Upcoming XFCE4.14 development
On 02/05/19 21:04, Olivier Duchateau wrote: >> [1] https://wiki.freebsd.org/Xfce >> -- >> Guido Falsi > > Hi Guido, > > I'm also working with Xfce 4.13. > > I think, it's time to switch to "simplify MASTER_SITES macro" in Makefile > (D8416 [1], I alreay use this feature in my repository). This is a more complicated change, and I think requires portmgr approval. BTW there are also unrelated changes in the patch there (LICENSE added). While not wrong it helps to keep unrelated changes out of reviews. You should address the comments there which you still have not also. I'll be looking at the review and if I have proposals I'll post them there. > > Remove all ports depending of x11-toolkits/libxfce4gui (not anymore > maintained by upstream for ages). While I agree in principle, I'm a little wary about removing ports just because they are old. I'd rather leave them in until they brake or become and hindrance to the maintenance of the other XFCE parts. I also see that they are already marked deprecated via Uses/xfce.mk, so we could deprecate them explicitly and add an expiration date. This procedure is what is actually mandated by the ports tree rules anyway. > > About GObject Introspection, x11/libxfce4util is fully functional [2]. I also > submit several patches for x11/xfce4-conf [3], sysutils/garcon [4]. I'm > working on x11/libexo too (but I wonder if this library is very useful). So > devel/xfce4-vala can be remove. Regarding Gobject Introspection, I know little about it, I simply tested enabling the flags and got some errors. I plan to investigate but I did not dig any deeper. I'll import your patches in my own repo. What do you mean with "So devel/xfce4-vala can be remove"? I'm sorry but I don't understand that. > > With Xfdesktop >= 4.13, in Ristretto the wallpaper manager needs this patch > [5]. Oh, interesting, I'll import that one too. I really hope all these patches get integrated before the pre-releases! > > We need to create slave port for x11-wm/xfce4-session: > - x11-wm/xfce4-session (linked to xfce4-screensaver) > - x11-wm/xfce4-session-xscreensaver (xscreensaver is supported by default, it > provides an autostart file). Yes, I was thinking about this too. But we need anyway to choose a default one. xfce4-screensaver looks promising but last time I tested it it still had some rough edges. I need to test again. I also see it's being actively developed fast, so I hope the author make some more releases before code freeze, so we can better test it. > > xscreensaver and xfce4-screensaver are in conflit with each other. I noticed. Being mine a test repo I did not care too much about resolving this conflict right now. As stated before, unless xfce4-screensaver becomes more stable I'd leave the default as is. > For the shutdown fallback (ability to close, quit and so on a session without > ConsoleKit) can be optional. It requires manual intervention on some ports > (but it is functional). I have not had time to followup to the bug in the XFCE bugzilla about this. I was planning to make tests these days with it. Due to this, I actually don't exactly know what we are talking about. I need time to study this. > > As Xfce 4.14 will be Gtk3 only (except for some applications, not yet ported > to this toolkit), x11-themes/gtk-xfce-engine is obslete. We need a new Gtk > theme (compatible with both versions), Adwaita ? Greybird ? Not an expert on themes, I've always taken whatever came by default, not caring too much as long as functional. I see that greybird is already in the tree and unmaintained (and the WWW link is broken). I will test that before endorsing it, but it looks like a promising candidate. > > Guido, in your repository for x11/libxfce4menu, GLADE option should be > gladeui2 (gladeui supports only Gtk2, and not Gtk3). Thanks! I fixed that. > > In x11/xfce4-conf dbus and dbus-glib are not necessary, because it depends of > gdbus (through Gio). So for some ports USE_XFCE must be adjusted. I can > provide list of these ports. I added those because poudriere reported them as missing dependencies. The library installed by that port is actually linked directly to those libraries. So poudriere warning looks legit. Maybe it is a case of overlinking? > ldd -av /usr/local/lib/libxfconf-0.so /usr/local/lib/libxfconf-0.so: libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x80067f000) libdbus-glib-1.so.2 => /usr/local/lib/libdbus-glib-1.so.2 (0x800683000) libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x8006ab000) libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x8006fe000) libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x800e0) libintl.so.8 => /usr/local/lib/libintl.so.8 (0x80074d000)
Upcoming XFCE4.14 development
Hi all! As you may know the XFCE people have published a schedule with a release date for XFCE4.14 on 11 August 2019! In the while I've been cooking up a repository on github with ports updated to XFCE 4.13 (development version): https://github.com/madpilot78/FreeBSD-xfce4.13 I'm now sending this email to make it known, and seeking feedback testing and also some help. So comments, suggestions and pull requests are welcome. At present I consider this repository as very experimental, but I'd like to make it usable on real workstation before XFCE4.14pre2, so that proper testing can be performed and to get into track to commit the update to the ports tree shortly after the official release. There are also some open issues, if anyone can help, please read the README in the repository about that. I also think the FreeBSD wiki xfce page [1] should get a little refresh, anyone willing to help cleanup old content and put up new information? Thanks! [1] https://wiki.freebsd.org/Xfce -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: starting xfce "the correct way"
On 18/12/18 09:50, Marko Cupać wrote: > Hi, > > what is the difference between starting xfce with `startxfce4 > --with-ck-launch' and sourcing /usr/local/etc/xdg/xfce4/xinitrc > in .xinitrc? Both ways seem to work, but with some noticeable > differences: --with-ck-launch enables me to shutdown without polkit > rules. This is a complicated matter which goes a little beyond my understanding of modern X server things. Anyway I have gathered this much: Modern display mangers are expected to setup policykit and a bunch of other things for the window manage/desktop environment. AFAIK the ones that do this correctly at present are GDM, and lightDM (but I'm not sure since lightDM is not working for me and I've been unable to diagnose it) If launching the X session from the console or with an older display manager (XDM, for example) one needs to launch "consolekit" which, AFAIK, performs the setup the DM should perform. you could also launch consolekit by hand, the --with-ck-launch switch is just for convenience. So I'd say that, if you use a "modern" display manager the correct way to launch it is without the --with-ck-launch switch. Modern display managers should actually do everything by themselves, understand which DE/WMs are available based on the files in /usr/local/share/xsessions and use the files there to figure out how to start them. If you start xfce from console you need extra steps to get a fully functional desktop environment, the --with-ck-launch is a useful shortcut. You should also setup the correct locale if not already done. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: FreeBSD Port: sysutils/xfburn
On 06/11/18 15:35, Guido Falsi wrote: > On 04/11/18 21:15, Guido Falsi wrote: >> On 04/11/18 05:36, Holger Wagemann wrote: >>> Dear committer, >>> >>> my system: FreeBSD 11.2-RELEASE-p4 amd64 >>> >>> pkg info xfburn >>> xfburn-0.5.5 >>> Name : xfburn >>> Version: 0.5.5 >>> Installed on : Sun Nov 4 05:29:02 2018 CET >>> Origin : sysutils/xfburn >>> >>> I can start xfburn, I can select files for creating an Audio-CD, but >>> when I try to start burning procedere, xfburn crashes , here is >>> complete output after starting: >> >> This will be difficult to debug. I've never tried to burn audio CDs with >> xfburn, but I'll try that shortly to see what happens on my system. >> >> For the record some standard questions: >> >> Are you using binary package or compiling your own ports? >> Quarterly or latest? >> >> In case someone should compile xfburn with debug symbols and get a >> backtrace from it. >> >> If I can reproduce this I'll do this myself. >> > > I succeeded in reproducing it and got a backtrace. I'm posting it for > the record, just in case someone is faster than me at studying it. It's a locking problem. Looks like in linux pthread_cond_timedwait is more permissive and accepts a lock held by another thread or no lock at all. I had to rework locking a little I'm not actually sure I got it right though. Here's the patch: https://people.freebsd.org/~madpilot/xfburn.diff It's against the port. Can you test it and report back? I'd suggest you test it with a CD-RW, so you can blank them if they get burned wrong. On my system it gets past the crash, but I get scsi errors when the actual burning starts, but maybe it's my drive. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: FreeBSD Port: sysutils/xfburn
On 04/11/18 21:15, Guido Falsi wrote: > On 04/11/18 05:36, Holger Wagemann wrote: >> Dear committer, >> >> my system: FreeBSD 11.2-RELEASE-p4 amd64 >> >> pkg info xfburn >> xfburn-0.5.5 >> Name : xfburn >> Version: 0.5.5 >> Installed on : Sun Nov 4 05:29:02 2018 CET >> Origin : sysutils/xfburn >> >> I can start xfburn, I can select files for creating an Audio-CD, but >> when I try to start burning procedere, xfburn crashes , here is >> complete output after starting: > > This will be difficult to debug. I've never tried to burn audio CDs with > xfburn, but I'll try that shortly to see what happens on my system. > > For the record some standard questions: > > Are you using binary package or compiling your own ports? > Quarterly or latest? > > In case someone should compile xfburn with debug symbols and get a > backtrace from it. > > If I can reproduce this I'll do this myself. > I succeeded in reproducing it and got a backtrace. I'm posting it for the record, just in case someone is faster than me at studying it. ** (xfburn:6198): WARNING **: 15:32:13.999: unknown profile, assuming BD ** (xfburn:6198): WARNING **: 15:32:14.001: unknown profile, assuming BD [New LWP 100802 of process 6198] GLib (gthread-posix.c): Unexpected error from C library during 'pthread_cond_timedwait': Operation not permitted. Aborting. Thread 35 received signal SIGABRT, Aborted. [Switching to LWP 100802 of process 6198] 0x0008013b957a in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x0008013b957a in thr_kill () from /lib/libc.so.7 #1 0x0008013b7974 in raise () from /lib/libc.so.7 #2 0x00080132afa9 in abort () from /lib/libc.so.7 #3 0x0008011f05d0 in g_thread_abort (status=1, function=0x8010b8821 "pthread_cond_timedwait") at gthread-posix.c:78 #4 0x0008011f0f13 in g_cond_wait_until (cond=0x804f93860, mutex=0x804f93870, end_time=1180297413) at gthread-posix.c:916 #5 0x00222fe4 in prepare (trans=0x804f938b0, error=0x7fffdfffdf28) at xfburn-transcoder-gst.c:846 #6 0x002207e1 in xfburn_transcoder_prepare (trans=0x804f938b0, error=0x7fffdfffdf28) at xfburn-transcoder.c:173 #7 0x0021ff15 in thread_burn_composition (params=0x80561b5b0) at xfburn-burn-audio-cd-composition-dialog.c:388 #8 0x0008011c24bd in g_thread_proxy (data=0x8050b5cf0) at gthread.c:784 #9 0x000800b16775 in ?? () from /lib/libthr.so.3 #10 0x in ?? () Backtrace stopped: Cannot access memory at address 0x7fffdfffe000 (gdb) -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: FreeBSD Port: sysutils/xfburn
On 04/11/18 05:36, Holger Wagemann wrote: > Dear committer, > > my system: FreeBSD 11.2-RELEASE-p4 amd64 > > pkg info xfburn > xfburn-0.5.5 > Name : xfburn > Version: 0.5.5 > Installed on : Sun Nov 4 05:29:02 2018 CET > Origin : sysutils/xfburn > > I can start xfburn, I can select files for creating an Audio-CD, but > when I try to start burning procedere, xfburn crashes , here is > complete output after starting: This will be difficult to debug. I've never tried to burn audio CDs with xfburn, but I'll try that shortly to see what happens on my system. For the record some standard questions: Are you using binary package or compiling your own ports? Quarterly or latest? In case someone should compile xfburn with debug symbols and get a backtrace from it. If I can reproduce this I'll do this myself. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: Package `xfce4-goodies` does not fully install all of its dependencies?
On 11/10/18 10:47, Hyun Hwang wrote: > Hi, > > On Thursday, October 11, 2018, 9:56 AM (UTC+0200), Guido Falsi > wrote: >> version of FreeBSD? Are you using latest binary packages? Quarterly? Own >> repo? > > My machine is running FreeBSD 12.0-ALPHA9 r339274, with pkg pulling things > from `pkg+http://pkg.freebsd.org/FreeBSD:12:amd64/latest` IIRC. Every package > installed on my machine was up-to-date, including the pkg itself. > At present packages for 12 could have other problems due to the OpenSSL thing, but since I was able to reproduce this in 11.2 this is not caused by that. >>> pkg: gstreamer1-plugins-lame has a missing dependency: lame >> >> Uhm, this could be related in some way. > > Possibly? I have no idea how could this happen in pkg; it's not like I can > mangle package dependencies as in Ports tree. > Not sure, But this missing dependency could be breaking the chain that causes the other ones not to be installed. All the packages missing are multimedia related. volumed, mixer, gigolo. So it looks reasonable. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: Package `xfce4-goodies` does not fully install all of its dependencies?
7-cairo: 1.14.1 > py27-gobject: 2.28.6_8 > libglade2: 2.6.4_9 > gstreamer-plugins: 0.10.36_11,3 > gstreamer: 0.10.36_6 > gstreamer-plugins-good: 0.10.31_3,3 > This list also includes other packages skipped by the previous command not related to this one, so it looks like pkg, in this further run, is recovering from skipping parts in the previous run > Number of packages to be installed: 55 > > The process will require 154 MiB more space. > 34 MiB to be downloaded. > > Proceed with this action? [y/N]: > ``` > > Can anyone tell me what is wrong? > > Thank you, > -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: help needed: problem updating x11/libexo to 0.12.1
On 06/18/18 23:51, Guido Falsi wrote: > Hi all, > > I have been testing updating libexo to recently released 0.12.1, but > can't publish the update since it causes thunar to crash on startup. > > As usual if I compile libexo WITH_DEBUG enabled, the problem goes away. > > I have filed a bug report upstream with my findings: > > https://bugzilla.xfce.org/show_bug.cgi?id=14465 > I'm following up to inform that upstream was very responsive and fast in proposing a fix. They already released a fixed version and I'll commit that later today, after some testing. -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
help needed: problem updating x11/libexo to 0.12.1
Hi all, I have been testing updating libexo to recently released 0.12.1, but can't publish the update since it causes thunar to crash on startup. As usual if I compile libexo WITH_DEBUG enabled, the problem goes away. I have filed a bug report upstream with my findings: https://bugzilla.xfce.org/show_bug.cgi?id=14465 and here is the patch to update the port (which I can't commit due to the crash): https://people.freebsd.org/~madpilot/libexo.diff I anyone is willing to help, please test the update, see if it crashes and if you have time and inclination I'm open to suggestions on how to solve this. It's important that any solution is something we can upstream. In the while I'm still investigating. Thanks in advance! -- Guido Falsi ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
[REVIEW] [RFC] adding x11menulibre to xfce4-goodies
Hi, I've recently added a port of menulibre to the ports collection: https://www.freshports.org/x11/menulibre/ Since xfce has bindings to call it from the whiskermenu panel plugin (and other places) and I noticed many linux distributions do bundle it with their xfce packages I think it would make since to do so too. I'd then like to add it to xfce4-goodies metaport. Here is a review on phabricator for the change: https://reviews.freebsd.org/D15597 I'm asking here before doing it because I can see some people could have objections due to adding some more dependencies. Hoping this is a reasonable way of handling it, if I get no objection in a pair of weeks or so, I'll go ahead and commit the change. Thanks! -- Guido Falsi <madpi...@freebsd.org> ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: tard needs help
On 01/06/2018 10:41, Per Gunnarsson via freebsd-xfce wrote: > Hello! > > I have accidentally removed the directories /usr/local/share/xfce4 and > /usr/local/share/xfwm4. Those files are all installed by the packages. So reinstalling all xfce related port/packages should fix your problem. You can get a list of what needs to be reinstalled using: pkg info -o '*xfce*' If you're using binary packages you can just pass the output of the above to pkg upgrade -f like this: pkg info -o '*xfce*' | xargs pkg upgrade -fy with portmaster you should be able to use a similar command after xargs(sorry can't help with portmaster syntax). For direct ports usage a more manual approach is needed, based on the output of pkg info. Some xfce related ports are installed without "xfce" text in their package name(thunar, garcon and gigolo come to mind) if you still have problems after the above you should reinstall those too. > > Now I wonder how I can download them so that I can restart with a > default panel. > The above should work, please let me know if it works fine. -- Guido Falsi <madpi...@freebsd.org> ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
Re: FreeBSD Port: x11-fm/thunar
On 10/07/2017 19:53, Daniel Drinnon wrote: Using poudriere to build x11-fm/thunar on a FreeBSD 11.1 p1 amd64 box with a FreeBSD 10.4 amd64 jail and it fails to build during the patch-depends phase because of a license issue. Here's a clip of the log: I fixed this in r451481. A change has been committed in bsd.license.mk which exposed a bug in how this port was using the LICENSE framework which went unnoticed till now. -- Guido Falsi <madpi...@freebsd.org> ___ freebsd-xfce@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xfce To unsubscribe, send any mail to "freebsd-xfce-unsubscr...@freebsd.org"
