Re: FreeBSD Port: mp4v2-1.9.1_1

2016-09-16 Thread Kevin Oberman 
Oops.Forgot the URL. https://github.com/TechSmith/mp4v2/releases

Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

On Fri, Sep 16, 2016 at 9:18 PM, Kevin Oberman  wrote:

> On Fri, Sep 16, 2016 at 5:47 PM, Michael  wrote:
>
>> Port is marked as broken :(
>>
>>
>>
>> please fix this see
>> https://www.freebsd.org/cgi/ports.cgi?query=^mp4v2-1.9.1_1
>> 
>> =name
>>
>
> The port was housed on Google Code which is longer exists. There is a
> version on gifhub that is at 3.0.1.1 while the current FreeBSD version is
> 1.9.1. It may take a bit of work to update the port to that version. If I
> get some time, I will give it a try, but I have not written or updated a
> port in a long time, so, if someone else wants to give it a shot (maybe
> you), go for it.
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
___
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: FreeBSD Port: mp4v2-1.9.1_1

2016-09-16 Thread Kevin Oberman 
On Fri, Sep 16, 2016 at 5:47 PM, Michael  wrote:

> Port is marked as broken :(
>
>
>
> please fix this see
> https://www.freebsd.org/cgi/ports.cgi?query=^mp4v2-1.9.1_1
> 
> =name
>

The port was housed on Google Code which is longer exists. There is a
version on gifhub that is at 3.0.1.1 while the current FreeBSD version is
1.9.1. It may take a bit of work to update the port to that version. If I
get some time, I will give it a try, but I have not written or updated a
port in a long time, so, if someone else wants to give it a shot (maybe
you), go for it.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: Checking port option descriptions

2016-09-16 Thread Kevin Oberman 
On Fri, Sep 16, 2016 at 3:42 PM,  wrote:

> On Fri, 16 Sep 2016 15:11:51 -0400, Jim Ohlstein 
> wrote:
>
> >"[S]ome" being the operative word here. I don't disagres with your basic
> >premise, but the truth is, at the end of the day it's up to the user to
> >understand the consequences of his decisions. If a user doesn't know
> >what 'XYZ' is, then adding 'Include protocols for use with XYZ servers'
> >probably doesn't tell him or her that much. On the other hand, if a user
> >knows what 'XYZ' is, then 'Enable XYZ' is likely enough information with
> >which to make a decision.
> >
> >So in this case there are likely to be two categories of users: those
> >who know what 'XYZ' is and those who do not. Those in the former have
> >the information either way. Those in the latter have three basic choices:
> >
> >1) Educate themselves before possibly adding software to their system
> >that they do not fully understand, thereby moving into to the former
> >category.
> >
> >2) Choose the default, on the (very possibly mistaken) assumption that
> >the porter "knows what's best." Unfortunately that assumption may be a
> >bad one, as the porter/maintainer is more likely to choose something
> >that satisfies "most users" and loads people with unnecessary
> >dependencies (thus defeating much of the benefit of building your own
> >ports), or worse, to choose options that work best for him or her.
>
> Most people want to *use* the machine they're integrating.  For
> them it's not a pastime or hobby.
>
> Very few such people have the time or energy to "educate
> themselves" enough to understand the interactive effects of the
> many MANY options for each of the ports they want to install.
>
> In part, that's due to the useless "comments" Warren rightly
> calls out in his post.  So yes, in hope of being safe, they'll
> accept the defaults.  With real, thoughtful, information-rich
> comments, that might actually happen less often.
>
> The same problem affects software development and causes a lot of
> code to be re-written from scratch rather than maintained.  Told
> to comment their code, too many programmers write things like "
> x=x+1 ; // increment x" and are baffled when more experienced
> engineers are scathing during code review.  After all, they did
> comment each line, so what's the problem?  If people want to
> understand what the code does, they should study it!
>

While I agree that you can't hope to fully cover the meaning of the each
option, some clue as to what it means if just so we can know where to look
for more information. Some items are both hard to describe briefly and not
worth the effort. E.g. the long list of available codecs and formats. What
can you hope to say about inclusion of speex or x264 in the available
space? On the other hand, what the heck is VDPAU? (Yes, I know, but lots of
people don't). Also, if an option has licensing implications, that's
important to many, but seldom mentioned.

Even when the meaning is clear in  global sense, what are the implications
for an application. E.g. "RTC=on: Add support for kernel real time clock"
in mplayer. I know exactly what the RTC is, but I have no idea why I might
or might not want it in mplayer.

No, I don't know the best thing in many cases, but I can assure you that
the defaults, while usually a good choice, are sometimes not. A prime
example is optimization. It is almost always desirable, but is usually not
default so that the package can be run on any hardware.

I have no answers, but it's not easy or clear-cut, but there is clearly
room for improvement.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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 Port: mp4v2-1.9.1_1

2016-09-16 Thread Michael 
Port is marked as broken :(

 

please fix this see
https://www.freebsd.org/cgi/ports.cgi?query=^mp4v2-1.9.1_1

=name

 

regards,

michael

___
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"

Dehydrated

2016-09-16 Thread Jos Chrispijn 


After switching from letsencrypt to dehydrated, the upgrade to the 
latest port version keeps appearing when running


portmaster -y --clean-distfiles
portmaster -y --clean-packages
portmaster -y --check-depends
portmaster -a

although there is no port update of it available.

Apperantly there is something outta sync**:


===>>> Gathering distinfo list for installed ports
===>>> Starting check of installed ports for available updates
===>>> The security/letsencrypt.sh port moved to 
security/dehydrated

===>>> Reason: Upstream renamed the project

===>>> Launching child to reinstall letsencrypt.sh-0.3.0
===>>> All >> letsencrypt.sh-0.3.0 (1/1) **
===>>> The security/letsencrypt.sh port moved to 
security/dehydrated

===>>> Reason: Upstream renamed the project

===>>> Currently installed version: dehydrated-0.3.1
===>>> Port directory: /usr/ports/security/dehydrated
===>>> Launching 'make checksum' for security/dehydrated in background
===>>> Gathering dependency list for security/dehydrated from ports
===>>> Initial dependency check complete for security/dehydrated

===>>> Returning to update check of installed ports

===>>> All >> (1)

===>>> The following actions will be taken if you choose to proceed:
Re-install dehydrated-0.3.1

Can someone tell me how to solve this? Thanks!

regards,
Jos Chrispijn

___
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: Checking port option descriptions

2016-09-16 Thread scratch65535 
On Fri, 16 Sep 2016 15:11:51 -0400, Jim Ohlstein 
wrote:

>"[S]ome" being the operative word here. I don't disagres with your basic 
>premise, but the truth is, at the end of the day it's up to the user to 
>understand the consequences of his decisions. If a user doesn't know 
>what 'XYZ' is, then adding 'Include protocols for use with XYZ servers' 
>probably doesn't tell him or her that much. On the other hand, if a user 
>knows what 'XYZ' is, then 'Enable XYZ' is likely enough information with 
>which to make a decision.
>
>So in this case there are likely to be two categories of users: those 
>who know what 'XYZ' is and those who do not. Those in the former have 
>the information either way. Those in the latter have three basic choices:
>
>1) Educate themselves before possibly adding software to their system 
>that they do not fully understand, thereby moving into to the former 
>category.
>
>2) Choose the default, on the (very possibly mistaken) assumption that 
>the porter "knows what's best." Unfortunately that assumption may be a 
>bad one, as the porter/maintainer is more likely to choose something 
>that satisfies "most users" and loads people with unnecessary 
>dependencies (thus defeating much of the benefit of building your own 
>ports), or worse, to choose options that work best for him or her.

Most people want to *use* the machine they're integrating.  For
them it's not a pastime or hobby.  

Very few such people have the time or energy to "educate
themselves" enough to understand the interactive effects of the
many MANY options for each of the ports they want to install.   

In part, that's due to the useless "comments" Warren rightly
calls out in his post.  So yes, in hope of being safe, they'll
accept the defaults.  With real, thoughtful, information-rich
comments, that might actually happen less often.

The same problem affects software development and causes a lot of
code to be re-written from scratch rather than maintained.  Told
to comment their code, too many programmers write things like "
x=x+1 ; // increment x" and are baffled when more experienced
engineers are scathing during code review.  After all, they did
comment each line, so what's the problem?  If people want to
understand what the code does, they should study it!
___
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: Checking port option descriptions

2016-09-16 Thread Jim Ohlstein 

Hello,

On 09/16/2016 11:52 AM, Warren Block wrote:

Ports options ask the user to make a decision on whether to enable that
option.  Option descriptions are critical for this, giving the user
information to help them make that decision.

Unfortunately, what is clear to the porter is often not clear to a user.
The Porter's Handbook says "Do not just repeat the name", but this still
happens, either exactly, or with a description that adds no information.

For example:

  XYZEnable XYZ

The description here adds no information. The name of the option itself
tells the reader that this is for enabling or disabling a feature. The
option asks them to make a decision, whether to enable that option or
not, or even just to leave it at the default, but does not give them any
help in making that decision. Let's improve that:

  XYZInclude protocols for use with XYZ servers

This gives the reader some additional details.


"[S]ome" being the operative word here. I don't disagres with your basic 
premise, but the truth is, at the end of the day it's up to the user to 
understand the consequences of his decisions. If a user doesn't know 
what 'XYZ' is, then adding 'Include protocols for use with XYZ servers' 
probably doesn't tell him or her that much. On the other hand, if a user 
knows what 'XYZ' is, then 'Enable XYZ' is likely enough information with 
which to make a decision.


So in this case there are likely to be two categories of users: those 
who know what 'XYZ' is and those who do not. Those in the former have 
the information either way. Those in the latter have three basic choices:


1) Educate themselves before possibly adding software to their system 
that they do not fully understand, thereby moving into to the former 
category.


2) Choose the default, on the (very possibly mistaken) assumption that 
the porter "knows what's best." Unfortunately that assumption may be a 
bad one, as the porter/maintainer is more likely to choose something 
that satisfies "most users" and loads people with unnecessary 
dependencies (thus defeating much of the benefit of building your own 
ports), or worse, to choose options that work best for him or her.


3) Ask themselves Harry Callahan's famous question, "Do I feel lucky?" 
and go away from the default.





Because so many of the option descriptions have predictable
no-added-information styles, it is possible to write a program that
detects these. In the process of doing that, I found some actual bugs in
descriptions that were not caught by other parts of the ports build or
portlint.

The program is called optcheck and can be found here:
  http://www.wonkity.com/~wblock/tmp/optcheck/

The readme.txt explains a little more, and optcheck-output.txt is a full
run against the ports tree from a couple of weeks ago.

The tests are just some that I came up with quickly, and can certainly
be improved. More can be added, and they can make better suggestions.
Ultimately, the hope is that this functionality will be added to
portlint or somewhere else that would help prevent these types of
pointless descriptions.

For usage, run
  optcheck -h

For a run against the full ports tree, use just
  optcheck

To run against a category or single port directory, use -d:
  optcheck -d /usr/ports/devel
  optcheck -d /usr/ports/print/ghostscript9-base



--
Jim Ohlstein
___
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"

Checking port option descriptions

2016-09-16 Thread Warren Block 

Ports options ask the user to make a decision on whether to enable that
option.  Option descriptions are critical for this, giving the user
information to help them make that decision.

Unfortunately, what is clear to the porter is often not clear to a user.
The Porter's Handbook says "Do not just repeat the name", but this still
happens, either exactly, or with a description that adds no information.

For example:

  XYZEnable XYZ

The description here adds no information. The name of the option itself
tells the reader that this is for enabling or disabling a feature. The
option asks them to make a decision, whether to enable that option or
not, or even just to leave it at the default, but does not give them any
help in making that decision. Let's improve that:

  XYZInclude protocols for use with XYZ servers

This gives the reader some additional details.


Because so many of the option descriptions have predictable
no-added-information styles, it is possible to write a program that
detects these. In the process of doing that, I found some actual bugs in
descriptions that were not caught by other parts of the ports build or
portlint.

The program is called optcheck and can be found here:
  http://www.wonkity.com/~wblock/tmp/optcheck/

The readme.txt explains a little more, and optcheck-output.txt is a full
run against the ports tree from a couple of weeks ago.

The tests are just some that I came up with quickly, and can certainly 
be improved. More can be added, and they can make better suggestions. 
Ultimately, the hope is that this functionality will be added to 
portlint or somewhere else that would help prevent these types of 
pointless descriptions.


For usage, run
  optcheck -h

For a run against the full ports tree, use just
  optcheck

To run against a category or single port directory, use -d:
  optcheck -d /usr/ports/devel
  optcheck -d /usr/ports/print/ghostscript9-base


___
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

2016-09-16 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
+-+
textproc/ansifilter | 1.7 | 2.2
+-+


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"