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 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 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 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: 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: 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: 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"
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: 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"
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 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 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 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 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 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 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 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 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: chflags:
/home/andrea/.th
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 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 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 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 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 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 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: 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: 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 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: 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: 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 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&revision=552836 https://svnweb.freebsd.org/ports?view=revision&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 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: 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: 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"
[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: [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"
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"
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: 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"
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 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 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"
