Re: Changing daemon user, dir ownership and updating packages
Am 13.04.2021 um 10:24 schrieb Stefan Bethke : > > As the maintainer, I've received this bug report: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255009 > > If you'd like to run the daemon under a user different from the default git, > you also need to change the ownership of the working directories, especially > /var/*/gitea. > > The expectation is that upgrading the package will not change the ownership > of already existing directories. When installing a newer version of the > package, pkg appears to reset the ownership to those specified in the package. > > The pkg-plist has this: > @owner git > @group git > @dir /var/db/gitea > @dir /var/log/gitea > @dir /var/run/gitea > > I believe this to be best practice. Is there a better way to have pkg create > these dirs if they're missing, but not touch them if they are there already? Adam has suggested a couple of approaches, but what I would really like is a common, documented way for ports to handle this situation. Updating ownership and mode of entries in the rc script automatically feels wrong to me, especially if it's a custom one-off for a single port. Kinda creating a POLA violation. I think as a general approach, checking that directories and files that the port knows will need to be writable for compatible access rights might be the safe choice. But that still leaves pkg updating the ownership/mode of existing directories as a surprise on updating a package. I think the "right" thing here would be a kind of three-way merge between changes an updated package brings in vs. changes the user has made on their system. That sound complicated to get right. Stefan -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP
Changing daemon user, dir ownership and updating packages
As the maintainer, I've received this bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255009 If you'd like to run the daemon under a user different from the default git, you also need to change the ownership of the working directories, especially /var/*/gitea. The expectation is that upgrading the package will not change the ownership of already existing directories. When installing a newer version of the package, pkg appears to reset the ownership to those specified in the package. The pkg-plist has this: @owner git @group git @dir /var/db/gitea @dir /var/log/gitea @dir /var/run/gitea I believe this to be best practice. Is there a better way to have pkg create these dirs if they're missing, but not touch them if they are there already? Stefan -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP
Gitea 1.13.0 port update
Hi there, I've just opened a PR to bring the Gitea port up to 1.13.0. This Gitea release contains many changes, some of them breaking. In my limited testing, it looks fine, but it probably won't hurt to give it a little bit more exposure before it hits the package repo. So if you're using Gitea, I would appreciate feedback on building and running Gitea from the patch included in this PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251577 Feel free to report any findings in that PR as well. Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-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: gitea-1.11.2
Am 10.03.2020 um 09:51 schrieb Felix W. Dekker : > > To whomever it may concern, > > Yesterday, I updated gitea on my FreeBSD server. I updated using pkg. > While `pkg info gitea` claims that the installed version is 1.11.2, the > command `gitea -v` claims that I'm running 1.9.0-dev. At the same time, > my instance does have the new features that have been released in 1.11.2. > > Is this an error in the distributed package or is there something I did > wrong on my end? The way the binary gets its version number embedded has changed. I probably screwed that up with the update to the port. Let me take a lokk later tonight. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244710 Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Downloading source archive from GitHub release instead of repo tar
I'm working on updating the Gitea port to 1.11, and I need to download the source archive off the release page, instead of an archive of the Github repo. The source archive on the release page contains additional files that are needed for the build (Go and node modules that would need to be downloaded during the build otherwise). PORTNAME= gitea DISTVERSIONPREFIX= v DISTVERSION=1.11.2 USE_GITHUB= yes How do I tell make that I do want to download the release tar.gz instead of the repo archive? Specifically, I need to download https://github.com/go-gitea/gitea/releases/download/v1.11.2/gitea-src-1.11.2.tar.gz instead of https://codeload.github.com/go-gitea/gitea/tar.gz/v1.11.2?dummy=/go-gitea-gitea-v1.11.2_GH0.tar.gz Stefan -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP
Re: Pkg repository is broken...
Am 07.03.2020 um 08:50 schrieb sth...@nethelp.no: > > I think a lot of people are waiting for some kind of guidance on how > to fix these problems, if the repos are supposed to be okay now. It would be really great if someone in the know would send something to -announce or similar, with an ETR. Maybe even with suggestions for workarounds. A forum thread mentions a workaround for those that cannot easily start compiling their own ports: https://forums.freebsd.org/threads/pkg-wrong-architecture-freebsd-12-0-amd64-instead-of-freebsd-12-amd64.74310/page-3 > ALTABI thing must be added in /usr/local/etc/pkg.conf: ALTABI = > "FreeBSD:12.0:amd64" Stefan -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP
Re: Debugging build with gmake, running npm toolchain
> Am 13.02.2020 um 14:42 schrieb Marcin Cieslak : > > On Wed, 12 Feb 2020, Stefan Bethke wrote: > >> The second issue is that npm install is invoked, which will most likely >> prevent the port to be built as a package. Is there a way to handle the >> download of the package-lock.json dependencies in the fetch stage? > > I have some hack in my private node-sass port: > https://github.com/saper/ports-exp/tree/master/textproc/node-sass > > jrm@ has solved this in the late net-im/mastodon port by simply putting all > JavaScript together > in one tarball: > https://svnweb.freebsd.org/ports/head/net-im/mastodon/?pathrev=472547 > > https://ftfl.ca/blog/2017-05-23-mastodon-freebsd.html > > The port got removed in > https://svnweb.freebsd.org/ports?view=revision&revision=474751 > <https://svnweb.freebsd.org/ports?view=revision&revision=474751> Thanks for the pointers! I'm currently trying to convince upstream to package the dependencies as vendor-like archives (for both Go modules and npms) and deploy them alongside the source release archive. That would allow me to treat these as additional distfiles, and simply unpack them into $WRKSRC. I'm hoping that this would make the maintenance of the port halfway reasonable. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Debugging build with gmake, running npm toolchain
I maintain www/gitea, and with the newest release, the build has been changed from a mostly pure Go build to a more complex setup using gmake, and including some npm-based toolchain to build CSS and JS. Right now, changing the port from USES=go:modules to USES=gmake runs into a compilation/linking error: flag provided but not defined: -fstack-protector-strong usage: link [options] main.o -B note add an ELF NT_GNU_BUILD_ID note when using ELF -E entry set entry symbol name The flag -fstack-protector-strong is not part of the Gitea code, but seems to come from the ports system. I'm having a hard time finding a build switch that prints the gmake command that is actually invoked, and information on how to customize that. The second issue is that npm install is invoked, which will most likely prevent the port to be built as a package. Is there a way to handle the download of the package-lock.json dependencies in the fetch stage? Stefan -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP
Re: Is IPV6 option still necessary?
Am 09.10.2019 um 08:15 schrieb Baptiste Daroussin : > > I agree I don't see the reason why we should keep that ipv6 option. When off > this option does not bring much value to the users as the code for apps to > support ipv6 mostly reside in the libc. Actually that was my intent in 2012 to > first turn it on by default everywhere and then drop the option entirely. Is there an easy way to tell which ports pay attention to the option? Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Gitea update to 1.8 breaking config change
For those of you using Gitea a quick heads-up: In Gitea 1.8.0, a new config variable JWT_SECRET has been introduced. If not set in gitea/conf/app.ini, Gitea will try and add it to the file; in the default setup of the port, the file is not writable by the git user, and Gitea will not start because of that. To get Gitea going again, either add that variable (see gitea/conf/app.ini.sample), or make app.ini writable to the git user so Gitea can add a suitable value for you. Do not use the value in the sample configuration! I’ve just submitted the PR for the update to 1.8.0, so the updated port should become available in the next couple of days. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-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: PHP 7.2: SIGSEGV in OpenSSL
> Am 24.04.2019 um 22:50 schrieb Mathieu Arnold : > > On Wed, Apr 24, 2019 at 06:34:06PM +0200, Stefan Bethke wrote: >>> Am 23.04.2019 um 18:01 schrieb Kurt Jaeger : >>> >>> Hi! >>> >>>> Did you find a solution? Please let me know. >>> >>> There's a well-known problem in the sequence in which php modules >>> are loaded. I don't know if this is the case here as well, >>> but that's what we do: >>> >>> fetch -o fixphpextorder \ >>> https://people.freebsd.org/~ohauer/scripts/fixphpextorder.sh >>> chmod 755 fixphpextorder >>> >>> cd /usr/local/etc/php >>> cat ext-*ini > extensions.ini >>> fixphpextorder >>> mv extensions.ini.new extensions.ini >>> rm ext-*ini >>> >>> Please test and report if it fixes the problem. >> >> Thanks Kurt, it appears to fix (or at least work around) the problem. >> >> Why is the default load order broken? Why does it not affect everyone? >> >> I moved all the individual inis into a bak subdir, and now only have an >> extensions.ini. >> >> If I understand correctly, mod_php/PHP reads the individual inis in order. >> Why aren’t they in the right order? Can this be fixed in the ports for the >> PHP modules? > > Could you give the order that works for you, so that we can try to > figure out which module is making it break ? > > Because there is no "right" order, there is an order that can work for > most people, and from time to time, two libs have conflicting symbols, > but it is not possible to detect that. So I made up an order that > should be ok, but some time is not. This is the order I’m actively using now: $ cat extensions.ini extension=session.so extension=fileinfo.so extension=ldap.so extension=simplexml.so extension=ctype.so extension=mbstring.so extension=tokenizer.so extension=filter.so extension=pgsql.so extension=mcrypt.so extension=gd.so extension=gettext.so extension=iconv.so extension=zlib.so extension=curl.so extension=xmlrpc.so extension=bz2.so extension=openssl.so extension=dom.so extension=hash.so extension=wddx.so extension=memcache.so extension=soap.so extension=pdo.so extension=pdo_mysql.so extension=mysqli.so extension=sockets.so extension=xml.so ; additional extension(s) not known by fixphpextorder.sh extension=intl.so extension=json.so extension=sqlite3.so extension=zip.so extension=memcached.so extension=pdo_pgsql.so extension=phar.so This is the order as installed by the ports (at least I think that’s the order PHP will read the files): $ cat $(echo bak/*.ini|sort) zend_extension=opcache.so extension=session.so extension=bz2.so extension=ctype.so extension=curl.so extension=dom.so extension=fileinfo.so extension=filter.so extension=gd.so extension=gettext.so extension=hash.so extension=iconv.so extension=intl.so extension=json.so extension=ldap.so extension=mbstring.so extension=mcrypt.so extension=mysqli.so extension=openssl.so extension=pdo.so extension=pgsql.so extension=simplexml.so extension=soap.so extension=sockets.so extension=sqlite3.so extension=tokenizer.so extension=xml.so extension=zip.so extension=zlib.so extension=memcache.so extension=memcached.so extension=pdo_mysql.so extension=pdo_pgsql.so extension=phar.so extension=wddx.so extension=xmlrpc.so This is the contents of bak (the former contents of /usr/local/etc/php): $ ls bak ext-10-opcache.ini ext-20-intl.ini ext-20-sqlite3.ini ext-18-session.ini ext-20-json.ini ext-20-tokenizer.ini ext-20-bz2.ini ext-20-ldap.ini ext-20-xml.ini ext-20-ctype.iniext-20-mbstring.ini ext-20-zip.ini ext-20-curl.ini ext-20-mcrypt.ini ext-20-zlib.ini ext-20-dom.ini ext-20-mysqli.ini ext-30-memcache.ini ext-20-fileinfo.ini ext-20-openssl.ini ext-30-memcached.ini ext-20-filter.ini ext-20-pdo.ini ext-30-pdo_mysql.ini ext-20-gd.ini ext-20-pgsql.iniext-30-pdo_pgsql.ini ext-20-gettext.ini ext-20-simplexml.iniext-30-phar.ini ext-20-hash.ini ext-20-soap.ini ext-30-wddx.ini ext-20-iconv.iniext-20-sockets.ini ext-30-xmlrpc.ini These are the PHP packages I have installed, minus the web apps: $ pkg info -r php72 php72-7.2.17_2: php72-xml-7.2.17_2 php72-hash-7.2.17_2 php72-session-7.2.17_2 php72-openssl-7.2.17_2 php72-xmlrpc-7.2.17_2 php72-mysqli-7.2.17_2 php72-mbstring-7.2.17_2 php72-phar-7.2.17_2 php72-ctype-7.2.17_2 php72-tokenizer-7.2.17_2 php72-json-7.2.17_2 php72-filter-7.2.17_2 php72-gd-7.2.17_2 php72-zlib-7.2.17_2 php72-zip-7.2.17_2 php72-bz2-7.2.17_2 php72-iconv-7.2.17_2
Re: PHP 7.2: SIGSEGV in OpenSSL
> Am 23.04.2019 um 18:01 schrieb Kurt Jaeger : > > Hi! > >> Did you find a solution? Please let me know. > > There's a well-known problem in the sequence in which php modules > are loaded. I don't know if this is the case here as well, > but that's what we do: > > fetch -o fixphpextorder \ >https://people.freebsd.org/~ohauer/scripts/fixphpextorder.sh > chmod 755 fixphpextorder > > cd /usr/local/etc/php > cat ext-*ini > extensions.ini > fixphpextorder > mv extensions.ini.new extensions.ini > rm ext-*ini > > Please test and report if it fixes the problem. Thanks Kurt, it appears to fix (or at least work around) the problem. Why is the default load order broken? Why does it not affect everyone? I moved all the individual inis into a bak subdir, and now only have an extensions.ini. If I understand correctly, mod_php/PHP reads the individual inis in order. Why aren’t they in the right order? Can this be fixed in the ports for the PHP modules? Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-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-mgmt/icingaweb2 fails to build with PHP 7.3
Am 27.01.2019 um 14:45 schrieb Stefan Bethke :
>
> It appears that (older?) versions of icingaweb2 do not work correctly with
> PHP 7.3. From my poudriere build log:
>> ===> Staging for icingaweb2-2.6.2_1
>> ===> Generating temporary packing list
>> /bin/mkdir -p
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/share/examples/icingaweb2/bash_completion.d/
>> install -m 0644
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/icingaweb2-2.6.2/etc/bash_completion.d/icingacli
>>
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/share/examples/icingaweb2/bash_completion.d
>> (cd /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/icingaweb2-2.6.2 && /bin/rm
>> -f -r .mailmap changelog.py icingaweb2.spec bin/license_writer.py packages
>> test)
>> (/usr/bin/find /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/icingaweb2-2.6.2
>> -name "*.bak" -delete)
>> /bin/mkdir -p
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2
>> (cd /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/icingaweb2-2.6.2 && /bin/sh
>> -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&
>> /usr/bin/find -Ed $1 $3 \( -type d -exec /bin/sh -c '\''cd '\''$2'\'' &&
>> chmod 755 "$@"'\'' . {} + -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' &&
>> chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE .
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2)
>> /bin/chmod 755
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2/bin/icingacli
>> install -l rs
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2/bin/icingacli
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/bin/icingacli
>> /bin/mkdir -p
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/etc/icingaweb2
>> /bin/mkdir -p
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/share/examples/icingaweb2/apache
>> (cd
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2
>> && ICINGAWEB_CONFIGDIR=/nonexistent ./bin/icingacli setup config webserver
>> apache --path=/icingaweb2 --root=/usr/local/www/icingaweb2/public
>> --config=/usr/local/etc/icingaweb2
>> --file=/wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/share/examples/icingaweb2/apache/icingaweb2.conf)
>>
>> Fatal error: Uncaught ErrorException: "continue" targeting switch is
>> equivalent to "break". Did you mean to use "continue 2"? in
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2/library/Icinga/Application/Modules/Module.php:689
>> Stack trace:
>> #0
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2/library/Icinga/Application/ClassLoader.php(303):
>> Icinga\Application\ApplicationBootstrap->Icinga\Application\{closure}(2,
>> '"continue" targ...', '/wrkdirs/usr/po...', 689, Array)
>> #1
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2/library/Icinga/Application/ClassLoader.php(303):
>> require()
>> #2 [internal function]:
>> Icinga\Application\ClassLoader->loadClass('Icinga\\Applicat...')
>> #3
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2/library/Icinga/Application/Modules/Manager.php(227):
>> spl_autoload_call('Icinga\\Applicat...')
>> #4
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2/library/Icinga/Application/Application
>> in
>> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2/library/Icinga/Application/Modules/Module.php
>> on line 689
>> *** Error code 255
>>
>> Stop.
>> make: stopped in /usr/ports/net-mgmt/icingaweb2
>
> I’ve also found this Debian issue:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914457
>
> Are you working on a fix? Otherwise, I might give porting the Debian change
> as a local patch.
Here’s some more info.
https://github.com/Icinga/icingaweb2/issues/3656
Looking at the 2.7 release milestone, it might be nice to have the necessary
patches locally in the port.
Stefan
--
Stefan BethkeFon +49 151 14070811
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
net/phpldapadmin: compatibility with PHP 7.3?
Hi, the port is currently marked as IGNORE_WITH_PHP=73. What is missing to support PHP 7.3? I’ve built the port, and it appears to work OK for me. The tree browser seemingly is not able to load further levels, but I can navigate using the main pane, and I can update attributes of existing objects. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-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: The status of docker
It’s bad etiquette to post to more than two lists, let’s take this to freebsd-virtualization@. > Am 19.01.2019 um 15:24 schrieb Grzegorz Junka : > > Hello, does anyone know the current status of docker on FreeBSD? Wiki > https://wiki.freebsd.org/Docker states it's experimental. The last commit in > https://github.com/kvasdopil/docker/tree/freebsd-compat is also from 2015. > > There in fact are two ports, freebsd-docker (from 2015) and docker (18.06). > What's the difference between them and which one should I use to run docker > images on FreeBSD host? > > Has this project been completed and now only needs testing, or has it been > abandoned, or maybe the approach has changed and I am looking in a wrong > place? > > Thanks, > GrzegorzJ > > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
net-mgmt/icingaweb2 fails to build with PHP 7.3
It appears that (older?) versions of icingaweb2 do not work correctly with PHP
7.3. From my poudriere build log:
> ===> Staging for icingaweb2-2.6.2_1
> ===> Generating temporary packing list
> /bin/mkdir -p
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/share/examples/icingaweb2/bash_completion.d/
> install -m 0644
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/icingaweb2-2.6.2/etc/bash_completion.d/icingacli
>
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/share/examples/icingaweb2/bash_completion.d
> (cd /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/icingaweb2-2.6.2 && /bin/rm
> -f -r .mailmap changelog.py icingaweb2.spec bin/license_writer.py packages
> test)
> (/usr/bin/find /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/icingaweb2-2.6.2
> -name "*.bak" -delete)
> /bin/mkdir -p
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2
> (cd /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/icingaweb2-2.6.2 && /bin/sh
> -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&
> /usr/bin/find -Ed $1 $3 \( -type d -exec /bin/sh -c '\''cd '\''$2'\'' &&
> chmod 755 "$@"'\'' . {} + -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' &&
> chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE .
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2)
> /bin/chmod 755
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2/bin/icingacli
> install -l rs
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2/bin/icingacli
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/bin/icingacli
> /bin/mkdir -p
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/etc/icingaweb2
> /bin/mkdir -p
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/share/examples/icingaweb2/apache
> (cd
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2 &&
> ICINGAWEB_CONFIGDIR=/nonexistent ./bin/icingacli setup config webserver
> apache --path=/icingaweb2 --root=/usr/local/www/icingaweb2/public
> --config=/usr/local/etc/icingaweb2
> --file=/wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/share/examples/icingaweb2/apache/icingaweb2.conf)
>
> Fatal error: Uncaught ErrorException: "continue" targeting switch is
> equivalent to "break". Did you mean to use "continue 2"? in
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2/library/Icinga/Application/Modules/Module.php:689
> Stack trace:
> #0
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2/library/Icinga/Application/ClassLoader.php(303):
> Icinga\Application\ApplicationBootstrap->Icinga\Application\{closure}(2,
> '"continue" targ...', '/wrkdirs/usr/po...', 689, Array)
> #1
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2/library/Icinga/Application/ClassLoader.php(303):
> require()
> #2 [internal function]:
> Icinga\Application\ClassLoader->loadClass('Icinga\\Applicat...')
> #3
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2/library/Icinga/Application/Modules/Manager.php(227):
> spl_autoload_call('Icinga\\Applicat...')
> #4
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2/library/Icinga/Application/Application
> in
> /wrkdirs/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/www/icingaweb2/library/Icinga/Application/Modules/Module.php
> on line 689
> *** Error code 255
>
> Stop.
> make: stopped in /usr/ports/net-mgmt/icingaweb2
I’ve also found this Debian issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914457
Are you working on a fix? Otherwise, I might give porting the Debian change as
a local patch.
Stefan
--
Stefan BethkeFon +49 151 14070811
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
PHP 7.2: SIGSEGV in OpenSSL
I'm seeing a lot of coredumps with a stack trace similar to this, on a 12-stable machine: # gdb /usr/local/sbin/httpd /httpd.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `/usr/local/sbin/httpd -DNOHTTPACCEPT'. Program terminated with signal 11, Segmentation fault. ... (gdb) bt #0 openssl_lh_strcasehash (c=0x803466cf2 ) at /freebsd/checkout/src/12/crypto/openssl/crypto/lhash/lhash.c:361 #1 0x00080138564d in obj_name_hash (a=0x7fffe9d0) at /freebsd/checkout/src/12/crypto/openssl/crypto/objects/o_names.c:166 #2 0x00080143be77 in OPENSSL_LH_delete (lh=0x800a27240, data=0x7fffe9d0) at /freebsd/checkout/src/12/crypto/openssl/crypto/lhash/lhash.c:302 #3 0x0008013852c8 in OBJ_NAME_remove ( name=0x803466cf2 , type=1) at obj_lcl.h:12 #4 0x00080143c15a in OPENSSL_LH_doall (lh=0x800a27240, func=0x8013855c0 ) at /freebsd/checkout/src/12/crypto/openssl/crypto/lhash/lhash.c:198 #5 0x000801385558 in OBJ_NAME_cleanup (type=1) at obj_lcl.h:12 #6 0x000801392918 in evp_cleanup_int () at /freebsd/checkout/src/12/crypto/openssl/crypto/evp/names.c:83 #7 0x00080146e39d in OPENSSL_cleanup () at /freebsd/checkout/src/12/crypto/openssl/crypto/init.c:567 #8 0x0008007a24e5 in __cxa_finalize (dso=0x0) at /freebsd/checkout/src/12/lib/libc/stdlib/atexit.c:233 #9 0x0008007320e1 in exit (status=54947058) at /freebsd/checkout/src/12/lib/libc/stdlib/exit.c:62 #10 0x000800a55118 in ?? () #11 0x7fffeb90 in ?? () The one case I could isolate the PHP code is calling stream_socket_enable_crypto(), but I suspect there might be others. Is anybody else seeing this? Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-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 does pkg want to install emby-server?
> Am 19.01.2019 um 01:08 schrieb Dave Cottlehuber : > > On Fri, 18 Jan 2019, at 22:27, Stefan Bethke wrote: >> No matter what package I try to install on my 12-stable machine, pkg >> always adds emby-server. When I check after the install, nothing >> requires emby-server. What’s going on? > > you probably have a further package that is missing the emby-server as a > dependency. > > sudo pkg check -d -v > > should tell you what package that is, either delete it or accept the > corrective action Hhm, the output did not provide any clues. But after running it, pkg install does not want to add emby-server anymore. Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Why does pkg want to install emby-server?
No matter what package I try to install on my 12-stable machine, pkg always adds emby-server. When I check after the install, nothing requires emby-server. What’s going on? $ sudo pkg install php71 Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. The following 2 package(s) will be affected (of 0 checked): New packages to be INSTALLED: php71: 7.1.26 emby-server: 3.5.3.0 Number of packages to be installed: 2 The process will require 75 MiB more space. 3 MiB to be downloaded. Proceed with this action? [y/N]: Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-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: 12-stable, poudriere in jail
No matter what I tried, the python and ruby builds still are failing.
I’ve since changed the setup to a VIMAGE vnet jail, and that appears to be
working properly.
If there is a way to make the „classic“ inherited IPs setup work, I’d love to
learn how.
Stefan
> Am 10.12.2018 um 00:20 schrieb Stefan Bethke :
>
> I’ve made some progress fiddling with common.sh. If I hard-reset $localipargs
> to an empty string, I can run the build successfully. ATM for me,
> $localipargs is set to „ip4.addr=127.0.0.1 ip6.addr=::1“, which breaks the
> jail(8) invocation.
>
> I’ve opened an issue on GH: https://github.com/freebsd/poudriere/issues/657
>
>> Am 09.12.2018 um 21:17 schrieb Stefan Bethke :
>>
>> Since upgrading my machine to 12-stable a couple of days ago, my poudriere
>> jail is having trouble building python and ruby errors like:
>> checking getaddrinfo bug... yes
>> Fatal: You must get working getaddrinfo() function.
>> or you can specify "--disable-ipv6".
>> ===> Script "configure" failed unexpectedly.
>>
>>
>> compiling getaddrinfo.c
>> In file included from getaddrinfo.c:86:
>> ./addrinfo.h:165:12: error: conflicting types for 'getnameinfo'
>> extern int getnameinfo __P((
>> ^
>> /usr/include/netdb.h:251:6: note: previous declaration is here
>> int getnameinfo(const struct sockaddr *, socklen_t, char *,
>> ^
>> getaddrinfo.c:408:7: warning: add explicit braces to avoid dangling else
>> [-Wdangling-else]
>> } else if (strcmp(sp->s_proto, "tcp") == 0) {
>>
>>
>> My jail has a private IP assigned to an Ethernet interface, and a loopback
>> address. In 11-stable, I shared 127.0.0.1 with the host. Since upgrading to
>> 12-stable, I get
>> jail: IPv4 addresses clash
>>
>> If change the loopback IPs on the jail to .2/:2, I then get:
>> [00:00:00] Warning: No loopback address defined, consider setting
>> LOIP6/LOIP4 or assigning a loopback address to the jail.
>>
>> but I get the above build errors. Setting LOIP4/LOIP6 to .2/:2, I’m back at
>> the IPv4 addresses clash error. Setting LOIP4/LOIP6 to 3./:3, I get the
>> warning again, and the build errors.
>>
>> I can build python on the host just fine.
>>
>> I’m getting the build problems with both a 11.2-RELEASE and a 12.0-RC3 based
>> reference jail.
>>
>>
>> The relevant lines from jail.conf:
>> pkg {
>> path = "/jail/pkg.xxx.xxx";
>> host.hostname = „pkg.xxx.xx";
>> ip4.addr += "bridge1|44.128.xx.xx";
>> ip4.addr += "lo0|127.0.0.1";
>> ip6.addr += "lo0|::1";
>> children.max = 40;
>> exec.poststart += "zfs jail $name data/jail/${host.hostname}/poudriere";
>> exec.poststart += "jexec $name zfs mount -a";
>> #exec.prestop += "zfs unjail $name
>> data/jail/${host.hostname}/poudriere";
>> allow.mount;
>> allow.mount.devfs;
>> allow.mount.linprocfs;
>> allow.mount.nullfs;
>> allow.mount.procfs;
>> allow.mount.tmpfs;
>> allow.mount.zfs;
>> allow.socket_af;
>> allow.chflags;
>> enforce_statfs=1;
>> #ip6=inherit;
>> ip4=inherit;
>> }
>>
>>
>> --
>> Stefan BethkeFon +49 151 14070811
>>
>> ___
>> freebsd-ports@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
> --
> Stefan BethkeFon +49 151 14070811
>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
--
Stefan BethkeFon +49 151 14070811
___
freebsd-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: 12-stable, poudriere in jail
I’ve made some progress fiddling with common.sh. If I hard-reset $localipargs
to an empty string, I can run the build successfully. ATM for me, $localipargs
is set to „ip4.addr=127.0.0.1 ip6.addr=::1“, which breaks the jail(8)
invocation.
I’ve opened an issue on GH: https://github.com/freebsd/poudriere/issues/657
> Am 09.12.2018 um 21:17 schrieb Stefan Bethke :
>
> Since upgrading my machine to 12-stable a couple of days ago, my poudriere
> jail is having trouble building python and ruby errors like:
> checking getaddrinfo bug... yes
> Fatal: You must get working getaddrinfo() function.
> or you can specify "--disable-ipv6".
> ===> Script "configure" failed unexpectedly.
>
>
> compiling getaddrinfo.c
> In file included from getaddrinfo.c:86:
> ./addrinfo.h:165:12: error: conflicting types for 'getnameinfo'
> extern int getnameinfo __P((
> ^
> /usr/include/netdb.h:251:6: note: previous declaration is here
> int getnameinfo(const struct sockaddr *, socklen_t, char *,
>^
> getaddrinfo.c:408:7: warning: add explicit braces to avoid dangling else
> [-Wdangling-else]
>} else if (strcmp(sp->s_proto, "tcp") == 0) {
>
>
> My jail has a private IP assigned to an Ethernet interface, and a loopback
> address. In 11-stable, I shared 127.0.0.1 with the host. Since upgrading to
> 12-stable, I get
> jail: IPv4 addresses clash
>
> If change the loopback IPs on the jail to .2/:2, I then get:
> [00:00:00] Warning: No loopback address defined, consider setting LOIP6/LOIP4
> or assigning a loopback address to the jail.
>
> but I get the above build errors. Setting LOIP4/LOIP6 to .2/:2, I’m back at
> the IPv4 addresses clash error. Setting LOIP4/LOIP6 to 3./:3, I get the
> warning again, and the build errors.
>
> I can build python on the host just fine.
>
> I’m getting the build problems with both a 11.2-RELEASE and a 12.0-RC3 based
> reference jail.
>
>
> The relevant lines from jail.conf:
> pkg {
> path = "/jail/pkg.xxx.xxx";
> host.hostname = „pkg.xxx.xx";
> ip4.addr += "bridge1|44.128.xx.xx";
> ip4.addr += "lo0|127.0.0.1";
> ip6.addr += "lo0|::1";
> children.max = 40;
> exec.poststart += "zfs jail $name data/jail/${host.hostname}/poudriere";
> exec.poststart += "jexec $name zfs mount -a";
> #exec.prestop += "zfs unjail $name
> data/jail/${host.hostname}/poudriere";
> allow.mount;
> allow.mount.devfs;
> allow.mount.linprocfs;
> allow.mount.nullfs;
> allow.mount.procfs;
> allow.mount.tmpfs;
> allow.mount.zfs;
> allow.socket_af;
> allow.chflags;
> enforce_statfs=1;
> #ip6=inherit;
> ip4=inherit;
> }
>
>
> --
> Stefan BethkeFon +49 151 14070811
>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
--
Stefan BethkeFon +49 151 14070811
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
12-stable, poudriere in jail
Since upgrading my machine to 12-stable a couple of days ago, my poudriere jail
is having trouble building python and ruby errors like:
checking getaddrinfo bug... yes
Fatal: You must get working getaddrinfo() function.
or you can specify "--disable-ipv6".
===> Script "configure" failed unexpectedly.
compiling getaddrinfo.c
In file included from getaddrinfo.c:86:
./addrinfo.h:165:12: error: conflicting types for 'getnameinfo'
extern int getnameinfo __P((
^
/usr/include/netdb.h:251:6: note: previous declaration is here
int getnameinfo(const struct sockaddr *, socklen_t, char *,
^
getaddrinfo.c:408:7: warning: add explicit braces to avoid dangling else
[-Wdangling-else]
} else if (strcmp(sp->s_proto, "tcp") == 0) {
My jail has a private IP assigned to an Ethernet interface, and a loopback
address. In 11-stable, I shared 127.0.0.1 with the host. Since upgrading to
12-stable, I get
jail: IPv4 addresses clash
If change the loopback IPs on the jail to .2/:2, I then get:
[00:00:00] Warning: No loopback address defined, consider setting LOIP6/LOIP4
or assigning a loopback address to the jail.
but I get the above build errors. Setting LOIP4/LOIP6 to .2/:2, I’m back at the
IPv4 addresses clash error. Setting LOIP4/LOIP6 to 3./:3, I get the warning
again, and the build errors.
I can build python on the host just fine.
I’m getting the build problems with both a 11.2-RELEASE and a 12.0-RC3 based
reference jail.
The relevant lines from jail.conf:
pkg {
path = "/jail/pkg.xxx.xxx";
host.hostname = „pkg.xxx.xx";
ip4.addr += "bridge1|44.128.xx.xx";
ip4.addr += "lo0|127.0.0.1";
ip6.addr += "lo0|::1";
children.max = 40;
exec.poststart += "zfs jail $name data/jail/${host.hostname}/poudriere";
exec.poststart += "jexec $name zfs mount -a";
#exec.prestop += "zfs unjail $name
data/jail/${host.hostname}/poudriere";
allow.mount;
allow.mount.devfs;
allow.mount.linprocfs;
allow.mount.nullfs;
allow.mount.procfs;
allow.mount.tmpfs;
allow.mount.zfs;
allow.socket_af;
allow.chflags;
enforce_statfs=1;
#ip6=inherit;
ip4=inherit;
}
--
Stefan BethkeFon +49 151 14070811
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [Bug 233475] www/gitea: Update to 1.6.0 (Fixes security vulnerability)
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233475 > > Bernhard Froehlich changed: > > What|Removed |Added > > Status|New |Closed > Resolution|--- |FIXED > > --- Comment #4 from Bernhard Froehlich --- > The mentioned security issues do not have any CVE numbers assigned so we > normally do not document those in our vuxml. Since there was no patch for the > port itself to bring it to 1.6.0 I did the update myself and did some light > runtime testing which seemed fine. Thanks! I must have accidentally replaced the gate patch with he vuxml patch. And regarding vuxml: other committers feel quite strongly about adding entries for project-reported vulnerabilities/fixes. I’m happy to do it either way, but it would be great if there was consensus what should be documented that way and what shouldn’t. Cheers, Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Changing PHP default version from 5.6 to 7.2 timeframe?
It appears that there is some work going on to prepare to switch the default PHP version from 5.6 to an actively supported version. What is the approximate timeframe for that change, if any? Should I jump and change the default version for my installs? I'm running the usual suspects like WordPress, MediaWiki, phpMyAdmin. Looking at the supported versions page, I would expect the change be made to 7.2. Is that correct? http://php.net/supported-versions.php Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP
Committer wanted: www/webhook
Hey, I would be grateful if some committer could take a look at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222883 Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP
Re: Upgrading www/gitea to 1.2.0
Am 15.10.2017 um 09:52 schrieb Stefan Bethke : > > If you’r using the Gitea port, the update to 1.2.0 will require you to add a > new INTERNAL_TOKEN key to the security section. See > /usr/local/etc/gitea/conf/app.ini.sample for details. Gitea will not start > until this key is added to the configuration. > > Gitea will try to add this key itself, but will fail if the app.ini file is > not writable by the gitea user, which is the default after installation. Since a couple of people have run into this problem, here’s a bit more info: Gitea has no daemon mode itself, so the port is using daemon(8) to run gitea as a daemon. Also, gitea writes a lot of stuff to stdout while it’s running, even when you have configured logging through app.ini. Up to and including version 1.2.1 of the port, stdout and stderr are thrown away by daemon(8). If gitea fails to start up using the port (i. e. you’re running 'service gitea start‘ and it’s not running afterwards), and there’s no log output in /var/log/gitea, you need to start it in the foreground. You can use this command line: # /usr/bin/env -i 'GITEA_WORK_DIR=/usr/local/share/gitea' 'GITEA_CUSTOM=/usr/local/etc/gitea' 'HOME=/usr/local/git' 'PATH=/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin' 'USER=git' /usr/local/sbin/gitea web (as a single line) This should produce error messages. If the error message says that Gitea cannot write the config file, it is trying to add variables to the config file; the only known instance so far is the new INTERNAL_TOKEN variable. Either allow Gitea to write the config file, or use app.ini.sample as a guide on where to add the INTERNAL_TOKEN variable, and how to produce the token value. I’ve just submitted port version 1.2.2 to Bugzilla (#223283). The rc script there will log Giteas output to syslog. In a default configuration, the output should show up in /var/log/debug.log. HTH, Stefan -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP
Upgrading www/gitea to 1.2.0
If you’r using the Gitea port, the update to 1.2.0 will require you to add a new INTERNAL_TOKEN key to the security section. See /usr/local/etc/gitea/conf/app.ini.sample for details. Gitea will not start until this key is added to the configuration. Gitea will try to add this key itself, but will fail if the app.ini file is not writable by the gitea user, which is the default after installation. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
unable to pkg upgrade: Assertion failed: (strcmp(uid, p->uid) != 0)
# pkg upgrade Updating FreeBSD repository catalogue... FreeBSD repository is up to date. Updating zs64 repository catalogue... zs64 repository is up to date. All repositories are up to date. Checking for upgrades (431 candidates): 100% Processing candidates (431 candidates): 100% Checking integrity...Assertion failed: (strcmp(uid, p->uid) != 0), function pkg_conflicts_check_local_path, file pkg_jobs_conflicts.c, line 386. Child process pid=12379 terminated abnormally: Abort trap # uname -a FreeBSD krokodil.zs64.net 11.1-BETA2 FreeBSD 11.1-BETA2 #5 r320116: Mon Jun 19 19:53:49 UTC 2017 r...@lokschuppen.zs64.net:/usr/obj/freebsd/checkout/src/sys/EISENBOOT amd64 # pkg -v 1.10.1 Any suggestions? Other jails on the same host update fine. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-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 options in make.conf vs. GSSIAPI
> Am 13.01.2017 um 14:12 schrieb Stefan Bethke : > > >> Am 13.01.2017 um 13:30 schrieb Stefan Bethke : >> >> For example, with dns/bind99, without options for that port in make.conf, I >> can run make showconfig and other build commands without issue. As soon as >> I add either of these: >> #OPTIONS_UNSET+= GSSAPI_BASE >> #OPTIONS_SET+=GSSAPI_MIT >> dns_bind99_UNSET+= GSSAPI_BASE >> dns_bind99_SET+=GSSAPI_MIT >> >> running make showconfig produces: >> # make showconfig >> > You must select one and only one option from the GSSAPI single >> *** Error code 1 >> >> Stop. >> make: stopped in /freebsd/checkout/ports/dns/bind99 > > I swear I’ve looked at this for I don’t know how long, but it’s really > trivial: > > Some ports have GSSAPI_BASE as their OPTIONS_DEFAULTS, some have GSSAPI_NONE. > > $ find . -name Makefile | xargs grep 'OPTIONS_DEFAULT=.*GSSAPI_' | sort > ./databases/mariadb101-server/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE > ./dns/bind9-devel/Makefile:OPTIONS_DEFAULT= SSL THREADS SIGCHASE IDN > GSSAPI_NONE JSON > ./dns/bind910/Makefile:OPTIONS_DEFAULT= SSL THREADS SIGCHASE IDN > GSSAPI_NONE JSON \ > ./dns/bind911/Makefile:OPTIONS_DEFAULT= SSL THREADS SIGCHASE IDN > GSSAPI_NONE JSON > ./dns/bind99/Makefile:OPTIONS_DEFAULT=SSL THREADS SIGCHASE IDN > GSSAPI_NONE RRL DLZ_FILESYSTEM \ > ./mail/dovecot2-pigeonhole/Makefile:OPTIONS_DEFAULT=MANAGESIEVE GSSAPI_NONE > ./mail/dovecot2/Makefile:OPTIONS_DEFAULT=KQUEUE GSSAPI_NONE > ./mail/fetchmail/Makefile:OPTIONS_DEFAULT=GSSAPI_BASE > ./net-mgmt/adcli/Makefile:OPTIONS_DEFAULT=GSSAPI_BASE > ./security/cyrus-sasl2-gssapi/Makefile:OPTIONS_DEFAULT= > GSSAPI_BASE > ./security/p5-Authen-Krb5-Simple/Makefile:OPTIONS_DEFAULT=GSSAPI_BASE > ./security/p5-Authen-Krb5/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE > ./security/p5-GSSAPI/Makefile:OPTIONS_DEFAULT=GSSAPI_BASE > ./security/p5-Heimdal-Kadm5/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE > ./security/py-kerberos/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE > ./sysutils/msktutil/Makefile:OPTIONS_DEFAULT=GSSAPI_BASE > ./www/mod_auth_kerb2/Makefile:OPTIONS_DEFAULT=GSSAPI_BASE > > In order to have only a single GSSAPI option selected, OPTIONS_UNSET must > include both: > OPTIONS_UNSET+= GSSAPI_BASE GSSAPI_NONE Here’s a small improvement to bsd.port.mk to print out all the active options for OPTION_SINGLEs and OPTION_RADIOs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216150 Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-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 options in make.conf vs. GSSIAPI
> Am 13.01.2017 um 13:30 schrieb Stefan Bethke : > > For example, with dns/bind99, without options for that port in make.conf, I > can run make showconfig and other build commands without issue. As soon as I > add either of these: > #OPTIONS_UNSET+= GSSAPI_BASE > #OPTIONS_SET+=GSSAPI_MIT > dns_bind99_UNSET+= GSSAPI_BASE > dns_bind99_SET+=GSSAPI_MIT > > running make showconfig produces: > # make showconfig > > You must select one and only one option from the GSSAPI single > *** Error code 1 > > Stop. > make: stopped in /freebsd/checkout/ports/dns/bind99 I swear I’ve looked at this for I don’t know how long, but it’s really trivial: Some ports have GSSAPI_BASE as their OPTIONS_DEFAULTS, some have GSSAPI_NONE. $ find . -name Makefile | xargs grep 'OPTIONS_DEFAULT=.*GSSAPI_' | sort ./databases/mariadb101-server/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE ./dns/bind9-devel/Makefile:OPTIONS_DEFAULT= SSL THREADS SIGCHASE IDN GSSAPI_NONE JSON ./dns/bind910/Makefile:OPTIONS_DEFAULT= SSL THREADS SIGCHASE IDN GSSAPI_NONE JSON \ ./dns/bind911/Makefile:OPTIONS_DEFAULT= SSL THREADS SIGCHASE IDN GSSAPI_NONE JSON ./dns/bind99/Makefile:OPTIONS_DEFAULT= SSL THREADS SIGCHASE IDN GSSAPI_NONE RRL DLZ_FILESYSTEM \ ./mail/dovecot2-pigeonhole/Makefile:OPTIONS_DEFAULT=MANAGESIEVE GSSAPI_NONE ./mail/dovecot2/Makefile:OPTIONS_DEFAULT=KQUEUE GSSAPI_NONE ./mail/fetchmail/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE ./net-mgmt/adcli/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE ./security/cyrus-sasl2-gssapi/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE ./security/p5-Authen-Krb5-Simple/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE ./security/p5-Authen-Krb5/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE ./security/p5-GSSAPI/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE ./security/p5-Heimdal-Kadm5/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE ./security/py-kerberos/Makefile:OPTIONS_DEFAULT=GSSAPI_BASE ./sysutils/msktutil/Makefile:OPTIONS_DEFAULT=GSSAPI_BASE ./www/mod_auth_kerb2/Makefile:OPTIONS_DEFAULT= GSSAPI_BASE In order to have only a single GSSAPI option selected, OPTIONS_UNSET must include both: OPTIONS_UNSET+= GSSAPI_BASE GSSAPI_NONE Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-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 options in make.conf vs. GSSIAPI
> Am 13.01.2017 um 13:36 schrieb Franco Fichtner : > > Hi Stefan, > >> On 13 Jan 2017, at 1:30 PM, Stefan Bethke wrote: >> >> For example, with dns/bind99, without options for that port in make.conf, I >> can run make showconfig and other build commands without issue. As soon as >> I add either of these: >> #OPTIONS_UNSET+= GSSAPI_BASE >> #OPTIONS_SET+=GSSAPI_MIT >> dns_bind99_UNSET+= GSSAPI_BASE >> dns_bind99_SET+=GSSAPI_MIT >> >> running make showconfig produces: >> # make showconfig >> > You must select one and only one option from the GSSAPI single >> *** Error code 1 > > Try to use "=" instead of "+=" for SET/UNSET. > > Here's an example we use in production: > > https://raw.githubusercontent.com/opnsense/tools/master/config/17.1/make.conf Tried that, doesn’t make a difference. -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Ports options in make.conf vs. GSSIAPI
I’m having trouble selecting options for ports through make.conf. For most ports, this works fine. I have set NO_DIALOG=yes so I can run ports commands from scripts and cron without being stuck in a dialog; for those few ports where I do need custom options, I set appropriate _SET and _UNSET options in make.conf, for example: graphics_ImageMagick_SET+= PANGO graphics_ImageMagick_UNSET+=X11 graphics_ImageMagick7_UNSET+= X11 However, if I try to do the same with GSSAPI, ports won’t build unless I do create a config file for that port. For example, with dns/bind99, without options for that port in make.conf, I can run make showconfig and other build commands without issue. As soon as I add either of these: #OPTIONS_UNSET+= GSSAPI_BASE #OPTIONS_SET+=GSSAPI_MIT dns_bind99_UNSET+= GSSAPI_BASE dns_bind99_SET+=GSSAPI_MIT running make showconfig produces: # make showconfig > You must select one and only one option from the GSSAPI single *** Error code 1 Stop. make: stopped in /freebsd/checkout/ports/dns/bind99 If I then run make do-config and simply save the config presented, the port starts working again as expected. This appears to affect any port that uses GSSAPI. I would very much like to be able to build ports without any interaction, and since I’m setting config options through make.conf, I’d also prefer not having to create ports options files, ever. Is there some option I’m missing for GSSAPI? I find the user documentation for GSSAPI not very helpful in this regard. I’ve tried to understand what Mk/Uses/gssapi.mk does, but failed. Stefan p.s. here’s a slightly condensed version of make.conf that I’m using: DISTDIR?= /var/ports/distfiles WRKDIRPREFIX?= /var/ports/work INDEXDIR= /var/ports DISABLE_VULNERABILITIES?= true NO_DIALOG= yes WITH_OPENSSL_PORT= YES DEFAULT_VERSIONS+= bdb=48 DEFAULT_VERSIONS+= perl5=5.20 DEFAULT_VERSIONS+= ssl=openssl OPTIONS_UNSET+= GSSAPI_BASE OPTIONS_SET+=GSSAPI_MIT editors_emacs_UNSET+= MAGICK # … more ports options -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Porting a Go implementation: dealing with dependencies
Am 20.11.2016 um 18:35 schrieb Kurt Jaeger : > > Hi! > >>>>> I'm trying to create a port for Gitea >>>>> (https://github.com/go-gitea/gitea). >> >> Here's my attempt at that port: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214688 > > Committed, thanks! Thank you for the super quick turnaround! -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Porting a Go implementation: dealing with dependencies
Am 20.11.2016 um 02:00 schrieb Stefan Bethke : > Am 18.11.2016 um 17:59 schrieb Steve Wills : >> On 11/18/2016 10:35, Stefan Bethke wrote: >>> I’m trying to create a port for Gitea >>> (https://github.com/go-gitea/gitea). Here’s my attempt at that port: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214688 -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Porting a Go implementation: dealing with dependencies
Am 18.11.2016 um 17:59 schrieb Steve Wills : > > Hi, > > On 11/18/2016 10:35, Stefan Bethke wrote: >> I’m trying to create a port for Gitea >> (https://github.com/go-gitea/gitea). The basics seem easy enough, but >> I’m not sure how to deal with it’s dependencies. > > Use the GH_* macros to fetch them. See: > > https://www.freebsd.org/doc/en/books/porters-handbook/makefile-distfiles.html#makefile-master_sites-github-description > > Or if the upstream vendors their deps like many do these days you can > use the GH_SUBDIR macro to put them in the proper place. > > There are examples to look at if that helps, see sysutils/consul as one > that has vendored deps or sysutils/serf for one that doesn’t. Thanks, it appears that the upstream has properly vendored the modules, and I don’t need to so anything, if I check out the latest commit ref instead of the latest tag. Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Porting a Go implementation: dealing with dependencies
I’m trying to create a port for Gitea (https://github.com/go-gitea/gitea). The
basics seem easy enough, but I’m not sure how to deal with it’s dependencies.
After downloading tag 0.97, I start building with
do-build:
(cd ${GO_WRKSRC} ; ${SETENV} ${GO_ENV} go build)
The result is a long list of unfulfilled dependencies:
$ sudo make
===> License APACHE20 accepted by the user
===> gitea-0.9.97 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by gitea-0.9.97 for building
===> Extracting for gitea-0.9.97
=> SHA256 Checksum OK for go-gitea-gitea-v0.9.97_GH0.tar.gz.
===> Patching for gitea-0.9.97
===> gitea-0.9.97 depends on executable: git - found
===> gitea-0.9.97 depends on file: /usr/local/bin/go - found
===> gitea-0.9.97 depends on executable: gmake - found
===> Configuring for gitea-0.9.97
===> Building for gitea-0.9.97
(cd /var/ports/work/home/vagrant/gitea/work/src/github.com/go-gitea/gitea ;
/usr/bin/env
GOPATH="/var/ports/work/home/vagrant/gitea/work:/usr/local/share/go"
CGO_CFLAGS="-I/usr/local/include" CGO_LDFLAGS="-L/usr/local/lib" GOBIN="" go
build)
cmd/dump.go:16:2: cannot find package "github.com/Unknwon/cae/zip" in any of:
/usr/local/go/src/github.com/Unknwon/cae/zip (from $GOROOT)
/var/ports/work/home/vagrant/gitea/work/src/github.com/Unknwon/cae/zip
(from $GOPATH)
/usr/local/share/go/src/github.com/Unknwon/cae/zip
cmd/serve.go:16:2: cannot find package "github.com/Unknwon/com" in any of:
/usr/local/go/src/github.com/Unknwon/com (from $GOROOT)
/var/ports/work/home/vagrant/gitea/work/src/github.com/Unknwon/com
(from $GOPATH)
/usr/local/share/go/src/github.com/Unknwon/com
…
Very few, if any, are available as ports. I could use go get to download
these, but I think that’s not how it’s supposed to work with a port.
I can build the master branch using the build instructions from the Github
project successfully.
Stefan
--
Stefan BethkeFon +49 151 14070811
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
www/mod_authnz_external24 replacement repo?
I’ve been a long time user of mod_authnz_external. I didn’t pay much attention to the Google Code retirement, so when I tried updating ports today, I was surprised by the IGNORE on the port. I did a little research: mod-auth-external is not archived on Google Code (at least I can’t find it there), so it’s hard to ascertain what the actual code base was the last time it was available. There’s a number of Github repos that have been imported from Google Code; none of them seem to have been created by the original maintainer. That’s not really surprising, since the original maintainer was looking for someone to take over from him a year and a half ago. I think I will try to prepare an update to the port to use https://github.com/phokz/mod-auth-external, since that comes up first in the search, and according to the commit history, has not been changed from the original source (yet). If anyone has a better suggestion, I’d be happy to hear it! Cheers, Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
graphics/ImageMagick vulnerability status?
Hey, according to https://www.imagemagick.org/discourse-server/viewtopic.php?f=4&t=29588, a release 6.9.4-0 should be out that improves the situation significantly. It appears that graphics/ImageMagick is at 6.9.3. It would be nice if people who follow ImageMagick more closely than me could speak to the security status of the current port, updates planned, and/or additional mitigation recommended. Heise News is reporting that exploits have been posted and are seen in the wild. Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Setting PERL_VERSION in make.conf
I’m a bit confused about setting PERL_VERSION in make.conf. It seems that setting it to 5.20.3 will result in Perl-related ports to be built differently than not setting it. Is this expected? How can I make sure I continue to use the version of perl I’ve got currently installed when the default version changes? Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-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 make install for p5 ports
> Am 20.12.2015 um 23:39 schrieb Stefan Bethke : > >> >> Am 20.12.2015 um 21:44 schrieb olli hauer : >> >> On 2015-12-20 21:26, Stefan Bethke wrote: >>> >>>> Am 20.12.2015 um 21:15 schrieb Stefan Bethke : >>>> >>>> For many perl ports, I’m getting errors similar to this: >>>> >>>> ... >>>> Installing >>>> /usr/obj/ports/freebsd/checkout/ports/net/p5-Net-Server/stage/usr/local/lib/perl5/site_perl/man/man1/net-server.1 >>>> ... >>>> Installing >>>> /usr/obj/ports/freebsd/checkout/ports/net/p5-Net-Server/stage/usr/local/bin/net-server >>>> > Compressing man pages (compress-man) >>>> ===> Installing for p5-Net-Server-2.008_1 >>>> ===> Checking if p5-Net-Server already installed >>>> ===> Registering installation for p5-Net-Server-2.008_1 as automatic >>>> pkg-static: Unable to access file >>>> /usr/obj/ports/freebsd/checkout/ports/net/p5-Net-Server/stage/usr/local/share/man/man1/net-server.1.gz: >>>> No such file or directory >>>> *** [fake-pkg] Error code 74 >>>> >>>> Stop in /freebsd/checkout/ports/net/p5-Net-Server. >>>> *** [install] Error code 1 >>>> >>>> Stop in /freebsd/checkout/ports/net/p5-Net-Server. >>>> *** [build-depends] Error code 1 >>>> >>>> Stop in /freebsd/checkout/ports/sysutils/munin-node. >>>> *** [stage] Error code 1 >>>> >>>> Stop in /freebsd/checkout/ports/sysutils/munin-node. >>>> >>>> >>>> I’ve tried upgrading my perl to 5.20, but I’m running into the same issue. >>>> >>>> FreeBSD 9-stable, perl 5.20. >>> >>> After fiddling around with the stage dir, it seems that the port installs >>> man pages for command line utilities into >>> stage/usr/local/lib/perl5/site_perl/man, while pig-static expects them in >>> stage/usr/local/share/man. >> >> Hi Stefan, >> >> no, the man page location looks fine. >> Perl man pages are installed to "/usr/local/lib/perl5/site_perl/man" and >> pkg-plist has the location defined as PERL5_MAN3. > > Please look at the error message above. pig-static expects the man page in > one place, but the port installs in in a different place inside the stage > dir. Only man1 pages seem to be affected, AFAIKT. Here’s how I can „fix“ it manually: > Compressing man pages (compress-man) ===> Installing for p5-DBI-1.634 ===> Checking if p5-DBI already installed ===> Registering installation for p5-DBI-1.634 pkg-static: Unable to access file /var/ports/work/databases/p5-DBI/stage/usr/local/share/man/man1/dbilogstrip.1.gz: No such file or directory pkg-static: Unable to access file /var/ports/work/databases/p5-DBI/stage/usr/local/share/man/man1/dbiprof.1.gz: No such file or directory pkg-static: Unable to access file /var/ports/work/databases/p5-DBI/stage/usr/local/share/man/man1/dbiproxy.1.gz: No such file or directory *** [fake-pkg] Error code 74 Stop in /usr/ports/databases/p5-DBI. *** [install] Error code 1 Stop in /usr/ports/databases/p5-DBI. /usr/ports/databases/p5-DBI# cd /var/ports/work/databases/p5-DBI/stage/usr/local/share /var/ports/work/databases/p5-DBI/stage/usr/local/share# mkdir man /var/ports/work/databases/p5-DBI/stage/usr/local/share# mv ../lib/perl5/site_perl/man/man1 man /var/ports/work/databases/p5-DBI/stage/usr/local/share# cd - /usr/ports/databases/p5-DBI /usr/ports/databases/p5-DBI# make install ===> Skipping 'config' as NO_DIALOG is defined ===> Installing for p5-DBI-1.634 ===> p5-DBI-1.634 depends on file: /usr/local/bin/perl5.20.3 - found ===> Checking if p5-DBI already installed ===> Registering installation for p5-DBI-1.634 [XXX] Installing p5-DBI-1.634... /usr/ports/databases/p5-DBI# -- Stefan BethkeFon +49 151 14070811 ___ freebsd-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 make install for p5 ports
> Am 20.12.2015 um 21:44 schrieb olli hauer :
>
> On 2015-12-20 21:26, Stefan Bethke wrote:
>>
>>> Am 20.12.2015 um 21:15 schrieb Stefan Bethke :
>>>
>>> For many perl ports, I’m getting errors similar to this:
>>>
>>> ...
>>> Installing
>>> /usr/obj/ports/freebsd/checkout/ports/net/p5-Net-Server/stage/usr/local/lib/perl5/site_perl/man/man1/net-server.1
>>> ...
>>> Installing
>>> /usr/obj/ports/freebsd/checkout/ports/net/p5-Net-Server/stage/usr/local/bin/net-server
>>> > Compressing man pages (compress-man)
>>> ===> Installing for p5-Net-Server-2.008_1
>>> ===> Checking if p5-Net-Server already installed
>>> ===> Registering installation for p5-Net-Server-2.008_1 as automatic
>>> pkg-static: Unable to access file
>>> /usr/obj/ports/freebsd/checkout/ports/net/p5-Net-Server/stage/usr/local/share/man/man1/net-server.1.gz:
>>> No such file or directory
>>> *** [fake-pkg] Error code 74
>>>
>>> Stop in /freebsd/checkout/ports/net/p5-Net-Server.
>>> *** [install] Error code 1
>>>
>>> Stop in /freebsd/checkout/ports/net/p5-Net-Server.
>>> *** [build-depends] Error code 1
>>>
>>> Stop in /freebsd/checkout/ports/sysutils/munin-node.
>>> *** [stage] Error code 1
>>>
>>> Stop in /freebsd/checkout/ports/sysutils/munin-node.
>>>
>>>
>>> I’ve tried upgrading my perl to 5.20, but I’m running into the same issue.
>>>
>>> FreeBSD 9-stable, perl 5.20.
>>
>> After fiddling around with the stage dir, it seems that the port installs
>> man pages for command line utilities into
>> stage/usr/local/lib/perl5/site_perl/man, while pig-static expects them in
>> stage/usr/local/share/man.
>
> Hi Stefan,
>
> no, the man page location looks fine.
> Perl man pages are installed to "/usr/local/lib/perl5/site_perl/man" and
> pkg-plist has the location defined as PERL5_MAN3.
Please look at the error message above. pig-static expects the man page in one
place, but the port installs in in a different place inside the stage dir.
Only man1 pages seem to be affected, AFAIKT.
> Is this a local configuration issue on my box? My make.conf has this:
>>
>> WRKDIRPREFIX?= /usr/obj/ports
>> WRKDIR?= ${WRKDIRPREFIX}${.CURDIR:S/${PORTSDIR}//}
>
> Try again without those two definitions, it is possible the overwrite the
> STAGEDIR variable.
> I just build the port without any issues, but without defining this vars.
Can’t do that, /usr/ports is mounted r/o (I’m inside a jail). At any rate,
modifying WRKDIR like that (used to be, should still be) supported.
Stefan
--
Stefan BethkeFon +49 151 14070811
___
freebsd-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 make install for p5 ports
> Am 20.12.2015 um 21:15 schrieb Stefan Bethke :
>
> For many perl ports, I’m getting errors similar to this:
>
> ...
> Installing
> /usr/obj/ports/freebsd/checkout/ports/net/p5-Net-Server/stage/usr/local/lib/perl5/site_perl/man/man1/net-server.1
> ...
> Installing
> /usr/obj/ports/freebsd/checkout/ports/net/p5-Net-Server/stage/usr/local/bin/net-server
> > Compressing man pages (compress-man)
> ===> Installing for p5-Net-Server-2.008_1
> ===> Checking if p5-Net-Server already installed
> ===> Registering installation for p5-Net-Server-2.008_1 as automatic
> pkg-static: Unable to access file
> /usr/obj/ports/freebsd/checkout/ports/net/p5-Net-Server/stage/usr/local/share/man/man1/net-server.1.gz:
> No such file or directory
> *** [fake-pkg] Error code 74
>
> Stop in /freebsd/checkout/ports/net/p5-Net-Server.
> *** [install] Error code 1
>
> Stop in /freebsd/checkout/ports/net/p5-Net-Server.
> *** [build-depends] Error code 1
>
> Stop in /freebsd/checkout/ports/sysutils/munin-node.
> *** [stage] Error code 1
>
> Stop in /freebsd/checkout/ports/sysutils/munin-node.
>
>
> I’ve tried upgrading my perl to 5.20, but I’m running into the same issue.
>
> FreeBSD 9-stable, perl 5.20.
After fiddling around with the stage dir, it seems that the port installs man
pages for command line utilities into stage/usr/local/lib/perl5/site_perl/man,
while pig-static expects them in stage/usr/local/share/man. Is this a local
configuration issue on my box? My make.conf has this:
WRKDIRPREFIX?= /usr/obj/ports
WRKDIR?=${WRKDIRPREFIX}${.CURDIR:S/${PORTSDIR}//}
DISTDIR?= /usr/obj/ports/distfiles
DISABLE_VULNERABILITIES?= true
PACKAGES?= /freebsd/packages
WITH_PKGNG= yes
Stefan
--
Stefan BethkeFon +49 151 14070811
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Unable to make install for p5 ports
For many perl ports, I’m getting errors similar to this: ... Installing /usr/obj/ports/freebsd/checkout/ports/net/p5-Net-Server/stage/usr/local/lib/perl5/site_perl/man/man1/net-server.1 ... Installing /usr/obj/ports/freebsd/checkout/ports/net/p5-Net-Server/stage/usr/local/bin/net-server > Compressing man pages (compress-man) ===> Installing for p5-Net-Server-2.008_1 ===> Checking if p5-Net-Server already installed ===> Registering installation for p5-Net-Server-2.008_1 as automatic pkg-static: Unable to access file /usr/obj/ports/freebsd/checkout/ports/net/p5-Net-Server/stage/usr/local/share/man/man1/net-server.1.gz: No such file or directory *** [fake-pkg] Error code 74 Stop in /freebsd/checkout/ports/net/p5-Net-Server. *** [install] Error code 1 Stop in /freebsd/checkout/ports/net/p5-Net-Server. *** [build-depends] Error code 1 Stop in /freebsd/checkout/ports/sysutils/munin-node. *** [stage] Error code 1 Stop in /freebsd/checkout/ports/sysutils/munin-node. I’ve tried upgrading my perl to 5.20, but I’m running into the same issue. FreeBSD 9-stable, perl 5.20. Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-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: Since r402136, my GraphicsMagic does not support JPEG anymore?
Am 22.11.2015 um 08:01 schrieb Stefan Bethke : > > It seems GraphicsMagic is not built with JPEG support anymore. I’m going to > try and downgrade to the previous revision to see if that restores JPEG > support. > > # /usr/local/bin/gm convert a.jpg b.jpg > /usr/local/bin/gm convert: No decode delegate for this image format (a.jpg). > > > /usr/ports/graphics/GraphicsMagick# grep \$FreeBSD Makefile > # $FreeBSD: head/graphics/GraphicsMagick/Makefile 402136 2015-11-21 06:32:47Z > sunpoet $ Downgrading to 402118 did restore JPEG support for me. I’ve added a bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204740 Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Since r402136, my GraphicsMagic does not support JPEG anymore?
It seems GraphicsMagic is not built with JPEG support anymore. I’m going to try and downgrade to the previous revision to see if that restores JPEG support. # /usr/local/bin/gm convert a.jpg b.jpg /usr/local/bin/gm convert: No decode delegate for this image format (a.jpg). /usr/ports/graphics/GraphicsMagick# grep \$FreeBSD Makefile # $FreeBSD: head/graphics/GraphicsMagick/Makefile 402136 2015-11-21 06:32:47Z sunpoet $ /usr/ports/graphics/GraphicsMagick# make showconfig ===> The following configuration options are available for GraphicsMagick-1.3.23_1,1: DOCS=on: Build and/or install documentation DPS=off: Display Ghostscript support FPX=off: FlashPix image format support OPENMP=on: Parallel processing support via OpenMP Q8BIT=off: Use 8-bit pixels (speed) instead of 16-bit (quality) SSE=off: Use SSE optimized routines TEST=off: Run bundled self-tests after build WEBP=on: WebP image format support WMF=on: Windows Metafile image format support X11=on: X11 (graphics) support XML=on: XML format or parser support ===> Use 'make config' to modify these settings /usr/ports/graphics/GraphicsMagick# gm version GraphicsMagick 1.3.23 2015-11-07 Q16 http://www.GraphicsMagick.org/ Copyright (C) 2002-2015 GraphicsMagick Group. Additional copyrights and licenses apply to this software. See http://www.GraphicsMagick.org/www/Copyright.html for details. Feature Support: Native Thread Safe yes Large Files (> 32 bit) yes Large Memory (> 32 bit) yes BZIP yes DPS no FlashPix no FreeType yes Ghostscript (Library)no JBIG yes JPEG-2000no JPEG no Little CMS no Loadable Modules no OpenMP yes (200505) PNG yes TIFF yes TRIO no UMEM no WebP yes WMF yes X11 yes XML yes ZLIB yes Host type: amd64-portbld-freebsd9.3 Configured using the command: ./configure '--enable-shared' '--enable-static' '--with-windows-font-dir=/usr/local/share/fonts/webfonts' '--without-perl' '--without-dps' '--without-fpx' '--with-threads' '--enable-openmp' '--disable-openmp-slow' '--with-quantum-depth=16' '--with-webp' '--with-wmf' '--with-x' '--with-xml' '--x-libraries=/usr/local/lib' '--x-includes=/usr/local/include' '--prefix=/usr/local' '--localstatedir=/var' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd9.3' 'build_alias=amd64-portbld-freebsd9.3' 'CC=cc' 'CFLAGS=-O2 -pipe -fstack-protector -fno-strict-aliasing' 'LDFLAGS= -fstack-protector' 'LIBS=' 'CPPFLAGS=' 'CPP=cpp' 'CXX=c++' 'CXXFLAGS=-O2 -pipe -fstack-protector -fno-strict-aliasing' Final Build Parameters: CC = cc -std=gnu99 CFLAGS = -fopenmp -O2 -pipe -fstack-protector -fno-strict-aliasing -Wall -D_THREAD_SAFE CPPFLAGS = -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/libxml2 CXX = c++ CXXFLAGS = -O2 -pipe -fstack-protector -fno-strict-aliasing -D_THREAD_SAFE LDFLAGS = -fstack-protector -L/usr/local/lib LIBS = -ljbig -lwebp -ltiff -lfreetype -lpng16 -lwmflite -lSM -lICE -lX11 -llzma -lbz2 -lxml2 -lz -lm -lgomp -lpthread -- Stefan BethkeFon +49 151 14070811 ___ freebsd-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 with duplicate LATEST_LINKs
> Am 18.08.2015 um 14:37 schrieb Ports Index build : > The following list includes ports maintained by you that have duplicate > LATEST_LINK values. They should either be modified to use a unique > PKGNAME, e.g. by using PKGNAMESUFFIX. Note that NO_LATEST_LINK is > deprecated. See the portmgr blog post for more information: > http://blogs.freebsdish.org/portmgr/2013/10/03/package-name-collisions/ > > devel/firmware-utils s...@assitu.de > graphics/pngnq s...@lassitu.de > mail/roundcube-sauserprefs s...@lassitu.de > > mail/squirrelmail-login_auth-plugin s...@lassitu.de > > science/py-ws2300s...@lassitu.de > www/ttf2eot s...@lassitu.de I’m trying to make sense of this, but having trouble. What exactly is the problem with these ports? None of the ports use LATEST_LINK, I believe the package names are unique, and there’s no multiple ports for these that only differ in the version number. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-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: monitorings-plugin hangs on configure ICMPv6
Am 12.01.2015 um 16:04 schrieb Mathieu Arnold : > > Could you test the patch there: > https://reviews.freebsd.org/D1502 > > and tell me how good, or bad, it goes ? Builds just fine. And I see you’ve already commit it. Thanks for the quick help! Regards, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: monitorings-plugin hangs on configure ICMPv6
Am 11.01.2015 um 17:54 schrieb Stefan Bethke :
>
> checking for ps syntax... /bin/ps axwo 'stat uid pid ppid vsz rss pcpu comm
> args'
> checking for ping... /sbin/ping
> checking for ping6... /sbin/ping6
> checking for ICMP ping syntax... /sbin/ping -n -c %d %s
> checking for ICMPv6 ping syntax... ^C===> Script "configure" failed
> unexpectedly.
>
> FreeBSD 9-stable, all ports up to date, inside a jail.
>
> Any suggestions?
Figured it out myself. My google-foo did not give me any hints to what the
problem is, only Linux related posts, but that led me to checking for
jail-related issues. The help text is a bit terse, I had to look at the
Makefile to understand what’s required.
Since I’m using NO_DIALOG, I have all my config option in /etc/make.conf. I’ve
added this:
+JAILED!= /sbin/sysctl -n security.jail.jailed
+.if ${JAILED} == 1
+monitoring-plugins_SET+= JAIL
+nagios-plugins_SET+= JAIL
+NAGIOSPOLLIP!=ifconfig em0 | sed -nEe 's/.*inet (.*) netmask.*/\1/p'
+NAGIOSPOLLIP6!=ifconfig em0 | sed -nEe 's/.*inet6 (.*) prefix.*/\1/p'
+.endif
(em 0 is my outward-facing interface on all the hosts.)
May I suggest to use something like this for the help text?
> If you are building the port inside a jail, you might need to tell check_ping
> which IP address to use as the source address, instead of 127.0.0.1 and ::1,
> respectively. Use the config option JAIL, and define NAGIOSPOLLIP and
> NAGIOSPOLLIP6 on the command line or in make.conf when building the port,
> setting them to the primary IPv4 and IPv6 address of your jail, respectively.
I have no idea what the second paragraph is supposed to tell me. Irrespective
of the first paragraph, you shouldn’t set the JAIL config option when building
the package with poudriere?
Stefan
--
Stefan BethkeFon +49 151 14070811
___
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"
monitorings-plugin hangs on configure ICMPv6
checking for ps syntax... /bin/ps axwo 'stat uid pid ppid vsz rss pcpu comm args' checking for ping... /sbin/ping checking for ping6... /sbin/ping6 checking for ICMP ping syntax... /sbin/ping -n -c %d %s checking for ICMPv6 ping syntax... ^C===> Script "configure" failed unexpectedly. FreeBSD 9-stable, all ports up to date, inside a jail. Any suggestions? Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: Error building ntopng
Thanks, that lets me build it, but it crashes after a couple minutes: Nov 9 22:50:00 diesel ntopng: stack overflow detected; terminated Nov 9 22:50:00 diesel kernel: pid 67897 (ntopng), uid 65534: exited on signal 6 Should I try and investigate, or are you aware of this already? > Am 09.11.2014 um 19:35 schrieb Muhammad Moinur Rahman <5u623...@gmail.com>: > > For the time being short solution is change LIB_DEPENDS of libzmq4 to > libzmq3. AM working on updating. > > On Sun, Nov 9, 2014 at 10:04 PM, Stefan Bethke wrote: > Any suggestions? Default options for noting and all dependencies, as far as I > can tell. > > > /usr/local/lib/libzmq.a(libzmq_la-curve_server.o): In function > `zmq::curve_server_t::decode(zmq::msg_t*)': > (.text+0x106b): undefined reference to `crypto_box_open_afternm' > clang++: error: linker command failed with exit code 1 (use -v to see > invocation) > Makefile:79: recipe for target 'ntopng' failed > gmake[2]: *** [ntopng] Error 1 > gmake[2]: Leaving directory > '/p2/freebsd/obj/ports/p2/freebsd/ports/net/ntopng/ntopng-1.2.1' > *** Error code 1 > > Stop. > make[1]: stopped in /p2/freebsd/ports/net/ntopng > *** Error code 1 > > Stop. > make: stopped in /p2/freebsd/ports/net/ntopng > # uname -a > FreeBSD diesel.lassitu.de 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #3 r273689: > Sun Oct 26 23:11:30 CET 2014 > r...@diesel.lassitu.de:/p2/freebsd/obj/p2/freebsd/10-stable/sys/DIESEL amd64 -- Stefan BethkeFon +49 151 14070811 ___ 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"
Error building ntopng
oduce_initiate(zmq::msg_t*)': (.text+0x55a): undefined reference to `crypto_box' /usr/local/lib/libzmq.a(libzmq_la-curve_client.o): In function `zmq::curve_client_t::process_welcome(zmq::msg_t*)': (.text+0x87d): undefined reference to `crypto_box_open' /usr/local/lib/libzmq.a(libzmq_la-curve_client.o): In function `zmq::curve_client_t::process_welcome(zmq::msg_t*)': (.text+0x938): undefined reference to `crypto_box_beforenm' /usr/local/lib/libzmq.a(libzmq_la-curve_client.o): In function `zmq::curve_client_t::process_ready(zmq::msg_t*)': (.text+0xa35): undefined reference to `crypto_box_open_afternm' /usr/local/lib/libzmq.a(libzmq_la-curve_client.o): In function `zmq::curve_client_t::encode(zmq::msg_t*)': (.text+0xb6e): undefined reference to `crypto_box_afternm' /usr/local/lib/libzmq.a(libzmq_la-curve_client.o): In function `zmq::curve_client_t::decode(zmq::msg_t*)': (.text+0xe3b): undefined reference to `crypto_box_open_afternm' /usr/local/lib/libzmq.a(libzmq_la-curve_server.o): In function `zmq::curve_server_t::curve_server_t(zmq::session_base_t*, std::__1::basic_string, std::__1::allocator > const&, zmq::options_t const&)': (.text+0x117): undefined reference to `crypto_box_keypair' /usr/local/lib/libzmq.a(libzmq_la-curve_server.o): In function `zmq::curve_server_t::produce_welcome(zmq::msg_t*)': (.text+0x2d0): undefined reference to `randombytes' /usr/local/lib/libzmq.a(libzmq_la-curve_server.o): In function `zmq::curve_server_t::produce_welcome(zmq::msg_t*)': (.text+0x32b): undefined reference to `randombytes' /usr/local/lib/libzmq.a(libzmq_la-curve_server.o): In function `zmq::curve_server_t::produce_welcome(zmq::msg_t*)': (.text+0x34a): undefined reference to `crypto_secretbox' /usr/local/lib/libzmq.a(libzmq_la-curve_server.o): In function `zmq::curve_server_t::produce_welcome(zmq::msg_t*)': (.text+0x377): undefined reference to `randombytes' /usr/local/lib/libzmq.a(libzmq_la-curve_server.o): In function `zmq::curve_server_t::produce_welcome(zmq::msg_t*)': (.text+0x422): undefined reference to `crypto_box' /usr/local/lib/libzmq.a(libzmq_la-curve_server.o): In function `zmq::curve_server_t::produce_ready(zmq::msg_t*)': (.text+0x627): undefined reference to `crypto_box_afternm' /usr/local/lib/libzmq.a(libzmq_la-curve_server.o): In function `zmq::curve_server_t::process_hello(zmq::msg_t*)': (.text+0x93d): undefined reference to `crypto_box_open' /usr/local/lib/libzmq.a(libzmq_la-curve_server.o): In function `zmq::curve_server_t::process_initiate(zmq::msg_t*)': (.text+0xa5a): undefined reference to `crypto_secretbox_open' /usr/local/lib/libzmq.a(libzmq_la-curve_server.o): In function `zmq::curve_server_t::process_initiate(zmq::msg_t*)': (.text+0xb19): undefined reference to `crypto_box_open' /usr/local/lib/libzmq.a(libzmq_la-curve_server.o): In function `zmq::curve_server_t::process_initiate(zmq::msg_t*)': (.text+0xbbc): undefined reference to `crypto_box_open' /usr/local/lib/libzmq.a(libzmq_la-curve_server.o): In function `zmq::curve_server_t::process_initiate(zmq::msg_t*)': (.text+0xc1e): undefined reference to `crypto_box_beforenm' /usr/local/lib/libzmq.a(libzmq_la-curve_server.o): In function `zmq::curve_server_t::encode(zmq::msg_t*)': (.text+0xd9c): undefined reference to `crypto_box_afternm' /usr/local/lib/libzmq.a(libzmq_la-curve_server.o): In function `zmq::curve_server_t::decode(zmq::msg_t*)': (.text+0x106b): undefined reference to `crypto_box_open_afternm' clang++: error: linker command failed with exit code 1 (use -v to see invocation) Makefile:79: recipe for target 'ntopng' failed gmake[2]: *** [ntopng] Error 1 gmake[2]: Leaving directory '/p2/freebsd/obj/ports/p2/freebsd/ports/net/ntopng/ntopng-1.2.1' *** Error code 1 Stop. make[1]: stopped in /p2/freebsd/ports/net/ntopng *** Error code 1 Stop. make: stopped in /p2/freebsd/ports/net/ntopng # uname -a FreeBSD diesel.lassitu.de 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #3 r273689: Sun Oct 26 23:11:30 CET 2014 r...@diesel.lassitu.de:/p2/freebsd/obj/p2/freebsd/10-stable/sys/DIESEL amd64 -- Stefan BethkeFon +49 151 14070811 ___ 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: lang/tlc86: missing standard modules?
Am 31.08.2014 um 17:40 schrieb Stefan Bethke :
>
> Am 31.08.2014 um 17:32 schrieb Stefan Bethke :
>
>> Hey,
>>
>> since the update to tcl86-8.6.2, I’m getting this error trace:
>> can't find package msgcat 1.4
>> while executing
>> "package require msgcat 1.4"
>> ("uplevel" body line 2)
>> invoked from within
>> "uplevel \#0 {
>> package require msgcat 1.4
>> if { $::tcl_platform(platform) eq {windows} } {
>> if { [catch { package require registry 1.1 }] } {
>> ..."
>> (file "/usr/local/lib/tcl8.6/clock.tcl" line 21)
>> invoked from within
>> "source -encoding utf-8 [file join $TclLibDir clock.tcl]"
>> (procedure "::tcl::clock::format" line 3)
>> invoked from within
>> "clock format [clock seconds] -gmt 1 -format "\"updated %Y%m%d %H%M%S\"""
>> (procedure "update_zone" line 27)
>> invoked from within
>> "update_zone $host $ip“
>>
>> As far as I can tell, msgcat should be included with Tcl. Botched install,
>> or is the port broken?
>>
>> I’m going to try a downgrade next.
>
> Downgrading the port to r366509 / 8.6.1 unbreaks my Tcl script. I was at
> r366676 before.
I’ve filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193207, which
includes a simple test case.
Stefan
--
Stefan BethkeFon +49 151 14070811
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: lang/tlc86: missing standard modules?
Am 31.08.2014 um 17:32 schrieb Stefan Bethke :
> Hey,
>
> since the update to tcl86-8.6.2, I’m getting this error trace:
> can't find package msgcat 1.4
>while executing
> "package require msgcat 1.4"
>("uplevel" body line 2)
>invoked from within
> "uplevel \#0 {
>package require msgcat 1.4
>if { $::tcl_platform(platform) eq {windows} } {
> if { [catch { package require registry 1.1 }] } {
>..."
>(file "/usr/local/lib/tcl8.6/clock.tcl" line 21)
>invoked from within
> "source -encoding utf-8 [file join $TclLibDir clock.tcl]"
>(procedure "::tcl::clock::format" line 3)
>invoked from within
> "clock format [clock seconds] -gmt 1 -format "\"updated %Y%m%d %H%M%S\"""
>(procedure "update_zone" line 27)
>invoked from within
> "update_zone $host $ip“
>
> As far as I can tell, msgcat should be included with Tcl. Botched install, or
> is the port broken?
>
> I’m going to try a downgrade next.
Downgrading the port to r366509 / 8.6.1 unbreaks my Tcl script. I was at
r366676 before.
Stefan
--
Stefan BethkeFon +49 151 14070811
signature.asc
Description: Message signed with OpenPGP using GPGMail
lang/tlc86: missing standard modules?
Hey,
since the update to tcl86-8.6.2, I’m getting this error trace:
can't find package msgcat 1.4
while executing
"package require msgcat 1.4"
("uplevel" body line 2)
invoked from within
"uplevel \#0 {
package require msgcat 1.4
if { $::tcl_platform(platform) eq {windows} } {
if { [catch { package require registry 1.1 }] } {
..."
(file "/usr/local/lib/tcl8.6/clock.tcl" line 21)
invoked from within
"source -encoding utf-8 [file join $TclLibDir clock.tcl]"
(procedure "::tcl::clock::format" line 3)
invoked from within
"clock format [clock seconds] -gmt 1 -format "\"updated %Y%m%d %H%M%S\"""
(procedure "update_zone" line 27)
invoked from within
"update_zone $host $ip“
As far as I can tell, msgcat should be included with Tcl. Botched install, or
is the port broken?
I’m going to try a downgrade next.
Cheers,
Stefan
--
Stefan BethkeFon +49 151 14070811
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Does www/chromium work?
If anyone's wondering what the fix for Chromium (chromium-36.0.1985.143_1) on FreeBSD 9 (stable) is: If you get this error: $ chrome /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required by /usr/local/share/chromium/chrome not found Add this at the end of /etc/libmap.conf: [/usr/local/share/chromium/chrome] libstdc++.so.6 gcc47/libstdc++.so.6 You might want to also check that GCC 4.7 is actually installed, I'm not sure the Chromium port pulls that in, or I just happened to have that installed already. HTH, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: roundcube's switch to composer, anything plugin port maintainers should be doing?
Am 03.06.2014 um 14:44 schrieb Alex Dupre : > Signierter PGP Teil > Stefan Bethke ha scritto: > > I was in the process of upgrading a roundcube plugin (sauserprefs) > > and noticed that roundcube is switching/has swichted to composer. > > This is the first time I’ve come across composer. Should I ignore > > that for the moment? Is there work underway to convert the plugin > > ports to use composer? Should the plugin ports be removed in favor > > of using composer manually? Is composer production ready yet? > > > > Inquiring minds want to know… > > Hi Stefan, like you this is the first time I've come across > 'composer'. It's a dependency manager, I have no plans to support it, > you can ignore it for the moment. The problem seems to be that plugin authors are moving to the new plugin repository, which is based around Composer. The original download link for sauserprefs is already gone. Unfortunately, for sauserprefs, there's only a snapshot version tagged (as I understand it), and the old version numbers for the plugin seem to have been abandoned. I could start doing dated snapshots from the plugins site on my own mirror, but this doesn't seem it's the right thing to do. I ll get in touch with my plugin's author to see what his take is on the situation. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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"
roundcube's switch to composer, anything plugin port maintainers should be doing?
Hi there, I was in the process of upgrading a roundcube plugin (sauserprefs) and noticed that roundcube is switching/has swichted to composer. This is the first time I’ve come across composer. Should I ignore that for the moment? Is there work underway to convert the plugin ports to use composer? Should the plugin ports be removed in favor of using composer manually? Is composer production ready yet? Inquiring minds want to know… Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP using GPGMail
Looking for a committer for ports/190274: [PATCH] science/py-ws2300: update to 1.9, Add STAGE support
Hey there, since I didn’t raise the PR, it’s not marked as maintainer-update, but the linked patch (not the included one) is ready to be committed. Cheers, Stefan -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: foomatic-rip and foo2zjs
Am 25.04.2014 um 15:20 schrieb Robert Backhaus :
> Anyway, here's a backtrace: - but the pointed line, 1200, just looks wrong -
>
> int fd = mkstemp (LOG_FILE "-XX.log"); - checked, edited, built - Yup,
> that's it. Here's the patch:
>
> --- foomaticrip.c.orig 2014-04-25 23:16:06.0 +1000
> +++ foomaticrip.c 2014-04-25 23:16:47.0 +1000
> @@ -1197,7 +1197,7 @@
> debug = 1;
>
> if (debug) {
> - int fd = mkstemp (LOG_FILE "-XX.log");
> + int fd = mkstemp ("LOG_FILE-XX.log");
> if (fd != -1)
> logh = fdopen(fd, "w");
> else
Sorry, that patch does’t look right to me. LOG_FILE should be a define that
get’s concatenated with the string literal. Since this is compile-time, I don’t
see how this would lead to a runtime error, unless LOG_FILE was defined to some
unusual value.
Stefan
--
Stefan BethkeFon +49 151 14070811
signature.asc
Description: Message signed with OpenPGP using GPGMail
foomatic-rip and foo2zjs
Two quick observations I’m too lazy to file PRs for: foomatic-rip (from foomatic-filters-4.0.17) coredumps if you set debug: 1 in /usr/local/etc/foomatic/filter.conf. I haven’t checked what is going wrong specifically. It is possible to run foomatic-rip form the command line with -v and with debug: 0, though. foo2zjs-20140401 requires textproc/gsed, but it’s not a dependency of the port. Not sure it really has to be gsed (instead of /usr/bin/sed), but that is what it calls. Stefan -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP using GPGMail
ImageMagick-6.8.0.7_3,1 font rendering problems
ImageMagick $ uname -a FreeBSD krokodil.zs64.net 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #2 r255602: Sun Sep 15 21:25:57 UTC 2013 r...@lokschuppen.zs64.net:/usr/obj/freebsd/checkout/src/sys/EISENBOOT amd64 # pkg_info -r ImageMagick-* Information for ImageMagick-6.8.0.7_3,1: Depends on: Dependency: xproto-7.0.25 Dependency: xineramaproto-1.2.1 Dependency: xf86vidmodeproto-2.3.1 Dependency: xextproto-7.2.1 Dependency: renderproto-0.11.1 Dependency: randrproto-1.4.0 Dependency: pixman-0.32.4 Dependency: libXdmcp-1.1.1 Dependency: libXau-1.0.8 Dependency: libICE-1.0.8,1 Dependency: libSM-1.2.2,1 Dependency: kbproto-1.0.6 Dependency: inputproto-2.3 Dependency: fixesproto-5.0 Dependency: dri2proto-2.8 Dependency: damageproto-1.2.1 Dependency: compositeproto-0.4.2 Dependency: libfontenc-1.1.2 Dependency: font-util-1.3.0_1 Dependency: encodings-1.0.4_1,1 Dependency: expat-2.1.0 Dependency: libpaper-1.1.24_1 Dependency: gsfonts-8.11_6 Dependency: freetype2-2.5.2 Dependency: mkfontscale-1.1.1 Dependency: mkfontdir-1.0.7 Dependency: fontconfig-2.11.0_1,1 Dependency: font-misc-meltho-1.0.3_1 Dependency: font-misc-ethiopic-1.0.3_1 Dependency: font-bh-ttf-1.0.3_1 Dependency: dejavu-2.34 Dependency: xorg-fonts-truetype-7.7_1 Dependency: pciids-20131225 Dependency: hicolor-icon-theme-0.12 Dependency: gnomehier-3.0 Dependency: fftw3-3.3.3_1 Dependency: perl5.14-5.14.4_4 Dependency: svgalib-1.4.3_6 Dependency: png-1.5.17 Dependency: libfpx-1.3.1.3 Dependency: lcms2-2.5 Dependency: jpeg-8_4 Dependency: jbigkit-1.6 Dependency: jbig2dec-0.11_1 Dependency: jasper-1.900.1_12 Dependency: giflib-nox11-4.2.3 Dependency: pkgconf-0.9.4 Dependency: pcre-8.33 Dependency: libpthread-stubs-0.3_4 Dependency: libpciaccess-0.13.2 Dependency: libdrm-2.4.17_1 Dependency: libltdl-2.4.2_2 Dependency: libffi-3.0.13_1 Dependency: icu-50.1.2 Dependency: libiconv-1.14_1 Dependency: libxml2-2.8.0_3 Dependency: libxcb-1.9.3 Dependency: xcb-util-0.3.9_1,1 Dependency: xcb-util-renderutil-0.3.8 Dependency: libX11-1.6.2,1 Dependency: libwmf-0.2.8.4_10 Dependency: libXt-1.1.4,1 Dependency: libXrender-0.9.8 Dependency: libXft-2.3.1 Dependency: libXfixes-5.0.1 Dependency: libXext-1.3.2,1 Dependency: libXxf86vm-1.1.3 Dependency: libXrandr-1.4.2 Dependency: libXmu-1.1.2,1 Dependency: libXinerama-1.1.3,1 Dependency: libXi-1.7.2,1 Dependency: libXdamage-1.1.4 Dependency: libXcursor-1.1.14 Dependency: libXcomposite-0.4.4,1 Dependency: libGL-7.6.1_4 Dependency: libGLU-9.0.0 Dependency: graphite2-1.2.4 Dependency: python2-2_2 Dependency: python-2.7_1,2 Dependency: libidn-1.28_1 Dependency: glib-2.36.3_1 Dependency: shared-mime-info-1.1 Dependency: liblqr-1-0.4.1_5 Dependency: libcroco-0.6.8 Dependency: freeglut-2.8.1 Dependency: tiff-4.0.3 Dependency: webp-0.3.1_4 Dependency: gdk-pixbuf2-2.28.2 Dependency: libgsf-1.14.28 Dependency: cups-client-1.5.4_1 Dependency: cups-image-1.5.4_1 Dependency: ghostscript9-9.06_4 Dependency: cairo-1.10.2_7,2 Dependency: harfbuzz-0.9.25 Dependency: pango-1.34.1_1 Dependency: atk-2.8.0 Dependency: gtk-update-icon-cache-2.24.22 Dependency: gtk2-2.24.22_1 Dependency: gtk-engines2-2.20.2_1 Dependency: librsvg2-2.36.4 -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ntp-devel-4.2.7p364_2 coredumps
Am 28.12.2013 um 06:13 schrieb Cy Schubert : > In message , Stefan Bethke > wri > tes: >> >> --Apple-Mail=_6EEA81A7-5FCB-41CB-A6F5-4CBEDAB3BBAE >> Content-Transfer-Encoding: quoted-printable >> Content-Type: text/plain; >> charset=us-ascii >> >> On both 9-stable and 10-stable >> >> Dec 26 13:02:04 lokschuppen ntpd[5270]: ntpd 4.2.7p364@1.2483-o Thu Dec = >> 26 12:55:22 UTC 2013 (1): Starting >> Dec 26 13:02:04 lokschuppen ntpd[5270]: Command line: = >> /usr/local/sbin/ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid -f = >> /var/db/ntpd.drift >> Dec 26 13:02:05 lokschuppen kernel: pid 5271 (ntpd), uid 0: exited on = >> signal 11 (core dumped) > > p404 has just been committed. Let's see if it makes a difference. > > Let me know what uname -a shows and any options/optional modules compiled > or loaded. That seems to have done the trick, thank you! The problem occurred on both FreeBSD diesel.lassitu.de 10.0-PRERELEASE FreeBSD 10.0-PRERELEASE #5 r259696: Sun Dec 22 00:13:23 CET 2013 r...@diesel.lassitu.de:/usr/obj/var/freebsd/10-stable/sys/DIESEL amd64 and FreeBSD lokschuppen.zs64.net 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #2 r255602: Sun Sep 15 21:25:57 UTC 2013 r...@lokschuppen.zs64.net:/usr/obj/freebsd/checkout/src/sys/EISENBOOT amd64 with defaults for the port: # make showconfig ===> The following configuration options are available for ntp-devel-4.2.7p404: ACTS=off: Enable ACTS modem service ARBITER=off: Enable Arbiter 1088A/B GPS receiver ARCRON_MSF=off: Enable Arcron MSF receiver AS2201=off: Enable Austron 2200A/2201A GPS receiver ATOM=on: Enable ATOM PPS interface AUDIO_CHU=off: Enable CHU audio/decoder BANCOMM=off: Enable Datum/Bancomm bc635/VME interface CHRONOLOG=off: Enable Chrono-log K-series WWVB receiver CHU=off: Enable CHU modem/decoder COMPUTIME=off: Enable Diem Computime Radio Clock DATUM=off: Enable Datum Programmable Time System DCF7000=off: Enable ELV/DCF7000 clock DUMBCLOCK=off: Enable Dumb generic hh:mm:ss local clock FG=off: Enable Forum Graphic GPS GPSVME=off: Enable TrueTime GPS receiver/VME interface HEATH=off: Enable Heath GC-1000 WWV/WWVH receiver HOPF6021=off: Enable HOPF 6021 clock HOPFPCI=off: Enable hopf 6039 PCI board HOPFSERIAL=off: Enable hopf serial clock device HPGPS=off: Enable HP 58503A GPS receiver IPV6=on: IPv6 protocol support IRIG=off: Enable IRIG audio decoder JJY=off: Enable JJY receiver JUPITER=off: Enable Rockwell Jupiter GPS receiver LEITCH=off: Enable Leitch CSD 5300 Master Clock LOCAL_CLOCK=off: Enable local clock reference MEINBERG=off: Enable Meinberg clocks MX4200=off: Enable Magnavox MX4200 GPS receiver NEOCLOCK4X=off: Enable NeoClock4X DCF77 / TDF receiver NMEA=on: Enable NMEA GPS receiver NTPSNMPD=off: Build and install ntpsnmpd NTP_SIGND=on: Enable signed NTP ONCORE=off: Enable Motorola VP/UT Oncore GPS receiver PALISADE=off: Enable Palisade clock PCF=off: Enable Conrad parallel port radio clock PST=off: Enable PST/Traconex 1020 WWV/WWVH receiver RAWDCF=off: Enable DCF77 raw time code RCC8000=off: Enable RCC 8000 clock RIPENCC=off: Enable RIPENCC specific Trimble driver SCHMID=off: Enable Schmid DCF77 clock SEL240X=off: Enable SEL 240X clocks SHM=off: Enable SHM clock attached thru shared memory SPECTRACOM=off: Enable Spectracom 8170/Netclock/2 WWVB SSL=on: SSL protocol support TRIMTAIP=off: Enable Trimble GPS receiver/TAIP protocol TRIMTSIP=off: Enable Trimble GPS receiver/TSIP protocol TRUETIME=off: Enable Kinemetrics/TrueTime receivers ULINK=off: Enable Ultralink WWVB receiver VARITEXT=off: Enable VARITEXT clock WHARTON=off: Enable WHARTON 400A Series clock WWV=off: Enable WWV Audio receiver ZYFER=off: Enable Zyfer GPStarplus receiver ===> Use 'make config' to modify these settings -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP using GPGMail
ntp-devel-4.2.7p364_2 coredumps
On both 9-stable and 10-stable Dec 26 13:02:04 lokschuppen ntpd[5270]: ntpd 4.2.7p364@1.2483-o Thu Dec 26 12:55:22 UTC 2013 (1): Starting Dec 26 13:02:04 lokschuppen ntpd[5270]: Command line: /usr/local/sbin/ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift Dec 26 13:02:05 lokschuppen kernel: pid 5271 (ntpd), uid 0: exited on signal 11 (core dumped) If I run it with -d, it starts up and runs normally, AFAICT. # gdb /usr/local/sbin/ntpd ntpd.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `ntpd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libmd.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libmd.so.5 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /usr/lib/librt.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x00080152c478 in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 [New Thread 801c07400 (LWP 102083/ntpd)] (gdb) bt #0 0x00080152c478 in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 #1 0x00080152cf5b in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 #2 0x00080152da8c in _malloc_postfork () from /lib/libc.so.7 #3 0x00080152dd4c in _malloc_postfork () from /lib/libc.so.7 #4 0x000801532838 in _malloc_prefork () from /lib/libc.so.7 #5 0x0008015349ba in malloc () from /lib/libc.so.7 #6 0x000800e0b213 in CRYPTO_malloc () from /lib/libcrypto.so.6 #7 0x000800e05fa9 in lh_new () from /lib/libcrypto.so.6 #8 0x000800dd6927 in ERR_get_implementation () from /lib/libcrypto.so.6 #9 0x000800dd665b in ERR_get_implementation () from /lib/libcrypto.so.6 #10 0x000800dd633c in ERR_load_strings () from /lib/libcrypto.so.6 #11 0x000800d85d98 in ERR_load_ERR_strings () from /lib/libcrypto.so.6 #12 0x000800d7b8b9 in ERR_load_crypto_strings () from /lib/libcrypto.so.6 #13 0x00457318 in ?? () #14 0x00415139 in ?? () #15 0x00406591 in ?? () #16 0x0008006ab000 in ?? () #17 0x00000000 in ?? () -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Ports with a broken PKGORIGIN: mail/squirrelmail-abook_import_e...
For the past three day, I’ve been receiving this warning, and again (like back in June), I have no clue what triggers this. Is the diagnostic broken, or the actual port? This time, the origin appears to be actually broken: $ cd /usr/ports/mail/squirrelmail-login_auth-plugin $ make -V PKGORIGIN /squirrelmail-login_auth-plugin and: # portupgrade -f squirrelmail-login_auth-plugin-3.0 … # pkg_info -o squirrelmail-login_auth-plugin-3.0 Information for squirrelmail-login_auth-plugin-3.0: Origin: /squirrelmail-login_auth-plugin Is this commit triggering this? r335921 | adamw | 2013-12-08 19:59:35 +0100 (Sun, 08 Dec 2013) | 10 lines Regards, Stefan Am 11.12.2013 um 13:57 schrieb er...@freebsd.org: > ** The following ports have an incorrect PKGORIGIN ** > > PKGORIGIN connects packaged or installed ports to the directory they > originated from. This is essential for tools like pkg_version or > portupgrade to work correctly. Wrong PKGORIGINs are often caused by a > wrong order of CATEGORIES after a repocopy. > > Please fix any errors as soon as possible. > > The ports tree was updated at Wed Dec 11 2013 12:37:26 UTC. > > - *mail/squirrelmail-abook_import_export-plugin* : > /squirrelmail-abook_import_export-plugin > > - *mail/squirrelmail-askuserinfo-plugin* : > /squirrelmail-askuserinfo-plugin > > - *mail/squirrelmail-avelsieve-plugin* : > /squirrelmail-avelsieve-plugin > > - *mail/squirrelmail-calendar_file_backend-plugin* : > /squirrelmail-calendar_file_backend-plugin > > - *mail/squirrelmail-change_sqlpass-plugin* : > /squirrelmail-change_sqlpass-plugin > > - *mail/squirrelmail-check_quota-plugin* : > /squirrelmail-check_quota-plugin > > - *mail/squirrelmail-email_footer-plugin* : > /squirrelmail-email_footer-plugin > > - *mail/squirrelmail-login_auth-plugin* : > /squirrelmail-login_auth-plugin > > - *mail/squirrelmail-login_notes-plugin* : > /squirrelmail-login_notes-plugin > > - *mail/squirrelmail-mark_read-plugin* : > /squirrelmail-mark_read-plugin > > - *mail/squirrelmail-multilogin-plugin* : > /squirrelmail-multilogin-plugin > > - *mail/squirrelmail-notes-plugin* : > /squirrelmail-notes-plugin > > - *mail/squirrelmail-notify-plugin* : > /squirrelmail-notify-plugin > > - *mail/squirrelmail-password_forget-plugin* : > /squirrelmail-password_forget-plugin > > - *mail/squirrelmail-pupdate-plugin* : > /squirrelmail-pupdate-plugin > > - *mail/squirrelmail-qmailadmin_login-plugin* : > /squirrelmail-qmailadmin_login-plugin > > - *mail/squirrelmail-quota_usage-plugin* : > /squirrelmail-quota_usage-plugin > > - *mail/squirrelmail-sasql-plugin* : > /squirrelmail-sasql-plugin > > - *mail/squirrelmail-secure_login-plugin* : > /squirrelmail-secure_login-plugin > > - *mail/squirrelmail-spam-buttons-plugin* : > /squirrelmail-spam-buttons-plugin > > - *mail/squirrelmail-squirrel_logger-plugin* : > /squirrelmail-squirrel_logger-plugin > > - *mail/squirrelmail-timeout_user-plugin* : > /squirrelmail-timeout_user-plugin > > - *mail/squirrelmail-unsafe_image_rules-plugin* : > /squirrelmail-unsafe_image_rules-plugin > > - *mail/squirrelmail-user_special_mailboxes-plugin* : > /squirrelmail-user_special_mailboxes-plugin > > - *mail/squirrelmail-websearch-plugin* : > /squirrelmail-websearch-plugin > > - *mail/squirrelmail-wetteronline-plugin* : > /squirrelmail-wetteronline-plugin > > -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Staging and read-only /usr/ports [PATCH]
Am 01.10.2013 um 15:45 schrieb Bryan Drewery :
> On 9/26/2013 4:52 PM, Stefan Bethke wrote:
>> Guys,
>>
>> I've noticed that more and more ports are trying to build a package
>> /usr/ports/category/port/port-version.tgz. Since my /usr/ports is mounted
>> read-only (via nullfs), this fails. I've looked through Mk/*.mk trying to
>> figure out how I can redirect this to another dir. Is PACKAGES the way to
>> go? What if I don't want to keep packages around?
> Please try this patch:
>
> http://people.freebsd.org/~bdrewery/pkg_install-make-package-ro.txt
Work great! Thanks a million!
PACKAGE not set in make.conf, WRKDIR:
WRKDIRPREFIX?= /var/ports/work
WRKDIR?=${WRKDIRPREFIX}${.CURDIR:S/${PORTSDIR}//}
...
---> Deinstalling 'btpd-0.16_2'
[Updating the pkgdb in /var/db/pkg ... - 207 packages found
(-1 +0) (...) done]
---> Installing the new version via the port
===> Staging for btpd-0.16_2
===> Generating temporary packing list
/bin/mkdir -p '/var/ports/work/net-p2p/btpd/stage/usr/local/bin'
install -s -o root -g wheel -m 555 btpd/btpd cli/btcli cli/btinfo
'/var/ports/work/net-p2p/btpd/stage/usr/local/bin'
/bin/mkdir -p '/var/ports/work/net-p2p/btpd/stage/usr/local/man/man1'
install -o root -g wheel -m 444 doc/btcli.1 doc/btinfo.1 doc/btpd.1
'/var/ports/work/net-p2p/btpd/stage/usr/local/man/man1'
install -o root -g wheel -m 444 /var/ports/work/net-p2p/btpd/btpd-0.16/README
/var/ports/work/net-p2p/btpd/stage/usr/local/share/doc/btpd/
> Compressing man pages
===> Building package for btpd-0.16_2
Creating package /var/ports/work/net-p2p/btpd/btpd-0.16_2.tbz
Registering depends:.
Creating bzip'd tar ball in '/var/ports/work/net-p2p/btpd/btpd-0.16_2.tbz'
===> Installing for btpd-0.16_2
===> SECURITY REPORT:
...
Stefan
--
Stefan BethkeFon +49 151 14070811
___
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: Staging and read-only /usr/ports
Am 27.09.2013 um 13:26 schrieb Bryan Drewery: >> So, if I do want to have NO_STAGE disabled (staging enabled), and I have a >> read-only /usr/ports, and I'm not yet using pkgng, I need to set PACKAGES to >> a read-write location, even if I do not want to retain packages? Or is there >> a variable specifically for setting the package storage path for building a >> staging package? > NO_STAGE is not a user variable. Do not set that. > > It is not intended that 'make install' creates a package in a read-only > directory. As I said, I am discussing this to fix it. For now you must > set PACKAGES= to a writable location until it is fixed. Thank you, I'll do that! Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: Staging and read-only /usr/ports
Am 27.09.2013 um 13:02 schrieb Bryan Drewery: > On 9/27/2013 3:55 AM, Boris Samorodov wrote: >> 27.09.2013 02:05, William Grzybowski пишет: >> >>> Well, it shouldn't create packages unless you use "make package", >> >> I think that if STAGE is used then a package is created and then >> it (the package) is get installed (via "make install" command). >> >>> you can set PACKAGES to move it from /usr/ports/packages. >> > > Yes, this is true for pkg_install. Pkgng does not do this. So, if I do want to have NO_STAGE disabled (staging enabled), and I have a read-only /usr/ports, and I'm not yet using pkgng, I need to set PACKAGES to a read-write location, even if I do not want to retain packages? Or is there a variable specifically for setting the package storage path for building a staging package? Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: Staging and read-only /usr/ports
Am 26.09.2013 um 23:54 schrieb William Grzybowski :
> On Thu, Sep 26, 2013 at 6:52 PM, Stefan Bethke wrote:
>> Guys,
>>
>> I've noticed that more and more ports are trying to build a package
>> /usr/ports/category/port/port-version.tgz. Since my /usr/ports is mounted
>> read-only (via nullfs), this fails. I've looked through Mk/*.mk trying to
>> figure out how I can redirect this to another dir. Is PACKAGES the way to
>> go? What if I don't want to keep packages around?
>
> Try set STAGEDIR=/somewhere/else/ in make.conf
The staging dir is not the problem, that is set correctly:
stb@mirror:/usr/ports/net-p2p/btpd$ make -V STAGEDIR
/var/ports/work/net-p2p/btpd/stage
Because of these make.conf settings:
### Ports
DISTDIR?= /var/ports/distfiles
WRKDIRPREFIX?= /var/ports/work
WRKDIR?=${WRKDIRPREFIX}${.CURDIR:S/${PORTSDIR}//}
The problem is the package destination, which error message you can examine in
my original message.
Stefan
--
Stefan BethkeFon +49 151 14070811
___
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"
Staging and read-only /usr/ports
Guys, I've noticed that more and more ports are trying to build a package /usr/ports/category/port/port-version.tgz. Since my /usr/ports is mounted read-only (via nullfs), this fails. I've looked through Mk/*.mk trying to figure out how I can redirect this to another dir. Is PACKAGES the way to go? What if I don't want to keep packages around? For the time being, I'm setting NO_STAGE=yes. Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 > Compressing man pages ===> Building package for btpd-0.16_2 Creating package /usr/ports/net-p2p/btpd/btpd-0.16_2.tbz Registering depends:. Creating bzip'd tar ball in '/usr/ports/net-p2p/btpd/btpd-0.16_2.tbz' tar: Failed to open '/usr/ports/net-p2p/btpd/btpd-0.16_2.tbz' pkg_create: make_dist: tar command failed with code 256 *** [do-package] Error code 1 Stop in /usr/ports/net-p2p/btpd. *** [reinstall] Error code 1 Stop in /usr/ports/net-p2p/btpd. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20130926-47352-43dmv env UPGRADE_TOOL=portupgrade UPGRADE_PORT=btpd-0.16_2 UPGRADE_PORT_VER=0.16_2 make -DFORCE_PKG_REGISTER reinstall ---> Restoring the old version ** Fix the installation problem and try again. [Updating the pkgdb in /var/db/pkg ... - 208 packages found (-0 +1) . done] ** Listing the failed packages (-:ignored / *:skipped / !:failed) ! net-p2p/btpd (btpd-0.16_2)(install error) ___ 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 with a broken PKGORIGIN: devel/boost-all, mail/squirrelma...
Am 26.06.2013 um 14:54 schrieb er...@freebsd.org: > ** The following ports have an incorrect PKGORIGIN ** > > PKGORIGIN connects packaged or installed ports to the directory they > originated from. This is essential for tools like pkg_version or > portupgrade to work correctly. Wrong PKGORIGINs are often caused by a > wrong order of CATEGORIES after a repocopy. > > Please fix any errors as soon as possible. > > The ports tree was updated at Wed Jun 26 2013 12:37:04 UTC. > > - *mail/squirrelmail-login_auth-plugin* : > /squirrelmail-login_auth-plugin Thank you for the notice, but I'm not sure what the issue is. portlint reports this: root@diesel:/usr/ports/mail/squirrelmail-login_auth-plugin# portlint WARN: Makefile: CATEGORIES is set externally to this port's Makefile, but this port is not configured as a slave port. 0 fatal errors and 1 warning found. Is this the reason for the change, or did a change to bsd.squirrelmail.mk trigger the warning? Both the plugin ports as well as the main squirrelmail port haven't been updated in months… Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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"
Maintainer update for mail/roundcube-userprefs (was ports/179007: )
Hey, sorry I screwed up the synopsis line; maybe somebody can correct that? Thanks, Stefan Am 27.05.2013 um 10:50 schrieb freebsd-gnats-sub...@freebsd.org: > Thank you very much for your problem report. > It has the internal identification `ports/179007'. > The individual assigned to look at your > report is: freebsd-ports-bugs. > > You can access the state of your problem report at any time > via this link: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=179007 > >> Category: ports >> Responsible:freebsd-ports-bugs >> Synopsis: >> Arrival-Date: Mon May 27 14:50:00 UTC 2013 -- Stefan BethkeFon +49 151 14070811 ___ 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: poudriere builds all dependencies, even if packages have already been built
Am 03.04.2013 um 16:29 schrieb Stefan Bethke : > Am 03.04.2013 um 14:02 schrieb Stefan Bethke: > > (Setup with system ports tree and FTP-installed 9.1-RELEASE excluded) > >> >> Starting jail 91amd64 >> realpath: /freebsd/checkout/ports/distfiles: No such file or directory >> >> Mounting ports from: /freebsd/checkout/ports > > On the second bulk run, the above error did not occur. I successfully built a > complete set of packages, then startd over with -c, interrupted the build > with ^C and continued it, all successfully. > > I'll try and figure out what it was specifically that made it break > beforehand (I was make world-installing 9-stable, and svn co a fresh ports > tree from a local mirror). I've now retraced my steps from yesterday, but can't recreate the problem, so all seems to be fine. When I created a new jail (svn checkout of stable/9), on the first bulk run I got the realpath error again; it seems poudriere fixes it itself? Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: poudriere builds all dependencies, even if packages have already been built
Am 03.04.2013 um 14:02 schrieb Stefan Bethke: (Setup with system ports tree and FTP-installed 9.1-RELEASE excluded) > >> Starting jail 91amd64 > realpath: /freebsd/checkout/ports/distfiles: No such file or directory > >> Mounting ports from: /freebsd/checkout/ports > >> Mounting packages from: > /var/poudriere/data/packages/91amd64-systemports > >> Appending to /etc/make.conf: /root/eisenboot/poudriere.d/make.conf > >> Calculating ports order and dependencies > >> Sanity checking the repository > >> Deleting stale symlinks > >> Cleaning the build queue > >> Hit ctrl+t at any time to see build progress and stats > >> Building 244 packages using 3 builders > ^C > > Not sure what the problem is: > # realpath /freebsd/checkout/ports/distfiles > /freebsd/checkout/ports/distfiles > > And I do have pkg installed in the host: > # pkg_info pkg-* > Information for pkg-1.0.11: > > Comment: > New generation package manager > > > Description: > New Generation package management tool for FreeBSD > > WWW: http://wiki.freebsd.org/pkgng > > # which -a pkg > /usr/sbin/pkg > /usr/local/sbin/pkg > > > I'm letting the build run for a while, and will inspect the logs. On the second bulk run, the above error did not occur. I successfully built a complete set of packages, then startd over with -c, interrupted the build with ^C and continued it, all successfully. I'll try and figure out what it was specifically that made it break beforehand (I was make world-installing 9-stable, and svn co a fresh ports tree from a local mirror). Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: poudriere builds all dependencies, even if packages have already been built
Am 03.04.2013 um 13:30 schrieb Bryan Drewery:
>> I've had some trouble with poudriere not mounting things where they belong.
>> I manually created /usr/ports and /wrkdirs and recreated the "clean"
>> snapshot. This worked around the "mount: no such file or directory"
>> problems, but I guess there might be an underlying cause to these and a
>> couple more issues. How would I go about identifying these? I think I
>> followed the installation instructions very carefully.
>>
>
> I have not heard of these issues and it appears your setup is now messed
> up. None of this manual hacking should be needed. I suggest recreating
> your jail.
OK, sound like a plan.
I'm getting further that I used to, but I do get an error when I try to kick
off the bulk build (which poudriere seems to ignore), see below:
Here's my poudriere.conf:
# egrep -v '^(#.*)?$' /usr/local/etc/poudriere.conf
ZPOOL=tank
FREEBSD_HOST=http://ftp2.de.freebsd.org
RESOLV_CONF=/etc/resolv.conf
BASEFS=/var/poudriere
USE_PORTLINT=no
USE_TMPFS=yes
DISTFILES_CACHE=/freebsd/distfiles
SVN_HOST=mirror.hanse.de
CCACHE_DIR=${BASEFS}/ccache
NO_RESTRICTED=no
According to
https://fossil.etoilebsd.net/poudriere/doc/trunk/doc/use_system_ports_tree.wiki,
I've marked my ports tree zfs:
# zfs get all tank/freebsd/checkout
NAME PROPERTY VALUE SOURCE
tank/freebsd/checkout type filesystem -
...
tank/freebsd/checkout poudriere:namesystemportslocal
tank/freebsd/checkout poudriere:typeports local
Created a jail for 9.1-RELEASE:
# poudriere jail -c -j 91amd64 -v 9.1-RELEASE
cannot open 'tank/poudriere': dataset does not exist
>> Creating 91amd64 fs... done
>> Fetching base.txz for FreeBSD 9.1-RELEASE amd64
/var/poudriere/jails/91amd64/fromftp/base.txz 100% of 57 MB 9122 kBps
>> Extracting base.txz... done
>> Fetching src.txz for FreeBSD 9.1-RELEASE amd64
/var/poudriere/jails/91amd64/fromftp/src.txz 100% of 91 MB 10 MBps
>> Extracting src.txz... done
>> Fetching games.txz for FreeBSD 9.1-RELEASE amd64
/var/poudriere/jails/91amd64/fromftp/games.txz100% of 1091 kB 3878 kBps
>> Extracting games.txz... done
>> Fetching lib32.txz for FreeBSD 9.1-RELEASE amd64
/var/poudriere/jails/91amd64/fromftp/lib32.txz100% of 9515 kB 7865 kBps
>> Extracting lib32.txz... done
>> Cleaning up... done
>> Jail 91amd64 9.1-RELEASE amd64 is ready to be used
# cat /usr/local/etc/poudriere.d/make.conf
# General configuration
WITH_PKGNG=yes
# Port-specific configuration
openvpn_UNSET= EASYRSA
Start building my list of ports:
# poudriere bulk -f poudriere-default-ports -j 91amd64 -J 3 -p systemports
>> Mounting system devices for 91amd64
/etc/resolv.conf -> /var/poudriere/jails/91amd64/etc/resolv.conf
>> Starting jail 91amd64
realpath: /freebsd/checkout/ports/distfiles: No such file or directory
>> Mounting ports from: /freebsd/checkout/ports
>> Mounting packages from: /var/poudriere/data/packages/91amd64-systemports
>> Appending to /etc/make.conf: /root/eisenboot/poudriere.d/make.conf
>> Calculating ports order and dependencies
>> Sanity checking the repository
>> Deleting stale symlinks
>> Cleaning the build queue
>> Hit ctrl+t at any time to see build progress and stats
>> Building 244 packages using 3 builders
^C
Not sure what the problem is:
# realpath /freebsd/checkout/ports/distfiles
/freebsd/checkout/ports/distfiles
And I do have pkg installed in the host:
# pkg_info pkg-*
Information for pkg-1.0.11:
Comment:
New generation package manager
Description:
New Generation package management tool for FreeBSD
WWW: http://wiki.freebsd.org/pkgng
# which -a pkg
/usr/sbin/pkg
/usr/local/sbin/pkg
I'm letting the build run for a while, and will inspect the logs.
Thanks for your help,
Stefan
--
Stefan BethkeFon +49 151 14070811
___
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: poudriere builds all dependencies, even if packages have already been built
Am 03.04.2013 um 12:53 schrieb Bryan Drewery:
> On 4/3/2013 4:17 AM, Stefan Bethke wrote:
>> Firstly, is there a better mailing list to discuss poudriere?
>>
>> I'm just getting my feet wet with poudriere, and are a bit surprised that
>> all dependencies for a port are built, instead of installing the packages
>> that got built earlier already. Is this intentional? Is there a
>> configuration option to have the requisite packages installed before
>> building a port?
>>
>>
>> Thanks,
>> Stefan
>>
>
> Here or pkg@ is fine.
>
> This is exactly what it does. It builds the dependencies one time then
> installs then builds the port needing them. On the next run if the
> dependencies have not updated it reuses them.
That's what I would expect, but that's not what I'm seeing.
I've been running build incrementally, fixing a problem, then running bulk
again. As expected, only the packages that hadn't been built successfully yet
were built. However, dependencies for these ports are not installed from the
already created packages, but are recompiled again. In this build log, you can
see that pkg is installed from the port instead of from the package; I seem to
get this for a large number of builds. I wouldn't really mind except for the
enormous amount of time it takes to rebuild the same ports over and over again.
I've had some trouble with poudriere not mounting things where they belong. I
manually created /usr/ports and /wrkdirs and recreated the "clean" snapshot.
This worked around the "mount: no such file or directory" problems, but I guess
there might be an underlying cause to these and a couple more issues. How
would I go about identifying these? I think I followed the installation
instructions very carefully.
$ head -100 ImageMagick-6.8.0.7_1.log
build started at Wed Apr 3 07:31:08 UTC 2013
port directory: /usr/ports/graphics/ImageMagick
building for: 9.1-STABLE amd64
maintained by: c.petrik.s...@gmail.com
Makefile ident: $FreeBSD: head/graphics/ImageMagick/Makefile 315309
2013-03-26 15:55:59Z bapt $
Poudriere version: 2.4.1
---Begin Environment---
BLOCKSIZE=K
MAIL=/var/mail/root
STATUS=1
PKG_EXT=txz
FORCE_PACKAGE=yes
tpid=97139
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
POUDRIERE_BUILD_TYPE=bulk
NBPARALLEL=4
PKGNG=1
PKG_DELETE=/usr/local/sbin/pkg delete -y -f
PKG_ADD=/usr/local/sbin/pkg add
PWD=/root/eisenboot
LOGS=/var/poudriere/data/logs
HOME=/root
USER=root
SKIPSANITY=0
LOCALBASE=/usr/local
PACKAGE_BUILDING=yes
VERSION=2.4.1
---End Environment---
---Begin make.conf---
/root/eisenboot/poudriere.d/make.conf
WITH_PKGNG=yes
# Das sollte eigentlich poudriere selber machen
WRKDIRPREFIX?= /wrkdirs
WRKDIR?=${WRKDIRPREFIX}${.CURDIR:S/${PORTSDIR}//}
MASTER_SITE_BACKUP?=\
http://mirror.hanse.de/pub/FreeBSD/ports/distfiles/${DIST_SUBDIR}/
MASTER_SITE_OVERRIDE?= ${MASTER_SITE_BACKUP}
# Port-Konfiguration
openvpn_UNSET= EASYRSA
PACKAGE_BUILDING=yes
DISABLE_MAKE_JOBS=yes
---End make.conf---
---Begin OPTIONS List---
===> The following configuration options are available for
ImageMagick-6.8.0.7_1:
16BIT_PIXEL=on: 16bit pixel support
BZIP2=on: bzip2 compression support
DJVU=off: DJVU format support (needs THREADS)
DOCS=on: Build and/or install documentation
FFTW=on: Discrete Fourier Transform support
FONTCONFIG=on: X11 font configuration support
FPX=on: FlashPix image format support
FREETYPE=on: TrueType font rendering support
GRAPHVIZ=off: Graphviz support
GSLIB=off: libgs (Postscript SHLIB) support
HDRI=off: High dynamic range images support
JASPER=on: JPEG 2000 support via JasPer
JBIG=on: JBIG image format support
JPEG=on: JPEG image format support
LCMS2=on: LCMS2 support
LQR=on: Liquid Rescale support
LZMA=on: LZMA compression support
MODULES=on: Modules support
OPENEXR=off: HDR image format support via OpenEXR
OPENMP=off: Parallel processing support via OpenMP
PANGO=off: Pango rendering library support
PDF=on: PDF document support
PERL=on: Perl scripting language support
PNG=on: PNG image format support
SVG=on: SVG vector image format support
TESTS=off: Run bundled self-tests after build
THREADS=off: Threading support
TIFF=on: TIFF image format support
WEBP=on: WebP image format support
WMF=on: Windows Metafile support
===> Use 'make config' to modify these settings
---End OPTIONS List---
=
===> ImageMagick-6.8.0.7_1 depends on file: /usr/local/sbin/pkg - not found
===>Verifying install for /usr/local/sbin/pkg in /usr/ports/ports-mgmt/pkg
===> License BSD accepted by the user
===> Fetching all distfiles
poudriere builds all dependencies, even if packages have already been built
Firstly, is there a better mailing list to discuss poudriere? I'm just getting my feet wet with poudriere, and are a bit surprised that all dependencies for a port are built, instead of installing the packages that got built earlier already. Is this intentional? Is there a configuration option to have the requisite packages installed before building a port? Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: pam_ssh_agent_auth: ENOENT
Am 26.03.2013 um 17:25 schrieb Martin Wilke : > Hey > > Please test the new patch. @ Stefan thx for the PR. > > http://people.freebsd.org/~miwi/psaa.diff Seems to be working just fine! Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: pam_ssh_agent_auth: ENOENT
Am 27.02.2013 um 09:01 schrieb Dimitry Andric : > On 2013-02-27 00:39, Stefan Bethke wrote: > ... >> openbsd-compat/vis.h is #ifdef'd HAVE_STRNVIS, so we check configure. >> configure.log thinks we have a suitable strnvis: >> >> configure:16566: checking for strnvis >> configure:16622: cc -o conftest -O2 -pipe -fno-strict-aliasing -fPIC -Wall >> -Wpointer-arith -Wuninitialized -Wsign-compare -Wno-pointer-sign >> -fstack-protector-all -fstack-protector-all conftest.c -lutil -lpam >&5 >> configure:16629: $? = 0 >> configure:16651: result: yes >> >> >> Do we? > > We have strnvis(), but it is not suitable. We got strnvis() from > NetBSD, and its arguments are in a different order from OpenBSD's > version. See the archive for earlier discussions (and crash reports :) > about this. > > I recommend adding the line: > > CONFIGURE_ENV=ac_cv_func_strnvis=no > > to the port Makefile, just as with security/openssh-portable. Ah, neat, I didn't know you could do that in a Makefile. I've just submitted ports/176469 with a patch to configure, but this much nicer. http://www.freebsd.org/cgi/query-pr.cgi?pr=176469 Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: pam_ssh_agent_auth: ENOENT
> Looks like the port is still broken if compiled on a 9-STABLE system
> with new vis(3) functions included. Compiling it on a 9.1-RELEASE
> system produces a working package. I use devel/poudriere-devel for
> compiling packages and I didn't test the port by compiling it
> manually.
I did some prodding, and it would appear the .so can't be loaded because of a
missing symbol:
#include
#include
#include
#include
int
main(void)
{
void *dlh;
dlh = dlopen("/usr/local/lib/pam_ssh_agent_auth.so", RTLD_NOW);
if (dlh == NULL)
errx(EX_OSERR, "dlopen(): %s", dlerror());
return 0;
}
$ ./dltest
dltest: dlopen(): /usr/local/lib/pam_ssh_agent_auth.so: Undefined symbol
"pamsshagentauth_strnvis"
The code in the test program is similar to the code in
src/contrib/openpam/lib/openpam_dynamic.c::openpam_dynamic().
Looking at the Makefiles, it seems that openbin-compat/vis.c should end up in
libopenbsd-compat.a, and that in turn should get linked into the module, but:
# nm --defined-only openbsd-compat/libopenbsd-compat.a
...
strtonum.o:
T pamsshagentauth_strtonum
strtoul.o:
vis.o:
port-aix.o:
...
openbsd-compat/vis.h is #ifdef'd HAVE_STRNVIS, so we check configure.
configure.log thinks we have a suitable strnvis:
configure:16566: checking for strnvis
configure:16622: cc -o conftest -O2 -pipe -fno-strict-aliasing -fPIC -Wall
-Wpointer-arith -Wuninitialized -Wsign-compare -Wno-pointer-sign
-fstack-protector-all -fstack-protector-all conftest.c -lutil -lpam >&5
configure:16629: $? = 0
configure:16651: result: yes
Do we? Then the hard-coded use in log.c needs to be changed. If FreeBSD's
strnvis is not compatible, then the configure test needs to be fixed. Attached
is a (dirty) patch to make that change to log.c; not sure if this is the
correct way. Maybe use __FreeBSD_version instead.
Stefan
--
Stefan BethkeFon +49 151 14070811
--- log.c.orig 2012-06-28 03:47:49.0 +0200
+++ log.c 2013-02-27 00:32:38.063952580 +0100
@@ -361,8 +361,13 @@
vsnprintf(msgbuf, sizeof(msgbuf), fmtbuf, args);
}
+#if defined(__FreeBSD__)
+ strnvis(fmtbuf, sizeof(fmtbuf), msgbuf,
+ log_on_stderr ? LOG_STDERR_VIS : LOG_SYSLOG_VIS);
+#else
pamsshagentauth_strnvis(fmtbuf, msgbuf, sizeof(fmtbuf),
log_on_stderr ? LOG_STDERR_VIS : LOG_SYSLOG_VIS);
+#endif
if(level == SYSLOG_LEVEL_FATAL) {
snprintf(msgbuf, sizeof msgbuf, "%s\r\nThis incident has been
reported to the authorities\r\n", fmtbuf);
___
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"
pam_ssh_agent_auth: ENOENT
Am 20.02.2013 um 16:34 schrieb Kimmo Paasiala : > On Wed, Feb 6, 2013 at 12:28 AM, Stefan Bethke wrote: >> >>> I can confirm that with the new port version on a two day old current, the >>> module doesn't work: >>> $ uname -a >>> FreeBSD freebsd-current.lassitu.de 10.0-CURRENT FreeBSD 10.0-CURRENT #0 >>> r246283: Sun Feb 3 16:55:16 CET 2013 >>> r...@freebsd-current.lassitu.de:/usr/obj/usr/src/sys/GENERIC amd64 >>> $ pkg info|grep pam >>> pam_ssh_agent_auth-0.9.4 PAM module which permits authentication via >>> ssh-agent >>> $ sudo ls >>> sudo: unable to initialize PAM: No error: 0 >>> >>> If I downgrade to the previous port version (and apply Kimmo's patch), it's >>> working properly. >> >> >> Here's a slightly different error message on 9-stable: >> $ uname -a >> FreeBSD diesel.lassitu.de 9.1-STABLE FreeBSD 9.1-STABLE #7 r245996: Sun Jan >> 27 22:36:05 CET 2013 r...@diesel.lassitu.de:/usr/obj/usr/src/sys/DIESEL >> amd64 >> stb@diesel:~$ sudo ls >> sudo: unable to initialize PAM: No such file or directory > > Latest version pam_ssh_agent_auth-0.9.4_1 seems to finally work > without any extra patches when built on a 9.1-RELEASE system. Hhm, with a 9.1-stable from this morning, I'm still getting ENOENT. Can you spot anything different in my setup? My /usr/local/etc/pam.d/sudo looks like this: # # PAM configuration for the "sudo" service # # auth authsufficient /usr/local/lib/pam_ssh_agent_auth.so file=~/.ssh/authorized_keys authinclude system # account account include system # session # XXX: pam_lastlog (used in system) causes users to appear as though # they are no longer logged in in system logs. session requiredpam_permit.so # password passwordinclude system /var/log/messages reports: Feb 25 17:41:01 lokschuppen sudo: in openpam_load_module(): no /usr/local/lib/pam_ssh_agent_auth found Feb 25 17:41:01 lokschuppen sudo: stb : unable to initialize PAM : No such file or directory ; TTY=pts/0 ; PWD=/root/eisenboot ; USER=root ; COMMAND=/bin/ls # ls -l /usr/local/lib/pam_ssh_agent_auth.so -rwxr-xr-x 1 root wheel 100194 Feb 25 08:48 /usr/local/lib/pam_ssh_agent_auth.so* # pkg_info|grep pam_ssh pam_ssh_agent_auth-0.9.4_1 PAM module which permits authentication via ssh-agent # ldd /usr/local/lib/pam_ssh_agent_auth.so /usr/local/lib/pam_ssh_agent_auth.so: libcrypto.so.6 => /lib/libcrypto.so.6 (0x801214000) libutil.so.9 => /lib/libutil.so.9 (0x8015bc000) libpam.so.5 => /usr/lib/libpam.so.5 (0x8017cf000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x8019d7000) libc.so.7 => /lib/libc.so.7 (0x80081b000) What other reasons could PAM have to report ENOENT? This is the same configuration that used to work with the earlier version. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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"
Please commit ports/176207
Hi, if any ports committer would be willing to commit the maintainer's patch in ports/176207, I'd appreciate it! Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: stable/9 r245439 breaks security/pam_ssh_agent_auth on stable/9 (WAS: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9)
Am 05.02.2013 um 23:06 schrieb Stefan Bethke : > Am 05.02.2013 um 19:09 schrieb Kimmo Paasiala : > >> On Tue, Feb 5, 2013 at 12:36 AM, Kimmo Paasiala wrote: >>> On Sun, Feb 3, 2013 at 7:22 PM, Chris Rees wrote: >>>> On 3 February 2013 17:15, Stefan Bethke wrote: >>>>> >>>>> Am 03.02.2013 um 10:57 schrieb Chris Rees : >>>>> >>>>>> On 3 February 2013 03:55, Kimmo Paasiala wrote: >>>>>>> >>>>>>> There is no PR yet with my fix and therefor no commit to ports tree >>>>>>> that would fix the problem. I'll file a PR soon (TM). >>>>>> >>>>>> The problem was in base, and is fixed there. >>>>> >>>>> Huh? With -current r246283, I still get a segfault from sudo unless I >>>>> have Kimmo's patch. >>>>> >>>>> Is there some confusion about which problem is addressed by Kimmo's patch? >>>>> >>>> >>>> Hm, perhaps it might be necessary then. >>>> >>>> Kimmo, please would you submit the patch you had as a PR? I'm sure >>>> Wesley would appreciate the hint. >>>> >>>> Chris >>> >>> I'll file a PR when I have recovered from a nasty flu. Right now I'm >>> not fit for thinking... >>> >>> I changed the title of this thread to a better one. >>> >>> -Kimmo >> >> It looks like the port was updated just recently to a new version that >> has its own problems that are no longer related strnvis(3). I'll have >> to give up for now. >> >> (freebsd-ports added to cc:) > > I can confirm that with the new port version on a two day old current, the > module doesn't work: > $ uname -a > FreeBSD freebsd-current.lassitu.de 10.0-CURRENT FreeBSD 10.0-CURRENT #0 > r246283: Sun Feb 3 16:55:16 CET 2013 > r...@freebsd-current.lassitu.de:/usr/obj/usr/src/sys/GENERIC amd64 > $ pkg info|grep pam > pam_ssh_agent_auth-0.9.4 PAM module which permits authentication via > ssh-agent > $ sudo ls > sudo: unable to initialize PAM: No error: 0 > > If I downgrade to the previous port version (and apply Kimmo's patch), it's > working properly. Here's a slightly different error message on 9-stable: $ uname -a FreeBSD diesel.lassitu.de 9.1-STABLE FreeBSD 9.1-STABLE #7 r245996: Sun Jan 27 22:36:05 CET 2013 r...@diesel.lassitu.de:/usr/obj/usr/src/sys/DIESEL amd64 stb@diesel:~$ sudo ls sudo: unable to initialize PAM: No such file or directory Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: stable/9 r245439 breaks security/pam_ssh_agent_auth on stable/9 (WAS: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9)
Am 05.02.2013 um 19:09 schrieb Kimmo Paasiala : > On Tue, Feb 5, 2013 at 12:36 AM, Kimmo Paasiala wrote: >> On Sun, Feb 3, 2013 at 7:22 PM, Chris Rees wrote: >>> On 3 February 2013 17:15, Stefan Bethke wrote: >>>> >>>> Am 03.02.2013 um 10:57 schrieb Chris Rees : >>>> >>>>> On 3 February 2013 03:55, Kimmo Paasiala wrote: >>>>>> >>>>>> There is no PR yet with my fix and therefor no commit to ports tree >>>>>> that would fix the problem. I'll file a PR soon (TM). >>>>> >>>>> The problem was in base, and is fixed there. >>>> >>>> Huh? With -current r246283, I still get a segfault from sudo unless I have >>>> Kimmo's patch. >>>> >>>> Is there some confusion about which problem is addressed by Kimmo's patch? >>>> >>> >>> Hm, perhaps it might be necessary then. >>> >>> Kimmo, please would you submit the patch you had as a PR? I'm sure >>> Wesley would appreciate the hint. >>> >>> Chris >> >> I'll file a PR when I have recovered from a nasty flu. Right now I'm >> not fit for thinking... >> >> I changed the title of this thread to a better one. >> >> -Kimmo > > It looks like the port was updated just recently to a new version that > has its own problems that are no longer related strnvis(3). I'll have > to give up for now. > > (freebsd-ports added to cc:) I can confirm that with the new port version on a two day old current, the module doesn't work: $ uname -a FreeBSD freebsd-current.lassitu.de 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r246283: Sun Feb 3 16:55:16 CET 2013 r...@freebsd-current.lassitu.de:/usr/obj/usr/src/sys/GENERIC amd64 $ pkg info|grep pam pam_ssh_agent_auth-0.9.4 PAM module which permits authentication via ssh-agent $ sudo ls sudo: unable to initialize PAM: No error: 0 If I downgrade to the previous port version (and apply Kimmo's patch), it's working properly. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: mysql-client-5.5.10 fails to install properly, breaking all dependant ports
Am 20.03.2011 um 22:43 schrieb Alex Dupre: > Stefan Bethke ha scritto: >> In my particular case, the umask is set to 0002 instead of the default 0022 > > http://lists.freebsd.org/pipermail/freebsd-ports/2007-September/043529.html > >> I've updated my portupgrade script to reset the umask to avoid similar >> problems > > Correct way to install ports. Won't argue with Kris, but I still think that the login shell from which I initiate a port build should have limited, well-documented effects on the result of that build, and with most ports, that is the case. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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"
mysql-client-5.5.10 fails to install properly, breaking all dependant ports
Since last year, updates to mysql-client-5.5.x kept breaking all dependant
ports, including the server itself. Apparently, the client library could not
be located, thus triggering a re-install of the client, which failed because
the client was already installed. At the same time, the old binaries would not
be able to find the client library, because the so version had been bumped.
I finally found the culprit, after trying to replicate the situation in a
sandbox (instead of on my main mail server): the ${PREFIX)/lib/mysql dir is
created with the standard umask, instead of overriding the bits.
In my particular case, the umask is set to 0002 instead of the default 0022,
leaing to a lib dir with rwxrwxr-x. ldconfig(8) refuses to take libs from
group-writable directories.
It appears that the mkdir for this dir is somewhere inside the install target
of MySQL, so I'n not certain what the easiest way would be to fix the
permission bits.
I've updated my portupgrade script to reset the umask to avoid similar problems
Stefan
--
Stefan BethkeFon +49 151 14070811
___
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: mysql-client-5.58 breaks postfix, dovecot
Am 28.12.2010 um 13:57 schrieb Stefan Bethke: > Just a quick warning since I just spent an hour figuring out why my mail > server broke: with the upgrade to mysql-client-5.5.8, postfix and dovecot > stop working. It appears that the lastest mysql-client-5.5.8_2, postfix and dovecot are working again. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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"
mysql-client-5.58 breaks postfix, dovecot
Just a quick warning since I just spent an hour figuring out why my mail server broke: with the upgrade to mysql-client-5.5.8, postfix and dovecot stop working. This is: FreeBSD gilb.zs64.net 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #32: Mon Nov 29 23:10:07 UTC 2010 r...@lokschuppen.zs64.net:/usr/obj/usr/src/sys/EISENBOOT amd64 Dovecot has trouble running the auth process: Dec 28 12:40:13 gilb dovecot: dovecot: Fatal: Auth process died too early - shutting down and lots of Dec 28 12:49:23 gilb dovecot: child 57253 (auth-worker) killed with signal 11 (core not dumped) postfix emitted messages like: Dec 28 12:36:51 gilb postfix/trivial-rewrite[44173]: fatal: proxy:mysql:/usr/local/etc/postfix/mysql_virtual_alias_maps.cf(0,lock|fold_fix): table lookup problem Dec 28 12:40:04 gilb postfix/cleanup[45936]: warning: 7F9BC680E: virtual_alias_maps map lookup problem for ad...@zs64.net I've downgraded to mysql-client-5.5.7 (but left the server at 5.5.8, since I had mysql_upgrade'd it already). Things appear to be back in working order. Here's the relevant packages currently installed: dovecot-managesieve-0.11.12 Dovecot ManageSieve Server daemon dovecot-sieve-1.2+0.1.18 A Sieve plugin for the Dovecot 'deliver' LDA mysql-client-5.5.7 Multithreaded SQL database (client) mysql-server-5.5.8 Multithreaded SQL database (server) postfix-2.7.2,1 A secure alternative to widely-used Sendmail -- Stefan BethkeFon +49 151 14070811 ___ 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"
devel/pecl-intl: what's up?
I'm trying to upgrade roundcube, and pecl-intl isn't building. Removing the IGNORE shows a number of linker errors. I found PR#153438 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=153438 suggesting that the patches are no longer needed. Removing them makes the build complete successfully. The resulting roundcube seems to be running fine, as well as other PHP apps I have on the same box (mediawiki). Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: sysutils/screen fails to build
Am 05.08.2010 um 23:32 schrieb Cy Schubert: > I'm in Newfoundland at the moment and will return home on Aug 17. I'll > look at this when I return. I finally got around figuring out why the screen update was failing on just this one box, while all my other -stables are just fine. The problem was an accidental upgrade to -current on that box, followed by a downgrade to -stable, back in May. Apparently, some -current includes and libraries are still hanging around, and are picked up by configure, specifically libulog and libutempter, but they are referencing symbols not available in the -stable libs. Sorry to bother you, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: [Netatalk-admins] RFT: netatalk-2.1
I've uploaded a new version of the FreeBSD port for netatalk 2.1.1, available at http://www.lassitu.de/freebsd/netatalk/netatalk-2.1.1-3.tar.bz2 A new build option WITH_APPLETALK (default: off) will build all AppleTalk-related programs, utilities, man pages, etc. By default, nothing that requires AppleTalk is built and installed; afpd is built without support for DDP. When building with PAM support, a suitable pam config file will be installed to $PREFIX/etc/pam.d/netatalk. Command line options for the various daemons are now configured through the standard rc.conf mechanism (afpd_flags, atalkd_flags, etc.) instead of through $PREFIX/etc/netatalk.conf. The main netatalk_enable knob is gone. To run the file server successfully, you should set afpd_enable="YES" and cnid_metad_enable="YES" in /etc/rc.conf. All five port config options compile successfully on FreeBSD 8.1-PRERELEASE, but I have only tested afpd with and without PAM; Kerberos, AppleTalk and Timelord support are untested. Enjoy, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: RFT: netatalk-2.1
Am 28.05.2010 um 08:27 schrieb Stefan Bethke: > Am 22.05.2010 um 19:08 schrieb Stefan Bethke: > >> Hi, >> >> I'm working on updating the net/netatalk port from 2.0.5 to 2.1. You can >> find the most current version of my work at >> http://www.lassitu.de/freebsd/netatalk/ >> >> Initial testing looks promising. There's one outstanding issue: upgrading >> from 2.0.5 to 2.1 appears to fail because of the wrong order of include >> paths. You can work around this by deinstalling 2.0.5 before building the >> new version. >> >> This work is also being tracked in PR#146576. > > I've uploaded new version which I believe to be committable: > http://www.lassitu.de/freebsd/netatalk/netatalk_2.1.1-1.tar.bz2 > > I have not tested Kerberos support since I'm lacking the environment. > > If your system has IPv6 configured, you will need to configure a server each > for IPv4 and IPv6. Note that both afpd and cnid_metad will by default bind > to IPv6 addresses. > The newest tarball 2.1.1-2 contains a patch to fix a segfault when having more than one afpd configured, thanks to Frank Lahm. To have afpd listen to both IPv4 and IPv6, you need to either have two server entries in afpd.conf, i.e.: - -tcp -noddp -ipaddr 0.0.0.0 -unixcodepage UTF8 -signature user:freebsd8 -cnid_server ::1 "ipv6" -tcp -noddp -ipaddr :: -unixcodepage UTF8 -signature user:freebsd8 -cnid_server ::1 or set the sysctl net.inet6.ip6.v6only=0. Note that the latter might have negative security implications. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: RFT: netatalk-2.1
Am 22.05.2010 um 19:08 schrieb Stefan Bethke: > Hi, > > I'm working on updating the net/netatalk port from 2.0.5 to 2.1. You can > find the most current version of my work at > http://www.lassitu.de/freebsd/netatalk/ > > Initial testing looks promising. There's one outstanding issue: upgrading > from 2.0.5 to 2.1 appears to fail because of the wrong order of include > paths. You can work around this by deinstalling 2.0.5 before building the > new version. > > This work is also being tracked in PR#146576. I've uploaded new version which I believe to be committable: http://www.lassitu.de/freebsd/netatalk/netatalk_2.1.1-1.tar.bz2 I have not tested Kerberos support since I'm lacking the environment. If your system has IPv6 configured, you will need to configure a server each for IPv4 and IPv6. Note that both afpd and cnid_metad will by default bind to IPv6 addresses. Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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"
RFT: netatalk-2.1
Hi, I'm working on updating the net/netatalk port from 2.0.5 to 2.1. You can find the most current version of my work at http://www.lassitu.de/freebsd/netatalk/ Initial testing looks promising. There's one outstanding issue: upgrading from 2.0.5 to 2.1 appears to fail because of the wrong order of include paths. You can work around this by deinstalling 2.0.5 before building the new version. This work is also being tracked in PR#146576. HTH, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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"
Apache 2.0.63_8 compiles, but does not run
One of the commits to www/apache20 in the past 24 hours breaks the port. See PR#146393 http://www.freebsd.org/cgi/query-pr.cgi?pr=146393 Downgrading to a revision from 2010-05-07 00:00 UTC or earlier works around this. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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"
ISC DHCP 4?
When I was looking for ISC DHCP server version 4 or newer, I was surprised that I didn't find any port. Am I looking for the wrong thing, or is 3.1 really the newest version in ports? What are people using for IPv6? Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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"
May I direct a committers attention to PR ports/137731?
Hi, would one of you mind taking a look at PR ports/137731? Thanks, Stefan -- Description: HAL integration of the vmmouse driver currently has two issues: - In the FDI file, the match element key="input.originating_device" contains="i8042_AUX_port" does not match on FreeBSD, so the the callout is never added, and the driver never activated. - The callout script uses hal-set-property --direct, which is not available in hal-0.5.10, the current port version of hal. How-To-Repeat: Try moving the mouse outside the VMware window. Fix: This patch forces the usage of the VMware mouse driver. Once hal-0.5.12 or newer is in ports, this patch should be changed to add the callout again. x11-drivers/xf86-input-vmmouse/files/patch-fdi-11-x11-vmmouse.fdi: --- fdi/11-x11-vmmouse.fdi 2008-12-16 23:41:13.0 +0100 +++ /root/11-x11-vmmouse.fdi2009-08-13 18:35:17.0 +0200 @@ -2,8 +2,8 @@ - - hal-probe-vmmouseappend> + + vmmouse -- Stefan BethkeFon +49 151 14070811 ___ 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: PHP gd issues
Am 05.08.2009 um 12:11 schrieb Stefan Bethke: Am 23.07.2009 um 10:44 schrieb mediaslut von abfab: I had the same fatallibpngerror discovered yesterday. It seems like libpng version 1.2.37 was buggy. And version 1.2.38 is not available yet on FreeBSD Ports (although, I don't know if this bug is fixed in this version?). I have downgraded to version 1.2.35 and the error has gone away. I just ran into this problem through WordPress. I can't find any PR referencing this, and I don't see ache@ or dinoex@ cc'ed... png-mng-implement has a reference to this issue: <http://sourceforge.net/mailarchive/forum.php?thread_name=e56ccc8f0907230957y2dce7077rb5388d71af762cde%40mail.gmail.com&forum_name=png-mng-implement > I don't have the time to do any analysis myself (not before the weekend anyway), so if any of you could take a look, I'd be most grateful. Updating the port to png-1.2.38 (and restarting the web server) fixed the issue for me. Thanks! Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: PHP gd issues
Am 23.07.2009 um 10:44 schrieb mediaslut von abfab: I had the same fatallibpngerror discovered yesterday. It seems like libpng version 1.2.37 was buggy. And version 1.2.38 is not available yet on FreeBSD Ports (although, I don't know if this bug is fixed in this version?). I have downgraded to version 1.2.35 and the error has gone away. I just ran into this problem through WordPress. I can't find any PR referencing this, and I don't see ache@ or dinoex@ cc'ed... png-mng-implement has a reference to this issue: <http://sourceforge.net/mailarchive/forum.php?thread_name=e56ccc8f0907230957y2dce7077rb5388d71af762cde%40mail.gmail.com&forum_name=png-mng-implement > I don't have the time to do any analysis myself (not before the weekend anyway), so if any of you could take a look, I'd be most grateful. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: recent change to ifconfig breaks OpenVPN?
Am 01.08.2009 um 17:24 schrieb Julian Elischer: Stefan Bethke wrote: (Moving the discussion to -ports.) Am 31.07.2009 um 00:57 schrieb Matthias Andree: Am 31.07.2009, 00:36 Uhr, schrieb Bjoern A. Zeeb >: Yeah that is as great as we are or rather were. So really, fix the openvpn scripts that assign the address to interfaces to do something that would make sense from the ``man ip'' (not the literal command) point of view. Just that it's "working" somewhere or used to work elswhere neither means that it was correct nor made sense at any time before. It's actually in the C code where it was advertised as FreeBSD fix. OpenVPN runs in 'topology subnet' mode here, which is documented as follows: Use a subnet rather than a point-to-point topology by configuring the tun interface with a local IP address and subnet mask, similar to the topology used in --dev tap and ethernet bridging mode. This mode allocates a single IP address per con- necting client [... MS-Windows stuff here ...] When used on *nix, requires that the tun driver supports an ifconfig(8) command which sets a subnet instead of a remote endpoint IP address. I wonder if TUNSIFMODE (see tun(4)) is somehow needed and if so, already done, and how the proper ifconfig call would look like in this case. Stefan already uttered some ideas in that direction. Here's a first draft at a patch for OpenVPN. With this, the tun interface gets set to IFF_BROADCAST mode. One small piece is still missing: OpenVPN tries to install a route for the subnet, but that fails because now ifconfig has already inserted that route. I'll try to look into that a bit later on. I also haven't tested the server side yet, or any other mode. I would have thought that the correct answer would be to set a different address for the remote end.. it is a p2p link so to make it look like an ethernet is a bit weird. Windows does not have p2p interfaces, so OpenVPN offers a "virtual ethernet" configuration where the OpenVPN server process routes packets between various clients inside this subnet. Looking from the outside, this --topology subnet mode is not a point to point link, but rather a broadcast network, and even before, OpenVPN installed a network route going over the p2p tun interface. This change aligns the configuration with the actual model OpenVPN uses. Other --topology modes continue to use p2p mode, and the interface is configured with the server's address. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: recent change to ifconfig breaks OpenVPN?
Am 31.07.2009 um 18:58 schrieb Stefan Bethke: Am 31.07.2009 um 14:38 schrieb Stefan Bethke: Here's a first draft at a patch for OpenVPN. With this, the tun interface gets set to IFF_BROADCAST mode. One small piece is still missing: OpenVPN tries to install a route for the subnet, but that fails because now ifconfig has already inserted that route. I'll try to look into that a bit later on. I also haven't tested the server side yet, or any other mode. The route for the subnet is pushed by the server (expanded from the --server config option). Although adding the route fails, the connection process continues and the connection is working fine. Making either the client ignore the pushed route or the server not push the route would be rather intrusive, so I think leaving it at this should be acceptable. Will continue testing... I've tested the patch on -stable and -current, with --topology subnet and --topology net30, in client and server modes, and everything seems to be working fine. From my point of view, this can be committed. I will submit the patch to James Yonan and the openvpn-developers list for inclusion. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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"
