Re: Flavors *COMPLETELY* break the port system (synth and poudriere are useless)
On 12/07/2017 12:36 AM, Mel Pilgrim wrote: > As for those complaining about, it's a remarkably small number of very > loud people, Let's not jump to the conclusion that since only the vocal minority who complains, then they are the only ones affected. Plenty of us are just silently waiting for a portmaster fix, seeing as complaints have no visible effect. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADUP] FLAVORS landing.
On 09/26/2017 05:38 PM, George Mitchell wrote: >> What is the last SVN revision without the changes? I just updated a >> few minutes ago and portmaster is already unable to build lang/perl5.24 >> to fix a security vulnerability. -- George > > Empirically, 450588 seems to still work. -- George The first FLAVORS commit is [1], but I think portmaster still generally works as before. The failure you're seeing with lang/perl5.24 is also there if you build it manually. [1] https://svnweb.freebsd.org/ports?view=revision=450663 ___ 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: Looking for porting experience
On 07/10/2017 12:05 AM, Jake Roberts via freebsd-ports wrote: > Good evening. I'd like to try my hand at making a port. You could submit an update to x11-fonts/unifont [1] from 7.0.3 to the current 10.0.04 [2]. This is both easy, and useful (for those running FreeBSD on desktop). There's also a fairly extensive list of tasks at [3]. [1] https://www.freshports.org/x11-fonts/gnu-unifont/ [2] https://lists.gnu.org/archive/html/unifont/2017-07/msg1.html [3] https://wiki.freebsd.org/PortsTasks ___ 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: Inconsistency? (was Re: misc/jive deleted)
> can anyone in > this thread explain why misc/jive is considered offensive and removed I'd like to extend the question: is there a new policy about "offensive" ports not being allowed in the ports tree any longer? If so, could someone point me to it? If not, then, well, I don't know what to say. You leave me very confused. Was the removal arbitrary? Is someone working on updating ports tree policies? ___ 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: LICENSE documentation
On 2016-09-14 11:49, Kurt Jaeger wrote: >> My interpretation of this phrase is not that LICENSE variable is >> mandatory (to which I would object on the basis that ports licensing >> framework is vague, incomplete, and apparently used by noone too), but >> rather that for the program to be freely distributable at all, it's >> author(s) need to explicitly give their permission. That permission is >> the license. If no license statement can be found in the sources or the >> website, then no permission is given, and it's technically illegal for >> anyone but the author(s) to use the software. > > This interpretation is based on the hypothesis > that the user is located in a country that has this kind of legal rule. > > This is not the case in every country, so your conclusion is not > always valid. That's true. Still, the inclusion of the program in ports collection depends on author(s) giving their permission, otherwise users in majority of countries FreeBSD is used in will be disqualified from using it -- and FreeBSD would probably be liable for copyright infringement too. ___ 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: LICENSE documentation
On 2016-09-14 10:19, Bob Eager wrote: > This port never did have LICENSE, and it had been updated recently with > no issues. However, I was told that "I don't see any mention of any > kind of license in the package or on the site, so it should be > LICENSE= NONE. Note that without clear licensing terms it's impossible > to legally use and redistribute the code." My interpretation of this phrase is not that LICENSE variable is mandatory (to which I would object on the basis that ports licensing framework is vague, incomplete, and apparently used by noone too), but rather that for the program to be freely distributable at all, it's author(s) need to explicitly give their permission. That permission is the license. If no license statement can be found in the sources or the website, then no permission is given, and it's technically illegal for anyone but the author(s) to use the software. If this is the case, I suggest you to contact the authors, explain the situation, and ask them to include some sort of a license statement -- we'll be forced to remove the program from ports collection otherwise. ___ 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: opensmtpd / openssl 1.0.2_8 problem
On 01/29/16 22:00, Pietro Cerutti wrote: > On 2016-Jan-29, 19:29, Pietro Cerutti wrote: >> I got reproducible errors in opensmtpd since I upgrade OpenSSL to >> 1.0.2_8 today. 1.0.2_4 is fine. I'm bisecting versions right now. > > OpenSSL 1.0.2e works fine, 1.0.2f does not. > >> >> Anybody else got hit by this? >> >> Jan 29 18:08:36 mail smtpd[31270]: smtp-in: session 16287480c99a20ee: >> connection from host mail.ptrcrt.ch [192.168.1.1] established >> Jan 29 18:08:36 mail smtpd[31268]: warn: lka -> pony: pipe closed >> Jan 29 18:08:36 mail smtpd[31267]: warn: control -> pony: pipe closed >> Jan 29 18:08:36 mail smtpd[31265]: warn: parent -> pony: pipe closed >> Jan 29 18:08:36 mail smtpd[31266]: warn: queue -> pony: pipe closed >> Jan 29 18:08:36 mail smtpd[31271]: warn: ca -> pony: pipe closed >> Jan 29 18:08:36 mail smtpd[31269]: warn: scheduler -> control: pipe closed >> >> At this point the service goes down. I'm seeing the same problem, and I'd really, really like to have my smtpd running again. ___ 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: help categorise license
On 2015-07-27 13:52, Kubilay Kocak wrote: (Also note that our license framework should probably be scrapped entirely, because it is ambiguous and undocumented). Or it could just be made less ambiguous and documented. Otherwise, we should scrap entirely all other things that are also ambiguous and undocumented. I imagine this will be a large list, and include large parts of the kernel. You're right, ambiguous and undocumented is not a great summary. My bad. I did not want to write an essay in an off-hand remark though, so let me clarify. What I mean is that it's not clear, not documented, and probably not widely agreed upon, what guarantees should the framework provide, or what use cases should it serve. Hence ambiguous and undocumented. If we where to resolve those questions, and document the result in the handbook, the complaint would be resolved. As an example: if a given port consists of a program, a few libraries, a set of documentation and a test suite -- all under different licenses (some of which are custom, some of which are dual), with the docs being optional, and the tests only used in the 'regression-test' target (so, not installed, but can be used during the build), what should we put into the LICENSE variable (there will be half a dozen of licenses in total)? For which users will the resulting LICENSE be helpful? Another example: if a port comes under a BSD license, but links with a GPL library, so that the resulting binary is necessarily GPL, what should the LICENSE be? Why? Next, let's say a port requires user to read and accept a license before installation (so, no auto-accept), should I use the license framework to present the said license to the user? As you can see, there are questions that arise in some of the trickier situations, with the end result that I neither know what to put into the LICENSE of my own ports, nor how to interpret the LICENSEs of other ports. I don't even have an understanding of what sort of a user benefits from my ports having a LICENSE. So, after 7 years (!) of waiting for official clarifications -- with no visible progress -- I think it is not surprising that I don't see a clarification to ever be made, and would prefer the framework 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: help categorise license
On 2015-07-27 11:59, Anton Shterenlikht wrote: I'm making a port of http://netlib.org/math. Their license looks like BSD2CLAUSE, but can somebody please check: http://netlib.org/math/license.htm That link should end with .html, not .htm. In any case, the license seems identical to the 3-clause BSD [1,2] (note the Neither the name of ... may be used to endorse or promote ... part). (Also note that our license framework should probably be scrapped entirely, because it is ambiguous and undocumented). [1] http://opensource.org/licenses/BSD-3-Clause [2] http://directory.fsf.org/wiki/License:BSD_3Clause ___ 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
Could a brave committer apply the fixes for graphics/mypaint? (was: Re: mypaint)
In the original thread Jan Beich wrote:
I think the following are relevant patches from bugzilla.
Index: Mk/Uses/scons.mk
===
--- Mk/Uses/scons.mk(revision 376385)
+++ Mk/Uses/scons.mk(working copy)
@@ -17,6 +17,8 @@ IGNORE= Incorrect 'USES+= scons:${scons_ARGS}' sco
MAKEFILE= #
MAKE_FLAGS= #
ALL_TARGET= #
+CCFLAGS?= ${CFLAGS}
+LINKFLAGS?=${LDFLAGS}
LIBPATH?= ${LOCALBASE}/lib
CPPPATH?= ${LOCALBASE}/include
SCONS=${LOCALBASE}/bin/scons
Index: graphics/mypaint/Makefile
===
--- graphics/mypaint/Makefile (revision 376385)
+++ graphics/mypaint/Makefile (working copy)
@@ -22,7 +22,7 @@ BUILD_DEPENDS:= ${RUN_DEPENDS} \
USE_GNOME=glib20 pygtk2
MAKE_ARGS=prefix=${PREFIX}
-USES= gettext pkgconfig scons tar:bzip2 python
+USES= compiler:gcc-c++11-lib gettext pkgconfig scons tar:bzip2 python
INSTALLS_ICONS= yes
SUB_FILES=pkg-install
-
In short, graphics/mypaint is currently broken, and PRs 193434 [1] and
193429 [2] should be committed to fix it. Both of them are one-line
changes, and both have been open for 5 months now.
Can someone commit those PRs?
Or better yet, give their submitter, Jan Beich, the commit bit so he
could do it himself? The guy submitted 300+ PRs, and he's not even
mentioned in the Additional Contributors list...
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193434
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193429
___
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: tdb
On 2015-01-16 16:47, R. Scott Evans wrote: On 01/16/15 09:39, Larry Rosenman wrote: On 2015-01-16 08:33, R. Scott Evans wrote: Admittedly I've only got a math minor, but isn't 1.3.4 1.2.13? ;-) # pkg version -IvL= tdb-1.2.13,1 succeeds index (index has 1.3.4) -scott the ,1 is the PORTEPOCH which apparently was changed because of a version number regression. Well, I mention it because while I use pkg version -IvL=, I know the FreeBSD Handbook section on updating ports instructs one to use 'pkg version -l ' which will cause this ports change to go unseen. Likewise, portmaster -a on my box didn't catch this and I had to specifically update/downgrade the port. Folks, the relevant diff here is [1]; it reverted PORTEPOCH from 1 to 0. And you're right, it's a bug, since PORTEPOCH should never ever decrease. [1] http://svnweb.freebsd.org/ports/head/databases/tdb/Makefile?r1=377150r2=377149 ___ 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: mypaint
On 2015-01-12 20:16, Jan Beich wrote:
I think the following are relevant patches from bugzilla.
Index: Mk/Uses/scons.mk
===
--- Mk/Uses/scons.mk(revision 376385)
+++ Mk/Uses/scons.mk(working copy)
@@ -17,6 +17,8 @@ IGNORE= Incorrect 'USES+= scons:${scons_ARGS}' sco
MAKEFILE= #
MAKE_FLAGS= #
ALL_TARGET= #
+CCFLAGS?= ${CFLAGS}
+LINKFLAGS?=${LDFLAGS}
LIBPATH?= ${LOCALBASE}/lib
CPPPATH?= ${LOCALBASE}/include
SCONS=${LOCALBASE}/bin/scons
Index: graphics/mypaint/Makefile
===
--- graphics/mypaint/Makefile (revision 376385)
+++ graphics/mypaint/Makefile (working copy)
@@ -22,7 +22,7 @@ BUILD_DEPENDS:= ${RUN_DEPENDS} \
USE_GNOME=glib20 pygtk2
MAKE_ARGS=prefix=${PREFIX}
-USES= gettext pkgconfig scons tar:bzip2 python
+USES= compiler:gcc-c++11-lib gettext pkgconfig scons tar:bzip2 python
INSTALLS_ICONS= yes
SUB_FILES=pkg-install
-
Yup, this fixes the problem. Thank you.
___
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: mypaint
On 2015-01-12 15:42, lum...@gmail.com wrote: It works but application doesn't start: We are not correctly installed or compiled! script: /usr/local/bin/mypaint deduced prefix: /usr/local lib_shared: /usr/local/share/mypaint/ lib_compiled: /usr/local/lib/mypaint/ Traceback (most recent call last): File /usr/local/bin/mypaint, line 170, in module datapath, extradata, confpath, localepath, localepath_brushlib = get_paths() File /usr/local/bin/mypaint, line 111, in get_paths from lib import mypaintlib File /usr/local/share/mypaint/lib/mypaintlib.py, line 25, in module _mypaintlib = swig_import_helper() File /usr/local/share/mypaint/lib/mypaintlib.py, line 17, in swig_import_helper import _mypaintlib ImportError: /usr/local/lib/mypaint/_mypaintlib.so: Undefined symbol _ZN10BufferCompIL20BufferCompOutputType1ELj16384E12HueBlendModeE9blendfuncE Yeah, I'm actually getting the same error myself now. There's even a bug report about this problem (PR 193429; bugzilla is down at the moment though). I'm currently updating my ports to see if the problem remains with the latest everything... (this will take a day or two on my hardware). ___ 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: mypaint
On 01/11/15 16:30, Ajtim wrote: Hi! I like to install graphics/Mypaint on FreeBSD 10.1, p, amd64 and I got: --- scons: Reading SConscript files ... building for 'python2.7' (use scons python_binary=xxx to change) using 'python2.7-config' (use scons python_config=xxx to change) rm -f libmypaint-tests.so libmypaint.so libmypaintlib.so python2.7 generate.py Writing mypaint-brush-settings-gen.h Writing brushsettings-gen.h You need to have numpy installed. ImportError: /usr/local/lib/libalapack.so.2: Undefined symbol cblas_zswap: Do you have math/py-numpy with ATLAS option on? If so, try toggling that option, reinstalling numpy and installing mypaint again. I don't know if this is still the case, but there was some interaction between that option and mypaint the last time I tried it. ___ 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: Request for (i386) testing: american fuzzy lop
On 2014-11-20 14:43, Fabian Keil wrote: Quoting the pkg-descr:
| American fuzzy lop is a fuzzer that employs a novel type of compile-time
| instrumentation and genetic algorithms to automatically discover clean,
| interesting test cases that trigger new internal states in the targeted
| binary. This substantially improves the functional coverage for the
| fuzzed code.
|
| WWW: http://lcamtuf.coredump.cx/afl/
I very much welcome this effort; I myself have tried to create a port
for it, but it required a whole lot of hacks (AFL is intertwined with
internals of GCC, which I failed to make work); I ended up needing
to rewrite it's assembly filters in a fairly hackish way... Can't
remember precisely what the problem was though.
The shar file is available at:
http://www.fabiankeil.de/sourcecode/freebsd/afl-60b.shar
The port is supposed to work on amd64 and i386 but so far
it has only been tested on amd64 (with 64bit binaries).
I don't know what this part is supposed to do:
# Workaround to make sure clang isn't confused for gcc
CC=${COMPILER_TYPE}
... but it seems to set CC to empty string on my machine; and I
get a whole bunch of this as the result:
--version: not found
make: /usr/ports/Mk/Uses/compiler.mk line 66: warning:
--version returned non-zero status
I also get this:
=== Building for afl-0.60b
gmake[2]: Entering directory '/tmp/ports/security/afl/work/afl-0.60b'
[*] Checking for the ability to compile x86 code...
gcc: not found
Oops, looks like your compiler can't generate x86 code.
(If you are looking for ARM, see experimental/arm_support/README.)
Makefile:46: recipe for target 'test_x86' failed
gmake[2]: *** [test_x86] Error 1
gmake[2]: Leaving directory '/tmp/ports/security/afl/work/afl-0.60b'
=== Compilation failed unexpectedly.
Missing GCC dependency?
(This is all on 10.0-RELEASE amd64).
___
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: Request for (i386) testing: american fuzzy lop
On 11/20/14 17:02, Fabian Keil wrote:
0.57b and later have [f]ixes to make things work on FreeBSD and
OpenBSD: use_64bit is inferred if not explicitly specified when
calling afl-as.
If you started with an earlier release, this might have been
the problem.
I was working with version 0.27b, so I guess lots of things changed
since then. They even have afl-clang now.
Does it work for you if you replace the line with:
MAKE_ARGS+= CC=${COMPILER_TYPE}
?
Yes, this fixes all the problems; AFL now installs fine.
I also tested actually compiling stuff with afl-clang and then running
afl-fuzz, which also seems to work.
I don't have an i386 system though.
And if not, does it work if you remove it completely?
Removing it does not work ('test_build' fails).
___
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: [package - 91amd64-quarterly] build failure mail
On 2014-09-24 08:37, pkg-fall...@freebsd.org wrote: You are receiving this mail as a port that you maintain is failing to build on the FreeBSD package build server. Please investigate the failure and submit a PR to fix build. Maintainer: vmage...@gmail.com Last committer: olg...@freebsd.org Ident: $FreeBSD: branches/2014Q3/editors/wordgrinder/Makefile 357277 2014-06-10 07:39:01Z olgeni $ Log URL: http://beefy2.isc.freebsd.org/data/91amd64-quarterly/2014-09-24_01h22m09s/logs/wordgrinder-0.3.3.log Build URL: http://beefy2.isc.freebsd.org/build.html?mastername=91amd64-quarterlybuild=2014-09-24_01h22m09s Log: Building editors/wordgrinder build started at Wed Sep 24 05:37:27 UTC 2014 port directory: /usr/ports/editors/wordgrinder building for: FreeBSD 91amd64-quarterly-job-16 9.1-RELEASE-p17 FreeBSD 9.1-RELEASE-p17 amd64 maintained by: vmage...@gmail.com Makefile ident: $FreeBSD: branches/2014Q3/editors/wordgrinder/Makefile 357277 2014-06-10 07:39:01Z olgeni $ Poudriere version: 3.1-pre Host OSVERSION: 1100027 Jail OSVERSION: 901000 Folks, what should I do to not receive these messages? I've already updated the port (long time ago), but I still get mail about build failures in the quarterly branch. ___ 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
Redports, broken regression tests and missing check-orphans
Bernhard, while we're at it, there are currently two problems with
redports which diminish it's usefulness significantly:
1. Redports used to run make regression-test on every build; right
now, each log has this instead:
phase 5: make test
[: -eq: unexpected operator
=== Regression tests skipped. ===
So, no regression tests are executed. I don't know what the problem is here.
2. Most ports now have stage support; this means that checking for
leftover files under ${PREFIX} is close to useless: only files in
pkg-plist are copied there. Instead, leftovers should be searched for in
${STAGEDIR} -- running make stage-qa and make check-orphans with
every build would do that.
(I've already botched two patches when I assumed that successful
redports run means that pkg-plist is complete).
So, can the first problem be fixed and the second suggestion
implemented? Should I be bothering tinderbox author(s) instead?
___
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 do maintainer updates work with bugzilla?
On 2014-08-03 22:18, Matthew Seaman wrote: By virtue of sending a PR into the system a le...@ee.lbl.gov account will have been created in Bugzilla. So, 'send-pr' still works? That's good news then, I was under impression that it was disabled after the bugzilla switch. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Patch for premake 4.4 beta 5 from premake 4
On 2014-06-24 09:51, Sergei G wrote: I had to update Premake 4 port (4.3) to 4.4 beta 5 on FreeBSD 10.0-RELEASE #0. I wanted to wait for the full (non-beta) 4.4 release, but seeing that some projects are already using 4.4-betas, I guess it's time to update the port... I included patch file with changes applied to Premake 4 port. The changes consist of: 1. updating version and addition of beta version in Makefile 2. switch to clang compiler in Makefile It's better to use 'cc' instead of 'clang'; this way nothing will break in 8.x and 9.x branches where GCC is still the default. 3. update of download file signatures 4. removal of 2 patch files, because the files appear to be obsolete and I could not figure out the proper fix. Keeping both patch files resulted in error during premake execution. I was successful for my small scope of compiling Box2D, but I observed a couple of issues with my upgrade. 3 regression tests failed (it appears due to at least one missing patch file): [...] Once I installed premake I observed that it generated Makefile with gcc in it, instead of clang. Should switch to clang be applied at premake or Box2D project level? I'll need to look into that before saying anything definite; I'll report back once I'll do that. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Patch for premake 4.4 beta 5 from premake 4
TL;DR: could a brave ports comitter apply an update for devel/premake4 at [1]? That would be much appreciated. Redports logs for this update are at [2]. Note that redports for some reason doesn't invoke regression-test target today; probably a bug on their part. On 2014-06-24 09:51, Sergei G wrote: I had to update Premake 4 port (4.3) to 4.4 beta 5 on FreeBSD 10.0-RELEASE #0. I included patch file with changes applied to Premake 4 port. The changes consist of: 3 regression tests failed (it appears due to at least one missing patch file): The main cause of these regressions is actually a very strange one (and you're right that those patches are what fixed it in the past). So, in one of it's routines premake tries to open '/etc/ld.so.conf'; it does so via Lua function 'io.open'. Now, FreeBSD doesn't have that file, and in theory 'io.open' should return 'nil', which should cause premake to skip this file. What actually happens is that 'io.open' returns some object that is neither nil, nor a proper file object. Premake thinks that 'io.open' succeeded, and tries to read from that non-nil, non-file object, which doesn't work. Why doesn't 'io.open' return 'nil' here is a mystery to me. Maybe premake ships with buggy Lua sources. I don't know. In any case, this problem is fixed in the patch at [1]. Once I installed premake I observed that it generated Makefile with gcc in it, instead of clang. Should switch to clang be applied at premake or Box2D project level? It appears that Premake only supports GCC for its gmake target. It is possible to simply replace gcc with clang in the premake sources, and it will mostly work, but: 1) it will not work for projects that use advanced options, since clang does not support, and in fact fails on some of the flags premake may pass to it (-ffast-math for example); 2) makefiles generated on FreeBSD will fail on other platforms (not sure if premake promises them to work though). The long-term solution for premake is to recognize clang as a valid compiler, and provide a set of flags it understands. The short-term solution for programs that use premake is to either require GCC from ports, or to manually replace gcc with clang before building, patching out incompatible compiler flags, if any. Note that Box2D v2.3.1 doesn't seem to use any flags that clang doesn't understand, so it is safe to change gcc into cc, and g++ into c++ in the makefiles that premake generates for it. [1] http://tx97.net/~magv/diff/premake-4.4.b5.diff [2] https://redports.org/buildarchive/20140624134401-54287/ ___ 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
Drop maintainership of lang/stklos and lang/ikarus
Hi, someone please mark these two ports as unmaintained: lang/stklos lang/ikarus The first port has problem building on FreeBSD, fails it's own test suite on other platforms (a memory corruption bug probably), and the last time I heard anything from it's author was in 2012. The second port is a project that died in 2009. Note that both these ports are currently unstaged, and I'm fine with both being deprecated (unless someone will step in to fix them). ___ 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-Announce] FreeBSD bug tracking moves from GNATS to Bugzilla
On 2014-06-03 11:05, David Chisnall wrote: We are pleased to announce that the FreeBSD project has begin the transition from the GNATS bug-tracking system to Bugzilla. The Bugzilla installation can be found here: https://bugs.freebsd.org/bugzilla/ It doesn't seem to be possible to post comments (or bugs) without creating an account and logging in. No comment-by-email too, as far as I can tell. Are those features gone forever? Can I ask them to be restored, at least in some capacity? ___ 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-Announce] FreeBSD bug tracking moves from GNATS to Bugzilla
On 2014-06-03 15:16, David Chisnall wrote: On 3 Jun 2014, at 13:09, Vitaly Magerya vmage...@gmail.com wrote: It doesn't seem to be possible to post comments (or bugs) without creating an account and logging in. That is correct. The current leaning is towards not providing such functionality as: - It makes spamming easy - If someone can't be bothered to make an account, they are unlikely to provide the feedback required to correctly diagnose the bug. Let my protest against such sweeping judgements be noted. No comment-by-email too, as far as I can tell. This is probably going to reappear at some point, if there is sufficient demand for it. I see. Consider me to be expressing the demand then. Anything that would allow me to participate without using an account would be very much appreciated. ___ 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
New devd-based X.Org autoconfiguration backend
On 09/09/2013 17:52, Niclas Zeising wrote: The attached patch, also available in the latest updated version at http://people.freebsd.org/~zeising/xorg-mesaupdate.diff updates various xorg related libraries and drivers, most of this is visible for all users of xorg. xorg-server now has the possibility to use devd instead of hal for autoconfiguration. And here's an update to that patch that implements a (hopefully) better devd-based autoconfiguration backend. Comments, questions, failure reports are welcome. Note that this backend is only enabled if you're using WITH_NEW_XORG. My attempts to port it to older xserver has so far been a failure (I left a piece of code that will compile with xserver-1.5.x, but X will fail to load drivers when my code asks it to). == How to install it Apply xorg-mesaupdate.diff to your ports tree, or grab the ports tree from Xorg development repo [2] (which is what I do). Apply the patch at [1] on top of that. Reinstall x11-servers/xorg-server with DEVD option on. As a first-time measure, either reboot or run service xhotplug start. Then (re)start X server (don't forget to remove InputDevice sections from your xorg.conf, if you've been using static configuration before). == What it does The backend will first add two devices: syscons keyboard device and sysmouse mouse device. Then, any atp(4), joy(4), psm(4), uep(4), uhid(4) and ums(4) devices will be added and removed dynamically, as they appear in your system. atp, psm and ums devices will by default use xf86-input-mouse driver; uep will use xf86-input-egalax, if it's installed. The rest will have no default driver. You can change the driver, and set any needed options for any of the devices by using InputClass section of xorg.conf (see xorg.conf man page). == Cooperation with moused(8) The backend will try to play along with moused(8): if you have moused_enable=YES (by default it's NO), or moused_nondefault_enable=YES (by default it's YES) set in your rc.conf, moused will be given the priority to take over psm and ums devices. The upside of this is that you'll have mouse working in console. The downside is that X server will only see the combined mouse device (sysmouse), and will not be able to configure each mouse individually. == Keyboards While it is possible to make X server to see and configure each keyboard individually, this backend chooses to let kbdmux(4) take over any ukbd device that appears in your system, and only expose X to one combined keyboard. This is so that your keyboards would work in both X and the console. The alternative (to let Xorg see each keyboard separately, but not to enable them in console) seems too error prone for my taste. == Multiple Xorg servers running at once As discussed earlier in this thread, sharing input devices is not really possible in FreeBSD. If multiple X servers are running on your machine at the same time, each will try to grab every input device, but aside from syscons and sysmouse, they will fail, and only the first server will be able to actually use the device. == Debugging hotplug (Users are not expected to know or care about this part). You can get a list of devices the backend tried to add by running service xhotplug list. Here's what it should show on a typical machine: # service xhotplug list syscons driver=kbd device= flags=keyboard name=System%20Keyboard product=syscons sysmouse driver=mouse flags=pointer name=System%20Mouse product=sysmouse psm0 driver=mouse flags=pointer name=PS%2f2%20Mouse You can remove any device like this: # service xhotplug remove psm0 ... and add it back, with different options: # service xhotplug add psm0 Emulate3Buttons=OFF To verify that X actually has all the devices you think it should have, you can use x11/xinput utility: # xinput ⎡ Virtual core pointer id=2[master pointer (3)] ⎜ ↳ Virtual core XTEST pointerid=4[slave pointer (2)] ⎜ ↳ System Mouse id=7[slave pointer (2)] ⎜ ↳ PS/2 Mouseid=8[slave pointer (2)] ⎣ Virtual core keyboard id=3[master keyboard (2)] ↳ Virtual core XTEST keyboard id=5[slave keyboard (3)] ↳ System Keyboard id=6[slave keyboard (3)] [1] http://tx97.net/~magv/diff/xorg-server-1.12.4_2.hotplug.diff [2] https://wiki.freebsd.org/Xorg#Development_Repo ___ 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] Update of xorg libraries and MESA
On 09/17/2013 10:29, Matthieu Volat wrote: Just as a side note : I tested the devd backend and mouse keyboard were detected. But what would be the best way to set the keyboard layout now? You should add something like this to your xorg.conf: Section InputClass Identifier All The Keyboards MatchDevicePath /dev/*kbd* Option XkbLayout us,ru -- any other kbd(4) options here -- EndSection (Warning: not tested). This should work with any backend, be it HAL or DEVD; see INPUTCLASS section of xorg.conf man page for details on how it works. ___ 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] Update of xorg libraries and MESA
Niclas Zeising wrote: xorg-server now has the possibility to use devd instead of hal for autoconfiguration. This is pretty great, and very much appreciated. I do have questions though; reading the code it seems that: 1) 'usb_id' is always NULL, so 'MatchUSBID' directive in xorg.conf won't work; 2) 'vendor' and 'product' will be determined from 'dev.x.x.%desc' sysctl by splitting on the first space, so for example my USB tablet, which has %desc equal to WALTOP International Corp. Slim Tablet will have vendor WALTOP and product International Corp. Slim Tablet -- so those are the strings I should use in 'MatchVendor' and 'MatchProduct'; 3) if 'devd' is restarted while Xorg is running, further hardware changes will not be reported to Xorg. Can you confirm I'm reading this right? If so, are there any plans to improving these points? ___ 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] Update of xorg libraries and MESA
Baptiste Daroussin wrote: 1) 'usb_id' is always NULL, so 'MatchUSBID' directive in xorg.conf won't work; 2) 'vendor' and 'product' will be determined from 'dev.x.x.%desc' sysctl by splitting on the first space, so for example my USB tablet, which has %desc equal to WALTOP International Corp. Slim Tablet will have vendor WALTOP and product International Corp. Slim Tablet -- so those are the strings I should use in 'MatchVendor' and 'MatchProduct'; 3) if 'devd' is restarted while Xorg is running, further hardware changes will not be reported to Xorg. Can you confirm I'm reading this right? If so, are there any plans to improving these points? Yes you are totally right about all this points this should be fixed. I have no time to work on this right now. Anyone volunteering? I am, once my flu is gone. I'm actually using a devd backend I wrote a few months ago (which avoids the mentioned issues), but it's rather different from yours (more intrusive that is): directives are added to devd config to call a script when devices appropriate for Xorg are added or removed. That script will maintain a file with the list of those devices; it will also print add/remove messages into a special pipe, if it exists. Xorg will read the file with the list on startup, and will create and listen to the pipe to see added/removed devices. This way devd restarts are safely handled, and the script called from devd can invoke 'usbconfig' to correctly determine vendor name, product name and usb id. The open problems here are: 1) what should happen if multiple X instances are running? 2) how to clean the file with the list of devices on boot? If you're OK with this approach in general, I can clean up my code, update it and submit a patch. ___ 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] dialog4ports does not popup anymore only for global options
Baptiste Daroussin wrote: I have committed the code preventing config-conditional to popup the dialog only if some global options are defined (NLS, DOCS, EXAMPLES and IPV6 for now). This was a popular demand, hope that it fits the requirement. So from now please always define via OPTIONS_DEFINE those options if your ports are going to use them. Is it possible to still show the dialog if one of those options implies additional dependencies? If not, what should those of us who do not want them installed do? ___ 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] dialog4ports does not popup anymore only for global options
Baptiste Daroussin wrote: Is it possible to still show the dialog if one of those options implies additional dependencies? If not, what should those of us who do not want them installed do? make config will always show those options so you can always tune them. just make config-conditional will not fireup a new dialog automatically if the defined options are only those from the global options. I see. As far as I can tell though, and correct me if I'm wrong, but 'make install' doesn't show those options. It also does not show those options for dependent ports. Neither does 'make config-recursive'. Tools like portmaster will now ignore those as well during install and reinstall. So, again, what are my options if I don't want dependencies to be pulled in silently? ___ 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] dialog4ports does not popup anymore only for global options
Baptiste Daroussin wrote: So, again, what are my options if I don't want dependencies to be pulled in silently? You have no options and you never had one in the ports tree sorry. Previously maintainers could decide to show dialog with only DOCS or not to show it. They didn't do it consistently, of course. Probably because no guidelines where established. If you have a way to implement that cleanly, I'll be happy to push such features in the ports but really I see a way to do what you ask for. We could provide 'OPTIONS_DEFINE_SILENT' for ports that don't want to spam the users with dialogs, but still want to provide the options. Or a separate flag, like 'OPTIONS_ARE_SILENT'. ___ 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: do not show up the dialog(1) by default?
I think it is not good idea, because if user don't know regarding options in ports he should do a make config and if it not exist should do a make install in this case we have two action.. Maybe other way for fix these frequent popping add needed options to make.conf I like the suggestion that if the dialog consists only of globally set options (NLS, DOC, etc) then it shouldn't appear by default. Except the cases when those options pull in additional dependencies. In those cases either the dialog should be shown, or the options should be disabled by default. ___ 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: do not show up the dialog(1) by default?
John Marino wrote: I like the suggestion that if the dialog consists only of globally set options (NLS, DOC, etc) then it shouldn't appear by default. Except the cases when those options pull in additional dependencies. In those cases either the dialog should be shown, or the options should be disabled by default. The issue is that _by definition_ these options are enabled by default. I'm not sure I agree that an always-enabled option should trigger a dialog just because it has dependencies. My motivation is that some of those dependencies (especially for DOCS) are quite big (docbook for example). Under no circumstances do I want to waste hours of time building those and all of their dependencies. So, again, silent DOCS/NLS/EXAMPLES when additional dependencies are involved is very, very undesirable. Doesn't NLS have dependencies? NLS does often mean gettext, yes. That would already negate the benefit greatly if this suggestion were followed. If that is a concern, we can actually count how many ports will be affected by such a policy. I expect the number not to be high. For example there are only 13 ports with NLS in the whole 'lang' category. Out of those 13, only 4 have no other options and will require a config dialog under the policy I propose. ___ 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 half installed ports
Matthias Apitz wrote: Say, we are installing ports/A which depends on ports/B; the Makefile detects the dependency and goes to install ports/B; if now during the final installation process, some files are already delivered to /usr/local, some files not, the system goes down (by intention because it's time to go out), before the installation of ports/B is fully done and registered to /var/db/pkg, next time when you restart installing ports/A it often sees, because the file referenced in the Makefile was allready installed (while others not), it thinks that ports/B was installed fine and proceeds with ports/A which later (or even in some other area) gives an error due to missing files of ports/B; I think, the only solution is that the dependency is not only based on some (random) file of B, but on the fact if B was *fully* installed and registered in /var/db/pkg; There is a case where this will break: if multiple ports install the same file, and you don't care which of them installed it, then you need to depend on the file, not on a specific port. For example, both www/node and www/node-devel install the same binary, and dependent ports will work with either of them. Now, it's true that using files as a proxy for interchangeable ports isn't ideal, and we could do better... Anyway, the problem you're describing allows for another fix. If ports/A depends of file-B, port system could check not only that file-B exists, but if there is also a package that installed it (via 'pkg which'), and if not, install ports/B. This will of course slow down ports operations somewhat. ___ 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 half installed ports
Earlier I wrote:
Anyway, the problem you're describing allows for another fix. If ports/A
depends of file-B, port system could check not only that file-B exists,
but if there is also a package that installed it (via 'pkg which'), and
if not, install ports/B. This will of course slow down ports operations
somewhat.
Here's a patch to that effect.
(Only tested with PKGNG; should work with old pkg tools, but some
tweaking may be required).
Matthias, can you try to reproduce the situation you described, and see
if it will be resolved after applying this patch?
diff -ruN Mk.orig/bsd.commands.mk Mk/bsd.commands.mk
--- Mk.orig/bsd.commands.mk 2013-03-19 11:27:52.0 +0200
+++ Mk/bsd.commands.mk 2013-04-11 14:15:49.0 +0300
@@ -128,6 +128,7 @@
PKG_CREATE?= ${PKG_BIN} create
PKG_ADD?= ${PKG_BIN} add
PKG_QUERY?=${PKG_BIN} query
+PKG_WHICH?=${PKG_BIN} which
.else
.if exists(${LOCALBASE}/sbin/pkg_info)
PKG_CMD?= ${LOCALBASE}/sbin/pkg_create
@@ -135,12 +136,14 @@
PKG_DELETE?= ${LOCALBASE}/sbin/pkg_delete
PKG_INFO?= ${LOCALBASE}/sbin/pkg_info
PKG_VERSION?= ${LOCALBASE}/sbin/pkg_version
+PKG_WHICH?=${LOCALBASE}/sbin/pkg_info -W
.else
PKG_CMD?= /usr/sbin/pkg_create
PKG_ADD?= /usr/sbin/pkg_add
PKG_DELETE?= /usr/sbin/pkg_delete
PKG_INFO?= /usr/sbin/pkg_info
PKG_VERSION?= /usr/sbin/pkg_version
+PKG_WHICH?=/usr/sbin/pkg_info -W
.endif
.endif
diff -ruN Mk.orig/bsd.port.mk Mk/bsd.port.mk
--- Mk.orig/bsd.port.mk 2013-03-30 07:31:29.0 +0200
+++ Mk/bsd.port.mk 2013-04-11 16:35:42.0 +0300
@@ -5063,6 +5063,9 @@
if [ ${_DEPEND_ALWAYS} = 1 ]; then \
${ECHO_MSG}(but
building it anyway); \
notfound=1; \
+ elif ! ${PKG_WHICH} $$prog
/dev/null; then \
+ ${ECHO_MSG}(but not
installed by any package); \
+ notfound=1; \
else \
notfound=0; \
fi; \
@@ -5104,6 +5107,9 @@
if [ ${_DEPEND_ALWAYS} = 1 ]; then \
${ECHO_MSG}(but building it
anyway); \
notfound=1; \
+ elif ! ${PKG_WHICH} `${WHICH} $$prog`
/dev/null; then \
+ ${ECHO_MSG}(but not installed
by any package); \
+ notfound=1; \
else \
notfound=0; \
fi; \
@@ -5141,11 +5147,19 @@
dir=$${dir%%:*}; \
fi; \
${ECHO_MSG} -n === ${PKGNAME} depends on shared library:
$$lib; \
- if ${LDCONFIG} ${_LDCONFIG_FLAGS} -r | ${GREP} -vwF -e
${PKGCOMPATDIR} | ${GREP} -qwE -e -l$$pattern; then \
+ libs=`${LDCONFIG} ${_LDCONFIG_FLAGS} -r | ${GREP} -vwF -e
${PKGCOMPATDIR}`; \
+ if ${ECHO_CMD} $$libs | ${GREP} -qwE -e -l$$pattern; then \
${ECHO_MSG} - found; \
if [ ${_DEPEND_ALWAYS} = 1 ]; then \
${ECHO_MSG}(but building it anyway); \
notfound=1; \
+ elif ${ECHO_CMD} $$libs | ${GREP} -wE -e
-l$$pattern | ${SED} 's/.*= //' | \
+ while read lib; do \
+ if ${PKG_WHICH} $$lib /dev/null;
then return 1; fi; \
+ done; \
+ then \
+ ${ECHO_MSG}(but not installed by any
package); \
+ notfound=1; \
else \
notfound=0; \
fi; \
___
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: maintainer timeout for FreeBSD commiters
On 2012-07-14 18:27, Chris Rees wrote: On 14 July 2012 16:24, Vitaly Magerya vmage...@gmail.com wrote: One problem (at least how it appears to me) is that when a PR gets automatically assigned to a maintainer who is also a committer, it is not automatically unassigned if the person is missing for a few months, and other committers ignore the PR because it is already assigned. This only happened once to me, but it took 6 months for another committer to notice it. And that was pretty fast, comparing to, say ports/154456 [1], which is open since 2011-02. Is automatic unassignment possible? Technically yes, but it's highly undesirable. You can feel free to bring it up here if you think that's happened. Hi, everyone. Two of my PRs, ports/175223 [1] and ports/176701 [2], have been automatically assigned to committers, and both have reached maintainer timeout a while ago. Could someone unassign them, so other committers could take a look? Thanks in advance. (I still think this should be done automatically. I would prefer not to bother everyone at ports@ for such things). [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/175223 [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/176701 ___ 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] New dialog for ports
Daniel Nebdal wrote: I just found a niggle: I have LANG=en_US.UTF-8 , NCURSES_NO_UTF8_ACS=1, TERM=xterm, and I'm using putty to connect to a FreeBSD-10 machine running a snapshot from february with ports from an hour ago. Putty is set to Translation: UTF-8, and use unicode line drawing code points. With those settings, dialog gives me nice line drawing characters (for some reason). If I unset NCURSES_NO_UTF8_ACS, all boxes are drawn using random letters instead. (jlmqx, to be exact.) They're not actually random; 'jlmqx' is the ASCII rendering of line drawing characters in ACS (alternative charset), which putty doesn't support in UTF-8 mode (therefore it shows the ASCII, not the ASC versions). The problem: ports config dialogs are _always_ drawn with the same random letters, and I haven't found any setting or combination of settings that works. This is probably more of a mis-configuration on my side I'm seeing the same thing too. I think I've found what causes it: unlike dialog, dialog4ports does not call setlocale(3) during startup. Try saving the attached patch as 'ports-mgmt/dialog4ports/files/patch-dialog4ports.c' and reinstalling dialog4ports; report back if it'll help. --- dialog4ports.c.orig 2013-03-20 14:07:09.0 +0200 +++ dialog4ports.c 2013-03-20 14:07:56.0 +0200 @@ -32,6 +32,7 @@ #include stdio.h #include stdlib.h #include stringlist.h +#include locale.h #include mixedlist.h @@ -213,6 +214,7 @@ char *helpfile; DIALOG_MIXEDLIST* items; + setlocale(LC_ALL, ); init_dialog(stdin, stdout); errno = 0; ___ 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 experimental gimp 2.8.2 port
Matthieu Volat wrote: I've been continuing to maintain my gimp 2.8 experimental ports, more rigorously checking pkg-plist files and updating to 2.8.2 (well, just incrementing the version number in the Makefile). For those who are interested, until gimp 2.8 is properly imported in the port tree, I've put everything on a github repo: https://github.com/mazhe/gimp28_ports Along a script to update the dependancies and gimp itself. Still missing are the help ports, and a script to revert to the standard versions, I'll check that ASAP. For the record it works fine for me, and doesn't even break any of other applications that depend on the updated libraries. Why isn't this all in the ports tree though? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Strange behavior in mc-light
Alexander Yerenkow yeren...@gmail.com wrote:
# env TARGET=arm TARGET_ARCH=armv6 TARGET_CPUARCH=armv6
CONFIGURE_HOST=arm-portbld-freebsd10.0
PATH=/usr/obj/arm.armv6/usr/src/tmp/usr/bin:${PATH}
STRIP_CMD=/usr/obj/arm.armv6/usr/src/tmp/usr/bin/strip gmake man2hlp
cc -O2 -pipe -fno-strict-aliasing -I..
-I/wrkdirs/usr/ports/misc/mc-light/work/mc-4.1.40-pre9/intl -I./../vfs
-I./.. -I./../slang -I.. -DBINDIR=\/usr/local/bin/\
-DLIBDIR=\/usr/local/share/mc/\
-DLOCALEDIR=\/usr/local/share/locale/\ -DWANT_PARSE -DREGEX_MALLOC
armv6 man2hlp.c -o man2hlp
cc: armv6: No such file or directory
gmake: *** [man2hlp] Error 1
Seems that somehow after -DREGEX_MALLOC there for some reason inserted
$TARGET_ARCH (rechecked with different values, like arm67 )
Is there any sense in this?
It appears that man2hlp above is built using an implicit builtin
rule, which for GNU make involves TARGET_ARCH for some reason.
I don't know where this is documented, but take a look:
$ strings /usr/local/bin/gmake | grep TARGET_ARCH | grep CC
$(CC) $(LDFLAGS) $(TARGET_ARCH)
$(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
So your best bet is to add a rule for man2hlp to src/Makefile.in;
I'm attaching a patch agains the port to this effect; it seems
to work for me.
diff -ruN mc-light.orig/files/patch-src_Makefile.in
mc-light/files/patch-src_Makefile.in
--- mc-light.orig/files/patch-src_Makefile.in 2012-09-05 23:40:25.0
+0300
+++ mc-light/files/patch-src_Makefile.in2012-09-05 23:47:01.0
+0300
@@ -3,7 +3,17 @@
--- src/Makefile.in.orig Wed Aug 18 23:32:30 2004
+++ src/Makefile.inFri Sep 3 14:47:25 2004
-@@ -135,7 +135,7 @@
+@@ -76,6 +76,9 @@
+ mc: $(OBJS) @LIBVFS@ @LIBSLANG@ @LIBEDIT_A@
+ $(CC) $(LDFLAGS) -o $@ $(OBJS) -L../vfs -L../slang -L../edit $(OURLIBS)
$(LIBS)
+
++man2hlp: man2hlp.c
++ $(CC) $(CFLAGS) $(LDFLAGS) -o $@ man2hlp.c
++
+ mfmt: mfmt.o
+ $(CC) $(LDFLAGS) mfmt.o -o mfmt
+
+@@ -135,7 +138,7 @@
install: mc mfmt @saver@
$(INSTALL_PROGRAM) mc $(DESTDIR)$(bindir)/$(binprefix)mc
$(INSTALL_PROGRAM) mcmfmt $(DESTDIR)$(bindir)/$(binprefix)mcmfmt
___
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: Plugins support in pkgng
Marin Atanasov Nikolov dna...@gmail.com wrote: This is just to share with you that soon after the official 1.0 release of pkgng we now have basic plugins support in pkgng's development branch. [...] It's not perfect or covering everything, but it will give you a quick start though :) How about the ability to add new commands to pkg? For example something like pkg cutleaves via plugins would be cool. ___ 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: Plugins support in pkgng
Glen Barber g...@freebsd.org wrote: How about the ability to add new commands to pkg? For example something like pkg cutleaves via plugins would be cool. I think 'pkg autoremove' already does this. Does autoremove show you all the leaves and ask which ones you want removed? I honestly don't know (and can't test at the moment); I assumed it only removed the ones with auto flag on. In any case, what I actually want is a pkg_cleanup alternative (i.e. cutleaves with a dialog(1)-like interface). There are other utilities that could benefit from being a plugin too. For example suggest plugin could use hooks on the build server to construct a database of binary name-package mapping, and add pkg suggest command on the client to query that database (e.g. pkg suggest ogg123 would suggest you to install audio/vorbis-tools, which is an idea that has been floating around). ___ 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 1.0 release schedule, and HEAD switch to pkgng by default schedule
Baptiste Daroussin b...@freebsd.org wrote: Please [...] ask question about pkgng [...] What would be the best practice of mixing ports with packages? The use case I have in mind is compiling Xorg ports locally WITH_NEW_XORG and WITH_KMS, and using packages from pkgbeta.freebsd.org for everything else. Is there some mixture of pkg and portmaster flags that allows this kind of setup? ___ 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 remove erroneous deps from pkgng
Julien Laffaye jlaff...@freebsd.org wrote: Yes it is needed at runtime if you are a developper using sqlite3 and pkg-config: to use `pkg-config sqlite3 --cflags` and `pkg-config sqlite3 --libs` in your $APP build process. It's $APP that needs pkg-config as a build dependency. Sqlite3 does not need to depend on pkf-config at all; it should install .pc file and nothing more. Look at lang/gcc, lang/python or devel/pcre: they all do it this way. In short, sqlite3 should completely drop the dependency on pkg-config. ___ 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 remove erroneous deps from pkgng
Julien Laffaye jlaff...@freebsd.org wrote: I am not trying to state what it should or should not do. I am trying to guess why it is doing things like it does. I apologize for being patronizing then. Is any committer here willing to remove sqlite3's dependency on pkg-config, or should I file a PR? (A grep through the sources reveals that sqlite3 does not use pkg-config for it's own build, so it should be safe to completely drop the dependency). ___ 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: maintainer timeout for FreeBSD commiters
Chris Rees cr...@freebsd.org wrote: No-one is exempt from timeouts on ports except secteam and portmgr. One problem (at least how it appears to me) is that when a PR gets automatically assigned to a maintainer who is also a committer, it is not automatically unassigned if the person is missing for a few months, and other committers ignore the PR because it is already assigned. This only happened once to me, but it took 6 months for another committer to notice it. And that was pretty fast, comparing to, say ports/154456 [1], which is open since 2011-02. Is automatic unassignment possible? [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/154456 ___ 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: maintainer timeout for FreeBSD commiters
Chris Rees cr...@freebsd.org wrote: Is automatic unassignment possible? Technically yes, but it's highly undesirable. Why? You can feel free to bring it up here if you think that's happened. I will, if it'll happen to me. In the mean while here's an incomplete list of PRs that where (auto)assigned to committers in June and didn't see any progress in at least 2 weeks: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168564 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168571 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168629 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168667 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168840 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168850 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168870 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168917 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168957 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/169076 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/169271 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/169287 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/169305 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/169369 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/169370 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/169388 (previous one is misassigned; the submitter *is* the maintainer) http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/169458 (I did not expect there to be this many of them). In some of these cases I think that work may continue behind the scenes, but it's hard to tell. ___ 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: USE_GMAKE fails in QATty?
On 07/07/2012, Boris Samorodov b...@passap.ru wrote:
Seems that Mk/bsd.port.mk assumes that LOCALBASE for gmake
is always /usr/local. Please, try the following patch.
--- bsd.port.mk 1 Jul 2012 20:57:48 - 1.732
+++ bsd.port.mk 7 Jul 2012 12:20:17 -
@@ -1647,7 +1647,7 @@
EXTRACT_DEPENDS+=unmakeself:${PORTSDIR}/archivers/unmakeself
.endif
.if defined(USE_GMAKE)
-BUILD_DEPENDS+= gmake:${PORTSDIR}/devel/gmake
+BUILD_DEPENDS+= ${LOCALBASE}/bin/gmake:${PORTSDIR}/devel/gmake
CONFIGURE_ENV+= MAKE=${GMAKE}
.endif
It helps partially: gmake is correctly recognized as installed,
but building ports with it still does not work since GMAKE is
still gmake. This is additionally needed:
--- bsd.commands.mk.orig2012-07-07 16:59:52.0 +0300
+++ bsd.commands.mk 2012-07-07 16:59:44.0 +0300
@@ -43,7 +43,7 @@
FIND?= /usr/bin/find
FLEX?= /usr/bin/flex
FMT?= /usr/bin/fmt
-GMAKE?=gmake
+GMAKE?=${LOCALBASE}/bin/gmake
GREP?= /usr/bin/grep
GUNZIP_CMD?= /usr/bin/gunzip -f
GZCAT?=/usr/bin/gzcat
The problem comes down to the fact that redports/QATty changes
LOCALBASE, but does not put it into PATH. Are ports are supposed
to work without $LOCALBASE/bin in PATH? Maybe it's just a glitch
in redports setup?
___
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: custom license on new port?
Michael Scheidell wrote: got a new port. submitted by the copyright owner and author. for reference, pr ports/168832 there is no LICENSE= in the Makefile, no LICENSE.txt in the distribution, but it does have the attached in the main.c file. [...] * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. That is 2-clause BSD [1], aka the FreeBSD license [2], so LICENSE=BSD should be sufficient if you want to add that (my understanding is that the license framework is unused and should probably be removed). [1] http://www.opensource.org/licenses/BSD-2-Clause [2] https://gnu.org/licenses/license-list#FreeBSD ___ 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 need a uniq identifier, do you have any suggestion?
Baptiste Daroussin wrote:
Perhaps we could introduce UNIQUE_ORIGIN which is
${ORIGIN}_${SUBPACKAGE} or something of the sort?
I thought about this one, but while here we should think about package move
which keeps being the same package, in that case origin will change, and the
uniquename will change which is no good for binary world.
Does pkgng handle MOVED during upgrades? If so, ${ORIGIN}_${SUBPACKAGE}
will work fine, if not -- then it should; relying on unique name not to
change is fragile.
For example when audio/polypaudio was renamed to audio/pulseaudio, it
would be unreasonable to keep it's unique name as polyaudio.
___
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: Documenting 'make config' options
Baptiste Daroussin b...@freebsd.org wrote:
There was a PR[1] to use some dialog(1) feature to expose it to
the user, would be nice if that extended description could
implemented that way (using help button from dialog(1)) I do not
plan to work on this now if someone want to do it that will be
great
1: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/123185
I'm attaching a simple patch that allows you to hit F1 and view
pkg-options-descr file in the options dialog (pkg- prefix
should probably be removed, as that file has nothing to do with
packages).
--- bsd.port.mk.orig2012-06-10 11:11:40.0 +0300
+++ bsd.port.mk 2012-06-10 12:15:44.0 +0300
@@ -2374,6 +2374,7 @@
.endif
DESCR?=${PKGDIR}/pkg-descr
+OPTIONS_DESCR?=${PKGDIR}/pkg-options-descr
PLIST?=${PKGDIR}/pkg-plist
PKGINSTALL?= ${PKGDIR}/pkg-install
PKGDEINSTALL?= ${PKGDIR}/pkg-deinstall
@@ -6068,8 +6069,15 @@
(${ECHO_MSG} === Cannot create $${optionsdir}, check permissions;
exit 1)
.endif
@TMPOPTIONSFILE=$$(mktemp -t portoptions); \
+ if [ -e ${OPTIONS_DESCR} ]; then \
+ helpopt=--hfile ${OPTIONS_DESCR}; \
+ helptitle= (F1 for details); \
+ else \
+ helpopt=; \
+ helptitle=; \
+ fi; \
trap ${RM} -f $${TMPOPTIONSFILE}; exit 1 1 2 3 5 10 13 15; \
- ${DIALOG} --checklist Options for ${PKGNAME:C/-([^-]+)$/ \1/} 21 70
15 ${DEFOPTIONS} 2 $${TMPOPTIONSFILE} || { \
+ ${DIALOG} $${helpopt} --checklist Options for ${PKGNAME:C/-([^-]+)$/
\1/}$${helptitle} 21 70 15 ${DEFOPTIONS} 2 $${TMPOPTIONSFILE} || { \
${RM} -f $${TMPOPTIONSFILE}; \
${ECHO_MSG} === Options unchanged; \
exit 0; \
___
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] Please convert your ports to new options framework
Bryan Drewery wrote:
Another common question is how to check if an option is not set. We all
try !${PORT_OPTIONS:MFOO} to find it does not work.
$ cat Makefile
all:
.if ${LIST:MFOO}
@echo HAVE FOO
.endif
.if !${LIST:MFOO}
@echo NO FOO
.endif
$ make LIST=FOO
HAVE FOO
$ make LIST=BAR
NO FOO
Seems to work fine. What am I missing?
___
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] Xorg 7.7 ready for testing!
Martin Wilke wrote: With the new mesa 8.0 release, accelerated support for a number of older graphic cards was dropped. At the moment we are not sure how to deal with that.We are thinking of just replacing mesa 7.11 with 8.0 or making a new flag like WITH_MESA= 7.11.2 / 8.0 in combination with WITH_NEW_XORG, and let the mesa 7.6.1 set as default together with the old xorg version. Obviosly the latter option make the already complex situation more complex. The problem is, users, especially the new ones can easily get confused with it. Another issue is, the packages.We can't deliver a package set with the new Xorg releases. Will it be possible to provide, say pkgng repo with packages compiled with new xorg and new mesa? That would simplify testing (and using) by a very large factor. We'd just change PACKAGESITE and run pkg upgrade. ___ 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 framework options aka optionng
Folks, when moving forward with optionsng, do we want to convert NOPORTDOCS and NOPORTEXAMPLES to options everywhere? I fear that if we do, way too many ports which otherwise have no options will start asking if I want the docs -- which I don't really care either way (unless that brings in new dependencies). Maybe it would be best if ports which otherwise don't have options, and for which building docs don't require new dependencies would not put DOCS and EXAMPLES into options? What do you think? ___ 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 framework options aka optionng
Baptiste Daroussin wrote:
Maybe it would be best if ports which otherwise don't have options, and
for which building docs don't require new dependencies would not put
DOCS and EXAMPLES into options? What do you think?
You can still switch to optionsng, if you don't define DOCS in OPTIONS_DEFINE
but just use the if ${PORT_OPTIONS:MDOCS} you are using optionsng but won't
have
the dialog showing up
That sounds sensible.
How should users activate/deactivate DOCS and/or EXAMPLES from command
line in this case? Should they use make OPTIONS_UNSET=DOCS?
anyway yes NOPORTDOCS and NOPORTEXAMPLES should disappear in long term
Right.
___
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 find the number of processor cores
Svyatoslav Lempert wrote:
Try to describe why/ and why you want to do this.
http://www.freebsd.org/cgi/query-pr.cgi?pr=167953
Try:
CPUS!= ${SYSCTL} -n kern.smp.cpus
What if the package was built on one machine, but is installed on
another one? The number of CPUs during the build is meaningless; you
need to test for those at runtime (or find another workaround).
___
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 dependencies with port options
Chris Inacio wrote: I wanted to add an option to multiple ports - that is easy. But, those ports have a dependency relationship, and I only want the last node in the port dependency graph to build with that option if the requisite ports have too. In real terms: net/spread - net/libfixbuf - net-mgmt/yaf I added a SPREAD option to net/libfixbuf to net-mgmt/yaf. net-mgmt/yaf can only build a Spread version if libfixbuf was built with a Spread version. Question 1) How do you construct such that if a user goes into net-mgmt/yaf chooses Spread and fixbuf isn't already installed, it builds fixbuf with the spread option? Question 2) How do you ensure that if fixbuf is already installed, it has the Spread option enabled, or disallow/error the Yaf Spread option? One way to do this is to create a separate port net/libfixbuf-spread that either installs separate libfixbuf-spread.so or just conflicts with net/libfixbuf, and then make net-mgmt/yaf depend on that if SPREAD option is 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: port dependencies with port options
Chris Inacio nacho...@gmail.com wrote: So let me see if I understand the conversation so far correctly: (*) If I want to detect it, then I would need something like a new library name output from from fixbuf based on the build. (This currently doesn't exist.) New library name is not for detection; net/libfixbuf installs libfixbuf.so (and a bunch of related files), what you need is a separate port, net/libfixbuf-spread, that would compile libfixbuf with Spread support and install a separate library (so it would not conflict with the one net/libfixbuf installs), e.g. libfixbuf-spread.so. Then your port, net-mgmt/yaf, depending on the USE_SPREAD option, will either depend on net/libfixbuf and link with -lfixbuf, or will depend on net/libfixbuf-spread and will link with -lfixbuf-spread. (*) I could do some split port, but (even being a noob) sounds pretty bad. It's not hard, and we can help you. (*) There isn't a current method that directly queries build options from one port to another. Right. Am I capturing current state? ___ 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
OPTIONS-NG (was: port variants)
Ion-Mihai Tetcu ite...@freebsd.org wrote: I hope things will change once we get OPTIONS-NG in, since the new framework will address (AFAIK) all the objections people have against our current OPTIONS. Is that a thing in existence? Is there anywhere I can read about it? ___ 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] pkgng 1.0-beta9 please test
Baptiste Daroussin wrote: * pkg set -o oldorigin:neworigin allow the user to modify the origin of a packages (useful for MOVED) Can such things be tracked automatically? I.e. will pkg upgrade upgrade moved packages? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libaio freebsd port
Chad Perrin c...@apotheon.net wrote: I found linux version in ports /usr/ports/emulators/linux-libaio but could not even find project homepage to look at source code. Is this it? http://oss.oracle.com/projects/libaio-oracle/ I think it is [1] and related functions, at least those are what emulators/linux-libaio provides. [1] http://www.freebsd.org/cgi/man.cgi?query=io_setupmanpath=SuSE+Linux%2Fi386+11.0 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD ports which are currently scheduled for deletion
portname: graphics/vrml2pov description:Convert VRML files to POVRay source maintainer: po...@freebsd.org status: BROKEN deprecated because: unfetchable This seems to be a ports-infrastructure problem, rather than a problem in the vrml2pov port. No, it's a No one cares enough about this port to step forward and maintain it problem. Er, as of a few hours ago (when I tried it), the URL in the distfile link on vrml2pov's download page *exactly* matched the URL that the port tries to fetch. The default FETCH_ARGS include -A which makes fetch fail on redirects; this is presumably because some sites redirect rather than return 404 when a file is not found. In cases when redirect needs to be followed, you need to override FETCH_ARGS in the port's Makefile. See the attached patch (I hope it'll get through the list). I can submit a PR, or some brave committer can apply it right away... Oh, it's actually appears to be fetchable the way it is right now, just remove the BROKEN lines. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD ports which are currently scheduled for deletion
portname: graphics/vrml2pov
description:Convert VRML files to POVRay source
maintainer: po...@freebsd.org
status: BROKEN
deprecated because: unfetchable
This seems to be a ports-infrastructure problem, rather than a
problem in the vrml2pov port.
No, it's a No one cares enough about this port to step forward
and maintain it problem.
Er, as of a few hours ago (when I tried it), the URL in the distfile
link on vrml2pov's download page *exactly* matched the URL that the
port tries to fetch.
The default FETCH_ARGS include -A which makes fetch fail on redirects;
this is presumably because some sites redirect rather than return 404
when a file is not found. In cases when redirect needs to be followed,
you need to override FETCH_ARGS in the port's Makefile.
See the attached patch (I hope it'll get through the list). I can submit
a PR, or some brave committer can apply it right away...
--- Makefile.orig 2012-02-08 13:18:22.0 +0200
+++ Makefile2012-02-08 13:18:47.0 +0200
@@ -17,13 +17,10 @@
RESTRICTED=Redistribution is not allowed
-BROKEN=unfetchable
-DEPRECATED=${BROKEN}
-EXPIRATION_DATE= 2012-03-21
-
USE_ZIP= yes
USE_GMAKE= yes
MAKEFILE= makefile
+FETCH_ARGS=-Fpr
PLIST_FILES= bin/vrml2pov
NO_WRKSUBDIR= yes
___
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: Adding licensing info to my ports: some questions
Eitan Adler wrote: 1) Will licensing section ever appear in the Porters Handbook? :-) Yes Is someone actually working on it? If so, and is there some sort of target timeline? Back in 2010 when the framework was introduced, my general impression was that maintainers where advised to wait with the adoption until that chapter is written... ___ 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: redports.org - The public FreeBSD ports development infrastructure
Hi again. I've got this issue: an update to one port depends on an update to another one, and I'd like to test both before submitting. So the question is this: if I've got both ports in the repository, when rebuilding the dependent port, will redports use the dependency from official ports tree, or from my repository? ___ 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: redports.org - The public FreeBSD ports development infrastructure
Bernhard, is there a time limit on build execution, or some other kind of hang prevention? My port (lang/stklos) has a known problem with hanging on 9.x, and it's already been building for 90 minutes (normally it takes one)... So, if you'll read this message before it is finished, please just kill it. This brings me to a feature request: being able to abort your own builds before they are finished. ___ 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: redports.org - The public FreeBSD ports development infrastructure
Bernhard Froehlich wrote: Hi Porters! I am happy to announce that redports.org has finally reached the point where I think It's safe to be used by everybody! First of all, this is pretty great. Next, questions, comments feature requests. 1. It would be good to see what is currently in the queue for each backend (or buildgroup) right now; just to get an estimation of when your build will finish (e.g. in a few minutes vs. in a month). An actual estimation would be even better. 2. GCC 4.5 buildgroup currently shows 0 queued builds, but for some reason my build in that buildgroup does not start. Is there really nothing queued there? 3. On My builds page I see two strange builds in waiting state: one for buildgroup GCC another for 4.5; should that be one buidgroup GCC 4.5? 4. Is each backend a separate physical (or virtual) machine (i.e. do they all operate independently)? Are more machines planned? 5. Is there a way to see all the build archive, not just yours when you are logged in? ___ 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/chicken, fails to package, needs MAKE_JOBS_UNSAFE
Doug Barton wrote: Also, once it got built, it failed to package: === Building package for chicken-4.7.0 tar: lib/chicken/6/modules.db: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 Stop in /usr/ports/lang/chicken. Seems to work for me on 8.2-RELEASE amd64. Can you send me your build/install/package logs? I'll try to reproduce the problem. Sure, here you go: http://people.freebsd.org/~dougb/chicken-build.log FYI, I did some more testing and it only fails on i386. I confirmed your experience that it works fine on 8-amd64. Doug, is there something peculiar about your i386 box? I tested on my laptop and on a clean VirtualBox setup (both 8.2-RELEASE, i386); in both cases the installation (and make package) work fine. Can you show a list of the installed ports on your system? ___ 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/chicken, fails to package, needs MAKE_JOBS_UNSAFE
Doug Barton wrote: On 10/05/2011 15:19, Vitaly Magerya wrote: Doug Barton wrote: Trying to create a package for lang/chicken today, it fails to build at all with FORCE_MAKE_JOBS, so it needs MAKE_JOBS_UNSAFE= true in the Makefile. True. Do you mind if I go ahead and add that sooner rather than later? I'll appreciate if you will. I actually have a seemingly working fix, but I'll submit it after the upstream will accept it. Seems to work for me on 8.2-RELEASE amd64. Can you send me your build/install/package logs? I'll try to reproduce the problem. Sure, here you go: http://people.freebsd.org/~dougb/chicken-build.log FYI, I did some more testing and it only fails on i386. I confirmed your experience that it works fine on 8-amd64. I'll look into it, 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: lang/chicken, fails to package, needs MAKE_JOBS_UNSAFE
Doug Barton wrote: Trying to create a package for lang/chicken today, it fails to build at all with FORCE_MAKE_JOBS, so it needs MAKE_JOBS_UNSAFE= true in the Makefile. True. Also, once it got built, it failed to package: === Building package for chicken-4.7.0 tar: lib/chicken/6/modules.db: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 Stop in /usr/ports/lang/chicken. Seems to work for me on 8.2-RELEASE amd64. Can you send me your build/install/package logs? I'll try to reproduce the problem. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD ports which are currently scheduled for deletion
On 21/08/2011, lini...@freebsd.org lini...@freebsd.org wrote: portname: devel/noweb description:A simple, extensible literate-programming tool maintainer: po...@freebsd.org deprecated because: No more public distfiles expiration date:2011-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=noweb The distfile for this port exist and is still fetchable from the same place as always, [1]. Please, unbreak it (or should I send a PR about this?). [1] ftp://www.eecs.harvard.edu/pub/nr/ ___ 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: [ANNOUNCE]: clang compiling ports
Hi, Roman. Can you specify what environment and which make options
where used? I'm somewhat confused because of log [1]: the Makefile
basically does the compiling this way:
${MAKE} PROG=lemon NOMAN=1 NO_MAN=1 \
CFLAGS=-g ${CFLAGS} \
-f /usr/share/mk/bsd.prog.mk
Since bsd.prog.mk does respect CC, and the log says that cc was
invoked, it must follow that CC is cc (or empty). What am I missing?
[1]
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/lemon-1.69.log
___
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 testers: www/shellinabox (Shell in a Box)
Olivier Cochard-Labbé wrote:
I've just finished my port of Shell in a Box: It's a secure web server
that provide ajax terminal emulator.
More information on the official website:
http://code.google.com/p/shellinabox/
After looking at the port for a while, I have some suggestions.
The port creates ${PREFIX}/etc/shellinabox directory, chowns it to
nobody and chmods it to 777. The reason for this is that shellinabox
creates certificates during the runtime and stores them into that
directory, but it only does that after dropping to nobody user.
As the author of shellinabox notes [1], this is a bad idea, because any
user can read and modify your keys this way. I also have a vague feeling
that storing variable files in ${PREFIX}/etc/shellinabox is a bad idea
as well (to compare, Debian port uses /var/lib/shellinabox).
So what I propose is this:
1. Create shellinabox user and group (via USERS and GROUPS).
2. Update rc script to start shellinaboxd with that user and group.
3. Make the certificate directory 700, owned by shellinabox:shellinabox.
4. Move the certificate directory to /var/shellinabox or similar
(what's our conventional location for this kind of files?).
I'm not sure on the 4 though. Any thoughts?
[1] http://code.google.com/p/shellinabox/issues/detail?id=22#c2
___
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 testers: www/shellinabox (Shell in a Box)
Olivier Cochard-Labbé wrote: I've just finished my port of Shell in a Box: It's a secure web server that provide ajax terminal emulator. Before to submit it, Can someone test it ? Builds installs fine. Does not run: # /usr/local/etc/rc.d/shellinaboxd onestart Starting shellinaboxd. # /usr/local/etc/rc.d/shellinaboxd onestatus shellinaboxd is not running. # tail -1 /var/log/messages Jun 25 11:31:30 vbsd kernel: pid 4461 (shellinaboxd) uid65534: exited on signal 11 # shellinaboxd Segmentation fault # uname -mrsi FreeBSD 8.0-RELEASE i386 GENERIC The machine in question is a vanilla 8.0-RELEASE in VirtualBox. I can provide any additional information, just name it. ___ 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: GPLv3-licensed ports
Charlie Kester wrote: Will someone with edit privileges for the wiki please add the following to the list of GPLv3-licensed ports (http://wiki.freebsd.org/PortsAndGPLv3)? math/ised misc/xsw sysutils/rdup And lang/ikarus too while we're at it. I don't understand the purpose of that list though. What does legal decisions regarding the use of GPLv3 in our ports system mean? ___ 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: GPLv3-licensed ports
Mehmet Erol Sanliturk wrote: I don't understand the purpose of that list though. What does legal decisions regarding the use of GPLv3 in our ports system mean? http://www.gnu.org/licenses/quick-guide-gplv3.html : ( BSD License is NOT compatible to GPL v3 ... , please see figure , if I understand it correctly . ) No, 3-clause BSD license is compatible with GPLv3 [1] (you can follow multiple arrows on that figure). You can combine BSD-licensed code with GPLv3-licensed code and either use it privately or redistribute it under GPLv3. Pretty much the same as with GPLv2. This actually implies that the packages and possibly the patches in GPL ports are covered by GPL too... hence the legal decision I guess. OK. [1] 4-clause BSD is incompatible with both GPLv2 and GPLv3. ___ 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: Let's add more DESKTOP_ENTRIES to our ports
On 19/08/2009, Dmitry Marakasov amd...@amdmi3.ru wrote: Here's the list of ports that depend on libX11 (based on INDEX-8) and do not either have DESKTOP_ENTRIES in Makefile or share/applications/*.desktop in pkg-plist: http://people.freebsd.org/~amdmi3/desktop-needed.txt Should interactive console applications have desktop entries? For example we have console games (e.g. games/tornado), interpreters, shells; there's also irc/irssi, www/elinks and similar. How do others (e.g. pkgsrc, debian/ubuntu) handle 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
Re: Automatically generate symlinks for virtual categories.
If anyone could improve the script please let me know. How about adding options? This patch [1] adds an option to specify alternative port root, an option to perform a dry run, and some usage printing. [1] http://tx97.net/pub/patches/auto-symlink-virtual.sh-r0-r1.diff ___ 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: Automatically generate symlinks for virtual categories.
And here [1] is a new version that does the same thing, but uses INDEX file instead of traversing the ports tree. It's quite faster this way (assuming your INDEX is up to date, maybe it's better to allow both algorithms?). Disclaimer: I did not test it properly. The thing that looks strange to me is that the original script appends main category to the name of port when symlinking. I copied that behavior for safety, but are there really naming conflicts in the ports tree? [1] http://tx97.net/pub/files/auto-symlink-virtual.sh ___ 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: Automatically generate symlinks for virtual categories.
I'll added your script to mine as a option. Yeah, I've done that too in the mean time, take a look: [1]. In that version both traverse algorithms share common linking code, it seems more maintainable this way. (I've added -w and -i to catch up with you, but the code overall is quite different, sorry about that). There's a question about the test for main category dir: if you use -w to specify a directory different than that of -p, a simlink $whereto/category/portname-category will be created. Maybe $whereto/category/portname would be the right thing in this case? [1] http://tx97.net/pub/files/auto-symlink-virtual.sh ___ 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: Automatically generate symlinks for virtual categories.
Some random comments: - you really want to add usage [1] (-d is intentionally not documented) - when destdir does not exist the script should make one [2] - you really want to handle whitespace in paths [3] - there's no easy way to use an INDEX that is not under portsdir; I think that in -i you should specify a path, not a filename [4] (The patches should be applied in the listed order). [1] http://tx97.net/pub/patches/auto-symlink-virtual-usage.diff [2] http://tx97.net/pub/patches/auto-symlink-virtual-destdir.diff [3] http://tx97.net/pub/patches/auto-symlink-virtual-whitespace.diff [4] http://tx97.net/pub/patches/auto-symlink-virtual-index.diff ___ 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
Help making a port for a (somewhat) restricted program
I'm creating a port for Petite Chez Scheme [1], which is a free interpreter
for commercial Chez Scheme, and has some licensing restrictions.
From what I understood in the license [2], user must accept it before
installing.
The text of the license is also distributed in the tarball, so it
seems appropriate
to simply display the license file on post-extract.
Is there a common way to display such a file before installing?
I'm currently using ${PAGER} for that [3], but it's unlike any other
port we have.
There's also a problem with packages: you can't create one unless
there's a way to show the license on pkg_add. I believe that pkg-install script
can be used here, but I don't think that putting the whole license inside
hat script is a good idea.
Currently I've forbidden making packages; any thoughts on the right way
to do that?
And the last issue: depending on a command line switch the port
requires fetching two different files. The way I've set it up is to set
a parameter depending on the switch, and then use it in DISTNAME.
In short, that makes portlint go crazy. Help on this is also appreciated.
[1] http://scheme.com/petitechezscheme.html
[2] http://scheme.com/download/petite-lic.html
[3] http://tx97/pub/patches/petite-chez.shar
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Help making a port for a (somewhat) restricted program
Look at how java/jdk-* does it.
java/jdk* uses ${PRINTF} (/usr/bin/printf) to display a message about
you having to go and download some of the restricted files, and then exits.
Once you've downloaded the files (and that implies that you've accepted
the license), the message no longer appears, and you can proceed with
installation.
(This seems to be the common way of treating restricted ports).
The difference with Petite Chez is that you do not need to accept anything
to download sources (no restriction on redistribution), so this part can be
automated; but you do have to read and accept the license before
installing it. ${PRINTF} won't help too much, as you can't display a
file with it;
and license is too big to fit on one screen anyway (that's why I'd use a pager).
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Help making a port for a (somewhat) restricted program
I just re-compiled jdk-1.6 (all 6 hours of it) yesterday. After unpacking the tarball(s) but before config. it popped up the Sun license and asked for a yes/no. I have no idea exactly how. Oh, yes, I missed that part somehow. The port has a script in it that shows the license and asks for yes/no. Looks good; I think I'll do that too. Thanks! (The first time I've mistakenly sent this only to Robert). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Help making a port for a (somewhat) restricted program
[3] http://tx97/pub/patches/petite-chez.shar That should have been http://tx97.net/pub/patches/petite-chez.shar ___ 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
