FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

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

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

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


Port| Current version | New version
+-+
net/yami4   | 1.10.2  | 1.11.0
+-+


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

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

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

Re: GSoC: Separation of Ports Build Process from Local Installation

[Peter Pentchev]

On Tue, May 28, 2019 at 08:28:41PM -0700, Rodney W. Grimes wrote:
> [ Charset UTF-8 unsupported, converting... ]
> > Hello All,
> > 
> > For Google Summer of Code 2019 I am working on FreeBSD's ports tree 
> > makefiles towards eliminating the dependency of the ports building 
> > process on the local system's installed packages.? Currently this level 
> > of separation can only be accomplished in practice through chroot or 
> > Jail.? The project will eliminate the need for cooperation of the root 
> > user since /usr/local will not need to be touched.
> > 
> > The major technical obstacle to be overcome is that ports expect to find 
> > files of their dependencies installed in /usr/local.? To support this 
> > without touching that location on the installed system, file accesses 
> > will be redirected to a location controlled by the ports build process 
> > through use of a library to intercept file accesses.
> 
> Assumption of /usr/local was considered wrong long long ago and it
> should always be ${PREFIX}.  Any place that actually assumes this
> value to be /usr/local should be fixed.
> 
> Had this policy been properly maintained it would simply be a mater
> of changing ${PREFIX} to a new and empty place before starting
> a ports build and things should of just worked.
> 
> Restoration to this ancient and functional behavior is desirable
> at least on my part.

Hmm, I could be wrong, but isn't ${LOCALBASE} supposed to be where
ports find stuff *during the build*, and ${PREFIX} where they
install the built files?  Of course, I haven't actually touched
a FreeBSD ports build in years, so I might very likely be wrong.
I also seem to remember a series of test port builds done a long
time ago with a different value for LOCALBASE, specifically to catch
ports that do not honor the policy in this regard.

> > Once I have that working (well enough to build one port at a time) I 
> > will move on to modify bsd.port.mk itself (and related files) to utilize 
> > this mechanism for virtual installation of port dependencies during builds.
> > 
> > The full project proposal can be seen at 
> > https://docs.google.com/document/d/1B30U9csgY299W59tNraSX1LYjzsba2i04OrYAUpdIZs/edit
> >  
> > .
> > 
> > My goal is that this work can be integrated well enough into 
> > /usr/ports/Mk so that unlike Jail, no set up work should be required for 
> > using ports tree to build a set of installable packages.
> > 
> > Please let me know if you are interested in this project; feedback is 
> > appreciated.? If someone would like to provide ongoing feedback or 
> > mentorship that would be especially helpful.? Bakul Shah is my mentor 
> > officially for GSoC but I would be happy to have additional support from 
> > someone who is experienced with internals of the port infrastructure 
> > makefiles.

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

[patch] [maintainer timeout, ~90 days] Bug 230753 - comms/minicom: Change minicom's permissions for security reasons

[Samy Mahmoudi]

Dear committer,

Could you please commit the changes associated with Bug 230753
.

Best regards,
Samy Mahmoudi
___
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: GSoC: Separation of Ports Build Process from Local Installation

[Matthew Seaman]

On 29/05/2019 10:56, Peter Pentchev wrote:

Hmm, I could be wrong, but isn't ${LOCALBASE} supposed to be where
ports find stuff*during the build*, and ${PREFIX} where they
install the built files?  Of course, I haven't actually touched
a FreeBSD ports build in years, so I might very likely be wrong.
I also seem to remember a series of test port builds done a long
time ago with a different value for LOCALBASE, specifically to catch
ports that do not honor the policy in this regard.


No, you are correct.  The LOCALBASE setting is where the ports will look 
for build dependencies.  However, the problem here is there is no 
guarrantee that the LOCALBASE value will not somehow be compiled into a 
resulting package (eg. as RPATH for dynamically loading a shlib) so 
would also be needed for runtime dependencies.


Being able to build with a custom value of LOCALBASE and then install 
and run the resulting package onto a system using different value for 
PREFIX would be an interesting piece of work.  The applicability would 
be people that custom build their own ports, but who are for some reason 
unable or unwilling to set up some sort of clean-build environment. 
This does strike me as an awful lot of work to solve a perceived problem 
where we do already have some pretty good solutions in place, but not to 
everybodies' taste.


Cheers,

Matthew



___
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: GSoC: Separation of Ports Build Process from Local Installation

[Stefan Esser]

Am 29.05.19 um 00:51 schrieb Theron:
> Hello All,
> 
> For Google Summer of Code 2019 I am working on FreeBSD's ports tree makefiles
> towards eliminating the dependency of the ports building process on the local
> system's installed packages.  Currently this level of separation can only be
> accomplished in practice through chroot or Jail.  The project will eliminate
> the need for cooperation of the root user since /usr/local will not need to be
> touched.
> 
> The major technical obstacle to be overcome is that ports expect to find files
> of their dependencies installed in /usr/local.  To support this without
> touching that location on the installed system, file accesses will be
> redirected to a location controlled by the ports build process through use of
> a library to intercept file accesses.
> 
> Once I have that working (well enough to build one port at a time) I will move
> on to modify bsd.port.mk itself (and related files) to utilize this mechanism
> for virtual installation of port dependencies during builds.
> 
> The full project proposal can be seen at
> https://docs.google.com/document/d/1B30U9csgY299W59tNraSX1LYjzsba2i04OrYAUpdIZs/edit
> .

What's wrong with using chroot to provide a clean build environment?

That is what synth does, and I have been using my re-implementation of
portmaster for this purpose for some time, which uses a chroot jail with
read-only null-mounts of all relevant file systems and a clean copy of
some files and directories in /etc and /var that can be written without
root privileges. The jail is set up in not measurable time (irrelevant
compared to the time required to build the port).

The only problem with this approach is that it requires extra disk space
for the build environment (e.g., the specific C compiler required by some
port) plus the work space for the actual port build process. I'm using
tmpfs file systems within the jail for the work directory and the copies
of parts of /etc and /var that need to be written to.

Is there a risk of mis-use of the interception library to attack the
system, BTW?

[Its use is not restricted to root and it might be used to re-map file
system paths for commands that check e.g. policy files to decide whether
some operation is authorized ... SUID programs should not be vulnerable
to such an attack (since they do not allow the library pre-load required
to intercept the file operations), but there might be application programs
that are restricted by non-writable files in hard-coded directories that
could be subverted this way ... (such a command would be ill-designed,
since any user could compile her own interception library, but providing
such a library with the system and possibly having hooks for it in libc
might simplify such an attack, especially if there is no compiler and
easy way to install such a library on a host).]

> My goal is that this work can be integrated well enough into /usr/ports/Mk so
> that unlike Jail, no set up work should be required for using ports tree to
> build a set of installable packages.

Yes, this might be beneficial. But there will be huge differences
compared to the current build process. And in the end you'll probably
have to put the logic used by, e.g., portmaster to track dependencies
and determine the availability of up-to-date packages (to use as build
dependencies) into the ports system.

> Please let me know if you are interested in this project; feedback is
> appreciated.  If someone would like to provide ongoing feedback or mentorship
> that would be especially helpful.  Bakul Shah is my mentor officially for GSoC
> but I would be happy to have additional support from someone who is
> experienced with internals of the port infrastructure makefiles.

I'd be interested to get further information about your approach and
the progress you make and my experience working on a somewhat similar
project with portmaster might allow me to answer questions or provide
some help ...

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"

openjdk11 and openjdk12 doesn't build

[Wojciech Puchar]

below typescript. please help
FreeBSD puchar.net 11.3-PRERELEASE FreeBSD 11.3-PRERELEASE #0 r347617: Sat 
May 18 19:54:54 CEST 2019 
r...@puchar.net:/h/backup1/src/sys/amd64/compile/puchar  amd64




===>  License GPLv2 accepted by the user
===>   openjdk12-12.0.1+12.2 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by openjdk12-12.0.1+12.2 for building
===>  Extracting for openjdk12-12.0.1+12.2
=> SHA256 Checksum OK for battleblow-openjdk-jdk12u-jdk-12.0.1+12-2_GH0.tar.gz.
===>  Patching for openjdk12-12.0.1+12.2
===>  Applying FreeBSD patches for openjdk12-12.0.1+12.2
===>   openjdk12-12.0.1+12.2 depends on executable: zip - found
===>   openjdk12-12.0.1+12.2 depends on package: autoconf>0 - found
===>   openjdk12-12.0.1+12.2 depends on file: /usr/local/include/cups/cups.h - 
found
===>   openjdk12-12.0.1+12.2 depends on executable: bash - found
===>   openjdk12-12.0.1+12.2 depends on executable: gmake - found
===>   openjdk12-12.0.1+12.2 depends on package: libiconv>=1.14_11 - found
===>   openjdk12-12.0.1+12.2 depends on package: pkgconf>=1.3.0_1 - found
===>   openjdk12-12.0.1+12.2 depends on file: 
/usr/local/libdata/pkgconfig/x11.pc - found
===>   openjdk12-12.0.1+12.2 depends on file: 
/usr/local/libdata/pkgconfig/xext.pc - found
===>   openjdk12-12.0.1+12.2 depends on file: 
/usr/local/libdata/pkgconfig/xi.pc - found
===>   openjdk12-12.0.1+12.2 depends on file: 
/usr/local/libdata/pkgconfig/xrandr.pc - found
===>   openjdk12-12.0.1+12.2 depends on file: 
/usr/local/libdata/pkgconfig/xrender.pc - found
===>   openjdk12-12.0.1+12.2 depends on file: 
/usr/local/libdata/pkgconfig/xt.pc - found
===>   openjdk12-12.0.1+12.2 depends on file: 
/usr/local/libdata/pkgconfig/xtst.pc - found
===>   openjdk12-12.0.1+12.2 depends on shared library: libasound.so - found 
(/usr/local/lib/libasound.so)
===>   openjdk12-12.0.1+12.2 depends on shared library: libfontconfig.so - 
found (/usr/local/lib/libfontconfig.so)
===>   openjdk12-12.0.1+12.2 depends on shared library: libfreetype.so - found 
(/usr/local/lib/libfreetype.so)
===>   openjdk12-12.0.1+12.2 depends on shared library: libgif.so - found 
(/usr/local/lib/libgif.so)
===>   openjdk12-12.0.1+12.2 depends on shared library: liblcms2.so - found 
(/usr/local/lib/liblcms2.so)
===>   openjdk12-12.0.1+12.2 depends on shared library: libpng16.so - found 
(/usr/local/lib/libpng16.so)
===>   openjdk12-12.0.1+12.2 depends on shared library: libjpeg.so - found 
(/usr/local/lib/libjpeg.so)
===>  Configuring for openjdk12-12.0.1+12.2
Warning: You are using legacy autoconf cross-compilation flags.
It is recommended that you use --openjdk-target instead.

configure: loading site script /usr/ports/Templates/config.site
configure: Configuration created at Wed May 29 15:46:45 UTC 2019.
checking for basename... /usr/bin/basename
checking for bash... /usr/local/bin/bash
checking for cat... /bin/cat
checking for chmod... /bin/chmod
checking for cmp... /usr/bin/cmp
checking for comm... /usr/bin/comm
checking for cp... /bin/cp
checking for cut... /usr/bin/cut
checking for date... /bin/date
checking for gdiff... no
checking for diff... /usr/bin/diff
checking for dirname... /usr/bin/dirname
checking for echo... /bin/echo
checking for expr... /bin/expr
checking for file... /usr/bin/file
checking for find... /usr/bin/find
checking for head... /usr/bin/head
checking for gunzip... /usr/bin/gunzip
checking for pigz... (cached) /usr/bin/gzip
checking for ln... /bin/ln
checking for ls... /bin/ls
checking for gmkdir... no
checking for mkdir... /bin/mkdir
checking for mktemp... /usr/bin/mktemp
checking for mv... /bin/mv
checking for nawk... /usr/bin/nawk
checking for printf... /usr/bin/printf
checking for greadlink... no
checking for readlink... /usr/bin/readlink
checking for rm... /bin/rm
checking for rmdir... /bin/rmdir
checking for sh... /bin/sh
checking for sort... /usr/bin/sort
checking for tail... /usr/bin/tail
checking for gtar... no
checking for tar... /usr/bin/tar
checking for tee... /usr/bin/tee
checking for touch... /usr/bin/touch
checking for tr... /usr/bin/tr
checking for uname... /usr/bin/uname
checking for uniq... /usr/bin/uniq
checking for wc... /usr/bin/wc
checking for which... /usr/bin/which
checking for xargs... /usr/bin/xargs
checking for gawk... (cached) /usr/bin/awk
checking for grep that handles long lines and -e... (cached) /usr/bin/grep
checking for egrep... (cached) /usr/bin/egrep
checking for fgrep... (cached) /usr/bin/fgrep
checking for a sed that does not truncate output... (cached) /usr/bin/sed
checking for cygpath... no
checking for df... /bin/df
checking for cpio... /usr/bin/cpio
checking for nice... /usr/bin/nice
checking for pandoc... no
checking build system type... amd64-portbld-freebsd11.3
checking host system type... amd64-portbld-freebsd11.3
checking target system type... amd64-portbld-freebsd11.3
checking openjdk-build os-cpu... bsd-x86_64
checking openjdk-target os-cpu... bsd-x86_64
checking openjdk-target os-env.

Re: games/dMagnetic: A new Port (Need help)

[Grzegorz Junka]

On 20/05/2019 07:14, dettus wrote:

Hello.

SInce the ports@ mailinglist seems to strip away attachments (as it 
should), I uploaded the port to my website.
Please download it at 
http://www.dettus.net/dMagnetic/freebsd_games_dMagnetic.tar.gz
sha256: 
df886bd85e30dc983ae7ab8d441db779355c63fe14c2117797c9889f23a9a00a, 
size=987 bytes.



Thomas Dettbarn

On 5/20/19 4:17 AM, dettus wrote:

Hello.


My name is Thomas Dettbarn. Two of my projects editors/dhex and 
games/nInvaders have already found their way into the FreeBSD ports.
Currently, I am working on dMagnetic, A Magic Scrolls Interpreter. 
This one lets you play classic text adventures such as "The Pawn" or
"The Guild of Thieves" in a terminal. (As well as "Fish!", "Myth", 
"Corruption", "Jinxter" and "Wonderland")


You can see some of the BEAUTIFUL screenshots on my website: 
http://www.dettus.net/dMagnetic. Please have a look.




For this, I created the inkling of an already working FreeBSD port. 
You should find it attached to this email.


Since I primarily see myself as a "developer", rather than a 
"maintainer", I would like to hand this one of to someone more 
experienced.
Plus, I had some issues when I tried adding extra files such as the 
README.txt or an .ini file to the do-install target.



so, please please help me out here guys! It would be an honor.


Thomas Dettbarn




Hi Thomas,

Is the intention of your email to find someone willing to add the games 
to ports? If yes, could mich, the current maintainer of your game (CC'd) 
be a good first contact?


Also, not sure how much traffic is on freebsd-ga...@freebsd.org but that 
might be another option when trying to find a maintainer.


GrzegorzJ


___
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: GSoC: Separation of Ports Build Process from Local Installation

[Cy Schubert]

On May 28, 2019 3:51:08 PM PDT, Theron  wrote:
>Hello All,
>
>For Google Summer of Code 2019 I am working on FreeBSD's ports tree 
>makefiles towards eliminating the dependency of the ports building 
>process on the local system's installed packages.  Currently this level
>
>of separation can only be accomplished in practice through chroot or 
>Jail.  The project will eliminate the need for cooperation of the root 
>user since /usr/local will not need to be touched.
>
>The major technical obstacle to be overcome is that ports expect to
>find 
>files of their dependencies installed in /usr/local.  To support this 
>without touching that location on the installed system, file accesses 
>will be redirected to a location controlled by the ports build process 
>through use of a library to intercept file accesses.
>
>Once I have that working (well enough to build one port at a time) I 
>will move on to modify bsd.port.mk itself (and related files) to
>utilize 
>this mechanism for virtual installation of port dependencies during
>builds.
>
>The full project proposal can be seen at 
>https://docs.google.com/document/d/1B30U9csgY299W59tNraSX1LYjzsba2i04OrYAUpdIZs/edit
>
>.
>
>My goal is that this work can be integrated well enough into 
>/usr/ports/Mk so that unlike Jail, no set up work should be required
>for 
>using ports tree to build a set of installable packages.
>
>Please let me know if you are interested in this project; feedback is 
>appreciated.  If someone would like to provide ongoing feedback or 
>mentorship that would be especially helpful.  Bakul Shah is my mentor 
>officially for GSoC but I would be happy to have additional support
>from 
>someone who is experienced with internals of the port infrastructure 
>makefiles.
>
>Theron Tarigo
>___
>freebsd-hack...@freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>To unsubscribe, send any mail to
>"freebsd-hackers-unsubscr...@freebsd.org"

How is this different from what poudriiere already does?


-- 
Pardon the typos and autocorrect, small keyboard in use.
Cheers,
Cy Schubert 
FreeBSD UNIX:  Web: http://www.FreeBSD.org

The need of the many outweighs the greed of the few.
___
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"

net-mgmt/zabbix4-server ipmi poller eats all CPU

[Miroslav Lachman]

I upgraded Zabbix server from 4.0.4 to 4.0.7 and right after "service 
zabbix_server restart" zabbix starts to eat all CPU


last pid:  4696;  load averages:  2.11,  2.39,  2.24up 0+00:35:43 
14:00:17

84 processes:  2 running, 82 sleeping
CPU: 32.7% user,  0.0% nice, 67.3% system,  0.0% interrupt,  0.0% idle
Mem: 312M Active, 126M Inact, 281M Wired, 200M Buf, 1243M Free
Swap: 1024M Total, 1024M Free

  PID USERNAMETHR PRI NICE   SIZERES STATETIMEWCPU COMMAND
  899 zabbix1  810 63268K 14008K RUN 10:40  98.85% 
zabbix_server: ipmi poller #2 [polled 5 values, idle 5.055918 sec during 
5.080817 sec] (zabbix_server)

  769 mysql57  200   540M   202M select   0:09   0.25% [mysqld]


I tried to restart Zabbix and reboot of the machine (VM in VirtualBox) 
but no change.


Are there somebody running Zabbix server 4.0.7 with IPMI pollers without 
this CPU issues?


The CPU was almost idle before upgrade.

More details can be found in this PR 238224
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238224

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

Re: GSoC: Separation of Ports Build Process from Local Installation

[Lorenzo Salvadore via freebsd-ports]

> On 29/05/2019 10:56, Peter Pentchev wrote:
>
> > Hmm, I could be wrong, but isn't ${LOCALBASE} supposed to be where
> > ports find stuffduring the build, and ${PREFIX} where they
> > install the built files? Of course, I haven't actually touched
> > a FreeBSD ports build in years, so I might very likely be wrong.
> > I also seem to remember a series of test port builds done a long
> > time ago with a different value for LOCALBASE, specifically to catch
> > ports that do not honor the policy in this regard.
>
> No, you are correct. The LOCALBASE setting is where the ports will look
> for build dependencies. However, the problem here is there is no
> guarrantee that the LOCALBASE value will not somehow be compiled into a
> resulting package (eg. as RPATH for dynamically loading a shlib) so
> would also be needed for runtime dependencies.

Indeed, I maintain a port where LOCALBASE is a value that appears in the
resulting package's files (not as RPATH): math/maxima. See its Makefile at
line 65.


> Being able to build with a custom value of LOCALBASE and then install
> and run the resulting package onto a system using different value for
> PREFIX would be an interesting piece of work. The applicability would
> be people that custom build their own ports, but who are for some reason
> unable or unwilling to set up some sort of clean-build environment.
> This does strike me as an awful lot of work to solve a perceived problem
> where we do already have some pretty good solutions in place, but not to
> everybodies' taste.

Here again I can give an example of someone who does not want any
clean-build environment: myself. My machine is pretty old, cpu is slow,
ram is low and poudriere gets annoying on it: it needs to install and deinstall
plenty of dependencies for each single new package it builds. My solution
at the moment is using ports keeping all the build depenencies always installed.
However, if I understood the project correctly, I fear it would not offer a
useful alternative in my case.

Lorenzo Salvadore.
___
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: GSoC: Separation of Ports Build Process from Local Installation

[Theron]

On 2019-05-29 09:49, Matthew Seaman wrote:

On 29/05/2019 10:56, Peter Pentchev wrote:

Hmm, I could be wrong, but isn't ${LOCALBASE} supposed to be where
ports find stuff*during the build*, and ${PREFIX} where they
install the built files?  Of course, I haven't actually touched
a FreeBSD ports build in years, so I might very likely be wrong.
I also seem to remember a series of test port builds done a long
time ago with a different value for LOCALBASE, specifically to catch
ports that do not honor the policy in this regard.


No, you are correct.  The LOCALBASE setting is where the ports will 
look for build dependencies.  However, the problem here is there is no 
guarrantee that the LOCALBASE value will not somehow be compiled into 
a resulting package (eg. as RPATH for dynamically loading a shlib) so 
would also be needed for runtime dependencies. 
LOCALBASE does control where ports find their dependencies at build 
time, but it is not the only purpose.  There is, as best I can tell, no 
kind of separation between LOCALBASE as location to find files at 
compile time vs. at run time.  LOCALBASE serves the same effective 
purpose as PREFIX, except that the separation is maintained so that a 
port can use some other PREFIX in special cases.  Therefore it seems 
reasonable to me to leave the established meaning of LOCALBASE as-is and 
to use a different mechanism for accessing the dependency install 
location at build time.
Besides, hijacking LOCALBASE is not really an option, since there are 
existing tests such as:

.if (${PREFIX} != ${LOCALBASE} && ${PREFIX} != ${LINUXBASE} && \
which seem reasonable to me.

On 2019-05-29 05:56, Peter Pentchev wrote:

I also seem to remember a series of test port builds done a long
time ago with a different value for LOCALBASE, specifically to catch
ports that do not honor the policy in this regard.
I will be doing a similar test, using syscall tracing, to check that 
nothing reads from the real ${LOCALBASE} during building.


On 2019-05-29 17:42, Lorenzo Salvadore via freebsd-ports wrote:

Indeed, I maintain a port where LOCALBASE is a value that appears in the
resulting package's files (not as RPATH): math/maxima. See its Makefile at
line 65.

Indeed, many other ports as well make this kind of assumption.


___
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: games/dMagnetic: A new Port (Need help)

[dettus]

Hello Grzegorz,

On 5/29/19 7:35 PM, Grzegorz Junka wrote:


Hi Thomas,

Is the intention of your email to find someone willing to add the 
games to ports? If yes, could mich, the current maintainer of your 
game (CC'd) be a good first contact?


Also, not sure how much traffic is on freebsd-ga...@freebsd.org but 
that might be another option when trying to find a maintainer.


GrzegorzJ


No, my intention of the original mail was to find ANYBODY willing to add 
my game to the ports. ;)


Anyways, it has been added, and I could not be more proud! I have 
learned a lot since then. But thank you!!



Thomas


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