Created attachment 427918 [details] gmrun-1.0.0.tar.xz I recently saw a buffer overflow in gmrun-0.9.2 After fixing it, I felt I need to port this to gtk3. I also fixed some other minor thing in the code.
Created attachment 427920 [details] gmrun-1.0.0.ebuild
Pushed to gitlab: https://gitlab.com/mazes_80/gmrun
Maybe you could proxy maintain this if desktop-misc people don't disagree :/
Created attachment 428546 [details] gmrun-1.0.0.ebuild Updated ebuild to point to freshly set up repository. Added vcs-snapshot to solve gitlab archive naming, as suggested in #575962 comment 3
Created attachment 429108 [details] gmrun-1.0.0.ebuild
unfortunately, there is still segfault... $ gmrun Segmentation fault $ echo $? 139 $ gdb gmrun Reading symbols from gmrun...(no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/gmrun [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7fffec008700 (LWP 4771)] [New Thread 0x7fffeb807700 (LWP 4772)] Thread 1 "gmrun" received signal SIGSEGV, Segmentation fault. 0x00007ffff6ff2ad0 in g_type_check_instance_cast () from /usr/lib64/libgobject-2.0.so.0 (gdb) bt #0 0x00007ffff6ff2ad0 in g_type_check_instance_cast () from /usr/lib64/libgobject-2.0.so.0 #1 0x0000555555559c4d in ?? () #2 0x00007ffff6307541 in __libc_start_main () from /lib64/libc.so.6 #3 0x000055555555a27a in ?? ()
Yes,
there is a segmentation fault, when compiling with pie. For now, I just use a -no-pie ugly workaround. I hope being able to fix this soon. Unfortunately, the error happens in some macro, so backtrace does not help a lot here. Custom widget may need more changes when migrating to gtk3, but I just did it "raw". A friend of mine also noticed the same behaviour in evince (under fedora for him), but is not yet able to reproduce the bug.
Created attachment 515316 [details] gmrun-1.0.0.ebuild Thanks, for your comment, as it incited me to have a look at this issue. debian bug #857065 pointed the exact same issue with the gtk2 only version of gmrun. They included some fedora patch to fix this. The fix in this version of the ebuild is pretty similar to what was suggested by the patch.
Created attachment 515318 [details] gmrun-9999.ebuild I also add a live ebuild (gtk3 deprecated functions removal).
live ebuild 9999 works like a charm! thank you :-)
(In reply to John Blbec from comment #11) > live ebuild 9999 works like a charm! thank you :-) Does the 1.0.0 new ebuild version also works ? Here it does (In reply to Pacho Ramos from comment #3) > Maybe you could proxy maintain this if desktop-misc people don't disagree :/ Yes, as I already maintain it for myself, i'm not against. Feedback incites me to solve issues, when I just use workaround when only for me. I also see #640018: some people still use this launcher, and bug can be closed if this bump is integrated.
(In reply to Samuel BAUER from comment #12) > (In reply to John Blbec from comment #11) > > live ebuild 9999 works like a charm! thank you :-) > > Does the 1.0.0 new ebuild version also works ? Here it does > 1.0.0 ebuild works great as well
Created attachment 516766 [details] gmrun-1.0.0.ebuild new EAPI defines sysconfdir = etc fix the 1.0.0 ebuild to install with sysconfir = datadir
it seems there is a problem with a configuration in ~/.gmrunrc which has lesser priority than the main one in /usr/share/gmrun/gmrunrc so user's configuration is ignored until you rename or delete the main one.
Created attachment 517084 [details] gmrun-1.0.1.ebuild Unlike <1.0.0 user configuration and history are now stored under ~/.config Or according your settings for XDG_CONFIG_DIR 1.0.1 removes url and extension handlers in config file, they're now managed through .desktop files and mimes.
Created attachment 517432 [details] gmrun-9999.ebuild
Created attachment 517434 [details] gmrun-1.0.1.ebuild
Created attachment 534874 [details] gmrun-1.0.2.ebuild
Created attachment 538038 [details] gmrun-1.0.2.ebuild Use tar.bz2 archive instead of tar.gz
Thank you for your contribution. I had a short look on the ebuild. Here a few ideas: • Please test the ebuild with repoman full -x https://wiki.gentoo.org/wiki/Repoman • We always try to use the latest EAPI, please bump to EAPI=7 https://dev.gentoo.org/~mgorny/articles/the-ultimate-guide-to-eapi-7.html • do not set KEYWORDS in the 9999 ebuild • KEYWORDS need ~ after a version bump run ekeyword ~all YOUREBUILD • please fix the header. (see /usr/portage/skel.ebuild and https://devmanual.gentoo.org/ebuild-writing/eapi/) • We usually sort the KEYWORDS as ekeywords does. This makes comparison between packages easier. Simply run ekeywords on the ebuild to let it sort. ewarn "Changes since gmrun-0.9.2:" ewarn "~/.gmrun_history moved to ~/.config/gmrun_history" ewarn "~/.gmrunrc moved to ~/.config/gmrunrc" ewarn "URL and extension handlers are now .desktop files" # I do not fully understand the following line. Please be more specific, what the # user needs to know here: ewarn "You may remove gmrun specific handlers in configuration file"
Created attachment 545716 [details] gmrun-1.0.2.ebuild repoman seems happy now (In reply to Jonas Stein from comment #21) > ewarn "URL and extension handlers are now .desktop files" > > # I do not fully understand the following line. Please be more specific, > what the > # user needs to know here: > ewarn "You may remove gmrun specific handlers in configuration file" Handlers management is now done via .desktop, so relics from custom handlers should be removed from configuration, I added "so" to the modified ebuild ewarn is easier to understand.
Created attachment 545718 [details] gmrun-9999.ebuild
Created attachment 545720 [details] metadata.xml
@Samuel Bauer: Thks for gmrun-1.0.2.ebuild which build and run fine here whereas gmrun-1.0.2 amd stable segfaults here. I can see this thread started quite a long time ago... I must have missed something.
Comment on attachment 545720 [details] metadata.xml --- a/x11-misc/gmrun/metadata.xml +++ b/x11-misc/gmrun/metadata.xml @@ -12,4 +12,8 @@ <upstream> <remote-id type="sourceforge">gmrun</remote-id> </upstream> + <use> + <flag name="gtk2">Use gtk+:2 instead of default gtk+:3</flag> + <flag name="popt">Use dev-libs/popt for parsing options</flag> + </use> </pkgmetadata>
desktop-misc would be glad, if you maintain this package.
There is another fork that is actually active. https://github.com/wdlkmpx/gmrun Just released a "1.0w" today.
(In reply to Henning Schild from comment #28) > There is another fork that is actually active. > https://github.com/wdlkmpx/gmrun > > Just released a "1.0w" today. Thanks I opened a ticket in their github project to notice them about my fork. I'll take a look at things they did, and how different we ported things. I also mentioned the thing about the buffer overflow in the history writer, but I don't remember exactly details as I did this port nearly 5 years ago.
I did not want to propose an ebuild and did not look into the fork-network recently. All i know is that at some point i came to the conclusion that this was the most active fork. The original seems dead, now the question is which is the best fork for gentoo to pick ... if any. But i use the tool on all my gentoo boxes and would even proxy maint if need be.
I still did not send updated metadata.xml to proxy maintain. The guy from the other fork seems more active than me (he works on gtk4 now), my repository is not very active, but not dead for sure. I still wonder which is the best choice as I didn't look at his code, but I know after some exchanges that he was aware of my repository and included some parts of my own work. If you want to carefully inspect diffs and proxy maint, it's also ok for me. Though I may be more competent to inspect changes as I know well this software.
Created attachment 697653 [details] metadata.xml
Created attachment 697656 [details] gmrun-9999.ebuild
Created attachment 697659 [details] gmrun-1.0.2.ebuild
(In reply to Jonas Stein from comment #27) > desktop-misc would be glad, if you maintain this package. Just updated the metadata.xml, I think that was the last needed step to proxy-maintain. (In reply to Henning Schild from comment #30) > All i know is that at some point i came to the conclusion that > this was the most active fork. > The original seems dead, now the question is which is the best fork for > gentoo to pick ... if any. wdlkmpx: exposes a very handy gtkcompat.h with ordered macros, better for maintainance and future upgrades. still suffers from various buffer overflows: one of them leads to the application not starting at all. I spent few hours comparing both repositories, trying to be partial on what's best for users. And for now I'm still not changing the uri for my proposed ebuild, keeping in mind there is also other issues in my repository
I may begin to use the https://github.com/wdlkmpx/gmrun but I need to patch it to allocate buffers instead of using some fixed size arrays, it turns out that was the main reason leading me to port things to gtk3. For some "performance" reason upstream doesn't want to allocate buffers. To avoid segfaults I encountered in the past I recommend them. If anybody else want to proxy-maintain using the active fork being aware of this restrictions, I'll be glad.
Hi, I tried attached 1.0.2 but it fails with below, no idea where patch is taken from it's not in the ebuild or attached here, maybe fetched from repo? >>> Preparing source in /var/tmp/portage/x11-misc/gmrun-1.0.2/work/gmrun-1.0.2 ... * Applying 0001-fix-segfault-in-gcc-6.patch ... can't find file to patch at input line 15
(In reply to mAhdi from comment #37) > Hi, I tried attached 1.0.2 but it fails with below, no idea where patch is > taken from it's not in the ebuild or attached here, maybe fetched from repo? > > >>> Preparing source in /var/tmp/portage/x11-misc/gmrun-1.0.2/work/gmrun-1.0.2 ... > * Applying 0001-fix-segfault-in-gcc-6.patch ... > can't find file to patch at input line 15 I think you got some patch under /etc/portage/patches/x11-misc/gmrun just try to: mv /etc/portage/patches/x11-misc/gmrun /etc/portage/patches/x11-misc/gmrun-0.9.2-r2 so you don't lose your local patchset for older versions, and prevent 1.0.2 to be patched.
Thanks compiled gtk3 version now and works, cheers :) Just one comment (and not sure you can do something about), as I'm running emerge as root config wasn't moved. After moving manually history works fine. Maybe iterate over all user accounts would be safer solution.
Created attachment 714777 [details] metadata.xml Updating metadata.xml was the last step to proxy-maint I guess. It took me long as I decided to use another fork, one I do not maintain, I had to inspect carefully
Created attachment 714780 [details] gmrun-1.2w.ebuild
Created attachment 714783 [details] gmrun-9999.ebuild
Created attachment 715302 [details] gmrun-9999.ebuild Update the ebuild to follow the build system
Created attachment 792560 [details] gmrun-9999.ebuild
Created attachment 792578 [details] gmrun-9999.ebuild
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fb7ab158478ebd19c76267608193e255c508b51a commit fb7ab158478ebd19c76267608193e255c508b51a Author: Henning Schild <henning@hennsch.de> AuthorDate: 2022-08-01 18:37:56 +0000 Commit: Piotr Karbowski <slashbeast@gentoo.org> CommitDate: 2022-08-29 19:14:20 +0000 x11-misc/gmrun: bump version to 1.4w Closes: https://bugs.gentoo.org/576992 Signed-off-by: Henning Schild <henning@hennsch.de> Closes: https://github.com/gentoo/gentoo/pull/26699 Signed-off-by: Piotr Karbowski <slashbeast@gentoo.org> x11-misc/gmrun/Manifest | 1 + x11-misc/gmrun/gmrun-1.4w.ebuild | 36 ++++++++++++++++++++++++++++++++++++ x11-misc/gmrun/metadata.xml | 5 ++++- 3 files changed, 41 insertions(+), 1 deletion(-)
