Re: Request for a second "ffmpeg" optionality in packages (much as with ImageMagick)

2018-06-26 Thread Mathieu Arnold 
On Mon, Jun 25, 2018 at 06:31:31PM -0600, Adam Weinberger wrote:
> On Mon, Jun 25, 2018 at 6:08 PM Walter Schwarzenfeld
>  wrote:
> >
> > I don't understand why? You set all these options to off..
> >
> 
> There's something to be said here for packages that don't try to be
> everything to everyone. I'd be surprised if OpenCV is a common format
> for a typical ffmpeg user. It is far more reasonable to ask people who
> need unusual codec support to build their own ffmpeg, than to ask
> everybody to install 2GB of dependencies for a relatively common tool.
> 
> You're right though, Walter, that it goes both ways, and it's also
> reasonable to ask people who want slim installs to build their own
> ffmpeg.
> 
> We've never had a policy regarding dependencitis, and at the end of
> the day it usually comes down to the set of default options that leads
> to the fewest unhappy PRs.

I do not think we have a policy regarding dependencies, but we have
about options, the default set should be the one who benefits most
people (as in, most people should not have to enable more options by
themselves.)
The oposite may have been true years ago, but these days, 2GB, while it
may feel big by human standard, is quite nothing, hard drives are in the
TB, SD cards are also getting there, these days, SD cards up to 32GB are
available for less than $10.

-- 
Mathieu Arnold


signature.asc
Description: PGP signature

head/audio/jack-keyboard

2018-06-26 Thread Hans Petter Selasky 
Can someone bump DISTVERSION or approve me to do it in 
head/audio/jack-keyboard/Makefile to 2.7.2 ?


--HPS

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Should a package restart on upgrade itself

2018-06-26 Thread Miroslav Lachman 

Miroslav Lachman wrote on 2017/06/27 19:32:

Matthias Fechner wrote on 2017/06/27 18:29:

Dear all,

it is always a pain if pkg upgrade a lot of packages to restart all
services to make sure update/security fixes are applied to all running
services.

Is there an option in pkg that it restart services automatically or is
it OK if I would add a post-install script to the packages (I maintain)
that will include a "service foo restart"?

What is best practice here?


Please don't do this.
Some ports did this in the past and this was really a pain during larger 
upgrades. It sometimes leave services stopped (hi MySQL).


The same bad practice is disabling / enabling Apache modules on upgrade.

pkg upgrade should just do it's work - upgrade packages on disk. But 
manipulating config files and restart of services is up to me - the 
Administrator (or my tools).


It would be nice to have some kind of "hooks" in pkg, which can be used 
to notify deployment tools that some services should be (re)started, or 
do restart in some simpler environment if user allows this (setup hooks 
for service restart).
But is must not be done automatically for individual ports / packages 
even if maintainer thinks it is Good Idea (tm)


Again and again and again...

Can we have some written (or do we have?) policy to not 
stop/start/restart services from some @preunexec / @postexec targets?
I really don't like that some packages are still shutting down or trying 
to restart in the middle of the pkg upgrade process.


One example from today upgrade:

[87/96] Extracting open-vm-tools-nox11-10.2.5,2: .. done
Stopping vmware_guestd.
Waiting for PIDS: 516.
Loading vmmemctl kernel module: already loaded.
vmware_guestd not running? (check /var/run/vmware_guestd.pid).
Starting vmware_guestd.

Can committers take care of this bad behaviour and not commit things 
like this?

https://svnweb.freebsd.org/ports/head/emulators/open-vm-tools/pkg-plist?revision=457485&view=markup

@preunexec %%PREFIX%%/bin/vmware-rpctool 'tools.set.version 0' ; service 
vmware-guestd stop 2>/dev/null || /usr/bin/true
@postexec service vmware-kmod restart && service vmware-guestd restart 
|| /usr/bin/true


Kind regards
Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Should a package restart on upgrade itself

2018-06-26 Thread Franco Fichtner 


> On 26. Jun 2018, at 1:27 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> One example from today upgrade:
> 
> [87/96] Extracting open-vm-tools-nox11-10.2.5,2: .. done
> Stopping vmware_guestd.
> Waiting for PIDS: 516.
> Loading vmmemctl kernel module: already loaded.
> vmware_guestd not running? (check /var/run/vmware_guestd.pid).

Wasn't this added a year ago?  I remember because it broke a production
build system.  ;)

https://github.com/opnsense/tools/commit/6ee7188ebef 


CC jpaetzel


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD ports you maintain which are out of date

2018-06-26 Thread portscout 
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
math/rpy2   | 2.7.8   | 2.9.4
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Should a package restart on upgrade itself

2018-06-26 Thread Josh Paetzel 



On Tue, Jun 26, 2018, at 6:27 AM, Miroslav Lachman wrote:
> Miroslav Lachman wrote on 2017/06/27 19:32:
> > Matthias Fechner wrote on 2017/06/27 18:29:
> >> Dear all,
> >>
> >> it is always a pain if pkg upgrade a lot of packages to restart all
> >> services to make sure update/security fixes are applied to all running
> >> services.
> >>
> >> Is there an option in pkg that it restart services automatically or is
> >> it OK if I would add a post-install script to the packages (I maintain)
> >> that will include a "service foo restart"?
> >>
> >> What is best practice here?
> > 
> > Please don't do this.
> > Some ports did this in the past and this was really a pain during larger 
> > upgrades. It sometimes leave services stopped (hi MySQL).
> > 
> > The same bad practice is disabling / enabling Apache modules on upgrade.
> > 
> > pkg upgrade should just do it's work - upgrade packages on disk. But 
> > manipulating config files and restart of services is up to me - the 
> > Administrator (or my tools).
> > 
> > It would be nice to have some kind of "hooks" in pkg, which can be used 
> > to notify deployment tools that some services should be (re)started, or 
> > do restart in some simpler environment if user allows this (setup hooks 
> > for service restart).
> > But is must not be done automatically for individual ports / packages 
> > even if maintainer thinks it is Good Idea (tm)
> 
> Again and again and again...
> 
> Can we have some written (or do we have?) policy to not 
> stop/start/restart services from some @preunexec / @postexec targets?
> I really don't like that some packages are still shutting down or trying 
> to restart in the middle of the pkg upgrade process.
> 
> One example from today upgrade:
> 
> [87/96] Extracting open-vm-tools-nox11-10.2.5,2: .. done
> Stopping vmware_guestd.
> Waiting for PIDS: 516.
> Loading vmmemctl kernel module: already loaded.
> vmware_guestd not running? (check /var/run/vmware_guestd.pid).
> Starting vmware_guestd.
> 
> Can committers take care of this bad behaviour and not commit things 
> like this?
> https://svnweb.freebsd.org/ports/head/emulators/open-vm-tools/pkg-plist?revision=457485&view=markup
> 
> @preunexec %%PREFIX%%/bin/vmware-rpctool 'tools.set.version 0' ; service 
> vmware-guestd stop 2>/dev/null || /usr/bin/true
> @postexec service vmware-kmod restart && service vmware-guestd restart 
> || /usr/bin/true
> 
> Kind regards
> Miroslav Lachman
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Here's the diff for the commit you referenced:

https://svnweb.freebsd.org/ports/head/emulators/open-vm-tools/pkg-plist?r1=457023&r2=457485&pathrev=457485

Which part are you objecting to?

I don't really have any objections to changing open-vm-tools.  I'll note that I 
inherited it in it's current state with regards to defaults and restarting, an 
it's probably worth fining out why it does those things before blatantly 
changing things.

It's possible that open-vm-tools is a poor example of what you are talking 
about based on it providing services for the OS for running on VMWare versus 
running some application service or daemon , but I will have to think about 
this before taking a strongly held opinion.

-- 

Thanks,

Josh Paetzel
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Should a package restart on upgrade itself

2018-06-26 Thread Miroslav Lachman 

Franco Fichtner wrote on 2018/06/26 13:41:


On 26. Jun 2018, at 1:27 PM, Miroslav Lachman <000.f...@quip.cz 
> wrote:


One example from today upgrade:

[87/96] Extracting open-vm-tools-nox11-10.2.5,2: .. done
Stopping vmware_guestd.
Waiting for PIDS: 516.
Loading vmmemctl kernel module: already loaded.
vmware_guestd not running? (check /var/run/vmware_guestd.pid).


Wasn't this added a year ago?  I remember because it broke a production
build system.  ;)

https://github.com/opnsense/tools/commit/6ee7188ebef


Yes, this one is old and I have seen it many times before but today I 
have enough energy to post about it :)


Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Should a package restart on upgrade itself

2018-06-26 Thread Miroslav Lachman 

Josh Paetzel wrote on 2018/06/26 20:03:



On Tue, Jun 26, 2018, at 6:27 AM, Miroslav Lachman wrote:

Miroslav Lachman wrote on 2017/06/27 19:32:

Matthias Fechner wrote on 2017/06/27 18:29:

Dear all,

it is always a pain if pkg upgrade a lot of packages to restart all
services to make sure update/security fixes are applied to all running
services.

Is there an option in pkg that it restart services automatically or is
it OK if I would add a post-install script to the packages (I maintain)
that will include a "service foo restart"?

What is best practice here?


Please don't do this.
Some ports did this in the past and this was really a pain during larger
upgrades. It sometimes leave services stopped (hi MySQL).

The same bad practice is disabling / enabling Apache modules on upgrade.

pkg upgrade should just do it's work - upgrade packages on disk. But
manipulating config files and restart of services is up to me - the
Administrator (or my tools).

It would be nice to have some kind of "hooks" in pkg, which can be used
to notify deployment tools that some services should be (re)started, or
do restart in some simpler environment if user allows this (setup hooks
for service restart).
But is must not be done automatically for individual ports / packages
even if maintainer thinks it is Good Idea (tm)


Again and again and again...

Can we have some written (or do we have?) policy to not
stop/start/restart services from some @preunexec / @postexec targets?
I really don't like that some packages are still shutting down or trying
to restart in the middle of the pkg upgrade process.

One example from today upgrade:

[87/96] Extracting open-vm-tools-nox11-10.2.5,2: .. done
Stopping vmware_guestd.
Waiting for PIDS: 516.
Loading vmmemctl kernel module: already loaded.
vmware_guestd not running? (check /var/run/vmware_guestd.pid).
Starting vmware_guestd.

Can committers take care of this bad behaviour and not commit things
like this?
https://svnweb.freebsd.org/ports/head/emulators/open-vm-tools/pkg-plist?revision=457485&view=markup

@preunexec %%PREFIX%%/bin/vmware-rpctool 'tools.set.version 0' ; service
vmware-guestd stop 2>/dev/null || /usr/bin/true
@postexec service vmware-kmod restart && service vmware-guestd restart
|| /usr/bin/true

Kind regards
Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Here's the diff for the commit you referenced:

https://svnweb.freebsd.org/ports/head/emulators/open-vm-tools/pkg-plist?r1=457023&r2=457485&pathrev=457485

Which part are you objecting to?

I don't really have any objections to changing open-vm-tools.  I'll note that I 
inherited it in it's current state with regards to defaults and restarting, an 
it's probably worth fining out why it does those things before blatantly 
changing things.

It's possible that open-vm-tools is a poor example of what you are talking 
about based on it providing services for the OS for running on VMWare versus 
running some application service or daemon , but I will have to think about 
this before taking a strongly held opinion.


I am sorry, I was not talking about that revision. Only about @preunexec 
and @postexec. They were added in

https://svnweb.freebsd.org/ports/head/emulators/open-vm-tools/pkg-plist?r1=388693&r2=436703
https://svnweb.freebsd.org/ports/head/emulators/open-vm-tools/pkg-plist?r1=436816&r2=444773

Stopping / Restarting any service in the midle of running pkg upgrade is 
Bad Thing (in my point of view).
Note that "service vmware-kmod restart" is not doing what somebody may 
think it is - you end up with new version of vmware-guestd and old 
version of loaded kernel module, because it is not unloaded (and in 
situations like securelevel cannot be even loaded)


Kind regards
Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Should a package restart on upgrade itself

2018-06-26 Thread Adam 
On Tue, Jun 26, 2018 at 1:03 PM, Josh Paetzel  wrote:

>
> Here's the diff for the commit you referenced:
>
> https://svnweb.freebsd.org/ports/head/emulators/open-vm-
> tools/pkg-plist?r1=457023&r2=457485&pathrev=457485
>
> Which part are you objecting to?
>
> I don't really have any objections to changing open-vm-tools.  I'll note
> that I inherited it in it's current state with regards to defaults and
> restarting, an it's probably worth fining out why it does those things
> before blatantly changing things.
>
> It's possible that open-vm-tools is a poor example of what you are talking
> about based on it providing services for the OS for running on VMWare
> versus running some application service or daemon , but I will have to
> think about this before taking a strongly held opinion.
>

FWIW most daemon equivalent upgrades on Windows force you to chose to
restart after an upgrade.  There isn't a lot of precedent for automatic,
non-confirming restarts in server class software IME.

-- 
Adam
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

devel/qt5-core (qt5-core-5.9.4_2) (uninstall error)

2018-06-26 Thread Janos Dohanics 
Hello List,

When trying to update qt5-core-5.9.4_2, it failed:

# portversion -vR qt5-core-5.9.4_2
[Reading data from pkg(8) ... - 1001 packages found - done]
gettext-runtime-0.19.8.1_1  =  up-to-date with port 
glib-2.50.3_3,1 =  up-to-date with port 
icu-61.1,1  =  up-to-date with port 
pcre2-10.21_1   =  up-to-date with port 
qt5-core-5.9.4_2<  needs updating (port has 5.10.1_2) 
qtchooser-39=  up-to-date with port 

# portupgrade -vR qt5-core-5.9.4_2
[everything fine, until...]
> Compressing man pages (compress-man)
===>   Installing ldconfig configuration file
--->  Build of devel/qt5-core ended at: Tue, 26 Jun 2018 17:05:02 -0400 
(consumed 00:00:55)
--->  Updating dependency info
--->  Uninstallation of qt5-core-5.9.4_2 started at: Tue, 26 Jun 2018 17:05:02 
-0400
--->  Fixing up dependencies before creating a package
--->  Backing up the old version
pkg: file '/usr/local/lib/qt5/libQt5Core.so.5.9' is missing
--->  Uninstalling the old version
[Reading data from pkg(8) ... - 1001 packages found - done]
--->  Deinstalling 'qt5-core-5.9.4_2'
--->  Preserving /usr/local/lib/qt5/libQt5Core.so.5 as 
/usr/local/lib/compat/pkg/libQt5Core.so.5
cp: symlink: libQt5Core.so.5.9.4: File exists
Copy failed!
[Reading data from pkg(8) ... - 1001 packages found - done]
** Listing the failed packages (-:ignored / *:skipped / !:failed)
! qt5-core-5.9.4_2  (copy failed)
--->  Uninstallation of qt5-core-5.9.4_2 ended at: Tue, 26 Jun 2018 17:05:03 
-0400 (consumed 00:00:00)
--->  Upgrade of devel/qt5-core ended at: Tue, 26 Jun 2018 17:05:03 -0400 
(consumed 00:00:56)
--->  ** Upgrade tasks 1: 0 done, 0 ignored, 0 skipped and 1 failed
--->  Listing the results (+:done / -:ignored / *:skipped / !:failed)
! devel/qt5-core (qt5-core-5.9.4_2) (uninstall error)
--->  Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed
--->  Session ended at: Tue, 26 Jun 2018 17:05:03 -0400 (consumed 00:00:57)

# ls -al /usr/local/lib/qt5/libQt5Core*
-rw-r--r--  1 root  wheel 1040 May  5 21:58 
/usr/local/lib/qt5/libQt5Core.prl
lrwxr-xr-x  1 root  wheel   19 May  5 21:58 
/usr/local/lib/qt5/libQt5Core.so -> libQt5Core.so.5.9.4
lrwxr-xr-x  1 root  wheel   19 May  5 21:58 
/usr/local/lib/qt5/libQt5Core.so.5 -> libQt5Core.so.5.9.4
-rwxr-xr-x  1 root  wheel  5028000 May  5 21:58 
/usr/local/lib/qt5/libQt5Core.so.5.9.4

How can I fix this?

-- 
Janos Dohanics
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: devel/qt5-core (qt5-core-5.9.4_2) (uninstall error)

2018-06-26 Thread Eugene Grosbein 
27.06.2018 9:46, Janos Dohanics wrote:

> # ls -al /usr/local/lib/qt5/libQt5Core*
> -rw-r--r--  1 root  wheel 1040 May  5 21:58 
> /usr/local/lib/qt5/libQt5Core.prl
> lrwxr-xr-x  1 root  wheel   19 May  5 21:58 
> /usr/local/lib/qt5/libQt5Core.so -> libQt5Core.so.5.9.4
> lrwxr-xr-x  1 root  wheel   19 May  5 21:58 
> /usr/local/lib/qt5/libQt5Core.so.5 -> libQt5Core.so.5.9.4
> -rwxr-xr-x  1 root  wheel  5028000 May  5 21:58 
> /usr/local/lib/qt5/libQt5Core.so.5.9.4
> 
> How can I fix this?

Just remove symlinks and re-do the procedure.


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: devel/qt5-core (qt5-core-5.9.4_2) (uninstall error)

2018-06-26 Thread Janos Dohanics 
On Wed, 27 Jun 2018 09:55:42 +0700
Eugene Grosbein  wrote:

> 27.06.2018 9:46, Janos Dohanics wrote:
> 
> > # ls -al /usr/local/lib/qt5/libQt5Core*
> > -rw-r--r--  1 root  wheel 1040 May  5
> > 21:58 /usr/local/lib/qt5/libQt5Core.prl lrwxr-xr-x  1 root
> > wheel   19 May  5 21:58 /usr/local/lib/qt5/libQt5Core.so ->
> > libQt5Core.so.5.9.4 lrwxr-xr-x  1 root  wheel   19 May  5
> > 21:58 /usr/local/lib/qt5/libQt5Core.so.5 -> libQt5Core.so.5.9.4
> > -rwxr-xr-x  1 root  wheel  5028000 May  5
> > 21:58 /usr/local/lib/qt5/libQt5Core.so.5.9.4
> > 
> > How can I fix this?
> 
> Just remove symlinks and re-do the procedure.

Thank you, easy enough. Looks like a number of other of my qt5 ports
(perhaps all?) have the same problem when upgrading (qt5-script,
qt5-dbus, qt5-network, qt5-xmlpatterns-5.10.1...)

-- 
Janos Dohanics
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"