Poudriere: Null-mount existing /usr/src folder for kernel sources

2013-11-13 Thread Beeblebrox
Some ports require kernel sources to build.
On a system that has /usr/src already downloaded, how can one null-mount
that folder into poudriere's build environment so that kernel sources are
made available for the poudriere jails?
These probably won't work:
* fstab file and entry in build-jailname/etc/fstab
* /etc/fstab.build-jailname on host
* Adding entry to /usr/local/etc/poudriere.d/jails/build-jailname/fs

I have not found any possible setting in poudriere.conf for this.



-
FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/Poudriere-Null-mount-existing-usr-src-folder-for-kernel-sources-tp5860808.html
Sent from the freebsd-ports mailing list archive at Nabble.com.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Package libiconv not found

2013-11-13 Thread Csaba Raduly
Hi all,
I'm affected by pkg registration conflict between libiconv-1.14_1 and
gettext-0.18.1.1
(http://lists.freebsd.org/pipermail/freebsd-ports/2013-March/082231.html)
and I was trying to follow the instructions in /usr/ports/UPDATING.
However, running pkg query %ro libiconv returns nothing (which may
or may not be a problem), but then

# pkg delete -f libiconv
Package(s) not found!

How is this possible? Where did I mess up?

My system is a FreeBSD 9.1 vmware image from thoughtpolice.co.uk
# uname -a
FreeBSD freeby91.localdomain 9.1-RELEASE FreeBSD 9.1-RELEASE #0
r243825: Tue Dec  4 09:23:10 UTC 2012
r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

I ran
# portsnap fetch
# portsnap update

installed portmaster and pkg, then ran pkg2ng, then tried

# portmaster -a

Csaba
P.S. Please CC me because I'm not subscribed to the list.
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
Ok, it boots. Which means it must be bug-free and perfect.  -- Linus Torvalds
People disagree with me. I just ignore them. -- Linus Torvalds
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: Poudriere: Null-mount existing /usr/src folder for kernel sources

2013-11-13 Thread Bryan Drewery
On 11/13/2013 2:25 AM, Beeblebrox wrote:
 Some ports require kernel sources to build.
 On a system that has /usr/src already downloaded, how can one null-mount
 that folder into poudriere's build environment so that kernel sources are
 made available for the poudriere jails?
 These probably won't work:
 * fstab file and entry in build-jailname/etc/fstab
 * /etc/fstab.build-jailname on host
 * Adding entry to /usr/local/etc/poudriere.d/jails/build-jailname/fs
 
 I have not found any possible setting in poudriere.conf for this.
 
 
 
 -
 FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS


Poudriere already does this by default. It null mounts the jail's
/usr/src into the build jails as read-only.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature


Re: Poudriere: Null-mount existing /usr/src folder for kernel sources

2013-11-13 Thread Beeblebrox
Thank you Brian for the answer.
The problem is, the data is on host's /usr/src and the jail's /usr/src is
empty. If I were to first null-mount host's /usr/src onto jail's /usr/src, I
don't suppose poudriere would be able to null-mount a null-mount?



-
FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/Poudriere-Null-mount-existing-usr-src-folder-for-kernel-sources-tp5860808p5860838.html
Sent from the freebsd-ports mailing list archive at Nabble.com.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: Poudriere: Null-mount existing /usr/src folder for kernel sources

2013-11-13 Thread Beeblebrox
While the null-mount of /var/db/ports onto /usr/local/etc/poudriere/options
gets transferred to the build jails by poudriere, the null-mount of /usr/src
onto poudriere-environment/usr/src (as expected) does not get propagated to
the build jails.




-
FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/Poudriere-Null-mount-existing-usr-src-folder-for-kernel-sources-tp5860808p5860844.html
Sent from the freebsd-ports mailing list archive at Nabble.com.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


net/grive update to 0.2.0_1 on 10-beta3

2013-11-13 Thread Alex V. Petrov
[ 95%] Building CXX object 
libgrive/CMakeFiles/unittest.dir/test/util/FunctionTest.cc.o
[ 97%] Building CXX object 
libgrive/CMakeFiles/unittest.dir/test/util/SignalHandlerTest.cc.o
[100%] Building CXX object 
libgrive/CMakeFiles/unittest.dir/test/xml/NodeTest.cc.o
4 warnings generated.
Linking CXX executable grive
../libgrive/libgrive.a(Json.cc.o): In function 
`gr::Json::Jsonstd::__1::vectorgr::Json, 
std::__1::allocatorgr::Json  (std::__1::vectorgr::Json, 
std::__1::allocatorgr::Json  
const)':
/usr/ports/net/grive/work/Grive-grive-93d696a/libgrive/src/protocol/Json.cc:(.text+0xb1e):
 
warning: Warning: please link against libjson-c instead of libjson
Linking CXX executable unittest
/usr/bin/ld: c: invalid DSO for symbol `json_object_array_get_idx' definition
/usr/local/lib/libjson-c.so.2: could not read symbols: Bad value
c++: error: linker command failed with exit code 1 (use -v to see invocation)
--- grive/grive ---
*** [grive/grive] Error code 1

make[3]: stopped in /usr/ports/net/grive/work/Grive-grive-93d696a
1 error

make[3]: stopped in /usr/ports/net/grive/work/Grive-grive-93d696a
--- grive/CMakeFiles/grive_executable.dir/all ---
*** [grive/CMakeFiles/grive_executable.dir/all] Error code 2

make[2]: stopped in /usr/ports/net/grive/work/Grive-grive-93d696a
A failure has been detected in another branch of the parallel make

make[3]: stopped in /usr/ports/net/grive/work/Grive-grive-93d696a
--- libgrive/CMakeFiles/unittest.dir/all ---
*** [libgrive/CMakeFiles/unittest.dir/all] Error code 2

make[2]: stopped in /usr/ports/net/grive/work/Grive-grive-93d696a
2 errors

make[2]: stopped in /usr/ports/net/grive/work/Grive-grive-93d696a
--- all ---
*** [all] Error code 2

make[1]: stopped in /usr/ports/net/grive/work/Grive-grive-93d696a
1 error

make[1]: stopped in /usr/ports/net/grive/work/Grive-grive-93d696a
=== Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make: stopped in /usr/ports/net/grive

=== make failed for net/grive
=== Aborting update

=== Killing background jobs
Terminated

=== You can restart from the point of failure with this command line:
   portmaster flags net/grive 

=== Exiting
-- 
-
Alex V. Petrov

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: net/grive update to 0.2.0_1 on 10-beta3

2013-11-13 Thread William Grzybowski
I don't know how to fix this, builds fine on 9.x:

http://beefy2.isc.freebsd.org/bulk/91amd64-default/2013-11-13_01h35m11s/logs/grive-0.2.0_1.log

On Wed, Nov 13, 2013 at 11:10 AM, Alex V. Petrov alexvpet...@gmail.com wrote:
 [ 95%] Building CXX object
 libgrive/CMakeFiles/unittest.dir/test/util/FunctionTest.cc.o

 [ 97%] Building CXX object
 libgrive/CMakeFiles/unittest.dir/test/util/SignalHandlerTest.cc.o

 [100%] Building CXX object
 libgrive/CMakeFiles/unittest.dir/test/xml/NodeTest.cc.o

 4 warnings generated.

 Linking CXX executable grive

 ../libgrive/libgrive.a(Json.cc.o): In function
 `gr::Json::Jsonstd::__1::vectorgr::Json, std::__1::allocatorgr::Json 
(std::__1::vectorgr::Json, std::__1::allocatorgr::Json  const)':

 /usr/ports/net/grive/work/Grive-grive-93d696a/libgrive/src/protocol/Json.cc:(.text+0xb1e):
 warning: Warning: please link against libjson-c instead of libjson

 Linking CXX executable unittest

 /usr/bin/ld: c: invalid DSO for symbol `json_object_array_get_idx'
 definition

 /usr/local/lib/libjson-c.so.2: could not read symbols: Bad value

 c++: error: linker command failed with exit code 1 (use -v to see
 invocation)

 --- grive/grive ---

 *** [grive/grive] Error code 1



 make[3]: stopped in /usr/ports/net/grive/work/Grive-grive-93d696a

 1 error



 make[3]: stopped in /usr/ports/net/grive/work/Grive-grive-93d696a

 --- grive/CMakeFiles/grive_executable.dir/all ---

 *** [grive/CMakeFiles/grive_executable.dir/all] Error code 2



 make[2]: stopped in /usr/ports/net/grive/work/Grive-grive-93d696a

 A failure has been detected in another branch of the parallel make



 make[3]: stopped in /usr/ports/net/grive/work/Grive-grive-93d696a

 --- libgrive/CMakeFiles/unittest.dir/all ---

 *** [libgrive/CMakeFiles/unittest.dir/all] Error code 2



 make[2]: stopped in /usr/ports/net/grive/work/Grive-grive-93d696a

 2 errors



 make[2]: stopped in /usr/ports/net/grive/work/Grive-grive-93d696a

 --- all ---

 *** [all] Error code 2



 make[1]: stopped in /usr/ports/net/grive/work/Grive-grive-93d696a

 1 error



 make[1]: stopped in /usr/ports/net/grive/work/Grive-grive-93d696a

 === Compilation failed unexpectedly.

 Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to

 the maintainer.

 *** Error code 1



 Stop.

 make: stopped in /usr/ports/net/grive



 === make failed for net/grive

 === Aborting update



 === Killing background jobs

 Terminated



 === You can restart from the point of failure with this command line:

 portmaster flags net/grive



 === Exiting

 --

 -

 Alex V. Petrov





-- 
William Grzybowski
--
Curitiba/PR - Brasil
___
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


NfSen Port PATCH

2013-11-13 Thread Chad Gross
I found an issue with the nfsen port Makefile. It is not properly
configured to expand the %%PORTNAME%% variable used when generating the
nfsen config file.


For example, the config that is installed shows this:

$VARDIR=${BASEDIR}/var/%%PORTNAME%%;


When it should be this:

$VARDIR=${BASEDIR}/var/nfsen;

I have attached the patch, but also included it in-line below. I emailed
the maintainer, but hadn't heard a response so figured I would send it here
just in case.


--- Makefile2013-11-03 12:31:00.0 -0500

+++ Makefile.new2013-11-03 12:30:51.0 -0500

@@ -37,6 +37,7 @@

 SUB_LIST+= PORTVERSION=${PORTVERSION}

 SUB_LIST+= PREFIX=${PREFIX}

 SUB_LIST+= WWWDIR=${WWWDIR}

+SUB_LIST+= PORTNAME=${PORTNAME}



 NO_STAGE=  yes

 post-patch:


Thanks,

Chad


nfsen.patch
Description: Binary data
___
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

Building specific ports with gcc in 10.0

2013-11-13 Thread Matthieu Volat
Hi everybody,

With the 10.0 release becoming more and more tangible, I tried to switch one 
laptop to 10.0-BETA3 and see how it would go.

I fumbled into a problem that I have a hard time to resolve: I would like to 
build graphics/darktable with gcc (lang/gcc46 to be precise, through the 
USE_GCC system) to benefit from openmp support. 

Here's the problem : graphics/darktable, mostly C, uses graphics/exiv2 which is 
written in C++, but built with clang++/libc++. So when I try to build 
graphics/darktable, I get errors of unresolved symbols from exiv2 library:

libdarktable.so: undefined reference to 
`Exiv2::XmpProperties::registerNs(std::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const, std::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const)'
libdarktable.so: undefined reference to 
`Exiv2::XmpParser::encode(std::basic_stringchar, std::char_traitschar, 
std::allocatorchar , Exiv2::XmpData const, unsigned short, unsigned int)'
libdarktable.so: undefined reference to
`Exiv2::ExifData::operator[](std::basic_stringchar,
std::char_traitschar, std::allocatorchar  const)'
[...]

I suppose this comes from symbol naming conventions between clang++/libc++ and 
g++/libstdc++ (wasn't C++ ABI supposed to be standard? I guess not). If I build 
exiv2 with g++, I can build darktable, but I feel this way of doing things will 
be a PITA in the future.

Does anybody knowledgeable with gcc know how to manage those issues?

-- 
Matthieu Volat ma...@alkumuna.eu


signature.asc
Description: PGP signature


Re: Best way to make the port install another port

2013-11-13 Thread Kevin Oberman
On Tue, Nov 12, 2013 at 2:31 PM, Lowell Gilbert 
freebsd-ports-lo...@be-well.ilk.org wrote:

 Big Lebowski spankthes...@gmail.com writes:

  Yes, that was exactly the case - I know about these options, and I know
 how
  to use them, but somehow RUN_DEPENDS doesnt feel right here. The original
  port is a standalone piece of software, that can perfectly run without
 the
  second one. The second one happens to be developed very closely with
 first
  one, and its a commandline tool for it (but there are other ways to
 access
  and work on the original port). Therefore RUN_DEPENDS sounds wrong.
  But if that's what should be used, I'll do so.

 Look at it this way; the *option* depends on the second port.


Take a look at the Makefile for any of the big multimedia ports like vlc or
mplayer. They have a long list of options for different codecs, most of
which create added RUN_DEPENDS.
-- 
R. Kevin Oberman, Network Engineer
E-mail: rkober...@gmail.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Proposal for Authors / Vendors in ports

2013-11-13 Thread Kris Moore

Wanted to run this by the ports community, see your thoughts. We build
our PBIs from the ports system, and are able to parse most of the
information out for display graphically, like descriptions, maintainers,
website, License, etc. However we currently don't have a way to pull the
actual name of the upstream vendor / author. I.E. for Firefox the vendor
would be Mozilla.

This information is useful to use, because we want to be able to show
users who exactly is the author of the software, not just the
maintainer, which may only be gnome@ or ports@ or whatever. Does anybody
have any thoughts on if this could be something we support in the tree?

While I'm on the topic, how about a broader type for ports as well?
Something like gui/cli/library/data/doc/meta/foo would be helpful to
further categorize applications.

-- 
Kris Moore
PC-BSD Software
iXsystems

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: Proposal for Authors / Vendors in ports

2013-11-13 Thread Melvyn Sopacua

On Wed, 13 Nov 2013, Kris Moore wrote:



Wanted to run this by the ports community, see your thoughts. We build
our PBIs from the ports system, and are able to parse most of the
information out for display graphically, like descriptions, maintainers,
website, License, etc. However we currently don't have a way to pull the
actual name of the upstream vendor / author. I.E. for Firefox the vendor
would be Mozilla.


WWW: [Mozilla](http://www.mozilla.org/)

So, markdown format in pkg-descr. Seems the least amount of work?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: Proposal for Authors / Vendors in ports

2013-11-13 Thread Eitan Adler
On Wed, Nov 13, 2013 at 3:27 PM, Melvyn Sopacua mel...@magemana.nl wrote:
 On Wed, 13 Nov 2013, Kris Moore wrote:


 Wanted to run this by the ports community, see your thoughts. We build
 our PBIs from the ports system, and are able to parse most of the
 information out for display graphically, like descriptions, maintainers,
 website, License, etc. However we currently don't have a way to pull the
 actual name of the upstream vendor / author. I.E. for Firefox the vendor
 would be Mozilla.


 WWW: [Mozilla](http://www.mozilla.org/)

 So, markdown format in pkg-descr. Seems the least amount of work?

This adds a lot of work to the parser.

IMHO we should have VENDOR_WWW and possibly VENDOR_NAME in the port's
Makefile.  It should not be hard to automate this for VENDOR_WWW since
we already have the WWW: lines in pkg-descr.

However I wonder how much non-porting metadata we should special case.
 In particular see below:

While I'm on the topic, how about a broader type for ports as well?
Something like gui/cli/library/data/doc/meta/foo would be helpful to
further categorize applications.

This has come up before.  There are two options
a) FreeBSD itself could come up with some level of categorization.  In
this case we should validate the data.

b) We can supply the ability for ports to include metadata useful for
third parties.  In this case we should not validate the data.

In the past I've argued for option B as the amount of data we could
add is endless.

Since the primary consumer would be PC-BSD or other package management
tools which would you prefer?





-- 
Eitan Adler
___
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: NfSen Port PATCH

2013-11-13 Thread Mark Felder

On Nov 13, 2013, at 12:27, Chad Gross avata...@gmail.com wrote:

 I found an issue with the nfsen port Makefile. It is not properly
 configured to expand the %%PORTNAME%% variable used when generating the
 nfsen config file.
 
 
 For example, the config that is installed shows this:
 
 $VARDIR=${BASEDIR}/var/%%PORTNAME%%;
 
 
 When it should be this:
 
 $VARDIR=${BASEDIR}/var/nfsen;
 
 I have attached the patch, but also included it in-line below. I emailed
 the maintainer, but hadn't heard a response so figured I would send it here
 just in case.
 
 
 --- Makefile2013-11-03 12:31:00.0 -0500
 
 +++ Makefile.new2013-11-03 12:30:51.0 -0500
 
 @@ -37,6 +37,7 @@
 
 SUB_LIST+= PORTVERSION=${PORTVERSION}
 
 SUB_LIST+= PREFIX=${PREFIX}
 
 SUB_LIST+= WWWDIR=${WWWDIR}
 
 +SUB_LIST+= PORTNAME=${PORTNAME}
 
 
 
 NO_STAGE=  yes
 
 post-patch:
 
 
 Thanks,
 

Thanks for catching this. I’m not sure how I missed this when I rewrote the 
port… I definitely tested clean installs, but I must have provided my own 
configs



signature.asc
Description: Message signed with OpenPGP using GPGMail


Determining file size of port source

2013-11-13 Thread Joe Nosay
ls -lh -D Byte does not give me the exact byte size of the archive. What
is the correct command?
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: Determining file size of port source

2013-11-13 Thread Joe Nosay
root@conhecer:/traverso/work # cd ..
root@conhecer:/traverso # make
===  Found saved configuration for traverso-0.49.2
===   traverso-0.49.2 depends on file: /usr/local/sbin/pkg - found
= traverso-0.49.2.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
= Attempting to fetch
http://downloads.sourceforge.net/project/traversofreebsdport/work/traverso-0.49.2-revision_2.tar.gztraverso-0.49.2.tar.gz
fetch:
http://downloads.sourceforge.net/project/traversofreebsdport/work/traverso-0.49.2-revision_2.tar.gztraverso-0.49.2.tar.gz:
Not Found
= Attempting to fetch
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/traverso-0.49.2.tar.gz
fetch:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/traverso-0.49.2.tar.gz:
File unavailable (e.g., file not found, no access)
= Couldn't fetch it - please try to retrieve this
= port manually into /usr/ports/distfiles/ and try again.
*** Error code 1

Stop.
make[1]: stopped in /traverso
*** Error code 1

Stop.
make: stopped in /traverso
root@conhecer:/traverso # ls /usr/ports/distfiles|grep trav
traverso-0.49.2-revision_2.tar.gz
root@conhecer:/traverso #



I do not need the 0.49.2 to  be added to the download path. I only need
what is listed in /usr/ports/distfiles and nothing more.


On Wed, Nov 13, 2013 at 6:15 PM, Joe Nosay superbisq...@gmail.com wrote:

 ls -lh -D Byte does not give me the exact byte size of the archive. What
 is the correct command?
 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: Determining file size of port source

2013-11-13 Thread Charles Swiger
Hi--

On Nov 13, 2013, at 3:15 PM, Joe Nosay superbisq...@gmail.com wrote:
 ls -lh -D Byte does not give me the exact byte size of the archive. What
 is the correct command?

ls -l _file_ is the most direct way, but you can run the file through wc -c or 
do other things.

Regards,
-- 
-Chuck

___
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: Determining file size of port source

2013-11-13 Thread Shane Ambler
On 14/11/2013 09:53, Joe Nosay wrote:
 root@conhecer:/traverso/work # cd ..
 root@conhecer:/traverso # make
 ===  Found saved configuration for traverso-0.49.2
 ===   traverso-0.49.2 depends on file: /usr/local/sbin/pkg - found
 = traverso-0.49.2.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
 = Attempting to fetch
 http://downloads.sourceforge.net/project/traversofreebsdport/work/traverso-0.49.2-revision_2.tar.gztraverso-0.49.2.tar.gz
 fetch:
 http://downloads.sourceforge.net/project/traversofreebsdport/work/traverso-0.49.2-revision_2.tar.gztraverso-0.49.2.tar.gz:
 Not Found
 = Attempting to fetch
 ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/traverso-0.49.2.tar.gz
 fetch:
 ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/traverso-0.49.2.tar.gz:
 File unavailable (e.g., file not found, no access)
 = Couldn't fetch it - please try to retrieve this
 = port manually into /usr/ports/distfiles/ and try again.
 *** Error code 1
 
 Stop.
 make[1]: stopped in /traverso
 *** Error code 1
 
 Stop.
 make: stopped in /traverso
 root@conhecer:/traverso # ls /usr/ports/distfiles|grep trav
 traverso-0.49.2-revision_2.tar.gz
 root@conhecer:/traverso #
 
 
 
 I do not need the 0.49.2 to  be added to the download path. I only need
 what is listed in /usr/ports/distfiles and nothing more.

If your asking about the sourceforge download link, we'd need to see
your Makefile to see how it is calculated to get it correct.

Using SF for MASTER_SITES includes auto link calculations, it sounds
like you are adding to the link creation when you don't need to.

 On Wed, Nov 13, 2013 at 6:15 PM, Joe Nosay superbisq...@gmail.com wrote:
 
 ls -lh -D Byte does not give me the exact byte size of the archive. What
 is the correct command?
 Thanks

You can use make makesum to create the distinfo for you - once you get
the download links 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: Proposal for Authors / Vendors in ports

2013-11-13 Thread Erwin Lansing
On Wed, Nov 13, 2013 at 04:47:20PM -0500, Eitan Adler wrote:
 On Wed, Nov 13, 2013 at 3:27 PM, Melvyn Sopacua mel...@magemana.nl wrote:
  On Wed, 13 Nov 2013, Kris Moore wrote:
 
 
  Wanted to run this by the ports community, see your thoughts. We build
  our PBIs from the ports system, and are able to parse most of the
  information out for display graphically, like descriptions, maintainers,
  website, License, etc. However we currently don't have a way to pull the
  actual name of the upstream vendor / author. I.E. for Firefox the vendor
  would be Mozilla.
 
 
  WWW: [Mozilla](http://www.mozilla.org/)
 
  So, markdown format in pkg-descr. Seems the least amount of work?
 
 This adds a lot of work to the parser.
 
 IMHO we should have VENDOR_WWW and possibly VENDOR_NAME in the port's
 Makefile.  It should not be hard to automate this for VENDOR_WWW since
 we already have the WWW: lines in pkg-descr.
 

That sounds like an excellent idea.  I'm just a bit worried about
spreading the information over too many places, and would rather split
content from logic and add these to pkg-descr as well next to the
current WWW.  I know we're not consistent already with things like
COMMENT and LICENSE already in the Makefile, so won't ojbect too much to
where these end up.

Erwin

-- 
Erwin Lansinghttp://droso.dk
er...@freebsd.orghttp:// www.FreeBSD.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org