Re: DoveCot 2.3

[Matt Smith]

On Mar 07 09:17, The Doctor wrote:

What are the hold ups for Dovecot 2.3 ?



You, constantly asking this list why they haven't upgraded any ports to 
the latest versions but not actually providing any patches yourself to 
help the volunteers do this more quickly.


--
Matt
___
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: Call for help: www/nginx and 3rd party module

[Matt Smith]

On Feb 21 17:18, Jochen Neumeister wrote:


Which 3rd party modules do you use, which the port itself provides?



This type of thing may be better suited for an online webpage type 
survey rather than potentially getting lots of posts to the mailing list 
with similar things?


I always use and would greatly miss HTTP_DAV_EXT. Because for some 
inexplicable reason they won't put this functionality in the core DAV.


I've also used HTTP_GEOIP2 in the past for a couple of things, but I 
wouldn't miss this one quite as much now.


--
Matt
___
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: All those notes...

[Matt Smith]

On Jan 08 14:44, Dave Horsfall wrote:
Why would /usr/local/etc/apache24/httpd.conf need to be removed if not 
needed?  Surely as I've just upgraded it, I might want it?


The notes are for people installing the port/package for the very first 
time or for people removing the package. It's telling you things that 
you should do to get it working initially or how to clean up old files 
that are no longer used now you've deleted it.


You are only seeing these notes because the act of upgrading them 
removes the old package and then installs the new package.


If you have simply upgraded it then you can likely completely ignore all 
of these notes and instead you should take note of anything that is 
written in /usr/ports/UPDATING which relates to upgrades for your 
specific packages.


--
Matt
___
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: Status of portupgrade and portmaster?

[Matt Smith]

On Oct 02 11:51, Don Lewis wrote:


Yes, but at least the poudriere jail doesn't build the kernel bits.  The
real pain point is that when you update the jail, the next bulk package
build will toss all the previously built packages and force a full
rebuild from scratch.  That makes sense if you believe that the contents
of the jail affect the contents of the packages build using that jail.
If you don't think that is true, then why bother to update the jail.


That is a good point and it does seem an overkill if you think not much 
has changed in the jail to warrant it. It doesn't do it every time, only 
when they increment the osrel number.


There is a way around it. I sometimes run this script which updates the 
jail to be the same as my host.


#/bin/sh

V1=`uname -r`
V2=`sysctl -n kern.osreldate`
JV=`find /var/poudriere/data/packages/ -depth 2 -name .jailversion`

echo "${V1} ${V2}" > ${JV}
echo "${JV} set to ${V1} ${V2}"


--
Matt
___
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: Status of portupgrade and portmaster?

[Matt Smith]

On Oct 02 20:01, Marco Beishuizen wrote:

On Mon, 2 Oct 2017, the wise Don Lewis wrote:

Yes it can.  If you use the svn method when creating a jail you can 
chose any arbitrary source branch from the svn repository and then 
you can specify any desired svn revision on that branch when you 
update the jail.  You would probably want to use this method when 
building ports for 12.0-CURRENT rather than creating the jail using 
a 12.0-CURRENT snapshot.


I'm running 11.1-STABLE now, upgrading every few months or when there 
is an important security fix. Do I have to build a new system twice in 
that case (once my running system and once the poudriere jail)?




What I do is to initially create the jail using poudriere jail -c -j 11 
-m src=/usr/src and then I upgrade the jail using poudriere jail -u -j 
11.


These commands use the existing /usr/src and /usr/obj trees from the 
host system buildworld/kernel. It doesn't need to be rebuilt.


--
Matt
___
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: Status of portupgrade and portmaster?

[Matt Smith]

On Oct 02 12:05, Vlad K. wrote:

On 2017-10-02 11:57, abi wrote:

2. Dependency chain is not updated - if I disable B feature on port A,
poudriere asks me for options of ports implementing B. I have to
Ctrl+C after any option change.



I find that annoying as well, but isn't that just how the 
config-recursive ports framework target works? Poudriere is really 
using the ports make targets here.


Do synth or portmaster do it differently?



Synths philosophy was that you should have the absolute bare minimum of 
options set and John wrote a script to do just this in 
/usr/ports/Tools/scripts/redundant-opt-files.sh to delete any which just 
have defaults in them.


My method with poudriere is to maintain two files, pkglist which is the 
list of ports that I want to bulk build, and optlist which is the list 
of ports for which I don't want the default options. This one is a 
hugely cut down list.


I then occasionally run poudriere options -n -j jailname -f optlist so 
that it non-recursively only gives me a dialog for the ports with 
non-default options.


--
Matt
___
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: Status of portupgrade and portmaster?

[Matt Smith]

On Oct 02 09:07, Carmel NY wrote:

On Sun, 1 Oct 2017 23:49:14 +0100, Matthew Seaman stated:


On 01/10/2017 11:34, Carmel NY wrote:

1. Does it determine out-of-date update packages automatically or does
the user have to determine that what is out-of-date and feed them to
poudriere manually and in the proper order?


Automatic.


2. From what I have read, the user is required to install each package
manually. Is that correct?


Poudriere builds a repository.  You then have to type 'pkg upgrade' or
'pkg install foo' to update your live system.  Most people do not find
this particularly taxing.


From the "pkg-descr" file:

poudriere is a tool primarily designed to test package production on
FreeBSD. However, most people will find it useful to bulk build ports
for FreeBSD.

While it will undoubtedly work, it is still more complex than the average
desktop user requirers. Synth fits the bill nicely by being, for the most
part, easy to understand and run. I am already on my forth "ports maintenance"
program having used portmanager, portmaster, portupgrade and now synth. At
this point, I would almost rather switch to a new OS before abandoning synth
for something that IMHO is just overkill for the average user.

Just my 2¢.



Of course if you did move to a different OS then the chances are you 
would be using a binary package repository and not compiling any 
software from source. So you wouldn't have any choice over the options 
that these packages were built with.


If you are happy enough to do this then you may as well just abandon 
building ports on FreeBSD anyway and just use the pkg tool from the 
official FreeBSD repository. This is the easiest option surely.


For what it's worth I've used both synth and poudriere and whilst 
poudriere is slightly heavier to use because of the requirement to 
create a build jail first, once that step has been done it's pretty much 
identical to using synth really.


My workflow is simply this:

poudriere ports -u (update the ports tree)
poudriere bulk -j 11 -f pkglist (check for any updates and build any 
packages listed in the pkglist file)

pkg upgrade (upgrade any upgraded packages)

That's it. The same workflow on synth is:
svn up /usr/ports
synth build pkglist
pkg upgrade

Pretty similar if you ask me. OK you could use synth upgrade-system and 
do it in one command rather than two but then you're building everything 
on the host system and not a specific list. Also I like the extra pkg 
stage, it gives me a chance to see what pkg is about to do and abort it 
if it wants to do something insane.


--
Matt
___
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: Status of portupgrade and portmaster?

[Matt Smith]

On Sep 29 20:23, Kurt Jaeger wrote:

Hi!


What is one officially supposed to use to build and upgrade
packages from source?


I doubt that we already have a 'official' consensus, but
buildung using poudriere, while expensive from the
hardware resource point of view, looks to me as the most stable
way to do it.



I agree. Portmaster was useful for many years but these days it is being 
left behind. The expectation is that ports are built in a clean room 
environment and portmaster does not provide that. I used synth for 
several months and it is a great tool. It works fine, but my problem 
with it is that the developer was forced out of FreeBSD and it needs an 
ada compiler.


I think on FreeBSD 12 the ada compiler is broken isn’t it? Meaning synth 
will break. For this reason I switched to poudriere and that works fine 
for me. As that is the tool used by the pkg builders themselves I know 
it will work.


For example we are shortly getting flavors support in the ports tree. I 
think the author of synth has already said he is not going to support 
this whereas poudriere will straight away.


--
Matt
___
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: synth install ... builds but does not always install named packages

[Matt Smith]

On Sep 15 08:23, Thomas Mueller wrote:
In some cases, the named packages failed to install the first time 
(math/gnumeric and editors/abiword), and in other cases desired 
dependencies didn't install (devel/nasm and sysutils/coreutils, for 
instance).


I need some of those build dependencies for other things like, for instance, 
cross-compiling Haiku and cross-compiling Linux toolchains, or other FreeBSD 
ports.

Is there anything I can specify to install those build dependencies, and how do 
I go through /var/synth/live-packages/All and pkg info -a to install those 
packages that failed to install without missing something?

Synth runs faster and more gracefully than portmaster, but portmaster installed 
everything that it built.

Tom



Maybe something along the lines of pkg install -g * ? I'm not sure, but 
-g lets you do a glob pattern.


--
Matt
___
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: synth install ... builds but does not always install named packages

[Matt Smith]

On Sep 15 07:34, Thomas Mueller wrote:

I am building up a system (FreeBSD 11.1-STABLE amd64) using synth, but even 
when the packages build and appear in /var/synth/live_packages/All , some of 
the packages don't install.

When I type "which gnumeric", "which bison", "which abiword", I just get a 
blank, and the executable files don't appear in /usr/local/bin .

This happened with math/gnumeric, editors/abiword-docs, among others.

I subsequently installed those packages by typing "synth install math/gnumeric" and 
"synth install editors/abiword-docs", but how do I find all the others that built and are 
listed in /var/synth/live_packages/All but did not install?

I see

"ls -l /var/synth/live_packages/All" has 657 lines, while

"pkg info -a" produces 544 lines.

I piped to "more", then hit G to go to the end, then Ctrl-G, which showed the 
number of lines.

This may not tell the whole story, but makes me believe there is a disparity, 
and ask how to find and install those packages that built but didn't install.

Has anybody else been stung by this bug?

Tom



Do you actually want those packages installed? The usual reason is that 
they are build dependencies only required for building another package 
and therefore they are in the repo but not installed. If they are run 
dependencies actually required for another package to run then they 
should be installed.


Freshports is a good site for looking at this.  
http://www.freshports.org/


If you search for something it tells you what is build and what is run.  
Alternatively you can look at the ports Makefile for lines such as 
BUILD_DEPENDS, RUN_DEPENDS, LIB_DEPENDS etc.


--
Matt
___
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 does not upgrade if more than one repository is defined

[Matt Smith]

On Jul 28 11:40, Miroslav Lachman wrote:

Matthias Fechner wrote on 2017/07/28 10:55:

Dear all,

I have a problem with pkg and I'm not sure if it is a bug in pkg or a
configuration issue.
I work on new version on ports which are in a separate poudriere
repository (to be able to easily test it).

I have now two configuration files in /usr/local/etc/pkg/repos,
poudriere.conf:
poudriere: {
url: "https://pkg.fechner.net/packages/110amd64-default;,
mirror_type: "pkg+http",
signature_type: "pubkey",
pubkey: "/usr/local/etc/ssl/certs/pkg.cert",
enabled: yes,
priority: 1
}

this is the standard repo which contains all stable packages.
Now I have a new version (in this case for gitlab) at gitlab.conf:
gitlab: {
url: "https://pkg.fechner.net/packages/110amd64-gitlab;,
mirror_type: "pkg+http",
signature_type: "pubkey",
pubkey: "/usr/local/etc/ssl/certs/pkg.cert",
enabled: yes,
priority: 10
}

The priority is higher and some package there have a higher version number.

But if I execute now 'pkg upgrade' pkg does not upgrade packages which
have a higher version from the gitlab repository, but stick to the
poudriere repository.

I also tried to do a 'pkg update -f; pkg upgrade' but it does not help.

Is there something wrong with my configuration or is this a bug in pkg?


If I understand you correctly, you have package A-1.0 installed from 
repo "poudriere" and now you have package A-1.1 in repo "gitlab" and 
you want to upgrade this package "A" to version 1.1.

Is it right?

I think that crossrepo upgrade is not automatic if package is in both 
repositories but it work if package is missing from previous repo and 
it it intentional.
I have more repositories too (different PHP version, different python 
versions but common utilities etc.) so packages are not 
unintentionally upgraded / downgraded.


But if you want to upgrade package A from different repo, you can 
choose the repo:


-r reponame, --repository reponame
 Install packages from only the named repository, irrespective
 of the configured ``active'' status from repo.conf.

You can try
  pkg install -r gitlab -f A

or
  pkg upgrade -r gitlab -f A

where A is you package(s) name.

Miroslav Lachman



This might also be related to the CONSERVATIVE_UPGRADE setting of 
pkg.conf. According to the man page:


CONSERVATIVE_UPGRADE: boolean
Ensure in multi repository mode that the priority is
given as much as possible to the repository where a
package was first installed from.  Default: YES.


--
Matt
___
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: What to do when the port fails in poudriere with "Too many open files" ?

[Matt Smith]

On Jun 28 22:38, Yuri wrote:
I have the port that builds fine without poudriere, but in poudriere 
it always fails with "Too many open files".


This happens during the Java build.


Where is the limit set in jail? /etc/login.conf doesn't have any limit.

What to do in such case? Maybe there is some way to tell Java to limit 
the number of open files?



Yuri



I would take a look at /usr/local/etc/poudriere.conf at the MAX_FILES 
setting.


--
Matt
___
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: [RFC] Why FreeBSD ports should have branches by OS version

[Matt Smith]

On Jun 23 08:02, scratch65...@att.net wrote:

On Fri, 23 Jun 2017 00:36:19 +0200, Miroslav Lachman
<000.f...@quip.cz> wrote:


scratch65...@att.net wrote on 2017/06/23 00:15:

[Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
 wrote:


On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:

My problem is that my industry experience tells me that reducing
the frequency of port releases is practically *guaranteed* to be
a Really Good Thing for everyone.


I remember before we had the quarterly releases, and people on the
mailing lists complained constantly about the ports bits only being
available once per release, or rolling with -head.


Mark, I can only suppose that those complainers are dilettantes
of some sort who believe that having The Latest-And-Greatest Bits
is a social-status enhancer.  **Nobody** with real work to do
ever willingly fools away time "fixing" what isn't broken.


And this is where you are so wrong. Ports tree is never in the state
where everything works and has no bugs. (and cannot be, because
upstreams have bugs) Even if it compiles and installs it does not mean
that it is not broken and nobody needs newer version.
Just because your needs are different than others doesn't mean others
are dilettantes.


How often have you bought all new versions of the software you
use, Miroslav, even though the versions you replaced still worked
fine?  I'd bet that you've never done that, and never will:
you're an adult, and have more important uses for your time and
money.

How often do you look around your flat or house for something to
"fix" even though everthing works well enough?  I'd bet not
often, if ever -- you probably always have so much real work to
do that you worry you'll never get it all done if you live to be
120.

There are individuals who claim to "need" the latest Mercedes or
Ferrari, or a bigger yacht, or a chalet in Switzerland.  But that
kind of "need" isn't on the same level as someone's need for a
place to live, or a way to get to work, or medical care for their
kids.

Similarly, few people constantly "need" the latest software. Even
if the new release has a feature that will make their work
easier, the release after that one is not likely to have
*another* such feature.   Nearly all adults can do their
computer-based work just fine without ever having the
Latest-And-Greatest hardware and software.  Those who claim they
simply *must* always have bleeding-edge kit are kidding someone.
Or delusional.
___


Can we stop suggesting that everybody in the world wants a stable 
release that doesn't frequently change, or that people who want to use 
the latest versions of software are delusional please?


I use FreeBSD *precisely* because it mostly keeps up with the latest 
stable versions of things. I have postfix 3.2, pgsql 9.6, nginx 1.13, 
libressl 2.5 etc. It's usually impossible to do this with linux unless 
you install things directly from source.


I upgrade my ports/packages via poudriere every single day which mostly 
just takes 2 minutes of my time as usually that results in maybe one or 
two packages being updated at a time. I see this as a positive thing 
rather than doing one massive huge upgrade every 3 months.


If I see that a package is going to have a major version upgrade then I 
say no and cancel the update until I have a spare half hour or so later 
in the day. Then I will spend the time seeing what the differences are 
and changing my config etc as appropriate.


I actually like this way of working and it suits me fine. I enjoy 
learning the ins and outs of new software. If everybody had the attitude 
of never spending time doing major version updates then we would all be 
in the python3 verses python 2 situation where virtually nobody is 
writing python3 code.


I'm not going to argue against what you guys are asking for, each to 
their own, you have your own requirements and that's fair enough. But I 
just wanted to make a point that the way that FreeBSD currently does it 
is not "nobody wants it done this way". At least one person does thanks.



--
Matt
___
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: Keeping -CURRENT up to date with Poudriere

[Matt Smith]

On Jun 19 23:14, Jaap Akkerhuis wrote:



On Jun 19, 2017, at 20:24, Ben Lavery-Griffiths  
wrote:

Thanks very much,

I’ll look into doing similar.


What I do is to have STABLE and CURRENT jails using the svn method.
Then "poudriere jail -u" takes care of the update.



Why bother having the system compile it twice? If you use -m 
src=/usr/src then it will just use the already built STABLE world from 
your host build. Easy way to make it synced to the live system. And 
poudriere jail -u still works fine to update it.




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

Re: The ports collection has some serious issues

[Matt Smith]

On Dec 08 05:16, Daniil Berendeev wrote:


Although portmaster is not releated to the FreeBSD project and is an
outside tool, there aren't any alternatives from the project itself. So
use it or die. Not a nice situation.


People have been trying to get portmaster deprecated and removed from 
the handbook but have met with resistance. It's pretty much unmaintained 
and because it acts on a live system can mess up as it has no idea if a 
port needs recompiling because a dependency changed ABI etc.


The recommended replacements are ports-mgmt/synth and 
ports-mgmt/poudriere. These build an entire package repository that the 
pkg tool can use but they do so in clean chrooted environments, and 
rebuild everything that's required to keep a consistent ABI. Synth is 
more designed for a single live system like a desktop or a single 
server, whereas poudriere is what the freebsd package build clusters use 
and is more designed for that type of usage. Worth taking a look.


It's a shame the handbook hasn't been updated to give this information.

Matt
___
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: lighttpd does not pull OpenSSL dependency

[Matt Smith]

On Oct 27 16:22, Matt Smith wrote:

I don't see this on my system which is FreeBSD 11.0-STABLE #0 r307132

$ ldd /usr/local/sbin/ntpd | grep -E '(crypto|ssl)'
libcrypto.so.38 => /usr/local/lib/libcrypto.so.38 (0x800cee000)
libssl.so.39 => /usr/local/lib/libssl.so.39 (0x801aca000)


Oh never mind, I guess it's because the so revision is 38/39 whereas in 
openssl it's 8 the same as the base version. Sorry for the noise!


--
Matt
___
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: lighttpd does not pull OpenSSL dependency

[Matt Smith]

On Oct 27 10:00, Matthew D. Fuller wrote:

On Thu, Oct 27, 2016 at 03:05:03PM +0200 I heard the voice of
Mathieu Arnold, and lo! it spake thus:


Once you install openssl from ports, the ports framework will use
it, always.


That is absolutely not the case since OpenSSL in base was updated to
.so.8 and ports wasn't re-bumped past it.  Everything gets confused
all the time.

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

Even in an e.g. net/ntp rebuilt just now:

% ldd /usr/local/sbin/ntpd | grep -E '(crypto|ssl)'
   libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x800cea000)
   libssl.so.8 => /usr/lib/libssl.so.8 (0x801ae6000)

Just looking at a ldd through /usr/local I'm finding tons of things
that are still linking to base libcrypto.  STuff from ldns, nginx,
Virtualbox, libwww, lots of X pieces...

This makes me *EXTREMELY* nervous about upgrading _any_ systems where
I'm using ports OpenSSL to stable/11.



I don't see this on my system which is FreeBSD 11.0-STABLE #0 r307132

$ ldd /usr/local/sbin/ntpd | grep -E '(crypto|ssl)'
libcrypto.so.38 => /usr/local/lib/libcrypto.so.38 (0x800cee000)
libssl.so.39 => /usr/local/lib/libssl.so.39 (0x801aca000)

Most likely because I have correctly declared the default version of the 
SSL library by putting DEFAULT_VERSIONS=ssl=libressl-devel in make.conf.


Without declaring it specifically like that I wouldn't trust the system 
to do it automatically either.



--
Matt
___
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: Upcoming OpenSSL 1.1.0 release

[Matt Smith]

On Aug 24 21:18, Bernard Spil wrote:
Today new vulnerabilities with (3)DES and BlowFish were made public and 
I believe we'll see release of another paper which is OpenSSL 1.1 
related with the release of OpenSSL 1.1.0. I have no knowledge if the 
paper/report contained vulnerabilities that have postponed the release 
of 1.1.0 but I think that is likely. That would mean that these 
vulnerabilities have been solved pre-release.


As far as I know x25519 is still a Draft RFC so unlikely to appear in 
browsers for a while. I can see LibreSSL adding this as well, whether 
in the draft version or in the final. This they did with 
ChaCha20/Poly1305 as well (draft in 2.3, release in 2.4). The LibreSSL 
devs would have closed the request if they didn't intend to support it 
https://github.com/libressl-portable/portable/issues/114


I don't think that FreeBSD will be making LibreSSL the 
libssl/libcrypto provider any time soon. The support timelines for 
LibreSSL (<1.5 years) are just too short for the FreeBSD release 
support (>3 years). OpenSSL is speeding up the release cycle as well 
but at least we can rely on RedHat to backport changes to older 
versions.


LibreSSL in base is a bit more than playing, it is becoming the 
default in HardenedBSD very soon and very likely in TrueOS (AKA 
PC-BSD) as of 11.0 RELEASE. Both HardenedBSD and TrueOS have a 
different attitude towards updating things in the base system as they 
do not serve as upstream to other projects/products that require 
longer support timelines. Come see my talk at EuroBSDCon, it will 
contain LibreSSL in base things.


Cheers,

Bernard.


Thanks for that reply. That answers things quite nicely. I believe 
x25519 is currently in chrome:


https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome=51=Win%207=126

It has x25519 listed as an Elliptic curve near the bottom. So for that 
reason I am interested in enabling it as I like to do things bleeding 
edge! I will probably stick with security/libressl-devel for the 
foreseeable future though I think and at least wait and see what people 
make of OpenSSL 1.1 after a few months if only for the fact it's a bit 
of a pain to switch back again by recompiling everything.


--
Matt
___
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: Upcoming OpenSSL 1.1.0 release

[Matt Smith via freebsd-ports]

On Aug 23 12:19, Roger Marquis wrote:

Matt Smith wrote:

Going slightly off-topic, I'm curious what the opinion is around this
and LibreSSL.


My organization evaluated this a few months ago and after a few diffs
and code reviews decided that libressl was the future.  We updated
poudriere and all make.confs, removed openssl, installed libressl and
have had no issues.  We did the same with openntp a few months earlier
and recommend both for any installation that needs good security.

Roger


I have been running libressl-devel for the past few months and other 
than having to manually patch a few ports to get them to compile have 
also had no problems. However this was the case a few months ago. My 
questioning is specifically related to the upcoming OpenSSL 1.1 which in 
theory has had a lot of work done to it by a full-time paid team of 
developers.  In fact it was meant to be released back in May but was 
delayed specifically so that they could squash all remaining bugs. It 
would be interesting if somebody could audit the changes to see how it 
compares to LibreSSL after it's released.  There is a possibility that 
it may actually be the better path going forward.


--
Matt
___
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: Upcoming OpenSSL 1.1.0 release

[Matt Smith via freebsd-ports]

On Aug 22 20:39, Mathieu Arnold wrote:

ports-committers is a *NEVER POST DIRECTLY TO* list, so, moving it to
ports@ where this belongs a lot more.

+--On 22 août 2016 20:30:15 +0200 Bernard Spil  wrote:
| Curious to know how we should procede with the upgrade of the OpenSSL
| port to 1.1.0!

All ports need to work with it, I'm sure software like BIND9 do not build
with it.

--
Mathieu Arnold


Going slightly off-topic, I'm curious what the opinion is around this
and LibreSSL. My understanding is that LibreSSL was forked from OpenSSL
1.0.1 and they have not backported newer stuff from OpenSSL. I also
believe OpenSSL now has several full time paid developers working on it
and that the 1.1 release has some significant changes under the hood?

I've been using LibreSSL for a while so that I can get chacha20 support
but OpenSSL 1.1 will not only have chacha20, but will also have x25519
support as well. This along with what I said above is making me think it
might be better to go back to OpenSSL.

I just wondered what people in the know think about the current
situation with these two things. Plus are there any roadmaps for the
future of FreeBSD regarding the defaults. Is the project ever going to
look at making LibreSSL the default port, or will that be kept as
OpenSSL for many years to come? I know Bernard has been looking into
that and playing around with LibreSSL in base etc. Just curious what the
official policy is going to be on that.

--
Matt
___
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 updating -d broken?

[Matt Smith via freebsd-ports]

On May 26 21:53, Alphons van Werven wrote:

Matt Smith via freebsd-ports wrote:


Anybody else notice that pkg updating -d has been broken for a while? Or
is it just me?

# grep 2016 /usr/ports/UPDATING | head -4
20160526:
20160525:
20160523:
20160511:

# pkg updating -d 20160523


Just to be sure: you do know that "pkg updating" only displays UPDATING
entries for ports that you have actually installed, right?

AvW


Wow, no I did not actually know that! Now I re-read the man page you're 
right, it clearly says that. It's just that whenever I've ran this 
command in past months it has *always* shown some entries whereas in the 
past month or two I've never seen it output anything at all. So it 
looked strange to me. It makes sense now though, thanks!



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

pkg updating -d broken?

[Matt Smith via freebsd-ports]

Anybody else notice that pkg updating -d has been broken for a while? Or 
is it just me?


# grep 2016 /usr/ports/UPDATING | head -4
20160526:
20160525:
20160523:
20160511:

# pkg updating -d 20160523
#

--
Matt
___
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: mail/postfix and mail/postfix-current need upgrading

[Matt Smith]

On Feb 26 18:48, olli hauer wrote:
In some weeks 3.1.x will become the default postfix, and 3.0.x will be 
removed from the tree, postfix211 will stay as the last postfix 2.x 
releases and current will become again current.

There are some users using VDA patches, only available for postfix 2.8 but it 
also works on 2.11, there is no support from the VDA project for 3.x and it 
seems the VDA project is no longer alive.


I saw this in the updates that you made yesterday, thanks! However it 
looks like VDA is still in the Makefile for postfix-current which seems 
weird if you say that you have removed VDA support?


--
Matt
___
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 + Synth issue

[Matt Smith]

On Feb 17 15:05, Kurt Jaeger 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.



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)


The PHP eco-system is so huge that one can say that even php56 is
not yet ready for prime time 8-)

So: Everyone knows that php70 has open issues, miwi and others are
tracking them down, and if users/testers submit problem reports via
bugzilla, it helps enormously.

It will settle the next few weeks.



I'll search bugzilla to see if there are any bug reports for this and if 
not I'll raise one then.


I know php70 is very new so I was expecting problems. Synth is pretty 
new as well though so I thought I would let people know in case they 
were not aware of this type of breakage.


Thanks,

--
Matt
___
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 + Synth issue

[Matt Smith]

On Feb 17 14:16, John Marino wrote:


It seems like a problem with comms/atslog to me.
You can work around it now by removing MYSQL as a default option for
that port (either modifying the port itself or adding something in
-make.conf to change it)

atslog is not maintained.  Another option is hiding the option if
php>=7.  Probably the easiest thing to do is turn off the option by
default though.



The problem is that it isn't just that port. I've also seen it on 
databases/mysqldumper for example. It's going to affect all ports which 
have USE_PHP=mysql within them of which I suspect there are quite a lot.  
It might be impractical to do what you suggest with them all and I'm 
wondering if miwi as the maintainer of PHP7 has any thoughts of an 
official way of solving it.


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

PHP7 + Synth issue

[Matt Smith]

Hi guys, I'm using the ports-mgmt/synth package builder to build my 
packages.  I just tried to build all of the packages for PHP7 from the 
new ports and came across an issue. If I set php=7.0 in DEFAULT_VERSIONS 
in the LiveSystem-make.conf (make.conf) then Synth bails out and refuses 
to build the repository. It does this:


Scanning entire ports tree.
progress: 5.93%
culprit: comms/atslog
Scan aborted because dependency could not be located.
databases/php70-mysql (required dependency of comms/atslog) does not 
exist.


It looks like it scans the port tree, come across a port that has 
USE_PHP=mysql in it and then bails because the port 
databases/php70-mysql does not exist. Obviously because mysql was 
removed from PHP7 in favour of mysqli.


Is this a problem with the ports infrastructure or should I just not 
declare php=7.0 in the DEFAULT_VERSIONS? If I do this then it builds 
fine, but I guess that might cause other issues elsewhere.


--
Matt
___
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 (was: [Bug 206922] Handbook: Chapter 4.5+ changes)

[Matt Smith]

On Feb 11 22:25, Lev Serebryakov wrote:

On 07.02.2016 17:28, John Marino wrote:


ports-mgmt/synth.  I would love to hear what signficant thing
portmaster can do that Synth can't.  (honestly)

Be installed FROM PORTS without all this build-one-more-gcc stuff.
Ada? For *port*management* tool? Are you joking?

--
// Lev Serebryakov


Remember that before portmaster we had cvsup which was written in 
Modula-3 and portupgrade which is written in Ruby. Whilst it is nice 
that portmaster is just a simple shell script with no dependancies 
that's a relatively new thing.


--
Matt
___
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: Removal of $UNIQUENAME

[Matt Smith]

On Aug 18 22:49, Kimmo Paasiala wrote:

It would have been nice to have some kind of announcement about the
removal of $UNIQUENAME. I for example was depending on it in my
make.conf with declarations like these:

vim_SET= CONSOLE
vim_UNSET= GTK2 RUBY TCL

I can of course rewrite those now using $OPTIONS_NAME (editors_vim
prefix instead of vim) after reading bsd.option.mk and figuring out
the way that works...

-Kimmo


There was. pkg updating UNIQUENAME will show you the announcement. Or 
just look at the top of /usr/ports/UPDATING.


--
Matt
___
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: OpenSSL Security Advisory [11 Jun 2015]

[Matt Smith]

On Jun 13 13:13, Michelle Sullivan wrote:

Don Lewis wrote:

On 13 Jun, Michelle Sullivan wrote:



SSH would be the biggie that most security departments are scared of...



Well, ssh is available in ports, though I haven't checked to see that it
picks up the correct version of openssl.




Problem is it doesn't have 'overwrite base' anymore - and
openssh-portable66 which does have overwrite base is now marked
depreciated... which means one would have to be very careful about how
they use SSH in production as both server and client...  Server is
easier as it has a different _enable identifier... but the client is not
distinguishable so unless one puts /usr/local/bin in their permanent
path as a priority over /usr/bin one will use the wrong version.



I put WITHOUT_OPENSSH=yes in /etc/src.conf. Then run make delete-old and 
make delete-old-libs in /usr/src. This removes the base version which 
means you don't have this issue any longer. I do the same thing with NTP 
and Unbound as well.


Obviously this makes more sense if like me you do source based stuff 
rather than using freebsd-update. I'm not sure if you can do similar 
with binary based upgrades?


The other alternatives are as you say, put /usr/local/bin before 
/usr/bin in the $PATH. Or add an alias for commands like ssh to point to 
the ports version. These methods aren't quite as clean though.


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

ports/base ntpd rc.d script with WITHOUT_NTP=yes

[Matt Smith]

Hi,

I just upgraded my server to 10.1-STABLE r281264 and when I ran 
mergemaster it told me that /etc/rc.d/ntpd was stale and would I like to 
delete it. It's never done this before. I've figured out it's because I 
have WITHOUT_NTP=yes in /etc/src.conf. I did this because I use the 
ports version of ntpd and thus wanted to remove the base installed 
version so that when I run commands like ntpq it's using my possibly 
newer port installed version and not the older one.


However, the port version doesn't have its own rc script. It usually 
uses the base version with ntpd_program and ntpd_config set.  With this 
latest change it means I have to have the base version installed again.  

Is it possible to get the port version to have its own rc script? 



--
Matt
___
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: BIND REPLACE_BASE option

[Matt Smith]

On Jan 14 12:15, Mathieu Arnold wrote:


Well, like I said, REPLACE_BASE was an abomination that should never have
existed, now that it's gone, it'll never get back, and you'll never see it
again.



Doug Barton who used to maintain BIND in both the base system and the 
port used to always say that the version in the base system was only 
designed to be used as a local resolver on a laptop/desktop. If it was 
used as a proper DNS server the port version was meant to be used 
instead. Based on this it makes perfect sense why BIND was replaced with 
local Unbound in the base, and the ports system still has BIND for 
people that were using it.


It should have been a very small minor change. If people didn't want to 
have two versions installed then the solution would have been to use 
WITHOUT_NAMED or WITHOUT_BIND whatever the knob was in src.conf so that 
those files were deleted or not installed in the first place. I do 
exactly this for NTPd, OpenSSH, and Unbound all of which I use the port 
versions for so don't need them in the base system.


--
Matt
___
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: BIND REPLACE_BASE option

[Matt Smith]

On Jan 14 13:30, Michelle Sullivan wrote:

Matt Smith wrote:

Doug Barton who used to maintain BIND in both the base system and the
port used to always say that the version in the base system was only
designed to be used as a local resolver on a laptop/desktop. If it was
used as a proper DNS server the port version was meant to be used
instead. Based on this it makes perfect sense why BIND was replaced
with local Unbound in the base, and the ports system still has BIND
for people that were using it.


Was this ever documented? (I've been using bind in base for servers for
many years and this is the first time I've heard of it - and it is
unlikely I'm the only one.)



I'm not sure if it was documented anywhere in particular. I've just seen 
it mentioned lots of times on these mailing lists in the past.  
Specifically around the time he was experimenting with slaving the root 
and arpa zones and there were a few configuration changes to named.conf 
at that time.


The main reasoning is that the versions of things in the base system are 
usually old and rarely get updated. They occasionally get patches if 
there's a serious security vulnerability but for minor bugs it's 
unlikely you'll see any patch. And to patch it you quite often need to 
do a full O/S upgrade which is very time consuming and probably needs a 
reboot. The port versions are updated straight away, even for minor bugs 
and because you've not also updated half the O/S in the process you 
don't need to do anything other than restart named.


--
Matt
___
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: gnupg-2.1 - 2.1 appears to break decryption of saved messages

[Matt Smith]

On Jan 07 07:49, Corey Halpin wrote:

On 2014-11-20, David Wolfskill wrote:

It has been my practice for several years to email sensitive information
(such as passwords) to myself via envrypted email, using mutt and GPG.

[...]

Then, a few minutes ago, I tried to retrieve a password from one of my
saved encrypted messages... only to be informed Could not copy
message.


 I also enjoyed some friction trying to use gnupg 2.1 with mutt,
though I didn't get the Could not copy message error that you
report.

 Instead I was seeing 'no secret key'.  In my case, this was resolved
by following the advice at
 https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase .

 Namely:
 echo allow-loopback-pinentry  ~/.gnupg/gpg-agent.conf

 and editing my copy of mutt's gpg.rc to add '--pinentry-mode
loopback' to every gpg invocation involving a passphrase-fd.

 After that, things were back to normal for me.

 Hopefully this helps others avoid the same problem.

~crh


I also had exactly the same problems, not only with mutt but with 
duplicity. I figured out how to fix it from the same site you found.  
This is very useful information which should have really been in the gpg 
release notes. However I also found that with this new version of gpg 
there is a better way to fix it. If you install the security/gpgme port 
then you don't need any of the gpg.rc stuff at all. You can replace it 
all with a single line of configuration set crypt_use_gpgme=yes.


Then it uses a much more sane internal API or something rather than 
parsing external commands.



--
Matt
___
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: gnupg pinentry

[Matt Smith]

On Dec 23 07:44, Mark Felder wrote:


It looks as though it would be feasible to write an extremely
lightweight pinentry-compatible program to depend on so we can kill the
dependency bloat and have a simple shell-based password entry option.

Anyone up for a weekend challenge? :-)


There has been another thread on this mailing list discussing making the 
port honour the WITHOUT_X11 and OPTIONS_UNSET+=X11 options from 
make.conf which would make it only depend on security/pinentry-curses 
instead of security/pinentry. This seems like a good solution to me. It 
would mean if one of those options is set it will only drag in a single 
dependancy rather than all the X11 libraries and GTK.


--
Matt
___
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: gnupg pinentry

[Matt Smith]

On Dec 22 22:33, Jonathan Chen wrote:

Hi,

Once upon a time, installing gnupg didn't require pinentry, and I
could run it quite happily on the command line. However, nowadays if I
install the port it drags in pinentry and a whole set of graphical
libraries that I don't really need on a headless box. Is pinentry
really required for gnupg to run correctly?



I believe in version 2.1.x they made entering the passphrase via 
pinentry basically mandatory and deprecated being able to do it via 
stdin methods. So it probably pulls in pinentry by default now. For 
binary packages this is unfortunatly going to default to all the front 
ends which includes ones for X. For port based source installs you can 
deselect the ones for X and only leave the ncurses one which then just 
pulls in one extra dependancy. Unfortunately that's the downside of 
binary package installs.


FYI, you can also re-enable passphrases by stdin if required by adding 
allow-loopback-pinentry to .gnupg/gpg-agent.conf and using the 
--pinentry-mode=loopback command line switch to gpg.


--
Matt
___
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: Unbound/NSD rc startup order

[Matt Smith]

On Dec 12 12:07, Mathieu Arnold wrote:

+--On 12 décembre 2014 05:00:00 -0600 Scot Hetzel swhet...@gmail.com
wrote:
| On Fri, Dec 12, 2014 at 4:15 AM, Darren Pilgrim
| list_free...@bluerosetech.com wrote
| On 12/11/2014 11:53 PM, Matt Smith wrote:
|
| Somebody has let me know that I made an obvious mistake in the above. I
| meant that the default rcorder is to run Unbound first followed by NSD.
| So to clarify I think in the default situation Unbound starts first,
| contacts NSD and gets no answer because it hasn't been started yet and
| then fails in some way.  Whereas if NSD is running first then Unbound is
| happy.
|
|
| Unbound requires SERVERS, but nsd requires LOGIN, a much later
| checkpoint.
|
| The fix would be adding an rcorder override mechanism whereby one could
| specify additional constraints (like unbound REQUIRE nsd).  If there's
| interest for this, I can see about a patch.
|
| Would it be better to add:
|
|# BEFORE: unbound
|
| to the dns/nsd rc.d script?

Well, the thing is, a resolver is required way before an authoritative
server is.



Yes. I've been thinking that maybe it's actually in the correct order 
really after all. I've worked around my particular problem by changing 
the order, but that might not be the case for everyone else.


I'm thinking now why actually do I have DNSSEC validation on my local 
intranet domain and reverse DNS anyway? I run two instances of NSD, one 
for the LAN which Unbound talks to, and one for the internet which 
everyone else talks to. It could be argued that I only need to DNSSEC 
sign the internet copies of the zones and not the LAN ones in which case 
this problem won't exist. Maybe I should just go down that route 
instead.


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

Unbound/NSD rc startup order

[Matt Smith]

Hi,

I have run Unbound and NSD for a long time and everything was working 
fine until the recent 1.5.x update for Unbound. Now if I reboot my 
server I get DNSSEC validation errors for my own local domain until I 
restart Unbound once again. I believe this is possibly related to the rc 
startup order.


My setup is that I have my local domain as an authoritative DNSSEC 
signed zone in NSD and then I use a stub-zone in Unbound which points to 
the NSD instance.  I also hard-wire the DNSSEC key for this domain into 
Unbound using a trust-anchor-file declaration.


When I rebooted my server last night this domain was failing validation 
with this error:


info: validation failure host.example.com. A IN: no DNSKEY rrset for 
trust anchor example.com. while building chain of trust


If I restart unbound again then it works fine. The default rcorder is to 
start Unbound first followed by Unbound. I'm wondering if since 1.5.x 
Unbound now attempts to read some data from the stub-zone which fails 
because NSD isn't running but then when I restart it it works 
successfully?


As a test I added nsd as a REQUIRE in the unbound rc.d script, rebooted 
again, and saw that it successfully worked as it did before I upgraded.  
It could just be an unrelated coincidence, but if it isn't I'm thinking 
the default rc order should maybe be changed for these ports?


--
Matt
___
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: Unbound/NSD rc startup order

[Matt Smith]

On Dec 11 10:51, Matt Smith wrote:

Hi,

I have run Unbound and NSD for a long time and everything was working 
fine until the recent 1.5.x update for Unbound. Now if I reboot my 
server I get DNSSEC validation errors for my own local domain until I 
restart Unbound once again. I believe this is possibly related to the 
rc startup order.


My setup is that I have my local domain as an authoritative DNSSEC 
signed zone in NSD and then I use a stub-zone in Unbound which points 
to the NSD instance.  I also hard-wire the DNSSEC key for this domain 
into Unbound using a trust-anchor-file declaration.


When I rebooted my server last night this domain was failing 
validation with this error:


info: validation failure host.example.com. A IN: no DNSKEY rrset for 
trust anchor example.com. while building chain of trust


If I restart unbound again then it works fine. The default rcorder is 
to start Unbound first followed by Unbound. I'm wondering if since 
1.5.x Unbound now attempts to read some data from the stub-zone which 
fails because NSD isn't running but then when I restart it it works 
successfully?


As a test I added nsd as a REQUIRE in the unbound rc.d script, 
rebooted again, and saw that it successfully worked as it did before I 
upgraded.  It could just be an unrelated coincidence, but if it isn't 
I'm thinking the default rc order should maybe be changed for these 
ports?


Somebody has let me know that I made an obvious mistake in the above. I 
meant that the default rcorder is to run Unbound first followed by NSD.  
So to clarify I think in the default situation Unbound starts first, 
contacts NSD and gets no answer because it hasn't been started yet and 
then fails in some way.  Whereas if NSD is running first then Unbound is 
happy.


--
Matt
___
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: Why was ispell removed?

[Matt Smith]

On Dec 01 13:58, Stephen Fisher wrote:
 I recently noticed that the ispell port has been removed in favor of the 
 aspell-ispell port (ispell compatibility script for aspell).  Does 
 anyone know why it was removed?  All I see on Fresh Ports is that it 
 was deprecated and finally removed in January of this year.  
 
 (The ispell script for aspell doesn't fully replicate ispell 
 functionality such as checking words on the command line as shown below)
 
 Real ispell:
 ispell
 @(#) International Ispell Version 3.3.02 12 Jun 2005
 word: word
 ok
 
 
 word: ^D
 
 
 
 aspell script:
 ispell
 Ispell compatibility script for Aspell.
 Usage: /usr/local/bin/ispell [options] -a|-l|-v[v]|-c|-e[1-4]|file

It seems that you can just use the -a switch on aspell:

$ aspell -a
@(#) International Ispell Version 3.1.20 (but really Aspell 0.60.6.1)
helo this is a tset
 helo 11 0: he lo, he-lo, hello, helot, help, halo, hell, held, helm,
hero, he'll
*
*
*
 tset 5 15: test, stet, Set, Tet, set

It seems to do exactly the same as hunspell like you have been pointed
to in the rest of this thread?

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