Re: Time for a firefox-56 port?
On 11/23/2017 20:11, Greg 'groggy' Lehey wrote: > I've just installed the latest version of firefox and confirmed that > it breaks both of the addons that make firefox bearable for me > (firemacs, https://addons.mozilla.org/en-US/firefox/addon/firemacs/ > and It's All Text!, > https://addons.mozilla.org/en-US/firefox/addon/its-all-text/). So I > can't use it. > > I'm sure I'm not the only person who relies on old addons. How about > a firefox-56 port until the current problems die down? > > Greg I think www/firefox-esr would give you something like 6 months more of pre-57 codebase? https://www.mozilla.org/en-US/firefox/organizations/faq/ ___ 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"
pkg lock doesn't work if a dependency wants an upgrade
What can I do to help diagnose this? I have setup an isolated test system where I can easily return it to a pre-upgraded state. I don't remember pkg printing a list of locked packages in the past so my faith in proper operation was increased but I was tricked. It looks like pkg upgraded postfix anyway because mailman depends on postfix. If I lock both postfix and mailman, pkg leaves postfix alone. Why can't the action of upgrading a package make a last minute check to make sure a package is not locked? Additionally why would upgrading a package cause it to become unlocked? Thanks. Note: I am not interested in formally modifying things so they avoid upgrading to postfix 3. I plan to upgrade soon but not tonight. # pkg lock postfix postfix-2.11.7_1,1: lock this package? [y/N]: y Locking postfix-2.11.7_1,1 # pkg lock -l Currently locked packages: postfix-2.11.7_1,1 # pkg query %ro postfix mail/mailman # pkg upgrade Updating pkg-2015 repository catalogue... pkg-2015 repository is up-to-date. All repositories are up-to-date. New version of pkg detected; it needs to be installed first. The following 1 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: pkg: 1.6.4 -> 1.6.4_1 The operation will free 64 B. 2 MiB to be downloaded. Proceed with this action? [y/N]: y Fetching pkg-1.6.4_1.txz: 100%2 MiB 2.5MB/s00:01 Checking integrity... done (0 conflicting) [1/1] Upgrading pkg from 1.6.4 to 1.6.4_1... [1/1] Extracting pkg-1.6.4_1: 100% Updating pkg-2015 repository catalogue... pkg-2015 repository is up-to-date. All repositories are up-to-date. Checking for upgrades (6 candidates): 100% Processing candidates (6 candidates): 16% postfix-2.11.7_1,1 is locked and may not be modified Processing candidates (6 candidates): 100% The following 8 package(s) will be affected (of 0 checked): Installed packages LOCKED: Package postfix-2.11.7_1,1 is locked and may not be upgraded to version 3.1.0,1 New packages to be INSTALLED: (don't worry about this part, it is from a package I left off) icu: 55.1 python: 2.7_2,2 Installed packages to be UPGRADED: openssh-portable: 7.1.p2,1 -> 7.2.p1,1 mailman: 2.1.20_2 -> 2.1.21_3 krb5: 1.14 -> 1.14.1 ca_root_nss: 3.22 -> 3.22.2 The process will require 68 MiB more space. 20 MiB to be downloaded. Proceed with this action? [y/N]: y Fetching openssh-portable-7.2.p1,1.txz: 100% 699 KiB 715.6kB/s00:01 Fetching mailman-2.1.21_3.txz: 100%3 MiB 3.6MB/s00:01 Fetching krb5-1.14.1.txz: 100%1 MiB 1.1MB/s00:01 Fetching ca_root_nss-3.22.2.txz: 100% 322 KiB 330.2kB/s00:01 Fetching postfix-3.1.0,1.txz: 100%1 MiB 1.6MB/s00:01 Fetching icu-55.1.txz: 100% 14 MiB 15.1MB/s00:01 Fetching python-2.7_2,2.txz: 100%996 B 1.0kB/s00:01 Checking integrity... done (0 conflicting) [1/8] Upgrading krb5 from 1.14 to 1.14.1... [1/8] Extracting krb5-1.14.1: 100% [2/8] Installing icu-55.1... [2/8] Extracting icu-55.1: 100% [3/8] Upgrading ca_root_nss from 3.22 to 3.22.2... [3/8] Extracting ca_root_nss-3.22.2: 100% [4/8] Upgrading postfix from 2.11.7_1,1 to 3.1.0,1... You may need to manually remove /usr/local/etc/postfix/main.cf if it is no longer needed. ==> You should manually remove the "postfix" user. ===> Creating users and/or groups. Using existing group 'mail'. Using existing group 'maildrop'. Using existing group 'postfix'. Using existing user 'postfix'. [4/8] Extracting postfix-3.1.0,1: 100% === Postfix already activated in /etc/mail/mailer.conf === postfix: Postfix is running with backwards-compatible default settings postfix: See http://www.postfix.org/COMPATIBILITY_README.html for details postfix: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload" postfix/postfix-script: refreshing the Postfix mail system <...> # pkg lock -l Currently locked packages: # ___ 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: Fwd: Re: svn commit: r386904 - in head/www/apache22: . files
That is exactly what I am using right now, so it works. Thanks. On 06/02/2015 15:19, Ryan Steinmetz wrote: > Adam, > > I've updated my patch once more. Please confirm. > > https://people.freebsd.org/~zi/patch-modules_ssl_ssl__engine__dh.c > > This removes the -rand bits and fixes the search/replace stuff. > > -r > > On (06/02/15 15:02), Adam McDougall wrote: >> Thank you for the tip and the explanation. I found out what was causing >> the difference. With libressl, the openssl gendh command no longer >> accepts -rand because it assumes your random has sufficient quality to >> start with: >> >> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/apps/Attic/gendh.c?rev=1.18&content-type=text/x-cvsweb-markup >> >> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/apps/Attic/gendh.c.diff?r1=1.17&r2=1.18 >> >> >> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/apps/Attic/gendh.c?rev=1.25&content-type=text/x-cvsweb-markup >> >> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/apps/Attic/gendh.c.diff?r1=1.24&r2=1.25 >> >> >> I don't know if there is a worthwhile benefit to using -rand with >> openssl on supported FreeBSD versions. I took $rand out of these lines >> and now apache works fine: >> +system("openssl gendh $rand -out dh2048.pem 2048"); >> +system("openssl gendh $rand -out dh3072.pem 3072"); >> >> On 06/02/2015 11:07, Ryan Steinmetz wrote: >>> Adam, >>> >>> Does this work for you with openssl? I'm unable to re-create this on my >>> side, but I'm also not testing with libressl. >>> >>> It isn't simply renaming them. There's a perl script that gets called >>> at build time that generates everything. During the build phase, you >>> should see a pair of messages indicating that it is generating the two >>> DH param files. It should take a few minutes. >>> >>> The reason for the "rename" is to allow the search/replace magic in the >>> perl to search/replace. >>> >>> Please send me the full build log. >>> >>> -r >>> >>> On (06/02/15 11:01), Adam McDougall wrote: >>>> It still didn't work. Cannot load >>>> /usr/local/libexec/apache22/mod_ssl.so into server: >>>> /usr/local/libexec/apache22/mod_ssl.so: Undefined symbol "get_dh2048" >>>> >>>> Additionally I'm concerned about the validity of renaming small primes >>>> and using them as if they were for much larger dh. When I do google >>>> searches for dh3072_p and dh2048_p I find larger sets of numbers. >>>> Renaming the existing primes doesn't feel right and worries me. >>>> >>>> On 06/02/2015 07:51, Ryan Steinmetz wrote: >>>>> Adam, >>>>> >>>>> Please test the following patch. It should be placed in the files >>>>> directory and should resolve the error you saw. >>>>> >>>>> https://people.freebsd.org/~zi/patch-modules_ssl_ssl__engine__dh.c >>>>> >>>>> You can then build the build as usual after running a 'make clean' >>>>> >>>>> -r >>>>> >>>>> On (06/01/15 14:47), Bryan Drewery wrote: >>>>>> On 5/31/2015 8:29 AM, Adam McDougall wrote: >>>>>>> Is anyone else getting this issue? I had to revert the change on my >>>>>>> systems. >>>>>>> Thanks. >>>>>>> >>>>>> >>>>>> Yes it looks incomplete. Nothing is providing get_dh2048. >>>>>> >>>>>>> work/httpd-2.2.29/modules/ssl/ssl_engine_dh.c:static DH >>>>>>> *get_dh512(void) >>>>>>> work/httpd-2.2.29/modules/ssl/ssl_engine_dh.c:static DH >>>>>>> *get_dh1024(void) >>>>>>> work/httpd-2.2.29/modules/ssl/ssl_engine_dh.c:dh = >>>>>>> get_dh2048(); >>>>>>> work/httpd-2.2.29/modules/ssl/ssl_engine_dh.c:dh = >>>>>>> get_dh3072(); >>>>>>> work/httpd-2.2.29/modules/ssl/ssl_engine_dh.c:dh = >>>>>>> get_dh3072(); >>>>>> >>>>>> The module is only providing 512 and 1024 but not 2048 and 3072 >>>>>> symbols. >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> Bryan Drewery >>>>>> >>>>> >>>>> >>>>> >>>> >>> >> > ___ 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: Fwd: Re: svn commit: r386904 - in head/www/apache22: . files
Thank you for the tip and the explanation. I found out what was causing the difference. With libressl, the openssl gendh command no longer accepts -rand because it assumes your random has sufficient quality to start with: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/apps/Attic/gendh.c?rev=1.18&content-type=text/x-cvsweb-markup http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/apps/Attic/gendh.c.diff?r1=1.17&r2=1.18 http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/apps/Attic/gendh.c?rev=1.25&content-type=text/x-cvsweb-markup http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/apps/Attic/gendh.c.diff?r1=1.24&r2=1.25 I don't know if there is a worthwhile benefit to using -rand with openssl on supported FreeBSD versions. I took $rand out of these lines and now apache works fine: +system("openssl gendh $rand -out dh2048.pem 2048"); +system("openssl gendh $rand -out dh3072.pem 3072"); On 06/02/2015 11:07, Ryan Steinmetz wrote: > Adam, > > Does this work for you with openssl? I'm unable to re-create this on my > side, but I'm also not testing with libressl. > > It isn't simply renaming them. There's a perl script that gets called > at build time that generates everything. During the build phase, you > should see a pair of messages indicating that it is generating the two > DH param files. It should take a few minutes. > > The reason for the "rename" is to allow the search/replace magic in the > perl to search/replace. > > Please send me the full build log. > > -r > > On (06/02/15 11:01), Adam McDougall wrote: >> It still didn't work. Cannot load >> /usr/local/libexec/apache22/mod_ssl.so into server: >> /usr/local/libexec/apache22/mod_ssl.so: Undefined symbol "get_dh2048" >> >> Additionally I'm concerned about the validity of renaming small primes >> and using them as if they were for much larger dh. When I do google >> searches for dh3072_p and dh2048_p I find larger sets of numbers. >> Renaming the existing primes doesn't feel right and worries me. >> >> On 06/02/2015 07:51, Ryan Steinmetz wrote: >>> Adam, >>> >>> Please test the following patch. It should be placed in the files >>> directory and should resolve the error you saw. >>> >>> https://people.freebsd.org/~zi/patch-modules_ssl_ssl__engine__dh.c >>> >>> You can then build the build as usual after running a 'make clean' >>> >>> -r >>> >>> On (06/01/15 14:47), Bryan Drewery wrote: >>>> On 5/31/2015 8:29 AM, Adam McDougall wrote: >>>>> Is anyone else getting this issue? I had to revert the change on my >>>>> systems. >>>>> Thanks. >>>>> >>>> >>>> Yes it looks incomplete. Nothing is providing get_dh2048. >>>> >>>>> work/httpd-2.2.29/modules/ssl/ssl_engine_dh.c:static DH >>>>> *get_dh512(void) >>>>> work/httpd-2.2.29/modules/ssl/ssl_engine_dh.c:static DH >>>>> *get_dh1024(void) >>>>> work/httpd-2.2.29/modules/ssl/ssl_engine_dh.c:dh = >>>>> get_dh2048(); >>>>> work/httpd-2.2.29/modules/ssl/ssl_engine_dh.c:dh = >>>>> get_dh3072(); >>>>> work/httpd-2.2.29/modules/ssl/ssl_engine_dh.c:dh = >>>>> get_dh3072(); >>>> >>>> The module is only providing 512 and 1024 but not 2048 and 3072 >>>> symbols. >>>> >>>> >>>> -- >>>> Regards, >>>> Bryan Drewery >>>> >>> >>> >>> >> > ___ 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: Fwd: Re: svn commit: r386904 - in head/www/apache22: . files
It still didn't work. Cannot load /usr/local/libexec/apache22/mod_ssl.so into server: /usr/local/libexec/apache22/mod_ssl.so: Undefined symbol "get_dh2048" Additionally I'm concerned about the validity of renaming small primes and using them as if they were for much larger dh. When I do google searches for dh3072_p and dh2048_p I find larger sets of numbers. Renaming the existing primes doesn't feel right and worries me. On 06/02/2015 07:51, Ryan Steinmetz wrote: > Adam, > > Please test the following patch. It should be placed in the files > directory and should resolve the error you saw. > > https://people.freebsd.org/~zi/patch-modules_ssl_ssl__engine__dh.c > > You can then build the build as usual after running a 'make clean' > > -r > > On (06/01/15 14:47), Bryan Drewery wrote: >> On 5/31/2015 8:29 AM, Adam McDougall wrote: >>> Is anyone else getting this issue? I had to revert the change on my >>> systems. >>> Thanks. >>> >> >> Yes it looks incomplete. Nothing is providing get_dh2048. >> >>> work/httpd-2.2.29/modules/ssl/ssl_engine_dh.c:static DH *get_dh512(void) >>> work/httpd-2.2.29/modules/ssl/ssl_engine_dh.c:static DH >>> *get_dh1024(void) >>> work/httpd-2.2.29/modules/ssl/ssl_engine_dh.c:dh = get_dh2048(); >>> work/httpd-2.2.29/modules/ssl/ssl_engine_dh.c:dh = get_dh3072(); >>> work/httpd-2.2.29/modules/ssl/ssl_engine_dh.c:dh = get_dh3072(); >> >> The module is only providing 512 and 1024 but not 2048 and 3072 symbols. >> >> >> -- >> Regards, >> Bryan Drewery >> > > > ___ 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"
Fwd: Re: svn commit: r386904 - in head/www/apache22: . files
Is anyone else getting this issue? I had to revert the change on my systems. Thanks. --- Begin Message --- On 05/20/2015 22:13, Ryan Steinmetz wrote: > Author: zi > Date: Thu May 21 02:13:07 2015 > New Revision: 386904 > URL: https://svnweb.freebsd.org/changeset/ports/386904 > > Log: > - Generate new DH params during build to mitigate Logjam attack > - Fix deprecated USE_AUTOTOOLS > - Bump PORTREVISION > > With hat: ports-secteam > Obtained from: Winni Neessen > > Added: > head/www/apache22/files/patch-modules_ssl_ssl__engine__dh.c (contents, > props changed) > Modified: > head/www/apache22/Makefile Hello, When I try to start apache I get: Performing sanity check on apache22 configuration: httpd: Syntax error on line 112 of /usr/local/etc/apache22/httpd.conf: Cannot load /usr/local/libexec/apache22/mod_ssl.so into server: /usr/local/libexec/apache22/mod_ssl.so: Undefined symbol "get_dh2048" I am using libressl but to me it looks like get_dh2048 and get_dh3072 are not in httpd-2.2.29/modules/ssl/ssl_engine_dh.c. Is this patch incomplete? Thanks for any help. --- End Message --- ___ 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: 10/stable virtualbox-ose crashes
On 05/29/2015 13:38, Kevin Oberman wrote: > On Fri, May 29, 2015 at 10:10 AM, Russell L. Carter > wrote: > >> Hi, >> kldload vboxsrv crashes recent 10/stables. Last known working >> kernel/module pair is from May 5th. >> >> Not sure what is the optimal next step, suggestions welcome. >> > > Sounds like you have done this, but several reports have been made of this > recently. All were "fixed" by rebuilding virtualbox-ose-kmod. Always > rebuild all kernel modules that are in ports when rebuilding the kernel, > preferably by adding the appropriate PORTS_MODULES to /etc/src.conf. > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkober...@gmail.com Won't this will be a problem if people use official packages (built on 10.x-RELEASE) on a system running -stable? Wouldn't it mean an ABI was violated? ___ 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 dying in ftp/curl configure
On 4/29/2015 5:01 AM, Russell L. Carter wrote: On 04/29/15 07:28, Matthew Seaman wrote: On 2015/04/29 15:26, Russell L. Carter wrote: I'd love to have a look at the config.log, but this is running under poudriere, which seems to clean up after errors. I tried ^Z right after curl fails, and then find . -name config.log at the top of the poudriere tree, and there doesn't seem to be a config.log. Any tips here would be appreciated. It's still failing, and there are 238 ports skipped because of it. Poudriere has a handy option to save a tarball of the work directory if the build fails. Add this to poudriere.conf: SAVE_WRKDIR=yes Thanks Matthew! The problem is here: configure:4240: cc -I/usr/include -O2 -pipe -fstack-protector -fno-strict-aliasing -I/usr/include -I/usr/include -L/usr/lib -L/usr/lib -L/usr/lib -Wl,-rpath,/usr/lib:/usr/local/lib -L/usr/lib -Wl,-rpath,/usr/lib:/usr/local/lib -fstack-protector conftest.c -lkrb5 -lgssapi -lgssapi_krb5 -lkrb5 -lgssapi -lgssapi_krb5 >&5 /usr/bin/ld: cannot find -lkrb5 cc: error: linker command failed with exit code 1 (use -v to see invocation) So Anton guessed correctly, as I have WITHOUT_KERBEROS=yes in src.conf(5). And of course in 'poudriere options ftp/curl' I have GSSAPI_NONE selected. So that's a bug. This is the first glitch I've encountered with about 6 months experience running WITHOUT_KERBEROS=yes. Frankly I was expecting quite a bit more. Russell It is a little unintuitive the way those GSSAPI_ options are designed. Try: ftp_curl_SET=GSSAPI_NONE ftp_curl_UNSET=GSSAPI_BASE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How to set unsupported port build options in make.conf with poudriere?
On 4/22/2015 7:50 AM, Mark Costlow wrote: I'm using poudriere on FreeBSD 10.1. I need to set --enable-drac when building mail/milter-greylist. There is no corresponding option in the milter-greylist port. In the past, I used portconf to achieve this: mail/milter-greylist: CONFIGURE_ARGS+=--enable-drac In the new post-portconf world, I tried this in /usr/local/etc/poudriere.d/build-make.conf: milter-greylist_SET="CONFIGURE_ARGS+=--enable-drac" Try: .if ${.CURDIR:M*/mail/milter-greylist} CONFIGURE_ARGS+=--enable-drac .endif _SET and _UNSET are only for toggling options, an example would be: mail_spamassassin_SET=DCC DKIM RAZOR PYZOR RELAY_COUNTRY SPF_QUERY ___ 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: LibreSSL infects ports, causes problems
On 04/09/2015 11:53, Christian Weisgerber wrote: > Baptiste Daroussin: > >> Some how you have mixed up things between base openssl and libressl, when >> starting to activate libressl if you are using ports only you have to be >> extra >> careful, (same goes with ncurses or ports openssl) just installing those >> ports >> is enough to "pollute" nearly anything you build after with a dependency on >> it >> (well anything that does link to libssl, libcrypto) > > Well, yes, that's what I said. It's a bug. > >> If it very complicated and >> error prone to cherry pick "only take base openssl here, only ports openssl >> there" the only "safe" way to solve this situation and being consistent is to >> always skip the version from base and enforce the version for ports. (the >> otherway around is impossible - very complicated) > > And the addition of LibreSSL as a not-quite-equivalent alternative > to ports OpenSSL makes this even more complicated. You can expect > things coming out of OpenBSD (like new versions of net/openntpd) > to require LibreSSL, because it includes a new library libtls that > doesn't exist in OpenSSL. In the meantime, LibreSSL has removed > some of the more horrific APIs of OpenSSL, which means some ports > will not build against LibreSSL as is. Like python27. Fixes for > these problems can be picked from the OpenBSD ports tree, if we > want to. > Many problem reports with patches are filed already just waiting for committers and are summarized here: https://wiki.freebsd.org/LibreSSL It would be great to get at least the python27 patch committed. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: svn commit: r381041 - head/textproc/p5-HTML-FormatExternal
On 03/11/2015 17:51, Matthew Seaman wrote: > Author: matthew > Date: Wed Mar 11 21:51:49 2015 > New Revision: 381041 > URL: https://svnweb.freebsd.org/changeset/ports/381041 > QAT: https://qat.redports.org/buildarchive/r381041/ > > Log: > Drop the dependency on p5-Encode. This is bundled with perl, and > p5-HTML-FormatExternal doesn't need any more recent verson itself. > > Submitted by: az > > Modified: > head/textproc/p5-HTML-FormatExternal/Makefile > > Modified: head/textproc/p5-HTML-FormatExternal/Makefile > == > --- head/textproc/p5-HTML-FormatExternal/Makefile Wed Mar 11 21:25:34 > 2015(r381040) > +++ head/textproc/p5-HTML-FormatExternal/Makefile Wed Mar 11 21:51:49 > 2015(r381041) > @@ -2,6 +2,7 @@ > > PORTNAME=HTML-FormatExternal > PORTVERSION= 22 > +PORTREVISION=1 > CATEGORIES= textproc perl5 > MASTER_SITES=CPAN > PKGNAMEPREFIX= p5- > @@ -14,8 +15,7 @@ LICENSE=GPLv3 > OPTIONS_DEFINE= ELINKS HTML2TEXT LINKS LYNX LYNX_CURRENT NETRIK > W3M > OPTIONS_DEFAULT= LYNX > > -BUILD_DEPENDS= p5-Encode>=0:${PORTSDIR}/converters/p5-Encode \ > - p5-URI>=0.08:${PORTSDIR}/net/p5-URI > +BUILD_DEPENDS= p5-URI>=0.08:${PORTSDIR}/net/p5-URI > RUN_DEPENDS:=${BUILD_DEPENDS} > > USES=perl5 It appears p5-HTML-FormatExternal depends on devel/p5-IPC-Run? Does this seem like an appropriate RUN_DEPENDS to add? Thanks. # perl -e 'use HTML::FormatExternal;' Can't locate IPC/Run.pm in @INC (you may need to install the IPC::Run module) (@INC contains: /usr/local/lib/perl5/site_perl/mach/5.18 /usr/local/lib/perl5/site_perl /usr/local/lib/perl5/5.18/mach /usr/local/lib/perl5/5.18 /usr/local/lib/perl5/site_perl/5.18 /usr/local/lib/perl5/site_perl/5.18/mach .) at /usr/local/lib/perl5/site_perl/HTML/FormatExternal.pm line 33. BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/HTML/FormatExternal.pm line 33. Compilation failed in require at -e line 1. # pkg install p5-IPC-Run Updating pkg-egr repository catalogue... pkg-egr repository is up-to-date. All repositories are up-to-date. Checking integrity... done (0 conflicting) The following 2 packages will be affected (of 0 checked): New packages to be INSTALLED: p5-IPC-Run: 0.94 p5-IO-Tty: 1.12_1 The process will require 365 KiB more space. Proceed with this action? [y/N]: y [1/2] Installing p5-IO-Tty-1.12_1... [1/2] Extracting p5-IO-Tty-1.12_1: 100% [2/2] Installing p5-IPC-Run-0.94... [2/2] Extracting p5-IPC-Run-0.94: 100% # perl -e 'use HTML::FormatExternal;' # ___ 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: pkgng deviates from defaults?
On 03/09/2015 15:05, Carsten Jensen wrote: > On 09-03-2015 17:34, Kimmo Paasiala wrote: >> On Mon, Mar 9, 2015 at 5:44 PM, Adam McDougall wrote: >>> On 03/09/2015 08:23, Carsten Jensen wrote: >>>> On 03/08/2015 02:41 PM, Baptiste Daroussin wrote: >>>>> On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote: >>>>>> It seems that pkgng deviates from installing the defaults. >>>>>> one of the culprits seems to be phpMyAdmin, as trying to upgrade this >>>>>> only it wants php56 >>>>>> deleting phpMyAdmin just shows I have other packages needing php56 in my >>>>>> system. >>>>>> >>>>>> is this a bug? and how can I prevent upgrading to the non-default php56? >>>>> The default settings are a ports tree setting not a pkg setting. for >>>>> now the >>>>> ports are hardcoding the required version into the packages, this is a >>>>> legacy of >>>>> the old system, noone has yet been working on this. so beside building >>>>> your own >>>>> packages with poudriere (which will define the default you want) righ >>>>> now there >>>>> is no way to avoid that. >>>>> >>>>> The php case but not only php will require small changes in pkg(8) to >>>>> activate >>>>> smart dependencies: depend on a>1<=2.10 and also adding >>>>> provides/requires (this >>>>> is not very hard to be added in pkg.) and it should also require heavy >>>>> changes >>>>> on the port side! >>>>> >>>>> As far as I know noone has been working on those changes in the port >>>>> side. the >>>>> pkg(8) changes are mostly pending for real use cases in the port side. >>>>> Meaning >>>>> both should be coordinated. >>>>> >>>>> Best regards, >>>>> Bapt >>>>> >>>> Sorry I don't think I was clear. >>>> Some applications wants php5 and some applications wants php56 when >>>> upgrading using pkg-ng. >>>> Using pkg-ng one cannot upgrade i.e. both phpMyAdmin and an other web >>>> based application due to this conflict. >>>> >>>> So while the upgrade happens to upgrade to php56 it also removes the >>>> other web application, as it only wants php5. >>>> >>>> Most of the applications on the server is maintained by pkg-ng, and it >>>> conflicts itself. >>>> >>>> Basically there are now 2 "default" php versions used by pkg-ng >>>> meaning, _I_ am not trying to upgrade to php56, pkg-ng does but it also >>>> tries to upgrade php5. >>>> >>>> I can't find any hardcode to php56 in the Makefile of databases/phpmyadmin >>>> >>>> I don't know if this is expressed better, I hope so atleast. >>>> >>>> >>>> Cheers >>>> Carsten >>>> >>> I think there is some confusion because the default PHP version in ports >>> recently changed to 5.6, and now the official packages are pulling in 5.6: >>> >>> https://svnweb.freebsd.org/ports?view=revision&revision=379433 >>> >>> pkg sometimes tries to remove conflicting packages (like ones that need >>> 5.5) unless you "pkg upgrade" without specifying a package and then it >>> has better information on what to reinstall so packages might not get >>> removed. >> In fact pkg(8) will not allow conflicting packages to be installed at >> all. The result is that if you want to install a package that would >> introduce a conflict in the installed package database the conflict >> has to be resolved one way or another. The only solution at the moment >> is to remove the offending packages from the existing installed >> packages. This is not a pkg(8) limitation but the consequence of how >> ports(7) system deals with conflicts and lack of infrastructure to >> properly allow multiple versions of the same software to co-exist. >> >> -Kimmo >> ___ >> 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" > Lots of good answers, thank you :-) > > I can understand that php 5.6 is now the default, I did major upgrades a &g
Re: pkgng deviates from defaults?
On 03/09/2015 08:23, Carsten Jensen wrote: > On 03/08/2015 02:41 PM, Baptiste Daroussin wrote: >> On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote: >>> >>> It seems that pkgng deviates from installing the defaults. >>> one of the culprits seems to be phpMyAdmin, as trying to upgrade this >>> only it wants php56 >>> deleting phpMyAdmin just shows I have other packages needing php56 in my >>> system. >>> >>> is this a bug? and how can I prevent upgrading to the non-default php56? >> >> The default settings are a ports tree setting not a pkg setting. for >> now the >> ports are hardcoding the required version into the packages, this is a >> legacy of >> the old system, noone has yet been working on this. so beside building >> your own >> packages with poudriere (which will define the default you want) righ >> now there >> is no way to avoid that. >> >> The php case but not only php will require small changes in pkg(8) to >> activate >> smart dependencies: depend on a>1<=2.10 and also adding >> provides/requires (this >> is not very hard to be added in pkg.) and it should also require heavy >> changes >> on the port side! >> >> As far as I know noone has been working on those changes in the port >> side. the >> pkg(8) changes are mostly pending for real use cases in the port side. >> Meaning >> both should be coordinated. >> >> Best regards, >> Bapt >> > > Sorry I don't think I was clear. > Some applications wants php5 and some applications wants php56 when > upgrading using pkg-ng. > Using pkg-ng one cannot upgrade i.e. both phpMyAdmin and an other web > based application due to this conflict. > > So while the upgrade happens to upgrade to php56 it also removes the > other web application, as it only wants php5. > > Most of the applications on the server is maintained by pkg-ng, and it > conflicts itself. > > Basically there are now 2 "default" php versions used by pkg-ng > meaning, _I_ am not trying to upgrade to php56, pkg-ng does but it also > tries to upgrade php5. > > I can't find any hardcode to php56 in the Makefile of databases/phpmyadmin > > I don't know if this is expressed better, I hope so atleast. > > > Cheers > Carsten > I think there is some confusion because the default PHP version in ports recently changed to 5.6, and now the official packages are pulling in 5.6: https://svnweb.freebsd.org/ports?view=revision&revision=379433 pkg sometimes tries to remove conflicting packages (like ones that need 5.5) unless you "pkg upgrade" without specifying a package and then it has better information on what to reinstall so packages might not get removed. ___ 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: resuming poudriere bulk
On 11/11/2014 16:52, Russell L. Carter wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > On 11/11/14 10:06, Russell L. Carter wrote: >> Hi, I am curious what is the best way to recover/restart an >> interrupted poudriere bulk build. The man page is not helpful >> here. >> > > So I had another opportunity to look into this, and I see > I can start and stop a bulk building jail just fine, but > I then seem to lose all the work up to the interrupt. > > Is there really no way to restart a bulk build from > unchanged state when you're say already 2/3 through 900+ > ports? > > Thanks, > Russell As long as the machine does not crash, you can re-run bulk after cancelling it or it dying, and it starts fresh builds of any packages which were not complete from a previous run. If libX11 succeeded, it keeps it, but if firefox was half way done compiling, it has to start firefox over. bulk does not rebuild the repo listing until the end, but you could do that manually if you want. ___ 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: new dependency for emacs-nox11
On 11/07/2014 09:25, Vick Khera wrote: > Emacs 24.4 update in ports pulls in a new dependency: desktop-file-utils. > This in turn pulls in a big swath of additional packages including python, > perl, pcre, glib. I cannot figure out what this utility is supposed to do, > as all it refers to is "make a desktop". I don't have a desktop on freebsd > nor do I run gnome. > > I do not understand the need for emacs to have a run-dependeny on this, > especially the non-x11 version. I have zero desktop systems here (they're > all servers) and nothing has X11 on it, and have no need for python and > most cases perl. > > Is there a way that the port could be tweaked so that the desktop utilities > are not installed when there is no desktop (ie, the nox11 variant)? My goal > is to have a minimal footprint of software on my servers so I do not have > to security audit all this extra software. > > Thanks for any info on why this is now included by default. The emacs port was fixed early this morning for this. Try updating? ___ 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: Apache does not respect value in DEFAULT_VERSIONS
On 09/09/2014 08:52, Andreas Nilsson wrote: > Hello, > > I've been going through my package building setup recently, and noticed > that apache default version has changed. > > Since I need apache-2.2 for one module I added apache=2.2 to > DEFAULT_VERSIONS in make.conf, but to no avail. I still get apache-2.4 and > ap24-modules. > > The only way to get apache-2.2 is to set APACHE_PORT=www/apache22 in > make.conf. > > This seems like a bug, or at least totally pointless to have apache-stuff > in bsd.default-versions.mk if its ignored. > > Best regards > Andreas Nilsson Do you have r367706 or later? I think this was fixed last night. ___ 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 and DISABLE_VULNERABILITIES
On 09/02/2014 23:09, Russell L. Carter wrote: > > > On 09/02/14 04:05, Alex Dupre wrote: >> Russell L. Carter ha scritto: >>> However, what I would like to learn is if poudriere >>> is able to understand DISABLE_VULNERABILITIES=YES, and if so, how to >>> enable it. I'm not asking a political question here, just a technical >>> one. If this is possible, how do I do it? >> >> NO_IGNORE= yes >> > > Thanks! That worked. My family can stop hating on me now, as youtube > lives. > > So, on FreeBSD-current, is there any other way besides chromium or > firefox plus the dastardly nspluginwrapper'd flash plugin to view > youtube, vimeo, etc? I am hoping that I have missed a better way. > Supposedly there are new video protocols coming down the pipe, w/o the > adobe baggage, or so I gather. > > Best, > Russell I've been meaning to take a look at emulators/pipelight after finally noticing it despite the vague name. Funny you should mention pipe? ___ 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: auditing port options and following default option value changes
On 08/27/2014 21:12, Don Lewis wrote: > I'm pretty much ready to throw in the towel on upgrading ports in place > with portupgrade and I'm planning on switching to poudriere. As part of > this conversion, I'd like to figure out what ports have non-default > options and which options are set to non-default values. Then I can > figure out whether I want to set each option back to default or > propagate the non-default value to poudriere. > > Also, since the option files for each port contain the values for all > the options, if I have a port with one non-default option value set, how > can I follow updates to the default values of the other options? This may help: http://docs.freebsd.org/cgi/mid.cgi?53FDE021.5030108 I have not abandoned all my options files yet, I've eliminated some over time as I switch to defining options in make.conf. I'll probably get burned some day and finish it off. ___ 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: Building subversion-1.8.10 under poudriere
On 08/27/2014 09:09, Willem Jan Withagen wrote: > On 2014-08-27 14:41, Dimitry Andric wrote: >> >> This is a problem in the devel/apr1 port. It checks for modf(), finds >> it in libc, then assumes isnan() also comes from libc. However, that >> does not work for static linking. >> >> Please apply the attached patch for apr1, which I have been using for >> some time now. > > Hi Dimitry, > > So this is due to me wanting to link things static? > Then I'll reconfig subversion to dynamic linking. > Because I don't have a clue (yet) as to how to get (and keep) custom > patches in a poudriere environment. > > Thanx for the reply, > --WjW > I keep custom patches this way: /usr/local/etc/poudriere.d/my-appropriate-make.conf: .if ${.CURDIR:M*/mail/mutt} EXTRA_PATCHES+= /distfiles/mypatches/patch-mail-mutt-fix-imap-append .endif You may also be interested in things like: .if ${.CURDIR:M*/security/krb5} CONFIGURE_ARGS+=--localstatedir=/var/db WITH_OPENSSL_PORT=yes .endif I suggest using this method in poudriere's make.conf for port building options: DEFAULT_VERSIONS= perl5=5.16 php=5.4 mysql=5.5 apache=2.2 pgsql=8.4 # Global port options OPTIONS_UNSET+=AVAHI BONJOUR CUPS MDNS PULSEAUDIO # specific port options: mail_dovecot_SET=GSSAPI mail_dovecot_UNSET=MANAGESIEVE That way you only change the options you desire and aren't hardcoding any of the other port options in case the default changes in the future, possibly in a critical way (threading for example). The path to the patch must be a proper path within port building jails and I believe poudriere mounts it's distfiles directory on /distfiles. It has to be a path that is available within port building jails. I picked distfiles because it is available. One thing I like about EXTRA_PATCHES is it will cause a port build to fail if the file is not found, so if that happens I will know to correct the problem rather than produce unpatched packages. I add my "mypatches" directory to my standard server backups so it is easy to restore if needed. Beware running poudriere distclean since it will wipe out unreferenced files in distfiles. ___ 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: [CFT] SSP Package Repository available
On 08/20/2014 13:20, Mark Martinec wrote: > 2014-08-20 18:34 Bryan Drewery wrote: >> On 9/21/2013 5:49 AM, Bryan Drewery wrote: >>> Ports now support enabling Stack Protector [1] support on FreeBSD 10 >>> i386 and amd64, and older releases on amd64 only currently. >>> >>> Support may be added for earlier i386 releases once all ports properly >>> respect LDFLAGS. >>> >>> To enable, just add WITH_SSP=yes to your make.conf and rebuild all >>> ports. >>> >>> The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all >>> may optionally be set instead. >>> >>> Please help test this on your system. We would like to eventually enable >>> this by default, but need to identify any major ports that have run-time >>> issues due to it. >>> >>> [1] https://en.wikipedia.org/wiki/Buffer_overflow_protection >>> >> >> We have not had any feedback on this yet and want to get it enabled by >> default for ports and packages. >> >> We now have a repository that you can use rather than the default to >> help test. We need your help to identify any issues before switching the >> default. >> >> This repository is available for: >> >> head >> 10.0 >> 9.1,9.2,9.3 >> >> It is not available for 8.4. If someone is willing to test on 8.4 I will >> build a repository for it. >> >> Place this in /usr/local/etc/pkgs/repos/FreeBSD_ssp.conf: >> >> FreeBSD: { enabled: no } >> FreeBSD_ssp: { >> url: "pkg+http://pkg.FreeBSD.org/${ABI}/ssp";, >> mirror_type: "srv", >> signature_type: "fingerprints", >> fingerprints: "/usr/share/keys/pkg", >> enabled: yes >> } >> >> Once that is done you should force reinstall packages from this >> repository: >> >> pkg update >> pkg upgrade -f >> >> Thanks for your help! >> Bryan Drewery >> On behalf of portmgr. > > I'm building about 2000 ports for our 10.0 servers and workstations using > poudriere since the 10.0 release, using WITH_SSP_PORTS=yes in poudriere's > make.conf. I suppose the WITH_SSP_PORTS=yes is equivalent to WITH_SSP=yes > but limited to ports (not sure where I got this setting, must have been > some announcement). > > So far I haven't come across any ill effects that I could attribute to SSP. > > Mark I concur with Mark, with my 1400+ packages for workstations and servers, I have had zero issues. This seems like a pretty safe change. I just confirmed -fstack-protector is in my build logs although less frequently than I assumed for ports such as zenity, meld, pidgin (once or twice each). Other ports such as vlc mention it 2029 times. Not sure if the low counts are expected. ___ 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: Cacti staged and migration issue (was Re: FreeBSD unmaintained ports which are currently scheduled for deletion)
On 08/15/2014 14:16, Kurt Jaeger wrote: > Hi! > >> Consequently, I have no idea how to set the owner/group on those >> directories in stagedir. > > As can be seen, with some help I was able to find a solution. > I also changed the patches to shebangfixes 8-} > > But: There's a real issue coming up in > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192618#c13 > > Can you have a look and probably provide a write-up on how to > migrate a running cacti install to the new hier(7) setup ? > I've been using the updated port since last night on a new server install, working well so far. On my old server I would have had to update the configs but I've been meaning to replace it anyway. Thanks. I think it would be a good idea copy or move the pkg-message updated path tips to /usr/ports/UPDATING to increase chances of it being read. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg: cached package size mismatch, cannot continue
On Mon, Aug 04, 2014 at 11:32:55AM -0700, Craig Rodrigues wrote: Hi, I install pkg-1.3.4 on my system. I did this: pkg clean -a (I verified that /var/cache/pkg was empty) # pkg install automake Updating repository catalogue FreeBSD repository is up-to-date All repositories are up-to-date The following 2 packages will be affected (of 135 checked): New packages to be INSTALLED: automake: 1.14 automake-wrapper: 20131203 The process will require 2 MB more space 434 KB to be downloaded Proceed with this action [y/N]: y Fetching automake-1.14.txz: 100% of 431 KB pkg: cached package automake-1.14: size mismatch, fetching from remote Fetching automake-1.14.txz: 100% of 431 KB pkg: cached package automake-1.14: size mismatch, cannot continue This seems to be happening for any package that I try to install. Any idea what the problem might be? -- Craig Rename /var/db/pkg/repo* (all of them) and try again. ___ 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: more problems after last upgrade(s) pkg
On 08/01/2014 09:27, Alex Keda wrote: > first: > > srv7# pkg -v > 1.3.3 > srv7# uname -a > FreeBSD srv7.host-food.ru 9.2-RELEASE-p8 FreeBSD 9.2-RELEASE-p8 #0: Mon > Jun 9 20:12:11 MSK 2014 > t...@srv7.host-food.ru:/usr/obj/usr/src/sys/HOST-FOOD amd64 > srv7# > > > srv7# pkg install -fy ap22-mod_geoip2 > Updating repository catalogue > HostFood repository is up-to-date > All repositories are up-to-date > The following 1 packages will be affected (of 756 checked): > > Installed packages to be REINSTALLED: > ap22-mod_geoip2-1.2.9 (forced reinstall) > > Fetching ap22-mod_geoip2-1.2.9.txz: 100% of 18 > kB > pkg: cached > package ap22-mod_geoip2-1.2.9: size mismatch, fetching from > remote > Fetching ap22-mod_geoip2-1.2.9.txz: 100% of 18 > kB > pkg: cached > package ap22-mod_geoip2-1.2.9: size mismatch, cannot continue > srv7# > > whats size mismatch? it's my own repo, all ports rebuilded and all pkg > and repository recreated every day. > I am also getting "size mismatch" on rt-3.8.17_1.txz: # pkg upgrade -F ... Proceed with this action [y/N]: y Fetching t1lib-5.1.2_3,1.txz: 100% of 708 kB Fetching rt-3.8.17_1.txz: 100% of 2 MB pkg: cached package rt-3.8.17_1: size mismatch, fetching from remote Fetching rt-3.8.17_1.txz: 100% of 2 MB pkg: cached package rt-3.8.17_1: size mismatch, cannot continue -rw-r--r-- 1 mcdouga9 wheel 2923996 Aug 1 12:36 rt-3.8.17_1.txz I deleted it in poudriere, updated my ports tree to include pkg 1.3.4, let poudriere compile both of those but I still have the issue. # pkg rquery %sb rt-3.8.17_1 20164010 ___ 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: Problems with portupgrade (maybe due to pkg-1.3) and gnutls3
On 07/24/2014 18:43, Kevin Oberman wrote: > Today I attempted to upgrade a bunch of ports with 'portmaster -a'. It > failed when it kept trying to install gnutls when I already had gnults3 > installed. Turns out that the man pages conflict. > > But, why was it trying to install gnutls? I am baffled. The Makefiles have > a LIB_DEPEND on libgnutls.so which is satisfied by the version of libgnutls > installed by gnutls3. > > "portmaster gtk-vnc" will attempt to install gnutls, but 'cd > /usr/ports/net/gtk-vnc && make does not try to install it and happily links. > > This was not an issue with pkg-1.2 and I suspect that the solver is having > an issue with the dependency on gnutls reading: > libgnutls.so:${PORTSDIR}/security/gnutls > > If gnutls3 is installed, it meets the dependency, but I something is > insisting on installing ${PORTSDIR}/security/gnutls even it it is. I > suspect the same issue exists for any other ports where two ports install > different versions of the same shareable library. > > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkober...@gmail.com See http://svnweb.freebsd.org/ports?view=revision&revision=362645 ___ 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: Upgrade to openjdk-7.55.13_4 fails -
On 04/29/2014 10:08, Dr. Peter Voigt wrote: > I am running 10.0-RELEASE-p1 amd64. The today upgrade to > openjdk-7.55.13_4 fails. > Check if the 20140428 entry for openjdk7 in /usr/ports/UPDATING helps you? 20140428: AFFECTS: users of java/openjdk7 AUTHOR: gle...@freebsd.org The previous version of openjdk7 had a bug that will prevent it from being able to bootstrap itself. Please deinstall openjdk7 before building the new version. ___ 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: Repair pkgng
On 04/09/2014 06:58, John Marino wrote: > On 4/9/2014 12:38, Melvyn Sopacua wrote: >> Hi, >> >> On Tue, 8 Apr 2014, Kevin Oberman wrote: >> > /var/db/pkg/libyaml-0.1.6/distfiles >> ... >>> >>> No, once you run pkgng, these files are in /var/db/pkg. The only files in >>> /var/db/ports are options files. >> >> Ah, my bad. >> Though it makes no sense in my mind. Distfiles belong to ports not >> packages. What problem was solved by moving this? >> > > It did not "move". > A clean /var/db/pkg has these contents (or similar): > auditfile > local.sqlite > repo-FreeBSD.sqlite > vuln.xml > > A clean /var/db/ports directory has these contents > */options > > > That's it. No distfiles. > > John I believe I've heard /var/db/pkg/something/distfiles is a dropping specifically from portmaster. Doesn't matter if pkgng or not. ___ 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: Libiconv confusion on 10.0-RELEASE
On 03/20/2014 14:54, Dr. Peter Voigt wrote: > Thanks on feedback to all. > > Meanwhile I've read a lot about iconv and to be honest, things are > becoming even less clear. I am having not enough experience with FreeBSD > to completely judge the situation. But obviously replacement of the > ports version of iconv is still an ongoing process somehow related to > 10.0-RELEASE. > > Besides the full list of affected ports I would like to know, if the > 11 ports on my 10.0-RELEASE system currently depending on > converters/libiconv all really have to. Or could they be built against > the base iconv? My attempts so far to rebuild them with > the /usr/ports/UPDATING advice was not successful. My feeling says > that information about iconv in /usr/ports/UPDATING is not complete. > > Regards, > Peter "Late" in the release cycle, libiconv was added to the base in 10. At the time, libiconv in base was intended to fully replace the one in ports on 10. For people who already had an earlier version of FreeBSD 10 or less were encouraged to recompile ports to use the libiconv in base and get rid of the port. Later on after 10 was released and people started using applications that use libiconv from base, some features were discovered missing or working improperly and some ports were modified to pull in libiconv from ports, and the libiconv from ports was modified to stop whining at users to remove it on 10. In short, if you installed 10.0-RELEASE, don't pay any attention to libiconv unless you are having specific problems. Do not try to fight ports from using libiconv from ports, they are using that version for a good reason. You don't really have a choice. Just relax and go with the flow. Don't try to force things to use one or the other. ___ 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: Issues with Poudriere builing packages depending on Perl
On 03/03/2014 07:44, Big Lebowski wrote: > Hi, > > I am trying to build bunch on packages in Poudriere on 10-R for 10-R and > 9.2-R. The packages are building fine, but for some reason at least one of > them builds with two different perl versions, 5.16 and 5.18. I would like > to get all my packages built with 5.18, so in my make.conf for Poudriere > jails I've the following: > > WITH_PKGNG=yes > WITHOUT_X11=yes > WITHOUT_X=yes > PERL5_DEFAULT=5.18 > PERL_PORT=perl5.18 > DEFAULT_VERSIONS= perl5=5.18 > > However, when trying to install it, I am getting the following result: > > root@machine:~ # pkg install nrpe > Updating repository catalogue > The following 4 packages will be installed: > > Installing perl5: 5.16.3_7 [FreeBSD] > Installing perl5.18: 5.18.2_1 [FreeBSD] > Installing nagios-plugins: 1.5_1,1 [localrepo] > Installing nrpe: 2.15 [localrepo] > > The installation will require 97 MB more space > > and then the installation of course fails due to the perl dependency > config. Has anyone a clue how to untangle that Poudriere/Perl mess? > > Also, any advices on the make.conf settings to absolutely avoid anything > related to x11/examples/docs? > > Thanks in advance! You can run poudriere bulk -vv and it will show the dependency tree. However since there are only two packages listed above that aren't perl, I would inspect each port manually to see if you can find out why it is trying to pull in a non-default version. You could even try installing just nagios-plugins and see which perl it tries to pull in. I only use: DEFAULT_VERSIONS= perl5=5.16 in my poudriere make.conf and everything uses 5.16, including nrpe and nagios-plugins. For the x11/examples/docs I am guessing something like: OPTIONS_UNSET+=DOCS EXAMPLES X11 however many things like to pull in X11 anyway and it will probably take a lot of work. ___ 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: Why would a port use its own existence as an excuse to fail install?
On 02/15/2014 22:31, David Wolfskill wrote: > Silly me -- I thought today might be a good day to upgrade X.org on my > laptop to the NEW_XORG. > > Laptop is running: > > FreeBSD g1-251.catwhisker.org 9.2-STABLE FreeBSD 9.2-STABLE #670 > r261880M/261884:902506: Fri Feb 14 04:50:27 PST 2014 > r...@g1-251.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > I would have updated it this morning, but there were to updates to > stable/9 as of r261913 (which is the current state of my local > private mirror). > > Ports is at r344370; I've been using pkgng on the machine for about > a week (though I still build ports, usually using portmaster. > > > Here's an example of the Subject > > One of the ports to be updated (based on the process documented in > ports/UPDATING 20131216) was textproc/clucene-qt4. > > So (cut/paste from typescript): > > ===>>> textproc/clucene-qt4 3/5 > 0;portmaster: textproc/clucene-qt4 3/5^G > ===>>> Port directory: /usr/ports/textproc/clucene-qt4 > > ===>>> Starting check for build dependencies > ===>>> Gathering dependency list for textproc/clucene-qt4 from ports > ===>>> Dependency check complete for textproc/clucene-qt4 > > ===>>> textproc/clucene-qt4 3/5 > 0;portmaster: textproc/clucene-qt4 3/5^G > ===> Cleaning for qt4-clucene-4.8.5 > ===> License LGPL21 accepted by the user > ===> qt4-clucene-4.8.5 depends on file: /usr/local/sbin/pkg - found > ===> Fetching all distfiles required by qt4-clucene-4.8.5 for building > ===> Extracting for qt4-clucene-4.8.5 > ===> Patching for qt4-clucene-4.8.5 > ===> Applying extra patch /common/ports/devel/qt4/files/extrapatch-configure > ===> Applying FreeBSD patches for qt4-clucene-4.8.5 > ===> qt4-clucene-4.8.5 depends on file: /usr/local/lib/qt4/libQtCore.so - > found > ===> qt4-clucene-4.8.5 depends on file: /usr/local/bin/qmake-qt4 - found > ===> Configuring for qt4-clucene-4.8.5 > /bin/mkdir -p > /common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/mkspecs > /bin/ln -sf /usr/local/bin/qmake-qt4 > /common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/bin/qmake > > This is the Open Source Edition. > ... > > Build type:/common/local/share/qt4/mkspecs/freebsd-g++ > Architecture: i386 > ... > Finding project files. Please wait... > WARNING: > /common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/projects.pro:46: > Unable to find file for inclusion doc/doc.pri > Reading > /common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/assistant > ... > ===>>> Starting check for runtime dependencies > ===>>> Gathering dependency list for textproc/clucene-qt4 from ports > ===>>> Dependency check complete for textproc/clucene-qt4 > > ===>>> textproc/clucene-qt4 3/5 > 0;portmaster: textproc/clucene-qt4 3/5^G > ===> Staging for qt4-clucene-4.8.5 > ===> Generating temporary packing list > install -m 755 -p "../../../../lib/libQtCLucene.so.4.8.5" > "/common/ports/textproc/clucene-qt4/work/stage/usr/local/lib/qt4/libQtCLucene.so.4.8.5" > ... > sed -e > "s,/common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/include,/usr/local/include/qt4,g" > -e > "s,/common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/lib,/usr/local/lib/qt4,g" > -e > "s,/common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5,/usr/local,g" > "../../../../lib/pkgconfig/QtCLucene.pc" > >"/common/ports/textproc/clucene-qt4/work/stage/usr/local/libdata/pkgconfig/QtCLucene.pc" > > Compressing man pages (compress-man) > ===> Installing ldconfig configuration file > ===> Installing for qt4-clucene-4.8.5 > ===> Registering installation for qt4-clucene-4.8.5 > Installing qt4-clucene-4.8.5...pkg-static: qt4-clucene-4.8.5 conflicts with > qt4-clucene-4.8.5 (installs files into the same place). Problematic file: > /usr/local/lib/qt4/libQtCLucene.la > *** [fake-pkg] Error code 70 > > Stop in /common/ports/textproc/clucene-qt4. > > ===>>> Installation of qt4-clucene-4.8.5 (textproc/clucene-qt4) failed > ===>>> Aborting update > > ===>>> Update for textproc/clucene-qt4 failed > ===>>> Aborting update > > ===>>> Killing background jobs > Terminated > > > So that "Installing qt4-clucene-4.8.5...pkg-static: qt4-clucene-4.8.5 > conflicts with qt4-clucene-4.8.5 (installs files into the same > place). Problematic file: /usr/local/lib/qt4/libQtCLucene.la" is what > I was going on about. That really seems like about the lamest excuse > for failing an install that I could imagine > > Eventually, it will probably become moot, as I'll (eventually) > migrate to stable/10, and go through the deinstall-all-ports, then > reinstall-all-ports exercise but, seriously...? What's causing this? > > How do I make it stop? > > Peace, > david > I know you mentioned UPDATING 20131216, but I suspect you are tripping over the 20140107 entry. The quick pkg set commands will probably solve this. Sometime
Re: FreeBSD 10.0-RC5 AMD64 pkg upgrade fail by gcc/gcc46
On 01/10/2014 10:02, CeDeROM wrote: > # uname -a > FreeBSD hexagon 10.0-RC5 FreeBSD 10.0-RC5 #0 r260430: Wed Jan 8 > 05:10:04 UTC 2014 > r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > # pkg delete -f gcc46 > ... > > # pkg upgrade > Updating repository catalogue > Upgrades have been requested for the following 347 packages: > ... > Reinstalling pdftk-2.02 (direct dependency changed) > Conflict found on path /usr/local/info/gcc46/dir between > gcc-4.6.4(lang/gcc) and gcc46-4.6.4_1,1(lang/gcc46) > (...) > Try temporarily removing pdftk since I know it brings in one of the gcc versions and see if your pkg upgrade finishes. If it does, try removing (without -f) the gcc that got installed and pkg will reveal one or more other packages that caused gcc to install. The problem is the new set of packages that your upgrade brings in contains packages that have a gcc 4.6 dependency but sourced from two different ports which conflict. Changes in ports will probably be needed to resolve this properly, unless you can do without one of them. As a local, temporary workaround (hack), you could probably use pkg set -o with the proper arguments to remap dependencies from one gcc 4.6 to the other so you only need one. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: php55-extensions build pulling in php5 (aka php54)
On 11/17/2013 16:06, Mark Costlow wrote: > I'm trying to use poudriere to build a set of PHP 5.5 packages. > This on a fresh 9.2 system with no PHP ports previously installed > (and the builds happen in a poudriere jail anyway). > > Building php55 works fine. But when I add php55-extensions, something > in it pulls in php54 > > My questions: > > 1. Regarding php55-extensions, I have not figured out how to discover > what element of this "meta port" is pulling in php5-gd and friends. > Is there any way to figure that out, other than looking at the > B-deps for all those ports by hand? Add -vv to your poudriere bulk build and just grep the output > > 2. Is there any way to overcome pecl-zendopcache's dependency on "php5"? Find the ports causing it using the above step and look for Makefile variables hard setting the default php version. Comment out the line. I've found it in a couple ports and filed at least one PR but I need to file more. > > 3. Is there any chance DEFAULT_VERSIONS will be extended to support > PHP version selection? > > Thanks for any advice you can offer, > > Mark > ___ 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: pkgng: How do I upgrade a single package?
On 11/03/2013 15:19, Darren Pilgrim wrote: Now that we have a repo, I want to start using binary packages for the numerous dependencies I have to install on pretty much every system: autotools, ca_root_nss, cmake-modules, gettext, glib, libtool, m4, etc. But `pkg upgrade` only asks me to upgrade everything at once. This absolutely won't work on any of my systems because I need non-default options on a few ports and therefore must compile those. But I don't want to compile everything from source. For example, of the 193 ports installed my home server, I set non-default options on only 15 of them. Everything else I can install as a binary package and save myself a HUGE amount of time. How do update individual ports from pkgng packages? Can I just install the new version over top of the old one? ___ pkg install -f pkgname ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portmaster refuses to use pkgng with local packages
On 10/27/13 10:57, Axel Rau wrote: I just converted to pkg and created a local build jail, which provides packages on a directory, which is mounted readonly by other jails. portmaster won't register with pkgng on the other jails: [somehost:/var/packages] root# pkg info pkg pkg-1.1.4_8 portmaster -PP --local-packagedir=/var/packages dialog4ports-0.1.5_1 ===>>> Package installation support cannot be used with pkgng yet, it will be disabled portmaster --packages-local --local-packagedir=/var/packages dialog4ports-0.1.5_1 ===>>> Package installation support cannot be used with pkgng yet, it will be disabled What am I doing wrong? Thanks, Axel --- PGP-Key:29E99DD6 ☀ +49 151 2300 9283 ☀ computing @ chaos claudius Perhaps 'pkg add' is what you want? ___ 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: pkgng behaviour change (upgrade -f and version)
On 07/04/13 04:16, bw.mail.lists wrote: > I'm not sure when it happened, I think since latest pkgng upgrade, > version 1.1.3, but pkgng now acts differently in at least two cases. > > 1. pkg upgrade -f > What happens: > > - > /root # pkg upgrade -f > Updating repository catalogue > New version of pkg detected; it needs to be installed first. > After this upgrade it is recommended that you do a full upgrade using: > 'pkg upgrade' > > Uprgades have been requested for the following 1 packages: > > Reinstalling pkg-1.1.3_1 > > 0 B to be downloaded > > Proceed with upgrading packages [y/N]: n > - > > What I expected to happen (man page quote): > -f Force reinstalling/upgrading the whole set of packages > > Problem: > Not sure how to upgrade everything now. > > 2. pkg version > What happens: > > - > /root # pkg version -vRL= > Updating repository catalogue > /root # > - > > What I expected to happen: > > - > /root # pkg version -vRL= > /root # > - > > Problem: > I have this in crontab: > > pkg update -q && pkg version -vRL= > > Previously I would get no email unless updates are needed. Now I get > emails about updating catalogue repository. Passing -q to 'pkg version' > doesn't suppress the message either. I'm not sure what -q would > suppress, but I don't think I want it, I was fine with the way it was > before. I can 'grep -v' that line out, but I assume that's not the > intended behavior, is it? > I'm not sure if you are following the p...@freebsd.org mailing list, but I had a related issue and forwarded your message there. It is fixed in 1.1.4. ___ 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: [HEADSUP] New make config UI
On 03/19/13 06:31, Baptiste Daroussin wrote: On Tue, Mar 19, 2013 at 11:20:43AM +0100, David Demelier wrote: 2013/3/19 Baptiste Daroussin Thanks a lot for that work to all contributors. I will try this evening and see how awesome it is :-). One questions I have: - Does the dialog4ports installation will be triggered in the pkg autoremove command since it's a leaf. Regards -- Demelier David ___ 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" No because it is an explicit installation that is done. regards, Bapt May I suggest an automatic 'make clean' in ports-mgmt/dialog4ports after make install? I accidentally installed it the first time with the old pkg_ tools, removed it, fixed WITH_PKGNG=yes in make.conf, but it would do this: root:/usr/ports/mail/postfix # make config dialog4ports isn't installed, do you want to install it now? [Y/n] y env: /usr/local/bin/dialog4ports: No such file or directory ===> Options unchanged root:/usr/ports/mail/postfix # 'make clean' in ports-mgmt/dialog4ports fixed it. Otherwise, it seems to be working, 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"
Re: recent port upgrades causing missing libraries
On Tue, Dec 11, 2012 at 02:57:14PM -0600, Bryan Drewery wrote: On 12/11/2012 9:03 AM, Adam McDougall wrote: > I used poudriere to build pkgng packages from the latest round > of port updates since the freeze. I know in the commit message > for xcb-util it bumped some other ports, but it seems like not > enough to make poudriere reinstall enough packages to make things > work. The pcre upgrade also caused some problems. I'm sorry that > I don't have time to make an extensive report of ports vs. libraries > or a PR but I can add some brief details. Using pkg install -fR > on xcb-util and pcre cured the issues for now, pkg install -fR devel/pcre should be enough. Is it what results in the errors below? I believe you are right about pcre being enough. I reverted /usr/local and /var/db/pkg to a backup so I could do some before and after "ldd *" in /usr/local/bin and -fR on xcb-util didn't make a difference after pcre. The reason I did xcb-util first was because it was the first library error I noticed during startx after the initial pkg upgrade. During pkg install -fR xcb-util I saw lots of library errors regarding pcre, so I followed with -fR on pcre. At this point everything looked fine. Thanks for your updates to UPDATING today. Have you modified your local libraries at all, symlinks, etc? No, this is all output from two desktops that are using only packages from my poudriere environment. I haven't symlinked libraries or anything like that. I try to take an all or nothing upgrade approach when it comes to libraries because I know mixing can cause difficult problems and having well built packages takes the pain out of updating (as long as the right stuff actually gets replaced). The output below is all from the second system where I took more notes because I was expecting it to happen. I'm not sure in this scenario why ldd would show linking against multiple library versions unless it is adding in library links recursively from a mix of old and new libraries. I think this would all have been fine if pkg or I had known about the additional steps needed. So much less painful than (re-re-re)compiling large portions of ports for library bumps. Is there a way to make pkg reinstall any package where the checksum at time of install no longer matches what the repo has? *somehow* I suspect it is possible for pkg to automatically know because I've seen it offer to reinstall some packages when I've changed compile options. I understand poudriere is super conservative about recompiling packages; I would like to apply that same rigor to pkg upgrade even if it takes an additional command, but reinstalling all packages each time would be overkill. I've added an UPDATING entry for pcre, and fixed the perl entry. Bryan Drewery 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"
recent port upgrades causing missing libraries
I used poudriere to build pkgng packages from the latest round of port updates since the freeze. I know in the commit message for xcb-util it bumped some other ports, but it seems like not enough to make poudriere reinstall enough packages to make things work. The pcre upgrade also caused some problems. I'm sorry that I don't have time to make an extensive report of ports vs. libraries or a PR but I can add some brief details. Using pkg install -fR on xcb-util and pcre cured the issues for now, but that doesn't mean I've caught them all. pkg_libchk doesn't work with pkgng. I could have told pkg to reinstall all packages but that is a big hammer. Reinstalling libiconv-1.14 Upgrading pcre: 8.31_1 -> 8.32 Upgrading png: 1.5.12 -> 1.5.13 Upgrading jpeg: 8_3 -> 8_4 Upgrading xcb-util: 0.3.8,1 -> 0.3.9_1,1 Upgrading glib: 2.28.8_4 -> 2.28.8_5 Upgrading tiff: 4.0.2_1 -> 4.0.3 Upgrading gobject-introspection: 0.10.8_2 -> 0.10.8_3 Upgrading cairo: 1.10.2_4,2 -> 1.10.2_5,2 Reinstalling ghostscript9-nox11-9.06_1 Upgrading pciids: 20120906 -> 20121208 Upgrading startup-notification: 0.12 -> 0.12_1 Upgrading openldap-client: 2.4.33 -> 2.4.33_1 Upgrading cups-client: 1.5.2_2 -> 1.5.4 Upgrading postfix: 2.9.4,1 -> 2.9.4_2,1 Upgrading binutils: 2.22_3 -> 2.23.1 Upgrading javavmwrapper: 2.4_2 -> 2.4_3 Upgrading xterm: 287 -> 287_1 Upgrading Thunar: 1.4.0_2 -> 1.4.0_3 Upgrading goffice: 0.8.17_2 -> 0.8.17_3 Upgrading ImageMagick: 6.7.9.4 -> 6.8.0.7 Upgrading wireshark: 1.8.3 -> 1.8.3_1 Upgrading Thunar from 1.4.0_2 to 1.4.0_3...Shared object "libpcre.so.1" not found, required by "update-desktop-database" Shared object "libpcre.so.1" not found, required by "update-desktop-database" done # pkg which `which update-desktop-database` /usr/local/bin/update-desktop-database was installed by package desktop-file-utils-0.18 Terminal: libpcre.so.1 => not found (0) exo-desktop-item-edit: libxcb-util.so.0 => not found (0) libpcre.so.1 => not found (0) libpcre.so.3 => /usr/local/lib/libpcre.so.3 (0x807942000) mousepad: libxcb-util.so.0 => not found (0) libxcb-util.so.1 => /usr/local/lib/libxcb-util.so.1 (0x807749000) libpcre.so.1 => not found (0) libpcre.so.3 => /usr/local/lib/libpcre.so.3 (0x80794e000) I think either more port version bumps are needed, or an entry in UPDATING. The UPDATING entry for perl is still wrong, I discussed on a list that it should not contain -x in the pkg command but it still does. The -x will make it install unwanted things. ___ 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: pkgng woes
Answering this in-line as a user of pkgng and binary packages: On 11/9/2012 4:53 AM, Beeblebrox wrote: Pkgng, as a concept may be great, but it's not really working - at least for me: 1. pkg2ng conversion does not do a complete job and I have about half of my ports in purgatory or a quasi-installed state. The program runs and is installed but pkgdb does not have a record for it. So my ports updates do a half-ass job. If it didn't work right, the problem should have been solved at that time or the conversion undone (pkg2ng made a backup of /var/db/pkg) so you don't move forward with a partial db. The package database it was trying to convert may have had its own problems, resulting in the failure, but if you don't have the error messages and have continued since then, it may be too late. It is hard to say what future issues will arise from a compromised package db, but that is what you now have. It may be best to scrap it and "pkg install" everything you need over top of your current install so the db is correct. (After appropriate backups) 2. I am used to portmaster and I accept that portupgrade is "more ready" to be used with pkgng than portmaster. However, portmaster has the "--check-depends" option which I would normally use to correct problem #1, alas I see no similar function in portupgrade or pkg. The "portupgrade -Ffu" and "pkg check" commands don't do the trick either. I have not tried portmaster with pkgdb yet but I understand recent versions of it support pkgng. Have you looked into that? 3. I have some ports that I never want to install (like accessibility/atk or net/avahi). The new pkgtools.conf has a nice feature of IGNORE_CATEGORIES and HOLD_PKGS which I hope will allow me to "blacklist" those ports but I have my doubts as the knob is PKGS and not PORTS - so we'll see. Separately though, while trying to get my system pkgng complient and doing updates, there have been some ports which were pulled in that I whish to remove. As in #2, portmaster --check-depends did a nice job of this and allowed the dependency to be removed from the portsdb structure - so same problem here as #2. I also had some similar concerns. I don't think you have much of a choice at the current stage, the packages on pkgbeta are being compiled a single way just like they were with the previous package format. This is expected to improve in the future, but if it really concerns you, it is best to use something like poudriere to make a custom set of packages (its pretty easy, really!) Once I tried it for my site, I am thrilled. Especially because my packages are complete, prompt, and customized. 4. I know how to do +IGNOREME in the portsdb and that is a very roundabout way of solving an sqlite entry. 5. pkg add does not respect existing port version information on the system. If you try to install a package and its dependencies, pkg tries to pull in its own preferred version. This happened for perl5 - I have 5.16 already on the system but pkg kept trying to install 5.14. The only solution was to use the old "pkg-add -i" to install one-by-one and without the dependencies. Interesting how pkgng does not have the -i (no-deps) option?? Same answer as #3 really. I also preferred 5.16 but don't really care as long as it works, so once I understood the deps in pkgbeta wanted 5.14 I just accepted that until I built my own packages with all 5.16. 6. portupgrade's -i (interactive) also completely ignores you when adding a new port. It just goes and does its thing then happily informs you of the its fait accompli. I haven't used portupgrade in a few years, and I want to avoid going back to dealing with it's database issues Ubuntu's Synaptic gives more control than this... -- View this message in context: http://freebsd.1045724.n5.nabble.com/pkgng-woes-tp5759489.html Sent from the freebsd-ports mailing list archive at Nabble.com. ___ 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg doesn't deal with perl minor upgrade? Re: svn commit: r306959 - in head: . lang/perl5.16
On 11/05/12 09:40, Baptiste Daroussin wrote: On Mon, Nov 05, 2012 at 08:48:09AM -0500, Adam McDougall wrote: What is the recommended procedure to deal with perl modules after a perl minor version upgrade like this? poudriere rebuilt all my perl modules when perl went to 5.16.2 but none of them get pulled down by pkg, just perl itself. perl-after-upgrade doesn't see any packages installed. I spot checked a perl module and it is still in /usr/local/lib/perl5/5.16.0 but that is no longer in the perl include path. At this point I would either hand pick the perl modules and force reinstall them, or use the big hammer and do pkg upgrade -f. Is there something better? Thanks. On 11/04/12 04:48, Andrej Zverev wrote: Author: az Date: Sun Nov 4 09:48:04 2012 New Revision: 306959 URL: http://svn.freebsd.org/changeset/ports/306959 Log: Update to 5.16.2 You do not need perl-after-upgrade just do: pkg install -fRx perl regards, Bapt This doesn't seem right? The output below is from a system that currently has no perl modules, let alone apache or perltidy, but some nagios stuff and pam_krb5 depend on perl (see below too): # pkg install -fRx perl Updating repository catalogue Repository catalogue is up-to-date, no need to fetch fresh copy The following packages will be installed: Upgrading perl: 5.16.0 -> 5.16.2 Installing p5-XML-NamespaceSupport: 1.11 Installing p5-XML-SAX-Base: 1.08 Installing db42: 4.2.52_5 Installing gdbm: 1.9.1 Installing expat: 2.0.1_2 Installing p5-XML-SAX: 0.99 Installing apr: 1.4.6.1.4.1_1 Installing p5-Math-BigInt: 1.997 Installing p5-Digest-HMAC: 1.03 Installing p5-GSSAPI: 0.28 Installing p5-Net-SSLeay: 1.49 Installing p5-XML-Filter-BufferText: 1.01 Installing p5-Convert-ASN1: 0.26 Installing p5-BSD-Resource: 1.2904 Installing p5-URI: 1.60 Installing p5-Authen-SASL: 2.16 Installing p5-IO-Socket-SSL: 1.76 Installing p5-XML-SAX-Writer: 0.53 Installing apache22: 2.2.23 Reinstalling nagios-plugins-1.4.16,1 Installing p5-perl-ldap: 0.4400 Installing ap22-mod_perl2: 2.0.7_1,3 Installing perltidy: 20120714 Reinstalling nrpe-2.13_2 Reinstalling pam_krb5-4.6 The installation will require 49 MB more space 20 MB to be downloaded Proceed with installing packages [y/N]: Would this be more appropriate? # pkg install -fRx perl-5.16 Updating repository catalogue Repository catalogue is up-to-date, no need to fetch fresh copy The following packages will be installed: Upgrading perl: 5.16.0 -> 5.16.2 Reinstalling nagios-plugins-1.4.16,1 Reinstalling nrpe-2.13_2 Reinstalling pam_krb5-4.6 The installation will free 99 MB 12 MB to be downloaded Proceed with installing packages [y/N]: ___ 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 doesn't deal with perl minor upgrade? Re: svn commit: r306959 - in head: . lang/perl5.16
What is the recommended procedure to deal with perl modules after a perl minor version upgrade like this? poudriere rebuilt all my perl modules when perl went to 5.16.2 but none of them get pulled down by pkg, just perl itself. perl-after-upgrade doesn't see any packages installed. I spot checked a perl module and it is still in /usr/local/lib/perl5/5.16.0 but that is no longer in the perl include path. At this point I would either hand pick the perl modules and force reinstall them, or use the big hammer and do pkg upgrade -f. Is there something better? Thanks. On 11/04/12 04:48, Andrej Zverev wrote: Author: az Date: Sun Nov 4 09:48:04 2012 New Revision: 306959 URL: http://svn.freebsd.org/changeset/ports/306959 Log: Update to 5.16.2 Changes: http://search.cpan.org/~rjbs/perl-5.16.2/pod/perldelta.pod Approved by: maintainer (implicit via email) With hat:perl@ Feature safe:yes Modified: head/UPDATING head/lang/perl5.16/Makefile head/lang/perl5.16/Makefile.man head/lang/perl5.16/distinfo head/lang/perl5.16/pkg-plist Modified: head/UPDATING == --- head/UPDATING Sun Nov 4 09:42:45 2012(r306958) +++ head/UPDATING Sun Nov 4 09:48:04 2012(r306959) @@ -5,6 +5,15 @@ they are unavoidable. You should get into the habit of checking this file for changes each time you update your ports collection, before attempting any port upgrades. +20121104: + AFFECTS: users of lang/perl5.16 + AUTHOR: a...@freebsd.org + + lang/perl5.16 has been updated to 5.16.2. You should update everything + that depends on perl. The easiest way to do that is to use + "perl-after-upgrade" script supplied with lang/perl5.16. + Please see its manual page for details. + 20121102: AFFECTS: users of shells/bash-completion AUTHOR: ad...@freebsd.org Modified: head/lang/perl5.16/Makefile == --- head/lang/perl5.16/Makefile Sun Nov 4 09:42:45 2012(r306958) +++ head/lang/perl5.16/Makefile Sun Nov 4 09:48:04 2012(r306959) @@ -40,7 +40,7 @@ OPTIONS= DEBUGGING "Build with debugging PORTSCOUT=limitw:1,even -PERL_VERSION= 5.16.0 +PERL_VERSION= 5.16.2 PERL_ARCH=mach SITE_PERL_REL?= lib/perl5/site_perl/${PERL_VERSION} SITE_PERL?= ${LOCALBASE}/${SITE_PERL_REL} Modified: head/lang/perl5.16/Makefile.man == --- head/lang/perl5.16/Makefile.man Sun Nov 4 09:42:45 2012 (r306958) +++ head/lang/perl5.16/Makefile.man Sun Nov 4 09:48:04 2012 (r306959) @@ -27,8 +27,11 @@ MAN1+= perl5123delta.1 MAN1+=perl5124delta.1 MAN1+=perl5140delta.1 MAN1+=perl5141delta.1 +MAN1+= perl5143delta.1 MAN1+=perl5142delta.1 MAN1+=perl5160delta.1 +MAN1+= perl5161delta.1 +MAN1+= perl5162delta.1 MAN1+=perl561delta.1 MAN1+=perl56delta.1 MAN1+=perl581delta.1 Modified: head/lang/perl5.16/distinfo == --- head/lang/perl5.16/distinfo Sun Nov 4 09:42:45 2012(r306958) +++ head/lang/perl5.16/distinfo Sun Nov 4 09:48:04 2012(r306959) @@ -1,4 +1,4 @@ -SHA256 (perl/perl-5.16.0.tar.bz2) = 8c1d25e92a5760e84f77baa57fde5606fd6e95ec992408d36fa53c47162721d1 -SIZE (perl/perl-5.16.0.tar.bz2) = 13568573 +SHA256 (perl/perl-5.16.2.tar.bz2) = 5ba91d9aa40220c615b644bb48fa5df7fbca4afb1c9e911bdc0ce2a93f072d7d +SIZE (perl/perl-5.16.2.tar.bz2) = 13725101 SHA256 (perl/BSDPAN-2007.tar.bz2) = 2f03218a592dc65ebfdc3c6b9394d91dcf4c53aa5290a08458b837baad5a21f9 SIZE (perl/BSDPAN-2007.tar.bz2) = 8448 Modified: head/lang/perl5.16/pkg-plist == --- head/lang/perl5.16/pkg-plistSun Nov 4 09:42:45 2012 (r306958) +++ head/lang/perl5.16/pkg-plistSun Nov 4 09:48:04 2012 (r306959) @@ -188,7 +188,6 @@ lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/IPC lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/IPC/SharedMem.pm lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/IPC/SysV.pm lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/List/Util.pm -lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/List/Util/PP.pm lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/List/Util/XS.pm lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/MIME/Base64.pm lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/MIME/QuotedPrint.pm @@ -204,7 +203,6 @@ lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/Per lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/PerlIO/via.pm lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/SDBM_File.pm lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/Scalar/Util.pm -lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/Scalar/Util/PP.pm lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/Socket.pm lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/Storable.pm lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/Sy
Re: Where is best place to log pkg bugs?
On 11/2/2012 9:56 PM, Eitan Adler wrote: On 2 November 2012 21:53, Adam McDougall wrote: The mailing lists don't seem to be a good place to send bugs and get attention, and I've found a few that I want to report and have in a bug system somewhere. Should I use gnats? yes please. Log then as "bin" category for now (we really should have a separate category). Thanks. I filed 3 plus one for poudriere at http://fossil.etoilebsd.net/poudriere/tktview/9636c6f78a14dff32a6553b9a58a8912a1b13843 ___ 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"
Where is best place to log pkg bugs?
The mailing lists don't seem to be a good place to send bugs and get attention, and I've found a few that I want to report and have in a bug system somewhere. Should I use gnats? 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"
Re: svn commit: r305926 - head/ports-mgmt/poudriere
I upgraded poudriere to 2.2 and started a build using: poudriere bulk -D -f /root/pkg-webold -j 90amd64-webold I noticed by the lack of "deleting stale"... and the high number of packages it was going to build that it was intending to rebuild all packages in the list. I don't seem to have a full history of zfs create commands available to see if I had created /poudriere/data manually in the past (I probably did judging by the zfs path), but a new /poudriere/data was automatically created today which got mounted over top thus /poudriere/data/packages was empty: 2012-10-17.11:19:21 zfs create -p -o poudriere:type=data -o mountpoint=/poudriere/data rpool/poudriere/data Filesystem 1K-blocks UsedAvail Capacity Mounted on rpool/data33772015 3924530 2984748412% /poudriere/data rpool/poudriere/data 2987362926144 29847484 0% /poudriere/data I'll move my packages into the new mount, but I wanted to give at least a heads up to others. On 10/15/12 13:12, Bryan Drewery wrote: Author: bdrewery Date: Mon Oct 15 17:12:43 2012 New Revision: 305926 URL: http://svn.freebsd.org/changeset/ports/305926 Log: - Update to 2.2 Changes: * Lots of bug fixes * Support JAILNAME-make.conf and PTNAME-make.conf * Updated ZSH completions * The 'pbi' subcommand has been removed * New "SET" feature. bulk, options, testport now all support a '-z SET' option that allows for extra customization of make.conf and options. See CUSTOMISATION section in poudriere(8) for more information. * Improved compatibility with older FreeBSD versions * Poudriere itself can be jailed, see website for more details. * Any ZFS dataset can now be used as a ports tree. Just set poudriere:type=ports and define poudriere:name to use as a ports tree. * ports: - No longer create port tress in ports/ subdirectory when using SVN or git * options: - Fix improperly using options-JAILNAME instead of JAILNAME-options directory, resulting in options not being used. - Fix the specified ports tree not being used * bulk: - Support for building the entire ports tree with the -a option - Support for overriding WRKDIR_ARCHIVE_FORMAT, see new poudriere.conf.sample - Summary output updates - SIGINFO improvements - Improved output during startup, explaining which files/directories are being used for the build. - Fix skipped ports causing incorrect counts - Logs are now only cleared on -c again - New '-C' option that deletes any existing packages, but only for the ones listed. This works well with '-t' for bulk testing. * jail: - Better version detection on new jails via newvers.sh * testport: - Lots of leftovers improvements - When using pkgng, DEVELOPER_MODE is now enabled by default, which will run extra plist checks. Feature safe:yes Modified: head/ports-mgmt/poudriere/Makefile head/ports-mgmt/poudriere/distinfo Modified: head/ports-mgmt/poudriere/Makefile == --- head/ports-mgmt/poudriere/Makefile Mon Oct 15 17:06:01 2012 (r305925) +++ head/ports-mgmt/poudriere/Makefile Mon Oct 15 17:12:43 2012 (r305926) @@ -1,7 +1,7 @@ # $FreeBSD$ PORTNAME= poudriere -PORTVERSION= 2.1.2 +PORTVERSION= 2.2 CATEGORIES= ports-mgmt MASTER_SITES= http://fossil.etoilebsd.net/poudriere/tarball/ DISTFILES=${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}?uuid=${PORTVERSION} @@ -27,7 +27,6 @@ PLIST_FILES= etc/poudriere.conf.sample \ share/poudriere/common.sh \ share/poudriere/test_ports.sh \ share/poudriere/ports.sh \ - share/poudriere/pbi.sh \ share/poudriere/jail.sh \ share/poudriere/bulk.sh \ share/poudriere/cron.sh \ Modified: head/ports-mgmt/poudriere/distinfo == --- head/ports-mgmt/poudriere/distinfo Mon Oct 15 17:06:01 2012 (r305925) +++ head/ports-mgmt/poudriere/distinfo Mon Oct 15 17:12:43 2012 (r305926) @@ -1,2 +1,2 @@ -SHA256 (poudriere-2.1.2.tar.gz?uuid=2.1.2) = 19a1d41463c8c04491b760df5aaf9caec348fac78538adf8276d397b41b239cd -SIZE (poudriere-2.1.2.tar.gz?uuid=2.1.2) = 33476 +SHA256 (poudriere-2.2.tar.gz?uuid=2.2) = b557a9d6ffab5e050935bf2eaded25c23f3e0ff610ce1293d1123cee8354898f +SIZE (poudriere-2.2.tar.gz?uuid=2.2) = 34481 ___ svn-ports-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-ports-all To unsubscribe, send any mail to "svn-ports-all-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing lis
pkg install order dependency problem
Short version: If you make a pkg repo with poudriere that includes java/diablo-jdk16 and tell pkg to install it, it knows pkgconf is a dep of xproto but it installs it in the wrong order so it fails. diablo-jdk16 is not on pkgbeta so I cannot test with that repo. I realize there are other jdk choices but this issue is about why pkg would get the install order wrong (it also seems to be missing a newline on the error). Please let me know if I can provide more information or test something. Thanks. This is on a recent 9.x-amd64 test system with no packages old or new: root@test:/root # env PACKAGESITE="http://my.local.server/pkg/freebsd:9:x86:64/latest"; pkg update The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg please wait Installing pkg-1.0.1... done If you are upgrading from the old package format, first run: # pkg2ng Updating repository catalogue repo.txz 100% 792KB 791.5KB/s 791.5KB/s 00:00 root@test:/root # pkg info pkg-1.0.1 New generation package manager root@test:/root # pkg install java/diablo-jdk16 Updating repository catalogue Repository catalogue is up-to-date, no need to fetch fresh copy The following packages will be installed: Installing javavmwrapper: 2.4 Installing compat7x-amd64: 7.3.703000.201008_1 Installing xextproto: 7.2.0 Installing xproto: 7.0.22 Installing pkgconf: 0.8.9 Installing diablo-jdk: 1.6.0.07.02_20 The installation will require 166 MB more space 56 MB to be downloaded Proceed with installing packages [y/N]: y javavmwrapper-2.4.txz 100% 18KB 17.6KB/s 17.6KB/s 00:00 compat7x-amd64-7.3.703000.201008_1.txz 100% 5010KB 4.9MB/s 4.9MB/s 00:00 xextproto-7.2.0.txz 100% 23KB 22.7KB/s 22.7KB/s 00:00 xproto-7.0.22.txz 100% 59KB 59.2KB/s 59.2KB/s 00:00 pkgconf-0.8.9.txz 100% 22KB 21.9KB/s 21.9KB/s 00:00 diablo-jdk-1.6.0.07.02_20.txz 100% 52MB 51.7MB/s 51.7MB/s 00:00 Checking integrity... done Installing javavmwrapper-2.4... done Installing compat7x-amd64-7.3.703000.201008_1... done Installing xextproto-7.2.0... done Installing xproto-7.0.22...missing dependency pkgconf-0.8.9root@test:/root # root@test:/root # root@test:/root # pkg install java/diablo-jdk16 Updating repository catalogue Repository catalogue is up-to-date, no need to fetch fresh copy The following packages will be installed: Installing xproto: 7.0.22 Installing pkgconf: 0.8.9 Installing diablo-jdk: 1.6.0.07.02_20 The installation will require 149 MB more space 0 B to be downloaded Proceed with installing packages [y/N]: y Checking integrity... done Installing xproto-7.0.22...missing dependency pkgconf-0.8.9root@test:/root # root@test:/root # root@test:/root # If I go ahead and install pkgconf manually, xproto and thus diablo-jdk succeed. Interestingly, if I only request to install xproto, it gets the order right: root@test:/root # pkg install xproto Updating repository catalogue Repository catalogue is up-to-date, no need to fetch fresh copy The following packages will be installed: Installing pkgconf: 0.8.9 Installing xproto: 7.0.22 The installation will require 428 kB more space 0 B to be downloaded Proceed with installing packages [y/N]: y Checking integrity... done Installing pkgconf-0.8.9... done Installing xproto-7.0.22... done ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How to check out ports
On 10/2/2012 10:54 PM, Paul Schmehl wrote: How do I handle this? firnsy-barnyard2-v2-1.10-0-g2f5d496.tar.gz Is the string at the end (g2f5d496) auto-generated? If so, that's another problem. I guess something like this? Sheesh. What a PITA. PORTNAME= barnyard2-v2 PORTVERSION=1.10 PKGNAMEPREFIX= firnsy- PKGNAMESUFFIX= -0-g2f5d496 Paul Schmehl, Senior Infosec Analyst See /usr/ports/deskutils/growl-for-linux/Makefile for an example, bsd.sites.mk has support for github. It was the first example I could find with grep. I believe its a new ports feature. ___ 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: textproc/p5-XML-SAX: prerequisite XML::SAX::Base 1.05 not found
On 5/9/2012 6:36 PM, milki wrote: On 09:26 Wed 09 May , Kevin Oberman wrote: I think that p5-XML-SAX-Base has to be removed before installing (maybe even building) ?p5-XML-SAX-0.99. I did a "pkg_delete p5-XML-SAX-Base-\*" followed by "portmaster p5-XML-SAX-Base" and "portmaster p5-XML-SAX". Once I did that, everything went fine. (In theaory I could have deleted p5-XML-SAX-Base and then installed both p5-XML-SAX-Base and p5-XML-SAX in a single portmaster run, but I didn't do it that way, so I can't promise that it will work. Do either of you remember how p5-XML-SAX-Base was installed? The port was removed 6 years ago and sunpoet readded it with the 0.99 update. It appears to have already been installed according to your port logs but not detected by the perl install itself, which means it there is some discrepency in the package's file locations. -milki I ran into this problem today from some servers I installed 2 days ago. I did not have p5-XML-SAX-Base-1.08 installed prior to running portupgrade -a this morning which installed it then p5-XML-Sax failed. If I remove p5-XML-SAX-Base-1.08 and let portupgrade re-add whatever it wants, it worked. ___ 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/157868: mail/mailman: Possible problem with MAIL_GID
On 06/20/11 07:00, Chris Rees wrote: On 20 June 2011 11:10, Guido Falsi wrote: On Mon, Jun 20, 2011 at 10:30:58AM +0100, Chris Rees wrote: On 20 June 2011 10:22, Guido Falsi wrote: On Sat, Jun 18, 2011 at 12:57:47PM +, Chris Rees wrote: Today I updated my ports and tried to upgrade my mailman install, but it failed because I use my own user and group: ===> Installing for mailman-2.1.14_5 ===> Generating temporary packing list ===> Checking if mail/mailman already installed ===> Creating users and/or groups. ** Cannot find any information about group `postlocal' in /usr/ports/GIDs. *** Error code 1 My local user will never be in /usr/ports/GIDs of course. I am using: # more /etc/make.conf #For Mailman MM_USERNAME=postlocal MM_USERID=2012 MM_GROUPNAME=postlocal MM_GROUPID=2012 MAIL_GID=postlocal Should I be doing something different? Please let me know if I can help. 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"
Re: portupgrade failure
On Thu, Dec 17, 2009 at 10:21:02AM +0100, Jimmy Renner wrote: Quoting Mark Linimon : > On Wed, Dec 16, 2009 at 11:13:36PM -0500, Robert Huff wrote: >> The maintainer, ruby@, is aware of this; a check of the PR >> database shows multiple open PRs, none critical but many serious >> going back six months and more. > > As an aside, the Severity and Priority fields have been so often abused > as to have become meaningless. Although I still try to groom the db > for "critical" ones, and thus try to get those some attention, I really > don't think the committers pay much attention. (In general I think > those should be reserved for "data corruption" and "security".) > > The longer-term solution is to remove those as user-settable fields. > >> This hard to understand given portupgrade is the recommended upgrade >> tool. > > Once the individual who was working on it gave it up to the mailing > list, it became one of those "everyone is responsible so no one is > responsible" problems. I don't have a recommended fix for this. > > Having said that, I have a ports tree as of a month ago and portupgrade > was working ok for me. I don't have the cycles to go figure out where > it fails to be able to fix it, sorry. > I don't know if your issues are related but yesterday I managed to fix a ports tree that made portupgrade crash. I wasn't aware that portupgrade looks in the options files for dependencies. I think some ports, and my guess it is those who gave me the problem, blindly pulls in dependencies without checking if they are already installed or not and it is in those cases that portupgrade can get an incorrect cyclic dependencies list. Some of that sounds true to my experience, for a while I've noticed while installing a new port with portupgrade that it will install the default dependencies before prompting with the options screen to find out which ones I want. For example if I do 'portupgrade -N postfix' on a fresh system, it will first install pcre and THEN prompt me to (de)select pcre or any of the other optional deps. Ok, enough of my strange unproven theories. I removed a lot of the options files from /var/db/ports/... and after some point, it was actually when removing them from all the p5-* ports, portupgrade started working again. When running portupgrade again I was more restrictive with what options to actually enable and after that everything works. Don't know if that will help anyone but I though I should at least put my ideas down somewhere. / Jimmy This message was sent using IMP, the Internet Messaging Program. ___ 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: MAKE_JOBS_UNSAFE (some more ports)
David Naylor wrote: On Saturday 06 June 2009 22:56:47 Ion-Mihai Tetcu wrote: On Sat, 6 Jun 2009 18:05:14 +0200 David Naylor wrote: P.S. Is anyone interested in a list of ports that do not compile under tmpfs? Me. The following are on my blacklist for tmpfs build, where: # df -h | grep tmp tmpfs 8.3G 12M8.3G 0%/tmp # grep WRKDIRPREFIX /etc/make.conf WRKDIRPREFIX=/tmp editors/openoffice.org-3 (just to big for my computer to handle) security/gpgme* lang/ocaml** java/openjdk6*** * Confirmed build failure on 7.1p2 and -Current from December * Confirmed build success on -Current from Saturday ** I had a strange problems with math/facile that it wouldn't build if ocaml was built on tmpfs (didn't confirm this one) *** Cannot reproduce (although do remember it) From what I read it appeared that tmpfs had an internal locking problem however it appears to be fixed in current. Last I tried it, procmail did not build on tmpfs either, I didn't have time to report the full details. After getting a compile error, I looked into what was in the build directory and found two files with the same name!! I think when I deleted one, I think the size of the other showed a change. ___ 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: [Call For Testing] VirtualBox for FreeBSD!
I figured it out. I needed "options COMPAT_IA32" in my kernel config. On Mon, May 25, 2009 at 12:07:47PM -0400, Adam McDougall wrote: > Hi, > When compiling I get the following error > > kBuild: Installing tstUtf8 => > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/testcase/tstUtf8 > > kBuild: Installing tstUuid => > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/testcase/tstUuid > > kBuild: Installing tstVMStructGC => > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/tstVMStructGC > > kBuild: Generating tstVMStructSize - > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/tstVMStructGC: > 1: Syntax error: "(" unexpected > kmk[2]: *** > [/root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h] > Error 2 > kmk[2]: *** Deleting file > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h' > > kmk[2]: *** Waiting for unfinished jobs > awk -f /usr/src/sys/conf/kmod_syms.awk > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/vboxdrv/vboxdrv.ko > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.def > | xargs -J% objcopy % > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/vboxdrv/vboxdrv.ko > > awk: can't open file > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.def > > source line number 10 > kmk[2]: Leaving directory > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' > kmk[2]: Entering directory > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' > kmk[2]: *** Exiting with status 2 > kmk[1]: *** [pass_binaries_this] Error 2 > kmk[1]: Leaving directory > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' > kmk: *** [pass_binaries_order] Error 2 > *** Error code 2 > > Stop in /root/vBox/virtualbox. > demophon# > > > demophon# uname -a > FreeBSD demophon 8.0-CURRENT FreeBSD 8.0-CURRENT #10: Wed May 6 > 09:04:17 UTC 2009 p...@demophon:/usr/obj/usr/src/sys/DEMOPHON amd64 > > Any ideas? > > Cheers > Paul > ___ > 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" > I am getting this error too from the latest test port on amd64 7-stable and 8-current: kBuild: Installing tstVMStructGC => /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/bin/tstVMStructGC kBuild: Generating tstVMStructSize - /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/bin/tstVMStructGC: 1: Syntax error: "(" unexpected kmk[2]: *** [/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h] Error 2 kmk[2]: *** Deleting file `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h' kmk[2]: *** Waiting for unfinished jobs kmk[2]: Leaving directory `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' kmk[2]: Entering directory `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' kmk[2]: *** Exiting with status 2 kmk[1]: *** [pass_binaries_this] Error 2 kmk[1]: Leaving directory `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' kmk: *** [pass_binaries_order] Error 2 *** Error code 2 The OS builds are 1-3 days old (full kernel + world) and ports were up to date. Help? 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" ___ 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: [Call For Testing] VirtualBox for FreeBSD!
Paul Wootton wrote: Martin Wilke wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok We uploaded a new tarball what should be fix the build on AMD64. Small changelog: - - devel/kbuild is now dependency - - remove misc/compat6 support Note: Use devel/bcc instead of devel/dev86 what means If you have devel/bcc installed please deinstall http://people.freebsd.org/~miwi/vbox/virtualbox_1.tgz Please give us feedback :P - - Martin - -- +---+---+ | PGP: 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | ICQ: 169139903 | Mail : miwi(at)FreeBSD.org | +---+---+ |Mess with the Best, Die like the Rest!| +---+---+ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoNQCUACgkQdLJIhLHm/OmgeQCgptEW5FhkmB8huDhs5LL63PhI +04AoONjytolxD892zcCnlv81MRLceEv =UJL8 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" Hi, When compiling I get the following error kBuild: Installing tstUtf8 => /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/testcase/tstUtf8 kBuild: Installing tstUuid => /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/testcase/tstUuid kBuild: Installing tstVMStructGC => /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/tstVMStructGC kBuild: Generating tstVMStructSize - /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/tstVMStructGC: 1: Syntax error: "(" unexpected kmk[2]: *** [/root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h] Error 2 kmk[2]: *** Deleting file `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h' kmk[2]: *** Waiting for unfinished jobs awk -f /usr/src/sys/conf/kmod_syms.awk /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/vboxdrv/vboxdrv.ko /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.def | xargs -J% objcopy % /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/vboxdrv/vboxdrv.ko awk: can't open file /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.def source line number 10 kmk[2]: Leaving directory `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' kmk[2]: Entering directory `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' kmk[2]: *** Exiting with status 2 kmk[1]: *** [pass_binaries_this] Error 2 kmk[1]: Leaving directory `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' kmk: *** [pass_binaries_order] Error 2 *** Error code 2 Stop in /root/vBox/virtualbox. demophon# demophon# uname -a FreeBSD demophon 8.0-CURRENT FreeBSD 8.0-CURRENT #10: Wed May 6 09:04:17 UTC 2009 p...@demophon:/usr/obj/usr/src/sys/DEMOPHON amd64 Any ideas? Cheers Paul ___ 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" I am getting this error too from the latest test port on amd64 7-stable and 8-current: kBuild: Installing tstVMStructGC => /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/bin/tstVMStructGC kBuild: Generating tstVMStructSize - /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/bin/tstVMStructGC: 1: Syntax error: "(" unexpected kmk[2]: *** [/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h] Error 2 kmk[2]: *** Deleting file `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h' kmk[2]: *** Waiting for unfinished jobs kmk[2]: Leaving directory `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' kmk[2]: Entering directory `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' kmk[2]: *** Exiting with status 2 kmk[1]: *** [pass_binaries_this] Error 2 kmk[1]: Leaving directory `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' kmk: *** [pass_binaries_order] Error 2 *** Error code 2 The OS builds are 1-3 days old (full kernel + world) and ports were up to date. Help? Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman
Re: Proposal: mechanism for local patches
RW wrote: On Tue, 2 Dec 2008 21:07:43 +0300 Dmitry Marakasov <[EMAIL PROTECTED]> wrote: I am not aware of any mechanism for this. But I agree that it's really needed. Before (in cvsup times) we could just place patches under files/ and be happy, but now when more people use portsnap we need something better. I wonder if portsnap actually needs to behave the way it does. Portsnap stores its compressed snapshot as one .gz file for each port plus one for each additional file (files in Mk/ etc). When you do an "update" any modified snapshot files are extracted over the appropriate location in the ports tree. The reason that "portsnap extract" deletes patch-files is that before each .gz file is extracted, the corresponding file or port directory is deleted. I wonder why, if an "update" can decompress over the top of a port, an "extract" need to delete it first. I can't think of any good reason offhand. Modifying portsnap not to delete extra files is just a matter of deleting one line. The behaviour of portsnap extract would then be virtually identical to csup. Alternately, it wouldn't be much harder to create a new portsnap command. I've encountered a similar situation where I wanted to add patches or even patch/replace standard files in a port to meet my needs, but portsnap wipes them out. For now I'm using cfengine to re-apply my local changes to the ports tree on about 10 systems, but I have to remember to run cfagent after portsnap manually (I don't want to use cfengine in daemon mode). I thought it would be nice if portsnap.conf would let me specify a post-execution command so I could make it run cfagent on its own, so there is little chance to forget. My goal is to allow customizations while retaining the same standard command procedures that would be used on a plain system, to provide consistency across the board without introducing custom scripts that replace standard commands. In that light, it would be useful if csup had something similar, however I practically never need to maintain patches to /usr/src/. Just posting this as food for thought. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade 'dovecot' failed
On Wed, Sep 10, 2008 at 01:23:01AM +0400, Alex Keda wrote: ---> Backing up the old version ---> Uninstalling the old version ---> Deinstalling 'dovecot-1.1.2_1' Dovecot is still running. Shall I stop it? [y]? ... ---> Restoring the old version Dovecot has reserved the groupname 'dovecot' and gid '143': Please resolve these issues and try again: Either remove the conflicting group or if you wish to continue using a legacy group override DOVECOT_GID. pkg_add: install script returned error status ** Command failed [exit code 1]: /usr/sbin/pkg_add -f /var/tmp/portupgrade7wXzzsEk/dovecot-1.1.2_1.tbz ---> Skipping 'mail/dovecot' ** Listing the failed packages (-:ignored / *:skipped / !:failed) - mail/dovecot (dovecot-1.1.2_1) Just a guess, are you running nscd? I've encountered problems with it caching stale information and ports running into trouble because of it. I haven't had time to report it. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: x11/xterm-227 does not like FreeBSD
I noticed this too but it was followed by an upgrade to 228 which seems to fix it On Wed, Jul 25, 2007 at 02:11:18PM -0700, Chris Timmons wrote: Greetings, When I upgraded to x11/xterm-227, I noticed that "rows" and "columns" as reported to the terminal device by xterm were set to 0: system:/home/cwt/xterm-227> stty all speed 38400 baud; 0 rows; 0 columns; Terminal applications would not properly recognize the window size until I re-sized the window manuall. After doing some research I found this in the xterm-228 release notes: # amend changes to handshake in patch #226 to accommodate Solaris, which relies on the extra setting of the terminal size after I/O initialization. Do this by adding new resource ptySttySize, which is false for Linux and MacOS X, i.e., true for for Solaris and other SVR4 platforms, as well as FreeBSD (reports by David Wood, Renato Botelho). You may want to hold off on that 'portupgrade -a' that you know wasn't a good idea to begin with until the port is upgraded :) -Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Uggg!
On Fri, Jun 01, 2007 at 02:15:48AM -0700, Ade Lovett wrote: On Jun 01, 2007, at 01:33 , Kris Kennaway wrote: > Download the packages from the FTP site and either reinstall them or > extract the +CONTENTS. This will work best if you don't have local > make.conf customizations, otherwise you will see variance. Actually, this does bring up a meta-issue that ports, pkgsrc, portage, all suffer from. What happens when the metadata gets blown away (by accident, hardware crash, flaming meteor from Mars, etc.) Is there anything we can do to mitigate this? Yes. It's an open-ended question. I also have no obvious solution. But I do see the need for such. -aDe gjournal :) My two cents: I've been using it on my laptop since soon after it was available in -current and I love it to pieces, it has been perfectly stable for me and I would be using it on my production servers it it were available in -stable. It seems like it would be an invaluable tool for developers or users who might expect crashes. I admit I am only using it on /usr, and my laptop has /var on /, but my crashes come from hardware or battery and I almost never compile while on battery. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"