maintainer-feedback requested: [Bug 223937] [patch] sysutils/xfce4-wavelan-plugin fix memory leak due to CSS changes
J.R. Oldroyd has reassigned Bugzilla Automation 's request for maintainer-feedback to x...@freebsd.org: Bug 223937: [patch] sysutils/xfce4-wavelan-plugin fix memory leak due to CSS changes https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223937 --- Description --- Created attachment 188351 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=188351&action=edit patch to fix memory leak due to Gtk3 CSS changes The recent upstream changes to support Gtk3 CSS introduce a rampant memory leak because the css_provider is re-created every time through the loop. Attached patch ensures that the css_provider is only created once. I am attaching a FreeBSD port patch as this memory leak is significant and needs an immediate fix. I will also submit a bug report upstream in order to have this problem fixed there, too. ___ 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"
[Bug 223937] [patch] sysutils/xfce4-wavelan-plugin fix memory leak due to CSS changes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223937 Bug ID: 223937 Summary: [patch] sysutils/xfce4-wavelan-plugin fix memory leak due to CSS changes Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Keywords: patch Severity: Affects Many People Priority: --- Component: Individual Port(s) Assignee: x...@freebsd.org Reporter: f...@opal.com Keywords: patch Flags: maintainer-feedback?(x...@freebsd.org) Assignee: x...@freebsd.org Created attachment 188351 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=188351&action=edit patch to fix memory leak due to Gtk3 CSS changes The recent upstream changes to support Gtk3 CSS introduce a rampant memory leak because the css_provider is re-created every time through the loop. Attached patch ensures that the css_provider is only created once. I am attaching a FreeBSD port patch as this memory leak is significant and needs an immediate fix. I will also submit a bug report upstream in order to have this problem fixed there, too. -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 202192] [PATCH] x11-fm/thunar 1.6.11 change file permissions on sshfs mounted files/dirs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202192 --- Comment #4 from rozhuk...@gmail.com --- IMHO they dont try build without HAVE_GIO_UNIX: GDesktopAppInfo is part of gio and hey will get undefined struct/type compiler error. They patch does not work (without mine) - 100%. Upstream do many insane and crappy things, I dont want understand why :) I replace effective_user_id == g_file_info_get_attribute_uint32 (file->info, G_FILE_ATTRIBUTE_UNIX_UID) to thunar_file_is_writable(file) All other logic not changed, just refactored to human understanding. You can use both checks via ||, like: return (effective_user_id == g_file_info_get_attribute_uint32 (file->info, G_FILE_ATTRIBUTE_UNIX_UID) || thunar_file_is_writable(file)) May be in some cases there different access levels for file data and metadata and original code will return TRUE is user is file owner or root. I dont know what use cases this cover, probably none. My check is simple: if file writeable than we can write metadata. This is good for most cases. I dont know how to allow user write data and restrict write metadata in unix with chmod(). In my case sshfs mounted to me (simple user), by authorized on remote side as root. -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 223937] [patch] sysutils/xfce4-wavelan-plugin fix memory leak due to CSS changes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223937 Guido Falsi changed: What|Removed |Added Flags|maintainer-feedback?(xfce@F |maintainer-feedback+ |reeBSD.org) | Assignee|x...@freebsd.org|madpi...@freebsd.org CC||madpi...@freebsd.org Status|New |In Progress --- Comment #1 from Guido Falsi --- Hi, Thanks for the patch. Just to make sure I understand correctly, the "recent upstream changes" are in the GTK3 sources? Since you are sending this upstream too, could you followup with a link to the upstream bug so it can be tracked? It would allow avoiding to commit patches different from what is accepted upstream. In the while I'll also test it. -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 202192] [PATCH] x11-fm/thunar 1.6.11 change file permissions on sshfs mounted files/dirs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202192 --- Comment #5 from Guido Falsi --- (In reply to rozhuk.im from comment #4) > IMHO they dont try build without HAVE_GIO_UNIX: GDesktopAppInfo is part of > gio and hey will get undefined struct/type compiler error. > They patch does not work (without mine) - 100%. > > Upstream do many insane and crappy things, I dont want understand why :) First of all a general clarification: I can understand but keep in mind that ports are just that, portings. The development should happen upstream and bugfixes should go there where there are developers who know how the existing code works and also usually have better ability to test changes. This kind of changes which diverge from upstream tend to make maintain a port difficult and could also cause regressions which end up being unjustly reported upstream casting shadows on FreeBSD porting methods. I think you understand divergence with upstream should be kept to a minimum. So as a general rule I'm accepting such changes only if they are for very important bugs and have good chance of being merged upstream, or are very FreeBSD specific (which sometimes hinders upstream inclusion). For the GIO part, how do I test in the ports tree with GIO disabled? The port does not have such an option, so it looks like we don't cover this condition either. > > I replace > effective_user_id == g_file_info_get_attribute_uint32 (file->info, > G_FILE_ATTRIBUTE_UNIX_UID) > to > thunar_file_is_writable(file) > > All other logic not changed, just refactored to human understanding. > > You can use both checks via ||, like: > return (effective_user_id == g_file_info_get_attribute_uint32 (file->info, > G_FILE_ATTRIBUTE_UNIX_UID) || thunar_file_is_writable(file)) > > May be in some cases there different access levels for file data and > metadata and original code will return TRUE is user is file owner or root. > I dont know what use cases this cover, probably none. > > My check is simple: if file writeable than we can write metadata. > This is good for most cases. > I dont know how to allow user write data and restrict write metadata in unix > with chmod(). As I said while I hear and understand your explanation I have no explanation about the existing code. I'm not refusing your code, and have no specific objection about it. I just need time to understand it properly. In the while if you can get your code included upstream or at least reviewed by an upstream developer that would greatly help this request. > > In my case sshfs mounted to me (simple user), by authorized on remote side > as root. Not sure I understand, you mean that you are a plain user on the local machine but authenticated as root on the ssh mount on the remote one? -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 202192] [PATCH] x11-fm/thunar 1.6.11 change file permissions on sshfs mounted files/dirs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202192 Guido Falsi changed: What|Removed |Added Flags|maintainer-feedback?(xfce@F |maintainer-feedback+ |reeBSD.org) | -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 202192] [PATCH] x11-fm/thunar 1.6.11 change file permissions on sshfs mounted files/dirs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202192 --- Comment #6 from rozhuk...@gmail.com --- (In reply to Guido Falsi from comment #5) https://bugzilla.xfce.org/show_bug.cgi?id=12863 year+ - no activity in upstream, is there are life? Yes, our port does not have GIO option, I do tests by add to makefile GIO option and uncheck it. I dont know what I need to do with upstream, they do not react on bug tacker. Yes, I mean that Im plain user that have sshfs root@remote mount. PS: miss null check return (thunar_file_is_writable(file) || (NULL != file->info && effective_user_id == g_file_info_get_attribute_uint32 (file->info, G_FILE_ATTRIBUTE_UNIX_UID))) -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 202192] [PATCH] x11-fm/thunar 1.6.11 change file permissions on sshfs mounted files/dirs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202192 --- Comment #7 from Guido Falsi --- (In reply to rozhuk.im from comment #6) > (In reply to Guido Falsi from comment #5) > > https://bugzilla.xfce.org/show_bug.cgi?id=12863 > year+ - no activity in upstream, is there are life? This is irrelevant and in fact against your interest to point this out. If a patch is not accepted upstream maybe there are reasons for that. Also the fact the patch is not accepted upstream, even if accepting without question it to be good, is no reason to push it in FreeBSD. It could add unexpected effects. It will also make updating the port more difficult. The patched code could be modified upstream and the patch need reconciliation, or changes upstream can cause the patch to break. > > Yes, our port does not have GIO option, I do tests by add to makefile GIO > option and uncheck it. So the GIO case is irrelevant to our ports tree. No need to diverge to fix a problem that cannot happen. > > > I dont know what I need to do with upstream, they do not react on bug tacker. > While I understand your frustration I have no connection with the upstream. If you get your code accepted by upstream that is proof of a minimum quality of the change and also will mean thee code will anyway get in the ports tree, so there is no reason to hold the change. If you cannot some FreeBSD committer needs to test check and make a decision, this takes time. This is a volunteer project and no one is paid for it or working full time on port bugs. Things may require time. Please give me time to evaluate your code properly. This is a "port" of the upstream code not original code. Any divergence needs a good motivation. -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 202192] [PATCH] x11-fm/thunar 1.6.11 change file permissions on sshfs mounted files/dirs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202192 --- Comment #8 from Guido Falsi --- (In reply to rozhuk.im from comment #4) > My check is simple: if file writeable than we can write metadata. > This is good for most cases. > I dont know how to allow user write data and restrict write metadata in unix > with chmod(). Looking at the upstream code and checking how UFS works I can now say this is definitely a wrong assumption. you can chmod any file you own, even if it is not writable, otherwise there would be no way to modify permissions on a file with 0444 permissions. obviously root can change permissions on any file. The upstream code, while a little convoluted, checks just for this, which is correct for local file systems. > > In my case sshfs mounted to me (simple user), by authorized on remote side > as root. Considering the previous correction this use case is quite peculiar and difficult to accommodate. Thunar clearly checks file permissions based on the local user. But the remote user is different, so it gets wrong conclusions. But I cannot see a way to fix this except give thunar detailed knowledge of the specific remote file system and the actual remote user. Anyway your patch as is cannot be accepted since it is actually wrong for the UFS semantics. It will work most of the time but fail in important situations (files with 0444 permissions). Looks like for some specific sshfs semantics thunar_file_is_writable(file) returns true and lets you go ahead. But it looks like a coincidence. I need to find some information on why that checks gives a different result. The only acceptable option would be to add an || thunar_file_is_writable(file) right before the "&& !thunar_file_is_trashed (file));" in the last return in the upstream code. But I still have to evaluate the consequences. I need to study sshfs a little. Your suggeestion about adding an || -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 202192] [PATCH] x11-fm/thunar 1.6.11 change file permissions on sshfs mounted files/dirs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202192 Guido Falsi changed: What|Removed |Added Resolution|--- |Works As Intended Status|In Progress |Closed --- Comment #9 from Guido Falsi --- (In reply to Guido Falsi from comment #8) > (In reply to rozhuk.im from comment #4) > > > My check is simple: if file writeable than we can write metadata. > > This is good for most cases. > > I dont know how to allow user write data and restrict write metadata in unix > > with chmod(). > > Looking at the upstream code and checking how UFS works I can now say this > is definitely a wrong assumption. > > you can chmod any file you own, even if it is not writable, otherwise there > would be no way to modify permissions on a file with 0444 permissions. > obviously root can change permissions on any file. > > The upstream code, while a little convoluted, checks just for this, which is > correct for local file systems. > > > > > In my case sshfs mounted to me (simple user), by authorized on remote side > > as root. > > Considering the previous correction this use case is quite peculiar and > difficult to accommodate. > > Thunar clearly checks file permissions based on the local user. But the > remote user is different, so it gets wrong conclusions. But I cannot see a > way to fix this except give thunar detailed knowledge of the specific remote > file system and the actual remote user. > > Anyway your patch as is cannot be accepted since it is actually wrong for > the UFS semantics. It will work most of the time but fail in important > situations (files with 0444 permissions). > > Looks like for some specific sshfs semantics thunar_file_is_writable(file) > returns true and lets you go ahead. But it looks like a coincidence. I need > to find some information on why that checks gives a different result. > > The only acceptable option would be to add an || > thunar_file_is_writable(file) right before the "&& !thunar_file_is_trashed > (file));" in the last return in the upstream code. But I still have to > evaluate the consequences. This is wrong too. thunar_file_is_writable(file) could return true for files you don't own (think write bit on a group you are part of), so on which you can't change attributes. Checking for write permissions to change attributes is unrelated. I don't know a proper way to cater for a remote file system were you access as a different user...especially if that user is root and you are not root locally. If you find a solution please file a new bug report. -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
