NEW: sysutils/vifm

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

NEW: sysutils/vifm

Rafael Sadowski
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&m=144944041505080&w=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 (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Erling Westenvik-2
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&m=144944041505080&w=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

Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Uwe Werler
In reply to this post by Rafael Sadowski

> 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&m=144944041505080&w=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!
Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Tobias Ulmer
In reply to this post by Rafael Sadowski
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&m=144944041505080&w=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


Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Dmitrij D. Czarkoff-2
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

Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Tobias Ulmer
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
>

Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Dmitrij D. Czarkoff-2
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

Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Landry Breuil-6
In reply to this post by Tobias Ulmer
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

Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Rafael Sadowski
In reply to this post by Tobias Ulmer
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

Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Landry Breuil-6
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
>

Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Dmitrij D. Czarkoff-2
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

Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Landry Breuil-6
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+ (booooo gnome blooaaat) or with libmagic
(booooo 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

Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Landry Breuil-6
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+ (booooo gnome blooaaat) or with libmagic
> (booooo 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

Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Dmitrij D. Czarkoff-2
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

Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Tobias Ulmer
In reply to this post by Rafael Sadowski
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

Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Rafael Sadowski
In reply to this post by Dmitrij D. Czarkoff-2
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).

Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Stuart Henderson-6
In reply to this post by Landry Breuil-6
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.

Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Stefan Sperling-5
In reply to this post by Rafael Sadowski
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.

Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Stuart Henderson-6
In reply to this post by Landry Breuil-6
> 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
--- Makefile 15 Jul 2015 19:26:44 -0000 1.40
+++ Makefile 2 Feb 2016 22:08:55 -0000
@@ -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 -0000 1.12
+++ patches/patch-amavisd 2 Feb 2016 22:08:55 -0000
@@ -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
-+++ amavisd Tue Feb  2 21:57:58 2016
++++ amavisd Tue 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;
+

Reply | Threaded
Open this post in threaded view
|

Re: NEW: sysutils/vifm

Landry Breuil-6
In reply to this post by Stefan Sperling-5
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

12