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

[Eugene Grosbein]

06.05.2021 10:49, Dima Panov wrote:

> 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 disagree. There is no reason for "leaf" ports to depend on ports version of 
openssl
and this is impossible in come cases. For example, net/mpd5 port that links 
with base libfetch
that links with base openssl. So, net/mpd5 must NOT be linked with ports openssl
and frankly, it needs not.

Global inflexible knob for whole ports tree is bad thing.

___
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: looking for port origin for executable

[Eugene Grosbein]

05.05.2021 0:28, Piotr Smyrak wrote:

>>  Would some kind soul please tell me which port installs the
>> executable "g-ir-scanner"?  I was purging unused ports and seem to
>> have done this one by mistake.
> 
> When I hit a wall like this, this is my usual way to get around without
> any additional tools:
> 
> $ find /usr/ports -name pkg-plist | xargs grep -l bin/g-ir-scanner

Or just: locale g-ir-scanner
Which is much faster as it uses indexed /var/db/locate.database


___
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

[Eugene Grosbein]

30.04.2021 14: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'.
> 
> Now let me use 'ntpdate' as an example.

named sometimes *requires* correct time to be set before it is started,
so you should either use some IP addressess for NTP bootstrapping at boot time,
or put NTP server hostname to /etc/hosts with its IP, so it resolves before 
named fires.


___
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

[Eugene Grosbein]

07.08.2020 18:10, Ashish SHUKLA wrote:

> Is there a similar seed file for subversion snapshot, that one can
> download, extract, and "svn up" ?
> 
> I was trying to "svn co" the ports tree, and it keeps dying in the
> middle of checkout every few minutes.

ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/

Last updated Feb 26 2020, though. Still usable for update to current state.


___
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

[Eugene Grosbein]

06.08.2020 13:23, Doug Hardie wrote:

>> On 5 August 2020, at 21:30, Eugene Grosbein  wrote:
>>
>> 06.08.2020 6:02, Tatsuki Makino wrote
>> :
>>> Is there any command other than "rm -rf /usr/ports ; portsnap extract"
>>> that can be easily repaired?
>>
>> svnlite revert -R /usr/ports
> 
> 
> master# svnlite revert -R /usr/ports
> svn: E155007: '/usr/ports' is not a working copy
> master# 
> master# rm -rf /usr/ports/*
> master# svnlite revert -R /usr/ports
> svn: E155007: '/usr/ports' is not a working copy

If portsnap's deprecated, one uses "svnlite checkout" to replace portsnap's data
with data of Subversion, then "svnlite revert" would work.

___
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

[Eugene Grosbein]

06.08.2020 6:02, Tatsuki Makino wrote
:
> Is there any command other than "rm -rf /usr/ports ; portsnap extract"
> that can be easily repaired?

svnlite revert -R /usr/ports

___
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 and less

[Eugene Grosbein]

01.08.2020 3:24, @lbutlr wrote:

> When postmaster displays the package messages after installing, it calls 
> less, which forces you to hit 'q' to exit, and when you quit less, it clear 
> the buffer on the screen and returns you to the display of the compile 
> process.
> 
> Is there anyway to change this behavior so that less is called with -E / 
> --QUIT-AT_EOF?

Yes: 

export MORE="-E"
or
export LESS="-E"

Our "more" command is another name (link) for "less" modifying its behaviour.

___
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: Makefile practice

[Eugene Grosbein]

11.07.2020 1:23, Harry Newton wrote:

> I look after a port that has a poor Makefile [the one supplied with the
> distribution, not the FreeBSD port Makefile].  The principal problem is
> where it installs things.
> 
> To get the port to do the right thing, I could either: heavily patch the
> supplied Makefile or: move files around in the stage tree.
> 
> Could someone give me a steer about recommended practice ?

It's up to porter. I tend to keep things simple: if moving files around
in the stage tree is simplier, do it with post-install target of the port.
We have large number of examples in the ports tree of post-install usage.

If it is simplier with small correction of software's Makefile or Makefile.in 
correcting DESTDIR,
do it with a patch or post-patch target of the port.

___
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: accel-ppp

[Eugene Grosbein]

19.06.2020 0:34, The Doctor via freebsd-ports wrote:

> Wonder if my mpd5.conf is configured properly?

It depends on your goals as mpd5 is versatile. It has extensive logging and 
documentaion.


___
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: accel-ppp

[Eugene Grosbein]

19.06.2020 0:35, Kurt Jaeger wrote:

> Which project is better maintained ?
> 
> mpd5 had it's latest release in 2016, but commits until recently.
> accel-ppp had it's latest release in August 2019 and also commits
> until recently.

mav@ and myself commit to upstream repo as needed, and there is another one 
person.
I maintain the port also.

___
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: accel-ppp

[Eugene Grosbein]

19.06.2020 0:09, The Doctor via freebsd-ports wrote:

> Would anyone like to help me port this application?
> 
> Very Linux based but coould be BSD convertible.
> 
> 
> It would make a good addition to the net ports.

We already have net/mpd5 in ports for this task.


___
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 9.16 port error still lingers

[Eugene Grosbein]

03.05.2020 0:29, The Doctor via freebsd-ports wrote:

> Then let's look at the file:

[skip]

Quickest way to unbreak your server: take default named.conf from the 
installation of version 9.16
and add your changes to it manually but keep default paths within lines 
"pid-file" and alike.
That is, keep changes to default file as small as possible.

___
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 9.16 port error still lingers

[Eugene Grosbein]

03.05.2020 1:13, Per olof Ljungmark wrote:

> On 2020-05-02 19:29, The Doctor via freebsd-ports wrote:
>> On Sat, May 02, 2020 at 06:53:18PM +0200, Christoph Moench-Tegeder wrote:
>>> ## The Doctor via freebsd-ports (freebsd-ports@freebsd.org):
> [snip]
> 
>> //Use with the following in named.conf, adjusting the allow list as needed:
>> key "rndc-key" {
>>algorithm hmac-md5;
>> secret "7ZbGK94NdSa2WACxx72W1w==";
> 
> I suggest you change this ^ rather quickly, especially if it is a public 
> name server.

This is a key for local (over 127.0.0.1) connections for rndc,
it can be abused by local users only, or if there is remotely expoitable 
vulnerability
for running shell code. Still, should not be published so easily but no direct 
harm
when system has no untrusted local users.

___
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: openssl problem after 11 -> 12

[Eugene Grosbein]

14.04.2020 16:58, Per olof Ljungmark wrote:

> I am at loss right now on how I could teach the FBSD-12 system to use the 
> older ciphers, it still works fine from 11.

Easiest way would be untar'ing FreeBSD 11 base.txz into chroot area and copy 
your script there, too.
Then use chroot to pkg install perl5 to be able run the script inside chroot.


___
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: lsof marked ignored

[Eugene Grosbein]

21.03.2020 4:30, @lbutlr wrote:

> On 20 Mar 2020, at 14:10, Robert Huff  wrote:
>> Adam Weinberger writes:
>>
 ===>>> Currently installed version: lsof-4.93.2_9,8
 ===>>> Port directory: /usr/ports/sysutils/lsof

===>>> This port is marked IGNORE
===>>> requires kernel sources
>>>
>>> That error should only occur if system sources are missing from
>>> /usr/src. Check that they're still there, and if not then check them
>>> out from svn.
>>
>>  (Last time I checked )
>>  Not only does it require kernel sources, but those sources need
>> to match the running kernel.
> 
> Why was this changed (I did not install the source and my /usr/src/ directory 
> is empty and has been since I moved to 12.1)

Nothing changed really. lsof needs the whole file sys/fs/pseudofs/pseudofs.h
for struct pfs_node and all other parts (types etc.) it uses from same file
and it needs the definition of struct lock_owner from sys/kern/kern_lock.c.

It tastes some other files in sys/ to enable -DHAS_LOCKF_ENTRY -DHAS_PAUSE_SBT 
-DHAS_CDEV2PRIV -DHASFUSEFS -DHAS_ZFS
but does not really needs their contents, so these flags could be enabled 
unconditionally by the port.

So if we could "export" pseudofs.h and struct lock_owner to /usr/include, then 
lsof could be built
without need of kernel sources.


___
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: users of xorg, in particular on FreeBSD 11.3

[Eugene Grosbein]

21.03.2020 6:41, Niclas Zeising wrote:

> [ This is cross-posted across several mailing lists for maximum visibility.  
> Please respect reply-to and keep replies to x...@freebsd.org . Thank you! ]
> 
> In order to improve support when using evdev to manage input devices, in 
> particular keyboards, we have switched the default in x11/libxkbcommon to the 
> evdev instead of the legacy ruleset.  This was done in ports r528813 .
> 
> On FreeBSD 11.3, the default configuration still requires the legacy ruleset.
> 
> If you are using FreeBSD 11.3, or if you are using xf86-input-keyboard on 
> FreeBSD 12 or later, you need to change the ruleset used by x11/libxkbcommon.
> 
> If you have issues with your keyboard, most notably arrow keys, and if 
> /var/log/Xorg.*.log shows that the "kbd" or "keyboard" driver is being used, 
> you need to switch to legacy rules by setting the environment variable 
> XKB_DEFAULT_RULES to xorg.
> 
> The easiest way to accomplish this is by adding it to your shell startup file.
> 
> As an example, for users of [t]csh, put
>   setenv XKB_DEFAULT_RULES xorg
> in ~/.login
> 
> For users of bourne type shells (sh, bash, ksh, zsh, ...) instead put
> export XKB_DEFAULT_RULES=xorg
> in ~/.profile

Please consider improving x11/libxkbcommon so that it uses -Ddefault-rules=xorg
if OSVERSION notes 11.x at build time, so there would be no breakage for us 
building xorg from ports.

___
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: Good CLI BitTorrent client?

[Eugene Grosbein]

04.03.2020 21:12, @lbutlr wrote:

> Sice people are talking about GUI botttorrent clients, are there decent ones 
> that are CLI?

There is "transmission" acting like a daemon. You may manage it using CLI, or 
GUI, or web interface with any browser.

___
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: cereal: fails to build on pure 64 bit systems

[Eugene Grosbein]

25.01.2020 17:38, Hinnerk van Bruinehsen wrote:

> Hello,
> 
> the newly introduced build for cereal fails to build on my system,
> because I don't have 32 bit compatibility stuff enabled.
> 
> The failure is caused by the default settings of enabling portability
> testing. I have attached a patch that fixes this for me by disabling the
> portability tests.
> 
> I also disabled -WError for the build, because it caused a build failure
> (because of unused CFLAGS for the build, -pie in my case).
> Since this is a non default setting, I guess that the last change is
> debatable, but while I am a big fan of -WError during development, I
> think it's not that great for packaging/distribution.

Thanks! Fixed in r524136.

___
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: cereal: fails to build on pure 64 bit systems

[Eugene Grosbein]

25.01.2020 17:38, Hinnerk van Bruinehsen wrote:

> Hello,
> 
> the newly introduced build for cereal fails to build on my system,
> because I don't have 32 bit compatibility stuff enabled.
> 
> The failure is caused by the default settings of enabling portability
> testing. I have attached a patch that fixes this for me by disabling the
> portability tests.
> 
> I also disabled -WError for the build, because it caused a build failure
> (because of unused CFLAGS for the build, -pie in my case).
> Since this is a non default setting, I guess that the last change is
> debatable, but while I am a big fan of -WError during development, I
> think it's not that great for packaging/distribution.

I've committed cereal. I'll look at this.


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

Re: Build with "DEBUG" symbols

[Eugene Grosbein]

16.01.2020 23:31, Carmel NY пишет:
> Hypothetically, suppose I wanted to build my entire ports system with
> "debug" symbols; would putting:
> 
>   WITH_DEBUG_PORTS=*
> 
> in the "make.conf" file work?
> 
> Asking for a friend.

This should work for /etc/make.conf:

WITH_DEBUG=yes


___
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: replacement of security/ipsec-tools

[Eugene Grosbein]

On 03.01.2020 05:06, Michael Grimm wrote:

> I am running ipsec-tools to implement a VPN tunnel (esp) between two hosts 
> for years now.
> 
> But this statement on http://ipsec-tools.sourceforge.net makes me think about 
> an alternative:
>   The development of ipsec-tools has been ABANDONED. 
>   ipsec-tools has security issues, and you should not use it. Please 
> switch to a secure alternative! 
> 
> Could you provide me with links where I could find more details about the 
> above mentioned 'security issues'?

Our port of ipsec-tools has fixes for all known security issues (f.e. 
CVE-2016-10396),
so you may safely continue using it provided you have latest port/package.

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

Re: net-snmp crash

[Eugene Grosbein]

19.11.2019 4:22, Michael W. Lucas wrote:
> Hi,
> 
> I can reliably crash net-snmp with an snmpset. Worth a formal bug
> report?
> 
> $ uname -a
> FreeBSD freebsdtest 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 GENERIC  amd64
> 
> $ pkg info net-snmp
> net-snmp-5.7.3_20,1
> Name   : net-snmp
> Version: 5.7.3_20,1
> Installed on   : Wed Oct  9 15:22:24 2019 EDT
> ...
> 
> Detail:
> 
> $ sysctl net.inet.ip.forwarding
> net.inet.ip.forwarding: 0
> 
> $ snmpget freebsd IP-MIB::ipForwarding.0
> IP-MIB::ipForwarding.0 = INTEGER: notForwarding(2)
> 
> $ snmpset freebsd IP-MIB::ipForwarding.0 i 1
> Timeout: No Response from freebsd
> 
> Yep, the agent is dead:
> 
> $ pgrep snmpd
> $
> 
> The sysctl change took place, however:
> 
> $ sysctl net.inet.ip.forwarding
> net.inet.ip.forwarding: 1
> 
> I can restart the agent and reverse the change, but snmpd crashes
> again.
> 
> So: worth a bug report, or no?

Yes, and this should be easy to debug and fix provided net-snmpd port built 
WITH_DEBUG=yes to include debugging symbols
and coredumps enabled.




signature.asc
Description: OpenPGP digital signature

Re: Omg upgrade wants to install MySQL

[Eugene Grosbein]

On 03.11.2019 21:03, @lbutlr wrote:

>>> On 02 Nov 2019, at 19:35, Eugene Grosbein  wrote:
>>>> I prefer third option. Sometimes it is handy to "pkg lock" packages you 
>>>> installed from ports buiklt with non-default options, too.
>>>
>>> If I could tell which pkg install is going to install MySQL and libX stuff 
>>> I would lock those, but I Dion’t see anyway to check that.
>>
>> You need to lock MariaDB.
> 
> MariaDB *is* locked. Both client and server. Pkg update was still going to 
> install MySQL.

pkg has no choice, as official package repo contains packages built with MySQL 
dependency only.

>>> And it does seem odd that pkg is still assuming MySQL and desktop FreeBSD.
>>> I know of many 120 FreeBSD servers and not one has a GUI desktop.
>>> I mean, I am sure they exist, but they must be a pretty tiny sliver.
>>
>> First, it is NOT pkg assuming anything. Package repository has packages 
>> built from ports with their *default* options
>> and pkg merely uses them.
> 
> Fine. Ports assuming MySQL.

Yes. You still may change defaults and rebuild those ports yourself.
Same with X11 support.

___
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: Omg upgrade wants to install MySQL

[Eugene Grosbein]

03.11.2019 9:20, @lbutlr wrote:

> On 02 Nov 2019, at 19:35, Eugene Grosbein  wrote:
>> I prefer third option. Sometimes it is handy to "pkg lock" packages you 
>> installed from ports buiklt with non-default options, too.
> 
> If I could tell which pkg install is going to install MySQL and libX stuff I 
> would lock those, but I Dion’t see anyway to check that.

You need to lock MariaDB.

> And it does seem odd that pkg is still assuming MySQL and desktop FreeBSD.
> I know of many 120 FreeBSD servers and not one has a GUI desktop.
> I mean, I am sure they exist, but they must be a pretty tiny sliver.

First, it is NOT pkg assuming anything. Package repository has packages built 
from ports with their *default* options
and pkg merely uses them.

Second, support of X headers/formats/libraries does not assume "desktop" FreeBSD
and does not install any graphical environment but generally only some small 
headers or libs,
not even libX11 not to mention heavy window managers or desktop environment.




___
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: Omg upgrade wants to install MySQL

[Eugene Grosbein]

02.11.2019 20:48, @lbutlr wrote:

> I have mariadb101 (client and server) installed, but when looking at what pkg 
> update will do, one of the things it will do is install MySQL. Is there 
> something I need to do to tell it to use MariaDB instead?
> 
> Since I am here, it also wants to install a bunch of X11 packages, but I 
> neither want nor have any desktop environment installed, so similar question, 
> how can I tell pkg to run in “don’t enable GUIs” mode?

Your choices are:

- you may use default package repository and then you must use default package 
builting options and flavours,
e.g. MySQL and not MariaDB, packages built with X11 options enabled etc.;
- or you may use non-default packages (f.e. MariaDB instead of MySQL) and then 
you either build and
use your own package repository containing packages built with your preferences;
- or you just build some packages using ports while using default package 
repository for distinct
packages and don't use "pkg upgdate".

I prefer third option. Sometimes it is handy to "pkg lock" packages you 
installed from ports buiklt with non-default options, too.


___
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: Is IPV6 option still necessary?

[Eugene Grosbein]

On 07.10.2019 13:18, Yasuhiro KIMURA wrote:

> On October 10, 2012 IPV6 option of all ports was enabled by
> default. Commit message said "We are in 2012, it is time to activate
> IPV6 options by default everywhere".
> 
> And now we are in 2019. IPv6 is more widely used than 2012. So I
> wonder if IPV6 option is still necessary.
> 
> If you use official packages then you always use IPv6-enabled
> binaries. And even if you build packages by yourself you still use
> IPv6-enabled ones unless you disable IPV6 option. So I think at most
> only a few people uses IPv6-disabled packages.
> 
> Are there anybody who still disables IPV6 option for some serious
> reason such as working around IPv6-related problem? If there aren't
> then I think it's time to remove IPV6 option from ports framework.

Think about embedded systems designed for internal use mostly/only (limited or 
no global connectivity)
with very constrained space for a code. Ability to reduce code bloat is good 
thing.

___
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: git submodule

[Eugene Grosbein]

29.08.2019 12:55, Cy Schubert wrote:

> 2) Have the port download two tarballs from github. But, how, elegantly?

Take a look at sysutils/fusefs-webdavfs for example.

___
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: fast aarch64 computer for creating a port?

[Eugene Grosbein]

On 20.08.2019 14:44, Ronald Klop wrote:
> Hello,
> 
> I'm trying to create a port for Mongodb 4.2. To aarch64 and amd64.
> Especially my RPI3 for aarch64 takes about 2 days to compile this. Does the 
> FreeBSD community have a fast aarch64 machine I could use to do test work? 
> Maybe some access to a jail could be provided.

When I was working with very slow MIPS32 hardware, I used qemu-user-static port 
that allows you
to use fast amd64 machine to build ports for MIPS32 as if it was real MIPS32 
box but quicker. Very handy.
You just start it as you would start plain chroot command and voila.

mipsworld="/usr/obj/nanobsd.mips/_.w"
mount -t devfs devfs $mipsworld/dev
mount -t nullfs /usr/ports $mipsworld/usr/ports
chroot $mipsworld /usr/local/bin/qemu-mips-static /bin/sh -E

Give it a try.

___
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 handle go dependencies

[Eugene Grosbein]

07.07.2019 5:10, Dmitri Goutnik via freebsd-ports wrote:

> Which can be fixed by just copying the linux version (this probably needs to 
> be upstreamed):
> 
> post-patch:
>   ${REINPLACE_CMD} -e "s|%%PREFIX%%|${PREFIX}|" 
> ${WRKSRC}/config.toml.example
>   ${MV} ${WRKSRC}/config.toml.example ${WRKSRC}/config.toml.sample
> +   ${CP} ${WRKSRC}/internal/helper/fstype/detect_linux.go 
> ${WRKSRC}/internal/helper/fstype/detect_freebsd.go

Making a symlink instead of copy should be faster and produce less I/O.
___
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 handle go dependencies

[Eugene Grosbein]

22.06.2019 16:58, Matthias Fechner wrote:

> Dear all,
> 
> I just prepare the gitlab-ce upgrade to version 12.0.0.
> But I have some problem with a package that uses go to compile.
> 
> The new version of devel/gitaly has changed the way the package is defined.
> They removed now all files from the vendor/ folder and add dependencies
> in a `go.mod` file.
> 
> If I now build the port it tries to fetch the files while no network
> access is allowed.
> 
> What is the correct way to getting these dependencies fetched and
> correctly included into the work-source in the fetch step using go?

That's not easy question. You may find it useful to check out
existing port sysutils/fusefs-webdavfs that successfully deals
with several dependencies located at Github (pborman/getopt and bazil/fuse).

Tricky part is in the post-patch: target of port's Makefile
that creates ${GETOPT_WRKSRCDIR} and ${FUSE_WRKSRCDIR} directories
and symlinks real paths for extracted dependencies into needed names
under ${GETOPT_WRKSRCDIR} and ${FUSE_WRKSRCDIR}.

Another dependency "golang.org/x/net/context" was integrated into golang itself
as "context" since go-1.7 so the port uses REINPLACE_CMD to patch the name in 
source files.

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

openssl111/gnutls issue in the ftp/wget

[Eugene Grosbein]

Hi!

Is it a bug in the port ftp/wget or in the ports infrastructure (bsd.sanity.mk, 
ssl.mk)
that ftp/wget fails to build for users of FreeBSD11 having openssl111 installed 
and DEFAULT_VERSIONS+=ssl=openssl111 ?

Error messages are:

> /!\ wget-1.20.3: Makefile errors /!\
> 
> The following options helpers are incorrectly set after bsd.port.options.mk
> and are ineffective: OPENSSL_LDFLAGS
> 
> *** Error code 1
___
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: OpenSSL engines directory path

[Eugene Grosbein]

24.04.2019 12:24, Eugene Grosbein wrote:

> Hi!
> 
> FreeBSD 12+ has OpenSSL version that supports loading additional "engines" 
> (shared libraries).
> Default path for engines in FreeBSD is /usr/lib/engines currently.
> The path for security/openssl111 port (needed for FreeBSD 11) is 
> ${LOCALBASE}/lib/engines-1.1
> 
> Please consider updating ports/Mk/Uses/ssl.conf with something like 
> OPENSSLENGINES
> that should equal to ${OPENSSLLIB}/engines when SSL_DEFAULT is "base"
> and for openssl111 it should be ${OPENSSLLIB}/engines-1.1
> 
> This would help porting engines.

Ports should install files inside ${LOCALBASE}, so we really need some variable
that should expand to /usr/local/lib/engines-1.1 when SSL_DEFAULT is 
"openssl111" for FreeBSD 11
or when SSL_DEFAULT is either "base" or "openssl111" for FreeBSD 12+

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

OpenSSL engines directory path

[Eugene Grosbein]

Hi!

FreeBSD 12+ has OpenSSL version that supports loading additional "engines" 
(shared libraries).
Default path for engines in FreeBSD is /usr/lib/engines currently.
The path for security/openssl111 port (needed for FreeBSD 11) is 
${LOCALBASE}/lib/engines-1.1

Please consider updating ports/Mk/Uses/ssl.conf with something like 
OPENSSLENGINES
that should equal to ${OPENSSLLIB}/engines when SSL_DEFAULT is "base"
and for openssl111 it should be ${OPENSSLLIB}/engines-1.1

This would help porting engines.
___
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: irc/ngircd: typo in Makefile

[Eugene Grosbein]

16.04.2019 2:09, Serpent7776 wrote:

> Hello,
> 
> I've just stumbled upon a possible typo in Makefile:
> 
> DEBUG_CONFIGURE_EBABLE=¦¦   debug
> 
> Shouldn't this be ENABLE instead of EBABLE?
> 

Fixed in r499085, 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: rc script problems

[Eugene Grosbein]

01.04.2019 3:55, Jim Trigg wrote:

> How do I write an rc script to preserve the pid of a child process? The 
> "port" I'm working with (technically a commercial package) has a startup 
> script that launches a java process. I had written a simple rc wrapper around 
> the script but have found it doesn't support stop because the pid captured is 
> the script's pid rather than the java process's pid.

Use something like this for startup script "portname.in" for Java-based long 
running service:

#!/bin/sh
#
# $FreeBSD$
#

# PROVIDE: portname
# REQUIRE: LOGIN
# KEYWORD: shutdown

#
# Add the following line to /etc/rc.conf to enable `portname':
#
# portname_enable="YES"

. /etc/rc.subr

command_interpreter="."
command="%%PREFIX%%/bin/java"
command_args="-jar portname.jar"
name="%%PORTNAME%%"
rcvar="${name}_enable"
start_cmd="start_cmd"
stop_cmd="stop_cmd"
pidfile="/var/run/${name}.pid"
required_files="%%DATADIR%%/portname.jar"
portname_chdir="%%DATADIR%%"

eval `JAVAVM_DRYRUN=yes ${command} | fgrep JAVAVM_COMMAND`
procname=${JAVAVM_COMMAND}

start_cmd()
{
check_startmsgs && echo "Starting ${name}."
cd ${portname_chdir}
daemon -u %%USERS%% -f -p ${pidfile} ${command} ${command_args} start
}

stop_cmd()
{
check_startmsgs && echo "Stopping ${name}."
rc_pid=$(check_pidfile $pidfile $procname)
pkill -F ${pidfile}
wait_for_pids $rc_pid
}

load_rc_config ${name}
: ${portname_enable="NO"}
run_rc_command "$1"
#EOF

That is, use daemon(8) utility that can act as superviser for java process:
start it with needed arguments, write its pid to pidfile etc.

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

Re: lang/go14 doesn't build without COMPAT11 in FREEBSD 12

[Eugene Grosbein]

24.03.2019 1:38, Lucas Nali de Magalhães wrote:

> I found a few bugs since I started rebuilding my system.
> Most of them are related with the lack of handling of CPUTYPE=native 
> make.conf tunable.

Use CPUTYPE?=native instead of CPUTYPE=native.

___
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: loose dependency

[Eugene Grosbein]

14.03.2019 11:40, Hiroki Sato wrote:

> Koichiro Iwao  wrote
>   in <20190314031726.aaspgwdcuithh...@icepick.vmeta.jp>:
> 
> me> Hi,
> me>
> me> If a port have runtime dependency on bin/convert command of ImageMagick
> me> but whichever ImageMagick{6,7}{,-nox11} are OK, how port Makefile should
> me> be written?
> me>
> me> ImageMagick6 and 7 conflicts each other. I want to respect user's
> me> choice which ImageMagick to use.
> 
>  There is no easy solution to solve it completely because currently
>  package dependency is solved in a strict manner including package
>  names and version numbers, not only existence of specific files.
>  Creating multiple ports which depend on each software or using
>  FLAVORS to make it easier is a way to provide packages with every
>  possible combinations of dependency and let one to choose.

OTOH, one still may create a port depending on existence of specific file
and fetching another port automatically in case of file absence.
It works just fine for those using ports as primary source, not packages.

And yes, if one uses packages, it is forced to live with "default" versions
including dependencies or build its own pkg repo.

___
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: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Eugene Grosbein]

17.02.2019 22:46, Diane Bruce wrote:

>> We already have libmap.conf(5). It should be possible to work around the 
>> problem
>> creating /usr/local/etc/libmap.d/python.conf with contents:
>>
>> [python2.7]
>> libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1
>>
>> [python3.4]
>> libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1
>>
> 
> Sure but I'm guessing not all python ports *need* gfortran hence
> we shouldn't force all python coded ports to use the gfortran libgcc_s.so

libmap.conf(5) manual page documents how to restrict such mappings 
per-directory.
One can create symlink for the interpreter and restrict the mapping for symlink 
only.

> Moreover, the libmap would have to be updated everytime gfortran got
> updated

Not quite: libgcc_s.so.1 needs mapping for interpreter only as our port 
building system
already creates libgfortran.so with right rpath for libgcc_s.so.1:

# ldd /usr/local/lib/gcc8/libgfortran.so.5
/usr/local/lib/gcc8/libgfortran.so.5:
libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x80146e000)
libz.so.6 => /lib/libz.so.6 (0x8016ad000)
libm.so.5 => /lib/libm.so.5 (0x8018c5000)
libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x801af3000)
libc.so.7 => /lib/libc.so.7 (0x800823000)


___
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: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Eugene Grosbein]

17.02.2019 22:41, Diane Bruce wrote:

>> Setting rpath for resulting binary should solve the problem.
> 
> No no no no no. Not for an interpreter. The interpreter doesn't 'know'
> you are about to load a binary module that needs libgcc_s and until
> it loads something that uses gfortran it doesn't matter
> which libgcc_s so it picks the 'wrong' one.
> 
> As my wiki page article says: 
> We can rename our libgcc (Yes other complications but...)
> 
> We can fix our system libgcc to have the missing functions/data that
> current libgcc has then bump our version
> 
> We can use a specific port which PRELOADs the gfortran libgcc_s.so
> e.g. python2_gfortran8 or whatever. (What a mess and it's ugly but
> it would work)
> 
> Individual python ports could be modified to do the PRELOAD with
> a tiny sh script e.g. opencad could envoke a small sh script
> that then starts the python interpreter. This would mean exposing the
> PATH from Mk/USES/fortan.mk
> 
> e.g. we currently do this:
> 
> FFLAGS+=-Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
> FCFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
> LDFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \
> 
> We'd need FRPATH=${LOCALBASE}/lib/gcc${_GCC_VER}
> exposed
> 
> blah. I finally just looked at openscad it's a binary not a python script
> As Steve sez it's missing the -Wl,-rpath stuff then

If all involved binaries and libraries in a chain starting from the interpreter
and including libraries have mappings for libgcc_s.so to right file,
the problem should be solved. And libmap.conf(5) should do the job.



___
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: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Eugene Grosbein]

17.02.2019 22:15, Diane Bruce wrote:

> Basically all we need is a pre-loader script for interpreters
> that run into this such as python. (I suspect there have to be other
> interpreters that run into this.) Perhaps something like 
> python2_gfortran or the like, all it has to do is PRELOAD or modify
> the library path  so we get the 'right' libgcc_s.so.

We already have libmap.conf(5). It should be possible to work around the problem
creating /usr/local/etc/libmap.d/python.conf with contents:

[python2.7]
libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1

[python3.4]
libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1


___
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: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Eugene Grosbein]

17.02.2019 12:56, Steve Kargl wrote:

> On Sun, Feb 17, 2019 at 12:37:36PM +0700, Eugene Grosbein wrote:
>> 17.02.2019 12:11, Steve Kargl wrot:
>>
>>>
>>> There is a problem with the order of libgcc_s.so.1
>>> in the cache created by ldconfig.  rtld will use
>>> the first one it finds.  If it fails, it fails.  It
>>> does not look to see if there is a second entry.
>>
>> If binary needs specific version of libgcc_s.so.1 installed
>> with gcc8 port/package, then building system must use specific
>> rpath, so rtld would not use "the first one it finds".
> 
> This is a well-known problem with libgcc_s.so.1 and gfortran.
> You can state whatever you believe should happen, but it does
> not seem to work that.  You have a few options:
> 1) Add -static to your options;
> 2) Use LD_LIBRARY_PATH, LD_RUN_PATH to point to
>/usr/local/lib/gcc8;
> 3) Add -Wl,-rpath=/usr/local/lib/gcc8 to FFLAGS in /etc/make.conf
>(check syntax for this one);
> 4) bump the major library version number for /lib/libgcc.so.1
>to 2;
> 5) fix rtld to not fail on the first found library in the cache.
>Iterated over all entries and only fail if the library isn't found;
> 6) rename /lib/libgcc_s.so.1 to /lib/libllvm_s.so.1 and teach
>llvm/clang/rtld to not misappropriate a well-known GCC library
>name.
> 

When a port from our Ports Collection needs specific version of GCC and its 
runtime libraries,
it utilizes "USE_GCC=8" and bsd.gcc.mk adds this to make everybody happy:

CFLAGS+=-Wl,-rpath=${_GCC_RUNTIME}
CXXFLAGS+=  -Wl,-rpath=${_GCC_RUNTIME}
LDFLAGS+=   -Wl,-rpath=${_GCC_RUNTIME} -L${_GCC_RUNTIME}

This is your 3) case and this is what I have meant.

When someone builds a binary having same requirements but without
writing port/using bsd.gcc.mk, same needs to be done
and everything should just work. Or better create a port.

___
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: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Eugene Grosbein]

17.02.2019 13:19, Steve Kargl wrote:

> For whatever reason, there are situations where the rpath
> isn't set in the library.  Read the rtld manpage.  You're
> hitting #5 in the list.

Our package building system sets rpath for dependants of gcc8,
so Fortran libraries (and others) do have rpath for its runtime.

Setting rpath for resulting binary should solve the 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"

Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Eugene Grosbein]

17.02.2019 12:11, Steve Kargl wrot:

>> # ldd /usr/local/lib/gcc8/libgfortran.so.5
>> /usr/local/lib/gcc8/libgfortran.so.5:
>> libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 
>> (0x80146e000)
>> libz.so.6 => /lib/libz.so.6 (0x8016ad000)
>> libm.so.5 => /lib/libm.so.5 (0x8018c5000)
>> libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x801af3000)
>> libc.so.7 => /lib/libc.so.7 (0x800823000)
>>
>> So, /usr/local/lib/gcc8/libgfortran.so.5 does not depend on 
>> /lib/libgcc_s.so.1
>> but on /usr/local/lib/gcc8/libgcc_s.so.1 in normal case.
>>
>> I assume something is broken in your installation. Try removing gcc8 and 
>> reinstalling
>> it using package.
> 
> There is a problem with the order of libgcc_s.so.1
> in the cache created by ldconfig.  rtld will use
> the first one it finds.  If it fails, it fails.  It
> does not look to see if there is a second entry.

If binary needs specific version of libgcc_s.so.1 installed with gcc8 
port/package,
then building system must use specific rpath, so rtld would not use "the first 
one it finds".

___
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: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Eugene Grosbein]

17.02.2019 8:58, Russell L. Carter wrote:

> On 2/16/19 6:44 PM, Eugene Grosbein wrote:
>> 17.02.2019 8:35, Russell L. Carter wrote:
>>
>>>>> Transcribed output from the FreeCAD Testing Framework GUI test all:
>>>>>
>>>>> First run of TestApp.All: Run: 212 Failures: 1 Errors: 20
>>>>>
>>>>> which isn't bad at all I suspect.  However one of the failures is
>>>>>
>>>>> /lib/libgcc_s.so.1 version GCC_4.8.0 required by
>>>>> /usr/local/lib/gcc8/libgfortran.so.5 not found
>>
>> Where did you get this from, exactly?
>>
> 
> I apologize, I am unsure what you are asking about with respect to the
> "this".  The output I am showing is literally typed in from the error
> display box that happens when I run FreeCAD-git, ie, current git
> FreeCAD, in an outside the ports tree bleeding edge version, including
> the dependencies, that I am working on.  I detailed this in the
> original message.  I would be delighted to share all my scripts and
> patches that got me this far.
> 
> Anyway there is a FreeCAD Test workbench, with an "all" option, right
> at the top, and that's where I'm starting on the bug triage.
> 
> Now I got to cook dinner but I will be back at it tomorrow.  Something
> of an obsession.  Plus I have a deck to design.  It would be cheaper
> to have someone else do this, but shouldn't FreeCAD do it on FreeBSD?

Maybe you should use libmap.conf(5) to work around the problem.
"ktrace -i" and kdump would be handy to discover exact name of the binary or 
library
for /etc/libmap.conf if FreeCAD-git happens to be not binary but some wrapping 
script
for real binary.

___
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: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Eugene Grosbein]

17.02.2019 8:35, Russell L. Carter wrote:

>>> Transcribed output from the FreeCAD Testing Framework GUI test all:
>>>
>>> First run of TestApp.All: Run: 212 Failures: 1 Errors: 20
>>>
>>> which isn't bad at all I suspect.  However one of the failures is
>>>
>>> /lib/libgcc_s.so.1 version GCC_4.8.0 required by
>>> /usr/local/lib/gcc8/libgfortran.so.5 not found

Where did you get this from, exactly?

___
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: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Eugene Grosbein]

17.02.2019 8:02, Russell L. Carter wrote:

> Greetings,
> 
> Restarting the FreeCAD 0.17 discussion on a different tangent.
> 
> As I mentioned before I am building (for now) outside of the ports
> tree FreeCAD-git + Coin-hg + QT5 + med-4.0.0.  I want to particularly
> thank very much all the porting work that has been done so far, I
> wouldn't have been able to get as far as I have without it.
> 
> french/med (french?) requires fortran, and for ports gfortran is
> apparently the only option.  gfortran depends on libgcc_s.so.1, which
> is FreeBSD's (only?) version of dll hell.
> 
> Transcribed output from the FreeCAD Testing Framework GUI test all:
> 
> First run of TestApp.All: Run: 212 Failures: 1 Errors: 20
> 
> which isn't bad at all I suspect.  However one of the failures is
> 
> /lib/libgcc_s.so.1 version GCC_4.8.0 required by
> /usr/local/lib/gcc8/libgfortran.so.5 not found
> 
> This is probably fatal to practical use of FreeCAD on FreeBSD.  I was
> able to open most of my previous models, created on debian-testing,
> but some were fail.
> 
> 2 threads, no happy ending:
> 
> https://lists.freebsd.org/pipermail/freebsd-ports/2018-May/113336.html
> https://lists.freebsd.org/pipermail/freebsd-python/2016-January/009672.html
> 
> Question to experienced porters, how is this best practice solved?

I've just did "pkg install gcc8" using my FreeBSD 11.2/amd64 system and got 
this:

# ldd /usr/local/lib/gcc8/libgfortran.so.5
/usr/local/lib/gcc8/libgfortran.so.5:
libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x80146e000)
libz.so.6 => /lib/libz.so.6 (0x8016ad000)
libm.so.5 => /lib/libm.so.5 (0x8018c5000)
libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x801af3000)
libc.so.7 => /lib/libc.so.7 (0x800823000)

So, /usr/local/lib/gcc8/libgfortran.so.5 does not depend on /lib/libgcc_s.so.1
but on /usr/local/lib/gcc8/libgcc_s.so.1 in normal case.

I assume something is broken in your installation. Try removing gcc8 and 
reinstalling
it using package.

___
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: Using LibreSSL with only one or a subset of all installed ports

[Eugene Grosbein]

07.02.2019 1:58, Kevin Oberman wrote:

> I'm not saying that it can't be done, but you have to know all of the
> linkages and be very sure that there are no conflicts.

Sometimes libmap.conf(5) helps.


___
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 check erroneously reports missing lib

[Eugene Grosbein]

05.02.2019 2:50, Xavier пишет:
> This is mediatomb from ports, on FreeBSD 12-STABLE :
> 
> 
> [root@numenor ~]# portupgrade -vf spidermonkey17 mediatomb
> [...compile...compile...compile...]
> 
> [root@numenor ~]# pkg check -Bd  mediatomb
> Checking mediatomb: 100%
> mediatomb is missing a required shared library: libjs.so
> 
> [root@numenor ~]# ldd /usr/local/bin/mediatomb |grep libjs
> libjs.so => /usr/local/lib/libjs.so (0x800e8b000)
> 
> And mediatomb works like a charm
> 
> Any idea ?

Perhaps, there is something wrong with your installation of lang/spidermonkey17
that installs libjs.so. What does "pkg which /usr/local/lib/libjs.so" tell?


___
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: Deregister a port?

[Eugene Grosbein]

04.02.2019 19:14, Luciano Mannucci wrote:
> 
> Is there a way to deregister a port without touching port's files?
> 
> The only way I see is build my own version without install, run
> pkg delete end then make install on the source tree I'm managing
> myself.
> 
> This leaves me without the package functionality while installing,
> wich is not desirable on production server.
> 
> Any ideas?

Use "make -DDISABLE_CONFLICTS" just like portupgrade does.
If this is not enough, please be more precise describing your problem
and do not forget to show build error log that you get without pkg delete.

Also read pkg-install(8) and pkg.conf(5) manual pages and consider copying
existing PKG_DBDIR to alternative directory like /opt/db/pkg
and using it by means of env PKG_DBDIR=/opt/db/pkg make -C /path/to/yourownport



___
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: packages and base jails

[Eugene Grosbein]

27.11.2018 6:42, Eugene Grosbein wrote:

> But not /usr/local nor /usr/{src|obj}, if that matters. So each jail have its 
> own
> set of packages or even ports if I choose to null-mount host's /usr/ports 
> readonly
> to /usr/local/j/${JAILNAME}/basejail/usr/ports

In fact, to /usr/local/j/${JAILNAME}/usr/ports directly.

> and write to jail's /etc/make.conf:
> 
> WRKDIRPREFIX=   /var/ports
> DISTDIR=/var/ports/distfiles
> PACKAGES=   /var/ports/packages
> INDEXDIR=   /var/ports
> 
> That works just fine for me.

___
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: packages and base jails

[Eugene Grosbein]

27.11.2018 3:24, Michael W. Lucas wrote:
> 
> Hi,
> 
> I'm writing a book on jails and am looking for BCP. I'd like to
> present either "This is the approved solution and should work" or
> "these are the gotchas with any of these, choose your pain."
> 
> Folks want base jails to include packages, but also want to install
> additional packages--which won't happen if /usr/local is mounted
> read-only in the base jail. Trawling around the Net I see a couple
> options. Both involve the primary jail using a different package
> repo. The overlay jail uses the standard package repo.
> 
> 1) primary jail uses a repo with PREFIX=/usr/pkg or /opt. Works in my
> simple use cases once I set ldconfig directories in rc.conf, but I'm
> told programs like pkgconfig can go sideways.
> 
> 2) base jail repo uses with PREFIX=/. Utterly violates separation of
> base and pkg, but everything should find everything out of the
> box. Again, seems to work in my wimpy use cases.
> 
> Is there an option that should work? Or is a matter of choosing
> between horrors?

Not sure I understand the problem which I don't have using sysutils/ezjail
that uses base jail situated in /usr/local/j/basejail in my case.

For each distinct jail instance, it null-mounts it read-only
to /usr/local/j/${JAILNAME}/basejail and /usr/local/j/${JAILNAME} it jail's 
root.
Inside this root, /bin is symlink to /basejail/bin, and /boot, /libexec, /rescue
and /sbin are similar symlinks, so are 
/usr/{bin|include|lib|lib32|libdata|libexec|ports|sbin|share}
all symlinks to corresponding directories inside ro-mounted /basejail/usr/...

But not /usr/local nor /usr/{src|obj}, if that matters. So each jail have its 
own
set of packages or even ports if I choose to null-mount host's /usr/ports 
readonly
to /usr/local/j/${JAILNAME}/basejail/usr/ports and write to jail's 
/etc/make.conf:

WRKDIRPREFIX=   /var/ports
DISTDIR=/var/ports/distfiles
PACKAGES=   /var/ports/packages
INDEXDIR=   /var/ports

That works just fine for me.

___
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: ssl=base

[Eugene Grosbein]

25.11.2018 18:57, Franco Fichtner wrote:

>> Why can't you use LibreSSL port for some ports and base libssl for other 
>> ports?
>> That is, net/mpd5 links with base system libfetch that depends on base 
>> libssl,
>> so it is example of port that cannot be built with LibreSSL.
> 
> FWIW, since 2015 we've had no build or operational issue with mpd5 for 
> LibreSSL
> from ports.

Fixed in r485853.

___
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: ssl=base

[Eugene Grosbein]

25.11.2018 18:46, Mathieu Arnold wrote:

>> As maintainer of the net/mpd5 port, I wonder why our ports/Mk/Uses/ssl.mk
>> prevents building this port using FreeBSD 12 and base system libssl
>> when libressl is installed?
>>
>> While building with ssl=base, the port itself does not include headers
>> from ${LOCALBASE}/include and it does not include ${LOCALBASE}/lib to search 
>> path for linking stage.
>>
>> I see no way to override noted (wrong) check-depends restriction, and that's 
>> not good.
> 
> Because you either use OpenSSL from the base system, or you install an
> *SSL variant from ports and use it.  You cannot mix half of the stuff
> from the base system and half of the stuff from a port version of *SSL.

Why can't you use LibreSSL port for some ports and base libssl for other ports?
That is, net/mpd5 links with base system libfetch that depends on base libssl,
so it is example of port that cannot be built with LibreSSL.

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

ssl=base

[Eugene Grosbein]

Hi!

As maintainer of the net/mpd5 port, I wonder why our ports/Mk/Uses/ssl.mk
prevents building this port using FreeBSD 12 and base system libssl
when libressl is installed?

While building with ssl=base, the port itself does not include headers
from ${LOCALBASE}/include and it does not include ${LOCALBASE}/lib to search 
path for linking stage.

I see no way to override noted (wrong) check-depends restriction, and that's 
not good.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [freebsd 11.2] net-snmpd incomplete mac addresses

[Eugene Grosbein]

05.10.2018 18:33, Patrick Lamaiziere wrote:
> Hello,
> 
> freebsd 11.2/amd64 release
> net-snmp-5.7.3_18
> 
> net-snmpd returns incomplete MAC addresses in IF-MIB::ifPhysAddress,
> the first octet is always "0".
> 
> $ snmpwalk -v 2c -c "xxx" localhost 1.3.6.1.2.1.2.2.1.6
> IF-MIB::ifPhysAddress.1 = STRING: 0:36:9f:93:7d:f8
> IF-MIB::ifPhysAddress.2 = STRING: 0:36:9f:93:7d:fa
> IF-MIB::ifPhysAddress.3 = STRING: 0:f4:bb:ef:c8:e4
> ...
> 
> $ ifconfig | grep ether
>   ether a0:36:9f:93:7d:f8
>   ether a0:36:9f:93:7d:fa
>   ether ec:f4:bb:ef:c8:e4
> 
> tcpdump confirms that the problem is in net-snmpd (and not the client).
> 
> Also when using the MIB IP-MIB::ipNetToMediaPhysAddress the MAC
> addresses are correct. 
> 
> $ snmpwalk -v2c -c '***r***' localhost IP-MIB::ipNetToMediaPhysAddress | grep 
> a0:36:9f:93:7d:f8
> IP-MIB::ipNetToMediaPhysAddress.13.10.10.1.118 = STRING: a0:36:9f:93:7d:f8
> 
> I've checked net-snmpd 5.7.3 under linux and the mac addresses are
> correct. (So it's specific to FreeBSD.)
> 
> Any clue ?

We have bsnmpd in the base system. Does it exhibit same 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"

Re: Delete a port

[Eugene Grosbein]

05.08.2018 0:42, Eitan Adler wrote:

>> Feel free to commit, but please use the  absolute path to vi?
> 
> Why? Would't one want to respect the user's preference when it comes
> to an editor? This preference is implicit when it comes to PATH.

This is traditional overcautiousness against user's possibly insecure
PATH having current directory that can lead to running malignant /tmp/vi
in multiuser environment.

Eugene

___
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: Delete a port

[Eugene Grosbein]

04.08.2018 21:03, Romain Tartière wrote:

> On Sat, Aug 04, 2018 at 12:28:41PM +0200, Matthias Fechner wrote:
>> ./rmport: svnlog: not found
>>
>> Anyone an idea what is wrong?
> 
> Never used this script, but I guess you are hitting line 390:
> 
> | $EDITOR svnlog
> 
> Any chance $EDITOR is not set?

It seems, rmport script needs a patch:

Index: Tools/scripts/rmport
===
--- Tools/scripts/rmport(revision 476322)
+++ Tools/scripts/rmport(working copy)
@@ -39,6 +39,7 @@
 # MAINTAINER=  cr...@freebsd.org
 #

+EDITOR=${EDITOR:-vi}
 PORTSDIR=${PORTSDIR:-/usr/ports}
 INDEX=${PORTSDIR}/`make -C ${PORTSDIR} -V INDEXFILE`






signature.asc
Description: OpenPGP digital signature

Re: Virtual Printer Port?

[Eugene Grosbein]

On 29.07.2018 03:28, Dan Mahoney (Gushi) wrote:
> Hey all,
> 
> This may be off topic, but does anyone know a port or configuration for 
> FreeBSD that can listen on a serial port and spit out a PDF?  I have a 
> piece of hardware (a hospital-grade pulse oximeter) that's able to talk to 
> an *original* HP Thinkjet with a serial port and produce graphical charts. 
> Like, the best 1993 has to offer.
> 
> I'd rather simply hook up a BSD box via a serial port and translate those 
> control codes into a PDF (or TIFF/PNG/postscript document).  The control 
> codes are pretty well documented, since you need them to make printer 
> drivers, but this is the reverse use.
> 
> Is there anything in ports that can do this?  Is there a better mailing 
> list to be asking on?

They say, HP Thinkjet used PCL1 as incoming printing language.

Basically, you need to *reverse* PCL1-render of original "document"
back to a file containg original data. This is similar to disassembly
of machine code back to program text and/or data.

I highly doubt you'll find ready-to-use "decompiler" for PCL1
and you may need to write such software yourself.

Or you can just toss received PCL1 to any modern PCL-compatible 
multi-functional device
to print it and scan resulting sheet back to PDF file :-)

PCL versions should be backward compatible.


 

___
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: building openjdk without alsa dependency

[Eugene Grosbein]

31.07.2018 7:29, blubee blubeeme пишет:
> I would like to build openjdk7 without the asound lib, I already
> removed ALSA from my kernel so the build fails but I am not writing
> Java applications that needs sound.
> 
> I made a few changes to just not build the ALSA parts and the port
> builds properly.
> 
> I had to edit the patch-bsd and created a new patch to remove building
> ALSA sound parts.
> 
> Would it be possible to have the java team add a knob to the USE_JAVA
> in bsd.java.mk so that I can use this version with other ports?
> 
> patch-jdk_make_common_Sanity.gmk : https://pastebin.com/cXej8LES
> patch-bsd :
> https://pastebin.com/E9xHTkKH

Please do not use pastebin but https://bugs.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: What the port license should be when software is "free for non-commercial use" with "click-to-accept" or clickwrap license?

[Eugene Grosbein]

05.07.2018 18:01, Marko Cupać wrote:

> What would be the benefit of users' clicks for owners of such software?
> What would owners of such software lose if they didn't require clicks?
> 
> What would be the benefit for pkg owners for investing time and effort
> into supporting such feature? How would FreeBSD project and its users
> benefit from it?

https://en.wikipedia.org/wiki/End-user_license_agreement#Shrink-wrap_and_click-wrap_licenses

___
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 the port license should be when software is "free for non-commercial use" with "click-to-accept" or clickwrap license?

[Eugene Grosbein]

03.07.2018 14:06, Mathieu Arnold wrote:

>>> But it doesn't ask to "agree" during 'pkg install dcc-dccd'.
>>
>> Yes. Meantime, you have several choices:
>>
>> 1) Mark the port NO_PACKAGE and/or no-pkg-mirror to force users use a port 
>> that
> 
> It is not no-pkg-mirror, in this case, it is no-auto-accept.

According to https://www.freebsd.org/doc/en/books/porters-handbook/licenses.html

> no-pkg-mirror
>   Free redistribution of package is prohibited. Equivalent to setting 
> NO_PACKAGE.
>   The package will not be distributed from the FreeBSD package CDN 
> https://pkg.freebsd.org/.

This is exactly what I'm talking about: preventing usage of a package
because pkg(8) does not honor "no-auto-accept" yet.
___
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: Passenger not working any more after Base System upgrade: can you reproduce?

[Eugene Grosbein]

On 02.07.2018 03:19, José Pérez via freebsd-ports wrote:

> Hi,
> after a Base System upgrade Passenger fails on
> startup with this error:
> nginx: [alert] Unable to start the Phusion Passenger watchdog: it seems 
> to have been killed with signal SIGABRT during startup (-1: Unknown 
> error)
> 
> Can please someone try and reproduce and/or
> suggest a workaround/fix?
> 
> How to reproduce:
> - stable 11.2
> - install nginx or apache (same problem with
>both)
> - install (almost) any passenger version (I
>could reproduce with 5.2.1, 5.3.2 (current
>in ports) and 5.3.3 (latest))
> 
> What you get:
> # service nginx start
> Performing sanity check on nginx configuration:
> nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is 
> ok
> nginx: configuration file /usr/local/etc/nginx/nginx.conf test is 
> successful
> Starting nginx.
> nginx: [alert] Unable to start the Phusion Passenger watchdog: it seems 
> to have been killed wit
> 
> Further error details in log:
> [ pid=57456, timestamp=1530359790 ] Process aborted! signo=SIGABRT(6), 
> reason=#65543, si_addr=0x0, randomSeed=1530359790

Have your tried to google this? Search for "reason=" "65543"
gives https://github.com/phusion/passenger/issues/987 as second link
that mentiones very similar problem pointing to some C++ compiler 
incompatibility
and FreeBSD 11.2 got new clang version 6.0.0, so that may be a culprit.

You should try to deinstall all dependent ports including nginx and the 
application itself
and rebuild them all from scratch to eliminate possible C++ mangling/runtime 
problems.

___
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: Passenger not working any more after Base System upgrade: can you reproduce?

[Eugene Grosbein]

On 02.07.2018 03:19, José Pérez via freebsd-ports wrote:

[skip]

Have you actually read the log?

> Further error details in log:
> [ pid=57456, timestamp=1530359790 ] Process aborted! signo=SIGABRT(6), 
> reason=#65543, si_addr=0x0, randomSeed=1530359790
> [ pid=57456 ] Crash log dumped to 
> /var/tmp/passenger-crash-log.1530359790

[skip]

> *** ERROR: cannot execute lsof: No such file or directory (errno=2)

Make sure your lsof binary is present (installed by port or package)
and your application has correct search path for it.

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

Re: What the port license should be when software is "free for non-commercial use" with "click-to-accept" or clickwrap license?

[Eugene Grosbein]

03.07.2018 6:17, Yuri wrote:

>> It does. See mail/dcc-dccd for example.
> But it doesn't ask to "agree" during 'pkg install dcc-dccd'.

Yes. Meantime, you have several choices:

1) Mark the port NO_PACKAGE and/or no-pkg-mirror to force users use a port that
1a) builds software from source, or
1b) installs pre-build binaries bundled with distfiles (just like cvsup binary 
port did earlier);
2) Prepare and submit a patch for pkg itself to support this feature. It should 
be not hard to do.


___
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: devel/qt5-core (qt5-core-5.9.4_2) (uninstall error)

[Eugene Grosbein]

27.06.2018 9:46, Janos Dohanics wrote:

> # ls -al /usr/local/lib/qt5/libQt5Core*
> -rw-r--r--  1 root  wheel 1040 May  5 21:58 
> /usr/local/lib/qt5/libQt5Core.prl
> lrwxr-xr-x  1 root  wheel   19 May  5 21:58 
> /usr/local/lib/qt5/libQt5Core.so -> libQt5Core.so.5.9.4
> lrwxr-xr-x  1 root  wheel   19 May  5 21:58 
> /usr/local/lib/qt5/libQt5Core.so.5 -> libQt5Core.so.5.9.4
> -rwxr-xr-x  1 root  wheel  5028000 May  5 21:58 
> /usr/local/lib/qt5/libQt5Core.so.5.9.4
> 
> How can I fix this?

Just remove symlinks and re-do the procedure.


___
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: make package "*** Error code 1"

[Eugene Grosbein]

08.06.2018 20:12, duckmanjbr wrote:

> 1st off,  thanks everyone for helping me out!  There was indeed a missing 
> filename and I believe I’ve remedied that.  I’m moving along but now getting 
> a "missing property prefix” error.  Am I missing a log file or something to 
> help trouble shoot these errors?  I’d like to piece it together to a working 
> state before I offer it as a pull request to pfSense/FreeBSD-ports. 
> 
> build_error:
> root@:~/pfSense-pkg-localrepo # make package
> ===>  License APACHE20 accepted by the user
> ===>   pfSense-pkg-LocalRepo-0.1_1 depends on file: /usr/local/sbin/pkg - 
> found
> ===> Fetching all distfiles required by pfSense-pkg-LocalRepo-0.1_1 for 
> building
> ===>  Extracting for pfSense-pkg-LocalRepo-0.1_1
> /bin/mkdir -p /root/pfSense-pkg-localrepo/work/pfSense-pkg-LocalRepo-0.1
> ===>  Patching for pfSense-pkg-LocalRepo-0.1_1
> ===>  Configuring for pfSense-pkg-LocalRepo-0.1_1
> ===>  Staging for pfSense-pkg-LocalRepo-0.1_1
> ===>   Generating temporary packing list
> /bin/mkdir -p /root/pfSense-pkg-localrepo/work/stage/usr/local/pkg
> /bin/mkdir -p /root/pfSense-pkg-localrepo/work/stage/usr/local/bin/localrepo
> /bin/mkdir -p /root/pfSense-pkg-localrepo/work/stage/etc/inc/priv
> /bin/mkdir -p 
> /root/pfSense-pkg-localrepo/work/stage/share/pfSense-pkg-LocalRepo
> install  -m 0644 -m 0644 
> /root/pfSense-pkg-localrepo/files/usr/local/pkg/localrepo.xml  
> /root/pfSense-pkg-localrepo/work/stage/usr/local/pkg
> install  -m 0644 
> /root/pfSense-pkg-localrepo/files/usr/local/pkg/localrepo.inc  
> /root/pfSense-pkg-localrepo/work/stage/usr/local/pkg
> install  -m 0644 
> /root/pfSense-pkg-localrepo/files/usr/local/bin/localrepo/localrepo.conf  
> /root/pfSense-pkg-localrepo/work/stage/usr/local/bin/localrepo
> install  -m 0644 
> /root/pfSense-pkg-localrepo/files/etc/inc/priv/localrepo.priv.inc  
> /root/pfSense-pkg-localrepo/work/stage/etc/inc/priv
> install  -m 0644 
> /root/pfSense-pkg-localrepo/files/usr/local/share/pfSense-pkg-LocalRepo/info.xml
>   /root/pfSense-pkg-localrepo/work/stage/share/pfSense-pkg-LocalRepo
> > Compressing man pages (compress-man)
> ===>  Building package for pfSense-pkg-LocalRepo-0.1_1
> [: =: unexpected operator
> pkg-static: Invalid package: object has missing property prefix
> pkg-static: the package is not valid
> *** Error code 1

I guess, your files/pkg-install.in file may have bugs.
And this seems to be very pfSence-specific, you probably get more attention 
asking pfSense people.

___
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: make package "*** Error code 1"

[Eugene Grosbein]

08.06.2018 16:58, Matthew Seaman wrote:

>>> @${REINPLACE_CMD} -i '' -e "s|%%PKGVERSION%%|${PKGVERSION}|" \
>>>
>>> .include 
>>
>> Here is obvious bug: the line with REINPLACE_CMD has continuation backslash
>> without any continuation text and without file name to process. Fix it.
> 
> Actually, since the next line is a blank line, that's going to be pretty
> harmless.

No. A filename is still missing.

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

Re: make package "*** Error code 1"

[Eugene Grosbein]

08.06.2018 8:12, duckmanjbr wrote:

> do-install:
>   ${MKDIR} ${STAGEDIR}${PREFIX}/pkg
>   ${MKDIR} ${STAGEDIR}${PREFIX}/bin/localrepo
>   ${MKDIR} ${STAGEDIR}/etc/inc/priv
>   ${MKDIR} ${STAGEDIR}${DATADIR}
>   ${INSTALL_DATA} -m 0644 ${FILESDIR}${PREFIX}/pkg/localrepo.xml \
>   ${STAGEDIR}${PREFIX}/pkg
>   ${INSTALL_DATA} ${FILESDIR}${PREFIX}/pkg/localrepo.inc \
>   ${STAGEDIR}${PREFIX}/pkg
>   ${INSTALL_DATA} ${FILESDIR}${PREFIX}/bin/localrepo/localrepo.conf \
>   ${STAGEDIR}${PREFIX}/bin/localrepo
>   ${INSTALL_DATA} ${FILESDIR}/etc/inc/priv/localrepo.priv.inc \
>   ${STAGEDIR}/etc/inc/priv
>   ${INSTALL_DATA} ${FILESDIR}${DATADIR}/info.xml \
>   ${STAGEDIR}${DATADIR}/info.xml
>   @${REINPLACE_CMD} -i '' -e "s|%%PKGVERSION%%|${PKGVERSION}|" \
> 
> .include 

Here is obvious bug: the line with REINPLACE_CMD has continuation backslash
without any continuation text and without file name to process. Fix it.

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

Re: leptonica update

[Eugene Grosbein]

03.06.2018 5:22, Walter Schwarzenfeld wrote:

> Yes, I was wrong:
> 
> The CONFLICTS_BUILD in leptonica means it would pick up the wrong 
> "openjpeg.h" if openjpeg15 is installed.

This seems to be porting bug that should be resolved by patching the source
instead of just addition of CONFLICTS_BUILD.

___
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/thunderbird fails on link with latest security/nss

[Eugene Grosbein]

26.05.2018 18:18, Jonathan Chen пишет:
> Hi,
> 
> With the recent update to security/nss, mail/thunderbird build
> currently fails on 11-STABLE/amd64 with:
> 
> [...]
> Executing: /usr/bin/c++ -std=gnu++11 -o plugin-container
> -Qunused-arguments -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_C99_MATH_TR1
> -D_DECLARE_C99_LDB
> L_MATH -DLIBICONV_PLUG -isystem /usr/local/include -Qunused-arguments
> -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers
> -Woverloaded-vir
> tual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code
> -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wloop-analysis
> -W
> c++11-compat-pedantic -Wc++14-compat -Wc++14-compat-pedantic
> -Wc++1z-compat -Wimplicit-fallthrough -Wstring-conversion
> -Wthread-safety -Wno-i
> nline-new-delete -Wno-error=deprecated-declarations
> -Wno-error=array-bounds -Wno-unknown-warning-option
> -Wno-return-type-c-linkage -O2 -pipe
> -O3 -DLIBICONV_PLUG -isystem /usr/local/include -fno-strict-aliasing
> -DLIBICONV_PLUG -isystem /usr/local/include -fno-exceptions
> -fno-strict-
> aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions
> -fno-math-errno -pipe -I/usr/local/include -O2 -O3 -fno-omit-frame-poi
> nter /construction/xports/mail/thunderbird/work/.build/ipc/app/tmp4zapiQ.list
> -pthread -Wl,--as-needed -Wl,-z,noexecstack -Wl,-z,text -rdynam
> ic -Wl,-rpath-link,/construction/xports/mail/thunderbird/work/.build/dist/bin
> -Wl,-rpath-link,/usr/local/lib ../../xpcom/glue/libxpcomglue_s.
> a -pie ../../toolkit/library/libxul.so -L/usr/local/lib
> -L/usr/local/lib -lplds4 -lplc4 -lnspr4 -pthread
> /construction/xports/mail/thunderbird/work/.build/ipc/app/tmp4zapiQ.list:
> INPUT("GMPLoader.o")
> INPUT("MozillaRuntimeMain.o")
> INPUT("../../mozglue/build/SSE.o")
> INPUT("../../memory/mozalloc/Unified_cpp_memory_mozalloc0.o")
> INPUT("../../memory/build/mozjemalloc_compat.o")
> INPUT("../../memory/build/mozmemory_wrap.o")
> INPUT("../../memory/build/jemalloc_config.o")
> INPUT("../../mozglue/misc/StackWalk.o")
> INPUT("../../mozglue/misc/TimeStamp.o")
> INPUT("../../mozglue/misc/TimeStamp_posix.o")
> INPUT("../../mfbt/Compression.o")
> INPUT("../../mfbt/Decimal.o")
> INPUT("../../mfbt/Unified_cpp_mfbt0.o")
> INPUT("../../mfbt/Unified_cpp_mfbt1.o")
> INPUT("../../memory/fallible/fallible.o")
> INPUT("../../dom/media/gmp/rlz/Unified_cpp_dom_media_gmp_rlz0.o")
> 
> /usr/bin/ld: warning: libssl3.so, needed by
> ../../toolkit/library/libxul.so, not found (try using -rpath or
> -rpath-link)
> /usr/bin/ld: warning: libsmime3.so, needed by
> ../../toolkit/library/libxul.so, not found (try using -rpath or
> -rpath-link)
> /usr/bin/ld: warning: libnss3.so, needed by
> ../../toolkit/library/libxul.so, not found (try using -rpath or
> -rpath-link)
> /usr/bin/ld: warning: libnssutil3.so, needed by
> ../../toolkit/library/libxul.so, not found (try using -rpath or
> -rpath-link)
> ../../toolkit/library/libxul.so: undefined reference to
> `PK11_CheckUserPassword@NSS_3.2'
> ../../toolkit/library/libxul.so: undefined reference to
> `PK11_GetAllTokens@NSS_3.2'
> [.. slew of link errors ...]
> 
> I have had a quick look, and it appears that the libssl3, libsmime3,
> libnss3 and libnssutil3 are located in /usr/local/lib/nss; but this
> does not appear to be specified in the link-path. Anyone have a quick
> fix?

The port security/nss has USE_LDCONFIG=${PREFIX}/lib/nss in its Makefile,
so it should install /usr/local/libdata/ldconfig/nss with single line inside:
/usr/local/lib/nss

That should be enough for /usr/local/lib/nss to be added to 
/var/run/ld-elf.so.hints at boot time.
Check your installation using "ldconfig -r"


___
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: Pause pkg install messages

[Eugene Grosbein]

On 24.05.2018 15:08, Johannes Lundberg wrote:
> Hi
> 
> The first thing me and probably many other do after install is
> pkg install xxx yyy zzz
> from console (meaning no scrollback buffer).
> 
> With xorg and friends this means hundreds of packets. After install all the
> pkg messages are display and most of sometimes very valuable information is
> just scrolled away.
> 
> Is there an easy way to fix* this by piping the output through less or
> something to pause for each screen so that the messages just aren't
> scrolled away?
> 
> In addition to that it would be nice (if it's not already done) to store
> this information in a log file somewhere so that one can revisit and see
> what needs to be manually configured for each installed package.
> 
> *by fix I mean something that does not put the burden on the user.

Installation/deinstallation of packages logged by default to /var/log/messages.
Syscons console has scrollback buffer by default.
If vt(4) has not, that's regression after syscons and should be fixed in the vt.

Also, one can have, for tcsh: alias pkg 'script -a /var/log/pkg.log pkg-static'
So "pkg install xxx yyy zzz" adds fulls output to specified file.

___
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 port installs from GitHub, why?

[Eugene Grosbein]

21.05.2018 2:02, Per olof Ljungmark wrote:

>> I may look into changing it, but if you generate a patch, I'll look at it. 
> 
> Easiest way to understand what I mean is to compare the official download at
> https://downloads.joomla.org/cms/joomla3/3-8-7/Joomla_3-8-7-Stable-Full_Package.zip?format=zip
> (42MB unzipped)
> 
> with the distfile from ports
> joomla-joomla-cms-3.8.7_GH0.tar.gz (71MB unpacked)
> 
> I never worked with the ports system so patching it for me would be too
> much. However, if you do not have the time I may know someone here that
> could do it.
> 
> Again, I think the port in its current state is designed for people who
> develop Joomla, not using it as a CMS like me.

One should not compare official end-user package with source downloads
because the port is supposed to build software from source and not install 
pre-built packages.

However, you can legitimately compare official end-user packages with our 
package
produced by the port, if you wish.

___
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 port installs from GitHub, why?

[Eugene Grosbein]

20.05.2018 18:52, Per olof Ljungmark wrote:

> I am curious as to why the www/joomla3 port installs from GitHub, looks
> like the port is better for Joomla code development than to run a CMS.
> 
> There are LOTS of files in the port install that is not needed to run
> Joomla.
> 
> I thought the recommended way is to fetch the latest version from
> joomla.org:
> 
> https://downloads.joomla.org/cms/joomla3/3-8-7/Joomla_3-8-7-Stable-Full_Package.zip?format=zip
> 
> 
> Can someone please enlighten me here?

You should ask port maintainer l...@freebsd.org (CC'd).


___
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: Could someone else please review and approve these revision so I can commit them

[Eugene Grosbein]

02.05.2018 15:45, Matthias Fechner wrote:

> as Torsten (tz) and Steve (swills) seems to be not available and I'm not 
> allowed to commit before the reviews were approved could please someone else 
> have a look to (they have security problems):
> https://reviews.freebsd.org/D15248
> https://reviews.freebsd.org/D15249
> 
> I would like to commit them ASAP to fix some critical security holes with 
> gitlab.

Done.


___
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: Port directory not found:

[Eugene Grosbein]

30.04.2018 4:08, AN wrote:

> FreeBSD BSD_12 12.0-CURRENT FreeBSD 12.0-CURRENT #29 r333091: Sun Apr 29 
> 10:13:09 EDT 2018 root@BSD_12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL  
> amd64 1200062
> 
> I have been seeing this recently when upgrading ports, any suggestions how to 
> fix would be appreciated.
> 
> Thanks
> 
> 
> # portupgrade -va
> --->  Session started at: Sun, 29 Apr 2018 17:03:25 -0400
> [Reading data from pkg(8) ... - 935 packages found - done]
> ** Port directory not found: devel/py-setuptools@py27
> ** Port directory not found: graphics/py-cairo@py36
> ** Port directory not found: devel/py-gobject3@py36
> ** Port directory not found: devel/py-setuptools@py36

Make sure your pkg and portupgrade utilities have current versions.

___
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: request for a new port + package

[Eugene Grosbein]

20.04.2018 3:22, Julian Elischer wrote:

>> The package is created automatically once new port is created and added
>> to FreeBSD Ports collection. You can create and submit new port yourself,
>> just read https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/
> 
> It seems to me that the description of what to do to make a port
> is somewhat recursive by which I mean you need to understand
> what it says before you read it. if you don't already know the jargon,
> it is all Greek. (Apologies to any Greeks on the list).

That means the language should be simplified (or thesaurus added :-)

> I think it would be a pretty cool project to write a tool that asks
> lots of questions and then eventually spits out a port Makefile.

I don't believe this is possible for ports other that are trivial to create 
without any tool.

> it could allow the user to browse to places and then analyse the
> links used etc.
> I think the port writer's handbook is a bit intimidating to new ports 
> submitters.

___
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: request for a new port + package

[Eugene Grosbein]

On 09.04.2018 14:16, Mayuresh Kathe wrote:

> how do i place a request for a new port + package?
> the sources for my requested tool are available at 
> http://www.t3x.org/files/zenlisp.zip and the author of that tool has 
> granted permission to move it from the existing "public domain" license 
> to any "bsdl" license.

The package is created automatically once new port is created and added
to FreeBSD Ports collection. You can create and submit new port yourself,
just read https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/


___
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: Not much reason to have */R-cran-* ports

[Eugene Grosbein]

21.03.2018 3:32, Yuri wrote:

> On 03/20/18 11:20, Eugene Grosbein wrote:
>> It is a bit funny you are bothered on 250 R-cran-* ports when we have 1908 
>> p5-* ports,
>> 964 py-* ports, 600 rubygem-* ports and 280 hs-* ports in the single 
>> ports/devel category.
>>
>> Are you planning to ban and remove p5 ports too? Most of them should be from 
>> CPAN.
>> We had BSDPAN for some time even...
> 
> 
> You are missing the key differences:
> 
> 1. Python and perl ports represent individually run software with their own 
> executables,
> when R doesn't. R packages are only useful in the context of R, as building 
> blocks of larger R
> programs only runnable in R environment. R packages are much more dependent 
> on environment.

This is exactly the same for most of devel/p5-* ports as they are just Perl 
libraries (modules)
only useful in the context of Perl as building blocks of larger Perl programs 
only runnable
in Perl environment.

___
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: Not much reason to have */R-cran-* ports

[Eugene Grosbein]

21.03.2018 0:01, Yuri wrote:

> FreeBSD should consider banning and removing them, in the same way as Go 
> libraries are banned.

Inability to download fixed and known working version and surely not hijacked 
distfile
of Go library is really bad. That is, one of strongest sides of FreeBSD Ports 
collection is that
it is a source of checksums stored independently of distfiles themselves.
So, our users are not vulnerable to attacks replacing distfiles with hacked 
copies.

Aside of that, it is very bad habit of Go software to actively download some 
ever changeing code
at compile time for many other reasons. I've faced it porting 
sysutils/fusefs-webdavfs.
I was lucky there were only three such dependency and two of them have Github 
repositories
so it is possible to download distfiles for fixed known revisions.

Third dependency got to standard Go distribution since its 1.7 release and 
simple
invocation of sed successfully prevents it from fetching 
golang.org/x/net/context
while building. Otherwise, I doubt that reliable port would be possible to 
create.

I wonder how other Go ports deal with external library dependencies.

And are you sure that R package manager is compatible with FreeBSD 
ports/packaging system?

Also, please take a look at 
https://www.mail-archive.com/freebsd-ports@freebsd.org/msg77613.html

It is a bit funny you are bothered on 250 R-cran-* ports when we have 1908 p5-* 
ports,
964 py-* ports, 600 rubygem-* ports and 280 hs-* ports in the single 
ports/devel category.

Are you planning to ban and remove p5 ports too? Most of them should be from 
CPAN.
We had BSDPAN for some time even...

Eugene Grosbein

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

Re: net/viamillipede seeks commiter

[Eugene Grosbein]

03.03.2018 12:06, Kurt Jaeger wrote:

>>> .include 
> [...]
>>> install: 
>>> /wrkdirs/usr/ports/net/viamillipede/work/stage/usr/local/bin/viamillipede: 
>>> chown/chgrp: Operation not permitted
> 
>>> Can you try to use a different approach and test it using poudriere ?
> 
>> Isn't it just a bug of poudriere's approach? There is nothing
>> wrong in just using bsd.prog.mk.
> 
> The plan behind poudriere is to build under an unprivileged account.

build != install

That's not any business of poudriere to deside how binaries need to be 
installed.

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

Re: net/viamillipede seeks commiter

[Eugene Grosbein]

03.03.2018 11:48, Kurt Jaeger wrote:

> Thanks, I tried to work on it.
> 
> The suggested port does not install using poudriere.
> 
> It uses
> 
> .include 
> 
> to get the install framework to install the program. This fails,
> as bsd.prog.mk assumes that it is allowed to use chown/chgrp, which
> is not the case while building under poudriere. And the program
> itself does not really need to be installed to be owned by root.
> 
> The error in poudriere is reported as this:
> 
> ===>   Generating temporary packing list
> install  -s -o root -g wheel -m 555   viamillipede 
> /wrkdirs/usr/ports/net/viamillipede/work/stage/usr/local/bin/viamillipede
> install: 
> /wrkdirs/usr/ports/net/viamillipede/work/stage/usr/local/bin/viamillipede: 
> chown/chgrp: Operation not permitted
> 
> Can you try to use a different approach and test it using poudriere ?

Isn't it just a bug of poudriere's approach? There is nothing wrong in just 
using bsd.prog.mk.

___
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: daily security run output and joomla3

[Eugene Grosbein]

29.01.2018 1:04, Larry Rosenman wrote:

>> Accoding to the messages of security periodic sript, the problrem is
>> not checksum mismatch but lost of package files. And "pkg check -r"
>> cannot recover it. So you should reinstall www/joomla3.
>>
> But as the OP notes, the joomla3 instructions *REQUIRE*
> removal of the install directory for security reasons, so 
> I understand where he is coming from. 
> 
> As the maintainer, I'm not sure how to fix it.

It is obvious: "install directory" should be removed from plist,
the port should supply convenient target to perform this removal
and there should be pkg-deinstall procedure to remove that directory
upon package deinstallation.




signature.asc
Description: OpenPGP digital signature

Re: 'pkg upgrade -f spamassassin' stops but doesn't restart spamd

[Eugene Grosbein]

08.01.2018 18:11, Miroslav Lachman wrote:

>>> PRs are false alibi. Some of my PRs are open for more than 10 years.
>>
>> So were mine when I could not commit fixes myself. This is not excuse to be 
>> lazy and not make another one.
>>
>>> For all erroneous port there must be will on maintainer and committer side.
>>> And if "they" think this is not a bug
>>
>> If we have written policy (and we have in this case), and upgrade really 
>> break things,
>> sane committer will not think "this is not a bug".
>>
>> Again, do you have a PR with "how-to-repeat" scenario and a patch,
>> so I could take it?
> 
> OK, let's move on. I can open PR if you are willing to help and commit some 
> fixes. But can we first talk 

Relevant discussion should better take place in the PR itself so it's not lost
and easier to point to when asking corresponding parties, f.e. portmgr@

You may open PR without patch too, you know. But it needs clear description of 
the problem
and "how-to-repeat".

___
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 upgrade -f spamassassin' stops but doesn't restart spamd

[Eugene Grosbein]

08.01.2018 4:00, Miroslav Lachman wrote:

> PRs are false alibi. Some of my PRs are open for more than 10 years.

So were mine when I could not commit fixes myself. This is not excuse to be 
lazy and not make another one.

> For all erroneous port there must be will on maintainer and committer side.
> And if "they" think this is not a bug

If we have written policy (and we have in this case), and upgrade really break 
things,
sane committer will not think "this is not a bug".

Again, do you have a PR with "how-to-repeat" scenario and a patch,
so I could take it?

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

Re: 'pkg upgrade -f spamassassin' stops but doesn't restart spamd

[Eugene Grosbein]

08.01.2018 3:36, Miroslav Lachman wrote:

>> There IS consensus on modifying config files while upgrade and it is written 
>> in our Porter's Handbook:
>> only unmodified files may be changes with upgrade. Any other behaviour is a 
>> bug that should be fixed.
> 
> If it is that simple then tell me how it is possible that for many years 
> there are repetitive discussions
> and many ports with many commits violating this "rule"?

Because:

1) People are lazy and make errors creating ports violating Porter's handbook 
instructions;
2) People are lazy and do not create formal Problem Reports even when they are 
annoyed
hoping that SomeOne (TM) would do that for them.

Where are your PRs?

___
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 upgrade -f spamassassin' stops but doesn't restart spamd

[Eugene Grosbein]

07.01.2018 22:10, Miroslav Lachman wrote:

>> I am following 11-STABLE and therefore upgrading my system quite frequently. 
>> During that process I do recompile all ports installed by poudriere and 
>> upgrade all ports after reboot.
> There are no consensus about what services should do on deinstall or upgrade. 
> That's why there is such a mess in ports / packages.
> Some did nothing (my preferred way), some stop (but did not start) the 
> service,
> some modify user edited config files (removing / disabling modules in 
> httpd.conf so Apache is broken on each upgrade of module(s)).

There IS consensus on modifying config files while upgrade and it is written in 
our Porter's Handbook:
only unmodified files may be changes with upgrade. Any other behaviour is a bug 
that should be fixed.

___
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: using security/openssl in a port

[Eugene Grosbein]

05.01.2018 11:16, Matthew Luckie пишет:
> On 1/5/18 5:09 PM, Eugene Grosbein wrote:
>> On 05.01.2018 09:44, Matthew Luckie wrote:
>>
>>> My main worry is that I could not find a single port that apparently
>>> depends on security/openssl.  I'm worried that its more complicated than
>>> simply declaring a dependency on security/openssl on particular freebsd
>>> versions because other ports that use openssl might link against it
>>> without registering a dependency.  Is my worry misplaced?
>>
>> Why don't you read the Porter's Handbook? It has answers to all your 
>> questions:
>>
>> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/uses-ssl.html
> 
> I already said that I considered USES = ssl and that it didn't seem to
> address my concerns.  Can you please point me at a port that depends on
> OpenSSL from ports using USES = ssl (or whatever this page of the
> porters handbook is trying to tell me to do).

For example, net/vtun has this:

.include 

.if ${SSL_DEFAULT:Mopenssl-devel}
BROKEN= Does not build with openssl-devel
.endif

.include 

That is, it stops build if user has specified SSL_DEFAULT=openssl-devel.
You need to stop build if FreeBSD version is old and user has NOT specified
SSL_DEFAULT=openssl (instead of SSL_DEFAULT=base) to build your port with 
security/openssl.





signature.asc
Description: OpenPGP digital signature

Re: using security/openssl in a port

[Eugene Grosbein]

On 05.01.2018 09:44, Matthew Luckie wrote:

> My main worry is that I could not find a single port that apparently
> depends on security/openssl.  I'm worried that its more complicated than
> simply declaring a dependency on security/openssl on particular freebsd
> versions because other ports that use openssl might link against it
> without registering a dependency.  Is my worry misplaced?

Why don't you read the Porter's Handbook? It has answers to all your questions:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/uses-ssl.html


___
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: using security/openssl in a port

[Eugene Grosbein]

05.01.2018 9:11, Matthew Luckie wrote:

> I maintain a port that has a new release which requires openssl 1.0.2 to
> build.  FreeBSD 10.3 and 10.4 both have openssl 1.0.1, and 11 onwards
> have 1.0.2.  Is there a magic way to have this port depend on ports
> openssl for freebsd releases without openssl 1.0.2?  I ran
> 
> find /usr/ports -exec grep "security/openssl" {} \; -print
> 
> and didn't find anything that I could use as a recipe.  USES = ssl
> doesn't seem to be it either.

https://www.freebsd.org/doc/en/books/porters-handbook/porting-versions.html
https://www.freebsd.org/doc/en/books/porters-handbook/versions-11.html

FreeBSD had openssl-1.0.1 in the base before import of 1.0.2d (1100085),
so use this in the port's Makefile:

.if ${OPSYS} == FreeBSD && ${OSVERSION} < 1100085
# add dependency here
.endif

___
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: Any way to make pkg use 'sudo' instead of 'su' to install as root?

[Eugene Grosbein]

01.01.2018 1:28, Yuri пишет:
> 'make install' calls pkg, which does su to change to the root account. su 
> asks for the root password again and again when there are many packages to 
> install.
> 
> Is there any way to configure this to be 'sudo'?

Why don't you use "sudo pkg" ?


___
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: 6100 subdirectories in /usr/ports/devel!

[Eugene Grosbein]

29.12.2017 4:16, Bob Willcox wrote:

>> In fact, ports/devel is first but not only category having similar problem 
>> with p5-* stuff:
>>
>> $ cd /usr/ports
>> $ find . -type d -mindepth 1 -maxdepth 1 | while read category; do printf 
>> "%15s " ${category#./}; ls $category | sed 's/-.*//' | sort | uniq -c | sort 
>> -rn | head -1; done | sort -k 2,2 -rn | head -15
>>   devel 1908 p5
>> www  807 p5
>>textproc  617 p5
>> net  327 p5
>>   databases  259 p5
>>security  258 p5
>>math  146 p5
>>mail  145 p5
>>graphics  100 p5
>> editors   98 libreoffice
>>sysutils   75 rubygem
>>  converters   72 p5
>>misc   63 p5
>>net-mgmt   56 p5
>>x11-toolkits   49 p5
>>
> 
> Yeah, I happened to notice the py-* stuff due to some problems I have been
> having with synth. I did notice the large number of p5-* subdirs but didn't
> count them.  :)
> 
> Certainly seems to be out of control...

I like we have all this p5-* stuff in the Ports.
It seems that 1900+ devel/p5-* ports justify new p5-devel or devel-p5 category, 
though.

But wouldn't such large move become a nightmare for users updating their 
systems?

___
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: 6100 subdirectories in /usr/ports/devel!

[Eugene Grosbein]

29.12.2017 3:36, Bob Willcox wrote:

>> Does anyone else feel that having 6100 subdirectories (939 are for py-* 
>> stuff)
>> is a bit excessive?
> 
> It is. But py-* stuff has second place only:
> 
> $ ls /usr/ports/devel | sed 's/-.*//' | sort | uniq -c | sort -rn | head
> 1908 p5
>  964 py
>  600 rubygem
>  280 hs
>  176 pear
>   57 R
>   56 pecl
>   48 elixir
>   47 geany
>   43 erlang

In fact, ports/devel is first but not only category having similar problem with 
p5-* stuff:

$ cd /usr/ports
$ find . -type d -mindepth 1 -maxdepth 1 | while read category; do printf "%15s 
" ${category#./}; ls $category | sed 's/-.*//' | sort | uniq -c | sort -rn | 
head -1; done | sort -k 2,2 -rn | head -15
  devel 1908 p5
www  807 p5
   textproc  617 p5
net  327 p5
  databases  259 p5
   security  258 p5
   math  146 p5
   mail  145 p5
   graphics  100 p5
editors   98 libreoffice
   sysutils   75 rubygem
 converters   72 p5
   misc   63 p5
   net-mgmt   56 p5
   x11-toolkits   49 p5


___
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: 6100 subdirectories in /usr/ports/devel!

[Eugene Grosbein]

29.12.2017 3:36, Bob Willcox wrote:

> Does anyone else feel that having 6100 subdirectories (939 are for py-* stuff)
> is a bit excessive?

It is. But py-* stuff has second place only:

$ ls /usr/ports/devel | sed 's/-.*//' | sort | uniq -c | sort -rn | head
1908 p5
 964 py
 600 rubygem
 280 hs
 176 pear
  57 R
  56 pecl
  48 elixir
  47 geany
  43 erlang


___
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 reinstall pkg(8) itself?

[Eugene Grosbein]

27.12.2017 23:13, Christian Weisgerber пишет:
> Eugene Grosbein:
> 
>>> You have pkg(8) installed, but want to recompile and reinstall it.
>>> How do you do this?
>>
>> Use pkg-static.
> 
> How?

"pkg-static install -f pkg" if you already have newly built local package file
for pkg itself or just "make deinstall install" in the ports-mgmt/pkg directory
to compile it before same move.


___
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 reinstall pkg(8) itself?

[Eugene Grosbein]

27.12.2017 22:33, Christian Weisgerber пишет:
> You have pkg(8) installed, but want to recompile and reinstall it.
> How do you do this?

Use pkg-static.


___
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: Procmail got updated!

[Eugene Grosbein]

23.12.2017 14:12, Kevin Oberman wrote:

> >>> So, you demand we stop shipping any unmaintained software with our 
> Ports & Packages?
> >>> Absence of CVEs means nothing and almost any non-trivial software has 
> bugs (axiom).
> >> Eugene, these are attempts to distract from the argument, or to mount 
> to
> >> fallacies. I do not intend to respond further to them or other of your
> >> messages in this thread.
> > That was real question, I like to know the answer.
> That generic question bears no relevance to the procmail case.
> OK. It looked  like a reasonable question and a one-liner answer which seemed 
> to say "I can't justify anything here" or "I don't want to bother". So maybe 
> it could be clarified.
> 
> First, I don't think Eugene meant "unmaintained by FreeBSD" but unmaintained 
> upstream. Or maybe both. Can you clarify, Eugene?

Unmaintained upstream, unmaintained in the Ports Collection. This was not about 
any part of FreeBSD base.

___
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: Procmail got updated!

[Eugene Grosbein]

22.12.2017 9:50, Matthias Andree пишет:
> Am 21.12.2017 um 10:16 schrieb Eugene Grosbein:
> 
>> So, you demand we stop shipping any unmaintained software with our Ports & 
>> Packages?
>> Absence of CVEs means nothing and almost any non-trivial software has bugs 
>> (axiom).
> 
> Eugene, these are attempts to distract from the argument, or to mount to
> fallacies. I do not intend to respond further to them or other of your
> messages in this thread.

That was real question, I like to know the answer.


___
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: Procmail got updated!

[Eugene Grosbein]

On 21.12.2017 14:24, Matthias Andree wrote:

 What happened with old good "Tools, not policy" thing?
>>>
>>> It's simpler than that, no policy involved.
>>>
>>> The tool had a hollow head, and broke after several years of banging it,
>>> and the former tool maker told the public it's out of warranty (never
>>> was in due to it being free) and not being fixed any more, and should be
>>> scrapped.
>>
>> I'm a little unsettled by this discussion, because it is moving into
>> territory with which we have very little precedent. And the precedent
>> that it would establish is not wholly within our mandate.
>>
>> FreeBSD ports provides the best available versions of software to run
>> on FreeBSD---we have traditionally been very conservative in
>> deprecating software. The mere fact that there are better alternatives
>> is not sufficient reason to take it away from people. When it ceases
>> to work, or is intolerably dangerous, then it is incumbent upon us to
>> act. You know far, far more about the intricacies of email than I do,
>> Matthias, so please correct me if I am incorrect here, but I'm not
>> aware of procmail being unsuitably dangerous for admins who make a
>> conscious decision to use it.
>>
> 
>  is all it
> needs to mount the various mentioned cases, such as dangerous, bitrotten
> and whatever other arguments have been asked for.
> 
> Given two CVEs and another crasher fixed in 3.22_5, that is reason
> enough to reconsider. We either need to take responsibility and have the
> port audited and someone paid to maintain it properly, or remove it, or
> at least we need to move it into the poison cabinet and lock it up (i.
> e. set DEPRECATED due to missing upstream maintenance and FORBIDDEN +
> NOPACKAGE due to it being dangerous),
> 
> This is not to belittle ache@ (until 2011) or sunpoet@s and the
> contributors' efforts, but really about the upstream software that we
> are shipping.

We do not "ship" procmail. It is not part of FreeBSD.
It is third-party software packaged for user's convenience without any 
guarantee.

So, you demand we stop shipping any unmaintained software with our Ports & 
Packages?
Absence of CVEs means nothing and almost any non-trivial software has bugs 
(axiom).

___
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: Procmail got updated!

[Eugene Grosbein]

On 21.12.2017 07:35, Kevin Oberman wrote:

>>> What happened with old good "Tools, not policy" thing?
>>
>> It's simpler than that, no policy involved.
>>
>> The tool had a hollow head, and broke after several years of banging it,
>> and the former tool maker told the public it's out of warranty (never
>> was in due to it being free) and not being fixed any more, and should be
>> scrapped.
> 
> It still works (painfully) and is used by many.  They would be wise to
> stop, but it is not the job of the project to force them to do so,
> 
> I do think that a pkg-message with "Here there be dragons! Proceed at your
> own risk. dropmail is a MUCH safer (and easier) path." would be
> appropriate.

+1

> I don't think it is the job of the project to force people to
> replace it if they think they know what they are doing. Of course, bitrot
> or similar may take it before long.

___
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: Procmail got updated!

[Eugene Grosbein]

On 20.12.2017 01:03, Matthias Andree wrote:

> Dear Ted, Eugene,

[skip]

What happened with old good "Tools, not policy" thing?


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