www/nginx-devel redis module fetch error

[Jim Ohlstein]

Hello,

After the recent bump of the third party redis module to 0.3.9, I've
found it to be un-fetchable. See below:


=> ngx_http_redis-0.3.9.tar.gz doesn't seem to exist in /portdistfiles/.
=> Attempting to fetch
http://distcache.FreeBSD.org/local-distfiles/osa/ngx_http_redis-0.3.9.tar.gz
fetch:
http://distcache.FreeBSD.org/local-distfiles/osa/ngx_http_redis-0.3.9.tar.gz:
Not Found
=> Attempting to fetch
http://distcache.us-east.FreeBSD.org/local-distfiles/osa/ngx_http_redis-0.3.9.tar.gz
fetch:
http://distcache.us-east.FreeBSD.org/local-distfiles/osa/ngx_http_redis-0.3.9.tar.gz:
Not Found
=> Attempting to fetch
http://distcache.eu.FreeBSD.org/local-distfiles/osa/ngx_http_redis-0.3.9.tar.gz
fetch:
http://distcache.eu.FreeBSD.org/local-distfiles/osa/ngx_http_redis-0.3.9.tar.gz:
Not Found
=> Attempting to fetch
http://distcache.us-west.FreeBSD.org/local-distfiles/osa/ngx_http_redis-0.3.9.tar.gz
fetch:
http://distcache.us-west.FreeBSD.org/local-distfiles/osa/ngx_http_redis-0.3.9.tar.gz:
Not Found
=> Attempting to fetch
http://distcache.FreeBSD.org/ports-distfiles/ngx_http_redis-0.3.9.tar.gz
fetch:
http://distcache.FreeBSD.org/ports-distfiles/ngx_http_redis-0.3.9.tar.gz:
Not Found
=> Couldn't fetch it - please try to retrieve this
=> port manually into /portdistfiles/ and try again.
*** Error code 1

Stop.
make: stopped in /usr/ports/www/nginx-devel
=>> Cleaning up wrkdir
===>  Cleaning for nginx-devel-1.14.0_8
build of www/nginx-devel | nginx-devel-1.14.0_8 ended at Tue May 15
12:21:11 EDT 2018
build time: 00:00:30
!!! build failure encountered !!!

-- 
Jim Ohlstein
Professional Mailman Hosting
https://mailman-hosting.com



signature.asc
Description: OpenPGP digital signature

Re: The future of portmaster [and of ports-mgmt/synth]

[Jim Ohlstein]

On Fri, 2017-06-02 at 06:10 -0400, Stari Karp wrote:
> Looks like the new portmaster is coming but what is about Synth? I am
> the user of Synth and I like to know what the FreeBSD leaders
> decided,
> please.
> 

The "FreeBSD leaders," in their infinite wisdom, decided to can John
Marino. Synth development will likely go on, geared towards Dragonfly.
Whether it will support future FreeBSD ports enhancements is anyone's
guess. Whether gcc6-aux will ever be fixed for 12-CURRENT and 64 bit
inodes is also anyone's guess.

Sadly, it is/
was the best option for users looking to migrate to a "modern" tool for
whom poudriere was too much.

-- 
Jim Ohlstein
Professional Mailman Hosting
https://mailman-hosting.com/

___
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 future of portmaster [and of ports-mgmt/synth]

[Jim Ohlstein]

On Wed, 2017-05-31 at 12:47 +, Gerard Seibert wrote:
> I would just like a clarification here. For the record, synth is
> broken
> on FreeBSD-11 and above with amd64. Is that correct?

My understanding was that the breakage is in gcc6-aux on 12-CURRENT
with 64 bit inodes.

I may be wrong...

-- 
Jim Ohlstein
Professional Mailman Hosting
https://mailman-hosting.com/
___
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: [t...@iki.fi: v2.2.30 released]

[Jim Ohlstein]

On Tue, 2017-05-30 at 14:02 -0600, The Doctor wrote:
> Heads up!

How about submitting a patch for the upgrade? That would be helpful.

https://bugs.freebsd.org/bugzilla/

> 
> - Forwarded message from Timo Sirainen <t...@iki.fi> -
> 
> Date: Tue, 30 May 2017 21:16:31 +0300
> From: Timo Sirainen <t...@iki.fi>
> To: dovecot-n...@dovecot.org, Dovecot Mailing List <dovecot@dovecot.o
> rg>
> Subject: v2.2.30 released
> X-Mailer: Apple Mail (2.3273)
> 
> https://dovecot.org/releases/2.2/dovecot-2.2.30.tar.gz
> https://dovecot.org/releases/2.2/dovecot-2.2.30.tar.gz.sig
> 
>  * auth: Use timing safe comparisons for everything related to
>passwords. It's unlikely that these could have been used for
>practical attacks, especially because Dovecot delays and flushes
> all
>failed authentications in 2 second intervals. Also it could have
>worked only when passwords were stored in plaintext in the passdb.
>  * master process sends SIGQUIT to all running children at shutdown,
>which instructs them to close all the socket listeners
> immediately.
>This way restarting Dovecot should no longer fail due to some
>processes keeping the listeners open for a long time.
> 
>  + auth: Add passdb { mechanisms=none } to match separate passdb
> lookup
>  + auth: Add passdb { username_filter } to use passdb only if user
>matches the filter. See https://wiki2.dovecot.org/PasswordDatabase
>  + dsync: Add dsync_commit_msgs_interval setting. It attempts to
> commit
>the transaction after saving this many new messages. Because of
> the
>way dsync works, it may not always be possible if mails are copied
>or UIDs need to change.
>  + imapc: Support imapc_features=search without ESEARCH extension.
>  + imapc: Add imapc_features=fetch-bodystructure to pass through
> remote
>server's FETCH BODY and BODYSTRUCTURE.
>  + imapc: Add quota=imapc backend to use GETQUOTA/GETQUOTAROOT on the
>remote server.
>  + passdb imap: Add allow_invalid_cert and ssl_ca_file parameters.
>  + If dovecot.index.cache corruption is detected, reset only the one
>corrupted mail instead of the whole file.
>  + doveadm mailbox status: Add "firstsaved" field.
>  + director_flush_socket: Add old host's up/down and vhost count as
> parameters
>  - More fixes to automatically fix corruption in dovecot.list.index
>  - dsync-server: Fix support for dsync_features=empty-header-
> workaround
>  - imapc: Various bugfixes, including infinite loops on some errors
>  - IMAP NOTIFY wasn't working for non-INBOX if IMAP client hadn't
>enabled modseq tracking via CONDSTORE/QRESYNC.
>  - fts-lucene: Fix it to work again with mbox format
>  - Some internal error messages may have contained garbage in v2.2.29
>  - mail-crypt: Re-encrypt when copying/moving mails and per-mailbox
> keys
>are used. Otherwise the copied mails can't be opened.
>  - vpopmail: Fix compiling
> 
> - End forwarded message -
> 
-- 
Jim Ohlstein
Professional Mailman Hosting
https://mailman-hosting.com/
___
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 future of portmaster

[Jim Ohlstein]

On Tue, 2017-05-30 at 14:25 -0600, Adam Weinberger wrote:
> > On 30 May, 2017, at 14:19, Thomas Mueller <mueller6...@twc.com>
> > wrote:
> > 
> > 
> > One thing I forgot to mention in my last post is that the UPDATING
> > file looks geared to portmaster and portupgrade.
> > 
> > Users are thus led to believe that portupgrade and portmaster are
> > still the currently recommended tools.
> > 
> > If the ports people want to get users to switch to synth or
> > poudriere, updating instructions should include synth and
> > poudriere.
> 
> There are no updating instructions for them. They do the right thing
> automatically. Only portmaster needs its hand held every time
> something gets updated.
> 
> The only difference is that things go into a make.conf in
> /usr/local/etc/poudriere.d/ rather than /etc/make.conf (see
> CUSTOMISATION in poudriere(8) for details), and I don't know if synth
> has a special place for it too.
> 

And not only that, but poudriere reads MOVED as well.

> 
-- 
Jim Ohlstein
Professional Mailman Hosting
https://mailman-hosting.com/
___
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: Several PostgreSQL versions installed

[Jim Ohlstein]

On Thu, 2017-05-25 at 22:06 +0200, Baptiste Daroussin wrote:
> On Thu, May 25, 2017 at 09:59:08PM +0200, José García Juanino wrote:
> > Hi FreeBSD porters,
> > 
> > 
> > I have been read the following thread
> > 
> > "Proposal to fix postgresql package maintainance nightmare"
> > 
> > https://lists.freebsd.org/pipermail/freebsd-ports/2015-July/099842.
> > html
> > 
> > but I think that, two years later, there is no progress on this
> > matter.
> > I am unaware if there is any project that addresses this issue, so
> > my
> > apologies if this work is already in progress.
> 
> No progress as far as I am aware. except a PoC (early, ugly,
> unfinished)
> https://people.freebsd.org/~bapt/pgsql95.diff
> 
> > 
> > The goal of the new postgresql port schema should be, in my honest
> > opinion:
> > 
> > * It must allow to install distinct version without ugly hacks as
> > jails,
> >   etc. Jails are a overkill to accomplish this task.
> > 
> > * Each software version must live in a separate directory
> > ${LOCALBASE}/pgsql/X.Y:
> > 
> > /usr/local/pgsql/9.2
> > /usr/local/pgsql/9.4
> > /usr/local/pgsql/9.6
> > 
> >   and so on.
> 
> Yes this is what I was proposing
> > 
> > 
> > * It is not necessary to provide an installed version as the
> > default.
> >   For example, if we need 9.5 and 9.6 versions installed, both are
> >   equally valid, and we do not need the standard postgresql
> > binaries
> >   (pg_dump, psql, pg_ctl, etc) installed in the standard PATH as
> >   /bin:/usr/bin:/usr/local/bin.  Those binaries are located under
> >   /usr/local/pgsql/X.Y/bin directory, and everyone can configure
> > the
> >   shell environment variable PATH to add the previous directory:
> >   PATH=$PATH:/usr/local/pgsql/X.Y/bin. Please do not make symlinks
> > from
> >   /usr/local/bin/pg_some to specific
> > /usr/local/pgsql/X.Y/bin/pg_some,
> >   it has very little advantages and a lot of drawbacks. Under a
> > prompt
> >   command line, a skilled database administrator always need to
> > know
> >   what command version is executing and do not need an standard
> > location
> >   as /usr/local/bin.
> 
> For a database administrator yes playing with the path is enough, but
> for a new
> comer installing pgsql for his blog this would be complicated
> > 
> > 
> > * The rc and the periodic script must be versioned also:
> > 
> > /usr/local/etc/rc.d/postgresql9.6
> > /usr/local/etc/rc.d/postgresql5.6
> > 
> 
> yes
> 
> One important thing is there is a need for a small modification for
> the
> postgresql build system: add a proper RUNPATH for the binaries to
> always find
> the right libpq
> 
> > 
> > 
> > Best regards, and thanks to the volunteers for make FreeBSD an
> > great
> > operating system!
> > 
> 
> Note that the same should apply to mysql/mariadb/etc
> 

And in a perfect world, PHP also. We run different versions in
different jails now. While it works, it is a bit of overkill.

-- 
Jim Ohlstein
Professional Mailman Hosting
https://mailman-hosting.com/
___
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: Recoll version bump in ports

[Jim Ohlstein]

Hello,

On 05/23/2017 11:15 AM, Matthew Seaman wrote:

On 2017/05/23 15:58, Jim Ohlstein wrote:



On 05/23/2017 10:54 AM, Matthew Seaman wrote:

On 2017/05/23 15:38, Michael L. Wilson wrote:

Now, I do happen to know what filters/rclpdf is and what it does. But in
this case I am not sure what make is asking for or how to proceed to
step. I could potentially accomplish this with some walk through.


filters/rclpdf is a run- or build- depends of deskutils/recoll that the
ports wants to install during the build process.  It seem you don't have
a full ports tree where you're testing your updated port.

One way around this is to run 'make missing' or 'make missing-packages'
from the deskutils/recoll port directory, and install any of the
packages listed there.



I thought that at first, but I don't have any port by that name.



True.  I had that awful moment of realization that there isn't a ports
category called 'filters' pretty much just as soon as I pressed 'send'.

This will be a file the port expects to find under ${WRKDIR} in order to
apply a SHEBANG fix to it.  Looks like that file no-longer exists in the
sources of the latest version of recoll, so you can just edit the
SHEBANG_FILES setting in the ports Makefile to work around the problem.
If that file is now auto-generated, you'll need to check that it doesn't
need the same sort of fix once it has been generated.  Otherwise, if the
file has simply been removed from the port entirely you'll need to
adjust the pkg-plist.

This doesn't look like an entirely simple update: might not be such a
good 'my first port' candidate...



Mea culpa...

--
Jim Ohlstein
Professional Mailman Hosting
https://mailman-hosting.com/
___
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: Recoll version bump in ports

[Jim Ohlstein]

On 05/23/2017 10:54 AM, Matthew Seaman wrote:

On 2017/05/23 15:38, Michael L. Wilson wrote:

Now, I do happen to know what filters/rclpdf is and what it does. But in
this case I am not sure what make is asking for or how to proceed to
step. I could potentially accomplish this with some walk through.


filters/rclpdf is a run- or build- depends of deskutils/recoll that the
ports wants to install during the build process.  It seem you don't have
a full ports tree where you're testing your updated port.

One way around this is to run 'make missing' or 'make missing-packages'
from the deskutils/recoll port directory, and install any of the
packages listed there.



I thought that at first, but I don't have any port by that name.

--
Jim Ohlstein
Professional Mailman Hosting
https://mailman-hosting.com/
___
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: Recoll version bump in ports

[Jim Ohlstein]

Hello,

On 05/23/2017 10:38 AM, Michael L. Wilson wrote:

Alright, I got as far as:

make -DBATCH install clean

===>  License GPLv2+ accepted by the user
===>   recoll-1.23.2_1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by recoll-1.23.2_1 for building
===>  Extracting for recoll-1.23.2_1
=> SHA256 Checksum OK for recoll-1.23.2.tar.gz.
===>  Patching for recoll-1.23.2_1
sed: filters/rclpdf: No such file or directory
*** Error code 1

Stop.
make: stopped in /usr/ports/deskutils/recoll


As Jerry Seinfeld would say, that's a shame. That isn't the file to be 
patched, so I'm *guessing* it's a problem that might need to be referred 
upstream. There's no maintainer, unfortunately...





Now, I do happen to know what filters/rclpdf is and what it does. But in 
this case I am not sure what make is asking for or how to proceed to 
step. I could potentially accomplish this with some walk through.


Mike

On 05/23/2017 04:30 PM, Jim Ohlstein wrote:

Hello,

On 05/23/2017 09:12 AM, Michael L. Wilson wrote:

Hi!

Thanks for the reply.

I could if I had the necessary skillset :)


It doesn't look too complicated:

1. Update the Makefile with the latest version info.

2. Run 'make makesum' to update the distino file.

3. Looks like there's one minor patch which may (or may not) need 
tweaking.


4. Try building.

5. If it succeeds, run 'make clean' and then 'svnlite diff'.

6. Post the output from the last command to bugs.freebsd.org.



On 05/23/2017 03:19 PM, Kurt Jaeger wrote:

Hi!


Might there be a possibility of having the current deskutils/recoll
version in ports recoll-1.21.6, bumped to the current release 1.23.2?
The new release fixes a number of serious bugs and has additional
features.


Do you think you can provide a patch ? Via bugs.freebsd.org ?



--
Jim Ohlstein
Professional Mailman Hosting
https://mailman-hosting.com/
___
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: Recoll version bump in ports

[Jim Ohlstein]

Hello,

On 05/23/2017 09:12 AM, Michael L. Wilson wrote:

Hi!

Thanks for the reply.

I could if I had the necessary skillset :)


It doesn't look too complicated:

1. Update the Makefile with the latest version info.

2. Run 'make makesum' to update the distino file.

3. Looks like there's one minor patch which may (or may not) need tweaking.

4. Try building.

5. If it succeeds, run 'make clean' and then 'svnlite diff'.

6. Post the output from the last command to bugs.freebsd.org.



On 05/23/2017 03:19 PM, Kurt Jaeger wrote:

Hi!


Might there be a possibility of having the current deskutils/recoll
version in ports recoll-1.21.6, bumped to the current release 1.23.2?
The new release fixes a number of serious bugs and has additional
features.


Do you think you can provide a patch ? Via bugs.freebsd.org ?


--
Jim Ohlstein
Professional Mailman Hosting
https://mailman-hosting.com/
___
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: ICU Portupdate faulty

[Jim Ohlstein]

Hello,

On 05/05/2017 11:37 AM, Jos Chrispijn wrote:

I am really not a fan of that.

Better would be to solve the 'vulneratbilities' issue.
/Jos


The vulnerabilites are outlined in 
http://www.vuxml.org/freebsd/607f8b57-7454-42c6-a88a-8706f327076d.html 
and appear to be patched in devel/icu 58.2_2,1 committed yesterday. See 
https://svnweb.freebsd.org/ports?view=revision=440117.




Op 5-5-2017 om 17:24 schreef mokhi:

It seems the port has known vulnerabilities.
If you are sure about what you are doing, run the make command with
"DISABLE_VULNERABILITIES=yes" option as it suggests.


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

Hash mismatch www/owncloud (10.0.0)

[Jim Ohlstein]

Helllo,

I did a fresh install today and received a "code integrity" error in the 
admin page. It led to this:


Technical information
=
The following list covers which files have failed the integrity check. 
Please read
the previous linked documentation to learn more about the errors and how 
to fix

them.

Results
===
- user_external
- INVALID_HASH
- lib/smb.php

Raw output
==
Array
(
[user_external] => Array
(
[INVALID_HASH] => Array
(
[lib/smb.php] => Array
(
[expected] => some_hash
[current] => a_different_hash"
)

)

)

)

Repeated the install and got the same error.

I haven't done much testing, but the script seems to be "working".

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

Committer needed

[Jim Ohlstein]

Hello,

I have a very simple port called "ct-submit" for submitting ssl 
certificates to transparency logs. It's been sitting almost three 
months. If someone would take a look I'd be much obliged.


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

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

Re: pkg problem

[Jim Ohlstein]

Hello,

> On Mar 28, 2017, at 2:48 PM, Alan Somers <asom...@freebsd.org> wrote:
> 
> Try setting DEFAULT_VERSIONS=pgsql=9.6 in /etc/make.conf.  Then any
> ports that use postgres will have to be rebuilt from ports instead of
> installed through pkg.
> -Alan

I believe he's using packages. 

> 
>> On Tue, Mar 28, 2017 at 12:24 PM, Jim Ohlstein <j...@ohlste.in> wrote:
>> Hello,
>> 
>> [cc'ing to ports mailing list since it seems more appropriate there]
>> 
>>> On 3/28/17 10:25 AM, m...@ft-c.de wrote:
>>> 
>>> Hello,
>>> 
>>> when I update/upgrade freebsd with pkg,
>>> pkg would install the postgresql93-client,
>>> but postgresql* version 9.6 is installed.
>> 
>> 
>> 
>> It appears as though $something that you are trying to upgrade has a
>> dependency on postgresql-client. Since postgresql93 is the default version
>> for FreeBSD packages, $something is built against postgresql93-client, and
>> is trying to pull it in as a dependency. That would cause
>> postgresql96-client to be deinstalled, which would then cause pretty much
>> anything postgresql96 related to be removed. Those packages are locked,
>> hence the failure.
>> 
>> 
>>> 
>>> What's going wrong?
>>> Have someoen a solution?
>>> 
>>> I get the following messages:
>>> 
>>> % pkg upgrade
>>> Updating FreeBSD repository catalogue...
>>> FreeBSD repository is up-to-date.
>>> All repositories are up-to-date.
>>> 
>>> postgresql96-plpython-9.6.0_1 is locked and may not be modified
>>> postgresql96-plperl-9.6.0_1 is locked and may not be modified
>>> postgresql96-contrib-9.6.1 is locked and may not be modified
>>> pgtcl-postgresql96-2.0.0_1 is locked and may not be modified
>>> pgadmin3-1.22.1_3 is locked and may not be modified
>>> pgtcl-postgresql96-2.0.0_1 is locked and may not be modified
>>> postgresql96-server-9.6.1_1 is locked and may not be modified
>>> pgadmin3-1.22.1_3 is locked and may not be modified
>>> pgadmin3-1.22.1_3 is locked and may not be modified
>>> pgadmin3-1.22.1_3 is locked and may not be modified
>>> postgresql96-contrib-9.6.1 is locked and may not be modified
>>> pgadmin3-1.22.1_3 is locked and may not be modified
>>> pgadmin3-1.22.1_3 is locked and may not be modified
>>> postgresql96-plperl-9.6.0_1 is locked and may not be modified
>>> postgresql96-client-9.6.1 is locked and may not be modified
>>> postgresql96-plperl-9.6.0_1 is locked and may not be modified
>>> postgresql96-client-9.6.1 is locked and may not be modified
>>> postgresql96-plpython-9.6.0_1 is locked and may not be modified
>>> pgadmin3-1.22.1_3 is locked and may not be modified
>>> postgresql96-server-9.6.1_1 is locked and may not be modified
>>> postgresql96-client-9.6.1 is locked and may not be modified
>>> pgadmin3-1.22.1_3 is locked and may not be modified
>>> pgadmin3-1.22.1_3 is locked and may not be modified
>>> postgresql96-server-9.6.1_1 is locked and may not be modified
>>> postgresql96-contrib-9.6.1 is locked and may not be modified
>>> pgadmin3-1.22.1_3 is locked and may not be modified
>>> postgresql96-client-9.6.1 is locked and may not be modified
>>> postgresql96-client-9.6.1 is locked and may not be modified
>>> 
>>> The following 32 package(s) will be affected (of 0 checked):
>>> 
>>> New packages to be INSTALLED:
>>>postgresql93-client: 9.3.15_1
>>> 
>>> Installed packages to be UPGRADED:
>>>php70-zlib: 7.0.16 -> 7.0.17
>>>... (more)
>>>php70-pgsql: 7.0.16 -> 7.0.17
>>>php70-pdo_sqlite: 7.0.16 -> 7.0.17
>>>php70-pdo_pgsql: 7.0.16 -> 7.0.17
>>>php70-pdo: 7.0.16 -> 7.0.17
>>>... (more)
>>>nspr: 4.13.1 -> 4.14
>>>mod_php70: 7.0.16 -> 7.0.17
>>>git: 2.11.0_3 -> 2.12.1
>>> 
>>> Installed packages to be REINSTALLED:
>>>apache24-2.4.25_1 (options changed)
>>> 
>>> Number of packages to be installed: 1
>>> Number of packages to be upgraded: 30
>>> Number of packages to be reinstalled: 1
>>> 
>>> The process will require 10 MiB more space.
>>> 234 KiB to be downloaded.
>>> 
>>> 
>>> 
>>> % pkg upgrade git
>>> Updating FreeBSD repository catalogue...
>>> FreeBSD repository is up-to-date.
>>> All repositories are up-to-date.

Re: pkg problem

[Jim Ohlstein]

Hello,

[cc'ing to ports mailing list since it seems more appropriate there]

On 3/28/17 10:25 AM, m...@ft-c.de wrote:

Hello,

when I update/upgrade freebsd with pkg,
pkg would install the postgresql93-client,
but postgresql* version 9.6 is installed.



It appears as though $something that you are trying to upgrade has a 
dependency on postgresql-client. Since postgresql93 is the default 
version for FreeBSD packages, $something is built against 
postgresql93-client, and is trying to pull it in as a dependency. That 
would cause postgresql96-client to be deinstalled, which would then 
cause pretty much anything postgresql96 related to be removed. Those 
packages are locked, hence the failure.




What's going wrong?
Have someoen a solution?

I get the following messages:

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

postgresql96-plpython-9.6.0_1 is locked and may not be modified
postgresql96-plperl-9.6.0_1 is locked and may not be modified
postgresql96-contrib-9.6.1 is locked and may not be modified
pgtcl-postgresql96-2.0.0_1 is locked and may not be modified
pgadmin3-1.22.1_3 is locked and may not be modified
pgtcl-postgresql96-2.0.0_1 is locked and may not be modified
postgresql96-server-9.6.1_1 is locked and may not be modified
pgadmin3-1.22.1_3 is locked and may not be modified
pgadmin3-1.22.1_3 is locked and may not be modified
pgadmin3-1.22.1_3 is locked and may not be modified
postgresql96-contrib-9.6.1 is locked and may not be modified
pgadmin3-1.22.1_3 is locked and may not be modified
pgadmin3-1.22.1_3 is locked and may not be modified
postgresql96-plperl-9.6.0_1 is locked and may not be modified
postgresql96-client-9.6.1 is locked and may not be modified
postgresql96-plperl-9.6.0_1 is locked and may not be modified
postgresql96-client-9.6.1 is locked and may not be modified
postgresql96-plpython-9.6.0_1 is locked and may not be modified
pgadmin3-1.22.1_3 is locked and may not be modified
postgresql96-server-9.6.1_1 is locked and may not be modified
postgresql96-client-9.6.1 is locked and may not be modified
pgadmin3-1.22.1_3 is locked and may not be modified
pgadmin3-1.22.1_3 is locked and may not be modified
postgresql96-server-9.6.1_1 is locked and may not be modified
postgresql96-contrib-9.6.1 is locked and may not be modified
pgadmin3-1.22.1_3 is locked and may not be modified
postgresql96-client-9.6.1 is locked and may not be modified
postgresql96-client-9.6.1 is locked and may not be modified

The following 32 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
postgresql93-client: 9.3.15_1

Installed packages to be UPGRADED:
php70-zlib: 7.0.16 -> 7.0.17
... (more)
php70-pgsql: 7.0.16 -> 7.0.17
php70-pdo_sqlite: 7.0.16 -> 7.0.17
php70-pdo_pgsql: 7.0.16 -> 7.0.17
php70-pdo: 7.0.16 -> 7.0.17
... (more)
nspr: 4.13.1 -> 4.14
mod_php70: 7.0.16 -> 7.0.17
git: 2.11.0_3 -> 2.12.1

Installed packages to be REINSTALLED:
apache24-2.4.25_1 (options changed)

Number of packages to be installed: 1
Number of packages to be upgraded: 30
Number of packages to be reinstalled: 1

The process will require 10 MiB more space.
234 KiB to be downloaded.



% pkg upgrade git
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
pgtcl-postgresql96-2.0.0_1 is locked and may not be modified
... (more: see above)

Checking integrity...
Assertion failed: (cun != NULL), function
pkg_conflicts_check_chain_conflict, file pkg_jobs_conflicts.c, line 499.
Child process pid=2230 terminated abnormally: Abort trap



% uname -a
FreeBSD ftc2 11.0-RELEASE-p2 FreeBSD 11.0-RELEASE-p2 #0: Mon Oct 24
06:55:27 UTC 2016
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64




--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

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

Re: devel/libevent shopstopper

[Jim Ohlstein]

Hello,

On 02/20/2017 11:11 AM, The Doctor wrote:



We have a big one!!


Yup, it's a big one. That's why there's an entry in /usr/ports/UPDATING:

20170220:
  AFFECTS: devel/libevent2
  AUTHOR: jbe...@freebsd.org

  libevent2 has been renamed back to libevent as the default version.
  If you manage out of tree ports make sure to run the following:

# pkg set -n libevent2:libevent
# pkg set -o devel/libevent2:devel/libevent



Libevent compiles but does not install

===>  Installing for libevent-2.1.8
===>  Checking if libevent already installed
===>   Registering installation for libevent-2.1.8 as automatic
Installing libevent-2.1.8...
pkg-static: libevent-2.1.8 conflicts with libevent2-2.1.8 (installs files into 
the same place).  Problematic file: /usr/local/bin/event_rpcgen.py
*** Error code 70

Stop.
make[1]: stopped in /usr/ports/devel/libevent
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/libevent

===>>> Installation of libevent-2.1.8 (devel/libevent) failed
===>>> Aborting update

===>>> Update for devel/libevent failed
===>>> Aborting update

Also

pkg delete -f libevent
Updating database digests format: 100%
No packages matched for pattern 'libevent'

Checking integrity... done (0 conflicting)
Package(s) not found!

Please fix!!



Not surprising since that is the port that won't install on your system.

Instead:

# pkg delete -f libevent2

and then recompile devel/libevent and any ports that depend on it.

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

Re: Expulsion of John Marino - reasons and impact?

[Jim Ohlstein]

Hello,

On 02/14/2017 06:15 PM, Bryan Drewery wrote:

On 2/14/2017 2:58 PM, Michael Gmelin wrote:

On 14 Feb 2017, at 22:16, Bryan Drewery <bdrew...@freebsd.org> wrote:

On 2/14/2017 12:50 PM, Dewayne Geraghty wrote:
https://svnweb.freebsd.org/ports?view=revision=433827

I think that commit message combined with
https://www.freebsd.org/internal/code-of-conduct.html is enough.

The commit message basically says that he misbehaved once too often and the CoC defines 
what "misbehave" might mean. Not over the top transparent/detailed to be honest.


Right, would you want an organization you volunteered for to drag your
name through the mud for some reason?  I don't think it's our place (the
project) to say more than we already have publicly.  Please drop this
before it gets out of hand.  Discussing people personally/negatively in
a public forum is not appropriate.



John has posted on the FreeBSD forums[1] that he did nothing and that 
there is "[no] evidence of continued bad behavior", so this argument 
holds no water any longer.


Don't get me wrong, I am not defending him. I have witnessed his nature 
publicly, and I have been on the receiving end here on the list and 
privately. However, he was an extremely active committer and at a time 
when PR's wait for committers, people complain that there aren't enough 
volunteers, and mentors are maxed out, perhaps a simple "trust us" (to 
use John's words) does not suffice. JMMHO of course.



[1] https://forums.freebsd.org/threads/59705/#post-342589
--
Jim Ohlstein
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Recent update to lang/php70 and lang/php71

[Jim Ohlstein]

Hello,

On 02/02/2017 04:35 AM, Torsten Zuehlsdorff wrote:

Hello Jim,


Could not this semantic change have waited for a new version? It forced
a rebuild of ALL PHP extensions for no reason. They all had a dependency
on devel/pcre via the main port as it was.


Did you use poudriere?


Yes



It wasn't meant to force a rebuild. There was no PORTREVISION bump nor a
new dependency. But poudriere detect a new one, so i would say its a
poudriere bug. Or am i wrong?


Looks like a direct dependency was added. Here's a sample output from a 
jail that runs PHP70:


Installed packages to be REINSTALLED:
php70-zlib-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-zip-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-xsl-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-xmlwriter-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-xmlreader-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-xml-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-wddx-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-sqlite3-7.0.15 [poudriere-php70] (direct dependency changed: pcre)
php70-simplexml-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-session-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-posix-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-pdo_sqlite-7.0.15 [poudriere-php70] (direct dependency changed: 
pcre)
php70-pdo_mysql-7.0.15 [poudriere-php70] (direct dependency changed: 
pcre)
php70-pdo-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-openssl-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-mbstring-7.0.15 [poudriere-php70] (direct dependency changed: 
pcre)
php70-json-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-iconv-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-hash-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-filter-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-fileinfo-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-exif-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-dom-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-curl-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-ctype-7.0.15 [poudriere-php70] (direct dependency added: pcre)
php70-bz2-7.0.15 [poudriere-php70] (direct dependency added: pcre)



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

Recent update to lang/php70 and lang/php71

[Jim Ohlstein]

Hello,

Thanks for your hard work.

Could not this semantic change have waited for a new version? It forced 
a rebuild of ALL PHP extensions for no reason. They all had a dependency 
on devel/pcre via the main port as it was.


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

Re: Checking port option descriptions

[Jim Ohlstein]

Hello,

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

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

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

For example:

  XYZEnable XYZ

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

  XYZInclude protocols for use with XYZ servers

This gives the reader some additional details.


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


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


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


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


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





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

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

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

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

For usage, run
  optcheck -h

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

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



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

Re: Update to mariadb101-client-10.1.16 failure

[Jim Ohlstein]

Hello,

On 7/24/16 9:15 AM, Bernard Spil wrote:

On 2016-07-24 14:25, Jim Ohlstein wrote:

Hello,

On 07/24/16 05:42, Mark J. Carpio wrote:

Hello all,

I am seeing an issue when attempting to update mariadb10.1

uname:

   FreeBSD 10.3-RELEASE-p4 #0: Sat May 28 12:23:44 UTC 2016
   r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64


Error seen during portmaster update:

   ===>  Applying FreeBSD patches for mariadb101-client-10.1.16

1 out of 7 hunks failed--saving rejects to scripts/CMakeLists.txt.rej
=> Patch patch-scripts_CMakeLists.txt failed to apply cleanly.
=> Patch(es) patch-CMakeLists.txt patch-client_CMakeLists.txt
patch-cmake_ssl.cmake patch-extra_CMakeLists.txt
patch-include_CMakeLists.txt patch-include_my__compare.h
patch-libmysql_CMakeLists.txt patch-libservices_CMakeLists.txt
patch-man_CMakeLists.txt patch-mysys_my__default.c
patch-pcre_CMakeLists.txt applied cleanly.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/databases/mariadb101-client
*** Error code 1

Stop.
make: stopped in /usr/ports/databases/mariadb101-client

===>>> make build failed for databases/mariadb101-client
===>>> Aborting update

===>>> Update for databases/mariadb101-client failed
===>>> Aborting update



Seeing the same thing, cc'd maintainer.

--
Jim


Hi Jiim,

Can you check again (update your ports tree)? I believe I fixed this
issue earlier today. Initially I only submitted the update to -server,
today I committed the changes to -client.



Yes, -client built successfully, -server is building now so it's well 
past the patch stage.


Thanks!

--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Update to mariadb101-client-10.1.16 failure

[Jim Ohlstein]

Hello,

On 07/24/16 05:42, Mark J. Carpio wrote:

Hello all,

I am seeing an issue when attempting to update mariadb10.1

uname:

   FreeBSD 10.3-RELEASE-p4 #0: Sat May 28 12:23:44 UTC 2016
   r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64


Error seen during portmaster update:

   ===>  Applying FreeBSD patches for mariadb101-client-10.1.16

1 out of 7 hunks failed--saving rejects to scripts/CMakeLists.txt.rej
=> Patch patch-scripts_CMakeLists.txt failed to apply cleanly.
=> Patch(es) patch-CMakeLists.txt patch-client_CMakeLists.txt
patch-cmake_ssl.cmake patch-extra_CMakeLists.txt
patch-include_CMakeLists.txt patch-include_my__compare.h
patch-libmysql_CMakeLists.txt patch-libservices_CMakeLists.txt
patch-man_CMakeLists.txt patch-mysys_my__default.c
patch-pcre_CMakeLists.txt applied cleanly.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/databases/mariadb101-client
*** Error code 1

Stop.
make: stopped in /usr/ports/databases/mariadb101-client

===>>> make build failed for databases/mariadb101-client
===>>> Aborting update

===>>> Update for databases/mariadb101-client failed
===>>> Aborting update



Seeing the same thing, cc'd maintainer.

--
Jim
___
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: curl and nginx no longer build on same host

[Jim Ohlstein]

Hello,

> On Jul 18, 2016, at 6:44 PM, Euan Thoms <e...@potensol.com> wrote:
> 
> 
>> On Tuesday, July 19, 2016 05:11 SGT, Jim Ohlstein <j...@ohlste.in> wrote: 
>> 
>> Hello,
>> 
>>> On Jul 18, 2016, at 4:37 PM, Euan Thoms <e...@potensol.com> wrote:
> 
> 
>>> OK, I'm clear about the make.conf options and what they mean. But I still 
>>> have a problem in that even if I use DEFAULT_VERSIONS+=ssl=openssl, 
>>> ftp/curl will not build, certainly not with portmaster and I think I tried 
>>> building it manually from inside it's ports directory.
>>> 
>>> /usr/ports/ftp/curl]# make
>>> ===>  curl-7.49.1 GSSAPI_BASE is not compatible with OpenSSL from ports. Use
>>> other GSSAPI options or OpenSSL from base system.
>>> *** Error code 1
>>> 
>>> Stop.
>>> make: stopped in /usr/ports/ftp/curl
>>> 
>>> 
>>> So basically, I'd have to change one of the GSSAPI options in ftp/curl. 
>>> Except I haven't got a clue on the ramifications of this. Do I need GSSAPI? 
>>> If so, should I use Heimdal or MIT?
>>> 
>>> So you see my point, it's not friendly on new FreeBSD users. I'm a fairly 
>>> experienced FreeBSD sys-adimin and I don't know what to do in this case.
>>> 
>>> At least I now know that there is a good reason to not have on port built 
>>> against base openssl and another built against ports openssl.
>> 
>> So basically they've deprecated a useful option without replicating the 
>> functionality. Bravo! 
>> 
>> Fortunately, it still works as intended.
> 
> 
> Aha, I got ftp/curl to build using WITH_OPENSSL_PORT=yes. Don't know why I 
> didn't try it before, perhaps since it is deprecated.
> 
> So, I think we need to address some shortcoming in the new macro 
> DEFAULT_VERSIONS+=ssl=openssl.
> 
> Perhaps I should create a new thread, with a more appropriate subject line? 
> Any suggestions?

That's evidently above my pay grade.

I recall recently there was a discussion of building all ports against the 
openssl port. It got lengthy and I stopped reading it. That's what that 
function does. Deprecating that function without forcing use of the openssl 
port was not wise IMMHO, but again, my opinion apparently doesn't matter. 

--
Jim
___
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: curl and nginx no longer build on same host

[Jim Ohlstein]

Hello,

> On Jul 18, 2016, at 4:37 PM, Euan Thoms <e...@potensol.com> wrote:
> 
> 
>> On Tuesday, July 19, 2016 04:03 SGT, Kevin Oberman <rkober...@gmail.com> 
>> wrote: 
>> 
>>> On Mon, Jul 18, 2016 at 12:45 PM, Euan Thoms <e...@potensol.com> wrote:
>>> 
>>> 
>>> On Saturday, July 16, 2016 20:43 SGT, Jim Ohlstein <j...@ohlste.in> wrote:
> 
>>> 
>>> OK, I understand. And I'm glad we're heading somewhere where we will have
>>> more consistency. I just feel that we shouldn't need anything in
>>> /etc/make.conf unless we are exerting some extra control and using
> 
>>> non-default options. I've managed to get away without anything in
>>> /etc/make.conf on all my jails, collectively they install quite a range of
>>> software types.
>>> 
>>> Are you sure that WITH_OPENSSL_PORT isn't deprecated. I got some warnings
>>> to that effect. So I've been using USES+=ssl=openssl instead. Perhaps
>>> that's part of the problem, maybe the ftp/curl port is still using the
>>> older make.conf flag. I'll try it next time I update.
>>> 
>>> Thanks Jim.
> 
>> 
>> Yes and no. WITH_OPENSSL_PORT in make,conf has been deprecated. It should
>> still work, but you should update to the new syntax. If you do use it, you
>> should see the following:
>> "Using WITH_OPENSSL_PORT in make.conf is deprecated, replace it with
>> DEFAULT_VERSIONS+=ssl=openssl in your make.conf"
>> 
>> To avoid conflicting SSL libraries in different ports, it is bast to put
>> the "DEFAULT_VERSIONS+=ssl=openssl" in /etc/make.conf. If you use base
>> OpsnSSL in some ports that create shareable libraries and the ports version
>> in others, you will eventually hit an executable, possibly from a third
>> port, that is linked to both and those programs will not run.
> 
> OK, I'm clear about the make.conf options and what they mean. But I still 
> have a problem in that even if I use DEFAULT_VERSIONS+=ssl=openssl, ftp/curl 
> will not build, certainly not with portmaster and I think I tried building it 
> manually from inside it's ports directory.
> 
> /usr/ports/ftp/curl]# make
> ===>  curl-7.49.1 GSSAPI_BASE is not compatible with OpenSSL from ports. Use
> other GSSAPI options or OpenSSL from base system.
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/ftp/curl
> 
> 
> So basically, I'd have to change one of the GSSAPI options in ftp/curl. 
> Except I haven't got a clue on the ramifications of this. Do I need GSSAPI? 
> If so, should I use Heimdal or MIT?
> 
> So you see my point, it's not friendly on new FreeBSD users. I'm a fairly 
> experienced FreeBSD sys-adimin and I don't know what to do in this case.
> 
> At least I now know that there is a good reason to not have on port built 
> against base openssl and another built against ports openssl. 

So basically they've deprecated a useful option without replicating the 
functionality. Bravo! 

Fortunately, it still works as intended. 

--
Jim
___
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: curl and nginx no longer build on same host

[Jim Ohlstein]

Hello,

On 7/15/16 11:41 PM, Euan Thoms wrote:


On Saturday, July 16, 2016 10:21 SGT, Jim Ohlstein <j...@ohlste.in> wrote:


Hello,


On Jul 15, 2016, at 10:03 PM, Euan Thoms <e...@potensol.com> wrote:

Bump

Can anyone else install or update ftp/curl after installing nginx?




Yes, but I'm building packages using poudriere, not using portmaster.


Good point, it may be a portmaster issue. Next time I update, I'll try to 
upgrade manually... eh, how do I do that again (scratches head).





The only way I'm able to update now is to uninstall openssl and nginx, then 
update curl, then reinstall nginx (which pulls in openssl). This was not 
required on several previous update cycles.


If memory serves me correctly, nginx and curl both require openssl from ports 
only if certain options are chosen (http2 being one), or at least that was the 
case in the past.

You may have option(s) selected for one that requires the version from ports, 
and one that does not.

Have you tried to force usage of openssl from ports in your /etc/make.conf?



Yes. I've used ssl=openssl and ssl=libressl in make.conf, no luck with either. 
The bottom line is ftp/curl with default port options does not want to build 
against openssl or libressl from ports. And it doesn't want to try and use the 
base openssl either.

Your point about the port options for http2 requiring the ports version of 
openssl is valid. But this happens when the default options for both ports are 
used. I could accept my manual workaround if I had changed the default port 
options on either of the two ports. But default port options should build 
together.

I suppose this has only come about on this upgrade cycle because nginx port now 
has http2 on by default?


As of version 1.10.0 it appears http2 is selected by default. It has 
been the default in www/nginx-devel for some time. it is not the default 
for ftp/curl:


OPTIONS_DEFAULT=CA_BUNDLE COOKIES OPENSSL PROXY RESOLV 
THREADED_RESOLVER TLS_SRP


My /etc/make.conf has the following:

WITH_OPENSSL_PORT=yes

That will force ftp/curl (and all ports) to build against the openssl 
port. If I understand correctly, that is about to become the default 
behavior for all ports at some time in the not so distant future, or at 
least it has been proposed.








On Thursday, July 14, 2016 23:30 SGT, "Euan Thoms" <e...@potensol.com> wrote:

I just tried to update my www/sogo2 jail and I now have ports breakage.

The first thing that happened is that "portmaster -Rad" failed on ftp/curl with 
the following message:

"""
===>  Cleaning for curl-7.49.1
You have a /usr/local/lib/libcrypto.so file installed, but the framework is 
unable
to determine what port it comes from.
Add DEFAULT_VERSIONS+=ssl= to your /etc/make.conf and try 
again.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/ftp/curl
*** Error code 1

Stop.
make: stopped in /usr/ports/ftp/curl

===>>> make build failed for ftp/curl
===>>> Aborting update

===>>> Update for curl-7.48.0_2 failed
===>>> Aborting update
"""

It seems that ftp/curl can't build with openssl or libressl installed from 
ports. And www/nginx will only build with openssl or libresll installed from 
ports. So basically nginx and curl can't co-exist on the same host/jail.

My port options are almost all the defaults, and I don't want to set anything in 
/etc/make.conf, but even if I do set DEFAULT_VERSIONS+=ssl=ssl I can't get 
curl to build.

I've been updating this jail regulary for a while now without any issue. This 
reminds me hair-pulling in the past with the Kerberos fork issues (MIT vs 
Heimdal). And I was finding ports management so easy these days, until today.

Why can't curl just use openssl from base, despite the port version being 
installed?



# uname -a
FreeBSD sogo.potensol.com 10.1-RELEASE-p16 FreeBSD 10.1-RELEASE-p16 #0: Tue Jul 
28 12:04:19 UTC 2015 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64









--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: curl and nginx no longer build on same host

[Jim Ohlstein]

Hello,

> On Jul 15, 2016, at 10:03 PM, Euan Thoms  wrote:
> 
> Bump
> 
> Can anyone else install or update ftp/curl after installing nginx?

Yes, but I'm building packages using poudriere, not using portmaster. 

> 
> The only way I'm able to update now is to uninstall openssl and nginx, then 
> update curl, then reinstall nginx (which pulls in openssl). This was not 
> required on several previous update cycles.

If memory serves me correctly, nginx and curl both require openssl from ports 
only if certain options are chosen (http2 being one), or at least that was the 
case in the past.

You may have option(s) selected for one that requires the version from ports, 
and one that does not.

Have you tried to force usage of openssl from ports in your /etc/make.conf?

> 
> 
>> On Thursday, July 14, 2016 23:30 SGT, "Euan Thoms"  
>> wrote: 
>> 
>> I just tried to update my www/sogo2 jail and I now have ports breakage.
>> 
>> The first thing that happened is that "portmaster -Rad" failed on ftp/curl 
>> with the following message:
>> 
>> """
>> ===>  Cleaning for curl-7.49.1
>> You have a /usr/local/lib/libcrypto.so file installed, but the framework is 
>> unable
>> to determine what port it comes from.
>> Add DEFAULT_VERSIONS+=ssl= to your /etc/make.conf and 
>> try again.
>> *** Error code 1
>> 
>> Stop.
>> make[1]: stopped in /usr/ports/ftp/curl
>> *** Error code 1
>> 
>> Stop.
>> make: stopped in /usr/ports/ftp/curl
>> 
>> ===>>> make build failed for ftp/curl
>> ===>>> Aborting update
>> 
>> ===>>> Update for curl-7.48.0_2 failed
>> ===>>> Aborting update
>> """
>> 
>> It seems that ftp/curl can't build with openssl or libressl installed from 
>> ports. And www/nginx will only build with openssl or libresll installed from 
>> ports. So basically nginx and curl can't co-exist on the same host/jail.
>> 
>> My port options are almost all the defaults, and I don't want to set 
>> anything in /etc/make.conf, but even if I do set 
>> DEFAULT_VERSIONS+=ssl=ssl I can't get curl to build.
>> 
>> I've been updating this jail regulary for a while now without any issue. 
>> This reminds me hair-pulling in the past with the Kerberos fork issues (MIT 
>> vs Heimdal). And I was finding ports management so easy these days, until 
>> today.
>> 
>> Why can't curl just use openssl from base, despite the port version being 
>> installed?
>> 
>> 
>> 
>> # uname -a
>> FreeBSD sogo.potensol.com 10.1-RELEASE-p16 FreeBSD 10.1-RELEASE-p16 #0: Tue 
>> Jul 28 12:04:19 UTC 2015 
>> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

--
Jim
___
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: iozone3-434 fails to rebuild

[Jim Ohlstein]

Hello,

> On Jun 21, 2016, at 4:14 PM, Alphons van Werven  wrote:
> 
> Doug Sampson wrote:
> 
>> it crashes as follows:
>> 
>>  ###
>> <...snip...>
>> iozone.c:1297:1: error: unknown type name 'off64_t'; did you mean 'off_t'?
>> off64_t offset = 0;   /*offset for random I/O */
>> ^~~
>> off_t
>> /usr/include/sys/types.h:173:18: note: 'off_t' declared here
>> typedef __off_t off_t;  /* file offset */
>>^
> [snip]
>> Doesn't matter which config options I select/deselect,
> 
> As far as I can tell it doesn't *crash*, it merely fails to build ;-)
> 
> I don't think the options are relevant in this case. If I'm not mistaken
> off64_t is some kind of GNU extension, but installing lang/gcc and trying
> to compile a piece of sample code with GCC still didn't work for me. Which
> means I can reproduce the problem on 10.2-RELEASE-p19/amd64.
> 
> There seems to be a #define or typedef missing somewhere. Perhaps somebody
> can ask around upstream what the authors are expecting from the off64_t
> type, so we can find a suitable replacement on FreeBSD systems: probably
> offset_t, (u)int64_t, or something along those lines.

How about it be reverted to the previous, WORKING, version in the meantime, and 
before an "upgrade" is committed, proper testing is done?

Just sayin'

--
Jim
___
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: iozone3-434 fails to rebuild

[Jim Ohlstein]

+1

> On Jun 21, 2016, at 3:07 PM, Kimmo Paasiala  wrote:
> 
>> On Tue, Jun 21, 2016 at 9:32 PM, Doug Sampson  wrote:
>> Trying to rebuild iozone after a recent port upgrade and it crashes as 
>> follows:
>> 
>>  ###
>> <...snip...>
>> iozone.c:1297:1: error: unknown type name 'off64_t'; did you mean 'off_t'?
>> off64_t offset = 0;   /*offset for random I/O */
>> ^~~
>> off_t
>> /usr/include/sys/types.h:173:18: note: 'off_t' declared here
>> typedef __off_t off_t;  /* file offset */
>>^
>> iozone.c:1298:1: error: unknown type name 'off64_t'; did you mean 'off_t'?
>> off64_t offset64 = 0;   /*offset for random I/O */
>> ^~~
>> off_t
>> /usr/include/sys/types.h:173:18: note: 'off_t' declared here
>> typedef __off_t off_t;  /* file offset */
>>^
>> iozone.c:1299:1: error: unknown type name 'off64_t'; did you mean 'off_t'?
>> off64_t filebytes64;
>> ^~~
>> off_t
>> /usr/include/sys/types.h:173:18: note: 'off_t' declared here
>> typedef __off_t off_t;  /* file offset */
>>^
>> fatal error: too many errors emitted, stopping now [-ferror-limit=]
>> 2 warnings and 20 errors generated.
>> *** Error code 1
>> 
>> Stop.
>> make[2]: stopped in /usr/ports/benchmarks/iozone/work/iozone3_434/src/current
>> *** Error code 1
>> 
>> Stop.
>> make[1]: stopped in /usr/ports/benchmarks/iozone
>> *** Error code 1
>> 
>> Stop.
>> make: stopped in /usr/ports/benchmarks/iozone
>> root@pisces:/usr/ports/benchmarks/iozone#
>>   ###
>> 
>> root@pisces:/usr/ports/benchmarks/iozone# make showconfig
>> ===> The following configuration options are available for iozone-3.434:
>> SSH=on: Use ssh in distributed measurement
>> THREADS=on: Enable threading (uses pthreads)
>> ===> Use 'make config' to modify these settings
>> root@pisces:/usr/ports/benchmarks/iozone#
>> 
>> Doesn't matter which config options I select/deselect, it still fails to 
>> rebuild. It occurs on both 10.3-RELEASE-p4 i386 and 10.3-RELEASE-p4 amd64 
>> systems.
>> 
>> 
>> ~Doug
>> ___
> 
> Same here on 10.3-RELEASE. I wonder how the port got updated with
> sponsorship from "Gandi.net", yet the committed changes were
> apparently not tested? Shouldn't Gandi.net volunteer as the maintainer
> for the port if they want it to be updated (the port is unmaintained
> at the moment)?
> 
> -Kimmo
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Zimbra Port

[Jim Ohlstein]

Sorry for the top post. 

We use Zimbra on an Ubuntu LTS VM with storage via iSCSI. 

Given the magnitude, I honestly don't think ports or packages is really the way 
to go. I believe that most people use a dedicated (to Zimbra) server or VM. 

If I were to approach this project, I'd do it outside of ports, maybe on 
github, or possibly as a VM image. 

That's not to say it can't be done, rather that a project of this size requires 
a layout that is not native to FreeBSD ports, and it's so massive with so many 
moving parts, having to comply with the ports infrastructure, and to maintain 
it, is probably far more effort than it's worth. 

Jim Ohlstein
> On Jun 1, 2016, at 9:47 AM, rs <rs+freebsd-po...@trust64.com> wrote:
> 
> Hello List,
> 
> I am trying to create a port of the zimbra collaboration suite. I am in 
> contact with upstream and they are actively helping in making a port happen.
> 
> It would be my first FreeBSD port (although I have a lot of linux knowledge 
> and know how to create packages for .deb).
> 
> My first steps involve right now making everything compile (Zimbra includes 
> *a lot* of libraries themselves instead of relying on the OS to provide them).
> 
> I have a couple of questions though:
> 
> * Zimbra expects itself to be installed to /opt/zimbra. It is not easy to 
> change that, /opt/zimbra is hardcoded in a lot of places. Its a longterm goal 
> of mine to help clean that up, but it is not possible right now. Are there 
> any problems with a package which installs to /opt?
> 
> * The Zimbra source is huge, a git clone is about 13 GigaBytes. I am not sure 
> on how source that big is handled correctly in ports. (e.g. is it OK that 
> every make does a git clone and you have to wait until you get the 13 GB of 
> data? Would this be a problem for the FreeBSD build cluster infrastructure to 
> create the packages?, ...)
> 
> * On the porters handbook it says to fetch a tarball from http/ftp, is it 
> also possible to directly work with git and clone a repository?
> 
> This is the right place to get help started in porting? FreeBSD has so much 
> mailing lists :-)
> 
> Thank you,
> Best
> RAy
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

PHP Download site

[Jim Ohlstein]

Hello,

I'm upgrading lang/php56 this morning using poudriere and we're still in 
the "fetch" phase after almost ten minutes. Looking at the log, it is 
fetching from http://de.php.net/. I've noticed this same slowness before 
as well with php70 being downloaded from Germany.


Is there a reason for this default, especially where it is so slow?

--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Mailman in a jail

[Jim Ohlstein]

Hello

On 4/22/16 7:20 AM, Kristof Provost wrote:



On 22 Apr 2016, at 13:11, Jim Ohlstein <j...@ohlste.in
<mailto:j...@ohlste.in>> wrote:

The main gotcha with Mailman is that it defaults to supporting Sendmail.
It actually needs to be rebuilt to work with postfix. That's the first
thing to look at. Did you install from ports or with pkg?


I built it with poudriere using the Postfix option.


Okay, that’s good. I did exactly the same ;)

It’s not quite clear to me if your problem is getting Postfix to deliver
to mailman, or mailman to postfix.

In my setup the list is on a separate (virtual) domain, and uses an
aliases file
(alias_maps = hash:/etc/aliases, hash:/usr/local/mailman/data/aliases).
That file is maintained by mailman and will have things like 'test:
 "|/usr/local/mailman/mail/mailman post test”’ in it.

Return delivery (i.e. mailman sending mail) is done using the DirectSMTP
module. My ‘SMTPHOST’ is set to the hostname of the jail (so to an IP
address the postfix is listening on). If you’ve still got that set to
the default of ‘localhost’ that might also explain your problems.
It might also be worth playing with telnet inside the jail and
confirming that you can talk to your postfix that way.



That was the problem. I more or less figured it out late last night when 
I looked at the mail logs of the front end server. My setup is like this:


web <--> fontend SSL termination/load balancer/cache <--> multiple 
backends (not web accessible)


Mailman is installed in in a jail in a backend server. That jail has a 
FQDN and it matches that of Mailman (lists.mydomain.com).


So in ~mailman/Mailman/mm_cfg.py I had:

SMTPHOST = 'lists.mydomain.com'

as instructed by the port upon installation.

That wound up having Mailman looking for the _real_ IP of that FQDN for 
the outgoing mail server, which led it back to the frontend server to 
which that IP is actually bound. That Postfix installation refused to 
relay because the IP range of that backend server was not allowed in 
"mynetworks" in its main.cf.


Allowing that IP range on Postfix on the frontend server got outgoing 
mail working late last night. It was a fairly inelegant solution but it 
worked. Editing ~mailman/Mailman/mm_cfg.py as follows got it working in 
the jail:


- SMTPHOST = 'lists.mydomain.com'
+ SMTPHOST = 'jail.ip.address'

What confused me were the port's instructions and the fact that the 
Mailman actually resolved the FQDN and looked for that IP externally.


Thanks to everyone who helped. I'm a bit embarrassed at the simplicity 
of the solution.


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Mailman in a jail

[Jim Ohlstein]

Hello,

> On Apr 22, 2016, at 6:05 AM, Kristof Provost <k...@freebsd.org> wrote:
> 
>> On 2016-04-21 11:21:36 (-0400), Jim Ohlstein <j...@ohlste.in> wrote:
>> I'm trying to get Mailman working in a 10.3 amd64 jail. Everything 
>> works, except Mailman doesn't talk to Postfix. Incoming mail works and 
>> posts to the list's archives but no outgoing email is sent. I asked in 
>> the Mailman list and they seem to think it's related to running in a jail.
>> 
>> If anyone's gotten this running in a jail I'd appreciate some input. I'm 
>> not married to Postfix - willing to use a different MTA.
> I'm currently running a Postfix + Mailman instance on 10.3. It does
> indeed work.
> 
> The main gotcha with Mailman is that it defaults to supporting Sendmail.
> It actually needs to be rebuilt to work with postfix. That's the first
> thing to look at. Did you install from ports or with pkg?

I built it with poudriere using the Postfix option. 

Jim
___
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: Mailman in a jail

[Jim Ohlstein]

Hello,

On 4/21/16 12:18 PM, David Wolfskill wrote:

On Thu, Apr 21, 2016 at 11:21:36AM -0400, Jim Ohlstein wrote:

Hello,

I'm trying to get Mailman working in a 10.3 amd64 jail. Everything
works, except Mailman doesn't talk to Postfix. Incoming mail works and
posts to the list's archives but no outgoing email is sent. I asked in
the Mailman list and they seem to think it's related to running in a jail.

If anyone's gotten this running in a jail I'd appreciate some input. I'm
not married to Postfix - willing to use a different MTA.



FWIW, mailman.freebsd.org is implemented this way: it's a jail; both
"mailman" and "postfix" show processes running under the (respective)
IDs:



I see pretty similar results:



d...@mailman.ysv:~ % ps lU mailman
UID   PID  PPID CPU PRI NIVSZ   RSS MWCHAN STAT TT  TIME COMMAND
  91 46905 1   0  20  0 105044 16632 wait   IsJ   -   0:00.04 /usr/local/bin
  91 46906 46905   0  20  0 147696 57836 select SJ-  19:55.33 /usr/local/bin
  91 46907 46905   0  20  0 143856 54844 select SJ-  20:39.62 /usr/local/bin
  91 46908 46905   0  20  0 146928 57828 select SJ-  20:11.64 /usr/local/bin
  91 46909 46905   0  20  0 144112 55084 select SJ-  20:05.08 /usr/local/bin
  91 46910 46905   0  20  0 165972 77940 select SJ-   8:59.94 /usr/local/bin
  91 46911 46905   0  20  0 167252 78760 select SJ-   9:00.74 /usr/local/bin
  91 46912 46905   0  20  0 160340 73732 select SJ-   9:01.35 /usr/local/bin
  91 46913 46905   0  20  0 165204 78460 select SJ-   9:01.00 /usr/local/bin
  91 46914 46905   0  20  0 142564 45556 select SJ-   1:13.76 /usr/local/bin
  91 46915 46905   0  20  0 138324 42776 select SJ-   1:13.19 /usr/local/bin
  91 46916 46905   0  20  0 141396 44808 select SJ-   1:13.59 /usr/local/bin
  91 46917 46905   0  20  0 140260 44956 select SJ-   1:13.38 /usr/local/bin
  91 46918 46905   0  20  0 202736 89700 select SJ-   6:49.71 /usr/local/bin
  91 46919 46905   0  20  0 174576 80544 select SJ-   6:46.04 /usr/local/bin
  91 46920 46905   0  20  0 188400 83560 select SJ-   6:46.32 /usr/local/bin
  91 46921 46905   0  20  0 185328 93104 select SJ-   6:49.27 /usr/local/bin
  91 46922 46905   0  20  0 172784 83460 select SJ-  34:33.65 /usr/local/bin
  91 46923 46905   0  20  0 168688 79560 -  RJ-  34:26.42 /usr/local/bin
  91 46924 46905   0  20  0 168432 79400 select SJ-  34:13.51 /usr/local/bin
  91 46925 46905   0  20  0 167920 77424 select SJ-  34:37.86 /usr/local/bin
  91 46926 46905   0  20  0 175700 84972 select SJ-  17:22.13 /usr/local/bin
  91 46927 46905   0  20  0 153940 66180 select SJ-  17:20.90 /usr/local/bin
  91 46928 46905   0  20  0 171860 79896 select SJ-  17:21.52 /usr/local/bin
  91 46929 46905   0  20  0 174420 86528 select SJ-  17:24.39 /usr/local/bin
  91 46930 46905   0  20  0 104788 16256 select IJ-   0:00.61 /usr/local/bin
  91   346   345   0  52  0  19596  3040 ttyin  I+J   6   0:00.30 -su (tcsh)
  91   339   338   0  24  0  19596  2900 pause  IJ7   0:10.41 -su (tcsh)
  91 55304   339   0  24  0   6228  1532 nanslp I+J   7   0:00.00 sleep 300
  91   358   357   0  36  0  19596  3040 pause  IJ8   0:04.29 -su (tcsh)
  91 55516   358   0  36  0   6228  1532 nanslp I+J   8   0:00.00 sleep 300


# ps lU mailman
UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND
91 70066 1 0 52 0 108860 16712 wait IsJ - 0:00.01 
/usr/local/bin/python2.7 /usr/local/mailman/bin/mailmanctl -s -q start
91 70067 70066 0 20 0 108872 16604 select SJ - 0:00.19 
/usr/local/bin/python2.7 /usr/local/mailman/bin/qrunner 
--runner=ArchRunner:0:1 -s
91 70068 70066 0 20 0 108860 16672 select SJ - 0:00.20 
/usr/local/bin/python2.7 /usr/local/mailman/bin/qrunner 
--runner=BounceRunner:0:1 -s
91 70069 70066 0 20 0 108860 16640 select SJ - 0:00.20 
/usr/local/bin/python2.7 /usr/local/mailman/bin/qrunner 
--runner=CommandRunner:0:1 -s
91 70070 70066 0 20 0 108872 16616 select SJ - 0:00.20 
/usr/local/bin/python2.7 /usr/local/mailman/bin/qrunner 
--runner=IncomingRunner:0:1 -s
91 70071 70066 0 20 0 108872 16728 select SJ - 0:00.21 
/usr/local/bin/python2.7 /usr/local/mailman/bin/qrunner 
--runner=NewsRunner:0:1 -s
91 70072 70066 0 20 0 109384 17272 select SJ - 0:00.32 
/usr/local/bin/python2.7 /usr/local/mailman/bin/qrunner 
--runner=OutgoingRunner:0:1 -s
91 70073 70066 0 20 0 108860 16728 select SJ - 0:00.21 
/usr/local/bin/python2.7 /usr/local/mailman/bin/qrunner 
--runner=VirginRunner:0:1 -s
91 70074 70066 0 52 0 109116 17036 select IJ - 0:00.21 
/usr/local/bin/python2.7 /usr/local/mailman/bin/qrunner 
--runner=RetryRunner:0:1 -s





d...@mailman.ysv:~ % sysctl security.jail.jailed
security.jail.jailed: 1


# sysctl security.jail.jailed
security.jail.jailed: 1


d...@mailman.ysv:~ % id postfix
uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail)


# id postfix
uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail)


d...@m

Re: Mailman in a jail

[Jim Ohlstein]

Hello,

On 4/21/16 1:31 PM, Alphons van Werven wrote:

Jim Ohlstein wrote:


Mailman logs show connection errors.


I don't know exactly how Postfix and Mailman (try to) communicate with one
another, but is it possible that SysV IPC has to be enabled for the jail?
Or maybe raw sockets, although that's probably less likely.


Enabling each did not change the problem. I still see multiple lines 
like this in Mailman's logs:


Apr 21 14:06:45 2016 (70072) Low level smtp error: [Errno 61] Connection 
refused, msgid: <mailman.0.1461262003.70138.c2-l...@lists.my.domain>
Apr 21 14:06:45 2016 (70072) delivery to em...@doman.com failed with 
code -1: [Errno 61] Connection refused


and nothing in /var/log/maillog

--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Mailman in a jail

[Jim Ohlstein]

Hello,

> On Apr 21, 2016, at 11:41 AM, Jan Bramkamp <cr...@rlwinm.de> wrote:
> 
>> On 21/04/16 17:21, Jim Ohlstein wrote:
>> Hello,
>> 
>> I'm trying to get Mailman working in a 10.3 amd64 jail. Everything
>> works, except Mailman doesn't talk to Postfix. Incoming mail works and
>> posts to the list's archives but no outgoing email is sent. I asked in
>> the Mailman list and they seem to think it's related to running in a jail.
>> 
>> If anyone's gotten this running in a jail I'd appreciate some input. I'm
>> not married to Postfix - willing to use a different MTA.
> 
> - Did you enable Postfix in the mailer.conf?

Yes

> - Are Postfix and mailman in the same jail?

Yes

Jim
___
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: Mailman in a jail

[Jim Ohlstein]

Hello,

> On Apr 21, 2016, at 11:55 AM, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> Jim Ohlstein wrote on 04/21/2016 17:21:
>> Hello,
>> 
>> I'm trying to get Mailman working in a 10.3 amd64 jail. Everything
>> works, except Mailman doesn't talk to Postfix. Incoming mail works and
>> posts to the list's archives but no outgoing email is sent. I asked in
>> the Mailman list and they seem to think it's related to running in a jail.
> 
> Can you send messages from this jail throught Postfix?
> 
> Does this work:
> 
> echo "jail test" | mail -s "Postfix in jail" your-addr...@example.com

Yes

> 
> Check it in /var/log/maillog and in you own mailbox.
> 
> Does Mailman or Postfix logs some errors in log files?

No. Postfix logs correctly but logs no attempts from Mailman. Mailman logs show 
connection errors. 

Jim
___
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: Mailman in a jail

[Jim Ohlstein]

Hello,

> On Apr 21, 2016, at 11:39 AM, Matthew Seaman <matt...@freebsd.org> wrote:
> 
>> On 04/21/16 16:21, Jim Ohlstein wrote:
>> I'm trying to get Mailman working in a 10.3 amd64 jail. Everything
>> works, except Mailman doesn't talk to Postfix. Incoming mail works and
>> posts to the list's archives but no outgoing email is sent. I asked in
>> the Mailman list and they seem to think it's related to running in a jail.
>> 
>> If anyone's gotten this running in a jail I'd appreciate some input. I'm
>> not married to Postfix - willing to use a different MTA.
> 
> Does mailman try and communicate with postfix over a network socket
> bound to the loopback address?

Not sure. I've never used it before but I've been tasked with converting a flat 
list of 5000+ email addresses into a mailing list. What I know is the 
connection fails and it's not even logged in /var/log/maillog. I've confirmed 
that Postfix can send from the command line (using the "mail" command) and 
receive, and it logs correctly. I assume the attempt isn't reaching Postfix or 
it'd be logged. 

> 
> That's a common gotcha in jails.  There isn't an accessible loopback
> address in a jail[*], but the kernel intercepts connection attempts and
> redirects things via the jail's primary address.  So an application that
> tries to bind to 127.0.0.1 ends up binding to 192.0.2.1 or whatever the
> jail address is.  Most of the time you'll get away with this.  However
> some more security aware applications (like postfix) realise something
> dodgy is going on and refuse to play.
> 
> The answer is basically to configure mailman to talk to postfix by the
> jail's IP explicitly.

Tried that. No joy. The setup is a bit more complex, however. It's a front end 
server which mainly serves as an SSL termination point, cache, and reverse 
proxy to multiple backend servers which are not web accessible. I'm using PF to 
forward SMTP connections directly to the jail IP which is on em0 on this 
particular backend server. I may bite the bullet and try it out outside a jail, 
but would rather not. 

> 
> [*] Unless you're using VIMAGE jails, but that's a topic for another day...
> 

Indeed. Not sure I'm willing to invest time getting that working at the 
compensation I'm getting which is exactly zero. It's for a non-profit at which 
I volunteer my time and know how. 

Thanks,

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

Mailman in a jail

[Jim Ohlstein]

Hello,

I'm trying to get Mailman working in a 10.3 amd64 jail. Everything 
works, except Mailman doesn't talk to Postfix. Incoming mail works and 
posts to the list's archives but no outgoing email is sent. I asked in 
the Mailman list and they seem to think it's related to running in a jail.


If anyone's gotten this running in a jail I'd appreciate some input. I'm 
not married to Postfix - willing to use a different MTA.


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: www/nginx-devel build failure after libbrotli update

[Jim Ohlstein]

Hello,

On 4/16/16 7:48 PM, Sergey A. Osokin wrote:

Hi Jim,

On Sat, Apr 16, 2016 at 06:02:19PM -0400, Jim Ohlstein wrote:

On 4/16/16 4:02 PM, Sergey A. Osokin wrote:


could you show the content of the nginx-devel-1.9.14_1/objs/autoconf.err file,
it looks like we have bad release of the devel/libbrotli...

Thanks in advance.


http://bit.ly/1SdU1Ai


Here is the issue:


checking for Brotli library

/usr/local/lib/libbrotlienc.so: undefined reference to 
`brotli::BrotliCompressFragmentTwoPass(unsigned char const*, unsigned long, 
bool, unsigned int*, unsigned char*, int*, unsigned long, unsigned long*, 
unsigned char*)'
/usr/local/lib/libbrotlienc.so: undefined reference to 
`brotli::BrotliCompressFragmentFast(unsigned char const*, unsigned long, bool, 
int*, unsigned long, unsigned char*, unsigned short*, unsigned long*, unsigned 
char*, unsigned long*, unsigned char*)'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
-

I've just committed a fix for devel/libbrotli, please update the ports tree and
recompile devel/libbrotli.

Thanks for report!



This is fixed. Thanks, Sergey!

--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: www/nginx-devel build failure after libbrotli update

[Jim Ohlstein]

Hello,

On 4/16/16 4:02 PM, Sergey A. Osokin wrote:

Hi Jim,

could you show the content of the nginx-devel-1.9.14_1/objs/autoconf.err file,
it looks like we have bad release of the devel/libbrotli...

Thanks in advance.



http://bit.ly/1SdU1Ai

--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

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

www/nginx-devel build failure after libbrotli update

[Jim Ohlstein]

Hello,

I have done this twice and gotten the same error on 10.3-STABLE using 
poudriere:


[snip]

===>   nginx-devel-1.9.14_1 depends on shared library: libpcre.so - 
found (/usr/local/lib/libpcre.so)

===>   Returning to build of nginx-devel-1.9.14_1
===>   nginx-devel-1.9.14_1 depends on shared library: libbrotlidec.so - 
not found

===>   Installing existing package /packages/All/libbrotli-1.0_1.txz
[pkg.jlkhosting.com] Installing libbrotli-1.0_1...
[pkg.jlkhosting.com] Extracting libbrotli-1.0_1: .. done
===>   nginx-devel-1.9.14_1 depends on shared library: libbrotlidec.so - 
found (/usr/local/lib/libbrotlidec.so)

===>   Returning to build of nginx-devel-1.9.14_1
===>   nginx-devel-1.9.14_1 depends on shared library: libbrotlienc.so - 
found (/usr/local/lib/libbrotlienc.so)

===
===

[snip]

configuring additional modules
adding module in /wrkdirs/usr/ports/www/nginx-devel/work/ngx_cache_purge-2.3
 + ngx_http_cache_purge_module was configured
adding module in 
/wrkdirs/usr/ports/www/nginx-devel/work/ngx-fancyindex-0.3.6
 - The 'addition' filter is needed for fancyindex_{header,footer}, but 
it was disabled

 + ngx_http_fancyindex_module was configured
adding module in 
/wrkdirs/usr/ports/www/nginx-devel/work/ngx_devel_kit-0.2.19

 + ngx_devel_kit was configured
adding module in 
/wrkdirs/usr/ports/www/nginx-devel/work/redis2-nginx-module-0.12

 + ngx_http_redis2_module was configured
adding module in 
/wrkdirs/usr/ports/www/nginx-devel/work/srcache-nginx-module-0.30

 + ngx_http_srcache_filter_module was configured
configuring additional dynamic modules
adding module in /wrkdirs/usr/ports/www/nginx-devel/work/nginx-ct-f3cad5e
 + ngx_ssl_ct_module was configured
adding module in 
/wrkdirs/usr/ports/www/nginx-devel/work/echo-nginx-module-4f7aa50

 + ngx_http_echo_module was configured
adding module in 
/wrkdirs/usr/ports/www/nginx-devel/work/headers-more-nginx-module-f5559ec

 + ngx_http_headers_more_filter_module was configured
adding module in 
/wrkdirs/usr/ports/www/nginx-devel/work/ngx_http_redis-0.3.8

 + ngx_http_redis_module was configured
adding module in 
/wrkdirs/usr/ports/www/nginx-devel/work/set-misc-nginx-module-6582fb4

found ngx_devel_kit for ngx_set_misc; looks good.
 + ngx_http_set_misc_module was configured
adding module in /wrkdirs/usr/ports/www/nginx-devel/work/ngx_brotli-2fc6f12
checking for Brotli library ... not found
checking for Brotli library in /usr/local/ ... not found
checking for Brotli library in /usr/pkg/ ... not found
checking for Brotli library in /opt/local/ ... not found
./configure: error: ngx_brotli filter module requires Brotli library.
===>  Script "configure" failed unexpectedly.

--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Creating port for sentora

[Jim Ohlstein]

Hello,

On 4/9/16 5:21 AM, Carmel wrote:

I have been investigating Sentora <http://sentora.org/>, I was wondering
if anyone is working on creating a port for this application?

The install script is 1200+ lines, written in bash that first looks for 
the two supported Linux distros and installs their packages from the 
respective repositories. It chokes on any other OS and even chokes on 
unsupported Linux distros.


Without looking at the scripts that actually perform the hosting 
functions, I would wager they look for config files in places where 
FreeBSD packages do not install them. That's only the beginning of what 
I'd imagine to be a horror show of ugly hacks that would be necessary.


If you manage to get it working after a complete rewrite of the install 
script (from scratch) and the support files, pretty much each update is 
going to require another such rewrite, or at least extensive patching.


Bottom line: you have four choices: wait for someone to spend dozens 
(maybe hundreds) of hours porting it to FreeBSD and committing to 
maintaining it, do it yourself, use a supported software distribution, 
or find another hosting control panel that supports FreeBSD out of the box.


You can always lobby the developers to support FreeBSD, which they 
_might_ do if they were properly incentivized.


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Committer needed for PR 208029

[Jim Ohlstein]

Hello,

On 4/6/16 12:39 PM, Mathieu Arnold wrote:

+--On 6 avril 2016 12:00:47 -0400 Jim Ohlstein <j...@ohlste.in> wrote:
| Hello,
|
|> On Apr 6, 2016, at 11:37 AM, Mathieu Arnold <m...@freebsd.org> wrote:
|>
|> +--On 6 avril 2016 10:06:41 -0400 Jim Ohlstein <j...@ohlste.in> wrote:
|> | Hello,
|> |
|> | On 4/6/16 12:44 AM, Kurt Jaeger wrote:
|> |> Hi!
|> |>
|> |>> Actually, I just noticed (when compiling the port), that the Makefile
|> |>> now says:
|> |>>
|> |>> WITH_OPENSSL_PORT=yes
|> |>
|> |> Yes, sorry, my fault. Fixed, and as suggested by mat: It is
|> |> now as IGNORE with a message explaining how to do it for 9.x.
|> |>
|> |
|> | This is much ado about nothing. The "WITH_OPENSSL_PORT" option is there
|> | for just this purpose and is used in many ports.
|>
|> No, the WITH_OPENSSL_PORT knob is a global one, and must not be used in
|> ports makefiles.  The fact is, there are ports using it, true, it does
|> not mean it is the right thing to do.
|>
|
| Then there are many ports being committed incorrectly, as well as, no
| doubt, many *official* packages.
|
| I really have no dog in this fight. I use it globally and build all of my
| own packages with poudriere, but either it shouldn't be there at all, or
| it should be ok to use. Having it available as an option to porters and
| then saying it shouldn't be used seems a bit silly.

Well, it is not available for the porters as it is a global directive, they
use it anyway.

Anyway, like I said, working on it.



Maybe an edit to portlint is in order. That way they might know. As of 
now, portlint does not so much as emit a warning.


I don't entirely disagree with the premise that all ports that require 
OpenSSL should be built against the version in ports. As I said, I do it 
and it also makes port maintenance simpler. However, as long as it is 
actually an option, as it is now, then it should be availed when desired.


Further down the road (but not all that far) I foresee other, perhaps 
bigger problems if using this strategy. OpenSSL 1.1.0 is in beta and 
will be released within the next month or two. It is not completely 
backward compatible. At some point it will become the official ports 
version and/or two versions will need to be maintained in ports, 1.0.2 
(LTS until 2019) and 1.1.x. This will create the problem of some/many 
ports not building against 1.1.x and some ports or port options 
_requiring_ 1.1.x. Assuming 1.1.x is the main OpenSSL in ports, there 
will be ports that would build properly against OpenSSL in base (but 
cannot be built that way if using the ports version is mandated), and do 
not compile against OpenSSL 1.1.x. Most can no doubt be patched, but 
waiting for upstream providers to do so may be problematic, and many 
porters lack the skills.


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Committer needed for PR 208029

[Jim Ohlstein]

Hello,

> On Apr 6, 2016, at 11:37 AM, Mathieu Arnold <m...@freebsd.org> wrote:
> 
> +--On 6 avril 2016 10:06:41 -0400 Jim Ohlstein <j...@ohlste.in> wrote:
> | Hello,
> | 
> | On 4/6/16 12:44 AM, Kurt Jaeger wrote:
> |> Hi!
> |> 
> |>> Actually, I just noticed (when compiling the port), that the Makefile
> |>> now says:
> |>> 
> |>> WITH_OPENSSL_PORT=yes
> |> 
> |> Yes, sorry, my fault. Fixed, and as suggested by mat: It is
> |> now as IGNORE with a message explaining how to do it for 9.x.
> |> 
> | 
> | This is much ado about nothing. The "WITH_OPENSSL_PORT" option is there
> | for just this purpose and is used in many ports.
> 
> No, the WITH_OPENSSL_PORT knob is a global one, and must not be used in
> ports makefiles.  The fact is, there are ports using it, true, it does not
> mean it is the right thing to do.
> 

Then there are many ports being committed incorrectly, as well as, no doubt, 
many *official* packages. 

I really have no dog in this fight. I use it globally and build all of my own 
packages with poudriere, but either it shouldn't be there at all, or it should 
be ok to use. Having it available as an option to porters and then saying it 
shouldn't be used seems a bit silly. 

> There is work going on to always use OpenSSL from ports, but it also needs
> to take into account GSSAPI, and it's a mess.

--
Jim
___
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: Committer needed for PR 208029

[Jim Ohlstein]

Hello,

> On Apr 6, 2016, at 10:47 AM, Kurt Jaeger  wrote:
> 
> Hi!
> 
>> This is much ado about nothing. The "WITH_OPENSSL_PORT" option is there 
>> for just this purpose and is used in many ports.
> 
> In 9.x this is sometimes a problem, if port X builds in variant 1
> and port Y depends/links on X, but builds in variant 2. So it's
> a temporary solution for 9.x and will be solved when 9.x is EOL'ed.
> 
> I'm not sure how this is solved in 10.x/11.x, probably the base SSL
> is much more up2date.
> 
>> Forcing users who want to use this port to use OpenSSL from ports for 
>> ALL ports is overkill.
> 
>> Think about official packages. Are ALL packages built against OpenSSL 
>> from ports, or only those that need them? It's the latter, of course. 
>> Are they incompatible in production? No.
> 
> There are grey areas, and I guess it will be like that for 9.x.

Not only 9.x. 10.x has OpenSSL 1.0.1. Some ports require 1.0.2 which is in 
ports. Openssl 1.1.0 is soon to be released but almost certainly won't be in 
11. It's likely to always be an issue. It's up to each individual maintainer to 
make certain his or her ports behave correctly if binaries link to one another. 
For a port like this the proper solution is to use the least intrusive option. 

--
Jim
___
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: Committer needed for PR 208029

[Jim Ohlstein]

Hello,

On 4/6/16 12:44 AM, Kurt Jaeger wrote:

Hi!


Actually, I just noticed (when compiling the port), that the Makefile now says:

WITH_OPENSSL_PORT=yes


Yes, sorry, my fault. Fixed, and as suggested by mat: It is
now as IGNORE with a message explaining how to do it for 9.x.



This is much ado about nothing. The "WITH_OPENSSL_PORT" option is there 
for just this purpose and is used in many ports. There's no reason some 
binaries can't be linked to one version of OpenSSL and others to 
another, so long as they aren't expected to work as one (I'd imagine a 
dynamically loaded module that is linked to a different library might 
cause a problem). That is the reason that ports contains a more current 
version than base. This is from the ports/www directory:


#  grep WITH_OPENSSL_PORT */Makefile
aws/Makefile:WITH_OPENSSL_PORT= yes
drood/Makefile:WITH_OPENSSL_PORT=   yes
h2o/Makefile:WITH_OPENSSL_PORT= no
h2o/Makefile:WITH_OPENSSL_PORT= yes
mod_tsa/Makefile:WITH_OPENSSL_PORT= yes
nginx-devel/Makefile:WITH_OPENSSL_PORT= yes
nginx-devel/Makefile:WITH_OPENSSL_PORT= yes
nginx/Makefile:WITH_OPENSSL_PORT=   yes
nginx/Makefile:WITH_OPENSSL_PORT=   yes
obhttpd/Makefile:WITH_OPENSSL_PORT=yes
owncloud/Makefile:WITH_OPENSSL_PORT=yes
spdylay/Makefile:.if ${OSVERSION} < 100 && !defined(WITH_OPENSSL_PORT)
tengine/Makefile:WITH_OPENSSL_PORT= yes
tomcat-native/Makefile:WITH_OPENSSL_PORT=   yes

I'm sure there are dozens of others.

Forcing users who want to use this port to use OpenSSL from ports for 
ALL ports is overkill.


Think about official packages. Are ALL packages built against OpenSSL 
from ports, or only those that need them? It's the latter, of course. 
Are they incompatible in production? No.


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: print/cups overhaul (PR 207746) side-effects

[Jim Ohlstein]

Hello,

> On Mar 15, 2016, at 2:44 PM, Torfinn Ingolfsen  wrote:
> 
> On Sat, Mar 12, 2016 at 4:51 PM, Walter Schwarzenfeld
>  wrote:
>> Where is the problem? There is only one "big" port (llvm36). Will be
>> sstimate 1 !/2 hours. Poudriere and more synth often wants more.
> 
> And how many hours will it take to compile the llvm port on a Raspberry Pi?
> Or any of the other ARM platforms that FreeBSD now supports.

It was just under two hours for LLVM-36 and clang 36 on an old Xeon. 

--
Jim
___
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: Owncloud port marked broken with PHP 7.0 and MySQL

[Jim Ohlstein]

Hello,

On 3/15/16 7:54 AM, Kurt Jaeger wrote:

Hi!


At the risk of sounding like a broken record (did you actually READ what
I wrote?) Owncloud does NOT require php-mysql, it requires
php-pdo_mysql. In PHP versions before 7.0 that pulled in the
corresponding php-mysql port. It is NOT a requirement (there, I said it
a THIRD time).


Can you submit a patch to the ports (maybe fixing the depends) so that
it builds ?



It's pretty straightforward. I'm guessing other ports were pulled in by 
this blanket search for requiring mysql extension when in fact what was 
needed was pdo-mysql.


--- Makefile(revision 411153)
+++ Makefile(working copy)
@@ -2,6 +2,7 @@

 PORTNAME=  owncloud
 PORTVERSION=   9.0.0
+PORTREVISION=  1
 CATEGORIES=www
 MASTER_SITES=  http://download.owncloud.org/community/

@@ -40,8 +41,7 @@
 LDAP_USE=  PHP=ldap
 MP3INFO_BUILD_DEPENDS= mp3info:${PORTSDIR}/audio/mp3info
 MP3INFO_RUN_DEPENDS=   ${MP3INFO_BUILD_DEPENDS}
-MYSQL_USE= MYSQL=client PHP=mysql,pdo_mysql
-MYSQL_VARS=IGNORE_WITH_PHP+=70
+MYSQL_USE= MYSQL=client PHP=pdo_mysql
 PGSQL_USES=pgsql
 PGSQL_USE= PHP=pdo_pgsql,pgsql
 SQLITE_USE=PHP=pdo_sqlite,sqlite3


Build log available at http://bit.ly/1UdfsGA.

--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Owncloud port marked broken with PHP 7.0 and MySQL

[Jim Ohlstein]

Hello,

On 3/15/16 7:05 AM, Mathieu Arnold wrote:



+--On 14 mars 2016 16:57:19 -0400 Jim Ohlstein <j...@ohlste.in> wrote:
| Hello,
|
| Not sure of the motivation behind this. Owncloud has supported PHP 7.0
| since prior to this release (9.0.0). See
| https://owncloud.org/blog/php-7-is-here-and-owncloud-is-ready/. Perhaps
| removing the unnecessary php(Xx)-mysql runtime requirement is what's
| actually needed, as it actually requires php(Xx)-pdo-mysql. That in
| itself creates a php-mysql dependency in PHP versions up to 5.6, but not
| in later versions, such as 7.0.

The owncloud port needs mysql, php 7.0 does not provide mysql, so it was
marked broken, along with all the ports that do so, and who also don't
build with 7.0.



At the risk of sounding like a broken record (did you actually READ what 
I wrote?) Owncloud does NOT require php-mysql, it requires 
php-pdo_mysql. In PHP versions before 7.0 that pulled in the 
corresponding php-mysql port. It is NOT a requirement (there, I said it 
a THIRD time).


From their docs at 
https://doc.owncloud.org/server/9.0/admin_manual/installation/source_installation.html


Database connectors (pick the one for your database:)

PHP module sqlite (>= 3, usually not recommended for performance reasons)
PHP module pdo_mysql (MySQL/MariaDB)
PHP module pgsql (requires PostgreSQL >= 9.0)

Now I may just be dumb, but I don't see a mention of php-mysql (I do 
however see pdo_mysql).


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

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

Owncloud port marked broken with PHP 7.0 and MySQL

[Jim Ohlstein]

Hello,

Not sure of the motivation behind this. Owncloud has supported PHP 7.0 
since prior to this release (9.0.0). See 
https://owncloud.org/blog/php-7-is-here-and-owncloud-is-ready/. Perhaps 
removing the unnecessary php(Xx)-mysql runtime requirement is what's 
actually needed, as it actually requires php(Xx)-pdo-mysql. That in 
itself creates a php-mysql dependency in PHP versions up to 5.6, but not 
in later versions, such as 7.0.


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: print/cups overhaul (PR 207746) side-effects

[Jim Ohlstein]

Hello,



Jim Ohlstein
> On Mar 11, 2016, at 2:52 PM, Martin Waschbüsch <mar...@waschbuesch.de> wrote:
> 
> Hi all,
> 
> I just did a rebuild of packages for my webservers with poudriere.
> What I noticed was that via the print/cups overhaul (see PR 207746),
> quite a lot (>50) of additional dependencies are added to the system, 
> including
> lots of x11 related libs, avahi, dbus, cairo, opengl, etc.
> 
> This stems from installing pecl-imagick which results in pulling in 
> ImageMagick,
> ghostscript, and cups.
> 
> Now, of course I can manually remove port options and reduce the number
> of additional dependencies, but I feel uneasy about the defaults now.
> 
> If I wanted to adjust an existing port to be less greedy with regards to 
> dependencies,
> how would I go about that? Create a slave port?
> 
> Thoughts, anyone?
> 

+1

All of a sudden my build box spent almost two hours compiling LLVM-36 and 
clang36 and then choked on Cairo "is marked as broken: OpenGL option needs X11 
support". This was after it compiled all this X11 crap that my servers don't 
need. Ironically, I need to refactor options because now I can't build 
ImageMagick-noX11. 

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

security/py-cryptography build failure with OpenSSL 1.0.2g

[Jim Ohlstein]

Hello,

Build failure since update of OpenSSL to 1.0.2g. FreeBSD 10.3-BETA2 
amd64, Poudriere version 3.1.12.


Build log at http://bit.ly/1UyofSH

Thanks,

--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: PHP7 issue [was PHP7 + Synth issue]

[Jim Ohlstein]

Hello,

On 2/17/16 8:59 AM, John Marino wrote:

On 2/17/2016 2:44 PM, Martin Wilke wrote:

Hi,

The long term solution will be switching to mysqli or pdo_mysql which is
provided by php70 (and php55/56), I am working right now on cleaning up
the pecl ports, after that I'll go and check which port can switch already.


php56-pdo_mysql has php56-mysql as a dependency.

# pkg info -d php56-pdo_mysql
php56-pdo_mysql-5.6.18:
php56-5.6.18
php56-mysql-5.6.18
php56-pdo-5.6.18

This is not the case with php70-pdo_mysql.

I have come across at least one port where you see the following in the 
Makefile:


MYSQL_USE=  MYSQL=client PHP=mysql,pdo_mysql

where:

MYSQL_USE=  MYSQL=client PHP=pdo_mysql

would suffice for PHP 5.6 and would not break PHP 7.0, assuming the 
correct extension is phpXx-pdo_mysql.






The problem with that approach is that his tree is broken now.
His choice is don't build at all or don't use php 7.0.

I think it's something that needs attention now unless the intent is to
say, "don't use php7 yet, it is not ready for prime time" (which is
possible)


This is clearly not a Synth issue. Synth did its job correctly.

PHP 7.0 is early and anyone who uses it in production uses it at their 
own peril. It's not the default PHP version, people have to actually 
opt-in to build PHP-based ports with it. As such, they need to have 
their eyes wide open.


Sorting this all out will take awhile with over 100 pecl extensions 
alone and many more than that ports dependent on PHP. The only way to 
figure it out is to leave it in ports so people can test it against 
their apps. Again, anyone who uses it in production without testing is 
asking for trouble.


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Recent update breaks php70-extensions

[Jim Ohlstein]

Hello,

On 2/16/16 10:41 AM, Martin Wilke wrote:

Hi,

Can you please checkout the portstree again. It should be fixed in _3.

Thanks.



Resolved. Thanks!


On Tue, Feb 16, 2016 at 9:35 PM, Jim Ohlstein <j...@ohlste.in
<mailto:j...@ohlste.in>> wrote:

Hello,

On 2/16/16 7:51 AM, Martin Wilke wrote:

hi,

please update your portstree i have fixed the problem around 30
mins ago.

thanks


That took care of that. There is another issue. When building the
mysql extensions (I build both php70-mysqli and php70-pdo_mysql) a
dependency on mysql-client is created for all extensions built
through that. So using poudriere I see:

[00:00:05] >> Checking packages for incremental rebuild needed
[00:00:07] >> Deleting owncloud-8.2.2.txz: missing dependency:
mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-bz2-7.0.3_2.txz: missing
dependency: mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-bcmath-7.0.3_2.txz: missing
dependency: mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-curl-7.0.3_2.txz: missing
dependency: mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-ctype-7.0.3_2.txz: missing
dependency: mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-calendar-7.0.3_2.txz: missing
dependency: mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-dom-7.0.3_2.txz: missing
dependency: mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-exif-7.0.3_2.txz: missing
dependency: mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-fileinfo-7.0.3_2.txz: missing
dependency: mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-extensions-1.1.txz: missing
dependency: php70-bz2-7.0.3_2
[00:00:07] >> Deleting php70-filter-7.0.3_2.txz: missing
dependency: mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-ftp-7.0.3_2.txz: missing
dependency: mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-gd-7.0.3_2.txz: missing dependency:
mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-iconv-7.0.3_2.txz: missing
dependency: mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-hash-7.0.3_2.txz: missing
dependency: mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-imap-7.0.3_2.txz: missing
dependency: mariadb101-client-10.1.11

    etc.

I don't recall that behavior from php56-extensions metaportw.



On Feb 16, 2016 20:32, "Jim Ohlstein" <j...@ohlste.in
<mailto:j...@ohlste.in>
<mailto:j...@ohlste.in <mailto:j...@ohlste.in>>> wrote:

 Hello,

 A recent commit has resulted in at least two extensions not
 building: php70-imap and php70-openssl. Same ultimate error
is seen
 in both:


 test: no: unexpected operator
 test: /usr/local: unexpected operator
 checking for pkg-config... no
 configure: error: Cannot find OpenSSL's 
 ===>  Script "configure" failed unexpectedly.


 The missing file is present in the poudriere jail:

   # locate evp.h | grep jail
 /poudriere/jails/10amd64/usr/include/openssl/evp.h


/poudriere/jails/10amd64/usr/src/crypto/heimdal/doc/doxyout/hcrypto/html/group__hcrypto__evp.html


/poudriere/jails/10amd64/usr/src/crypto/heimdal/doc/doxyout/hcrypto/html/page_evp.html

/poudriere/jails/10amd64/usr/src/crypto/openssl/crypto/evp/evp.h
 /poudriere/jails/10amd64/usr/src/sys/boot/efi/include/efidevp.h

 but not in the jail's /usr/local/include/openssl/ sub-directory
 where it should be since I have 'WITH_OPENSSL_PORT=yes' in the
 make.conf for that build. I have confirmed that OpenSSL port is
 present in that repo.

 Both extensions built properly previously. Not sure if it's the
 latest commit or the initial one as I had previously built
these
 extensions from the pre-commit versions obtained from
miwi@'s git repo.


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Recent update breaks php70-extensions

[Jim Ohlstein]

Hello,

On 2/16/16 7:51 AM, Martin Wilke wrote:

hi,

please update your portstree i have fixed the problem around 30 mins ago.

thanks


That took care of that. There is another issue. When building the mysql 
extensions (I build both php70-mysqli and php70-pdo_mysql) a dependency 
on mysql-client is created for all extensions built through that. So 
using poudriere I see:


[00:00:05] >> Checking packages for incremental rebuild needed
[00:00:07] >> Deleting owncloud-8.2.2.txz: missing dependency: 
mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-bz2-7.0.3_2.txz: missing dependency: 
mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-bcmath-7.0.3_2.txz: missing dependency: 
mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-curl-7.0.3_2.txz: missing dependency: 
mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-ctype-7.0.3_2.txz: missing dependency: 
mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-calendar-7.0.3_2.txz: missing 
dependency: mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-dom-7.0.3_2.txz: missing dependency: 
mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-exif-7.0.3_2.txz: missing dependency: 
mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-fileinfo-7.0.3_2.txz: missing 
dependency: mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-extensions-1.1.txz: missing dependency: 
php70-bz2-7.0.3_2
[00:00:07] >> Deleting php70-filter-7.0.3_2.txz: missing dependency: 
mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-ftp-7.0.3_2.txz: missing dependency: 
mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-gd-7.0.3_2.txz: missing dependency: 
mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-iconv-7.0.3_2.txz: missing dependency: 
mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-hash-7.0.3_2.txz: missing dependency: 
mariadb101-client-10.1.11
[00:00:07] >> Deleting php70-imap-7.0.3_2.txz: missing dependency: 
mariadb101-client-10.1.11


etc.

I don't recall that behavior from php56-extensions metaportw.




On Feb 16, 2016 20:32, "Jim Ohlstein" <j...@ohlste.in
<mailto:j...@ohlste.in>> wrote:

Hello,

A recent commit has resulted in at least two extensions not
building: php70-imap and php70-openssl. Same ultimate error is seen
in both:


test: no: unexpected operator
test: /usr/local: unexpected operator
checking for pkg-config... no
configure: error: Cannot find OpenSSL's 
===>  Script "configure" failed unexpectedly.


The missing file is present in the poudriere jail:

  # locate evp.h | grep jail
/poudriere/jails/10amd64/usr/include/openssl/evp.h

/poudriere/jails/10amd64/usr/src/crypto/heimdal/doc/doxyout/hcrypto/html/group__hcrypto__evp.html

/poudriere/jails/10amd64/usr/src/crypto/heimdal/doc/doxyout/hcrypto/html/page_evp.html
/poudriere/jails/10amd64/usr/src/crypto/openssl/crypto/evp/evp.h
/poudriere/jails/10amd64/usr/src/sys/boot/efi/include/efidevp.h

but not in the jail's /usr/local/include/openssl/ sub-directory
where it should be since I have 'WITH_OPENSSL_PORT=yes' in the
make.conf for that build. I have confirmed that OpenSSL port is
present in that repo.

Both extensions built properly previously. Not sure if it's the
latest commit or the initial one as I had previously built these
extensions from the pre-commit versions obtained from miwi@'s git repo.



--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

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

Recent update breaks php70-extensions

[Jim Ohlstein]

Hello,

A recent commit has resulted in at least two extensions not building: 
php70-imap and php70-openssl. Same ultimate error is seen in both:



test: no: unexpected operator
test: /usr/local: unexpected operator
checking for pkg-config... no
configure: error: Cannot find OpenSSL's 
===>  Script "configure" failed unexpectedly.


The missing file is present in the poudriere jail:

 # locate evp.h | grep jail
/poudriere/jails/10amd64/usr/include/openssl/evp.h
/poudriere/jails/10amd64/usr/src/crypto/heimdal/doc/doxyout/hcrypto/html/group__hcrypto__evp.html
/poudriere/jails/10amd64/usr/src/crypto/heimdal/doc/doxyout/hcrypto/html/page_evp.html
/poudriere/jails/10amd64/usr/src/crypto/openssl/crypto/evp/evp.h
/poudriere/jails/10amd64/usr/src/sys/boot/efi/include/efidevp.h

but not in the jail's /usr/local/include/openssl/ sub-directory where it 
should be since I have 'WITH_OPENSSL_PORT=yes' in the make.conf for that 
build. I have confirmed that OpenSSL port is present in that repo.


Both extensions built properly previously. Not sure if it's the latest 
commit or the initial one as I had previously built these extensions 
from the pre-commit versions obtained from miwi@'s git repo.


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Removing documentation

[Jim Ohlstein]

Hello,

On 2/15/16 3:40 PM, Michelle Sullivan wrote:

John Marino wrote:

On 2/15/2016 6:32 PM, Roger Marquis wrote:


This makes no sense.  Ports are not tied to base releases.
And you think lack of developer resources is an invalid reason?


There was no mid-release issue with base as far as I know.  The issue was
with ports and by extension pkgng (and related -ngs).



ports are developed independently.  They do not follow release
schedules.  Ports have to support all supported releases, that's the
only connection.


Yeah, I'd agree with this... except...

pkg_* tools don't exist on 10.x only pkgng...  that makes it base os
thing.. even if it's downloaded in/via ports..

So sorry don't claim it's only part of the ports system, because whilst
it maybe built and administered there, the tools it replaced were
removed from the base OS at the very beginning of 10.x...


This is like milking a dead cow here. Even if you get something out of 
it you're not going to drink it.


If you want to be using a 2014 OS in 2022, then a RHEL derived system is 
the product for you. Enjoy it. I don't believe that there is an upgrade 
path in RHEL, so you'll either have to retire hardware or nuke your 
systems to upgrade.


No one forced you to use 10.x before you were ready. 9 is still 
supported to this day. And as has been pointed out, pkg_ tools were in 
ports should you have wanted to continue to use them, and you could have 
kept them and frozen your ports tree, as has been pointed out.


Could the pkg(8) roll out have been handled better? Yes! Hey, I'm not 
happy about Bush v Gore in 2000 but I'm not still crying about it. 
You're frustrated, angry, bitter, whatever. I'm terribly sorry but it's 
ime to move on.


Red Hat, which is now your preferred product, is a for-profit company 
with over 8000 paid employees, many of whom are testing and testing and 
testing. They never update anything except at the point of a gun, and 
then only after extensive testing. On the plus side, it's stable. It 
never really changes. FreeBSD, on the other hand, is a comparatively 
small organization and an operating system that moves forward, though 
sometimes it's two steps forward and one back.. Some things need to be 
tested in the field to find out where and what needs to be 
changed/fixed/improved. That's the way it is. Was this an epic fail? 
That's a matter of opinion, though we all already know yours. The fact 
is that you had choices. You made those choices with your eyes open (if 
you didn't then shame on you!) and things didn't go as smoothly as you'd 
have liked. As I said, it's time to move on. Your arguments are specious.



--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Removing documentation

[Jim Ohlstein]

ccasional risk that it 
will crap out when upgrading a dependency, still works well for solitary 
systems using only ports. My point is that the main tool is there. It's 
pkg(8). It does a _reasonably_ good job of sussing out what's necessary, 
installing only run dependencies, and avoiding "dependency hell". For 
people who use only official packages I'd daresay it's superior to 
apt-get. Can it be improved? Yes. I have a wishlist in fact. However, 
it's a young tool that really is excellent, especially compared to what 
was (not) present previously. What tools, if any, a user chooses to 
employ around pkg is up to that user. On Debian and Ubuntu I need both 
apt-* tools and aptitude. On FreeBSD I currently use poudriere. Others 
only need pkg itself.


In my use case, I compile everything myself because I like to customize 
options and there also may be a slight control issue there as well. ;) I 
use poudriere and maintain different repos for different options. Just 
the other day I spun up a new one for the yet to committed PHP 7.0 
ports. It took a couple of minutes to do, though compiling some of the 
modules was an effort - separate issue. I created a jail, added that 
repo, installed php70, and was ready to test. To do that on Debian would 
probably have been a lot more effort, though I imagine someone has a 
repo out there with packages, if I wanted to use someone else's 
packages...






Synth is a binary.  There's no POLA there.


If there were no ports system, and everything was package-driven, I'd
agree.  Synth and its cousins exist because people work from ports --
which means that dependencies matter.


There's no requirement to build from ports, that's an unsubstanciated
invention.  Notice that not a single person could defend that position
after a challenge.  There's no technical basis for it; it's just emotional.


The laissez-faire "there's no requirement to build from ports" that
permeates FreeBSD is exactly what's wrong.  The fact that half of the
documentation and quasi-official tools tell people "hey, use one of
these three ports management tools, or maybe packages, pick what works
for you -- oh, and be sure to check /usr/ports/UPDATING every time you
touch any port or package" is a deep symptom of this fragmentation.


In a straight fly-off against any of the tools, Synth wins hands down
with any objective measurement.  Poudriere is slightly more bulletproof
and more appropriate for a cluster (as it was targetted at) but for
average user Synth is better suited.

It's a concurrent builder.  Ada is a concurrent language.  How is its
suitability even a debate?


Because FreeBSD software management itself is not purely package based.

As long as the ports system exists (and I think it should!), the
management of compilation requirements -- especially for something
that might need to be bootstrapped early, like a software management
tool -- is a valid topic.

To be clear: except for the Ada/ruby/whatever dependency chain, my
beef isn't with Synth qua Synth.  It's that every time we spin up Yet
Another Optional Software Management Tool, we fragment further.  If
Synth becomes the holy grail of package management -- so compelling
that it becomes the only choice people would want to make, which is
what I think we need -- then it should become part of base.

If that happened, would we want to ship with Ada in base?  If not, why not?



This is a good point. I still don't understand why pkg(8) is not in the 
base (though I imagine there's a reason and it takes less than a minute 
to install). There can't be many users who install a base system and use 
it without a single additional piece of software. However, for my $0.02, 
that is the only change I'd make to base at this point with respect to 
package management, aside from my pkg(8) wishlist. As an aside, and 
fwiw, unless there is a non-GPL'd Ada compiler out there, we won't see 
Ada or any Ada-based binaries in base, even if Synth turns out to be the 
best thing since sliced bread.


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: ports/pkg/OS integration 2.0 (was: Re: Removing documentation)

[Jim Ohlstein]

Hello,

On 2/12/16 11:25 AM, Royce Williams wrote:

On Fri, Feb 12, 2016 at 6:38 AM, Royce Williams <ro...@tycho.org> wrote:

This is, indeed, a gap in the Debian world.  It's one that the ports
system is a great start towards resolving.  That's why I think that
ports + pkg could be a superior offering that people would flock to,
and which deserves more focus.


To be fair, this is also why my comparison FreeBSD's ports system to
some other OSes binary package system is an unfair comparison.  :)
The complexity of letting people pick their own compilation options is
significant, and one that the Linux/Debian/dpkg world largely
sidesteps.

But it's exactly where I think that FreeBSD could really shine.
FreeBSD's ports system is the best system I've seen for managing
custom compilation.  If the OS, binary packages, and ports were more
tightly integrated, it would be magic.

Some goals:

* The OS needs a structured way to know that a different package has
changed its default behavior in some way.  (The Ubuntu
/etc/alternatives symlink system and other mechanisms solve this
well). In other words, a common framework that could accommodate
things like deciding to use a port or package instead of the facility
provided by the OS.


This is true. That probably would not be impossible to implement. It 
would be nice to be able to have two or more versions of a tool 
installed and relatively seamlessly switchable, at least for testing. 
I'm thinking PHP, Apache, nginx, etc.


/usr/local/bin/php5  and /usrlocal/bin/php7 with one at any time 
symlinked to /usr/local/bin/php or /usr/local/alternatives/php or whatever.




* Port maintainers should be able to express how one-offs and
conflicts should be resolved in a machine-readable way. (In other
words, as a test of fitness to purpose, most historic entries in
/usr/ports/UPDATING should be programmatically expressible in the
system).


Yes!



* The ports system needs to know which compilation options were used
by packages in the pkg system, so that if a conflict arises, it can be
intelligently expressed by the maintainers (or the user can be told
that they are mutually exclusive).


I believe at this time all official packages are compiled with the 
particular port's default options. That is until "flavors" are 
implemented at some point in the future.




* if the user's port configuration options aren't different from the
package defaults, ask the user if they want to use the package instead
(with global and per-port knobs to stop asking if the user desires).


Another big YES!



In other words, the end goal should be that the OS, ports, and
packages can coexist for common use cases.



--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: PHP7 package?

[Jim Ohlstein]

Hello,

On 2/11/16 11:20 AM, Kurt Jaeger wrote:

Hi!


That's fewer than I'd have thought, but there are also ports like
php56-redis which don't show up as "pecl" though they are in the PECL
repo.


Then we have to add them manually to the 'ports-to-test' list.


I'd say that in order to be rigorous, all php*- and pecl- ports need to
be tested (at least) for compilation against php70 in in a clean system,
and it's a good opportunity to update all with current versions. I'm
happy to help. Feel free to contact me off list.


Three tests then: build-test, run-test, use-test



I've run some initial tests on PHP 7.0 and 10-STABLE in jails. The good 
news is I have definitely seen quantifiable page load time improvements 
in a small (~150 blogs of varying activity) WordPress Multisite 
installation using nginx and php-fpm that I tested using both Pingdom's 
page load test and curl's "time_starttransfer" result from nearby and 
remote IP's. This is evident even with the use of a Redis object cache 
via predis. The bad news is there seems to be a bug in php-fpm. When 
started at jail startup it results in the following:


last pid: 61693;  load averages:  4.69,  2.11,  1.07 

up 
13+14:07:02  20:50:42

16 processes:  6 running, 10 sleeping
CPU 0: 37.8% user,  0.0% nice, 61.4% system,  0.8% interrupt,  0.0% idle
CPU 1: 41.7% user,  0.0% nice, 58.3% system,  0.0% interrupt,  0.0% idle
CPU 2: 29.9% user,  0.0% nice, 70.1% system,  0.0% interrupt,  0.0% idle
CPU 3: 42.5% user,  0.0% nice, 57.5% system,  0.0% interrupt,  0.0% idle
Mem: 327M Active, 1531M Inact, 13G Wired, 27M Cache, 236M Buf, 963M Free
ARC: 10G Total, 4367M MFU, 3956M MRU, 691K Anon, 131M Header, 1824M Other
Swap: 8192M Total, 8192M Free

  PID USERNAME   THR PRI NICE   SIZERES STATE   C   TIME 
WCPU COMMAND
61600 www  1  960   155M 25160K RUN 2   1:41  84.47% 
php-fpm: pool www (php-fpm)
61587 www  1  960   155M 25160K CPU11   1:38  81.88% 
php-fpm: pool www (php-fpm)
61588 www  1  960   155M 25160K CPU33   1:41  77.49% 
php-fpm: pool www (php-fpm)
61536 www  1  960   155M 25160K CPU22   1:44  77.29% 
php-fpm: pool www (php-fpm)
61535 www  1  960   155M 25160K RUN 0   1:40  76.76% 
php-fpm: pool www (php-fpm)


This is fixed by restarting php-fpm. Otherwise these processes will spin 
out of control happily consuming 60-90% of each CPU indefinitely. For 
now my somewhat less than elegant workaround has been to restart php-fpm 
using a cron and a five second sleep after boot. It never recurs, at 
least not after 24 hours. I haven't had a chance to look into this 
further but am curious if anyone else has noticed it. Note that these 
children are spawned inappropriately as there are no requests coming 
into this particular jail and pm.start_servers is set to the default of 
2 with the default pm.max_children = 5. After restart there are just the 
2 children behaving as expected.


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: PHP7 package?

[Jim Ohlstein]

Hello,

On 2/7/16 8:32 AM, Kurt Jaeger wrote:

Hi!


This post suggests that a php7 port should be coming soon


https://docs.freebsd.org/cgi/getmsg.cgi?fetch=86492+0+archive/2016/freebsd-ports/20160117.freebsd-ports

but there is stil no port or package available for php7


You can check out the repo and build them yourself, it works, see it at

https://a1.opsec.eu/test.php



I cloned the ports, created a (separate) poudriere ports collection and 
added them to that. No problem building the php70 port or most of the 
modules that I use in php70-extensions. The pdflib module is a PECL 
module that hasn't been updated to PHP 7.0 and chokes. So do some other 
PECL extensions. In fact, I'd guess there are hundreds of PECL modules 
in the ports tree that either have not been updated to PHP 7.0 upstream 
or have not been updated in the ports tree if they have been updated 
upstream. I found examples of both (pecl-APCu has been updated upstream 
but not in ports, pecl-memcache has not been updated upstream) in 
modules I use regularly. Some modules are hosted on Github and are 
branched for PHP 7.x but are not at the "release" stage and have to be 
edited with a Github "tag" (phpXx-redis being a case in point - it 
builds against php70 if it is modified to use GH tag "0d4b421", and a 
similar situation with pecl-igbinary which has to be completely reworked 
as the update is not available in PECL, only on GH). Of course I haven't 
tested most of them in any meaningful way so the fact that they compile 
does not indicate that I believe they work as intended.


This may in fact be a larger sticking point in adoption of PHP 7.x than 
backward code incompatibility, though that's a subject for another day 
on another mailing list.


Thank you miwi@ et al for the work. Clearly much remains to be done.

--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: PHP7 package?

[Jim Ohlstein]

Hello,

On 2/11/16 10:12 AM, Kurt Jaeger wrote:

Hi!


In fact, I'd guess there are hundreds of PECL modules
in the ports tree that either have not been updated to PHP 7.0 upstream
or have not been updated in the ports tree if they have been updated
upstream.


List of PECL modules:

portfind pecl | wc -l
  137

Maybe put the list in the wiki, and start some upgrade orgy ?

Sounds 'somewhat' doable.



That's fewer than I'd have thought, but there are also ports like 
php56-redis which don't show up as "pecl" though they are in the PECL 
repo. The current port uses a GH source. See 
https://pecl.php.net/package/redis and 
https://svnweb.freebsd.org/ports/head/databases/php56-redis/Makefile?revision=403460=markup 
for an example. In fact, that GH source is also outdated and results in 
a redirect.


root@rubicon:~ # curl -I https://github.com/nicolasff/phpredis
HTTP/1.1 301 Moved Permanently
Server: GitHub.com
Date: Thu, 11 Feb 2016 15:28:34 GMT
Content-Type: text/html; charset=utf-8
Status: 301 Moved Permanently
Cache-Control: no-cache
Vary: X-PJAX
Location: https://github.com/phpredis/phpredis

I'd say that in order to be rigorous, all php*- and pecl- ports need to 
be tested (at least) for compilation against php70 in in a clean system, 
and it's a good opportunity to update all with current versions. I'm 
happy to help. Feel free to contact me off list.


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Removing documentation

[Jim Ohlstein]

On 2/9/16 9:08 AM, John Marino wrote:

On 2/9/2016 2:46 PM, Jim Ohlstein wrote:

After all of this "discussion" I decided to give synth a try. I have no
pony in this race as I use neither portmaster nor portupgrade. Both may
still be in my repo, but they are not installed.


Thanks for trying it!



The build time of "like 20-30 minutes, at most" is ummm... let' just
call it optimistic. I only needed five new dependencies. Poudriere was
unable to take advantage of more than two parallel builders except for a
rather short overlap where it used three, if I recall correctly. The
vast majority of the time it used only one builder. Build and package
time for gcc6-aux was 34:52 on an Intel E5-2650 v3. Build and package
time for binutils, required for gcc6-aux, took 4:44. That's pretty close


hmmm, my core i5 builds it in 10-12 minutes and I've had it ~4 years?
I'm not sure why such a big descreptancy, but newer machines with 4-8Gb
or more ram should have no issues with time.


Interesting. I just tested again and got 31:47. To be fair, I only allow 
that VM four cores. Perhaps it might do better with more?





to 40 minutes for just two dependencies, one of which is a dependency of
the other. Build and package time for synth was 1:09.

I installed synth and had a look at the man page. Nice job on the
documentation though I might suggest more real world examples, in an
"Examples" section at the end, would be helpful to people like me who
want to understand how to get started. Sort of like a "quick start
guide" that comes with a new electronic component. Get it going and then
read the details on what's really important for the specific use case.
That shouldn't be construed as a knock on the documentation, which
really is very good.


Do you think the illustrated README on the github page is helpful?

https://github.com/jrmarino/synth



Yes, I do indeed. Thanks.




This was last night and I haven't tried building with it yet. I need to
re-read the documentation. I do however have concerns, the biggest of
which is, yes, the dependencies. I use poudriere because I like to build
packages myself for my installations and with my options, so using the
FreeBSD repo version of synth will be a non-starter. That means that
I'll need to rebuild gcc6-aux every time I need to rebuild synth,
assuming gcc6-aux has been updated. It's a fair guess that gcc6-aux is
regularly updated (the current version is dated 20160124). It's also a


After gcc6 hits release (6.1), it will probably only be released with
every point release (6.2, 6.3), which are separated by months.


fair guess that synth will go through a few iterations in the short term
given its youth. Looking at my recent build logs, the longest builds I


It's feature complete and v1.00 is coming out in a few days (same as
0.99_6 with a version bump).  v1.1 will come soon after when I improve
on the build-repository command to not scan the entire tree.  It's
already been through the iterations, so I don't there will be that many
more.  In any case, it's a small problem (and when gcc6-aux is released,
it won't build the bundled libraries anymore but use other ports so it
will be much, much faster to compile.



run are far shorter than 35 minutes. This will slow things down and I'm
not certain I'm going to be willing to keep a package in my repo that
requires that amount of build time just as a dependency I otherwise
would never build. To be honest, synth, which I will try, will have to
be _far_ superior to poudriere in order to replace it as my tool of
choice. Of course that's my use case and mine only.


To be fair, poudriere users aren't the target audience.  Yes, it's
significantly faster than poudriere and maybe people like the interface
better, but if they are already set up on poudriere and happy with it,
that's a fine choice too.

It's more for people that aren't using poudriere, really should be, but
are intimidated by it.



--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Removing documentation

[Jim Ohlstein]

at the
same time, I just wanted that expanded on.  I don't know if you still
think it's unreasonable, but I do appreciate that you took the time to
respond.

P.S.  If FreeBSD 11 didn't regress with ncurses (PR 199109) then
probably we could provide synth with NO runtime dependencies.  But there
doesn't seem to be any interest in fixing the regression unfortunately.



--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: Who was the mental genius

[Jim Ohlstein]

Hello,

On 6/6/14, 2:24 PM, Alfred Perlstein wrote:



On Jun 6, 2014, at 10:02 AM, Warren Block wbl...@wonkity.com wrote:


On Fri, 6 Jun 2014, Paul Schmehl wrote:

No offense was meant.  I deliberately chose the subject to stimulate 
discussion, which it has obviously done.


Stimulating discussion without insulting people generally gives better results.

Look, we are all doing the best we can with what we've got.  The ports people 
have been trying to accomplish the equivalent of turning a cruise ship around 
in a bathtub without rattling the silverware.  It's not possible to anticipate 
every issue, particularly when there are so many.

The way improvements are made is for interested people (that is, you) to
get involved and help to improve it.

The challenge you have created is to anticipate the next issue and report it, 
preferably with a plan for a solution, before it happens.



Let's not overly tone police folks. If no one can constructively criticize then 
we don't get any feedback.

Anyone's tone can be attacked I firmly believe that Paul's tone matches the way 
we east coasters chide each other to provoke debate.


Not to get too far off topic but as a life long east coaster (except for 
a short sojourn in the flatlands of Kansas), and being old enough to 
know better, that is not normal east coast chiding. Maybe that's 
normal northeast talk, but here in the south people have manners.


Having said that, this is what I infer from the situation. With all due 
respect Paul, you have said you are 18 months from retirement. Most 
folks are kinda coasting by that point. I'm guessing that's why you were 
running your servers on a no longer supported version of FreeBSD. 
Unfortunately, no longer supported *really* meant no longer 
supported in this case, and you got bit, and got angry. Sadly, you have 
no one to blame but yourself, since this was in fact well documented.


If I was not a polite southerner, perhaps I'd ask who was the mental 
genius that expected to run an unsupported OS for the next 18 months? 
But I'm too polite to ask.


--
Jim Ohlstein


Never argue with a fool, onlookers may not be able to tell the 
difference. - Mark Twain

___
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: pkg 2 ng conversion

[Jim Ohlstein]

Hello,

On 5/28/14, 2:13 PM, Jim Pazarena wrote:

I have several servers, some 9.1, 9.2, 10.0
all nagging about the deprecated package system.
So I've bitten the bullet and am converting to the new pkg system.
The notes for conversion indicate you must add WITH_PKGNG=yes to
make.conf. Also done.

On a new/fresh install, V10, should a person immediately place
WITH_PKGNG=yes in the make.conf ? And then is it not required
to run pkg2ng ? Or is it implied? It seems not, but I cannot find
documentation in this respect.


In my experience it is unnecessary to add WITH_PKGNG=yes in a fresh 
FreeBSD 10 box, and it is certainly not necessary to run pkg2ng since 
there are no installed packages.


The pkg_* tools are not included in FreeBSD 10 and the pkg(ng) system is 
the default.


--
Jim Ohlstein


Never argue with a fool, onlookers may not be able to tell the 
difference. - Mark Twain

___
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: lang/php5: Update doesn't install libphp5.so anymore, www/apache24 fails to start

[Jim Ohlstein]

Hello,

On 4/4/14, 1:28 PM, O. Hartmann wrote:

After updating ports today and a lot of the php-stuff, I get this error 
restarting
apache24:

  httpd: Syntax error on line 162 of /usr/local/etc/apache24/httpd.conf: Cannot
load libexec/apache24/libphp5.so into server: Cannot open
/usr/local/libexec/apache24/libphp5.so

I tried to rebuild apache24 as well as lang/php5 with first rmconfig and then 
config
again avoiding missing something. No effect.

What happened here? /usr/ports/UPDATING doesn't have any kind of information 
regarding
this subject.




From UPDATING:

20140327:
  AFFECTS: users of lang/php5 and lang/php55 with Apache module
  AUTHOR: a...@freebsd.org

  The Apache PHP module has been separated from the main PHP port.
  If it is needed, install either www/mod_php5 or www/mod_php55.


--
Jim Ohlstein


Never argue with a fool, onlookers may not be able to tell the 
difference. - Mark Twain

___
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: Has NO_MANCOMPRESS been silently depreciated?

[Jim Ohlstein]

On 2/6/14, 9:36 AM, N.J. Mann wrote:

In message 52f39326.2040...@marino.st,
John Marino (freebsd.cont...@marino.st) wrote:

On 2/6/2014 14:31, N.J. Mann wrote:

You are asking for an infrastructure
change.


No I am not.  I _am_ asking that something which used to be supported
(and was documented), that has silently been removed, be reinstated.



The two are not mutually exclusive. So actually, yes you _are_.

If you want it back that badly, write the necessary patches and submit them.

--
Jim Ohlstein


Never argue with a fool, onlookers may not be able to tell the 
difference. - Mark Twain

___
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: What is the problem with ports PR reaction delays?

[Jim Ohlstein]

On 1/28/14, 10:04 AM, Daniel Siechniewicz wrote:

Hi,

Just a little stick in this anthill:

- I've seen a few people volunteering, but so far the reaction seems
to be: oh, yeah, well, ah, cool. I'd expect, with all the talk about
how much they are needed, that they will be snatched immediately and
coerced into doing unspeakable things (like processing a 100 PRs a
day, ensuring high quality testing and all that :) ). I certainly hope
this is happening behind the scenes.


Not.


--
Jim Ohlstein


Never argue with a fool, onlookers may not be able to tell the 
difference. - Mark Twain

___
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: What is the problem with ports PR reaction delays?

[Jim Ohlstein]

Hello,

On 1/25/14, 9:04 PM, Alfred Perlstein wrote:

On 1/25/14 3:48 PM, Aryeh Friedman wrote:

On Sat, Jan 25, 2014 at 6:41 PM, Yuri y...@rawbw.com wrote:


On 01/25/2014 14:44, Aryeh Friedman wrote:


The key seems to be that no one has time to do the stuff they really
want
to do (get new ports into the system)... to that end automating
everything
that can be automated is sure help free up comitter time so they can
look
at what is interesting


Yes. I just can't imagine any generic port tests that can't be automated
and coded into the script once and for good.
Ideal system should be like github with the added automated testing
between pull request submission and merge. It should either fail and
notify
the submitter, or succeed and notify the committers.


Git hup (or *ANY* remote service for that matter) is a no go IMO


You just don't get it.

Again, you just really, really, don't get it.

You WANT a gateway to a remote service that the project does not have to
handle.

Why?  Because then we offload the problem to another org.

The FreeBSD project should be about innovation in OS design, platform
and software.  Ops work is bunk and just slows us down.

The more we can outsource the better we'll be.  (and what if that
service blows up?  well we move on!  it's simple!)

Continuing to insist that we run the services ourselves it just wasting
our limited resources.  Not only that but we get emotionally attached to
technologies that are old, dying and dead when off the shelf stuff works
just fine.


I've read all 60 or so messages in this thread and there really are two 
related but distinct issues here.


The thread title is What is the problem with ports PR reaction 
delays?. This has meandered into a philosophical debate about who knows 
what and who knows squat about version control systems, whether we need 
to maintain certain requirements, testing ports, etc.


I like the KISS approach myself. This can be boiled down to those two 
issues, one of which is a symptom of the other. Arguing and debating 
over a long term solution to the OP's question does nothing to solve the 
problem in the short to intermediate term. There are 1680 current ports 
related PR's at this moment.


As we all know, the committers are volunteers, mostly with real jobs and 
real lives and they obviously cannot keep up with the current load. The 
short to medium term solution for that is more committers. I'll add my 
name to the list of those who are willing to step in and help to clean 
up the mess. I'm certain that if a request went out, there would be many 
who are more qualified than I.


At the same time, a group of interested individuals should offer input 
to the folks who already are looking at changing the bug reporting 
system away from gnats - 
https://wiki.freebsd.org/Bugtracking/BugRelocationPlan. Doing it in one 
fell swoop might make sense. It's ripping off the bandaid but I'd 
rather do it only once myself.


What does *not* make sense is a new port for what might be a very useful 
tool waiting since September for someone to look at it. Arguing over git 
and subversion et alia does nothing to fix that. As they say on the ESPN 
NFL pregame show, C'mon man!.


--
Jim Ohlstein
___
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: What is the problem with ports PR reaction delays?

[Jim Ohlstein]

Hello,

On 1/25/14, 10:33 PM, Aryeh Friedman wrote:



I like the KISS approach myself. This can be boiled down to those
two issues, one of which is a symptom of the other. Arguing and
debating over a long term solution to the OP's question does nothing
to solve the problem in the short to intermediate term. There are
1680 current ports related PR's at this moment.


The reason for the whole tangent was the observation that large number
of the pending PR's are likely to fail one or more *BASIC*  tests and
setting stuff up to run those tests is trivial (like I said I voluneteer
to do it)... the other main thread there was that some of the *IDEAS* of
SCM can borrowed and incorporated into manual procedures (such as
requiring a successful build before a human will look at it) the other
one is a more formalized workflow such as the one that aegis
enforces if just the first is done I think half the PR's can be
cleared out immediately and if both then 80% can be cleared out within a
few weeks




None of those *IDEAS* solve the current problem. The personal argument 
solves less than nothing. Debate is cool. Telling people they don't know 
anything is not.


Your statement looks to be pure supposition to me. On 
http://www.freebsd.org/cgi/query-pr-summary.cgi?category=portsseverity=priority=class=state=sort=nonetext=responsible=multitext=originator=release= 
the vast majority of them are not color coded beyond white which simply 
means open. Many have not even been assigned. Only a comparatively 
small number are analyzed, [awaiting] feedback, patched, 
suspended, or closed. In other words no one knows how many will 
fail. The ones that are a decade old probably will. Those from the last 
few months, the majority, are anyone's guess since they haven't even 
been reviewed. That is unless you have some hard data to back up your 
claim about those percentages.


As for changing the workflow, again, that's not a short-term solution, 
and probably not even a medium-term answer. The answer is to get them 
looked at and stop having a pissing contest over who knows more and who 
knows less. *THAT* solves nothing.


Peace out.

--
Jim Ohlstein

Never argue with a fool, onlookers may not be able to tell the 
difference. - Mark Twain

___
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

bind99 port overwriting named.conf

[Jim Ohlstein]

Hello,

I upgraded ports yesterday and (much to my chagrin) found that 
/usr/local/etc/named/named.conf had been overwritten.


I initially reported it to the maintainer and was told now, you know it 
does that and you can save it before upgrading..


This seems to be counter to the way most (all?) other ports work, 
especially when it was not even a minor version upgrade.


Further, looking at 
http://svnweb.freebsd.org/ports?view=revisionrevision=335667, it seems 
the intent is:


Install named.conf as named.conf.sample and don't overwrite on upgrade.

So which is it going to be going forward?

Please cc me on replies as I do not subscribe to this list.

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