Rebuilding my ports area

[Dave Horsfall]

FreeBSD 9.3-RELEASE-p20 (GENERIC) #0: Tue Jul 21 19:29:33 UTC 2015

Having completely scragged my ports area following various changes to 
pkg/pkgng/etc, and being unable to "sysinstall" it from CD (not found for 
some reason) or via FTP (not found on server etc), I found a pristine copy 
of ports.txz and unpacked it (sigh, yet another compression scheme), after 
renaming the old directory.

Anyway, what do I do now?  Assume that many ports have been installed, and 
that the databases etc are probably a dog's breakfast, per the conflicts 
that I have posted here earlier.  If it helps, I have a list of those 
ports that were installed, and hopefully the dependencies will be taken 
care of automagically.

Thanks.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer"
Watson never said "I think there is a world market for maybe five computers."
___
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"

net-mgmt/pnp and nagios4

[Marko Cupać]

Hi,

Is it possible to run pnp4nagios with nagios4 on FreeBSD? I see that
their documentation page states that "PNP4Nagios Broker Module
npcdmod.o is not compatible with Nagios Core 4.x". However, I plan to
use "Bulk Mode with NPCD", or maybe even Bulk or Synchronous mode.
Those should have no problem with nagios4.

Building pnp in poudriere pulls in nagios, but I already have nagios4
installed. Could pnp port be modified so that one can choose nagios
version?

Regards,
-- 
Marko Cupać
https://www.mimar.rs/
___
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: NEW PORT for librdkafka

[Victor]

___
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: NEW PORT for librdkafka

[Kurt Jaeger]

Hi!

> > GH_TAGNAME= e3d984849a

> > builds, changed the error to a warning. Should we commit this ?

> Yes, please.

Done.

-- 
p...@opsec.eu+49 171 3101372 5 years to go !
___
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: Rebuilding my ports area

[David Wolfskill]

On Fri, Jul 24, 2015 at 05:21:07PM +1000, Dave Horsfall wrote:
> FreeBSD 9.3-RELEASE-p20 (GENERIC) #0: Tue Jul 21 19:29:33 UTC 2015
> 
> Having completely scragged my ports area following various changes to 
> pkg/pkgng/etc, and being unable to "sysinstall" it from CD (not found for 
> some reason) or via FTP (not found on server etc), I found a pristine copy 
> of ports.txz and unpacked it (sigh, yet another compression scheme), after 
> renaming the old directory.
> 
> Anyway, what do I do now?  Assume that many ports have been installed, and 
> that the databases etc are probably a dog's breakfast, per the conflicts 
> that I have posted here earlier.  If it helps, I have a list of those 
> ports that were installed, and hopefully the dependencies will be taken 
> care of automagically.
> 

Near the bottom of portmaster(8), there is a procedure entitled "Using
portmaster to do a complete reinstallation of all your ports".  I have
used that procedure (with some variations) over the years -- e.g.,
migrating from 8.x -> 9.x, then 9.x to  10.x; more recently, I extracted
bits of it to migrate from stable/10 i386 -> stable/10 amd64 [gory
details at
].

Based on my experiences doing those, I *think* that using that procedure
as a basis (and adapting in slightly) may serve you well.  (Note that as
of this writing, that procedure still refers to the old pkg_* tools.  So
instead of "pkg_delete -a" I used "pkg delete -fa".)

One of the first things, though, would be to determine if you'r going to
use pre-built packages (and if so, built by whom) or build the ports
yourself.

The procedure I used in the above-cited article -- once I finished
bumping into issues caused by my ignorance (or other oddities) -- turned
out to work quite well -- but I was only able to accomplish it because I
had available hardware to perform the package-building (using poudriere)
for me.

portmaster itself is "merely" a shell script, so it has no dependencies
on (other) ports; installing it on a pristine system will bring in pkg,
but no others.

Note, too: after generating the list of 'installed ports" (which may
look incomplete: it doesn't actually list all of your inistalled ports,
but rather, a subset that is necessary to get all of them installed), I
finid it useful to trim the list further and re-order the list (so that
more critical, smaller port -- such as sudo and tmux -- are built before
more complicated ports cause problems).  One of the things I typically
do on non-development machines during this pass is remove ports from the
list that are "obviously" only build dependencies -- autoconf*;
automake*; nearly all devel/* ports -- as the installation of the ports
I really use directly will bring the others in if they are actually needed.

If at all possible, of course, make a good (tested!) backup before you
do the "pkg delete -af". :-}

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpGvjRCcGXnw.pgp
Description: PGP signature

Re: Rebuilding my ports area

[Warren Block]

On Fri, 24 Jul 2015, David Wolfskill wrote:


On Fri, Jul 24, 2015 at 05:21:07PM +1000, Dave Horsfall wrote:

FreeBSD 9.3-RELEASE-p20 (GENERIC) #0: Tue Jul 21 19:29:33 UTC 2015

Having completely scragged my ports area following various changes to
pkg/pkgng/etc, and being unable to "sysinstall" it from CD (not found for
some reason) or via FTP (not found on server etc), I found a pristine copy
of ports.txz and unpacked it (sigh, yet another compression scheme), after
renaming the old directory.

Anyway, what do I do now?  Assume that many ports have been installed, and
that the databases etc are probably a dog's breakfast, per the conflicts
that I have posted here earlier.  If it helps, I have a list of those
ports that were installed, and hopefully the dependencies will be taken
care of automagically.



Near the bottom of portmaster(8), there is a procedure entitled "Using
portmaster to do a complete reinstallation of all your ports".  I have
used that procedure (with some variations) over the years -- e.g.,
migrating from 8.x -> 9.x, then 9.x to  10.x; more recently, I extracted
bits of it to migrate from stable/10 i386 -> stable/10 amd64 [gory
details at
].


Updated portmaster man page procedure here:
https://forums.freebsd.org/threads/rebuilding-all-ports-with-portmaster.51210/
___
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: Rebuilding my ports area

[Chris H]

On Fri, 24 Jul 2015 17:21:07 +1000 (EST) Dave Horsfall 
wrote

> FreeBSD 9.3-RELEASE-p20 (GENERIC) #0: Tue Jul 21 19:29:33 UTC 2015
> 
> Having completely scragged my ports area following various changes to 
> pkg/pkgng/etc, and being unable to "sysinstall" it from CD (not found for 
> some reason) or via FTP (not found on server etc), I found a pristine copy 
> of ports.txz and unpacked it (sigh, yet another compression scheme), after 
> renaming the old directory.
> 
> Anyway, what do I do now?  Assume that many ports have been installed, and 
> that the databases etc are probably a dog's breakfast, per the conflicts 
> that I have posted here earlier.  If it helps, I have a list of those 
> ports that were installed, and hopefully the dependencies will be taken 
> care of automagically.
> 
> Thanks.
Maybe I'm missing something regarding your particular situation. But
wouldn't
svn co svn://svn.freebsd.org/ports/head /usr/ports
have given it to you?

--Chris
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer"
> Watson never said "I think there is a world market for maybe five computers."
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


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

Re: net-mgmt/pnp and nagios4

[Lars Engels]

On Fri, Jul 24, 2015 at 11:35:05AM +0200, Marko Cupać wrote:
> Hi,
> 
> Is it possible to run pnp4nagios with nagios4 on FreeBSD? I see that
> their documentation page states that "PNP4Nagios Broker Module
> npcdmod.o is not compatible with Nagios Core 4.x". However, I plan to
> use "Bulk Mode with NPCD", or maybe even Bulk or Synchronous mode.
> Those should have no problem with nagios4.
> 
> Building pnp in poudriere pulls in nagios, but I already have nagios4
> installed. Could pnp port be modified so that one can choose nagios
> version?

Hi Marko,

it would probably be possible to add a pnp-nagios4 slave port to pnp.
You could copy the pnp-icinga port and change the dependency to
net-mgmt/nagios4.

Lars


pgpPCtvSq92xr.pgp
Description: PGP signature

Re: Proposal to fix postgresql package maintainance nightmare

[joris dedieu]

2015-07-21 21:47 GMT+02:00 Christoph Moench-Tegeder :
> ## Baptiste Daroussin (b...@freebsd.org):
>
>> We do manage a bunch of postgresql servers on FreeBSD, and I really find the
>> current model of packages postgresql is a nightmare on FreeBSD.
>
> Not that much worse than in some other environments :)
> Comparing all the PostgreSQL packaging models, I like the debian model
> best (PostgreSQL is my day job, so I can claim some experience here).
>
>> Having one single postgresql-client package always on the latest stable 
>> version
>> (backward compability being very good) providing the client cli tools and the
>> libraries (those libraries will be used for everything in the ports tree
>> needing to talk to postgresql)
>
> As others already noted, using a psql (command line client) with a
> version different from the respective server has it's limitations
> (it works in general, but some of the meta commands may fail).
> On the other hand, the ABI of libpq is stable enough for all the
> supported versions of psql (and other clients). So you'd need one
> package with libpq alone, and another one with psql and the other
> client utils (http://www.postgresql.org/docs/9.4/static/reference-client.html
> is the list). The server itself would be the another package.
> The libpq package can always be built from the latest release
> of PostgreSQL.
> An additional "postgresql-{client,server}-meta" package would
> provide symlinks from ${LOCALBASE}/bin/ to
> ${PREFIX}/bin/ (PREFIX being the PREFIX for
> the selected PostgreSQL package, postgresbinary all the binaries
> PostgreSQL installs).
> For applications using PostgreSQL, the USES=pgsql logic has to
> point configure and it's equivalents to the right pg_config, and
> all well behaved applications should find the right libraries etc.
>
>> That way everything talk to pgsql will only depend on one postgresql-client
>> packages that will smoothly be upgraded to newer versions.
>
> Using the schema outlined above, the "normal" PostgreSQL-using
> application will only have to depend on the libpq package,
> which is version-agnostic. Only those applications which
> really need psql will have to depend on the (versioned)
> posggresql-client package, or even better, the client-meta
> package (that way, changes of the default postgresql version
> will not require dependency-wrangling throughout the tree).
>
>> Any opinion on that change? Any idea one how to make the upgrade path as
>> transparent as possible for current setup? (beside of course adding an 
>> UPDATING
>> entry)
>
> Using the meta-packages (which could just pick up the previously
> set default version), the upgrade path should be completely
> transparent for most cases.
>
> Another thing I've been thinking about is the ability to have
> multiple PostgreSQL clusters on one machine. Currently there's
> only the one "postgresql_data" variable in rc.conf. It shouldn't
> be that hard to have something like
> postgresql94_clusters="default stage dev"
> postgresql94_default_data="..."
> postgresql94_stage_data="..."
>
> Depending on the rc script handling (one script to rule them
> all vs. each PostgreSQL has it's own script), we might even do
> something line
> postgresql_clusters="9.4:default 9.5:testing"
> postgresql_default_data="..."
> postgresql_testing_data="..."

Is not that an other problem ? Maybe we need a generic mechanism to
manage instances (think mysql, tomcat, apache ...) ? At least a common
syntax, to avoid something like the [check|config][test|check] issue

Regards
Joris
>
> If you want to enlist me for testing/script wrangling/etc.,
> just drop me an email.
>
> Regards,
> Christoph
>
> --
> Spare Space
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: svn commit: r392851 - in head: . devel devel/libiomp5-devel devel/llvm-devel devel/llvm-devel/files lang/clang-devel lang/clang-devel/files

[Brooks Davis]

On Fri, Jul 24, 2015 at 11:40:10PM +, Brooks Davis wrote:
> Author: brooks
> Date: Fri Jul 24 23:40:09 2015
> New Revision: 392851
> URL: https://svnweb.freebsd.org/changeset/ports/392851
> 
> Log:
>   Mostly complete redo to the build of -devel LLVM ports:
>- Switch to cmake.
>- Combine all builds into devel/llvm-devel.
>  - Remove devel/libiomp5-devel
>  - Make lang/clang-devel a metaport so people can still find it.
>   
>   Upgrade a snapshot shortly after the 3.7 branch point.

I'm aiming to introduce a devel/llvm37 port next week based on this framework
so please test if you anticipate wanting to use 3.7.

-- Brooks


pgp3mo4NjgjcZ.pgp
Description: PGP signature