Re: The ports collection has some serious issues

[Jim Trigg]

On 12/19/2016 09:02 AM, John Marino wrote:

On 12/18/2016 23:42, Jim Trigg wrote:

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

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


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

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


Wasn't that a global bug that was fixed?7


I don't know; I can't find any record of it...\


You logic is faulty IMO.  All binary packages produced officially for
FreeBSD are built with poudriere.  If poudriere can't build it due to a
bug in the port itself, then nobody gets the package.  Obviously that's
unacceptable, so the port bug gets fixed, quickly.


All binary packages produced officially for FreeBSD are built with 
poudriere *with default options*. ZTS is not the default (even though 
it's needed in most cases for mod_php and apache).



So it sounds like you're saying that poudriere is too strict at
enforcing correctness and you need something more forgiving?


No, that's not what I'm saying. I can't find anything online showing 
that this problem has been reported. I can't reproduce it using the tool 
that I've been using for years (portmaster). Therefore my first 
assumption was that the problem was the new tool I had just started 
using. Note: while my phrasing may have been poor, I was not meaning to 
imply that the tool (poudriere) was necessarily broken, just that I 
couldn't figure out what was going wrong and that it seemed (based on my 
data sample) to be poudriere rather than the port. Having now tested 
using the ports tree directly (make -C 
/usr/ports/databases/php70-pdo_mysql on a basically clean ports tree 
with "OPTIONS_SET+= ZTS" in /etc/make.conf) and gotten the same failure 
as with poudriere, I now have no idea how it worked in portmaster, and 
acknowledge that it is a problem with the port.



Unfortunately, port maintainers break the tree.  Usually the big breaks
are avoid with EXP-RUNs but it's common to see updates where downstream
dependencies weren't tested and break (aside: IMO this it is the
responsibility of the person updating the first port to verify the deps
still build but not everyone does this).

So sometimes you hit a tree break and that's what happened.  It was
fixed right?  The bottom line: if a port doesn't build on poudriere and
synth, the issue must be fixed, not worked around by using a tool
incapable of detecting it.  That's how most of the "I use portmaster and
this doesn't work" topics get started.


It doesn't seem to have been fixed, since I'm still seeing the error. 
I'm saying that 90% of the time portmaster works for me, and when it 
doesn't I can figure out a solution 90% of that time. I haven't gotten 
poudriere to work for me yet given the set of options I need set.



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


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


I am a big supporter of poudriere.  While many people find they prefer
synth and enjoy its performance advantage, I will never tell a poudriere
user to switch if they are happy with poudriere.


But you will tell a portmaster user to switch if they are happy with 
portmaster because it doesn't do things the way you think they should be 
done... Never mind that the whole pkgng system was forced on us 
willy-nilly, and it's the main reason there are problems with 
portmaster. Note that the "cannot as yet contest this" is because I'm 
not convinced that synth is "more effective" than poudriere - I expect 
that they are each better suited for a particular use case. The 
difference is that as far as I can tell, poudriere is satisfactory for 
the use case synth is designed for, but synth is not suited for the use 
case poudriere was initially intended for. (Note that a primary use of 
poudriere is/was to replace the now extinct port tinderbox.)


Jim Trigg
___
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: Custom base jails for ZFS replication

[Chad Perrin]

On Wed, Dec 21, 2016 at 12:59:23AM -0500, Randy Westlund wrote:
> Is there a jail management tool that lets you install packages in a base
> jail, and share that with multiple thin jails?

I know ezjail does this, as far as it goes.


> 
> I want to deploy many thin jails across multiple servers, and be able to
> update both the base system and ports in a base jail and then ZFS
> replicate that to the base jails on the production servers.  I'd like
> the thin jails to only contain my customer-specific application data, so
> I don't have to manually update all of them.

I'm not sure what it would take to use a base jail across separate
servers.  It is not something I have tried to do, or even thought of a
reason I'd need it.


> 
> I don't see any way to do this with ezjail or iocage.  Does anyone else
> have a deployment like this?

It sounds distinctly out of the ordinary, so I would not be surprised if
there is little or no tool support for it.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.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"

Custom base jails for ZFS replication

[Randy Westlund]

Is there a jail management tool that lets you install packages in a base
jail, and share that with multiple thin jails?

I want to deploy many thin jails across multiple servers, and be able to
update both the base system and ports in a base jail and then ZFS
replicate that to the base jails on the production servers.  I'd like
the thin jails to only contain my customer-specific application data, so
I don't have to manually update all of them.

I don't see any way to do this with ezjail or iocage.  Does anyone else
have a deployment like this?


signature.asc
Description: PGP signature

Re: issues in several ports.

[Peter Jeremy]

On 2016-Dec-21 04:01:50 +, Wyle Coyote via freebsd-ports 
 wrote:
>.I upgraded to 10.3 release installed via dvd

"upgraded" how?  Was this a fresh install or did you try to install
10.3 over the top of your 7.4 system?  If the latter, it's quite
likely that there are remnants of FreeBSD 7.4 (libraries, include
files and/or ports) that are confusing the ports build system (GNU
configure is really good at locating and incorrectly using leftover
cruft).  I strongly recommend you do a reinstall from scratch.  If
you can't, as a minimum, you should install a source tree and run
"make delete-old delete-old-libs" as well as deleting all your
installed ports (your entire /usr/local and /var/db/pkg).

>in the uw-imap 2007f it will not compile under the port. In fact I am familiar 
>with imap and the client fairly well. I can get the program to build from 
>source, which I cannot in updated ports.  I also added the -lcrypt
>Tried just the c-client out of ports, same problem, no build.

If the above doesn't fix your problem, can you please try a fresh
build with "DISABLE_MAKE_JOBS=yes" and make the complete build log
available somewhere.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Subscription for committer

[John Marino]

On 12/20/2016 18:39, Warren Block wrote:

On Mon, 19 Dec 2016, John Marino wrote:


On 12/19/2016 20:22, Mark Linimon wrote:

On Mon, Dec 19, 2016 at 07:07:06PM -0600, John Marino wrote:

It's a natural reaction to stop attempting to contribute when previous
contributions don't get "attention they deserve".


Which some people (including me) see as odds with:


the impression that portmaster is officially recommended [has] to be
stamped out


People tend to put off working on topics that include "demands".

It's just human nature.

Plus, there are thousands of other PRs to work on that don't involve
such
charged language.  Working on those is more rewarding and less
frustrating.


It was decided that any implied recommendation for portupgrade and
portmaster in FreeBSD documentation has to be removed.


Obviously there is some disagreement on this point, as this long,
multiply-broken, renamed thread has shown.


It wasn't up for discussion; portmgr made the decision on it and said it 
should be done.






The docs people are aware of the decision and are charged to implement
it.


As volunteers, committers are free to choose the work they want to do.


Then give me authority to commit to documentation.
This excuse is easily defused.



It's not "my" demand.  If valid PRs are in a moving queue, fine.  If
valid PRs are being conveniently and intentionally forgotten, I would
say that's not fine.


There is no queue.  Volunteers choose the work they want to do.


I am reluctant to point out the elephant in the room, but I think you 
know what I'm thinking.





and mcl: I challenge you to identify *ANY* offputting language in PR
214679. You can't just imply that it exists when it doesn't.


There has been plenty of off-putting language outside of that PR
referring back to it, including some a few lines above. These are far
beyond demotivational. More of the same will not have a different effect.

My apologies for extending this already too-long thread.


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

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

issues in several ports.

[Wyle Coyote via freebsd-ports]

History background.
First let me say I've been running freebsd since 4.X, I resisted upgrading 
after 7.4 for as long as I could and always patch.I upgraded to 10.3 release 
installed via dvd at the start of December.Before you say, it is not the 
machine. Check the hardware and it still runs freebsd 7.4 without error.
Yes it is an AMD64

in the uw-imap 2007f it will not compile under the port. In fact I am familiar 
with imap and the client fairly well. I can get the program to build from 
source, which I cannot in updated ports.  I also added the -lcrypt
Tried just the c-client out of ports, same problem, no build.

When trying to use php5.6.29 out the ports it also fails to build for 10.3  

Then we have the root ca_nss package since someone at freebsd forgot that fetch 
needs this to check https:. It fails to build as well. Now I was able to use 
the package install to get around this one. Still isn't ports suppose to be a 
viable option?if we manage to get a compiling then linking is impossible. Could 
not read symbols: Bad value
cc: error: linker command failed with exit code 1 (use -v to see invocation) I 
am guessing we are having a boundary issue from 32 to 64 bits. Just a guess. I 
am not familiar enough with clang to address the issues.

What is the common thread on all these ports? could not read symbols: Bad value
cc: error: linker command failed with exit code 1 (use -v to see invocation)
GCC may not have been fully compliant, but Clang appears to have a few more 
issues.Now the one program that did compile and I could link to libiconv 
libraries, which build out of the ports, 
that will not build of the source.tar ball.
 Even straight source  (tar balls) that works perfect on 7.4 will not on 10.3  
could not read symbols: Bad value cc: error: linker command failed with exit 
code 1 (use -v to see invocation). So what is the magic switch for this 
compiler to get these to compile?
Any advice would be great? I think we need to fix a few of these. I am betting 
it is the new compiler. Seems a lot of these started showing on 10. and not 
before.
Thank you,Rick
___
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

[Christian Schwarz]

On Tue, Dec 20, 2016 at 10:12:04AM +0100, Franco Fichtner wrote:
> And lastly... if we have the automatic "default" flavour that is
> defined by the OPTIONS_DEFAULT knobs, we could finally avoid pkg
> upgrading custom builds by knowing that somebody built a "custom"
> version of their port and that there is no equivalent to upgrade
> to.
> 
> This is exciting!

While it is exciting, I would be sad to see flavours be the solution to
pkg not recognizing build OPTIONS_ as part of a package's identity
right now[1].

What is not entirely clear to me:

  Are flavours always a tuple of values for OPTIONS_ defined by their
  master port?

The reason I bring this up: a binary package is identified by the
following information:

  - pkg name (the master's name, unique over ports tree)
  - version & revision
  - the artifacts used to build the binary
(tarballs, but also build dependencies, ...)
  - a vector of available options
  - a vector of values for the available options
  - (other stuff you could probably find in a talk on reproducible
 builds)

It is obvious that a master port will have *many* binary incarnations.
To my understanding, flavours are a comfortable way to write down some
commonly used incarnations.

Reducing the package manager's job to checking that some incarnation of
the package is present is surely better than no support for this.

However, I think the logical next step is to have ports declare that
they depend on a subset of specific configuration values being used in
their dependencies.

In this scenario, flavours are no different to pkg than self-built
ports with custom-picked non-(flavour|standard)ized options.
This, I would very much prefer.

Either way: big thanks to bapt and those who contributed so far!

-- Christian

[1] Please continue reading for what I understand as 'package identity'.
___
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: Subscription for committer

[Warren Block]

On Mon, 19 Dec 2016, John Marino wrote:


On 12/19/2016 20:22, Mark Linimon wrote:

On Mon, Dec 19, 2016 at 07:07:06PM -0600, John Marino wrote:

It's a natural reaction to stop attempting to contribute when previous
contributions don't get "attention they deserve".


Which some people (including me) see as odds with:


the impression that portmaster is officially recommended [has] to be
stamped out


People tend to put off working on topics that include "demands".

It's just human nature.

Plus, there are thousands of other PRs to work on that don't involve such
charged language.  Working on those is more rewarding and less frustrating.


It was decided that any implied recommendation for portupgrade and portmaster 
in FreeBSD documentation has to be removed.


Obviously there is some disagreement on this point, as this long, 
multiply-broken, renamed thread has shown.


The docs people are aware of the decision and are charged to implement 
it.


As volunteers, committers are free to choose the work they want to do.

It's not "my" demand.  If valid PRs are in a moving queue, fine.  If 
valid PRs are being conveniently and intentionally forgotten, I would 
say that's not fine.


There is no queue.  Volunteers choose the work they want to do.

and mcl: I challenge you to identify *ANY* offputting language in PR 214679. 
You can't just imply that it exists when it doesn't.


There has been plenty of off-putting language outside of that PR 
referring back to it, including some a few lines above. These are far 
beyond demotivational. More of the same will not have a different 
effect.


My apologies for extending this already too-long thread.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: mail/spamassassin config option AS_ROOT is confusing

[Adam Weinberger]

> On 20 Dec, 2016, at 16:51, RW  wrote:
> 
> On Tue, 20 Dec 2016 11:53:43 -0700
> Mike Brown wrote:
> 
>> The AS_ROOT option in the mail/spamassassin port is really confusing
>> to me. Given that its description is "Run spamd as root
>> (recommended)", what actually happens is somewhat bonkers:
>> 
>> The main spamd process always runs as root. If AS_ROOT is enabled,
>> then the child processes who do all the work will not run as root,
>> but rather as unprivileged user spamd. If AS_ROOT is disabled, then
>> the children *will* run as root, but as needed they will setuid to
>> the user calling spamc. 
>> Which setting you want depends on where user prefs and Bayes data is
>> stored. If it's in user-owned ~/.spamassassin directories, then you
>> want AS_ROOT disabled or you'll get a plethora of error messages and
>> lock file warnings relating to permissions, since user spamd can't
>> write where it needs to.
> 
> That shouldn't happen as the default (without virtual users) is to
> use /var/spool/spamd, the spamd user's home directory.
> 
>> It took me a while to figure this out on a fresh installation. I
>> enabled the option, thinking "yes, of course I want it to run as
>> root, so that it can write to the users' home directories"... then I
>> was confused when it ended up not running as root but rather as user
>> spamd, and the behavior I wanted was only possible if I configured
>> the port to *not* run spamd as root.
>> 
>> I guess I am just griping, but I would like to think there is a
>> better way to describe and name the configuration option. Maybe
>> AS_SPAMD_USER with description "Run spamd as unprivileged user
>> (recommended)"? 
> 
> I never noticed this because (probably like a lot of people) the first
> thing I did was set my own spamd_flags in rc.conf and that overrides
> the effect of AS_ROOT. 
> 
> I do agree it's confusing. I've CC'ed the maintainer. 

Thanks for the Cc, RW. Mike, I completely agree that the wording is terrible.

I think your suggested text ("Run spamd as unprivileged user (recommended)") is 
great.

The ports system also has the ability to put more detail into a pkg-help file 
that shows up as something like "Press ^E for more info." It sounds like this 
would be useful here. It's been a while since I messed around with that option 
so would you be interested in writing a slightly more detailed explanation of 
the difference?

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.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: mail/spamassassin config option AS_ROOT is confusing

[RW via freebsd-ports]

On Tue, 20 Dec 2016 11:53:43 -0700
Mike Brown wrote:

> The AS_ROOT option in the mail/spamassassin port is really confusing
> to me. Given that its description is "Run spamd as root
> (recommended)", what actually happens is somewhat bonkers:
> 
> The main spamd process always runs as root. If AS_ROOT is enabled,
> then the child processes who do all the work will not run as root,
> but rather as unprivileged user spamd. If AS_ROOT is disabled, then
> the children *will* run as root, but as needed they will setuid to
> the user calling spamc. 
> Which setting you want depends on where user prefs and Bayes data is
> stored. If it's in user-owned ~/.spamassassin directories, then you
> want AS_ROOT disabled or you'll get a plethora of error messages and
> lock file warnings relating to permissions, since user spamd can't
> write where it needs to.

That shouldn't happen as the default (without virtual users) is to
use /var/spool/spamd, the spamd user's home directory.

> It took me a while to figure this out on a fresh installation. I
> enabled the option, thinking "yes, of course I want it to run as
> root, so that it can write to the users' home directories"... then I
> was confused when it ended up not running as root but rather as user
> spamd, and the behavior I wanted was only possible if I configured
> the port to *not* run spamd as root.
> 
> I guess I am just griping, but I would like to think there is a
> better way to describe and name the configuration option. Maybe
> AS_SPAMD_USER with description "Run spamd as unprivileged user
> (recommended)"? 

I never noticed this because (probably like a lot of people) the first
thing I did was set my own spamd_flags in rc.conf and that overrides
the effect of AS_ROOT. 

I do agree it's confusing. I've CC'ed the maintainer. 


___
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: Cyrus IMAP in a jail anyone?

[Per olof Ljungmark]

On 2016-12-20 21:45, Per olof Ljungmark wrote:
> Hi,
> 
> I'm facing a peculiar problem with two Cyrus instances both running
> 11.STABLE jails. Using the sync feature I am able to replicate the
> mailboxes but syncing sieve scripts does not work:
> 
> On the sending side(sync_client):
> 
> <1482265840 sync_client[72614]: SIEVE received NO response: System I/O error
> Error from do_user(tester): bailing out!
> sync_client[72614]: Error in do_user(tester): bailing out!
> 
> and on the receiving end:
> 
> syncserver[39165]: IOERROR: creating directory /data: Permission denied
> 
> It occurs when the compiled sieve script attempts transfer.
> 
> Now, the only place where a "/data" exists is on the sending host
> system, it is the root dir of the jails, so, is there any way that the
> jailed Cyrus can learn this? Anyone succesfully running a similar conig
> jailed?
> 

It was me as usual, sorry for the noise.

At least it gave me an opportunity to start using dtrace, thank you to
the FreeBSD team for 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"

Alternate strategy for ports / portupgrade

[Garance A Drosehn]

Hi.  gad@FreeBSD here.  My life at work and "on the personal front"
continues to be a time-consuming morass, so I haven't contributed
much to FreeBSD discussions for the last few years.

I wanted to bring up a strategy I have used for ports in the threads
on "the ports collection has some serious issues", but that thread has
gone all over the map while I've been swamped at work (due to the end-
of-semester rush here at RPI).  So, here's a new thread just to make a
few observations:

1) running a ports collection of the magnitude of the FreeBSD ports
   collection is a massive challenge.  Hats off to anyone who works
   on any of the tools for it.  It's easy to see why people might
   get burned out while working on ports.

2) I happen to use portupgrade, possibly just because I like ruby.
   I did try using poudriere, but it doesn't happen to work well for
   my current systems.  I could certainly see using poudriere (or
   maybe synth?) in the future, if my situation changes.

3) I'm not here to debate what anyone else should use.  This is just
   a short note about a strategy that I've used a few times, and
   which has worked well-enough for me.

Like anyone else, I sometimes get into situations where my set of
ports is "in a mess", and I have trouble upgrading some package or
groups of packages.  I would guess that I end up in this kind of
mess every 18-24 months, on average.

Here's a terse description of how I extract myself from that mess.

On all my machines I have plenty of disk space.  So I create
duplicates of '/', '/var', and '/usr'.  Also, I have '/usr/ports'
in a partition of its own.  I unmount /usr/ports, and then mount:

  #  df -kl
  /dev/ada0p39   1586716   823228   636552   56%   /xx/rePort
  /dev/ada0p40   2082716   538732  1377368   28%   /xx/rePort/var
  /dev/ada0p41   9016380  3389188  4905884   41%   /xx/rePort/usr
  /dev/ada0p33   5450748   898376  4116316   18%   /xx/rePort/usr/ports

I execute:
  #  mount -t devfs   devfs /xx/rePort/dev
  #  mount -t fdescfs fdesc /xx/rePort/dev/fd

so that I'll also have:
  devfs110  100%   /xx/rePort/dev
  fdescfs  110  100%   /xx/rePort/dev/fd

I then have one session chroot-ed into '/xx/rePort', and another
remaining outside of that.  In short, I then blow away all ports which
are inside 'rePort', and build my entire collection up from scratch.
This also forces me to look over all the ports I have, and sometimes
that is a good idea all by itself.  This is always a good time to try
upgrading to new major-versions of perl and python, for instance.

Now I'm skipping over a lot of details here, but the basic idea is to
build a brand-new /usr/local from scratch, *WITHOUT* touching anything
is currently in /usr/local.  I can test many of those packages by
running them inside the rePort chroot, and I can do a variety of
comparisons between the active /usr/local (config files, etc) and the
new one.

Note that I can do this at my own pace.  Maybe it'll take me a week or
two, building and cross-checking ports in my spare time.  And once I'm
optimistic enough, I'll rsync /xx/rePort/usr/local back to /usr/local-new
on the real system.  I can then try switching between the old and new
via 'mv /usr/local /usr/local-old && mv /usr/local-new /usr/local'.

There's additional work to move info under '/xx/rePort/var' to where
it belongs in the real '/var'.  There's some other things I do, but
this message is already pretty long.  I also have some notes on ways
that maybe this could be improved, assuming I ever have the spare time.
(I'll also note that I make snapshots of all the rePort partitions
before I start, so that I can use those snapshots to find *everything*
which has changed under rePorts when I'm done).

I just thought I'd mention this idea, in case it might help out
someone who finds themselves in a mess when upgrading ports, and
they can't afford a lot of downtime to clean up the mess.

Cheers to all, and to all a good night.

-- 
Garance Alistair Drosehn= dro...@rpi.edu
Senior Systems Programmer   or   g...@freebsd.org
Rensselaer Polytechnic Institute; Troy, NY;  USA
___
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"

[jchamp...@apache.org: [ANNOUNCE] Apache HTTP Server 2.4.25 Released]

[The Doctor]

Heads up!!

- Forwarded message from Jacob Champion  -

Date: Tue, 20 Dec 2016 12:17:57 -0800
From: Jacob Champion 
To: annou...@httpd.apache.org
Subject: [ANNOUNCE] Apache HTTP Server 2.4.25 Released
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.5.1

 Apache HTTP Server 2.4.25 Released

The Apache Software Foundation and the Apache HTTP Server Project
are pleased to announce the release of version 2.4.25 of the Apache
HTTP Server ("Apache").  This version of Apache is our latest GA
release of the new generation 2.4.x branch of Apache HTTPD and
represents fifteen years of innovation by the project, and is
recommended over all previous releases. This release of Apache is
a security, feature, and bug fix release, and addresses these
specific security defects as well as other fixes:

  CVE-2016-0736 (cve.mitre.org)
  mod_session_crypto: Authenticate the session data/cookie with a
  MAC (SipHash) to prevent deciphering or tampering with a padding
  oracle attack.

  CVE-2016-2161 (cve.mitre.org)
  mod_auth_digest: Prevent segfaults during client entry allocation
  when the shared memory space is exhausted.

  CVE-2016-5387 (cve.mitre.org)
  core: Mitigate [f]cgi "httpoxy" issues.

  CVE-2016-8740 (cve.mitre.org)
  mod_http2: Mitigate DoS memory exhaustion via endless
  CONTINUATION frames.

  CVE-2016-8743 (cve.mitre.org)
  Enforce HTTP request grammar corresponding to RFC7230 for request
  lines and request headers, to prevent response splitting and cache
  pollution by malicious clients or downstream proxies.

NOTE: Version 2.4.24 was not released.

We consider this release to be the best version of Apache available, and
encourage users of all prior versions to upgrade.

Apache HTTP Server 2.4.25 is available for download from:

  http://httpd.apache.org/download.cgi

Apache 2.4 offers numerous enhancements, improvements, and performance
boosts over the 2.2 codebase.  For an overview of new features
introduced since 2.4 please see:

  http://httpd.apache.org/docs/trunk/new_features_2_4.html

Please see the CHANGES_2.4 file, linked from the download page, for a
full list of changes. A condensed list, CHANGES_2.4.25 includes only
those changes introduced since the prior 2.4 release.  A summary of all
of the security vulnerabilities addressed in this and earlier releases
is available:

  http://httpd.apache.org/security/vulnerabilities_24.html

This release requires the Apache Portable Runtime (APR) version 1.5.x
and APR-Util version 1.5.x. The APR libraries must be upgraded for all
features of httpd to operate correctly.

This release builds on and extends the Apache 2.2 API.  Modules written
for Apache 2.2 will need to be recompiled in order to run with Apache
2.4, and require minimal or no source code changes.

  http://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING

When upgrading or installing this version of Apache, please bear in mind
that if you intend to use Apache with one of the threaded MPMs (other
than the Prefork MPM), you must ensure that any modules you will be
using (and the libraries they depend on) are thread-safe.

Please note that Apache Web Server Project will only provide maintenance
releases of the 2.2.x flavor through June of 2017, and will provide some
security patches beyond this date through at least December of 2017.
Minimal maintenance patches of 2.2.x are expected throughout this
period, and users are strongly encouraged to promptly complete their
transitions to the the 2.4.x flavor of httpd to benefit from a much
larger assortment of minor security and bug fixes as well as new
features.

- End forwarded message -

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Merry Christmas 2016 and Happy New Year 2017
___
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"

Cyrus IMAP in a jail anyone?

[Per olof Ljungmark]

Hi,

I'm facing a peculiar problem with two Cyrus instances both running
11.STABLE jails. Using the sync feature I am able to replicate the
mailboxes but syncing sieve scripts does not work:

On the sending side(sync_client):

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

RE: amazing

[Chapter ISOC Chapter Support]

Hey,
I've just found something really amazing, I'm shocked! Just take a look 


Cheers, Chapter ISOC Chapter Support



From: freebsd-ports [mailto:freebsd-ports@FreeBSD.org]
Sent: Tuesday, December 20, 2016 4:30 PM
To: livejour...@bekreyev.ru
Subject: Ah.  My bad.

I think you might be half-right. Jenny death does exist, but considering that 
Inanimate Sensation is basically  about the contempt that Ride has for his fans 
 I could see them holding off on  the release  just to fuck with us. If  that 
was their intent then they did  a great job, JD was the  only thing I wanted 
for  christmas and it really fucked with me  not getting it.


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

mail/spamassassin config option AS_ROOT is confusing

[Mike Brown]

The AS_ROOT option in the mail/spamassassin port is really confusing to me. 
Given that its description is "Run spamd as root (recommended)", what actually 
happens is somewhat bonkers:

The main spamd process always runs as root. If AS_ROOT is enabled, then the 
child processes who do all the work will not run as root, but rather as 
unprivileged user spamd. If AS_ROOT is disabled, then the children *will* run 
as root, but as needed they will setuid to the user calling spamc.
 
Which setting you want depends on where user prefs and Bayes data is stored. 
If it's in user-owned ~/.spamassassin directories, then you want AS_ROOT 
disabled or you'll get a plethora of error messages and lock file warnings 
relating to permissions, since user spamd can't write where it needs to.

It took me a while to figure this out on a fresh installation. I enabled the 
option, thinking "yes, of course I want it to run as root, so that it can 
write to the users' home directories"... then I was confused when it ended up 
not running as root but rather as user spamd, and the behavior I wanted was 
only possible if I configured the port to *not* run spamd as root.

I guess I am just griping, but I would like to think there is a better way to 
describe and name the configuration option. Maybe AS_SPAMD_USER with 
description "Run spamd as unprivileged user (recommended)"? Not sure this 
really would've helped me know which option to choose, but it would've spared
me from part of the wild goose chase I've been on all day.

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

Re: The ports collection has some serious issues

[Baptiste Daroussin]

On Tue, Dec 20, 2016 at 11:57:38PM +1100, Dave Horsfall wrote:
> On Mon, 19 Dec 2016, John Marino wrote:
> 
> > I never, not once, tried to "get rid of portmaster".  By repeating this 
> > untruth after I already corrected you is trolling.  There was a very 
> > small chance you were just ignorant but thanks for admitting you knew 
> > exactly what you were doing and making Dave H. look silly.
> > 
> > What I have (and others) wanted?  What would make us happy?
> 
> Perhaps for you to just quietly FOAD?  When it comes to common sense, you 
> appear to be utterly impervious.
> 

The direction this thread is taking is intollerable in our community, please
stay polite and keep this discussion civil (or rather bring it back to a civil
discussion).

We will not accept such insults in our community

Bapt


signature.asc
Description: PGP signature

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

[Luca Pizzamiglio]

Hi,

I think it's a nice to have and an improvement.
It's quite clean, even if the number of Makefile's can really increase.

I've some questions:

Q1) It seems obvious (at least to me), that DOCS and EXAMPLES
should/could become subpackages.
How it could be handled by pkg? Are you thinking to add some "magic"
to enable or disable the automatic installation of specific
subpackages?

Q2) are we opening the door the -devel packages like some Linux distros?

Q3) Do you think there is a general way to decide what should stay an
OPTION and what should/could become a FLAVOR?

Q4) Can FLAVORs be in CONFLICT with each others or only conflict-free
FLAVOR will be accepted?
If ports can depend to FLAVOR, strange CONFLICTS can arise..

Thanks for the great job! I'll keep contributing as much as I can.

Best regards,
Luca

On Tue, Dec 20, 2016 at 10:12 AM, Franco Fichtner  wrote:
>
>> On 20 Dec 2016, at 9:42 AM, Franco Fichtner  wrote:
>>
>> To emphasise on this:
>
> And lastly... if we have the automatic "default" flavour that is
> defined by the OPTIONS_DEFAULT knobs, we could finally avoid pkg
> upgrading custom builds by knowing that somebody built a "custom"
> version of their port and that there is no equivalent to upgrade
> to.
>
> This is exciting!
>
>
> 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"
___
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: Gettext Issues

[@lbutlr]

On Dec 17, 2016, at 4:36 AM, Tijl Coosemans  wrote:
> 
> Can you email me
> /usr/ports/devel/gettext-runtime/work/gettext-0.19.8.1/gettext-runtime/config.log

I did get this fixed by restoring the various so.# files from backups until 
bash and sudo and others stopped complaining.

What I am going to do after the holidays is simply install freeBSD $LATEST onto 
a new machine, sync over all the mail, and install fresh ports of everything. I 
think in the migrations from freeBSD 8 to 9 to 10 this machine has left behind 
too much kruft.

For right now, most everything is working and all the important things are 
working.

I would send the file, but at this point it’s empty (as part of a attempt at 
starting over I trashed and rebuilt /usr/ports).

I should have posted my “solution” but end-of-year and holidays reared their 
ugly heads.

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

Re: The ports collection has some serious issues

[David Demelier]

2016-12-20 13:57 GMT+01:00 Dave Horsfall :
> Perhaps for you to just quietly FOAD?  When it comes to common sense, you
> appear to be utterly impervious.

Perhaps we can stay polite?

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

Re: The ports collection has some serious issues

[Dave Horsfall]

On Mon, 19 Dec 2016, John Marino wrote:

> I never, not once, tried to "get rid of portmaster".  By repeating this 
> untruth after I already corrected you is trolling.  There was a very 
> small chance you were just ignorant but thanks for admitting you knew 
> exactly what you were doing and making Dave H. look silly.
> 
> What I have (and others) wanted?  What would make us happy?

Perhaps for you to just quietly FOAD?  When it comes to common sense, you 
appear to be utterly impervious.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Franco Fichtner]

> On 20 Dec 2016, at 9:42 AM, Franco Fichtner  wrote:
> 
> To emphasise on this:

And lastly... if we have the automatic "default" flavour that is
defined by the OPTIONS_DEFAULT knobs, we could finally avoid pkg
upgrading custom builds by knowing that somebody built a "custom"
version of their port and that there is no equivalent to upgrade
to.

This is exciting!


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"

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

[Franco Fichtner]

> On 20 Dec 2016, at 9:27 AM, Franco Fichtner  wrote:
> 
> We shouldn't use "-" or "/" anyway, should we?  Please no fancy things
> like "~" or so.  No arbitrary package names...

To emphasise on this:

A flavour should act as a full replacement of its unflavoured package, that
means the package name must be kept.  Only one flavour (or unflavoured)
package can be installed at all times.  As an example:

A weird package "foo" requires "vim", but the user doesn't want to deal with
X11, the user should be able to:

# pkg install vim:lite foo

This should not try to change "vim:lite" to "vim".

# pkg install vim

This should be perfectly fine afterwards, too.

Every "vim" should act as "vim", not revoking the integrity of the package
dependency on vim during e.g. pkg upgrade.  No forced install should be
needed to do this as long as the shared libraries and dependencies are still
satisfied.  And maybe the moral of the story is that flavours should not
be depended on by default, although it could be a possibility for special
cases.

This is something that is really really needed.  An very good example would
be Suricata package with Hyperscan right now, where Hyperscan does not work
on all amd64 architectures, so we need to have a replacement package.  But
if that replacement package without Hyperscan needs to be a separate port,
any package depending on Suricata (e.g. a distribution or GUI package) will
complain about the missing dependency and try to undo a Suricata-No-Hyperscan
package[1] as it conflicts and changes back to the defunct package on upgrade.


Cheers,
Franco

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210490
___
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

[Franco Fichtner]

Hi,

> On 19 Dec 2016, at 1:31 AM, Baptiste Daroussin  wrote:
> 
> For flavors I would like to propose a simple approach first which is more 
> like a
> rework of the slave ports for now:

This progression sure is nice to see!  I like "category/portname/flavour"
origin a lot, but how is it handled in terms of packages names?

Are we going to see something like:

# pkg install myport:flavour

We shouldn't use "-" or "/" anyway, should we?  Please no fancy things
like "~" or so.  No arbitrary package names...

In OpenBSD, installing flavoured packages has been hard to script in the
past, offering a prompt whenever the main package is going to be installed.
The thing to think about here is that

# pkg install myport

Should *only* install the default port, especially with -y option.

# pkg install myport:

This *could* prompt for flavours, then.  The nice thing should be the
user doesn't have to care about flavours if that is so.

Flavours as you showed can be very simple.  Why not go the extra mile
here:

FLAVOURS=   sub1 sub2

OPTIONS_sub1=   EXPLICIT LIST OF OPTIONS
OPTIONS_sub2=   ANOTHER LIST OF OPTIONS

And keep everything as is.  No need for sub-packages?  No implied
OPTIONS_DEFAULT, no nothing.  A single line to grep and change.  :)

>From this perspective, nothing changes for users of the ports tree, options
are defined by the main port and all of its flavours are neatly stored in
the Makefile.  People can still use all options during rebuild, even the
ones only used in flavours.


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"

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"

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
archivers/dpkg  | 1.18.16 | 1.18.17
+-+
graphics/opencv2| 2.4.13.1| 2.4.13.2
+-+
graphics/opencv2-core   | 2.4.13.1| 2.4.13.2
+-+
graphics/opencv2-java   | 2.4.13.1| 2.4.13.2
+-+
graphics/py-opencv2 | 2.4.13.1| 2.4.13.2
+-+
www/WebMagick   | 2.03pre27   | 2.03pre28
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

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