FreeBSD ports you maintain which are out of date

[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
+-+
devel/hgview| 1.6.2   | 1.8.1
+-+
www/webservices | 0.5.5   | 0.6.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
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

pkg-devel much slower than pkg?

[Stefan Esser]

On my -CURRENT system with 1572 ports installed, I decided to give
pkg-devel (pkg-1.3.0.b2) a try.

Using portmaster, I observe very significant increases in the time
required to check which ports to upgrade. With pkg-devel:

# time portmaster -a
===>>> Gathering distinfo list for installed ports

===>>> Starting check of installed ports for available updates

===>>> All ports are up to date

===>>> Exiting

real13m43.057s (= 823s)
user0m44.465s
sys 1m20.432s

The same command with pkg-1.2.7 needs less than 20% of the real
time to run:

real2m30.298s (= 150s)
user0m39.246s
sys 1m11.392s

It may be too early to expect pkg-1.3 to be optimized for speed,
but I just wanted to report this regression ...

Since the CPU times are not so different, it appears that the amount
of disk I/O is much higher with pkg-devel.

It might be possible to optimize the database structure or to cache
larger parts of the package DB in RAM (size is some 100MB on my system).

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

Re: ports/INDEX building broken on 11.0-CURRENT

[Warner Losh]

On May 13, 2014, at 5:04 PM, Don Lewis  wrote:

> On 13 May, To: po...@freebsd.org wrote:
>> Please excuse the crosspost.  I'm not sure if this is a ports problem or
>> a CURRENT problem.
>> 
>> I just updated my 11.0-CURRENT machine to r265940 and can no longer
>> build ports/INDEX-11.  My ports tree is r353903.  I think this problem
>> is being caused by the recent changes to /usr/share/mk/*.
>> 
>> # make index
>> Generating INDEX-11 - please wait..--- describe.accessibility ---
>> --- describe.arabic ---
>> --- describe.archivers ---
>> --- describe.astro ---
>> --- describe.audio ---
>> --- describe.benchmarks ---
>> --- describe.biology ---
>> --- describe.cad ---
>> --- describe.chinese ---
>> --- describe.comms ---
>> --- describe.converters ---
>> --- describe.databases ---
>> --- describe.deskutils ---
>> --- describe.devel ---
>> clang33: not found
>> make[5]: "/usr/share/mk/bsd.compiler.mk" line 24: warning: "clang33 
>> --version" returned non-zero status
>> make[5]: "/usr/share/mk/bsd.compiler.mk" line 37: Unable to determine 
>> compiler type for clang33.  Consider setting COMPILER_TYPE.
>> ===> devel/ccons failed
>> *** [describe.devel] Error code 1
>> 
>> make[2]: stopped in /usr/ports
>> 1 error
>> 
>> make[2]: stopped in /usr/ports
>> 
>> 
>> Before reporting this error, verify that you are running a supported
>> version of FreeBSD (see http://www.FreeBSD.org/ports/) and that you
>> have a complete and up-to-date ports collection.  (INDEX builds are
>> not supported with partial or out-of-date ports collections.
>> If that is the case, then
>> report the failure to po...@freebsd.org together with relevant
>> details of your ports configuration (including FreeBSD version,
>> your architecture, your environment, and your /etc/make.conf
>> settings, especially compiler flags and OPTIONS_SET/UNSET settings).
>> 
>> Note: the latest pre-generated version of INDEX may be fetched
>> automatically with "make fetchindex".
>> 
>> 
>> *** Error code 1
>> 
>> Stop.
>> make[1]: stopped in /usr/ports
>> *** Error code 1
>> 
>> Stop.
>> make: stopped in /usr/ports
>> 
>> 
>> If I go to the offending port:
>> 
>> # cd /usr/ports/devel/ccons/
>> # make describe
>> clang33: not found
>> make: "/usr/share/mk/bsd.compiler.mk" line 24: warning: "clang33 --version" 
>> returned non-zero status
>> make: "/usr/share/mk/bsd.compiler.mk" line 37: Unable to determine compiler 
>> type for clang33.  Consider setting COMPILER_TYPE.
>> 
>> 
>> I don't have any problems building the INDEX file on 9.3-PRERELEASE
>> r265940.
> 
> Various ports were setting CC to the following, which was causing the
> bsd.compiler.mk to barf:
>   clang32
>   clang33
>   /usr/bin/gcc
>   mingw32-gcc
>   gcc

Yea, the actual problem is that it assumed that the CC you’d set actually 
existed on the system. Not unreasonable in the building /usr/src context, but 
less reasonable in this context...

> The patch below allowed me to successfully run "make index" and reduced
> the error spewage.  It also greatly reduces the need to run
>   ${CC} --version
> in order to set COMPILER_TYPE.
> 
> It still seems like a great waste to run
>   ${CC} --version
> for each port to set COMPILER_VERSION since only a handful of ports need
> this information.

Unfortunately, you can’t do that. You must know the version of the compiler
in the bsd.*.mk system now. It is unfortunate that ports system users this
aspect of tree, or at least that it slows things down a bit.

> Then there is this sort of circular dependency in some ports, like this
> one in textproc/ibus/Makefile:
> 
> .if ${COMPILER_TYPE} == gcc && ${COMPILER_VERSION} < 46
> USE_GCC=yes
> .endif
> 
> This will cause CC to be redefined, but COMPILER_TYPE and
> COMPILER_VERSION will still retain their old values.

This suggests that ports might be better served by another mechanism, since 
this one doesn’t fit quite right….

> Index: share/mk/bsd.compiler.mk
> ===
> --- share/mk/bsd.compiler.mk  (revision 265940)
> +++ share/mk/bsd.compiler.mk  (working copy)
> @@ -21,23 +21,28 @@
> .if !target()
> :
> 
> -_v!= ${CC} --version
> .if !defined(COMPILER_TYPE)
> -. if ${CC:T:Mgcc*}
> +. if ${CC:T:M*gcc*}
> COMPILER_TYPE:=   gcc  
> -. elif ${CC:T:Mclang}
> +. elif ${CC:T:Mclang*}
> COMPILER_TYPE:=   clang
> -. elif ${_v:Mgcc}
> +. else
> +_v!= ${CC} --version
> +.  if ${_v:Mgcc}
> COMPILER_TYPE:=   gcc
> -. elif ${_v:M\(GCC\)}
> +.  elif ${_v:M\(GCC\)}
> COMPILER_TYPE:=   gcc
> -. elif ${_v:Mclang}
> +.  elif ${_v:Mclang}
> COMPILER_TYPE:=   clang
> -. else
> +.  else
> .error Unable to determine compiler type for ${CC}.  Consider setting 
> COMPILER_TYPE.
> +.  endif
> . endif
> .endif
> .if !defined(COMPILER_VERSION)
> +. if !defined(_v)
> +_v

Re: pkg-devel much slower than pkg?

[Baptiste Daroussin]

On Fri, May 23, 2014 at 12:38:06PM +0200, Stefan Esser wrote:
> On my -CURRENT system with 1572 ports installed, I decided to give
> pkg-devel (pkg-1.3.0.b2) a try.
> 
> Using portmaster, I observe very significant increases in the time
> required to check which ports to upgrade. With pkg-devel:
> 
> # time portmaster -a
> ===>>> Gathering distinfo list for installed ports
> 
> ===>>> Starting check of installed ports for available updates
> 
> ===>>> All ports are up to date
> 
> ===>>> Exiting
> 
> real13m43.057s (= 823s)
> user0m44.465s
> sys 1m20.432s
> 
> The same command with pkg-1.2.7 needs less than 20% of the real
> time to run:
> 
> real2m30.298s (= 150s)
> user0m39.246s
> sys 1m11.392s
> 
> It may be too early to expect pkg-1.3 to be optimized for speed,
> but I just wanted to report this regression ...
> 
> Since the CPU times are not so different, it appears that the amount
> of disk I/O is much higher with pkg-devel.
> 
> It might be possible to optimize the database structure or to cache
> larger parts of the package DB in RAM (size is some 100MB on my system).
> 

This is a regression introduced during b1 -> b2 dev, we are working on it.

regards,
Bapt


pgptGgPT5a3I1.pgp
Description: PGP signature

[CURRENT] x11/nvidia-driver: nvidia_linux.c:42:37: error: incompatible integer to pointer conversion passing 'unsigned long long' to parameter of type 'cap_rights_t *'

[O. Hartmann]

On 11.0-CURRENT, sources r266594, I get this error when tryong to compile port
x11/nvidia-driver:

nvidia_linux.c:42:37: error: incompatible integer to pointer conversion passing 
'unsigned
long long' to parameter of type 'cap_rights_t *' (aka 'struct cap_rights *')
[-Werror,-Wint-conversion] if ((error = fget(td, args->fd, CAP_IOCTL, &fp)) != 
0)


signature.asc
Description: PGP signature

[QAT] 354958: 4x leftovers

[Ports-QAT]

- Stage support
- USES=libtool
- Use new LIB_DEPENDS format
- Create database directory during startup rather than in the package

PR: ports/189769
Submitted by:   Krzysztof Stryjek 
-

  Build ID:  20140523193400-58433
  Job owner: t...@freebsd.org
  Buildtime: 104 minutes
  Enddate:   Fri, 23 May 2014 21:17:37 GMT

  Revision:  354958
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=354958

-

Port:net-mgmt/collectd 4.10.9_7

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~t...@freebsd.org/20140523193400-58433-336630/collectd-4.10.9_7.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~t...@freebsd.org/20140523193400-58433-336631/collectd-4.10.9_7.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~t...@freebsd.org/20140523193400-58433-336632/collectd-4.10.9_7.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~t...@freebsd.org/20140523193400-58433-336633/collectd-4.10.9_7.log


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

postfix-policyd-weight broken with p5-Net-DNS 0.75

[Herbert J. Skuhra]

Hi,

after updating p5-Net-DNS from version 0.74 to 0.75
postfix-policyd-weight (0.1.15.2) stopped working.

I get the below error on two systems:

May 23 13:31:35 mx postfix/policyd-weight[1037]: child: spawned 
May 23 13:31:35 mx postfix/policyd-weight[1037]: warning: child: err: Undefined 
subroutine &main::dn_expand called at /usr/local/bin/policyd-weight line 3590, 
 line 23.  
May 23 13:31:36 mx postfix/policyd-weight[908]: master: child 1037 exited 

I am using perl 5.16.3 on FreeBSD 8.4-RELEASE-p10 (amd64) and perl
5.18.2 on FreeBSD 10.0-STABLE (i386).

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

Re: ACTION REQUIRED - Unstaged Ports being DEPRECATED on June 31st.

[Kubilay Kocak]

On 13/05/2014 4:49 AM, Melvyn Sopacua wrote:
>
>
> On Mon, 12 May 2014, John Marino wrote:
>
>> I commit PR patches that are 6 to 18 months old fairly frequently.
>> There is obviously a huge backlog but many PRs are processed daily.  The
>> PRs that aren't getting processed quickly are "[NEW PORT]" PRs (and
>> apparently anything mentioning fuse-fs for some reason).  A staging PR
>> is going to jump the line; it has a higher priority.
>>
>> Why would you even entertain the idea that a staging PR will fall
>> between the cracks?
>
> Perhaps the better question is: what are the factors that will make
> committers shy away from a PR, even if it's summary contains stage? [1]
> Maybe we (maintainers) can do better?

That *is* a great question Melvyn, and one I imagine many maintainers
have thought about. We have a ways to go in developing a proactive
coaching & mentoring culture in FreeBSD, and with that in mind to start
a conversation, here's a few things that come to mind that show me a PR
might warrant special attention given limited time & resources:

- A PR with a patch, with [patch] prefixed in the summary

These are easy to identify when skimming with little effort, and shows
intent and initiative from the submitter.

- Build logs or URL's (eg: poudriere, redports) showing build OK

This shows the submitter groks the effort required at the other end, and
again initiative in arming a committer with the information they might
need to get it done. These prelim QA steps also identify easy issues
early in the process, helping to up-skill the submitter, developing them
for greater contributions, and ultimately saves time in any potential
back and forth.

- porttools, portlint, port test, test port, stage, DEV_MODE = OK (even
just showing these steps have been run)

Again, basic proactive QA. Shows an understanding of the tools and steps
involved, and a regard for quality over quantity or personal benefit
only. Seeing that these steps have been already been run makes it easier
to choose one PR over another that hasn't, even if we're going to run
them again anyway.

- Proposed commit log with explanations of non-obvious changes.

This provides an insight and information to help assess/review your
changes with additional context, to ensure that what you intended to do
is what you actually achieved. It also opens the door for exposing the
submitter to conventions or process changes within the Project they may
not yet be aware of. It also means we don't need to write it.

- Be vocal. Follow-up, Ask questions, Don't wait. Don't give up. The
question is always "What's left before this can be committed?" and "What
would I need to see if I were to take on this work?" Help answer those
questions and you position your contributions in the best light for action.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Can you please close ports/184033 and ports/189749

[Alan Hicks]

Can you please close ports/184033 and ports/189749 as they have been 
superseded by Revision 354447.


Alas I forgot to include [patch] in the subject or that I had tested 
under poudriere so they understandably got missed.


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