Overriding binary package with local build

[heasley]

If one builds a package from ports in order to use different options, for
example building with postgres support instead of mysql, or builds a
specific version, but otherwise utilizes binary packages, how is this
indicated to 'pkg upgrade'?

For example.  On this system I've built gld with postgres instead of mysql
and postfix with another option.  The mysql dependency is coming from the
binary gld with the default options.  And, in theory postfix has different
options, but also needs an update.

So, is it possible to tell pkg(8) about the different options/local built,
but still complain when a version update is necessary?

# pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
...

New packages to be INSTALLED:
mysql56-client: 5.6.23

Installed packages to be UPGRADED:
postgresql94-server: 9.4.0 -> 9.4.1
postgresql94-client: 9.4.0 -> 9.4.1_1
postfix: 2.11.3_4,1 -> 2.11.4,1

Installed packages to be REINSTALLED:
gld-1.8_2 (options changed)

...
___
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: Overriding binary package with local build

[Matthew Seaman]

On 03/09/15 09:43, heasley wrote:
> If one builds a package from ports in order to use different options, for
> example building with postgres support instead of mysql, or builds a
> specific version, but otherwise utilizes binary packages, how is this
> indicated to 'pkg upgrade'?
> 
> For example.  On this system I've built gld with postgres instead of mysql
> and postfix with another option.  The mysql dependency is coming from the
> binary gld with the default options.  And, in theory postfix has different
> options, but also needs an update.
> 
> So, is it possible to tell pkg(8) about the different options/local built,
> but still complain when a version update is necessary?
> 
> # pkg upgrade
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up-to-date.
> All repositories are up-to-date.
>   ...
> 
> New packages to be INSTALLED:
> mysql56-client: 5.6.23
> 
> Installed packages to be UPGRADED:
> postgresql94-server: 9.4.0 -> 9.4.1
> postgresql94-client: 9.4.0 -> 9.4.1_1
> postfix: 2.11.3_4,1 -> 2.11.4,1
> 
> Installed packages to be REINSTALLED:
> gld-1.8_2 (options changed)

The best way I've found of doing this is to set up a local poudriere
instance to build the packages you want to customize, plus anything
that depends directly on them.  You can then set your local pkgrepo as
higher priority than the main FreeBSD repo in
/usr/local/etc/pkg/repos/foo.conf.  You might also want
'CONSERVATIVE_UPGRADE=yes' in /usr/local/etc/pkg.conf

A poudriere setup for building just a few packages doesn't need a whole
lot of system resources.  You'll need to tune poudriere.conf so it
doesn't try and max out usage of everything -- maybe limit it to a
single builder.  You can serve the packages it builds either by HTTP, or
if everything is all on the same machine, you can just use a
file:/// URL in your repo conf.

Cheers,

Matthew





signature.asc
Description: OpenPGP digital signature

Re: How could I increase "runaway" timer for package build cluster?

[Lev Serebryakov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08.03.2015 12:40, Ben Woods wrote:
> Actually, taking a look at my /usr/local/etc/poudriere.conf 
> configuration file, I see these settings have indeed been exposed
> for configuration there without having to touch the poudriere code
> itself. The appropriate settings are:
> 
> # This defines the max time (in seconds) that a command may run for
> a build # before it is killed for taking too long. Default: 86400 
> #MAX_EXECUTION_TIME=86400
> 
> # This defines the time (in seconds) before a command is considered
> to # be in a runaway state for having no output on stdout. Default:
> 7200 #NOHANG_TIME=7200

 The problem is, it is not my cluster, but FreeBSD official cluster. I
could not change configs of it, I could only edit Makefile of my port.


- -- 
// Lev Serebryakov AKA Black Lion
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJU/X/sXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePTfEP/RZ+mpm4KR3ThMQsal/Aifgg
d3iPz4mud6eFOeZkLzJCQplB7yWRDz12FUXY7VXx3gAqvbaNL9uEwYLhuOg7UKpS
F3VeIZEl8GrBj3gO6ZtuVT+Gg4TUVMggmWuy64u73M/n+xLrsKjCKM17kyv4DpKq
hYLEvJTLwWMox0l38c0/ETp6CVSqtAv5r+PE+gQZMTgH+RDufdv71Dsy3pbkJL2z
M09dy9MLLa7FbfirCNh2kVSv6BHBMPxuuWntCHbs2vw619mvpf8OlNil/tt5/mip
bpU0b154aNcFrXpGAZcfmFaZRBwS4XEaD70tRbnJZjleOJoDbYIRJp6Fg17ABjxs
43YumxZlwHYEABbpR4DQnUHxSeykpf3D8fcRSMD/29nHbESHcpJoscO7wvz3nP8Q
Vi7pYkAJodGdhSWpHpgu/KfVGexoZgngkQPQ7/2FKR6D7Pm+wC3ilxhSRNDAJlkd
F/smVWCJNrd61a64d8BTA21xeQCRQch/YXS6YpAdhSR1Y10uZuqhvugVzzv8J9S9
JRGC1PD3DoV2FjY1GK6ncP229OG06QOnqrvPp+Yg+rhlnLseNpqVh6e3Ja/rJWZ1
AWvecKGcAwSh6dhugBZ5BoPaZ8sRlF9ZD2QXW6nXDO1+EpoZK/rLTq1Z6pHL6/mD
5HYU5/UWCzoaLaIQBlwg
=v5fn
-END PGP SIGNATURE-
___
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: How could I increase "runaway" timer for package build cluster?

[Matthew Seaman]

On 03/09/15 11:11, Lev Serebryakov wrote:
> On 08.03.2015 12:40, Ben Woods wrote:
>> Actually, taking a look at my /usr/local/etc/poudriere.conf 
>> configuration file, I see these settings have indeed been exposed
>> for configuration there without having to touch the poudriere code
>> itself. The appropriate settings are:
> 
>> # This defines the max time (in seconds) that a command may run for
>> a build # before it is killed for taking too long. Default: 86400 
>> #MAX_EXECUTION_TIME=86400
> 
>> # This defines the time (in seconds) before a command is considered
>> to # be in a runaway state for having no output on stdout. Default:
>> 7200 #NOHANG_TIME=7200
> 
>  The problem is, it is not my cluster, but FreeBSD official cluster. I
> could not change configs of it, I could only edit Makefile of my port.

I added a small change to make 'pkg create' emit a progress bar which
will be in pkg-1.15 -- you have to tweak some settings in pkg.conf to
enable it though.  With this change I've managed to avoid poudriere
timeouts while packaging stuff with large numbers of files --
texlive-texmf being a classic example.  You can try it now by installing
net-mgmt/pkg-devel, but beware that will eventually cause all your
client machines to end up running pkg-devel too.

Cheers,

Matthew







signature.asc
Description: OpenPGP digital signature

Maven 3.2.5

[Alexander Yerenkow]

Could someone from committers take a look at port?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188110

Thanks.

-- 
Regards,
Alexander Yerenkow
___
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: Overriding binary package with local build

[Mike Clarke]

On Mon, 9 Mar 2015 09:43:24 +
heasley  wrote:

> For example.  On this system I've built gld with postgres instead of mysql
> and postfix with another option.  The mysql dependency is coming from the
> binary gld with the default options.  And, in theory postfix has
> different options, but also needs an update.

pkg lock gld

This will prevent gld from being updated by pkg but it will also
prevent you from installing it when you rebuild it so you will need to
unlock it for the duration while you're building it. See pkg-lock(8).

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

[SUGGESTED FEATURE] USE_SVNREPO allows to build the port using only subversion repository URL

[Yuri]

I came across one package which doesn't distribute source tarballs, and 
only offers subversion URL. I implemented the new feature USE_SVNREPO 
that allows to build the port in such setup. Here is what it does:

* exports source from the subversion repository for specified URL/revision
* resets the timestamp of every file and directory to 1970-01-01 for 
reproducibility

* creates tarball

Patch adding this feature is attached to this bug report: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198449


Yuri
___
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: pkgng deviates from defaults?

[Carsten Jensen]

On 03/08/2015 02:41 PM, Baptiste Daroussin wrote:

On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote:


It seems that pkgng deviates from installing the defaults.
one of the culprits seems to be phpMyAdmin, as trying to upgrade this
only it wants php56
deleting phpMyAdmin just shows I have other packages needing php56 in my
system.

is this a bug? and how can I prevent upgrading to the non-default php56?


The default settings are a ports tree setting not a pkg setting. for now the
ports are hardcoding the required version into the packages, this is a legacy of
the old system, noone has yet been working on this. so beside building your own
packages with poudriere (which will define the default you want) righ now there
is no way to avoid that.

The php case but not only php will require small changes in pkg(8) to activate
smart dependencies: depend on a>1<=2.10 and also adding provides/requires (this
is not very hard to be added in pkg.) and it should also require heavy changes
on the port side!

As far as I know noone has been working on those changes in the port side. the
pkg(8) changes are mostly pending for real use cases in the port side. Meaning
both should be coordinated.

Best regards,
Bapt



Sorry I don't think I was clear.
Some applications wants php5 and some applications wants php56 when 
upgrading using pkg-ng.
Using pkg-ng one cannot upgrade i.e. both phpMyAdmin and an other web 
based application due to this conflict.


So while the upgrade happens to upgrade to php56 it also removes the 
other web application, as it only wants php5.


Most of the applications on the server is maintained by pkg-ng, and it 
conflicts itself.


Basically there are now 2 "default" php versions used by pkg-ng
meaning, _I_ am not trying to upgrade to php56, pkg-ng does but it also 
tries to upgrade php5.


I can't find any hardcode to php56 in the Makefile of databases/phpmyadmin

I don't know if this is expressed better, I hope so atleast.


Cheers
Carsten



___
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: pkgng deviates from defaults?

[Chris H]

On Mon, 09 Mar 2015 13:23:11 +0100 Carsten Jensen  wrote

> On 03/08/2015 02:41 PM, Baptiste Daroussin wrote:
> > On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote:
> >>
> >> It seems that pkgng deviates from installing the defaults.
> >> one of the culprits seems to be phpMyAdmin, as trying to upgrade this
> >> only it wants php56
> >> deleting phpMyAdmin just shows I have other packages needing php56 in my
> >> system.
> >>
> >> is this a bug? and how can I prevent upgrading to the non-default php56?
> >
> > The default settings are a ports tree setting not a pkg setting. for now
> > the ports are hardcoding the required version into the packages, this is a
> > legacy of the old system, noone has yet been working on this. so beside
> > building your own packages with poudriere (which will define the default
> > you want) righ now there is no way to avoid that.
> >
> > The php case but not only php will require small changes in pkg(8) to
> > activate smart dependencies: depend on a>1<=2.10 and also adding
> > provides/requires (this is not very hard to be added in pkg.) and it should
> > also require heavy changes on the port side!
> >
> > As far as I know noone has been working on those changes in the port side.
> > the pkg(8) changes are mostly pending for real use cases in the port side.
> > Meaning both should be coordinated.
> >
> > Best regards,
> > Bapt
> >
> 
> Sorry I don't think I was clear.
> Some applications wants php5 and some applications wants php56 when 
> upgrading using pkg-ng.
> Using pkg-ng one cannot upgrade i.e. both phpMyAdmin and an other web 
> based application due to this conflict.
> 
> So while the upgrade happens to upgrade to php56 it also removes the 
> other web application, as it only wants php5.
> 
> Most of the applications on the server is maintained by pkg-ng, and it 
> conflicts itself.
> 
> Basically there are now 2 "default" php versions used by pkg-ng
> meaning, _I_ am not trying to upgrade to php56, pkg-ng does but it also 
> tries to upgrade php5.
> 
> I can't find any hardcode to php56 in the Makefile of databases/phpmyadmin
> 
> I don't know if this is expressed better, I hope so atleast.
You might be able to avoid the issue you're having, by using:
DEFAULT_VERSIONS+=php=5.5
in your make.conf(5) (/etc/make.conf) file.
Check to see if you already have a DEFAULT_VERSIONS line there.
If not simply add
DEFAULT_VERSIONS+=php=5.5
you your make.conf file. If the line already exists, it is
a space separated list. So simply append it to the list thusly
DEFAULT_VERSIONS+=mysql=5.5 php=5.5
assuming that the entry mysql=5.5 was already listed.

HTH

--Chris
> 
> 
> Cheers
> Carsten
> 
> 
> 
> ___
> 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"


___
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: CFT: vlc 2.2.0

[Fabian Keil]

Juergen Lock  wrote:

>  I just saw vlc 2.2.0 is out and updated the port, please test:
> 
>   https://people.freebsd.org/~nox/tmp/vlc-2.2.0-001.patch

Thanks for the update.

I get a couple of warnings at build time:

configure: WARNING: unrecognized options: --disable-egl, --disable-libvnc, 
--disable-quicksync, --enable-dirac, --enable-glx, --with-qt-includes, 
--with-qt-libraries, --with-extra-includes, --with-extra-libs
[...]
> Running Q/A tests (stage-qa)
Warning: 'lib/vlc/plugins/codec/libtheora_plugin.so' is not stripped consider 
trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
[... same message for the other plugins ]

The installed binary seems to mostly work as expected.

The only regression I noticed so far is that vlc doesn't get the final window
size right when it's started with a video file specified on the command line:
https://www.fabiankeil.de/bilder/screenshots/vlc/vlc-2.2.0-001-rendering-flaw.jpg

After going to fullscreen and back again (for example by hitting f twice)
vlc uses the expected window size. Moving the window around has the same effect.
Loading the video through the GUI seems to work around the problem as well.

I'm using a tiling window manager (i3) which could be part of the problem
and I wouldn't be surprised if the problem was OS-independent.

Fabian


pgp__gCXW_quL.pgp
Description: OpenPGP digital signature

Re: pkgng deviates from defaults?

[Mike Clarke]

On Mon, 09 Mar 2015 07:04:30 -0700
"Chris H"  wrote:

> You might be able to avoid the issue you're having, by using:
> DEFAULT_VERSIONS+=php=5.5
> in your make.conf(5) (/etc/make.conf) file.

As far as I know this won't have any effect on pkg.

If the OP wishes to use pkg then the only option is to switch to using
php5.6. This will involve uninstalling all the php5.5 packages and
reinstalling default php5.6 versions. I went through this process
recently and described the steps involved in questions@


-- 
Mike Clarke
___
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: powerpc64 10.1-STABLE [WITH_DEBUG] context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it

[Mark Millard]

I've discovered why/how WITH_DEBUG= ends up with cmake's /usr/local/bin/ctest 
messed up for PIC code generation (powerpc64 context). A source code fix that 
avoids the problem is likely to change cmake's hashtable.hxx that has

inline size_t _stl_next_prime(size_t __n)
{
  const unsigned long* __first = get_stl_prime_list();
  const unsigned long* __last = get_stl_prime_list() + (int)_stl_num_primes;
  const unsigned long* pos = cmsys_stl::lower_bound(__first, __last, __n);
  return pos == __last ? *(__last - 1) : *pos;
}

to also indicate static for it like the .hxx file has for

static inline const unsigned long* get_stl_prime_list() {

static const unsigned long _stl_prime_list[_stl_num_primes] =
{
  5ul,  11ul, 23ul,
  53ul, 97ul, 193ul,   389ul,   769ul,
  1543ul,   3079ul,   6151ul,  12289ul, 24593ul,
  49157ul,  98317ul,  196613ul,393241ul,786433ul,
  1572869ul,3145739ul,6291469ul,   12582917ul,  25165843ul,
  50331653ul,   100663319ul,  201326611ul, 402653189ul, 805306457ul,
  1610612741ul, 3221225473ul, 4294967291ul
};

return &_stl_prime_list[0]; }

NOTE: _stl_next_prime has the only calls to _get_stl_prime_list that exist in 
the source code.


The details for what is going on follow...

There are 7 instances of get_stl_prime_list's code in my /usr/local/bin/ctest, 
each with differing %r2 offsets for differing %r2 values to allow finding 
appropriate _stl_prime_list addresses in various places that include the header 
file. Each code instance from my build's /usr/local/bin/ctest is shown below. 
(Note that the ._ZN5cmsysL18get_stl_prime_listEv name does not vary despite the 
distinct addresses.)

But there is only 1 instance of _stl_next_prime's code in /usr/local/bin/ctest, 
also shown below. This routine directly calls the first of the 
._ZN5cmsysL18get_stl_prime_listEv routines below, effectively forcing the %r2 
offset from that code to always be used --and so generating garbage addresses 
for 6 of the 7 static contexts.

6 of the ._ZN5cmsysL18get_stl_prime_listEv's are completely unused.

But most of the initial usage of _stl_next_prime in execution order happens to 
have the %r2 value that goes with the first ._ZN5cmsysL18get_stl_prime_listEv 
routine. That is why /usr/local/bin/ctest dies as late as it does.

I have observed the indicated behavior leading up to the crash under gdb as 
well.

101751c0 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1)
101751c4 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdur1,-64(r1)
101751c8 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr  r31,r1
101751cc <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld  r0,-2976(r2)
101751d0 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr  r3,r0
101751d4 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld  r1,0(r1)
101751d8 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld  r31,-8(r1)
101751dc <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
101751e0 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
101751e4 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x9
101751e8 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz r0,1(r1)

1017c028 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1)
1017c02c <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdur1,-64(r1)
1017c030 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr  r31,r1
1017c034 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld  r0,-2720(r2)
1017c038 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr  r3,r0
1017c03c <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld  r1,0(r1)
1017c040 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld  r31,-8(r1)
1017c044 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
1017c048 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
1017c04c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x9
1017c050 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz r0,1(r1)

101f4ae8 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1)
101f4aec <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdur1,-64(r1)
101f4af0 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr  r31,r1
101f4af4 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld  r0,2088(r2)
101f4af8 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr  r3,r0
101f4afc <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld  r1,0(r1)
101f4b00 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld  r31,-8(r1)
101f4b04 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr
101f4b08 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0
101f4b0c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x9
101f4b10 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz r0,1(r1)

1029161c <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1)
10291620 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdur1,-64(r1)
10291624 <.

Re: pkgng deviates from defaults?

[Adam McDougall]

On 03/09/2015 08:23, Carsten Jensen wrote:
> On 03/08/2015 02:41 PM, Baptiste Daroussin wrote:
>> On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote:
>>>
>>> It seems that pkgng deviates from installing the defaults.
>>> one of the culprits seems to be phpMyAdmin, as trying to upgrade this
>>> only it wants php56
>>> deleting phpMyAdmin just shows I have other packages needing php56 in my
>>> system.
>>>
>>> is this a bug? and how can I prevent upgrading to the non-default php56?
>>
>> The default settings are a ports tree setting not a pkg setting. for
>> now the
>> ports are hardcoding the required version into the packages, this is a
>> legacy of
>> the old system, noone has yet been working on this. so beside building
>> your own
>> packages with poudriere (which will define the default you want) righ
>> now there
>> is no way to avoid that.
>>
>> The php case but not only php will require small changes in pkg(8) to
>> activate
>> smart dependencies: depend on a>1<=2.10 and also adding
>> provides/requires (this
>> is not very hard to be added in pkg.) and it should also require heavy
>> changes
>> on the port side!
>>
>> As far as I know noone has been working on those changes in the port
>> side. the
>> pkg(8) changes are mostly pending for real use cases in the port side.
>> Meaning
>> both should be coordinated.
>>
>> Best regards,
>> Bapt
>>
> 
> Sorry I don't think I was clear.
> Some applications wants php5 and some applications wants php56 when
> upgrading using pkg-ng.
> Using pkg-ng one cannot upgrade i.e. both phpMyAdmin and an other web
> based application due to this conflict.
> 
> So while the upgrade happens to upgrade to php56 it also removes the
> other web application, as it only wants php5.
> 
> Most of the applications on the server is maintained by pkg-ng, and it
> conflicts itself.
> 
> Basically there are now 2 "default" php versions used by pkg-ng
> meaning, _I_ am not trying to upgrade to php56, pkg-ng does but it also
> tries to upgrade php5.
> 
> I can't find any hardcode to php56 in the Makefile of databases/phpmyadmin
> 
> I don't know if this is expressed better, I hope so atleast.
> 
> 
> Cheers
> Carsten
> 

I think there is some confusion because the default PHP version in ports
recently changed to 5.6, and now the official packages are pulling in 5.6:

https://svnweb.freebsd.org/ports?view=revision&revision=379433

pkg sometimes tries to remove conflicting packages (like ones that need
5.5) unless you "pkg upgrade" without specifying a package and then it
has better information on what to reinstall so packages might not get
removed.
___
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: WITH_OPENSSL_PORT documentation

[Mathieu Arnold]

+--On 8 mars 2015 13:24:09 -0600 Adam Weinberger  wrote:
| Can somebody please write something---anything, even 2 sentences---for
| the PHB about how to use WITH_OPENSSL_PORT? What users should set it to
| to get LibreSSL for example, and what porters are supposed to put in the
| Makefile to support it?
| 
| The text at the top of bsd.openssl.mk just shows WITH_OPENSSL_PORT=yes. A
| few sentences would be a big help, and I'm sure the doc people would be
| happy to take care of all the markup and formatting for you.

It'll soon be a moot point, WITH_OPENSSL_PORT will be the only option :-)

-- 
Mathieu Arnold
___
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: pkgng deviates from defaults?

[Kimmo Paasiala]

On Mon, Mar 9, 2015 at 5:44 PM, Adam McDougall  wrote:
> On 03/09/2015 08:23, Carsten Jensen wrote:
>> On 03/08/2015 02:41 PM, Baptiste Daroussin wrote:
>>> On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote:

 It seems that pkgng deviates from installing the defaults.
 one of the culprits seems to be phpMyAdmin, as trying to upgrade this
 only it wants php56
 deleting phpMyAdmin just shows I have other packages needing php56 in my
 system.

 is this a bug? and how can I prevent upgrading to the non-default php56?
>>>
>>> The default settings are a ports tree setting not a pkg setting. for
>>> now the
>>> ports are hardcoding the required version into the packages, this is a
>>> legacy of
>>> the old system, noone has yet been working on this. so beside building
>>> your own
>>> packages with poudriere (which will define the default you want) righ
>>> now there
>>> is no way to avoid that.
>>>
>>> The php case but not only php will require small changes in pkg(8) to
>>> activate
>>> smart dependencies: depend on a>1<=2.10 and also adding
>>> provides/requires (this
>>> is not very hard to be added in pkg.) and it should also require heavy
>>> changes
>>> on the port side!
>>>
>>> As far as I know noone has been working on those changes in the port
>>> side. the
>>> pkg(8) changes are mostly pending for real use cases in the port side.
>>> Meaning
>>> both should be coordinated.
>>>
>>> Best regards,
>>> Bapt
>>>
>>
>> Sorry I don't think I was clear.
>> Some applications wants php5 and some applications wants php56 when
>> upgrading using pkg-ng.
>> Using pkg-ng one cannot upgrade i.e. both phpMyAdmin and an other web
>> based application due to this conflict.
>>
>> So while the upgrade happens to upgrade to php56 it also removes the
>> other web application, as it only wants php5.
>>
>> Most of the applications on the server is maintained by pkg-ng, and it
>> conflicts itself.
>>
>> Basically there are now 2 "default" php versions used by pkg-ng
>> meaning, _I_ am not trying to upgrade to php56, pkg-ng does but it also
>> tries to upgrade php5.
>>
>> I can't find any hardcode to php56 in the Makefile of databases/phpmyadmin
>>
>> I don't know if this is expressed better, I hope so atleast.
>>
>>
>> Cheers
>> Carsten
>>
>
> I think there is some confusion because the default PHP version in ports
> recently changed to 5.6, and now the official packages are pulling in 5.6:
>
> https://svnweb.freebsd.org/ports?view=revision&revision=379433
>
> pkg sometimes tries to remove conflicting packages (like ones that need
> 5.5) unless you "pkg upgrade" without specifying a package and then it
> has better information on what to reinstall so packages might not get
> removed.

In fact pkg(8) will not allow conflicting packages to be installed at
all. The result is that if you want to install a package that would
introduce a conflict in the installed package database the conflict
has to be resolved one way or another. The only solution at the moment
is to remove the offending packages from the existing installed
packages. This is not a pkg(8) limitation but the consequence of how
ports(7) system deals with conflicts and lack of infrastructure to
properly allow multiple versions of the same software to co-exist.

-Kimmo
___
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: CFT: vlc 2.2.0

[Scott Furry]

On 09/03/2015 08:46, Fabian Keil wrote:

Juergen Lock  wrote:


  I just saw vlc 2.2.0 is out and updated the port, please test:

https://people.freebsd.org/~nox/tmp/vlc-2.2.0-001.patch

Thanks for the update.

I get a couple of warnings at build time:

configure: WARNING: unrecognized options: --disable-egl, --disable-libvnc, 
--disable-quicksync, --enable-dirac, --enable-glx, --with-qt-includes, 
--with-qt-libraries, --with-extra-includes, --with-extra-libs
[...]
> Running Q/A tests (stage-qa)
Warning: 'lib/vlc/plugins/codec/libtheora_plugin.so' is not stripped consider 
trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
[... same message for the other plugins ]

The installed binary seems to mostly work as expected.

The only regression I noticed so far is that vlc doesn't get the final window
size right when it's started with a video file specified on the command line:
https://www.fabiankeil.de/bilder/screenshots/vlc/vlc-2.2.0-001-rendering-flaw.jpg

After going to fullscreen and back again (for example by hitting f twice)
vlc uses the expected window size. Moving the window around has the same effect.
Loading the video through the GUI seems to work around the problem as well.

I'm using a tiling window manager (i3) which could be part of the problem
and I wouldn't be surprised if the problem was OS-independent.

Fabian
There is also a vlc preference setting to control video sizing. So, if 
you have the window not maximized, the window will be seen to adjust 
"automatically" to the video size. This can be changed in 
tools->preferneces->interface->"Resize Interface to video size". I 
believe the default for this sitting is "checked".


S
___
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: Re: WITH_OPENSSL_PORT documentation

[Olli Hauer]

   Hi Mathieu,
   what is the target timeframe for."soon",.e.g. for.8.x and.9.x having an
   older openssl in base.
   Is there wip. to hide the base ssl libs ?
   --
   Sent from my Android phone with GMX Mail. Please excuse my brevity.

   Mathieu Arnold  wrote:

 +--On 8 mars 2015 13:24:09 -0600 Adam Weinberger 
 wrote:
 | Can somebody please write something---anything, even 2
 sentences---for
 | the PHB about how to use WITH_OPENSSL_PORT? What users should set
 it to
 | to get LibreSSL for example, and what porters are supposed to put
 in the
 | Makefile to support it?
 |
 | The text at the top of bsd.openssl.mk just shows
 WITH_OPENSSL_PORT=yes. A
 | few sentences would be a big help, and I'm sure the doc people
 would be
 | happy to take care of all the markup and formatting for you.
 It'll soon be a moot point, WITH_OPENSSL_PORT will be the only
 option :-)
 --
 Mathieu Arnold
 ___
 freebsd-ports@freebsd.org mailing list
 [1]http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to
 "freebsd-ports-unsubscr...@freebsd.org"

References

   1. http://lists.freebsd.org/mailman/listinfo/freebsd-ports
___
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: pkgng deviates from defaults?

[Chris H]

On Mon, 9 Mar 2015 15:07:39 + Mike Clarke 
wrote

> On Mon, 09 Mar 2015 07:04:30 -0700
> "Chris H"  wrote:
> 
> > You might be able to avoid the issue you're having, by using:
> > DEFAULT_VERSIONS+=php=5.5
> > in your make.conf(5) (/etc/make.conf) file.
> 
> As far as I know this won't have any effect on pkg.
Bummer. Sorry to hear that.
Seems like there *should* be a way in pkg(8) to honor
DEFAULT_VERSIONS
not that there is a way now. But that there *should* be
a way, in the (near?) future. :-)

Thanks for the heads up, Mike.

--Chris
> 
> If the OP wishes to use pkg then the only option is to switch to using
> php5.6. This will involve uninstalling all the php5.5 packages and
> reinstalling default php5.6 versions. I went through this process
> recently and described the steps involved in questions@
>  > 
>
> -- 
> Mike Clarke
> ___
> 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"


___
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: graphics/freeglut build fail

[Raif S. Berent]

I would not give this problem a second thought, since 40 to 50 ports regularly 
break during poudriere runs. The exception for this port is that many 
downstream ports (>370 for me) depend on it. Then, a "# make package" from host 
gets accepted by the poudriere queue.

ccache has no relevance to the problem, and building with GCC works. Can we 
place a conditional in the Makefile {if version > trillion ; use GCC}?
I know, I suck at coding. I'm gonna get there some day...

poudriere build log:
https://drive.google.com/file/d/0Bxs_eepbMt6qMVp0aGFZUklmTW8/view?usp=sharing

> I got the port to build with USE_GCC=ANY.
> poudriere accepted (did not delete) the binary created by host so the
> full build now continues :))

___
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: pkgng deviates from defaults?

[Carsten Jensen]

On 09-03-2015 17:34, Kimmo Paasiala wrote:
> On Mon, Mar 9, 2015 at 5:44 PM, Adam McDougall  wrote:
>> On 03/09/2015 08:23, Carsten Jensen wrote:
>>> On 03/08/2015 02:41 PM, Baptiste Daroussin wrote:
 On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote:
> It seems that pkgng deviates from installing the defaults.
> one of the culprits seems to be phpMyAdmin, as trying to upgrade this
> only it wants php56
> deleting phpMyAdmin just shows I have other packages needing php56 in my
> system.
>
> is this a bug? and how can I prevent upgrading to the non-default php56?
 The default settings are a ports tree setting not a pkg setting. for
 now the
 ports are hardcoding the required version into the packages, this is a
 legacy of
 the old system, noone has yet been working on this. so beside building
 your own
 packages with poudriere (which will define the default you want) righ
 now there
 is no way to avoid that.

 The php case but not only php will require small changes in pkg(8) to
 activate
 smart dependencies: depend on a>1<=2.10 and also adding
 provides/requires (this
 is not very hard to be added in pkg.) and it should also require heavy
 changes
 on the port side!

 As far as I know noone has been working on those changes in the port
 side. the
 pkg(8) changes are mostly pending for real use cases in the port side.
 Meaning
 both should be coordinated.

 Best regards,
 Bapt

>>> Sorry I don't think I was clear.
>>> Some applications wants php5 and some applications wants php56 when
>>> upgrading using pkg-ng.
>>> Using pkg-ng one cannot upgrade i.e. both phpMyAdmin and an other web
>>> based application due to this conflict.
>>>
>>> So while the upgrade happens to upgrade to php56 it also removes the
>>> other web application, as it only wants php5.
>>>
>>> Most of the applications on the server is maintained by pkg-ng, and it
>>> conflicts itself.
>>>
>>> Basically there are now 2 "default" php versions used by pkg-ng
>>> meaning, _I_ am not trying to upgrade to php56, pkg-ng does but it also
>>> tries to upgrade php5.
>>>
>>> I can't find any hardcode to php56 in the Makefile of databases/phpmyadmin
>>>
>>> I don't know if this is expressed better, I hope so atleast.
>>>
>>>
>>> Cheers
>>> Carsten
>>>
>> I think there is some confusion because the default PHP version in ports
>> recently changed to 5.6, and now the official packages are pulling in 5.6:
>>
>> https://svnweb.freebsd.org/ports?view=revision&revision=379433
>>
>> pkg sometimes tries to remove conflicting packages (like ones that need
>> 5.5) unless you "pkg upgrade" without specifying a package and then it
>> has better information on what to reinstall so packages might not get
>> removed.
> In fact pkg(8) will not allow conflicting packages to be installed at
> all. The result is that if you want to install a package that would
> introduce a conflict in the installed package database the conflict
> has to be resolved one way or another. The only solution at the moment
> is to remove the offending packages from the existing installed
> packages. This is not a pkg(8) limitation but the consequence of how
> ports(7) system deals with conflicts and lack of infrastructure to
> properly allow multiple versions of the same software to co-exist.
>
> -Kimmo
> ___
> 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"
Lots of good answers, thank you :-)

I can understand that php 5.6 is now the default, I did major upgrades a
few weeks back,
and it was 5.4 that was the default then.  Thats not a problem for me as
long as the upgrade
process isn't troublesome.

But I'm wondering why pkg-ng wants to remove other packages rather than
just upgrading
or reinstalling due to dependencies have changed.
Shouldn't these applications have been built using the new defaults?

The problems occured during the simple:
pkg upgrade

oh, and I've seen a couple of lines similar to this:
mod_php5 has no direct installation candidates, change it to mod_php5?
[Y/n]:

no matter what I've chosen it does nothing than exiting to the shell,
trying to run pkg upgrade
again and it asks the same question.

Carsten






___
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: CFT: vlc 2.2.0

[Juergen Lock]

In article <2d36b48f.62887...@fabiankeil.de> you write:
>Juergen Lock  wrote:
>
>>  I just saw vlc 2.2.0 is out and updated the port, please test:
>>=20
>>  https://people.freebsd.org/~nox/tmp/vlc-2.2.0-001.patch
>
>Thanks for the update.
>
>I get a couple of warnings at build time:
>
>configure: WARNING: unrecognized options: --disable-egl, --disable-libvnc, 
>--disable-quicksync, --enable-dirac, --enable-glx, --with-qt-includes, 
>--with-qt-libraries, --with-extra-includes, --with-extra-libs
>[...]

Yeah probably not important.

>> Running Q/A tests (stage-qa)
>Warning: 'lib/vlc/plugins/codec/libtheora_plugin.so' is not stripped consider 
>trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
>[... same message for the other plugins ]
>
 Not sure plugins should be stripped...

>The installed binary seems to mostly work as expected.
>
>The only regression I noticed so far is that vlc doesn't get the final window
>size right when it's started with a video file specified on the command line:
>https://www.fabiankeil.de/bilder/screenshots/vlc/vlc-2.2.0-001-rendering-flaw.jpg
>
>After going to fullscreen and back again (for example by hitting f twice)
>vlc uses the expected window size. Moving the window around has the same 
>effect.
>Loading the video through the GUI seems to work around the problem as well.
>
>I'm using a tiling window manager (i3) which could be part of the problem

 Possibly, I don't see this on lxde here. (which isn't tiling)

>and I wouldn't be surprised if the problem was OS-independent.
>
 Right.

 Thanx for testing! :)
Juergen
___
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: How could I increase "runaway" timer for package build cluster?

[Kevin Oberman]

On Mon, Mar 9, 2015 at 4:23 AM, Matthew Seaman <
m.sea...@infracaninophile.co.uk> wrote:

> On 03/09/15 11:11, Lev Serebryakov wrote:
> > On 08.03.2015 12:40, Ben Woods wrote:
> >> Actually, taking a look at my /usr/local/etc/poudriere.conf
> >> configuration file, I see these settings have indeed been exposed
> >> for configuration there without having to touch the poudriere code
> >> itself. The appropriate settings are:
> >
> >> # This defines the max time (in seconds) that a command may run for
> >> a build # before it is killed for taking too long. Default: 86400
> >> #MAX_EXECUTION_TIME=86400
> >
> >> # This defines the time (in seconds) before a command is considered
> >> to # be in a runaway state for having no output on stdout. Default:
> >> 7200 #NOHANG_TIME=7200
> >
> >  The problem is, it is not my cluster, but FreeBSD official cluster. I
> > could not change configs of it, I could only edit Makefile of my port.
>
> I added a small change to make 'pkg create' emit a progress bar which
> will be in pkg-1.15 -- you have to tweak some settings in pkg.conf to
> enable it though.  With this change I've managed to avoid poudriere
> timeouts while packaging stuff with large numbers of files --
> texlive-texmf being a classic example.  You can try it now by installing
> net-mgmt/pkg-devel, but beware that will eventually cause all your
> client machines to end up running pkg-devel too.
>
>
Just slightly confused. Do you mean pkg-1.4.15 (now on 1.4.12) or pkg-1.5?
Any idea on time-frame?
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
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: pkgng deviates from defaults?

[Adam McDougall]

On 03/09/2015 15:05, Carsten Jensen wrote:
> On 09-03-2015 17:34, Kimmo Paasiala wrote:
>> On Mon, Mar 9, 2015 at 5:44 PM, Adam McDougall  wrote:
>>> On 03/09/2015 08:23, Carsten Jensen wrote:
 On 03/08/2015 02:41 PM, Baptiste Daroussin wrote:
> On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote:
>> It seems that pkgng deviates from installing the defaults.
>> one of the culprits seems to be phpMyAdmin, as trying to upgrade this
>> only it wants php56
>> deleting phpMyAdmin just shows I have other packages needing php56 in my
>> system.
>>
>> is this a bug? and how can I prevent upgrading to the non-default php56?
> The default settings are a ports tree setting not a pkg setting. for
> now the
> ports are hardcoding the required version into the packages, this is a
> legacy of
> the old system, noone has yet been working on this. so beside building
> your own
> packages with poudriere (which will define the default you want) righ
> now there
> is no way to avoid that.
>
> The php case but not only php will require small changes in pkg(8) to
> activate
> smart dependencies: depend on a>1<=2.10 and also adding
> provides/requires (this
> is not very hard to be added in pkg.) and it should also require heavy
> changes
> on the port side!
>
> As far as I know noone has been working on those changes in the port
> side. the
> pkg(8) changes are mostly pending for real use cases in the port side.
> Meaning
> both should be coordinated.
>
> Best regards,
> Bapt
>
 Sorry I don't think I was clear.
 Some applications wants php5 and some applications wants php56 when
 upgrading using pkg-ng.
 Using pkg-ng one cannot upgrade i.e. both phpMyAdmin and an other web
 based application due to this conflict.

 So while the upgrade happens to upgrade to php56 it also removes the
 other web application, as it only wants php5.

 Most of the applications on the server is maintained by pkg-ng, and it
 conflicts itself.

 Basically there are now 2 "default" php versions used by pkg-ng
 meaning, _I_ am not trying to upgrade to php56, pkg-ng does but it also
 tries to upgrade php5.

 I can't find any hardcode to php56 in the Makefile of databases/phpmyadmin

 I don't know if this is expressed better, I hope so atleast.


 Cheers
 Carsten

>>> I think there is some confusion because the default PHP version in ports
>>> recently changed to 5.6, and now the official packages are pulling in 5.6:
>>>
>>> https://svnweb.freebsd.org/ports?view=revision&revision=379433
>>>
>>> pkg sometimes tries to remove conflicting packages (like ones that need
>>> 5.5) unless you "pkg upgrade" without specifying a package and then it
>>> has better information on what to reinstall so packages might not get
>>> removed.
>> In fact pkg(8) will not allow conflicting packages to be installed at
>> all. The result is that if you want to install a package that would
>> introduce a conflict in the installed package database the conflict
>> has to be resolved one way or another. The only solution at the moment
>> is to remove the offending packages from the existing installed
>> packages. This is not a pkg(8) limitation but the consequence of how
>> ports(7) system deals with conflicts and lack of infrastructure to
>> properly allow multiple versions of the same software to co-exist.
>>
>> -Kimmo
>> ___
>> 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"
> Lots of good answers, thank you :-)
> 
> I can understand that php 5.6 is now the default, I did major upgrades a
> few weeks back,
> and it was 5.4 that was the default then.  Thats not a problem for me as
> long as the upgrade
> process isn't troublesome.
> 
> But I'm wondering why pkg-ng wants to remove other packages rather than
> just upgrading
> or reinstalling due to dependencies have changed.
> Shouldn't these applications have been built using the new defaults?
> 
> The problems occured during the simple:
> pkg upgrade
> 
> oh, and I've seen a couple of lines similar to this:
> mod_php5 has no direct installation candidates, change it to mod_php5?
> [Y/n]:
> 
> no matter what I've chosen it does nothing than exiting to the shell,
> trying to run pkg upgrade
> again and it asks the same question.
> 
> Carsten
> 
> 

Sorry, I meant "pkg upgrade -f" may give you better results because it
will pull down all rebuilt packages and have more information to resolve
the problem, at least in my experience.  It doesn't seem like it should
be necessary though.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-port

Re: CFT: vlc 2.2.0

[Baptiste Daroussin]

On Mon, Mar 09, 2015 at 10:15:04PM +0100, Juergen Lock wrote:
> In article <2d36b48f.62887...@fabiankeil.de> you write:
> >Juergen Lock  wrote:
> >
> >>  I just saw vlc 2.2.0 is out and updated the port, please test:
> >>=20
> >>https://people.freebsd.org/~nox/tmp/vlc-2.2.0-001.patch
> >
> >Thanks for the update.
> >
> >I get a couple of warnings at build time:
> >
> >configure: WARNING: unrecognized options: --disable-egl, --disable-libvnc, 
> >--disable-quicksync, --enable-dirac, --enable-glx, --with-qt-includes, 
> >--with-qt-libraries, --with-extra-includes, --with-extra-libs
> >[...]
> 
> Yeah probably not important.
> 
> >> Running Q/A tests (stage-qa)
> >Warning: 'lib/vlc/plugins/codec/libtheora_plugin.so' is not stripped 
> >consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
> >[... same message for the other plugins ]
> >
>  Not sure plugins should be stripped...
They should at least no reason not to strip them
> 
> >The installed binary seems to mostly work as expected.
> >
> >The only regression I noticed so far is that vlc doesn't get the final window
> >size right when it's started with a video file specified on the command line:
> >https://www.fabiankeil.de/bilder/screenshots/vlc/vlc-2.2.0-001-rendering-flaw.jpg
> >
> >After going to fullscreen and back again (for example by hitting f twice)
> >vlc uses the expected window size. Moving the window around has the same 
> >effect.
> >Loading the video through the GUI seems to work around the problem as well.
> >
> >I'm using a tiling window manager (i3) which could be part of the problem
> 
>  Possibly, I don't see this on lxde here. (which isn't tiling)
> 
> >and I wouldn't be surprised if the problem was OS-independent.
> >
>  Right.
> 
>  Thanx for testing! :)
>   Juergen
> ___
> 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"


pgpaaTAXtsU3n.pgp
Description: PGP signature

Re: proper DOXYGEN option default value

[Steve Wills]

On Wed, Mar 04, 2015 at 02:41:48PM -0800, Don Lewis wrote:
> I maintain a number of ports that use doxygen to generate their
> documentation.  They all list DOXYGEN in OPTIONS_DEFAULT so that
> the packages will include documentation.
> 
> I recently received a PR for one of those ports that mentioned that most
> users don't require the documentation and pointed out that anyone
> building the port will find it is very painful because of the amount of
> time it takes to build doxygen and all of its dependencies (primarily
> all the TeX stuff).
> 
> It's been my experience that there is enough churn in the dependencies
> that the whole mess needs to get rebuilt fairly frequently.
> 
> As I see it, the pros and cons of listing DOXYGEN in OPTIONS_DEFAULT
> are:
>   Pros:
> * Users who need the documentation can use the binary packages if
>   they desire
> * This option gets regular exercise on the build cluster
>   Cons:
>   * A bit of extra load on the ports build cluster to install
> doxygen and its dependencies as a BUILD_DEPENDS for each
> supported OS version and architecture
>   * The packages are a bit larger
>   * A bit more space is consumed on the user's machine because
> documentation is installed, even if they don't need it
>   * Users building from ports have to build and install doxygen
> and it's dependencies unless they take measures to avoid it,
> either by disabling the option for each port or adding
> OPTIONS_UNSET=DOXYGEN to their /etc/make.conf to do this
> globally
> 
> The pros and cons of removing DOXYGEN from OPTIONS_DEFAULT:
>   Pros:
>  * Less load on the ports build cluster
>  * Smaller packages
>  * Less space consumed on most user machines
>  * Users building from ports who do not need the documentation don't
>pay the doxygen penalty without taking any special measures
>   Cons:
>  * Anyone who does need the documentation has to build from the
>port and pay the cost of building and installing doxygen and its
>dependencies.
>  * The DOXYGEN option would not get regular testing and could be
>subject to bit rot.
> 
> Ideally, the documentation could be built and packaged separately.  It
> could even be NO_ARCH.   Unfortunately, at this time this would require
> adding a bunch of new ports just for the documentation.
> 
> Since these ports only generate HTML documentation, it might be helpful
> to have a doxygen-lite port that has GRAPHVIZ and LATEX disabled, and
> use that as a BUILD_DEPENDS.  That introduces the problem of conflicts
> between doxygen and doxygen-lite if someone who builds from ports needs
> the full featured doxygen for other purposes.
> 
> Since we have neither of the above, should I leave my ports as-is, or
> should I disable DOXYGEN by default?

Personally I would tend to lean towards leaving DOXYGEN off by default,
especially if there is other accompanying documentation. This is the case for
lang/ruby* for example.

But beward that this may mean it is more likely that the DOXYGEN parts of the
plist may become outdated when the doxygen port is updated. So keep testing
that option.

Steve
___
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: How could I increase "runaway" timer for package build cluster?

[Matthew Seaman]

On 09/03/2015 23:11, Kevin Oberman wrote:
> On Mon, Mar 9, 2015 at 4:23 AM, Matthew Seaman <
> m.sea...@infracaninophile.co.uk> wrote:
> 
>> On 03/09/15 11:11, Lev Serebryakov wrote:
>>> On 08.03.2015 12:40, Ben Woods wrote:
 Actually, taking a look at my /usr/local/etc/poudriere.conf
 configuration file, I see these settings have indeed been exposed
 for configuration there without having to touch the poudriere code
 itself. The appropriate settings are:
>>>
 # This defines the max time (in seconds) that a command may run for
 a build # before it is killed for taking too long. Default: 86400
 #MAX_EXECUTION_TIME=86400
>>>
 # This defines the time (in seconds) before a command is considered
 to # be in a runaway state for having no output on stdout. Default:
 7200 #NOHANG_TIME=7200
>>>
>>>  The problem is, it is not my cluster, but FreeBSD official cluster. I
>>> could not change configs of it, I could only edit Makefile of my port.
>>
>> I added a small change to make 'pkg create' emit a progress bar which
>> will be in pkg-1.15 -- you have to tweak some settings in pkg.conf to
>> enable it though.  With this change I've managed to avoid poudriere
>> timeouts while packaging stuff with large numbers of files --
>> texlive-texmf being a classic example.  You can try it now by installing
>> net-mgmt/pkg-devel, but beware that will eventually cause all your
>> client machines to end up running pkg-devel too.
>>
>>
> Just slightly confused. Do you mean pkg-1.4.15 (now on 1.4.12) or pkg-1.5?
> Any idea on time-frame?

Sorry, yes.  That was a typo.  pkg-1.5 is in the works.  Bapt has said
he wants to release it "before BSDCan" and there's a chunk of work gong
in on regression testing at the moment.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.

PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matt...@infracaninophile.co.uk



signature.asc
Description: OpenPGP digital signature