Re: [maintainer update] sysutils/vifm 0.12.1 -> 0.13
On Sun, Apr 09, 2023 at 08:43:24AM +0200, Rafael Sadowski wrote:
> On Wed Apr 05, 2023 at 05:47:51PM +, xaizek wrote:
> > Hello,
> >
> > Update package to the latest release.
> >
> > Icons are also installed to ${prefix}/share/icons/ now
> > (${prefix}/share/pixmaps isn't always looked in), but no corresponding
> > gtk tag is added because gtk is not a dependency.
>
> Hmm, usually we are not doing this. The standard way is to
> add @tag gtk-update-icon-cache %D/share/icons/hicolor and add
> the missing RDEP on x11/gtk+3,-guic BUT for CLI tools we actually don't
> do that because if you only want to use the pure CLI tool without any
> GUI you don't need GTK and the dependency chain.
>
> We should probably just not install the icons, right?
My bad, I skipped over @comment for pixmaps directory and thought that
one is installed. Updated the patch.
diff --git a/sysutils/vifm/Makefile b/sysutils/vifm/Makefile
index fd1e2e80b..c96a92cf8 100644
--- a/sysutils/vifm/Makefile
+++ b/sysutils/vifm/Makefile
@@ -1,5 +1,5 @@
COMMENT = ncurses file manager with Vim-like everything
-V = 0.12.1
+V =0.13
DISTNAME = vifm-${V}
CATEGORIES = sysutils
HOMEPAGE = https://vifm.info/
diff --git a/sysutils/vifm/distinfo b/sysutils/vifm/distinfo
index 4cace9ddb..ecd2cc206 100644
--- a/sysutils/vifm/distinfo
+++ b/sysutils/vifm/distinfo
@@ -1,2 +1,2 @@
-SHA256 (vifm-0.12.1.tar.bz2) = j+KBPr3Mz+ma7OArBdYqIJkVJdRrDM+67Dr2FMZlVog=
-SIZE (vifm-0.12.1.tar.bz2) = 1510709
+SHA256 (vifm-0.13.tar.bz2) = DZKTdJp5QHat6Wfs3EfRQdheRQNwWUdlORvfGpvUUHU=
+SIZE (vifm-0.13.tar.bz2) = 1546673
diff --git a/sysutils/vifm/pkg/PLIST b/sysutils/vifm/pkg/PLIST
index 8cc9861e8..5f0f2e049 100644
--- a/sysutils/vifm/pkg/PLIST
+++ b/sysutils/vifm/pkg/PLIST
@@ -16,6 +16,7 @@ share/doc/vifm/AUTHORS
share/doc/vifm/BUGS
share/doc/vifm/COPYING
share/doc/vifm/ChangeLog
+share/doc/vifm/ChangeLog.LuaAPI
share/doc/vifm/FAQ
share/doc/vifm/INSTALL
share/doc/vifm/NEWS
@@ -24,6 +25,14 @@ share/doc/vifm/TODO
share/fish/
share/fish/vendor_completions.d/
share/fish/vendor_completions.d/vifm.fish
+@comment share/icons/
+@comment share/icons/hicolor/
+@comment share/icons/hicolor/128x128/
+@comment share/icons/hicolor/128x128/apps/
+@comment share/icons/hicolor/128x128/apps/vifm.png
+@comment share/icons/hicolor/scalable/
+@comment share/icons/hicolor/scalable/apps/
+@comment share/icons/hicolor/scalable/apps/vifm.svg
@comment share/pixmaps/
@comment share/pixmaps/vifm.png
share/vifm/
Re: [maintainer update] sysutils/vifm 0.12.1 -> 0.13
On Wed Apr 05, 2023 at 05:47:51PM +, xaizek wrote:
> Hello,
>
> Update package to the latest release.
>
> Icons are also installed to ${prefix}/share/icons/ now
> (${prefix}/share/pixmaps isn't always looked in), but no corresponding
> gtk tag is added because gtk is not a dependency.
Hmm, usually we are not doing this. The standard way is to
add @tag gtk-update-icon-cache %D/share/icons/hicolor and add
the missing RDEP on x11/gtk+3,-guic BUT for CLI tools we actually don't
do that because if you only want to use the pure CLI tool without any
GUI you don't need GTK and the dependency chain.
We should probably just not install the icons, right?
>
> Best regards,
> xaizek
> diff --git a/sysutils/vifm/Makefile b/sysutils/vifm/Makefile
> index fd1e2e80b..c96a92cf8 100644
> --- a/sysutils/vifm/Makefile
> +++ b/sysutils/vifm/Makefile
> @@ -1,5 +1,5 @@
> COMMENT =ncurses file manager with Vim-like everything
> -V = 0.12.1
> +V = 0.13
> DISTNAME = vifm-${V}
> CATEGORIES = sysutils
> HOMEPAGE = https://vifm.info/
> diff --git a/sysutils/vifm/distinfo b/sysutils/vifm/distinfo
> index 4cace9ddb..ecd2cc206 100644
> --- a/sysutils/vifm/distinfo
> +++ b/sysutils/vifm/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (vifm-0.12.1.tar.bz2) = j+KBPr3Mz+ma7OArBdYqIJkVJdRrDM+67Dr2FMZlVog=
> -SIZE (vifm-0.12.1.tar.bz2) = 1510709
> +SHA256 (vifm-0.13.tar.bz2) = DZKTdJp5QHat6Wfs3EfRQdheRQNwWUdlORvfGpvUUHU=
> +SIZE (vifm-0.13.tar.bz2) = 1546673
> diff --git a/sysutils/vifm/pkg/PLIST b/sysutils/vifm/pkg/PLIST
> index 8cc9861e8..da1acd006 100644
> --- a/sysutils/vifm/pkg/PLIST
> +++ b/sysutils/vifm/pkg/PLIST
> @@ -16,6 +16,7 @@ share/doc/vifm/AUTHORS
> share/doc/vifm/BUGS
> share/doc/vifm/COPYING
> share/doc/vifm/ChangeLog
> +share/doc/vifm/ChangeLog.LuaAPI
> share/doc/vifm/FAQ
> share/doc/vifm/INSTALL
> share/doc/vifm/NEWS
> @@ -24,6 +25,14 @@ share/doc/vifm/TODO
> share/fish/
> share/fish/vendor_completions.d/
> share/fish/vendor_completions.d/vifm.fish
> +share/icons/
> +share/icons/hicolor/
> +share/icons/hicolor/128x128/
> +share/icons/hicolor/128x128/apps/
> +share/icons/hicolor/128x128/apps/vifm.png
> +share/icons/hicolor/scalable/
> +share/icons/hicolor/scalable/apps/
> +share/icons/hicolor/scalable/apps/vifm.svg
> @comment share/pixmaps/
> @comment share/pixmaps/vifm.png
> share/vifm/
[maintainer update] sysutils/vifm 0.12.1 -> 0.13
Hello,
Update package to the latest release.
Icons are also installed to ${prefix}/share/icons/ now
(${prefix}/share/pixmaps isn't always looked in), but no corresponding
gtk tag is added because gtk is not a dependency.
Best regards,
xaizek
diff --git a/sysutils/vifm/Makefile b/sysutils/vifm/Makefile
index fd1e2e80b..c96a92cf8 100644
--- a/sysutils/vifm/Makefile
+++ b/sysutils/vifm/Makefile
@@ -1,5 +1,5 @@
COMMENT = ncurses file manager with Vim-like everything
-V =0.12.1
+V =0.13
DISTNAME = vifm-${V}
CATEGORIES = sysutils
HOMEPAGE = https://vifm.info/
diff --git a/sysutils/vifm/distinfo b/sysutils/vifm/distinfo
index 4cace9ddb..ecd2cc206 100644
--- a/sysutils/vifm/distinfo
+++ b/sysutils/vifm/distinfo
@@ -1,2 +1,2 @@
-SHA256 (vifm-0.12.1.tar.bz2) = j+KBPr3Mz+ma7OArBdYqIJkVJdRrDM+67Dr2FMZlVog=
-SIZE (vifm-0.12.1.tar.bz2) = 1510709
+SHA256 (vifm-0.13.tar.bz2) = DZKTdJp5QHat6Wfs3EfRQdheRQNwWUdlORvfGpvUUHU=
+SIZE (vifm-0.13.tar.bz2) = 1546673
diff --git a/sysutils/vifm/pkg/PLIST b/sysutils/vifm/pkg/PLIST
index 8cc9861e8..da1acd006 100644
--- a/sysutils/vifm/pkg/PLIST
+++ b/sysutils/vifm/pkg/PLIST
@@ -16,6 +16,7 @@ share/doc/vifm/AUTHORS
share/doc/vifm/BUGS
share/doc/vifm/COPYING
share/doc/vifm/ChangeLog
+share/doc/vifm/ChangeLog.LuaAPI
share/doc/vifm/FAQ
share/doc/vifm/INSTALL
share/doc/vifm/NEWS
@@ -24,6 +25,14 @@ share/doc/vifm/TODO
share/fish/
share/fish/vendor_completions.d/
share/fish/vendor_completions.d/vifm.fish
+share/icons/
+share/icons/hicolor/
+share/icons/hicolor/128x128/
+share/icons/hicolor/128x128/apps/
+share/icons/hicolor/128x128/apps/vifm.png
+share/icons/hicolor/scalable/
+share/icons/hicolor/scalable/apps/
+share/icons/hicolor/scalable/apps/vifm.svg
@comment share/pixmaps/
@comment share/pixmaps/vifm.png
share/vifm/
[update] sysutils/vifm to 0.12.1
Hello,
New version is out with all OpenBSD patches incorporated into it. Apart
from removing them, the changes are:
* version bump
* distinfo update
* addition of fish shell completion files to PLIST
Also several compilation warnings are gone, none of them indicated any kind
of issue, so there were no patches for them before.
Best regards,
xaizek
Index: Makefile
===
RCS file: /cvs/ports/sysutils/vifm/Makefile,v
retrieving revision 1.4
diff -u -p -u -r1.4 Makefile
--- Makefile27 Aug 2022 16:28:16 - 1.4
+++ Makefile22 Sep 2022 10:46:06 -
@@ -1,5 +1,5 @@
COMMENT = ncurses file manager with Vim-like everything
-V =0.12
+V =0.12.1
DISTNAME = vifm-${V}
CATEGORIES = sysutils
HOMEPAGE = https://vifm.info/
Index: distinfo
===
RCS file: /cvs/ports/sysutils/vifm/distinfo,v
retrieving revision 1.4
diff -u -p -u -r1.4 distinfo
--- distinfo27 Aug 2022 16:28:16 - 1.4
+++ distinfo22 Sep 2022 10:46:06 -
@@ -1,2 +1,2 @@
-SHA256 (vifm-0.12.tar.bz2) = M6lhjzKzW1uMZEg4hPmtCZY8qEZbKTXe95FZAo4nssA=
-SIZE (vifm-0.12.tar.bz2) = 1426579
+SHA256 (vifm-0.12.1.tar.bz2) = j+KBPr3Mz+ma7OArBdYqIJkVJdRrDM+67Dr2FMZlVog=
+SIZE (vifm-0.12.1.tar.bz2) = 1510709
Index: patches/patch-src_Makefile_in
===
RCS file: patches/patch-src_Makefile_in
diff -N patches/patch-src_Makefile_in
--- patches/patch-src_Makefile_in 27 Aug 2022 16:28:16 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,24 +0,0 @@
-1. Install Default-256.vifm with other sample color schemes.
-2. Port system exports CFLAGS and LDFLAGS which breaks tests.
-
-Index: src/Makefile.in
src/Makefile.in.orig
-+++ src/Makefile.in
-@@ -628,7 +628,8 @@ dist_sample_colors__DATA = ../data/colors/astrell-root
-
../data/colors/dmilith-user.vifm \
-
../data/colors/istib-solarized-dark.vifm \
-
../data/colors/juef-zenburn.vifm \
--
../data/colors/reicheltd-light.vifm
-+
../data/colors/reicheltd-light.vifm \
-+
../data/colors/Default-256.vifm
-
- dist_vim_doc__DATA = ../data/vim/doc/plugin/vifm-plugin.txt
- nodist_vim_doc__DATA = $(abs_srcdir)/../data/vim/doc/plugin/tags
-@@ -2599,6 +2600,7 @@ clean-local:
-
- runtests:
- echo 'mkdir -p $(abs_builddir)/../tests/' > $@_
-+ echo 'unset CFLAGS LDFLAGS' > $@_
- echo \
- '$(MAKE) -C $(abs_srcdir)/../tests B=$(abs_builddir)/../tests/
CC="$(CC)"' \
- >> $@_
Index: patches/patch-src_compat_curses_c
===
RCS file: patches/patch-src_compat_curses_c
diff -N patches/patch-src_compat_curses_c
--- patches/patch-src_compat_curses_c 27 Aug 2022 16:28:16 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,23 +0,0 @@
-Disable old workaround for curses on OpenBSD.
-
-Index: src/compat/curses.c
src/compat/curses.c.orig
-+++ src/compat/curses.c
-@@ -16,7 +16,7 @@
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
USA
- */
-
--#ifdef __OpenBSD__
-+#ifdef FAKE_NCURSESW
-
- #include "curses.h"
-
-@@ -31,7 +31,7 @@ int
- compat_wget_wch(WINDOW *w, wint_t *wc)
- {
- *wc = wgetch(w);
-- return ((char)*wc == ERR) ? ERR : OK;
-+ return ((char)*wc == ERR) ? ERR : (*wc >= KEY_MIN ? KEY_CODE_YES : OK);
- }
-
- int
Index: patches/patch-src_compat_curses_h
===
RCS file: patches/patch-src_compat_curses_h
diff -N patches/patch-src_compat_curses_h
--- patches/patch-src_compat_curses_h 27 Aug 2022 16:28:16 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,21 +0,0 @@
-Disable old workaround for curses on OpenBSD.
-
-Index: src/compat/curses.h
src/compat/curses.h.orig
-+++ src/compat/curses.h
-@@ -31,11 +31,11 @@
- * for implementation as it needs more than just wchar_t.) */
- #define K(x) ((wchar_t)((wint_t)0xe000 + 1 + (x)))
-
--/* OpenBSD has perverted ncurses library, which has stubs with infinite loops
-- * instead of real wide functions. As there is only a couple of wide
functions
-- * in use, they can be emulated. */
-+/* In the past OpenBSD has perverted ncurses library, which had stubs with
-+ * infinite loops instead of real wide functions. As there is only a couple
of
-+ * wide functions in use, t
Re: [new] sysutils/vifm
On 2022/08/27 15:34, xaizek wrote: > On Sat, Aug 27, 2022 at 03:08:09PM +0100, Stuart Henderson wrote: > > I think it makes sense to add it back. > > Great. > > > Comments on the port: > > - we don't use subpackages just for desktop files and dependencies > > Something in manpages/guide made me think otherwise, but I can't find it > now. Dropped that part. > > > - there are some checks in configure for various tools (groff, vim, git) - > > everything from packages that affects the build needs to be listed as a > > dependency or disabled (e.g. for groff/mandoc the right way is probably > > to set MANGEN_PROG=mandoc, for vim it looks like maybe nothing is needed > > because unless I missed something perl is used in preference, and perl > > is always available in base) > > MANGEN_PROG=mandoc works and ignores installed groff. > > Yes, Vim is used to generate tags only if perl isn't available. > > Git is used to get tag & commit revision if build happens inside of a > repository. If there is no .git directory, presence of git makes no > difference. > > Other standard tools (awk, sed, col) are used to process output of > groff/mandoc if they are available. Thanks. I've readded it with small tweaks; - add the pixmap/desktop file entries to pkg/PLIST with @comment, so that future regen's won't pick them up - drop TEST_DEPENDS, it's implied by USE_GMAKE
Re: [new] sysutils/vifm
On Sat, Aug 27, 2022 at 03:08:09PM +0100, Stuart Henderson wrote: > I think it makes sense to add it back. Great. > Comments on the port: > - we don't use subpackages just for desktop files and dependencies Something in manpages/guide made me think otherwise, but I can't find it now. Dropped that part. > - there are some checks in configure for various tools (groff, vim, git) - > everything from packages that affects the build needs to be listed as a > dependency or disabled (e.g. for groff/mandoc the right way is probably > to set MANGEN_PROG=mandoc, for vim it looks like maybe nothing is needed > because unless I missed something perl is used in preference, and perl > is always available in base) MANGEN_PROG=mandoc works and ignores installed groff. Yes, Vim is used to generate tags only if perl isn't available. Git is used to get tag & commit revision if build happens inside of a repository. If there is no .git directory, presence of git makes no difference. Other standard tools (awk, sed, col) are used to process output of groff/mandoc if they are available. > On 2022/08/27 11:13, xaizek wrote: > > Hello, > > > > As far as I know port for Vifm was included once, got removed and then > > there was one failed attempt to add it back. There seems to be some > > interest in having it, and in particular I've received a request for a > > port as Vifm's maintainer, so I decided to give it a try after using > > OpenBSD for a bit for other reasons. > > > > I originally declined making a port because I'm not using OpenBSD, > > but I can run it in a VM for tests and filter out all emails from this > > list that don't mention "vifm" to keep an eye on the port. Although > > ideally, if this gets accepted, some OpenBSD & Vifm user could take over > > the port and just ask me for assistance in case of issues. > > > > This is a multi-package port. -main doesn't depend on any other port, > > except during build. -desktop provides .desktop file with a > > corresponding pixmap and depends on devel/desktop-file-utils. Tests > > pass. /etc is handled via @sample. There is a number of patches, but > > they should all be gone for the next release. > > > > pkg/DESCR-main: > > > > Vifm is a file manager with curses interface, which provides Vim-like > > environment for managing objects within file systems, extended with some > > useful ideas from mutt. If you use vi, Vifm gives you complete keyboard > > control over your files without having to learn a new set of commands. > > > > Install vifm-desktop pakcage for desktop integration. > > > > pkg/DESCR-desktop: > > > > This package adds .desktop-file of Vifm. > > > > Best regards, > > xaizek sysutils.tar.bz2 Description: Binary data
Re: [new] sysutils/vifm
I think it makes sense to add it back. Comments on the port: - we don't use subpackages just for desktop files and dependencies - there are some checks in configure for various tools (groff, vim, git) - everything from packages that affects the build needs to be listed as a dependency or disabled (e.g. for groff/mandoc the right way is probably to set MANGEN_PROG=mandoc, for vim it looks like maybe nothing is needed because unless I missed something perl is used in preference, and perl is always available in base) On 2022/08/27 11:13, xaizek wrote: > Hello, > > As far as I know port for Vifm was included once, got removed and then > there was one failed attempt to add it back. There seems to be some > interest in having it, and in particular I've received a request for a > port as Vifm's maintainer, so I decided to give it a try after using > OpenBSD for a bit for other reasons. > > I originally declined making a port because I'm not using OpenBSD, > but I can run it in a VM for tests and filter out all emails from this > list that don't mention "vifm" to keep an eye on the port. Although > ideally, if this gets accepted, some OpenBSD & Vifm user could take over > the port and just ask me for assistance in case of issues. > > This is a multi-package port. -main doesn't depend on any other port, > except during build. -desktop provides .desktop file with a > corresponding pixmap and depends on devel/desktop-file-utils. Tests > pass. /etc is handled via @sample. There is a number of patches, but > they should all be gone for the next release. > > pkg/DESCR-main: > > Vifm is a file manager with curses interface, which provides Vim-like > environment for managing objects within file systems, extended with some > useful ideas from mutt. If you use vi, Vifm gives you complete keyboard > control over your files without having to learn a new set of commands. > > Install vifm-desktop pakcage for desktop integration. > > pkg/DESCR-desktop: > > This package adds .desktop-file of Vifm. > > Best regards, > xaizek
[new] sysutils/vifm
Hello, As far as I know port for Vifm was included once, got removed and then there was one failed attempt to add it back. There seems to be some interest in having it, and in particular I've received a request for a port as Vifm's maintainer, so I decided to give it a try after using OpenBSD for a bit for other reasons. I originally declined making a port because I'm not using OpenBSD, but I can run it in a VM for tests and filter out all emails from this list that don't mention "vifm" to keep an eye on the port. Although ideally, if this gets accepted, some OpenBSD & Vifm user could take over the port and just ask me for assistance in case of issues. This is a multi-package port. -main doesn't depend on any other port, except during build. -desktop provides .desktop file with a corresponding pixmap and depends on devel/desktop-file-utils. Tests pass. /etc is handled via @sample. There is a number of patches, but they should all be gone for the next release. pkg/DESCR-main: Vifm is a file manager with curses interface, which provides Vim-like environment for managing objects within file systems, extended with some useful ideas from mutt. If you use vi, Vifm gives you complete keyboard control over your files without having to learn a new set of commands. Install vifm-desktop pakcage for desktop integration. pkg/DESCR-desktop: This package adds .desktop-file of Vifm. Best regards, xaizek vifm.tar.bz2 Description: Binary data
Re: NEW: sysutils/vifm
BTW, if anyone plans on committing vifm, be aware that there's a quirks entry from when it was last in the tree, and you will probably want to do 'cvs add's rather than 'cvs import' to avoid having to deal with merge conflicts.
Re: NEW: sysutils/vifm
Dmitrij D. Czarkoff said: > Here is a tarball with another attempt at vifm port: > > - uses waitpid(2) to reap spawned processes > - in mime detection code uses pledge(2) + libmagic(3) as first choice >and execl(3) + file(1) as second > - same in filetype detection (in previous ports was just popen(3)) > - does nothing to one remaining popen(3) and multiple system(3) calls. > - gets rid of FLAVORs > > If someone wants to replace remaining popen(3) and system(3), useful > egrep pattern is "(os|vifm)_system". I have better things to do. > > Please, don't mistake this message for implicit OK. A couple of bug fixes... -- Dmitrij D. Czarkoff vifm-0.8.1a.tgz Description: application/tar-gz
Re: NEW: sysutils/vifm
Stuart Henderson said:
> > - in mime detection code uses pledge(2) + libmagic(3) as first choice
> >and execl(3) + file(1) as second
>
> er, we were trying to get rid of libmagic use...
As I see it, we are trying to solve security issues related to the fact
that libmagic may be tricked into executing code from inspected file.
The solution, as discussed earlier, was to use file(1) with its own
parser of magic database. That said, it was observed that libmagic
gives better results then our file(1) with our magic database. Thus
previous approach was to split the ports into two flavors: secure
(file(1) only) and usable (libmagic).
This diff puts libmagic-interfacing code into subprocess with
pledge("stdio rpath"), so that libmagic can't harm user in meaningful
way. If it tries to do something funny, it gets killed, and
execl("/usr/bin/file", ...) is used instead. I think this way users are
served better then with either of ports above.
--
Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
On 2016/06/12 11:03, Dmitrij D. Czarkoff wrote: > Here is a tarball with another attempt at vifm port: > > - uses waitpid(2) to reap spawned processes > - in mime detection code uses pledge(2) + libmagic(3) as first choice >and execl(3) + file(1) as second er, we were trying to get rid of libmagic use... > - same in filetype detection (in previous ports was just popen(3)) > - does nothing to one remaining popen(3) and multiple system(3) calls. > - gets rid of FLAVORs > > If someone wants to replace remaining popen(3) and system(3), useful > egrep pattern is "(os|vifm)_system". I have better things to do. > > Please, don't mistake this message for implicit OK. > > -- > Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
Here is a tarball with another attempt at vifm port: - uses waitpid(2) to reap spawned processes - in mime detection code uses pledge(2) + libmagic(3) as first choice and execl(3) + file(1) as second - same in filetype detection (in previous ports was just popen(3)) - does nothing to one remaining popen(3) and multiple system(3) calls. - gets rid of FLAVORs If someone wants to replace remaining popen(3) and system(3), useful egrep pattern is "(os|vifm)_system". I have better things to do. Please, don't mistake this message for implicit OK. -- Dmitrij D. Czarkoff vifm-0.8.1a.tgz Description: application/tar-gz
Re: NEW: sysutils/vifm
Rafael Sadowski said:
> here is a third and last try to push vifm in ports tree.
Now that we have pledge(2), it would probably be a better idea to use
libmagic with fork+pledge.
| + /* replace single quotes with double */
| + if (strchr(filename, '\''))
| {
| - return -1;
| + qp = quoted_filename;
| +
| + do {
| + if (*filename == '\'')
| + *qp++ = '\\';
| + *qp++ = *filename;
| + } while (*filename++ != '\0');
| +
| + filename = quoted_filename;
| }
This is not needed. And even if it was, comment should have been
different.
| + switch (fork())
| {
| - pclose(pipe);
| - return -1;
| + case -1:
| + printf("ERROR: forking child process failed\n");
| + return -1;
| + case 0:
| + dup2 (pipes[1], STDOUT_FILENO);
| + close(pipes[0]);
| + close(pipes[1]);
| + /* Use the file command to get mimetype */
| + execl("/usr/bin/file", "file", "-b", "--mime-type",
filename);
| + exit(0);
| + default:
| + close(pipes[1]);
| + (void)read(pipes[0], buf, buf_sz);
Shouldn't the parent process wait(2) for child?
--
Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
On 2016/06/09 20:39, Landry Breuil wrote: > So, fwiw, the attached version is ok for me to import - stuff can still > be fixed in-tree if more issues arise. Let's stop the bikeshedding, and > thank Rafael for his perseverance. Kill the patch.orig and OK with me. Though the desktop-file-utils dep for no_x11 is pretty horrible, I think that should be made conditional and move the @exec to a PFRAG, but that could be done after it's in..
Re: NEW: sysutils/vifm
On Wed, Jun 08, 2016 at 11:00:21PM +0200, Rafael Sadowski wrote: > On Wed Jun 08, 2016 at 09:34:50PM +0200, Landry Breuil wrote: > > On Tue, Jun 07, 2016 at 09:28:37PM +0200, Rafael Sadowski wrote: > > > Hi ports@ and vifm friends, > > > > > > here is a third and last try to push vifm in ports tree. > > > > > > port core features: > > > - The same as: http://marc.info/?l=openbsd-ports=145647165914163=2 > > > - new: remove popen(2) call and replace with fork(2)(execl(3) > > > > > > pkg/DESCR: > > > > > > Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, > > > vifm gives you complete keyboard control over your files without having > > > to learn a new set of commands. It goes not just about vi[m] like > > > keybindings, but also about modes, options, registers, commands and > > > other things you might already like in vi[m]. > > > > > > OK, Comments? > > > > Has all the failure/risky cases that were reported in the last thread > > tested/taken care of now ? > > > > Landry > > Of course, I fixed all failure/risky cases and yes I tested it well. I > would have thought that was patently obvious. I'll send fork/execl > replacement patch upstream. Here's a slightly modified version of your patch to fix warnings: /usr/obj/tmpfs/ports/vifm-0.8.1a/vifm-0.8.1a/src/int/file_magic.c:181: warning: missing sentinel in function call /usr/obj/tmpfs/ports/vifm-0.8.1a/vifm-0.8.1a/src/int/file_magic.c:182: warning: implicit declaration of function 'exit' /usr/obj/tmpfs/ports/vifm-0.8.1a/vifm-0.8.1a/src/int/file_magic.c:182: warning: incompatible implicit declaration of built-in function 'exit' - include stdlib.h for exit() - remove unused char command declaration - add NULL sentinel as last arg of execl() I've tested it a bit, with a file named "echo 'foo' > bar" in /tmp, no ill effect. But that was with the default gtk backend, and it allows me to open the file in mousepad fine. With the no_x11 FLAVOR, it 'does the right thing' afaict. 30832 vifm ARGS [0] = "file" [1] = "-b" [2] = "--mime-type" [3] = "/tmp/echo \\'foo\\' > bar" And via enter, opens the file in vim. 61442 vifm ARGS [0] = "/bin/ksh" [1] = "-c" [2] = "vim /tmp/echo\\ \\'foo\\'\\ \\>\\ bar" 66333 ksh ARGS [0] = "vim" [1] = "/tmp/echo 'foo' > bar" Tested slightly with jpg and mp4 files, mimetype seems correctly found, i still have 'less' options to open the file than with the default flavor (check :f) but that's expected. So, fwiw, the attached version is ok for me to import - stuff can still be fixed in-tree if more issues arise. Let's stop the bikeshedding, and thank Rafael for his perseverance. Landry vifm2.tgz Description: application/tar-gz
Re: NEW: sysutils/vifm
On Wed Jun 08, 2016 at 09:34:50PM +0200, Landry Breuil wrote: > On Tue, Jun 07, 2016 at 09:28:37PM +0200, Rafael Sadowski wrote: > > Hi ports@ and vifm friends, > > > > here is a third and last try to push vifm in ports tree. > > > > port core features: > > - The same as: http://marc.info/?l=openbsd-ports=145647165914163=2 > > - new: remove popen(2) call and replace with fork(2)(execl(3) > > > > pkg/DESCR: > > > > Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, > > vifm gives you complete keyboard control over your files without having > > to learn a new set of commands. It goes not just about vi[m] like > > keybindings, but also about modes, options, registers, commands and > > other things you might already like in vi[m]. > > > > OK, Comments? > > Has all the failure/risky cases that were reported in the last thread > tested/taken care of now ? > > Landry Of course, I fixed all failure/risky cases and yes I tested it well. I would have thought that was patently obvious. I'll send fork/execl replacement patch upstream. Rafael
Re: NEW: sysutils/vifm
On Tue, Jun 07, 2016 at 09:28:37PM +0200, Rafael Sadowski wrote: > Hi ports@ and vifm friends, > > here is a third and last try to push vifm in ports tree. > > port core features: > - The same as: http://marc.info/?l=openbsd-ports=145647165914163=2 > - new: remove popen(2) call and replace with fork(2)(execl(3) > > pkg/DESCR: > > Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, > vifm gives you complete keyboard control over your files without having > to learn a new set of commands. It goes not just about vi[m] like > keybindings, but also about modes, options, registers, commands and > other things you might already like in vi[m]. > > OK, Comments? Has all the failure/risky cases that were reported in the last thread tested/taken care of now ? Landry
Re: NEW: sysutils/vifm
Am 07.06.2016 21:28:37, schrieb Rafael Sadowski: > Hi ports@ and vifm friends, > > here is a third and last try to push vifm in ports tree. > > port core features: > - The same as: > http://marc.info/?l=openbsd-ports=145647165914163=2 > - new: remove popen(2) call and replace with fork(2)(execl(3) > > pkg/DESCR: > > Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, > vifm gives you complete keyboard control over your files without having > to learn a new set of commands. It goes not just about vi[m] like > keybindings, but also about modes, options, registers, commands and > other things you might already like in vi[m]. > > OK, Comments? > > Best regards, > > Rafael Dear Rafael, I'd like to see it in the ports tree. Many thanks and regards. Uwe
NEW: sysutils/vifm
Hi ports@ and vifm friends, here is a third and last try to push vifm in ports tree. port core features: - The same as: http://marc.info/?l=openbsd-ports=145647165914163=2 - new: remove popen(2) call and replace with fork(2)(execl(3) pkg/DESCR: Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, vifm gives you complete keyboard control over your files without having to learn a new set of commands. It goes not just about vi[m] like keybindings, but also about modes, options, registers, commands and other things you might already like in vi[m]. OK, Comments? Best regards, Rafael vifm.tar.gz Description: application/tar-gz
Re: NEW: sysutils/vifm
Rafael Sadowski said:
> - czarkoff@'s file(1)-based mime type detection patch.
My patch was actually bad. It does not fix vulnerability it is supposed
to fix.
| + if (strchr(filename, '\''))
| + {
| + qp = quoted_filename;
| +
| + do {
| + if (*filename == '\'')
| + *qp++ = '\\';
| + *qp++ = *filename;
| + } while (*filename++ != '\0');
| +
| + filename = quoted_filename;
| + }
| +
For some reason I thought that backslash-escaping single quotes inside
single-quoted string in shell will help. It won't. Eg. filename
'$(rm -R ~)
will cause all the due damage.
The quoting part can be improved to replace every single quote with
'\"'
but I am not sure whether it will solve all the problems. It would make
most sense to switching code from popen(3) to fork(2)+exec(3) instead.
> - add "no_x11" flavor (from czarkoff@).
> -- no_x11 flavor comes with 3 wantlibs ;)
Once "file" backend is fixed, there would be no need in flavors any more
I believe.
--
Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
On Fri Feb 26, 2016 at 08:26:47AM +0100, Rafael Sadowski wrote: > hey @ports and vifm friends, > > here is a second try to push vifm in ports tree. > > port core features: > > - default build without libmagic > - czarkoff@'s file(1)-based mime type detection patch. > -- I'll pull request upstream with czarkoff's okay. > - add "no_x11" flavor (from czarkoff@). > -- no_x11 flavor comes with 3 wantlibs ;) > - 0.8.1a update. > > tested @amd64. Many thanks to czarkoff from some good advice. > > pkg/DESCR: > > Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, > vifm gives you complete keyboard control over your files without having > to learn a new set of commands. It goes not just about vi[m] like > keybindings, but also about modes, options, registers, commands and other > things you might already like in vi[m]. > > Best regards, > > Rafael *ping* >From no one okay after the wild discussion[1]? [1]: https://marc.info/?l=openbsd-ports=145400156405000=2
NEW: sysutils/vifm
hey @ports and vifm friends, here is a second try to push vifm in ports tree. port core features: - default build without libmagic - czarkoff@'s file(1)-based mime type detection patch. -- I'll pull request upstream with czarkoff's okay. - add "no_x11" flavor (from czarkoff@). -- no_x11 flavor comes with 3 wantlibs ;) - 0.8.1a update. tested @amd64. Many thanks to czarkoff from some good advice. pkg/DESCR: Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, vifm gives you complete keyboard control over your files without having to learn a new set of commands. It goes not just about vi[m] like keybindings, but also about modes, options, registers, commands and other things you might already like in vi[m]. Best regards, Rafael vifm.tar.gz Description: application/tar-gz
Re: NEW: sysutils/vifm
Landry Breuil said: > On Wed, Feb 03, 2016 at 12:42:34AM +0100, Dmitrij D. Czarkoff wrote: > > Stuart Henderson said: > > > On 2016/02/03 00:25, Dmitrij D. Czarkoff wrote: > > > > Stuart Henderson said: > > > > > On 2016/02/02 21:58, Landry Breuil wrote: > > > > > > Oh, and the code in src/int/file_magic.c even has a fallback to use > > > > > > file > > > > > > %s -b --mime-type called via popen().. > > > > > > > > > > It would be nice to kill the other options and use file(1) from base > > > > > as the only detection method, it is *loads* safer. > > > > > > > > Well, the actual code is: > > > > > > > > | snprintf(command, sizeof(command), "file \"%s\" -b --mime-type", > > > > filename); > > > > > > > > Note double quotes. Of course no quoting is performed on filename. > > > > Thus: > > > > > > > > 1. If filename contains double quote, vifm sigfaults. > > > > 2. If filename is nasty, nasty things happen. Eg. I renamed a png image > > > >to "$(echo text)", and vifm opened it in vi. I guess filename > > > >"`doas rm -Rf $HOME/*`" will also pleasantly surprise user. > > > > > > Ugh. I have seen CVEs assigned for smaller problems than that! > > > > I've added a naive patch to openbsd-wip version of this port. Vifm > > still opens renamed png in vi, but at least does not execute commands. > > better report it directly upstream then ? :) I'd leave this honor to maintainer. -- Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
On Tue, Feb 02, 2016 at 05:09:34PM +0100, Tobias Ulmer wrote: > What's the point when it requires half of GNOME? You should call the > package gvifm... > > CONFIGURE_ARGS += --without-gtk --without-libmagic --without-X11 > --without-dyn-X11 As the one who originally ported vifm years ago, its code quality was not great, and at some point it got removed. Apparently upstream has now revived this software, has a new website, so why not giving it a chance again, especially if people seem to like it ? I've tested it briefly on macppc and it seemd to work. The gtk+2/libmagic/libX11 dependency, maybe it is a bit overkill (from configure.ac): [use GTK+ to determine mimetypes if available @<:@default=yes@:>@]), [use libmagic to determine mimetypes if available @<:@default=yes@:>@]), [use libX11 to determine terminal emulator title @<:@default=yes@:>@]),. [load libX11 dynamically @<:@default=yes@:>@]) @rafael: if you decide to keep gtk dependency, LIB_DEPENDS=x11/gtk+2 ought to be enough, no need to list pango/glib/atk/gdk_pxibuf. You didnt set CONFIGURE_ARGS so x11/libmagic will be picked up automatically if present at configure time. This will be an issue in bulks. > (libmagic is a security disaster waiting to happen in a file manager) sqlite> select distinct(fullpkgpath) from depends where dependspath like '%libmagic%'; audio/sox devel/py-libmagic devel/py-libmagic,python3 editors/tpad geo/viking graphics/qiv lang/classpath mail/amavisd-new,-main mail/zarafa/zarafa,-main misc/p5-File-LibMagic multimedia/mediatomb multimedia/mkvtoolnix multimedia/mkvtoolnix,no_x11 net/bro net/mldonkey net/nepenthes print/lyx security/yara/main sysutils/binwalk textproc/zathura/core www/xapian-omega x11/emelfm2 x11/gnome/file-roller Then i guess we have other issues here. Landry
Re: NEW: sysutils/vifm
On Tue, Feb 02, 2016 at 08:56:35PM +0100, Rafael Sadowski wrote: > On Tue Feb 02, 2016 at 05:09:34PM +0100, Tobias Ulmer wrote: > > What's the point when it requires half of GNOME? You should call the > > package gvifm... > > Is that my fault!? If you don't like, it don't use it. I'm NOT a vifm > developer. I only port for my friend Uwe. That's it! > > > > > CONFIGURE_ARGS += --without-gtk --without-libmagic --without-X11 > > --without-dyn-X11 > > That's not my line. I think that was a suggestion from tobias :) > > > > (libmagic is a security disaster waiting to happen in a file manager) > > I follow you but it's just a port and not base stuff. I see misc/screen > in the ports tree. In my opinion screen is creep but it's only my > personal opinion. > > Finale, Dmitrij D. Czarkoff starts a "no_x11" flavor. Thanks Dmitrij. > https://github.com/jasperla/openbsd-wip/commit/a755a173f7ff05c23ab6d999716a4fe4855a54bc Im not sure 'feature-set-wise' that it's worth adding the complexity of a FLAVOR. You're the maintainer, you decide, but since libmagic and gtk+2 are here for the same feature (mimetype checking) maybe have a look at the code and see how it works (fine or not). Either way, please explicitely list --with/--without in CONFIGURE_ARGS for clarity. Note that the dyn-x11 thing was apparently broken in github, they added the requirement for -ldl which doesnt make sense on OpenBSD. So please check that the feature actually works if you want to enable it Landry >
Re: NEW: sysutils/vifm
On Tue Feb 02, 2016 at 05:09:34PM +0100, Tobias Ulmer wrote: > What's the point when it requires half of GNOME? You should call the > package gvifm... Is that my fault!? If you don't like, it don't use it. I'm NOT a vifm developer. I only port for my friend Uwe. That's it! > > CONFIGURE_ARGS += --without-gtk --without-libmagic --without-X11 > --without-dyn-X11 That's not my line. > > (libmagic is a security disaster waiting to happen in a file manager) I follow you but it's just a port and not base stuff. I see misc/screen in the ports tree. In my opinion screen is creep but it's only my personal opinion. Finale, Dmitrij D. Czarkoff starts a "no_x11" flavor. Thanks Dmitrij. https://github.com/jasperla/openbsd-wip/commit/a755a173f7ff05c23ab6d999716a4fe4855a54bc Best regards, Rafael
Re: NEW: sysutils/vifm
Landry Breuil said: > Im not sure 'feature-set-wise' that it's worth adding the complexity of > a FLAVOR. Flavors were supposed to address the "half GNOME" issue. -- Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
On Tue, Feb 02, 2016 at 09:34:13PM +0100, Dmitrij D. Czarkoff wrote: > Landry Breuil said: > > Im not sure 'feature-set-wise' that it's worth adding the complexity of > > a FLAVOR. > > Flavors were supposed to address the "half GNOME" issue. Sure, but in that particular case it turned into 'do you want your mime detection to be done with gtk+ (bo gnome blooaaat) or with libmagic (bo full of security issues)' :) Honestly, try both implementations, figure out which one 'performs' better in termes of filetype detection, and choose the less worst :) or just disable the feature if it not used much/broken. Doing a FLAVOR for this is just overkill, as 99% of the users wont know which one to choose (shall we build both by default?), and expect a non-no_x11 flavor to have some kind of GUI.. Landry
Re: NEW: sysutils/vifm
> On Tue, Feb 02, 2016 at 05:09:34PM +0100, Tobias Ulmer wrote:
> > (libmagic is a security disaster waiting to happen in a file manager)
>
On 2016/02/02 19:22, Landry Breuil wrote:
> sqlite> select distinct(fullpkgpath) from depends where dependspath like
> '%libmagic%';
[..]
> mail/amavisd-new,-main
Possible diff for amavisd-new below, I'm running it here, needs a bunch
more testing though.
> Then i guess we have other issues here.
Yep, it takes time to chip away at them.
Index: Makefile
===
RCS file: /cvs/ports/mail/amavisd-new/Makefile,v
retrieving revision 1.40
diff -u -p -r1.40 Makefile
--- Makefile15 Jul 2015 19:26:44 - 1.40
+++ Makefile2 Feb 2016 22:08:55 -
@@ -9,7 +9,7 @@ PKGNAME-main= ${DISTNAME}
PKGNAME-utils= amavisd-new-utils-${V}
CATEGORIES=mail security
-REVISION-main= 2
+REVISION-main= 3
REVISION-utils=2
HOMEPAGE= http://www.amavis.org/
Index: patches/patch-amavisd
===
RCS file: /cvs/ports/mail/amavisd-new/patches/patch-amavisd,v
retrieving revision 1.12
diff -u -p -r1.12 patch-amavisd
--- patches/patch-amavisd 2 Feb 2016 21:58:32 - 1.12
+++ patches/patch-amavisd 2 Feb 2016 22:08:55 -
@@ -1,6 +1,18 @@
$OpenBSD: patch-amavisd,v 1.12 2016/02/02 21:58:32 sthen Exp $
+
+Hunks 1, 3: Disable File::LibMagic in favour of safer file(1) from base.
+
--- amavisd.orig Sun Oct 26 00:06:00 2014
-+++ amavisdTue Feb 2 21:57:58 2016
amavisdTue Feb 2 22:08:33 2016
+@@ -12557,7 +12557,7 @@ sub after_chroot_init() {
+grep(/\.pm\z/, keys %INC)) {
+ next if !grep($_ eq $m, qw(Amavis::Conf
+ Archive::Tar Archive::Zip Compress::Zlib Compress::Raw::Zlib
+- Convert::TNEF Convert::UUlib File::LibMagic
++ Convert::TNEF Convert::UUlib
+ MIME::Entity MIME::Parser MIME::Tools Mail::Header Mail::Internet
+ Digest::MD5 Digest::SHA Digest::SHA1 Crypt::OpenSSL::RSA
+ Authen::SASL Authen::SASL::XS Authen::SASL::Cyrus Authen::SASL::Perl
@@ -29847,7 +29847,7 @@ sub new_SpamAssassin_instance {
# PREFIX=> '/usr/local',
# DEF_RULES_DIR => '/usr/local/share/spamassassin',
@@ -10,3 +22,21 @@ $OpenBSD: patch-amavisd,v 1.12 2016/02/0
#see Mail::SpamAssassin man page for other options
};
if ($sa_version_num < 3.001005 && !defined $sa_args->{LOCAL_STATE_DIR})
+@@ -30595,17 +30595,8 @@ BEGIN {
+ import Amavis::Unpackers::NewFilename qw(consumed_bytes);
+ }
+
+-BEGIN {
+ use vars qw($filemagic);
+- eval {
+-require File::LibMagic;
+-File::LibMagic->VERSION(1.00);
+-import File::LibMagic;
+-$filemagic = File::LibMagic->new;
+- } or do {
+ undef $filemagic;
+- };
+-}
+
+ use subs @EXPORT_OK;
+
Re: NEW: sysutils/vifm
Landry Breuil said:
> Doing a FLAVOR for this is just overkill, as 99% of the users wont know
> which one to choose (shall we build both by default?),
Idea is that people should install package with no FLAVOR. If they
really, really want to have as little dependencies as possible, they
install "no_x11" FLAVORed package.
> and expect a non-no_x11 flavor to have some kind of GUI..
Let them. Really, X11 does not mean GUI.
> Oh, and the code in src/int/file_magic.c even has a fallback to use file
> %s -b --mime-type called via popen()..
>
> In terms of priority:
> ---
> if(get_gtk_mimetype(file, mimetype) == -1)
> {
> if(get_magic_mimetype(file, mimetype) == -1)
> {
> if(get_file_mimetype(file, mimetype, sizeof(mimetype)) == -1)
> return NULL;
> }
> }
> ---
>
> So by default the primary method is gtk, then magic, then file.
Maybe file is not a bad option - in the end it is the most secure
filetype detection tool we have in OpenBSD ATM.
> And if i still look at the code... one of the uses of getting the
> mimetype of a file seems to be.. to print the mimetype. Another (grep -r
> get_handlers) seems to be to propose the various mimetype handlers found
> in the desktop files to handle it. am i reading this right ?
Well, I don't use file managers, but I suppose that printing mimetype
and automagically open files in right application is why you may want a
file managers. Otherwise cp, rm, ln and cd are your file manager.
--
Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
On Tue, Feb 02, 2016 at 08:56:35PM +0100, Rafael Sadowski wrote: > On Tue Feb 02, 2016 at 05:09:34PM +0100, Tobias Ulmer wrote: > > What's the point when it requires half of GNOME? You should call the > > package gvifm... > > Is that my fault!? If you don't like, it don't use it. I'm NOT a vifm > developer. I only port for my friend Uwe. That's it! Take a chill pill, dude. I find it hilarious (and a little disgusting) a ncurses based file manager now depends on gtk. > > > > > CONFIGURE_ARGS += --without-gtk --without-libmagic --without-X11 > > --without-dyn-X11 > > That's not my line. Indeed, that's was my mild suggestion/attempt at decreasing the bloat. I've tried it like this on sparc64 and it worked fine. > > > > > > (libmagic is a security disaster waiting to happen in a file manager) > > I follow you but it's just a port and not base stuff. I see misc/screen > in the ports tree. In my opinion screen is creep but it's only my > personal opinion. > > Finale, Dmitrij D. Czarkoff starts a "no_x11" flavor. Thanks Dmitrij. > https://github.com/jasperla/openbsd-wip/commit/a755a173f7ff05c23ab6d999716a4fe4855a54bc Good idea, I like it. > > Best regards, > > Rafael
Re: NEW: sysutils/vifm
On Tue, Feb 02, 2016 at 10:41:12PM +0100, Rafael Sadowski wrote: > Yes, if we disable GTK+ and libmagic we fallback to file(1). Easy choice. Just use file(1) and disable the others. file(1) is satisfied by the base install (no extra deps) and is also the most secure option of the bunch.
Re: NEW: sysutils/vifm
On 2016/02/02 21:58, Landry Breuil wrote: > Oh, and the code in src/int/file_magic.c even has a fallback to use file > %s -b --mime-type called via popen().. It would be nice to kill the other options and use file(1) from base as the only detection method, it is *loads* safer.
Re: NEW: sysutils/vifm
On Tue, Feb 02, 2016 at 09:44:52PM +0100, Landry Breuil wrote:
> On Tue, Feb 02, 2016 at 09:34:13PM +0100, Dmitrij D. Czarkoff wrote:
> > Landry Breuil said:
> > > Im not sure 'feature-set-wise' that it's worth adding the complexity of
> > > a FLAVOR.
> >
> > Flavors were supposed to address the "half GNOME" issue.
>
> Sure, but in that particular case it turned into 'do you want your mime
> detection to be done with gtk+ (bo gnome blooaaat) or with libmagic
> (bo full of security issues)' :)
>
> Honestly, try both implementations, figure out which one 'performs'
> better in termes of filetype detection, and choose the less worst :) or
> just disable the feature if it not used much/broken.
>
> Doing a FLAVOR for this is just overkill, as 99% of the users wont know
> which one to choose (shall we build both by default?), and expect a
> non-no_x11 flavor to have some kind of GUI..
Oh, and the code in src/int/file_magic.c even has a fallback to use file
%s -b --mime-type called via popen()..
In terms of priority:
---
if(get_gtk_mimetype(file, mimetype) == -1)
{
if(get_magic_mimetype(file, mimetype) == -1)
{
if(get_file_mimetype(file, mimetype, sizeof(mimetype)) == -1)
return NULL;
}
}
---
So by default the primary method is gtk, then magic, then file.
And if i still look at the code... one of the uses of getting the
mimetype of a file seems to be.. to print the mimetype. Another (grep -r
get_handlers) seems to be to propose the various mimetype handlers found
in the desktop files to handle it. am i reading this right ?
Oh well.
Landry
Re: NEW: sysutils/vifm
On Tue Feb 02, 2016 at 10:16:47PM +0100, Dmitrij D. Czarkoff wrote:
> Landry Breuil said:
> > Doing a FLAVOR for this is just overkill, as 99% of the users wont know
> > which one to choose (shall we build both by default?),
>
> Idea is that people should install package with no FLAVOR. If they
> really, really want to have as little dependencies as possible, they
> install "no_x11" FLAVORed package.
>
> > and expect a non-no_x11 flavor to have some kind of GUI..
>
> Let them. Really, X11 does not mean GUI.
I like the flavor idea from Dmitrij. It feels right. Tobias tried it on
sparc64 (Not the flavor but some flags).
So let's try with flavor. Dmitrij has begun so let's (maybe) improve and
test at daily work.
>
> > Oh, and the code in src/int/file_magic.c even has a fallback to use file
> > %s -b --mime-type called via popen()..
> >
> > In terms of priority:
> > ---
> > if(get_gtk_mimetype(file, mimetype) == -1)
> > {
> > if(get_magic_mimetype(file, mimetype) == -1)
> > {
> > if(get_file_mimetype(file, mimetype, sizeof(mimetype)) == -1)
> > return NULL;
> > }
> > }
> > ---
> >
> > So by default the primary method is gtk, then magic, then file.
>
> Maybe file is not a bad option - in the end it is the most secure
> filetype detection tool we have in OpenBSD ATM.
>
> > And if i still look at the code... one of the uses of getting the
> > mimetype of a file seems to be.. to print the mimetype. Another (grep -r
> > get_handlers) seems to be to propose the various mimetype handlers found
> > in the desktop files to handle it. am i reading this right ?
>
> Well, I don't use file managers, but I suppose that printing mimetype
> and automagically open files in right application is why you may want a
> file managers. Otherwise cp, rm, ln and cd are your file manager.
>
Yes, if we disable GTK+ and libmagic we fallback to file(1).
Re: NEW: sysutils/vifm
On Tue, Feb 02, 2016 at 10:52:45PM +0100, Stefan Sperling wrote: > On Tue, Feb 02, 2016 at 10:41:12PM +0100, Rafael Sadowski wrote: > > Yes, if we disable GTK+ and libmagic we fallback to file(1). > > Easy choice. Just use file(1) and disable the others. file(1) is satisfied > by the base install (no extra deps) and is also the most secure option of > the bunch. Tried with just the file backend enabled, it's "less" rich than the gtk/libmagic combination but works for pdf/jpg/txt/mp3. No match for tgz, proposes fuse-archivemount for .tar.gz, proposes text editor for gpx/gsb... for the latter, the correct mimetype was found and the best handler was proposed. I guess that's what you get for using file from base which is ... basic. (try :f on a file to see the available handlers for the detected mimetype) Landry
Re: NEW: sysutils/vifm
Stuart Henderson said: > On 2016/02/02 21:58, Landry Breuil wrote: > > Oh, and the code in src/int/file_magic.c even has a fallback to use file > > %s -b --mime-type called via popen().. > > It would be nice to kill the other options and use file(1) from base > as the only detection method, it is *loads* safer. Well, the actual code is: | snprintf(command, sizeof(command), "file \"%s\" -b --mime-type", filename); Note double quotes. Of course no quoting is performed on filename. Thus: 1. If filename contains double quote, vifm sigfaults. 2. If filename is nasty, nasty things happen. Eg. I renamed a png image to "$(echo text)", and vifm opened it in vi. I guess filename "`doas rm -Rf $HOME/*`" will also pleasantly surprise user. -- Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
Stuart Henderson said: > On 2016/02/03 00:25, Dmitrij D. Czarkoff wrote: > > Stuart Henderson said: > > > On 2016/02/02 21:58, Landry Breuil wrote: > > > > Oh, and the code in src/int/file_magic.c even has a fallback to use file > > > > %s -b --mime-type called via popen().. > > > > > > It would be nice to kill the other options and use file(1) from base > > > as the only detection method, it is *loads* safer. > > > > Well, the actual code is: > > > > | snprintf(command, sizeof(command), "file \"%s\" -b --mime-type", > > filename); > > > > Note double quotes. Of course no quoting is performed on filename. > > Thus: > > > > 1. If filename contains double quote, vifm sigfaults. > > 2. If filename is nasty, nasty things happen. Eg. I renamed a png image > >to "$(echo text)", and vifm opened it in vi. I guess filename > >"`doas rm -Rf $HOME/*`" will also pleasantly surprise user. > > Ugh. I have seen CVEs assigned for smaller problems than that! I've added a naive patch to openbsd-wip version of this port. Vifm still opens renamed png in vi, but at least does not execute commands. -- Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
On 2016/02/03 00:25, Dmitrij D. Czarkoff wrote: > Stuart Henderson said: > > On 2016/02/02 21:58, Landry Breuil wrote: > > > Oh, and the code in src/int/file_magic.c even has a fallback to use file > > > %s -b --mime-type called via popen().. > > > > It would be nice to kill the other options and use file(1) from base > > as the only detection method, it is *loads* safer. > > Well, the actual code is: > > | snprintf(command, sizeof(command), "file \"%s\" -b --mime-type", filename); > > Note double quotes. Of course no quoting is performed on filename. > Thus: > > 1. If filename contains double quote, vifm sigfaults. > 2. If filename is nasty, nasty things happen. Eg. I renamed a png image >to "$(echo text)", and vifm opened it in vi. I guess filename >"`doas rm -Rf $HOME/*`" will also pleasantly surprise user. Ugh. I have seen CVEs assigned for smaller problems than that!
Re: NEW: sysutils/vifm
Landry Breuil said: > Tried with just the file backend enabled, it's "less" rich than the > gtk/libmagic combination but works for pdf/jpg/txt/mp3. No match for tgz, > proposes fuse-archivemount for .tar.gz, proposes text editor for > gpx/gsb... for the latter, the correct mimetype was found and the best > handler was proposed. I guess that's what you get for using file from > base which is ... basic. I somehow overlooked the fact that vifm only uses X11 to set window title. I bet people may live without this feature. (I thought it uses X11 for clipboard.) Provided that basic things work with file(1) backend, FLAVORs indeed don't seem a good idea. Attached tarball contains a non-FLAVORed port for vifm with all optional features disabled. Brief testing demonstrates that it is buggy (prints artifacts in file info dialog for some file names, provides different set of handlers for the files with same mime type, seldom picks different handlers for the same file). I believe that my patch makes file(1) usage in this port at least safer then it was. FLAVORed version is still available in openbsd-wip repo. I am not really interested in vifm, so I leave this port here as it is. -- Dmitrij D. Czarkoff vifm-0.8.1.tgz Description: application/tar-gz
Re: NEW: sysutils/vifm
On Wed, Feb 03, 2016 at 12:42:34AM +0100, Dmitrij D. Czarkoff wrote: > Stuart Henderson said: > > On 2016/02/03 00:25, Dmitrij D. Czarkoff wrote: > > > Stuart Henderson said: > > > > On 2016/02/02 21:58, Landry Breuil wrote: > > > > > Oh, and the code in src/int/file_magic.c even has a fallback to use > > > > > file > > > > > %s -b --mime-type called via popen().. > > > > > > > > It would be nice to kill the other options and use file(1) from base > > > > as the only detection method, it is *loads* safer. > > > > > > Well, the actual code is: > > > > > > | snprintf(command, sizeof(command), "file \"%s\" -b --mime-type", > > > filename); > > > > > > Note double quotes. Of course no quoting is performed on filename. > > > Thus: > > > > > > 1. If filename contains double quote, vifm sigfaults. > > > 2. If filename is nasty, nasty things happen. Eg. I renamed a png image > > >to "$(echo text)", and vifm opened it in vi. I guess filename > > >"`doas rm -Rf $HOME/*`" will also pleasantly surprise user. > > > > Ugh. I have seen CVEs assigned for smaller problems than that! > > I've added a naive patch to openbsd-wip version of this port. Vifm > still opens renamed png in vi, but at least does not execute commands. better report it directly upstream then ? :) Landry
Re: NEW: sysutils/vifm
On Tue, Feb 02, 2016 at 05:18:13PM +0100, Dmitrij D. Czarkoff wrote: > Tobias Ulmer said: > > What's the point when it requires half of GNOME? You should call the > > package gvifm... > > GTK+ is not half of GNOME. Is this supposed to make me feel better? :p > > -- > Dmitrij D. Czarkoff >
Re: NEW: sysutils/vifm
Tobias Ulmer said: > What's the point when it requires half of GNOME? You should call the > package gvifm... GTK+ is not half of GNOME. -- Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
Tobias Ulmer said: > On Tue, Feb 02, 2016 at 05:18:13PM +0100, Dmitrij D. Czarkoff wrote: > > Tobias Ulmer said: > > > What's the point when it requires half of GNOME? You should call the > > > package gvifm... > > > > GTK+ is not half of GNOME. > > Is this supposed to make me feel better? :p It makes *me* feel better. I have all of the dependencies anyway, just because of browser. -- Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
What's the point when it requires half of GNOME? You should call the package gvifm... CONFIGURE_ARGS += --without-gtk --without-libmagic --without-X11 --without-dyn-X11 (libmagic is a security disaster waiting to happen in a file manager) On Thu, Jan 28, 2016 at 06:18:59PM +0100, Rafael Sadowski wrote: > hey @ports and vifm friends, > > here is an up-to-date vifm port. Tested on amd64 by me and positive test > feedback from Uwe Werler. Port request by Uwe. > > I found a thread on ports@: > https://marc.info/?l=openbsd-ports=144944041505080=2 > > I can not confirm runtime problems or memory usage oversize at buildtime. > > pkg/DESCR: > Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, > vifm gives you complete keyboard control over your files without having > to learn a new set of commands. It goes not just about vi[m] like > keybindings, but also about modes, options, registers, commands and other > things you might already like in vi[m]. > > Best regards, > > Rafael
Re: NEW: sysutils/vifm
> hey @ports and vifm friends, > > here is an up-to-date vifm port. Tested on amd64 by me and positive test > feedback from Uwe Werler. Port request by Uwe. > > I found a thread on ports@: > https://marc.info/?l=openbsd-ports=144944041505080=2 > > I can not confirm runtime problems or memory usage oversize at buildtime. > > pkg/DESCR: > Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, > vifm gives you complete keyboard control over your files without having > to learn a new set of commands. It goes not just about vi[m] like > keybindings, but also about modes, options, registers, commands and other > things you might already like in vi[m]. > > Best regards, > > Rafael Up to now it work's like a charme on -current. Thanks Rafael!
Re: NEW: sysutils/vifm
On Thu, Jan 28, 2016 at 06:18:59PM +0100, Rafael Sadowski wrote: > here is an up-to-date vifm port. Tested on amd64 by me and positive > test feedback from Uwe Werler. Port request by Uwe. Tested positive on amd64. Love it! Thank you very much. Hope it gets imported. Regards, Erling > I found a thread on ports@: > https://marc.info/?l=openbsd-ports=144944041505080=2 > > I can not confirm runtime problems or memory usage oversize at > buildtime. > > pkg/DESCR: > Vifm is a two panel ncurses based vi[m] like file manager. If you use > vi, vifm gives you complete keyboard control over your files without > having to learn a new set of commands. It goes not just about vi[m] > like keybindings, but also about modes, options, registers, commands > and other things you might already like in vi[m]. > > Best regards, > > Rafael
NEW: sysutils/vifm
hey @ports and vifm friends, here is an up-to-date vifm port. Tested on amd64 by me and positive test feedback from Uwe Werler. Port request by Uwe. I found a thread on ports@: https://marc.info/?l=openbsd-ports=144944041505080=2 I can not confirm runtime problems or memory usage oversize at buildtime. pkg/DESCR: Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, vifm gives you complete keyboard control over your files without having to learn a new set of commands. It goes not just about vi[m] like keybindings, but also about modes, options, registers, commands and other things you might already like in vi[m]. Best regards, Rafael vifm.tar.gz Description: application/tar-gz
Re: vifm
Predrag Punosevac writes: > I noticed that vifm has been removed from the OpenBSD port three prior > to 5.8 release. Are there technical reasons for such decision (I > remember pains to initial import vifm into the port three due to the > code quality)? It looks like vifm got many new features which might have > triggered the decision. > > I just tried ranger instead of vifm but it seems overkill for an > occasional user like myself (I found vifm sometimes useful with ssh/tmux > sessions). See the commit message... "remove; it's been runtime broken since forever and the latest version isn't any better either as confirmed by landry@. maintainer is MIA too."
vifm
I noticed that vifm has been removed from the OpenBSD port three prior to 5.8 release. Are there technical reasons for such decision (I remember pains to initial import vifm into the port three due to the code quality)? It looks like vifm got many new features which might have triggered the decision. I just tried ranger instead of vifm but it seems overkill for an occasional user like myself (I found vifm sometimes useful with ssh/tmux sessions). Best, Predrag
Re: New: misc/vifm
On Sat, Aug 08, 2009 at 08:58:13PM +0200, Landry Breuil wrote: On Sat, Aug 08, 2009 at 04:22:08PM +0200, Tobias Ulmer wrote: First try that doesn't crash on amd64 within seconds. Removes the most evil things gcc warns about and moves malloc out of the signal handler. There is without a doubt, much more to repair... For sure.. with your patches, it still explodes on sparc64 at the same point.. volunteers for code reading fixing forwarding patches upstream needed :) ok, so here's a version that works (basic testing) @macppc/sparc64/i386/alpha/amd64 - allocating : char file_name[view-window_width -2]; - and accessing : file_name[view-window_width +1] is no good.. but the code does indeed lots of scarier things :) While here, install vifmrc to share/vifm to remove the annoying warning upon first startup, where it tried to copy the file from there to ~/.vifm. Comments/oks ? Landry vifm3.tgz Description: application/tar-gz
Re: New: misc/vifm
On Sun, Aug 09, 2009 at 12:49:46PM +0200, Landry Breuil wrote: On Sat, Aug 08, 2009 at 08:58:13PM +0200, Landry Breuil wrote: On Sat, Aug 08, 2009 at 04:22:08PM +0200, Tobias Ulmer wrote: First try that doesn't crash on amd64 within seconds. Removes the most evil things gcc warns about and moves malloc out of the signal handler. There is without a doubt, much more to repair... For sure.. with your patches, it still explodes on sparc64 at the same point.. volunteers for code reading fixing forwarding patches upstream needed :) ok, so here's a version that works (basic testing) @macppc/sparc64/i386/alpha/amd64 - allocating : char file_name[view-window_width -2]; - and accessing : file_name[view-window_width +1] is no good.. but the code does indeed lots of scarier things :) While here, install vifmrc to share/vifm to remove the annoying warning upon first startup, where it tried to copy the file from there to ~/.vifm. Comments/oks ? Thanks, works fine on amd64. Since you've done all the patching, you were the one who originally posted the port two years ago, and I don't have access to sparc64 -- I probably don't deserve to be a maintainer of this port ;-).
Re: New: misc/vifm
On Fri, Aug 07, 2009 at 04:06:53PM -0700, Aaron Stellman wrote: Hello ports@, attached is the ports of vifm -- ncurses file manager with vi keybindings. cat pkg/DESCR Vifm is a ncurses based file manager with vi like keybindings. If you use vi, vifm gives you complete keyboard control over your files without having to learn a new set of commands. I had this in my tree at some point (maybe 0.3), and i remember its code was rather ugly. Works on i386, but seems to do really bad things (tm) on sparc64 just at startup : Program received signal SIGABRT, Aborted. __stack_smash_handler (func=0x21d058 moveto_list_pos, damaged=-738134664) at /usr/src/lib/libc/sys/stack_protector.c:91 /usr/src/lib/libc/sys/stack_protector.c: No such file or directory. in /usr/src/lib/libc/sys/stack_protector.c (gdb) bt #0 __stack_smash_handler (func=0x21d058 moveto_list_pos, damaged=-738134664) at /usr/src/lib/libc/sys/stack_protector.c:91 #1 0x0010c074 in moveto_list_pos (view=0x720698, pos=0) at filelist.c:553 #2 0x00102e04 in main (argc=1, argv=0xfffe9a68) at vifm.c:26 I don't see the reason of this crash, will investigate a bit, but i'll appreciate if others could have a look too. Landry
Re: New: misc/vifm
On Sat, Aug 08, 2009 at 11:12:02AM +0200, Landry Breuil wrote: On Fri, Aug 07, 2009 at 04:06:53PM -0700, Aaron Stellman wrote: Hello ports@, attached is the ports of vifm -- ncurses file manager with vi keybindings. cat pkg/DESCR Vifm is a ncurses based file manager with vi like keybindings. If you use vi, vifm gives you complete keyboard control over your files without having to learn a new set of commands. I had this in my tree at some point (maybe 0.3), and i remember its code was rather ugly. Works on i386, but seems to do really bad things (tm) on sparc64 just at startup : Program received signal SIGABRT, Aborted. __stack_smash_handler (func=0x21d058 moveto_list_pos, damaged=-738134664) at /usr/src/lib/libc/sys/stack_protector.c:91 /usr/src/lib/libc/sys/stack_protector.c: No such file or directory. in /usr/src/lib/libc/sys/stack_protector.c (gdb) bt #0 __stack_smash_handler (func=0x21d058 moveto_list_pos, damaged=-738134664) at /usr/src/lib/libc/sys/stack_protector.c:91 #1 0x0010c074 in moveto_list_pos (view=0x720698, pos=0) at filelist.c:553 #2 0x00102e04 in main (argc=1, argv=0xfffe9a68) at vifm.c:26 I don't see the reason of this crash, will investigate a bit, but i'll appreciate if others could have a look too. Landry That's not surprising, from memory the code uses sizeof(buf) when it actually wanted bufsize in a number of places. I will take a look as well. Tobias
Re: New: misc/vifm
First try that doesn't crash on amd64 within seconds. Removes the most evil things gcc warns about and moves malloc out of the signal handler. There is without a doubt, much more to repair... vifm2.tar.gz Description: application/tar-gz
Re: New: misc/vifm
On Sat, Aug 08, 2009 at 04:22:08PM +0200, Tobias Ulmer wrote: First try that doesn't crash on amd64 within seconds. Removes the most evil things gcc warns about and moves malloc out of the signal handler. There is without a doubt, much more to repair... For sure.. with your patches, it still explodes on sparc64 at the same point.. volunteers for code reading fixing forwarding patches upstream needed :) Landry
Re: New: misc/vifm
Landry Breuil lan...@rhaalovely.net wrote: On Sat, Aug 08, 2009 at 04:22:08PM +0200, Tobias Ulmer wrote: First try that doesn't crash on amd64 within seconds. Removes the most evil things gcc warns about and moves malloc out of the signal handler. There is without a doubt, much more to repair... For sure.. with your patches, it still explodes on sparc64 at the same point.. volunteers for code reading fixing forwarding patches upstream needed :) Landry I would like to bring to your attention two facts: 1. Somebody did try to port vifm to OpenBSD few years ago. There is the reason vifm is still not in ports. 2. Good luck with fixing things upstream. My fellow Tucsonian who coded vifm did that in order to learn programming language C :-) He is retired these days so am not sure if he is interested in brushing up his programming skills. Best, Predrag
Re: New: misc/vifm
On Sat, Aug 08, 2009 at 05:32:16PM -0400, Predrag Punosevac wrote: Landry Breuil lan...@rhaalovely.net wrote: On Sat, Aug 08, 2009 at 04:22:08PM +0200, Tobias Ulmer wrote: First try that doesn't crash on amd64 within seconds. Removes the most evil things gcc warns about and moves malloc out of the signal handler. There is without a doubt, much more to repair... For sure.. with your patches, it still explodes on sparc64 at the same point.. volunteers for code reading fixing forwarding patches upstream needed :) Landry I would like to bring to your attention two facts: 1. Somebody did try to port vifm to OpenBSD few years ago. There is the reason vifm is still not in ports. Funny, looking at the archives... i found out it was myself who already ported it :) 2. Good luck with fixing things upstream. My fellow Tucsonian who coded vifm did that in order to learn programming language C :-) He is retired these days so am not sure if he is interested in brushing up his programming skills. Well - we can still keep the patches local anyway, or someone can still take over maintenance of it - thanks free software :) Landry
Re: [new] vifm
On Mon, Nov 19, 2007 at 04:27:59PM +0100, Landry Breuil wrote: Hi, a small port for vifm, a ncurses based file manager with vi like keybindings. Works fine for me on i386, it's rather basic but may be useful to someone.. cf http://vifm.sourceforge.net/docs.html for default keybindings. port is here : http://gcu.info/~gaston/ports/vifm.tar.gz Comments ? Ok ? Landry Works fine on amd64.
[new] vifm
Hi, a small port for vifm, a ncurses based file manager with vi like keybindings. Works fine for me on i386, it's rather basic but may be useful to someone.. cf http://vifm.sourceforge.net/docs.html for default keybindings. port is here : http://gcu.info/~gaston/ports/vifm.tar.gz Comments ? Ok ? Landry
Re: [new] vifm
Le Mon, 19 Nov 2007 16:27:59 +0100, Landry Breuil [EMAIL PROTECTED] a écrit : Hi, a small port for vifm, a ncurses based file manager with vi like keybindings. Works fine for me on i386, it's rather basic but may be useful to someone.. cf http://vifm.sourceforge.net/docs.html for default keybindings. port is here : http://gcu.info/~gaston/ports/vifm.tar.gz Comments ? Ok ? Landry Hi, Tested on @i386: Ok. Nice tool :) Pea
Re: [new] vifm
On Mon, Nov 19, 2007 at 04:27:59PM +0100, Landry Breuil wrote: a small port for vifm, a ncurses based file manager with vi like keybindings. Works fine for me on i386, it's rather basic but may be useful to someone.. Works for me on i386 and macppc. It dumps core on sparc64. On both sparc64 and macppc, I get this when I start vifm (but not i386): Unable to find configuration file. cp: /usr/local/share/vifm/vifmrc0.2: No such file or directory -ME
Re: [new] vifm
On Mon, Nov 19, 2007 at 01:20:34PM -0500, Mike Erdely wrote: On Mon, Nov 19, 2007 at 04:27:59PM +0100, Landry Breuil wrote: a small port for vifm, a ncurses based file manager with vi like keybindings. Works fine for me on i386, it's rather basic but may be useful to someone.. Works for me on i386 and macppc. It dumps core on sparc64. On both sparc64 and macppc, I get this when I start vifm (but not i386): Unable to find configuration file. cp: /usr/local/share/vifm/vifmrc0.2: No such file or directory Funny, this file isn't listed in PLIST... I think i'll give a second chance to this port by patching source, removing dumb helper scripts and fix coredump on sparc64... stay tuned. Landry
Re: Request for new port: vifm
Hello ports@ again,
sorry for answering my own mail, but I did some more research:
To make vifm compile you just have to install automake 1.7 (I used 1.9) change
the links in vifm/ to point to
/usr/local/share/automake-1.9/{depcomp,install-sh,missing,mkinstalldirs}
The patch I posted before has to be used (still don't know why, older version
of ncurses on openbsd?).
I found about about more niffty features, one is that you can define default
programs for every file type, so vifm will use those programms to open them.
As I said EVERYBODY working with VI[M] and many files should have a look at it,
the ease of use is just impressive.
Since I didn't get any reply so far what could I do to get it adopted as an
official port?
Btw, it works (at least) on:
i386
amd64
(not on hppa and vax (there is no new enough autoconf :))
Regards,
ahb
Request for new port: vifm
Hello ports@, I would really like to see vifm [1] in the ports tree, because it is a really nice and comfortable file manager (like mc), but with vi key bindings. I basically downloaded the source, untared it, fixed all the symlinks in the vifm directory and had to comment out one line in vimfm/src/ui.c I don't know where the symlinks SHOULD go, I just linked it against files I found with the same name (yeah it worked somehow :) This is not a fix of course, but it enabled me to compile it and it runs just fine. I'm sure somenone here (having much more C/ncurses knowledge) could fix it quickly. #--- dirty_hack ---# --- vifm/src/ui.c Sun Jul 17 23:51:28 2005 +++ vifm2/src/ui.c Thu Nov 24 07:57:51 2005 @@ -324,7 +324,7 @@ ioctl(0, TIOCGWINSZ, ws); - resize_term(ws.ws_row, ws.ws_col); +/* resize_term(ws.ws_row, ws.ws_col); */ getmaxyx(stdscr, screen_y, screen_x); #--# Since I'm sure many developers/ports-maintainers are using vi[m] as well, would it be possible to make a port and include it? [1] http://vifm.sourceforge.net/ Regards, ahb Please CC me, otherwise I have to read it in the archives (no problem either).
