What to do when the port fails in poudriere with "Too many open files" ?

2017-06-28 Thread Yuri 
I have the port that builds fine without poudriere, but in poudriere it 
always fails with "Too many open files".


This happens during the Java build.


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

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



Yuri

___
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: /usr/ports -r444615 (e.g.) & head -r320458 (e.g.): sysutils/u-boot-pine64 build fails for arch/arm/dts/pine64_plus.dtb source handling error (gic in a64.dtsi)

2017-06-28 Thread Mark Millard 
On 2017-Jun-28, at 7:44 PM, Mark Millard  wrote:

> Is the below a BSDL vs. GPL DTS issue?
> 
> In my attempt to build sysutils/u-boot-pine64 I got:
> 
>  OBJCOPY u-boot.srec
>  OBJCOPY u-boot-nodtb.bin
> start=$(aarch64-none-elf-nm u-boot | grep __rel_dyn_start | cut -f 1 -d ' '); 
> end=$(aarch64-none-elf-nm u-boot | grep __rel_dyn_end | cut -f 1 -d ' '); 
> tools/relocate-rela u-boot-nodtb.bin 0x4a00 $start $end
>  SYM u-boot.sym
>  DTC arch/arm/dts/pine64_plus.dtb
> Error at arch/arm/dts/.pine64_plus.dtb.dts.tmp:533:27: Expected unit address
> gic: interrupt-controller@{
>   ^
> Error at arch/arm/dts/.pine64_plus.dtb.dts.tmp:533:27: Failed to find root 
> node /.
> gic: interrupt-controller@{
>   ^
> Failed to parse tree.
> gmake[3]: *** [scripts/Makefile.lib:299: arch/arm/dts/pine64_plus.dtb] Error 1
> gmake[2]: *** [dts/Makefile:36: arch-dtbs] Error 2
> gmake[1]: *** [Makefile:821: dts/dt.dtb] Error 2
> gmake[1]: *** Waiting for unfinished jobs
> gmake[1]: Leaving directory 
> '/usr/obj/portswork/usr/ports/sysutils/u-boot-pine64/work/u-boot-2016.05'
> 
> 
> 
> Looking at the gic part of the source. . .
> 
> # more 
> /usr/obj/portswork/usr/ports/sysutils/u-boot-pine64/work/u-boot-2016.05/arch/arm/dts/a64.dtsi
> . . .
>gic: interrupt-controller@{
>compatible = "arm,gic-400";
>interrupt-controller;
>#interrupt-cells = <3>;
>#address-cells = <0>;
> 
>reg = <0x01C81000 0x1000>,
>  <0x01C82000 0x2000>,
>  <0x01C84000 0x2000>,
>  <0x01C86000 0x2000>;
>interrupts =   (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>};
> 
> 
> 
> I'll be trying 3 other u-boot-*'s so I may have more to
> report later.

The other 3 that I tried worked fine:

Installation of sysutils/u-boot-rpi2 (u-boot-rpi2-2015.04)
Installation of sysutils/u-boot-rpi3 (u-boot-rpi3-2017.01)
Installation of sysutils/u-boot-sinovoip-bpi-m3 
(u-boot-sinovoip-bpi-m3-2016.05)

So this may be unique to a64.dtsi and its lack of
hexadecimal digits after the "@" in what I quoted.

Still, sysutils/u-boot-pine64 used to build. So it may
be a BSDL vs. GPL DTS issue as far as the handling of
the notation goes.

===
Mark Millard
markmi at dsl-only.net

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

/usr/ports -r444615 (e.g.) & head -r320458 (e.g.): sysutils/u-boot-pine64 build fails for arch/arm/dts/pine64_plus.dtb source handling error (gic in a64.dtsi)

2017-06-28 Thread Mark Millard 
Is the below a BSDL vs. GPL DTS issue?

In my attempt to build sysutils/u-boot-pine64 I got:

  OBJCOPY u-boot.srec
  OBJCOPY u-boot-nodtb.bin
start=$(aarch64-none-elf-nm u-boot | grep __rel_dyn_start | cut -f 1 -d ' '); 
end=$(aarch64-none-elf-nm u-boot | grep __rel_dyn_end | cut -f 1 -d ' '); 
tools/relocate-rela u-boot-nodtb.bin 0x4a00 $start $end
  SYM u-boot.sym
  DTC arch/arm/dts/pine64_plus.dtb
Error at arch/arm/dts/.pine64_plus.dtb.dts.tmp:533:27: Expected unit address
 gic: interrupt-controller@{
   ^
Error at arch/arm/dts/.pine64_plus.dtb.dts.tmp:533:27: Failed to find root node 
/.
 gic: interrupt-controller@{
   ^
Failed to parse tree.
gmake[3]: *** [scripts/Makefile.lib:299: arch/arm/dts/pine64_plus.dtb] Error 1
gmake[2]: *** [dts/Makefile:36: arch-dtbs] Error 2
gmake[1]: *** [Makefile:821: dts/dt.dtb] Error 2
gmake[1]: *** Waiting for unfinished jobs
gmake[1]: Leaving directory 
'/usr/obj/portswork/usr/ports/sysutils/u-boot-pine64/work/u-boot-2016.05'



Looking at the gic part of the source. . .

# more 
/usr/obj/portswork/usr/ports/sysutils/u-boot-pine64/work/u-boot-2016.05/arch/arm/dts/a64.dtsi
. . .
gic: interrupt-controller@{
compatible = "arm,gic-400";
interrupt-controller;
#interrupt-cells = <3>;
#address-cells = <0>;

reg = <0x01C81000 0x1000>,
  <0x01C82000 0x2000>,
  <0x01C84000 0x2000>,
  <0x01C86000 0x2000>;
interrupts = ;
};



I'll be trying 3 other u-boot-*'s so I may have more to
report later.

===
Mark Millard
mar...@dsl-only.net

___
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: math/R: Build failure after PORTREVISION for shlib change

2017-06-28 Thread Joseph Mingrone 
Hi David,

So far I haven't been able to reproduce any problems in an
11.0-RELEASE-p1 jail.  Could you send your list of port options?  If I
can't reproduce any issues with the same options turned on, I will ask
you for a full build log.

Joseph


signature.asc
Description: PGP signature

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

2017-06-28 Thread Dirk Meyer 
Hallo Julian H. Stacey,

> But if one stands on a broken system & needs to recover, some simple
> stock cc & sh tool/procedure with no dependencies is attractive, even if
> one has to coble something ones self.

I agree.
maybe you like to try:
$ less /usr/ports/ports-mgmt/pkg_jail/files/README

kind regards Dirk

- Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany
- [dirk.me...@dinoex.sub.org],[dirk.me...@guug.de],[din...@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: math/R: Build failure after PORTREVISION for shlib change

2017-06-28 Thread David Wolfskill 
On Wed, Jun 28, 2017 at 04:36:18PM -0300, Joseph Mingrone wrote:
> Hi David,
> 
> So far I haven't been able to reproduce any problems in an
> 11.0-RELEASE-p1 jail.  Could you send your list of port options?  If I
> can't reproduce any issues with the same options turned on, I will ask
> you for a full build log.
> 
> Joseph

Thanks for taking a look.

g1-227(11.1)[2] make -C /usr/ports/math/R showconfig
===> The following configuration options are available for R-3.4.0_1:
 ICU=on: Unicode support via ICU
 INFO=on: GNU info manuals
 LDOUBLE=on: Long double data type
 LETTER=on: US letter paper
 LIBR=on: Shared R library
 MEMPROF=off: Memory profiling via Rprofmem() and tracemem()
 NLS=on: Native Language Support
 RPROF=on: R profiling via Rprof()
 X11=on: X11 graphics device
> Require GCC
 LTO=on: Use Link Time Optimization
 OPENMP=on: Parallel processing support via OpenMP
> Require X11
 GHOSTSCRIPT=on: Graphics device for bitmap files via Ghostscript
 JPEG=on: JPEG graphics device
 CAIROPANGO=on: Cairo graphics device and Pango multi-language text
 PNG=on: PNG graphics device
 TCLTK=on: Tcl/Tk GUI toolkit support
 TEXDOCS=on: Build/Install TeX-dependent documentation files
 TIFF=on: TIFF image format support
> Options available for the single BLAS: you have to select exactly one of 
them
 ATLAS=off: ATLAS BLAS implementation
 OPENBLAS=off: OpenBLAS BLAS implementation
 NETLIB=off: Netlib BLAS implementation
 RBLAS=on: Use R-bundled BLAS implementation
===> Use 'make config' to modify these settings
g1-227(11.1)[3] 

I also placed both "normal" and gzipped copies of the typescript
from the (multiple) portmaster runs in
; see R.log (or
R.log.gz).

(I had run portmaster; it built a few things, tried math/R & died.
I re-started portmaster, eliding math/R, but portmaster found it
anyway... though it didn't show up in the list until several other
ports were built successfully.  I then tried again, skipping both
math/R and databases/R-cran-DBI; all of the specified ports built
OK.  Then I tried just math/R & databases/R-cran-DBI; those failed
(as before).  I then specified 'MAKE_JOBS_UNSAFE=yes' in /etc/make.conf
& tried the laast run again; still failed.  Each time, I appended
to the typescript.)

Just in case it's relevant, as /usr/local/bin/gcc-ar5 is from gcc5-5.4.0_2:

g1-227(11.1)[5] make -C /usr/ports/lang/gcc5 showconfig
===> The following configuration options are available for gcc5-5.4.0_2:
 BOOTSTRAP=on: Build using a full bootstrap
 GRAPHITE=off: Support for Graphite loop optimizations
 JAVA=on: Java platform support
===> Use 'make config' to modify these settings

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Do Congress's recent actions on health care qualify as "terrorist acts?"

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


signature.asc
Description: PGP signature

Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work

2017-06-28 Thread Mark Millard 
On 2017-Jun-28, at 3:21 AM, Gerald Pfeifer  wrote:

> I am testing a patch for gcc5-devel right now that will disable fixincludes 
> (or rather its fixed files) being packaged.
> 
> Should that work fine for you, I will push this back to gcc5 the following 
> days.
> 
> That said, the change that triggered this is what I would expect on CURRENT, 
> not STABLE (and hence hoped we'd have more time for this change).
> 
> My Internet connectivity right now is only slightly above pigeon speed, so 
> sorry for any delays.


Thanks!

Some notes:

A primary test is building lang/gcc5-devel under release/11.0.1
and then using it under stable/11 or some draft of release/11.1.0 .

It looks like the the lang/gcc5-devel build still creates and
uses the headers that go in include-fixed/ but that they are
removed from $(STAGEDIR}${TARGLIB} 's tree before installation
or packaging.

So, if I understand right, lang/gcc5-devel itself still does use
the adjusted headers to produce its own materials but when
lang/gcc5-devel is used later it does not. Definitely
something to be testing since it is a mix overall.

Is some form of exp-like run needed that tries to force use
of a release/11.0.1 built lang/gcc5-devel (-r444563) to build
other things under, say, stable/11  or some draft of
release/11.1.0 ? Is this odd combination even possible
currently?

A normal exp-run on release/11.0.1 without a system version
switch being involved also seems appropriate. The same could
be said of an exp-run based on a release/11.1.0 draft for
both building lang/gcc5-devel and using it to build other
things.



I had hoped that the Linux From Scratch technique of doing:

sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in

(or an equivalent) before gcc/Makefile.in is used would
allow lang/gcc5-devel to use the same headers in its build
that the installed compiler would then use to produce other
code --by avoiding generating most of the adjusted files in
the first place. But I guess that did not work out.

Eventually most of the lang/gcc* 's will need whatever
technique is used. Some, such as lang/gcc6-aux, need
more done because of binary bootstrap materials being
downloaded and used and so the build of lang/gcc6-aux
gets the problem and fails before staging happens: the
binary-bootstrap materials need to avoid the adjusted
headers that they currently contain.

===
Mark Millard
markmi at dsl-only.net

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

Re: 'pkg version' strangeness - No valid entries found

2017-06-28 Thread Andy Farkas 

On 28/06/2017 22:01, Adam Weinberger wrote:



It may be a typo in your make.conf.

If you have
DEFAULT_VERSIONS+= perl5=lang/perl5.22
It should be
DEFAULT_VERSIONS+= perl5=5.22

# Adam



root# cat /etc/make.conf
cat: /etc/make.conf: No such file or directory

-andyf

___
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

2017-06-28 Thread scratch65535 
On Tue, 27 Jun 2017 18:16:01 -0500, Mark Linimon
 wrote:

>On Tue, Jun 27, 2017 at 04:53:36PM -0400, scratch65...@att.net wrote:
>> Since that's what I integrate for my dev use, I'd be happy to
>> take a zero'th-order cut at defining it, if nobody else wants to.
>
>Fine.  See http://www.lonesome.com/FreeBSD/poudriere/subsets/ for what
>I use.  I'm not particularly interested in maintaining it as a general
>set of files, but if someone can build on it, fine.

Okay, I'll hae a keik.

>
>> By "unnecessary", Mark, I mean the fact that the bits are not
>> controlled locally, and thus potentially change from moment to
>> moment such that it's impossible to guarantee that two people
>> building the same app with the same options on two different
>> days, or even hours, will get the same result.
>
>I don't understand this.
>
>The distinfo mechanism is the solution for this problem for released
>code.
>
>If people are relying on "whatever is in git at the moment" to
>mean "release", well then that's upstream not understanding what
>is meant by "release".  Either educated them or fork their code
>and become the new upstream.

No, I'm talking about how when trying to build a port, even if
using only the defaults, the process often fails to run to
completion.  

And the failure is nearly always because some glop of bits being
fetched from godknowswhere.edu has gone missing, or has been
upped and is now the wrong version as far as the makefile is
concerned, or has some other problem.  

Since I believe that 90% or more of our maintainers are
conscientious and build at least the default config, I can only
suppose, when the make fails, that somebody over at
godknowswhere.edu decided to do something ad-hoc, and that
"something" broke the build.  This happens so often that I don't
even try to build from ports any more ---my own work already
supplies more craziness than I can use.

>
>> Switching to a central repository model, where the bits are
>> fetched from around the globe only once per cycle, sanitised, and
>> thereafter read only from the repository, would drop the number
>> of file-not-founds and wrong-versions down pretty close to zero.
>
>Again, I simply don't understand this.

If we controlled the bits from which ports were built, then
nobody (I hope!!) would be changing them in an ad-hoc way, which
*should* make every build run to completion without
file-not-found etc.

>
>> >No one has ever done the work on "most minimal set of dependencies"
>> >in the ports tree -- and that's because it's hard work.  Add to that
>> >the fact that the technology has never supported partial checkouts
>> >and it complicates things.
>> 
>> No argument from me!   IMO a big contributor to the problem is
>> that the bits haven't been normalised and integrated into
>> libraries.  So the process is frankensteinean:  odds and bobs
>> dredged up wherever they can be found and stuck together in hope
>> that they'll cooperate.
>
>And this is where the hard work lies.
>
>By comparison, defining "which ports are canonical" is easy.
>
>IMHO.

I can only repeat that you'll get no argument from me! 

But that's the basic advantage of libraries:  do the hard work
once, benefit from it forever (fsvo "once" and "forever").   

Or do the work forever, and benefit each time only once.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: 'pkg version' strangeness - No valid entries found

2017-06-28 Thread Adam Weinberger 
> On 28 Jun, 2017, at 4:24, Andy Farkas  wrote:
> 
> 
> root# cd /usr/ports
> root# make index
> Generating INDEX-11 - please wait..--- describe.accessibility ---
> --- describe.arabic ---
> --- describe.archivers ---
>   .
>   .
>   .
> --- describe.x11-toolkits ---
> --- describe.x11-wm ---
> make_index: /usr/ports/archivers/atool: no entry for /usr/ports/:lang/perl5.22
> Done.
> root#
> root# pkg version -v
> pkg: No valid entries found in '/usr/ports/INDEX-11'
> root#
> root# make index
> Generating INDEX-11 - please wait..--- describe.accessibility ---
> --- describe.arabic ---
> --- describe.archivers ---
> --- describe.astro ---
> --- describe.audio ---
> --- describe.benchmarks ---
> ^Z
> Suspended
> root#
> root# pkg version -v
> ImageMagick-6.9.6.4_1,1<   needs updating (port has 6.9.8.9,1)
> ORBit2-2.14.19_2   =   up-to-date with port
> OpenEXR-2.2.0_7=   up-to-date with port
>   .
>   .
>   .
> zenity-3.18.0  =   up-to-date with port
> zip-3.0_1  =   up-to-date with port
> zziplib-0.13.62_2  =   up-to-date with port
> root#
> root# fg
> make index
>   .
>   .
>   .
> 
> ..and after it finishes I get 'No valid entries' error again for 'pkg version'
> 
> Anyone know what's going on and/or how to fix?
> 
> "no entry for /usr/ports/:lang/perl5.22/" looks suspect...

It may be a typo in your make.conf.

If you have
DEFAULT_VERSIONS+= perl5=lang/perl5.22
It should be
DEFAULT_VERSIONS+= perl5=5.22

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

FreeBSD ports you maintain which are out of date

2017-06-28 Thread 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
+-+
emulators/mame  | 0.166   | mame0187
+-+
emulators/mess  | 0.166   | mame0187
+-+
math/giacxcas   | 1.2.2-57| 1.2.3-55
+-+


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"

'pkg version' strangeness - No valid entries found

2017-06-28 Thread Andy Farkas 


root# cd /usr/ports
root# make index
Generating INDEX-11 - please wait..--- describe.accessibility ---
--- describe.arabic ---
--- describe.archivers ---
   .
   .
   .
--- describe.x11-toolkits ---
--- describe.x11-wm ---
make_index: /usr/ports/archivers/atool: no entry for 
/usr/ports/:lang/perl5.22

 Done.
root#
root# pkg version -v
pkg: No valid entries found in '/usr/ports/INDEX-11'
root#
root# make index
Generating INDEX-11 - please wait..--- describe.accessibility ---
--- describe.arabic ---
--- describe.archivers ---
--- describe.astro ---
--- describe.audio ---
--- describe.benchmarks ---
^Z
Suspended
root#
root# pkg version -v
ImageMagick-6.9.6.4_1,1<   needs updating (port has 6.9.8.9,1)
ORBit2-2.14.19_2   =   up-to-date with port
OpenEXR-2.2.0_7=   up-to-date with port
   .
   .
   .
zenity-3.18.0  =   up-to-date with port
zip-3.0_1  =   up-to-date with port
zziplib-0.13.62_2  =   up-to-date with port
root#
root# fg
make index
   .
   .
   .

..and after it finishes I get 'No valid entries' error again for 'pkg 
version'


Anyone know what's going on and/or how to fix?

"no entry for /usr/ports/:lang/perl5.22/" looks suspect...

-andyf

___
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: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work

2017-06-28 Thread Gerald Pfeifer 
Hi everyone,

I am testing a patch for gcc5-devel right now that will disable fixincludes (or 
rather its fixed files) being packaged.

Should that work fine for you, I will push this back to gcc5 the following days.

That said, the change that triggered this is what I would expect on CURRENT, 
not STABLE (and hence hoped we'd have more time for this change).

My Internet connectivity right now is only slightly above pigeon speed, so 
sorry for any delays.

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

2017-06-28 Thread Torsten Zuehlsdorff 

On 27.06.2017 15:24, scratch65...@att.net wrote:

[Default] On Mon, 26 Jun 2017 19:33:50 +, Grzegorz Junka
 wrote:


we could
start small with a just a handful of ports in a stable LTS (Long Term
Support) branch. Develop processes around maintaining them, get some
feedback about the effort of applying only security fixes, then add more
ports as required or as viable from the resources point of view. How
does that sound?


It sounds excellent, at least to me.

How many platform roles are seen as fbsd's metier?

Firewall?  Already handled.

Specialist workstations such as sound/video editing?  Maybe.  I
don't know enough about that to have an opinion.

Servers.  No question.  That's always been freebsd's best thing.
The number of ports to build a server-of-all-work is not large.
Unnecessarily complex and a source of uncontrolled errors, yes,
but not really *large* qua large.


It really depends. For example only www/gitlab needed 400 ports (!) and 
its a while i checked.

Without a defined list of supported software this is only wishing ;)

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

2017-06-28 Thread Torsten Zuehlsdorff 

On 26.06.2017 21:33, Grzegorz Junka wrote:

On 26/06/2017 07:24, Torsten Zuehlsdorff wrote:

Aloha David,


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.


The discussions did go on for a while, but lets get more technical. 
While i can understand your use case, it raises various questions:


- How should be EOL-Software handled? For example PHP 5.6, Typo3 7, 
PostgreSQL 9.2 and many more will expire long before FreeBSD 11 
expires but are still valid (or even default version) when created. 
Since the versions are frozen, how should - at least- security issues 
handled?
[Yes, i read that a user can switch at its own risk to another branch, 
but lets assume he is very fine with the version (because i have such 
customer)]


- How should be new dependencies handled? GitLab for example sometimes 
*requieres* updates of its dependencies in order to fix security issues.


- Same as above: how should be dropped dependencies handled? In worst 
case we need to maintain them for nearly 5 years, but nobody (should) 
use them


- How to resolve conflicts? I mentioned GitLab above and now realize, 
that sometimes the GitLab update breaks for example www/redmine 
because it depends at other versions than GitLab.


- Where do get the fixes from? We have around 26.000 ports which needs 
fixes in worst case


- How to handle for example security issues only fixed through an 
update? Which such a long time between "updates" it gets very very 
hard to port/get/write patches in fast developing software. Wordpress 
or Gitlab are typical examples with thousands of lines in code-changes 
every update


- How to make the customer clear, that complains about the software 
(old, outdated, missing features, unresolved bugs, etc) are intentional?


- Where to archive the distfiles? Sometimes upstream completely remove 
them from everywhere they can.


And last: how to make updates from FreeBSD version to version easier? 
Many user already have problems with single major updates. From my 
experiences in Windows or Ubuntu LTS usages with such or very similar 
version handling: the update, even of the OS, is pushed as far away as 
possible, because of the big amount of work required, since everything 
needs to checked/updated/changed.


I have a hard time to image, that is handled in another way by you. So 
if you can me give more insight about your use-case i would be happy 
to read it for a better understanding.


I have various customer requiring (and paying for) very old software 
(for example still PHP 5.3). So i know some of there motivations, 
which boils every time down to "its to expensive to upgrade our 
software" [but they don't mean expensive in money]. So maybe we can 
make something happen. 


I understand a stable ports branch would be required by specific 
applications (of the FreeBSD system), e.g. data centers, bespoke private 
solutions, home servers. Therefore not all 26.000 ports would need to be 
security-patched. In fact, I believe it would be viable to determine a 
thousand or two of ports mostly used in those environments and commit to 
patch only those.


Yes, but even with a subset of the ports-tree neither of the above 
problems is addressed!


Even RedHat, which is a model example, doesn't commit to maintain all 
packages, just a selected set of them. In the similar fashion to having 
Tier 1, Tier 2 and Tier 3 supported platforms for FreeBSD, we could 
start small with a just a handful of ports in a stable LTS (Long Term 
Support) branch. Develop processes around maintaining them, get some 
feedback about the effort of applying only security fixes, then add more 
ports as required or as viable from the resources point of view. How 
does that sound?


This didn't address any of the issues mentioned above. Nor from other 
threads.


But to be clear: since i already do such things (on a much smaller 
scale) i have no problem with this idea. But since i'm already get paid 
and know the work behind it, i wont do it for free.
Even do setup a minimal QA infrastructure needs money and maintenance 
and just build-tests are not enough.


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: Should a package restart on upgrade itself

2017-06-28 Thread Guido Falsi 
On 06/27/17 19:32, Miroslav Lachman wrote:
> Matthias Fechner wrote on 2017/06/27 18:29:
>> Dear all,
>>
>> it is always a pain if pkg upgrade a lot of packages to restart all
>> services to make sure update/security fixes are applied to all running
>> services.
>>
>> Is there an option in pkg that it restart services automatically or is
>> it OK if I would add a post-install script to the packages (I maintain)
>> that will include a "service foo restart"?
>>
>> What is best practice here?
> 
> Please don't do this.
> Some ports did this in the past and this was really a pain during larger
> upgrades. It sometimes leave services stopped (hi MySQL).
> 

I subscribe to this comment. I also got burned in the past by this
behavior(which luckily is no more present).

I'd like to also comment that pkg should just do it's work, managing
packages, if you want to automate system maintenance, there are specific
tools for that (like puppet, ansible, cfengine, chef...and others I
can't name right away).

Coding parts of software configuration management in pkg is not a good
idea IMHO.

-- 
Guido Falsi 
___
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: Should a package restart on upgrade itself

2017-06-28 Thread Torsten Zuehlsdorff 



On 27.06.2017 18:29, Matthias Fechner wrote:

Dear all,

it is always a pain if pkg upgrade a lot of packages to restart all
services to make sure update/security fixes are applied to all running
services.

Is there an option in pkg that it restart services automatically or is
it OK if I would add a post-install script to the packages (I maintain)
that will include a "service foo restart"?


Since the number of services is limited i do in such scenarios you 
described (or in doubt) a simple:

# service -R

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

2017-06-28 Thread Thomas Mueller 
from Mark Linimon:

> On Tue, Jun 27, 2017 at 09:01:39PM +, Thomas Mueller wrote:
> > raising the possibility of building for other targets.

> Which is very much not hardly even the same as "they are being resistant
> to change".  In fact, about as far away from it as is possible to get.

> "techinically possible" != "feasible in the immediate future".

> I feel like I'm repeating myself in this thread, again.

> mcl

A lot of pkgsrc users, perheps the majority, use architecture either i386 or 
amd64 (I have no statistics).

FreeBSD also supports many architectures, not as many as NetBSD, but some where 
there is no Ada compiler, and no LLVM/clang either.

Some of the architectures supported by NetBSD are near-extinct now, acorn26 for 
one, and would not be prime targets for pkgsrc development, nobody is going to 
care about lack of an Ada compiler.

Tom

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