Re: FreeBSD Port: rubygem-passenger-4.0.41_2
On Fri, Apr 11, 2014 at 5:51 PM, Steven Hartland
kill...@multiplay.co.uk wrote:
The change is from :N - :M
.if ${PORT_OPTIONS:MDEBUG}
- Select only those words that match DEBUG
Which occurs 220 in the port tree and:
.if ${PORT_OPTIONS:NDEBUG}
- Select words that don't match DEBUG
Which only occurs twice, so TBH I assumed it was a typo given every other
option uses PORTOPTIONS:M${option}
Unfortunately the docs don't seem to provide any clarification
http://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html
so if anyone could chime in with some details on the exact meanings that
would be most appreciated.
You have to read the make(1) man page:
http://www.freebsd.org/cgi/man.cgi?query=makesektion=1
___
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: Port: net-p2p/zetacoin
On Fri, Apr 11, 2014 at 6:03 PM, Daniel Morante dan...@morante.net wrote:
I'm updating the port and at the same time making some changes to the rc.d
start up script.
I have added the option to change the user that zetacoind runs as:
: ${zetacoin_user=root}
: ${zetacoin_group=wheel}
zetacoin_create_datadir()
{
echo Creating data directory
eval mkdir -p ${zetacoin_datadir}
[ $? -eq 0 ] chown -R ${zetacoin_user}:${zetacoin_group}
${zetacoin_datadir}
ln -s ${zetacoin_datadir} /.zetacoin
}
I'm not sure if I should leave it defaulting to root/wheel or have the port
create a zetacoin user and group and have it use that to begin with.
It's better to have less things run as root/wheel. Especially if the
zetacoind daemon can be run as a different user.
Should I just let the end user make that decision?
The port maintainer should make this decision to switch the user/group
to zetacoin.
The problem I see with defaulting to a zetacoin user is that existing
installations will need to manually change the owner and group of the data
directory.
Thoughts?
You just have to prepare a note for UPDATING that says that the
zetacoind daemon is now run as user zetacoin, and that existing
installations will need to change the owner/group to zetacoin for the
data directory.
--
DISCLAIMER:
No electrons were maimed while sending this message. Only slightly bruised.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ audio/pd| 0.45-4 | 0.45-5 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[QAT] 351087: 4x leftovers
- Update to 1.4.2 - Build ID: 20140412112601-51059 Job owner: t...@freebsd.org Buildtime: 18 minutes Enddate: Sat, 12 Apr 2014 11:44:20 GMT Revision: 351087 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=351087 - Port:devel/R-cran-foreach 1.4.2 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~t...@freebsd.org/20140412112601-51059-316570/R-cran-foreach-1.4.2.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~t...@freebsd.org/20140412112601-51059-316571/R-cran-foreach-1.4.2.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~t...@freebsd.org/20140412112601-51059-316572/R-cran-foreach-1.4.2.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~t...@freebsd.org/20140412112601-51059-316573/R-cran-foreach-1.4.2.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140412112601-51059 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: print/cups: since update to 1.7.1: error : Send-Document client-error-document-format-not-supported
On Fri, 11 Apr 2014 19:09:13 +0400 Boris Samorodov b...@passap.ru wrote: 11.04.2014 15:08, O. Hartmann пишет: On Wed, 09 Apr 2014 02:23:58 +0400 Boris Samorodov b...@passap.ru wrote: 09.04.2014 00:25, O. Hartmann пишет: On Tue, 08 Apr 2014 23:16:33 +0400 Boris Samorodov b...@passap.ru wrote: 08.04.2014 17:42, O. Hartmann пишет: Since the update of print/cups from 1.5.X to 1.7.1 How did you do it? As it is reported in /usr/ports/UPDATING. I delete first cups-image, then did the update which reeled in all the new stuff automatically. OK, lets start from some obvious things. Did you restart cupsd while experimenting? No. Given you have cupsd running at this mere system, it may be a good idea to restart it after printer/cups-base update(s). Give an output for: - % type lpr lpr is /usr/local/bin/lpr pkg which /usr/local/bin/lpr /usr/local/bin/lpr was installed by package cups-base-1.7.1 % ls -l /usr/local/etc/cups -r--r--r-- 1 root wheel 2807 11 Apr 11:58 cups-browsed.conf -rw-r- 1 root cups 3197 8 Apr 17:15 cups-files.conf -rw-r- 1 root cups 3197 8 Apr 17:15 cups-files.conf.bak -rw-r- 1 root wheel 3137 11 Apr 12:02 cups-files.conf.sample -r--r--r-- 1 root wheel 9521 11 Apr 11:50 cups-pdf.conf -r--r--r-- 1 root wheel 9521 11 Apr 11:50 cups-pdf.conf.sample -rw-r- 1 root cups 3442 8 Apr 17:22 cupsd.conf -rw-r- 1 root cups 5098 8 Apr 17:20 cupsd.conf.O -rw-r- 1 root cups 3442 8 Apr 17:22 cupsd.conf.bak -rw-r- 1 root wheel 4492 11 Apr 12:02 cupsd.conf.default -r--r--r-- 1 root wheel 4492 11 Apr 12:02 cupsd.conf.sample drwxr-xr-x 2 root wheel 512 11 Apr 12:02 interfaces -r--r--r-- 1 root wheel 1875 8 Apr 19:17 mime.convs -r--r--r-- 1 root wheel 1874 11 Apr 12:02 mime.convs.sample -r--r--r-- 1 root wheel 6456 8 Apr 19:18 mime.types -r--r--r-- 1 root wheel 6455 11 Apr 12:02 mime.types.sample Seems that you commented out a line at mime.* files. drwxr-xr-x 2 root cups512 11 Apr 12:02 ppd -rw--- 1 root cups 4134 8 Apr 17:33 printers.conf -rw--- 1 root cups 4134 8 Apr 14:58 printers.conf.O -rw--- 1 root cups 4134 8 Apr 17:22 printers.conf.bak -rw-r--r-- 1 root cups946 11 Apr 11:53 pstoraster.convs -r--r--r-- 1 root wheel 778 11 Apr 12:04 pstotiff.convs -r--r--r-- 1 root wheel 2084 11 Apr 12:04 pstotiff.types -r--r--r-- 1 root wheel 284 11 Apr 11:49 snmp.conf -r--r--r-- 1 root wheel 284 11 Apr 12:02 snmp.conf.sample drwx-- 2 root cups512 11 Apr 12:02 ssl % make -C /usr/ports/print/cups-client pretty-print-config -GNUTLS (whoops ... this is not the default, isn't it?) As for me, it is the default. But I don't think the problem is here. == corrected that with a new recompilation with rmconfig preceded. % grep CUPS /etc/make.conf NULL (menas: no output) % pkg info -x cups hp foo gut cups-base-1.7.1 cups-client-1.7.1 cups-filters-1.0.52 cups-image-1.7.1 cups-pdf-2.6.1_1 cups-pstoraster-8.15.4_7 cups-samba-6.0_7 gutenprint-cups-5.2.8_1 libgnomecups-0.2.3_5,1 linux-f10-cups-libs-1.3.11_1 foomatic-db-hpijs-1.4 hplip-3.14.1 kdevelop-php-1.6.0_1 kdevelop-php-docs-1.6.0_1 php5-5.4.27 swhplugins-0.4.15_4 foomatic-db-20140331 foomatic-db-engine-4.0.11,2 foomatic-db-hpijs-1.4 foomatic-filters-4.0.17 gimp-gutenprint-5.2.8 gutenprint-base-5.2.8 gutenprint-cups-5.2.8_1 gutenprint-ijs-5.2.8 - OK, you have quite a few cups ports. Stop cupsd, move temporary /var/log/cups/*_log to another location. Start cupsd and look for suspicious messages at /var/log/cups/* files. Nothing suspicious so far. With print/cups-filters installed, the whole cups printing system is corrupted and doesn't print a single sheet of paper (PDF/PS) normal es expected. Prior to this task, I recompiled, as you suggested, first all cups ports and afterwards hplip/foomatic. I also installed print/cups-filters before recompiling hplip/foomatic. Hm. As for me, I can't build hplip with new cups* ports: - === Installing for cups-base-1.7.1 === Checking if print/cups-base already installed === cups-base-1.7.1 is already installed You may wish to ``make deinstall'' and install this port again by ``make reinstall'' to upgrade it properly. If you really wish to overwrite the old port of print/cups-base without deleting it first, set the variable FORCE_PKG_REGISTER in your environment or the make install command line. *** Error code 1 Stop. make[3]: stopped in /usr/ports/print/cups-base *** Error code 1 Stop. make[2]: stopped in /usr/ports/print/cups-base *** Error code 1 Stop. make[1]: stopped in /usr/ports/print/hplip *** Error code 1 - This is because cups-base is no more installing libcupsdriver.so. And
Re: Shared object libicui18n.so.50 not found, required by libseed.so.0
В письме от 11 апреля 2014 21:24:00 пользователь AN написал: Thanks Kevin that fixed it. pkg delete -f seed-\* make install clean === Installing for seed-2.31.91_4 === Checking if devel/seed already installed === Registering installation for seed-2.31.91_4 Installing seed-2.31.91_4... done On my 10-stable (after pkg delete -f seed-\* and portmaster devel/seed): ../../libseed/seed-module.h:50:70: note: expanded from macro 'CHECK_ARG_COUNT' wrong number of arguments; expected %s, got %Zd, \ ~^ seed-readline.c:80:22: error: use of undeclared identifier 'Function'; did you mean 'function'? rl_bind_key(*key, (Function *) c); ^~~~ function seed-readline.c:67:17: note: 'function' declared here SeedObject function, ^ seed-readline.c:80:32: error: expected expression rl_bind_key(*key, (Function *) c); ^ seed-readline.c:95:3: warning: invalid conversion specifier 'Z' [-Wformat-invalid-specifier] CHECK_ARG_COUNT(readline.done, 0); ^~ ../../libseed/seed-module.h:50:70: note: expanded from macro 'CHECK_ARG_COUNT' wrong number of arguments; expected %s, got %Zd, \ ~^ seed-readline.c:108:3: warning: invalid conversion specifier 'Z' [-Wformat-invalid-specifier] CHECK_ARG_COUNT(readline.buffer, 0); ^~~~ ../../libseed/seed-module.h:50:70: note: expanded from macro 'CHECK_ARG_COUNT' wrong number of arguments; expected %s, got %Zd, \ ~^ seed-readline.c:123:3: warning: invalid conversion specifier 'Z' [-Wformat-invalid-specifier] CHECK_ARG_COUNT(readline.insert, 1); ^~~~ ../../libseed/seed-module.h:50:70: note: expanded from macro 'CHECK_ARG_COUNT' wrong number of arguments; expected %s, got %Zd, \ ~^ seed-readline.c:151:3: warning: invalid conversion specifier 'Z' [-Wformat-invalid-specifier] CHECK_ARG_COUNT(readline.readline, 1); ^~ ../../libseed/seed-module.h:50:70: note: expanded from macro 'CHECK_ARG_COUNT' wrong number of arguments; expected %s, got %Zd, \ ~^ 5 warnings and 2 errors generated. gmake[5]: *** [libseed_readline_la-seed-readline.lo] Ошибка 1 gmake[5]: Выход из каталога `/usr/ports/devel/seed/work/seed-2.31.91/modules/readline' gmake[4]: *** [all-recursive] Ошибка 1 gmake[4]: Выход из каталога `/usr/ports/devel/seed/work/seed-2.31.91/modules' gmake[3]: *** [all-recursive] Ошибка 1 gmake[3]: Выход из каталога `/usr/ports/devel/seed/work/seed-2.31.91' gmake[2]: *** [all] Ошибка 2 gmake[2]: Выход из каталога `/usr/ports/devel/seed/work/seed-2.31.91' *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/seed *** Error code 1 Stop. make: stopped in /usr/ports/devel/seed -- - Alex V. Petrov ___ 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: print/cups: since update to 1.7.1: error : Send-Document client-error-document-format-not-supported
On Fri, 11 Apr 2014 08:19:45 -0400 Ajtim lum...@gmail.com wrote: On Friday 11 April 2014 13:08:33 O. Hartmann wrote: On Wed, 09 Apr 2014 02:23:58 +0400 Boris Samorodov b...@passap.ru wrote: 09.04.2014 00:25, O. Hartmann пишет: On Tue, 08 Apr 2014 23:16:33 +0400 Boris Samorodov b...@passap.ru wrote: 08.04.2014 17:42, O. Hartmann пишет: Since the update of print/cups from 1.5.X to 1.7.1 How did you do it? As it is reported in /usr/ports/UPDATING. I delete first cups-image, then did the update which reeled in all the new stuff automatically. OK, lets start from some obvious things. Did you restart cupsd while experimenting? No. Give an output for: - % type lpr lpr is /usr/local/bin/lpr pkg which /usr/local/bin/lpr /usr/local/bin/lpr was installed by package cups-base-1.7.1 % ls -l /usr/local/etc/cups -r--r--r-- 1 root wheel 2807 11 Apr 11:58 cups-browsed.conf -rw-r- 1 root cups 3197 8 Apr 17:15 cups-files.conf -rw-r- 1 root cups 3197 8 Apr 17:15 cups-files.conf.bak -rw-r- 1 root wheel 3137 11 Apr 12:02 cups-files.conf.sample -r--r--r-- 1 root wheel 9521 11 Apr 11:50 cups-pdf.conf -r--r--r-- 1 root wheel 9521 11 Apr 11:50 cups-pdf.conf.sample -rw-r- 1 root cups 3442 8 Apr 17:22 cupsd.conf -rw-r- 1 root cups 5098 8 Apr 17:20 cupsd.conf.O -rw-r- 1 root cups 3442 8 Apr 17:22 cupsd.conf.bak -rw-r- 1 root wheel 4492 11 Apr 12:02 cupsd.conf.default -r--r--r-- 1 root wheel 4492 11 Apr 12:02 cupsd.conf.sample drwxr-xr-x 2 root wheel 512 11 Apr 12:02 interfaces -r--r--r-- 1 root wheel 1875 8 Apr 19:17 mime.convs -r--r--r-- 1 root wheel 1874 11 Apr 12:02 mime.convs.sample -r--r--r-- 1 root wheel 6456 8 Apr 19:18 mime.types -r--r--r-- 1 root wheel 6455 11 Apr 12:02 mime.types.sample drwxr-xr-x 2 root cups512 11 Apr 12:02 ppd -rw--- 1 root cups 4134 8 Apr 17:33 printers.conf -rw--- 1 root cups 4134 8 Apr 14:58 printers.conf.O -rw--- 1 root cups 4134 8 Apr 17:22 printers.conf.bak -rw-r--r-- 1 root cups946 11 Apr 11:53 pstoraster.convs -r--r--r-- 1 root wheel 778 11 Apr 12:04 pstotiff.convs -r--r--r-- 1 root wheel 2084 11 Apr 12:04 pstotiff.types -r--r--r-- 1 root wheel 284 11 Apr 11:49 snmp.conf -r--r--r-- 1 root wheel 284 11 Apr 12:02 snmp.conf.sample drwx-- 2 root cups512 11 Apr 12:02 ssl % make -C /usr/ports/print/cups-client pretty-print-config -GNUTLS (whoops ... this is not the default, isn't it?) == corrected that with a new recompilation with rmconfig preceded. % grep CUPS /etc/make.conf NULL (menas: no output) % pkg info -x cups hp foo gut cups-base-1.7.1 cups-client-1.7.1 cups-filters-1.0.52 cups-image-1.7.1 cups-pdf-2.6.1_1 cups-pstoraster-8.15.4_7 cups-samba-6.0_7 gutenprint-cups-5.2.8_1 libgnomecups-0.2.3_5,1 linux-f10-cups-libs-1.3.11_1 foomatic-db-hpijs-1.4 hplip-3.14.1 kdevelop-php-1.6.0_1 kdevelop-php-docs-1.6.0_1 php5-5.4.27 swhplugins-0.4.15_4 foomatic-db-20140331 foomatic-db-engine-4.0.11,2 foomatic-db-hpijs-1.4 foomatic-filters-4.0.17 gimp-gutenprint-5.2.8 gutenprint-base-5.2.8 gutenprint-cups-5.2.8_1 gutenprint-ijs-5.2.8 - Stop cupsd, move temporary /var/log/cups/*_log to another location. Start cupsd and look for suspicious messages at /var/log/cups/* files. Nothing suspicious so far. With print/cups-filters installed, the whole cups printing system is corrupted and doesn't print a single sheet of paper (PDF/PS) normal es expected. Prior to this task, I recompiled, as you suggested, first all cups ports and afterwards hplip/foomatic. I also installed print/cups-filters before recompiling hplip/foomatic. It works for me now (FreeBSD 10.0-RELEASE): I did deinstall cups* and hplip. Than installed cups and patched hplip. First I used as usual hp-business_inkjet_3000-hpijs-pcl3.ppd.gz and it didn't work It printed:%PDF-1.4 and jobs processing never stopped. Than I removed device and installed again with -3000-ps.ppd.gz and it works but cannot print test page. I tried alternatives, but it is with all (known to me) usefull drivers for the specific printer the same result: empty pages, print job stuck in queue. I also tried most recent hplip-3.14.4 but I doubt this is the reason. I can print PDF and PS, as reported, when deinstalling/removing print/cups-filters using clients like xpdf, xdvi or printing directly via lpr -PPRINTER_NAME jobfile.ps. This fails when print/cups-filter is installed. Have you tried to deinstall by intention cups-filters and check whether the formerly used driver works for you? I also deinstalled everything related to hplip and cups (cups, cups-XXX, hplip, qpdf, foomatic-XXX) and reinstalled first print/cups which reels in all
Re: [CFT] audio/xfce4-mixer 4.11.0
В Thu, 10 Apr 2014 20:08:13 + Olivier Duchateau olivi...@freebsd.org пишет: Hi, New release (targetted development) has been published yesterday. It's already present in Xfce repository [1]. Hi. I tested the new port - I not have noticed any regressions... On what to look for when testing? If there are preferences ... Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
pkg add: howto force the installation of a binary package?
Since this ever-fragile FreeBSD port editors/libreoffice fails on 11-CURRENT and 9.2-STABLE to compile (it fails on fours systems running the named flavours of OS), I try to install the binary package via pkg add. But, very funny, I receive always the error: pkg: Missing dependency matching Origin: 'net/openldap24-client' Version: '2.4.39' The port in question is already installed, but I have pkg info -ox openldap openldap-sasl-client-2.4.39 net/openldap24-sasl-client This is fun. I tried to find the magical force knob in pkg-add to override such (insane) restrictions, but I didn't find any. Is there a regular way to install the port by force without checking for the dependency? It seems that pkgng allows only installations of ports that do not dare to have different options than the standard defined in the binary package expectations? Thanks in advance for your suggestions, Oliver P.S. Please CC me. signature.asc Description: PGP signature
Re: pkg add: howto force the installation of a binary package?
On Sat, Apr 12, 2014 at 05:24:12PM +0200, O. Hartmann wrote: Since this ever-fragile FreeBSD port editors/libreoffice fails on 11-CURRENT and 9.2-STABLE to compile (it fails on fours systems running the named flavours of OS), I try to install the binary package via pkg add. But, very funny, I receive always the error: pkg: Missing dependency matching Origin: 'net/openldap24-client' Version: '2.4.39' The port in question is already installed, but I have pkg info -ox openldap openldap-sasl-client-2.4.39 net/openldap24-sasl-client This is fun. I tried to find the magical force knob in pkg-add to override such (insane) restrictions, but I didn't find any. Is there a regular way to install the port by force without checking for the dependency? It seems that pkgng allows only installations of ports that do not dare to have different options than the standard defined in the binary package expectations? Thanks in advance for your suggestions, Oliver P.S. Please CC me. From pkg-add(8) -M Force the installation of the package with missing dependencies. pgpfbjPfwb2Qq.pgp Description: PGP signature
Re: pkg add: howto force the installation of a binary package?
On Sat, 12 Apr 2014 18:01:44 +0200 Lars Engels lars.eng...@0x20.net wrote: On Sat, Apr 12, 2014 at 05:24:12PM +0200, O. Hartmann wrote: Since this ever-fragile FreeBSD port editors/libreoffice fails on 11-CURRENT and 9.2-STABLE to compile (it fails on fours systems running the named flavours of OS), I try to install the binary package via pkg add. But, very funny, I receive always the error: pkg: Missing dependency matching Origin: 'net/openldap24-client' Version: '2.4.39' The port in question is already installed, but I have pkg info -ox openldap openldap-sasl-client-2.4.39 net/openldap24-sasl-client This is fun. I tried to find the magical force knob in pkg-add to override such (insane) restrictions, but I didn't find any. Is there a regular way to install the port by force without checking for the dependency? It seems that pkgng allows only installations of ports that do not dare to have different options than the standard defined in the binary package expectations? Thanks in advance for your suggestions, Oliver P.S. Please CC me. From pkg-add(8) -M Force the installation of the package with missing dependencies. Strange, on FreeBSD 11.0-CURRENT #0 r264364: Sat Apr 12 10:34:56 CEST 2014 amd64 I get this: root@thor: [All] man pkg-add PKG-ADD(8) FreeBSD System Manager's Manual PKG-ADD(8) NAME pkg add -- Registers a package and installs it on the system SYNOPSIS pkg add [-IAfq] pkg-name ... pkg add [-IAfq] protocol://path/pkg-name ... DESCRIPTION pkg add installs packages from either a local source or a remote one. When installing from a remote source you need to specify the protocol to use when fetching the package. Currently supported protocols are FTP, HTTP and HTTPS. Otherwise, pkg add will read the file named on the command line. If this is a regular file, and the package to be installed has unmet dependencies, pkg add will search the directory containing pkg-name for suitable pkg archive files to fulfill those dependencies. If pkg-name is literally - then it will read the package data from stdin. pkg add will automatically detect and unpack most common compression formats based on the content of the data stream it reads, ignoring any extension the file- name may have. If this involves reading from a pipe (including stdin), fifo, socket or some other non-regular form of input stream then pkg add will immediately emit an error if pkg-name has unmet dependencies. OPTIONS The following options are supported by pkg add: -I If any installation scripts (pre-install or post-install) exist for given packages, do not execute them. -A Mark the installed packages as orphan. Will be automatically removed if no other packages depend on them. For more information please refer to pkg-autoremove(8) -f Force the reinstallation of the package if already installed. -q Force quiet output. ENVIRONMENT The following environment variables affect the execution of pkg add. See pkg.conf(5) for further description. ASSUME_ALWAYS_YES HANDLE_RC_SCRIPTS PKG_DBDIR FILES See pkg.conf(5). SEE ALSO pkg.conf(5), pkg(8), pkg-annotate(8), pkg-audit(8), pkg-autoremove(8), pkg-backup(8), pkg-check(8), pkg-clean(8), pkg-config(8), pkg-convert(8), pkg-create(8), pkg-delete(8), pkg-fetch(8), pkg-info(8), pkg-install(8), pkg-lock(8), pkg-query(8), pkg-register(8), pkg-repo(8), pkg-rquery(8), pkg-search(8), pkg-set(8), pkg-shell(8), pkg-shlib(8), pkg-stats(8), pkg-update(8), pkg-updating(8), pkg-upgrade(8), pkg-version(8), pkg-which(8) FreeBSD 11.0 September 22, 2013 FreeBSD 11.0 signature.asc Description: PGP signature
Re: pkg add: howto force the installation of a binary package?
On Sat, 12 Apr 2014 18:01:44 +0200 Lars Engels lars.eng...@0x20.net wrote: On Sat, Apr 12, 2014 at 05:24:12PM +0200, O. Hartmann wrote: Since this ever-fragile FreeBSD port editors/libreoffice fails on 11-CURRENT and 9.2-STABLE to compile (it fails on fours systems running the named flavours of OS), I try to install the binary package via pkg add. But, very funny, I receive always the error: pkg: Missing dependency matching Origin: 'net/openldap24-client' Version: '2.4.39' The port in question is already installed, but I have pkg info -ox openldap openldap-sasl-client-2.4.39 net/openldap24-sasl-client This is fun. I tried to find the magical force knob in pkg-add to override such (insane) restrictions, but I didn't find any. Is there a regular way to install the port by force without checking for the dependency? It seems that pkgng allows only installations of ports that do not dare to have different options than the standard defined in the binary package expectations? Thanks in advance for your suggestions, Oliver P.S. Please CC me. From pkg-add(8) -M Force the installation of the package with missing dependencies. root@thor: [All] pkg add -M libreoffice-4.1.5_1.txz pkg: illegal option -- M Usage: pkg add [-IAfq] pkg-name ... pkg add [-IAfq] protocol://path/pkg-name ... For more information see 'pkg help add'. root@thor: [All] pkg info pkg pkg-1.2.7_2 Name : pkg Version: 1.2.7_2 Installed on : Sat Apr 12 18:40:02 CEST 2014 Origin : ports-mgmt/pkg Architecture : freebsd:11:x86:64 Prefix : /usr/local Categories : ports-mgmt Licenses : BSD2CLAUSE Maintainer : port...@freebsd.org WWW: http://wiki.freebsd.org/pkgng Comment: Package manager Shared Libs required: libpkg.so.1 Shared Libs provided: libpkg.so.1 Flat size : 9.55MiB Description: Package management tool WWW: http://wiki.freebsd.org/pkgng signature.asc Description: PGP signature
Re: pkg add: howto force the installation of a binary package?
On 12/04/2014 17:41, O. Hartmann wrote: From pkg-add(8) -M Force the installation of the package with missing dependencies. This is only in pkg-1.3.x -- ie. try ports-mgmt/pkg-devel Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matt...@infracaninophile.co.uk signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] ports 2014Q2 branched
Hi Baptiste, this is awesome news. I think this is very good process. I got a question. From which FreeBSD branch is the latest and quarterly build? Since it can be affected by such things as update to new xorg when default in stable/10, etc. Because if the base is stable/10 it should be clear for users or release/10.0 that quarterly/latest is not safe to use. Or when it is from release/10.0, what happened when there will be release/10.1? Anyway thanks a lot, Robert. On Wed, 2 Apr 2014 11:24:34 +0200 Baptiste Daroussin b...@freebsd.org wrote: Hi all, I am pleased to announce that we have created the 2014Q2 branch of the ports tree. Because the first 2014Q1 branch was experimental you might not have heard of it yet. January 2014 saw the release of the first quaterly branch, intended at providing a stable and high-quality ports tree. Those stable branches are a snapshot of the head ports tree taken every 3 months and currently supported for three months, during which they receive security fixes as well as build and runtime fixes. Packages are built on regular basis on that branch (weekly) and published as usual via pkg.FreeBSD.org (/quarterly instead of the usual /latest). They are signed the same way the /latest branch is. While packages for 2014Q1 were only built for 10 (i386 and amd64) 2014Q2 will be built for both FreeBSD 9 and 10 (i386 and amd64). The first build of 2014Q2 will started this morning (wednesday at 1 am UTC) and should hit your closest mirrors very soon. On behalf of the port management team Bapt ___ 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
[QAT] 351124: 4x leftovers, 3x depend_object, 24x success, 1x bad_c++_code
Use @sample for my port, cleanup an etc/PORTNAME into ETCDIR. Sponsored by: Absolight - Build ID: 20140412192400-60697 Job owner: m...@freebsd.org Buildtime: 3 hours Enddate: Sat, 12 Apr 2014 22:05:08 GMT Revision: 351124 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=351124 - Port:deskutils/mirall Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316706/mirall-1.5.3_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316707/mirall-1.5.3_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316708/mirall-1.5.3_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316709/mirall-1.5.3_1.log - Port:dns/bind10 1.1.0 Buildgroup: 8.4-QAT/amd64 Buildstatus: DEPEND_OBJECT Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316710/bind10-1.1.0.log Buildgroup: 8.4-QAT/i386 Buildstatus: DEPEND_OBJECT Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316711/bind10-1.1.0.log Buildgroup: 9.2-QAT/amd64 Buildstatus: DEPEND_OBJECT Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316712/bind10-1.1.0.log Buildgroup: 9.2-QAT/i386 Buildstatus: BAD_C++_CODE Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316713/bind10-1.1.0.log - Port:dns/bind910 9.10.0rc1_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316714/bind910-9.10.0rc1_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316715/bind910-9.10.0rc1_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316716/bind910-9.10.0rc1_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316717/bind910-9.10.0rc1_1.log - Port:dns/bind98 9.8.7_8 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316718/bind98-9.8.7_8.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316719/bind98-9.8.7_8.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316720/bind98-9.8.7_8.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316721/bind98-9.8.7_8.log - Port:dns/bind99 9.9.5_10 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316722/bind99-9.9.5_10.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316723/bind99-9.9.5_10.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316724/bind99-9.9.5_10.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316725/bind99-9.9.5_10.log - Port:dns/maradns 2.0.09 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316726/maradns-2.0.09.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140412192400-60697-316727/maradns-2.0.09.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log:
pkg-static: Plist error, directory listed as a file: something.egg-info
Over the past week, a number of users have reported the following error
when upgrading Python ports:
pkg-static: Plist error, directory listed as a file:something.egg-info
This has been isolated as a symptom of:
a) A recent pkg version (1.2.7_1) which now generates an error
instead of silently creating a corrupt package
b) Python installations that contain *multiple* python packages that
provide the setuptools module (such as setuptools and distribute).
This (b) can either be the result of a manual install as root (via
easy_install or pip) outside of the scope of ports/packages, or due to
leftovers from previous upgrades.
The root cause is a version of setuptools is imported during the python
setup.py `install` stage, that does not contain a patch which removes
directory entries from --record output (a feature of setuptools).
Users should inspect their ${LOCALBASE}/lib/pythonX.Y/site-packages
directory, and remove any packages that reference old versions of
setuptools or distribute.
Some examples of entries that may be removed are:
1) distribute-0.6.35-py2.7.egg
2) setuptools-0.6c11-py2.7.egg
3) *Any* version of setuptools directly from PyPi via pip or easy_install
If you have any questions, or are unsure whether you can remove a
particular entry or not, either:
- Delete it, then reinstall devel/py-setuptoolsXY for good measure, OR
- Check with us on the mailing list or at #freebsd-python on freenode IRC
TLDR:
You want to be left with the version of setuptools from ports/packages
(currently 2.0.1) as the *only* installed Python package in site-packages/.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: rubygem-passenger-4.0.41_2
On Sat, Apr 12, 2014 at 03:09:04AM -0500, Scot Hetzel wrote:
On Fri, Apr 11, 2014 at 5:51 PM, Steven Hartland
kill...@multiplay.co.uk wrote:
The change is from :N - :M
.if ${PORT_OPTIONS:MDEBUG}
- Select only those words that match DEBUG
Which occurs 220 in the port tree and:
.if ${PORT_OPTIONS:NDEBUG}
- Select words that don't match DEBUG
Which only occurs twice, so TBH I assumed it was a typo given every other
option uses PORTOPTIONS:M${option}
Unfortunately the docs don't seem to provide any clarification
http://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html
so if anyone could chime in with some details on the exact meanings that
would be most appreciated.
You have to read the make(1) man page:
http://www.freebsd.org/cgi/man.cgi?query=makesektion=1
So, the patch is here.
But now I've got following error:
x1% sudo make install
=== Staging for rubygem-passenger-4.0.41_3
=== rubygem-passenger-4.0.41_3 depends on package: rubygem-fastthread=1.0.7
- found
=== rubygem-passenger-4.0.41_3 depends on package: rubygem-rack=1.4.5 -
found
=== rubygem-passenger-4.0.41_3 depends on package:
rubygem-daemon_controller=1.2.0 - found
=== rubygem-passenger-4.0.41_3 depends on file: /usr/local/bin/gem19 - found
=== rubygem-passenger-4.0.41_3 depends on file: /usr/local/bin/ruby19 - found
=== rubygem-passenger-4.0.41_3 depends on file: /usr/local/sbin/apxs - found
=== rubygem-passenger-4.0.41_3 depends on shared library: libeio.so - found
=== rubygem-passenger-4.0.41_3 depends on shared library: libev.so - found
=== rubygem-passenger-4.0.41_3 depends on shared library: libcurl.so - found
=== Generating temporary packing list
Building native extensions. This could take a while...
Successfully installed passenger-4.0.41
1 gem installed
Installing RDoc documentation for passenger-4.0.41...
(CC=clang CXX=clang++
/usr/home/osa/ports/www/rubygem-passenger/work/stage/usr/local/bin/passenger-install-apache2-module
--auto)
/usr/local/lib/ruby/site_ruby/1.9/rubygems/dependency.rb:247:in `to_specs':
Could not find passenger (= 0) amongst [daemon_controller-1.2.0,
fastthread-1.0.7, rack-1.4.5, rake-10.2.2] (Gem::LoadError)
from /usr/local/lib/ruby/site_ruby/1.9/rubygems/dependency.rb:256:in
`to_spec'
from /usr/local/lib/ruby/site_ruby/1.9/rubygems.rb:1231:in `gem'
from
/usr/home/osa/ports/www/rubygem-passenger/work/stage/usr/local/bin/passenger-install-apache2-module:22:in
`main'
*** Error code 1
Stop.
Any idea what's wrong here?
Index: Makefile
===
--- Makefile(revision 351090)
+++ Makefile(working copy)
@@ -3,7 +3,7 @@
PORTNAME= passenger
PORTVERSION= 4.0.41
-PORTREVISION= 2
+PORTREVISION= 3
CATEGORIES=www rubygems
MASTER_SITES= RG
PKGNAMEPREFIX= rubygem-
@@ -39,11 +39,11 @@
.endif
.endif
-LIB_DEPENDS+= eio:${PORTSDIR}/devel/libeio \
- ev:${PORTSDIR}/devel/libev \
- curl:${PORTSDIR}/ftp/curl
-BUILD_DEPENDS+=
rubygem-fastthread=1.0.1:${PORTSDIR}/devel/rubygem-fastthread \
- rubygem-rack=0:${PORTSDIR}/www/rubygem-rack \
+LIB_DEPENDS+= libeio.so:${PORTSDIR}/devel/libeio \
+ libev.so:${PORTSDIR}/devel/libev \
+ libcurl.so:${PORTSDIR}/ftp/curl
+BUILD_DEPENDS+=
rubygem-fastthread=1.0.7:${PORTSDIR}/devel/rubygem-fastthread \
+ rubygem-rack=1.4.5:${PORTSDIR}/www/rubygem-rack \
rubygem-daemon_controller=1.2.0:${PORTSDIR}/devel/rubygem-daemon_controller
RUN_DEPENDS:= ${BUILD_DEPENDS}
@@ -81,7 +81,7 @@
s! -feliminate-unused-debug-symbols
-feliminate-unused-debug-types!!g; \
201,203s!true!false!' \
${WRKSRC}/build/basics.rb
-.if ${PORT_OPTIONS:NDEBUG}
+.if ${PORT_OPTIONS:MDEBUG}
@${REINPLACE_CMD} \
's!-DPASSENGER_DEBUG!-DNDEBUG!g' \
${WRKSRC}/build/basics.rb
@@ -101,19 +101,23 @@
's!-lpthread!${PTHREAD_LIBS}!g' \
${WRKSRC}/lib/phusion_passenger/platform_info/cxx_portability.rb
-post-build:
+post-install:
.if ${PORT_OPTIONS:MAPACHE22}
- (CC=${CC} CXX=${CXX} ${WRKSRC}/bin/passenger-install-apache2-module
--auto)
+ (CC=${CC} CXX=${CXX}
${STAGEDIR}${PREFIX}/bin/passenger-install-apache2-module --auto)
.endif
-
.if ${PORT_OPTIONS:MNGINX}
- (cd ${WRKSRC} CC=${CC} CXX=${CXX} ${RAKE_BIN} nginx)
+ (cd ${STAGEDIR}${PREFIX}/${GEMS_DIR}/${GEM_NAME} CC=${CC} CXX=${CXX}
${RAKE_BIN} nginx)
.endif
.if ${PORT_OPTIONS:MSYMLINK}
- ${LN} -s ${GEM_LIB_DIR} ${STAGE}${PREFIX}/${GEMS_DIR}/${PORTNAME}
+ ${LN} -s ${GEM_LIB_DIR} ${STAGEDIR}${PREFIX}/${GEMS_DIR}/${PORTNAME}
.endif
- ${FIND} ${WRKSRC} -name '*.o' -delete
- ${FIND} ${WRKSRC} -name '*.bak' -delete
+ ${FIND} ${STAGEDIR} -name '*.o' -delete
+ ${FIND} ${STAGEDIR} -name '*.bak'
problem with libguile
Hi all, I'm have to install some ports (anjunta and autogen) and I get this error: checking whether libguile can be linked with... no configure: error: Cannot find libguile. libguile is required. === Script configure failed unexpectedly. Please report the problem to cls...@freebsd.org [maintainer] and attach the /usr/ports/devel/autogen/work/autogen-5.12/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 Stop. but whe I run root@valfenda:/usr/ports/devel/autogen # pkg info -a | grep guile guile-1.8.8GNU Ubiquitous Intelligent Language for Extension guile-lib-0.2.2Repository of useful code written in Guile Scheme slib-guile-3b3_1 SLIB installation for Guile show the guile-libe was installed ok, have some idea about this? and about the problema with gnash and libbooster, it will be resolve one day? The ports tree in -current have some problems and I can't solve using my abilities. Some problems I simple give up and I see in the near future if has been solved. My system: root@valfenda:/usr/ports/devel/autogen # uname -a FreeBSD valfenda 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r264373: Sat Apr 12 16:23:51 BRT 2014 rizzo@valfenda:/usr/obj/usr/src/sys/VALFENDA amd64 root@valfenda:/usr/ports/devel/autogen # root@valfenda:/usr/ports/devel/autogen # svn info /usr/ports/ Caminho: /usr/ports Working Copy Root Path: /usr/ports URL: svn://svn.freebsd.org/ports/head Relative URL: ^/head Raiz do Repositório: svn://svn.freebsd.org/ports UUID do repositório: 35697150-7ecd-e111-bb59-0022644237b5 Revisão: 351108 Tipo de Nó: diretório Agendado: normal Autor da última Mudança: tijl Revisão da última Mudança: 351108 Data da última Mudança: 2014-04-12 13:29:28 -0300 (Sáb, 12 Abr 2014) root@valfenda:/usr/ports/devel/autogen # TIA, --- /* **Nilton José RizzoUFRRJ **http://www.rizzo.eng.br http://www.ufrrj.br **http://lattes.cnpq.br/0079460703536198 **/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD ports which are currently scheduled for deletion
On 4/9/2014 19:56, Christian Weisgerber wrote: On 2014-04-08, Tijl Coosemans tijl at coosemans.org wrote: Then, once it is reasonable to assume that a port is unused it is first marked deprecated which gives users some time to step forward. There seems to be the general problem, seen again and again, that users only learn of a port's deprecation status when it is finally removed and not in the preceding grace period. I find this highly doubtful. I will give you that binary package users won't know the package is deprecated or their is even a problem until the package is no longer available, but somebody is going to see if if they build from source. OTOH, if somebody only rebuilds every 15 months, the deprecation period could come and go. I guess the ultimate solution is that pkg info shows packages that are deprecated. In the meantime -- it's still a non-problem as long as svn revert works. John I call bullshit on that claim. I'm in full agreement with Christian on this. I just happened to look at the list this time around because there was a long thread forming which suggested something was flagged for removal that shouldn't be, and I recently got surprised by the overzealous removal of another port. Going through it I see several that I have used and would be surprised to find gone only because there's no new releases upstream. Is it impossible that a piece of software is done and needs no changes to remain useful? NO How many users look at these long lists to see if any of their software is in them? I have enough other details to track that I usually don't see any deprecation notice until the port just disappears. Example: I recently was surprised to find that Kopete lost MSN support and in fact libmsn had disappeared. It was only on a major KDE update that I noticed this, some 4 months after the port was deleted. So, I have to revert multiple things to restore simple functionality. Reason for removal was stated that MSN network has shutdown. No, it hasn't. Microsoft has been pushing people onto Skype for a year, but if you just connect with any 3rd party client you can still communicate with contacts using other such clients or who have merged their accounts with a Skype account. To be fair, libmsn itself had not been updated so it would not connect, but it wasn't for the reason stated. The only problem is it had not been updated and was still reporting itself as an old beta of the MSN client so it would get disconnected with a get Skype message. Updating the version it reports to same as libpurple claims fixes that, which is a one line patch. But to even make that change, first I have to resuscitate the port. Then I have to go revert changes in Kopete port to make use of it. Figuring out when it was removed and how exactly to restore it took more time than fixing the only actual issue, a minor update that might have been made already had the entire port not been discarded prematurely. On this list I see cfv, which I've used for years, marked just because it's not maintained. It works great, it needs no changes. You want someone to bloat it with a useless non-feature to prove people still use it? I see there's a few other sfv checkers in ports tree, but then I have to go test all those, pick a suitable replacement, alter any scripts that call cfv to call the replacement, etc. Quickly looking at the options, all the others are less functional (two only do SFV, one does PAR, but not all the other formats cfv supports) and one of them is a GUI tool so useless for scripted invocation. Also on the list is cpupowerd, which even has a maintainer, marked because it's for the ancient K8. Yeah, sooo old, ahem, I still have one of those boxes running and would prefer utilities for it not disappear. In fact, I have another four boxes with K7 CPUs still running. Just because it's old doesn't mean it's unused. In this case, old means it still works because the motherboards have some decent capacitors. I don't use XMMS anymore, but I did use it for years and agree with other respondents that the suggestion to use XMMS2 is a bad joke at best. At least there is an effort to fix that one already underway. I see xfm on the chopping block for lack of maintenance. Just last month we had two users on this ML discussing possibly updating that port. kdc2tiff, tiff2png, etc are simple image converters which, once working, really need no change so need no maintenance. Sure, there are more comprehensive tools that serve those functions. I'm not using them, but somebody, somewhere, has a workflow which depends on one of those and they won't be happy about having to change their scripts when one of their basic utilities disappears. Hi Mikhail, I think the term self-inflicted is a little strong... we can't really expect the tree to stand still. I would expect people to loudly complain if their favourite port were dropped-- it's really not
