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
+-+
print/py-relatorio  | 0.6.3   | 0.6.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: HEADSUP: FLAVORS (initial version) and subpackages proposals

[David Demelier]

2016-12-19 1:31 GMT+01:00 Baptiste Daroussin :
> Hi all,
>
> I have been working for a while on 2 long standing feature request for the 
> ports
> tree: flavors and subpackages.
>
> For flavors I would like to propose a simple approach first which is more 
> like a
> rework of the slave ports for now:
>
> Examples available here:
> https://reviews.freebsd.org/D8840 (with the implementation)
> and
> https://reviews.freebsd.org/D8843
>
> Design: introduce a 3rd level in the hierarchy and make it work a bit like 
> slave
> ports
>
> pros:
> - all slave ports are self hosted under the same directory: easier for
>   maintenance
> - should work with all existing tools
>

This is what I really wanted for years especially for ports like spell
checker. Some are in dedicated categories such as french/aspell while
other are in textproc/-aspell and that's a big mess.

OpenBSD ports has something like textproc/aspell/ and that is
very nice and clean. If the plan is to do the same, that is definitely
a major improvement.

> cons:
> - hackish: it is not really much more than a slave port
> - it adds plenty of new Makefiles :(
>
> I think anyway this is an improvement
>
> Next step after that is in would be to extend it to allow some dependency on 
> "I
> depend on whatever flavor if port X"
>
> Subpackages:
> Design:
> Add a new macro MULTI_PACKAGES
> flag plist with an @pkg{suffixofthesubpackage} file
> the framework will split the plist into small plist and create all the 
> packages
> All variables like COMMENT can be overridden with a 
> COMMENT_${suffixofthesubpackage}
>
> pros:
> - simple and working almost now
> - allow to simplify lots of ports
> - options friendly (_PACKAGE automatically appends a new entry to
>   MULTI_PACKAGES)
>

Also lovely as it will probably remove some packages that duplicate a
lot the ports tree (-nox11 for example). If I understood correctly
that one.

> Any comment?

Yes, make it real :)

And again, thanks for your amazing and regular good work bapt!

-- 
Demelier David
___
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: The ports collection has some serious issues

[David Demelier]

2016-12-18 21:22 GMT+01:00 Kevin Oberman :
> synth(8)... try it, you'll like it. (Sorry, dating myself.)

I also never tried synth as I'm very familiar with poudriere, but I'll
have a look for sure :)

-- 
Demelier David
___
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: The ports collection has some serious issues

[Peter Jeremy]

On 2016-Dec-17 20:16:12 -0600, John Marino  wrote:
>On 12/17/2016 19:35, Peter Jeremy wrote:
>> $ cd /usr/ports/ports-mgmt/synth/ && make
>> [ about an hour of grinding away elided ]
>> ===>   ini_file_manager-03_2 depends on file: /usr/local/gcc6-aux/bin/ada - 
>> not found
>> ===>  gcc6-aux-20160822 is only for amd64 i386, while you are running armv6.
>>
>> Overall, a total failure.
>>
>> OTOH, portmaster installs in a minute or so and runs perfectly well.  I fail
>> to see why you are so insistant on replacing it with something that doesn't
>> work at all.
>>
>
>Real smooth there, Slick.
>
>It's been mentioned several times in this thread alone that Ada is only 
>available for i386 and amd64.

Not in this thread, no it hasn't.  I went digging and found that it has been
mentions in some of the other 7 separate "The ports collection has some
serious issues" that you have started.

> I think you already knew that

Well, I pointed it out to you in February this year and after 10 months,
nothing has changed, including your persistent desire to get rid of
portmaster, despite the fact that synth is not a suitable replacement.

>and thus 
>this is a pure troll.

I insist that you retract that insult.  In this thread, without any
qualification, you stated that anyone who used portmaster or portupgrade
should swap to synth, and gave a process which you know will only work on
i386 and amd64.

>Use poudriere for non-x86 platforms.  armv6 packages are built with 
>poudriere + QEMU, but I suspect you already knew this as well.

I haven't investigated because I haven't had the the need to.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: The ports collection has some serious issues

[Jim Trigg]

On 12/18/2016 02:24 AM, John Marino wrote:

2) portmaster's dirty build method is inferior to clean environment
builds (true)
3) There is better and official alternative (true)


Maybe. I have a case where portmaster (on my current production box) 
builds fine but poudriere (on my intended replacement production box) 
does not.


Case in point: php70-pdo_*. The first time I tried a build pdo_sqlite 
failed. This time (after correcting other ports' option problems) 
pdo_mysql fails for basically the same reason - pdo_* cannot find pdo 
because pdo thinks PHP_EXT_DIR=20151012-zts but pdo_* thinks 
PHP_EXT_DIR=20151012 - log for the latter below signature. Yet doing the 
build with postmaster works fine.



4) There's a second, even more effective alternative for x86 platforms
(true)


I can not as yet contest this. I haven't tried synth because if 
poudriere works it will have further value add for me (as a port 
maintainer I can build my port in multiple environments on a single 
box). Dealing with the conversion factor isn't worth it to me for the 
alleged gains synth brings.


--
Jim Trigg

Log for php70-pdo_mysql
>> Building databases/php70-pdo_mysql
build started at Sun Dec 18 23:53:21 EST 2016
port directory: /usr/ports/databases/php70-pdo_mysql
building for: FreeBSD freebsd_10-3x64-HEAD-job-04 10.3-RELEASE-p14 
FreeBSD 10.3-RELEASE-p14 amd64

maintained by: t...@freebsd.org
Makefile ident:  $FreeBSD: head/databases/php70-pdo_mysql/Makefile 
422569 2016-09-21 15:43:47Z tz $

Poudriere version: 3.1.14
Host OSVERSION: 1003000
Jail OSVERSION: 1003000

---Begin Environment---
SHELL=/bin/csh
UNAME_v=FreeBSD 10.3-RELEASE-p14
UNAME_r=10.3-RELEASE-p14
BLOCKSIZE=K
MAIL=/var/mail/root
STATUS=1
ARCH=amd64
SAVED_TERM=screen
MASTERMNT=/srv/poudriere/data/.m/freebsd_10-3x64-HEAD/ref
UID=0
FORCE_PACKAGE=yes
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
_JAVA_VERSION_LIST_REGEXP=1.6\|1.7\|1.8\|1.6+\|1.7+\|1.8+
POUDRIERE_BUILD_TYPE=bulk
PKGNAME=php70-pdo_mysql-7.0.14
OSREL=10.3
_OSRELEASE=10.3-RELEASE-p14
PYTHONBASE=/usr/local
OLDPWD=/
_SMP_CPUS=4
PWD=/srv/poudriere/data/.m/freebsd_10-3x64-HEAD/ref/.p/pool
HAVE_COMPAT_IA32_KERN=YES OPSYS=FreeBSD
MASTERNAME=freebsd_10-3x64-HEAD
SCRIPTPREFIX=/usr/local/share/poudriere
_JAVA_VENDOR_LIST_REGEXP=openjdk\|oracle\|sun
USER=root
HOME=/root
POUDRIERE_VERSION=3.1.14
SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
CONFIGURE_MAX_CMD_LEN=262144
LIBEXECPREFIX=/usr/local/libexec/poudriere
LOCALBASE=/usr/local
PACKAGE_BUILDING=yes
_JAVA_OS_LIST_REGEXP=native\|linux
OSVERSION=1003000
---End Environment---

---Begin OPTIONS List---
===> The following configuration options are available for 
php70-pdo_mysql-7.0.14:

 MYSQLND=on: Use MySQL Native Driver
===> Use 'make config' to modify these settings
---End OPTIONS List---

--CONFIGURE_ARGS--
--with-pdo-mysql=mysqlnd --with-php-config=/usr/local/bin/php-config 
--prefix=/usr/local ${_LATE_CONFIGURE_ARGS}

--End CONFIGURE_ARGS--

--CONFIGURE_ENV--
XDG_DATA_HOME=/wrkdirs/usr/ports/databases/php70-pdo_mysql/work 
XDG_CONFIG_HOME=/wrkdirs/usr/ports/databases/php70-pdo_mysql/work 
HOME=/wrkdirs/usr/ports/databases/php70-pdo_mysql/work TMPDIR="/tmp" 
SHELL=/bin/sh CONFIG_SHELL=/bin/sh 
AUTOCONF=/usr/local/bin/autoconf-2.69 
AUTOCONF_DIR=/usr/local/share/autoconf-2.69 
AUTOHEADER=/usr/local/bin/autoheader-2.69 
AUTOIFNAMES=/usr/local/bin/ifnames-2.69 
AUTOM4TE=/usr/local/bin/autom4te-2.69 
AUTORECONF=/usr/local/bin/autoreconf-2.69 
AUTOSCAN=/usr/local/bin/autoscan-2.69 
AUTOUPDATE=/usr/local/bin/autoupdate-2.69  AUTOCONF_VERSION=2.69 
CONFIG_SITE=/usr/ports/Templates/config.site lt_cv_sys_max_cmd_len=262144

--End CONFIGURE_ENV--

--MAKE_ENV--
XDG_DATA_HOME=/wrkdirs/usr/ports/databases/php70-pdo_mysql/work 
XDG_CONFIG_HOME=/wrkdirs/usr/ports/databases/php70-pdo_mysql/work 
HOME=/wrkdirs/usr/ports/databases/php70-pdo_mysql/work TMPDIR="/tmp" 
NO_PIE=yes WITHOUT_DEBUG_FILES=yes WITHOUT_KERNEL_SYMBOLS=yes 
SHELL=/bin/sh NO_LINT=YES  AUTOCONF=/usr/local/bin/autoconf-2.69 
AUTOCONF_DIR=/usr/local/share/autoconf-2.69 
AUTOHEADER=/usr/local/bin/autoheader-2.69 
AUTOIFNAMES=/usr/local/bin/ifnames-2.69 
AUTOM4TE=/usr/local/bin/autom4te-2.69 
AUTORECONF=/usr/local/bin/autoreconf-2.69 
AUTOSCAN=/usr/local/bin/autoscan-2.69 
AUTOUPDATE=/usr/local/bin/autoupdate-2.69  AUTOCONF_VERSION=2.69 
PREFIX=/usr/local  LOCALBASE=/usr/local  LIBDIR="/usr/lib"  CC="cc" 
CFLAGS="-O2 -pipe  -fstack-protector -fno-strict-aliasing"  CPP="cpp" 
CPPFLAGS=""  LDFLAGS=" -fstack-protector" LIBS=""  CXX="c++" 
CXXFLAGS="-O2 -pipe -fstack-protector -fno-strict-aliasing " 
MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install  -s -m 555" 
BSD_INSTALL_LIB="install  -s -m 444"  BSD_INSTALL_SCRIPT="install  -m 
555"  BSD_INSTALL_DATA="install  -m 0644"  BSD_INSTALL_MAN="install  -m 444"

--End MAKE_ENV--

--PLIST_SUB--
PHP_EXT_DIR=20151012
OSREL=10.3
PREFIX=%D
LOCALBASE=/usr/local
RESETPREFIX=/usr/local
PORTDOCS=""
PORTEXAMPLES=""

HEADSUP: FLAVORS (initial version) and subpackages proposals

[Baptiste Daroussin]

Hi all,

I have been working for a while on 2 long standing feature request for the ports
tree: flavors and subpackages.

For flavors I would like to propose a simple approach first which is more like a
rework of the slave ports for now:

Examples available here:
https://reviews.freebsd.org/D8840 (with the implementation)
and
https://reviews.freebsd.org/D8843

Design: introduce a 3rd level in the hierarchy and make it work a bit like slave
ports

pros:
- all slave ports are self hosted under the same directory: easier for
  maintenance
- should work with all existing tools

cons:
- hackish: it is not really much more than a slave port
- it adds plenty of new Makefiles :(

I think anyway this is an improvement

Next step after that is in would be to extend it to allow some dependency on "I
depend on whatever flavor if port X"

Subpackages:
Design:
Add a new macro MULTI_PACKAGES
flag plist with an @pkg{suffixofthesubpackage} file
the framework will split the plist into small plist and create all the packages
All variables like COMMENT can be overridden with a 
COMMENT_${suffixofthesubpackage}

pros:
- simple and working almost now
- allow to simplify lots of ports
- options friendly (_PACKAGE automatically appends a new entry to
  MULTI_PACKAGES)

cons:
- will break the paradigm that certain tools depend on (portmaster/portupgrade
  in particular are a huge problem since they are not actively maintained)

Example of the usage:
https://people.freebsd.org/~bapt/multipackage.diff

Note that I took the mpg123 as an example because it was a simple one to test
not because it may need subpackages

As a result you build 3 packages:
mpg123 (the runtime tools)
mpg123-lib: the runtime libraries
mpg123-sndio: the sndio plugin

LIB_DEPENDS on ports depending on libmpg123.so does not have to be changed, the
framework already automatically register only the mpg123-lib as a dependency and
not others.

Not the example is missing one thing: a dependency between mpeg123-lib and
mpg123

The second is not ready yet and would take time to land

Any comment?

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: graphics/Inkscape not building either with or without openmp option set

[Fernando Herrero Carrón]

2016-12-18 21:44 GMT+01:00 Kevin Oberman :

> On Sun, Dec 18, 2016 at 12:22 PM, Fernando Herrero Carrón <
> elfe...@gmail.com> wrote:
>
>> 2016-12-18 21:19 GMT+01:00 Fernando Herrero Carrón :
>>
>> >
>> > It looks like inkscape unconditionally asks for compiler:openmp in its
>> > Makefile.
>> >
>>
>> Sorry, I just rechecked and this is not true. Still, it fails in both
>> cases.
>
>
> I reported this issue a long time ago, but it is a problem with incorrect
> linkage when ImageMagick is installed with OpenMP. for an explanation and
> workaround, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194760
> See comment 18 for my analysis and confirmed work around.
>
> Oh, sorry, I must have skipped it. Thanks for the pointer, will read it
carefully.
___
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: graphics/Inkscape not building either with or without openmp option set

[Kevin Oberman]

On Sun, Dec 18, 2016 at 12:22 PM, Fernando Herrero Carrón  wrote:

> 2016-12-18 21:19 GMT+01:00 Fernando Herrero Carrón :
>
> >
> > It looks like inkscape unconditionally asks for compiler:openmp in its
> > Makefile.
> >
>
> Sorry, I just rechecked and this is not true. Still, it fails in both
> cases.


I reported this issue a long time ago, but it is a problem with incorrect
linkage when ImageMagick is installed with OpenMP. for an explanation and
workaround, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194760
See comment 18 for my analysis and confirmed work around.
--
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: graphics/Inkscape not building either with or without openmp option set

[Fernando Herrero Carrón]

2016-12-18 21:22 GMT+01:00 Fernando Herrero Carrón :

>
>
> 2016-12-18 21:19 GMT+01:00 Fernando Herrero Carrón :
>
>>
>> It looks like inkscape unconditionally asks for compiler:openmp in its
>> Makefile.
>>
>
> Sorry, I just rechecked and this is not true. Still, it fails in both
> cases.
>
>
I made it build by explicitly adding llvm37/lib to LDFLAGS, and then
stumbled upon this other issue with GraphicsMagick [and openmp] (
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194760). This is getting
tough :-(
___
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: graphics/Inkscape not building either with or without openmp option set

[Fernando Herrero Carrón]

2016-12-18 21:19 GMT+01:00 Fernando Herrero Carrón :

>
> It looks like inkscape unconditionally asks for compiler:openmp in its
> Makefile.
>

Sorry, I just rechecked and this is not true. Still, it fails in both cases.
___
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"

graphics/Inkscape not building either with or without openmp option set

[Fernando Herrero Carrón]

Hi everyone,

graphics/inkscape is failing to build with openmp otion set, but unchecking
it yields exactly the same result. There is an open PR about this (
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208883) but hasn't
receive much attention.

It looks like inkscape unconditionally asks for compiler:openmp in its
Makefile. I know the openmp issue has been brought up several times but, is
there a way to make inkscape compile with it? Otherwise I would remove
openmp support for the time being and at least get it to build.

Cheers,
Fernando
___
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: The ports collection has some serious issues

[Roger Marquis]

On Sun, 18 Dec 2016, Willem Jan Withagen wrote:

On 18-12-2016 16:00, John Marino wrote:

[please keep me CC'd, I can't respond easily if not]

I find that sort of strange... but that could be my feeling.


Given the hyperbole and intentionally misleading content of waay too
much of this thread, including its title, the only thing I find strange
is that anyone could take it seriously.


Like I said, it feels strange.


If you think that's strange you should check out the posts that
torpedo'd HardenedBSD's Reddit page.  Having seen this before in other
projects and knowing some of the sources you wouldn't be mislead by
following the money i.e., astroturf.  At least the FreeBSD project
doesn't utilize professional astroturfers advertising on sites like the
Philippines' Craigslist.  See also
.

Roger Marquis
___
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: The ports collection has some serious issues

[Willem Jan Withagen]

On 18-12-2016 16:00, John Marino wrote:

> [please keep me CC'd, I can't respond easily if not]

I find that sort of strange... but that could be my feeling.

Someone builds a tool, and then decides that it is not very useful to be
part of the community that he creates the tool for...

Like I said, it feels strange.
--WjW

___
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: The ports collection has some serious issues

[Dave Horsfall]

On Sun, 18 Dec 2016, John Marino wrote:

> > > Real smooth there, Slick.
> > 
> > Sarcasm might get you somewhere, but I'm not sure you want to be 
> > there.
> 
> He was trolling.  You know it. I know it.  Everyone that read it knows it.

I happen to know Peter as a friend; you don't.  He doesn't troll; you do.

And who is this "everyone", anyway?  Either enumerate them, or STFU.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
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: The ports collection has some serious issues

[Matthew Seaman]

On 18/12/2016 14:18, Grzegorz Junka wrote:
> Isn't poudriere automatically saving the options file when building a
> new port with default options (i.e. when no options have been
> specified)? And also, aren't the selected options available in the
> resulted pkg file, so that synth could look them up there?

Poudriere will only save options settings if you run 'poudriere options
...' -- if you're trying to build a package and you've never set any
options for it, then poudriere will silently build using the default
options for that package.  Similarly if the maintainer adds or removes
options on a port where you already set some options, poudriere will
just quietly build using the default value of any new options.

On the other hand, if you do modify options, or if the default options
settings change in the ports, poudriere will recognise this the next
time you run a 'poudriere bulk ...' or similar and will add the packages
with changed options to the rebuild queue.

Yes, the resulting pkg contains information about the options settings.
You can see this in the --full or --raw output from pkg-info(8), but it
seems there is no flag to pkg-info(8) to print out just the options
settings.  To do that, use pkg-query(8):

# pkg query '%Ok %Ov' postfix
BDB off
CDB off
DOCS on
INST_BASE off
LDAP off
LDAP_SASL off
LMDB on
MYSQL off
NIS off
PCRE on
PGSQL off
SASL on
SASLKMIT off
SASLKRB5 off
SQLITE off
TEST off
TLS on

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: The ports collection has some serious issues

[scratch65535]

 On 17 Dec 2016, at 20:47, Alphons van Werven
 wrote:
> But ever
>> since some time during the 9.X era I started to pick up signs that the
>> FreeBSD project as a whole is moving into a direction that troubles me--in
>> some cases deeply indeed.

I don't know what direction Fonz sees the project moving in [his
loss will be significant, and I personally wish he would
reconsider], but I've had a sense for some time that there's an
undercurrent of some kind moving us insensibly toward Linux and,
strangely, a mix of uncaringness and authoritarianism.  

I can't really quote specifics on my perception of a Linux-ward
drift because I haven't been keeping an evidence notebook.  But
for evidence of authoritarianism creeping in,  I offer the
imposition of the new pkg utility on all of us awhile back even
though it was still half-baked.  That came as qute a shock, at
least to me.  I didn't like it at all.   And now there seems to
be some psychological warfare going on over basic build tools.

I go back a ways with FreeBSD,  v1.1.3 or something like that. So
I'm not ready to bail, but I really, truly, no-kidding perceive a
drift toward incoherence that, unless reversed, will make FreeBSD
just another footnote in computing history, like Minix, 386BSD,
the UCSD P-system, and others that after a brief heyday ceased to
matter because their support base was hobby-oriented and
uncommitted, with neither a clear vision for the future nor even
a desire for one.
___
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"

The ports collection has some serious issues

[John Marino]

Grzegorz Junka wrote:

On 17/12/2016 18:51, John Marino wrote:

On 12/17/2016 12:34, abi wrote:



2. It doesn't provide dialog for port options, so
2.1 I don't receive information if port options have changed. I don't
know what else will be pulled to my system after port tree update.


which of course is a false statement.
If you set port options which then change, Synth will stop and tell
you to reconfigure or remove the saved port options.


Not at all. For example, let's assume I go recommended way and have
options for ports with not default settings. Let's say, I have perl with
default options (no OPTIONS file). Let's say port maintainer adds new
option, [NSA Backdoor]
Perl will be silently compiled with that option, right?


Yes.  If you don't explicitly save the options then Synth has no way
to detect a change in options.


Isn't poudriere automatically saving the options file when building a
new port with default options (i.e. when no options have been
specified)? And also, aren't the selected options available in the
resulted pkg file, so that synth could look them up there?
Grzegorz


[please keep me CC'd, I can't respond easily if not]

Synth does look up package options.  It compares it with the currently 
options specifications and will obsolete the package if they don't match 
exactly.


Synth intentionally does not store option files.  It will use option 
files that are pre-created for it (the lack of stored options means "use 
the defaults").


The behavior is intentional and it results in synth rarely having to 
break a scan and stop and most people want this, but it just so happens 
that abi wanted the exact opposite behavior.  It's actually the first 
time I've heard somebody wanting the "explicitly save options" behavior 
because it's quite disruptive in practice. [1]


John

[1] I wonder how hard it would be for Synth to optionally create an 
saved options file (outside of the ports framework) when the package is 
successfully built.  It's likely possible (non-default behavior)


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
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: VCode on FreeBSD?

[mokhi]

I did tried it months ago.
It needed special version of npm and such packages that some of them
didn't met of what we had on port-tree.
I didn't spend more time after that though (But I guess it was
possible to satisfy it with little patches).


===
Best wishes, Mokhi.
___
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: The ports collection has some serious issues

[Grzegorz Junka]

On 17/12/2016 18:51, John Marino wrote:

On 12/17/2016 12:34, abi wrote:



2. It doesn't provide dialog for port options, so
2.1 I don't receive information if port options have changed. I don't
know what else will be pulled to my system after port tree update.


which of course is a false statement.
If you set port options which then change, Synth will stop and tell
you to reconfigure or remove the saved port options.


Not at all. For example, let's assume I go recommended way and have
options for ports with not default settings. Let's say, I have perl with
default options (no OPTIONS file). Let's say port maintainer adds new
option, [NSA Backdoor]
Perl will be silently compiled with that option, right?


Yes.  If you don't explicitly save the options then Synth has no way 
to detect a change in options.


Isn't poudriere automatically saving the options file when building a 
new port with default options (i.e. when no options have been 
specified)? And also, aren't the selected options available in the 
resulted pkg file, so that synth could look them up there?

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

VCode on FreeBSD?

[Grzegorz Junka]

Are there any objective reasons why Visual Studio Code hasn't been 
ported to FreeBSD yet (apart from not having the time/person to do it)?


Grzegorz

___
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: The ports collection has some serious issues

[scrat]

On 12/18/16 02:24, John Marino wrote:


The whole "see, it's not a replacement, you lose" tactic is weak and
transparent.  Nobody ever said that.  what was said:

1) portmaster is not maintained (true)
2) portmaster's dirty build method is inferior to clean environment
builds (true)
3) There is better and official alternative (true)
4) There's a second, even more effective alternative for x86 platforms
(true)
5) portmaster should come with a big fat warning (subjective)

So poudriere doesn't have this "weakness" and synth only has it because
these 2nd tier platforms are popular enough to warrant bringing the Ada
compiler over to them.  Is it possible to port the ada frontend to
armv6/v7?  Of course, I've already done it, see lang/gnatdroid*.
However, it's questionable to try to build huge packages natively on
armv6/7.

You can't claim portmaster is the only and therefore best option for
second tier platforms.  It's untrue.  Saying it runs where synth isn't
available doesn't justify keeping portmaster at an exulted status.  You
cannot dismiss poudriere like that.

John



Jumping into the frying pan ( I like it hot ).

I like synth and I use it for all my AMD64 boxen.  The only thing that I 
have an issue with is when there are only a few packages that are being 
updated and it wants to build 100+.  Example:


These are the ports that would be built ([N]ew, [R]ebuild, [U]pgrade):
  U => x11/libXpm (3.5.11_4 => 3.5.12)
  U => audio/soundtouch (1.9.2_1 => 1.9.2_2)
  N => ports-mgmt/dialog4ports
  U => editors/vim-lite (8.0.0130 => 8.0.0134)

  R => mail/thunderbird
  R => x11/kde4
  R => x11/lumina
  R => x11/xorg
Total packages that would be built: 221

Yes I cut some of the ones to be rebuilt.  I don't know enough about the 
how, when and why that synth needs to rebuild all of those... I just 
except it and move on.   Synth has never left me with a broken system as 
some of the other package managers.


I have synth configured to use /usr/home/synth:

$ ls /usr/home/synth
build   logspkg.listports
distfiles   packagespkgbld.sh   svn-update-freebsd.sh

so everything is in /usr/home/synth.

Here is how I use it ( I have two scripts )

cat svn-update-freebsd.sh

#!/bin/sh -

prefix="/usr/home/source"
current="base/head"
stable="base/stable/11"
releng="base/releng/11.0"
release="base/release/11.0.0"
ports="ports/head"
branches="branches/2016Q4"
doc="doc/head"
source="${stable} ${releng} ${release} ${ports} ${branches} ${doc}"
for i in ${source} ; do
if [ -d "${prefix}/${i}" ]; then
svnlite update "${prefix}/${i}"
else
mkdir -vp "${prefix}/${i}"
svnlite co "https://svn.freebsd.org/${i}; "${prefix}/${i}"
fi
done
#mkdir -vp "${prefix}/quarterly/2016Q4"
#svnlite checkout "https://svn.freebsd.org/ports/branches/2016Q4 
${prefix}/quarterly/2106Q4"
rsync --verbose --archive --recursive --delete ${prefix}/${ports}/ 
/usr/home/synth/ports/


cat pkgbld.sh

#!/bin/sh -
synth just-build /usr/home/synth/pkg.list
synth rebuild-repository

A simple

#  cd /usr/home/synth && ./svn-update-freebsd.sh && ./pkgbld.sh;poweroff

works for me.

Synth is good and I highly recommend 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"

The ports collection has some serious issues

[John Marino]

David wrote

On 12/16/2016 04:06 PM, John Marino wrote:

Starting with a clean system:
1) install synth from binary package from official freebsd builder (a
single package)


What about just building synth from ports? Then the OP have everything
built from ports.

--
David


In the example, the system is *clean*.  If you build from ports you 
immediately litter it with installed build dependencies.


The "real" process is just use the binary package that FreeBSD provides. 
 I was showing how to bootstrap it cleanly and the target audience is 
those that insist they were the ones to build it (which I assume is a 
small percentage of the overall audience).  There is zero advantage to 
building it yourself.


The other reasons is that all the build dependencies get generated as 
packages in a synth directory, so by avoiding Synth temporarily has the 
cost of having to potentially rebuild them all again later for other 
packages or rebuilding a new version of synth.  So it avoids unnecessary 
repeat work as well.


John


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

new multimedia/motion problem

[Alex V. Petrov]

Hi!

New motion-4.0.1
Trying to run a web interface results in an error:

[0:] [NTC] [ALL] [Dec 18 20:49:58] motion_startup: Using log type (ALL)
log level (ALL)
[0:] [NTC] [ENC] [Dec 18 20:49:58] ffmpeg_init: ffmpeg libavcodec
version 57.64.101 libavformat version 57.56.100
[0:] [NTC] [ALL] [Dec 18 20:49:58] main: Motion running in setup mode.
[0:] [NTC] [ALL] [Dec 18 20:49:58] main: Camera 1 is from
/usr/local/etc/motion/camera1.conf
[0:] [NTC] [ALL] [Dec 18 20:49:58] main: Camera 1 is device: /dev/bktr0
input -1
[0:] [NTC] [ALL] [Dec 18 20:49:58] main: Stream port 8081
[0:] [NTC] [ALL] [Dec 18 20:49:58] main: Camera 2 is from
/usr/local/etc/motion/camera2.conf
[0:] [NTC] [ALL] [Dec 18 20:49:58] main: Camera 2 is device: /dev/bktr1
input -1
[0:] [NTC] [ALL] [Dec 18 20:49:58] main: Stream port 8082
[0:] [NTC] [ALL] [Dec 18 20:49:58] main: Waiting for threads to finish,
pid: 43548
[1:] [NTC] [ALL] [Dec 18 20:49:58] motion_init: Camera 1 started: motion
detection Enabled
[1:] [NTC] [VID] [Dec 18 20:49:58] vid_start: [/dev/bktr0]
[2:] [NTC] [ALL] [Dec 18 20:49:58] motion_init: Camera 2 started: motion
detection Enabled
[2:] [NTC] [VID] [Dec 18 20:49:58] vid_start: [/dev/bktr1]
[1:] [ERR] [VID] [Dec 18 20:49:58] set_input: Channel Port -1 out of
range (0-4)
[1:] [NTC] [VID] [Dec 18 20:49:58] v4l_start: set input [-1]
[1:] [WRN] [ALL] [Dec 18 20:49:58] motion_init: Could not fetch initial
image from camera Motion continues using width and height from config
file(s)
[1:] [NTC] [ALL] [Dec 18 20:49:58] image_ring_resize: Resizing
pre_capture buffer to 1 items
[2:] [ERR] [VID] [Dec 18 20:49:58] set_input: Channel Port -1 out of
range (0-4)
[2:] [NTC] [VID] [Dec 18 20:49:58] v4l_start: set input [-1]
[2:] [WRN] [ALL] [Dec 18 20:49:58] motion_init: Could not fetch initial
image from camera Motion continues using width and height from config
file(s)
[2:] [NTC] [ALL] [Dec 18 20:49:58] image_ring_resize: Resizing
pre_capture buffer to 1 items
[1:] [NTC] [STR] [Dec 18 20:49:58] http_bindsock: error binding on
127.0.0.1 port 8081
[2:] [NTC] [STR] [Dec 18 20:49:58] http_bindsock: error binding on
127.0.0.1 port 8082
[1:] [ERR] [ALL] [Dec 18 20:49:58] motion_init: Problem enabling
motion-stream server in port 8081: Invalid argument
[2:] [ERR] [ALL] [Dec 18 20:49:58] motion_init: Problem enabling
motion-stream server in port 8082: Invalid argument
[1:] [NTC] [ALL] [Dec 18 20:49:58] motion_loop: Thread exiting
[2:] [NTC] [ALL] [Dec 18 20:49:58] motion_loop: Thread exiting


-- 
-
Alex.
___
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: Dropping enigmail support from enigmail

[Christoph Moench-Tegeder]

## Martin Birgmeier (la5lb...@aon.at):

> However, lightning seems to be gone - I don't find it installed with the
> port and it does not seem to be offered as an add-on for this platform.

I believe thunderbird by default activated the "wrong" lightning
plugin (the one which was now removed) and cannot be bothered to
switch an existing profile to the "other" lightning. I do not have
a good solution for that - see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215348

Regards,
Christoph

-- 
Spare Space
___
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: The ports collection has some serious issues

[David Demelier]

On 12/16/2016 04:06 PM, John Marino wrote:

Starting with a clean system:
1) install synth from binary package from official freebsd builder (a 
single package)


What about just building synth from ports? Then the OP have everything 
built from ports.


--
David
___
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: The ports collection has some serious issues

[Bob Eager]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 18 Dec 2016 17:43:32 +1100
Greg 'groggy' Lehey  wrote:

> On Saturday, 17 December 2016 at 20:16:12 -0600, John Marino wrote:
> > On 12/17/2016 19:35, Peter Jeremy wrote:  
> >> $ cd /usr/ports/ports-mgmt/synth/ && make
> >> [ about an hour of grinding away elided ]  
> >> ===>   ini_file_manager-03_2 depends on
> >> file: /usr/local/gcc6-aux/bin/ada - not found ===>
> >> gcc6-aux-20160822 is only for amd64 i386, while you are running
> >> armv6.  
> >>
> >> Overall, a total failure.
> >>
> >> OTOH, portmaster installs in a minute or so and runs perfectly
> >> well.  I fail to see why you are so insistant on replacing it with
> >> something that doesn't work at all.  
> >
> > Real smooth there, Slick.  
> 
> Sarcasm might get you somewhere, but I'm not sure you want to be
> there.
> 
> > It's been mentioned several times in this thread alone that Ada is
> > only available for i386 and amd64.  I think you already knew that
> > and thus this is a pure troll.  
> 
> I think Peter has highlighted a significant weakness.  A tool that
> doesn't work on all platforms is hardly a replacement for a core tool
> that does.

I agree. One of the criticisms levelled at portupgrade is that it needs
ruby. But to need Ada...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYVmsjAAoJECgXX9ms/Huo6NYH/1+t2KbHubACNbgD8+cnJGNQ
rFABzBnv5QgU1ypuNlTO1kYtwPmFtFXa1Oz/24tHygTXJKFoYhlyDAZGmwS12KIo
PtDkfgyjcv0/W1uWMZbZXB3N3IQXcJ1VOKLNHhKhP3IKEaUrFJhL6gIXcEs5ObiG
4ShLYZtyxNWAbhOP7dGyOaXY5wkkxXBntNmMko4+cRoNgHbHScufpJJT5fiRPPue
85XDhS9XVNbGbG+tcxLFcPaejtc/cn+MpkByqFWYknORsT1NCphmgs7t/NcY5yOB
rR+LTHh0oHVW3n3qV4pZIZ/zXrq78QYN6INVUtrDnRJ21nfjit0/N8fHhASYUhY=
=CnYc
-END PGP SIGNATURE-
___
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: Dropping enigmail support from enigmail

[Martin Birgmeier]

Thanks for the pointer to enigmail in UPDATING, so I misunderstood the
log message and should have looked in UPDATING.

However, lightning seems to be gone - I don't find it installed with the
port and it does not seem to be offered as an add-on for this platform.


On 12/17/16 23:09, Jan Beich wrote:
> Martin Birgmeier  writes:
>
>> After upgrading to thunderbird-45.5.1_6 I noticed that enigmail (and
>> lightning) support were gone from thunderbird. I tried to find a
>> replacement package until I read the svn log message:
> Lightning had 2 copies, only one of those was removed. For Enigmail see
> /usr/ports/UPDATING from 20161216.
>
>> I think a decision to remove such an essential component should not be
>> taken so lightly, especially when the actual port version (45.5.1) has
>> not even changed.
> Why the version should change? Enigmail isn't part of Thunderbird distribution
> but just one of third-party extensions you can find on addons.mozilla.org.
> For historic reasons it was bundled with the port but the requirment is gone.
>
> ENIGMAIL option was unmaintained beyond updates which were irregular.
> And it was bound to get in the way if anyone attempted to refactor the
> current maintenance nightmare gecko@ is in.
>
>

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

Using the license framework to define a port with distribution restrictions

[Carsten Larsen]

Hi,

I have a question in relation to the FreeBSD license framework and how 
to define a port with distribution restrictions. The port in question is 
devel/vasm port.


The legal section of documentation (1.2) for this port is at:
http://sun.hasenbraten.de/vasm/release/vasm.html

It is not clear to me how it should be done. So far I have the following 
proposal which seems to keep portlint happy:


LICENSE=EULA
LICENSE_NAME_EULA=  vasm End User License Agreement
LICENSE_TEXT_EULA=  \
vasm is copyright in 2002-2016 by Volker Barthelmann. \
This archive may be redistributed without modifications 
and used for non-commercial purposes. \
Distributing modified versions and commercial usage 
needs my written consent. \

Certain modules may fall under additional copyrights.
LICENSE_PERMS_EULA= pkg-mirror dist-mirror

Would the above be sufficient in relation to the legal concerns of this 
port ? I am also considering if the LICENSE_TEXT should only consists of 
"Distributing modified versions and commercial usage needs my written 
consent."


All (relevant) input would be appreciated.


Kind regards
Carsten Larsen

___
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: The ports collection has some serious issues

[Thomas Mueller]

>From John Marino and my previous post:

> > I believe you could cd $PORTSDIR/ports-mgmt/synth and
> > make package-recursive |& tee build-12amd64.log (or whatever you want to
> > name the log file; this example if for shell tcsh)?
 
> That installs build dependencies on the system.  That would be no better than
> running portmaster the first time.  If you run the process I suggested, you'll
> end up with a self-hosted machine with no extra stuff installed.


> > For a system with pkgng, is there any difference in package format
> > between "make install", portmaster and portupgrade?

> There shouldn't be, the ports framework is responsible for creating the
> package.

> > If your system already has portmaster, you could portmaster
> > ports-mgmt/synth |& tee synth-12amd64.log?

> > And then switch from portmaster to synth for all further ports
> > builds/updates?

> sure.
> Although it will still be dirty from portmaster so at that point you would
> gather a "prime list" of packages, feed thoughs into synth to create a local
> repository, remove all packages from the system and re-install them with the
> "prime list" and the new local repository.


> > It would not be necessary to start with a clean system for FreeBSD, as
> > opposed to NetBSD, or am I mistaken here?

> No, you can start anytime but I do recommend the procedure above to ensure the
> system is in good shape and doesn't contain unnecessary package installations.

I ran make all-depends-list from $PORTSDIR/ports-mgmt/synth.  Dependencies 
looked like packages I would need anyway.

I want to try to cross-compile Haiku and Linux toolchains (among other things).

I looked for synth in the online wiki.freebsd.org, found nothing, but did find 
portupgrade (no portmaster).

If FreeBSD users are to use synth, it needs to be in the documentation. 
Otherwise FreeBSD users will assume portupgrade or portmaster is the proper way 
to upgrade ports.

I would have thought there would be an Ada for ther platforms like PowerPC and 
(Ultra)Sparc.

Tom

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