Re: virtualbox issue

[chris]

Hi,

I got this too and found it was something to do with my src.conf but I got lazy 
and didn't bother to test which one it was. But it's a start?

Chris

 On Tue, 25 Nov 2014 08:34:17 -0600 R. Scott 
Evans wrote  
 > I sucessfully updated virtualbox on my 9.3-RELEASE (amd64) hosts today  
 > without incident but trying to update an existing virtualbox-ose-4.3.18  
 > port to 4.3.20 on a 10.1-RELEASE (amd64) box and I get a fail message  
 > that I don't have 32 bit libraries.  Worked without them before but  
 > okay, I try and install the 32 bit libraries: 
 >  
 > "cd /usr/src; make build32 install32" 
 >  
 > and I now choke on libmagic... 
 >  
 > "... 
 > cd /usr/src/lib/libmagic;  WORLDTMP=/usr/obj/usr/src/tmp  MAKEFLAGS="-m  
 > /usr/src/tools/build/mk  -m /usr/src/share/mk"  
 > MAKEOBJDIRPREFIX=/usr/obj/lib32 make SSP_CFLAGS= DESTDIR=  
 > DIRPRFX=lib/libmagic/ -DNO_LINT -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF  
 > -DEARLY_BUILD build-tools 
 > cc -O2 -pipe  -DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H  
 > -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file/src  
 > -std=gnu99   -I/usr/obj/usr/src/tmp/legacy/usr/include -DCOMPILE_ONLY  
 > -L/usr/obj/usr/src/tmp/legacy/usr/lib -o mkmagic  
 > /usr/src/lib/libmagic/../../contrib/file/src/apprentice.c  
 > /usr/src/lib/libmagic/../../contrib/file/src/cdf_time.c  
 > /usr/src/lib/libmagic/../../contrib/file/src/encoding.c  
 > /usr/src/lib/libmagic/../../contrib/file/src/funcs.c  
 > /usr/src/lib/libmagic/../../contrib/file/src/magic.c  
 > /usr/src/lib/libmagic/../../contrib/file/src/print.c  -lz -legacy 
 > /usr/bin/ld: cannot find -legacy 
 > cc: error: linker command failed with exit code 1 (use -v to see invocation) 
 > *** Error code 1 
 >  
 > Stop. 
 > make[2]: stopped in /usr/src/lib/libmagic 
 > *** Error code 1 
 >  
 > Stop. 
 > make[1]: stopped in /usr/src 
 > *** Error code 1 
 >  
 > Stop. 
 > make: stopped in /usr/src 
 > " 
 >  
 > What am I missing? 
 >  
 > Thanks, 
 > -scott 
 > ___ 
 > freebsd-ports@freebsd.org mailing list 
 > http://lists.freebsd.org/mailman/listinfo/freebsd-ports 
 > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" 
 > 


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

Re:

[chris]

Hi,

Try compiling it from ports, or supply us with some sort of debug info.

Chris


-
Chris Petrik
FreeBSD Developer
E on FreeBSD
--
As in certain cults it is possible to kill a process if you know its true name.
-- Ken Thompson and Dennis M. Ritchie







 On Wed, 26 Nov 2014 22:10:11 -0600 B J 
wrote  
 > I recently made a clean installation of FreeBSD 10 on an external hard 
 > drive, using Mate as the desktop and Slim as the login manager. 
 >  
 > I installed Squeak using: 
 >  
 > pkg install lang/squeak 
 >  
 > When I try to run Squeak by simply typing 
 >  
 > squeak 
 >  
 > but it looks for a VM.  Being more specific with the file locations, when I 
 > try: 
 >  
 > /usr/local/lib/squeak/4.10.2-2614/squeakvm 
 > /usr/local/lib/squeak/Squeak4.3.image 
 >  
 > I get: 
 >  
 > "Illegal instruction (core dumped)" 
 >  
 > If I try: 
 >  
 > /usr/local/bin/squeak/ /usr/local/lib/squeak/Squeak4.3.image 
 >  
 > the result is: 
 >  
 > CHECKING cogvm 
 > CHECKING squeakvm 
 > Illegal instruction (core dumped) 
 >  
 > The version is squeak-4.10.2_2.  I had the same thing happen a few 
 > days ago when I installed 4.10.2_1.  A few months ago, I installed 
 > Squeak on an internal drive running FreeBSD 10 with Gnome2 and GDM and 
 > it executes without any problem. 
 >  
 > Did I overlook something because I have no idea what's going on. 
 >  
 > Please advise.  Thank you. 
 >  
 > Dr. B. M. Jatzeck 
 > ___ 
 > freebsd-ports@freebsd.org mailing list 
 > http://lists.freebsd.org/mailman/listinfo/freebsd-ports 
 > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" 
 > 


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

Re: Updating CentOS ports infrastructure

[chris]

 On Fri, 12 Dec 2014 05:31:34 -0600 Jerry wrote 
 

Fri, 12 Dec 2014 06:27:41 -0500 
 
UPDATING 20141209 does not specifically list having to install the 
emulators/linux-c6 port. Isn't that a required prerequisite? 
 
-- 
Jerry 


This is the meta port, ports such as linux-flash only require certain parts 
etc..

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

Re: Resetting maintainership

[chris]

 On Fri, 12 Dec 2014 17:31:54 -0600 Dan Langille 
wrote  


> On Dec 10, 2014, at 5:27 PM, Pietro Cerutti  
wrote: 
> 
> All, 
> 
> unfortunately, I don't foresee having time to take care of my ports as 
> they deserve in the near future. Hence, I'm dropping maintainership of 
> all of them. Of course, I'll be occasionally patching and updating stuff 
> here and there anyway. Here's the list of ports. Please be greedy :) 
 
That’s a whole lot of ports. Thanks for your work. Best wishes. 
 
— 
Dan Langille 
http://langille.org/ 
 
 
 
 
 


Please send list so I can see if any interest me.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Re: Resetting maintainership

[chris]

 On Fri, 12 Dec 2014 20:25:42 -0600 Chris H <bsd-li...@bsdforge.com> 
wrote  

On Fri, 12 Dec 2014 18:01:29 -0600 chris <ch...@bsdjunk.com> wrote

>  On Fri, 12 Dec 2014 17:31:54 -0600 Dan 
Langille&lt;d...@langille.org&gt;
> wrote  
>
> 
> &gt; On Dec 10, 2014, at 5:27 PM, Pietro Cerutti 
&lt;g...@freebsd.org&gt;
> wrote: &gt; 
> &gt; All, 
> &gt; 
> &gt; unfortunately, I don't foresee having time to take care of my 
ports as 
> &gt; they deserve in the near future. Hence, I'm dropping 
maintainership of 
> &gt; all of them. Of course, I'll be occasionally patching and 
updating stuff
> &gt; here and there anyway. Here's the list of ports. Please be greedy 
:) 
> 
> That’s a whole lot of ports. Thanks for your work. Best wishes. 
> 
> — 
> Dan Langille 
> http://langille.org/ 
> 
> 
> 
> 
> 
> 
> 
> Please send list so I can see if any interest me.
Please learn to use the mailing list archives for such things:
https://docs.freebsd.org/mail/current/freebsd-ports.html

Thanks.

--Chris

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


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

I'll take all of those if possible.

Chris

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

Re: FreeBSD Port: hiawatha-9.8

[chris]

On , Alex wrote:

Hello,

hiawatha-web server 9.11 is out and include many nice features and 
updates.

Please update hiawatha port and pkg.

Thanks in advance.
I am working on a update that uses the port polarssl which looks to be 
broken atm. Once that is fixed I will submit a PR for such update.


The Grim Reaper

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

python support appears broken in the ports trree

[Chris]

I've spent the past 2 days attempting a fresh build/install
of world/kernel && preferred ports/applications. The world/kernel
worked to perfection. But I can *not* get the ports to build,
and install. All *fatal* errors stem from python.
So after booting into a new world/kernel; I proceed to build/install
perl5-5.30, python27 && python37. I now feel I have the versions I
need/want. So I move to /usr/ports/x11/xorg and perform a
make config-recursive until the dialogs will no longer appear.

From there (today) make(1) terminates at:

...
===>  Staging for xorg-7.7_3
===>   xorg-7.7_3 depends on file: /usr/local/libdata/pkgconfig/dri.pc - not 
found
===>   mesa-dri-18.3.2_9 depends on package: wayland-protocols>=1.8 - found
===>   mesa-dri-18.3.2_9 depends on file: 
/usr/local/libdata/pkgconfig/pthread-stubs.pc - found
===>   mesa-dri-18.3.2_9 depends on executable: bison - found
===>   mesa-dri-18.3.2_9 depends on executable: msgfmt - found
===>   mesa-dri-18.3.2_9 depends on executable: gmake - found
===>   mesa-dri-18.3.2_9 depends on package: pkgconf>=1.3.0_1 - found
===>   mesa-dri-18.3.2_9 depends on file: /usr/local/bin/python2.7 - found
===>   mesa-dri-18.3.2_9 depends on package: llvm80>=3.9.0_4 - not found
===>  llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified.
*** Error code 1

...

I struggled all day yesterday with various ports barfing with similar
python messages. So today I blew everything off the disk, and started
from scratch. Which only repeats what happened yesterday. Is python
multiplicity no longer available? Or?

make.conf(5)
DEFAULT_VERSIONS+=tcl=8.7 tk=8.7

FreeBSD eleventhree 11.3-RELEASE-p5 FreeBSD 11.3-RELEASE-p5 #0 r355580: Tue Dec 
10 13:22:30 PST 2019
root@eleventhree:/usr/obj/usr/src/sys/ELEVENTHREE  amd64

Path: /usr/src
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/releng/11.3
Relative URL: ^/releng/11.3
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 355580
Node Kind: directory
Schedule: normal
Last Changed Author: gordon
Last Changed Rev: 354654
Last Changed Date: 2019-11-12 10:13:51 -0800 (Tue, 12 Nov 2019)

Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: svn://svn.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 519768
Node Kind: directory
Schedule: normal
Last Changed Author: pizzamig
Last Changed Rev: 519768
Last Changed Date: 2019-12-10 09:39:01 -0800 (Tue, 10 Dec 2019)

Thank you for all your time, and consideration.

--Chris


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

Re: python support appears broken in the ports trree

[Chris]

On Tue, 10 Dec 2019 16:53:38 -0800 s...@troutmask.apl.washington.edu said

Thank you very much for taking the time to reply.

On Tue, Dec 10, 2019 at 04:47:06PM -0800, Chris wrote:
> I struggled all day yesterday with various ports barfing with similar
> python messages. So today I blew everything off the disk, and started
> from scratch. Which only repeats what happened yesterday. Is python
> multiplicity no longer available? Or?
> 


Empirical evidence suggests that answer is "yes".


Sigh... It would /seem/ so.
Maybe someone(tm) should make an entry in UPDATING?

Thanks again!

--Chris


--
Steve
___
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: python support appears broken in the ports trree

[Chris]

On Wed, 11 Dec 2019 06:21:29 +0100 Jan Beich jbe...@freebsd.org said


Chris  writes:

> I struggled all day yesterday with various ports barfing with similar
> python messages. So today I blew everything off the disk, and started
> from scratch. Which only repeats what happened yesterday. Is python
> multiplicity no longer available? Or?

See bug 233723 or bug 237795. Build each port separately instead of relying
on dependecy chaining should work. For best experience use poudriere.


Thank you very much for the insight, Jan!
Near as I can figure from the two bugs, I'm going to need to fix
Mk/python.mk

That should be a fun project. :P

Thanks again!

--Chris


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

What is the actual syntax used to FLAVOR ports?

[Chris]

OK I know FLAVOR is an evolving concept. But I can not find
the FLAVOR documentation. Only references in the porters
handbook. What I think needs to be available is an entire
list of flavor tags for all (port) categories.
For example;
make FLAVOR=python27 returns the error use py27.
OK now I know how to flavor, and build python flavors.
But what of Perl?
make FLAVOR=perl2.8. Nope. How about make FLAVOR=p5-28,
and so it goes...
Does there exist a definitive list of flavors? It'd
also be valuable for defining defaults in make.conf(5)

Thanks!

--Chris


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

Re: What is the actual syntax used to FLAVOR ports?

[Chris]

On Sat, 8 Feb 2020 21:44:35 -0800 Kevin Oberman rkober...@gmail.com said


On Sat, Feb 8, 2020 at 1:27 PM Chris  wrote:

> OK I know FLAVOR is an evolving concept. But I can not find
> the FLAVOR documentation. Only references in the porters
> handbook. What I think needs to be available is an entire
> list of flavor tags for all (port) categories.
> For example;
> make FLAVOR=python27 returns the error use py27.
> OK now I know how to flavor, and build python flavors.
> But what of Perl?
> make FLAVOR=perl2.8. Nope. How about make FLAVOR=p5-28,
> and so it goes...
> Does there exist a definitive list of flavors? It'd
> also be valuable for defining defaults in make.conf(5)
>
> Thanks!
>
> --Chris


The problem is not having a clear understanding of what a FLAVOR is and
when it is used.

FLAVORS are generally a way to deal with the problem of incompatible
versions and Python is the poster child. Python2 and Python3 are two
version of a VERY popular language that have significant syntax
incompatibilities. While a program written for gcc-4.2 should work fine
when compiled with gcc-7, it is VERY unlikely that a program written for
Python2 will work with Python3. While the changes needed are often fairly
straight forward, they have to be made. The result is a requirement of
having both interpreters installed and two packages of of most Python
libraries built from a single source.

Adding FLAVORS for a port is an expensive operation and is never lightly
approved by the ports management team as it adds a great deal of complexity
and both human and machine overhead. Requests to FLAVOR a port are
carefully reviewed and will only be approved with adequate justification.

In the case of Perl, no attempt to flavor it has been needed. Most Perl
packages (p5-*) will work with any of the three available ports. In most
cases they may be installed and continue to work across versions with no
changes. Python (py-) ports MUST be reinstalled to move from Python2 to
Python3. Some have not had required changes to work with Python3 made and,
initially, almost none did. Some have now been written with no support for
Python2. All of this has to be properly handled by the package building
system and it is not at all trivial.

As of today, I believe the only FLAVORed ports are those using emacs,
lazarus, php, and, of course, python. By "using", I mean that the port
Makefile includes "USE_PYTHON" or similar USE_ definitions of the other
languages. (Yes, emacs is not a language, but elisp, the core of emacs, is
and lazarus is an IDE for Pascal.)

I'm sorry of this is not entirely clear, but I hope it helps and I hope it
is all correct. I may have worded some of it poorly.

Thank you for taking the time to provide a very informative answer, Kevin.
You did a fine job!
I currently am Maintainer for ~150 ports. So have become very familiar
with the prerequisites. But have become fairly frustrated with the
introduction of FLAVOR(s). Not the concept. But the lack of documenting
them. As a user; what would I use to apply a FLAVOR for any given port I
want to install; as in what is the correct syntax for all the languages
that are, or will be flavored? I can't seem to find any definitive
documentation. As a porter, the subject matter is fairly terse in the
porters handbook. Not many clues in /usr/ports/MK either.
So since I was unable to find much FLAVOR documentation. Specifically;
syntax for all the languages available to FLAVOR(s). I thought I might
try here.

Thanks again, for taking the time to reply!

--Chris


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

Re: What is the actual syntax used to FLAVOR ports?

[Chris]

On Tue, 11 Feb 2020 09:45:53 +0100 Mathieu Arnold m...@freebsd.org said


On Mon, Feb 10, 2020 at 09:02:34PM -0500, Ernie Luzar wrote:
> Kevin Oberman wrote:
> > On Sat, Feb 8, 2020 at 1:27 PM Chris  wrote:
> > 
> > > OK I know FLAVOR is an evolving concept. But I can not find

> > > the FLAVOR documentation. Only references in the porters
> > > handbook. What I think needs to be available is an entire
> > > list of flavor tags for all (port) categories.
> > > For example;
> > > make FLAVOR=python27 returns the error use py27.
> > > OK now I know how to flavor, and build python flavors.
> > > But what of Perl?
> > > make FLAVOR=perl2.8. Nope. How about make FLAVOR=p5-28,
> > > and so it goes...
> > > Does there exist a definitive list of flavors? It'd
> > > also be valuable for defining defaults in make.conf(5)
> > > 
> > > Thanks!
> > > 
> > > --Chris
> > 
> > 
> > The problem is not having a clear understanding of what a FLAVOR is and

> > when it is used.
> > 
> > FLAVORS are generally a way to deal with the problem of incompatible

> > versions and Python is the poster child. Python2 and Python3 are two
> > version of a VERY popular language that have significant syntax
> > incompatibilities. While a program written for gcc-4.2 should work fine
> > when compiled with gcc-7, it is VERY unlikely that a program written for
> > Python2 will work with Python3. While the changes needed are often fairly
> > straight forward, they have to be made. The result is a requirement of
> > having both interpreters installed and two packages of of most Python
> > libraries built from a single source.
> > 
> > Adding FLAVORS for a port is an expensive operation and is never lightly

> > approved by the ports management team as it adds a great deal of
> complexity
> > and both human and machine overhead. Requests to FLAVOR a port are
> > carefully reviewed and will only be approved with adequate justification.
> > 
> > In the case of Perl, no attempt to flavor it has been needed. Most Perl

> > packages (p5-*) will work with any of the three available ports. In most
> > cases they may be installed and continue to work across versions with no
> > changes. Python (py-) ports MUST be reinstalled to move from Python2 to
> > Python3. Some have not had required changes to work with Python3 made and,
> > initially, almost none did. Some have now been written with no support for
> > Python2. All of this has to be properly handled by the package building
> > system and it is not at all trivial.
> > 
> > As of today, I believe the only FLAVORed ports are those using emacs,

> > lazarus, php, and, of course, python. By "using", I mean that the port
> > Makefile includes "USE_PYTHON" or similar USE_ definitions of the other
> > languages. (Yes, emacs is not a language, but elisp, the core of emacs, is
> > and lazarus is an IDE for Pascal.)
> > 
> > I'm sorry of this is not entirely clear, but I hope it helps and I hope it

> > is all correct. I may have worded some of it poorly.
> > --
> > Kevin Oberman, Part time kid herder and retired Network Engineer
> > E-mail: rkober...@gmail.com
> > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> 
> wow the above reply is not how I remember how things were envisioned when

> this flavor function was first talked about. Having to get permission first
> and being limited to languages was never talked about and not at all a
> requirement.


Thank you *very* much for the link and reply, Mathieu!
I must admit to being fairly embarrassed for having missed it.


Having to get permissions was never envisioned, and we will stop having
it as a requirement when people stop trying to forcefully do very silly
things, it will probably be relaxed when we have subpackages.
It is not at all limited to languages, I have no idea where that came
from.  You only have to grep for '^FLAVORS=' to see that.

Good tip! I think it's simply *easiest* to think of it in terms of languages,
akin to DEFAULT_VERSIONS.


> It was envisioned as a way to per can a set of different
> defaults so a package with pre canned defaults would be auto built in the
> ports system that is different from the basic defaults.  ON the subject of
> documentation about how to set up flavors for a port is totally lacking at
> this point. You know the old saying, developers are good programmers but are
> terrible at documenting their work if they do it at all. So with that in
> mind do your own thing following what you see for flavored languages

llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified.

[Chris]

I'm testing modifications of ports I maintain in
a jail. I have nothing in make.conf(5) except
DEVELOPER=true
But I get messages regarding python versions like:
llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified.
But I make no demands on versions.
What causes this, and how can I stop it. :)

Thanks!

--Chris


___
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: llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified.

[Chris]

On Thu, 27 Feb 2020 19:52:23 + Brooks Davis bro...@freebsd.org said


On Thu, Feb 27, 2020 at 08:44:59AM -0800, Chris wrote:
> I'm testing modifications of ports I maintain in
> a jail. I have nothing in make.conf(5) except
> DEVELOPER=true
> But I get messages regarding python versions like:
> llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified.
> But I make no demands on versions.
> What causes this, and how can I stop it. :)

Is your set of packages fully up to date?  IIRC other have had issues
when they tried to install LLVM with out of date dependencies.

Thank you for taking the time to reply, Brooks!
Yep. Fully synced. In fact the whole jail was fresh. Only a new
world, and a fresh ports tree. Nothing had yet been built; which
explains the need for llvm8. But not the Python discrepancy. :/

Thanks again!

--Chris


-- Brooks



___
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: llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified.

[Chris]

On Thu, 27 Feb 2020 21:46:12 +0100 Mathieu Arnold m...@freebsd.org said


On Thu, Feb 27, 2020 at 07:52:23PM +, Brooks Davis wrote:
> On Thu, Feb 27, 2020 at 08:44:59AM -0800, Chris wrote:
> > I'm testing modifications of ports I maintain in
> > a jail. I have nothing in make.conf(5) except
> > DEVELOPER=true
> > But I get messages regarding python versions like:
> > llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified.
> > But I make no demands on versions.
> > What causes this, and how can I stop it. :)
> 
> Is your set of packages fully up to date?  IIRC other have had issues

> when they tried to install LLVM with out of date dependencies.

It was fixed on r522485.

Thanks! :)

--Chris


--
Mathieu Arnold



___
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: About protocols in openssl

[Chris]

On Fri, 28 Feb 2020 09:59:21 +0100 Willem Jan Withagen w...@digiware.nl said


On 28-2-2020 01:32, Marcin Cieslak wrote:
> On Thu, 27 Feb 2020, Willem Jan Withagen wrote:
>
>>
> 
/home/jenkins/workspace/ceph-master/src/pybind/mgr/.tox/py3/lib/python3.7/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
> 
>> Undefined symbol "SSLv3_client_method"

>
> This looks to me that you are trying to build ceph in the virtualenv 
> which probably

> pulls required python packages on its own.
>
> Can you make it to depend and use the existing 
> security/py-cryptography port?

>
> I don't know how exactly the ceph port is supposed to work but it 
> seems to

> require virtualenv for its inner workings. You might want to force
> virtual env to use FreeBSD-provided libraries with --system-site-packages
> but AFAIK it will no longer download anything, i.e. all dependencies
> need to packaged.
>
Interesting, since virtualenv/tox is used during testing with Continuous 
Integration.
And there is where I need the stuff, the port/package comes without the 
testing stuff.
People that want to develop stuff for Ceph really should use what is in 
the Git repo.


> I have just ran "make test" in my ports tree to test py-cryptography
> and got 1 error (TestECDSACertificate.test_load_ecdsa_no_named_curve)
> but nothing related to SSLv3_client_method being not there.
I guess that is because the ports one does not require SSLv3, and is not 
complaining about missing it.
Like you said, very likely virtualenv has pulled its own stuff, and that 
will require SSLv3

Which is no longer available by default  in openSSL in ports.

I'll try and see if I can get away with --system-site-packages, and 
loading tons op packages.

I feel your pain. I was working on a port I maintain 2 days ago, where
configure *insisted* that SSL wasn't available. It was driving me mad.
As all the while I assumed that it was the way I had crafted the Makefile,
or that the ports system had recently changed something. As a result I
acquired a far more intimate knowledge regarding how SSL is used in ports(7).
Worst of it was; in the end, it turned out to be that configure was
searching for a symbol in the openssl library I was using, that had been
removed (renamed) between 1.1.1 && 1.1.1d. Sorry for the long preface.
But I mention it all because in doing it I'm pretty sure I know how you
can get away with what you're after (using the last version that allowed
what you need). I need to get in front of my builder box, and grab the
logs. So I can give you the magic incantation for your Makefile.
I'll probably get a lot of grief for saying all this. So I'll share
those details off list. So as not to give instructions on how to subvert
the ports system. ;)

HTH

--Chris

FreeBSD 14.0-FUTURE #0.000 cray256



--WjW
___
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: New bacula release

[Chris]

On Fri, 28 Feb 2020 11:20:51 +0100 Andrea Venturoli m...@netfence.it said


Hello.

Sorry to bother you, but I'm planning some upgrades of old Bacula 
installation and I'd benefit from some info.


While I was going to update to 9.4.x, I saw 9.6.2 is out.
Do you have any schedule for the FreeBSD port?

Just to decide whether to wait for it or go ahead with 9.4 in the meantime.

 bye & Thanks
av.

What revision is your ports(7) tree at? I mention this, because according
the site that maintainer of bacula runs:

https://www.freshports.org/search.php?query=bacula&stype=name&method=match&num=100&deleted=excludedeleted&orderby=category&orderbyupdown=asc&search=Search

indicates bacula is already at 9.6.2. :)

HTH

--Chris
FreeBSD 14.0-FUTURE #0.000 cray256


___
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: When to use TMPPLIST instead of pkg-plist?

[Chris]

On Sat, 29 Feb 2020 11:02:23 +0100 Mateusz Piotrowski 0...@freebsd.org said


On 2/29/20 12:15 AM, Mathieu Arnold wrote:
> On Fri, Feb 28, 2020 at 10:06:19PM +0100, Mateusz Piotrowski wrote:
>> Do we have any (perhaps unwritten) policy for when to use TMPPLIST? And
> when
>> should a port maintainer stick to pkg-plist?
> We do not.  A port maintainer should stick to pkg-plist.

That's what I thought.

Is there a reason for it? Does it all boil down to that fact that 
pkg-plist is much more explicit and easier to debug/review? Or there is 
another reason?

TMPPLIST is an artifact of the QA process when making a port. It is used
for comparison to what you, as a port maintainer claim is the pkg-plist,
and whats found that looks as the actual plist. When a discrepancy occurs.
You're warned, and instructed to make changes as required.
The thing is, because of so many variables, that TMPPLIST isn't always
correct. So to rely on it, as Mathieu stated, would be *bad* policy. As
memory serves; it's also the product of make make-plist.

Hope that helps in clarification. :)

--Chris

FreeBSD 14.0-FUTURE #0.000 cray256



Cheers,

Mateusz

___
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: When to use TMPPLIST instead of pkg-plist?

[Chris]

On Sat, 29 Feb 2020 19:44:40 + Bob Eager r...@tavi.co.uk said


On Sat, 29 Feb 2020 11:29:18 -0800
Chris  wrote:

> TMPPLIST is an artifact of the QA process when making a port. It is
> used for comparison to what you, as a port maintainer claim is the
> pkg-plist, and whats found that looks as the actual plist. When a
> discrepancy occurs. You're warned, and instructed to make changes as
> required. The thing is, because of so many variables, that TMPPLIST
> isn't always correct. So to rely on it, as Mathieu stated, would be
> *bad* policy. As memory serves; it's also the product of make
> make-plist.

 make makeplist

I believe

You believe correctly. :)
funny it doesn't show up in man ports.

Thanks for the correction, Bob!

--Chris


___
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: When to use TMPPLIST instead of pkg-plist?

[Chris]

On Sat, 29 Feb 2020 14:30:14 -0500 Theron theron.tar...@gmail.com said


On 2020-02-29 14:44, Bob Eager wrote:
>make makeplist
>
> I believe
>
Indeed.  A port may also provide its own definition of makeplist 
(ideally preserving the /you/have/to/check/... nag) to make maintenance 
easier, but any changes to resulting pkg-plist can still be easily seen 
by version control.  Is providing such helpers encouraged / discouraged 
as a policy?

It's a tool, in an aid for automation/convenience. A good maintainer will
recognize that, and act accordingly. :)
IOW it's not 100%, and it's output is subject to scrutiny by the maintainer.

--Chris


Theron



___
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: claws-mail search a new home

[Chris]

On Fri, 6 Mar 2020 09:33:35 +0100 Jochen Neumeister jon...@freebsd.org said


Heya,

On the desktop I switched from FreeBSD to MacOS.
Therefore I am looking for a new home for the claws-mail ports.
So if you are interested in maintaining these ports in the future, 
please send a message.

I hope I can leave this very good email client in good hands :)

If I'm not using Webmail, Claws is my go-to mail client. I really
like it. I realize this is also a commitment to a good many "plugins". :)
If you consider me a worthy candidate. I'd be more than happy to
take it off your hands (Maintain it). :)

Thanks for your time, and consideration!

--Chris
FreeBSD 14.0-FUTURE #0.000 cray256



Cheers
Jochen

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

7 month old bug squashed. Please commit

[Chris]

Hi I just picked up mail/claws-mail, and discovered a
7 month old bug. I resolved the problem, and created
a patch to fix it. I wouldn't normally say anything
except that it's such an old bug.

pr: 239659

Thanks!

--Chris


___
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: how to retrieve the messages ports emit after install?

[Chris]

OK I'm a by ports make install as a rule. But I needed to
spin up a box quickly, and decided to use pkg(8). xorg,
and another port (package) I installed, dumped some
important information after the install. I stripped the
text from the console/terminal, and tried to paste it into
a fresh file. But the new graphics drivers don't allow
that sort of thing (graphics vs text mode). So I was left
with mostly gibberish. I need to get that information back.
I just guessed that pkg message  might do it.
But no joy. How can I retrieve that information?

Thanks!

--Chris


___
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: how to retrieve the messages ports emit after install?

[Chris]

On Wed, 18 Mar 2020 08:27:29 + Bob Eager r...@tavi.co.uk said


On Tue, 17 Mar 2020 23:28:49 -0700
Chris  wrote:

> OK I'm a by ports make install as a rule. But I needed to
> spin up a box quickly, and decided to use pkg(8). xorg,
> and another port (package) I installed, dumped some
> important information after the install. I stripped the
> text from the console/terminal, and tried to paste it into
> a fresh file. But the new graphics drivers don't allow
> that sort of thing (graphics vs text mode). So I was left
> with mostly gibberish. I need to get that information back.
> I just guessed that pkg message  might do it.
> But no joy. How can I retrieve that information?

Simple!

 pkg info -D pkgname

(or pkg info --pkg-message pkgname)

--pkg-message, argh... I was *so* close!
Thanks, Bob. Really appreciated!
and for the record. I *did* read the man page. But as others
were also inclined to suggest; I thought the output would be
related to *query*

Thanks also, to everyone else who took the time to help!

--Chris


There are more complicated ways...



___
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: how to retrieve the messages ports emit after install?

[Chris]

On Wed, 18 Mar 2020 14:20:05 + Bob Eager r...@tavi.co.uk said


On Wed, 18 Mar 2020 07:18:40 -0700
Chris  wrote:

> > > OK I'm a by ports make install as a rule. But I needed to
> > > spin up a box quickly, and decided to use pkg(8). xorg,
> > > and another port (package) I installed, dumped some
> > > important information after the install. I stripped the
> > > text from the console/terminal, and tried to paste it into
> > > a fresh file. But the new graphics drivers don't allow
> > > that sort of thing (graphics vs text mode). So I was left
> > > with mostly gibberish. I need to get that information back.
> > > I just guessed that pkg message  might do it.
> > > But no joy. How can I retrieve that information?  
> > 
> > Simple!
> > 
> >  pkg info -D pkgname
> > 
> > (or pkg info --pkg-message pkgname)  
> --pkg-message, argh... I was *so* close!

> Thanks, Bob. Really appreciated!
> and for the record. I *did* read the man page. But as others
> were also inclined to suggest; I thought the output would be
> related to *query*

As it happens, I had the same problem a few days ago and eventually got
round to a rather persistent search for the information!

I appreciate your persistence! I was going mad trying to figure it out.
IMHO this should be added to the pkg(8) man page. Maybe the EXAMPLES section?

Thanks again, Bob!

--Chris


___
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: how to retrieve the messages ports emit after install?

[Chris]

On Wed, 18 Mar 2020 17:31:53 +0100 Mateusz Piotrowski mpp...@gmail.com said


On 3/18/20 5:20 PM, Chris wrote:
> IMHO this should be added to the pkg(8) man page. Maybe the EXAMPLES 
> section?


https://github.com/freebsd/pkg/pull/1819

Cheers,

Mateusz

WOW! That was fast. Thank you!!! :)

--Chris


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

drmn0: This code is obsolete abandonware. Install the graphics/drm-legacy-kmod pkg

[Chris]

erm...
I *did* install the graphics/drm-legacy-kmod pkg
what's going on here.
This is on 12.1-CURRENT as is installed from the install
media. Followed by a
pkg install xorg-server xorg-drivers xorg-fonts xorg-apps \
drm-legacy-kmod xfce-4 slim pcmanfm
echo startxfce4>~/.xinitrc
echo 'kld_list="/boot/modules/i915kms.ko">>/etc/rc.conf
and bounce the box.
This drm problem also seems to be interfering with my
ability to run xfce4 (of xorg) properly.

What do I need to do?

Thanks!

--Chris


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

Re: mail/mailman v3?

[Chris]

On Tue, 28 Apr 2020 16:43:49 +0200 Kurt Jaeger p...@freebsd.org said


Hi!

> I see the mailman lists themselves are now on Mailman 3:
> 
>

> 
https://mail.python.org/archives/list/mailman-annou...@python.org/thread/HHQN7V6NY7G5CTOSC3WBU7VXW5KEBGVO/

Interesting!

Looks like a very uncomfortable design for uniq URLs 8-(

Agreed. It's also appears to be only about half completed.
In the end, this looks more a downgrade than an upgrade, as
at *least* it completely abandons the previous archive system.
Making your previous archive, an archive of an archive. :(
Hyperkitty -- isn't that sort of redundant? I mean; have you ever
seen a kitty that _wasn't_ *hyper* ? :)

--Chris





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

Re: mail/mailman v3?

[Chris]

five-or-six-item
list of what makes up the suite.

Given the shape of the documents, and even assuming that documentation
is the first thing that falls short in commercial time-pressed
development, I find that messy.

There is certainly a LOT of work to do, work out processes to get
documentation consistent with the code releases, then actually do that.


- PERSONAL CONCLUSION AND OUTLOOK

This is a subjective and personal note of someone who has not read a
single line of Mailman 3 implementation, but only its documentation
that's accessible from web sites and several one-or-two clicks deep
hyperlink chains, but is asked again and again (as mailman 2 maintainer)
about mailman 3.

I have shown how I feel that the documentation is untidy, inconsistent,
and partially unmaintained on sites that are linked from list.org.

I have shown how I personally do not trust that mailman 3 is
feature-complete when looking at the mailman 2.x feature set.


So assuming we've had a port, what calms a potential porter's or
maintainer's mind that he's not going to be drowned in user support?

Personlly I fear that a port would bring with it lots of people getting
tripped up by the inconsistent web sites, and it would probably add more
support work than the sum of all other ports I am currently listed
MAINTAINER for.

So I don't want to play a *major* role in the porting, feel free to ask
me here or there, and I will not become maintainer now.

If Python 3.x were not a rather important argument, I would have written
a polite form of "leave me alone with that immature stuff and would have
moved on.

- FINAL QUESTIONS

Leaving Python 3.x compatibility aside, what good arguments can anyone
weigh in for Mailman 3.x who is using it in practice (f.i. on Linux)?

How is it better?

Is it mature?

Would it be plausible to port Tauthon 2.8.2 (I am not doing that) and
continue using mailman2 on it (I might help with this part)?
<https://github.com/naftaliharris/tauthon>


In sentiment I am inline with your thoughts as well.
Would it be a worthy project to create a mailman(2)-lts port?
I'd be fully up for helping, and or creating it myself.
There's a port that's a shim for py2.x-->py3.x called 2to3, or something
like that. It also wouldn't be that difficult to simply modify mailman(2)
to adopt the py3.x language changes.

My 3¢ for what they're worth. :)

--Chris


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

Re: mail/mailman v3?

[Chris]

On Thu, 30 Apr 2020 02:03:20 +0200 Matthias Andree matthias.and...@gmx.de said


Am 28.04.20 um 22:02 schrieb Chris:
> In sentiment I am inline with your thoughts as well.
> Would it be a worthy project to create a mailman(2)-lts port?
> I'd be fully up for helping, and or creating it myself.
> There's a port that's a shim for py2.x-->py3.x called 2to3, or something
> like that. It also wouldn't be that difficult to simply modify mailman(2)
> to adopt the py3.x language changes. 


Given that Mailman is mainly a text processing machine with various
heads (mail, web and CGI, command line) interfaces, and one of the ideas
driving the incompatible Python 3 was to clean up the delineation of the
strings/bytes/unicode types from one another and see to encoding. we'd
be in for lots of - ironically speaking - "fun" - meaning code audits,
revisions, possibly explicit code to write for the front lines to
properly decode external input and encode internal output.

The string stuff is the challenge (in python), and having just taken a
closer look, 3.x makes some changes in this area as well. Which only makes
the same challenges _different_. :(


I haven't looked into too much detail, but attaining 100% conversion and
test coverage would be a challenge and possibly a major undertaking.

I'd assume had it been as simple as 2to3 or py-futurize or adopting
py-six, someone might have done that already.

After looking closer, I'm inclined to say the (work) load appears close
to the same. Only the tasks have changed.

I really like Perl a lot more for all this string/byte handling stuff.
Maybe Majordomo? B-}

--Chris


___
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: Wrong Ports-OSVERSION in jails

[Chris]

On Fri, 1 May 2020 12:40:20 +0200 Jochen Neumeister jon...@freebsd.org said


Hi all,

i installed a new FreeBSD 12.1 amd64.
As next, i Install a new Jail with "bsdinstall jail /jails/jail1-www" 
and update the jail with "freebsd-update -b /jails/jail1-www fetch install".


I mount the Ports-tree into the jail with a /etc/fstab.jail1-www:

   /usr/ports  /jails/jail1-www/usr/ports  nullfs  ro
0   0

Here the entry in jail.conf:

   jail1-www {
  host.hostname = "jail1-www.local";
  path = /jails/jail1-www;
  ip4.addr = "192.168.2.31";
  mount.fstab="/etc/fstab.jail1-www";
   }

Your jail(8) client (jail) will adopt your host' OS version(s).
You have some control over that withing your jail.conf(5):

# uname -r, freebsd-version
#osrelease = 12.0-CURRENT;
# /usr/obj/usr/src/include/osreldate -- uname -K, uname -U
# /usr/src/sys/sys/param.h
#osreldate = 1200054;
(from comments I keep in my jail.conf)

The only area I run into is ensuring that my uname -r is
in sync with my uname -(K|U). Especially where older jails
are involved, and -CURRENT went to (RELEASE|STABLE)
Here are some links for 12 that might help:
https://www.freebsd.org/doc/en/books/porters-handbook/versions-12.html
just change versions-12 to versions-13 for 13*
Annoying, isn't it? :-)

HTH

--Chris



When i connect into the jail, the Tree is available and ready to use 
with this entry in /etc/make.conf:


   KDIRPREFIX=/tmp
   DISTDIR=/tmp/distfiles
   PACKAGES=/tmp/packages

When i will, as example, install nginx:

   root@jail1-www:/usr/ports/www/nginx # make install clean
   make: "/usr/ports/Mk/bsd.port.mk" line 1204: UNAME_r
   (12.1-RELEASE-p3) and OSVERSION (1101001) do not agree on major
   version number.

   root@jail1-www:/usr/ports/www/nginx # uname -a
   FreeBSD jail1-www.local 12.1-RELEASE-p3 FreeBSD 12.1-RELEASE-p3
   GENERIC  amd64
   root@jail1-www:/usr/ports/www/nginx # make -C /usr/ports/ -V OSVERSION
   make[1]: "/usr/ports/Mk/bsd.port.mk" line 1204: UNAME_r
   (12.1-RELEASE-p3) and OSVERSION (1101001) do not agree on major
   version number.
   make: "/usr/ports/Mk/bsd.port.subdir.mk" line 117: warning: "make -V
   _JAVA_VERSION_LIST_REGEXP USE_JAVA=1 -f /usr/ports/Mk/bsd.port.mk"
   returned non-zero status
   make[1]: "/usr/ports/Mk/bsd.port.mk" line 1204: UNAME_r
   (12.1-RELEASE-p3) and OSVERSION (1101001) do not agree on major
   version number.
   make: "/usr/ports/Mk/bsd.port.subdir.mk" line 122: warning: "make -V
   _JAVA_VENDOR_LIST_REGEXP USE_JAVA=1 -f /usr/ports/Mk/bsd.port.mk"
   returned non-zero status
   make[1]: "/usr/ports/Mk/bsd.port.mk" line 1204: UNAME_r
   (12.1-RELEASE-p3) and OSVERSION (1101001) do not agree on major
   version number.
   make: "/usr/ports/Mk/bsd.port.subdir.mk" line 127: warning: "make -V
   _JAVA_OS_LIST_REGEXP USE_JAVA=1 -f /usr/ports/Mk/bsd.port.mk"
   returned non-zero status
   make[1]: "/usr/ports/Mk/bsd.port.mk" line 1204: UNAME_r
   (12.1-RELEASE-p3) and OSVERSION (1101001) do not agree on major
   version number.
   make: "/usr/ports/Mk/bsd.port.subdir.mk" line 132: warning: "make -V
   _JAVA_PORTS_INSTALLED USE_JAVA=1 -f /usr/ports/Mk/bsd.port.mk"
   returned non-zero status
   1101001

Here the output from the Mainsystem:

root@server-01:/etc # uname -a
FreeBSD server-01.home. 12.1-RELEASE-p3 FreeBSD 12.1-RELEASE-p3 
GENERIC  amd64

root@server-01:/etc # make -C /usr/ports/ -V OSVERSION
1201000

I delete the portstree and check i out again with svn, but the same

Any tipps to fix this?

Jochen

___
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: Poudriere - Compile ALL Ports

[Chris]

On Tue, 5 May 2020 22:38:36 +0200 Leander Schaefer i...@netocean.de said


Hello,

I have been dealing with Poudriere for quite a while and one of the most 
issues I have is, that I have ports which won't compile along with 
another. Reason is mostly something like:


pkg-static: ImageMagick7-7.0.10.6 conflicts with ImageMagick6-6.9.11.6,1 
(installs files into the same place). Problematic file: 
/usr/local/bin/Magick++-config


So in other words a newer version is going to place its binaries etc. 
into the same place as the previous version. I have read and used 
something like:


# Build several PHP versions parallel on the same server:
# https://github.com/freebsd/poudriere/issues/602
PHP_ALT=php56 php70 php71 php72 php73
.for port in ${PHP_ALT}
.if ${.CURDIR:M*/ports*/*/${port}*}
DISABLE_CONFLICTS=YES
PREFIX=/usr/local/${port}
PHPBASE=/usr/local/${port}
LOCALBASE=/usr/local
CONFIGURE_ARGS+=--datadir=/usr/local/${port}/share
CONFIGURE_ARGS+=--bindir=/usr/local/${port}/bin
CONFIGURE_ARGS+=--with-config-file-scan-dir=/usr/local/${port}/etc/php
#CONFIGURE_ARGS+=--with-php-config=/usr/local/${port}/bin/php.conf
#CONFIGURE_ARGS+=--with-iconv=/usr/local
#CONFIGURE_ARGS+=--with-pcre-dir=/usr/local
.endif
.endfor

But I was wondering: How is the FreeBSD Team dealing with this, when 
they compile their packages for the public repository? Because we only 
use one official repository and all packages are there ... some even 
with differet options enabled. So how to deal with this? How can I 
compile the entire ports tree without issues and build a repository of 
it and some packages even with different options? Lets say one OpenLDAP 
with SASL and another one with SASL? The only way I was able to do this 
was building it in separate repositories.


Thanks

I use Jails which helps weed out some of the conflicts. That is different
jails for different (port) options that *may* cause conflict. Also
ports-mgmt/synth is pretty damn clever about sorting out conflicts.
However, I have no direct knowledge on how the pkg build admins deal with
this. But just thought I'd share some alternate avenue(s) FWIW. :-)



___
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: Poudriere - Compile ALL Ports

[Chris]

On Thu, 7 May 2020 20:39:41 +0200 Leander Schaefer i...@netocean.de said


Hello Chris,

Hello List,

I have checked out ports-mgmt/synth unfortunately it would be a massive 
downgrade compared to poudriere. Does anyone have the right clue about 
how the FreeBSD package managment team provides a complete repository 
without having these conflicts? There must be a way to do this with 
poudriere since I am most certainly sure they also use poudriere.


Also is there a way to tell poudriere to give a package a different / 
individual name. E.g. I want to compile openldap one time with SASL and 
another time without SASL and place them in the same repository. The 
package naming could/should then be something like this:


OK I don't use poudriere, or any of the other "convenience" toys. They
introduce too many additional variables, which can easily lead to
unintended results.
With that in mind. I use jail(8). It provides a "clean room" with no
more than what a base system, and the ports(7) framework has to provide.
All the questions you've asked so far, are well covered in ports(7).
Conflicting "depends"? Run make all-depends-list some-port, followed by
make all-depends-list some-other-port. Then compare the results. Want
to make a package repo?
myjail.jail # mkdir -p /usr/port/packages/All
myjail.jail # mkdir -p /usr/port/packages/Latest
myjail.jail # cd /usr/ports/ports-mgmt/pkg
myjail.jail # make package install clean
myjail.jail # cd /usr/port/x11/xorg
myjail.jail # make package-recursive

My point is. There *shouldn't* be that much controversy building
ports that build, and install harmoniously. That's the way the
ports/pkg system was designed. The fact that you're running into
so much controversy, seems to indicate you have a "tainted"
environment -- built/installed several ports from source, followed
by installing some by way of pkg(8). Using that procedure is a
crap-shoot -- a gamble, that will ultimately lead to failure.
It's really hard to say what, and where things went wrong. It's
not my computer. But I would strongly suggest building a jail,
and using it to create a package-repo. You'll have a clean
environment to create packages that are guaranteed to work
together on your system. Take a good look at the ports(7) man
page for all the possibilities. The jail(8) man page also
deserves a good read. It's trivial to create a jail, and it's
not at all resource hungry -- I've got 7 jails running on a 3
core AMD box w/8G ram on it. It also runs www, and mail. While
that's not my build server. It does illustrate how light-weight
jails are/can be.

HTH

--Chris


- openldap-sasl

- openldap

Thanks

Am 05.05.20 um 23:06 schrieb Leander Schaefer:
> Hello Chris,
>
>
> thanks for your reply. Thanks for the hint about ports-mgmt/synth. I 
> am definitly going to have a look into this! Well, my Podriere is 
> using Jails by default. Is there any hack you applied for this issue 
> to avoid?

>
>
> Best regards,
>
> Leander
>
>
> Am 05.05.20 um 22:46 schrieb Chris:
>> On Tue, 5 May 2020 22:38:36 +0200 Leander Schaefer i...@netocean.de said
>>
>>> Hello,
>>>
>>> I have been dealing with Poudriere for quite a while and one of the 
>>> most issues I have is, that I have ports which won't compile along 
>>> with another. Reason is mostly something like:

>>>
>>> pkg-static: ImageMagick7-7.0.10.6 conflicts with 
>>> ImageMagick6-6.9.11.6,1 (installs files into the same place). 
>>> Problematic file: /usr/local/bin/Magick++-config

>>>
>>> So in other words a newer version is going to place its binaries 
>>> etc. into the same place as the previous version. I have read and 
>>> used something like:

>>>
>>> # Build several PHP versions parallel on the same server:
>>> # https://github.com/freebsd/poudriere/issues/602
>>> PHP_ALT=php56 php70 php71 php72 php73
>>> .for port in ${PHP_ALT}
>>> .if ${.CURDIR:M*/ports*/*/${port}*}
>>> DISABLE_CONFLICTS=YES
>>> PREFIX=/usr/local/${port}
>>> PHPBASE=/usr/local/${port}
>>> LOCALBASE=/usr/local
>>> CONFIGURE_ARGS+=--datadir=/usr/local/${port}/share
>>> CONFIGURE_ARGS+=--bindir=/usr/local/${port}/bin
>>> CONFIGURE_ARGS+=--with-config-file-scan-dir=/usr/local/${port}/etc/php
>>> #CONFIGURE_ARGS+=--with-php-config=/usr/local/${port}/bin/php.conf
>>> #CONFIGURE_ARGS+=--with-iconv=/usr/local
>>> #CONFIGURE_ARGS+=--with-pcre-dir=/usr/local
>>> .endif
>>> .endfor
>>>
>>> But I was wondering: How is the FreeBSD Team dealing with this, when 
>>> they compile their packages for the public repository? Because we 
>>> on

Re: Are broken ports retested before performing scheduled removal?

[Chris]

On Wed, 13 May 2020 16:24:17 -0700 Edward Sanford Sutton, III 
mirror...@hotmail.com said


games/oneko was recently removed as it was marked broken due to being
unfetchable. I tried an old copy of the ports tree I had where it was
marked as such and `make fetch -DTRYBROKEN` succeeded. Was there an
error recorded for this and was it ever retested? Is this just a side
effect of having a failure and no maintainer?
 If being removed as unfetchable, wouldn't a better MOVED entry be to
say it was unfetchable (for more than 6 months) instead of just broken
for more than 6 months?
Thanks for feedback

I just made an attempt with
make -DBATCH fetch
This was the output I recieved
===>   oneko-2.0b_5 depends on file: /usr/local/sbin/pkg - found
=> oneko-2.0b.tar.gz doesn't seem to exist in /usr/ports/distfiles/oneko.
=> Attempting to fetch http://www.3bit.co.jp/~sasaki/oneko/oneko-2.0b.tar.gz
oneko-2.0b.tar.gz 100% of   84 kB  111 kBps 00m00s
=> oneko-2.0b-pop1.1-patch.tar.gz doesn't seem to exist in 
/usr/ports/distfiles/oneko.
=> Attempting to fetch 
http://www.3bit.co.jp/~sasaki/oneko/oneko-2.0b-pop1.1-patch.tar.gz
oneko-2.0b-pop1.1-patch.tar.gz100% of   17 kB   50 kBps 00m00s
=> oneko-2.0b-tip1.7.tar.gz doesn't seem to exist in /usr/ports/distfiles/oneko.
=> Attempting to fetch 
http://www.net24.ne.jp/~ryo2/archives/oneko-2.0b-tip1.7.tar.gz
fetch: http://www.net24.ne.jp/~ryo2/archives/oneko-2.0b-tip1.7.tar.gz: Not Found
=> Attempting to fetch 
http://distcache.FreeBSD.org/ports-distfiles/oneko/oneko-2.0b-tip1.7.tar.gz
oneko-2.0b-tip1.7.tar.gz  100% of   62 kB 1719 kBps 00m00s
=> oneko-2.0b-sender0.5.tar.gz doesn't seem to exist in 
/usr/ports/distfiles/oneko.
=> Attempting to fetch 
http://www2u.biglobe.ne.jp/~hsaka/distfiles/oneko-2.0b-sender0.5.tar.gz
oneko-2.0b-sender0.5.tar.gz   100% of   41 kB  154 kBps 00m00s
=> oneko-2.0b-bsd0.2.tar.gz doesn't seem to exist in /usr/ports/distfiles/oneko.
=> Attempting to fetch 
http://www2u.biglobe.ne.jp/~hsaka/distfiles/oneko-2.0b-bsd0.2.tar.gz
oneko-2.0b-bsd0.2.tar.gz  100% of   21 kB  159 kBps 00m00s
===> Fetching all distfiles required by oneko-2.0b_5 for building

As you can see, oneko-2.0b-tip1.7.tar.gz failed, and required freebsd's 
discache.
All the rest of them worked. :-)

--Chris


___
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: Conflict on very first port (xorg) on rpi3

[Chris]

On Fri, 15 May 2020 11:05:54 -0700 bob prohaska f...@www.zefox.net said


On Fri, May 15, 2020 at 01:49:21PM -0300, Danilo G. Baio wrote:
> On Fri, May 15, 2020 at 08:19:22AM -0700, bob prohaska wrote:
> > On Fri, May 15, 2020 at 12:33:10AM -0700, Mark Millard via freebsd-ports
> wrote:
> > > 
> > > Some building and isntalling had to occur prior to the

> > > textproc/py-sphinx18 build attempt, possibly from
> > > prior session(s) of building and installing.
> > > 
> > > 
> > 
> > In this case x11/xorg was the first port attempted in a new

> > ports tree. The only "prior sessions" would have been within
> > the dependencies of x11/xorg. Is that resolvable by poudriere?
> > 
> > > textproc/py-sphinx18 is new as of 2020-May-11.

> > > The devel/llvm[16789]0 ports require textproc/py-sphinx18 .
> > > Only about 26 ports require textproc/py-sphinx18 but
> > > I'll not list the others.
> > > 
> > > textproc/py-sphinx has been around longer and has

> > > 142 ports that require it. I'll not list them.
> > > 
> > > 
> > > textproc/py-sphinx18/Makefile lists:
> > > 
> > > CONFLICTS_INSTALL=  py*-sphinx
> > > 
> > > textproc/py-sphinx/Makefile lists:
> > > 
> > > CONFLICTS_INSTALL=  py*-sphinx18
> > > 
> > > 
> > > So, for example, indirectly the devel/llvm[16789]0

> > > ports conflict with at least 142 other ports because
> > > of the textproc/py-sphinx* difference in requirements.
> > > 
> > > 
> > > The conflict is real and limits what combinations

> > > of ports you may have installed at the same time.
> > 
> > I'll try deinstalling the conflicting port and hope

> > it won't be required later
> 
> It seems that just devel/llvm80 is pulling sphinx18 when building

> x11/xorg.
> 
> Try disabling DOCS option on devel/llvm80 for now.
> 
> I've opened a PR to track this issue:

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


Wish I'd known it was only the DOCS option! Too late now,
sphinx18 is deinstalled and llvm80 is building.

This is probably a dumb question, but is there some way
to learn at the outset what conflicts need to be worked
around? Something like a "make conflicts" target? Seemingly 
it could be done by hand, but that promises to be tedious.

I think
run-depends-list, build-depends-list, or all-depends-list
should give you what you seek. :-)

--Chris


At best 8-)

Thanks for writing!

bob prohaska

___
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: Gratuitous port splitting (was: Port Avidemux)

[Chris]

On Sun, 24 May 2020 09:56:39 -0700 Freddie Cash fjwc...@gmail.com said


Perhaps the avidemux port should be renamed to avidemux-libs, and then a
new avidemux meta-port could be created with basically just an OPTIONS
screen where your pick which parts you want installed?

+1 for that.
I was going to propose making a meta-port called "avidemux" with options
that pull only what's required to create a functional port. But decided
to wait till I got through all my mail first, in case someone as (at least)
as smart as I am beat me to the proposal. ;-)

--Chris


Cheers,
Freddie

Typos due to smartphone keyboard.
___
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: Porting Practice

[Chris]

On Sun, 5 Jul 2020 00:46:39 + Brandon helsley brandon.hels...@hotmail.com 
said


I have gotten a couple of emails from portscout about ports that need updated
and maintained. Before I go about updating and maintaining these ports I
wanted to do some practice on a couple that I use like x11/nvidia-settings. I
have recieved alot of help on the forums and from the documentation, but i'm
still at a loss as to how the diff process works. Also, i've gotten stuck at
a few spots along the way. I use svn to checkout a copy of the
nvidia-settings port which has no maintainer. The copy goes into my root
directory either in a work directory or not. After I make the changes to the
files and issue the command...

MAKE CONFIG:root@machine17:/usr/ports/x11/nvidia-settings # make config
===> No options to configure

make patch and make configure both work.

PORTLINT:root@machine17:/usr/ports/x11/nvidia-settings # portlint
WARN: Makefile: Consider adding support for a NLS knob to conditionally
disable gettext support.
0 fatal errors and 1 warning found.

So once I get past this point and have succesfully tested the port with
portlint and poudriere testport, I'm confused as to how I am supposed to
build the package, and create a suitable diff to patch the port either with
svn or diff -u.

FWIW this is my basic workflow

svn co --depth empty svn://svn.freebsd.org/ports/head DEV
svn up --set-depth empty DEV/x11
svn up DEV/x11/nvidia-settings

edit edit edit

make -DBATCH check-plist
make stage-qa
make check-sanity
portlint

all systems are a go

cd DEV/x11

svn diff --ignore-properties > x11_nvidia-settings.diff

open Bugzilla, and attach this svn(1) diff(1)

If nothing else, this will (hopefully) give you a scope of
the overall process tweaking/fixing/adopting a port :-)

HTH!

--Chris




The documentation for (diff -u) says "To create a suitable diff for a single
patch, copy the file that needs patching to something.orig, save the changes
to something and then create the patch:"
% diff -u something.orig something > something.diff

Im not sure really the meaning of this documentation. What file needs
patching, which file to copy, where to save changes to exactly, and how and
why the svn method is different. Which method should I choose? I know it says
that unified diff and svn are preffered but since I am new maybe the (diff
-u) command would be easier to begin with? Please help and include anything
that's relevant even if i didn't mention it. I'm really excited to get
started and will absorb like a sponge any know how that's offered!!!

One last thing. I have not attempted a poudriere testport today but for the
last ten or so times I have tried, my computer shuts down after a few minutes
of testing. Is this a overheating or is it some kind of another problem?
___
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: Porting Practice

[Chris]

On Sun, 5 Jul 2020 13:07:53 +1200 Jonathan Chen j...@chen.org.nz said


On Sun, 5 Jul 2020 at 12:47, Brandon helsley
 wrote:
>
> I have gotten a couple of emails from portscout about ports that need updated
> and maintained. Before I go about updating and maintaining these ports I 
wanted
> to do some practice on a couple that I use like x11/nvidia-settings. I have
> recieved alot of help on the forums and from the documentation, but i'm still
> at a loss as to how the diff process works.
[...]

This is my personal workflow:
1. Take a simple copy of the port into my working directory
2. Get the port working in my working directory.
3. cd my-working-directory
4. diff -ruN /usr/ports/x11/nvidia-settings . > /tmp/nvidia-settings.patch

I believe that "svn diff" is the preferred method for generating patches.

5. submit patch onto bugs.freebsd.org

Hope that helps.
--
Jonathan Chen 
___
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: Gracefully killing and restarting a port build....

[Chris]

On Tue, 7 Jul 2020 20:47:03 -0700 bob prohaska f...@www.zefox.net said


While compiling www/chromium on a Pi3B it has become clear that the
default -j4 isn't going to work (yes, I know, ya told me). 


On the plus side, it hasn't crashed, despite several days of
continuous swapping  with 1-2GB of swap in use. Kudos to the
VM folks.

Now I'd like to (gracefully) stop the make and restart it with more 
sane -j values. -2 seems like a reasonable start. 

A simple 
kill  aimed at the original make doesn't seem to do anything. Even 
kill -9  appears to have no effect on the c++ threads, which are
still running minutes afterwards. 

Now it seems rather like I'm stuck: The original  is gone, but 
c++ is still grinding away as if nothing has changed.. 


Is there a better way to accomplish a clean(ish) stop and restart of
a multi-threaded make process?

Thanks for reading, apologies if it's a dumb question,

Not at all. :-)
I usually leverage multiple terminals, and simply dedicate one to
the/a build session. So simply issuing a ^C to that terminal sends
an INTR to the parent, and children. I've experienced no problems
restarting the process (build) after doing so.

HTH! :-)

--Chris


bob prohaska



___
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: Gracefully killing and restarting a port build....

[Chris]

On Wed, 8 Jul 2020 08:30:13 -0700 bob prohaska f...@www.zefox.net said


On Wed, Jul 08, 2020 at 10:44:03AM +0200, Ronald Klop wrote:
> 
> 
> Kill the leaf nodes of the process tree. So kill the c++ processes. Or type

> ctrl-c if you have control of the terminal.

In this case I'd lost control of the controlling terminal and didn't 
know how to recover it.  After kill -9  of the initial make process 
I left the system standing overnight, to see if killing the original make 
process would eventually propagate down to the leaf nodes. It didn't. 


Then I used killall c++, and again, it killed the named processes, but other
things,
notably pkg, kept running. After waiting a few minutes they were killall-ed.
A notation from ninja eventually showed up in the logfile saying
"interrupted
by user", so maybe ninja was the place to start shutting things down.

> If you are running the compile in a jail (like poudriere) you might use
> "killall -j  c++" or something similar.

No room for a jail on a Pi, alas
> Pkill can be usable also.
Thank you, I didn't know about it.
> BTW: How graceful a restart works is outside of the scope of the ports
> framework and depends a lot on the structure of the chromium build process
> itself.
>
Understood. This is the first time I've ever needed to kill a port build.
Usually they die prematurely of natural causes!

FWIW should you need to attempt such a strategy again. You'll want to add
sh (/bin/sh) to the list of potential "victims" in your kill list. :-)

--Chris


Thanks for your help

bob prohaska

___
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: [HEADS UP] Planned deprecation of portsnap

[Chris]

On Tue, 4 Aug 2020 14:43:20 -0400 Steve Wills swi...@freebsd.org said


We are planning to deprecate use of portsnap in ports.


...
Makes sense to me. Thank you. :-)


* Portsnap doesn't seem to save disk space compared to svn or git, if 
you count the metadata (stored in /var/db/portsnap by default) and you 
do an apples-to-apples comparison of svn or git without history and 
ignoring possible ZFS compression. That is, you use "svn export" or git 
"clone --depth 1", you see this disk usage:


342Msvnexport
426Mgit
477Mportsnap

* Portsnap also doesn't work offline which git does. With git, you can 
also easily add the history by running "git pull --unshallow"


* This migration away from portsnap fits well with the planned migration 
to git.



Please tell me that this doesn't mean a

[HEADS UP] Planned deprecation of subversion

is on the horizon.

--Chris


___
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: [HEADS UP] Planned deprecation of portsnap

[Chris]

On Wed, 5 Aug 2020 06:40:39 +0200 Kurt Jaeger p...@freebsd.org said


Hi!

> > * This migration away from portsnap fits well with the planned
> > migration to git.

> Please tell me that this doesn't mean a
> 
> [HEADS UP] Planned deprecation of subversion
> 
> is on the horizon.


There's a list where the git topic is discussed:

https://lists.freebsd.org/pipermail/freebsd-git/

Have a look at the archive, and yes, subversion as version control
system for the FreeBSD project will probably be replaced by git.

Thank you very much for taking the time to respond, Kurt! :-)

This is very bad news for us. I can make so many arguments against
dropping subversion. It's really not (needn't be) a matter of either/or.

Thanks again, Kurt. Even if it wasn't what I wanted to hear.

--Chris


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

ln -s python3 python2 && ln -s python37 python27?

[Chris]

I'm currently performing a big buildup for a large deployment.
I built world && kernel in the build jail, and performed the
install into another jail for the port/package buildup that
will in turn be used for the deployment STABLE-12@363918 &&
PORTS@544342, respectively.
Problem _appears_ to be with Python as maintained in the ports
tree. make.conf(5) defines only:
DEFAULT_VERSIONS+=python=3.7 python3=3.7
performing a make config-recursive in xorg-server/ until dialogs
no longer appear. Followed by a make package-recursive install clean
goes as anticipated, building python-3.7 && py-37 additions, llvm,
...
But towards the end I'm greeted by a large python2.7 session with
all the expected warnings about EOL and installing to the same
place.
Can I simply avoid all this BS by deleting python2.7 and family,
and simply link all references to python3.7. This is quite maddening.
There must be a way out. No?

Thank you in advance for any, and all clues to salvation! :-)

--Chris


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

Make install fails for mail/thunderbird

[Chris]

Hello,

I'm seeing this when doing a "make install" on mail/thunderbird (version
24):

resource://gre/modules/devtools/Console.jsm
resource://gre/modules/devtools/WebConsoleClient.jsm
resource://gre/modules/devtools/dbg-server.jsm
Traceback (most recent call last):
  File
"/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/toolkit/mozapps/installer/packager.py",
line 375, in 
main()
  File
"/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/toolkit/mozapps/installer/packager.py",
line 367, in main
args.source, gre_path, base)
  File
"/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/toolkit/mozapps/installer/packager.py",
line 148, in precompile_cache
errors.fatal('Error while running startup cache precompilation')
  File
"/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/python/mozbuild/mozpack/errors.py",
line 101, in fatal
self._handle(self.FATAL, msg)
  File
"/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/python/mozbuild/mozpack/errors.py",
line 96, in _handle
raise ErrorMessage(msg)
mozpack.errors.ErrorMessage: Error: Error while running startup cache
precompilation
gmake[2]: *** [stage-package] Error 1
gmake[2]: Leaving directory
`/usr/ports/mail/thunderbird/work/comm-esr24/obj-x86_64-unknown-freebsd8.4/mail/installer'
gmake[1]: *** [install] Error 2
gmake[1]: Leaving directory
`/usr/ports/mail/thunderbird/work/comm-esr24/obj-x86_64-unknown-freebsd8.4'
gmake: *** [install] Error 2
*** Error code 2

Stop in /usr/ports/mail/thunderbird.
*** Error code 1

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

multimedia/phonon build fails

[Chris]

Seeing this when I try to build:

Generating moc_statesvalidator_p.cpp
[  3%] Built target phonon_automoc
Scanning dependencies of target phonon
make: don't know how to make /usr/local/lib/qt4/libQtDeclarative.so. Stop
*** Error code 2
1 error
*** Error code 2
1 error
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop in /usr/ports/multimedia/phonon.
*** Error code 1

Stop in /usr/ports/multimedia/phonon.

This is on a FreeBSD 8.x machine. Any help would be appreciated!
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Upcoming OpenSSL 1.1.0 release

[Chris]

Hi

I am excited about opensl 1.1 but I am not sure if it is right to just
jump the security/openssl port to it, maybe make a new
security/openssl11 port?

Or move the default port but add a new security/openssl10 port for 1.0.2.

Chris

On 22 August 2016 at 19:39, Mathieu Arnold  wrote:
> ports-committers is a *NEVER POST DIRECTLY TO* list, so, moving it to
> ports@ where this belongs a lot more.
>
> +--On 22 août 2016 20:30:15 +0200 Bernard Spil  wrote:
> | Curious to know how we should procede with the upgrade of the OpenSSL
> | port to 1.1.0!
>
> All ports need to work with it, I'm sure software like BIND9 do not build
> with it.
>
> --
> Mathieu Arnold
___
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: Upcoming OpenSSL 1.1.0 release

[Chris]

Dirk, it wont be as messy as the havoc it can cause on production
machines.  There is several ports which have multiple versions without
a mess, I do not see wh openssl would be any different as the version
used can be put in the make.conf.

I just had a quick glance at the 1.2 changelog, and it will be a bad
idea to put this in ports replacing 1.0.2, 1.0.2 is a LTS release and
in addition 1.1.10 disables RC4 and 3des, whilst those ciphers are old
there is legitimate reasons for sysadmins to support use of those
ciphers for a while longer.

Remember we dont all run FreeBSD as a hobby some of use this in
production where we are responsible for making sure things work in a
commercial environment.  Decisions have to be done carefully with this
in mind.

Also 1.1.0 is not fully backwards compatible with 1.0.x meaning
everything compiled against it has to be recompiled, which was not the
case when moving upwards on minor version revisions, it seems not much
thought has been put into these gotcha's as I seen a upgrade was
attempted only yesterday.

So I stress again, openssl needs two seperate ports, one for 1.1.x and
another for 1.0.x.

On 23 August 2016 at 12:09, Dirk Meyer  wrote:
>
>
>> I am excited about opensl 1.1 but I am not sure if it is right to just
>> jump the security/openssl port to it, maybe make a new
>> security/openssl11 port?
>>
>> Or move the default port but add a new security/openssl10 port for 1.0.2.
>
> this would only increase the mess we have,
> and create only more conflicts between libssl.so versions.
>
> We have done this for openssl 0.9x before, not with good results.
>
> 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: Upcoming OpenSSL 1.1.0 release

[Chris]

On 22 August 2016 at 19:39, Mathieu Arnold  wrote:
> ports-committers is a *NEVER POST DIRECTLY TO* list, so, moving it to
> ports@ where this belongs a lot more.
>
> +--On 22 août 2016 20:30:15 +0200 Bernard Spil  wrote:
> | Curious to know how we should procede with the upgrade of the OpenSSL
> | port to 1.1.0!
>
> All ports need to work with it, I'm sure software like BIND9 do not build
> with it.
>
> --
> Mathieu Arnold
complete chaos on my lan box with openssl-devel port (1.1.0) os 10.3

failed ports on complilation

openssh-portable - missing evp function nmap - missing md4 function
libssh2 - missing evp function wget - missing evp function
proftpd - missing evp function ruby - missing evp function
net-snmp - missing evp function python27 - compiles but then make
install fails missing hashlib and ssl.sl files
libarchive - archive_libcryptor linker error
apr1 - missing evp function
serf - bio bucket read function missing
openvpn - ctx error
libevent - missing bio_buffervent
nghttp2 (this and rest stopped looking for error type)
apache24
curl

sucessful ports

exim
spdylay
___
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: Upcoming OpenSSL 1.1.0 release

[Chris]

On 22 August 2016 at 19:39, Mathieu Arnold  wrote:
> ports-committers is a *NEVER POST DIRECTLY TO* list, so, moving it to
> ports@ where this belongs a lot more.
>
> +--On 22 août 2016 20:30:15 +0200 Bernard Spil  wrote:
> | Curious to know how we should procede with the upgrade of the OpenSSL
> | port to 1.1.0!
>
> All ports need to work with it, I'm sure software like BIND9 do not build
> with it.
>
> --
> Mathieu Arnold
repost with fixed formatting

complete chaos on my lan box with openssl-devel port (1.1.0) os 10.3

failed ports on complilation

openssh-portable - missing evp function
nmap - missing md4 function
libssh2 - missing evp function
wget - missing evp function
proftpd - missing evp function
ruby - missing evp function
net-snmp - missing evp function
python27 - compiles but then make install fails missing hashlib and ssl.sl files
libarchive - archive_libcryptor linker error
apr1 - missing evp function
serf - bio bucket read function missing
openvpn - ctx error
libevent - missing bio_buffervent
nghttp2 (this and rest stopped looking for error type)
apache24
curl

successful ports

exim
spdylay
___
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: Upcoming OpenSSL 1.1.0 release

[Chris]

On 29 August 2016 at 18:34, Bernard Spil  wrote:
> Thanks Chris! Added these (and reasons) to wiki.freebsd.org/OpenSSL/1.1.0
>
> On Mon, Aug 29, 2016 at 2:24 PM, Chris  wrote:
>> On 22 August 2016 at 19:39, Mathieu Arnold  wrote:
>>> ports-committers is a *NEVER POST DIRECTLY TO* list, so, moving it to
>>> ports@ where this belongs a lot more.
>>>
>>> +--On 22 août 2016 20:30:15 +0200 Bernard Spil  wrote:
>>> | Curious to know how we should procede with the upgrade of the OpenSSL
>>> | port to 1.1.0!
>>>
>>> All ports need to work with it, I'm sure software like BIND9 do not build
>>> with it.
>>>
>>> --
>>> Mathieu Arnold
>> repost with fixed formatting
>>
>> complete chaos on my lan box with openssl-devel port (1.1.0) os 10.3
>>
>> failed ports on complilation
>>
>> openssh-portable - missing evp function
>> nmap - missing md4 function
>> libssh2 - missing evp function
>> wget - missing evp function
>> proftpd - missing evp function
>> ruby - missing evp function
>> net-snmp - missing evp function
>> python27 - compiles but then make install fails missing hashlib and ssl.sl 
>> files
>> libarchive - archive_libcryptor linker error
>> apr1 - missing evp function
>> serf - bio bucket read function missing
>> openvpn - ctx error
>> libevent - missing bio_buffervent
>> nghttp2 (this and rest stopped looking for error type)
>> apache24
>> curl
>>
>> successful ports
>>
>> exim
>> spdylay

bernard bind99 fails during configure unable to find openssl shared
files, I tested that later as I had to add the flags to ignore the
vuln check.

I did retry everything after enabling sslv3 knob but it had no affect,
so it seems we need to wait for developers of these apps to update
code to be compatible with 1.1.0.

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: [HEADS UP] Planned deprecation of portsnap

[Chris]

On Mon, 10 Aug 2020 12:11:06 -0400 Robert Huff roberth...@rcn.com said


Michael Gmelin writes:

>  There are many users who never create any patches, but simply use
>  the ports tree to install software.

Add my name to that list.
	(Used to use cvsup ... now subversion ... soon git ... where will 
the insanity end?   :-) )

LOL it *won't*. In about 6mos from now, something shinny will appear
on the horizon
It's a bit like a dog chasing it's tail; it never ends. ;-)

But I don't mind. So long as the svn server can be kept in sync.



Respectfully,


    Robert Huff



--Chris


--

Get it right: _physical_ distancing; _social_ cohesion



___
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 feature request

[Chris]

On Thu, 13 Aug 2020 10:17:34 +0100 Mike Clarke jmc-freeb...@milibyte.co.uk said


On Wednesday, 12 August 2020 05:05:17 BST Tatsuki Makino wrote:

> But it seems to be a mixture of various revisions because poudriere is
> building it.
> svnlite up -q -r COMMITTED $PORTSDIR/category/name seems to be a
> revision of the package when it was built.

What would be needed would be for pkg to provide the revision number of the
ports tree used by 
poudriere at the time of the build, not the revision of each individual port.

For example for 12.1-
RELEASE amd64
http://beefy6.nyi.freebsd.org/jail.html?mastername=121amd64-default[1] shows

that at the time of writing this email the latest completed build is 544349
and there is a build run in 
progress for 544776. If this revision number could be stored as a property of
the repository then 
pkg could have a command (e.g. 'pkg revno') which would currently return
544349. After the 
current build has completed and propagated to the repository then 'pkg revno'
would return 
544776 after the next time I run 'pkg update'.


I'm already using a manual version of this process. If today I needed to
build one of the few ports 
for which I don't use packages I would get the revision number of the latest
poudriere build and run 
'svnlite up -q -r 544349 /usr/ports' to sync my ports tree with the version
used for the repository. 
Providing I allow enough time for the new build to be transferred to the
FreeBSD repository before 
doing this it works fine. It would, of course, be much better if I could
obtain the revision number of 
the repository directly from pkg.


The real icing on the cake would be to have a command 'pkg sync-ports' which
would use the 
revision information to upgrade the ports tree in one go without needing to

manually run svn.

+1
Yes, please. Even if only the src rev the packages were built from. Cobbling
up a script to capture the output of pkg srcrev/revno would be trivial to pass
to svn up/co. :-)



--
Mike Clarke


[1] http://beefy6.nyi.freebsd.org/jail.html?mastername=121amd64-default


--Chris


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

Re: Bind master error on empty.db

[Chris]

On 2020-10-29 04:25, @lbutlr wrote:

Spam detection software, running on the system "mail.covisp.net",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
ad...@covisp.net for details.

Content preview:  When updating bind 9.16 I get: pkg-static: file
'/usr/local/etc/namedb/master/empty.db'
   is missing pkg-static: package creation failed ===>>> Ignore this error 
[i]

   ===>>> Abort update [a] ===>>> Retry [r]

Content analysis details:   (6.1 points, 5.0 required)

 pts rule name  description
 -- 
--

-1.9 BAYES_00   BODY: Bayes spam probability is 0 to 1%
[score: 0.]
 1.5 BODY_8BITS BODY: Body includes 8 consecutive 8-bit 
characters

 3.3 RCVD_IN_PBLRBL: Received via a relay in Spamhaus PBL
[73.14.161.160 listed in zen.spamhaus.org]
 0.0 RCVD_IN_SORBS_DUL  RBL: SORBS: sent directly from dynamic IP
address
[73.14.161.160 listed in dnsbl.sorbs.net]
 1.0 RDNS_DYNAMIC   Delivered to internal network by host with
dynamic-looking rDNS
 0.3 KHOP_HELO_FCRDNS   Relay HELO differs from its IP's reverse DNS
 0.0 HELO_MISC_IP   Looking for more Dynamic IP Relays
 1.9 NO_FM_NAME_IP_HOSTNNo From name + hostname using IP address

BAYES_HT0.000-+--H*Ad:U*freebsd-ports, 0.000-+--grep, 0.000-4--bytes,
0.001-+--H*Ad:D*freebsd.org, 0.002-1--retry, 0.002-+--usr, 0.002-1--sooner,
0.002-1--UD:db, 0.003-+--HTo:D*freebsd.org, 0.003-1--abort, 0.004-+--config,
0.006-+--HTo:U*freebsd-ports, 0.009-+--HTo:D*org, 0.010-+--bind,
0.015-+--H*x:Apple, 0.016-+--H*UA:Apple, 0.037-+--H*Ad:D*org, 
0.041-+--H*ct:plain,

0.048-+--install, 0.049-3--H*m:kreme, 0.049-3--H*F:U*kremels, 0.061-+--file,
0.063-2--H*x:2.3654.0.3.2.82, 0.063-2--H*UA:2.3654.0.3.2.82, 
0.089-1--sample,
0.093-4--ignoring, 0.093-2--H*F:D*kreme.com, 0.116-+--error, 
0.124-1--rushed,

0.126-+--etc
BAYES_ST0.987-1--HX-Envelope-From:sk:kremels



Looks to me that it (empty.db) may not be properly listed in the ports 
pkg-plist file.


As an aside; why the enormous SPAM header?

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

Re: STOP rust!

[Chris]

On 2020-11-12 15:47, Adam Weinberger wrote:

On Thu, Nov 12, 2020 at 2:58 PM Dewayne Geraghty
 wrote:


On 11/11/2020 12:24 am, Rozhuk Ivan wrote:
> Hi all!
>
> With latest ports tree librsvg2-rust-2.50.0 is required to some ports.
> It want replace librsvg2-2.40.21.
>
> I do not want build ugly rust during hours to build small lib in less than 
minute.


Rust is an absolute beast, there's no doubt about it. Rust itself
builds painfully slowly, and then it builds other things painfully
slowly as well. I go through contortions to avoid needing Rust;
building node is frustrating enough. I'm 100% with you that building
Rust is like beating your CPU with a hammer.

Unfortunately for those of us with limited build resources, Rust is
the New Hotness for a reason. Upstreams are switching to it every day,
and more and more libraries and binaries will rely on it. We are going
to have to rip off that band-aid sometime, and the right time to do it
is when upstreams switch to it. When something I need requires Rust,
I'll have to make my peace with it. I strongly urge against the
kludges offered in this thread; much as it sucks to build, I urge you
to make your peace with Rust as a dependency. It will not be the last.
There are many great programs that I eschew because they're written in
Rust; once I make my peace with it, I'll get to use a lot of things
I've been avoiding.

librsvg has switched to Rust, and so the port has no choice but to
switch to it. It's not that we prioritize FreeBSD-provided pkgs over
end-user poudriere, it's simply our obligation to build the current
stable release with the tools they require. Linux-oriented upstreams
(like GNOME) generally expect end-users to install from
distro-provided packages, so they approach the choice of
C/C++/Haskell/Go/Rust as a transparent change. BSDs still celebrate
end-user builds, and the tools to do so are increasingly massive,
disparate, and complex.

It would be really nice if poudriere could keep a list of pkgs that
should be fetched rather than built locally, but that alone is a
nightmare for the solver, I suspect.

The tl;dr here is that I 100% agree that Rust absolutely sucks to
build, and I avoid needing to build Rust, but the ports tree will
always use whatever tools the current stable version requires. librsvg
is now built with Rust, and so we now build librsvg with Rust.

# Adam

Ahem,
Using a 500 ton brake press to bend paper clips is just stupid. While Adam
makes some good points. I'd like to add that Rust is popular for a reason, 
and

can be considered UNpopular for good reason. IOW please inform your vendor
that using a 500 ton brake press to bend paper clips is stupid, and 
unreasonable.
It's a hard point to argue when confronted with the fact that using a 
multi-gig
builder to build a several-k library/program is just impractical, and 
unreasonable.


Thanks for listening. :-)

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

What's the procedure to rename a port?

[Chris]

I maintain a port where the original author is now gone.
I intend to take over maintenance, and make some additions/
improvements.
it's devel/tkcvs -- a GUI for cvs/svn management. But it's
*really* an RCS management utility, and as I am also adding
GIT support. I feel it's name, and as a result, it's potential
popularity. Would better expressed as: tkrcs.
How to proceed, where the ports infrastructure is concerned?

Thanks!

--Chris
___
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: Bug 251656

[Chris]

On 2020-12-08 13:33, Dave Hayes wrote:
Is there a method for getting this assigned? I'll admit I misspelled the 
port

name in the subject, but now how do I fix the process? Thanks in advance.

If you opened the bug. You should have the permission to rewrite the topic
of the bug. So that it's gets assigned, and addressed more promptly. :-)00
FYI
ideally, the topic should have read:

x11-servers/xorg-server: segmentation fault

Seems insignificant. But the colon is significant.

HTH

--Chris
___
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: portmaster new development

[Chris]

On 2020-12-28 05:16, Stefan Esser wrote:
Am 28.12.20 um 11:11 schrieb abi via freebsd-ports:> I build my ports in 
poudriere

in VM without zfs or ssd on pre-Sandy
Bridge CPU. I don't have enough memory or disk space, so I don't use tmpfs 
or ccache either. I migrated from portmaster when it was abandoned several 
years ago and don't think I'll come back, especially if new portmaster will 
be written on bash. The idea behind portmaster was zero dependencies, so it 
doesn't brake after major upgrades.


You are free to use poudriere and it definitely is the official tool
for FreeBSD package building (and I have to use it myself and it has
cost me a lot of time rebuilding broken poudriere jails and keeping
them in state that I can use them to test new ports on a number of
different releases as well as i386 plus amd64).

And while you are free to never again use portmaster, telling people
that it has been abandoned is just a _lie_ and I'd want to ask you to
stop telling it. It has been continuously maintained for decades.

The next version will not be using bash but LUA, which is highly
portable and does not have problematic dependencies. I'm well aware
that a pure shell script has its advantages, but bringing down the
time to scan for updates on my system from 300 to less than 10 seconds
(for > 2000 installed packages) combined with the ability to build
ports in a clean jail might make it an attractive choice for current
users of the /bin/sh based version.


The lovely thing about options, is that *everyone* gets to have one.
The more the merrier! :-)

@Stefan
Really excited to hear about your LUA version of portmaster.
Thanks! :-)

--Chris



Regards, STefan

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

Re: How to fix/patch hardcoded values

[Chris]

On 2020-12-29 00:07, Mathieu Arnold wrote:

On Sun, Dec 27, 2020 at 09:58:13PM +, Nuno Teixeira wrote:

Hello I've just submited a new port net/gitup
 and I used a
simple workaround to help program find its config in /usr/local/etc instead
of (hardcoded) ./

--- gitup.c.orig 2020-12-27 21:16:22 UTC
+++ gitup.c
@@ -2030,7 +2030,7 @@ main(int argc, char **argv)
...
- const char *configuration_file = "./gitup.conf";
+ const char *configuration_file = "/usr/local/etc/gitup.conf";

Now I'm thinking that this might not be the best fix in case PREFIX is a
different one.

Could I have an opinion on this?


You need to change the patch to use %%PREFIX%% or %%LOCALBASE%%
depending on whether this is a reference to a path/file installed by the
software or by one of its dependency.  Then, in a post-patch target, you
need to use REINPLACE_CMD to replace those to by they variables
equivalent, something like:

post-patch:
${REINPLACE_CMD} -e 's,%%PREFIX%%,${PREFIX}' ${WRKSRC}/githup.c

It seems to me that you might also want to allow the user to reference
a/their config from within their home dir (~/). But of course that's
purely optional. Just thought I might mention it in case it mattered.
___
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: TeXLive 2020 Update

[Chris]

On 2020-12-30 10:51, CTH via freebsd-ports wrote:

Hi all,

I'm new to this list, but I have been looking into updating the TeX Live 
ports to
2020. The current version is 2015, and the TeX ports could use with a little 
TLC

to bring those up to date.

I have been trying to update the TeX related ports in place, using the 
current
infrastructure. i.e. updating bsd.tex.mk, then updating each port's Makefile 
to
download, build, and install using the 2020 sources. I began porting the 
current
patch files to patch the new sources in the same way the old sources were 
patched,
in order not to break any current functionality or expectations. In some of 
those
cases, I'm not sure continuing to patch the upstream source makes sense, and 
it

might make more sense to provide a more vanilla out-of-the-box experience.

Since I'm new to this, I'm not sure what the preferred way of collaborating 
or
reaching out for help is. I'd like to submit my partial work for some sort 
of
review before I go much further, just as a sanity check at least. I'd also 
not
like to step on anyone else's toes that might be considering working on the 
same
thing, or already working on it. Looking over the list archives for the past 
6

months didn't show any activity on those ports.

There may be a couple of ways of going about this. One would be building 
from
source (as the current scheme does, and the work I started), but we could 
also use
the upstream binary packages for FreeBSD 12.1+. Or a combination, by adding 
a new

TeX flavor perhaps?

Hello, and thanks for your efforts!
We generally initiate things like this through the FreeBSD bugzilla
( https://bugs.freebsd.org ).
You could probably easily get the ball rolling opening a bug for 
print/texlive-base

Here's a link to start the process:

https://bugs.freebsd.org/bugzilla/enter_bug.cgi?component=Individual%20Port%28s%29&product=Ports%20%26%20Packages&short_desc=print%2Ftexlive-base

sorry if it gets wrapped too badly.

This will allow you to indicate your intentions, and add any patches you may 
have
already. It will also initiate conversation with any/all related individuals. 
Those
already maintaining ports are already subscribed to this list, and will 
receive

reports of your work here (bugzilla posts to this and other related lists).

I hope this helps, and thanks again! :-)

--Chris


Thanks!
Travis
___
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: OpenSource app Simple Diary

[Chris]

On 2021-01-03 01:57, Matthias Apitz wrote:

Hello,

In the forum about the mobile Purism L5 someone announced some app to write 
a

diary:

https://forums.puri.sm/t/app-simple-diary/11508
https://github.com/johan-bjareholt/simple-diary-gtk

I have below its README file.  Its dependencies are:

- GTK+3

x11-toolkits/gtk30/ ?


- webkit2gtk-4.0

www/webkit2-gtk3/


- md4c and md4c-html - Not quite sure what these might translate to.


--Chris


Do we have them in our ports collection in head? I couldn't see them, at
least not with the above names exactly.

Thanks

matthias


Simple Diary


Simple and lightweight diary app.

Many features are still missing as this is a work in progress.

### Features
- Saves entries in markdown
- Adding images to your entries
- Works for small form factor devices
- Flatpak support

### Dependencies
- GTK+3
- webkit2gtk-4.0
- md4c and md4c-html

### Building

# Meson

First install dependencies listed above

Secondly run the following: meson build && ninja -C build

Executable will be built at build/src/simple-diary

# Flatpak

Build the org.johanbjare.SimpleDiary.yml manifest as with any other flatpak
manifest with flatpak-builder

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

GitHub: size of remote file is not known

[Chris]

I don't use Github. So I'm not familiar with their service(s).
But ports using source fetched from them always return:
size of remote file is not known
Is it that their servers simply refuse to return size/content-length
or is this something else?
I can see where this might turn into a problem for those attempting
to build ports on a system with limited resources -- especially
during a meta-port build, and even more so for newcomers.

Is anyone familiar with why this is so? I'd like to change this.

Thanks!

--Chris
___
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: GitHub: size of remote file is not known

[Chris]

On 2021-01-05 03:49, Mathieu Arnold wrote:

On Mon, Jan 04, 2021 at 08:04:32PM -0800, Chris wrote:

I don't use Github. So I'm not familiar with their service(s).
But ports using source fetched from them always return:
size of remote file is not known
Is it that their servers simply refuse to return size/content-length
or is this something else?
I can see where this might turn into a problem for those attempting
to build ports on a system with limited resources -- especially
during a meta-port build, and even more so for newcomers.

Is anyone familiar with why this is so? I'd like to change this.


USE_GITHUB is using a GitHub (and a git) feature to have git-archive(1)
files generated and served on the fly.

Feature? ;-)

So, the server has no idea how
small or large the file will be, as it does not exist yet, so it cannot
report the size to the http client.

Once one is generated it gets cached for a while, so if the file has
been requested not too far back, the server will have it cached and will
know the size, but it only happens for files that are requested
frequently.

Ahh. Then it looks grim for making any changes in that regard.
Thank you very much for the insight, Mathieu.

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

Can we create an (only for) ARCHS meta-category?

[Chris]

I'd like to propose we create an ARCHS category.
IOW create a category that works on the different 1st 2nd tiers
supported by FreeBSD.
It's difficult for users of other than x86/amd64 to find ports
that will build/install on their systems. If we could create a
category that contained ports that were known to work on archs
*besides* x86/amd64. They'd know what to anticipate, if they're
looking to start (or continue) using FreeBSD. This seems especially
important where meta-ports are concerned.

Thanks! :-)

--Chris
___
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: Handling directory ownership in pkg-plist

[Chris]

On 2021-02-06 13:34, Chris Rees wrote:

Hi all,

Resurrecting audio/ampache-resurrect, and I have @owner www/@group www above 
all
of the WWWDIR files, and they are correctly owned.  However, the directories 
under
it are all still owned by root:wheel, and if I explicitly add them all with 
@dir

pkg then complains about not being able to find them.

Would it be unacceptable to just have @exec chown -R www:www %D/%%WWWDIR%% 
at the bottom?

Yes. By way of pre-install:
You'll probably get a complaint unless you use: ${CHOWN}


Chris

--Chris
___
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: Handling directory ownership in pkg-plist

[Chris]

On 2021-02-07 02:18, Chris Rees wrote:

Hi Chris,

Thamks for the reply.

On 7 February 2021 03:57:03 GMT, Chris  wrote:

On 2021-02-06 13:34, Chris Rees wrote:

Hi all,

Resurrecting audio/ampache-resurrect, and I have @owner www/@group

www above

all
of the WWWDIR files, and they are correctly owned.  However, the

directories

under
it are all still owned by root:wheel, and if I explicitly add them

all with

@dir
pkg then complains about not being able to find them.

Would it be unacceptable to just have @exec chown -R www:www

%D/%%WWWDIR%%

at the bottom?

Yes. By way of pre-install:
You'll probably get a complaint unless you use: ${CHOWN}


Perhaps I was unclear- I'm referring to pkg-plist, so there is no ${CHOWN} 
there.


The exact proposed line is

@postexec chown -R www:www %D/%%WWWDIR%%

I was wondering what the 'proper' way to do this was.

I almost listed that as well. But it's been a couple years, and I couldn't
remember exactly how it looked. A look around to refresh my memory seems
to reveal that the pkg-plist for www/kanboard provides what you're looking
for eg; @owner && @group

Hope that helps, and good luck! :-)


Chris

--Chris
___
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: Handling directory ownership in pkg-plist

[Chris]

On 2021-02-07 02:18, Chris Rees wrote:

Hi Chris,

Thamks for the reply.

On 7 February 2021 03:57:03 GMT, Chris  wrote:

On 2021-02-06 13:34, Chris Rees wrote:

Hi all,

Resurrecting audio/ampache-resurrect, and I have @owner www/@group

www above

all
of the WWWDIR files, and they are correctly owned.  However, the

directories

under
it are all still owned by root:wheel, and if I explicitly add them

all with

@dir
pkg then complains about not being able to find them.

Would it be unacceptable to just have @exec chown -R www:www

%D/%%WWWDIR%%

at the bottom?

Yes. By way of pre-install:
You'll probably get a complaint unless you use: ${CHOWN}


Perhaps I was unclear- I'm referring to pkg-plist, so there is no ${CHOWN} 
there.


The exact proposed line is

@postexec chown -R www:www %D/%%WWWDIR%%

I was wondering what the 'proper' way to do this was.
I'm wondering why it's not enough to create a post-extract that doesn't 
something

like
cd ${WRKSRC}/some/dir && ${CHOWN} -R ${WWUSER}:${WWGROUP} .
Then the ports framework would create an appropriate pkg-plist based on that. 
A

make -DBATCH makeplist would generate your target pkg-plist.

I'm paraphrasing, as I don't have your Makefile. But I've needed to perform 
tasks
like myself. Out of curiosity. What does a make -DBATCH makeplist generate? 
Does
the output provide the necessary clues to create a pkg-plist you're 
interested in?


Chris

--Chris
___
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: Handling directory ownership in pkg-plist

[Chris]

On 2021-02-07 12:19, Chris Rees wrote:

Afternoon,

On 7 February 2021 19:05:26 GMT, Chris  wrote:

On 2021-02-07 02:18, Chris Rees wrote:

Hi Chris,

Thamks for the reply.

On 7 February 2021 03:57:03 GMT, Chris 

wrote:

On 2021-02-06 13:34, Chris Rees wrote:

Hi all,

Resurrecting audio/ampache-resurrect, and I have @owner www/@group

www above

all
of the WWWDIR files, and they are correctly owned.  However, the

directories

under
it are all still owned by root:wheel, and if I explicitly add them

all with

@dir
pkg then complains about not being able to find them.

Would it be unacceptable to just have @exec chown -R www:www

%D/%%WWWDIR%%

at the bottom?

Yes. By way of pre-install:
You'll probably get a complaint unless you use: ${CHOWN}


Perhaps I was unclear- I'm referring to pkg-plist, so there is no

${CHOWN}

there.

The exact proposed line is

@postexec chown -R www:www %D/%%WWWDIR%%

I was wondering what the 'proper' way to do this was.

I'm wondering why it's not enough to create a post-extract that doesn't

something
like
cd ${WRKSRC}/some/dir && ${CHOWN} -R ${WWUSER}:${WWGROUP} .
Then the ports framework would create an appropriate pkg-plist based on
that.
A
make -DBATCH makeplist would generate your target pkg-plist.

I'm paraphrasing, as I don't have your Makefile. But I've needed to
perform
tasks
like myself. Out of curiosity. What does a make -DBATCH makeplist
generate?
Does
the output provide the necessary clues to create a pkg-plist you're
interested in?


CHOWN can't be used in the Makefile as you need root.

make makeplist used after CHOWN does nothing different- it appears not to 
notice

that they have different owners.
But what of the pkg-plist for www/kanboard? It has the clues you need for 
setting the

pkg-plist. The ports framework will honor the perms set within it. eg;
@owner %%KANBOARD_USERNAME%%
@group %%KANBOARD_GROUPNAME%%
%%WWWDIR%%/.htaccess
%%WWWDIR%%/ChangeLog
%%WWWDIR%%/LICENSE
%%WWWDIR%%/app/.htaccess
%%WWWDIR%%/app/Action/Base.php
%%WWWDIR%%/app/Action/CommentCreation.php
...

Just change the leader to the @user and @group to your desired names in your
pkg-plist. Save it to your port. Done. :-)


There is nothing documented on this that I can find, so I'll commit the 
@postexec line.


Chris

--Chris
___
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: Creating port from pre-built package

[Chris]

On 2021-02-11 08:26, Shawn Webb wrote:

Hey all,

The Splunk universal forwarder for FreeBSD is distributed as a package
tarball that you can use `pkg add` on. I'm in a position where I'd
like to create a port of the package so that I can automate certain
tasks.

Reverse engineer a package? I think that will violate the NDA you
signed. ;-)

Really. Unless the package is simply a wrapper of a binary blob. You'll
need to *build* the port, as part of the package creation process.
That is, unless I've *completely* misunderstood your intent here. :-)



Being a ports newb, I'm not sure how to properly create a port from a
pre-built package. Does anyone have any non-xkcd pointers[1]?

[1]: https://xkcd.com/138/

Thanks,

--Chris
___
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: Creating port from pre-built package

[Chris]

On 2021-02-11 09:08, Shawn Webb wrote:

On Thu, Feb 11, 2021 at 09:03:19AM -0800, Chris wrote:

On 2021-02-11 08:26, Shawn Webb wrote:
> Hey all,
>
> The Splunk universal forwarder for FreeBSD is distributed as a package
> tarball that you can use `pkg add` on. I'm in a position where I'd
> like to create a port of the package so that I can automate certain
> tasks.
Reverse engineer a package? I think that will violate the NDA you
signed. ;-)

Really. Unless the package is simply a wrapper of a binary blob. You'll
need to *build* the port, as part of the package creation process.
That is, unless I've *completely* misunderstood your intent here. :-)


It's literally a package of pre-built binaries. You can install it by
running:

# pkg add ./splunkforwarder-8.0.7-cbe73339abca-freebsd-11.1-amd64.txz

Here's what `pkg info` shows:

$ pkg info -F splunkforwarder-8.0.7-cbe73339abca-freebsd-11.1-amd64.txz
   [11:55:13]
splunkforwarder-8.0.7
Name   : splunkforwarder
Version: 8.0.7
Origin : sysutils/splunk
Architecture   : FreeBSD:11:amd64
Prefix : /opt
Categories :
Licenses   :
Maintainer : eng-rele...@splunk.com
WWW: http://www.splunk.com
Comment: Splunk> The platform for machine data.
Annotations:
no_provide_shlib: yes
FreeBSD_version: 1101001
Flat size  : 56.6MiB
Description:
Splunk> The platform for machine data.

(C) 2005-2020 Splunk Inc. All rights Reserved

I'm not looking to re-build the binaries, but rather just use ports to
recreate the package given a pre-existing package tarball.

Well it's missing Categories && Licenses, and the Prefix is wrong.
So changes are in order. Aside from unpacking it somewhere, and cobbling
up a script to re-pack(age) it. I'm at a loss. But it *does* seem like
it might be possible.

Good luck.



Thanks,

--Chris
___
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: bogus warning from pkg

[Chris]

On 2021-02-15 22:20, Steve Kargl wrote:

On Mon, Feb 15, 2021 at 08:18:13PM -0800, Mark Millard wrote:

Steve Kargl sgk at troutmask.apl.washington.edu wrote on
Tue Feb 16 02:14:06 UTC 2021 :

> On Mon, Feb 15, 2021 at 05:10:54PM -0800, Mark Millard via freebsd-ports 
wrote:
> > Steve Kargl sgk at troutmask.apl.washington.edu wrote on
> > Mon Feb 15 20:39:19 UTC 2021 :
> >
> > > Step 1).  Install FreeBSD 13.0 on empty disk.
> > > Step 2).  Install git from ports and grab FreeBSD 14.0 src.
> > > Step 3).  Buildworld/kernel for FreeBSD 14.0
> > > Step 4).  Install FreeBSD 14.0 and reboot.
> > > Step 5).  Delete all ports.
> > > Step 6).  Re-install pkg, portmaster, and 589 other ports.
> >
> > It does not sound like Step 6 was "rebuild ports and install"
> > but just pkg install use, at least for pkg itself.
>
> Ports are rebuilt on the system as the pre-built ports
> have options selected that do not match the requirements
> of the system.  It takes a week or more to rebuild
> everything, which why I'm concerned with the bogus
> warning and whether 'pkg bootstrap -f' would rebuild
> everything.
>
> I also do
>
> % cd /usr/ports
> % svn update
> % make fetchindex
> % pkg audit -qF
>
> before I build any port.  That third step pulls down
> the INDEX-14, which again leads to confusion when pkg
> issues a warning about 13.

If you still have the context to do the comparison:

How does the output of "pkg info pkg" compare to:

. . .
Architecture   : FreeBSD:13:amd64
. . .
Annotations:
FreeBSD_version: 13?
. . .

Does it have "14"s instead of "13"s?



I simply did a 'portmaster -Byd pkg' and did a rebuild
and re-install of pkg.  That seems to have mysteriously
fixed the issue.  I'll chalk this up to another FreeBSD
heisenbug.


Just saw this on current@. While this on a aarch, it still seems relevant.

title: pkg vs uname troubles after upgrade to 14

Hi,

Upgraded from 13 to 14.

# uname -UK
143 143

But elfdump on uname gives:
note (.note.tag):
   FreeBSD 1300133 (NT_FREEBSD_ABI_TAG)


# pkg -o OSVERSION=143 upgrade
pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap -f" 
recommended

Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Updating database digests format: 100%
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be REINSTALLED:
   pkg-1.16.2 (ABI changed: 'freebsd:14:aarch64:64' -> 
'freebsd:13:aarch64:64')


Number of packages to be reinstalled: 1


How do I do this properly? Rebuilding name still gives it the ELF note of 
1300133.

It does not matter if I pass "-o OSVERSION=143" to pkg or not.
Found https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104, but I don't 
think it was really resolved.


This is on aarch64. And why does pkg not use the version uname is reporting 
by -UK instead of the ELF note?


Regards,
Ronald.

Maybe sheds some additional light?
___
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"

maintainer seeks available committer

[Chris]

No this isn't intended for the personal ads. ;-)
I've got a couple of PRs that have been hanging
for awhile that should be ready to commit:

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

Thanks! :-)

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

When did pkg(8) drop support for 12-STABLE?

[Chris]

OK On a virgin 12 stable install. Followed by a
svnlite co svn://svn.freebsd.org/portd/head /usr/ports
and a /usr/src already populated.
A trip to /usr/ports/ports-mgmt/pkg
followed by make install clean
returned:
/!\ ERROR: /!\

Ports Collection support for your FreeBSD version has ended, and no ports are
guaranteed to build on this system. Please upgrade to a supported release.

No support will be provided if you silence this message by defining
ALLOW_UNSUPPORTED_SYSTEM.

*** Error code 1

Stop.
While I could follow pkg's suggested alternative. This all just seems
very wrong.
Is there any way to disable pkg completely. So I can simply build
ports, rather than packages? maybe a
WITH_PKG=false
USE_PKG=false
or something else?

Thanks in advance for any enlightenment.

--Chris
___
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: When did pkg(8) drop support for 12-STABLE?

[Chris]

On 2021-02-23 14:58, @lbutlr wrote:

On 23 Feb 2021, at 13:26, Chris  wrote:

OK On a virgin 12 stable install.


The current release is 12.2-RELEASE. 12.0-RELEASE was EOLed last February. I 
am

not sure what build you mean by "12-STABLE"
It was from a 12-STABLE usb stick (probably 12.1). Is there no way forward, 
save

building up to 12.2?


Are you on the http://lists.freebsd.org/mailman/listinfo/freebsd-stable 
mailing list?
Yep. But subscribed under a different email address. Guess I should look into 
it.


Thank you very much for taking the time to reply!

--Chris
___
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: When did pkg(8) drop support for 12-STABLE?

[Chris]

On 2021-02-23 16:04, Mark Millard wrote:

Chris portmaster at bsdforge.com wrote on
Tue Feb 23 23:31:09 UTC 2021 :


On 2021-02-23 14:58, @lbutlr wrote:
> On 23 Feb 2021, at 13:26, Chris  wrote:
>> OK On a virgin 12 stable install.
>
> The current release is 12.2-RELEASE. 12.0-RELEASE was EOLed last February. I
> am
> not sure what build you mean by "12-STABLE"
It was from a 12-STABLE usb stick (probably 12.1). Is there no way forward,
save
building up to 12.2?



You might want to report the output of:

# uname -apKU

if you can still run it in the environment in question.

Thank you for your thoughtful suggestion, Mark.
It returns:
FreeBSD fbsd12dev 12.1-STABLE FreeBSD 12.1-STABLE r363918 GENERIC  amd64 
amd64 1201522 1201522


Is that bad?

Thanks again.

--Chris


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: When did pkg(8) drop support for 12-STABLE?

[Chris]

On 2021-02-23 18:25, Jonathan Chen wrote:

On Wed, 24 Feb 2021 at 15:00, Chris  wrote:


On 2021-02-23 16:04, Mark Millard wrote:
> Chris portmaster at bsdforge.com wrote on
> Tue Feb 23 23:31:09 UTC 2021 :
>
>> On 2021-02-23 14:58, @lbutlr wrote:
>> > On 23 Feb 2021, at 13:26, Chris  wrote:
>> >> OK On a virgin 12 stable install.
>> >
>> > The current release is 12.2-RELEASE. 12.0-RELEASE was EOLed last February. 
I
>> > am
>> > not sure what build you mean by "12-STABLE"
>> It was from a 12-STABLE usb stick (probably 12.1). Is there no way forward,
>> save
>> building up to 12.2?
>
>
> You might want to report the output of:
>
> # uname -apKU
>
> if you can still run it in the environment in question.
Thank you for your thoughtful suggestion, Mark.
It returns:
FreeBSD fbsd12dev 12.1-STABLE FreeBSD 12.1-STABLE r363918 GENERIC  amd64
amd64 1201522 1201522

Is that bad?



Thanks for the reply, Jonathan.

You're running 12.1, and not -STABLE. The EOL for 12.1 was Nov-2019.

Odd. It _says_ it's the STABLE branch.


You need to get a later version or run -STABLE (ie: build from source
off the stable/12 branch).

It _was_ built from the stable/12 branch. All be it a good while ago.
I guess I've somehow lost my understanding of what tracking STABLE really
means. Or maybe it's changed. But I installed from a 12-STABLE medium.
uname(1) reports it's 12-STABLE (12.1-STABLE). But it's _not_ 12-STABLE.
See my confusion? :-)

Thanks again.

--Chris


Cheers.
--
Jonathan Chen 

___
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: When did pkg(8) drop support for 12-STABLE?

[Chris]

On 2021-02-24 00:56, @lbutlr wrote:

On 23 Feb 2021, at 16:31, Chris  wrote:
It was from a 12-STABLE usb stick (probably 12.1). Is there no way forward, 
save

building up to 12.2?


It sounds like the version you want is -RELEASE, not -STABLE.

Yep.


Think of -STABLE as "We are still working on this, but we THINK it's stable" 
as

opposed to RELEASE "this is ready for general release."

Yes. Seems my understanding became inverted somewhere along the line.
I was _really_ looking to install RELEASE.

Thank you very much for taking the time to reply! :-)

--Chris


Matthius included the steps needed to get to the current supported version.

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

Re: www/joomla3 is no longer in the FreeBSD pkg repo

[Chris]

On 2021-03-04 00:50, Patrick M. Hausen wrote:

Hi all,


Am 04.03.2021 um 02:17 schrieb Chris Rees :
The problem is, that although the php80 flavour does not depend on 
pecl-pdflib, the default flavour does,
which means that the package will not be built as it you have to agree to 
pecl-pdflib's licence.


I am not a lawyer. That being said I have done some homework and did a lot 
if reading
in February 2020. Sent my findings to the port maintainer of print/pdflib, 
but did not get

a response, unfortunately.

My conclusion is that you don't need to agree to PDFlib GmbH's license, 
because all
of the legalese on their home page applies to a completely different product 
than the

one used by pecl-pdflib.

But step by step ...

1.	pecl-pdflib is published under the PHP license, so it is clearly open 
source.
2.	The FreeBSD port is not based on pdflib, but pdflib-lite - this is the 
crucial point.

3.  pdflib-lite is a product abandoned by PDFlib GmbH in 2011.
4.	pdflib-lite archives come with an open source license bundled in the 
archive.
5.	This is the only license applicable to our case. All the other licensing 
stuff on their

website applies to pdflib - *which is a completely different product*.
6.	The license bundled with pdflib-lite explicitly permits the distribution 
of binaries as

long as the license document and some other auxiliary files are 
included.
7.	The port does this and puts the necessary documents in 
/usr/local/share/doc/pdflib.


You won't find any information about pdflib-lite on PDFlib GmbH's website, 
because
they pulled it. Nonetheless the source is "out there", bundled with a 
permissive license

which cannot be taken back.

So the entire discussion is moot - as long as pecl-pdflib can be built with 
pdflib-lite.


The problem with the port/packages infrastructure is that this line in
ports/print/pdflib/Makefile
is nonsense, IMHO:

RESTRICTED= Many odd restrictions on usage and distribution


Download the pdflib-lite tarball and see the documents for yourself. I am 
repeating myself:
all the legalese on the PDFlib GmbH website *does not apply* to this product 
(pdflib-lite).
I needed the pdflib-lite for a script I cobbled up to batch convert to/from 
text/pdf
a couple of years ago. I can confirm that the lib is with a *non*restrictive 
license.

My humble suggestion;
Can't we please simply create a pdflib-lite port, and be done with all this 
and related? :-)


--Chris



Kind regards,
Patrick
--

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

Re: www/joomla3 is no longer in the FreeBSD pkg repo

[Chris]

On 2021-03-04 08:39, Chris Rees wrote:

On 04/03/2021 16:16, Chris wrote:

On 2021-03-04 00:50, Patrick M. Hausen wrote:

Hi all,


Am 04.03.2021 um 02:17 schrieb Chris Rees :
The problem is, that although the php80 flavour does not depend on 
pecl-pdflib, the default flavour does,
which means that the package will not be built as it you have to agree to 
pecl-pdflib's licence.


I am not a lawyer. That being said I have done some homework and did a lot 
if reading
in February 2020. Sent my findings to the port maintainer of print/pdflib, 
but did not get

a response, unfortunately.

My conclusion is that you don't need to agree to PDFlib GmbH's license, 
because all
of the legalese on their home page applies to a completely different 
product than the

one used by pecl-pdflib.

But step by step ...

1.    pecl-pdflib is published under the PHP license, so it is clearly 
open source.
2.    The FreeBSD port is not based on pdflib, but pdflib-lite - this is 
the crucial point.

3.    pdflib-lite is a product abandoned by PDFlib GmbH in 2011.
4.    pdflib-lite archives come with an open source license bundled in the 
archive.
5.    This is the only license applicable to our case. All the other 
licensing stuff on their

website applies to pdflib - *which is a completely different product*.
6.    The license bundled with pdflib-lite explicitly permits the 
distribution of binaries as
long as the license document and some other auxiliary files are 
included.
7.    The port does this and puts the necessary documents in 
/usr/local/share/doc/pdflib.


You won't find any information about pdflib-lite on PDFlib GmbH's website, 
because
they pulled it. Nonetheless the source is "out there", bundled with a 
permissive license

which cannot be taken back.

So the entire discussion is moot - as long as pecl-pdflib can be built 
with pdflib-lite.


The problem with the port/packages infrastructure is that this line in
ports/print/pdflib/Makefile
is nonsense, IMHO:

RESTRICTED= Many odd restrictions on usage and distribution


Download the pdflib-lite tarball and see the documents for yourself. I am 
repeating myself:
all the legalese on the PDFlib GmbH website *does not apply* to this 
product (pdflib-lite).
I needed the pdflib-lite for a script I cobbled up to batch convert to/from 
text/pdf
a couple of years ago. I can confirm that the lib is with a 
*non*restrictive license.

My humble suggestion;
Can't we please simply create a pdflib-lite port, and be done with all this 
and related? :-)


The pdflib that we have in the port *is* pdflib-lite :)   Hence my proposed 
review to ale@.



Brilliant!

Thanks! :-)

--Chris

Chris

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

comitter please

[Chris]

I have patch in a pr(1) that should be ready for commit:

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

Thanks! :-)

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

Re: Python 2.7 removal outline

[Chris]

There have been a great many comments on this matter on the
mailing list. All the replies are valuable. But (this) original
post has been trimmed in all those replies. So in an effort to
maintain context to the original statement. I'm making my reply
here. Which reflects the attitude of most all of the replies made
to this announcement. My comments below this initial announcement...

On 2021-03-24 06:03, Rene Ladan wrote:

Hi,

below is an outline continuing the Python 2.7 cleanup:

- all affected ports are now marked as deprecated, with an expiration date
  of either 2020-12-31 or 2021-06-23.
- we will have to wait for Chromium to fully switch to Python 3 before we
  can fully remove Python 2.7. This is work in progress on their side. Not
  waiting would imply removing www/chromium (obviously), editors/vscode
  (it escaped the recursive-deprecation dance of devel/electron*), but most
  importantly www/qt5-webengine which would drag half of KDE with it.
  However, lang/python27 will be marked as RESTRICTED so that all ports
  mentioned above can still be built and run, but Python 2.7 itself will
  not be available as a package.
- No more new ports having USES=python:2.7 or USES=python:2.7+ or existing
  ports reverting to that, no excuses.
- No usage of lang/tauthon by the framework or any port, no excuses.
- lang/tauthon will be removed on 2021-06-23 as noticed in the port itself,
  no excuses. Tauthon is not guaranteed to be compatible with any official
  Python version so keeping it would just unnecessarily complicate things.
- mail/mailman is being replaced by clusteradm@  with mlmmj. You can use
  `pkg lock` to stick with it after removal, if there is no other way.
- you are of course free to provide your own version of Python 2.7, Tauthon
  and any application using those languages in your local setup, by using
  overlays for example.

Miscellaneous tidbits:
- WHY?!?!? Well, back in 2008, the Python Software Foundation planned to
  mark Python 2.7 end-of-life at 2015-01-01, see [1], but that date was
  pushed back to 2020-01-01 because a lot of downstream users had not
  converted yet. So Python 2.7 is already end-of-life for 1.5 years, which
  means that according to [1] the PSF is no longer fixing security issues
  for it. As can be seen on [2], multiple vulnerabilities already have
  been fixed for Python 3.6 to 3.9 this year.
- On a related note, most software using Python 2.7 was already removed
  from the Ports Tree last year, a lot of it being unmaintained or
  more or less abandoned upstream.
- Upstream Chromium is working on converting their codebase to Python 3 but
  there is no completion date. Interestingly, adridg@ is experimenting with
  converting www/qt5-webengine to Python 3 too.
- We are indeed faster with dropping Python 2.7 than e.g. Ubuntu, however
  more recent Debian/Ubuntu distributions are more and more dropping Python
  2.7 too. This also has to do with how their branching model works, the
  package set of Ubuntu LTS is determined a few months before the release
  itself.

[1] https://www.python.org/dev/peps/pep-0373/
[2] https://www.python.org/downloads/release/python-392/

Ren,
on behalf of portmgr


OK ports maintenance is almost exclusively on a volunteer/best
effort basis. Most Maintainers have a $DayJob. Some have $Family.
Some (not me) have something they call a $Life. Through all that,
they somehow manage to make time to adopt, and Maintain one or
more ports. Some -- perhaps many, do it because they're grateful
for FreeBSD and all the efforts made to create, and keep it a first
class OS. So in an effort to show their gratitude, attempt to
give-back by becoming a Maintainer. Some are programmers, some
are hackers, and some are just starting out. Often times for
seasoned Maintainers the task itself is relatively routine. But
Maintaining ports, even for seasoned Maintainers can be hard work.
If not because of the actual problem itself. To manage to find
the required time to get the job done in an acceptable time frame.
For the unseasoned Maintainer. The job can often be hard.
Why does our work have so little value that portmgr@ is unwilling
to keep us all in the loop, or consider our opinions on such matters?
Is it just me? Or is there a gross disconnect here?
Maintainers need a Forum where their views on ports matters get
some semblance of credence. Hell. I maintain some 160 ports. That's
got to be worth *something*.

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

Re: Python 2.7 removal outline

[Chris]

On 2021-03-25 22:24, Kurt Jaeger wrote:

Hi!


Why does our work have so little value that portmgr@ is unwilling
to keep us all in the loop, or consider our opinions on such matters?


The portmgr@ role is a huge task and all the reasons (limited time,
dayjobs, etc) ares  valid for those folks from portmgr as for
the rest of the ports maintainers and committers.

Indeed, and don't think that hadn't occurred to me. In fact I suspected
that portmgr@ was feeling a bit overwhelmed, and that *that* triggered
the seemingly overreaching python announcement.
May I humbly request a petition for such large-sweeping changes? IMHO
this will give portmgr@ the opportunity to get caught up, and perhaps
get some assistance -- maybe we all come up with an idea that saves
_everyones_ bacon. :-)


Thanks for the thoughtful reply.

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

Re: Python 2.7 removal outline

[Chris]

On 2021-03-26 08:44, RW via freebsd-ports wrote:

On Fri, 26 Mar 2021 13:55:33 +1100 (EST)
Dave Horsfall wrote:


On Thu, 25 Mar 2021, George Mitchell wrote:

>> [...] it is really not for everybody to use overlays in current
>> state (overlays are poor documented at least). [...]
>
> Until this thread I had never heard of them.  --
> George

I can't remember the last time I used overlays (certainly with CP/M);
I didn't know that FreeBSD even supported them (why bother when
you've got VM?).


I doubt that meaning of overlay is going to be relevant. I'd not heard
of it either, but from looking in ports/Mk/ it seems to be a way of
modifying port builds.

As I understand it. It allows you to graft out-of-tree ports/versions
onto the ports-tree-proper.

--Chris

___
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: Python 2.7 removal outline

[Chris]

On 2021-03-26 12:19, Dan Mahoney (Ports) wrote:

More thoughts on mailman, specifically:

So, I just went to find an old FB post I made about mailman 2.x:

===
From the "Load Bearing Bit" department:
Pretty much the entire world is stuck using an EOL'd mailing list manager 
(mailman

2.x), which depends on an EOL'd python (2.7).
This includes:
* All the gnu mailing lists
* All of the linux mailing lists at listman.redhat
* all the FreeBSD mailing lists
* all the sourceforge mailing lists
* all the IETF mailing lists
* all of lists.isc.org
* NANOG
===

That’s an AWFUL LOT of sysadmins, network admins, and coders who looked long 
and

hard at Mailman 3 and decided “that’s not ready yet”.

I think, if *nothing else*, tauthon needs to be stapled in for mailman, even 
if it

lives under /usr/local/mailman/bin or something (and bakes in the couple of
dependencies).
I *fully* concur. In fact, at least 2 ports that I maintain added a depends 
on
tauthon. Which really raised my ire hearing it's intended doom announcement. 
:(
Honestly. If something "just works", isn't a "security risk". Than don't fix 
it!


--Chris


I know about the archive incompatibility.  There *might* be a GSOC project 
to fix
it.  Maybe.  Other changes can happen with greater use, but clearly there’s 
a

first-mover disadvantage here.

-Dan


On Mar 26, 2021, at 9:06 AM, Chris  wrote:

On 2021-03-26 08:44, RW via freebsd-ports wrote:

On Fri, 26 Mar 2021 13:55:33 +1100 (EST)
Dave Horsfall wrote:

On Thu, 25 Mar 2021, George Mitchell wrote:
>> [...] it is really not for everybody to use overlays in current
>> state (overlays are poor documented at least). [...]
>
> Until this thread I had never heard of them.  --
> George
I can't remember the last time I used overlays (certainly with CP/M);
I didn't know that FreeBSD even supported them (why bother when
you've got VM?).

I doubt that meaning of overlay is going to be relevant. I'd not heard
of it either, but from looking in ports/Mk/ it seems to be a way of
modifying port builds.

As I understand it. It allows you to graft out-of-tree ports/versions
onto the ports-tree-proper.

--Chris

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

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

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

Re: Python 2.7 removal outline

[Chris]

On 2021-03-26 15:18, Olivier Certner wrote:

Le vendredi 26 mars 2021, 22:43:12 CET Chris a écrit :
Honestly. If something "just works", isn't a "security risk". Than don't 
fix

it!


Not so simple... But for build-only dependencies, I concur.

But anyway, all new security reports for 3.x will be fixed in Tauthon. I've
now already reviewed 55 security bugs from PSF and fixed those appropriate
(most are either not bugs, or irrelevant, or already fixed in 2.7 or Tauthon
proper). I have ~20 more to review (and possibly fix), then I'll test the
result and finally push all this upstream.

Thank you, Olivier. I *really* appreciate all the work you've put into this.

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

Committer for couple fixed ports that didn't get merged to Quarterly?

[Chris]

Hi I have a couple of pr's that were committed
but not merged to Quarterly. As a result pkg-fallout@
continues to complain.
Can someone please merge these to 2 FIXED prs to Quarterly?

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

Thanks!

--Chris
___
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: poudriere: net/openldap24-server: stage/runaway , building forever

[Chris]

On 2021-04-09 01:16, Ronald Klop wrote:

Hi,

The official pkg builders are also stuck for 14-CURRENT. Although at a 
different

port sysutils/msktutil.

See main-amd64 at https://pkg-status.freebsd.org/builds?type=package

It is stuck in "stage/runaway" for 61 hours now.
http://beefy18.nyi.freebsd.org/build.html?mastername=main-amd64-default&build=p569609_s5b3b19db73
(ipv6 only)

NB: I'm not involved in the pkg building cluster.

Regards,
Ronald.
I ran into a similar situation yesterday testing a port I was upgrading. It 
wasn't
the port itself. But one of it's dependencies. It flashed a warn (magenta) 
followed
by a lime green line. It was far too fast to catch any of it. But it ran this 
way
for a good 10 minutes. It was a small dependency. But the warn clearly 
tripped it up.
I've never seen an warn trip anything up for such a long time on something so 
small.
The server was completely unloaded. Just my login and my small port build. It 
finally
ran to completion without any ill affect. But I've never seen anything like 
it. A

race condition creep into the ports framework, maybe?

--Chris



Van: "O. Hartmann" 
Datum: vrijdag, 9 april 2021 07:27
Aan: FreeBSD Ports 
Onderwerp: Re: poudriere: net/openldap24-server: stage/runaway , building 
forever


On Fri, 9 Apr 2021 06:17:03 +0200
"Hartmann, O."  wrote:

> Recent CURRENT host (FreeBSD 14.0-CURRENT #26 main-n245806-4d221f59b85: Sat
> Apr  3 06:43:44 CEST 2021 amd64), poudriere CURRENT jail at 14.0-CURRENT
> 147 amd64 from 2021-04-08 05:25:38. It seems that the recent CURRENT does
> have a serious problem when building net/openldap24-server. The build process
> gets stuck with staging and is marked "runaway":
>
> [head-amd64-head-default] [2021-04-08_13h56m41s] [parallel_build:] Queued:
> 1847 Built: 63 Failed: 17   Skipped: 1759 Ignored: 8Tobuild: 0 Time:
> 13:26:35 [01]: net/openldap24-server | openldap-sasl-server-2.4.58
> stage/runaway (06:28:32 / 08:41:16)
>
> Also, on jails (recent CURRENT) serving as OpenLDAP server (also recent taken
> from git /usr/ports, branch main), run into a serious problem starting slapd,
> when starting slapd and the process is reporting checking configuration, it
> freezes forever. Putting slapd into debug mode doesn't help, since the freeze
> is quite early.
>
> Does anybody know what the reason for this strange behaviour is on CURRENT?
> All CURRENT servers are affected (almost all the same revision as shown
> above)?
>
> Thanks in advance,
>
> O. Hartmann

Short update, another host is stuck at the very same point, host's CURRENT 
is at

 FreeBSD 14.0-CURRENT #2 main-n245870-86a52e262a6: Wed Apr  7 13:57:20 CEST
 2021 amd64, it's jails is taken from the same source.

The process is stuck at staging and took 34 hours ... never seen before:


[...]
[09:05:25] [03] [02:13:44] Finished net/openldap24-server |
openldap-sasl-server-2.4.58: Failed: stage/runaway load: 10.39  cmd: awk 
24374

[running] 0.06r 0.00u 0.00s 0% 3420k [headamd64-head-default]
[2021-04-07_12h26m18s] [parallel_build:] Queued: 3298 Built: 2123 Failed: 7
Skipped: 1161 Ignored: 7Tobuild: 0 Time: 40:52:34 [03]:
net/openldap24-server | openldap-sasl-server-2.4.58 stage/runaway
(31:48:30 / 34:01:11) [40:52:52] Logs:
/pool/poudriere/data/logs/bulk/headamd64-head-default/2021-04-07_12h26m18s
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"




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

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

Re: Deprecation of portsnap

[Chris]

On 2021-04-13 15:53, Dave Horsfall wrote:

On Mon, 12 Apr 2021, Peter Jeremy via freebsd-ports wrote:

Except that git will arbitrarily and randomly decide that it needs to run 
"gc" - which is similarly extravagant in memory usage.  Last time I found 
one running, it thrashed that poor VM for 3 days.


Would this be a good time to mention the https://ohshitgit.com/ site? 
Warning: it

contains strong language...

It would!
And the language is very appropriate, thank you. :-)


-- Dave


--Chris


___
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: Deprecation of portsnap

[Chris]

On 2021-04-13 23:22, Stefan Esser wrote:

Am 14.04.21 um 02:43 schrieb Chris:

On 2021-04-13 15:53, Dave Horsfall wrote:

On Mon, 12 Apr 2021, Peter Jeremy via freebsd-ports wrote:


Except that git will arbitrarily and randomly decide that it needs to

run

"gc" - which is similarly extravagant in memory usage.  Last time I

found

one running, it thrashed that poor VM for 3 days.


Would this be a good time to mention the https://ohshitgit.com/ site? 
Warning: it

contains strong language...

It would!
And the language is very appropriate, thank you. :-)


If you disagree regarding the appropriateness of the language,

Not at all. I found the site absolutely *wonderful*. Thanks! :-)


there is:

https://dangitgit.com/

And in the upper right corner you'll find a language selection
list that gives access to some 20 translations.

Or just try the URL with your 2-letter country code added ...

Regards, STefan

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

When will git be supported for ports?

[Chris]

Hi all,
Maintainer for some ~160 ports, and attempting to fix some
bugs. But as I understand it 'git' is supposed to be the new
source of truth. While I know svn by heart. I have near zero
understanding of git, or for that matter, why anyone would
rather use it. That said; as I try to discover the new
procedures for maintaining ports under git. I see there isn't
anything in the porters-handbook regarding the acquisition
of the ports tree in order to get started. Shouldn't this be
at the very beginning of the ports doc? The closest thing I
could find was a reference to a link: #ports-using/ in the
Handbook. Which doesn't exist. It *should* throw a 404. But
was cleverly masked, and simply returns the front page. This
is a terrible idea. As the doc maintainers will never know
they need to make corrections, and new users with a new
interest in FreeBSD will become frustrated and turn away.
Maintainers, like me, utilizing what little time they have
to spare will also become frustrated and likely find that
they now only have the time to discover where the actual
information is. With no more time to actually *fix* the port
they sought to. While I realize this should probably be sent
to docs@ I'm not on the list, and because this is ports
related. I hope it finds value here as well.

Thanks for listening.

--Chris
___
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: When will git be supported for ports?

[Chris]

On 2021-04-28 11:15, Kurt Jaeger wrote:

Hi!


Maintainer for some ~160 ports, and attempting to fix some
bugs. But as I understand it 'git' is supposed to be the new
source of truth. While I know svn by heart. I have near zero
understanding of git, or for that matter, why anyone would
rather use it.


The 'why' was explained here:

https://github.com/bsdimp/freebsd-git-docs/

But, unfortunatly, that text moved somewhere. It's a good
first test to find out how to recover that text from the git repo 8}
Any hints ?


That said; as I try to discover the new
procedures for maintaining ports under git. I see there isn't
anything in the porters-handbook regarding the acquisition
of the ports tree in order to get started.
Shouldn't this be at the very beginning of the ports doc?


This below should work, and I agree with you: It was hard to find out.

mkdir -p somedir/ports
cd somedir
git clone -o freebsd \
--config remote.freebsd.fetch='+refs/notes/*:refs/notes/*' \
https://git.freebsd.org/ports.git ports

I'm also trying to learn more git to be able to work on the
ports tree, but my time is limited and somehow, I still do
not see the forest for the trees 8-(

Kurt, you're AWESOME!
Vastly useful, and GREATLY appreciated. :-)

Now, if we could only get this $hit in the docs. ;-)

Thanks!

--Chris
___
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: When will git be supported for ports?

[Chris]

On 2021-04-28 11:25, Li-Wen Hsu wrote:

On Thu, Apr 29, 2021 at 2:15 AM Kurt Jaeger  wrote:


Hi!

> Maintainer for some ~160 ports, and attempting to fix some
> bugs. But as I understand it 'git' is supposed to be the new
> source of truth. While I know svn by heart. I have near zero
> understanding of git, or for that matter, why anyone would
> rather use it.

The 'why' was explained here:

https://github.com/bsdimp/freebsd-git-docs/

But, unfortunatly, that text moved somewhere. It's a good
first test to find out how to recover that text from the git repo 8}
Any hints ?


That was a draft repository used before the document migrated to use 
AsciiDoc.


In the README of that repository:

"""
These changes have been pushed into the FreeBSD tree. See the committer’s 
guide.

https://docs.freebsd.org/en/articles/committers-guide/#git-primer
"""


> That said; as I try to discover the new
> procedures for maintaining ports under git. I see there isn't
> anything in the porters-handbook regarding the acquisition
> of the ports tree in order to get started.


I guess that was because the porter's handbook was mainly about
porting, like writing the Makefile and pkg-plist. The VCS thing was
mainly in the committer's guide. But it's nice to mention some simple
git usages which will help people submit patches. After all that's one
of the reasons and possible benefit to use git.

A HUGE thank you for your reply. I know this probably seems simplistic.
But in order to get involved with ports, you're going to need a ports
tree. Not everyone who starts using FreeBSD will have a source tree, or
even build from source. So getting the ports tree as a necessary first
step IMHO should be noted. As everyone seems to be telling everyone the
proper git workflow, and they all vary. Maybe FreeBSD might show a 'ports
git workflow'. Much the same as the build/install world/kernel workflow in
/src/UPDATING at the top of the porters-handbook?
It's not that I don't know how to 'git clone'. It's that there's a
preferred procedure/protocol to becoming/being a FreeBSD ports
Maintainer, and I simply want to get it right the first time. Thereby
saving committers a good deal of time and effort. ;-)

Thanks again! :-)

--Chris



> Shouldn't this be at the very beginning of the ports doc?

This below should work, and I agree with you: It was hard to find out.

mkdir -p somedir/ports
cd somedir
git clone -o freebsd \
--config remote.freebsd.fetch='+refs/notes/*:refs/notes/*' \
https://git.freebsd.org/ports.git ports

I'm also trying to learn more git to be able to work on the
ports tree, but my time is limited and somehow, I still do
not see the forest for the trees 8-(

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

Looking for a committer

[Chris]

Hi. This is probably not the message you were expecting. ;-)
While I know most all the committers with any tenure.
It's my understanding that doing this directly "shopping
for a committer" is strictly frowned upon.
So please consider this my CV for application as a ports
committer.
I've been w/FreeBSD as long as it's existed, and a ports
maintainer for currently some 160 ports. I've been a
maintainer for more than 6yrs now. I had an experience
today I found very rewarding -- guiding a newcomer to
the creation of their first port [#255496]. As a rule;
I'm always "tackling problems". But this was a different
experience. Which got me to thinking that this is
something I'm really comfortable with, and something I
could really enjoy. If given the chance. I'm fairly
candid, as many of you know. But none-the-less have
pretty good communication skills.
tl;dr; I'd like to join the ports team. Please accept
my application. :-)

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

Re: How to make 'named' rc script invokded earlier at boot time

[Chris]

On 2021-04-30 00:30, Yasuhiro Kimura wrote:

I installed dns/bind916 on my home server and configured it so it
worked as both authoritative and recursor. Then I added
'nameserver 127.0.0.1' to /etc/resolv.conf and everything worked fine.

But after updating OS from 12.2-RELEASE to 13.0-RELEASE I noticed
execution of some rc scripts fails at boot time because of DNS lookup
error. And I also found these scripts are executed earlier than
'named'.

I've been plagued with this for years (well, a couple anyways) on several
of my servers. As I never saw anyone else mention it. I assumed it was just
"me". ;-)
rc(8) has a mountlate. Seems to me there ought to be a "startlate" key as
well. While this won't fix the cause introduced. It might at least solve
the problem.
create an /etc/rc.conf.local and move your host/nic related things into
it followed by your "named" entry. Leaving everything else in /etc/rc.conf
This (should) source all the rc.conf.local entries ahead of the rc.conf
entries. Thereby providing name resolution before ntpdate(8)/time sync
service(s)

HTH

--Chris


Now let me use 'ntpdate' as an example.

If I run `rcorder /etc/rc.d/* /usr/local/etc/rc.d/*` on 12.2-RELEASE,
then I get following result.

--
root@rolling-vm-freebsd3[474]# uname -a
FreeBSD rolling-vm-freebsd3.home.utahime.org 12.2-RELEASE-p6 FreeBSD
12.2-RELEASE-p6 GENERIC  amd64
root@rolling-vm-freebsd3[475]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/*
/etc/rc.d/growfs
/etc/rc.d/sysctl
/etc/rc.d/hostid
/etc/rc.d/zvol
/etc/rc.d/dumpon
(snip)
/etc/rc.d/static_arp
/etc/rc.d/bridge
/etc/rc.d/route6d
/etc/rc.d/NETWORKING
/etc/rc.d/mountcritremote
/etc/rc.d/devfs
/etc/rc.d/ipmon
/etc/rc.d/kdc
/etc/rc.d/mdconfig2
/etc/rc.d/newsyslog
/etc/rc.d/syslogd
/usr/local/etc/rc.d/tcsd
/usr/local/etc/rc.d/named
/etc/rc.d/watchdogd
/etc/rc.d/savecore
/etc/rc.d/archdep
/etc/rc.d/linux
/etc/rc.d/sysvipc
/etc/rc.d/SERVERS
/usr/local/etc/rc.d/tpmd
/usr/local/etc/rc.d/stunnel
/etc/rc.d/accounting
/etc/rc.d/ntpdate
/etc/rc.d/rpcbind
/etc/rc.d/nfsclient
/etc/rc.d/nisdomain
(snip)
--

As you can see, while 'named' is executed before SERVERS, 'ntpdate' is
done after it.

On the other hand I get following result on 13.0-RELEASE.

--
root@rolling-vm-freebsd2[332]# uname -a
FreeBSD rolling-vm-freebsd2.home.utahime.org 13.0-RELEASE FreeBSD 
13.0-RELEASE #0

releng/13.0-n244733-ea31abc261f: Fri Apr  9 04:24:09 UTC 2021
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
root@rolling-vm-freebsd2[333]# rcorder /etc/rc.d/* /usr/local/etc/rc.d/*
/etc/rc.d/dhclient
/etc/rc.d/dumpon
/etc/rc.d/growfs
/etc/rc.d/natd
(snip)
/etc/rc.d/netwait
/etc/rc.d/blacklistd
/etc/rc.d/local_unbound
/etc/rc.d/NETWORKING
/etc/rc.d/pppoed
/etc/rc.d/kdc
/etc/rc.d/kfd
/etc/rc.d/nfsuserd
/etc/rc.d/iscsid
/etc/rc.d/ipropd_slave
/etc/rc.d/nfscbd
/etc/rc.d/iscsictl
/etc/rc.d/ipropd_master
/etc/rc.d/kadmind
/etc/rc.d/kpasswdd
/etc/rc.d/mountcritremote
/etc/rc.d/wpa_supplicant
/etc/rc.d/motd
/etc/rc.d/accounting
/etc/rc.d/cleartmp
/etc/rc.d/dmesg
/etc/rc.d/archdep
/etc/rc.d/gptboot
/etc/rc.d/hostapd
/etc/rc.d/virecover
/etc/rc.d/mdconfig2
/etc/rc.d/devfs
/etc/rc.d/os-release
/etc/rc.d/newsyslog
/etc/rc.d/linux
/etc/rc.d/syslogd
/etc/rc.d/sysvipc
/etc/rc.d/watchdogd
/etc/rc.d/savecore
/etc/rc.d/ntpdate
/etc/rc.d/localpkg
/etc/rc.d/auditd
/etc/rc.d/bsnmpd
/etc/rc.d/pwcheck
/etc/rc.d/power_profile
/etc/rc.d/rpcbind
/etc/rc.d/auditdistd
/usr/local/etc/rc.d/named
/etc/rc.d/nfsclient
/etc/rc.d/hastd
/etc/rc.d/SERVERS
/etc/rc.d/nisdomain
/usr/local/etc/rc.d/stunnel
/usr/local/etc/rc.d/tpmd
/usr/local/etc/rc.d/tcsd
(snip)
--

Now both 'named' and 'ntpdate' are executed before SERVERS. And
unfortunately the latter is earlier than the former. So it is natural
that execution of 'ntpdate' fails with DNS lookup failure.

I compared ntpdate rc script between releng/12.2 and releng/13.0 but
there is no difference.

--
yasu@rolling-vm-freebsd2[1035]% pwd
/usr/src
yasu@rolling-vm-freebsd2[1036]% git diff origin/releng/12.2 
origin/releng/13.0  --

libexec/rc/rc.d/ntpdate
yasu@rolling-vm-freebsd2[1037]%
--

And of cource there is no difference with /usr/local/etc/rc.d/named
either. So it seems evaluation of rcorder(8) is changed between
12.2-RELASE and 13.0-RELEASE.

Then is there any way to make 'named' rc script invoked earlier at
boot time on 13.0-RELEASE?

Best Regards.

---
Yasuhiro Kimura
___
freebsd-ports@freebsd.

Re: Ports recompile for 13.0-RELEASE

[Chris]

On 2021-05-04 07:10, @lbutlr wrote:
With the move to FreeBSD 13.0 is there a simple (single step) way to 
reinstall all
the current ports other than saving off a list of the ports and then 
stepping
through that list to reinstall them? It was very inefficient when moving to 
12.0
as many ports in the list, of course, were dependent on other ports, but 
then got
recompiled, sometimes multiple times. I know I ended up in a make loop where 
came
was compiled over and over again until I aborted, listed the current ports, 
differ
on the previous ports, and picked a port I though would have a lot of reps 
to
restart the compile. I then did this several more times to get back to where 
I had

been on 11.x

And there's still no way to tell if a port was installed from pkg or from 
ports,
correct? Since I use MariaDB instead of MySQLI have to be sure I don't try 
to use

package for anything that will try to install MySQL instead.

And finally, the release of 13.0 ends the 12.x versions, right? There will 
not be a 12.3.


(And yes, I've tried moving to poudrerie several times and we do not get on. 
At all.)
Not a big fan of poudrerie. If I must, I generally choose synth. But try to 
avoid both
if at all possible. jail(8) is my go-to for most things they try to 
facilitate.
While this isn't the simple "set it, and forget it" solution you seek. I find 
that
picking a meta-port/package as part of something I'm installing, gets me 
pretty close

to all I need.
The key to my method is the "recursive" keyword. IOW
# cd /usr/ports/x11/xorg/
# make config-recursive (repeat this until dialog stops appearing)
When complete
# make package-recursive (install) clean
If I'm in my build jail and have a /usr/ports/packages/(All|latest)
I (ultimately) end up with a nice package repo that facilitates an image 
install

or upgrade path from a fresh install.

HTH

--Chris
___
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: Making a port to use OpenSSL of ports collection on FreeBSD 11.x

[Chris]

On 2021-05-05 07:22, Yasuhiro Kimura wrote:

From: Michael Gmelin 
Subject: Re: Making a port to use OpenSSL of ports collection on FreeBSD 
11.x

Date: Tue, 4 May 2021 23:05:06 +0200


See https://docs.freebsd.org/en/books/porters-handbook/uses/#uses-ssl

Best


I checked it but couldn't find proper solution.

I think what is necessary in my case is something like version-spec
argument of 'USES=python'.

For example, if 'USES=python:3.8+' is specified in Makefile of a port,
lang/python38 is used for it even if user sets
'DEFAULT_VERSIONS+=python=3.7' in /etc/make.conf.

But 'USES=ssl' doesn't provide such argument.

I ran into a similar situation requiring freebsd 11 users not use
SSL from base, and I simply used a conditional based against freebsd
version, that also included a RUN_DEPENDS on security/openssl
Wouldn't that work in your case?

--Chris


---
Yasuhiro Kimura
___
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: Making a port to use OpenSSL of ports collection on FreeBSD 11.x

[Chris]

On 2021-05-05 09:10, Yasuhiro Kimura wrote:

From: Chris 
Subject: Re: Making a port to use OpenSSL of ports collection on FreeBSD 
11.x

Date: Wed, 05 May 2021 08:03:00 -0700


I ran into a similar situation requiring freebsd 11 users not use
SSL from base, and I simply used a conditional based against freebsd
version, that also included a RUN_DEPENDS on security/openssl
Wouldn't that work in your case?

--Chris


Probably only adding security/openssl to *_DEPENDS isn't enough. If
you look at Mk/Uses/ssl.mk, you'll find the path of include files and
libraries are customized depending on which ssl stack is used. So you
also need to add similar custimizetion in Makefile of port avoding
conflicts with the settings in Mk/Uses/ssl.mk. And it must be hard
job.

Well unless something has changed significantly in that regard over
the last couple mos. I found it was enough to trap ${OSREL:R} targeting
11 && within that conditional add ssl=openssl
It worked a treat. You may find some additional clues in
bsd.default-versions.mk

HTH

--Chris


---
Yasuhiro Kimura
___
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: Making a port to use OpenSSL of ports collection on FreeBSD 11.x

[Chris]

On 2021-05-05 20:49, Dima Panov wrote:

Moin!

Chris, your suggestion leads to dll hell due to mix-links between ssl 
libraries :(
At least, your setup easily face up situation where one lib will be built 
with
“port openss” and consumers still get a “base openssl”. DEFAULT_VERSION here 
is
set to avoid a such situation — the whole ports collection should be linked 
with

ONE ssl/crypto library.
I agree. After posting my proposed solution. I was finally able to find 
_which_ of
the ports I did it in. Fortunately, it was an isolated case. Which got me to 
thinking
that _this_ case here had far reaching ramifications. I would have withdrawn 
my

suggestion. But you beat me to it. ;-)

Thanks for the reply (and correction), Dima!

--Chris


--
Dima. (desktop, kde, x11, office, ports-secteam)@FreeBSD team
(flu...@freebsd.org, https://t.me/dima_panov)

On Thursday, May 06, 2021 at 6:26 AM, Chris (mailto:portmas...@bsdforge.com)> wrote:

On 2021-05-05 09:10, Yasuhiro Kimura wrote:
> From: Chris 
> Subject: Re: Making a port to use OpenSSL of ports collection on FreeBSD
> 11.x
> Date: Wed, 05 May 2021 08:03:00 -0700
>
> > I ran into a similar situation requiring freebsd 11 users not use
> > SSL from base, and I simply used a conditional based against freebsd
> > version, that also included a RUN_DEPENDS on security/openssl
> > Wouldn't that work in your case?
> >
> > --Chris
>
> Probably only adding security/openssl to *_DEPENDS isn't enough. If
> you look at Mk/Uses/ssl.mk, you'll find the path of include files and
> libraries are customized depending on which ssl stack is used. So you
> also need to add similar custimizetion in Makefile of port avoding
> conflicts with the settings in Mk/Uses/ssl.mk. And it must be hard
> job.
Well unless something has changed significantly in that regard over
the last couple mos. I found it was enough to trap ${OSREL:R} targeting
11 && within that conditional add ssl=openssl
It worked a treat. You may find some additional clues in
bsd.default-versions.mk

HTH

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

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

pkg-fallout: License not correctly defined: defining both LICENSE_FILE and LICENSE_TEXT is not allowed

[Chris]

I'm getting the following report from pkg-fallout@:
License not correctly defined: defining both LICENSE_FILE and LICENSE_TEXT is 
not allowed

for
x11-themes/kde-icons-nuovext2

HOWEVER the error returned by pkg-fallout@ makes absolutely no
sense at all, given the Makefile for the report contains only:

LICENSE=LGPL3
LICENSE_FILE=   ${WRKSRC}/COPYING

for the license section.
Please advise, or tell me how to fix the pkg builder.

Thanks!

--Chris
___
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-fallout: License not correctly defined: defining both LICENSE_FILE and LICENSE_TEXT is not allowed

[Chris]

On 2021-05-13 09:08, Christoph Moench-Tegeder wrote:

## Chris (portmas...@bsdforge.com):


HOWEVER the error returned by pkg-fallout@ makes absolutely no
sense at all, given the Makefile for the report contains only:


Foremost, that Makefile has an .include, and that's where the mess
(for this use case) happens.
From a quick glance, I'm not totally sure how that
kde-icons-noia/Makefile.icons makes sense in the grand scheme of
things (if it's that common functionality, should it live somewhere
in Mk? if it's relevant only for a very limited number of ports, should
it have some comments about that?), but the way it currently interacts
with your port is not that fine: in the very least, it overwrites
your LICENSE variables, which cannot be your intention. (Try
"make -V LICENSE" in kde-icons-nuovoext2).

Sorry. My bad. LGPL3 is now included in the current LICENSE Templates.
So LICENSE_FILE is redundant && pkg-fallout (the ports framework) was
trying to use a "clue bat" to tell me so. ;-)

Sorry for the noise, and thanks for taking the time to reply.

--Chris


Regards,
Christoph

___
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-fallout: License not correctly defined: defining both LICENSE_FILE and LICENSE_TEXT is not allowed

[Chris]

On 2021-05-14 14:19, Christoph Moench-Tegeder wrote:

## Chris (portmas...@bsdforge.com):


>  but the way it currently interacts
> with your port is not that fine: in the very least, it overwrites
> your LICENSE variables, which cannot be your intention. (Try
> "make -V LICENSE" in kde-icons-nuovoext2).
Sorry. My bad. LGPL3 is now included in the current LICENSE Templates.
So LICENSE_FILE is redundant && pkg-fallout (the ports framework) was
trying to use a "clue bat" to tell me so. ;-)


Absolutely not. Due to the included file, your port has not set
the LICENSE to "LGPL3" but to "theme". That is a severe problem,
you're not allowed to just put another license on that port. It's
also not "look at the Makefile, the intention is clear": the
LICENSE field ends up in the package, and there's no weaseling
around the problem.
Code bugs may be annoying, but "wrong license" is a mistake with
potential to awaken the lawyers. Fix it.

I'm confused by your reply.
The problem I'm addressing in this case; is that the following as
*always* worked for licenses which carried a copy in
${WRKSRC}/LICENSE_NAME:

LICENSE=LICENSE_TYPE
LICENSE_FILE=   ${WRKSRC}/LICENSE_NAME

however. I've recently been plagued with complaints from pkg-fallout:

===>  License not correctly defined: defining both LICENSE_FILE and 
LICENSE_TEXT is not allowed

make: exec(exit) failed (No such file or directory)
*** Error code 1

When using that strategy. Sure enough; when performing a make test
on the problem port. I get roughly the same ERROR. Curious I thought.
Something in the ports framework must have changed. fe;

LICENSE=LGPL3
LICENSE_FILE=   ${WRKSRC}/COPYING

fails. EVEN though the file ${WRKSRC}/COPYING exists.
ALSO; LICENSE_FILE *and* LICENSE_TEXT are not BOTH defined, as stated
in the ERROR output.

Removing LICENSE_FILE returns; no problems with port.

So there you have it. The long version. :-)


you're not allowed to just put another license on that port.

I'm not. It's a verbatim LGPL3 port && license as reported
within the port' source. :-)


Code bugs may be annoying, but "wrong license" is a mistake with
potential to awaken the lawyers.

I'm well versed in law, and I've performed nothing contrary to the
ports' source' intent. :-)

--Chris



Regards,
Christoph

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