Re: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 1:23 pm, Kurt Jaeger wrote:

Hi!


There's a blog post from one of the folks that explains the
idea behind that 'fast update' mode of operations, and yes,
he's doing real work.
http://blog.koehntopp.info/index.php/1776-rolling-out-patches-and-changes-often-and-fast/

That is ONE kind of installation.

Well, there's the thinking that in the not-to-far future, everything
is connected, and you'll need to be able to update at any time
because of whatever security/threat that IT ecosystem throws at you.


It DOES NOT WORK when th most you can upgrade a customer system is
once a year or once every two years.

The 'other side' of the debate thinks: Well, if they think this
is the way to do it, they have a problem and need to change
their procedures.

The viewpoint is: That system can start debating with the next
worm/trojan coming along, but that won't help. The assumption
is: everything is connected/on the internet, and not even
voluntarily.

Think connected cars, IoT etc.


I will add that such users would help their own case by fixing such
issues and feeding the changes back to their branches upstream,
thus helping maintain the branch. Maybe we could have a system of
"corporate sponsors" for these branches.

Given the state of fundraising in open source, I doubt that this
will be viable.

My personal experience is that if it were put in the form of an annual s
subscription, most mid sized corporate finance offices wouldn't blink 
at $20k
if they thought it was an important part of their product.  (that's 
the key)

Some wouldn't blink at 50K.  ("the software is free but we need to
help pay for people to do real work to keep it safe, it'll save us (some
fraction of) a full time person").

The problem is that such a set of sponsored branches does not exist so
knowing who'd sign up and who would't is just guesswork, and the companies
have made "alternative arrangements"  whether that means somewhat forgoing
the ports tree (e.g Vicor) or building an infrastructure around ports
head ( e.g. Panzura), or having some other snapshotting system ( e.g 
Ironport/Cisco)



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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Kurt Jaeger]

Hi!

> > There's a blog post from one of the folks that explains the
> > idea behind that 'fast update' mode of operations, and yes,
> > he's doing real work.

> > http://blog.koehntopp.info/index.php/1776-rolling-out-patches-and-changes-often-and-fast/

> That is ONE kind of installation.

Well, there's the thinking that in the not-to-far future, everything
is connected, and you'll need to be able to update at any time
because of whatever security/threat that IT ecosystem throws at you.

> It DOES NOT WORK when th most you can upgrade a customer system is 
> once a year or once every two years.

The 'other side' of the debate thinks: Well, if they think this
is the way to do it, they have a problem and need to change
their procedures.

The viewpoint is: That system can start debating with the next
worm/trojan coming along, but that won't help. The assumption
is: everything is connected/on the internet, and not even
voluntarily.

Think connected cars, IoT etc.

> I will add that such users would help their own case by fixing such 
> issues and feeding the changes back to their branches upstream,
> thus helping maintain the branch. Maybe we could have a system of 
> "corporate sponsors" for these branches.

Given the state of fundraising in open source, I doubt that this
will be viable.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 12:39 pm, Mark Linimon wrote:

On Fri, Jun 23, 2017 at 11:58:14AM +0800, Julian Elischer wrote:

What we want is:
A "recent" starting point for our next project/upgrade to start from
and an ongoing version of that, which will get critical fixes only for
at LEAST 2 years, probably 5.
The key here is the *_*critical fixes only*_* part.

And how much is that worth to you and/or your company?

glad you asked.

If we had such a setup it would probably be worth a good part of a 
person's salary.


Since we have had to do without it, we have workarounds in place that 
took a lot of work to make.
But we are now running a  parallel system where we are taking 
snapshots of head and using them.
The downside is that we don't have the resources to follow all the 
Security issues so we are forced
to do cross-revision upgrades sometimes where for example all the 
packages we install were
compiled from a tree that approximates 10.3 ports, but the openssl 
package is from a source tree
that is much newer.  We enjoy this about as much as having our 
corporate wisdom teeth pulled out

but it's forced on us.
In the near future we will be taking a new snapshot for the next 
release. What branch and revision
of the ports tree wil be snapshotted is still not decided, If there 
were a suitable first-half-2017
stable branch we'd take that for sure, then we'd follow it, merging 
changes in, and probably feeding

fixes back.

Since there are no "security patch only" branches, What we will 
probably end up doing is
snapshotting head and crossing our fingers hoping that we notice any 
relevant
vulnerabilities and have the time to work out a fix. Of course If 
there is no easy patch, we
may have to do single-package upgrades, which is usually only painless 
for  a short time

after the snapshot, because the Makefile infrastructure keeps changing.



I mean, honestly.  You constantly criticize the volunteers for not doing
what you need.  Well _need_, to me, implies the existence of some kind
of incentive.  I can state to you, flatly, that "a feeling of a job well
done" isn't _sufficient incentive_ to do professional-level QA.  There's
a reason people get _paid to do it_: it's hard, long, tedious, unrewarding
work, and it never ends.

Clearly, relying on _volunteers_ to do professional-level QA isn't working
out for you.

Thus, IMVVHO, at this point, to get what you _need_, you need to get out
your checkbook and provide a _financial_ incentive.  In my experience,
with the volunteers that we have, we can barely keep things afloat as
it is.  It's sufficiently hard to recruit people, and burnout is high
-- especially given the grief we take.

(I won't even start on how even "critical fixes" can drag in the need
to update dependencies, which then conflict with each other, and so on
and so forth, and thus even "critical fixes" aren't trivial.)

Summary: you are providing negative incentive to the ports crew, with
no upside for them, and you can't understand why it doesn't work.

tl;dr: you want us to be RedHat but with no paid employees.

mcl



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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Mark Linimon]

On Fri, Jun 23, 2017 at 11:58:14AM +0800, Julian Elischer wrote:
> What we want is:
> A "recent" starting point for our next project/upgrade to start from
> and an ongoing version of that, which will get critical fixes only for
> at LEAST 2 years, probably 5.
> The key here is the *_*critical fixes only*_* part.

And how much is that worth to you and/or your company?

I mean, honestly.  You constantly criticize the volunteers for not doing
what you need.  Well _need_, to me, implies the existence of some kind
of incentive.  I can state to you, flatly, that "a feeling of a job well
done" isn't _sufficient incentive_ to do professional-level QA.  There's
a reason people get _paid to do it_: it's hard, long, tedious, unrewarding
work, and it never ends.

Clearly, relying on _volunteers_ to do professional-level QA isn't working
out for you.

Thus, IMVVHO, at this point, to get what you _need_, you need to get out
your checkbook and provide a _financial_ incentive.  In my experience,
with the volunteers that we have, we can barely keep things afloat as
it is.  It's sufficiently hard to recruit people, and burnout is high
-- especially given the grief we take.

(I won't even start on how even "critical fixes" can drag in the need
to update dependencies, which then conflict with each other, and so on
and so forth, and thus even "critical fixes" aren't trivial.)

Summary: you are providing negative incentive to the ports crew, with
no upside for them, and you can't understand why it doesn't work.

tl;dr: you want us to be RedHat but with no paid employees.

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

[Julian Elischer]

On 23/6/17 7:28 am, Grzegorz Junka wrote:


On 22/06/2017 15:50, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman
 wrote:


On 2017/06/22 15:03, scratch65...@att.net wrote:

Why don't the same choices apply here?  What am I missing?

Two things:

  1) It's progress in the development of the FreeBSD base system that
drives the release cycle.  The general state of the ports does not 
exert

much influence on release frequency -- nor should it.

Still not getting it, I'm afraid.How often does the base
system undergo such drastic architecture changes that existing
ports won't run under it?  I haven't really been monitoring the
situation, but I'd guess it's very seldom if only because such an
architectural change is a cursëd big job that can hardly ever be
justfied.

I'd guess that most adults for whom systems are tools not toys
are not too dissimilar to me:  I want to *use* my tools, not
spend time replacing them every quarter or even every year.  As
long as they do the job and don't compromise the system, they're
fine by me.  I have apps running under Win7 that were written for
W2K (and in one case NT, iirc), and they're just as useful today
as they were then.  They do the job: why in the name of sanity
should I replace them?



Not sure how you use your tools or in which industry you work. Take 
front-end development for example.


here lies the crux of the problem.
FreeBSD is often not a front-end software module.
It is often used to provision off-line (from a 
management/administrative perspective) systems.

Front end or personal systems can be upgraded day by day.
Real products such as routers, proxies, gateways, accounting systems, 
firewalls etc. can NOT be upgraded every day.

you are lucky if the customer allows you to do it once a year.

Chrome is releasing a new version every couple of days. Sure, I 
don't upgrade every release, but when I am developing a website, I 
want to test using the same version that my customers are using, 
which is the latest, since Chrome on Windows updates itself 
automatically. The same with new versions of Firefox. Often new 
versions of browsers require new versions of libraries to support 
new features (CSS/JavaScript). That requires new versions of 
compiler and transpilers. They may, in turn, require an updated 
version of node or npm.


Take server-side development as another example. Erlang is releasing 
a new version of OTP every couple of weeks. Sure, I don't need a new 
version when supporting an old application, but I may need one when 
starting a new application. Especially that many libraries that I am 
going to use won't support Erlang older than a specific version.


A similar story with C++ development, where the standard is being 
constantly developed and compilers are adding these features every 
release. Again, you may not need these new features, but a library 
that you need to use may require the new version.


 No matter how long you are going to maintain a specific version of 
ports with locked down versions of applications, there will surely 
come a time when you will need to upgrade. And for every user that 
time will be different. The current model is in my opinion the most 
common denominator - we can't maintain multiple branches with past 
versions so lets try to properly maintain one with current versions.


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

[Julian Elischer]

On 23/6/17 2:57 am, Dave Hayes wrote:

On 06/22/2017 11:43, demelier.da...@gmail.com wrote:

Let me use my example of www/node back. I have built the port www/node
in poudriere using this origin (so no version). At the time I've built
it it was a 6.x version. When I upgraded my machine, www/node has
switched to 7.x version and since this software follows semantic
versioning, every application using the 6.x branch may or may not work
anymore.


I completely agree that an annoying consequence of what the 
volunteers are doing with the ports tree. These unwelcome surprises 
are the bulk of my non-automated work in creating package repositories.


Frankly, I also wish this kind of thing would stop. Ultimately my 
wishes are irrelevant for reasons far far beyond the scope of this 
thread.



Now, I'm in a state where if I pull the ports tree, I must check if
www/node6 still exists or I must not upgrade.

With releases branches I will be sure that:

  1. www/node will *always* be at a 6.x version;
  2. www/node will still be supported for the version of the FreeBSD
system.


That sounds reasonable...yet others will likely expect www/node to 
always be the latest version. Perhaps these others might complain 
that it is not the latest version and it would be reasonable to have 
node always be at the latest version.
then at install they should set their packages to follow head, and 
ignore the branches.


Would you agree that release branches would be unnecessary if 
somehow you could select the version of node that the ports tree 
builds via some (as yet unspecified) mechanism?



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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 10:39 am, Kurt Jaeger wrote:

Hi!


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

There's a blog post from one of the folks that explains the
idea behind that 'fast update' mode of operations, and yes,
he's doing real work.

http://blog.koehntopp.info/index.php/1776-rolling-out-patches-and-changes-often-and-fast/


That is ONE kind of installation.

It only works if you are talking about a software module that is 
either dynamically delivered (think web apps that are downloaded every 
time they are run) or at lear often redelivered. (say, a personal 
system that gets automatic upgrades, a-la slack on OS-X (they seem to 
have  anew version every week or two)
It DOES NOT WORK when th most you can upgrade a customer system is 
once a year or once every two years.


That kind of installation basically "follows head". It doesn't need 
ANY branches. So quarterly branches are of no use to them either.
They are a minority of all commercial users, and a completely non 
existent part of appliance manufacturers,

(because you can't do it that way unless you only have 2 customers (*)).

 * and even then, the customers may only allow you to upgrade every 
so often. For example Bank of America only allow their FreeBSD 
machines to be upgraded after a several month testing and burn-in 
period on a parallel test system with real data and dummy users, and 
that can obviously only happen on a yearly scale as it costs a lot to 
do. (ask Devin about the details..it's been a while since I worked on 
their stuff but I know it's still similar).


To be useful any branch must:
1/ not make unneeded changes, but DO include all/most CRITICAL changes.
2/ stay around and be buildable for at least 3 years, preferably 5.

Note that a company can take care of point 2 themselves to some extent 
by mirroring etc.
but they probably don't have the expertise to handle all if the 
critical (security) patches part of the picture.


I will add that such users would help their own case by fixing such 
issues and feeding the changes back to their branches upstream,
thus helping maintain the branch. Maybe we could have a system of 
"corporate sponsors" for these branches.





___
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

[The Doctor]

On Fri, Jun 23, 2017 at 11:43:14AM +1000, Dewayne Geraghty wrote:
> 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.

Will this work for the 1.6.X ?

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

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
https://www.empire.kred/ROOTNK?t=94a1f39b  Look at Psalms 14 and 53 on Atheism
Talk Sense to a fool and he calls you foolish - Euripides
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Kurt Jaeger]

Hi!

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

There's a blog post from one of the folks that explains the
idea behind that 'fast update' mode of operations, and yes,
he's doing real work.

http://blog.koehntopp.info/index.php/1776-rolling-out-patches-and-changes-often-and-fast/

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baho Utot]

On 6/22/2017 8:31 PM, Grzegorz Junka wrote:


On 22/06/2017 23:16, Baho Utot wrote:

On 6/22/2017 6:36 PM, Miroslav Lachman wrote:

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

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


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

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


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


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


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




That is just an argument to not do anything, by default.

Here is my point, I am a user that installs an OS ( FreeBSD-11.0). 
Then builds the base from releng-11.0.  Followed by building the 
ports I need.  That doesn't give me a usable system always. Should I 
not be able to do the above and expect a stable system? If not I am 
running the wrong OS/system.  Updates are another monster as I do not 
want to place my now running system ( finally stable ) and do this 
all over again.  I am not up for that.  Hell FreeBSD can not even 
boot my dual boot system Win7 and FreeBSD 11.0 on zfs raid without 
going to BIOS and selecting the disk to boot from.  No one here could 
point me to how to set it up using grub as a boot loader!  The only 
information I got was to wing it using half baked information.


A user would probably start with precompiled packages. Only power 
users who know what they are doing would try to compile the packages 
themselves, and at that point I would expect them to know a thing or 
two about verifying that they compile and work fine.

Grzegorz


The pre-compiled packages is what drove me to build the entire system as 
it gave me a broken system that would not work and upon getting it to 
function would/**/spontaneous reboot.  My hand built packages stopped that.


I have built run LFS for 10 years.  I created a packaging system using 
rpm for LFS ( it is on github ) .  I worked for turbolinux as a beta 
tester and worked with the folks that kept KDE3 alive, so I am some one 
that knows something.


I can say from a user stand point ( and previous packager ) that the 
base packages is nothing but a f'n mess.  I still have not cleaned up my 
desktop system after trying base packages.  I was told the only way to 
fix that was to delete the entire pkg database and reinstall all the 
packages I had installed.   That is just not acceptable.  One should be 
able to just delete the entry of the package in the package database and 
move on.  I was going to build a tool to do just that.  I then came 
across OpenBSD, so I have delayed that until I decide if OpenBSD is a 
good fit for me. pkgng is almost a beta product at this date.


What is wrong with open source projects is this holier that thou 
attitude,  you folks would do well to lose that attitude and start 
working WITH instead of against the users of your system.   They may not 
always be right but they SHOULD BE AT LEAST HEARD.


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

www/libxul

[George Mitchell]

At svn revision 443684.

After "make clean extract":
work/firefox-45.9.0esr/.mozconfig does not exist.
No file under www/libxul contains the string "--enable-jemalloc=4".
In particular, no patch file in the files directory refers to
.mozconfig or contains "--enable-jemalloc=4".

But after "make patch":
work/firefox-45.9.0esr/.mozconfig has been created and contains
"--enable-jemalloc=4".
Consequently, the configure script dies at line 26248, complaining
that "Option, jemalloc, does not take an argument (4)".

I'd love to propose a patch to fix this problem, but I cannot
discover for the life of me where the "--enable-jemalloc=4" came
from.  What am I missing?

If I make patch, then manually delete the line:
ac_add_options --enable-jemalloc=4
that mysteriously appeared in .mozconfig and then run configure,
all is well. -- George



signature.asc
Description: OpenPGP digital signature

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

On 22/06/2017 23:16, Baho Utot wrote:

On 6/22/2017 6:36 PM, Miroslav Lachman wrote:

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

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


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

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


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


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


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




That is just an argument to not do anything, by default.

Here is my point, I am a user that installs an OS ( FreeBSD-11.0). 
Then builds the base from releng-11.0.  Followed by building the ports 
I need.  That doesn't give me a usable system always. Should I not be 
able to do the above and expect a stable system? If not I am running 
the wrong OS/system.  Updates are another monster as I do not want to 
place my now running system ( finally stable ) and do this all over 
again.  I am not up for that.  Hell FreeBSD can not even boot my dual 
boot system Win7 and FreeBSD 11.0 on zfs raid without going to BIOS 
and selecting the disk to boot from.  No one here could point me to 
how to set it up using grub as a boot loader!  The only information I 
got was to wing it using half baked information.


A user would probably start with precompiled packages. Only power users 
who know what they are doing would try to compile the packages 
themselves, and at that point I would expect them to know a thing or two 
about verifying that they compile and work fine.

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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

On 22/06/2017 15:50, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman
 wrote:


On 2017/06/22 15:03, scratch65...@att.net wrote:

Why don't the same choices apply here?  What am I missing?

Two things:

  1) It's progress in the development of the FreeBSD base system that
drives the release cycle.  The general state of the ports does not exert
much influence on release frequency -- nor should it.

Still not getting it, I'm afraid.How often does the base
system undergo such drastic architecture changes that existing
ports won't run under it?  I haven't really been monitoring the
situation, but I'd guess it's very seldom if only because such an
architectural change is a cursëd big job that can hardly ever be
justfied.

I'd guess that most adults for whom systems are tools not toys
are not too dissimilar to me:  I want to *use* my tools, not
spend time replacing them every quarter or even every year.  As
long as they do the job and don't compromise the system, they're
fine by me.  I have apps running under Win7 that were written for
W2K (and in one case NT, iirc), and they're just as useful today
as they were then.  They do the job: why in the name of sanity
should I replace them?



Not sure how you use your tools or in which industry you work. Take 
front-end development for example. Chrome is releasing a new version 
every couple of days. Sure, I don't upgrade every release, but when I am 
developing a website, I want to test using the same version that my 
customers are using, which is the latest, since Chrome on Windows 
updates itself automatically. The same with new versions of Firefox. 
Often new versions of browsers require new versions of libraries to 
support new features (CSS/JavaScript). That requires new versions of 
compiler and transpilers. They may, in turn, require an updated version 
of node or npm.


Take server-side development as another example. Erlang is releasing a 
new version of OTP every couple of weeks. Sure, I don't need a new 
version when supporting an old application, but I may need one when 
starting a new application. Especially that many libraries that I am 
going to use won't support Erlang older than a specific version.


A similar story with C++ development, where the standard is being 
constantly developed and compilers are adding these features every 
release. Again, you may not need these new features, but a library that 
you need to use may require the new version.


 No matter how long you are going to maintain a specific version of 
ports with locked down versions of applications, there will surely come 
a time when you will need to upgrade. And for every user that time will 
be different. The current model is in my opinion the most common 
denominator - we can't maintain multiple branches with past versions so 
lets try to properly maintain one with current versions.


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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baho Utot]

On 6/22/2017 6:36 PM, Miroslav Lachman wrote:

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

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


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

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


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


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


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




That is just an argument to not do anything, by default.

Here is my point, I am a user that installs an OS ( FreeBSD-11.0). Then 
builds the base from releng-11.0.  Followed by building the ports I 
need.  That doesn't give me a usable system always.  Should I not be 
able to do the above and expect a stable system?  If not I am running 
the wrong OS/system.  Updates are another monster as I do not want to 
place my now running system ( finally stable ) and do this all over 
again.  I am not up for that.  Hell FreeBSD can not even boot my dual 
boot system Win7 and FreeBSD 11.0 on zfs raid without going to BIOS and 
selecting the disk to boot from.  No one here could point me to how to 
set it up using grub as a boot loader!  The only information I got was 
to wing it using half baked information.


FreeBSD needs a stable OS followed by a booting method/software followed 
by a stable ports system.


Linux became the custer it has because of the constant change for 
changes sake.  FreeBSD is close behind.
That is why I am going to switch to Open BSD as it has "correctness in 
mind" rather than "I got to have the lastest even if it gets me nothing" 
mindset.


You folks are beating yourself to death trying to keep up when it just 
is not necessary ( for most cases, although some one will say that they 
need the latest version of package XYZ ).  For instance, what do I gain 
by using version 11.0 and the ports head, over version 10.0 and the 
ports head at that time?   Well nothing.  YMMV.



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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Miroslav Lachman]

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

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


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

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


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


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


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


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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

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

>On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:
>> My problem is that my industry experience tells me that reducing
>> the frequency of port releases is practically *guaranteed* to be
>> a Really Good Thing for everyone.
>
>I remember before we had the quarterly releases, and people on the
>mailing lists complained constantly about the ports bits only being
>available once per release, or rolling with -head.

Mark, I can only suppose that those complainers are dilettantes
of some sort who believe that having The Latest-And-Greatest Bits
is a social-status enhancer.  **Nobody** with real work to do
ever willingly fools away time "fixing" what isn't broken. That's
why there are still millions of XP boxes in daily use despite
everything M$ has been able to do to force people to give them
up.

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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Mark Linimon]

On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:
> My problem is that my industry experience tells me that reducing
> the frequency of port releases is practically *guaranteed* to be
> a Really Good Thing for everyone.

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

In other words, the exact opposite of what you are suggesting.

tl;dr: there is no way to satisfy everyone.

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

[Andre Goree]

On 2017/06/22 9:00 am, The Doctor wrote:

ARR and APR-utils are up to 1.6.X

Please update ports accordingly.

--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware 
AntiChrist rising!
https://www.empire.kred/ROOTNK?t=94a1f39b  Look at Psalms 14 and 53 on 
Atheism

Talk Sense to a fool and he calls you foolish - Euripides
___
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"



Also, apache2.4 fails to build when ssl=libressl is set it 
/etc/make.conf, seemingly b/c of apr1 configuration/settings (see 
below).  I've noticed when running make config on devel/apr1, it has 
only ticks for 'openssl' & 'nss', FWIW.



/usr/local/share/apr/build-1/libtool --silent --mode=link cc-O2 
-pipe -I/usr/local/include -DLIBICONV_PLUG -fstack-protector 
-fno-strict-aliasing-L/usr/local/lib/db5 -L/usr/lib  
-L/usr/local/lib -Wl,-rpath,/usr/local/lib -fstack-protector -o 
fcgistarter  fcgistarter.lo  -L/usr/local/lib -R/usr/local/lib $
laprutil-1 -ldb-5.3 -lgdbm -lexpat -L/usr/local/lib -R/usr/local/lib 
-lapr-1 -lcrypt -lpthread

--- ab ---
ab.o: In function `main':
ab.c:(.text+0xbd9): undefined reference to 
`SSL_CTX_set_max_proto_version'
ab.c:(.text+0xbea): undefined reference to 
`SSL_CTX_set_min_proto_version'
cc: error: linker command failed with exit code 1 (use -v to see 
invocation)

*** [ab] Error code 1

make[4]: stopped in /usr/ports/www/apache24/work/httpd-2.4.26/support
1 error

make[4]: stopped in /usr/ports/www/apache24/work/httpd-2.4.26/support
*** [all-recursive] Error code 1

make[3]: stopped in /usr/ports/www/apache24/work/httpd-2.4.26/support
1 error

make[3]: stopped in /usr/ports/www/apache24/work/httpd-2.4.26/support
*** [all-recursive] Error code 1

make[2]: stopped in /usr/ports/www/apache24/work/httpd-2.4.26
1 error

make[2]: stopped in /usr/ports/www/apache24/work/httpd-2.4.26
===> Compilation failed unexpectedly.

--
Andre Goree
-=-=-=-=-=-
Email - andre at drenet.net
Website   - http://www.drenet.net
PGP key   - http://www.drenet.net/pubkey.txt
-=-=-=-=-=-
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Dave Hayes]

On 06/22/2017 11:43, demelier.da...@gmail.com wrote:

Let me use my example of www/node back. I have built the port www/node
in poudriere using this origin (so no version). At the time I've built
it it was a 6.x version. When I upgraded my machine, www/node has
switched to 7.x version and since this software follows semantic
versioning, every application using the 6.x branch may or may not work
anymore.


I completely agree that an annoying consequence of what the volunteers 
are doing with the ports tree. These unwelcome surprises are the bulk of 
my non-automated work in creating package repositories.


Frankly, I also wish this kind of thing would stop. Ultimately my wishes 
are irrelevant for reasons far far beyond the scope of this thread.



Now, I'm in a state where if I pull the ports tree, I must check if
www/node6 still exists or I must not upgrade.

With releases branches I will be sure that:

  1. www/node will *always* be at a 6.x version;
  2. www/node will still be supported for the version of the FreeBSD
system.


That sounds reasonable...yet others will likely expect www/node to 
always be the latest version. Perhaps these others might complain that 
it is not the latest version and it would be reasonable to have node 
always be at the latest version.


Would you agree that release branches would be unnecessary if somehow 
you could select the version of node that the ports tree builds via some 
(as yet unspecified) mechanism?

--
Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org
 *The opinions expressed above are entirely my own* 

If you want to get rid of somebody, just tell them something
for their own good.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[demelier . david]

On Thu, 2017-06-22 at 10:43 -0700, Dave Hayes wrote:
> They are not useless to me.
> 
> I maintain a fair number of different package repositories for
> various 
> purposes. Over a long period of time I've found that trying to build 
> from HEAD is a random crapshoot as to whether everything you want
> will 
> build without you having to svn random ports back and forth through
> the 
> revision tree (or patch them yourself), patch your build processes, 
> and/or ask for help (which you often might not get).
> 
> In contrast, the quarterly branches (so far) have built everything
> I've 
> wanted cleanly and this has been true for some years. No, the 
> quarterlies are not perfect, but they seem to be closer to perfect
> than 
> HEAD is.
> 

The problem is not if a port will build fine or not.

Let me use my example of www/node back. I have built the port www/node
in poudriere using this origin (so no version). At the time I've built
it it was a 6.x version. When I upgraded my machine, www/node has
switched to 7.x version and since this software follows semantic
versioning, every application using the 6.x branch may or may not work
anymore. And that was my case, etherpad could not start. Fortunately, I
had the chance that the port www/node6 existed and I could downgrade.

Some people would argue to upgrade etherpad to a version that supports
node 7.x but that is not always an option. Hint: how many application
are still not python 3 compatible ? :-)

Now, I'm in a state where if I pull the ports tree, I must check if
www/node6 still exists or I must not upgrade.

With releases branches I will be sure that:

  1. www/node will *always* be at a 6.x version;
  2. www/node will still be supported for the version of the FreeBSD
system.

Regards,

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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Dave Hayes]

On 06/22/2017 09:16, scratch65...@att.net wrote:

I can't help feeling that there's something very wrong when
people for whom the system is a tool rather than a plaything have
to work around the choices made by the "official" developers.


I'd say this is true no matter what OS you use these days.
--
Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org
 *The opinions expressed above are entirely my own* 

It is only knowledge that will destroy bias.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Dave Hayes]

On 06/22/2017 08:53, Julian Elischer wrote:

Yeah but the quarterly branches are relatively useless because they a
not sync'd to anything and mean nothing special to anyone.


They are not useless to me.

I maintain a fair number of different package repositories for various 
purposes. Over a long period of time I've found that trying to build 
from HEAD is a random crapshoot as to whether everything you want will 
build without you having to svn random ports back and forth through the 
revision tree (or patch them yourself), patch your build processes, 
and/or ask for help (which you often might not get).


In contrast, the quarterly branches (so far) have built everything I've 
wanted cleanly and this has been true for some years. No, the 
quarterlies are not perfect, but they seem to be closer to perfect than 
HEAD is.


Note that you have to handle the edge cases (recent security patches, 
revision mismatch, etc) anyway, HEAD or no. I find I have to handle less 
with the quarterlies because they do generally build cleanly.

--
Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org
 *The opinions expressed above are entirely my own* 

Possession of a system of knowledge, or an interest in it,
or in discovering one, shouldn't be assumed to confer any
license or capacity to operate it. Individual criticisms of
a system, incapacity to operate it, or dissatisfaction with
it should not be confused with any shortcoming of the system
itself.
___
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"

Thunderbird + Lightning on FreeBSD

[Rastko P]

I tried compiling Thunderbird from ports, but it's too big, and there
are errors. I'll try to do it some time again, starting clean.


But in the mean time...

Choosing the macOS extension/add-on format seems to be working for the
binary distribution.

Just go to Most Popular add-ons, and Ligthning will be greyed-out. Click
on the "Add" button, and

choose Mac OS X. And it appears to be working.



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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

[Default] On Thu, 22 Jun 2017 16:16:44 +0200, Baptiste Daroussin
 wrote:

>The model with one branch per release will bring it to way more with a
>maintenance window way larger 

It would indeed!  Factor of 3, I think.  

But I'm really not suggesting that, I'm suggesting that a better
schedule would be one ports release for v10, one for v11, one for
v12, etc.   It could be done for n.0 or any of the others.  Were
it my decision, I'd probably go for n.1, since there might be
fewer bugs than in n.0, but the difference might not be
significant.

My problem is that my industry experience tells me that reducing
the frequency of port releases is practically *guaranteed* to be
a Really Good Thing for everyone.  Yet apparently you and others
on the dev team don't like the idea, and no matter how I much I
think about it, I haven't been able to understand why you don't.

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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

[Default] On Fri, 23 Jun 2017 00:01:45 +0800, Julian Elischer
 wrote:

>I've had this conversation with ports several times, But the requirements
>of  'business' is not their interest.  In fact i was told several times,
>"Don't use our quarterly packages, make your own with poudriere".
>(which makes one wonder "What is the purpose of he quarterlies?)

Indeed.  

I can't help feeling that there's something very wrong when
people for whom the system is a tool rather than a plaything have
to work around the choices made by the "official" developers.
Besides your question, I'd add:  for whom are the developers
developing, if not for those who want a useful tool rather than a
hobby? 

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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Matthew Seaman]

On 2017/06/22 20:56, Baho Utot wrote:
> One could still use releng 11.0 ports with 10.3 OS could they not

No, not in general.

You've got it the wrong way round.

You might get away with releng 10.3 ports and 11.0 OS for a while but it
will likely cause you grief when you do run afoul of a necessary
security update and try and update stuff.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

[Default] On Thu, 22 Jun 2017 17:30:10 +0200, Torsten Zuehlsdorff
 wrote:

>I regularly seeing admins setting up different Ubuntu versions, because 
>at one you have PHP 7 and on the other MySQL 5.7, but not both at the 
>same Ubuntu version.

Which is one of the nice things about having central development
rather than a dozen forks being developed separately.  But it
still doesn't work perfectly, since we also have some skews like
that.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 22/6/17 11:50 pm, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman
 wrote:


On 2017/06/22 15:03, scratch65...@att.net wrote:

Why don't the same choices apply here?  What am I missing?

Two things:

  1) It's progress in the development of the FreeBSD base system that
drives the release cycle.  The general state of the ports does not exert
much influence on release frequency -- nor should it.

Still not getting it, I'm afraid.How often does the base
system undergo such drastic architecture changes that existing
ports won't run under it?  I haven't really been monitoring the
situation, but I'd guess it's very seldom if only because such an
architectural change is a cursëd big job that can hardly ever be
justfied.

I'd guess that most adults for whom systems are tools not toys
are not too dissimilar to me:  I want to *use* my tools, not
spend time replacing them every quarter or even every year.  As
long as they do the job and don't compromise the system, they're
fine by me.  I have apps running under Win7 that were written for
W2K (and in one case NT, iirc), and they're just as useful today
as they were then.  They do the job: why in the name of sanity
should I replace them?

So where's the point in everyone going mad trying to keep up a
quarterly release schedule that serves more as an annoyance than
benefit to your customer base?  (Do you read the Asterix comics?
The one where Asterix and Obelix go to Switzerland is
particularly apropos here, I think:  the owner of the inn awakens
the guests every hour so that they can turn over the hourglass
mounted over their bed.  What benefit do the guests derive from
that?  None, of course, but it helps the owner feel in control of
things.  But the guests are, reasonably, quite upset by the loss
of sleep due to his obsessiveness.)



  2) Even if we could scrape up enough people to support however many
branches you are proposing, remember they are all volunteers.  It's hard
enough getting people to maintain the existing quarterly branches as it
is, and those are relatively short lived so that most merges from head
are pretty trivial.  People really aren't going to want to do
essentially repetitive merges to branches where everything else is up to
X years older than head.  Which would make it both tedious and
frequently difficult to do.

Again I'm really not following your logic.   There are 2 versions
of the base system now in play:  10.3 and 11.0.  There are 2 more
being developed: 10.4 and 11.1.   10.2 has already been trashed,
thus forcing us to upgrade to 10.3 whether we wanted to or not,
which in many cases, mine among them, was a "not".  I'm sure the
same thing will happen with 10.4 and 11.1 and plenty folk will be
just as annoyed as we were with 10.2


I've had this conversation with ports several times, But the requirements
of  'business' is not their interest.  In fact i was told several times,
"Don't use our quarterly packages, make your own with poudriere".
(which makes one wonder "What is the purpose of he quarterlies?)

My suggestion is to ignore the existence of the quarterly snapshots as
they are neither stable (they change every 3 months out from under 
you) nor snapshots,
(they a re updated randomly a bit at a time. This just doesn't work 
for what business needs.
So the only alternative is to have a SVN mirror, and take your own 
snapshots, and keep your eye

on the security notices.



Let's say you guys don't try to follow that schedule.  You do a
ports release for (let's say) 10.0 and then 11.0, but not for the
other point releases in between.  So if someone feels the deep
need for 10.1, or 10.2, or 10.3 (or 11.n mutatis mutandis),
they'll run 10.0 (or 11.0)  ports under it.   It's done all the
time in industry.   If you treat each ports release as a DVD
--immutable once shipped--, or as a PROM, where changes can be
made but it's a pain in the dupa so you only do it for the
emergency case, it seems to me that the pressure has gone down by
a factor of  3 or so.  So where's the problem in that?

's mise le meas
___
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: [RFC] Why FreeBSD ports should have branches by OS version

[Torsten Zuehlsdorff]

On 22.06.2017 21:56, Baho Utot wrote:



On 6/22/2017 11:30 AM, Torsten Zuehlsdorff wrote:

On 22.06.2017 21:26, Baho Utot wrote:

On 6/22/2017 10:03 AM, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin
 wrote:

As usual with such proposal, where do you find the manpower to 
handle the number
of branches required (the quarterly branches are already hard to 
maintain, it is

only one branch).

Please help me out here, Baptiste, because I'm apparently missing
*something*.

Out in industry, if you haven't enough people to do a new
high-quality release every N months, and you can't get a
headcount increase, then you cut the release schedule.  Can't do
4 releases a year?  Cut back to 2.  Still too many?  Cut back to
1.

The alternatives to cutting the schedule are that (a) people
begin burning out and quitting, (b) quality drops and your
customer base begins abandoning you, or (c) both of the above.

Why don't the same choices apply here?  What am I missing?
___




I am looking at OpenBSD to replace FreeBSD.  They have a more relaxed 
update schedule and that fits with what I need.


Go ahead with whatever fits your needs.

But since the ports-tree is a subversion repository it is really easy 
to maintain the status you want. I do this for various customer and my 
various server.


I am looking for a system that is very stable and doesn't do the 
upgrade path for the sake of it being newer.


Which has various downsides. I remember for example various linux LTS 
distros, which only apply security fixes. I discovered various bugs 
which stay there for years, because they are not security issues - 
they just hurt you daily. :D


No not really I ran LFS servers and desktops for 10 years


This does not mean that you're hit by the bugs i am. The most recent 
example is a bug in curl parsing a #. This was introduced via a security 
fix in Ubuntu and make use of '#' in passwords for htaccess impossible, 
until you use new curl releases. Which are not available on Ubuntu 16 
LTS for some more years.


Having a "releng ports" version that goes with a releng version of 
the OS would be great by me.   Linux from scratch does this and it 
works very well. 


It really does not work well. In everyday situation this results in 
"heck we need a new server to get a new version of a needed software, 
because we need a new linux version".
I regularly seeing admins setting up different Ubuntu versions, 
because at one you have PHP 7 and on the other MySQL 5.7, but not both 
at the same Ubuntu version.


BSD != Linux so your comparison is invalid.


No, that is the point of my comparison. Luckily BSD != Linux and also 
the various distributions schemes of updates having there up- and downsides.
But in such discussions its often that only the own use-case is 
mentioned. And i want to widen the scope.


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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baho Utot]

On 6/22/2017 11:30 AM, Torsten Zuehlsdorff wrote:

On 22.06.2017 21:26, Baho Utot wrote:

On 6/22/2017 10:03 AM, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin
 wrote:

As usual with such proposal, where do you find the manpower to 
handle the number
of branches required (the quarterly branches are already hard to 
maintain, it is

only one branch).

Please help me out here, Baptiste, because I'm apparently missing
*something*.

Out in industry, if you haven't enough people to do a new
high-quality release every N months, and you can't get a
headcount increase, then you cut the release schedule.  Can't do
4 releases a year?  Cut back to 2.  Still too many?  Cut back to
1.

The alternatives to cutting the schedule are that (a) people
begin burning out and quitting, (b) quality drops and your
customer base begins abandoning you, or (c) both of the above.

Why don't the same choices apply here?  What am I missing?
___




I am looking at OpenBSD to replace FreeBSD.  They have a more relaxed 
update schedule and that fits with what I need.


Go ahead with whatever fits your needs.

But since the ports-tree is a subversion repository it is really easy 
to maintain the status you want. I do this for various customer and my 
various server.


I am looking for a system that is very stable and doesn't do the 
upgrade path for the sake of it being newer.


Which has various downsides. I remember for example various linux LTS 
distros, which only apply security fixes. I discovered various bugs 
which stay there for years, because they are not security issues - 
they just hurt you daily. :D




No not really I ran LFS servers and desktops for 10 years

Having a "releng ports" version that goes with a releng version of 
the OS would be great by me.   Linux from scratch does this and it 
works very well. 


It really does not work well. In everyday situation this results in 
"heck we need a new server to get a new version of a needed software, 
because we need a new linux version".
I regularly seeing admins setting up different Ubuntu versions, 
because at one you have PHP 7 and on the other MySQL 5.7, but not both 
at the same Ubuntu version.


BSD != Linux so your comparison is invalid.

One could still use releng 11.0 ports with 10.3 OS could they not

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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 22/6/17 10:16 pm, Baptiste Daroussin wrote:

On Thu, Jun 22, 2017 at 10:03:33AM -0400, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin
 wrote:


As usual with such proposal, where do you find the manpower to handle the number
of branches required (the quarterly branches are already hard to maintain, it is
only one branch).

Please help me out here, Baptiste, because I'm apparently missing
*something*.

Out in industry, if you haven't enough people to do a new
high-quality release every N months, and you can't get a
headcount increase, then you cut the release schedule.  Can't do
4 releases a year?  Cut back to 2.  Still too many?  Cut back to
1.

The alternatives to cutting the schedule are that (a) people
begin burning out and quitting, (b) quality drops and your
customer base begins abandoning you, or (c) both of the above.

Why don't the same choices apply here?  What am I missing?

We only have 1 quarterly branch at the time :)

The model with one branch per release will bring it to way more with a
maintenance window way larger (actually it is 3 month making the quarterly
relatively easy to maintain)
Yeah but the quarterly branches are relatively useless because they a 
not sync'd to anything and mean nothing special to anyone.
As soon as you sync to one, it's deleted and replaced by a completely 
different one meaning you have to replace *EVERYTHING*,

so one might as well just use head. it's actually easier.




Best regards,
Bapt



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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

[Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman
 wrote:

>On 2017/06/22 15:03, scratch65...@att.net wrote:
>> Why don't the same choices apply here?  What am I missing?
>
>Two things:
>
>  1) It's progress in the development of the FreeBSD base system that
>drives the release cycle.  The general state of the ports does not exert
>much influence on release frequency -- nor should it.

Still not getting it, I'm afraid.How often does the base
system undergo such drastic architecture changes that existing
ports won't run under it?  I haven't really been monitoring the
situation, but I'd guess it's very seldom if only because such an
architectural change is a cursëd big job that can hardly ever be
justfied. 

I'd guess that most adults for whom systems are tools not toys
are not too dissimilar to me:  I want to *use* my tools, not
spend time replacing them every quarter or even every year.  As
long as they do the job and don't compromise the system, they're
fine by me.  I have apps running under Win7 that were written for
W2K (and in one case NT, iirc), and they're just as useful today
as they were then.  They do the job: why in the name of sanity
should I replace them?

So where's the point in everyone going mad trying to keep up a
quarterly release schedule that serves more as an annoyance than
benefit to your customer base?  (Do you read the Asterix comics?
The one where Asterix and Obelix go to Switzerland is
particularly apropos here, I think:  the owner of the inn awakens
the guests every hour so that they can turn over the hourglass
mounted over their bed.  What benefit do the guests derive from
that?  None, of course, but it helps the owner feel in control of
things.  But the guests are, reasonably, quite upset by the loss
of sleep due to his obsessiveness.)


>
>  2) Even if we could scrape up enough people to support however many
>branches you are proposing, remember they are all volunteers.  It's hard
>enough getting people to maintain the existing quarterly branches as it
>is, and those are relatively short lived so that most merges from head
>are pretty trivial.  People really aren't going to want to do
>essentially repetitive merges to branches where everything else is up to
>X years older than head.  Which would make it both tedious and
>frequently difficult to do.

Again I'm really not following your logic.   There are 2 versions
of the base system now in play:  10.3 and 11.0.  There are 2 more
being developed: 10.4 and 11.1.   10.2 has already been trashed,
thus forcing us to upgrade to 10.3 whether we wanted to or not,
which in many cases, mine among them, was a "not".  I'm sure the
same thing will happen with 10.4 and 11.1 and plenty folk will be
just as annoyed as we were with 10.2

Let's say you guys don't try to follow that schedule.  You do a
ports release for (let's say) 10.0 and then 11.0, but not for the
other point releases in between.  So if someone feels the deep
need for 10.1, or 10.2, or 10.3 (or 11.n mutatis mutandis),
they'll run 10.0 (or 11.0)  ports under it.   It's done all the
time in industry.   If you treat each ports release as a DVD
--immutable once shipped--, or as a PROM, where changes can be
made but it's a pain in the dupa so you only do it for the
emergency case, it seems to me that the pressure has gone down by
a factor of  3 or so.  So where's the problem in that? 

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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Torsten Zuehlsdorff]

On 22.06.2017 21:26, Baho Utot wrote:

On 6/22/2017 10:03 AM, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin
 wrote:

As usual with such proposal, where do you find the manpower to handle 
the number
of branches required (the quarterly branches are already hard to 
maintain, it is

only one branch).

Please help me out here, Baptiste, because I'm apparently missing
*something*.

Out in industry, if you haven't enough people to do a new
high-quality release every N months, and you can't get a
headcount increase, then you cut the release schedule.  Can't do
4 releases a year?  Cut back to 2.  Still too many?  Cut back to
1.

The alternatives to cutting the schedule are that (a) people
begin burning out and quitting, (b) quality drops and your
customer base begins abandoning you, or (c) both of the above.

Why don't the same choices apply here?  What am I missing?
___




I am looking at OpenBSD to replace FreeBSD.  They have a more relaxed 
update schedule and that fits with what I need.


Go ahead with whatever fits your needs.

But since the ports-tree is a subversion repository it is really easy to 
maintain the status you want. I do this for various customer and my 
various server.


I am looking for a system that is very stable and doesn't do the upgrade 
path for the sake of it being newer.


Which has various downsides. I remember for example various linux LTS 
distros, which only apply security fixes. I discovered various bugs 
which stay there for years, because they are not security issues - they 
just hurt you daily. :D


Having a "releng ports" version that goes with a releng version of the 
OS would be great by me.   Linux from scratch does this and it works 
very well.  


It really does not work well. In everyday situation this results in 
"heck we need a new server to get a new version of a needed software, 
because we need a new linux version".
I regularly seeing admins setting up different Ubuntu versions, because 
at one you have PHP 7 and on the other MySQL 5.7, but not both at the 
same Ubuntu version.


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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baho Utot]

On 6/22/2017 10:03 AM, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin
 wrote:


As usual with such proposal, where do you find the manpower to handle the number
of branches required (the quarterly branches are already hard to maintain, it is
only one branch).

Please help me out here, Baptiste, because I'm apparently missing
*something*.

Out in industry, if you haven't enough people to do a new
high-quality release every N months, and you can't get a
headcount increase, then you cut the release schedule.  Can't do
4 releases a year?  Cut back to 2.  Still too many?  Cut back to
1.

The alternatives to cutting the schedule are that (a) people
begin burning out and quitting, (b) quality drops and your
customer base begins abandoning you, or (c) both of the above.

Why don't the same choices apply here?  What am I missing?
___




I am looking at OpenBSD to replace FreeBSD.  They have a more relaxed 
update schedule and that fits with what I need.


I am looking for a system that is very stable and doesn't do the upgrade 
path for the sake of it being newer.


Having a "releng ports" version that goes with a releng version of the 
OS would be great by me.   Linux from scratch does this and it works 
very well.  Why not have the ports system mirror the OS system?  Could 
it not be done by using branches in subversion?  Of course if changed it 
would have to mature out a little.


If the laptop that I have under testing pans out I be gone.



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

PR needs care

[Fernando Apesteguía]

Hi,

Can anyone have a look at this?

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

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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Matthew Seaman]

On 2017/06/22 15:03, scratch65...@att.net wrote:
> Why don't the same choices apply here?  What am I missing?

Two things:

  1) It's progress in the development of the FreeBSD base system that
drives the release cycle.  The general state of the ports does not exert
much influence on release frequency -- nor should it.

  2) Even if we could scrape up enough people to support however many
branches you are proposing, remember they are all volunteers.  It's hard
enough getting people to maintain the existing quarterly branches as it
is, and those are relatively short lived so that most merges from head
are pretty trivial.  People really aren't going to want to do
essentially repetitive merges to branches where everything else is up to
X years older than head.  Which would make it both tedious and
frequently difficult to do.

Tedious and difficult generally means "you need to pay someone to do
that".  Which means you need a commercial setup to generate the money to
pay all those wages.  Which means you -- the end user -- get to pay for
the provision of those specially maintained package sets.

Now, if you think you have a viable business case for maintaining
essentially a static snapshot-plus-security-fixes of the ports and
supplying packages generated from it, by all means go ahead and try
offering that as a commercial service.  I doubt you'll succeed though --
a number of other people[*] have been down that path, and they usually
give up fairly early because the market just won't support it at the moment.

Cheers,

Matthew

[*] These guys most recently:
http://www.xinuos.com/menu-products/openserver-10  They're still going,
but I haven't heard of much activity from them for the last year or so.




signature.asc
Description: OpenPGP digital signature

Re: [RFC] Why FreeBSD ports should have branches by OS version

[David Demelier]

2017-06-22 16:16 GMT+02:00 Baptiste Daroussin :
> The model with one branch per release will bring it to way more with a
> maintenance window way larger (actually it is 3 month making the quarterly
> relatively easy to maintain)

So after three months if you don't switch branch, you're outdated
since bugfixes are not applied in old ones. Then we get back into the
same trouble of major upgrades while the user just wanted to have
security updates.

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

[Baptiste Daroussin]

On Thu, Jun 22, 2017 at 10:03:33AM -0400, scratch65...@att.net wrote:
> [Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin
>  wrote:
> 
> >As usual with such proposal, where do you find the manpower to handle the 
> >number
> >of branches required (the quarterly branches are already hard to maintain, 
> >it is
> >only one branch).
> 
> Please help me out here, Baptiste, because I'm apparently missing
> *something*.   
> 
> Out in industry, if you haven't enough people to do a new
> high-quality release every N months, and you can't get a
> headcount increase, then you cut the release schedule.  Can't do
> 4 releases a year?  Cut back to 2.  Still too many?  Cut back to
> 1.
> 
> The alternatives to cutting the schedule are that (a) people
> begin burning out and quitting, (b) quality drops and your
> customer base begins abandoning you, or (c) both of the above.
> 
> Why don't the same choices apply here?  What am I missing?

We only have 1 quarterly branch at the time :)

The model with one branch per release will bring it to way more with a
maintenance window way larger (actually it is 3 month making the quarterly
relatively easy to maintain)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

[Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin
 wrote:

>As usual with such proposal, where do you find the manpower to handle the 
>number
>of branches required (the quarterly branches are already hard to maintain, it 
>is
>only one branch).

Please help me out here, Baptiste, because I'm apparently missing
*something*.   

Out in industry, if you haven't enough people to do a new
high-quality release every N months, and you can't get a
headcount increase, then you cut the release schedule.  Can't do
4 releases a year?  Cut back to 2.  Still too many?  Cut back to
1.

The alternatives to cutting the schedule are that (a) people
begin burning out and quitting, (b) quality drops and your
customer base begins abandoning you, or (c) both of the above.

Why don't the same choices apply here?  What am I missing?
___
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"

NEW APR/APR-Utils

[The Doctor]

ARR and APR-utils are up to 1.6.X

Please update ports accordingly.

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
https://www.empire.kred/ROOTNK?t=94a1f39b  Look at Psalms 14 and 53 on Atheism
Talk Sense to a fool and he calls you foolish - Euripides
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[David Demelier]

2017-06-22 14:18 GMT+02:00 Baptiste Daroussin :
> On Thu, Jun 22, 2017 at 02:15:02PM +0200, David Demelier wrote:
> As usual with such proposal, where do you find the manpower to handle the 
> number
> of branches required (the quarterly branches are already hard to maintain, it 
> is
> only one branch).

I think release branches won't need much maintainance as unless a
security issue is found, no updates are necessary.

> What do you do for security fixes: backport to the stable version? who is
> backporting to software not maintained upstream any more in the given branch?
>

I would never backport anything. It's quite the opposite. If a
security flaw is discovered in let say: OpenSSL; then we check if it's
present in the release branch and top port in quarterly then HEAD if
they are also affected by this issue.

Regarding your second mail, the question may also apply on HEAD :-)

Cheers,

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

[Vlad K.]

On 2017-06-22 14:15, David Demelier wrote:


While I use quarterly ports branches, I usually update my ports tree
before installing a new service and I faced some troubles:


What works best for us, to keep a stable production, is to track the 
HEAD with svn. That way we can pre-empt changes locally, test, and 
deploy into production, or block upstream changes by keeping some older 
version until something else is fixed.


Otherwise as others have suggested, the problem is manpower and 
backporting patches. Although, in my experience having run both Ubuntu 
LTS and FreeBSD in production, when a maintainer, who is not the 
developer of some software, tries to backport patches, it often results 
in regressions and even more problems introduced. So I'd rather use 
rolling release directly from the developers with minimal local changes.


A rolling release with clearly marked stable versions kept longer around 
(ala Gentoo), is the best way to solve the problem with ports without 
introducing extra manpower and the need to backport.




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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baptiste Daroussin]

On Thu, Jun 22, 2017 at 02:18:56PM +0200, Baptiste Daroussin wrote:
> On Thu, Jun 22, 2017 at 02:15:02PM +0200, David Demelier wrote:
> > Hello,
> > 
> > Today I've upgraded one of my personal FreeBSD servers. It's running
> > FreeBSD 11.0 for a while.
> > 
> > While I use quarterly ports branches, I usually update my ports tree
> > before installing a new service and I faced some troubles:
> > 
> > www/node was updated from 6.x to 7.x: unfortunately my etherpad
> > instance is not compatible with 7.x. I needed to install www/node6.
> > 
> > devel/mercurial was updated to 4.2: redmine has a small issue making
> > repository browsing unavailable. I temporarily downgraded Mercurial to
> > 4.0.
> > 
> > I think the current process of having rolling-releases packages makes
> > unpredictable upgrades as we have to manually check if the upgrade
> > will be fine or not. When a user installs FreeBSD 11.0 on its system,
> > it probably expects that everything will work fine until a next major
> > upgrade like 12.0. That's why I think we really should implement
> > branches for a specific FreeBSD version.
> > 
> > When FreeBSD 12.0 is released, we should create a ports branch that
> > will contains only fixes (such as security advisories, crash fixes and
> > such). No minor or major upgrades until a new 13.0 version is
> > released. This is the only way to make safe upgrades.
> > 
> > If user think that a software is too old (since we have long delay
> > between major releases) it can still use the default tree at its own
> > risks.
> > 
> > Additional benefits of having a ports tree by version: you don't need
> > to have conditionals in ports Makefiles (how many ports check for
> > FreeBSD version? a lot).
> > 
> > Any comments are appreciated.
> 
> As usual with such proposal, where do you find the manpower to handle the 
> number
> of branches required (the quarterly branches are already hard to maintain, it 
> is
> only one branch).
> 
> What do you do for security fixes: backport to the stable version? who is
> backporting to software not maintained upstream any more in the given branch?
> 
> Bapt

Oh and of course the day you freeze a branch you will have complain about "how
do I get python 3.8 on freebsd 11.0"

Bapt


signature.asc
Description: PGP signature

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Fernando Apesteguía]

El 22 jun. 2017 14:15, "David Demelier"  escribió:

Hello,

Today I've upgraded one of my personal FreeBSD servers. It's running
FreeBSD 11.0 for a while.

While I use quarterly ports branches, I usually update my ports tree
before installing a new service and I faced some troubles:

www/node was updated from 6.x to 7.x: unfortunately my etherpad
instance is not compatible with 7.x. I needed to install www/node6.

devel/mercurial was updated to 4.2: redmine has a small issue making
repository browsing unavailable. I temporarily downgraded Mercurial to
4.0.

I think the current process of having rolling-releases packages makes
unpredictable upgrades as we have to manually check if the upgrade
will be fine or not. When a user installs FreeBSD 11.0 on its system,
it probably expects that everything will work fine until a next major
upgrade like 12.0. That's why I think we really should implement
branches for a specific FreeBSD version.

When FreeBSD 12.0 is released, we should create a ports branch that
will contains only fixes (such as security advisories, crash fixes and
such). No minor or major upgrades until a new 13.0 version is
released. This is the only way to make safe upgrades.

If user think that a software is too old (since we have long delay
between major releases) it can still use the default tree at its own
risks.

Additional benefits of having a ports tree by version: you don't need
to have conditionals in ports Makefiles (how many ports check for
FreeBSD version? a lot).

Any comments are appreciated.

Regards,


CMIIW but when similar approaches come up, one of the reasons to not do it
is man power.


--
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"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baptiste Daroussin]

On Thu, Jun 22, 2017 at 02:15:02PM +0200, David Demelier wrote:
> Hello,
> 
> Today I've upgraded one of my personal FreeBSD servers. It's running
> FreeBSD 11.0 for a while.
> 
> While I use quarterly ports branches, I usually update my ports tree
> before installing a new service and I faced some troubles:
> 
> www/node was updated from 6.x to 7.x: unfortunately my etherpad
> instance is not compatible with 7.x. I needed to install www/node6.
> 
> devel/mercurial was updated to 4.2: redmine has a small issue making
> repository browsing unavailable. I temporarily downgraded Mercurial to
> 4.0.
> 
> I think the current process of having rolling-releases packages makes
> unpredictable upgrades as we have to manually check if the upgrade
> will be fine or not. When a user installs FreeBSD 11.0 on its system,
> it probably expects that everything will work fine until a next major
> upgrade like 12.0. That's why I think we really should implement
> branches for a specific FreeBSD version.
> 
> When FreeBSD 12.0 is released, we should create a ports branch that
> will contains only fixes (such as security advisories, crash fixes and
> such). No minor or major upgrades until a new 13.0 version is
> released. This is the only way to make safe upgrades.
> 
> If user think that a software is too old (since we have long delay
> between major releases) it can still use the default tree at its own
> risks.
> 
> Additional benefits of having a ports tree by version: you don't need
> to have conditionals in ports Makefiles (how many ports check for
> FreeBSD version? a lot).
> 
> Any comments are appreciated.

As usual with such proposal, where do you find the manpower to handle the number
of branches required (the quarterly branches are already hard to maintain, it is
only one branch).

What do you do for security fixes: backport to the stable version? who is
backporting to software not maintained upstream any more in the given branch?

Bapt


signature.asc
Description: PGP signature

[RFC] Why FreeBSD ports should have branches by OS version

[David Demelier]

Hello,

Today I've upgraded one of my personal FreeBSD servers. It's running
FreeBSD 11.0 for a while.

While I use quarterly ports branches, I usually update my ports tree
before installing a new service and I faced some troubles:

www/node was updated from 6.x to 7.x: unfortunately my etherpad
instance is not compatible with 7.x. I needed to install www/node6.

devel/mercurial was updated to 4.2: redmine has a small issue making
repository browsing unavailable. I temporarily downgraded Mercurial to
4.0.

I think the current process of having rolling-releases packages makes
unpredictable upgrades as we have to manually check if the upgrade
will be fine or not. When a user installs FreeBSD 11.0 on its system,
it probably expects that everything will work fine until a next major
upgrade like 12.0. That's why I think we really should implement
branches for a specific FreeBSD version.

When FreeBSD 12.0 is released, we should create a ports branch that
will contains only fixes (such as security advisories, crash fixes and
such). No minor or major upgrades until a new 13.0 version is
released. This is the only way to make safe upgrades.

If user think that a software is too old (since we have long delay
between major releases) it can still use the default tree at its own
risks.

Additional benefits of having a ports tree by version: you don't need
to have conditionals in ports Makefiles (how many ports check for
FreeBSD version? a lot).

Any comments are appreciated.

Regards,

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

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
+-+
lang/js_of_ocaml| 2.5 | 3.0.0
+-+


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"

Re: net-mgmt/nagios-check_ports and jails

[Andrea Venturoli]

On 06/21/17 20:09, Ryan Frederick wrote:

Andrea,

I took a look at ports-mgmt/jailaudit, and it works a bit differently
than ports-mgmt/nagios-check_ports. jailaudit makes a list of packages
installed in the jail and runs pkg(8) audit outside of the jail against
the list. nagios-check_ports, on the other hand, calls pkg(8) audit with
the -j option to run inside the jail and thus requires a copy of
vuln.xml within the jail.


That's what I suspected.




I would suggest running `pkg audit -F` within the jails regularly or
setup something to copy vuln.xml into the jails.

That being said I do have a bugfix to commit upstream that unbreaks
checking for updates within a jail from outside the jail. I'll hopefully
get that released soon.


I'm in no hurry, so I can wait for soon :)

Thanks for your work.

 bye
av.
___
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"