Re: Changing daemon user, dir ownership and updating packages

[Dewayne Geraghty]

On 26/04/2021 6:03 pm, Stefan Bethke wrote:
> But that still leaves pkg updating the ownership/mode of existing directories 
> as a surprise on updating a package. I think the "right" thing here would be 
> a kind of three-way merge between changes an updated package brings in vs. 
> changes the user has made on their system. 

Sometimes the right thing isn't easy ;)

There are some cases where I explicitly assign ownership and more
restrictive modes to installed ports.  Would "pkg add -I" prevent file
ownership/mode changes or just prevent the execution of installation
scripts... (hint for a flag to prevent file mode/ownership changes on
existing systems)

I suspect Gleb's paradigm of a separate file to explicitly control file
attributes (after upgrades) is reasonable, but this is problematic and
negates the value of a packaging system.
___
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: Specific svn/git package update use case

[Dewayne Geraghty]

On 4/04/2021 12:30 pm, Simon Wright wrote:
> Hi all,
> 
> I've been following the discussion about the git upgrade to the ports
> repro but am not clear about how it impacts my use case.
> 
> At the moment I track ports on the revision that the Freebsd build
> cluster uses to build the "latest" package set. I take the currently
> reported latest build revision number from Poudriere on the appropriate
> package build box, update my ports tree to that revision using svn on a
> Debian box then use the resulting port tree to build my few ports and
> dependencies locally with somewhat different build options from default
> then export the resulting package set to my local machines. This process
> has been working satisfactorily for several years now. My systems are
> always running the same package set as "latest".
> 
> My question is: is the poudriere build process going to change and will
> the build cluster still report the latest build in a form that I can
> feed to git on Debian to update my ports tree to the same level as the
> Freebsd package server?
> 
> As of today I am still seeing the Latest build version on
> http://beefy6.nyi.freebsd.org/jail.html?mastername=122amd64-default/
> reported as svn revision 569609 and updating my ports using svn works.
>

Unfortunately svn is frozen at
Revision: 569609
which I'm sure will disenfranchise some.

I'd suggest that you search this mail-list for
"Re: I run poudriere - what do I need to do once ports switch over to git?"
Though it is not something we use.

This may help https://wiki.freebsd.org/git
specifically https://github.com/lwhsu/freebsd-git-docs/blob/main/URLs.md

The reason(s) for moving to git are described here
https://github.com/bsdimp/freebsd-git-docs/

I've also found Ed Maste's email "Proposed ports git transition
schedule" helpful.


> My apologies if I've missed this in the discussion or referenced docs
> and thanks for any guidance or pointers.
> 
> Simon Wright.
> ___
> 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: No update for a day on ports?

[Dewayne Geraghty]

On 1/04/2021 6:19 pm, Herbert J. Skuhra wrote:
> https://wiki.freebsd.org/git
> 
Thanks Milan for bringing this to everyone's attention.

Would appreciate if anyone can provide insight as to the 4 git commands
that I need to function, in a manner similar to the way I use svnlite
use.  Git equivalents for:

svnlite update /usr/ports
svnlite update -r '{$-$MM-$DD}' /usr/ports/$category/$port
svnlite log -l $N /usr/ports/$category/$port
svnlite diff /usr/ports/$category/$port

I'm sure many other users would have a similar usage (and similar
non-knowledge of git)

Is this
git clone -o freebsd --config
remote.freebsd.fetch='+refs/notes/*:refs/notes/*'
https://git.freebsd.org/${repo}.git
really the equivalent of
svnlite update /usr/ports
I have a few changes to the infrastructure that I don't want to loose by
overwriting those changes.

As a minor aside, has anyone stated the reason why the user-base of base
or ports are moving to git?  (And its greatly appreciated that 12-stable
will continue to feed svn as it provides an opportunity for users to
migrate to, what for many, is new)

Kind regards, Dewayne.
PS We use ports to build, no remote packages (since FreeBSD 4).
___
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: Python 2.7 removal outline

[Dewayne Geraghty]

On 26/03/2021 9:25 am, George Mitchell wrote:
> On 3/25/21 6:06 PM, Miroslav Lachman wrote:
>> [...]  it is really not for
>> everybody to use overlays in current state (overlays are poor
>> documented at least).
>> [...]
> 
> Until this thread I had never heard of them.  -- George
> 
Yes me too. poudriere isn't on our radar so its another layer of
complexity entering the build fray.
___
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: Python 2.7 removal outline

[Dewayne Geraghty]

On 25/03/2021 4:01 am, Miroslav Lachman wrote:

> I really appreciate the work of ports team, committers and maintainers
> but I dislike double standards. All ports requiring Python 2.7 were
> marked deprecated the last year almost all of them removed according to
> expiration date 2020-12-31 but some of them are still there.
> If there is Python 2.7, if there is Chromium then any of removed ports
> can be there. If "we" want to get rid of them then "we" should remove
> all of them and not just some by sentiment.
> For example Iridium browser was removed because of Python 2.7 but
> Chromium is still there. They are both based on the same source with the
> same dependencies but Iridium cares more about privacy, yet it was
> slaughtered instead of Chromium.
> I really would like to see some policies for things like this next time.
> 
> Miroslav Lachman

Thanks Miroslav, I have the same view.  Though I agree with Rene about
the need to remove vulnerable ports and the interests of the FreeBSD
community, its worth considering those with both a need and an
understanding of the ramifications of using python2.7.

We've been disappointed having to digress from the ports infrastructure
to continue with python2.7 applications that we need, which were removed
(a year ago).  It could've been so much more pleasant had a
"restricted", or better option been employed.

No new ports requiring python2.7 is an excellent suggestion in terms of
maintaining a viable user-base (kudos Mathias).  For how long, is
another discussion.

Though after reading through
https://reviews.freebsd.org/D28665
are we expecting to keep KDE users on FreeBSD post June 23 (without
www/qt5-webengine, konqueror, kontact, kmail,...)?

And its incongruous to say talk about upstream abandoning applications,
as many continue to maintain "their" software with a now unsupported
product (py2.7).  Again the need outweighs the risk (for us) vs the
upstream cost of conversion.  It is an unpleasant though necessary  choice.

And for the fear-mongers, with a good FreeBSD firewall and strong
security mindset, vulnerabilities can be substantially mitigated; and it
really should be an option (for experienced folk) to be able to use what
is *needed* while properly comprehending the risk vs maintaining an
increasingly digressive ports infrastructure.
___
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: Warning: Major OS version upgrade detected

[Dewayne Geraghty]

A while ago, due to mismatching ABI, I had to insert into:
/usr/local/etc/pkg.conf
ABI = "freebsd:12:x86:64";
Perhaps explicitly stating "freebsd:13:x86:64"; may help?
BUT this will require maintenance. :/


___
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: STOP rust!

[Dewayne Geraghty]

On 11/11/2020 12:24 am, Rozhuk Ivan wrote:
> Hi all!
> 
> With latest ports tree librsvg2-rust-2.50.0 is required to some ports.
> It want replace librsvg2-2.40.21.
> 
> I do not want build ugly rust during hours to build small lib in less than 
> minute.
> 
> 
> Same with polkit & spidermonkey.
> https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/35
> 
> I remove polkit where it is possible.
> ___
> 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"
> 

Good question Rozhuk, I've had a similar "problem" elsewhere.  The
workaround is to force your applications to break from the normal
maintenance/updating process.  There are two methods:

1. Lets say the upstream port that now wants to use librsvg2-rust-2.50.0 is
/usr/ports/risky/business

You'll need to modify
/usr/ports/risky/business/Makefile
to depend on librsvg2 and not librsvg2-rust

OR
2. You'll need to revert the port risky/business, everytime you perform
a /usr/ports update.

(Lookup svnlite help, or use something like
svnlite update /usr/ports
svnlite update -r '{2020-11-01}' /usr/ports/risky/business
the order is important)

Keep a record of which option you've chosen because you'll eventually
want to return to the normal way of doing things, because port
maintainers track the status of their ports - for security, feature and
bug updates and generously do the work for you.  (svnlite diff
/usr/ports may be helpful, unless you accidentally accept differences ;) )

The more promising approach is, as Yuri suggests, take up the issue with
the librsvg2 team.  However I've observed that when a downstream project
team invest in migrating to new tools, they're unlikely to rescind that
decision.

You'll also need to track the interaction of up/downstream tools because
eventually something will require a new feature in librsvg2 2.50+

Tough call, but the flexibility of the ports system helps.
___
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: Using gcc as a build dependency only

[Dewayne Geraghty]

On 11/11/2020 7:55 am, Bob Eager wrote:
> I have a port that, for reasons I won't go into, I build with gcc.
> 
> It all works fine with USE_GCC= yes - no problem.
> 
> The issue is that it's a build dependency and a run dependency. So
> anyone wanting to use it has to install gcc, and is discouraged because
> (a) it's big and (b) it drags in other stuff.
> 
> Presumably this is because it needs the gcc runtime, but I'm not sure.
> And I can't see a runtime package that parallels the compiler.
> 
> Can anyone comment on this? And please don't say 'convert to clang'
> because that isn't possible, at least not yet.
> ___
> 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"
> 

Hi Bob, I have faced the same dilemma.  The process I use is to:
Install (tar) only the gcc files needed, usually
libstdc++.s*
libgcc_s*

You might need to consider the other tools that gcc uses (like
math/{gmp,mpc,mpfr}

and then add to /usr/ports/Mk/local.mk, I append:
RUN_DEPENDS:=${RUN_DEPENDS:Ngcc*}
BUILD_DEPENDS:=${BUILD_DEPENDS:Ngcc*}
I also have, but I'm unsure if this is still required
LIB_DEPENDS:=${LIB_DEPENDS:Ngcc*}

I hope someone has a better way?
Regards.
PS All my build, install, update processes are automated; so you'll need
something to track gcc (and friends) updates.
___
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 are my options regarding deprecated PyPy port?

[Dewayne Geraghty]

On 26/08/2020 7:12 am, figosdev via freebsd-ports wrote:
>> the easiest way, if you build your own ports, is to svnlite update -r 
>> '{2020-03-29}' /usr/ports/security/w3af Note the date before removal from 
>> the ports tree.
> 
> Thanks, this is probably what I was looking for (a way to get a copy of the 
> existing work if ports deletes it).
> 
You're welcome :)

> Forgive my lack of experience here-- does this imply that when something is 
> "deleted" from ports-- it is like an edit in git or Wikipedia, where the old 
> version still (typically) exists in the tree somewhere? Because if a year 
> from now I can still get the old ports code from the older tree, that's good 
> enough for me.
> 

I can't speak to git or wikipedia, but I use this technique for ports
that go back to 2018-12-14.  So you should be ok for awhile, perhap a
ports infrastructure person can illuminate.  Though frankly, I keep
copies of all local tree changes against a pristine copy of the ports
tree ("diff -urN" is useful)

You should be aware that the mailing list(s) has mentioned a move to
git, and there is an intention to retain the svn feed, so we should be
fine for the foreseeable.  Also mentioned was a transition guide...

> I also got the downloadable Linux ELF pre-compiled version from pypy.org to 
> run in Linuxulator-- this has me covered for most of the stuff I do with 
> Python, though for GUI stuff it doesn't seem to like the libc in /compat or 
> the one I copied (a point for another list, but for me this solves most of my 
> issue.)
> 

A bit unfortunate that you need to, though its a resilient workaround :)

> Same GUI stuff runs on the native PyPy. I'm hoping the PyPy devs find a way 
> to make this work, I intend to ask them if they can make a FreeBSD download 
> again. They did one for FreeBSD64 a long time ago.
> 
Yes, the best way is to try to get the upstream folks to modify their
code for python3.  Though if the dev doesn't want to, you (we) need to
make a calculated risk determination, as I've found with a few very
useful applications (ports).

And as a general rule, I'd suggest avoiding unmaintained ports that
enable inbound network access.
Cheerio.
___
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 are my options regarding deprecated PyPy port?

[Dewayne Geraghty]

On 25/08/2020 11:49 am, figosdev via freebsd-ports wrote:
> Hi, I'm new to FreeBSD-- I installed it for the first time this week. 
> Honestly, so far it has exceeded expectations.
> 
> I installed X11, but the first thing I installed was PyPy2.
> 
> Unlike CPython2, which is EOL'd, PyPy2 does not to the best of my knowledge 
> depend on CPython. When I installed it with pkg, it said the port was 
> deprecated and will be removed from ports soon-- but it also said it was 
> based on Python 2.7 (which is EOLd).
> 
> I think there is a misunderstanding there. PyPy states the intention to 
> continue to maintain that version.
> 
> Removing this port is unnecessary. Aware of the politics around this (which 
> go way over FreeBSD anyway) I doubt I will convince someone to save this 
> port, sadly.
> 
> I've used both Python 2.x and 3.x for years now. If this problem can't be 
> fixed, can I at least be put in touch with the current port maintainer so 
> that I can learn how to maintain this as a 3rd party package for my own use?
> 
> I'm certain I'm not up to becoming an official port maintainer at this stage, 
> but I'd like to be able to at least compile and run PyPy2 on freebsd without 
> redoing the ports work that was already done on this.
> ___
> 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"
> 

Hi figodev, I've had a similar experience.  Though in my case
security/w3af was removed, per

/usr/ports/MOVED:security/w3af||2020-03-31|Has expired: Uses deprecated
version of Python

So in my case the easiest way, if you build your own ports, is to

svnlite update -r '{2020-03-29}' /usr/ports/security/w3af
Note the date before removal from the ports tree.

You might consider the same action.  Though over time you will need to
self-maintain...
___
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/py-html5lib with FLAVOR=py27 failed to build

[Dewayne Geraghty]

On 27/07/2020 4:34 pm, Kubilay Kocak wrote:
).
> 
> The strategy, plan and execution for deprecation of Python 2.7 and the
> guidelines for deprecation and removal of Python 2.7 ports was not
> coordinated with, discussed with or executed by the Python team, as it
> should have been.
> 
> The issues associated with this as well as the impact it has had on the
> team, maintainers and and users has already been reported to core as one
> set of example symptoms that form part of a broader report.
> 
> Python is more than happy to address the issues associated with that
> plan. I encourage and welcome interested developers, users, maintainers
> who want to participate in improve the situation to join #freebsd-python
> on freenode.
> 
> 
> -- 
> koobs
> @Python
> 
> 
> 
> ___
> 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"
> 

Thank-you Stefan I couldn't agree more.  I use security/w3af for web
scanning and have pursued upstream, but it was zapped from the ports
infrastructure around March.

Koobs sharing the perspective of @python is very much appreciated.  I
recall a time when changes to a "port" was the responsibility of the
maintainer.

Unfortunately python2.7 dependent ports are removed or scheduled to be
removed outside the actual python2.7 EOL window, which is rather
inexplicable.  The EOL tyranny is significantly detrimental to FreeBSD's
reputation as many well used, and in some cases necessary ports do not
have an upgrade to 3.X plan.  And yes, we should apply pressure
upstream, but taking the ports away isn't "user" friendly; sans there
being a significant security issue. :)

I lament new users who decide to build ports only to find that they've
been removed or marked broken due to download relocation.  I would've
thought that a FreeBSD distribution site would retain and contribute to
 FreeBSD being a pleasurable experience.  Sadly I digress.

___
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: RFD: proposed new (likely virtual) category, education

[Dewayne Geraghty]

On 18/07/2020 1:09 pm, Pau Amma wrote:
> This category would comprise ports that are mainly educational in nature
> or purpose, such as:
> - course-writing or course-delivery applications,
> - classroom or school management applications (eg, scheduling classes),
> - applications, utilities, or games primarily or substantially designed
> to help the user learn a specific topic or study in general, like typing
> tutors, flashcard applications, or educational games.
> 
> This category would be useful because some of these applications are in
> non-obvious categories, making them hard to find if you don't already
> know about them. For instance, if I had not already known about anki or
> mnemosyne, I don't think it would have occurred to me to look for them
> under games.
...
> 
> Observant readers will notice that there are 10 misc/* ports in that
> category. I do not, however, know whether that is enough to justify
> making it a physical category with all the additional work involved.
> 
> Things that would need to be changed if that proposal is accepted:
> - The Makefiles for all these ports
> - The section on port categories of the Porter's Handbook
> - Possibly other things I'm missing
> 
> All comments or constructive criticism gratefully accepted.
> ___

Great idea Pau!

You might like to add www/sakai though its quite dated (ports is 10.2;
current version 20.1)
___
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: State changes via pkg's scripts

[Dewayne Geraghty]

On 8/07/2020 5:23 pm, Baptiste Daroussin wrote:
> On Wed, Jul 08, 2020 at 04:32:34PM +1000, Dewayne Geraghty wrote:
>> Is there a more convenient method to examine a package's scripts than
>> unpacking the manifest file and
>> # cat +MANIFEST | jq -rM '.scripts'
>> ?  As I'd like to know what changes will, or have been applied.
> 
> pkg info --raw-format json -R yourpkg | jq -rM '.scripts'
> 
> So far noone added a better interface yet, it should not be difficult to add
> 
> Best regards,
> Bapt
> 
Unfortunate.  Thank-you, that is helpful.
Kind regards, Dewayne.
___
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: State changes via pkg's scripts

[Dewayne Geraghty]

On 8/07/2020 4:52 pm, Dave Horsfall wrote:
> On Wed, 8 Jul 2020, Dewayne Geraghty wrote:
> 
>> # cat +MANIFEST | jq -rM '.scripts'
> 
> Sorry, but this always pushes one of my buttons.  When using "cat file |
> proc"
> what's wrong with "proc < file"?
> 
> -- Dave

Almost answered the question.  :)

I was being explicit (and mentally lazy) though saving an extra three
characters is better. ;)
___
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"

State changes via pkg's scripts

[Dewayne Geraghty]

Is there a more convenient method to examine a package's scripts than
unpacking the manifest file and
# cat +MANIFEST | jq -rM '.scripts'
?  As I'd like to know what changes will, or have been applied.

For example to review the dependencies of a file
# pkg info -d -F  /packages/K8/All/samba410-4.10.15.txz provides an
indication of what is going to be installed.

I'd searched the man pages of pkg-info and pkg-query.

Cheers, Dewayne.
___
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 failing with -fno-common with clang 9/gcc 9

[Dewayne Geraghty]

On 24/06/2020 7:00 am, Kyle Evans wrote:
> On Mon, Jun 22, 2020 at 1:35 AM Tobias Kortkamp  wrote:
>>
>> On Thu, Apr 30, 2020, at 14:56, Kyle Evans wrote:
>>> In any event, I would urge folks to be proactive and identify this
>>> stuff, reporting issues upstream and spreading awareness of the
>>> impending default change for those projects that may not already be
>>> actively aware.
>>>
>>> On a closing note, I'm just going to kinda drop these patches here for
>>> anyone that's willing/able to help make this a collective effort to
>>> identify/fix/report problems here; they backport the default
>>> -fno-common patch from future-LLVM11 to the base system compiler on a
>>> system near you:
>>>
>>> HEAD: https://people.freebsd.org/~kevans/llvm-fnocommon-head.diff
>>
>> Can you ask for an exp-run with this patch applied?  There needs
>> to be a comprehensive list of failing ports for people to be able
>> to work on this.  We see some failing ports because of default
>> -fno-common in GCC 10 [1] already.
>>
>> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246700
> 
> I can, but my only problem in doing so is that I cannot take
> responsibility for following up on the issues discovered. I have some
> outstanding exp-run that I've dropped the ball on, I'm a bit wobbly on
> personally requesting one for this unless some group of people
> can/will offer to make sure the issues are fixed so that the exp-run
> can actually be completed in a reasonable timeframe.
> 
> Thanks,
> 
> Kyle Evans
> ___
> 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"
> 

Kyle, at best the maintainers should be advised to either:
1. add CFLAGS+=-fcommon to their problematic port's Makefile
2. pursue their respective upstream to address the issue as its going to
"endemic" once clang10+ and gcc10+ become widespread.

I don't see this as a problem for you alone to carry.

I built all my ports using -fno-common in make.conf, and added
CFLAGS+=-fcommon to the problem ports.  It can be a simple fix, or you
could apply the same kind of patching (llvm-fnocommon-head.diff) to
gcc10+ and llvm10+ in ports to delay "the problem" being experienced for
FreeBSD folk, but... (in my view, -fno-common is a good thing)

PS if I had a send-pr functionality, I would've happily raised the 47
PR's (of the 1400+ ports built/used) ;)
___
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: cups-pdf crash status -139

[Dewayne Geraghty]

I suspect that you've set your locale incorrectly.  You might like to
try (what I think you're trying to use)
/usr/share/locale/en_US.UTF-8
instead of, what the ktrace is using, which is:
/usr/share/locale/en_US.UTF8
An easy mistake ;)

On 18/06/2020 12:04 am, Per olof Ljungmark wrote:
> On 2020-06-17 11:23, Michael Gmelin wrote:
>>
>>
>> On Wed, 17 Jun 2020 09:43:35 +0200
>> Per olof Ljungmark  wrote:
...
> 59594: write(5,"D [16/Jun/2020:11:43:18 +0200] c"...,130) = 130 (0x82)
> 70204:
> open("/usr/share/locale/en_US.UTF8/LC_TIME",O_RDONLY|O_CLOEXEC,015533671400)
> ERR#2 'No such file or directory'
> 59594: kevent(3,0x0,0,{ 9,EVFILT_READ,0x0,0,0xdb,0x803ed55e0 },469674,{
> 1.0 }) = 1 (0x1)
> 70204: write(2,"DEBUG: cgiSetArray: job_printer_"...,59) = 59 (0x3b)
> 59594: read(9,"cgiSetVariable: TOTAL="1"\nDEBUG"...,2047) = 278 (0x116)
> 70204: write(2,"DEBUG: cgiSetArray: job_printer_"...,68) = 68 (0x44)
> 59594: write(5,"D [16/Jun/2020:11:43:18 +0200] ["...,65) = 65 (0x41)
> 
> ___
> 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: jitsi documentation

[Dewayne Geraghty]

Well considered experienced-based guidance, clearly written and well
explained, an excellent document assembling all the required pieces. I
look forward to deploying.

Perhaps with an additional note about your usage experience, this would
be a good article for the FreeBSD Journal? (or at least an addition to
https://www.freebsd.org/docs/books.html, as is?)

Though like so many things, its a choice point should I stay with
ejabberd (since 2010) and fiddle, or jump to prosody...

Thank-you Bob,
Regards.

On 30/05/2020 7:26 am, Bob Eager wrote:
> First, thanks to all who worked on this port. I looked at this a while
> ago and was totally confused by it all!
> 
> I have installed jitsi in a FreeBSD jail and it works very nicely. I
> wrote down what I did so that I could do it again in rather less time.
> Then I got a bit carried away.
> 
> What resulted was a detailed document on how to set it all up - and a
> few other bits. It might be useful to others.
> 
> See http://www.bobeager.uk/jitsi.html for details.
> ___
> 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: FreeBSD Port: open-vm-tools-11.0.1_3,2

[Dewayne Geraghty]

Suggest that you add to make.conf
DISABLE_VULNERABILITIES=yes


On 5/05/2020 8:08 am, Kurt Buff - GSEC, GCIH wrote:
>  All,
> 
> Has been done?
> 
> I just built a new machine on our VMware cluster and tried to install this
> from ports on 12.1-RELEASE-p3 with an updated tree, and it complained about
> a dependency:
> 
> ===>  python27-2.7.17_1 has known vulnerabilities:
> python27-2.7.17_1 is vulnerable:
> Python -- Regular Expression DoS attack against client
> CVE: CVE-2020-8492
> WWW:
> https://vuxml.FreeBSD.org/freebsd/a27b0bb6-84fc-11ea-b5b4-641c67a117d8.html
> 
> Thanks,
> 
> Kurt
> 
> On Wed, Apr 29, 2020 at 2:11 PM Dutchman01 via freebsd-ports <
> freebsd-ports@freebsd.org> wrote:
> 
>> Hi, new maintenance release is out,
>>
>> this port could use an upstream release.
>>
>>
>>
>> Can you please upgrade the port?
>>
>>
>>
>> Ty , regards,
>>
>> dutchy
>>
>> ___
>> 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"
> 

___
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: Bind 9.16 port error still lingers

[Dewayne Geraghty]

I think a few people have given the advise that you should look at the
placement of your pid file.  I don't know what the default is, but I have
 pid-file   "/var/run/named/pid";
in my named.conf file.  This ensures that I'm able to successfully run
named as the bind user and the pid file is going to be where I expected
it to be (it probably moved 20 years ago ;) ).

As I'm running named as user bind, then I need to write to /var/run as
bind.  I can't write to /var/run, because /var/run has root:wheel
ownership and 755 protection.   So you might need to:

1. mkdir /var/run/named
2. chown bind:bind /var/run/named
3. chmod 750 /var/run/named
4. stop named
5. rm /var/run/named.pid (if its still there)
6. start named

I note that you received almost immediate suggestions from those
concerned about the security of your systems, which is very comforting.  :)

Regards, Dewayne.
PS I appreciate your frustraction, I think that the removal of expired
ports is a little too enthusiastic


On 3/05/2020 12:05 am, The Doctor via freebsd-ports wrote:
> ...

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

Ports failing with -fno-common with clang 9/gcc 9

[Dewayne Geraghty]

As -fno-common will become the default in gcc10/llvm11 per
https://lists.freebsd.org/pipermail/svn-src-stable-12/2020-April/004761.html

I thought I might share the list of ports that failed to build for
maintainers to be aware of using -fno-common:

archivers/arc
benchmarks/iozone
benchmarks/netperf
databases/gdbm
databases/libmemcached
databases/pgpool-II-40
databases/postgresql11-client
databases/postgresql11-server
devel/gnustep-make
devel/libunwind
graphics/freeglut
lang/erlang
lang/gnustep-base
lang/libobjc2
lang/yap-devel
mail/isoqlog
mail/spamilter
net-mgmt/argus3
net-mgmt/argus3-clients
net-mgmt/iftop
net-mgmt/nagios4
net/fping
net/isc-dhcp44-client
net/isc-dhcp44-relay
net/isc-dhcp44-server
net/socat
net/ss5
net/tableutil
ports-mgmt/pkg
security/gnupg1
security/openvas9-manager
security/openvpn-auth-ldap
security/ossec-hids-local
security/ossec-hids-server
security/snort
security/suricata
sysutils/LPRng
sysutils/logrotate
sysutils/lsof
sysutils/mpiexec
www/squidguard
www/webalizer

I'm sorry this is a small list but I only use 1488 ports.
___
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"

python 2.7 marked as deprecated and EOL while 2.7.18 RC is available

[Dewayne Geraghty]

Its very confusing building ports at the moment.  At https://www.python.org/
there is a release candidate for 2.7.18, while our python 2.7 has been
marked as deprecated with an expiration date.  Can the Expiration Date of
2020-12-31 be retracted?

It appears that devel/scons, at least, requires python 2.7 to run; though
it builds with 3.7.
Regards, Dewayne.
___
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"

Mk/Uses/gnustep.mk uses incorrect GNUSTEP_LOCAL_LIBRARIES

[Dewayne Geraghty]

I'd raise a PR but Mk is immune.

The problem:
devel/sope4 failure to build due to:
ld-elf.so.1: Shared object "libgnustep-base.so.1.26" not found, required by
"plmerge"

Investigation:
#  make -C /usr/ports/devel/sope4 -VGNUSTEP_LOCAL_LIBRARIES
/usr/local/GNUstep/Local/Library/Libraries

# ls /usr/local/GNUstep/Local/Library/Libraries
#

# ls /usr/local/GNUstep/System/Library/Libraries/
Javagnustep-base
 libgnustep-base.so.1.26
Resources   libgnustep-base.so
 libgnustep-base.so.1.26.0

Due to /usr/ports/Mk/Uses/gnustep.mk
GNUSTEP_LOCAL_LIBRARIES=  ${GNUSTEP_LOCAL_ROOT}/Library/Libraries

GNUSTEP_LOCAL_ROOT=   ${GNUSTEP_PREFIX}/Local

The fix:
Change /usr/ports/Mk/Uses/gnustep.mk
GNUSTEP_LOCAL_LIBRARIES=  ${GNUSTEP_SYSTEM_ROOT}/Library

-- 
*** *NOTICE *This email and any attachments may contain legally privileged
or confidential information and may be protected by copyright. You must not
use or disclose them other than for the purposes for which they were
supplied. The privilege or confidentiality attached to this message and
attachments is not waived by reason of mistaken delivery to you. If you are
not the intended recipient, you must not use, disclose, retain, forward or
reproduce this message or any attachments. If you receive this message in
error please notify the sender by return email or telephone, and destroy
and delete all copies. ***
___
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: FLAVORS for Ruby

[Dewayne Geraghty]

Bottom line: flavors came into being to satisfy specific needs.  Python 2
underwent substantial changes during the upgrade to python 3, to the extent
that many (most) python applications would cease to function.  Similarly
php5 to php7.  Without flavours the user-base would've been severly
impacted during the upgrade transition where some fraction of their
applications would fail.  Flavours, though I didn't appreciate it at the
time, was/is a really smart move and has saved most of us contorting our
systems  with different versions of the "same" software

I suppose if the ruby developers make such a substantial change to the
language that applications break, then adding flavors to ruby might be
worthwhile.  As stated, there is substantial effort required and the need
significant.  And as I still have "ports" that use python2 (though most use
python3), I greatly appeciate their effort.

Is there a specific issue, ie breakage requiring ruby flavors?
___
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: Welcome flavors! portmaster now dead? synth?

[Dewayne Geraghty]

On 5/12/2017 10:43 AM, Tatsuki Makino wrote:
> By the way, where is the clever way to update to flavor?
> I am using portmaster.
> ___
> 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"
>
This might give you a clue. 
(1) https://svnweb.freebsd.org/ports?view=revision=455210

Though after the apparent confusion with ansible from Nov 30, I think
I'll wait for the infrastructure developers to provide guidance
Refer:
(2) https://svnweb.freebsd.org/ports/head/sysutils/ansible/Makefile?view=log

Full marks to introducing python flavors as it should serve to iron out
the flavor problems. 

Unfortunately it appears that we need to build multiple versions of,
say, python when you only NEED to run 2.7 refer to (1) above?  It used
to be that the ports team recommended when users should update python,
php, etc and the ports suite would head in that direction.   Its an
uncomfortable prospect - *maintaining* multiple versions of the same
language on a production platform...



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

Default option changes-lacking explanation

[Dewayne Geraghty]

It would be very helpful if maintainers could add an explanation for the
changes to default options that they make. 

For example freeradius3 recently added heimdal and updfromto as default
options to the build without any reason in either the maintainer's (svn)
log nor in UPDATING.  As a suggestion:

  * Improved Kerberos support. Added MIT krb as an option. Heimdal base
now defaults to ON.
  * udp_fromto enables specification of source address, helpful on
multi-homed devices. Default is now ON

I'm sure there are a lot of administrators that would like to have
consistency in their builds/installs, even if they regularly have to
review the log files to find it.  This is not to take away the valuable
work that maintainers contribute to the project, only that a little more
communication of changes that do affect people will help them to prepare
pro-actively their builds.

Regards, Dewayne.

PS And Zi, thankyou for modernising the Makefile and adding MIT Krb.

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

How to force defaulting to heimdal port - a surprise from postgresql96 using base

[Dewayne Geraghty]

Just noticed that the postgresql96-server options
HEIMDAL_KRB5 MIT_KRB5
were removed, 11 days ago.  (They were inherited options defined in
postgresql92)

How do I tell /usr/ports/Mk/Uses/gssapi.mk that only the heimdal port
should be used, in the general sense - for all ports.

Ideally what I would like to do is to tell those ports that I want
kerberos to be used, to only use heimdal port; and preferably with the
bootstrap option to correctly set the build,run dependencies. Something
like:
GSSAPI_HEIMDAL_USES=gssapi:heimdal,bootstrap or
USES=gssapi:heimdal,bootstrap
and in some cases
GSSAPI_HEIMDAL_USES=gssapi:heimdal,bootstrap,flags
depending on how the Makefile is used.

In the absence of a DEFAULT_VERSIONS+=gssapi=heimdal|mit|base (ie
DEFAULT_VERSIONS+=ssl=openssl equivalence).  Would the creation of
/usr/ports/*/*/Makefile.local
that only contains
USES+=gssapi:heimdal,bootstrap
GSSAPI_HEIMDAL_USES=gssapi:heimdal,bootstrap
be the best solution, for all the ports I need to use kerberos?

But two questions arise:
1. How does the ports system process variables in USES?
2. If its a "first found" in the list, is there a way to prepend what is
required to the USES variable?

I would appreciate advise/help as to how I can reliably use the heimdal
port. 
Dewayne

___
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: how to build mpich with gcc?

[Dewayne Geraghty]

___
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: Configuring options/knobs without `make config`

[Dewayne Geraghty]

Oops.  I forgot to mention that you would use portmaster this way
/usr/local/sbin/portmaster -m "commands to pass" $CATEGORY/$PORT
which I use for other tasks, as explained earlier.
For example
portmaster -m 'WITH="SQLITE LDAP" WITHOUT="DIGEST IPV6"' $CAT/$PORT

Note: -m "" can not be issued multiple times on the command line.

___
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: Configuring options/knobs without `make config`

[Dewayne Geraghty]

Richard,
I'm unsure of how you're planning on using the information, perhaps
these suggestions may help:

To examine what options are available, chosen or rejected (note: the
value of CATEGORY and PORT must be in lowercase):
make -C /usr/ports/$CATEGORY/$PORT -VPORT_OPTIONS -VSELECTED_OPTIONS
-VDESELECTED_OPTIONS

If you're after consistency, then I would suggest that you use
/etc/make.conf to ascribe the options that you want for each of the ports.

For example, using mail/dovecot2:
mail_dovecot2_SET=LZ4 KQUEUE SSL
mail_dovecot2_UNSET=BDB PGSQL

I'll reiterate that I don't interactively set port options on anything,
so no "make config".  I use a tool called ports-mgmt/portconf to manage
my ports. I can't recommend the tool as I do some preprocessing to align
with port devs requirements, currently
$CATEGORY_$PORT_[SET|UNSET]=
if in /etc/make.conf or on the command line by
[WITH|WITHOUT]=

Enjoy.
Dewayne
___
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: NEW APR/APR-Utils

[Dewayne Geraghty]

Rightly or wrongly I haven't tested with apr-1.6.  I pretty much adhere
to the versions within /usr/ports.  Only when there's a CVE do I break
ranks - and usually after I've filed a PR for the (security) issue to be
addressed.

Sometimes the maintainers' need to have their attention drawn to
available updates, which benefits everyone.

Unfortunately the PR mechanism is the only tracking mechanism (or poker,
depending on your perspective) available to us.

___
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: NEW APR/APR-Utils

[Dewayne Geraghty]

Andre,
I've been down this path a few times and Bernard (who looks after
most/all? things related to libressl) does a great job in supporting
people like us that build our own packages.

Out of frustration of build failures, I applied the patch below, please
pay attention to line-breaks.

This isn't the best solution as the patches to individual ports as a
place holder until the upstream devs do things properly, is the best
course.  I build 1057 ports (for server use only) successfully, including
-rw-r--r--  1 root  wheel   473K Jun 18 19:21
/usr/packages2/K8/All/apr-1.5.2.1.5.4_2.txz ; # libressl


Index: /usr/ports/security/libressl/Makefile
===
--- /usr/ports/security/libressl/Makefile   (revision 444004)
+++ /usr/ports/security/libressl/Makefile   (working copy)
@@ -13,6 +13,7 @@
 LICENSE_FILE=  ${WRKSRC}/COPYING

 CPE_VENDOR=openbsd
+CFLAGS+="-O3"

 OPTIONS_DEFINE=MAN3 NC
 OPTIONS_DEFAULT=   MAN3 NC
@@ -35,8 +36,17 @@
 INSTALL_TARGET=install-strip
 TEST_TARGET=   check

+pre-configure:
+.if ${ARCH} == "amd64"
+   @${REINPLACE_CMD} -e '/define
OPENSSL_VERSION_NUMBER/s|OPENSSL_VERSION_NUMBER.*|OPENSSL_VERSION_NUMBER
0x100020bfL|1' ${WRKSRC}/include/openssl/opensslv.h
+.endif
+
+# pre-install:
 post-install:
${RM} -r ${STAGEDIR}/${PREFIX}/etc/ssl/cert.pem
+.if ${ARCH} == "amd64"
+   @${REINPLACE_CMD} -e '/define
OPENSSL_VERSION_NUMBER/s|OPENSSL_VERSION_NUMBER.*|OPENSSL_VERSION_NUMBER
0x100020bfL|1' ${STAGEDIR}${PREFIX}/include/openssl/opensslv.h
+.endif

 post-install-NC-on:
${INSTALL_MAN} ${WRKSRC}/apps/nc/nc.1
${STAGEDIR}/${PREFIX}/man/man1/nc.1

This should get you over the hump. :)
Regards, Dewayne.
___
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]

[Dewayne Geraghty]

Your use case is very similar to others that manage servers, particularly
on behalf of others.  We also rebuilt nightly , if any vulnerabilities were
discovered we'd test and push to clients' servers.
 :)
Cheers.
-- 
*Disclaimer:* *As implied by email protocols, the information in this
message is not confidential. Any intermediary or recipient may inspect,
modify (add), copy, forward, reply to, delete, or filter email for any
purpose unless said parties are otherwise obligated.  Nothing in this
message may be legally binding without cryptographic evidence of its
integrity and/or confidentiality.*
___
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: sysutils/tmux - strange behaviour with new version 2.4

[Dewayne Geraghty]

Thanks for the hint.  That probably explains why a long awk script
misbehaved by "processing a comment", on FreeBSD 11stable amd64 updated
fortnightly. (Thought it was a bad awk, but there are other gremlins
lurking)
-- 
*Disclaimer:*



*As implied by email protocols, the information in this message is not
confidential. Any intermediary or recipient may inspect, modify (add),
copy, forward, reply to, delete, or filter email for any purpose unless
said parties are otherwise obligated.  Nothing in this message may be
legally binding without cryptographic evidence of its integrity and/or
confidentiality.*
___
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: Licence practice for dependencies - making use of more restrictive licences optional

[Dewayne Geraghty]

Matthew,
Sure.  Some ports require gcc to compile, but these are covered by this
exemption
https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html
so that aspect isn't an issue, and its a little tangential anyway.  I'm not
focusing upon what opendnssec does, rather it was an example that appeared
on top of my freshports browse earlier and the inclusion of gnugrep was a
(human) memory trigger. ;)

Where a port needs something that is more restrictive than the original
authors intent, is the issue that I'd like to address.
For example, some ports provide the option of using libedit or readline,
while others have that option embedded in their configure scripts.  The
practice that I'd encourage is where an application/port uses a less
restrictive licence for their software then the less restrictive dependency
option should be used (mandated) or *preferably* provide that option for
port builders.

Developers provide a great service to all of us.  If they choose one
licence over another that's their choice and really outside of my intent of
this discussion.  It is more to do with whether or not dependencies that
restrict software use, should be optional or not, against the parent port.
For example if I use curl (MIT licence) - I can choose to select openssl
(OpenSSL) over gnutls (GPLv3) - a good thing.

Regards, Dewayne.
PS Sorry for sending to you (Matthew) twice, I'm used to replying only to
the author
___
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"

Licence practice for dependencies - making use of more restrictive licences optional

[Dewayne Geraghty]

The recent change to https://svnweb.freebsd.org/ports/head/dns/opendnssec13/
Makefile?view=markup=439426 which uses BSD3Clause, while gnugrep
uses GPLv3+; reminded me of a customer's requirement to remove GPLv3 code
from a device they needed.

While attempting to satisfy a particular customer's requirement, it became
apparent that I was also seeking compliance with the author's intent of
using a less restrictive licence; yet it seems that some port
maintainers/committers are unintentionally restricting the software by
adding dependencies that add these restrictive licences/practises.  It
would be better if such restrictions were optional, rather than mandatory
as this opendnssec example, perhaps something similar to what is done in
security/krb5-115 could be adopted as part of Standard Operating Practices
(port maintainers guide?)

For my client? A few scripts and a quick (recursive) search for GPL against
their requirements list revealed the easy low-hanging fruit of replacing
readline by libedit (in some cases removing both); and moving what used GPL
source into a separate jail sufficed.

Regards, Dewayne
___
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: Downloading with lynx or w3m, how to download as is, without gratuitous gzip

[Dewayne Geraghty]

Yes, I'm with Anatoly.  Some browsers accept encrypted or compressed
content and then try to display it. I've tried lynx (GPL2),wget (GPL3) but
curl (MIT) with minimum options does the trick nicely.
I use curl in place of fetch, so in a make.conf there's
FETCH_CMD= /usr/local/bin/curl --create-dirs --connect-timeout 10 -m 240
--retry 1 -C - --ipv4 -O -o -

curl is harder to master than wget ;)

Hopefully this helps :)
___
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: Is pkg quarterly really needed?

[Dewayne Geraghty]

Scratch65535, I think your best solution is to use latest and upgrade when
you need to.  Unlike Freddie's comment re only desktop users using latest.
I ONLY upgrade my local svn of ports when there's a vulnerability or
significant (for users) functional improvement of a port.

It is a labour intensive exercise, monitoring CVE's for all
externally-facing applications.

Its a nice idea having a snapshot of ports, from the perspective of
consistency, but that model doesnt suite our risk appetite on multiple
levels; and in our view back-porting fixes to a quarterly snapshot - a good
idea from a security perspective it is a really bad idea from a
consistency/administrative/audit perspective.

How the ports infrastructure can meet many conflicting objectives is
something that we (the consumers of the ports service) must decide for our
circumstance.  The use-the-latest paradigm suits individuals that manage
their individual machine, but when you manage multiple clients' servers,
the requirements are different (try meeting a SAS70-II/SAE16-SOC2, ISO27001
SOA, NIST 800-53r5, etc)

On a non-audit level, Microsoft might hold to monthly updates/fixes ("patch
Tuesday") but bad guys don't.
Regards, Dewayne.
___
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: net/samba46

[Dewayne Geraghty]

I use gcc5 to build most of my ports. And I have samba running as a
fileshare only, not a domain. Soon to change as I will be moving from
samba36 pdc.

On 11.0stable (most recent build of base using clang4) works well.  I'll
see if we can bring forward testing of AD on Samba46 & FreeBSD 11 to this
weekend?




-- 
*Disclaimer:*



*As implied by email protocols, the information in this message is not
confidential. Any intermediary or recipient may inspect, modify (add),
copy, forward, reply to, delete, or filter email for any purpose unless
said parties are otherwise obligated.  Nothing in this message may be
legally binding without cryptographic evidence of its integrity and/or
confidentiality.*
___
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: running poudriere with 8 builders

[Dewayne Geraghty]

Set maxvnodes to 50 and jump 100k until you're happy.  I have Xeon e3
that uses 800,000 and thats reasonable; but i keep it at load 8 for a two
days. Keep an eye on your swap, I set mine to swap out idle stuff early.

Thanks for sharing your experience
-- 
*Disclaimer:*



*As implied by email protocols, the information in this message is not
confidential. Any intermediary or recipient may inspect, modify (add),
copy, forward, reply to, delete, or filter email for any purpose unless
said parties are otherwise obligated.  Nothing in this message may be
legally binding without cryptographic evidence of its integrity and/or
confidentiality.*
___
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: openjdk6-i386 not found

[Dewayne Geraghty]

Unfortunately Mark, a question that I'm unable to answer.  The request was
to build a minecraft server for a friend on a i386, hence, via portmaster:
games/minecraft-server 211/284 >> java/openjdk8-jre >> java/openjdk7 >>
java/bootstrap-openjdk
___
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"

openjdk6-i386 not found

[Dewayne Geraghty]

To whom would I file a PR for the following missing file:
http://distcache.freebsd.org/ports-distfiles/openjdk6-i386-r351880.tar.xz
returns 162 byte file from nginx - Not Found

distcache.freebsd.org   canonical name = distcache.geo.freebsd.org.
Name:   distcache.geo.freebsd.org
Address: 149.20.1.201

Regards.
___
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?

[Dewayne Geraghty]

Some people collect brown pebbles, you know, those little maintainership
pebbles where people generously volunteer to keep ports up-to-date and
remain functioning on the various platforms.  Collecting these and
demonstrating an ongoing professional and technically competent
contribution, sometimes leads to the much coveted white pebbles, the ones
that denote recognition of technical abilities and ultimate providers of
source to the FreeBSD consumers – the larger family. They, the trusted
elite with their commit-bit.


Sometimes a commit bit is relinguished due to exhaustion or simply lack of
time for volunteer activities. But even these are held onto until the owner
feels like its time to hand-it-back. Rarely, very rarely is a commit bit
withdrawn and in such a public way as


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


Bryan quite rightly advised that negative discussion of an individual
shouldn’t be public.  Perhaps strange that it was the FreeBSD portmgr that
alluded to unacceptable and intractable behaviour which resulted in the
removal of the commit bit.  It’s appreciated that the maintainership of the
60+ ports, some quite complex (gcc6-aux and other compilers),


http://www.freshports.org/search.php?stype=maintainer=match=marino=30=category=asc=Search=html=head

that John maintained was reinstated.  Mistakes happen but it is a concern
that the impression of automatic removal of maintainership rights had taken
hold - and without any discussion with the maintainer.


Unfortunately when you’ve held the white stone, once taken, diminishes the
motivation to retain the brown ones.

https://forums.freebsd.org/threads/59705/page-2#post-343136

So perhaps these ports, now semi-abandoned – difficult to acquire, easily
removed; are now likely to follow the familiar path of dormant PR’s and
eventually made available for others to adopt. An unintended consequence...


So that we can better understand the person, this is an interview with John
(jump to 21 minutes):

http://www.jupiterbroadcasting.com/93926/synthesize-all-the-things-bsd-
now-129/

Clearly a person proud of the recognition afforded by having a commit-bit
and as demonstrated by his ports contribution, deservedly so.


Sadly the lack of involvement by the Foundation is somewhat surprising,
even for a group that advocates a hands off approach; and for the FreeBSD
base, its probably warranted.  Unfortunate for that paradigm to apply in
the ports arena, a shame really.


Not retaining people of John Marino’s calibre is a loss, to push him out of
the Project is a travesty.  Such a strong word, but appropriate when the
REASON for his departure has not been revealed - to John!  Discussions that
affect someone’s professional reputation are held, decisions made and
without recourse, review or an opportunity for defence.  The victim remains
uninformed as to the cause.


I thank those of you that have mailed me privately.  We can only hope that
those that have the authority to look at the impact and the consequences of
this decision, properly review the efficacy of such, the consequences and
take the right action.  Which for those not privy to the impugned
horrendous and ongoing misconduct, are better served by having John inside
the FreeBSD family foistering the relationship between Dragonfly and
FreeBSD and others; continuing to provide packaging choice, a voice (one of
the few) that challenges the status quo; but mostly for his passion in
contributing to the project as a top contributor for 3 years!


To be clear, the only person that is ENTITLED to know the reason is John
Marino; it is then up to him to assess and whether it should be made
public.  That is the very least that should happen.

Regards, Dewayne
___
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

[Dewayne Geraghty]

On 21 February 2017 at 07:48, The Doctor  wrote:

> On Mon, Feb 20, 2017 at 12:35:41PM -0800, Kevin Oberman wrote:
> > On Mon, Feb 20, 2017 at 11:57 AM, The Doctor 
> > wrote:
> >
> > > On Mon, Feb 20, 2017 at 05:55:46PM +, Jan Beich wrote:
> > > > The Doctor  writes:
> > > >
> > > > > We have a big one!!
> > > > >
> > > > > 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
> > > >
> > > > How did you invoke the build? portmaster and portupgrade are
> supposed to
> > > > look into /usr/ports/MOVED before proceeding. If they don't then
> you're
> > > > probably treading the unsupported territory[1] or encountered a bug.
> > >
> > > My sequence is
> > >
> > > pkg update -f
> > > portsnap fetch update
> > > portmaster -a
> > >
> > > Am I doing something wrong?
> > >
> >
> > If you are building from ports, I'm not clear on why you do 'pkg update
> > -f', but it should not hurt.
> >
> > Before running "portmaster -a", you should run "portmster -o
> devel/libevent
> > devel/libevent2".
> >
> > Just looking quickly at portmaster, it appears to deal with deleted ports
> > and ports moved to a different location in the tree, but it does not look
> > to me like it handles renamed ports properly. If someone who is better at
> > shell scripting than I am wants to look at the code after line 1100,
> maybe
> > this could either be fixed or added.
>
> Is this a portmaster issue?
>
> > --
> > Kevin Oberman, Part time kid herder and retired Network Engineer
> > E-mail: rkober...@gmail.com
> > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
> --
> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@
> nl2k.ab.ca
> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist
> rising!
> http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
> God is dead! Yahweh lives! Jesus his only begotten Son is the Risen
> Saviour!!
> ___
> 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"
>



Unlikely to be a portmaster issue.  If you look inside /usr/ports/UPDATING
you're find some useful references to the way that portmaster handles name
changes and John's "portmaster -o" advice is correct; its easy to miss that
point in the man page ;)

Perhaps its just a timing issue but both libevent2 and libcheck name
changed broke our overnight builds.  Unfortunately we didn't realise that
we had a dependency until databases/memcached barfed.  So we need to check
/usr/ports/UPDATING and MOVED against a previous build to minimise that
liklihood and catch dependencies.

Upside is that we've just completed testing of synth, and decided to move
the development servers to it.  A recent post (from Bapt@) reaffirmed that
the changes to /usr/ports is likely to break portmaster and other tools due
to flavour's same origin.  So rather than continue to rely upon a
previously advocated tool, which is well suited to our very narrow purpose,
its time to move.

For those interested in synth but skittish:
1. install synth; read the manual
2. synth configure
which places the synth.ini file in /usr/local/etc/synth
and for testing purposes try
3. synth just-build $category/$portname;
Example: synth just-build devel/check devel/libevent ftp/curl
4. Examine your logs in /var/log/synth
Particularly 00_last_results.log and 02_failure_list.log
5. Examine your new packages in /var/synth/live_packages/All

Gotchas: if you have complex make.conf file that pulls in other files, you
will need to concatenate them into the one make.conf.

If you have home grown build systems like we do, that have used portmaster
since around 2005, its a big deal to change.  We're looking forward to this
incremental change.  And if you use jails extensively, synth runs happily
in a jail too - but this was against John Marinos advice, however we have
strict functional separation here.
___
freebsd-ports@freebsd.org mailing list

Expulsion of John Marino - reasons and impact?

[Dewayne Geraghty]

Occasionally we’re called to account for our decisions, reflect upon their
correctness and at times reverse the decision.



John Marino (John) has conducted himself with a passion for making
decisions in the interests of ports' users over many years with great
professionalism and enthusiasm.   At times, this passion exudes into
bravado, even exuberance.  This is not uncommon when sharing deep-seated
beliefs of how things should be done.  Sometimes, perhaps too rarely we see
contrary opinions expressed in the various FreeBSD lists.



As I’ve observed with my first and second level managers, the weak managers
never hire people that challenge their views, or have talents superior to
their own; they hire people with lesser abilities.  To their detriment they
deny themselves the opportunity to grow.  Similarly with community-based
projects, I’m currently a Director of one, in this context strongly
divergent views distract from the singular imperative of helping
others.  Regardless
such views cause, reflection – are we heading in the right direction; are
our actions aligned with our mission; is our strategy meeting the goals of
our customers (the needy in the community); are we properly communicating
and advocating our purpose.  Time consuming and sometimes unpleasant, the
opportunity to review and challenge is worthwhile.



John is significant contributor to the ports user-base, he has advocated
views which represent the needs of the user-community and his expulsion,
the reasons for them and the analysis of his expulsion upon the project
should be communicated, for transparency and reassurance that such
decisions are in the interests of everyone.  This is simply inadequate:

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

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





I value John’s forthright opinions, and his motivations and contribution to
GNU, Ada, DragonflyBSD and FreeBSD are not unrecognised.  He articulates
his position clearly; his design and development efforts are sound, and the
development of Synth is appreciated.



This lack of transparency suggests that he is divergent, so lets examine
this as a reason for expulsion.



Was it due to providing a choice.  Users of FreeBSD have a choice:

a) build their own build/development system

b) use poudererie - which to me is another layer of complexity and another
source of frequent change

c) use synth - where transparency and is relatively simple to use.



The ports system has undergone significant change over the last 4 years,
much of it needed and requiring significant time and active contribution by
the meta-ports developers.  Unfortunately the cost to those using the ports
system during this time has been significant.  I see John as a stabilising
influence (as Doug Barton was) - is this the reason?



Lets just examine FreeBSD for a moment.  The project is fantastic and so
many different ideas and approaches have collaborated and continue to
progress; I was a saddened when Matt Dillon split from FreeBSD.  Its a
testament to all that there remain, that a high level of exchange and
collaboration continues and John has acted as a conduit and has contributed
in this area also.



So how should we view “The FreeBSD Project"?  Its really split along the
logical boundaries of: the base system, the ports meta-system, and the
ports system.



The ports system is actively maintained by many ports “maintainers” and the
frequency of change reflects the changes to applications (source) that is
under greater scrutiny to be (more) secure.  This is ok, and I’ll come back
to this.

I started with FreeBSD in 2003, when packages were available and this
greatly contributed to my uptake of FreeBSD.  Over time, I needed to
customise my settings sometimes for performance reasons, usually for
security reasons.  I was very happy with the ports system, and I was able
to work-around the changing library versioning issues; but it did need to
be fixed.



Roughly 4-5 years ago pkg and the meta-ports system underwent significant
and needed change. The folks doing this work have done a great job; but.  The
implementation of the changes had a deleterious effect.  The frequency of
change became intolerable, at one point we had 0.25 of an FTE just
maintaining our build systems.  We rebuilt all packages overnight which
enabled testing in the event of critical issues for our clients. Had we
known of the meta-ports flux we would've changed our business model and
commitments to our customer base.



Now we see discussions over whether ports should be supported past the EOL
of an OS.  Seriously?  I had a client that refused OS upgrades, so we
maintained up-to-date ports for around 4 years after FreeBSD 6.1 was
EOL.  Ridiculous
but a credit to the ports and meta-ports developers/maintainers, at the
time.  Our view of FreeBSD being rock-solid was reinforced.  However,
nothing like this should be expected to be supported, though packages
should be able to be built for 

Re: Samba43 install error

[Dewayne Geraghty]

On Thu, 29 Dec 2016 at 00:34, Gerard Seibert  wrote:

> FreeBSD 11.0
>
>
>
> I am unable to update samba43. The following error message is displayed:
>
>
>
> samba43-4.3.13 cannot install: SASL support requested and
>
> openldap-client-2.4.44  is installed.
>
> *** Error code 1
>
>
>
> Stop.
>
> make: stopped in /usr/ports/net/samba43
>
>
>
> I am using the default port configuration as listed below:
>
>
>
> ===> The following configuration options are available for samba43-4.3.13:
>
>  ACL_SUPPORT=on: File system ACL support
>
>  ADS=on: Active Directory client support
>
>  AD_DC=on: Active Directory Domain Controller support
>
>  AIO_SUPPORT=on: Asyncronous IO support
>
>  CUPS=off: CUPS printing system support
>
>  DEBUG=on: Build with debugging support
>
>  DEVELOPER=off: With development support
>
>  DNSUPDATE=on: Dynamic DNS update (require ADS)
>
>  DOCS=on: Build and/or install documentation
>
>  EXP_MODULES=off: Experimental modules
>
>  FAM=on: File Alteration Monitor support
>
>  LDAP=on: LDAP client support
>
>  MANPAGES=off: Build manpages from DOCBOOK templates
>
>  PAM_SMBPASS=off: PAM authentication via passdb backends
>
>  PTHREADPOOL=on: Pthread pool
>
>  QUOTAS=on: Disk quota support
>
>  SYSLOG=on: Syslog logging support
>
>  UTMP=on: UTMP accounting support
>
> > Options available for the radio DNS: you can only select none or one
> of them
>
>  NSUPDATE=off: Use samba NSUPDATE utility for AD DC
>
>  BIND99=off: Use bind99 as AD DC DNS server frontend
>
>  BIND910=off: Use bind910 as AD DC DNS server frontend
>
> > Options available for the radio ZEROCONF: you can only select none
> or one of them
>
>  AVAHI=off: Zeroconf support via Avahi
>
>  MDNSRESPONDER=off: Zeroconf support via mDNSResponder
>
>
>
> I turned of LDAP in the config file; however, the problem still exists.
>
>
>
> I do not understand why this is happening. Does anyone have a work-around
> for this or should I file a PR?
>
>
>
> --
>
> Carmel
>
>
>
> ___
>
> 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"
>
> I had a problem on FreeBSD 11 & samba 44.  I used gcc5 to build.  I
modified s few things and now running samba 4.4.8 :)
I force gcc5 use for a few ports as clang fails.
Might help you.
Regards.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: HEADSUP: FLAVORS (initial version) and subpackages proposals

[Dewayne Geraghty]

Thanks Bapt et al,

I use FreeBSD and the ports system extensively, we build everything from
source and largely customise approx 25% of the 900 packages we rely upon.
I'm more than a little concerned to have changes performed against the
ports infrastructure.  As our primary sources of (whats coming) "Change"
information are the: Quarterly reports and the OS Release Notes;
after-the-fact sources are a daily review of
https://lists.freebsd.org/pipermail/svn-src-stable-11/2016-December/thread.html
for OS impact; and the excellent Freshports.

So a few questions:

Could you be able to enlighten us (the readers) so we can better understand
what will be changed; or share your vision of the benefits and operational
impact for operational people that build: from source; and those that only
use binary?

Is there a transition plan or schedule for the bulk of these changes to
occur?

Will the flavors/subpackages be developed separately from the existing
ports suite?  (I'm hoping that the parent ports will be unaffected, and so
our existing build procedures continue to build correctly)

How will we (the users/admins) track or be informed of changes or better,
planned/soon changes?  (will changes to ports, particularly parent ports,
be co-ordinated through UPDATING or perhaps a new FLAVOURS file if the
parent is say a stub and the real decisions are relocated to slaves?)

Will there be any guidance regarding how flavours/packages should be
created or the criteria for creating sub-packages (secure/insecure; all
options on/off; most useable options on; most liked by the maintainer; most
likely to be used for a datacentre; most likely to be used for desktops;
...)?   Will "The Porter's Handbook" be updated for things like criteria;
naming conventions etc?

For folks (like me) that build entirely from source and customise options
to build the applications, how will flavours/subpackages be of benefit?
Will the ability to customise ports, as they exist today, remain?  Will I
even notice a change?

I'd like to plan ahead to make this transition seemless and continue to use
FreeBSD and the excellent ports system as we do now.

I started with FreeBSD 2.2.8.  There were packages available from the
FreeBSD website.  It was a terrific aid.  We also enjoyed the different
flavours of jail that were provided by ezjail.  However over time, both
evolved as did our expertise to customise our ports (~200 custom ports) and
Jamie Gratton evolved the jail system to eliminate our need of the
excellent ezjail tool.  So I can see merit in, what very little I'm
guessing of, the next evolution of ports.

Aside: we already build different package configurations from existing
ports' source.  (eg different bind910 with/without kerberos; different
samba44's; simultaineous building of dhcp-[server|client|relay] etc)

I look forward to being on the same page and to understand where this is
going, the likely/potential impact; the naming conventions; etc.

Kind regards, Dewayne.
___
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"

Problem with gcc5 std library when building ports

[Dewayne Geraghty]

Have spent a couple of days trying to build around 800 ports with gcc5.
This one has me stumped!

Can anyone help regarding the apparant absence of snprintf from std?  Am I
missing something, perhaps LDCONFIG or?  I've looked in /usr/ports/Mk/
bsd.gcc.mk and /usr/ports/Mk/bsd.port.mk but this is an area that I'm
unfamiliar, so nothing really stood out.

If I change the compiler from gcc5 to clang everything compiles and runs
correctly. I have in /etc/make.conf
USE_GCC=  5
and to use clang, I just comment out the above. So everything is constant,
on FreeBSD 10.3Stable (updated and rebuilt overnight)

For example: /usr/ports/devel/jsoncpp (but many share this problem)
g++5 -o buildscons/linux-gcc-FreeBSD/src/lib_json/json_reader.o -c -O2
-pipe -DOPENSSL_NO_SSL2 -DOPENSSL_NO_SSL3 -g0 -ggdb0 -DSTRIP_FBSDID
-UDEBUGGING -UDEBUG -march=c3-2 -mtune=c3-2 -Wl,-rpath=/usr/local/lib/gcc5
-fno-strict-aliasing --std=c++11 -Wl,-rpath=/usr/local/lib/gcc5 -Iinclude
src/lib_json/json_reader.cpp

src/lib_json/json_reader.cpp: In member function 'std::__cxx11::string
Json::Reader::getLocationLineAndColumn(Json::Reader::Location) const':
src/lib_json/json_reader.cpp:34:18: error: 'snprintf' is not a member of
'std'
 #define snprintf std::snprintf

And for completeness:
# ldconfig -r | grep -E "gcc|\+"
search directories:
/lib:/usr/lib:/usr/lib/compat:/usr/local/lib:/usr/local/lib/gcc5:/usr/local/lib/heimdal:/usr/local/lib/perl5/5.20/mach/CORE
35:-lgcc_s.1 => /lib/libgcc_s.so.1
38:-lc++.1 => /usr/lib/libc++.so.1
126:-lcc1.0 => /usr/local/lib/gcc5/libcc1.so.0
127:-lgcc_s.1 => /usr/local/lib/gcc5/libgcc_s.so.1
128:-lstdc++.6 => /usr/local/lib/gcc5/libstdc++.so.6
129:-lcilkrts.5 => /usr/local/lib/gcc5/libcilkrts.so.5
130:-lssp.0 => /usr/local/lib/gcc5/libssp.so.0
131:-lquadmath.0 => /usr/local/lib/gcc5/libquadmath.so.0
132:-lgfortran.3 => /usr/local/lib/gcc5/libgfortran.so.3
133:-lobjc.4 => /usr/local/lib/gcc5/libobjc.so.4
134:-lgomp.1 => /usr/local/lib/gcc5/libgomp.so.1
135:-lgomp-plugin-host_nonshm.1 =>
/usr/local/lib/gcc5/libgomp-plugin-host_nonshm.so.1
136:-litm.1 => /usr/local/lib/gcc5/libitm.so.1
137:-latomic.1 => /usr/local/lib/gcc5/libatomic.so.1

Regards, Dewayne
___
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: gcc5 dependency challenges

[Dewayne Geraghty]

On 14 October 2016 at 21:22, Kubilay Kocak <ko...@freebsd.org> wrote:

> On 14/10/2016 6:48 PM, Dewayne Geraghty wrote:
> > After some rudimentary performance testing I note that we get up
> > around 3% improvement in application performance when we use gcc5 for
> > our package builds.
> >
> > However building ports with gcc results in gcc5 being a dependency.
> > Examining ldd, we find that rarely does anything require gcc5's
> > shared libs for their execution.  Even simple things like ftp/wget
> > and devel/ccache depend on gcc5 for building but NOT runtime.  As we
> > aren't allowed to install compilers onto production systems, what is
> > the best course of action to address? (We could just install gcc5 and
> > then remove it but then of course, the base pkg wants to remove
> > everything (600+ packages) that depends on gcc5!)
> >
> > So the question is - how should we build our packages or install them
> > so that gcc5 is not (unnecessarily) installed?
> >
> > We've added to our /etc/make.conf USE_GCC=  5 but I wonder if there's
> > something like a build_depends mechanism?
> >
> >
> > Background: Our FreeBSD 10.3 Stable uses pkg 1.8.3; whereas ports
> > uses 1.8.7_3, minor point.
> >
> > Why gcc5? Well most ports use clang 3.4.1 to compile, some ports do
> > use gcc 4.8.5; and if we move to FreeBSD11 then we also need to add
> > llvm3.6 into the build/migrating equation.  So to aid our migration
> > effort we "think" choosing gcc5 now is a good idea; particularly as
> > /usr/ports/base/gcc uses gcc 5.4.0 (rather than /usr/ports/lang/gcc
> > which is 4.8.5)
> >
> > All production systems use local package repositories (as heimdal is
> > widely used as are  non-default options).
> >
> > Kind regards, Dewayne
>
> This (in progress thing) may help:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211154
>
> See dependent Bugzilla issue:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211079
>
> ./koobs
>

Kubilay,
Thank-you very much for the pointers.

I have appended the following to /usr/ports/Mk/bsd.port.mk
.if defined(PRODUCTION_USE)# defined in make.conf :)
RUN_DEPENDS:=${RUN_DEPENDS:Ngcc*}
RUN_DEPENDS:=${RUN_DEPENDS:Npkg*}
RUN_DEPENDS:=${RUN_DEPENDS:Nindexinfo*}
.endif
which has achieved the desired goal.

So I've gone from a virgin system without gcc or binutils where:

b1# pkg-static add /root/build/i386/portconf-1.6_1.txz
[b1.hs] Installing portconf-1.6_1...
[b1.hs] `-- Installing gcc5-5.4.0...
[b1.hs] |   `-- Installing binutils-2.27_4,1...
[b1.hs] |   | `-- Installing gcc5-5.4.0...
[b1.hs] |   |   `-- Installing binutils-2.27_4,1...
to
b2# pkg-static add /root/build/amd64/portconf-1.6_1.txz
[b2.hs] Installing portconf-1.6_1...
[b2.hs] Extracting portconf-1.6_1: 100%
(Note that portconf is a text script!)

Julian,
I agree with you.  I have been using a similar approach for many years on
our production boxes, essentially repackaging our packages to achieve the
purpose that you require.  (Note though I also use pkg 1.6.4 to install as
the 1.8 series didn't work as it tried to do something to directories that
didn't exist (I vaguely recall man page directories)).

This is the kludge of excluded files to be repackaged by tar:
cat << EOM > $EXCL
man/man?/
include/*
*/man/man?/
share/doc/*
share/examples/*
*/doc/html/
*/doc/pdf/
/lib/edoc-*
lib/erl_docgen*
usr/local/share/doc/
usr/local/share/*/doc/
lib/*.a
EOM

Then walk through your packages and
 tar -cJp -X $EXCL  --options='xz:compression-level=6' -f
/packages-reduced/$P @${P}
where P is the package (eg wget-1.18.txz)

Kind regards, Dewayne.
___
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"

gcc5 dependency challenges

[Dewayne Geraghty]

After some rudimentary performance testing I note that we get up around 3%
improvement in application performance when we use gcc5 for our package
builds.

However building ports with gcc results in gcc5 being a dependency.
Examining ldd, we find that rarely does anything require gcc5's shared libs
for their execution.  Even simple things like ftp/wget and devel/ccache
depend on gcc5 for building but NOT runtime.  As we aren't allowed to
install compilers onto production systems, what is the best course of
action to address?
(We could just install gcc5 and then remove it but then of course, the base
pkg wants to remove everything (600+ packages) that depends on gcc5!)

So the question is - how should we build our packages or install them so
that gcc5 is not (unnecessarily) installed?

We've added to our /etc/make.conf
USE_GCC=  5
but I wonder if there's something like a build_depends mechanism?


Background:
Our FreeBSD 10.3 Stable uses pkg 1.8.3; whereas ports uses 1.8.7_3, minor
point.

Why gcc5? Well most ports use clang 3.4.1 to compile, some ports do use gcc
4.8.5; and if we move to FreeBSD11 then we also need to add llvm3.6 into
the build/migrating equation.  So to aid our migration effort we "think"
choosing gcc5 now is a good idea; particularly as /usr/ports/base/gcc uses
gcc 5.4.0 (rather than /usr/ports/lang/gcc which is 4.8.5)

All production systems use local package repositories (as heimdal is widely
used as are  non-default options).

Kind regards, Dewayne
___
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: Alternatives to rsync

[Dewayne Geraghty]

On 14 October 2016 at 17:01, Franco Fichtner  wrote:

>
> > On 14 Oct 2016, at 7:54 AM, Eduardo Morras via freebsd-ports <
> freebsd-ports@freebsd.org> wrote:
> >
> >
> > Sorry for commenting on this reply to Greg to answer Shane Ambler, I
> > joined maillist today.
> >
> > On Fri, 14 Oct 2016 09:26:03 +1100
> > Greg 'groggy' Lehey  wrote:
> >
> >> On Thursday, 13 October 2016 at 18:13:39 +1030, Shane Ambler wrote:
> >>> On 13/10/2016 15:09, reko.turja--- via freebsd-ports wrote:
>  One of my users is needing rsync like functionality to transfer
>  changed contents of some directories between couple of machines.
>  As rsync 3 isn't open source, but GPL3 it's out of question in
>  order to keep the system untainted.
> 
>  The software should be relatively lightweight - no fullblown
>  mirroring/backup is needed. Also hints how to achieve similar ends
>  using maybe tar/ssh might do.
> >>>
> >>> sysutils/cpdup provides similar functionality to rsync and is bsd
> >>> licensed.
> >
> > cpdup in ports comes from old matt dillon pages and is version1.18.
> > DragonflyBSD has version 1.32 at [1][2] and compiles with low effort on
> > FreeBSD.
>
> If there is interest in updating the port we should do it.  I can talk
> to Matt, see if he is willing to release an updated portable version
> with required build fixes (if any).
>
>
> Cheers,
> Franco
> ___
> 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"
>


Franco, That's probably a good idea as the cpdup homepage has source for
1.09.

Could we be so lucky to include extended attributes and MAC labels in cpdup?
Regards, Dewayne
___
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"

Eliminate the use of gettext

[Dewayne Geraghty]

I would like to reduce (eliminate) the prevalence of GPLv3 code in the
applications that we build.

How can we eliminate the use of gettext-runtime in, for example, heimdal
which is widely used?

We use English only, so internationalisation isn't a concern and the
inclusion of gettext-runtime means that we're introducing GPLv3 code into
applications that are BSD licenced.

*Regards.*
___
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"

Mariadb101 does compile on i386 if use gcc

[Dewayne Geraghty]

While working through my ports' patches to revert the local changes for
libressl [Thanks to John Marino, your ssl commits are appreciated :) ], I
came across this for
/usr/ports/databases/mariadb101-server/Makefile

-NOT_FOR_ARCHS= i386
-NOT_FOR_ARCHS_REASON=  currently does not compile on i386, see \
-   https://mariadb.atlassian.net/browse/MDEV-9627
+#NOT_FOR_ARCHS=i386
+#NOT_FOR_ARCHS_REASON= currently does not compile on i386, see \
+#  https://mariadb.atlassian.net/browse/MDEV-9627
+USE_GCC=   any

This might help others using mariadb on i386.
___
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"

binutils version tweak

[Dewayne Geraghty]

Would it be possible for someone to increment the PORTREVISION for
devel/binutils.  The last three changes aren't being picked up due to a
constant Version,Revision,Epoch sequence.  And two of these changes  are
relevant.
Thank-you.
___
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"

Wiki to help migration to libressl

[Dewayne Geraghty]

Bernard,

Thank-you for maintaining this invaluable resource.  Whenever I experience
a problem that I suspect is due to ssl/crypto, I check here
https://wiki.freebsd.org/LibreSSL/Ports
and then bugzilla!

For anyone considering migrating their openssl to libressl, this is an
invaluable resource.  (at least until the maintainers can test/incorporate
the provided patches ;) )

Kind regards, Dewayne.
PS I use openssl on i386 (as most benefit from VIA's padlock accelerator)
and the amd64's use libressl (benefiting from AES-NI) for the 900+
server-related ports.
___
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: Passwordless accounts vi ports!

[Dewayne Geraghty]

Olivier,
I've checked my 10.3Stable systems and they all have '*' as their password,
which is consistent with /usr/ports/Mk/UIDs.  You might like to check the
age of the latter.
Regards, Dewayne.
PS Both ports and src were built from updated src and ports from 2016-08-09
___
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: GraphicsMagick *and* ImageMagick fail to compile

[Dewayne Geraghty]

I can echo Kevin's experience.
Successfully built on 10.3-STABLE FreeBSD 10.3-STABLE #0 r303088M: Thu Jul
21, using ccache on both i386 and amd64.
-rw-r--r--  1 root  wheel   6.8M Jul 23 01:34
ImageMagick-nox11-6.9.4.3,1.txz

#  cd /usr/ports/graphics/ImageMagick-nox11 && make showconfig | grep =off
 DJVU=off: DJVU format support (needs THREADS)
 GRAPHVIZ=off: Graphviz graph drawing support
 GSLIB=off: libgs (Postscript SHLIB) support
 HDRI=off: High dynamic range images support
 OPENEXR=off: HDR image format support via OpenEXR
 OPENMP=off: Parallel processing support via OpenMP
 TESTS=off: Run bundled self-tests after build
___
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: stunnel fails to build

[Dewayne Geraghty]

On 21 July 2016 at 18:15, tech-lists  wrote:

> Hi,
>
> ports: r418866
> stable/11: r302999
>
> I have the following defined in /etc/make.conf - could this be the issue?
>
> DEFAULT_VERSIONS+=  ssl=libressl-devel
>
> ###
>
> build fails like this:
>
> /usr/ports/security/stunnel # make MAKE_JOBS_UNSAFE=yes
> ===>  Building for stunnel-5.35,1
> Making all in src
> /usr/bin/make  all-am
>   CCLD libstunnel.la
>   CC   stunnel-tls.o
> In file included from tls.c:39:
> ./prototypes.h:656:9: error: unknown type name 'CRYPTO_RWLOCK'
> typedef CRYPTO_RWLOCK *STUNNEL_RWLOCK;
> ^
> tls.c:56:30: warning: incompatible pointer types passing 'void *(size_t,
> const char *, int)' (aka 'void *(unsigned long, const char *, int)') to
> parameter of type 'void *(*)(size_t)' (aka 'void *(*)(unsigned long)')
> [-Wincompatible-pointer-types]
> CRYPTO_set_mem_functions(str_alloc_detached_debug,
>  ^~~~
> /usr/local/include/openssl/crypto.h:412:38: note: passing argument to
> parameter 'm' here
> int CRYPTO_set_mem_functions(void *(*m)(size_t), void *(*r)(void *,
> size_t), void (*f)(void *));
>  ^
> tls.c:57:9: warning: incompatible pointer types passing 'void *(void *,
> size_t, const char *, int)' (aka 'void *(void *, unsigned long, const
> char *, int)') to parameter of type 'void *(*)(void *, size_t)' (aka
> 'void *(*)(void *, unsigned long)') [-Wincompatible-pointer-types]
> str_realloc_debug, str_free_debug);
> ^
> /usr/local/include/openssl/crypto.h:412:58: note: passing argument to
> parameter 'r' here
> int CRYPTO_set_mem_functions(void *(*m)(size_t), void *(*r)(void *,
> size_t), void (*f)(void *));
>  ^
> tls.c:57:28: warning: incompatible pointer types passing 'void (void *,
> const char *, int)' to parameter of type 'void (*)(void *)'
> [-Wincompatible-pointer-types]
> str_realloc_debug, str_free_debug);
>^~
> /usr/local/include/openssl/crypto.h:412:85: note: passing argument to
> parameter 'f' here
> int CRYPTO_set_mem_functions(void *(*m)(size_t), void *(*r)(void *,
> size_t), void (*f)(void *));
>
>^
> 3 warnings and 1 error generated.
> *** Error code 1
>
> Stop.
> make[4]: stopped in /usr/ports/security/stunnel/work/stunnel-5.35/src
> *** Error code 1
>
> Stop.
> make[3]: stopped in /usr/ports/security/stunnel/work/stunnel-5.35/src
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/ports/security/stunnel/work/stunnel-5.35
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/security/stunnel
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/security/stunnel
>
> ===
>
> same issues on -current
>
> thanks,
> --
> J.
> ___
> 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"
>

After reading about your issue, I updated all of my ports, via svnlite, and
successfully built on yesterday's fresh FreeBSD 10.3 Stable for i386 using
openssl.  Unfortunately on the amd64, which uses libressl, I receive:
===>  stunnel-5.35,1 may not be packaged: The stunnel license restricts
distribution when linked to non-OpenSSL non-base SSL-libraries.  (A recent
enhancement)

My customisations are:
i386 uses make.conf entry:  ssl=openssl
amd64 uses make.conf:  ssl=libressl
This may be significant to your situation?

If there is a problem with the Makefile, please log a PR so everyone can
benefit.  ;)
___
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 happens to the ports for platform i386

[Dewayne Geraghty]

On 12 July 2016 at 09:35, Don Lewis  wrote:

> On 11 Jul, Ivan Klymenko wrote:
> > Hi all.
> >
> > Dear maintainer and committers.
> > Please check what you are doing before heading to the world.
> > What happens to the i386 platform?
> > If it is so difficult to keep it clean it all from the official site
> > https://www.freebsd.org/platforms/
> > i386 platform almost everywhere and is constantly broken.
> > cross-platform build, including ports:
> >
> > devel/libffi
> > http://pastebin.com/q2amknag
> > security/libgcrypt
> > http://pastebin.com/xJTDxRxu
> > math/gmp
> > http://pastebin.com/ibaXeFJp
> > graphics/jpeg-turbo
> > http://pastebin.com/cfpu3k4d
> > graphics/svgalib
> > http://pastebin.com/fXp6t9r2
> > multimedia/xvid
> > http://pastebin.com/J468Ts1Y
> > audio/liba52
> > http://pastebin.com/0GqyidMS
> > audio/flac
> > http://pastebin.com/dFLBUpEd
> > archivers/unzip
> > http://pastebin.com/rE3AHzPB
> > devel/liboil
> > http://pastebin.com/kdqypsxq
> > multimedia/libfame
> > http://pastebin.com/NSd7adYZ
> > security/nss
> > http://codepad.org/VjumGYA0
> > graphics/libvisual04
> > http://codepad.org/7VirQ15W
> > databases/firebird25-client
> > http://codepad.org/EVCYbBju
> > math/lp_solve
> > http://codepad.org/28YvZcz6
> > audio/lame
> > http://codepad.org/PjvxHTrY
> > net-im/tox
> > http://codepad.org/wwwRayBW
> > archivers/p7zip
> > http://codepad.org/ISKwqTTs
> > security/clamav
> > http://codepad.org/iNeSQLTS
> > graphics/goom
> > http://codepad.org/VIjhFxvO
> > multimedia/cuse4bsd-kmod
> > http://codepad.org/bSF0L0Xr
> > devel/libunwind
> > http://codepad.org/yt5hinbF
> >
> > And most importantly - as if no one notices or is indifferent to it,
> > what is happening in FreeBSD.
> >
> > Install FreeBSD to their workplace and use it - what you are doing for
> > yourself - or do not use and do not do anything for FreeBSD.
> >
> > Thank you for understanding.
>
> I'm not seeing any problems here.  My laptop runs this:
>
> %uname -mrs
> FreeBSD 10.3-STABLE i386
>
> I've got 765 packages installed, including some big things like the
> GNOME and MATE desktops, some KDE apps, Firefox, Thunderbird,
> LibreOffice, OpenOffice, etc.
>
> hairball:~ 107%pkg info | wc -l
>  765
>
> I build my own packages (about 1500 ports) using poudriere running on an
> amd64 machine running various flavors of head, including 11.0-CURRENT,
> 11.0-ALPHA*, and currently 12.0-CURRENT (it gets updated from source on
> a fairly regular basis).  I rarely see failures on the i386 packages,
> and when I do, the same port usually fails on amd64 as well.  On my last
> package build run, I got zero build failures for FreeBSD 10 packages,
> either amd64 or i386.  The only two build failures that I did observer
> were when building packages for 12.0-CURRENT amd64.
>
> Of the ports that you list above, I've got these installed on my laptop:
>
> %pkg info | grep libffi
> libffi-3.2.1   Foreign Function Interface
> %pkg info | grep libgcrypt
> libgcrypt-1.7.1General purpose crypto library based on
> code used in GnuPG
> %pkg info | grep gmp
> gmp-5.1.3_3Free library for arbitrary precision
> arithmetic
> %pkg info | grep jpeg-turbo
> jpeg-turbo-1.4.2   SIMD-accelerated JPEG codec which replaces
> libjpeg
> %pkg info | grep svgalib
> svgalib-1.4.3_7Low level console graphics library
> %pkg info | grep xvid
> xvid-1.3.4,1   Opensource MPEG-4 codec, based on OpenDivx
> %pkg info | grep flac
> flac-1.3.1_2   Free lossless audio codec
> %pkg info | grep unzip
> unzip-6.0_7List, test, and extract compressed files
> from a ZIP archive
> %pkg info | grep solve
> lp_solve-5.5.2.0   Linear Programming Solver
> %pkg info | grep lame
> lame-3.99.5_3  Fast MP3 encoder kit
>
> ___
> 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"
>

Most likely the compiler isn't being detected due to a ccache setting.
Sometimes it can be tricky when working with custom settings.

We use ccache in both 10.3Stable i386 and amd64 environments (sans
poudriere) - and we've successfully built some of the ports that Ivan has
listed.

And Walter is right there are some ports like security/hashcat (2.0) that
only builds on amd64 and security/john on i386.  Otherwise most things
build on both, though I'm confident that things like samba4, which has a
lot of tautological errors on i386, aren't going to run the same. ;)

Ivan, these may be relevant
lrwxr-xr-x  1 root  wheel   21 Jul 11 14:22 CC -> /usr/local/bin/ccache
lrwxr-xr-x  1 root  wheel   21 Jul 11 14:22 c++ -> /usr/local/bin/ccache
lrwxr-xr-x  1 root  wheel   21 Jul 11 14:22 cc -> /usr/local/bin/ccache
lrwxr-xr-x  1 root  wheel   21 Jul 11 14:22 clang -> 

Re: openssl-1.0.2.13

[Dewayne Geraghty]

Gerard, the ports tree reflects the updated OpenSSL port.  Perhaps you need
to
svnlite update /use/ports/security/OpenSSL
:)


-- 
*Disclaimer:*



*As implied by email protocols, the information in this message is not
confidential. Any intermediary or recipient may inspect, modify (add),
copy, forward, reply to, delete, or filter email for any purpose unless
said parties are otherwise obligated.  Nothing in this message may be
legally binding without cryptographic evidence of its integrity and/or
confidentiality.*
___
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: Recording TIMESTAMPs in distinfo for reproducible builds work

[Dewayne Geraghty]

On 13 May 2016 at 04:08, Ed Maste  wrote:

> Baptiste and I have been looking at reproducible builds in the FreeBSD
> ports tree, and one thing we'll need is a consistent timestamp that
> doesn't change when a port is rebuilt without changes.
>
> We considered a few different ideas, and have settled on experimenting
> with the time 'make makesum' is run.
>
> I have a bsd.port.mk change that I'll commit shortly to record the
> TIMESTAMP when "make makesum" is run.  I want to do this now so that
> this data is collected and stored "for free" along with regular
> distfile updates.  This will allow experimentation and development of
> reproducible package builds with real data.
>
> For now ports that have no distinfo file, and distfile updates done
> without using "make makesum," can just ignore the TIMESTAMP.
>
> -Ed
> ___
> 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"
>


A nice idea as the version changes PORTVERSION/REVISION aren't always a
reliable indicator.  If you're trying to tag a port build(s) as being
unchanged from one build cycle to another, how will the changes to
/usr/ports/Mk be tagged?

We currently mtree the /usr/ports/Mk dir/subdirs so we can easily determine
where we need to look if there's a problem and/or we need to revert
something quickly.
Regards, Dewayne
___
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: Samba 4.3 compile fails with CUPS option set

[Dewayne Geraghty]

Thanks for posting Frank; I also have this problem which O.Hartman has
created the PR
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208767

And MAKE_JOBS_UNSAFE makes no difference.

On 16 April 2016 at 00:28, Frank Seltzer  wrote:

> I've been having this problem since the port update a few days ago.  I've
> tried with and without CUPS set multiple times each and 'with' always fails
> in the same place with the same error and 'without' always completes
> successfully.
>
> The ports/UPDATING file SAMBA entry dated 20160412 only refers to the
> BadLock vulnerability.  Since it showed no example update commands for pkg,
> portupgrade or portmaster I expected a straightforward compile and install.
>
> Ports are updated every night at 8:00 PM EDT using svnlite and the
> Makefile appears to be up to date:
>
> # $FreeBSD: head/net/samba43/Makefile 413163 2016-04-12 22:44:03Z timur $
>
>
> [3342/3873] Linking default/lib/util/libsamba-debug-samba4.so
> default/source3/client/smbspool_krb5_wrapper_170.o: In function `main':
> /usr/ports/net/samba43/work/samba-4.3.8/bin/../source3/client/smbspool_krb5_wrapper.c:198:
> undefined reference to `clearenv'
> cc: error: linker command failed with exit code 1 (use -v to see
> invocation)
> runner cc default/source3/lib/asys/tests_2.o
> default/source3/lib/asys/asys_1.o
> default/source3/lib/pthreadpool/pthreadpool_1.o -o
> /usr/ports/net/samba43/work/samba-4.3.8/bin/default/source3/lib/asys/asystest
> -fstack-protector -pie -Wl,-z,relro,-z,now -lpthread -Wl,-no-undefined
> -Wl,--export-dynamic -Wl,--as-needed
> -Wl,-rpath,/usr/ports/net/samba43/work/samba-4.3.8/bin/shared
> -Wl,-rpath,/usr/ports/net/samba43/work/samba-4.3.8/bin/shared/private
> -Ldefault/lib/replace -L/usr/local/lib -Wl,-Bdynamic -lreplace-samba4 -lrt
> -lcrypt
> runner cc default/lib/util/close_low_fd_7.o default/lib/util/debug_8.o -o
> /usr/ports/net/samba43/work/samba-4.3.8/bin/default/lib/util/libsamba-debug-samba4.so
> -fstack-protector -Wl,-z,relro,-z,now -lpthread -Wl,-no-undefined
> -Wl,--export-dynamic -Wl,--as-needed -shared
> -Wl,--version-script=/usr/ports/net/samba43/work/samba-4.3.8/bin/default/lib/util/samba-debug.vscript
> -Wl,-rpath,/usr/ports/net/samba43/work/samba-4.3.8/bin/shared
> -Wl,-rpath,/usr/ports/net/samba43/work/samba-4.3.8/bin/shared/private
> -Ldefault/lib/replace -Ldefault/lib/util -L/usr/local/lib -Wl,-Bdynamic
> -ltime-basic-samba4 -lsocket-blocking-samba4 -lreplace-samba4 -lrt -lcrypt
> -ltalloc
> Waf: Leaving directory `/usr/ports/net/samba43/work/samba-4.3.8/bin'
> Build failed:  -> task failed (err #1):
> {task: cc_link dynconfig_1.o,smbspool_krb5_wrapper_170.o ->
> smbspool_krb5_wrapper}
> ===> Compilation failed unexpectedly.
> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
> the maintainer.
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/net/samba43
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/net/samba43
> ** Command failed [exit code 1]: /usr/bin/script -qa
> /tmp/portupgrade20160415-11962-1bfjw2n env UPGRADE_TOOL=portupgrade
> UPGRADE_PORT=samba43-4.3.8 UPGRADE_PORT_VER=4.3.8 make
> ** Fix the problem and try again.
> ** Listing the failed packages (-:ignored / *:skipped / !:failed)
> ! net/samba43 (samba43-4.3.8)   (interrupted by user)
> ___
> 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"
>



-- 
*Disclaimer:*



*As implied by email protocols, the information in this message is not
confidential. Any intermediary or recipient may inspect, modify (add),
copy, forward, reply to, delete, or filter email for any purpose unless
said parties are otherwise obligated.  Nothing in this message may be
legally binding without cryptographic evidence of its integrity and/or
confidentiality.*
___
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: Library creep and additional dependencies for net/ntp?

[Dewayne Geraghty]

On 30 March 2016 at 17:09, Cy Schubert <cy.schub...@komquats.com> wrote:

> In message
> <CAGnMC6pGQ9iMZAHE-NWHboCw4MaRT+k2nXzOsXD2fkWg+kdhhw@mail.gmail.c
> om>
> , Dewayne Geraghty writes:
> > --001a114035e2660c5e052f3be038
> > Content-Type: text/plain; charset=UTF-8
> >
> > Overnight I updated /usr/ports via svnlite, rebuilt all ports and noticed
> > additional libraries and dependencies for net/ntp
> >
> > On 12th Feb, I'd built ntp-4.2.8p6.txz.  Checking the libraries, I had
> > # ldd /usr/local/sbin/ntpd
> > /usr/local/sbin/ntpd:
> > libmd.so.6 => /lib/libmd.so.6 (0x280fb000)
> > libm.so.5 => /lib/libm.so.5 (0x2810f000)
> > libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x28139000)
> > libintl.so.8 => /usr/local/lib/libintl.so.8 (0x282ca000)
> > libthr.so.3 => /lib/libthr.so.3 (0x282d3000)
> > libc.so.7 => /lib/libc.so.7 (0x282f4000)
> >
> > Today, I rebuilt ntp and found
> > # ldd /usr/local/sbin/ntpd
> > /usr/local/sbin/ntpd:
> >* libmd5.so.0 => /usr/local/lib/libmd5.so.0 (0x280fc000) - from
> > libwww*
> > libm.so.5 => /lib/libm.so.5 (0x280fe000)
> > libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x28128000)
> >* libdns_sd.so.1 => /usr/local/lib/libdns_sd.so.1 (0x282b9000) -
> > mDNSResponder*
> > libintl.so.8 => /usr/local/lib/libintl.so.8 (0x282c1000)
> > libthr.so.3 => /lib/libthr.so.3 (0x282ca000)
> > libc.so.7 => /lib/libc.so.7 (0x282eb000)
> >
> > *  libz.so.6 => /lib/libz.so.6 (0x2845e000)libssl.so.8 =>
> > /usr/local/lib/libssl.so.8 (0x28473000)*
> >
> > Checking pkg info -d ntpd
> > # pkg info -d ntp
> > ntp-4.2.8p6:
> > openssl-1.0.2_8
> > libevent2-2.0.22_1
> > gettext-runtime-0.19.6
> > libedit-3.1.20150325_1
> >
> > Can anyone shed any light on why ntp has picked up these additional
> > libraries and created additional dependencies on libwww and
> mDNSresponder?
> >
> > I'm also curious as to how *libz *and *libssl *are now required, between
> > ntp4.2.8p6 built in February vs the March build?
> >
> > By way of comparison,
> > /usr/sbin/ntpd:  (base OS ntp also ntp4.2.8p6)
> > libm.so.5 => /lib/libm.so.5 (0x8008d2000)
> > libthr.so.3 => /lib/libthr.so.3 (0x800afa000)
> > libcrypto.so.7 => /lib/libcrypto.so.7 (0x800d1f000)
> > libc.so.7 => /lib/libc.so.7 (0x801115000)
> >
> > These results are on "FreeBSD 10.3-PRERELEASE #0 r296427M:"  My options
> for
> > ntp have remained unchanged since 20140914.
>
> Actually nothing has changed. However the net/ntp ./configure script
> detects if additional libraries are already on your system, e.g. libmd5,
> libdns_sd, and uses them. For instance, my laptop has huge collection of
> packages installed to support various GUI environments under X:
>
> slippy$ ldd /usr/local/sbin/ntpd
> /usr/local/sbin/ntpd:
> libmd5.so.0 => /usr/local/lib/libmd5.so.0 (0x2c4c6000)
> libm.so.5 => /lib/libm.so.5 (0x2c6c8000)
> libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x2ca0)
> libdns_sd.so.1 => /usr/local/lib/libdns_sd.so.1 (0x2ce5e000)
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x2d066000)
> libthr.so.3 => /lib/libthr.so.3 (0x2d271000)
> libc.so.7 => /lib/libc.so.7 (0x2d496000)
> libz.so.6 => /lib/libz.so.6 (0x2d843000)
> libssl.so.7 => /usr/lib/libssl.so.7 (0x2da59000)
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x2dcc5000)
> slippy$
>
> My firewall OTOH bare bones, has very few packages and no X installed:
>
> cwfw# ldd /usr/local/sbin/ntpd
> /usr/local/sbin/ntpd:
> libmd.so.6 => /lib/libmd.so.6 (0x8008ba000)
> libm.so.5 => /lib/libm.so.5 (0x800aca000)
> libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x800e0)
> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x801253000)
> libthr.so.3 => /lib/libthr.so.3 (0x80145e000)
> libc.so.7 => /lib/libc.so.7 (0x801683000)
> cwfw#
>
> In my poudriere build repo, the cached package (it's still building), ntpd
> references:
>
> cwsys$ ldd /tmp/usr/local/sbin/ntpd
> /tmp/usr/local/sbin/ntpd:
> libmd.so.6 => /lib/libmd.so.6 (0x2c4c4000)
> libm.so.5 => /lib/libm.so.5 (0x2c6d4000)
> libcrypto.so.7 => /lib/libcrypto.so.7 (0x2c8fd000)
> libthr.so.3 => /lib/libthr.so.3 (0x2ccf3000)
>

Library creep and additional dependencies for net/ntp?

[Dewayne Geraghty]

Overnight I updated /usr/ports via svnlite, rebuilt all ports and noticed
additional libraries and dependencies for net/ntp

On 12th Feb, I'd built ntp-4.2.8p6.txz.  Checking the libraries, I had
# ldd /usr/local/sbin/ntpd
/usr/local/sbin/ntpd:
libmd.so.6 => /lib/libmd.so.6 (0x280fb000)
libm.so.5 => /lib/libm.so.5 (0x2810f000)
libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x28139000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x282ca000)
libthr.so.3 => /lib/libthr.so.3 (0x282d3000)
libc.so.7 => /lib/libc.so.7 (0x282f4000)

Today, I rebuilt ntp and found
# ldd /usr/local/sbin/ntpd
/usr/local/sbin/ntpd:
   * libmd5.so.0 => /usr/local/lib/libmd5.so.0 (0x280fc000) - from
libwww*
libm.so.5 => /lib/libm.so.5 (0x280fe000)
libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x28128000)
   * libdns_sd.so.1 => /usr/local/lib/libdns_sd.so.1 (0x282b9000) -
mDNSResponder*
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x282c1000)
libthr.so.3 => /lib/libthr.so.3 (0x282ca000)
libc.so.7 => /lib/libc.so.7 (0x282eb000)

*  libz.so.6 => /lib/libz.so.6 (0x2845e000)libssl.so.8 =>
/usr/local/lib/libssl.so.8 (0x28473000)*

Checking pkg info -d ntpd
# pkg info -d ntp
ntp-4.2.8p6:
openssl-1.0.2_8
libevent2-2.0.22_1
gettext-runtime-0.19.6
libedit-3.1.20150325_1

Can anyone shed any light on why ntp has picked up these additional
libraries and created additional dependencies on libwww and mDNSresponder?

I'm also curious as to how *libz *and *libssl *are now required, between
ntp4.2.8p6 built in February vs the March build?

By way of comparison,
/usr/sbin/ntpd:  (base OS ntp also ntp4.2.8p6)
libm.so.5 => /lib/libm.so.5 (0x8008d2000)
libthr.so.3 => /lib/libthr.so.3 (0x800afa000)
libcrypto.so.7 => /lib/libcrypto.so.7 (0x800d1f000)
libc.so.7 => /lib/libc.so.7 (0x801115000)

These results are on "FreeBSD 10.3-PRERELEASE #0 r296427M:"  My options for
ntp have remained unchanged since 20140914.

Regards, Dewayne
___
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: Moving to synth (was: Removing documentation)

[Dewayne Geraghty]

On 9 February 2016 at 11:58, Michel Talon  wrote:

> Greg 'groggy' Lehey wrote:
>
> > So how would things improve in this respect if we change to synth?
> > There we need a maintainer who understands Ada.  OK, at the moment
> > that's you.  But what happens when you relinquish maintainership for
> > whatever reason?
>
> > My feeling on the matter is that there's space for more than one tool,
> > as Mathias suggested.  But I think it would help synth to have
> > user-oriented documentation similar to that for portmaster or
> > portupgrade ("to achieve this, do this...").  I could see this as a
> > good addition to the handbook (4.5.3.3).  A(n objective) discussion of
> > the pros and cons of the three alternatives would also be useful.
>
> Having been in the situation of doing such a discussion some 10 years ago,
> when portupgrade and portmaster were the fashionable tools, and pkgng
> did not exist, i was very interested to discover this tool synth that i
> had never heard of.
>
> Of course unable to find it in the ports i finally found it was a
> DragonFly port very recently
> ported to FreeBSD, and then that it was written in Ada. Next task find the
> Ada compiler.
> Needless to say, no port named ada under lang, finally found it was
> gcc5-aux. Downloaded
> the packages for gcc5-aux and ncurses the port for synth from SVN
> repository, and began compiling.
> Somewhere the build broke because of unsupported
> pragma Suppress (Tampering_Check);
> but after removing this line i had finally a brand new synth.
> Frankly one first prerequisite for having this discussion is that the
> *package* synth is ready to be downloaded
> and people don't have to go through this ordeal.
>
> Immediately i wanted to test it on a port which is not too much connected
> to other stuff
> so i did after synth configure
> synth status
> and
> synth build lang/chicken.
> The first one bombed since there was a problem with the options on some
> port. I solved it as required and
> synth status gave some answer.
> Then the second one decided it needed to recompile 6 ports and started
> doing it. The nice curses
> screen appeared, which for sure is beautiful but doesn't say much about
> what is going on.
> Fortunately i discovered beautiful logs under /var/log/synth, and
> apparently the 6 builds went OK.
> Then it asked me to scan the ports tree which took ages, finally to
> discover that my builds failed
> "option check" and do nothing.
> This prompted me to try understanding what the crap synth was doing, and i
> finally found that the
> "repository" was the place under /usr/obj where synth moved all the
> packages it had compiled, that
> there was a ton of mounts under /usr/obj reproducing a clean room freebsd
> system to compile the port.
> That the long operation above consisted in running make -V in a lot of
> ports to discover the value
> of certain variables which is usually done to compute the INDEX in
> /usr/ports, and that, due to the
> above failure the corresponding packages had been removed from the
> repository.  Part of this information
> i obtained by looking at the code which is surprisingly readable for
> someone who doesn't know ada.
> The exact
>
> This little story leads me to a second prerequisite, produce a more
> complete documentation describing exactly
> what synth does, how to solve buggy situations etc. The argument "the soft
> can be directly used by newbies
> without documentation" i don't buy.
>
> Finally lets us target the center. I like very much the idea of using
> these mounts to compile the packages.
> It is fast and simpler than jails. I also like the idea of doing several
> things simultaneously. Is it really necessary
> to use thousands and thousands of lines of code to do that? Concerning the
> objection that portmaster
> has no dependency while synth has dependencies i think this objection has
> no merit since it is a binary
> which will run without problem, its data structures being in memory. This
> is in great contrast with portupgrade
> where if you upgrade ruby when portupgrade runs, you are in a mess (or if
> you upgrade the db that
> portupgrade uses). I have not seen if synth checks for circular
> dependencies, portupgrade certainly
> did it.
>
> In summary, synth seems to be a very nice work. As an exercice in shell
> writing, portmaster is
> certainly a master's work, but it is a poor substitute to a real
> management tool. Portupgrade
> was more ambitious, but had too many problems and was incredibly slow. So
> i think J. Marino
> is right, better bite the bullet as soon as possible, polish whatever
> needs polishing, update the documentation
> and go ahead.  The fact that synth is written in a relatively obscure
> language can be a deterrent,
> but in fact it is very readable by non ada practitioners.
>
>
>
>
>
>
>
>
> --
> Michel Talon
>
> ___
> freebsd-ports@freebsd.org mailing list
> 

Re: gnupg-1.4.20.tar.bz2.sig not available by FTP

[Dewayne Geraghty]

The distinfo needs to be
SHA256 (gnupg-1.4.20.tar.bz2) =
04988b1030fa28ddf961ca8ff6f0f8984e0cddcb1eb02859d5d8fe0fe237edcc
SIZE (gnupg-1.4.20.tar.bz2) = 3692881
SHA256 (gnupg-1.4.20.tar.bz2.sig) =
60699efc9c9546722c04aba69fff874aaf5dacd7d4637238cb8d66960963f843
SIZE (gnupg-1.4.20.tar.bz2.sig) = 574


On 24 December 2015 at 10:35, JosC  wrote:

> On 24-12-2015 0:00, JosC wrote:
>
>> Dear port maintainer,
>>
>> The port update of gnupg-1.4.20.tar.bz2.sig seems to bump.
>>
>> => Attempting to fetch
>> ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.20.tar.bz2.sig
>> fetch: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.20.tar.bz2.sig: size
>> mismatch: expected 287, actual 574
>>
>> => Attempting to fetch
>> http://mirror.tje.me.uk/pub/mirrors/ftp.gnupg.org/gnupg/gnupg-1.4.20.tar.bz2.sig
>> fetch:
>> http://mirror.tje.me.uk/pub/mirrors/ftp.gnupg.org/gnupg/gnupg-1.4.20.tar.bz2.sig:
>> Not Found
>>
>> => Attempting to fetch
>> http://distcache.FreeBSD.org/ports-distfiles/gnupg-1.4.20.tar.bz2.sig
>> fetch:
>> http://distcache.FreeBSD.org/ports-distfiles/gnupg-1.4.20.tar.bz2.sig:
>> Not Found
>>
>> => Couldn't fetch it - please try to retrieve this
>> => port manually into /usr/ports/distfiles// and try again.
>>
>> I tried to use the ftp location @
> https://lists.gnupg.org/pipermail/gnupg-announce/2015q4/000382.html
>
>  ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.20.tar.bz2   (3606k)
>  ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.20.tar.bz2.sig
>
> but the files I downloaded seem to have a mismatch in size too, so that I
> get the first two error lines from above.
>
> BR, Jos Chrispijn
>
>
>
> ___
> 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"

pkg info -B not listing all shared libraries

[Dewayne Geraghty]

Does "pkg info -B $pkg_name" only list the shared packages from the first
level of supporting "ports", or is it supposed to be all shared (ports')
libraries that are used?

While reviewing the composition of packages, I noticed that not all shared
libraries which are used, appear in the output from "pkg info -B $pkg_name".

Lets use curl as an example.  The library /usr/local/lib/libintl.so.8 is
missing from
# pkg info -B curl-7.45.0
curl-7.45.0:
libheimntlm.so.0
libssh2.so.1
libcrypto.so.8
libheimbase.so.1
libkrb5.so.26
libhx509.so.5
libasn1.so.8
libgssapi.so.3
libcom_err.so.1
libroken.so.18
libssl.so.8
libwind.so.0

However
# ldd `which curl`
/usr/local/bin/curl:
libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x800848000)
libssl.so.8 => /usr/local/lib/libssl.so.8 (0x800ab9000)
libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x800d25000)
libz.so.6 => /lib/libz.so.6 (0x801139000)
libkrb5.so.26 => /usr/local/lib/heimdal/libkrb5.so.26 (0x80134f000)
libgssapi.so.3 => /usr/local/lib/heimdal/libgssapi.so.3
(0x8015ca000)
libthr.so.3 => /lib/libthr.so.3 (0x801803000)
libc.so.7 => /lib/libc.so.7 (0x801a28000)
libssh2.so.1 => /usr/local/lib/libssh2.so.1 (0x801dcc000)
libheimntlm.so.0 => /usr/local/lib/heimdal/libheimntlm.so.0
(0x801ff4000)
libhx509.so.5 => /usr/local/lib/heimdal/libhx509.so.5 (0x8021fa000)
libcom_err.so.1 => /usr/local/lib/heimdal/libcom_err.so.1
(0x802443000)
libasn1.so.8 => /usr/local/lib/heimdal/libasn1.so.8 (0x802646000)
libwind.so.0 => /usr/local/lib/heimdal/libwind.so.0 (0x8028e4000)
libheimbase.so.1 => /usr/local/lib/heimdal/libheimbase.so.1
(0x802b0c000)
libroken.so.18 => /usr/local/lib/heimdal/libroken.so.18
(0x802d1)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x802f21000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x803141000)

I appreciate that libintl.so.8 is part of the gettext-runtime, a second
tier of inclusion (by heimdal); however both the output from "pkg info -B"
and the documentation either (respectively) imply or state that "-B Display
all shared libraries used by pkg-name".

Perhaps this can be addressed in the documentation by adding "only shared
libraries from the first level of dependencies upon other ports  are
included", which also accommodates the missing system libraries (libz,
libcrypt, ...)?

[I came across this while looking for efficient ways to prune unnecessary
libraries from the system.]
Regards, Dewayne.
___
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: squid default options

[Dewayne Geraghty]

Pavel,
Thank-you for providing the opportunity to provide feedback.

I think that there could be a reasonable argument for:
1) Turning on all options to ensure that the port will build, and most
"ports consumers" can expect the functionality they need. Presumes that the
consumer will customise the port.
2) Enable the minimal useful options, so that out of the box there is
minimal functionality. Assuming basic/no network complexity. Might be
sufficient for people starting their FreeBSD journey.
3) Enable options that provide the best coverage for the most common
scenario of use, carries assumptions of network and
authentication/authorisation use.
4) Turn on only those options that the maintainer uses, as that is what has
been thoroughly tested.
5) Turn off all options, forcing a consumer to enable what they need.
(Largely counter-productive)

Over the years I've seen options 1-4 being used, however I would "vote" for
3 - most common (sense) use case  :)

If using transparent proxying requires a custom kernel, then I think its
reasonable to expect that the port/package should also be customised to
suit the FW choice.

Should we care about what FreeBSD "distributions" require?  Yes, to the
extent that the options that they require, function correctly; particularly
when the requirements are mutually exclusive.

To your point about kerberos, I build ports against the heimdal port, and
the package content is correctly linked, per.
# ldd /usr/local/libexec/squid/negotiate_kerberos_auth
/usr/local/libexec/squid/negotiate_kerberos_auth:
libheimntlm.so.0 => /usr/local/lib/heimdal/libheimntlm.so.0
(0x2807f000)
libhx509.so.5 => /usr/local/lib/heimdal/libhx509.so.5 (0x28085000)
libcom_err.so.1 => /usr/local/lib/heimdal/libcom_err.so.1
(0x280c4000)
...

As FYI, this is what I enable
 AUTH_KERB=on: Install Kerberos authentication helpers
 AUTH_LDAP=on: Install LDAP authentication helpers
 AUTH_SASL=on: Install SASL authentication helpers
 AUTH_SMB=on: Install SMB auth. helpers (req. Samba)
 EXAMPLES=on: Build and/or install examples
 FS_AUFS=on: Enable AUFS (async-io) support
 IPV6=on: IPv6 protocol support
 KQUEUE=on: Enable kqueue(2) support
 SSL=on: Enable SSL gatewaying support
 SSL_CRTD=on: Use ssl_crtd to handle SSL cert requests
and I would not expect these options to be enabled by default ;)

Thank-you for maintaining squidXX it is a port with a lot of useful options.

Kind regards, Dewayne
PS Selecting the language option(s) would be nice to reduce the package
size, perhaps error_dirs?= and error_dir_links?=  but I digress.

On 6 December 2015 at 20:44, Pavel Timofeev  wrote:

> Hi!
> I'm a maintainer of squid port and I'd like to ask you about default
> squid options turned on by default.
> Squid 4 is in release candidate stage now and we already have an
> initial port for it here
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203860.
>
> So, how do you think, what options should be turned on by default?
>
> I think the main idea should be if option doesn't invoke any
> additional dependency it should be turned on.
> However, there are options like TP_{IPF,IPFW,PF} which mean
> 'Transparent proxying with {IPF,IPFW,PF}'. They don't invoke any
> dependency.
> If you have GENERIC kernel and world, of course.
> Well, I know, we can't satisfy everyone, so default option set have to
> be guided by common sense and  appropriate for the most.
>
> But there are FreeBSD based OSs like pfSense, FreeNAS, etc..
> Should we think/care about them? To be honest I've never used them. I
> can misunderstand something.
>
> Same story with GSSAPI_BASE. It needs kerberos from base system, that
> can absent in others FreeBSD bases OSs.
> ___
> 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"

sendmail patch fixes sasl kerberos

[Dewayne Geraghty]

I've noticed that a contributor's patch was included in the sendmail
update for 10.1Stable this morning:
/usr/src/contrib/sendmail/contrib/AuthRealm.p0.

This patch enbles sasl to function properly in a kerberised
environment.  Without the patch the server's hostname is taken/used  as
the realm... 

Can it be included in mail/sendmail/files? 

Aside: The patch date on my *local*
/usr/ports/mail/sendmail/files/patch-gssapi is Feb 1, 2014, around the
time that john.marsh...@riverwillow.com.au provided the patch upstream.

Regards, Dewayne


___
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: mail/postfix default build options request: SASL

[Dewayne Geraghty]

On 7/07/2015 3:45 PM, Kubilay Kocak wrote:
 On 7/07/2015 3:31 PM, Gregory Orange wrote:
 Hi Olli and ports@,

 I don't know if this is a helpful forum to raise it, but I would like to
 request that SASL be enabled in the default build options for
 mail/postfix. I am attempting to use binary-only packages wherever
 possible, and so far this is the first where I currently have to build
 it myself.

 I would have thought SASL is in use across many Postfix installations,
 but of course I could be wrong. I was tempted to try out
 SMTP-after-IMAP, but since Postfix has the support, I think SASL is far
 cleaner.

 Would any responders please include me in the CC? I am not subscribed to
 the list.

 Thanks,
 Greg.

 If consensus can't be achieved or there is a good reason not to enable
 this by default, then postfix-sasl as a slave port may be a desirable
 alternative, which I believe has existed in the past.

 I'm generally:

  +1 on security related options enabled by default
  +1 on OPTIONS_DEFAULT matching upstream defaults
  -1 on OPTIONS_DEFAULT introducing large dependency sets

 ./koobs
 ___
 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
I'm with you on that one koobs.  Everything we build includes kerberos
/or tls or sasl; but it has a complexity/management cost.  A slave port
would be a good short term option pending
flavours/variants/something-with-strong-authentication.  This would
probably help postfix to be comparable to sendmail+tls+sasl2+ldap?

___
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: Cups-base will not build

[Dewayne Geraghty]

On 27/06/2015 4:06 PM, Leslie Jensen wrote:
 I've tried with MAKE_JOBS_UNSAFE=yes but it does not do it!

 Any suggestions?

 Thanks

 /Leslie


  -L/usr/local/lib -lgnutls-lpthread -lm -lcrypt   -lz -lz
 ../cups/libcups.a(http-support.o): In function `_httpResolveURI':
 /usr/ports/print/cups-client/work/cups-2.0.3/cups/http-support.c:1702:
 undefined reference to `DNSServiceCreateConnection'
 /usr/ports/print/cups-client/work/cups-2.0.3/cups/http-support.c:1711:
 undefined reference to `DNSServiceResolve'
 /usr/ports/print/cups-client/work/cups-2.0.3/cups/http-support.c:1741:
 undefined reference to `DNSServiceRefSockFD'
 /usr/ports/print/cups-client/work/cups-2.0.3/cups/http-support.c:1833:
 undefined reference to `DNSServiceProcessResult'
 /usr/ports/print/cups-client/work/cups-2.0.3/cups/http-support.c:1811:
 undefined reference to `DNSServiceResolve'
 /usr/ports/print/cups-client/work/cups-2.0.3/cups/http-support.c:1798:
 undefined reference to `DNSServiceResolve'
 /usr/ports/print/cups-client/work/cups-2.0.3/cups/http-support.c:1845:
 undefined reference to `DNSServiceRefDeallocate'
 /usr/ports/print/cups-client/work/cups-2.0.3/cups/http-support.c:1847:
 undefined reference to `DNSServiceRefDeallocate'
 /usr/ports/print/cups-client/work/cups-2.0.3/cups/http-support.c:1849:
 undefined reference to `DNSServiceRefDeallocate'
 /usr/ports/print/cups-client/work/cups-2.0.3/cups/http-support.c:1852:
 undefined reference to `DNSServiceRefDeallocate'
 /usr/ports/print/cups-client/work/cups-2.0.3/cups/http-support.c:1855:
 undefined reference to `DNSServiceRefDeallocate'
 ../cups/libcups.a(http-support.o): In function `http_resolve_cb':
 /usr/ports/print/cups-client/work/cups-2.0.3/cups/http-support.c:2159:
 undefined reference to `TXTRecordGetValuePtr'
 /usr/ports/print/cups-client/work/cups-2.0.3/cups/http-support.c:2204:
 undefined reference to `TXTRecordGetValuePtr'
 /usr/ports/print/cups-client/work/cups-2.0.3/cups/http-support.c:2215:
 undefined reference to `TXTRecordGetValuePtr'
 cc: error: linker command failed with exit code 1 (use -v to see invocation)
 Makefile:192: receptet f?r m?let ?ippserver? misslyckades
 gmake[3]: *** [ippserver] Fel 1
 gmake[3]: L?mnar katalogen ?/usr/ports/print/cups-base/work/cups-2.0.3/test?
 Makefile:31: receptet f?r m?let ?all? misslyckades
 gmake[2]: *** [all] Fel 1
 gmake[2]: L?mnar katalogen ?/usr/ports/print/cups-base/work/cups-2.0.3?
 *** Error code 1

 Stop.
 make[1]: stopped in /usr/ports/print/cups-base
 *** Error code 1

 Stop.
 make: stopped in /usr/ports/print/cups-base

 ===
 ___

Leslie,
You'll need to provide further details. For example:
# uname -aKU
FreeBSD b2.hs 10.1-STABLE FreeBSD 10.1-STABLE #0 r284339M: Sun Jun 14
07:17:24 AEST 2015
root@hathor:/usr/obj/prod/100102/D/K8/usr/src/sys/hqdev-amd64-smp-vga   

amd64 1001518 1001518

# svnlite info /usr/ports | egrep Rev|Date
Revision: 390691
Last Changed Rev: 390691
Last Changed Date: 2015-06-27 15:45:12 +1000 (Sat, 27 Jun 2015)

# cc -v
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.1
Thread model: posix
Selected GCC installation:

# make -DBATCH  showconfig
=== The following configuration options are available for
cups-base-2.0.3_3:
 DBUS=off: D-Bus IPC system support
 ICONS=off: Desktop icons
 LIBPAPER=on: Paper size selection support via libpaper
 LIBUSB=off: USB support
 PAM=off: Pluggable authentication module support
 XDG_OPEN=off: Build with XDG_OPEN as browser
 Interpreters for web interfaces
 JAVA=off: Java platform support
 PERL=off: Perl scripting language support
 PHP=off: PHP bindings or support
 PYTHON=off: Python bindings or support
 Zeroconf support: you can only select none or one of them
 AVAHI=off: Zeroconf support via Avahi
 MDNSRESPONDER=on: Zeroconf support via mDNSResponder
=== Use 'make config' to modify these settings

How I tested, in my case to see if cups-base was going to be a problem:
# make -DBATCH   clean deinstall package
...
=== Staging rc.d startup script(s)
===  Building package for cups-base-2.0.3_3

where USE_K8 passes customisations for the target host, like CCFLAGS+=
-march=core-avx-i that aren't really relevant.  (aside: portmaster is
how I rebuild everything)

So thanks for the heads up, but, with the config options that I'm using
(ie NOT avahi), it looks ok...

Dewayne.

___
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: cmake: missing library /usr/local/lib/libjsoncpp.so

[Dewayne Geraghty]

On 19/06/2015 8:16 AM, Kevin Oberman wrote:
 On Thu, Jun 18, 2015 at 5:45 AM, Dr. Peter Voigt pvo...@uos.de wrote:

 Sorry for incomplete subject.


 On Thu, 18 Jun 2015 08:31:29 +0200
 Dr. Peter Voigt pvo...@uos.de wrote:

 When building latest devel/cmake on 10.1-RELEASE-p13 (amd64)

 # portmaster --no-confirm --no-term-title -D -G cmake

 there is an error about missing library /usr/local/lib/libjsoncpp.so

 ...

 ===  Installing for cmake-3.2.3
 ===  Checking if cmake already installed
 ===   Registering installation for cmake-3.2.3 as automatic
 (cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/ccmake
 - required shared library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/cmake -
 required shared library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/cpack -
 required shared library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/ports/devel/cmake/work/stage//usr/local/bin/ctest -
 required shared library /usr/local/lib/libjsoncpp.so not found
 Installing cmake-3.2.3...

 === Re-installation of cmake-3.2.3 succeeded

 === The following actions were performed:
 Re-installation of cmake-modules-3.2.3
 Re-installation of cmake-3.2.3

 However:

 # ls -l /usr/local/lib/libjsoncpp*
 -rw-r--r-- 1 root wheel 535316 Jun 17
 20:22 /usr/local/lib/libjsoncpp.a lrwxr-xr-x 1 root wheel 15 Jun
 17 20:22 /usr/local/lib/libjsoncpp.so - libjsoncpp.so.0 -r--r--r-- 1
 root wheel 348376 Jun 17 20:22 /usr/local/lib/libjsoncpp.so.0

 Build finished just fine but during installation registration of
 shared libraries failed. This can be verified with pkg:

 # pkg check -Bnv cmake
 [1/1] Checking cmake-3.2.3: shared
 libraries...(cmake-3.2.3) /usr/local/bin/ccmake - required shared
 library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/local/bin/cmake - required shared
 library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/local/bin/cpack - required shared
 library /usr/local/lib/libjsoncpp.so not found
 (cmake-3.2.3) /usr/local/bin/ctest - required shared
 library /usr/local/lib/libjsoncpp.so not found done

 Is this a known issue or should I create a PR?

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

 Peter,

 Very odd. You confirm that the file is present, but pkg does not seem to
 know it. I can confirm seeing the same thing, but it is a bogus error as
 rtld can successfully load and run cmake and ldd shows it as resolving
 correctly.. Further, the pkg db does know about it as:
 # pkg which /usr/local/lib/libjsoncpp.so
 /usr/local/lib/libjsoncpp.so was installed by package jsoncpp-0.6.0.r2_1

 It looks like a bug and it affects some people, but it looks most likely
 to be a pkg issue of some sort as the sharable is present and rtld seems
 happy with it.
 --
 Kevin Oberman, Network Engineer, Retired
 E-mail: rkober...@gmail.com
 PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
 ___
 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



Confirmed on (amd64) 10.1S built on 14th June.

Unfortunately on the 10.1S i386 using either clang or gcc;  cmake 3.2.3
doesn't build.

clang

/var/ports/usr/ports/devel/cmake/work/cmake-3.2.3/Source/cmGlobalGenerator.cxx:(.text+0x1237d):
undefined reference to `Json::operator(std::__1::basic_ostreamchar,
std::__1::char_traitschar , Json::Value const)'
c++: error: linker command failed with exit code 1 (use -v to see
invocation)
*** Error code 1


And using lang/gcc

/usr/local/libexec/ccache/gcc48 -O2 -pipe -g0 -ggdb0 -DSTRIP_FBSDID
-march=prescott -mtune=prescott  -Wl,-rpath=/usr/local/lib/gcc48
-fno-strict-aliasing
-I/var/ports/usr/ports/devel/cmake/work/cmake-3.2.3/Bootstrap.cmk
-I/var/ports/usr/ports/devel/cmake/work/cmake-3.2.3/Source  
-I/var/ports/usr/ports/devel/cmake/work/cmake-3.2.3/Bootstrap.cmk
-DKWSYS_NAMESPACE=cmsys  -c
/var/ports/usr/ports/devel/cmake/work/cmake-3.2.3/Source/kwsys/System.c
-o System.o
--- cmGlobalNinjaGenerator.o ---
In file included from
/var/ports/usr/ports/devel/cmake/work/cmake-3.2.3/Source/cmGlobalNinjaGenerator.cxx:14:0:
/var/ports/usr/ports/devel/cmake/work/cmake-3.2.3/Source/cmGeneratorExpressionEvaluationFile.h:39:64:
error: 'mode_t' has not been declared
   std::mapstd::string, std::string outputFiles, mode_t
perm);
^
*** [cmGlobalNinjaGenerator.o] Error code 1

make[1]: stopped in
/var/ports/usr/ports/devel/cmake/work/cmake-3.2.3/Bootstrap.cmk
1 error

The build also fails after the ccache, WRKDIRPREFIX  are cleared.  A
revert to cmake and 

libressl vs openssl - surprises

[Dewayne Geraghty]

Having read that PC-BSD are/have moved to using libressl in their base
system, it was time to have a look.  So I updated my ports tree, built
in sequence openssl, tested and then built libressl and tested.
Platform xeon 1230Lv3 (1.8GHz, 8 logical cores), FreeBSD 10.1 built
fresh last night.

Summary:
openssl aes256 encrypt/decrypt 160MB file: 0.686157 secs (244509876
bytes/sec)
libressl aes256 encrypt/decrypt 160MB file:  1.768195 secs (94883282
bytes/sec)

openssl speed -evp aes-256-cbc: 74691.70k   288535.11k   876427.49k 
5323319.66k 29095886.85k
libressl, speed -evp aes-256-cbc:  95036.12k   103030.42k   104839.86k  
105190.19k   105840.81k

Please note that I added the following to each Makefile, immediately
after CPE_VENDOR line
CFLAGS+=-O3
I also have the options for openssl  sse2 shared threads. There are no
options for libressl.

As I use crypto/ssl extensively it seems that migrating to the libressl
port will reduce the performance of dependent ports.  Are others seeing
similar performance?  Does anyone have any suggestions for raising the
performance of libressl?

On the bright side, libressl includes ChaCha20-Poly1305 and other
ciphers contrary to the openbsd man page.

Refs:
1. http://blog.pcbsd.org/2015/03/a-look-at-the-upcoming-features-for-10-1-2/
2.
https://forums.freebsd.org/threads/replace-openssl-with-libressl.47203/
use of OPENSSL_PORT=security/libressl


Detail:
I ran the speed and encrypt/decrypt cycle three times for each and took
the middle score from each for comparison.

For reference
dd if=/dev/zero bs=1m count=160  /dev/null ; # 0.016084 secs
(10431025952 bytes/sec)

openssl
--
dd if=/dev/zero bs=1m count=160 | openssl enc -e -aes-256-cbc -pass
pass:p1 | openssl enc -aes-256-cbc -d -pass pass:p1  /dev/null
160+0 records in
160+0 records out
167772160 bytes transferred in 0.686157 secs (244509876 bytes/sec)

openssl speed -evp aes-256-cbc
Doing aes-256-cbc for 3s on 16 size blocks: 1568234 aes-256-cbc's in 0.34s
Doing aes-256-cbc for 3s on 64 size blocks: 1479306 aes-256-cbc's in 0.33s
Doing aes-256-cbc for 3s on 256 size blocks: 1203590 aes-256-cbc's in 0.35s
Doing aes-256-cbc for 3s on 1024 size blocks: 690433 aes-256-cbc's in 0.13s
Doing aes-256-cbc for 3s on 8192 size blocks: 138740 aes-256-cbc's in 0.04s
OpenSSL 1.0.2c 12 Jun 2015
built on: reproducible build, date unspecified
options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,16,int)
aes(partial) idea(int) blowfish(idx)
compiler: /usr/local/libexec/ccache/cc -I. -I.. -I../include  -fPIC
-DOPENSSL_PIC -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -Wall -O2 -pipe -g0 -ggdb0
-DSTRIP_FBSDID -O3 -march=core-avx-i  -O3 -fno-strict-aliasing
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192
bytes
aes-256-cbc  74691.70k   288535.11k   876427.49k  5323319.66k
29095886.85k

libressl
-
# dd if=/dev/zero bs=1m count=160 | openssl enc -e -aes-256-cbc -pass
pass:p1 | openssl enc -aes-256-cbc -d -pass pass:p1  /dev/null
160+0 records in
160+0 records out
167772160 bytes transferred in 1.768195 secs (94883282 bytes/sec)

# openssl speed -evp aes-256-cbc
Doing aes-256-cbc for 3s on 16 size blocks: 18097699 aes-256-cbc's in 3.05s
Doing aes-256-cbc for 3s on 64 size blocks: 4829551 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 256 size blocks: 1241390 aes-256-cbc's in 3.03s
Doing aes-256-cbc for 3s on 1024 size blocks: 310582 aes-256-cbc's in 3.02s
Doing aes-256-cbc for 3s on 8192 size blocks: 38861 aes-256-cbc's in 3.01s
LibreSSL 2.1.7
built on: date not available
options:bn(64,64) rc4(ptr,int) des(idx,cisc,16,int) aes(partial)
idea(int) blowfish(idx)
compiler: information not available
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192
bytes
aes-256-cbc  95036.12k   103030.42k   104839.86k   105190.19k  
105840.81k

___
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

rubygem databases conflicting file placement

[Dewayne Geraghty]

As there have been a few updates to rubygem ports occurring, would someone be 
able to look into why these ports:
/usr/ports/databases/rubygem-arel3  2014-08-27
/usr/ports/databases/rubygem-activerecord 2015-04-03
place files into the same location and cause conflict?  I've added the dates of 
when they were last modified.

They're preventing metasploit from being built.

Please refer to the last entry in 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199107

Thank-you.
Dewayne.

___
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: Broken _DEPENDS logic

[Dewayne Geraghty]

On 4/05/2015 7:38 AM, Matthew Seaman wrote:
 On 03/05/2015 21:08, Lowell Gilbert wrote:
 But, generally, the answer to your question is no, becuase it is often
 the case that more than one port can serve as a dependency for another
 port. Your suggestion amounts to saying that only one port can satisfy a
 dependency for another port, which is not the case.
 You're correct as far as the ports goes, but not when you're dealing
 with precompiled packages.  Once you've built the package, the
 dependency on the specific version of the other port is baked into it.
 That's something which is likely to change in the not too distant
 future, but it's going to mean some fundamental changes in the ports in
 order to bring about.

 At the moment, therefore, the advice for pkg users when you want to make
 customizations like eg. using a different version of postfix is to set
 up your onw instance of poudriere and build your own.

   Cheers,

   Matthew


I read Lowell's issue as indirectly suggesting an enhancement to the
packaging system.

For the sake of the discussion, lets assume a dependency hierarchy of: X
depends upon Y.
While building X, rather than assume the prefix for Y, and test for the
existence of a file installed by Y (and this is very often used), use
pkg to ascertain the dependency's origin and lookup the prefix for Y,
prior to the test.

And please can we not assume that everyone is using poudriere.

Regards, Dewayne.
___
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

metasploit dependencies aren't installing due to contention

[Dewayne Geraghty]

I'm not entirely sure who should pick this up but I filed a PR on
security/metasploit failing to build, due to conflicting placement of
subordinate ports.  Both devel/rubygem-i18n and
archivers/rubygem-rubyzip are trying to place files in the same location.

pkg-static: rubygem-i18n-0.7.0,2 conflicts with rubygem-rubyzip-1.1.6
(installs files into the same place).  Problematic file:
/usr/local/lib/ruby/gems/2.1/doc/rubyzip-1.1.6/rdoc/Zip/CentralDirectory.html
*** Error code 70

But when these are worked around, then
pkg-static: rubygem-activemodel-3.2.21 conflicts with
rubygem-json_pure-1.8.2 (installs files into the same place). 
Problematic file:
/usr/local/lib/ruby/gems/2.1/doc/activemodel-3.2.21/rdoc/ActiveModel/AttributeMethods/ClassMethods/AttributeMethodMatcher.html
*** Error code 70
occurs.

Further details in the PR
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199107

The last time I successfully built metaploit was Feb 22, on FreeBSD10.1
stable amd64.  I usually update stable the day before we rebuild all
ports - its a historical thing.

I hope that someone may be able to assist?  I'm really just a user of
the metasploit tool and all I know about ruby is that its something that
my wife would like to have. :)

Regards, Dewayne.

___
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: openssl and bash libcrypto

[Dewayne Geraghty]

On 9/04/2015 10:02 PM, Kimmo Paasiala wrote:
 On Thu, Apr 9, 2015 at 1:42 PM, Aristedes Maniatis a...@ish.com.au wrote:
 Starting in the last week or so, several different applications are 
 exhibiting the same symptoms of broken libcrypto libraries.

 (gdb) core bash.core
 Core was generated by `bash'.
 Program terminated with signal 11, Segmentation fault.

 (gdb) bt
 #0  0x0008029cafe5 in OPENSSL_ia32_cpuid () from 
 /usr/local/lib/libcrypto.so.8
 #1  0x0008033cf0b9 in OPENSSL_ia32cap_loc () from /lib/libcrypto.so.7
 #2  0x0008032d584e in _init () from /lib/libcrypto.so.7
 #3  0x7fffd7c0 in ?? ()
 #4  0x0008006d66bf in r_debug_state () from /libexec/ld-elf.so.1
 #5  0x0008006dad87 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1
 #6  0x0008006d7ad3 in dlopen () from /libexec/ld-elf.so.1
 #7  0x000800e5c436 in _nsdbtaddsrc () from /lib/libc.so.7
 #8  0x000800e563c9 in _nsyyparse () from /lib/libc.so.7
 #9  0x000800e5cab1 in nsdispatch () from /lib/libc.so.7
 #10 0x000800e49ebe in getpwuid () from /lib/libc.so.7
 #11 0x000800e49cbf in getpwnam () from /lib/libc.so.7


 Although that symptom is in bash, I've got the exact same symptoms in 
 asterisk. The builds are done in poudriere with the make flags:

 WITH_OPENSSL_PORT=yes


 I've tried updating to the latest 10.1-RELEASE-p6, although it is possible 
 that that is exactly what caused the problem in the first place when the 
 poudriere jail was updated to that release.

 The function calls mention ia32 but this box is purely 64bit.


 I've seen recent discussions about the problems that confusion between core 
 openssl and ports openssl can cause. But I can't for the life of me figure 
 how to avoid this problem.

 * Should bash be built with Build static executables and/or libraries?
 * Should I stop trying to use openssl from ports until this is fixed?
 * Why is /lib/libcrypto.so.7 calling /usr/local/lib/libcrypto.so.8 ?

 I've tried so many different combinations of settings, I don't know what to 
 try next.

 Thanks
 Ari


 --
 --
 Aristedes Maniatis
 ish
 http://www.ish.com.au
 Level 1, 30 Wilson Street Newtown 2042 Australia
 phone +61 2 9550 5001   fax +61 2 9550 4001
 GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

 You could build world with WITHOUT_OPENSSL but that would also disable
 some other needed pieces such as OpenSSH and you'd have to install
 them from ports.

 WITHOUT_OPENSSL
  Set to not build OpenSSL.  When set, it also enforces the follow‐
  ing options:

  WITHOUT_KERBEROS
  WITHOUT_KERBEROS_SUPPORT
  WITHOUT_OPENSSH

  When set, the following options are also in effect:

  WITHOUT_GSSAPI (unless WITH_GSSAPI is set explicitly)
 ___
 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



Take care, as: geli, pkg and tar will fail to build, the latter due to
libarchive, and libfetch as also being affected.  I went down this path
a few years ago, but stopped when the ability to install
security/openssl into /usr was instituted.  (geli only needs openssl
headers).  As an FYI, I build all ports using security/openssl though
heimdal and a few others are a challenge because they try/tried to use
base openssl libcom_err.so.
I'd suggest making a backup of the openssl libs (crypto, ssl),
pkg-static and verify /rescue/tar is available, so that you have a
recovery route.

___
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: squid 3.5 plans

[Dewayne Geraghty]

On 24/02/2015 3:45 AM, Nick Rogers wrote:
 On Mon, Feb 23, 2015 at 8:18 AM, Johan Hendriks joh.hendr...@gmail.com
 wrote:

 Op 23-02-15 om 16:31 schreef Marko Cupać:

 On Sat, 21 Feb 2015 08:28:40 +0100
 Marko Cupać marko.cu...@mimar.rs wrote:

  On Thu, 19 Feb 2015 21:23:15 -0500
 Robert Simmons rsimmo...@gmail.com wrote:


  That is true. It looks like an update to both 3.5 and 3.4 were
 released on the same day. How about dropping www/squid33 and
 creating a www/squid34 port. Then updating the www/squid port to
 3.5.2.

 I would say this is a bad idea, as squid 3.5 does not work on FreeBSD
 10.1 with GENERIC kernel. Furthermore, it won't be fixed with
 binary patches (ie. until 10.2 or 11.0).

 I think www/squid should be recommended squid version for FreeBSD
 users. It wouldn't be appropriate to recommend version which does not
 work without recompiling kernel.

 We discussed it not so long ago:
 https://www.mail-archive.com/search?l=freebsd-ports@
 freebsd.orgq=subject:%22Re%3A+www%2Fsquid+does+not+
 shutdown+via+rc%22o=newest

 I have just installed www/squid33 because I wanted to avoid compiling
 custom kernel, but apparently it does not shutdown via rc either.

 I think we are closer to conclusion that no version of squid can be
 controlled with included rc scripts on 10.1-pX. Perhaps users who
 install squid on 10.1 should be warned somehow (pkg message or
 something).

 Just a me to,  Squid33 on FreeBSD 10.1-RELEASE-p5 does not kill squid with
 /usr/local/etc/rc.d/squid stop

 Yeah, the FreeBSD bug definitely affects all 3.x versions of squid,
 possibly even the old 2.7 stuff. Nobody on the FreeBSD side yet seems to
 think its a big enough of a regression to patch 10.1-RELEASE. I tried
 raising the problem with the squid team, thinking perhaps there is some
 workaround they could implement, but there was no response.

 http://lists.squid-cache.org/pipermail/squid-users/2015-January/001745.html

 For now the consensus is you must patch the 10.1 kernel for the shutdown
 behavior to work correctly. And the problem is not unique to the rc script.


Yes - that's correct.  This was covered late January and 10.1Stable contains 
the fix.

(Cut/paste of an email between ports@ and John Marshall which explains the 
situation :)

On Tue, 27 Jan 2015, 00:29 +0900, Yasuhiro KIMURA wrote:

 Yes, this is bug. But it is bug of 10.1-RELEASE rather than squid.
 See following bug report:

 Bug 195802 - www/squid restarts after shutdown and dumps core
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195802

Thank you so much for posting this link!  Merging r275456 and r275502
from stable/10 to my releng/10.1 src tree and rebuilding and installing
the kernel, means that I can once again manage squid 3.4.n via the rc.d
script instead of a prescribed series of kill(1) commands.

...and thank you rea@ and kib@ for the patches!

-- John Marshall

___
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

Different interpretation of PATH_KRB5_CONFIG between make and portmaster

[Dewayne Geraghty]

I'm a little perplexed.  I can build the new port security/kstart using
make, but not portmaster.  The latter seems to substitute the value for
PATH_KRB5_CONFIG.

I use port security/heimdal for all ports so I added to the Makefile file
PATH_KRB5_CONFIG=   /usr/local/bin/krb5-config

When I build a package using make, as follows:
rm -R /var/ports/usr/ports/* /usr/staging/*
cd /usr/ports/security/kstart  make -DBATCH clean deinstall package
the package is built and examining the log file, the build log  uses
krb5-config... /usr/local/bin/krb5-config

while
rm -R /var/ports/usr/ports/* /usr/staging/*
portmaster --no-term-title --no-confirm -H -K -D -g -G -B -v 
security/kstart
substitute's the Makefiles krb5-config path with
checking for krb5-config... /usr/bin/krb5-config
and fails.

However, being tenacious, this also succeeds in building a package
portmaster --no-term-title --no-confirm -H -K -D -g -G -B -v -m
PATH_KRB5_CONFIG=/usr/local/bin/krb5-config security/kstart

Can anyone advise the different interpretation by make /or portmaster
of PATH_KRB5_CONFIG which I identified by kstart's
./configure --help

The system is a FreeBSD 10.1-STABLE #0 r278144M: Wed Feb  4 05:08:40
AEDT 2015 using i386

Regards, Dewayne
PS The arguments to portmaster is an extract from a larger configure
script. 

-- 
For the talkers: “The superior man acts before he speaks, and afterwards speaks 
according to his action.”
For everyone else: “Life is really simple, but we insist on making it 
complicated.”

___
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: Use GCC only for specific ARCH

[Dewayne Geraghty]

On 10/12/2014 7:11 PM, Daniel Morante wrote:
 I have a port that builds fine on a 9.3 amd64, but on 9.3 i386 it
 fails on this line:

 inline int64 GetMaxMoney() { return nBestHeight = HARDFORK_HEIGHT_1 ?
 500 * COIN : 250 * COIN; }

 With the following error:

 integer constant is too large for 'long' type

 If I add USE_GCC=yes to the port's Makefile, it builds successfully
 on i386.  I'd like to apply this 'fix' only to the 32-bit platform so
 I did the following:

 .if ${ARCH} == i386
 USE_GCC=yes
 .endif

 Is that the 'correct' way to do things?

 The port can be found here:
 https://github.com/tuaris/FreeBSD-Coin-Ports/blob/master/ports/kittehcoin/Makefile#L80


Daniel,
In addition to USE_GCC=yes  in your make.conf, you'll also need to add
to /etc/libmap.conf
libgcc_s.so.1 gcc48/libgcc_s.so.1
libgomp.so.1  gcc48/libgomp.so.1
libobjc.so.4  gcc48/libobjc.so.2
libssp.so.0   gcc48/libssp.so.0
libstdc++.so.6gcc48/libstdc++.so.6
# I don't believe I use these, but to easily avoid further
troubleshooting, they're here
libatomic.so.1gcc48/libatomic.so.1
libgomp.so.1  gcc48gcc48/libgomp.so.1
libquadmath.so.0  gcc48/libquadmath.so.0

So with libmap.conf configured, a simple cd /usr/ports/security/nmap 
make clean deinstall package; pkg add nmap-6.47.txz results in, I've
added the '' for reference:

# ldd /usr/local/bin/nmap
/usr/local/bin/nmap:
libpcre.so.1 = /usr/local/lib/libpcre.so.1 (0x80095d000)
libpcap.so.1 = /usr/local/lib/libpcap.so.1 (0x800bd)
libssl.so.8 = /usr/local/lib/libssl.so.8 (0x800e15000)
libcrypto.so.8 = /usr/local/lib/libcrypto.so.8 (0x801081000)
libstdc++.so.6 = /usr/local/lib/gcc48/libstdc++.so.6 (0x80148c000)
libm.so.5 = /lib/libm.so.5 (0x801796000)
libgcc_s.so.1 = /usr/local/lib/gcc48/libgcc_s.so.1
(0x8019bd000) 
libc.so.7 = /lib/libc.so.7 (0x801bd2000)
libthr.so.3 = /lib/libthr.so.3 (0x801f76000)

without libmap.conf you'll have

/usr/local/bin/nmap:
libpcre.so.1 = /usr/local/lib/libpcre.so.1 (0x80095d000)
libpcap.so.1 = /usr/local/lib/libpcap.so.1 (0x800bd)
libssl.so.8 = /usr/local/lib/libssl.so.8 (0x800e15000)
libcrypto.so.8 = /usr/local/lib/libcrypto.so.8 (0x801081000)
libstdc++.so.6 = /usr/local/lib/gcc48/libstdc++.so.6 (0x80148c000)
libm.so.5 = /lib/libm.so.5 (0x801796000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x8019bd000)  
libc.so.7 = /lib/libc.so.7 (0x801bcb000)
libthr.so.3 = /lib/libthr.so.3 (0x801f6f000)

Aside:
I came across this as I was getting 'bus error' while building
/usr/ports/security/p5-IO-Socket-SSL with march=prescott.  As it turns
out, the problem was repeatable with

echo 'eval { require Net::SSLeay; $Net::SSLeay::trace=1;
Net::SSLeay::randomize(); };'  /tmp/a; perl /tmp/a
bus error

Rebuilding SSLEAY and perl5.20 with gcc enabled me to continue working,
without changing my CFLAGS statement
CFLAGS= -O2 -pipe -g0 -ggdb0 -march=prescott -mtune=prescott 
-fno-strict-aliasing

I initially tried to turn off stack-protector, however even applying to
/etc/make.conf
WITHOUT_SSP=yes
SSP_UNSAFE=yes

perl5.20 continued to add --stack-protector to CFLAGS.  Yes, I even
mv bsd.ssp.mk bsd.ssp.mk-hide; touch bsd.ssp.mk
it was simply too elusive... 

I should mention that I added to make.conf the following as I also use
ccache (3.2)
CC:=/usr/local/libexec/ccache/gcc48
cc:=/usr/local/libexec/ccache/gcc48
gcc48:=/usr/local/libexec/ccache/gcc48
CXX:=/usr/local/libexec/ccache/g++48
c++:=/usr/local/libexec/ccache/g++48
g++48:=/usr/local/libexec/ccache/g++48
I suspect that I should only need CC and CXX, but I'm not very technical.

Thanks for your hint about USE_GCC=yes in make.conf, along with
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/custom-gcc/configuring-ports-gcc.html
It started me down an alternate road :) 

After clearing the ccache and /var/ports, my first attempt of using
gcc48 using -march pentium3 (on i386) and core2 (on amd64), failed to
build 7 ports; interestingly using clang they successfully built all 655
packages.  (??)

Regards, Dewayne.

-- 
For the talkers: “The superior man acts before he speaks, and afterwards speaks 
according to his action.”
For everyone else: “Life is really simple, but we insist on making it 
complicated.”

___
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: Sprinkling WITH_OPENSSL_BASE in ports, ratbox build failure.

[Dewayne Geraghty]

On 28/01/2015 6:42 PM, Matthew Seaman wrote:
 On 2015/01/28 05:57, Dewayne Geraghty wrote:
 ratbox generated an unusual error message today, via portmaster on a
 10.1Stable, amd64 system
 However commenting out the recently inserted
 WITH_OPENSSL_BASE=yes
 from the Makefile enables the build to complete and uses the correct
 crypto and ssl libraries.  Shouldn't it be an option base or port?  Or
 is the openssl port going to go away?
 More like the other way around: ports will use the openssl version from
 ports exclusively, and the version in the base system will move into a
 private location.  (This is my understanding of current thinking, but I
 make no guarantee that it is what does eventually get implemented.)

 The ircd-ratbox port doesn't appear to be doing anything unusual with
 respect to openssl support that I can see from a quick inspection of the
 port Makefile.

 If you've just added 'WITH_OPENSSL_BASE' to your make.conf, then (a) you
 potentially need to recompile many ports which depend on openssl so you
 don't end up with mixed linkage against both ports and base, and (b)
 some ports require the ports version of openssl because they depend on
 functionality only in the newer version available from ports.

 Personally, I prefer 'WITH_OPENSSL_PORT=yes'  It's meant I have been
 able to turn off SSLv2 and SSLv3 everywhere pretty simply (no more
 POODLE...)

   Cheers,

   Matthew


Matthew,
Thank-you for taking the time to review and advise.

It turned out that

WITH_OPENSSL_BASE

was inserted into the irc-ratbox/Makefile some time about but only
recently took effect due to the addition of USE= openssl (#1) which
triggered the application of openssl from base [Thanks to John Marshall
for explaining the sequence, offline].  I do have WITH_OPENSSL_PORT in
my old ports.conf so when I removed the

WITH_OPENSSL_BASE

from the Makefile everything went as expected.  Since our email exchange
the Makefile has been modified and the world is a happier place for it ;)

Kind regards, Dewayne.
PS I still use WITH/WITHOUT options in ports.conf as I have a filter
that does the correct ..._SET/.._UNSET work.  Done at a time during high
ports flux.

Reference: #1  I suspect that this had something to do with it  
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195796

___
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

Sprinkling WITH_OPENSSL_BASE in ports, ratbox build failure.

[Dewayne Geraghty]

ratbox generated an unusual error message today, via portmaster on a
10.1Stable, amd64 system

Dependency error: this port wants the OpenSSL library from the FreeBSD
base system. You can't build against it, while a newer
version is installed by a port.
Please deinstall the port or undefine WITH_OPENSSL_BASE.
*** Error code 1

Unfortunately there is no option to select port or base system per make
showconfig.  WITH_OPENSSL_BASE isn't defined, and the port is being
built on a fresh machine...
# cd /usr/ports/irc/ircd-ratbox  make -V OPENSSL_USE_BASE
but it isn't defined by my system
# cd /usr/ports/irc/ircd-ratbox  make -V WITH_OPENSSL_BASE
yes
# grep OPENSSL_BASE /etc/make*; grep OPENSSL_BASE /etc/src*; grep
OPENSSL_BASE /usr/local/etc/ports.conf
#
# pkg info | grep ratbox
#

I use the openssl port for two reasons, firstly I select non-default
options and secondly it is way easier to update a port than a system. 
Typically we reboot an internal server when we need to replace the UPS
batteries, around 2+ years and external servers when a relevant CVE or
SA is issued.

However commenting out the recently inserted
WITH_OPENSSL_BASE=yes
from the Makefile enables the build to complete and uses the correct
crypto and ssl libraries.  Shouldn't it be an option base or port?  Or
is the openssl port going to go away?

 Regards, Dewayne
___
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

[Dewayne Geraghty]

On 17/01/2015 2:51 AM, Patrick Powell wrote:
 On 01/15/15 09:00, Roger Marquis wrote:
 This sounds like you, like many other people have done in the past,
 have
 built an in-house solution based on the tools available at the time,
 which includes 'make package'

 I wouldn't call it an in-house solution since the package target is a
 feature of the ports infrastructure.  We simply 'make package' and
 install other systems from the resulting package.

 This does not, however, appear to be as well supported by portsng/pkgng
 as it was in the previous versions.  Now it just exits with no message
 and a 0 exit-code without creating the package unless you've created
 /usr/ports/packages and/or specified one or more of WRKDIRPREFIX,
 PACKAGES and PKGREPOSITORY.

 What documentation there is seems to be based on older versions (like
 much of the FreeBSD website) and I haven't found anything on the
 differences between 'make package' and Poudriere.

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

 This is actually a side effect of the STAGING implementation.  The
 package file is put into the
 port (created) work sub directory.   Now if I could only find the
 documentation that tells me how to put, say,
 WORK_DIRECTORY=/var/tmp/work  into the /etc/make.conf file or
 something similar I would be
 a very (well, not so grumpy) happy camper.  I read this somewhere once
 but I cannot find
 it again.  WRKDIRPREFIX?  WORKDIRPREFIX?

Patrick,
We have these in make.conf that may help with your research
WRKDIRPREFIX=   /var/ports
DISTDIR=/usr/distfiles
TMPDIR= /tmp
PACKAGES=   /packages
STAGEDIR= /usr/staging

which we've used for many years.  Only STAGEDIR was recently added.  Its
a great aid when you commence a rebuild to just
rm -R /usr/staging /var/ports/usr
Regards, Dewayne.


-- 
For the talkers: “The superior man acts before he speaks, and afterwards speaks 
according to his action.”
For everyone else: “Life is really simple, but we insist on making it 
complicated.”

___
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

Installing openssl without gcc or binutils dependents

[Dewayne Geraghty]

I would appreciate advise on the best approach to install openssl that
has been built with gcc48 without needing to install gcc and binutils
into the target machine?

Background
Attempting to run sshd or openssl resulted in
signal 4, illegal instruction.
The target systems are i386 boxes running the VIA C3  chipset using 10.1
Stable and packages built from svnlite update of ports from 2014-12-30.

The suspect file is libcrypto.so.8.

All systems are built using clang and custom compiler directives, in
this case,
-march=c3-2 -mtune=c3-2
and other attempts of building used CPUTYPE=c3-2 which generated the
same signal 4 when run on the target platform; march=pentium3 had same
result.  The build occurs within an i386 jail on an amd64 FreeBSD 10.1
Stable, base system.

Solution
Inserted into /usr/ports/security/openssl/Makefile
USE_GCC=yes
resulted in a successful installation and running of sshd and curl which
was the objective.  However the openssl now has a dependency on gcc48
and binutils, which wont fit into the embedded image of 64MB (and isn't
needed)

I would prefer to use pkg tools to install applications rather than the
crude workaround of
tar -xpPf /kits/openssl-1.0.1_16.txz /usr/local/bin /usr/local/lib

I suspect something in /usr/ports/Mk would need a flag ??

Advise appreciated...

Kind regards, Dewayne.
PS Fortunate aside, geom_eli only requires openssl header files,
otherwise the base system would also require gcc48 for these target machines

___
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: print/cups fails to build on 9.3-STABLE i386

[Dewayne Geraghty]

On 16/01/2015 6:02 AM, William Bulley wrote:
 After running this command: # svn update /usr/ports I tried to
 upgrade the print/cups port.

 As root I then ran this command:

# portmaster -K -B -D print/cups

 Below is the output leading up to the failure and the failure itself.

 BTW - I did retry the build in /usr/ports/print/cups using this:

# make MAKE_JOBS_UNSAFE=yes install

 and got the same results.

  =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

 ...
 ...
 Making all in test...
 gmake[1]: Entering directory '/usr/ports/print/cups-base/work/cups-1.7.3/test'
 echo Linking ippserver...
 Linking ippserver...
 cc -L../cgi-bin -L../cups -L../filter -L../ppdc -L../scheduler 
 -L/usr/local/lib -Wl,-rpath,/usr/local/lib -Wl,-R/usr/local/lib  -fPIE -pie 
 -Wall -Wno-format-y2k -Wunused -fPIC -Os -g -fstack-protector -o ippserver 
 ippserver.o  ../cups/libcups.a \
  -lssl -lcrypto  -pthread -lm -lcrypt -lssp_nonshared -liconv  -lz -lz
 ../cups/libcups.a(http-support.o): In function `_httpResolveURI':
 /usr/ports/print/cups-client/work/cups-1.7.3/cups/http-support.c:1617: 
 undefined reference to `DNSServiceCreateConnection'
 /usr/ports/print/cups-client/work/cups-1.7.3/cups/http-support.c:1626: 
 undefined reference to `DNSServiceResolve'
 /usr/ports/print/cups-client/work/cups-1.7.3/cups/http-support.c:1736: 
 undefined reference to `DNSServiceRefDeallocate'
 /usr/ports/print/cups-client/work/cups-1.7.3/cups/http-support.c:1656: 
 undefined reference to `DNSServiceRefSockFD'
 /usr/ports/print/cups-client/work/cups-1.7.3/cups/http-support.c:1700: 
 undefined reference to `DNSServiceResolve'
 /usr/ports/print/cups-client/work/cups-1.7.3/cups/http-support.c:1722: 
 undefined reference to `DNSServiceProcessResult'
 /usr/ports/print/cups-client/work/cups-1.7.3/cups/http-support.c:1731: 
 undefined reference to `DNSServiceRefDeallocate'
 /usr/ports/print/cups-client/work/cups-1.7.3/cups/http-support.c:1733: 
 undefined reference to `DNSServiceRefDeallocate'
 ../cups/libcups.a(http-support.o): In function `http_resolve_cb':
 /usr/ports/print/cups-client/work/cups-1.7.3/cups/http-support.c:2071: 
 undefined reference to `TXTRecordGetValuePtr'
 /usr/ports/print/cups-client/work/cups-1.7.3/cups/http-support.c:2058: 
 undefined reference to `TXTRecordGetValuePtr'
 Makefile:192: recipe for target 'ippserver' failed
 gmake[1]: *** [ippserver] Error 1
 gmake[1]: Leaving directory '/usr/ports/print/cups-base/work/cups-1.7.3/test'
 Makefile:31: recipe for target 'all' failed
 gmake: *** [all] Error 1
 *** [do-build] Error code 1

 Stop in /usr/ports/print/cups-base.
 *** [install] Error code 1

 Stop in /usr/ports/print/cups-base.



 Regards,

 web...


William, I experienced the same issue.  Using these enabled a successful
build
 WITHOUT_AVAHI | WITH_MDNSRESPONDER in my custom ports.conf which I
think means you need to add

print_cups-base_UNSET=AVAHI
print_cups-base_SET=MDNSRESPONDER
I also set LIBPAPER - though I can't recall if that was a positive.  It
was a long time ago.

Please note: I don't use the additional layer of poudriere.

-- 
For the talkers: “The superior man acts before he speaks, and afterwards speaks 
according to his action.”
For everyone else: “Life is really simple, but we insist on making it 
complicated.”

___
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: postgresql93 port and libedit

[Dewayne Geraghty]

On 15/01/2015 5:27 PM, Waitman Gobble wrote:
 Hi,

 I noticed that postgresql93-client port pulls in readline, which is GPLv3.
 When I get rid of readline in Makefile 'USES' and also change the
 bottom of the Makefile in postgresql93-server,

 ...
 .include ${.CURDIR}/../postgresql92-server/Makefile

 CONFIGURE_ARGS+=--with-libedit-preferred


 It builds without readline and links against libedit in base:


 # ldd /usr/local/bin/psql
 /usr/local/bin/psql:
 libpq.so.5 = /usr/local/lib/libpq.so.5 (0x800885000)
 libintl.so.8 = /usr/local/lib/libintl.so.8 (0x800ab3000)
 libssl.so.7 = /usr/lib/libssl.so.7 (0x800cbe000)
 libedit.so.7 = /lib/libedit.so.7 (0x800f2a000)
 libthr.so.3 = /lib/libthr.so.3 (0x801161000)
 libc.so.7 = /lib/libc.so.7 (0x801385000)
 libcrypto.so.7 = /lib/libcrypto.so.7 (0x80171e000)
 libncursesw.so.8 = /lib/libncursesw.so.8 (0x801b16000)



 .. there's a link to gettext libintl but that's LGPL (2.1)

 Anyhow I haven't done testing with psql linked to libedit instead of
 readline.. There's some noise about this a few years back but I don't
 see anything recent. Anyone have any 'bad' recent experience with
 libedit? pitfalls? It might be good to have libedit added as an
 option. I'm working on an appliance and the readline dependency kinda
 messes things up a bit for me. Obviously other remedies beyond ports
 but I think it could be a nice option. Comments appreciated.

 Thanks,


Good catch Waitman.  And thanks for sharing an approach to avoid GPLv3
inclusion. 

Though you've raised an interesting question as to whether the licencing
information displayed by pkg info is accurate where a port pulls in
mandatory dependencies that use a more restrictive open source licence.

Of the subset of ports that I use (servers only), the ports [licences]
that may be of concern are:  python27 [PSFL], mediawiki [GPLv2],
mysql56-server [from mysql web GPL], pcre [BSD3CLAUSE] also use readline
and aren't tagged as GPLv3 which they probably should as FreeBSD
metaports requires readline? 


___
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: security/pinentry patch for WINOUT_X11 systems

[Dewayne Geraghty]

On 19/12/2014 11:26 PM, Dmitry Morozovsky wrote:
 Max,

 pinentry currently brokes if WITHOUT_X11 (or, by new world orderm 
 OPTIONS_UNSET+=X11) is set.

 what do you think about the following patch?

 marck@castor:/FreeBSD/ports/ports/security/pinentry svn diff
 Index: Makefile
 ===
 --- Makefile(revision 374940)
 +++ Makefile(working copy)
 @@ -25,7 +25,11 @@
  .if !defined(PINENTRY_SLAVE)
  OPTIONS_MULTI= FRONTEND
  OPTIONS_MULTI_FRONTEND=NCURSES GTK2 QT4
 +. if defined(WITHOUT_X11) || ${OPTIONS_UNSET:MX11}
 +OPTIONS_DEFAULT=   NCURSES
 +. else
  OPTIONS_DEFAULT=   ${OPTIONS_MULTI_FRONTEND}
 +. endif

  NCURSES_DESC=  Curses frontend
  GTK2_DESC= Gtk+ 2 frontend


Max,
That's a good idea and ensures a correct build but it adds complexity if
packages are built for other target environments.  The use of src.conf
was meant to be guidence for the buildworld/buildkernel experience, 
its expedient use in ports adds unintented logic to Makefiles and we've
learnt to rename src.conf when ports are built to minimise this.

The change to pinentry options (removing GTK) caused a problem for us
too, when we rebuilt our package set.  Ensuring that the appropriate
front-end is selected, in our case ncurses, as an option is the better,
more general solution.

Regards, Dewayne.

-- 
For the talkers: “The superior man acts before he speaks, and afterwards speaks 
according to his action.”
For everyone else: “Life is really simple, but we insist on making it 
complicated.”

___
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: squid-3.4.8_1 leaking memory

[Dewayne Geraghty]

(Bottom-posted)
On 25/09/2014 3:48 PM, Brian W. wrote:
 You seem to be onto something. On a single user testbox I use I see this

   PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIMEWCPU
 COMMAND

  6100 squid 1  200   612M 84076K kqread  1   4:01   0.00% squid

 I then restarted squid and saw

 73400 squid 1  200 61568K 21456K kqread  0   0:00   0.00% squid

 I am on the i386 flavor of 10.0-RELEASE-p9

 On Wed, Sep 24, 2014 at 9:56 PM, Victor Sudakov v...@mpeks.tomsk.su wrote:

 Colleagues,

 squid-3.4.8_1 seems to be leaking memory heavily. Its SIZE and RES are
 growing several MB per minute until eventually swapping begins.

 Is anyone using it? Have you encountered this problem?

 The relevant entries in squid.conf are:

 cache_mem 128 MB
 cache_dir ufs /webcache/cache 512 16 256
 memory_pools off # neither on nor off have any effect on leaking.

 As you see, the memory requirements should be rather modest.

 Running on 8.4-RELEASE-p16 i386.

 --
 Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
 sip:suda...@sibptus.tomsk.ru
 ___
I think you should file a bug report

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

so that this can be actioned/tracked.  I don't have squid 3.4.8 running
yet, but a friend forwarded his experience after only 6 days of light use:

last pid: 43552;  load averages:  0.34,  0.23,  0.18  up 5+22:34:1206:01:32
245 processes: 1 running, 244 sleeping

Mem: 483M Active, 6021M Inact, 1581M Wired, 371M Cache, 1636M Buf, 7394M Free
Swap: 32G Total, 1104M Used, 31G Free, 3% Inuse


  PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIMEWCPU COMMAND
 6095 squid 1  200   738M 63044K kqread  7   2:12   0.00% squid
73487 squid 1  200   326M  7548K kqread  3   0:15   0.00% squid

Regards, Dewayne.

___
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 with heimdal port requires a tweak

[Dewayne Geraghty]

Bind99 with heimdal enables GSS-TSIG, which is useful when using samba4
(or those pesky Windows Servers) in a production environment.  There is
a one line change required against
/usr/ports/dns/bind99/files/patch-configure
to avoid bind 9.9.6 bringing in heimdal base shareable libraries when
the intent is to use the heimdal port.

Please refer https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193912

My thanks to John Marshall for his generous assistance in the hunt for a
solution.

Regards, Dewayne.
___
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

Transition from ${UNIQUENAME}_SET to ${CATEGORY}_${UNIQUENAME}_SET

[Dewayne Geraghty]

Seems that options for port customisations has changed.  Previously I used:
${UNIQUENAME}_SET=...
but now told by others on various irc channels that it was now
${CATEGORY}_${UNIQUENAME}_SET=
which proved to be correct (for some ports).

So I added the categories to the customisations and started to rebuild
all ports that I use.  Unfortunately devel/apr1 failed.  It didn't use
LDAP, which I'd told it to use, causing apache to fail etc.

Now I have in make.conf
# These work
apr_SET=THREADS BDB LDAP
www_apache24_SET=...  
# These don't
devel_apr_SET=THREADS BDB LDAP

Am I caught in a transition or is this inconsistency expected?  I
suppose I'm not really affected anymore as I detected the anomaly and
wrote a script to duplicate the customisations to my ports.

For those less familiar, I've found these helpful:
make showconfig | grep =on  # which will display
what is turned on
make  __MAKE_CONF=/dev/null showconfig | grep =on # displays the
port maintainers defaults.

___
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: libressl anyone?

[Dewayne Geraghty]

On 12/07/2014 9:12 AM, Kevin Oberman wrote:
 Now that OpenBSD has released LibreSSL, can someone port it? And maybe try
 putting it into head? I'd love to see OpenSSL gone yesterday.

 The initial portable LibreSSL is available from
 http://ftp.openbsd.org/pub/OpenBSD/LibreSSL. Note that the OpenBSD folks
 say that this release is intended for testing and evealuation, so it is not
 a candidate for any stable or release, but it does build on FreeBSD.

 Yes, if I get some time today or tomorrow, I'll try to write up a port, but
 I'm still far from comfortable with the new porting stuff, so it will
 likely take longer that I'd like. Others can probably knock it out in
 nothing flat.
Thanks for sharing Kevin.  I found this a compelling paper justifying
the libressl effort and seeking community involvement. (For the time
poor, start at page/slide 7)
http://www.openbsd.org/papers/bsdcan14-libressl/index.html
As an aspiration, Libressl is expected in Openbsd 5.6; 5.5 was released
on 1st May, 2014.
Dewayne.
___
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: marking vulnerable ports forbidden?

[Dewayne Geraghty]

On 16/07/2014 7:48 AM, Bryan Drewery wrote:
 On 7/15/2014 7:45 AM, René Ladan wrote:
 Hi,

 according to Freshports [1] there are currently 24 vulnerable ports not
 marked as forbidden.
 How about checking this list on a regular basis and marking such ports and
 forbidden and optionally as deprecated? This would inform users not using
 vuxml earlier about vulnerabilities.

 [1] http://www.freshports.org/ports-vulnerable.php

 Regards,
 René
 ___
 Do take it case-by-case though. Doing this wipes out most Linux ports
 IIRC. Some of the vulns documented are not worthy of a FORBIDDEN.

Good point Bryan.  I've added this to my /usr/ports/Mk/bsd.port.mk to
accomodate an ability to choose and make my own informed decision.  It
might be worthy of adoption:

--- /usr/ports/Mk/bsd.port.mk.orig2 2014-07-16 10:28:19.0 +1000
+++ /usr/ports/Mk/bsd.port.mk   2014-07-16 10:28:31.0 +1000
@@ -3036,7 +3036,7 @@
 .if !defined(TRYBROKEN)
 IGNORE=is marked as broken on ${ARCH}: ${BROKEN_${ARCH}}
 .endif
-.elif defined(FORBIDDEN)
+.elif defined(FORBIDDEN)  !defined(NO_IGNORE_FORBIDDEN)
 IGNORE=is forbidden: ${FORBIDDEN}
 .endif

The use of NO_IGNORE is far too course, so NO_IGNORE_FORBIDDEN is a
compromise. :)

___
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

perl5.20 and document generation problem

[Dewayne Geraghty]

This might help someone avoid the same issue or provide a clue to more
knowledgeable folk.

I experienced doc generation failures on 9.3Stable for the
security/heimdal and sysutils/log_analysis ports.  Reverting from
perl5.20 to perl5.16 eliminated the following problems.

From security/heimdal build log
--
Making all in doc
sed -e 's,[@]dbdir[@],/var/heimdal,g'  -e
's,[@]PACKAGE_VERSION[@],1.5.2,g'  ./vars.tin  vars.texi.tmp
chmod +x vars.texi.tmp
mv vars.texi.tmp vars.texi
restore=:  backupdir=.am$$   am__cwd=`pwd` 
CDPATH=${ZSH_VERSION+.}:  cd .   rm -rf $backupdir  mkdir
$backupdir   if (/bin/sh
/var/ports/usr/ports/security/heimdal/work/heimdal-1.5.2/missing --run
makeinfo --version) /dev/null 21; then  for f in ./heimdal.info
./heimdal.info-[0-9] ./heimdal.info-[0-9][0-9] ./heimdal.i[0-9]
./heimdal.i[0-9][0-9]; do  if test -f $f; then mv $f $backupdir;
restore=mv; else :; fi;  done;  else :; fi   cd $am__cwd;  if
/bin/sh /var/ports/usr/ports/security/heimdal/work/heimdal-1.5.2/missing
--run makeinfo  --css-include=./heimdal.css -I .  -o ./heimdal.info
./heimdal.texi;  then  rc=0;  CDPATH=${ZSH_VERSION+.}:  cd .;  else 
rc=$?;  CDPATH=${ZSH_VERSION+.}:  cd .   $restore $backupdir/*
`echo ././heimdal.info | sed 's|[^/]*$||'`;  fi;  rm -rf $backupdir;
exit $rc
./whatis.texi:39: unknown command `def'
./whatis.texi:39: unknown command `xsub'
./whatis.texi:40: unknown command `global'
./whatis.texi:40: unknown command `let'
./whatis.texi:40: unknown command `xsub' (possibly involving @sub)
./win2k.texi:314: warning: @end should only appear at a line beginning
*** [./heimdal.info] Error code 1

Stop in /var/ports/usr/ports/security/heimdal/work/heimdal-1.5.2/doc.
*** [all-recursive] Error code 1

From sysutils/log_analysis log files, upstream has been unchanged for
around 2 years
-
===  Building for log_analysis-0.46
/usr/local/bin/pod2man log_analysis  log_analysis.1
log_analysis around line 8793: You forgot a '=back' before '=head2'
log_analysis around line 8802: '=item' outside of any '=over'
POD document had syntax errors at /usr/local/bin/pod2man line 71.
*** [log_analysis.1] Error code 255

Stop in /var/ports/usr/ports/sysutils/log_analysis/work/log_analysis-0.46.
*** [do-build] Error code 1

Stop in /usr/ports/sysutils/log_analysis.

--
texinfo-5.2.20140608   is installed, and the /etc/src.conf contains
WITHOUT_INFO=YES

Regards, Dewayne
___
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: print/cups new 1.7.3 fails on undefined references in http.c

[Dewayne Geraghty]

Thomas, We're at risk of straying off topic, but as you're the thread
owner...

To build without dialogue stuff:
cd /usr/ports/print/cups-base
# To see options
make showconfig
# To find the ports unique name, you'll need this to set the port
specific options in make
make -VUNIQUENAME
# To define options in make.conf, similar to pkgsrc  though reversed
echo cups-base_SET=LIBPAPER  /etc/make.conf
# To make without dialogue
make -DBATCH

If you wish to set global options, for all ports or really don't want to
lookup the UNIQUENAME
echo OPTION_SET=\heimdal_home=/usr\  /etc/make.conf

I actually use /usr/ports/port-mgmt/portconf to manage all changes, but
that is largely historical.
Hope that assists.
Dewayne
PS You will need to do something? delete? where-ever your previously
defined options, via dialoue have been set. I can't help there.

___
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: rsync 3.1.1 zlib might not work

[Dewayne Geraghty]

Emanuel,
Thanks for bringing to our attention, I transmit ~900MB of backups over
the WAN  rather than the uncompressed 9G database. You've saved a client
excess use charges.

I tested using highly compressible data (mostly nulls) and it seems to
work as expected.

Without -z or -zz: Sent 593 bytes speadup 0.82
With -z :  Sent 593 bytes speadup 0.82(Unexpected.  Should be in
ports/UPDATING)
With -zz: sent 85 bytes speedup is 4.27   (Expected)

Detail
# rm ./b  printf %512ca  a  rsync -av ./a ./b
sending incremental file list
a

sent 593 bytes  received 35 bytes  1,256.00 bytes/sec
total size is 512  speedup is 0.82

# rm ./b  printf %512ca  a  rsync -avz ./a ./b
This rsync lacks old-style --compress due to its external zlib.  Try -zz.
Continuing without compression.

sending incremental file list
a

sent 593 bytes  received 35 bytes  1,256.00 bytes/sec
total size is 512  speedup is 0.82

# rm ./b  printf %512ca  a  rsync -avzz ./a ./b
sending incremental file list
a

sent 85 bytes  received 35 bytes  240.00 bytes/sec
total size is 512  speedup is 4.27

# ldd `which rsync`
/usr/local/bin/rsync:
libz.so.6 = /lib/libz.so.6 (0x800873000)
libc.so.7 = /lib/libc.so.7 (0x800a87000)

Perhaps ports/UPDATING should alert users to the new requirement to use
-zz (not in man page) instead of -z or --compress?

Regards, Dewayne.
___
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: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-14:08.heimdal

[Dewayne Geraghty]

Regarding the errata notice for heimdal, for the sake of consistency
should the security/heimdal port also be patched?  The following is
against security/heimdal, and could be dropped into
security/heimdal/files if required:

--- lib/gssapi/krb5/prf.c.orig2014-06-25 15:30:54.0 +1000
+++ lib/gssapi/krb5/prf.c 2014-06-25 15:31:45.0 +1000
@@ -119,7 +119,7 @@
 while(dol  0) {
size_t tsize;

-   _gsskrb5_encode_om_uint32(num, input.data);
+   _gsskrb5_encode_be_om_uint32(num, input.data);

ret = krb5_crypto_prf(context, crypto, input, output);
if (ret) {

___
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: Way to make settings in /etc/make.conf effective only for ports

[Dewayne Geraghty]

On 22/06/2014 7:40 PM, Alfred Perlstein wrote:

 On 6/22/14, 2:20 AM, Melvyn Sopacua wrote:
 Hi Yasuhiro,

 On Sun, 22 Jun 2014, Yasuhiro KIMURA wrote:

 Recently I found some of settings for ports in /etc/make.conf
 interfere with other software project. So are there any way to make
 settings in /etc/make.conf effective only for ports?

 You can wrap those settings in .CURDIR check:
 .if !empty(.CURDIR:M/usr/ports/*)
 # port settings here
 .endif

 What about using a check for ../../Mk/bsd.ports.mk or
 ../Mk/bsd.ports.mk ?

 Alternatively, you can make a different file, say /etc/make.ports.conf
 and then build ports with the environment variable __MAKE_CONF set to
 it.
 -- 
 Melvyn
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


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


Simplest way would be to install ports-mgmt/portconf. The installation
appends what's needed to /etc/make.conf
Then you need to add to /usr/local/etc/ports.conf to enable what you
require the port to do.  Something like:

databases/mariadb55-client: mariadb_UNSET=MAXKEY X11 GNOMEVFS
lang/perl*: OPTIONS_SET=THREADS PERL_64BITINT
lang/php5:  php5_UNSET=DEBUG MULTIBYTE X11 GNOMEVFS | php5_SET=APACHE
SUHOSIN

should give you a sense of what you can do.  The above is an extract
from a script that was used during the transition from WITH_|WITHOUT_ to
OPTIONS_SET|OPTIONS_UNSET and ${UNIQUENAME}_SET${UNIQUENAME}_UNSET, but
it should serve to give you a clue as to how to make tweaking your ports
a lot easier.  Then when you want to make a port just
make -DBATCH
this avoids the dialogue and provides consistency when building a lot of
ports across different machines /or platforms.  It also saves
cluttering your make.conf.

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

Re: Ports tree insecure because of IGNOREFILES+IGNORE

[Dewayne Geraghty]

Good catch philj, I wasn't aware of this feature.  I'm grepping the
ports that I use as I type my appreciation.  Though this makes me wonder
about the efficacy of having a sha signature for the package manifest...
Regards, Dewayne.
___
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

devel/icu preventing openldap24-sasl-client build

[Dewayne Geraghty]

openldap24-sasl-client has a new mandatory dependency on devel/icu.  Is
there any way to turn this dependency off, as I don't require this
additional 22MB source or its 18M package?

How it surfaced?
cd /usr/ports/net/openldap24-sasl-client
make -DBATCH  clean deinstall package
...
configure: WARNING: ICU not available
checking sasl/sasl.h usability... yes
checking sasl/sasl.h presence... yes
checking for sasl/sasl.h... yes
checking sasl.h usability... no
checking sasl.h presence... no
checking for sasl.h... no
checking for sasl_client_init in -lsasl2... no
checking for sasl_client_init in -lsasl... no
configure: error: Could not locate Cyrus SASL
===  Script configure failed unexpectedly.
Please report the problem to delp...@freebsd.org [maintainer] and attach the
/var/ports/usr/ports/net/openldap24-sasl-client/work/openldap-2.4.39/config.log
including the output of the failure of your make command. Also, it might be
a good idea to provide an overview of all packages installed on your system
(e.g. a /usr/sbin/pkg_info -Ea).
*** [do-configure] Error code 1

Examining the config log,
configure:21986: /usr/local/libexec/ccache/cc -o conftest  -O2 -pipe
-pipe -O2 -g0 -march=prescott  -DMDB_DSYNC=O_SYNC -Dfdatasync=fsync
-fno-strict-aliasing -I/usr/local/include 
-Wl,-rpath,/usr/lib:/usr/local/lib conftest.c -licuuc -licudata  5
conftest.c:123:37: error: unicode/utypes.h-disabled: No such file or
directory


___
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

Requests for port updates

[Dewayne Geraghty]

Has bugzilla taken on the role of being the repository for update
requests?  With gnats, when the synopsis contained port information (eg
mail\opendkim ...) the issue was routed directly to the maintainer. 
If there is no auto-routing then how is a maintainer to be alerted to a
port request - unless they happen to refer to bugzilla.

Mailing freebsd-ports just doesn't seem right... but if it is

mail/opendkim - current PORTVERSION is 2.8.3, while version 2.9.2 has
been available since April and uses --with-lmdb
sysutils/cfengine36 - released today.  Modified the VERSION number and
built 3.6.0 cleanly. Preliminary testing ok. (also uses lmdb)
www/phpbb3 - Changing PORTVERSION=3.0.11 to 3.0.12 and building is ok too.

Dewayne.
___
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