Re: FreeBSD ports which are currently scheduled for deletion

[Stefan Esser]

Am 21.06.2012 10:29, schrieb lini...@freebsd.org:
> portname:   audio/gstreamer-plugins-flite
> description:Gstreamer flite run-time speech synthesis engine
> plugin
> maintainer: multime...@freebsd.org
> status: BROKEN
> deprecated because: BROKEN for more than 6 month
> expiration date:2012-05-10
> build errors:   none.
> overview:   
> http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=gstreamer-plugins-flite

I just tried building this port and it built and packaged without any
problems. Is the compile log still available that lead to this port
being marked broken?

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

PKG_NG: pkg deinstall fails with "argument list too long"

[Stefan Esser]

PKG_NG seems to have introduced a limit on the size of ports that can be
deinstalled:

# cd /usr/ports/math/lapack
#  make deinstall
===>  Deinstalling for math/lapack
===>   Deinstalling lapack-3.4.0_2
The following packages will be deinstalled:

lapack-3.4.0_2

The deinstallation will free 28 MB
Deinstalling lapack-3.4.0_2...lapack-3.4.0_2 is required by:
qrupdate-1.1.1, deleting anyway
pkg: Cannot run script(DEINSTALL): Argument list too long
*** [deinstall] Error code 3

This is on an up-to-date -CURRENT with freshly fetched ports and
pkg-1.0.r6_1 and WITH_PKGNG=yes in /etc/make.conf.

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

Re: PKG_NG: pkg deinstall fails with "argument list too long"

[Stefan Esser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 27.08.2012 23:23, schrieb Baptiste Daroussin:
> On Mon, Aug 27, 2012 at 10:22:27PM +0200, olli hauer wrote:

Please do not hijack this thread, even if you are also reporting a
problem with PKG_NG. Threads are free and nobody bothered to reply
to the more urgent problem of the failed deinstallation.

>> On 2012-08-27 20:03, Stefan Esser wrote:
>>> PKG_NG seems to have introduced a limit on the size of ports
>>> that can be deinstalled:
>>> 
>>> # cd /usr/ports/math/lapack #  make deinstall ===>
>>> Deinstalling for math/lapack ===>   Deinstalling
>>> lapack-3.4.0_2 The following packages will be deinstalled:
>>> 
>>> lapack-3.4.0_2
>>> 
>>> The deinstallation will free 28 MB Deinstalling
>>> lapack-3.4.0_2...lapack-3.4.0_2 is required by: qrupdate-1.1.1,
>>> deleting anyway pkg: Cannot run script(DEINSTALL): Argument
>>> list too long *** [deinstall] Error code 3

I have located the line that is causing this error. It is the
posix_spawn on line 102 of libpkg/script.c. The argument length
is limited to KERN_ARGMAX (sysctl kern.argmax) which seems to
be a R/O value initialized to 256KB.

AFAICT this is not even a loader tuneable. A new kernel must
be built, or pkg must be modified to honor the argument length
limit.

The argument is the string argument of "sh -c ", which
can not be split in the general case.

In the specific case of math/lapack, the arguments to execve()
(called by posix_spawn()) are:

argv[0] = "sh"
argv[1] = "-c"
argv[2] = " set -- lapack-3.4.0_2
rm -f /usr/local/man/cat3/INSTALL_ilaver.f.3.gz ...
/usr/local/man/cat3/zupmtr.f.3.gz.bz2"

The argument list must be broken into pieces of less than 256KB,
since rising KERN_ARGMAX to >330KB will lead to the same problem
with the next port with even longer PLIST.

Regards, STefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlA8jA8ACgkQ69HRkrVjAEzuXgCfTP0gdtRa2CqWp3iWwKu90LO8
ThkAniYRTiGP870wrHwGKCg/F1UmWneF
=UqHR
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

PR 171155 (was: Re: PKG_NG: pkg deinstall fails with "argument list too long")

[Stefan Esser]

I have created PR ports/171155 to report the issue, that
ports with long PLISTs cannot be deinstalled with PKGNG:

http://www.freebsd.org/cgi/query-pr.cgi?pr=171155

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

[patch] Portaudit and PKGNG

[Stefan Esser]

PR ports/171406 contains a patch I submitted to make portaudit work with
PKGNG:

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/171406

It works on my systems, but definitely needs further review. The
patch just replaces "pkg_info" by "pkg info" and "pkg_version" by
"pkg version". This works fine, since PKGNG apparently supports
all the required options and kept the output format unchanged
compared to the old framework.

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

Re: [patch] Portaudit and PKGNG

[Stefan Esser]

Am 10.09.2012 09:27, schrieb Stefan Esser:
> PR ports/171406 contains a patch I submitted to make portaudit work with
> PKGNG:
> 
>   http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/171406
> 
> It works on my systems, but definitely needs further review. The
> patch just replaces "pkg_info" by "pkg info" and "pkg_version" by
> "pkg version". This works fine, since PKGNG apparently supports
> all the required options and kept the output format unchanged
> compared to the old framework.
> 
> Regards, STefan

Seems this patch is not required, since "pkg audit" implements the
functionality (but with a changed message format, so scripts that
parse portaudit output need to be modified).

Therefor the patch is not really useful ...

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

Re: FreeBSD 10.0-CURRENT/amd64 r242305: www/apache22: setfib: NO: invalid FIB (max 0)

[Stefan Esser]

Am 30.10.2012 09:28, schrieb O. Hartmann:
> Am 10/29/12 14:57, schrieb Rainer Hurling:
>> Am 29.10.2012 14:19 (UTC+1) schrieb O. Hartmann:
>>> Hello world.
>>> 
>>> With the most recent FreeBSD 10.0-CURRENT/amd64 r242305, CLAN
>>> buildworld and with libc++/c++11 compiled, I can not start the
>>> Apache 2.22 webserver anymore and receive this error on all
>>> boxes:
>>> 
>>> 
>>> service apache22 restart Performing sanity check on apache22
>>> configuration: Syntax OK apache22 not running? (check
>>> /var/run/httpd.pid). Performing sanity check on apache22
>>> configuration: Syntax OK Starting apache22. setfib: NO: invalid
>>> FIB (max 0) /usr/local/etc/rc.d/apache22: WARNING: failed to
>>> start apache22
>> 
>> I don't know, if this is intended. But the following entry in 
>> /etc/rc.conf helps restarting the server:
>> 
>> apache22_fib=0
>> 
>> This is mentioned in the updated rc.conf(5).
>> 
> 
> Thanks. This helped and seems to resolve the problem.

Yes, but does not fix the underlying problem.

r242184 added setfib(1) support to rc.subr and assumes, that any
non-blank value is a FIB number.

But the RC script for apache sets "apache_fib" to "NO" if it does
not contain a FIB number.

This leads to a comamnd "setfib -F NO apache" and setfib complains
about the non-zero value.

I assume that the apache RC script should be modified to not pass
apache22_fib="NO" for the case of no FIB. OTOH, the code in rc.subr
could be changed to accept "NO" as equivalent to an empty value of
the FIB variable.

Setting "apache22_fib=0" just hides the problem. It does not harm,
but the default of not specifying a FIB should just work.

Regards, STefan

PS: I'll open a PR ...
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Should we Rust warnings suggesting adding work/stage/usr/local/bin to the PATH?

[Stefan Esser]

Am 17.05.18 um 14:42 schrieb Mateusz Piotrowski:
> Hello,
> 
> When I build Rust packages I get warnings like this one:
> 
>> warning: be sure to add 
>> `/usr/home/0mp/ports/games/genact/work/stage/usr/local/bin` to your PATH to 
>> be able to run the installed binaries
> 
> It is not very helpful when building ports. Do you think that we should
> try to mute it by default?

I have seen such a message when building a Haskell based port, too.

Seems there are more languages (or build systems) that perform such
a check and emit a misleading warning ...

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

Re: Why portmaster uses g++ not g++6 nor clang++?

[Stefan Esser]

Am 18.05.18 um 17:13 schrieb Koichiro Iwao:
> Hi,
> 
> I'm building devel/qt5-make by portmaster. Somehow portmaster incorrectly
> detects gcc6 and uses g++ despite it is actually installed as g++6. If I > 
> build it without portmaster, clang++ is used and build finishes successfully.

Sorry, this was my fault and I hope it is fixed with the follow-up commit
to portmaster version 3.19-10.

I had received a proposed patch to significantly speed-up portmaster by
caching of a few parameters in environment variables. My commit was meant
to work around a side effect of the proposed patch (sourcing of a script
imported several unused subroutines into portmaster and I wanted to just
use the result of execution of the one relevant subroutine, but missed the
fact that the quoting came out wrong ...).

(If you are interested: The environment variable _CXXINTERNAL_acaad9ca
should contain the literal character sequence "-lc++" including the
double quotes, when I use eval as in the defective version, I either get
no quotes around -lc++ or I get extra double-quotes around the whole
variable, if I eval the script output piped through sed s:":\\:" ...)

Since I did not manage to get the correct result without sourcing the
script, I gave in and accept the fact, that these subroutines are now
imported into portmaster.

Anyway, I hope my latest commit has fixed the problem ...

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

Re: Why portmaster uses g++ not g++6 nor clang++?

[Stefan Esser]

Am 18.05.18 um 22:17 schrieb Rozhuk Ivan:
> On Fri, 18 May 2018 20:30:38 +0200
> Stefan Esser  wrote:
> 
>> Sorry, this was my fault and I hope it is fixed with the follow-up
>> commit to portmaster version 3.19-10.
>>
> 
> Sorry for offtopic, but if portmaster install some build dep or run dep
> if does not mark it as autoinstalled, and:
> pkg query -e '%a = 0' %o
> show autotools, help2man and other build only crap as user install it,
> pkg autoremove
> does not remove this.
> 
> Also --delete-build-only broken.
> 
> portmaster -BgvDa -y --delete-build-only 
> --local-packagedir=/usr/ports/packages --packages-local
> if found some package - install it, and after install create package and 
> overwrite original.
> pkg create -n will prevent this, or additional checks, or just keep remember 
> that pkg allready
> exist because port just installed from it.

I'm working on a completely new re-implementation of portmaster and the new
version will get these points right. Fixing the current port version is too
hard and wasted effort, since only the features and command line options are
carried over, but none of the code of the current version.

The current port master port was written at the time of the "old" package
management tools (pre PKG-NG). It took me quite some time and effort to
implement flavors support in that version, and I found that it is much
harder to maintain that version than to rewrite it with the current package
tools in mind.

The new version is already able to upgrade ports, but it lacks some of the
features of the old version (e.g. installation from local packages). But it
is already better at tracking changes, e.g. as in the recent KDE4 port and
package renaming (where both port directory and package name were changed
at the same time and the current portmaster in ports has no way to track
this change and to upgrade the affected ports).

But I'm not going to implement all features of the current portmaster. E.g.
I have no plan to implement dependency tracking via the INDEX file or the
installation of packages from a remote repository (since mixing locally
compiled and official packages is not well supported). But I plan to offer
the installation of build dependencies from locally cached packages (and
the deinstallation after they are no longer required).

But the use case you described in your mail will be covered.

I hope to have the new version ready for testing as a portmaster-devel port
before the end of June.

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

Re: net-p2p/qbittorrent needs to be unblocked by portmgr

[Stefan Esser]

Am 20.06.18 um 10:34 schrieb Tobias Kortkamp:
> On Wed, Jun 20, 2018, at 10:18, Yuri wrote:
>> Committing transaction...
>> svn: E165001: Commit failed (details follow):
>> svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:
>> Do not commit a port with FLAVORS without first
>> getting approval from portmgr.
>>
> 
> What happens when you add something like
> 
> Approved by:  portmgr (???)
> 
> to the commit message?

... after getting approval from portmgr to be allowed to state approval?

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

Re: rubgem update to 3.2.7

[Stefan Esser]

Am 09.07.18 um 05:04 schrieb Koichiro Iwao:
> On Mon, Jul 09, 2018 at 12:02:22AM +0200, Walter Schwarzenfeld via 
> freebsd-ports wrote:
>> Portmaster tries to build the update in the wrong order.
>>
>> Right order for me was (depend on which packages are installed):
>>
>> rubygem-glib2
>> rubygem-gobject-introspection
>> rubygem-gio2
>> rubygem-gdk_pixbuf2
>> rubygem-pango
>> rubygem-gdk3
>>
>> rubygem-gtk3
>>
>> rubygem-atk
> 
> I can also confirm the issue. I always perform portmaster in order that
> you shown by hand when rubygem-gtk ports updated. portmaster needs to be 
> fixed.

A quick check shows that this is a problem with the port, which obviously
declares actual build dependencies as run dependencies.

Please open a PR and let the ruby maintainers fix this issue.

E.g. in x11-toolkits/rubygem-gtk3/Makefile:

RUN_DEPENDS=rubygem-atk>=${PORTVERSION}:accessibility/rubygem-atk \
rubygem-gdk3>=${PORTVERSION}:x11-toolkits/rubygem-gdk3 \

rubygem-gdk_pixbuf2>=${PORTVERSION}:graphics/rubygem-gdk_pixbuf2 \
rubygem-gio2>=${PORTVERSION}:devel/rubygem-gio2 \
rubygem-glib2>=${PORTVERSION}:devel/rubygem-glib2 \

rubygem-gobject-introspection>=${PORTVERSION}:devel/rubygem-gobject-introspection
\
rubygem-pango>=${PORTVERSION}:x11-toolkits/rubygem-pango

Run dependencies are generally built after the port that needs them, since
they may themselves depend on resources provided by the respective port.

Build dependencies OTOH provide those files that need to be updated before
building a port. They may also be run dependencies (and often are), and in
that case they need to be in both the BUILD_DEPENDS and RUND_DEPENDS lists.

I cannot modify the behavior of portmaster (i.e. build run dependencies
before the port that needs them, since this would break quite a number of
other ports with correct dependency specifications: Then portmaster would
try to build run dependencies before their prerequisites are available).

So, I'm sorry, but portmaster will not be able to upgrade the rubygem ports
in the correct order, unless the port dependencies are fixed.

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

libkgapi-18.08 conflicts with kdepim-runtime-18.04.3_2

[Stefan Esser]

This might be no problem when upgrading from a package, but upgrading from a
port (e.g. with portmaster) fails with:

===>   Registering installation for libkgapi-18.08.0
Installing libkgapi-18.08.0...
pkg-static: libkgapi-18.08.0 conflicts with kdepim-runtime-18.04.3_2 (installs
files into the same place).  Problematic file:
/usr/local/lib/sasl2/libkdexoauth2.so
*** Error code 70

I had expected some information in UPDATING or a conflicts entry, which
matches kdepim-runtime<=18.04 or something like that ...

What is the correct way to deal with that problem?

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

Re: Ports vs packages

[Stefan Esser]

Am 26.08.18 um 21:55 schrieb Gregory Byshenk:
> On Sun, Aug 26, 2018 at 01:01:24PM +0200, Jos Chrispijn wrote:
>> On 26-8-2018 2:07, Pete Wright wrote:
>>> one thing i do for my systems is if there is an update to a port i 
>>> need/want to test before the official build cluster is done is run a 
>>> "make package" in the port directory.? then i can install the updated 
>>> code as a pkg for future upgrade convenience.? this works great for 
>>> ports without many external dependencies at build-time, not so much 
>>> when things like llvm need to be build ;)
>>
>> I did that once myself but ended in total chaos because I found out that 
>> using ports and packages next to each other is not a good marriage.
>> Port options that may have been enabled may be overuled by packages 
>> (which are always built using the default options). Not for a specific 
>> port but with regards to the depencies is will us (and which may already 
>> been installed as packages).
>>
>> I am quite a nub on this, so perhaps the problems were otherwise. Since 
>> I completely switched to packages, these issues are gone.
> 
> If you are using packages by default, then this shouldn't
> really be a problem. Your packages should have default 
> options, so if you build one port - using the default 
> options! - then there should be no serious conflict. At
> least when there are few/no dependencies, as Pete notes.
> 
> Where you can get into problems is if you are building 
> using ports by default, along with non-standard options,
> and then try to add packages. That can get very ugly.

To be fully compatible with official packages, you have to build in
Poudriere with the same FreeBSD version as used of the official builds.

Building in your host environment might cause conflicts between shared
libraries, if the shared library version used for the packages (from the
oldest supported release of the FreeBSD version you use) might be too old
to match what you use in a newer release of that FreeBSD version.

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

Re: RUN_DEPENDS and portmaster

[Stefan Esser]

Am 10.09.18 um 06:54 schrieb Matthias Fechner:
> Dear all,
> 
> I have a questions reagarding the RUN_DEPENDS and at which step
> dependencies should be installed.
> I'm the maintainer of gitlab-ce port and I added a feature that checks
> in the install target:
> do-install:
> (cd ${WRKSRC} && ${RM} Gemfile.lock && bundle install --local)
> ${FIND} ${WRKSRC} -name '*.orig' -delete
> ...
> 
> that all gems available in the system do match the version required by
> the Gemfile.
> Poudriere works fine with this, but portmaster fails.
> Regarding the documentation RUN_DEPENDS packages should be installed
> before the install is happening.

Hi Matthias,

this is the description of the sequence of actions performed by the
ports framework alone.

INSTALLS_DEPENDS covers the case of dependencies that are required
to be available when a port is being installed.

Portmaster installs RUN_DEPENDS only after the port that depends on
them, since it is assumed, that they are actually only required to
execute it after it has been completely installed.

The reason is, that portmaster is typically used to upgrade multiple
ports in such a way, that all BUILD_DEPENDS are up to date (not only
available) when some some dependent port is compiled.

In case that some upgraded port actually is a build dependency of
some other port, it will need to have its run dependencies installed
and upgraded, and portmaster will assure this is the case.

The sequence of upgrade actions was chosen to follow this scheme to
prevent dependency loops (which typically will consist of a mix of
build and run dependencies).

> Is this install related to the do-install target or the installation
> of the package itself?

I have re-implemented portmaster and have been using my version to
maintain my ports since May. Due to several bad design decisions (or
rather the lack of thorough design) of the FLAVOR feature, it took me
quite some effort and time to get performance of that version to an
acceptable level.

Currently I'm building and installing ports in the same order as the
current official portmaster version, but that could easily be changed.

I have considered following the same concept as synth does (i.e. build
ports in a clean environment), at least as an option. But I have not
started to implement such a feature, yet.

> Is this maybe a problem with portmaster as poudiere handles this correctly?

This is a design decision in portmaster that has existed for at least
a decade.

Use INSTALL_DEPENDS if you depend on a port being available and upgraded
before your port's do-install is invoked.

Changing the current portmaster version in ports is no option, since it
does not offer to recursively upgrade or install any other port while
working on some port and it cannot easily be made to support such a
sequence of actions.

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

Re: RUN_DEPENDS and portmaster

[Stefan Esser]

Am 12.09.18 um 07:58 schrieb Matthias Fechner:
> Dear Stefan, Dear Mathieu,
> 
> Am 10.09.18 um 14:10 schrieb Stefan Esser:
>> This is a design decision in portmaster that has existed for at least
>> a decade.
>>
>> Use INSTALL_DEPENDS if you depend on a port being available and upgraded
>> before your port's do-install is invoked.
>>
>> Changing the current portmaster version in ports is no option, since it
>> does not offer to recursively upgrade or install any other port while
>> working on some port and it cannot easily be made to support such a
>> sequence of actions.
> 
> thanks a lot for your explanation, so it seems to be a problem with
> portmaster.
> But as I do not want to block all users from using gitlab-ce that are
> using portmaster I think it is ok to define all RUN_DEPENDS also as
> BUILD_DEPENDS?

Yes, adding them to BUILD_DEPENDS will cause all those ports to be built
and installed by portmaster before the port that executes those tests.

I had thought there also was INSTALL_DEPENDS, but now I see that in fact
there only is INSTALLS_DEPENDS, which is used internally in bsd.port.mk.

So, BUILD_DEPENDS is the variable to use in that case.

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

Re: RUN_DEPENDS and portmaster

[Stefan Esser]

Am 17.09.18 um 07:47 schrieb Matthias Fechner:
> Am 10.09.18 um 12:16 schrieb Mathieu Arnold:
>> Reading Mk/bsd.port.mk at line 5274, run-depends are installed before
>> do-install runs.
> 
> thanks, I see it the same way and created a PR for it, to get this fixed
> in portmaster.

You are of course free to create a PR against portmaster.

But the behavior of portmaster will not be changed.

RUN_DEPENDS are dependencies required to run a port, not dependencies
required to install a port.


And I do not care whether bsd.port.mk treats RUN_DEPENDS as if they
were INSTALL_DEPENDS (which do not exist). The fact that bsd.port.mk
works in that way is due to the fact, that it generally executes sub
processes in a depth first manner. Portmaster distinguishes build and
run dependencies and makes sure, that build dependencies not only exist,
but are updated before the ports they depend on, while bsd.port.mk will
use any build dependency that satisfies the range requirements (if any)
and does not upgrade existing but outdated (in the sense that an upgrade
is available) dependencies. Portmaster will then upgrade any out-dated
run dependencies (again if an upgrade is available, not only if it is
strictly required). Thus portmaster guarantees, that a port is built
with the latest available build tools, and that run dependency upgrades
see the upgraded port that requires them, in case they depend on it.


I have spent hundreds of hours to work around the bad design of the
FLAVOR support, which ignored the requirements of tools like portmaster
or portupgrade. Changes to the port infrastructure tend to ignore the
existence and requirements of build tools that have a decade long
history and use cases not covered by the port infrastructure alone.

I'm not going to spend any time on a change that made portmaster install
RUN_DEPENDS before executing "make install" for a port.

You are free to create a patch to that effect, but be aware that it is
extremely likely to break lots of upgrade scenarios, and I'll make you
responsible for fixing them (or back-out your assumed patch that treats
run dependencies as if they were build dependencies).

Regards, STefan



signature.asc
Description: OpenPGP digital signature

Not a portmaster problem

[Stefan Esser]

Am 17.09.18 um 22:51 schrieb @lbutlr:
> I am using MariaDB 10.0 on FreeBSD 11.3
> 
> When trying to update rsyslogd via postmaster I get:
> 
> checking for mysql_config... mysql_config
> checking for mysql_init in -lmysqlclient... no
> configure: error: in `/usr/ports/sysutils/rsyslog8/work/rsyslog-8.37.0':
> configure: error: MySQL library is missing
> See `config.log' for more details
> ===>  Script "configure" failed unexpectedly.
> Please report the problem to matt...@freebsd.org [maintainer] and attach the
> "/usr/ports/sysutils/rsyslog8/work/rsyslog-8.37.0/config.log" including the
> output of the failure of your make command. Also, it might be a good idea to
> provide an overview of all packages installed on your system (e.g. a
> /usr/local/sbin/pkg-static info -g -Ea).
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/ports/sysutils/rsyslog8
> *** Error code 1
> 
> I’ve disabled the MySQL output for now, but this disconnect between MySQL and 
> Maria seems to be happening with a lot of ports.
> 
> Is there anything I can do to restore the MySQL output for rsylog?

AFAICT, Wolfgang Zenker correctly points at PR 230839.

Portmaster does not appear to play a role - the problem exists when
building without portmaster, too.

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

Re: Error building net/librsync2

[Stefan Esser]

Am 18.09.18 um 12:23 schrieb Jakob Breivik Grimstveit:
> $ uname -a
> FreeBSD core2.grimstveit.no 11.2-RELEASE-p3 FreeBSD 11.2-RELEASE-p3 #7
> r338607: Wed Sep 12 13:24:12 CEST 2018
> r...@core2.grimstveit.no:/usr/obj/usr/src/sys/CORE2
> amd64
> 
> [...]
> [22/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc
> -O2 -pipe -march=native  -fstack-protector -fno-strict-aliasing -Wall -O2
> -pipe -march=native  -fstack-protector -fno-strict-aliasing -fPIC -MD -MT
> CMakeFiles/rsync.dir/src/scoop.c.o -MF CMakeFiles/rsync.dir/src/scoop.c.o.d
> -o CMakeFiles/rsync.dir/src/scoop.c.o   -c src/scoop.c
> [23/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc
> -O2 -pipe -march=native  -fstack-protector -fno-strict-aliasing -Wall -O2
> -pipe -march=native  -fstack-protector -fno-strict-aliasing -fPIC -MD -MT
> CMakeFiles/rsync.dir/src/version.c.o -MF
> CMakeFiles/rsync.dir/src/version.c.o.d -o
> CMakeFiles/rsync.dir/src/version.c.o   -c src/version.c
> [24/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc
> -O2 -pipe -march=native  -fstack-protector -fno-strict-aliasing -Wall -O2
> -pipe -march=native  -fstack-protector -fno-strict-aliasing -fPIC -MD -MT
> CMakeFiles/rsync.dir/src/util.c.o -MF CMakeFiles/rsync.dir/src/util.c.o.d
> -o CMakeFiles/rsync.dir/src/util.c.o   -c src/util.c
> [25/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc
> -O2 -pipe -march=native  -fstack-protector -fno-strict-aliasing -Wall -O2
> -pipe -march=native  -fstack-protector -fno-strict-aliasing -fPIC -MD -MT
> CMakeFiles/rsync.dir/src/mdfour.c.o -MF
> CMakeFiles/rsync.dir/src/mdfour.c.o.d -o
> CMakeFiles/rsync.dir/src/mdfour.c.o   -c src/mdfour.c
> [26/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc
> -O2 -pipe -march=native  -fstack-protector -fno-strict-aliasing -Wall -O2
> -pipe -march=native  -fstack-protector -fno-strict-aliasing -fPIC -MD -MT
> CMakeFiles/rsync.dir/src/trace.c.o -MF CMakeFiles/rsync.dir/src/trace.c.o.d
> -o CMakeFiles/rsync.dir/src/trace.c.o   -c src/trace.c
> [27/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc
> -O2 -pipe -march=native  -fstack-protector -fno-strict-aliasing -Wall -O2
> -pipe -march=native  -fstack-protector -fno-strict-aliasing -fPIC -MD -MT
> CMakeFiles/rsync.dir/src/tube.c.o -MF CMakeFiles/rsync.dir/src/tube.c.o.d
> -o CMakeFiles/rsync.dir/src/tube.c.o   -c src/tube.c
> [28/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc
> -O2 -pipe -march=native  -fstack-protector -fno-strict-aliasing -Wall -O2
> -pipe -march=native  -fstack-protector -fno-strict-aliasing -fPIC -MD -MT
> CMakeFiles/rsync.dir/src/whole.c.o -MF CMakeFiles/rsync.dir/src/whole.c.o.d
> -o CMakeFiles/rsync.dir/src/whole.c.o   -c src/whole.c
> [29/53] /usr/bin/cc  -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe
> -march=native  -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe
> -march=native  -fstack-protector -fno-strict-aliasing -MD -MT
> CMakeFiles/sumset_test.dir/tests/sumset_test.c.o -MF
> CMakeFiles/sumset_test.dir/tests/sumset_test.c.o.d -o
> CMakeFiles/sumset_test.dir/tests/sumset_test.c.o   -c tests/sumset_test.c
> FAILED: CMakeFiles/sumset_test.dir/tests/sumset_test.c.o
> /usr/bin/cc  -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe
> -march=native  -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe
> -march=native  -fstack-protector -fno-strict-aliasing -MD -MT
> CMakeFiles/sumset_test.dir/tests/sumset_test.c.o -MF
> CMakeFiles/sumset_test.dir/tests/sumset_test.c.o.d -o
> CMakeFiles/sumset_test.dir/tests/sumset_test.c.o   -c tests/sumset_test.c
> In file included from tests/sumset_test.c:27:
> /usr/local/include/librsync.h:430:21: error: unknown type name 'FILE'
> void rs_mdfour_file(FILE *in_file, char *result);
> ^
> /usr/local/include/librsync.h:432:23: error: unknown type name 'FILE'
> rs_result rs_sig_file(FILE *old_file, FILE *sig_file,
>   ^
> /usr/local/include/librsync.h:432:39: error: unknown type name 'FILE'
> rs_result rs_sig_file(FILE *old_file, FILE *sig_file,
>   ^
> /usr/local/include/librsync.h:437:27: error: unknown type name 'FILE'
> rs_result rs_loadsig_file(FILE *, rs_signature_t **, rs_stats_t *);
>   ^
> /usr/local/include/librsync.h:441:43: error: unknown type name 'FILE'
> rs_result rs_delta_file(rs_signature_t *, FILE *new_file, FILE *delta_file,
> rs_stats_t *);
>   ^
> /usr/local/include/librsync.h:441:59: error: unknown type name 'FILE'
> rs_result rs_delta_file(rs_signature_t *, FILE *new_file, FILE *delta_file,
> rs_stats_t *);
>   ^
> /usr/local/include/librsync.h:443:25: error: unknown type name 'FILE'
> rs_result rs_patch_file(FILE *basis_file, FILE *delta_file, FILE *new_file,
> rs_stats_t *);
> ^
> /usr/lo

Re: RUN_DEPENDS and portmaster

[Stefan Esser]

Am 18.09.18 um 14:05 schrieb Matthias Fechner:
> Dear Stefan,
> 
> Am 17.09.2018 um 14:31 schrieb Stefan Esser:
>> But the behavior of portmaster will not be changed.
>> RUN_DEPENDS are dependencies required to run a port, not dependencies
>> required to install a port.
>>
>>
>> And I do not care whether bsd.port.mk treats RUN_DEPENDS as if they
>> were INSTALL_DEPENDS (which do not exist). The fact that bsd.port.mk
>> works in that way is due to the fact, that it generally executes sub
>> processes in a depth first manner. Portmaster distinguishes build and
>> run dependencies and makes sure, that build dependencies not only exist,
>> but are updated before the ports they depend on, while bsd.port.mk will
>> use any build dependency that satisfies the range requirements (if any)
>> and does not upgrade existing but outdated (in the sense that an upgrade
>> is available) dependencies. Portmaster will then upgrade any out-dated
>> run dependencies (again if an upgrade is available, not only if it is
>> strictly required). Thus portmaster guarantees, that a port is built
>> with the latest available build tools, and that run dependency upgrades
>> see the upgraded port that requires them, in case they depend on it.
> 
> I fully understand you.
> 
> Maybe it will be a good idea to phase portmaster out as it seems to be a
> unmaintable beast?
> 
> Maybe synth can replace it for users that are not used to poudriere?

I have been using a portmaster-rewrite for many months, which is ready
for release except for some performance tuning. (The portmaster in ports
is not un-maintainable, but it's hard to modify a monolithic 4000 line
shell script that uses global variables to pass state and recursive
invocation of itself to provide local state when required.)

The performance problems are caused by bad design of the FLAVOR feature,
which ignored the requirements of tools like portmaster (I've written
about this at length when FLAVOR support had been committed).

Synth is a non-starter for me, since it is written in Ada and only
available on i386/amd64. I have plans to implement the functionality
of synth in portmaster (not really hard, since the complex parts are
the logic that deals with moved ports and conflicts, while the actual
port building is simple). Portmaster can already create packages
without installing them (unless they are BUILD_DEPENDS of some later
port, of course) and you can populate your local repository with
portmaster.

Different from poudriere or synth, portmaster adapts to the preferences
of the user (and e.g. upgrades samba48 used by some port that specifies
a dependency on samba46, if the system already has an outdated samba48
installed).

Portmaster will use what's available on a system and does allow selective
upgrades (keeping some ports at a back-level on purpose, but still upgrade
other ports that depend on them), while a poudirere/pkg based upgrade will
typically require all dependencies to exactly match what was present at
the time the package was built (in a clean environment, not resembling the
system the packages are going to be installed on).

Both, portmaster and poudriere/pkg have their use-cases, and there is only
a partial overlap. There are quite a number of portmaster users, and they
use it since their use-cases are not well covered by other tools.

The way the ports system handles installs (in that it installs RUN_DEPENDS
before the port that needs them) is an artifact of the way Makefiles
naturally work, i.e. of the tool the ports system is based on.

I do not understand why you intend on having RUN_DEPENDS cause installation
of dependencies before your port. If you need those dependencies before the
port is installed, then they are not really run dependencies, but dependencies
of your particular build process.

Portmaster has worked for far more than a decade with >20,000 ports. I do
not see that your single port that expects run dependencies to be available
before the installation has completed is reasonable cause to change the way
portmaster works with dependencies. It pre-dates the "new" ports framework
by far, and it used to be common practice, that changes respect established
practices.

BTW: Your port-install target will not be run when installing from a package
(or building a package) anyway. Portmaster will take care of providing the
required dependencies, as will pkg.

So what's the reasoning that this test in do-install is required at all?

You already specify exact versions in the RUN_DEPENDS, which are checked
by the ports framework. Portmaster will take care, that all these ports
are re-built to the latest level (hopefully satisfying the version test)
after gitlab-ce has been installed. If you use pkg, the test is performed
at install time, too.

Are there any PRs due to lack of tha

Re: RUN_DEPENDS and portmaster

[Stefan Esser]

Am 19.09.18 um 14:25 schrieb Kurt Jaeger:
> Hi!
> 
>> Why is Ada only available on i386/amd64?
> 
> Because nobody provided fixes for the build on other platforms up to now.

And given that the only use of Ada in FreeBSD ports seems to be synth,
it seems a lot easier to implement the synth functionality in some more
portable (or at least readily available) language.

There is nothing in Ada, that makes it specifically suitable for synth.
The synth code consists mostly of string processing and program invocations.
It uses Ada exception handling, but I did not spot anything that could not
easily be implemented in any other language.

In fact, due to the many invocations of external binaries, porting of
synth to a shell seems sensible. I do not consider the time-outs on all
the build phases a strict requirement, but even those could be implemented
with shell mechanisms,

The setup of the clean environment for the package builds is easy to extract
and I have considered adding that feature to portmaster, to support building
of ports that currently fail if a previous version is installed (generally
caused by include paths that prefer installed headers over those in the
sources of the new version).

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

Re: FreeBSD Port: firefox-63.0.1,1 multiple errors build

[Stefan Esser]

Am 01.11.18 um 03:38 schrieb Jonathan Chen:
> On Thu, 1 Nov 2018 at 15:35, Montgomery-Smith, Stephen
>  wrote:
> [...]
>> I only started using portupgrade recently.  I find it rather unreliable.
>>  I think the problem is that some ports need to be deleted before they
>> can be built successfully.
> 
> For reliable port builds, you need use port builders that use clean
> environments; ie poudriere or synth

True, but we used to make ports build with a previous version installed,
whenever possible. The problems are generally caused by the build process
picking up include files or libraries from LOCALBASE instead of from the
port's source directory.

I'd expect a port maintainer to check for easy fixes to such build problems.

Maybe we should add a port variable that is true if a port conflicts with
earlier versions of itself. That would indicate to port build tools like
portmaster or portupgrade that the old version should be deleted before
starting the build of the new version (and to re-install the old version
if the build of the new one fails).

E.g.:

CONFLICTS_WITH_ITSELF=  yes

I'd be willing to integrate support for such a functionality into portmaster,
if it was accepted in the ports framework.

Regards, STefan

PS: And yes, there are good reasons to keep support for tools that are
lighter-weight than poudriere and more portable than synth in the
ports system.
___
freebsd-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: Inkscape compiles but crashes on startup

[Stefan Esser]

Am 04.11.18 um 22:21 schrieb bob prohaska:
> On Sun, Nov 04, 2018 at 10:47:22AM +0100, T??l Coosemans wrote:
>> On Sat, 3 Nov 2018 22:31:34 -0700 bob prohaska  wrote:
>>> On Sat, Nov 03, 2018 at 07:18:52AM +0100, Walter Schwarzenfeld wrote:
 Wait, fix of the primal cause of it is committed right now.

 https://svnweb.freebsd.org/ports?view=revision&revision=483878
>>>
>>> Alas, no luck. Updating the ports tree and recompiling inkscape got
>>> rid of the locale error, but inkscape still crashes with an otherwise
>>> similar error stream from Gtk.
>>
>> You have to rebuild devel/glib20.
> 
> That did the trick, thank you!

If some dependent port only runs after glib20 has been recompiled,
shouldn't that be reason to bump the port revision of glib20, even
though the port didn't change in any other way?

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

Re: FreeBSD Port: firefox-63.0.1,1 multiple errors build

[Stefan Esser]

Am 01.11.18 um 17:43 schrieb Mathieu Arnold:
> On Thu, Nov 01, 2018 at 08:54:16AM +0100, Stefan Esser wrote:
>> Am 01.11.18 um 03:38 schrieb Jonathan Chen:
>>> On Thu, 1 Nov 2018 at 15:35, Montgomery-Smith, Stephen
>>>  wrote:
>>> [...]
>>>> I only started using portupgrade recently.  I find it rather unreliable.
>>>>  I think the problem is that some ports need to be deleted before they
>>>> can be built successfully.
>>>
>>> For reliable port builds, you need use port builders that use clean
>>> environments; ie poudriere or synth
>>
>> True, but we used to make ports build with a previous version installed,
>> whenever possible. The problems are generally caused by the build process
>> picking up include files or libraries from LOCALBASE instead of from the
>> port's source directory.
>>
>> I'd expect a port maintainer to check for easy fixes to such build problems.
>>
>> Maybe we should add a port variable that is true if a port conflicts with
>> earlier versions of itself. That would indicate to port build tools like
>> portmaster or portupgrade that the old version should be deleted before
>> starting the build of the new version (and to re-install the old version
>> if the build of the new one fails).
>>
>> E.g.:
>>
>> CONFLICTS_WITH_ITSELF=   yes
> 
> You can already set
> 
> CONFLICT_BUILD=   firefox-62.*

Besides overloading the CONFLICTS* variables with just another meaning,
this does not work at all.

You obviously have not tested this suggestion before posting!

The output of "make check-depends" is explicitly filtered to omit matches
that belong to the same origin as the port being built.

And BTW: Another problem with flavors: The check for same origin does also
suppress entries for conflicting packages built from that origin but with
a different flavor (even if the FLAVOR is also reflected in the package
name, e.g. by a prefix).

STefan



signature.asc
Description: OpenPGP digital signature

Re: Acme-client (Let's Encrypt)and OpenSSL

[Stefan Esser]

Am 26.11.18 um 19:58 schrieb Xavier:
> On 10/11/2018 17:27, Xavier wrote:
>> Hi,
>>
>> Following the upgrade fom 11-STABLE to 12-STABLE, I updated OpenSSL from
>> 1.0.1 to 1.1.1, since it seemd mandatory for pkg to work
>>
>> But when I check pacakages with pkg check -Bd, I've an error :
>>> acme-client is missing a required shared library: libssl.so.46
>>
>> Trying to rebuild acme-client, it insists to install libressl, which
>> obvously fails.
> 
> I fixed the problem by force upgrading acme-client using binaries (pkg
> upgrade -f acme-client)
> 
> But build problem from source is still present :
> 
> --
> [root@numenor acme-client]# grep openssl /etc/make.conf
> DEFAULT_VERSIONS+=ssl=openssl111
> 
> [root@numenor acme-client]# openssl version
> OpenSSL 1.1.1a-freebsd  20 Nov 2018
> 
> [root@numenor acme-client]# svn info
> Path: .
> Working Copy Root Path: /usr/ports
> URL: svn://svn.freebsd.org/ports/head/security/acme-client
> Relative URL: ^/head/security/acme-client
> Repository Root: svn://svn.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 485950
> Node Kind: directory
> Schedule: normal
> Last Changed Author: tobik
> Last Changed Rev: 476218
> Last Changed Date: 2018-08-02 07:33:16 +0200 (Thu, 02 Aug 2018)
> 
> [root@numenor acme-client]# make config
> ===> No options to configure
> 
> [root@numenor acme-client]# make all
> ===>  License ISCL accepted by the user
> ===>   acme-client-0.1.16_4 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by acme-client-0.1.16_4 for building
> 
> ===>  libressl-2.8.2 conflicts with installed package(s):
>   openssl111-1.1.1a
> 
>   They install files into the same place.
>   You may want to stop build with Ctrl + C.
> --

Other ports overcome this problem by using a dependency of the form
"security/libressl:stage" and then linking against the static lib in
the stage directory.

Since libressl is not installed in that case, there is no install
conflict to care about ...

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

Re: ClamAV Port Version Regression?

[Stefan Esser]

Am 11.12.18 um 18:51 schrieb Janky Jay, III:
> Hi All,
> 
>   After a portsnap to pull ${latest), I'm seeing the following:
> 
> clamav-0.101.0_2   <   needs updating (index has 0.100.2,1)
> 
>   The version that is claiming to be the latest appears to be a version
> regression. Am I wrong here? I checked the ClamAV site and it appears
> version 0.101.0 is, in fact, the latest. So, I'm wondering if there was
> possibly a revision issue that's causing this?

The ,1 at the end of the port to be installed indicates a new port epoch,
which is used to enforce an "upgrade" to a lower version number.

This is typically done if a port upgrade has been revoked due to problems
with the new version.

In this particular case the commit log says:

r487064 | antoine | 2018-12-09 18:33:26 +0100 (Sun, 09 Dec 2018) | 6 lines

Downgrade to 0.100.2
Upstream plans to release version 0.101.1 which fixes header issues in January
2019

Regards, STefan



signature.asc
Description: OpenPGP digital signature

PKGNAME of perl package

[Stefan Esser]

Just noticed that the package name of the perl ports does not match the
PKGNAME variable:

$ make -C /usr/ports/lang/perl5.26/ -V PKGNAME
perl5-5.26.3

# make package
===>  Building package for perl5.26-5.26.3

There is a mismatch of names

perl5-5.26.3 vs. perl5.26-5.26.3

and this confuses (my version of) portmaster ...

Is this by design and what use is the PKGNAME variable, if the package
is actually created under another name?

Which variable should I use to get the actual package name from the
port's Makefile?

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

Re: thunderbird build error

[Stefan Esser]

Am 16.12.18 um 17:07 schrieb John Kennedy:
> On Sun, Dec 16, 2018 at 07:54:34AM -0500, George Mitchell wrote:
>> On 12/15/18 1:10 PM, George Mitchell wrote:
>>> I recently updated my port build machine to 11.2-RELEASE.  I'm in the
>>> process of recompiling my (previously) 10.4-based ports to 11.2, and
>>> perhaps I shouldn't be trying to do this incrementally.  [...]
>>
>> Sure enough, deleting all ports and starting on a fresh ports tree
>> fixed this problem.  But I'm still unable to get the Powder Keg set
>> up on my machine (and I'm still happy with portmaster anyway).
>> -- George
> 
> I was a happy portmaster user for a really long time, but eventually I ran 
> into
> problems.  Basically, once you get enough packages built (say, X11, 
> browser-of-
> choice and trimmings) and keep it up for long enough (like through some major
> version bumps of dependent packages) you will run into an issue two packages
> that are incompatible need to be installed at the same time.  That tends to 
> get
> caught and fixed for the general case (the FreeBSD-provided package build), 
> but
> others do not (like incompatible packages that are required to build but not 
> to
> be installed).
> 
> I wish I'd gotten poudriere to work before I got synth to work because synth
> isn't as portable (say, to ARM) and I apparently like to punish myself (by not
> cross-compiling... yet).

I have (my version of) portmaster mostly working in a clean chroot jail.
It is still a pure shell script (works with the FreeBSD /bin/sh and bash),
thus portable to all architectures supported by FreeBSD (e.g. ARM).

There are a few edge cases that need further work, but my version does
already support 4 build modes:

1) direct build ("classic portmaster mode")

2) delayed installation (only BUILD_DEPENDS are immediately installed,
   all other ports are installed or upgraded from saved packages at the
   end of the portmaster run)

3) jailed build (everything is built in a chroot jail and installed after
   all builds have finished, except for pure build dependencies, which are
   only kept as packages for use in the next portmaster run)

4) repository mode (packages are saved and at the end the repository files
   are updated to allow local and remote upgrades with "pkg upgrade")

> In any case, synth/poudriere seems to be good at rebuilding anything that 
> might
> need it, ready for a quick "pkg upgrade".  Sometimes it may *seem* like a bit
> much (like gcc7 -> gcc8, or upgrading ca_root_nss), but I've been burned by
> portmaster not always catching on to some more subtle changes that would break
> things (and that even assuming that was ever aspired to by portmaster).  For
> example, look at the advice we were given for perl5.26 -> 5.28, but now for a
> bunch of packages where you don't know the dependencies because you're not a
> master of ports.  I don't feel the need to periodically delete and reinstall
> all packages just to be sure.
> 
> tl;dr:  You can't build everything with portmaster.  You should be able to 
> with
> poudriere (and if not, someone will probably be working on it to figure out 
> why
> not).

My goal is to have portmaster build everything, but with some restrictions
compared to poudriere (only for the architecture and release of the base
system) and with the option to use the direct mode for simple cases and
jailed builds (which require extra disk space for the chroot jail) in case
the builds need to be performed in a clean environment.

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

Re: thunderbird build error

[Stefan Esser]

Am 17.12.18 um 00:11 schrieb George Mitchell:
> On 12/16/18 5:24 PM, Stefan Esser wrote:
>> [...]
>> I have (my version of) portmaster mostly working in a clean chroot jail.
>> It is still a pure shell script (works with the FreeBSD /bin/sh and bash),
>> thus portable to all architectures supported by FreeBSD (e.g. ARM).
>>
>> There are a few edge cases that need further work, but my version does
>> already support 4 build modes:
>>
>> 1) direct build ("classic portmaster mode")
>>
>> 2) delayed installation (only BUILD_DEPENDS are immediately installed,
>>all other ports are installed or upgraded from saved packages at the
>>end of the portmaster run)
>>
>> 3) jailed build (everything is built in a chroot jail and installed after
>>all builds have finished, except for pure build dependencies, which are
>>only kept as packages for use in the next portmaster run)
>>
>> 4) repository mode (packages are saved and at the end the repository files
>>are updated to allow local and remote upgrades with "pkg upgrade")
>> [...]
>> My goal is to have portmaster build everything, but with some restrictions
>> compared to poudriere (only for the architecture and release of the base
>> system) and with the option to use the direct mode for simple cases and
>> jailed builds (which require extra disk space for the chroot jail) in case
>> the builds need to be performed in a clean environment.
>>
>> Regards, STefan
>> [...]
> 
> Wow!  I've been using "classic" mode and I didn't even realize the
> new modes were there.  THANK YOU for all your fine work!   -- George

Well, they are in my development version, not the one currently in
ports ...

I have worked on the portmaster rewrite since december 2017, when I
noticed that it was impossible to make the current port fully work
with flavors and complex dependency changes. It works for most simple
cases, but there have been changes (e.g. KDE4->KF5) where the current
version just can't pass the required state around (and that could not
be fixed without a lot or effort).

Anyway, I'm giving the current "beta" of the new portmaster to interested
developers, but there are still a number of details that need to be
cleaned up.

One of the nice features that are already working well is that a failed
portmaster run can be restarted with just "portmaster -R". All state and
options are read in from a restart file (but it is possible to add e.g.
an -x option to exclude some port that causes the failure from the current
run when restarting ...).

I had hoped to have finished the current version to a state that could
be released at least as portmaster-devel for interested parties to test,
a few months ago. But I have continued adding features (for example to
build the ports in a chroot jail), and I'm alternating between adding
features and cleaning and speeding-up the code ...

I'd really hope to commit that version as an alternative to the current
portmaster port within the next weeks (but I'm not sure that I'll have
much time to work on it over the holidays ...).

Thanks to all that have supported my work by testing draft versions and
who have given very valuable feedback!

Best regards, STefan



signature.asc
Description: OpenPGP digital signature

Re: Django versions

[Stefan Esser]

Am 07.03.19 um 09:02 schrieb Matthew Seaman:
> On 07/03/2019 07:22, Antoine Brodin wrote:
>> Please don't use the django metaport,  this port should be removed and
>> people should stop using hacks.
>> Someone needs to integrate a USE_PYTHON=django in python.mk
> 
> Let me look at that.  I never did like leaving D12592 so unresolved.
> 
> Although it would be good to have a more general solution to
> multiple-flavourization.

If anything in that direction is discussed, then please include
me in the thread (since I do read the list, but I'm not able to
follow it closely, currently).

I had asked about multi-flavour support nearly one-and-a-half year
ago and I was told that lack of support for more than one flavour
was by design and considered to be the correct concept.

There are quite a number of other weaknesses in the way flavours
are currently implemented (and it cost me a lot of effort to work
around them, when I took over maintainer-ship of portmaster to make
it support flavours).

I had given up trying top get this fixed, but it may be the right
time (given some experience with flavoured ports) to reconsider
some of the design and implementation choices made ...

Regards, STefan



signature.asc
Description: OpenPGP digital signature

Re: Can't compile www/node on rpi2

[Stefan Esser]

Am 27.03.19 um 02:46 schrieb bob prohaska:
>> All the
>>> port-management tools in ports-mgmt assume this, and build
>>> port-dependancies as required. When building ports, it is always best
>>> to use one of the build-tools (ie: poudriere, synth , portmaster)
>>> instead of by hand.
>>
> I've played a little with portmaster, and it seemed more prone to stopping
> unintentionally than a simple "make -DBATCH" in the port directory. IIRC,
> it always stopped on stale but installed dependencies. Perhaps I'm doing
> somthing dumb, but I couldn't figure out what it was. Could it merely be
> the fact that I'm using a Raspberry Pi 2 or 3?

Could you provide me with traces of portmaster runs for cases where it did
not upgrade stale dependencies?

The dependency resolution and build strategy of portmaster scans all ports
for potential upgrades and ought to upgrade dependencies first, even if
the currently installed versions satisfy version requirements stated in a
dependency.

Portmaster should only stop if a dependency cannot be upgraded (and it does
this even if an older version is installed that might be sufficient for the
build attempted) or if it detects conflicts that cannot be resolved without
user intervention.

There have been a number of problems in the ports collection recently, which
lead to problems for port management tools other than poudriere. E.g. due to
the removal of FLAVORS from ports that could be built with either qt4 or qt5,
which was not accompanied by entries in MOVED that provide a hint about the
prior category/port@qt5 now just being category/port again ...

I'd like to get such cases detected and correctly dealt with in portmaster,
but each additional special case will slow down general processing due to
tests that take time but fail in 99,99% of cases. And they consume my time
due to the need to develop and test work-arounds for such cases ...

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

Re: category for VPN softwares?

[Stefan Esser]

Am 02.04.19 um 07:42 schrieb Koichiro Iwao:
> On Tue, Apr 02, 2019 at 06:41:51AM +0200, Kurt Jaeger wrote:
>> Create a real category vpn and move everything to it ?
> 
> Sounds better! Gentoo has net-vpn category. Just FYI, Gentoo also have
> net-dialup category. PPP/PPPoE/L2TP softwares are put under net-dialup
> but I feel that classification is too fine. At least creating vpn or
> net-vpn souds good.

How about a new "real" category vpn and preserving the current categories
of the ports as their additional categories (assuming that they are in net
vs. security for a reason).
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: python

[Stefan Esser]

Am 11.04.19 um 00:03 schrieb ajtiM via freebsd-ports:
> Hi!
> 
> With portmaster I try to update todays ports and python default is
> version 3.7 which is okay for me but not for hplip:
>  ===>>> All >>
> hplip-3.17.11_3 (5/43)
> 
> ===>>> Returning to dependency check for print/hplip
> ===>>> Dependency check complete for print/hplip
> 
> ===>>> All >> hplip-3.17.11_3 (5/43)
> 
> ===>  hplip-3.17.11_4 FLAVOR is defined (to py27) while this port does
> not have FLAVORS..
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/print/hplip

This is a bad effect caused by the removal of FLAVORs from an
installed port.

Since the previous revision of this port required a flavor, it
will be updated with that same flavor passed as a parameter to
the build process. The build could just ignore the irrelevant
flavor, but that is not what the ports system does ...

In this particular case the removal of QT4 is the cause. The
port used to support flavors "qt4" and "qt5" and to fix this
issue for portmaster, entries in MOVED should exist that make
upgrades use print/hplip without flavor, whether the qt4 or
qt5 version was installed.

I plan to add code to portmaster to verify that a FLAVOR that
is to be used for a port still applies, before starting to
build it.

But it is not obvious to me what to do for all of the cases
that exist:

1) FLAVORS removed from the port -> build without flavors

2) Specific FLAVOR removed from the port -> build with default
   flavor (?)

Anyway, for the time being you'll have to deinstall the port
(use "pkg delete -f hplip" to prevent recursive deletion of
dependent ports) and then re-install it with portmaster (which
will build it without flavor, then.

Another possibility is to remove the "flavor" annotation
registered for this port in the PKGDB, then portmaster will
upgrade the port without providing a FLAVOR to the build ...

I'll see that I fix this problem in portmaster, but it will take
some time ...

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

Re: python

[Stefan Esser]

Please excuse the top-post - I have only one sentence to
add:

I have tried to reproduce the issue with print/hplip by
installing a QT4 flavored version from before the port
update, and updating that port the new the non-flavor
version with portmaster, which worked without issue - so
I'm not able to test any fix to portmaster, currently ...

Regards, STefan

Am 11.04.19 um 09:29 schrieb Stefan Esser:
> Am 11.04.19 um 00:03 schrieb ajtiM via freebsd-ports:
>> Hi!
>>
>> With portmaster I try to update todays ports and python default is
>> version 3.7 which is okay for me but not for hplip:
>>  ===>>> All >>
>> hplip-3.17.11_3 (5/43)
>>
>> ===>>> Returning to dependency check for print/hplip
>> ===>>> Dependency check complete for print/hplip
>>
>> ===>>> All >> hplip-3.17.11_3 (5/43)
>>
>> ===>  hplip-3.17.11_4 FLAVOR is defined (to py27) while this port does
>> not have FLAVORS..
>> *** Error code 1
>>
>> Stop.
>> make: stopped in /usr/ports/print/hplip
> 
> This is a bad effect caused by the removal of FLAVORs from an
> installed port.
> 
> Since the previous revision of this port required a flavor, it
> will be updated with that same flavor passed as a parameter to
> the build process. The build could just ignore the irrelevant
> flavor, but that is not what the ports system does ...
> 
> In this particular case the removal of QT4 is the cause. The
> port used to support flavors "qt4" and "qt5" and to fix this
> issue for portmaster, entries in MOVED should exist that make
> upgrades use print/hplip without flavor, whether the qt4 or
> qt5 version was installed.
> 
> I plan to add code to portmaster to verify that a FLAVOR that
> is to be used for a port still applies, before starting to
> build it.
> 
> But it is not obvious to me what to do for all of the cases
> that exist:
> 
> 1) FLAVORS removed from the port -> build without flavors
> 
> 2) Specific FLAVOR removed from the port -> build with default
>flavor (?)
> 
> Anyway, for the time being you'll have to deinstall the port
> (use "pkg delete -f hplip" to prevent recursive deletion of
> dependent ports) and then re-install it with portmaster (which
> will build it without flavor, then.
> 
> Another possibility is to remove the "flavor" annotation
> registered for this port in the PKGDB, then portmaster will
> upgrade the port without providing a FLAVOR to the build ...
> 
> I'll see that I fix this problem in portmaster, but it will take
> some time ...
> 
> Regards, STefan
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Request to change ruby default version to 2.5

[Stefan Esser]

Am 20.04.19 um 11:05 schrieb Matthias Fechner:
> Am 20.04.2019 um 06:59 schrieb Walter Schwarzenfeld:
>> After this change:
>>
>> |portmaster -R -r ruby-2.5|
>>
>> |
>> ===>>> Port directory: /usr/ports/databases/ruby-bdb
>>
>>     ===>>> This port is marked BROKEN
>>     ===>>> does not build with Ruby 2.5
>>
>>
>>     ===>>> If you are sure you can build it, remove the
>>        BROKEN line in the Makefile and try again. 
> 
> you have here several possibilities:
> 
> - keep on ruby 2.4 till portmaster is fixed, see UPDATING

What is there to fix in portmaster?

Portmaster uses the BROKEN= in the Makefile to detect ports
that will not build and warns about this situation before
trying to start the actual build ...

If there is a request to upgrade dependent ports (with -r)
then portmaster will perform checks that are possible before
starting the builds.

Without this check, the build will fail later-on, possibly
after replacing a number of ports with ones build for the
new ruby version. (Which may or may not cause problems, this
cannot be mechanically checked by portmaster.)

You can exclude ports from being rebuild with portmaster by
using "-x ruby-bdb" (for this particular case). But this may
lead to inconsistencies (will keep the version for ruby-2.4
installed, which will lead to run-time errors).

> - write a bug report upstream for ruby-bdb to get it fixed for ruby 2.5

Yes, that is the only sensible approach (IMHO), if you are
not able to fix the ruby-bdb port yourself to work with the
new ruby version.

> - fix portmaster by yourself

What do you suggest to change in portmaster?

> - use a more recent package builder like poudriere

How does this help, if a port requires ruby-bdb and that is not
yet available for the ruby version used to by the other ports?

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

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

[Stefan Esser]

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

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

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

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

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

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

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

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

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

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

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

Re: Massive PORTS_REVISION bump after making gcc-9.1 default

[Stefan Esser]

Am 28.07.19 um 01:26 schrieb Kevin Oberman:
> Today I was hit with 226 ports needing update. With one exception, all were
> the result of the bump or the default gcc version to 9.1. The problem is
> that 9.1 was not installed first, so over 43 of these ports were rebuilt
> with the exact same compiler it was built with before the rebuild, eating
> up 2:45 of time on my build system. I'm sure if was less for many as my
> build system is over 8 years old. It was non-trivial in any case.

Which port management tool did you use to rebuild the updated ports?

I just checked what portmaster does, and it appears to build gcc-9.1
before starting to update ports that depend on it.

It was the 78th port out of 653 out-dated ports (most of them due to
a bumped port revision because of the gcc update), and I checked with
"make all-depends-list" that none of the first 77 ports depended on
gcc ...

> Should an install of gcc9 preceded all updates? Perhaps a note in UPDATING?
> I certainly looked there before I started when I saw 226 ports in the list.

Updating required build tools before ports that require them should
be automatic, if a tool like portmaster, portupgrade or poudriere is
used.

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

Need help: nearly complete port of GitHub CLI

[Stefan Esser]

I have tried to create a port for the recently announced GitHub CLI 1.0.

What I got so far can be downloaded from:

https://people.freebsd.org/~se/ports/github-cli-port.tar.bz2


The GH_TUPLE list of the dependencies was the part that caused most
effort, but it should be correct and complete, AFAICT.

The port is nearly ready, but there is a compilation error which
appears to be caused by a missing architecture dependent definition:

# github.com/muesli/termenv
vendor/github.com/muesli/termenv/termenv_unix.go:76:9: readfds.Bits 
undefined (type syscall.FdSet has no field or method Bits)
vendor/github.com/muesli/termenv/termenv_unix.go:87:12: readfds.Bits 
undefined (type syscall.FdSet has no field or method Bits)

*** Error code 2

Another missing function could be fixed by copying over the Linux
specific definition, but I assume it should apply to FreeBSD, too
(see the post-extract target in the Makefile).


Since I do not know much about Go, I'm stuck, but think it should
be very easy to get the missing definition fixed for somebody with
some knowledge of Go and its build infrastructure.

More issues may exist, but since I'm stuck with the compiler error
that prevents building of the binary, I can't tell ...

Any help is highly appreciated ...

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: Need help: nearly complete port of GitHub CLI

[Stefan Esser]

Am 19.09.20 um 12:49 schrieb Christoph Moench-Tegeder:

## Stefan Esser (s...@freebsd.org):


I have tried to create a port for the recently announced GitHub CLI 1.0.


Without having actually looked at your work - we do already have
devel/gh - "GitHub's official command line tool", which seems to
be the beta version of what you're porting. And it has what seems
to be a patch for your specific problem.


Thank you, I had not been aware of a port for the beta version.

I have updated the port to use the new dependency versions that I had
worked out for my port attempt and could build version 1.0.0 that way.

There is a non-committer registered as maintainer of the port, and I
have sent him the diff for review and plan to commit the update (as
is or with the changes he might request).

Best regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Port uploaded for review (was: Re: Availability of samba 4.12.x)

[Stefan Esser]

I have derived a port for Samba-4.12.7 from net/sambar411 and have made 
it available for testing on Phabrcator:


https://reviews.freebsd.org/D26491

The CONFLICTS line is commented out to allow compilation if an older
version of this port is already installed and the CONFLICTS lines of
the other versions have to be adjusted to include this new port.

It builds and works for me on amd64/CURRENT, but I have not been able
to test it on other releases or architectures.

Since there is a maintainer, I'm not going to commit this version,
unless approved by him (timur) - but I do of course leave it to the
maintainer to make further changes or adjustments to this port ...

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: What are the benefits of NO_ARCH?

[Stefan Esser]

Am 02.11.20 um 15:33 schrieb Mateusz Piotrowski:

Hi ports@,

I wonder if setting NO_ARCH=yes brings any significant benefits to how 
our ports collection works. I'd be grateful if you could shed some light 
on the importance of setting NO_ARCH whenever possible.


NO_ARCH means that there is no need to build packages for each of the
supported architectures, e.g. for pure interpreted scripts or data files
that do not depend on byte-order and word-size (e.g. many font file
formats).

The result is reduced resources spent on building the packages, network
traffic, disk space on mirrors and on distribution media.

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: security/openvpn-auth-ldap-2.0.4 not compatible with security/openvpn-2.5.0

[Stefan Esser]

Am 06.11.20 um 07:10 schrieb xtouqh--- via freebsd-ports:

Nikita Druba wrote:

Hello!

After updating security/openvpn to last(2.5.0) version, it's not start 
anymore, because:


Updating how?

"2020-11-06 02:37:05 PLUGIN_INIT: could not load plugin shared object 
/usr/local/lib/openvpn-auth-ldap.so: /usr/local/lib/libobjc.so.4.6: 
Undefined symbol "ceilf"


This suggests you need to update/rebuild lang/libobjc2 dependency as well.


Does that mean that the PORTREVISION of lang/libobjc2 has
to be bumped?

Seems this is a port maintained by ports@ and nobody feels
responsible?


OpenPGP_signature
Description: OpenPGP digital signature

Re: Donation to Foundation for Poudriere /opt builds! (Bounty?)

[Stefan Esser]

Am 09.11.20 um 00:40 schrieb Tatsuki Makino:

I think you need to rewrite all the files under /etc that have
/usr/local in them.
For example, ldconfig_paths in /etc/rc.conf.


I have committed that change a few days ago, and it was heavily
disputed by those who think that there never should be a path
other than /usr/local used for LOCALBASE.


Perhaps we need to apply it to both host and jail.


It is in -CURRENT and I could MFC to -STABLE, but it will take
some time to arrive in a release (with 12.2 just finished).


If the shell of the user root of a jail is csh, the PATH of /root/.cshrc
in jail may also be relevant.


There are a number of files that need to be adjusted if LOCALBASE
is not /usr/local, and I'm willing to put proposed patches up for
review and commit them if accepted.


In addition, /root/.profile is another file that defines the PATH.


Yes, and there are many more.

I have added _PATH_LOCALBASE to /usr/include/paths.h in -CURRENT
to be picked up by binaries.

There already is ${LOCALBASE} in the Makefile in /usr/src and it
is used in some isolated parts of the tree to support a LOCALBASE
other than /usr/local.

But /usr/local has been hard-coded in FreeBSD for decades (not in
many files and binaries, but in some critical ones) and it takes
effort to make this a parameter that can be easily adjusted.

But there are down-sides: Making this parameter variable can lead
to security issues, since an attacker might be able to circumvent
policy restrictions and authorization checks.

I'm all for making it easy to build a system for another value of
LOCALBASE, but I'm not convinced that being able to choose another
value at run-time is worth the vulnerabilities this may create.


However, when you do all that, it's already a different OS distribution
than FreeBSD, isn't it :) ?


No, I don't think so. It is still FreeBSD, but you have to understand
that it is FreeBSD without pre-built packages, since most of them can
be built for a different LOCALBASE (but not all!) but the official
packages won't run (need a re-compile).

This may change if packages start to use the proposed getlocalbase()
function to construct paths at run-time. Other files provided by a
port need to be patched at install time (may apply to configuration
files rc scripts, ...)

Making FreeBSD friendly to environments that have a need for another
LOCALBASE than /usr/local will take a lot of effort and contributions
are welcome, as long as they do not cause issues for the large majority
that will continue to use the default of /usr/local.

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Port build failure in stage-qa

[Stefan Esser]

Building virtualbox-ose-kmod failed for me today (for the first time)
due to REINPLACE_CMD not changing some files. This breaks my kernel
build that include the kernel modules:

> Compressing man pages (compress-man)
===> Staging rc.d startup script(s)
> Running Q/A tests (stage-qa)
Warning: Possible REINPLACE_CMD issues:
- - REINPLACE_CMD ran, but did not modify file contents: Config.kmk
- - REINPLACE_CMD ran, but did not modify file contents: configure
*** Error code 1

Stop.
make[1]: stopped in /usr/svn/ports/head/emulators/virtualbox-ose-kmod
*** Error code 1

Stop.
make: stopped in /usr/svn/ports/head/emulators/virtualbox-ose-kmod



This appears to be due to the following commit that affected qa.sh:

r554893 | mat | 2020-11-11 14:29:52 +0100 (Wed, 11 Nov 2020) | 13 lines

Add set pipefail in most framework scripts.

set pipefail changes the pipeline return status from being the return
status of the last command to the last non 0 exit status of any command
in the pipeline.  This is needed to make sure all the commands in a
pipeline did actually return a non 0 status and not only the last one.

PR: 250723
Exp-run by: antoine
Reviewed by:bapt
Approved by:bapt
Differential Revision:  https://reviews.freebsd.org/D27007


Since DEVELOPER=yes cannot be overridden on the command line, I'll
have to remove it from make.conf to get a kernel with matching
modules installed.

Is this an expected outcome of the change?

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: Port build failure in stage-qa,Port build failure in stage-qa

[Stefan Esser]

Am 11.11.20 um 23:48 schrieb Yasuhiro KIMURA:

From: Stefan Esser 
Subject: Port build failure in stage-qa,Port build failure in stage-qa
Date: Wed, 11 Nov 2020 21:56:49 +0100


Since DEVELOPER=yes cannot be overridden on the command line, I'll
have to remove it from make.conf to get a kernel with matching
modules installed.


I add following lines in make.conf.

--
.ifndef NO_DEVELOPER
DEVELOPER=yes
.endif
--

And developer mode can be disabled from command line with

% make NO_DEVELOPER=yes

Just FYI.


Thank you! I should have got to this solution myself ;-)

Such an override should probably exist in the port system's
Makefiles, but your work-around resolves the issue I had.

Best regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: portsnap

[Stefan Esser]

Am 26.12.20 um 18:41 schrieb LuMiWa via freebsd-ports:

Hi!

Today I red again an email:

Subject:[HEADS UP] Planned deprecation of portsnap
From:   Steve Wills 
Date:   2020-08-04 18:43:20

And as portsnap user I have a question: Do they planning deprecation of
portmaster too?


No, I'm actively working on portmaster and have rewritten it from
scratch for better performance (and additional features, e.g. building
in a clean chroot jail, similar to synth or poudriere).

I have been using that version for more than one year, but the
functionality is not complete, yet.

On a test system with > 2200 installed ports it takes less than 10
seconds to identify the ~600 out-of-date ports (that I keep in this
state for testing of the upgrade strategy function), which is more
than 30 times faster than the same operation with the "official"
portmaster.

Until completion of that version, I'll continue to maintain and
update the current portmaster port ...

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: portmaster new development

[Stefan Esser]

Am 27.12.20 um 06:04 schrieb Thomas Mueller:

And as portsnap user I have a question: Do they planning deprecation of



portmaster too?



No, I'm actively working on portmaster and have rewritten it from
scratch for better performance (and additional features, e.g. building
in a clean chroot jail, similar to synth or poudriere).



I have been using that version for more than one year, but the
functionality is not complete, yet.



On a test system with > 2200 installed ports it takes less than 10
seconds to identify the ~600 out-of-date ports (that I keep in this
state for testing of the upgrade strategy function), which is more
than 30 times faster than the same operation with the "official"
portmaster.



Until completion of that version, I'll continue to maintain and
update the current portmaster port ...



Regards, STefan


Question about the relation of portsnap and portmaster reminds me of Java and 
Javascript, or potato and sweet potato (not closely related).


Yes, portsnap and portmaster do not share anything beyond the first 4 
letters of their names ...



Since my question is about a new portmaster, I rename the subject to "portmaster" or 
"portmaster new development", rather than hijack the "portsnap" thread.

Which portmaster do I get if I build and install what is currently in the ports 
tree?


This is a version that I became maintainer of when it lacked flavor 
support and the original developer (Doug Barton) had left the project.



amelia2# ls -l ports-mgmt/portmaster
total 16
-rw-r--r--  1 root  wheel  1479 Dec 27 02:01 Makefile
-rw-r--r--  1 root  wheel   184 Feb 28  2018 distinfo
drwxr-xr-x  2 root  wheel   512 Dec 27 02:01 files
-rw-r--r--  1 root  wheel  1189 May  6  2019 pkg-descr

from a fresh svn up of the ports tree.


Yes, I added a feature requested by Kevin Obermann, yesterday, who
had noticed that a locked port could be built but not installed, if
the user answers "yes" to the question whether the lock should be
ignored.


An improved portmaster arouses my interest.  Maybe modify the name so it can be added to 
the ports tree and coexist with the "official" portmaster.


After taking over the current portmaster I noticed that it is ancient
in its structure. It used global variables throughout and forked a lot
if sub-processes to allow for local state.

Since it is extremely cumbersom to work on a linear 4000 line shell
script, I re-wrote it from scratch using bash associative arrays and
used that version since the summer of 2019. That version did already
support clean builds in a chroot jail as an option.

But I noticed that better data structures would allow to substantially
speed-up the scanning phase and decided to port that bash based version
to LUA. It can be found in my GH repo, but I'm currently reworking the
planning phase to allow for multiple pre-decessors of a port (e.g. if
A-v1 is integrated into B-v2 and B-v1 is already installed).

My current (not pushed) development version locks up due to such a case
(deskutils/kdepim-apps-libs has been merged into net/akonadi-contacts
and akonadi-contacts is downlevel, leading two an attempt to get an
exclusive lock on the target package name twice, since the two update
tasks are not currently merged into one).

But other than that it has been usable for simple updates for a long
time already.


Desired features/options would be to keep going rather than stop when one port 
fails to build, and the ability to install build dependencies, which may be 
useful for building other software.


Yes, I mark failed updates as such and cancel planned updates of
dependencies, but unrelated updates go on.


With synth, I had a difficult time getting everything that was built to 
install, some packages like bison are needed in building other software.


The bash version supported 4 modes: traditional portmaster, delayed
installation of packages not depended on in the update run, jailed
builds with installation of packages after completion of all builds
and repository mode to just create packages in a jail.

I ran into issues when I tried to optimize the disk space used for
the jail by de-installing no longer required build dependencies
from the jail as soon as possible. I needed better data structures
than offered by bash to efficiently express these dependencies.

That was the point where I decided to migrate the code to LUA.


How is poudriere in that regard?  I never used poudriere, have been intimidated 
by not wanting to use zfs or dialog4ports, or such an elaborate setup just to 
update one or a few ports.


I have to use poudriere to test ports before commit, but I do not
like it. The build jails are quickly becoming stale and have to be
rebuilt (causing all previously built packages to be compiled again)
and I often run into issues where a build dependency fails for reasons
that ar enot obvious (e.g. gmake) and I have found that the easiest
method of recovery is to throw away the whole poudriere jail and to
start over with a 

Re: portmaster new development

[Stefan Esser]

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


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

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

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

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: portmaster new development

[Stefan Esser]

Am 28.12.20 um 15:04 schrieb abi via freebsd-ports:

On 28.12.2020 16:16, Stefan Esser wrote:
Am 28.12.20 um 11:11 schrieb abi via freebsd-ports:> I build my ports 
in poudriere in VM without zfs or ssd on pre-Sandy
Bridge CPU. I don't have enough memory or disk space, so I don't use 
tmpfs or ccache either. I migrated from portmaster when it was 
abandoned several years ago and don't think I'll come back, 
especially if new portmaster will be written on bash. The idea behind 
portmaster was zero dependencies, so it doesn't brake after major 
upgrades.


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

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

I remember portmaster marked as deprecated in 2016. I've switched to 
poudriere because of that. So, it _was_ abandoned when I migrated. It is 
good that it is not, the more options - the better. But some people here 
telling that poudriere requires ZFS and powerful dedicated hardware, I 
just pointed that they are wrong.


The portmaster port had been marked deprecated by the author of synth
and this commit has been reverted by him on request of portmgr on the
next day.

The portmaster port has never been abandoned - it does not suffice that
some unrelated committer considers his port management tool superior
and decides to deprecate a "competing" one.

Poudriere works best on sufficiently powerful build servers and it
often requires rebuilding dependencies over hours when I just want to
test a new port before committing it.

My goal is to have portmaster build ports in a clean jail as synth
does (restricted to i386 and amd64 due to the dependency on Ada) and
poudriere do, but without giving up the ease of use of portmaster for
other use cases.

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: portmaster new development

[Stefan Esser]

Am 28.12.20 um 22:07 schrieb Michael Grimm:>> On 28. Dec 2020, at 21:41, 
Stefan Esser  wrote:


Poudriere works best on sufficiently powerful build servers and it
often requires rebuilding dependencies over hours when I just want to
test a new port before committing it.


Excuse me, but that is not true in this generality. I do run poudriere on ZFS 
in a cloud instance with 7G of memory and a CPU of 2.1 MHz. Never had to wait 
for more then one hour for recompiling *all* of my 240+ ports for STABLE-12. 
YMMV, yes, but stating that in that totality is nonsense, at least IMHO.


My build host is much bigger and I often have to build
dependencies over night before I can test-build a new
port with poudriere.

Maybe your ports do not have as many big dependencies,
but building LLVM and GCC as a dependency for 3 release
versions takes its time and whenever these ports have
been updated I cannot run "poudriere test" for my new
port before the compilers are updated.

If there are no complex dependencies, you are right,
but MESA, KDE (or even Qt5) and all ports that need
a specific compiler version that is receiving updates
cause excessive delays before a port can be test built
with poudriere.

So yes, YMMV, but it depends on the complexity of the
dependencies. And I test with different options in
the different jails (e.g. with/without DOCS, one with
non-standard PREFIX, etc.) for a better test coverage.
Therefore I cannot fetch pre-compiled compilers and
other dependencies to speed up my port tests.

And this might be typical for poudriere users. If you
do not want to build with non-default options you are
better served by using pre-compiled packages.

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: Creating port from pre-built package

[Stefan Esser]

Am 11.02.21 um 18:12 schrieb Shawn Webb:

On Thu, Feb 11, 2021 at 06:09:52PM +0100, Patrick M. Hausen wrote:

Hi all,


Am 11.02.2021 um 18:03 schrieb Chris :

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

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

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

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


The binary package is provided by the software manufacturer without
source code.

Still one might want to have a port available so one can put the port
in poudriere and have it available in one's own package repo.



Right, I'm not aiming to recompile the software. I'm looking to simply
create a new package.txz with the pre-built artifacts included.


I shouldn't be too hard to create a port, just be careful to consider
the architecture dependency of the binary package you are using.

If multiple architectures and OS releases are supported, then you'll
have to create the package name from those parameters and provide
distinfo data for all supported combinations of architecture and
OS release. You can override the name of the DISTINFO_FILE in the
port's Makefile to have separate distinfo files per arch/version.

In the port's Makefile extract the contents of the correct package
into the stage directory, have dummy targets for phases that are not
reuquired (e.g. an empty do-stage to have the stage done marker set
in the ${WRKSRC} directory) and provide a pkg-plist (possibly multiple
variants selected by the PLIST variable, if there are arch/version
specific differences).

Use ONLY_FOR_ARCH and IGNORE to limit the package building to those
architectures and releases that are supported, to prevent package
fall-out messages and to give ports users a reasonable error message
when trying to build the port on an unsupported system.

The generated package will have the meta-data from your port. If
you want to preserve some meta-date from the pre-built package, then
extract it from the extracted distfile, e.g. in the build phase.
Else use NO_BUILD to suppress this and possibly other phases that
are not required (empty dummy targets will do as well).

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: Creating port from pre-built package

[Stefan Esser]

Am 11.02.21 um 18:12 schrieb Shawn Webb:

On Thu, Feb 11, 2021 at 06:09:52PM +0100, Patrick M. Hausen wrote:

Hi all,


Am 11.02.2021 um 18:03 schrieb Chris :

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

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

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

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


The binary package is provided by the software manufacturer without
source code.

Still one might want to have a port available so one can put the port
in poudriere and have it available in one's own package repo.



Right, I'm not aiming to recompile the software. I'm looking to simply
create a new package.txz with the pre-built artifacts included.


Adding to the previous mail on how a FreeBSD port might be used to
install this binary package:

Be sure to be allowed to re-package the binary distribution that
you want to use in this port. The license may explicitly forbid the
distribution of derived works of any kind.

Do also set the LICENSE and specifically the LICENSE_PERMS variable
in the port's Makefile to indicate whether the FreeBSD package that
will be built from this port may be created, distributed, possibly
also sold.

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: On 14-CURRENT: no ports options anymore?

[Stefan Esser]

Am 13.03.21 um 20:17 schrieb Hartmann, O.:

Since I moved on to 14-CURRENT, I face a very strange behaviour when trying to 
set
options via "make config" or via poudriere accordingly. I always get "===> 
Options
unchanged" (when options has been already set and I'd expect a dialog menu).
This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is at FreeBSD
14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 amd64).

I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG.

How to fix this? What happened?


Hi Oliver,

please check your TERM setting and test with a trivial setting
if it is not one of xterm, vt100 or vt320 (for example).

I had this problem when my TERM variable was xterm-color, which
used to be supported but apparently no longer is.

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: FreeBSD Port: owncloud-php80-10.6.0

[Stefan Esser]

Am 19.03.21 um 10:23 schrieb Erik Neubauer via freebsd-ports:

Hi,

Thanks for maintaining an ownCloud package!

I noticed that you are using PHP 8.0. However ownCloud doesn't support 
that version of PHP.


Unfortunately I don't have any experience with BSDs, but perhaps I can 
help you create a package based on PHP 7.4?


Hi Sunpoet,

the following patch prevents use of PHP-8.0 and the creation of
a package for that PHP version:

Index: www/owncloud/Makefile
===
--- www/owncloud/Makefile   (revision 568788)
+++ www/owncloud/Makefile   (working copy)
@@ -18,6 +18,7 @@
 USE_PHP=   bz2 ctype curl dom fileinfo filter gd hash iconv intl json \
mbstring pdo posix session simplexml xml xmlreader xmlwriter \
xsl zip zlib
+IGNORE_WITH_PHP=   80

 NO_ARCH=   yes
 NO_BUILD=  yes

In order to get the current owncloud-php80 package removed from the
package mirrors, a PORT_REVISION bump will be required.

Let me know if I should go ahead and commit that change ...

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: Deprecation of portsnap

[Stefan Esser]

Am 14.04.21 um 02:43 schrieb Chris:

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

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

Except that git will arbitrarily and randomly decide that it needs to 
run 
"gc" - which is similarly extravagant in memory usage.  Last time I 
found 

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


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

contains strong language...

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


If you disagree regarding the appropriateness of the language,
there is:

https://dangitgit.com/

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

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

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: Ports INDEX

[Stefan Esser]

Am 14.04.21 um 21:33 schrieb Carmel:

I just switched from using 'portsnap' to 'git'. I removed everything in
the directory, then used 'git' to build it. That worked fine. I had to
manually recreate the 'distfiles' directory, but I expected to have to
do that.

Now, if I run a 'make search' in the directory, I receive an error
message that it needs the INDEX file. I ran "make index" and that
seems to work alright. My question is, is that the best way to handle
this? Couldn't 'git' download the INDEX file, too. I assume that
'portsnap' was doing something like that.


You do not want to bloat the ports repository with the INDEX file.

It does not contain any useful "historical" information, only the
current version is ever relevant.

A mechanism that applies the relatively small deltas to the INDEX
file instead of having to download the compressed file with "make
fetchindex" could reduce the amount of data to transfer, though.

A mechanism like CTM could provide that. Else "make fetchindex" is
the fastest way to get the index, but only "make index" does also
reflect dependencies affected by locally set non-default port options.



OpenPGP_signature
Description: OpenPGP digital signature

SVNWEB not updated for ports

[Stefan Esser]

After the switch to GIT, the ports SVN repository is in a frozen state.

This causes accesses to https://svnweb.freebsd.org/ports/head/ to return
stale information.

But the real issue IMHO is that the "FreeBSD Ports Search" page on the
web server does return 404 errors for ports that have been created in
GIT and did not exist in SVN.

I have created a review for the suggested fix:

https://reviews.freebsd.org/D29829




OpenPGP_signature
Description: OpenPGP digital signature

Re: SVNWEB not updated for ports

[Stefan Esser]

Am 19.04.21 um 14:42 schrieb Helge Oldach:
> Stefan Esser wrote on Mon, 19 Apr 2021 12:11:40 +0200 (CEST):
>> After the switch to GIT, the ports SVN repository is in a frozen state.
>>
>> This causes accesses to https://svnweb.freebsd.org/ports/head/ to return
>> stale information.
> 
> I guess it might be more appropriate to encourage 
> https://cgit.freebsd.org/ports/?h=main instead...

No, I'm talking about the path to the actual files and have created
a review:

https://reviews.freebsd.org/D29829

The fix is trivial and a functionally equivalent replacement of the
SVNWEB link (I just noticed that I had suggested a path that lead to
a different representation of the content and have updated the patch
that is attached to this review).

I'd suggest to test the suggested path of cgit.freebsd.org/ports/plain
by directly patching the file on the web-server just for the purpose of
verification of accesses still working, then to commit it to the doc
repository.

I cannot locally test the change, but if it has bad side-effects, it
can easily be reverted.

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

[SOLVED?] Recovery of deleted ports fails due to pre-commit checks

[Stefan Esser]

The recovery of deleted ports in their previous form is rejected
by the pre-commit checks on the repository server:

remote:
remote: 
remote: Do not commit ports without TIMESTAMP in their distinfo files.
remote: Rerun make makesum to add it.
remote: 
remote:

I have tried to revert the deletion with unchanged files and then
updated the ports' Makefiles and distinfo files in a later commit.

Pushing those commits all together fails with the message above,
and in order to not confuse GIT, deleted files should be committed
first, before applying any changes.

Apparently this is not possible, and I cannot re-order the commits
in such a way, that the distinfo change is merged in to the initial
commit.

I'm now going to try with 10 commits squashed into 1, to make the
distinfo update appear to be part of the initial commit. This will
make it much harder to distinguish the reversal of the deletion
from later changes, though.


The squashed commit has worked - the multimedia/transcode port and
dependent ports that had been deleted should be restored and fixed.

It is thus possible to commit a reverted port, but I had rather kept
the commit log entries separate and more comprehensible.

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: [SOLVED?] Recovery of deleted ports fails due to pre-commit checks

[Stefan Esser]

Am 03.05.21 um 09:01 schrieb Mathieu Arnold:
> On Sat, May 01, 2021 at 09:01:02PM +0200, Stefan Esser wrote:
>> The recovery of deleted ports in their previous form is rejected
>> by the pre-commit checks on the repository server:
>>
>> remote:
>> remote: 
>> remote: Do not commit ports without TIMESTAMP in their distinfo files.
>> remote: Rerun make makesum to add it.
>> remote: 
>> remote:
>>
>> I have tried to revert the deletion with unchanged files and then
>> updated the ports' Makefiles and distinfo files in a later commit.
>>
>> Pushing those commits all together fails with the message above,
>> and in order to not confuse GIT, deleted files should be committed
>> first, before applying any changes.
> 
> This is not needed at all, Git cannot get confused by something it has
> no knowledge of. Once a file is deleted, or moved, the history tracking
> stops.

I wanted to re-connect the resurrected files to the history of the port.
And that works best, if unmodified files are committed first, changes
applied and committed thereafter.

Did you try "git log multimedia/transcode"?

The history is there, back to 2002.



OpenPGP_signature
Description: OpenPGP digital signature

Re: [SOLVED?] Recovery of deleted ports fails due to pre-commit checks

[Stefan Esser]

Am 04.05.21 um 11:46 schrieb Mathieu Arnold:
> On Mon, May 03, 2021 at 09:54:36PM +0200, Stefan Esser wrote:
>> Am 03.05.21 um 09:01 schrieb Mathieu Arnold:
>>> On Sat, May 01, 2021 at 09:01:02PM +0200, Stefan Esser wrote:
>>>> The recovery of deleted ports in their previous form is rejected
>>>> by the pre-commit checks on the repository server:
>>>>
>>>> remote:
>>>> remote: 
>>>> remote: Do not commit ports without TIMESTAMP in their distinfo files.
>>>> remote: Rerun make makesum to add it.
>>>> remote: 
>>>> remote:
>>>>
>>>> I have tried to revert the deletion with unchanged files and then
>>>> updated the ports' Makefiles and distinfo files in a later commit.
>>>>
>>>> Pushing those commits all together fails with the message above,
>>>> and in order to not confuse GIT, deleted files should be committed
>>>> first, before applying any changes.
>>>
>>> This is not needed at all, Git cannot get confused by something it has
>>> no knowledge of. Once a file is deleted, or moved, the history tracking
>>> stops.
>>
>> I wanted to re-connect the resurrected files to the history of the port.
>> And that works best, if unmodified files are committed first, changes
>> applied and committed thereafter.
>>
>> Did you try "git log multimedia/transcode"?
>>
>> The history is there, back to 2002.
> 
> Yeah, but this has nothing to do with you commiting unmodified files.
> Git does not track file renames or moves (or resurrection), it blindly
> looks at what you told it and goes as far as it can find things.

Yes, sure, but the general advice when moving around files in GIT
repositories is: First move and commit unchanged, then modify in
place and commit again. And I was under the impression that the
same advice applies to files that have been deleted and are brought
back - GIT can identify and reconnect them in a way that preserves
history only by guessing, and I wanted to make it as easy as possible
for GIT, since I have watched GIT to get trivial operations of that
kind wrong in grotesque ways ...

https://github.blog/2020-12-17-commits-are-snapshots-not-diffs/#since-commits-arent-diffs-how-does-git-track-renames



OpenPGP_signature
Description: OpenPGP digital signature

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

[Stefan Esser]

Am 05.05.21 um 18:00 schrieb Yasuhiro Kimura:
> You misunderstand my intention. What I would like to do is to make a
> port use security/openssl instead of base OpenSSL even if user sets
> 'DEFAULT_VERSIONS+=ssl=base' in /etc/make.conf (or user doesn't
> customize setting about ssl at all).

You can mark the port as broken if the user has selected "base" and
this is incompatible with the port's requirements. E.g.:

.include 

.if ${SSL_DEFAULT} == base
BROKEN_FreeBSD_11=  OpenSSL 1.1 required
.endif

.include 

You can of course add a better message, and the user can decide to
try the compilation again after changing the default. But this will
of course prevent the building of official packages for FreeBSD-11.

> As I wrote previous mail, if 'USES=python:3.8+' is specified in
> Makefile of a port, lang/python38 is used for the port event if user
> adds 'DEFAULT_VERSIONS+=python=3.7' in /etc/make.conf. I'm looking for
> similar way about ssl setting.

You could add a dependency on the openssl port and make sure, that
the port's include file and library is used in preference of the
base version on FreeBSD-11.

But you have to consider the risk of mixing references to the base and
the ports version in one binary (e.g. other libraries are linked in that
had been built against the base version).

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: pkg builders order of jobs

[Stefan Esser]

Am 09.05.21 um 12:22 schrieb Ronald Klop:
> Hi,
> 
> On the pkg builders the list of builds is ordered on git hash.
> http://beefy18.nyi.freebsd.org/jail.html?mastername=main-amd64-default
> (NB: ipv6 only)
> 
> This ordering is totally random to me. With svn the list was naturally ordered
> because of the incremental commit id.
> 
> Is it possible to add the commit count to the job-name like 
> sys/conf/newvers.sh
> in base?
> git_cnt=$($git_cmd rev-list --first-parent --count HEAD 2>/dev/null)

Adding the start-time of the build in ISO format would also be highly
appreciated, at least by me ;-)

The date should reflect the time of the last commit that has been
considered. Such a time stamp would let me see with little effort
whether a failure is due to a long running build job that did not
catch-up with the latest fixes to a port, or whether there still is
an issue with a port (especially for the "exotic" architectures that
I do not test on my system and that often need a lot longer to complete
a build job).

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Firefox build failure on -CURRENT (with CLANG and with GCC)

[Stefan Esser]

Hi Florian,

seems that Firefox cannot be built with CLANG. The build fails due to a
visibility default set in mozilla-release/config/gcc_hidden.h, which is
in conflict with Qt declarations:

In file included from
work/mozilla-release/intl/locale/src/nsLocaleService.cpp:7:
In file included from /usr/local/include/qt4/QtCore/QString:1:
In file included from /usr/local/include/qt4/QtCore/qstring.h:46:
/usr/local/include/qt4/QtCore/qbytearray.h:143:7: error: visibility does
not match previous declaration
class Q_CORE_EXPORT QByteArray
  ^
/usr/local/include/qt4/QtCore/qglobal.h:1412:27: note: expanded from
macro 'Q_CORE_EXPORT'
#define Q_CORE_EXPORT Q_DECL_EXPORT
  ^
/usr/local/include/qt4/QtCore/qglobal.h:1269:42: note: expanded from
macro 'Q_DECL_EXPORT'
#define Q_DECL_EXPORT __attribute__((visibility("default")))
 ^
../../../config/gcc_hidden.h:6:13: note: previous attribute is here
#pragma GCC visibility push(hidden)

Seems that this GCC pragma has different semantics in GLANG ...

If the contents of gcc_hidden.h is commented out, CLANG completes the
build, but the installation fails in the phase where hyphenation tables
are built:

 adding: hyphenation/hyph_af.dic (deflated 55%)
  adding: hyphenation/hyph_sv.dic (deflated 51%)
  adding: hyphenation/hyph_it.dic (deflated 55%)
  adding: hyphenation/hyph_cy.dic (deflated 53%)
  adding: hyphenation/hyph_gl.dic (deflated 69%)
  adding: hyphenation/hyph_is.dic (deflated 50%)
  adding: hyphenation/hyph_ia.dic (deflated 51%)
  adding: hyphenation/hyph_en_US.dic (deflated 59%)
  adding: hyphenation/hyph_pt.dic (deflated 55%)
Segmentation fault (core dumped)
gmake[1]: *** [install] Error 139
gmake[1]: Leaving directory
`/usr/work/usr/svn/ports/head/www/firefox/work/mozilla-release/browser/installer'
gmake: *** [install] Error 2
*** [gecko-pre-install] Error code 2

Adding USE_GCC=any to the port lets the build complete, but installation
fails at a later point:

  adding: hyphenation/hyph_tr.dic (deflated 64%)
QEventLoop: Cannot be used without QApplication
resource:///components/txEXSLTRegExFunctions.js
resource:///components/nsLoginManagerPrompter.js
[...]
resource:///modules/services-sync/addonutils.js
Failed to import
resource:///modules/services-sync/addonutils.js:[Exception... "Component
returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)
[nsIJSCID.getService]"  nsresult: "0x80570016
(NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame ::
resource://gre/modules/Services.jsm ::  :: line 22"  data: no]
resource:///modules/services-sync/engines/clients.js
Failed to import
resource:///modules/services-sync/engines/clients.js:TypeError:
Services.appinfo is undefined
resource:///modules/services-common/utils.js
resource:///modules/services-notifications/service.js
resource:///modules/services-sync/engines/addons.js
Failed to import
resource:///modules/services-sync/engines/addons.js:TypeError:
Services.appinfo is undefined
resource:///modules/services-common/storageservice.js
resource:///modules/services-sync/engines/apps.js
Failed to import
resource:///modules/services-sync/engines/apps.js:TypeError:
Services.appinfo is undefined
resource:///modules/ClusterLib.js
resource:///modules/services-sync/rest.js
Failed to import resource:///modules/services-sync/rest.js:TypeError:
Services.appinfo is undefined
resource:///modules/SpellCheckDictionaryBootstrap.js
resource:///modules/services-sync/engines/forms.js
Failed to import
resource:///modules/services-sync/engines/forms.js:TypeError:
Services.appinfo is undefined
resource:///modules/services-common/log4moz.js
resource:///modules/services-common/stringbundle.js
resource:///modules/MessagePortWorker.js
Failed to import
resource:///modules/MessagePortWorker.js:ReferenceError: AbstractPort is
not defined
resource:///modules/services-sync/main.js
resource:///modules/services-common/rest.js
resource:///modules/distribution.js
resource:///modules/services-sync/engines/history.js
Failed to import
resource:///modules/services-sync/engines/history.js:TypeError:
Services.appinfo is undefined
resource:///modules/services-sync/addonsreconciler.js
Failed to import
resource:///modules/services-sync/addonsreconciler.js:TypeError:
Services.appinfo is undefined
resource:///modules/services-sync/engines/tabs.js
Failed to import
resource:///modules/services-sync/engines/tabs.js:TypeError:
Services.appinfo is undefined
resource:///modules/services-sync/engines/bookmarks.js
Failed to import
resource:///modules/services-sync/engines/bookmarks.js:TypeError:
Services.appinfo is undefined
resource:///modules/services-common/preferences.js
resource:///modules/services-sync/keys.js
Failed to import resource:///modules/services-sync/keys.js:TypeError:
Services.appinfo is undefined
resource:///modules/services-sync/policies.js
Failed to import
resource:///modules/services-sync/policies.js:TypeError:
Services.appinfo is undefined
resource:///modules/s

Re: Removal of Portmanager

[Stefan Esser]

Am 16.01.2013 09:48, schrieb b.f.:
> Mark wrote:
>> On Wed, Jan 16, 2013 at 01:51:39AM +, RW wrote:
 Reports are sent to ports@ every 2 weeks.
>>>
>>> And I wonder how many people read carefully through all 478 entries.
>>
>> And your suggestion is ... ?
>>
> 
> Try ports/ports-mgmt/portupdate-scan.

I just wanted to give it a try, but it does not seem to support PKGNG.
(I'll have a look to check whether that's easy to fix ...)

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

Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous

[Stefan Esser]

Am 08.09.2013 08:14, schrieb O. Hartmann:
> On Sat, 7 Sep 2013 22:49:54 GMT rak...@freebsd.org wrote:
> 
>> Synopsis: devel/qt4-script:
>> /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is
>> ambiguous
>> 
>> State-Changed-From-To: open->patched State-Changed-By: rakuco 
>> State-Changed-When: Sat Sep 7 22:47:43 UTC 2013 
>> State-Changed-Why: I don't think the previous version worked.
>> 
>> From your description, it looks like you've switched to building
>> with libc++ whereas libstdc++ was being used before.
>> 
>> The upcoming Qt 4.8.5 plus a few patches which only made it to
>> 4.8.6 (but we've backported) will finally make Qt build with
>> libc++.
>> 
>> We've just sent an exp-run request for Qt 4.8.5, and will
>> hopefully fix all these errors once it is committed.
>> 
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=181913
> 
> 
> I build the world/kernel since early this year with
> 
> CXXFLAGS+=  -stdlib=libc++ CXXFLAGS+=
> -std=c++11
> 
> 
> in /etc/src.conf. I do not use those flags in /etc/make.conf!
> /etc/src.conf is supposed to target ONLY the /usr/src world, not
> the ports - this is as I interpret the man page for /etc/src.conf
> and it would be logical. But this rule/thinking seems to be broken
> by some includes from /usr/ports/Mk ingredients.

There are ports that use bsd.prog.mk instead of the Makefile supplied
with the source files. Just grep for bsd.port.mk in the port's "files"
sub directory, if you find that /etc/src.conf settings affect a port.

I think these ports are in violation of POLA and had a longer mail
exchange with a port maintainer, who told me that use of bsd.prog.mk
was the preferred method to build binaries on FreeBSD, for base and
for ports.

So no file under /usr/ports/Mk is to blame, but some ports do
implicitly reference /etc/src.conf via their use of bsd.prog.mk.

Regards, STefan

NB: I just performed the grep suggested above and found that the
following ports mention bsd.prog.mk in files/*:

archivers/parchive
archivers/pixz
archivers/zipmix
audio/id3v2
audio/mp3gain
benchmarks/raidtest
comms/mlan
comms/mlan3
comms/obexapp
converters/chmview
converters/iconv
devel/bcc
devel/calibrator
devel/frink
devel/libpasori
devel/linux_kdump
devel/opencvs
devel/qmake
devel/qmake4
devel/ruby-byaccr
dns/dnsreflector
editors/fb
editors/hexpert
editors/tamago
editors/tweak
emulators/cpmtools
finance/libstocks
ftp/bsdftpd-ssl
ftp/ftpsesame
games/cre
games/xroach
graphics/exiftran
graphics/s10sh
japanese/edyvalue
japanese/kon2-16dot
japanese/man
japanese/suicavalue
mail/althea
mail/archivesmtp
mail/biffer
mail/dma
math/moo
misc/cpuid
misc/team
net-mgmt/choparp
net-mgmt/icmpquery
net-mgmt/ipv6mon
net/ifdepd
net/openntpd
net/packetdrill
net/pcnfsd
net/pppd23
net/pxe-pdhcp
net/sharity-light
net/skyfish
palm/mdbconv
print/epsonepl
print/mup
security/ipv6toolkit
security/isakmpd
security/openssh-askpass
security/sst
shells/nologinmsg
shells/v7sh
sysutils/bsdmoted
sysutils/freqsdwn
sysutils/jfbterm
sysutils/sb16config
sysutils/sbniconfig
sysutils/setquota
textproc/hhm
textproc/wordnet
www/http_get
www/http_load
www/http_post
www/mathopd
www/mohawk
x11-wm/vtwm
x11/gpctool
x11/wmxss
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: How to disable staging support in ports tree universally?

[Stefan Esser]

Am 12.10.2013 07:59, schrieb Jeremy Chadwick:
> So how do I stop this staging nonsense when it doesn't apply to any of
> my systems/environments?  I install third-party software directly from
> the ports tree, I DO NOT USE pkg, nor do I ever plan on using pkg given
> that I customise ports individually (through "make config" and some
> make.conf knobs) quite heavily.
> 
> I want to know how to stop this excess waste of disk I/O when it doesn't
> apply to my environments/systems, and I'm sure many others do as well.

Staging is no "waste" of disk I/O, it has been implemented for
very good reasons.

If you are compiling ports on a system with slow disks, you may
consider moving STAGEDIR into a RAM disk or TMPFS.

I find the extra I/O to be negligible - most ports spend a magnitude
more time in GNU configure than in the staging phase.

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

Re: Proposal for Authors / Vendors in ports

[Stefan Esser]

Am 15.11.2013 08:23, schrieb Matthew Seaman:
> On 15/11/2013 00:54, Eitan Adler wrote:
>> On Thu, Nov 14, 2013 at 5:41 PM, Jaap Akkerhuis
>>  wrote:
>>> 
>>> On Nov 14, 2013, at 8:30, Erwin Lansing 
>>> wrote:
>>> 
 That sounds like an excellent idea.  I'm just a bit worried
 about spreading the information over too many places, and
 would rather split content from logic and add these to
 pkg-descr as well next to the current WWW.  I know we're not
 consistent already with things like COMMENT and LICENSE
 already in the Makefile, so won't ojbect too much to where
 these end up.
>>> 
>>> Apart from spreading this information into to many places
>>> (pkg_desc seams a proper place to have such information), why
>>> have the Makefile double up as a database?
>> 
>> pkg_descr is free form.  Makefiles are parsable (make -V).
> 
> pkg_descr is only as free-form as we define it to be.  It's a lot 
> quicker to parse out the WWW entry from pkg_descr than it is to
> run 'make -V' to extract values from port Makefiles.  That's
> because make includes and parses a whole stack of different files
> from /usr/ports/Mk and elsewhere and does a bunch of other
> processing -- takes about 200ms per port just to print out the
> variables used in the INDEX.
> 
> So, unless the variable is needed as part of the build process for
> a port putting it in pkg_decr makes sense to me.  This could
> include some well-known values like MAINTAINER if we want to go
> that far.

Two comments:

1) I think that pkg-descr contains information about the ported
   software, not the port. I.e. the web-site, the organisation, or
   the license are good candidates for pkg-descr. The maintainer
   or other information that does not relate to the ported software
   itself but just to how it is managed in the FreeBSD ports tree
   should be kept in some other place. (IMHO)

2) If meta-information is moved to pkg-descr, it might be worthwhile
   to add some knowledge about formats and restrictions to portlint.

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

Re: portmaster refuses to use pkgng with local packages

[Stefan Esser]

Am 24.11.2013 12:43, schrieb Axel Rau:
> While trying ports-mgmt/poudriere in my ezjail/portmaster environment, I 
> learned:
> poudriere can't run at secure level 1, because it loads linux.ko and uses 
> chflags.
> 
> Regarding moving to pkgng, what are the replacements to portaudit / jailaudit?

# pkg audit -F

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

Problem with Samba-4.1 on -CURRENT

[Stefan Esser]

I've recently tried Samba-4.1 as a replacement for 3.6, but cannot get
it to work.  I'm seeing SIGABRT being triggered, probably due to a
problem in MD5Final().

I'm seeing the same kind of abort in
- smbd
- smbclient
- smbclient4

E.g.:
# smbclient4 -U guest -L localhost
Password for [WORKGROUP\guest]:
Abort trap (core dumped)


The following error messages are logged when I try to access a Samba
share from a windows system:

May  4 08:37:23 dummy smbd[26018]: stack overflow detected; terminated
pid 26019 (smbd), uid 0: exited on signal 6
May  4 08:37:23 dummy smbd[26019]: stack overflow detected; terminated
pid 26020 (smbd), uid 0: exited on signal 6
May  4 08:37:23 dummy smbd[26020]: stack overflow detected; terminated
pid 26021 (smbd), uid 0: exited on signal 6
May  4 08:37:23 dummy smbd[26021]: stack overflow detected; terminated
pid 26022 (smbd), uid 0: exited on signal 6
...


Execution of smbclient in a debugger leads to:

(lldb) bt
* thread #1: tid = 101459, 0x00080437a3aa libc.so.7`kill + 10, stop
reason = signal SIGABRT
  * frame #0: 0x00080437a3aa libc.so.7`kill + 10
frame #1: 0x00080437a360 libc.so.7`??? + 144
frame #2: 0x00080437a2d0 libc.so.7`__stack_chk_fail + 16
frame #3: 0x00080169d66d libsamba-util.so.0`hmac_md5_final
(digest=0x7fffd4a0, ctx=0x7fffd2e8) + 141 at hmacmd5.c:102

(Running under control of system GDB and GDB-7.9 behave the same as
under LLDB.)


This happens on a -CURRENT amd64 system with a port compiled with
default options. Both GCC-4.8 and system CLANG have been used to
build the port - with identical results.

The Samba-4.1 port uses -fstack-protector, and it seems that the stack
is really corrupted, when execution stops.  But I did not have time to
check why this happens.

Does anybody have an idea what's going wrong?

(One thought is that there might be several implementations of MD5Final
with different definitions of "struct ctx" ...)

I'll create a PR with all information I'm able to gather, if this is
a real problem (and not one that only exists in my environment).

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

Re: Samba 4.2.3 exited on signal 4

[Stefan Esser]

Am 18.08.2015 um 14:07 schrieb Timur I. Bakeyev:
> Could be that you are affected by
> https://bugzilla.samba.org/show_bug.cgi?id=11455
> 
> Can you, please, verify, that it is the case?

A good test is to install the pre-compiled package and compare
ldd output for the port compiled by you and the package binaries
(i.e. strip off the addresses and compare only the filenames that
ldd reports for either smbd binary).

In my case the smbd and smbclient where linked against a wrong
MD5 library (/usr/local/lib/libmd5.so from www/libwww) instead
of the system library (/usr/lib/libmd.so). This was due to the
configure script preferring libmd5.so over libmd.so ...

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

Re: Samba 4.2 crashes

[Stefan Esser]

Am 25.08.2015 um 18:02 schrieb Andrea Venturoli:
> Hello.
> 
> I'm trying to upgrade from samba 3.6 to 4.2 (mainly because the former
> is deprecated, so I don't want AD, just plain old functionality).
> 
> I started with simpler installations and had almost no problem.
> However, in a just a little bit more complex case (PDC+BDC with LDAP
> backend), smbd and/or winbindd keep crashing.
> 
> I started by upgrading the PDC; everything should be fine (config files,
> rc.conf, database directory, connection to LDAP, etc...).
> However I'm getting lots of the following messages:
> 
>> kernel: pid 50545 (smbd), uid 0: exited on signal 6
> 
>> winbindd[89801]: stack overflow detected; terminated
> 
>> winbindd[89801]: stack overflow detected; terminated

I have seen that kind of failure when the port was built on a system
that had www/libwww installed. In that case libmd5.so from libwww is
linked to samba in preference of the system's libmd.so.

I sent a note to the port's maintainer, a few weeks ago, but apparently
he did not apply the patch I included, which fixes the port.

In case you have libwww installed, you can simply temporarily deinstall
it while you build samba42.

Or apply the attached patch (copy it to the samba42 port's files
directory and rebuild the port).

Best regards, STefan
--- lib/crypto/wscript_configure~   2014-10-01 11:16:21.0 +0200
+++ lib/crypto/wscript_configure2015-08-11 22:54:47.865668000 +0200
@@ -1,8 +1,8 @@
 if not conf.CHECK_FUNCS_IN('MD5Init', 'bsd', headers='bsd/md5.h',
 checklibc=True):
-conf.CHECK_FUNCS_IN('MD5Init', 'md5', headers='sys/md5.h',
-checklibc=True)
 conf.CHECK_FUNCS_IN('MD5Init', 'md', headers='sys/md5.h',
 checklibc=True)
+conf.CHECK_FUNCS_IN('MD5Init', 'md5', headers='sys/md5.h',
+checklibc=True)
 conf.CHECK_FUNCS_IN('CC_MD5_Init', '', headers='CommonCrypto/CommonDigest.h',
 checklibc=True)
___
freebsd-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: minidlna server not visible in network

[Stefan Esser]

Am 19.12.2015 um 13:45 schrieb Guido Falsi:
> On 12/19/15 12:26, Volodymyr Kostyrko wrote:
>> On 19.12.15 00:03, Dr. Peter Voigt wrote:
>>> Today I have upgraded net/minidlna to latest version. I am on FreeBSD
>>> 10.2-RELEASE-p8 (amd64).
>>>
>>> Access via web interface on port 8200 is working fine. But the MiniDLNA
>>> server is not seen in my network and correspondingly I cannot access
>>> any of my FLAC audio files. I do not host any other media besides the
>>> FLAC files.
>>>
>>> I strongly assume this is related to upgrading to version 1.1.5.
>>>
>>> Can anyone reproduce this behavior?
>>
>> That's not correct.
>>
>> 1. If you already queued any files on your UPnP client whey will play
>> correctly.
>> 2. If you leave you UPnP client open for some time it will eventually
>> find your server.
>> 3. If your UPnP client is already open restarting minidlna will make it
>> visible.
>>
>> So I'd say it just fails responding to probes.
>>
> 
> I posted a reply to the bug report.
> 
> I'll investigate this one further in thee next few days. I'll followup
> in the bug report with anything I find out.

I tried to add some information to the bug report, but bugs.freebsd.org
denied access and there does not seem to be a way to reset the password.
(I thought it was the Kerberos password, but that did not work.)


Anyway: I had been using minidlna-1.1.5 for a few weeks in order to
test the patch that makes it use poll() instead of select() in order to
allow for large media collections (some 8000 directories in my case)
and kqueue() notifications for file changes.

I noticed, that no initial service announcements were sent, but given
enough time, the minidlna server would be noticed by clients. Since I
had not tested the unpatched minidlna-1.1.5 (without the poll-patch),
I had assumed that the problem was in my poll-patch.


I'd assume that the initial SSDP packet is not sent by minidlna. I do
not know whether the situation is fixed by a timer based SSDP packet
being sent at a later time, or by the client trying to reach the server
(but I guess the latter case applies).


A sensible test would be a tcpdump of traffic between minidlna server
and a client, that is started before the minidlna server. My guess is,
that minidlna replies to a client polling for reachable UPnP servers,
and that minidlna does not announce its availability when started, but
only in response to clients polling for a server.

Since I do not have time to further diagnose this before mid of January,
I went back to 1.1.4 for the time being.

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

Re: pipelight and playonbsd

[Stefan Esser]

Am 04.04.2016 um 20:46 schrieb Grzegorz Junka:
> Port playonbsd depends on i386-wine-devel and pipelight depends on
> i386-wine-staging. So when I want to install pipelight pkg asks me to
> uninstall playonbsd. Does it mean playonbsd is incompatible with
> pipelight? Are two versions of wine really necessary? Wouldn't it be
> better if ports were dependent on one or the other? Howe can I solve this?

You should be able to easily test, whether PlayOnBSD works
with i386-wine-staging if you just remove i386-wine-devel
and install i386-wine-staging instead.

Please report to me, what you find.

If you build PlayOnBSD from the port, your current Wine
version will be used, anyway. I'd be interested in whether
wine-staging works, because I'll need to add a CONFLICTS
line to the port, to prevent installation of PlayOnBSD on
systems with incompatible wine versions, else ...

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

Re: HPLIP ugen

[Stefan Esser]

Lars Eighner wrote:
> On Sat, 1 Sep 2007, Brian Wagener wrote:
> 
>> When using HPLIP your usb printer has to use the ugen driver in order for
>> all printing/scanning/status functionality to be present. The problem
>> is, my
>> printer loads as a umass device so it doesn't get detected by hplip.
>>
>> Does anyone know of a workaround for this? Is there anyway to force my
>> printer to use ugen instead of umass? I can't just remove umass because
>> other devices require it.
> 
> The only way is to use a kernel built without umass (and without ulpt).  If
> you can boot without umass, you can load umass from the command line (using
> kldload) after the printer is attached.  Although I have not actually tried

Hmmm, there might be two methods to implement a more user-
friendly behaviour:

1) Make umass ignore the device

2) Make ugen accept it with higher priority than umass

For 1) the umass driver should get a "DONOTATTACH" quirk,
which then lets ugen gain control. But if anybody wanted
to use the umass driver with that printer (e.g. if he is
only interested in reading from the built-in card reader
and does not want to print anything), this would not be
possible (without installation of HPLIP, that is).
If the device was grabbed by ulpt (if umass does not want
it, then it must be black-listed in both, but I do not
expect this to be the case).

Variant 2) would need a device table and support for
scanning it to be added to ugen. Devices that are best
served by ugen could be entered to that list, to prevent
other drivers from taking precedence. This does not seem
such an uncommon situation and might also be useful for
device protocol tests, for example. Device hints could
be used to control this feature for specific devices.

Either variant is workable (but 1) is easier to implement).
It may be counter-intuitive for a device to be added to a
driver that is *not* meant to be used to control it ...

Regards, STefan
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: minidlna: file descriptor 3794 too big for select

[Stefan Esser]

Am 23.06.2014 15:21, schrieb Bob Willcox:
> I just installed minidlna 1.1.3 on my system from ports and ran into the
> problem described in Stefan Essers' bug report 185155.
> 
> Checking the source and the patch file extra-patch-kqueue I see that Stefan's
> suggested workaround has been included. However, the file upnpevents.c didn't
> 'know' about the increased FD_SETSIZE value so it failed with the following
> fatal error:

Yes, the diagnostic was just meant to report the issue, since the
message printed in the error case was not specific and misleading,
without this check.

Then I proposed to a patch that increased FD_SETSIZE, to not abort
with a clear indication of what went wrong, but instead to allow
the program to work with large media libraries.

But this was an intermediate step, too ... ;-)

> upnpevents.c:423: fatal: upnpevents_selectfds: file descriptor 3794 too big 
> for select, limit is 1024
> 
> So...I added a #define for FD_SETSIZE to the top of that file and things seem
> to be working ok now. Here's my simple patch:
> 
> --- upnpevents.c.orig 2014-06-05 17:14:30.0 -0500
> +++ upnpevents.c  2014-06-23 07:47:53.0 -0500
> @@ -47,6 +47,7 @@
>   */
>  #include "config.h"
>  
> +#define FD_SETSIZE   8192
>  #include 
>  #include 
>  #include 
> 

The use of select() is a bad choice when combined with kqueue(), since
data connections tend to be at the upper end of the FD range, while all
the thousands of file descriptors between the lowest few and topmost
few are for exclusive use by kqueue(), and thus never used in FD_SET.

To fix this problem without the need to adapt FD_SETSIZE to the number
of directories containing media files (and thus watched by kqueue()),
I developed a patch that converts minidlna to use poll() instead of
select(). This is more efficient (and IMHO also clearer), but I did not
make any attempt to get that patch accepted upstream.

I've been using the patched minidlna for more than 6 months without
any issues, and have moved the patch forward over two minor releases,
meanwhile. Since I wanted a minimal diff, indentation of the patched
files is not right (i.e. the patch has been created with "diff -bw").

I do not want to spam the mail-list with a large patch, that is only
of interest to a minority of readers, but I'll send it in private mail
to anybody showing interest.

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

Re: Help with "port test"

[Stefan Esser]

Am 15.07.2014 11:48, schrieb Andrea Venturoli:
> Hello.
> 
> I'm trying to create a new port and there are some things I don't
> understand.
> 
> Referring to chapter 9 of the Porter's Handbook:
> 
> _ "make clean; make package PREFIX=/var/tmp/`make -V PORTNAME`" gives no
> error;
> 
> _ "make stage && make check-orphans && make package" also finds no issue;
> 
> _ however "port test" gives:
> 
>> ===> Checking for directories owned by MTREEs
>> Error: Owned by MTREE: @unexec rmdir "/usr/local" >/dev/null 2>&1 || :
> 
> What does this mean?

You are trying to delete the directory /usr/local, which is part of
the base system.

Just remove '@unexec rmdir "/usr/local" ...' from pkg-plist ...

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

pkg: Cannot get a read lock on a database, it is locked by another process

[Stefan Esser]

The locking of the pkg database leads to soft failures, but I'm afraid,
if these soft failures happen to coincide with certain administrative
tasks, they can lead to unexpected results.

One example is that portmaster fails to detect PKGNG (and then assumes
to be working in a pre-PKGNG environment), if some pkg subcommand locks
the database. To repeat:

# pkg version -Bs &
# pkg info

As long as pkg version runs, pkg info fails to get the read lock (at
least in the large majority of my tests). You can also prevent any pkg
command from running, if you STOP (kill -STOP / ^Z) pkg version. Any
other pkg command will fail, until "pkg version" has been "unstopped"
and run to completion. This might even be a local DoS, if any command
that read-locks the package DB for extended time can be executed by
an unprivileged user.

Similar error messages are reported by pkg_libcheck, which issues
lots of pkg commands in parallel. (I have observed some 5 lock
failures per 1000 installed packages on my system).


I did not try to test all combinations of simultanous pkg commands
and did not verify, whether e.g. "pkg upgrade" might be stopped
half way through because of an error accessing the pkg database,
but I have seen SQLITE error messages that indicated failed write
operations (INSERT/UPDATE).

Either the timeouts are too low, or the duration during which the
database is locked by a single operation is too large (or there is
no fairness and some processes never get access to the database?).


I think this should be fixed, since pkg commands that lock the
database can be run from CRON or by other means in the background
and the operator who issues pkg commands in the foreground (or runs
portmaster) receives spurious error messages (which might still be
better than the batch jobs doing silly things, after they failed to
obtain information from the pkg database ...)

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

Re: Strange pkg_deinstall behaviour with pkgng

[Stefan Esser]

Am 29.07.2014 um 23:45 schrieb Baptiste Daroussin:
> On Tue, Jul 29, 2014 at 11:23:10PM +0200, Gyrd Thane Lange wrote:
>> General gripe about pkg(8): The command structure and options are
>> very similar to the previous pkg_tools but with enough changes in
>> options and behaviour that it trips up an unwary user. I feel
>> this is a POLA violation. It is almost like it is baiting the
>> user into making a mistake. Is is similar enough to the old tools
>> that the user think it is sufficient to just replace the hyphen
>> with a space (as in pkg-delete and pkg delete) but sometimes with
>> subtle changes in options or behaviour, most of them with no
>> clear rationale for the change.
>> 
>> I suppose that the superficial likeness was to make it more
>> familiar for existing users of pkg_tools, but since it is not
>> 100% compatible (would be better if it was) it would perhaps have
>> been better to make a clean break to remove preconceptions about
>> operations.
>> 
> making a clean break would have made the tool completly rejected,
> the fact we were quite closed did the trick to help the project
> moving to pkg.

Hi Bapt,

this is probably true and the pkg commands are similar enough for
interactive use, if you know pkg_ (and you'll spot unexpected
behaviour and adjust your usage if the output did not match your
expectations).

Don't get me wrong: I highly appreciate the effort and result of
creating the new pkg tools!

And I've been using them as soon as they were first available for
testing and have converted a few scripts to (also) support the
new pkg tools.


But I second Gyrd's position: Scripts will perform unexpected
actions without the user noticing that some intermediate step
was wrongly converted from pkg_ to pkg (or the semantics of the
pkg options changed when new features where added, changing the
previously compliant behaviour in a way not expected by the
author of the script).

We can try to keep portmaster and portupgrade, the bsdadmintools
and other script code, that relies on pkg consistent with the
evolving semantics of pkg options.


But there may be scripts we are not aware of or that we do not
have in the ports collection, which break in unexpected and hard
to fix ways.

IMHO the only viable solution is to be as compatible to the old
pkg_ tools as possible with reasonable effort.

When there are incompatibilities changes to the semantics of
an option (either because some option can not be implemented,
because it is obsolete, or because better semantics can be
provided), then a new option should be used for the new
semantics and the old option should either still be available
with the legacy result, or it should lead to an error abort
(and if you do not catch that in a script, that script is to
blame, not the new pkg tools).

In short:

- kept options should give very similar results

- new options may produce whatever they want

- useless options should not be re-used to provide some other
  useful result, but should instead lead to an error abort


And I'll repeat, that there is nothing wrong with pkg being
different from pkg_*. But care should be taken to prevent
non-interactive use of pkg from corrupting a system ...

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

[Analyzed] Re: Problem with xorg

[Stefan Esser]

The problem is caused by Unicode code points in keymap files, which were
made possible (and have to be used) for many locales after the
introduction of Unicode support with vt(4).

Am 28.08.2014 um 19:43 schrieb Stefan Esser:
> Am 28.08.2014 um 17:03 schrieb Filippo Moretti via freebsd-stable:
>> I have problem with xorg with my custom kernel both with and without VT 
>> supports.
>> I can still reboot with generic and have xorg work.My system:FreeBSD sting 
>> 10.0-STABLE FreeBSD 10.0-STABLE #0 r269789: Mon Aug 11 02:47:02 UTC 2014 
>> r...@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC  i386
>> With my kernel-vt I get a sementation fault,while with SC I got a complete 
>> crash
> [...]
>> [  3434.354] (**) Option "Protocol" "standard"
>> [  3434.354] (WW) Option "Device" requires an string value
>> [  3434.354] (**) Option "XkbRules" "base"
>> [  3434.354] (**) Option "XkbModel" "pc105"
>> [  3434.354] (**) Option "XkbLayout" "us"
>> [  3434.354] (**) Option "config_info" 
>> "hal:/org/freedesktop/Hal/devices/usb_device_46d_c517_noserial_if0"
>> [  3434.354] (II) XINPUT: Adding extended input device "USB Receiver" (type: 
>> KEYBOARD, id 7)
>> [  3434.354] Segmentation fault at address 0x2a3da760
>> [  3434.354] 
>> Fatal server error:
>> [  3434.354] Caught signal 11 (Segmentation fault). Server aborting
>> [  3434.354] 
>> [  3434.355] 
>> Please consult the The X.Org Foundation support 
>>  at http://wiki.x.org
>>  for help. 
>> [  3434.355] Please also check the log file at "/var/log/Xorg.0.log" for 
>> additional information.
> 
> Just a me-to, but on -CURRENT:
> 
> [   357.752] (**) Keyboard0: always reports core events
> [   357.752] (**) Option "Protocol" "standard"
> [   357.752] (**) Option "XkbRules" "xorg"
> [   357.752] (**) Option "XkbModel" "pc105"
> [   357.752] (**) Option "XkbLayout" "de"
> [   357.752] (**) Option "XkbVariant" "nodeadkeys"
> [   357.752] (II) XINPUT: Adding extended input device "Keyboard0"
> (type: KEYBOARD, id 7)
> [   357.752] Segmentation fault at address 0x80500ae80
> [   357.752]
> Fatal server error:
> [   357.752] Caught signal 11 (Segmentation fault). Server aborting

Further information: I used ktrace to identify the failing operation.
It is in x11-drivers/xf86-input-keyboard line 1265 of bsd_KeyMap.c:

#define KD_GET_ENTRY(i,n) \
  eascii_to_x[((keymap.key[i].spcl << (n+1)) & 0x100) +
keymap.key[i].map[n]]

[...]

void
KbdGetMapping (InputInfoPtr pInfo, KeySymsPtr pKeySyms, CARD8 *pModMap)
{
  KbdDevPtr pKbd = (KbdDevPtr) pInfo->private;
  KeySym*k;
  int   i;

#ifndef __bsdi__
  switch (pKbd->consType) {

/*
 * XXX wscons has no GIO_KEYMAP
 */
#if (defined (SYSCONS_SUPPORT) || defined (PCVT_SUPPORT)) &&
defined(GIO_KEYMAP)
  case SYSCONS:
  case PCVT:
{
  keymap_t keymap;

  if (ioctl(pInfo->fd, GIO_KEYMAP, &keymap) != -1) {
for (i = 0; i < keymap.n_keys && i < NUM_KEYCODES; i++)
  if (remap[i]) {
k = map + (remap[i] << 2);
k[0] = KD_GET_ENTRY(i,0);   /* non-shifed */
k[1] = KD_GET_ENTRY(i,1); /* shifted */
k[2] = KD_GET_ENTRY(i,4); /* alt */
k[3] = KD_GET_ENTRY(i,5); /* alt - shifted */
if (k[3] == k[2]) k[3] = NoSymbol;
if (k[2] == k[1]) k[2] = NoSymbol;
if (k[1] == k[0]) k[1] = NoSymbol;
if (k[0] == k[2] && k[1] == k[3])
  k[2] = k[3] = NoSymbol;
  }
  }
}
break;
#endif /* SYSCONS || PCVT */

The keymap returned by ioctl(GIO_KEYMAP) used to contain characters
in the selected locale, which meant it was limited to 8 bit values,
effectively.

Now with Unicode support, larger values (>=0x100) can be found in
keymap files. In my case, the Euro symbol (0x20ac) was the cause
of an out-of-bounds access to the keymap array in line 1265 of
bsd_KbdMap.c (assignment to k[2] for Alt "E").

I did not have time to investigate, how this problem can be
resolved, though.

But I'll create a ports PR with this information, since it must be
resolved before 10.1, or users of keyboard layouts that generate
characters beyond u+ff will reliably crash the X server ...

Regards, STefan

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

Re: [Analyzed] Re: Problem with xorg

[Stefan Esser]

Am 31.08.2014 um 09:45 schrieb Adrian Chadd:
> Ok, so what can we do right now to not have unicode characters in say,
> the US keymap file?

The  "normal" US keyboard (/usr/share/vt/keymaps/us.kbd) does not
contain characters >= 0x100.
There is no problem even with ISO8859-1 characters used in many European
countries, since they all are in the range 0x00 to 0xff.

A problem is European keyboards with teh Euro sign (0x20ac) or e.g.
Cyrillic or Greek keyboards, where many characters are >= 0x100.

> (Just a local change, not committed anywhere - I agree it needs to be
> fixed in the xorg code.)

I'm wondering whether it might make sense to have the work-around
committed to the xf86-input-keyboard port.
People will waste time trying to understand, why their X server stops
working when they select a keyboard layout with problematic characters
for use with vt.

This was not possible until a few weeks ago, since there were no such
keymaps committed to vt/keymaps. If you had a keymap defined in rc.conf,
then the name that used to work with syscons did not work with vt, but
was just
ignored (and the compiled in default US keyboard layout was used).

I plan to commit a change to rc.d/syscons, soon, which will allow vt to
be used with syscons keymap names (which are then internally converted
to vt keymap names).
With that change to rc.d/syscons, people will have their localized
keyboard layout under vt, but will not be able to a local X11 server,
anymore ...

So I'm considering to commit the work-around patch, since a single
missing key (under plain X11 - e.g. KDE works with all keys) will be
just a minor violation of POLA, compared to no X11 at all.

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

Re: svn: E200019: Version mismatch in 'svn_gnome_keyring' (expecting equality): found 1.8.0, expected 1.8.10

[Stefan Esser]

Am 03.09.2014 um 16:36 schrieb O. Hartmann:
> 
> I receive this error while using /usr/local/bin/svn:
> 
> svn: E200019: Version mismatch in 'svn_gnome_keyring' (expecting
> equality): found 1.8.0, expected 1.8.10
> 
> It occurs on every usage of the svn binary installed via port
> devel/subversion. Using /usr/bin/svn as it is installed by the base
> system works fine.

Hi Oliver,

I have experienced a similar problem after the upgrade of the port
to 1.8.10, but with kwallet instead of gnome-keyring. The system
SVN continued to work (probably because it lacks support for the
KDE or Gnome wallet applications?).

In my case, removal of the offending wallet application from the
config file (~/.subversion/config) solved the problem for me and
I did not further research the topic:

### Section for authentication and authorization customizations.
[auth]
### Set password stores used by Subversion. They should be
### delimited by spaces or commas. The order of values determines
### the order in which password stores are used.
### Valid password stores:
###   gnome-keyring(Unix-like systems)
###   kwallet  (Unix-like systems)
###   keychain (Mac OS X)
###   windows-cryptoapi(Windows)
# password-stores = gnome-keyring,kwallet
password-stores = gnome-keyring

In your case, removal of gnome-keyring should get you going again.

(I had not working X11 at the time of this issue, and therefore
could not check, whether a start of KDE after installation of the
svn-1.8.10 port might have resolved the issue ...)

> I already tried to recompile the whole port and prerequisits and also
> deleted it and reinstalled devel/subversion - no success. Somehow I
> think the system is polluted by some weird config file I've overseen (I
> also deleted my .subversion folder).

I looked up the routine that checks compatibility, but ran out of
time. It is in the svn sources but I did not keep note of the
file and function that emits the error message. And since the
above change to the config file made the problem disappear (and
there were no other reports on the mail lists), I lost interest
in analyzing the root cause.

> Does anybody has any idea?

Please try with only kwallet or no external password store
defined in the config file.

You may also check, whether starting SVN with gnome-keyring active
will fix the issue.

I'm not sure, whether this version check is new in 1.8.9, or why
it never before caused problems for me - but again, I do not have
time for research ...

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

Re: FreeBSD Port: x11-drivers/xf86-input-keyboard

[Stefan Esser]

Am 04.09.2014 um 07:42 schrieb Fervent Dissent:
> This is the first update I've done since switching to the new xorg. The
> first time neither the keyboard or mouse drivers were correctly chosen. Now
> the mouse upgraded fine, but the keyboard still defaults to the old xorg
> driver. After working on it I confirmed by manually downloading both
> versions. My keyboard only worked after 'pkg add
> xf86-input-keyboard-1.8.0_2.txz'. The version pkg fetches is 11120kB, the
> one I added is 11124kB. I am using all packages on my system.
> 
> Could this be fixed?
> 
> I also tried to build from ports, but that also built the wrong version? I
> just wanted to report this incase others have problems.

This is caused by your use of the vt console driver with a Unicode
keymap containing characters >= 0x100. I have annalyzed this and
created a PR with patch for the port:

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

As a workaround, you may start the X server with a US keyboard by
issuing

kbdcontrol -l us

just before starting X. You'll need to select an appropriate keymap
under X, then.

Regards, STefan

PS: This is a problem with the xorg-input-keyboard port and if it
is not fixed within that port, there will be a huge number of
users affected, when 10.1 is released. This must be fixed!
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: service doen't get started at boottime, but can start manually

[Stefan Esser]

Am 07.09.2014 um 19:00 schrieb Mike Clarke:
> So all files in /etc/rd.d are potential startup scripts but those in 
> /usr/local/etc must meet the requirement of having a PROVIDE line.
> 
> This inconsistency isn't mentioned anywhere in the examples in 
>  so 
> it looks like either the documentation needs this adding or perhaps 
> the test for PROVIDE in find_local_scripts_new() should be replaced by 
> a test for defining the variable "name" (which is mandatory) or 
> perhaps there's no longer any need to apply this test?

This was for a reason:

There used to be an etc/rc.local (not sure about its name at that
time) that just invoked all scripts found in /usr/local/etc/rc.d
in alphabetical order, ignoring backup scripts ending in e.g. "~".
Scripts where started without argument, there was no stop function
and thus no way to stop a local service from a rc.d script before
shutdown.  (This logic is still found in "rc.d/localpkg" - it does
try to perform a stop operation though, which is different from
the old behaviour AFAIR.  Legacy startup scripts did not check for
any parameters being passed to them ...)

> In /etc/rc we have:
[...]
> 112 # Now that disks are mounted, for each dir in $local_startup
> 113 # search for init scripts that use the new rc.d semantics.
> 114 #
> 115 case ${local_startup} in
> 116 [Nn][Oo] | '') ;;
> 117 *)  find_local_scripts_new ;;
> 118 esac
[...] (The above sets ${local_rc}
> 126 files=`rcorder ${skip} ${skip_firstboot} /etc/rc.d/* ${local_rc} 
> 2>/dev/null`

When local/etc/rc.d was included into the rcorder based dependency
calculation, there still were many "old" scripts.  Invoking them at
shutdown could lead to bad effects and they lacked the parameters
required for dependency calculation.  (IIRC, these used to have a
".sh" extension, but I'm not sure whether it was mandatory in order
to have them executed by rc.d/local.)

A simple mechanism was required to distinguish scripts that should
still be started in alphabetic order and only on startup from those
that had dependency information (to be sorted by rcorder and to be
invoced with "stop" on shutdown).  And checking for "PROVIDE:" is a
simple discriminator, which selects the mechanism to use, without
relying on the file name (which did not follow a strict scheme and
presence or absence of ".sh" was no good indicator).


This logic (and dependency on PROVIDE: for local startup files) exists
as long as they have been included in the rcorder calculation.  And it
may still be a sensible requirement, since there might be local startup
scripts that never made it into the tree or into a port, which rely on
this behaviour.

This is obviously a shortcoming in the documentation, which should be
fixed.  AFAIK, the old style startup files have never been deprecated
and are still fully supported ...

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

Re: symlinked ports directory -> problem to resolve dependencies in portmaster

[Stefan Esser]

Am 16.11.2014 um 07:26 schrieb Alexander Leidinger:
> Hi,
> 
> my /usr/ports directory is a symlink to /space/system/usr_ports, when I
> try now to update a port with portmaster, it fails when it tries to
> follow dependencies.
> 
> Example:
> ---snip---
> # portmaster webcamd-
> ===>>> Package installation support cannot be used with pkgng yet,
>it will be disabled
> 
> 
> ===>>> Currently installed version: webcamd-3.17.0.6
> ===>>> Port directory: /usr/ports/multimedia/webcamd
> 
> ===>>> Launching 'make checksum' for multimedia/webcamd in background
> ===>>> Gathering dependency list for multimedia/webcamd from ports
> ===>>> Launching child to install /space/system/usr_ports/devel/pkgconf
> 
> ===>>> webcamd-3.17.0.6 >> /space/system/usr_ports/devel/pkgconf (1/1)
> 
> ===>>> No valid installed port, or port directory given
> ===>>> Try portmaster --help
> 
> 
> ===>>> Update for /space/system/usr_ports/devel/pkgconf failed
> ===>>> Aborting update
> 
> # realpath /usr/ports/devel/pkgconf
> /space/system/usr_ports/devel/pkgconf
> 
> # make -C /usr/ports -V PORTSDIR
> /space/system/usr_ports
> 
> # grep PORTSDIR /etc/make.conf
> 
> ---snip---
> 
> I can't find an entry in UPDATING which looks related. Any ideas what's
> wrong here?

Hi Alexander,

there was a change to the .mk files which requires the attached patch to
portmaster (repeated inline, but probably with mangled white-space):

--- portmaster~
+++ portmaster
@@ -359,7 +359,7 @@
 if [ "$$" -eq "$PM_PARENT_PID" ]; then
if [ -z "$pd" ]; then
if [ -z "$PORTSDIR" ]; then
-   [ -d /usr/ports ] && pd=/usr/ports
+   [ -d /usr/ports ] && pd=`realpath /usr/ports`
[ -z "$pd" ] &&
pd=`pm_make_b
-f/usr/share/mk/bsd.port.mk -V PORTSDIR 2>/dev/null`
else

I always wanted to create a PR that mentions that patch, but forgot
about it and was just reminded by you ;-)

Best regards, STefan
--- portmaster~
+++ portmaster
@@ -359,7 +359,7 @@
 if [ "$$" -eq "$PM_PARENT_PID" ]; then
if [ -z "$pd" ]; then
if [ -z "$PORTSDIR" ]; then
-   [ -d /usr/ports ] && pd=/usr/ports
+   [ -d /usr/ports ] && pd=`realpath /usr/ports`
[ -z "$pd" ] &&
pd=`pm_make_b -f/usr/share/mk/bsd.port.mk -V 
PORTSDIR 2>/dev/null`
else
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Locking problems in pkg makes portmaster fail

[Stefan Esser]

Hi all,

I've been having problems with portmaster being aborted because of
failed attempts of pkg to obtain a lock. The same problem occurs
with pkg and pkg-devel (I installed pkg-devel to check whether it
was due to an already fixed problem in pkg-1.3.8).

Other possibly relevant machine details: -CURRENT/amd64 on ZFS.


A typical portmaster/pkg error message is:


===>>> Creating a backup package for old version cuse4bsd-kmod-0.1.35
Creating package for cuse4bsd-kmod-0.1.35
pkg: Cannot get an advisory lock on a database, it is locked by another
process

===>  Installing for cuse4bsd-kmod-0.1.35
===>  Checking if cuse4bsd-kmod already installed
===>   cuse4bsd-kmod-0.1.35 is already installed
  You may wish to ``make deinstall'' and install this port again
  by ``make reinstall'' to upgrade it properly.
  If you really wish to overwrite the old port of cuse4bsd-kmod
  without deleting it first, set the variable "FORCE_PKG_REGISTER"
  in your environment or the "make install" command line.
*** Error code 1

Stop.
make[1]: stopped in /usr/svn/ports/head/multimedia/cuse4bsd-kmod
[...]


In all these cases it was just portmaster that was using pkg, no other
process could have held a lock. (BTW: This was with "portmaster -dgw",
I have not checked whether other options hide this problem ...)


I have further debugged this problem and found, that the locking
problem occurs during this command from /usr/ports/mk/bsd.openssl.mk:

OPENSSL_SHLIBFILE!= ${PKG_INFO} -ql ${OPENSSL_INSTALLED} | grep
"^`pkg query "%p" ${OPENSSL_INSTALLED}`/lib/libcrypto.so.[0-9]*$$"

(sorry about possible line-wrap - this should be a single line ...)

This command on its own can be executed without problems:

# pkg info -ql openssl | grep `pkg query %p openssl`/lib/libcrypto.so.*
/usr/local/lib/libcrypto.so.8

But when it is run in parallel to portmaster creating a package, that
process can not acquire the necessary lock and portmaster aborts.

This problem does only occur, if portmaster runs a background task
that parses bsd.openssl.mk (and it appears that every time this file
is read by "make", the pkg-grep-pkg command sequence is invoked).
(It seems to be due to a "make -V" in some other port's directory,
which has a ".include bsd.openssl.mk", which is executed by portmaster
in preparation of building the next port, but I have not identified
the exact line in portmaster that does that.)

I have no other work-around than to manually install the affected
ports.

Anyway: While it seems that this is a problem in portmaster, I still
think that multiple invocations of "pkg info" or "pkg query" at the
time a "pkg create" is running should not make the latter fail ...

Regards, STefan

PS: I'm supprised this problem has not been reported on the mail-lists,
since it is unlikely to only affect me. I'll do a search in the PRs
and create a new PR if I really cannot find an existing one ...
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: rewrite of rmlint; port needs an update

[Stefan Esser]

Am 22.12.2014 um 16:39 schrieb christop...@ira-kunststoffe.de:
> Hello,
> 
> Im the author of rmlint, a tool to remove several types of waste from
> your filesystem.
> It is especially good for finding duplicate files and directories.
> I (and a co-developer) rewrote rmlint (version now is 2.0.0) and merged
> it into the master
> branch a few days ago. The new version has many improvements concerning
> speed and accuracy (and also somewhat better code quality :).
> I briefly tested it on a friend's FreeBSD box and it compiles and runs
> just fine - although some optimizations were disabled.
> 
> The biggest difference concerning compilation: It uses scons now.
> Also a note: the master branch is considered to be stable, all dangerous
> action happens in the develop branch now. Proper releases will be made
> too after gathering a small amount of patches.
> You can find the documentation here: http://rmlint.rtfd.org Code can be
> found in the usual place: https://github.com/sahib/rmlint
> I wrote a little bit more about the changes here:
> https://bbs.archlinux.org/viewtopic.php?id=191247
> 
> The last package was done by Jesse Smith (jessefrgsm...@yahoo.ca), but
> he told me would like to give it to someone else due to time constraints.
> 
> So... anyone up for it? :)

Seems that an rmlint port had been submitted as a PR, but was closed
because of deficiencies in the port and submitter timeout when trying
to resolve these issues.

But this old rmlint port is no good starting point, anyway, since it
violates many style requirements.

I have started to work on a new rmlint port and intend to finish it
when I'm back from a 2 week vacation ...

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

[FIXED] Re: portmaster --check-port-dbdir is broken for me

[Stefan Esser]

Am 21.07.2016 um 15:18 schrieb Walter Schwarzenfeld:
> Thorsten, after the remove of the  patch portmaster find the right files
> which are not installed, and nothing other.
> It seems is was the patch.

Sorry if my patch broke some of portmaster's functionality.

I had tested the behaviour of the loop with and without the patch
(you can repeat my test by adding "set -x" after the line reading

echo "===>>> Building list of installed port names";  echo ''

and "set +x" before

echo "===>>> Checking $port_dbdir"

The trace output is identical (except for the variable assignment
in all_pkgs_by_origin() for the patched file) and $unique_list is
identical throughout the loop.

BUT in case of the patched version, $unique_list is created in the
second process in the pipe, and lost when that process terminates.

This should be fixed in SVN rev. 419005.

Thanks for reporting and sorry for the incompete testing that I
had done for the initial patch.

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

Re: Wine & PlayOnBSD

[Stefan Esser]

Am 05.01.2017 um 22:29 schrieb abi:
> 
> On 05.01.2017 22:12, Grzegorz Junka wrote:
>>
>> On 01/01/2017 17:28, abi wrote:
>>>
>>> On 01.01.2017 18:28, Grzegorz Junka wrote:
 I am using FreeBSD 10.3 x64. I understand that to run Windows
 applications on that configuration I can use only one of the following:

 1. playonbsd-4.2.10_1
 2. wine-staging-2.0.r3_1,1
 3. i386-wine-staging-2.0.r3_1,1
 4. wine-devel-2.0.r3_1,1
 5. i386-wine-devel-2.0.r3_1,1
 6. wine-1.8.6,1
 7. i386-wine-1.8.6,1

 Currently I have installed playonbsd, which is good but it seems
 that not all applications I would like to install can be installed
 on it.

 Which one of those options would give me the most compatibility with
 office-type and multimedia applications (e.g. DVD player, SoftPhone,
 applications that access USB), not necessarily games?

 Should I prefer some of these ports over others for my x64 system?

 When switching from one port to another (e.g. wine to playonbsd) can
 I keep the currently installed Windows applications or I would need
 to reinstall any of the applications/libraries installed on the
 previous version?

 It seems that front-end ports (q4wine, swine) default to 4. from the
 list (wine-devel-2.0.r3_1,1). Is there any reason for that? Can they
 run without problems on a x64 system?

 Many thanks for any insights.
>>>
>>> Probably you need i386-wine-devel and emulators/winetricks
>>> playonbsd is a wrapper for wine. No need to use it at all, just get
>>> installer for you program, create new wineprefix and install software
>>> into it
>>>
>>> Personally, I make 1 wineprefix for 1 program (or program group ) with
>>> env WINEPREFIX=$HOME/.local/share/wineprefixes/ck2 wineboot
>>> sandbox it with winetricks if needed
>>> copy installer into $HOME/.local/share/wineprefixes/ck2/drive_c/Distr
>>> env WINEPREFIX=$HOME/.local/share/wineprefixes/ck2 wine cmd
>>> navigate to Distr and run installer
>>>
>>> ck2 is example prefix for crusader kings II. I love Paradox games :P
>>>
>>
>> Thank you for the tips. Any reason why I shouldn't be using the x64
>> versions? And also, wasn't playonbsd designed to give a greater
>> compatibility with Windows applications? What benefit is it to use
>> playonbsd over normal wine with winetricks then? I mean, why is it in
>> ports?
> 
> x64 version lacks WoW subsystem, so it can't execute 32-bit programs at
> all. playonbsd can't give greater compatibility as it's wrapper for
> wine. It can set compatibility options or install common software,
> however you can find your program in wine database and look for recipes
> yourself. I doubt playonbsd tracks wine precisely, wine changes too
> fast, so probably not all recipes are up to date and it's not very
> complex to do all steps manually after all. Why it's in port is a
> rhetoric question, ports are user driven. Maybe someone like it or maybe
> maintainer is a developer. I dunno, but ability to choose is always for
> good.

Thank you for your replies to Grzegorz - I have some minor points to
add.

PlayOnLinux had hooks for FreeBSD, which never worked. The port fixes
assumptions that don't apply to FreeBSD, but it diverges somewhat from
the way, PlayOnLinux behaves. But the port versions is working, AFAIK.

PlayOnLinux assumes, that any Wine version configured into the install
script of some supported Windows application package can be fetched and
installed in the user's home directory. This is not how FreeBSD packages
are installed - in fact, FreeBSD does not support the installation of
multiple Wine versions side by side, but assumes, that there are no
critical recessions and always uses the latest (stable or devel) Wine
as found in the corresponding ports.

Therefore, some of the further settings per Windows package may be too
conservative, since they apply only to the old WIne version that was
used when the PlayOnLinux install script for that package was created.
(If the old Wine version required use of a native Windows DLL instead
of one provided by Wine, this may have long been fixed in the current
Wine version, used on FreeBSD.)

You can consider PlayOnBSD as a tool that allows to install Windows
packages with settings tested by the PlayOnLinux community, without the
user being aware of such a requirement to start Wine with specific
options.

So, yes, winetricks will allow to acchieve similar results to PlayOnBSD,
but may need more experience to use it.

I've tested the installation of several Windows applications (e.g.
MS-Office 2010, mp3tag, some simple games) and they worked without any
manual tweaking.

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

Re: Wine & PlayOnBSD

[Stefan Esser]

Am 09.01.2017 um 21:20 schrieb Grzegorz Junka:
> Thank you for the additional information. The PlayOnLinux documentation
> mentions some dedicated application to actually install or run the
> Windows apps from some UI. Is this supported in PlayOnBSD?

Yes, there is an UI that allows to modify settings (e.g. whether to use
some native DLL) for supported Windows applications.

You can also create Desktop Icons that let you directly start Wine with
the covered Windows applications.

Somebody reported, that these icons were not correctly created. I have
tried to implement a fix, but I'm not sure that it works (do not use KDE
or any other XDG compatible WM). If you give PlayOnBSD a try and find,
that these icons do not work, than I'll take another look at the script
that creates these icons and puts the required path and options into
the parameters for that icon.

> Also, is there any reason why PlayOnBSD depends on a 64-bit version of
> wine? I would have thought that 32-bit version could give a better
> compatibility?

See this comment for "${ARCH} == amd64" in emulators/wine/Makefile:

% # Wine is composed of three parts:
% #  - wine (aka this port) is the 32-bit component and runs 32-bit
programs (on FreeBSD/i386)
% #  - wine64 (aka this part of this port) is the 64-bit component and
runs 64-bit programs
% #(on FreeBSD/amd64)
% #  - wow64 (a subset of emulators/i386-wine-devel) is a part of the
64-bit component that runs
% #32-bit programs (on FreeBSD/amd64)
% # We also currently have:
% #  - "wine32" (aka emulators/i386-wine-devel) is the 32-bit component
and runs 32-bit programs
% #(on FreeBSD/amd64).  This will be superseded by wow64.

I do not have any i386 systems (except for poudriere jails used to build
and test new/modified ports), but IMHO i386-wine is compiled for a real
i386 as "host" and runs 32 bit Windows programs only (for lack of 64
bit support in the host processor).

I have tested a number of 32 bit Windows applications with the 64 bit
version of Wine (i.e. built for amd64), and they worked as expected.

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

Re: Unable to upgrade from Samba43 to Samba44 or Samba45

[Stefan Esser]

Am 08.06.17 um 21:15 schrieb Dimitry Andric:
> On 8 Jun 2017, at 20:35, Mark Knight  wrote:
>>
>> On 08/06/2017 18:35, Dimitry Andric wrote:
>>> I'm guessing that it is confused by an existing samba installation.  Try
>>> removing all other samba installations before attempting to build this
>>> port.
>>
>> Having followed an off-list suggestion to create a package (thanks) as a 
>> backup, I removed samba43 and established that your "guess" was right. Thank 
>> you!
>>
>> Presumably this implies a bug in the port?
> 
> Not really, more a deficiency in portmaster.  The port itself is marked
> as conflicting with any other samba port:
> 
> CONFLICTS?= *samba3[2-6]-3.* samba4-4.0.* samba4[1-356]-4.* 
> p5-Parse-Pidl-4.*
> 
> E.g., you should normally not be able to build it when samba43 is
> installed.  Probably, portmaster is overriding this safety belt somehow.

I have always understood CONFLICTS to indicate, that some port
can not be *installed* at the same time as some of the ports listed
as conflicting.

Building such a port while a conflicting version is installed, is
possible most of the time. If such a build fails, it is most ofter
due to the build preferring the already installed headers over those
provided with the new version (i.e. a wrong ordering of include
paths).

Since port developers typically test ports in poudriere (to get a
clean build environment and e,g, to be sure, all dependencies are
correctly specified), they often don't notice such conflicts with
already installed versions of the same port.

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

Re: Update failure E000022 after upgrade to subversion 1.9.6

[Stefan Esser]

Am 12.07.17 um 07:42 schrieb Rainer Hurling:
> Hi duglas@
> 
> I had the same problem. I completely solved it by rebuilding the
> dependency chain of devel/subversion:
> 
> portmaster serf-1.3.9_1 expat-2.2.1 gettext-runtime-0.19.8.1_1
> apr-1.5.2.1.5.4_2 sqlite3-3.19.3_1 subversion-1.9.6
> 
> Probably, only one of them is the culprit, but I haven't testet ;)

I have, and it appears to have been devel/apr1 ...

After rebuilding first apr and then subversion, the problem is resolved
on my system.

The cause seems to have been the ino64 change, which is visible from the
userland. Library versioning should take care of that, but that does not
work, if subversion wants the new version and apr needs the old one ...

Other ports could be affected as well, if they link against a library
that needs an old version of a C library function, while the binary was
built for the new call signature.

As long as ports are built with or without the ino64 change, they should
continue to work (and thus, -STABLE packages are not affected).

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

Re: make install for print/texinfo fails on -CURRENT

[Stefan Esser]

Am 12.07.17 um 18:11 schrieb David Naylor:
> On Tuesday, 11 July 2017 08:47:17 Bob Willcox wrote:
>> Hmm, I just tried running synth on my test system again (this is the system
>> that I successfully built and install texinfo on just a bit ago) and synth
>> still fails with the same build errors as before. I'm not all that familiar
>> with synth, but it appears that it may be working with some old stuff.
> 
> Hi
> 
> (Replying to a random email)
> 
> I've encountered the exact same issue while building the i386 packages for 
> wine.  Once I forced a rebuild of _all_ texinfo dependencies, installation 
> worked.  
> 
> I suspect an ABI change in -CURRENT that broke a dependency (sounds like perl 
> based on the thread).  

I had a problem with subversion after the upgrade to 1.9.6, and this
was due to an incompatibility with the apr library, which had not been
rebuilt for some time.

Seems that this is fall-out from the ino64 changes. Seems that while
symbol versioning allows old libraries to access struct stat as it was
before the change, this struct stat passed to a freshly built binary
(or library) by reference will cause obvious failures.


So, if you compile any port after the ino64 change, better make sure
that all referenced libraries (that operate on struct stat and might
pass such a struct to a fresh binary) have been rebuilt before.

As long as binary packages are built on a pre-ino64 machine, the
resulting packages ought to work on any -CURRENT system. But if you
build any port that references a library installed by such a package,
you risk mixing different versions of struct stat. This will continue
to be a problem as long as the -CURRENT package builders are pre-ino64.

If the package builders are upgraded to support ino64, all ports that
call stat() (or other functions with call signature affected by ino64)
should have PORTREVISION bumped, as should all ports depending on them.

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

Re: Porters Handbook section 4.4

[Stefan Esser]

Am 26.09.17 um 08:21 schrieb Kubilay Kocak:
> In section:
> 
> 4.4. Patching
> 
> - Add new section (at/numbered 4.4.2)
>   - Name: Automatic Patch Generation
> - Renumber sections (4.4.2 -> 4.4.3)
> 
> Text:
> 
> The ports framework provides a {{{makepatch}} target, which when run,
> automatically creates correctly named and formatted patch files in the
> correct location. The general process is as follows:
> 
> % cd 
> % make patch
> 
> Note: In the general case, {{{make patch}} is used (not just {{{make
> extract}}} to extract the DISTFILES), because ports that contain
> existing patches need to have the patches applied so that they are also
> generated (regenerated) in the last step.
> 
> ```
> % cd work/ (WRKSRC)
> ```
> 
> At this point, make the source changes in WRKSRC:
> 
> ```
> % cp  .orig

Do not perform this copy operation, IF the .orig file does already exist
(from the earlier "make patch" step).

I'd also use "cp -p" to preserve the original modification time, which
will be included in the patch ...

Else, your change will be against a patched file, without the patch that
lead to this state being conserved.

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

Re: [HEADUP] FLAVORS landing.

[Stefan Esser]

Am 27.09.17 um 13:52 schrieb Julian Elischer:
> On 27/9/17 4:20 pm, Matthew Seaman wrote:
> 
> Before this gets too far down the road I would like to suggest that we
> quickly formalise some nomenclature
> or we will have 200 different ideas as to how to do the same thing;
> 
> I would like to propose the following possible "examples of official"
> flavours:
> -nodocs ..  nearly every port has a DOCS option..  a way to
> automatically turn it off globally and generate said pkgs would be good.
> -minimal ..  smallest possible feature set.. probably used just to
> satisfy some stupid dependency.
> -kitchensink    ..  speaks for itself .. options lit up like a christmas
> tree
> -runtime    ..  no .a files, include files, development
> documentation or sources ..
>     might only contain a single libxx.so.N file, or a
> single binary executable.

No, these are no good examples for flavours, as I understand them ...

These are possible typical sub-package categories, or rather you could
remove the DOCS from the base port, but offer a sub-package for them.


I'd rather think that NO-X11 might become a typical flavour, or the
dependency on a particular crypto library (e.g. openssl vs. libressl).


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

Re: [HEADUP] FLAVORS landing.

[Stefan Esser]

Am 26.09.17 um 16:05 schrieb Mathieu Arnold:
> Hi,
> 
> **Do not commit FLAVORS to any ports, a hook will prevent it, that being
> said, do try it and test what can be done.**
> 
> To test this feature in poudriere, you need
> poudriere-devel-3.1.99.20170621 or later.
> 
> This has been a long awaiting feature, most of the work has been done by
> bapt, bdrewery and antoine, I am just the one actually doing the
> announce and commit and all.
> 
> All this information, and more to come are in the first link to our wiki
> in the bottom block. A roadmap is in the second link.
> 
> To define a different flavors in a port, before any include, set:
> 
> FLAVORS=  flavor1 flavor2 [...]
> 
> The first flavor in the list will be the default.

One question regarding the naming of packages:

The default flavour should probably(?) lead to a package with the same
name as created without flavours.

But any non-default flavour needs a distinct package name.

In the case of the Python ports, this will be the version prefix (py27-
vs. py36-).

But what is planned for the general case?

Will it be left to the port maintainer to add prefixes / postfixes to
package names that reflect the flavours by means of the options that
are enabled by some particular flavour?

Or will the flavour be automatically added to the package name, if
there would be name collisions, otherwise?

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

Re: [HEADUP] FLAVORS landing.

[Stefan Esser]

Am 27.09.17 um 22:57 schrieb Don Lewis:
> If at some point you run into a bug and need the debug files, you can
> pkg install the debug files for whatever packages that you need without
> disturbing your already installed runtime files, and then you can later
> deinstall the debug files when you are done with them without needing to
> reinstall the runtime files.  The same thing applies to docs.

This assumes, that a matching version of the debug files is still
available. Otherwise, you had to first install the latest version
of the package and to reproduce the situation with that version.

This may be seen as a feature (bug reports only for the version
currently in ports), but may be impractical in many cases.

The matching of versions of base package and sub-packages must be
more strict than by version number, since trivial changes might be
applied to a port without incrementing the PORTREVISION, but with
impact on the binary, e.g. if the port is to built with some gcc
version from ports and that gcc port has been updated, leading to
different object files and debug symbols than a previous version
of the port with identical version number.

A "build number" could be added to each (sub-)package and only if
this build number matches, a sub-package may be installed on top
of an already installed base package. The build time/date could of
course be used instead, if an identical value is used for all the
corresponding files.

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

Re: New pkg audit FNs

[Stefan Esser]

Am 10.10.17 um 00:03 schrieb Steve Wills:
> Hi,
> 
> On 10/09/2017 17:55, Jan Beich wrote:
>> Why not
>> teach pkg-audit(8) to query NVD based on CPE annotations in *binary*
>> packages?
>> Doing so would also provide a workaround for VuXML entries cancelled
>> to reduce bloat.
> 
> I agree, pkg-audit needs to be taught to do that. Along those lines, we
> could create a port for cvechecker:
> 
> https://github.com/sjvermeu/cvechecker

I have a mostly working port of cvechecker, which I plan to commit
soonish.

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

new port security/cvechecker

[Stefan Esser]

Am 13.10.17 um 09:25 schrieb Torsten Zuehlsdorff:
> Aloha,
> 
>>> Why not
>>> teach pkg-audit(8) to query NVD based on CPE annotations in *binary*
>>> packages?
>>> Doing so would also provide a workaround for VuXML entries cancelled
>>> to reduce bloat.
>>
>> I agree, pkg-audit needs to be taught to do that. Along those lines,
>> we could create a port for cvechecker:
>>
>> https://github.com/sjvermeu/cvechecker
>>
>> But both solutions only handle installed packages.
>>
>> We would still need something to alert us to CVEs in non-installed
>> software, I think.
>>
>> Also, I've just looked and it seems only a little over 1000 ports have
>> CPE strings. Adding something to portlint that warned ports developers
>> to add any needed CPE info would be helpful. I think that type of
>> warning has helped us improve LICENSE entries.
> 
> One more thought on this topic: a cvececker isn't enough. Looking at
> security updates of piwik, gitlab, phpmailer and many more: most of the
> security issues fixed never got an CVE entry. But of course any of the
> issues could be exploited in one or another way.
> 
> But i think cvechecker is a step in the right direction. pkg audit is
> incredible helpful even with its current restrictions!

Well, and now cvechecker is in ports :)

Please let me know about any problems with the port.

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

Re: Firefox became much slower

[Stefan Esser]

Am 01.11.17 um 12:40 schrieb Guido Falsi:
> On 11/01/2017 12:15, Baho Utot wrote:
>>
>>
>> On 11/01/17 02:07, Gleb Popov wrote:
>>> Hello.
>>>
>>> I'm using Firefox on quite ancient machine (amd64, though) and after
>>> updating from firefox-56.0.1_3 to 56.0.2_3,1 it has become much more
>>> sluggish - whole UI hangs during page loading, scrolling isn't smooth
>>> anymore.
>>>
>>> Anyone also see this?
>>> ___
>>
>>
>> Yep FF is starting to get on my nerves.  Javascript brings it to it's knees
> 
> Most sites make an unreasonable use of javascript though. The recent
> news about sites and CDNs leveraging javascript to mine bitcoins make
> things even worse.
> 
> My personal suggestion is to use noscript, most sites work quite fine
> without javascript and even more sites work fine by allowing only a few
> origins, but blocking dozens of third party scripts.

I used to use NoScript, but have switched to uMatrix, meanwhile.

uMatrix has lots of pre-configured rules (blocks trackers and known
malware sites), but I'm using it in conjunction with uBlock from the
same developers.

Both are available as "new-style" web-extensions and will continue
to work with Firefox 57.

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