Re: Anyone got RethinkDB working in FreeBSD?
On 9/12/15 2:01 AM, Kurt Jaeger wrote:
Hi!
Right now, I'm in the part where it tries to link the
build/external/v8_3.30.33.16/build/out
stuff and fails because the clang loader does not handle
liba files 8-(
The latest .shar is available at
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203043
together with a build-log at
https://opsec.eu/backup/rethinkdb-build
which shows that it fails to link the external v8. If anyone has an
idea on how to fix this ? (Bcc: to sunpoet who maintains lang/v8*).
Why do you want it to link against the external v8 port? Seems like
just introducing a dependency headache.
.a files work on -stable. Did they get broken in -current?
~ % cc -v
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.1
Thread model: posix
Selected GCC installation:
.(02:43:28)(builder@build2)
~ % cat t.c
int
derp(int x)
{
return x*2;
}
.(02:43:37)(builder@build2)
~ % cat m.c
#include
int derp(int);
int
main(void)
{
printf("%d\n", derp(2));
}
.(02:43:40)(builder@build2)
~ % cc -c t.c
.(02:43:48)(builder@build2)
~ % ar -r t.a t.o
.(02:43:53)(builder@build2)
~ % cc m.c t.a
.(02:43:58)(builder@build2)
~ % ./a.out
4
.(02:44:00)(builder@build2)
~ % uname -a
FreeBSD build2 10.1-BETA2 FreeBSD 10.1-BETA2 #0 df2cf31(HEAD): Tue Jul
7 00:38:22 UTC 2015 root@build2:/usr/obj/usr/src/sys/GENERIC amd64
.(02:44:25)(builder@build2)
~ %
___
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 with new port with multiple downloaded files from github
Hey, any luck with this port?
>Tom Pusateri writes:
>
>> Here’s the Makefile
>>
>> PORTNAME=libchromiumcontent
>> PORTVERSION= 43.0.2357.65
>
>To override these variables you have to modify master port to use ?=.
>And altering PORTNAME often breaks master's DISTFILES/WRKSRC/etc.
>
>In this case PORTVERSION should probably stay in sync with master to
>avoid trying to apply new port patches against old chromium.
>
>> DISTVERSIONPREFIX= v
>> DISTVERSIONSUFFIX= -atom-2
>
>DISTVERSION*FIX affect both master and slave distfile. If you only want
>to alter the latter convert into GH_TAGNAME.
>
>>
>> MAINTAINER= pusateri at bangj.com
>> COMMENT= Shared library build of Chromium's Content module
>>
>> USE_GITHUB= yes
>Define to "nodefault" to avoid altering MASTER_SITES inherited from the
>master port.
>
>> GH_PROJECT= libchromiumcontent:libchromiumcontent
>> GH_ACCOUNT= atom:libchromiumcontent
>>
>> .include "${MASTERDIR}/Makefile"
>
>Would the following work for you?
>--8<---cut here---start->8---
>PKGNAMEPREFIX= libchromiumcontent-
>
>MAINTAINER=pusateri at bangj.com
>COMMENT= Shared library build of Chromium's Content module
>
>USE_GITHUB=nodefault
>GH_PROJECT=libchromiumcontent:libchromiumcontent
>GH_ACCOUNT=atom:libchromiumcontent
>GH_TAGNAME=v43.0.2357.65-atom-2:libchromiumcontent
>
>MASTERDIR= ${.CURDIR}/../chromium
>DESCR= ${.CURDIR}/pkg-descr
>DISTINFO_FILE= ${.CURDIR}/distinfo
>
># Apply port patches if any from slave
>.if exists(${.CURDIR}/files)
>EXTRA_PATCHES+=${.CURDIR}/files/patch-*
>.endif
>
>.include "${MASTERDIR}/Makefile"
>--8<---cut here---end--->8---
___
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: Anyone got RethinkDB working in FreeBSD?
Hi! > Right now, I'm in the part where it tries to link the > build/external/v8_3.30.33.16/build/out > stuff and fails because the clang loader does not handle > liba files 8-( The latest .shar is available at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203043 together with a build-log at https://opsec.eu/backup/rethinkdb-build which shows that it fails to link the external v8. If anyone has an idea on how to fix this ? (Bcc: to sunpoet who maintains lang/v8*). -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ 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"
FreeBSD Port: htop-1.0.3
Dear Maintainer,
I just wanted to let you know that the output for htop (after
installation) is out of order:
Message for htop-1.0.3:
***
htop(1) requires linprocfs(5) to be mounted. If you don't
have it mounted already, please add this line to /etc/fstab
and run `mkdir -p /usr/compat/linux/proc; ln -s /usr/compat /compat; mount
linproc`:
linproc /compat/linux/proc linprocfs rw,late 0 0
***
should be
Message for htop-1.0.3:
***
htop(1) requires linprocfs(5) to be mounted. If you don't
have it mounted already, please add this line to /etc/fstab
linproc /compat/linux/proc linprocfs rw,late 0 0
and run `mkdir -p /usr/compat/linux/proc; ln -s /usr/compat /compat; mount
linproc`:
***
The last line should be before the mkdir commands, to prevent users from
incorrectly adding the "mkdir ..." commands to /etc/rc.conf
I installed htop using 'pkg install htop-1.0.3'.
Output of 'pkg info htop-1.0.3':
htop-1.0.3
Name : htop
Version: 1.0.3
Installed on : Sat Sep 12 03:11:13 MDT 2015
Origin : sysutils/htop
Architecture : freebsd:10:x86:64
Prefix : /usr/local
Categories : sysutils
Licenses : GPLv2
Maintainer : g...@hychen.org
WWW: http://htop.sourceforge.net/
Comment: Better top(1) - interactive process viewer
Options:
LSOF : on
Annotations:
repo_type : binary
repository : FreeBSD
Flat size : 151KiB
Description:
htop is an enhanced version of top, the interactive process viewer,
which can display the list of processes in a tree form.
Comparison between 'htop' and 'top'
* In 'htop' you can scroll the list vertically and horizontally
to see all processes and full command lines.
* In 'top' you are subject to a delay for each unassigned
key you press (especially annoying when multi-key escape
sequences are triggered by accident).
* 'htop' starts faster ('top' seems to collect data for a while
before displaying anything).
* In 'htop' you don't need to type the process number to
kill a process, in 'top' you do.
* In 'htop' you don't need to type the process number or
the priority value to renice a process, in 'top' you do.
* In 'htop' you can kill multiple processes at once.
* 'top' is older, hence, more tested.
WWW: http://htop.sourceforge.net/
If you have any questions, let me know.
-
Antonio Arredondo
PhD Candidate
NMSU Computer Science Department
http://www.cs.nmsu.edu/~aarredon/
-
___
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: rc script problem - pidfile not being recognised
On Sat, 12 Sep 2015 01:46:23 +0200 Michelle Sullivan wrote: > Roger Marquis wrote: > > RW via freebsd-ports wrote: > >> It needs both. It won't use just the pid file because the pid > >> might have been reassigned to another process if the original > >> daemon died without deleting its pid file. > > > > Why would this rc script *require* a command_interpreter variable > > to use the pidfile variable? I'm curious because this violates > > KIS, the principle of least surprise and few rc scripts seem to > > have this variable defined. > > > > Using command_interpreter is good to be sure, for for the reason > > listed, but rc scripts should not fail if it is undefined. > > +1 to that. You'd rather an rc script fails at run-time and shuts down the wrong daemon than fail when the script is being developed? ___ 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: rc script problem - pidfile not being recognised
RW via freebsd-ports wrote: You'd rather an rc script fails at run-time and shuts down the wrong daemon than fail when the script is being developed? It's not so much where the script fails than that it fails in the first place. Neither a pidfile nor a command_interpreter needs to be required for an rc scripts to work. These are nice features but making them mandatory is at best a sort of premature optimization. The freebsd rc script environment is already far too OS-specific and un-editable, often containing no readable shell code at all. What if your interpreter changes from say python2.7 to python for example? Does that mean you have to reinstall all the associated packages or edit their rc scripts? Neither shouldn you have to parse who knows how many hundred of lines of shell code included by /etc/rc.subr or rewrite an rc script from scratch to make a simple change. We appreciate the features this subsystem provides and the work devs have put into it but not when it's made mandatory. The value of KIS needs to be emphasized here. IMO, Roger Marquis ___ 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"
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ x11/xvkbd | 3.6 | 3.7 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
