Re: category customports
Hi, the short answer: echo 'VALID_CATEGORIES=local' >> /etc/make.conf On Thu, 18 Feb 2016, Walter Schwarzenfeld wrote: If I make an own port, I had it add to the category/Makefile. But this could be overwritten with the next update. If I make an own category I had it add to /usr/ports/Mk/bsd.port.mk under VALID_CATEGORIES. There is a Mk/bsd.local.mk for a reason. While it technically is under version control to provide a template (hopefully that changes at some point), it should not be comitted to unless strictly necessary. Two reasons to use the bsd.local.mk: 1) You use various make.conf files to build for different machines or testing options (use: `env __MAKE_CONF=/etc/test.conf make ...`) and putting it in bsd.local.mk centralizes it. One could also make a /etc/make.shared.conf in this case. Either / or. 2) You wish to set VALID_CATEGORIES based on some other (early available) variable. This is the better case for using this file as it is intended for extra logic, not extra configuration. Hope this helps, ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How to tell pkg it's OK to overwrite files by another port
Hi Baptiste, On Wed, 6 Aug 2014, Baptiste Daroussin wrote: On Wed, Aug 06, 2014 at 09:19:48PM +0200, Melvyn Sopacua wrote: Both are candidates for myconfig.conf, where optimized should win and otherwise default, but they come from two different ports. This may actually be the way to handle it, if @sample didn't assume the same basename. There is the @sample keyword for that ;) I don't think there is. @sample foo.sample sets target_file to foo. There's no way to specify that target_file should be bar. If two ports have the same .sample file, there is still a conflict. So in my case, I need two different .sample files installing to a shared target_file. I think this is a corner case, so I'll stick it in a custom pkg-install. -- Melvyn ___ 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 tell pkg it's OK to overwrite files by another port
Hi Baptiste, On Tue, 5 Aug 2014, Baptiste Daroussin wrote: On Tue, Aug 05, 2014 at 05:35:03AM +0200, Melvyn Sopacua wrote: Hi, the issue: for www/magento there is a sample data package. I'd like to make a port for it, but the sample data overwrites a few files in the www/magento port's installed files to match the sample theme. This is OK and needed. But I don't know how to tell pkg this. I can make the sample data an option in the magento port and keep it in one port, but this would put a large burdon on maintaining the pkg-plist on upgrades as sample-data is only updated when backwards incompatible changes are made to the core that make the older sample data unusable. So I prefer to maintain it as a separate port. There is a problem if that is how the port works. If magento expect some data to be replaced changed etc then it should not be tracked by the package to avoid an upgrade of the package to overwrite the user special version which is why pkg(8) has a strong hold on which files belongs to which package. So I think magento should be fixed in that regard. otherwise there is the PERMISSIVE options for pkg(8) but this is really really not recommanded to use. The best is again to fix the magento port so it allows the normal use cases. It's going to be a hack either way. Think of it as two sample files from different sources: default.conf.sample optimized.conf.sample Both are candidates for myconfig.conf, where optimized should win and otherwise default, but they come from two different ports. This may actually be the way to handle it, if @sample didn't assume the same basename. So I guess I have to install two different .sample files and a pkg-(de)install script that updates to the right one, keeping the actual file out of the pkg-plist. That's the least hack-ish I can come up with for now, but I'm open to suggestions. -- Melvyn ___ 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: WANT_PHP_WEB is just a synonym for WANT_PHP_CGI in automated build environments
Hi Matthew, On Mon, 4 Aug 2014, Matthew Pounsett wrote: As far as I can tell, the only way you get an installed version of PHP without either the CGI or FPM options set is to install mod_php5. That makes installing mod_php5 a prerequisite to making mod_php5 a dependency to any port that uses WANT_PHP_WEB. Now we're finally getting to the issue, let's cut the noise: - automated builds are not a factor. The bug is with the dependencies. - WANT_PHP_CGI is not a factor. The bug is that mod_php5 is not in the loop. So, let's see what happens: 1. databases/phpmyadmin has WANT_PHP_WEB set 2. On a clean environment I want to install that port and expect apache and mod_php5 built for me. 3. Because I don't want fpm or cgi, I unset the options for the lang/php5 options dialog. Expected result: phpMyAdmin depends on apache and mod_php5 among others. Result: # pkg query -F /var/packages/test/All/phpMyAdmin-4.2.7.txz %do lang/php5 archivers/php5-bz2 textproc/php5-ctype security/php5-filter devel/php5-json converters/php5-mbstring security/php5-mcrypt databases/php5-mysqli security/php5-openssl www/php5-session archivers/php5-zlib # pkg query -F /var/packages/test/All/php5-5.4.30.txz %do textproc/libxml2 devel/pcre # pkg info -lF /var/packages/test/All/php5-5.4.30.txz|grep bin/ /usr/local/bin/php /usr/local/bin/php-config /usr/local/bin/phpize So, there is no php-cgi or fpm, but www/mod_php5 is not in phpMyAdmin's dependencies, which means WANT_PHP_WEB is not satisfied, yet no errors are generated. Filed as: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192388 -- Melvyn ___ 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
How to tell pkg it's OK to overwrite files by another port
Hi, the issue: for www/magento there is a sample data package. I'd like to make a port for it, but the sample data overwrites a few files in the www/magento port's installed files to match the sample theme. This is OK and needed. But I don't know how to tell pkg this. I can make the sample data an option in the magento port and keep it in one port, but this would put a large burdon on maintaining the pkg-plist on upgrades as sample-data is only updated when backwards incompatible changes are made to the core that make the older sample data unusable. So I prefer to maintain it as a separate port. -- Melvyn ___ 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: WANT_PHP_WEB is just a synonym for WANT_PHP_CGI in automated build environments
Hello! On Sat, 2 Aug 2014, Matthew Pounsett wrote: It looks to me like the rules that WANT_PHP_WEB uses to decide whether to build the CGI or module version of PHP will always choose the CGI version unless the module is already installed. If this is true, it means that in automated build environments (e.g. tinderbox) – where *only* the direct dependencies of a port are installed at build time – there isn’t any way to tell WANT_PHP_WEB to install the module. This effectively makes WANT_PHP_WEB a synonym for WANT_PHP_CGI in these environments. I don't see the problem. If you want the mod_php module in your port set WANT_PHP_MOD. If you don't care which implementation it is as long as it can speak with a webserver, you set WANT_PHP_WEB. The WANT_PHP_WEB knob is for port maintainers that trust the system administrators that use the PHP software will know what suits them most. For automated builds use the OPTIONS framework. Tinderbox can handle that just fine. -- Melvyn ___ 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: WANT_PHP_WEB is just a synonym for WANT_PHP_CGI in automated build environments
Hi Matthew,
On Sun, 3 Aug 2014, Matthew Pounsett wrote:
On Aug 3, 2014, at 02:07 , Melvyn Sopacua mel...@magemana.nl wrote:
For automated builds use the OPTIONS framework. Tinderbox can handle
that just fine.
Right, and I’m speaking from the perspective of the admin building the
port, not the maintainer. The maintainer can set that the port will
work with either .. but in an automated build environment it looks
like there is no knob for the administrator to tell the ports system
which to use.
Unless that changed in recent years, you can have Tinderbox mount your
options database in /var/db/ports into the build jail. So you can do one
configure run and set it.
A second possibility is to simply add www/mod_php5 to ports to be built,
since it's no longer part of lang/php5. This won't work for the
upstream-abandoned php 5.3.
A third is to set php53_SET=APACHE in /etc/make.conf.
Again.. unless I’m missing some knob that exists to give guidance to
the ports system. I’m familiar with the options framework, but I
can’t find anything in bsd.php.mk that could be used to give guidance
to the ports system that mod_php5 is desired when WANT_PHP_WEB is
defined.
WANT_PHP_WEB actually pulls in the apache module if php is installed
only with the CLI or EMBED backend. See this bit:
if defined(WANT_PHP_MOD) || (defined(WANT_PHP_WEB) defined(PHP_VERSION) ${PHP_SAPI:Mcgi} ==
${PHP_SAPI:Mfpm} == )
USE_APACHE_RUN= 22+
.include ${PORTSDIR}/Mk/bsd.apache.mk
RUN_DEPENDS+=
${PHPBASE}/${APACHEMODDIR}/libphp5.so:${PORTSDIR}/${MOD_PHP_PORT}
.endif
--
Melvyn
___
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
Hi Adam, On Fri, 1 Aug 2014, Adam McDougall wrote: -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 While there certainly is a bug here (I'm bitten by it too), this is always a false comparison. %sb requests the flat size, which is the size after installation. The package size (which is what fetch is reporting) cannot be queried at the moment. I've added some extra debugging in the release-1.3 branch and am looking to reproduce it now. index 612..e2aa789 100644 --- a/libpkg/repo/binary/fetch.c +++ b/libpkg/repo/binary/fetch.c @@ -221,8 +221,8 @@ checksum: unlink(dest); pkg_emit_error(cached package %s-%s: -size mismatch, fetching from remote, -name, version); +size mismatch (%li != %li), fetching from remote, +name, version, pkgsize, st.st_size); return (pkg_repo_binary_try_fetch(repo, pkg, true, mirror, destdir)); } retcode = sha256_file(dest, cksum); -- Melvyn ___ 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
I've added some extra debugging in the release-1.3 branch and am looking to reproduce it now. Reported: https://github.com/freebsd/pkg/issues/906 -- Melvyn ___ 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: COPYTREE_BIN/COPYTREE_SHARE does not work as expected
Hi,
On Sun, 6 Jul 2014, Pawel Pekala wrote:
Dnia 2014-07-05, o godz. 12:04:57
Mikolaj Golub troc...@freebsd.org napisał(a):
Hi,
It looks like COPYTREE_BIN/COPYTREE_SHARE does not work as it is
documented in bsd.port.mk:
# Example use:
# cd ${WRKSRC}/doc ${COPYTREE_SHARE} . ${DOCSDIR}
! -name *.bak #
# Installs all directories and files from ${WRKSRC}/doc
# to ${DOCSDIR} except sed backup files.
If there is a *.bak file in . directory (e.g. test.bak), *.bak is
expanded to this name, the condition ! -name *.bak becomes ! -name
test.bak, and other *.bak files are ignored.
Worse, if there are several *.bak files, *.bak is expanded to the
list and COPYTREE_SHARE fails.
I made a mistake while documenting this macros, as '*' is a shell
wildcard it should be quoted. I believe the correct example should be:
cd ${WRKSRC}/doc ${COPYTREE_SHARE} . ${DOCSDIR} ! -name *.bak
It can't be done. sh -c will escape quotes.
I've simplified the test and modified it to show what's going on.
Your example doesn't escape the quotes, so quotes end and globbing
starts. The normal way to specify a glob to -name is '*.bak', so let's
see how that works out:
/bin/rm -rf /tmp/test_COPYTREE_SHARE
/bin/mkdir -p /tmp/test_COPYTREE_SHARE/src/1
/usr/bin/touch /tmp/test_COPYTREE_SHARE/src/1.bak
/usr/bin/touch /tmp/test_COPYTREE_SHARE/src/1/1.bak
/usr/bin/touch /tmp/test_COPYTREE_SHARE/src/1/2.bak
(cd /tmp/test_COPYTREE_SHARE/src /bin/sh -x -c '(/usr/bin/find -d $0
$2 | /usr/bin/cpio -dumpl $1 /dev/null 21) /usr/bin/find -d $0
$2 -type d -exec chmod 755 $1/{} \; /usr/bin/find -d $0 $2 -type f
-exec chmod 444 $1/{} \;' -- . /tmp/test_COPYTREE_SHARE/dst -not -name
'*.bak')
+ /usr/bin/find -d . -not -name \''*.bak'\'
+ /usr/bin/cpio -dumpl /tmp/test_COPYTREE_SHARE/dst
+ /usr/bin/find -d . -not -name \''*.bak'\' -type d -exec chmod 755
/tmp/test_COPYTREE_SHARE/dst/{} ';'
+ /usr/bin/find -d . -not -name \''*.bak'\' -type f -exec chmod 444
/tmp/test_COPYTREE_SHARE/dst/{} ';'
[ ! -f /tmp/test_COPYTREE_SHARE/dst/1/2.bak ]
*** [test1] Error code 1
Note how sh turns it into \''*.bak'\' effectively escaping the globbing
at find runtime. Similar if we swap quotes to '-not -name *.bak':
+ /usr/bin/find -d . -not -name '*.bak'
This has always been broken for globs as far as I know, which is why
cleaning up in post-patch is done.
I honestly think -fc is the best approach, since globbing the first path
is easily overcome and rare. Not having to run cleanup in post-patch has
advantages both at runtime and Makefile clutter.
Simplified test:
TESTDIR=/tmp/test_COPYTREE_SHARE
SH= /bin/sh -x
all: test1
test1:
${RM} -rf ${TESTDIR}
${MKDIR} ${TESTDIR}/src/1
${TOUCH} ${TESTDIR}/src/1.bak
${TOUCH} ${TESTDIR}/src/1/1.bak
${TOUCH} ${TESTDIR}/src/1/2.bak
(cd ${TESTDIR}/src ${COPYTREE_SHARE} . ${TESTDIR}/dst -not -name
'*.bak')
[ ! -f ${TESTDIR}/dst/1/2.bak ]
@${RM} -rf ${TESTDIR}
.include bsd.port.mk
___
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: COPYTREE_BIN/COPYTREE_SHARE does not work as expected
Hi Pawel,
On Sun, 6 Jul 2014, Pawel Pekala wrote:
Hi Melvyn,
On 2014-07-06 16:34 +0200, Melvyn Sopacua mel...@magemana.nl wrote:
+ /usr/bin/find -d . -not -name '*.bak'
This has always been broken for globs as far as I know, which is why
cleaning up in post-patch is done.
Little hackish, but this seems to work:
(cd ${TESTDIR}/src ${COPYTREE_SHARE} . ${TESTDIR}/dst -not -name *\.bak)
Wow, great find. Defenitely needs documentation :).
--
Melvyn
___
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: Porters Handbook update
On Sun, 6 Jul 2014, Kevin Oberman wrote: On Sun, Jul 6, 2014 at 12:59 AM, Frederic Culot cu...@freebsd.org wrote: Beloved porters, following some discussions related to the rights and duties of ports maintainers it became obvious that our handbook was not specific enough on the matter. Hence an update was committed that aims at clarifying the notion of maintainership and all porters are invited to peruse the changes: http://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer.html And of course, a big thanks to all of you who dedicate their time to maintain our ports! Frederic, with portmgr-secretary hat on excluding major public holidays to what segment of the public? Easy fix: exluding local (to the maintainer) bank holidays. However, in practice, it's not enforced that strict. Some periods people work 90 hours a week, some periods they have their weekends and some periods they leave the house when they have them. But, I'm rather surprised that maintainers now get their responsibilities spelled out, while there's no section on committers, and quite a shortage of them. From my own experience, there have been people coaching me and I thank them for it, but on average I have to chase down the PR's to get them committed. This takes time out of the maintaining part, especially if you work on ports that require dependencies to be updated or entered into the tree before they can be updated or entered. And let me stress this, this by no means an attack on individual committers or committers as a group. It is an observation of resources in order to discuss possible solutions. By this post [1], Getting a commit bit does not obligate you to process PRs. Isn't it time to: - relax (and spell out) requirements for ports-comitters and / or: - add processing PR's to the responsibilities of ports-comitters I've skimmed what I considered relevant sections of the committers-guide and did not find much. If I missed it, feel free to point me to the section. [1] http://lists.freebsd.org/pipermail/freebsd-ports/2014-January/089221.html -- Melvyn ___ 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
Ports that don't actually support Python 3.x
Hello, I'm coming accross a few ports that are in the tree as we speak, that do not actually install correctly with Python 3.x but aren't marked as 2.7 only. There seems to be 2 cases: 1. incompatibility in setup.py or related, thus failing in configure 2. incompatibility in the code itself, thus failing in byte_compile The ones in 2 fail with PYDISTUTILS_AUTOPLIST in install, because the files cannot be compiled and thus are missing when using the plist. I've got a few in PRs, few in the queue to become PR's, but perhaps a broader effort is needed? I'm willing to help, if an exp-run or something similar would generate a list. PS: A common error is: `except Exception, var:`. This can probably be fixed with a REINPLACE_CMD that can be standardized, but so far, bringing the port up-to-date with upstream fixes the problem (notable exception being www/py-beautifulsoup32). -- Melvyn ___ 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 that don't actually support Python 3.x
On Sun, 6 Jul 2014, Robert Simmons wrote: Beautiful Soup 3.x is Python 2.x only. From the website: I know that. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191387#c3 The port doesn't: http://svn.freebsd.org/ports/head/www/py-beautifulsoup32/Makefile That was the point of the mail. -- Melvyn ___ 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 that don't actually support Python 3.x
Hi Kubilay! On Mon, 7 Jul 2014, Kubilay Kocak wrote: On 7/07/2014 7:52 AM, Melvyn Sopacua wrote: Submit an issue with patch, I'll add maintainer_approval flag cc'ing maintainer if you cant, just let me know the issue ID :) Thought I submitted more already, but they're still in the queue and django-redis was comitted. Will submit tomorrow. We also gotta decide what you wanna do with www/py-django-mezzanine. I've created a www/py-django-mezzanine3 locally, as I wasn't sure if 1.x was kept in tree for existing projects that cannot migrate. Finally got it working (read: installing) fully (* marks py3.x fixes, - marks fixes bringing the ports to py3.x): % pkg install www/py-django-mezzanine3 Updating repository catalogue The following 31 packages will be installed: Installing gettext: 0.18.3.1_1 Installing sqlite3: 3.8.5_1 Installing libxml2: 2.9.1_1 Installing openssl: 1.0.1_13 Installing png: 1.5.18 Installing jpeg: 8_5 Installing python33: 3.3.5_1 Installing py33-setuptools33: 5.1_1 Installing py33-pycrypto: 2.6.1 Installing py33-slimit: 0.8.1 Installing py33-six: 1.5.2 Installing py33-django-appconf: 0.6_1 Installing py33-beautifulsoup: 4.3.2 - Installing py33-django-mezzanine3-grappelli: 0.3.11 - Installing py33-django-mezzanine3-filebrowser: 0.3.4 Installing py33-sqlite3: 3.3.5_4 Installing postgresql91-client: 9.1.13_1 Installing freetype2: 2.5.3_2 Installing py33-pytz: 2014.4,1 Installing py33-south: 1.0 Installing py33-requests: 2.3.0 * Installing py33-oauthlib: 0.6.3 - Installing py33-html5lib: 0.999_1 Installing py33-psycopg2: 2.5.3 * Installing py33-bleach: 1.4 Installing py33-pillow: 2.4.0 Installing py33-tzlocal: 1.1.1 * Installing py33-requests-oauthlib: 0.4.1 - Installing py33-django_compressor: 1.4 Installing py33-django: 1.6.5 - Installing py33-django-mezzanine3: 3.1.7 The installation will require 190 MB more space Let me know if you want a port www/py-mezzanine3 or upgrade existing. From the top of my head, at least www/py-flup is broken and one in the deps of virtualenvwrapper. -- Melvyn ___ 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
Porting OroCRM (Was: Re: maven and ports that try to fetch files during build stage)
Hi Mark, On Sat, 21 Jun 2014, Mark Linimon wrote: On Sat, Jun 21, 2014 at 12:02:32PM -0500, Pedro Giffuni wrote: This is a problem with the Apache POI port but it is also an issue with a potential Apache hadoop update: apparently our cluster doesn't like ports that download stuff as part of their build s/doesn't like/doesn't allow/ This is intentional so that we can understand exactly what it being installed by the port. I have a similar issue with a Symfony based project, called OroCRM. Basically all it installs are some templates, a few php files and symfony/composer configuration. In other words, after installation you haven't got a working product, but still have to run composer and download a bunch of stuff. To port this software I see that I have two choices: 1) I install it as the project itself [1] wants you to and thus the user has nothing to show for it. 2) I do the composer-dance myself, package and put it up for download. This has the downside that any local changes to the composer configuration file will not be picked up and I may break the application with upgrades. What would be advisable in this case? [1] http://www.orocrm.com/documentation/index/current/installation -- Melvyn ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: bmon-2.1.0_5
Hi Michelle, On Sat, 21 Jun 2014, Michelle Sullivan wrote: Don't know if maintainer of bmon is around as port is unstaged and 2.x (and the distfiles don't seem to exist in the master site) so submitted new port for net/bmon-devel - straight from github info here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191249 There is an official release. If you set GH_TAG to 3.2 and GH_COMMIT to d47fffc then just update the net/bmon port. You can get this info at: https://github.com/tgraf/bmon/releases -- Melvyn ___ 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: Way to make settings in /etc/make.conf effective only for ports
Hi Yasuhiro, On Sun, 22 Jun 2014, Yasuhiro KIMURA wrote: Recently I found some of settings for ports in /etc/make.conf interfere with other software project. So are there any way to make settings in /etc/make.conf effective only for ports? You can wrap those settings in .CURDIR check: .if !empty(.CURDIR:M/usr/ports/*) # port settings here .endif Alternatively, you can make a different file, say /etc/make.ports.conf and then build ports with the environment variable __MAKE_CONF set to it. -- Melvyn ___ 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 can I override global OPTIONS_UNSET for specific port in make.conf? www/xcache
Hi,
On Thu, 19 Jun 2014, Miroslav Lachman wrote:
I don't need DOCS, EXAMPLES etc. for each port as I normaly do not use them
on servers.
I have this line in make.conf
OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS
So how can I have globally disabled EXAMPLES and enable it only for one
specific port?
I don't know if there's a simpler way, but this will work:
OPTIONS_UNSET= X11 GUI CUPS DOCS NLS
.if empty(.CURDIR:M*/www/xcache)
OPTIONS_UNSET+= EXAMPLES
.endif
Of course, this gets more complex the more exceptions you want,
ultimately arriving at something like this
PORTS_WITH_EXAMPLES=www/xcache misc/foo
_WANT_EXAMPLES=0
OPTIONS_UNSET= X11 GUI CUPS DOCS NLS
.for port in ${PORTS_WITH_EXAMPLES}
.if !empty(.CURDIR:M*${port}) # not sure about this var expansion
_WANT_EXAMPLES=1
.endif
.if ${_WANT_EXAMPLES} == 0
OPTIONS_UNSET+= EXAMPLES
.endif
(untested)
--
Melvyn
___
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: Update php from 5.4 to 5.5 ?
Hi Kurt,
On Wed, 18 Jun 2014, Kurt Jaeger wrote:
For each module, I have to find the suitable php55 module to replace it.
So it will be a manual process, for now.
Not entirely...
www/pecl-APC: doesn't support PHP 5.5
That's real. But it's APC. It's somewhat dying, somewhat staying around
for it's API, since Zend Optimizer hit 5.4 in beta and 5.5 fully.
devel/php5-pcntl: doesn't support PHP 5.2 5.3 5.5
security/php5-openssl: doesn't support PHP 5.2 5.3 5.5
databases/php5-mysqli: doesn't support PHP 5.2 5.3 5.5
databases/php5-pdo: doesn't support PHP 5.2 5.3 5.5
databases/php5-mysql: doesn't support PHP 5.2 5.3 5.5
databases/php5-pdo_mysql: doesn't support PHP 5.2 5.3 5.5
security/php5-mcrypt: doesn't support PHP 5.2 5.3 5.5
databases/php5-pdo_sqlite: doesn't support PHP 5.2 5.3 5.5
converters/php5-mbstring: doesn't support PHP 5.2 5.3 5.5
databases/php5-pdo_pgsql: doesn't support PHP 5.2 5.3 5.5
net/php5-ldap: doesn't support PHP 5.2 5.3 5.5
devel/php5-json: doesn't support PHP 5.2 5.3 5.5
databases/php5-pgsql: doesn't support PHP 5.2 5.3 5.5
mail/php5-imap: doesn't support PHP 5.2 5.3 5.5
sysutils/php5-posix: doesn't support PHP 5.2 5.3 5.5
converters/php5-iconv: doesn't support PHP 5.2 5.3 5.5
security/php5-hash: doesn't support PHP 5.2 5.3 5.5
www/php5-session: doesn't support PHP 5.2 5.3 5.5
math/php5-gmp: doesn't support PHP 5.2 5.3 5.5
devel/php5-gettext: doesn't support PHP 5.2 5.3 5.5
textproc/php5-simplexml: doesn't support PHP 5.2 5.3 5.5
net/php5-soap: doesn't support PHP 5.2 5.3 5.5
net/php5-sockets: doesn't support PHP 5.2 5.3 5.5
databases/php5-sqlite3: doesn't support PHP 5.2 5.3 5.5
devel/php5-tokenizer: doesn't support PHP 5.2 5.3 5.5
textproc/php5-xml: doesn't support PHP 5.2 5.3 5.5
textproc/php5-wddx: doesn't support PHP 5.2 5.3 5.5
archivers/php5-zip: doesn't support PHP 5.2 5.3 5.5
archivers/php5-zlib: doesn't support PHP 5.2 5.3 5.5
www/mod_php5: doesn't support PHP 5.3 5.5
graphics/php5-exif: doesn't support PHP 5.2 5.3 5.5
textproc/php5-dom: doesn't support PHP 5.2 5.3 5.5
sysutils/php5-fileinfo: doesn't support PHP 5.2 5.3 5.5
ftp/php5-curl: doesn't support PHP 5.2 5.3 5.5
security/php5-filter: doesn't support PHP 5.2 5.3 5.5
textproc/php5-ctype: doesn't support PHP 5.2 5.3 5.5
graphics/php5-gd: doesn't support PHP 5.2 5.3 5.5
archivers/php5-bz2: doesn't support PHP 5.2 5.3 5.5
textproc/php5-xmlreader: doesn't support PHP 5.2 5.3 5.5
textproc/php5-xsl: doesn't support PHP 5.2 5.3 5.5
textproc/php5-xmlwriter: doesn't support PHP 5.2 5.3 5.5
archivers/php5-phar: doesn't support PHP 5.2 5.3 5.5
I believe most of these - if not all - are cosmetic errors.
You can do the following:
pkg query -e '%o ~ */php5-*' '%o'| while read origin; do \
new_origin=`echo ${origin} | sed -e 's/php5-/php55-/'`
echo portmaster -o ${new_origin} ${origin}; done update.sh
Then execute update.sh.
I do this in 2 steps, so that /dev/stdin is free for portmaster to use.
--
Hope this helps,
Melvyn
___
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
Seeking committer(s)
Hi, looking for committer(s) for: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189885 (Once this is added, will finalize magento 1.9.0.1) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190163 (Maintainer timeout) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189873 (Essential for Magento Developers and Support Engineers) Also would be nice if 'My Requests' was nuked from the main menu in Bugzilla and replaced by 'My Bugs'. I have no idea what 'My Requests' is supposed to be and 'My Bugs' is hidden way when it should be front and center for maintainers. -- Melvyn ___ 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: Seeking committer(s)
Hi Kurt,
On Sun, 15 Jun 2014, Kurt Jaeger wrote:
= Couldn't fetch it - please try to retrieve this
= port manually into /usr/ports/distfiles/ and try again.
It works with
USE_GITHUB= yes
GH_ACCOUNT= netz98
GH_PROJECT= n98-magerun
GH_COMMIT= 4b31f25
NO_BUILD= yes
WRKSRC= ${WRKDIR}/${GH_ACCOUNT}-${GH_PROJECT}-${GH_COMMIT}
But it fetches a different version. You can probably live with that ?
Rather not. They do proper release tagging, so let's work with them.
As indicated in the bugzilla report, I suspect you were using an IPv6
only host in your test.
It is/was working for me as submitted. I don't mind changing PORTVERSION
to .2 and submit a new patch for you, saves an extra PR.
--
Melvyn
___
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: Seeking committer(s)
Hi Kurt,
On Sun, 15 Jun 2014, Kurt Jaeger wrote:
It is/was working for me as submitted. I don't mind changing PORTVERSION
to .2 and submit a new patch for you, saves an extra PR.
Please have a look at my fetch log:
http://people.freebsd.org/~pi/misc/magerun-fetch
Well, I'll be damned:
fetch
'https://codeload.github.com/netz98/n98-magerun/legacy.tar.gz/1.89.1?dummy=n98-magerun-1.89.1.tar.gz'
1.89.1?dummy=n98-magerun-1.89.1.tar.gz100% of 1679 kB 1036 kBps
00m02s
ls -al 1.89.1\?dummy=n98-magerun-1.89.1.tar.gz|awk '{ print $5 }'
1719495
fetch
'https://codeload.github.com/netz98/n98-magerun/tar.gz/1.89.1?dummy=n98-magerun-1.89.1.tar.gz'
1.89.1?dummy=n98-magerun-1.89.1.tar.gz100% of 1679 kB 1051 kBps
00m02s
ls -al 1.89.1\?dummy=n98-magerun-1.89.1.tar.gz|awk '{ print $5 }'
1719486
If you could just run a make makesum, then no other modifications will
be needed. It's just a github thing and I got a local patch that uses
tar.gz instead of the legacy.tar.gz thing. Totally forgot about it, as I
did that way back when things with codeload were screwed up (and added
nodeload.github.com in the process).
I'll revert my local patch, so that I don't submit the same mistakes in
the future.
--
Melvyn
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: port maintainership of alpine?
Hi all, since I'm a daily user.. On Sat, 24 May 2014, Kurt Jaeger wrote: I've put it on http://people.freebsd.org/~pi/misc/alpine-2.11.tar.xz Feel free to drop me a line too for help or time constraints. Just know I'll be evading the ncurses stuff ;-) -- Melvyn ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: lang/gcc and tmpfs no space let on device
On Fri, 16 May 2014, Marko Cupać wrote:
This is the point of failure:
libtool: compile: /usr/ports/lang/gcc/work/build/./gcc/gcj
-B/usr/ports/lang/gcc/work/build/x86_64-portbld-freebsd10.0/libjava/
-B/usr/ports/lang/gcc/work/build/./gcc/
-B/usr/local/x86_64-portbld-freebsd10.0/bin/
-B/usr/local/x86_64-portbld-freebsd10.0/lib/
-isystem /usr/local/x86_64-portbld-freebsd10.0/include
-isystem /usr/local/x86_64-portbld-freebsd10.0/sys-include
-fomit-frame-pointer -Usun -fclasspath=
-fbootclasspath=../.././../gcc-4.7.3/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c
-fsource-filename=/usr/ports/lang/gcc/work/build/x86_64-portbld-freebsd10.0/libjava/classpath/lib/classes
-MT javax/management.lo -MD -MP -MF javax/management.deps
@javax/management.list -fPIC -o javax/.libs/management.o jc1: fatal
error: error writing to /tmp/ccmi9d4D.s: No space left on device
In case you can't afford enough space:
cat 'EOF' lang/gcc/Makefile.local
TMPDIR:=/var/tmp
MAKE_ENV+=TMPDIR=${TMPDIR}
EOF
--
Melvyn
___
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: ACTION REQUIRED - Unstaged Ports being DEPRECATED on June 31st.
On Mon, 12 May 2014, John Marino wrote: I commit PR patches that are 6 to 18 months old fairly frequently. There is obviously a huge backlog but many PRs are processed daily. The PRs that aren't getting processed quickly are [NEW PORT] PRs (and apparently anything mentioning fuse-fs for some reason). A staging PR is going to jump the line; it has a higher priority. Why would you even entertain the idea that a staging PR will fall between the cracks? Perhaps the better question is: what are the factors that will make committers shy away from a PR, even if it's summary contains stage? [1] Maybe we (maintainers) can do better? [1] http://www.freebsd.org/cgi/query-pr-summary.cgi?category=portsseverity=priority=class=maintainer-updatestate=opensort=nonetext=responsible=multitext=stageoriginator=release= -- Melvyn ___ 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: ACTION REQUIRED - Unstaged Ports being DEPRECATED on June 31st.
Hi, On Mon, 12 May 2014, John Marino wrote: On 5/12/2014 20:49, Melvyn Sopacua wrote: On Mon, 12 May 2014, John Marino wrote: I commit PR patches that are 6 to 18 months old fairly frequently. There is obviously a huge backlog but many PRs are processed daily. The PRs that aren't getting processed quickly are [NEW PORT] PRs (and apparently anything mentioning fuse-fs for some reason). A staging PR is going to jump the line; it has a higher priority. Why would you even entertain the idea that a staging PR will fall between the cracks? Perhaps the better question is: what are the factors that will make committers shy away from a PR, even if it's summary contains stage? [1] Maybe we (maintainers) can do better? [1] Heh, 54 out of 2000+ PRs isn't too bad. :) Ok..2000 ports PR's open at given time on how many committers? Starting to look like Kurt has the right idea here. I doubt most cases are people intentionally passing over an ugly PR. I am sure it happens but staging is generally straightforward so the PR itself isn't going to scare someone off. Well, mine (ports/188901) I can see why someone walks around it, cause the patch is 1MB and needs to be downloaded. The bulk is of course the giant plist introduced by staging (and we can blame Zend for a file-intensive boilerplate heavy framework, but that's another topic). However, I don't see a way to make it more attractive, which is why I asked. -- Melvyn ___ 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
Make loosing a variable (emulators/virtualbox-ose-additions)
Hi, emulators/virtualbox-ose-additions always fails for me in the stage installation, so today I looked a bit further: Bad: install -o root -g wheel -m 444 /usr/obj/ports/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.3.10/out/freebsd.amd64/release/bin/additions/vboxvideo_drv_.so /usr/obj/ports/usr/ports/emulators/virtualbox-ose-additions/work/stage/usr/local/lib/xorg/modules/drivers/vboxvideo_drv.so Good: install -o root -g wheel -m 444 /usr/obj/ports/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.3.10/out/freebsd.amd64/release/bin/additions/vboxvideo_drv_17.so /usr/obj/ports/usr/ports/emulators/virtualbox-ose-additions/work/stage/usr/local/lib/xorg/modules/drivers/vboxvideo_drv.so The difference between bad and good are the 17 missing in the shared object name. The bad line is created in a clean build and the good line if one invokes the install target immediately after that failed one. Is make really loosing a variable here or could this be a parallelization issue in the upstream build system? -- Melvyn ___ 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: libfreetype.so.9 errors
On Sun, 20 Apr 2014, Beeblebrox wrote:
Use sysutils/libchk and 'pkg which' to find the port that is linked
against the old library and needs rebuild.
Irrelevant - full poudriere run means I am re-building all ports from a full
list of ports installed on the system. Also, the UPDATING entry from
20140416 only applies if one uses portmaster/portupgrade as updating method.
When using pre-built binaries, pkgng should be taking care of all of these
issues internally. It would not work only if:
* poudriere is unable to detect the certain binaries that need to be
re-built
* An internal pkg error causes some ports to be skipped and not re-installed
(both of which are unlikely)
* The ports in question have not made the transition as yet (which is the
most likely scenario)
* portstree changed during build (just adding for completeness).
A second library joins the cause: libxcb.so.2 is called by some binaries but
only libxcb.so.1.1.0 exists.
Perhaps it's also time to add some consistency:
find . -depth 3 -name Makefile -exec grep -h 'print/freetype2' {} + | \
sed -E -e 's,^(.*=)?[[:space:]]+([^[:space:]]+).*$,\2,' \
-e '/^#/d' | sort | uniq -c |sort -rn
122 libfreetype.so:${PORTSDIR}/print/freetype2
67 freetype:${PORTSDIR}/print/freetype2
46 freetype.9:${PORTSDIR}/print/freetype2
2 libfreetype.so.9:${PORTSDIR}/print/freetype2
1 freetype-config:${PORTSDIR}/print/freetype2
1 ${LOCALBASE}/bin/freetype-config:${PORTSDIR}/print/freetype2
1 ${FREETYPE_WRKSRC}/config.mk:${PORTSDIR}/print/freetype2:build
___
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
Hi, On Thu, 10 Apr 2014, RW wrote: It's newer than the recently reworked version of the options framework, but /var/db/port was used for options before that. Aha! So that's what I missed, thank you. It also doesn't affect me, since I now build my packages using PORT_DBDIR=/var/db/ports/$machine_name so I can differentiate between (types of) machines. Thanks again for clarifying that, RW. -- Melvyn ___ 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
Hi, On Wed, 9 Apr 2014, John Marino wrote: This still doesn't make sense. Distfiles are of no concern to binary packages, so why would I continue to clutter /var/db/pkg with a large tree of directories that is then duplicated to /var/db/ports? What problem in portmaster or the options framework was solved by moving this? If the portmaster-created distfiles bother you, stop using portmaster, perhaps? It seems superfluous to me anyway; I don't get why people feel they need it with pkg. I already did a while back. Yet, it's still the recommended tool in the handbook if I'm not mistaken. FreeBSD has also always adhered to a sensible hier(7), which portmaster is now breaking. IFAIK, options has always been in /var/db/ports, this is not new. It didn't get moved. Correct. Portmaster moved it's distfiles file. I'm not sure what you are trying to achieve with the what problem was solved line of questioning. If it were moved, are you trying to get it moved back? What's the goal here? Yeah. One of the advantages and early implementation goals of pkg(1) was to reduce clutter in /var/db/pkg. Secondly, 70-80% of common ports now use an options file (think DOCS, EXAMPLES, NLS), so the chance that /var/db/ports/portname already exists is pretty high. Why then reintroduce files/directories in /var/db/pkg that affect both port building and deployment? I don't understand what the upside to this change in portmaster is and thus assume that it solved an issue. -- Melvyn ___ 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
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? -- Melvyn ___ 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
Hi, So, after the detour... On 4/9/2014 12:38, Melvyn Sopacua wrote: Though it makes no sense in my mind. Distfiles belong to ports not packages. What problem was solved by moving this? This still doesn't make sense. Distfiles are of no concern to binary packages, so why would I continue to clutter /var/db/pkg with a large tree of directories that is then duplicated to /var/db/ports? What problem in portmaster or the options framework was solved by moving this? ___ 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
Clang with libc++ on 9.x and nghttp2
Hi,
seeing r350552 I fixed something related locally as below. I don't think
the fix is 100% correct (cause I haven't the faintest clue how
compiler.mk actually sets compiler flags), but it does the job and gets
rid of lang/gcc.
I do think that the testing for _CXXINTERNAL in Uses/compiler.mk is
incorrect, at least if one truely wants to test for clang being capable
of c++11 features.
diff -r 14e2c13e58e1 -r e0ade5980519 Mk/Uses/compiler.mk
--- a/Mk/Uses/compiler.mk Sat Apr 05 08:07:55 2014 +0200
+++ b/Mk/Uses/compiler.mk Sat Apr 05 20:46:45 2014 +0200
@@ -101,7 +101,7 @@
.endif
.if ${_COMPILER_ARGS:Mfeatures}
-_CXXINTERNAL!= ${CXX} -\#\#\# /dev/null 21
+_CXXINTERNAL!= ${CXX} -std=c++11 -stdlib=libc++ -\#\#\# /dev/null 21
.if ${_CXXINTERNAL:M\-lc++\}
COMPILER_FEATURES= libc++
.else
diff -r 14e2c13e58e1 -r e0ade5980519 www/nghttp2/Makefile
--- a/www/nghttp2/Makefile Sat Apr 05 08:07:55 2014 +0200
+++ b/www/nghttp2/Makefile Sat Apr 05 20:46:45 2014 +0200
@@ -3,6 +3,7 @@
PORTNAME= nghttp2
PORTVERSION= 0.3.2
+PORTREVISION= 1
CATEGORIES=www net
MASTER_SITES=
https://github.com/tatsuhiro-t/${PORTNAME}/releases/download/v${PORTVERSION}/ \
LOCAL/sunpoet
@@ -30,7 +31,7 @@
USE_GNOME= libxml2
USE_LDCONFIG= yes
USE_OPENSSL= yes
-USES= compiler:c++11-lang pathfix pkgconfig tar:xz
+USES= compiler:c++11-lib pathfix pkgconfig tar:xz
PORTDOCS= *
@@ -41,6 +42,8 @@
.if ${OSVERSION} 100 !defined(WITH_OPENSSL_PORT)
IGNORE=nghttp2 requires OpenSSL 1.0.1+
+.elif ${OSVERSION} 100
+CXXFLAGS+= -stdlib=libc++
.endif
post-build:
___
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
Hi, On Wed, 2 Apr 2014, Jakob Breivik Grimstveit wrote: /var/db/pkg only contains these files: $ find /var/db/pkg [...] /var/db/pkg/libyaml-0.1.6 /var/db/pkg/libyaml-0.1.6/distfiles /var/db/pkg/gcc-ecj-4.5 /var/db/pkg/gcc-ecj-4.5/distfiles /var/db/pkg/cmake-modules-2.8.10.2 /var/db/pkg/cmake-modules-2.8.10.2/distfiles [...] Why do you have files that portmaster sticks in /var/db/ports in /var/db/pkg? Did you perhaps switch those directories on restore or have a faulty value in PORT_DBDIR? If so, does +CONTENTS exist in /var/db/ports/libyaml-0.1.6? ___ 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
Owner/group or permissions for directories
Hello, is there a way to have parent directories of files be created with same owner or permissions as the files? In addition: @mode a+w ... @mode behaves unexpected. chmod a+w doesn't clear r and x, yet mode in pkg-plist does so I end up with files that have -w--w--w-. And of course their parents still have 755 with root/wheel. I prefer not to resort to @exec or post install scripts but I don't see I have a choice here. -- Melvyn ___ 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: Blanket approval to modernize the Ports Tree
On Tue, 7 Jan 2014, FreeBSD Ports Management Team Secretary wrote: This can be done with implicit portmgr@ blanket approval, and without maintainer approval. Please, however, respect some boundaries, do not change ports belonging to kde@, gnome@ or x11@. These teams work in private repos that may have changes pending. I've had an update for www/magento sent a few months back, which landed in spam. Replied to the bugbuster address and never saw any follow up. Work then took a lot of a time, so I didn't chase this down. Please note however, that I'm working on the 1.8.1.0 upgrade, which will convert to stage in the process. As a precaution, I'll put a link up to the patch, rather then add it to the mail as an attachment. It will be rather big, cause of the conversion to a pkg-plist. In short, hands off please, it's being worked on. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Proposal for Authors / Vendors in ports
On Fri, 15 Nov 2013, Stefan Esser wrote: Am 15.11.2013 08:23, schrieb Matthew Seaman: On 15/11/2013 00:54, Eitan Adler wrote: On Thu, Nov 14, 2013 at 5:41 PM, Jaap Akkerhuis jaa...@xs4all.nl wrote: On Nov 14, 2013, at 8:30, Erwin Lansing er...@freebsd.org wrote: That sounds like an excellent idea. I'm just a bit worried about spreading the information over too many places, and would rather split content from logic and add these to pkg-descr as well next to the current WWW. I know we're not consistent already with things like COMMENT and LICENSE already in the Makefile, so won't ojbect too much to where these end up. Apart from spreading this information into to many places (pkg_desc seams a proper place to have such information), why have the Makefile double up as a database? pkg_descr is free form. Makefiles are parsable (make -V). pkg_descr is only as free-form as we define it to be. It's a lot quicker to parse out the WWW entry from pkg_descr than it is to run 'make -V' to extract values from port Makefiles. That's because make includes and parses a whole stack of different files from /usr/ports/Mk and elsewhere and does a bunch of other processing -- takes about 200ms per port just to print out the variables used in the INDEX. +1. I also fail to see the upside of adding extra variables to the makefiles. Requestor of this feature already hinted it's going to be queried using the pkg command, so all it needs is a pkg command that can parse a single line into 2 meaningful chunks, using well-defined delimiters. In addition, there's no descision being made based upon these variables in the building/installation process. So, unless the variable is needed as part of the build process for a port putting it in pkg_decr makes sense to me. This could include some well-known values like MAINTAINER if we want to go that far. Two comments: 1) I think that pkg-descr contains information about the ported software, not the port. I.e. the web-site, the organisation, or the license are good candidates for pkg-descr. The maintainer or other information that does not relate to the ported software itself but just to how it is managed in the FreeBSD ports tree should be kept in some other place. (IMHO) License is used in port building logic. Adding more metadata to pkg-descr fills up the 4k holes mentioned earlier in the thread and adds possibilities for sites like freshports to add more content with minimal effort. Since metadata and description are words with similar meaning, I don't see a need for a name change or new file, as proposed earlier. 2) If meta-information is moved to pkg-descr, it might be worthwhile to add some knowledge about formats and restrictions to portlint. +1 -- Melvyn Sopacua ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Proposal for Authors / Vendors in ports
On Wed, 13 Nov 2013, Kris Moore wrote: Wanted to run this by the ports community, see your thoughts. We build our PBIs from the ports system, and are able to parse most of the information out for display graphically, like descriptions, maintainers, website, License, etc. However we currently don't have a way to pull the actual name of the upstream vendor / author. I.E. for Firefox the vendor would be Mozilla. WWW: [Mozilla](http://www.mozilla.org/) So, markdown format in pkg-descr. Seems the least amount 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: Anyone looked at making a port for https://www.eff.org/https-everywhere ?
On Thu, 7 Nov 2013, Mark Felder wrote: Do we actually have ports for other browser plugins (besides flash/java)? ll $PORTSDIR/www|grep xpi But this one easily installs via an extension and doesn't require compilation / bugfixing, like f.e. yslow. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Staging and directory modes/ownerships
Hi,
I'm trying to upgrade www/magento and in the process make it use the
stage. Aside from having to package a fixed plist again to set modes and
ownerships, I can no longer find a way to set these properties on
directory trees.
The short version:
How do I convert the following in do-install to work with staging?
${CHOWN} -R ${WWWOWN}:${WWWGRP} ${PREFIX}/www/magento/media
${FIND} ${PREFIX}/www/magento -type d -exec ${CHMOD} a+w {} +
Note that this *has* to ensure that if the top level directory exists
and has a different mode/owner they are changed.
I tried using @mode and @owner on the first occurance of the top-level
directory in the pkg-plist but this only sets the properties for the
files in question.
Since @mkdir is ignored and @exec frowned upon, I don't see a proper way
to do this.
For now I'll go with adding @exec commands to ${TMPPLIST}, I suppose.
--
Melvyn Sopacua
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Staging and directory modes/ownerships
On Sun, 3 Nov 2013, Tijl Coosemans wrote:
On Sun, 3 Nov 2013 14:47:00 +0100 (CET) Melvyn Sopacua wrote:
I'm trying to upgrade www/magento and in the process make it use the
stage. Aside from having to package a fixed plist again to set modes and
ownerships, I can no longer find a way to set these properties on
directory trees.
After converting the Makefile for staging you can create an initial
pkg-plist using make makeplist. Later you can also check for missing
items using make check-orphans.
Yes, I've read the Wiki page. I still opted to create my own genplist
target and wrap it in MAINTAINER_MODE to start handling some of the %%
variables.
For now I'll go with adding @exec commands to ${TMPPLIST}, I suppose.
Would this work:
@owner www
@group www
www/magento/media/foo/bar
If bar is a directory, I expect to see errors from the package tools
here, but I haven't tried it. If bar is a file, then it doesn't change
owner of media/foo (tested). Further more, it would be rather hard to do
so, since in this case, www/magento should be left untouched.
@mode 0777
@dirrm www/magento/media/foo
This directive is processed on deinstallation. I don't think it will
work but I have not tested it.
Thanks for answering.
--
Melvyn Sopacua
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Staging and directory modes/ownerships
On Sun, 3 Nov 2013, Tijl Coosemans wrote:
On Sun, 3 Nov 2013 22:22:24 +0100 (CET) Melvyn Sopacua wrote:
On Sun, 3 Nov 2013, Tijl Coosemans wrote:
On Sun, 3 Nov 2013 14:47:00 +0100 (CET) Melvyn Sopacua wrote:
I'm trying to upgrade www/magento and in the process make it use the
stage. Aside from having to package a fixed plist again to set modes and
ownerships, I can no longer find a way to set these properties on
directory trees.
For now I'll go with adding @exec commands to ${TMPPLIST}, I suppose.
Would this work:
@owner www
@group www
www/magento/media/foo/bar
If bar is a directory, I expect to see errors from the package tools
here, but I haven't tried it. If bar is a file, then it doesn't change
owner of media/foo (tested). Further more, it would be rather hard to do
so, since in this case, www/magento should be left untouched.
bar is a file. Only files can be listed like this. Directories always
have @dirrm. @owner, @group and @mode apply to all the following entries,
so the directories listed below are also owned by www. This works at
least with pkg. I don't know if it works with the old pkg_install tools.
Can you confirm if it works with pkg if the directory already exists and
has different owner? It doesn't with pkg_install, so I might just wrap
the @exec if pkg isn't used.
--
Melvyn Sopacua
___
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 tree broken with cycling dependencies
On Friday 14 September 2007 18:48:44 Dmitry Morozovsky wrote: On Fri, 14 Sep 2007, Andriy Gapon wrote: AG It seems that after todays portsnap (1 hour ago) my port tree is broken AG by having cycling dependencies. AG Example: AG /usr/ports/graphics/cairo$ make all-depends-list | grep pango AG /usr/ports/x11-toolkits/pango AG /usr/ports/x11-toolkits/pango$ make all-depends-list | grep cairo AG /usr/ports/graphics/cairo AG AG I think the root cause is that x11/xorg-libraries port has (run) AG dependency on x11/pixman port which has a (auto-detected) dependency AG USE_GNOME+=gtk20 where gtk20 port, of course, has a dependency on AG xorg-libraries. Actually, gtk20 now does not have to have all xorg-libraries depends, which is fixed with rev 1.201 of Makefile (no PORTREVISION change though) - see my other mails in this ML. Negative: grep FreeBSD: Makefile make all-depends-list | grep pixman (cd ../../x11/xorg-libraries make all-depends-list|grep pixman) # $FreeBSD: ports/x11-toolkits/gtk20/Makefile,v 1.201 2007/09/14 04:51:56 marcus Exp $ /usr/ports/x11/pixman /usr/ports/x11/pixman Work-around: # cat /usr/ports/x11/pixman/Makefile.local .undef WANT_GNOME And yes, I realize it does: checking for GTK... yes But at least the cyclic dep is gone, till it gets properly fixed. FYI: cvsup'd ~30 mins ago, using cvsup10.freebsd.org. -- Melvyn Sopacua [EMAIL PROTECTED] FreeBSD 6.2-STABLE Qt: 3.3.8 KDE: 3.5.7 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
