Re: How to package maven based ports
Sent from my iPhone > On Jul 20, 2019, at 14:33, Daniel Morante wrote: > > I've run into the same issue while attempting to port a few JAVA apps that > use maven and more recently one that also uses yarn for dependencies. > >> Have a look at the java/eclipse port. It uses a pre-warmed maven >> repository that is fetched from github. > While this is indeed a clever solution, it's (in my opinion) not ideal. > Don't take this personally, I applaud you for taking the time and effort in > making the Eclipse port. I use it on my systems. However, I feel that it's > important that I point this out. There are potential problems with this > approach. Most notably that the source of the dependencies gets changed from > the original location. The consequences could be serious should something > happen to your repository. > > This in my opinion is a bigger issue caused by these so called 'modern' > package managers that are becoming popular to use (maven, npm, yarn, and > composer to name a few). Historically like what is currently done with perl > and python (and to a lesser extent ruby), we would create ports for each of > these libraries and let the ports system handle the rest. > > Ideally the FreeBSD ports system should have the needed tooling to fetch > these type of dependencies as part of the same process used during the dist > files retrieval step. One method would be for the porter to include the > pom.xml, composer.json, and/or package.json files as part of the port > skeleton. The ports system would (using appropriate tools) download the > dependencies to 'pre-warm' a local cache as you are doing. Then set the > environment to use the local cache instead of downloading during the build > phase. > > I think this may be possible to hack together using the current make targets > 'pre-fetch' and 'post-fetch'? Further thinking about this, having the > pom.xml in the skeleton may not even be needed is you can use the post-fetch > target? > >> On 7/14/2019 3:21 PM, Matthias Fechner wrote: >>> Am 14.07.2019 um 00:23 schrieb Jonathan Chen: >>> Have a look at the java/eclipse port. It uses a pre-warmed maven >>> repository that is fetched from github. >>> >>> You can create a localised repository that only contains the >>> dependancies required by the project by specifying: >>> -D maven.repo.local=/my/local/repo >>> >>> Once your project builds correctly, you can create a repo as a project >>> on Github with its contents that can be retrieved with the port for >>> the build. >> thanks a lot for this. >> I'm not fully done with the port, but I was able to get this maven >> repository to be pushed to github and the port downloads it and >> compilation works as expected. >> Thanks a lot for you answer, it helped a lot. >> >> Now I need someone for testing the port, as I do not use it and are >> therefor I'm not able to test it. >> >> The final step would be to do some clean up a make the port more pretty. >> >> I try later to write a short summary if some one else needs to build a >> port with maven how it could be done. >> >> Gruß >> Matthias >> While using a pre-warmed repository does change the source of the dependencies, one thing it protects you from is when a specific version of a needed dependency is suddenly removed from the source repo. I saw this happen too many times working the Eclipse port over the years (and thanks Jonathan for taking this over) - Eclipse would be released being built against a snapshot version of something and two weeks later an official release of that ‘something’ is pushed out and the snapshot repo is deleted. And while it way work for simple projects to be able to use the built-in maven capability to just resolve and download dependencies (and do nothing else) as a single command in the port fetching phases, this might not work for all projects - definitely not something as complex as a Eclipse. Jimmy ___ 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: testing the value of ${CXX} in ports Makefile
On Fri, Jan 30, 2015 at 09:40:46AM +0100, Tijl Coosemans wrote: On Thu, 29 Jan 2015 22:46:32 -0800 (PST) Don Lewis truck...@freebsd.org wrote: gcc46, gcc47, gcc48, and probably gcc5 (haven't tested that one yet) all work. gcc49 requires a source patch. Can't you make the patch work with all versions of gcc? +1 Make the PATCH deal with whatever version of GCC is being used to compile that big of code... Jimmy ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fwd: building java/eclipse in HEAD w/ poudriere ...
On Thu, Oct 23, 2014 at 12:30:16PM +0200, Matthias Apitz wrote: El día Tuesday, September 09, 2014 a las 09:10:26AM -0500, Jimmy Kelley escribió: Hello Matthias, No ideas at the present on your problem. I tried building the eclipse port with poudriere, but lang/gcc is failing for me on -CURRENT right now. I had never before built the eclipse port on a -CURRENT machine, so I set up a -CURRENT i386 VM in VirtualBox with 2Gb RAM, 30 GB disk space, did a pkg install of eclipse 4.3.2_1 that currently is available (to get all the build/run dependencies installed), and then did a make package of the eclipse 4.3.2_2 in the ports tree. One hour later, I had a eclipse package ready to install, no out of memory errors or any other problem. From posts on the Eclipse Wiki's, building Eclipse with only 2Gb of RAM seems to running pretty close to the lower limit needed. I have managed to build with -Xmx1536m, but that's a low as I dare go; suggestions on the Eclipse Wiki for building Eclipse 4.4 recommend setting -Xmx2560m. I don't know anything about poudriere really, having never used it until my attempt last week. Could the overhead of poudriere be taking away from the memory space that would normally be available if one wasn't using it? Hello, Was meanwhile someone able to build java/eclipse on head in i386 *with* poudriere? Thx matthias Matthias, I finally had the time to set up an environment to do the build in a -CURRENT i386 poudriere environment. It built with no errors; see the bug you filed for details: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193479 Regards, Jimmy ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fwd: building java/eclipse in HEAD w/ poudriere: java.lang.OutOfMemoryError: Java heap space
On Sat, Aug 23, 2014 at 03:51:01PM +0200, Matthias Apitz wrote: Hello ljboi...@gmail.com, Can you as the MAINTAINER of the port please clarify how one can build this port on FreeBSD vm-tiny-r269739 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r269739M: Fri Aug 15 18:07:41 CEST 2014 guru@vm-tiny-r269739:/usr/obj/usr/src/sys/GENERIC i386 $ LANG=C svn info Path: . Working Copy Root Path: /usr/ports URL: svn://svn.freebsd.org/ports/head/java/eclipse Relative URL: ^/head/java/eclipse Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 364388 Node Kind: directory Schedule: normal Last Changed Author: marino Last Changed Rev: 361589 Last Changed Date: 2014-07-11 23:56:01 +0200 (Fri, 11 Jul 2014) Thanks in advance matthias - Forwarded message from Matthias Apitz g...@unixarea.de - Date: Sat, 23 Aug 2014 09:19:10 +0200 From: Matthias Apitz g...@unixarea.de To: freebsd-ports@freebsd.org Cc: freebsd-j...@freebsd.org Subject: building java/eclipse in HEAD w/ poudriere: java.lang.OutOfMemoryError: Java heap space Hello, I'm building ports in HEAD with poudriere; java/eclipse is failing with java.lang.OutOfMemoryError: Java heap space I've already set in make.conf MAVEN_OPTS=-Xmx2048m -XX:MaxPermSize=512m But tis does not help; the VM where poudriere is running has 4 GByte memory and 4 GByte swap space. Any ideas? Thanks matthias Hello Matthias, I have not tried to build this version of Eclipse on -CURRENT at all. I think -Xmx2048m for MAVEN_OPTS on i386 is too big; try -Xmx1792m. I had that in the Makefile when first developing and testing the port, but removed it; maybe putting that back in will deal with the complaints that bdrewery@ had about memory usage on the package builders... redports has never been kind to this port, but maybe I'll give it another go... Regards, Jimmy ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [pkg-fall...@freebsd.org: [REL - head-amd64-default][textproc/multimarkdown] Failed for multimarkdown-4.3.2 in checksum]
On Fri, Nov 08, 2013 at 09:55:00AM -0500, Adam Weinberger wrote:
Hi, I'm still having trouble with this. Can anybody offer me some advice
here? During which build stages may my port dial out? When make
checksum is run independently of make fetch, it begins by wiping out
${WRKDIR}.
Can I dial out during do-build on the package cluster?
# Adam
--
Adam Weinberger
ad...@adamw.org
http://www.adamw.org
Date: Fri, 8 Nov 2013 05:47:29 GMT
From: pkg-fall...@freebsd.org
To: ad...@freebsd.org
Cc: pkg-fall...@freebsd.org
Subject: [REL - head-amd64-default][textproc/multimarkdown] Failed for
multimarkdown-4.3.2 in checksum
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.
snip...
Hi Adam,
I've been working on a port for the latest version of Eclipse, which will
have to clone the eclipse git repo along with a bunch of submodules as you are
doing with the multimarkdown port. I will tell you that what has to be
pulled down is HUGH, and it really was a pain to wait for that fetch to happen
when I wanted to clean and rebuild because of some build error. What I ended
up doing is have the fetch phase pull the git repo down into the DISTDIR area
(git clone if it's not there, git update if it is already there ), and
then have the extract phase copy the stuff in DISTDIR over to WRKSRC where
it can be patched and built; a clean copy is always left in DISTDIR, just
like the tarballs of other ports.
This might sound like overkill (it's 2+Gb per copy of the git repo), but
for eclipse it's necessary because the build process needs the repo history
for timestamp info, and it really does speed things up (and will for future
port updates).
Perhaps this might help with the multimarkdown port...
Jimmy
___
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 java/eclipse-devel in CURRENT
On Tue, Oct 15, 2013 at 09:08:42PM +0200, Matthias Apitz wrote: El día Friday, October 11, 2013 a las 02:09:01PM +0200, Matthias Apitz escribió: Hello, How can I compile the port java/eclipse-devel im 10-CURRENT (with ports tree as well on bleading edge)? Openjdk16 can't be build and Openjdk17 can not build java/eclipse-devel. Do you need more log file about the errors? Thanks After some days I went back to the problem java eclipse... I don't know why, but now (without updating /usr/ports) I was able to build openjdk6; java/eclipse-devel failed to compile, it was hard using gcc in some stage, USE_GCC=any did no help, only a dirty symlink from gcc -- gcc46 made it happy... and java/eclipse-devel works fine; Thx matthias -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 I submitted a fix for the gcc problem just last week: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/182743 Jimmy ___ 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
Problems building www/webkit-gtk2 after dumping base gcc on 10-CURRENT
Hi all, As part of slogging through the iconv change this last week, I deleted the webkit-gtk2 port (and things that depended on it) to allow a portupgrade -af session to run without taking the ENTIRE weekend. I then went ahead and upgraded the base system which included the removal of the gcc tools. So far, so good... and now to rebuild webkit and those others I had removed. Trying with clang, it errors out looking for ext/atomicity.h in Source/JavaScriptCore/wtf/Atomics.h. No such file anywhere to be found, and with the ifdefs in that file I figured it must have been part of the base gcc stuff. So I installed gcc from the ports, set WITH_GCC=4.4+ and tried again. atomicity.h is now found and away it chugs for a long time. The new result is a linker error about not finding libstdc++, and I'm scratching my head because that file is right there where the gcc port installed it. I did what the gnome-libtool suggested and added a -v to print the full text of the link command being run, and to my suprise it appears that the gnome-libtool is using the system base compiler, not the gcc one as directed by the WITH_GCC option, to do the linking step. Just to be sure, 'make clean' and 'make' again, and watching with ps shows g++/gcc being run to compile the source files, but cc when it hits that linking stage. I'm no expert on libtool/gnome-libtool; anybody have any ideas of what I could do to debug this? Jimmy ___ 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: order of patches under ports/xxx/zzz/files
In article mailpost.1373447036.2906182.1611.mailing.freebsd.po...@freebsd.cs.nctu.edu.tw you wrote: I'm trying to understand exactly how the patches located in files directory in a port apply. For example, port math/metis-edf has under files: # ls files/ medis-patch-Lib_Makefile.txtpatch-Lib::proto.h patch-Test::Makefile patch-CONFIG::configure patch-Lib_Makefile patch-onmetis patch-CONFIG_onmetis.in patch-Programs::Makefile # Patch medis-patch-Lib_Makefile.txt must be applied on top of patch-Lib_Makefile. This does seem to work, but what process makes sure that the order of patch application is exactly that. I can see that it works manually: # cd ./work/metis-edf-4.1/ /usr/ports/math/metis-edf/work/metis-edf-4.1 # patch ../../files/patch-Lib_Makefile Hmm... Looks like a unified diff to me... The text leading up to this was: -- |--- Lib/Makefile.orig 2008-12-03 11:08:03.0 +0100 |+++ Lib/Makefile 2010-05-16 16:33:40.0 +0200 -- Patching file Lib/Makefile using Plan A... Hunk #1 succeeded at 2. Hunk #2 succeeded at 22. done # patch ../../files/medis-patch-Lib_Makefile.txt Hmm... Looks like a unified diff to me... The text leading up to this was: -- |--- Lib/Makefile.intermediate 2013-03-22 20:40:34.429173000 + |+++ Lib/Makefile -- Patching file Lib/Makefile using Plan A... Hunk #1 succeeded at 22. done # and that applying the second patch directly does not work: # cd ../.. # make clean extract === Cleaning for metis-edf-4.1.2_3 === metis-edf-4.1.2_3 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by metis-edf-4.1.2_3 for building === Extracting for metis-edf-4.1.2_3 = SHA256 Checksum OK for aster-full-src-10.8.0-3.noarch.tar.gz. (cd /usr/ports/math/metis-edf/work /usr/bin/tar -xf /usr/ports/math/metis-edf/work/aster-full-src-10.8.0/SRC/metis-edf-4.1-2.noarch.tar.gz --no-same-owner --no-same-permissions) # cd work/metis-edf-4.1/ # patch ../../files/medis-patch-Lib_Makefile.txt Hmm... Looks like a unified diff to me... The text leading up to this was: -- |--- Lib/Makefile.intermediate 2013-03-22 20:40:34.429173000 + |+++ Lib/Makefile -- Patching file Lib/Makefile using Plan A... Hunk #1 failed at 22. 1 out of 1 hunks failed--saving rejects to Lib/Makefile.rej done # But how does the ports environment know the order of patch application? Thanks Anton ___ 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 The application of patches in a ports files directory is done with a for-loop of all files named patch-* (see /usr/ports/Mk/bsd.port.mk), so I imagine the file names would be sorted alphabetically by the wildcard. It is not required, but each patch file generally is meant to patch a specific source file, and the individual sections of a patch file are applied in the order that they appear. If your new patch just adds to the existing patch, you could just concatenate it to the end of the existing patch file, and the patch command will handle the ordering. Jimmy ___ 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: VirtualBox 4.2.14 unusable
On Tue, Jul 09, 2013 at 01:34:59PM +0200, Bernhard Fröhlich wrote: On Mon, Jul 8, 2013 at 11:03 PM, Jimmy Kelley ljboi...@gmail.com wrote: On Mon, Jul 08, 2013 at 10:14:44PM +0400, Mikhail Tsatsenko wrote: 2013/7/8 Jimmy Kelley ljboi...@gmail.com: On Mon, Jul 08, 2013 at 12:40:16PM -0300, Sergio de Almeida Lenzi wrote: Yes it is broken, the logic that finds how much real memory is there in the FreeBSD is broken, reports ZERO.. There is a Problem Report and a person that says will fix it, 2 weeks ago... I am using the last version 4.2.12 that works I am still waiting for the fix... Sergio I did a search on the Freebsd PRs (http://www.freebsd.org/cgi/query-pr-summary.cgi) and cannot find anything that seems to reference this problem. Would you know the PR number? Or was this just some discussion on the mailing list? I'll file an offical PR if there isn't one. Jimmy There is no PR for this problem. As far as I understand memory calculation is still broken on CURRENT. And I suspect it is a build-time not runtime bug. Can anybody who is facing the problem send me a full build log of the virtualbox-ose port from affected machine for investigation please. ___ 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 -- Mikhail Attached is my build log; I'm running 10-CURRENT i386. I see the patch files commited for this problem with VBox 4.2.14 (PR #180086) on my machine, but I have upgraded my ports tree since and have the newer 4.2.16 version that I'm building. Please try the patch from that mail and see if it helps. From the reports it looks reasonable to say that the currently committed patch works only on amd64. So far the reports where it doesn't work are all on i386 and this matches with the description of the fix in the mail. http://lists.freebsd.org/pipermail/svn-ports-all/2013-July/024215.html -- Bernhard Froehlich http://www.bluelife.at/ Thanks for point out that old message. I applied that updated patch and it works now. The code is incorrectly assuming a 64-bit size for querying the hw.physmem sysctl on a 32-bit system. Jimmy ___ 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: VirtualBox 4.2.14 unusable
On Sat, Jul 6, 2013 at 10:40 AM, David Demelier demelier.da...@gmail.comwrote: Hey guys, Are you expecting the same behavior than me on VirtualBox 4.2.14? http://www.demelierdavid.fr/files/VirtualBox-Bug.png I just can't create a new virtual machine :-), Fix for this was done three days ago r321665http://svnweb.freebsd.org/ports/head/emulators/virtualbox-ose/Makefile?revision=321665view=markup. Port is now at 4.2.14_1. Does it still fail for you? I'm seeing the same thing, 10-CURRENT r252987, with r322456 of virtualbox-ose (4.2.16). The Memory size dialog, when trying to create a new virtual machine, shows 0MB for the max, the slider cannot be moved and the text box accepts input but appears to be ignored. Jimmy ___ 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: VirtualBox 4.2.14 unusable
On Mon, Jul 08, 2013 at 05:46:18PM +0400, Mikhail Tsatsenko wrote: 2013/7/8 Jimmy Kelley ljboi...@gmail.com: On Sat, Jul 6, 2013 at 10:40 AM, David Demelier demelier.da...@gmail.comwrote: Hey guys, Are you expecting the same behavior than me on VirtualBox 4.2.14? http://www.demelierdavid.fr/files/VirtualBox-Bug.png I just can't create a new virtual machine :-), Fix for this was done three days ago r321665http://svnweb.freebsd.org/ports/head/emulators/virtualbox-ose/Makefile?revision=321665view=markup. Port is now at 4.2.14_1. Does it still fail for you? I'm seeing the same thing, 10-CURRENT r252987, with r322456 of virtualbox-ose (4.2.16). The Memory size dialog, when trying to create a new virtual machine, shows 0MB for the max, the slider cannot be moved and the text box accepts input but appears to be ignored. It is very strange. Could you please check that top utility shows correct amount of memory. -- Mikhail 2Gb of RAM in my machine, and top reports: 74 processes: 1 running, 73 sleeping CPU: 3.9% user, 0.0% nice, 4.5% system, 0.2% interrupt, 91.3% idle Mem: 949M Active, 110M Inact, 266M Wired, 78M Cache, 96M Buf, 586M Free Swap: 4096M Total, 10M Used, 4086M Free Jimmy ___ 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: VirtualBox 4.2.14 unusable
On Mon, Jul 08, 2013 at 12:40:16PM -0300, Sergio de Almeida Lenzi wrote: Yes it is broken, the logic that finds how much real memory is there in the FreeBSD is broken, reports ZERO.. There is a Problem Report and a person that says will fix it, 2 weeks ago... I am using the last version 4.2.12 that works I am still waiting for the fix... Sergio I did a search on the Freebsd PRs (http://www.freebsd.org/cgi/query-pr-summary.cgi) and cannot find anything that seems to reference this problem. Would you know the PR number? Or was this just some discussion on the mailing list? I'll file an offical PR if there isn't one. Jimmy ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why was the ventrilo-server port removed?
On Wed, Jun 05, 2013 at 09:40:59AM -0700, Anton Afanasyev wrote: On Wed, Jun 5, 2013 at 5:25 AM, Bob Willcox b...@immure.com wrote: I'd be willing to. I don't think anything for it has changed. The distfile is still available at the same location. I still run it and don't see any issues with it. It looks like the port was deprecated because no more public distfiles: http://portsmon.freebsd.org/portoverview.py?category=audioportname=ventrilo-server Anton As Bob pointed out, the distfile IS freely available, just not directly without agreeing to the download terms. The old diablo JDK ports were like this. I can see the reason for the automated ports system marking this a deprecated, since it can't tell the difference between a truely missing distfile vs. one that requires manual intervention. Is there something that can reset the deprecation countdown timer is cases like 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: fetch: expansion of correct source location in MASTER_SITES fails
On Sat, Jun 01, 2013 at 02:47:18PM +0200, O. Hartmann wrote:
On Sat, 01 Jun 2013 11:48:37 +
Steve Wills st...@mouf.net wrote:
On 06/01/13 11:17, O. Hartmann wrote:
I'm preparing a port and I fail downloading the sources, although
the base URL and the target tar ball are expanded correctly. But
the fetch process then complains with this:
[...]
=== pocl-0.8.0 depends on file: /usr/local/sbin/pkg - found
= pocl-0.8rc1.tar.gz doesn't seem to exist
in /usr/ports/distfiles/. = Attempting to fetch
http://sourceforge.net/projects/pocl/files/pocl-0.8rc1.tar.gz fetch:
http://sourceforge.net/projects/pocl/files/pocl-0.8rc1.tar.gz: Moved
Temporarily
If one the takes the error line named
fetch http://sourceforge.net/projects/pocl/files/pocl-0.8rc1.tar.gz
and issue it directly on the console, surprisingly the the fetch
works! This is weird.
What is wrong here? Is this a bug in fetch?
Nothing is wrong here. The = Attempting... line is not trying to
tell you what command it is running, but rather what it is doing.
This result is perfectly normal due to the default args that ports
pass to fetch. See bsd.port.mk:
2214 FETCH_ARGS?=-AFpr
The fetch man page will explain these further.
For Sourceforge, there is a SF macro in bsd.sites.mk which you
should use so that users will try the various mirrors. Many ports use
this, so there are many examples to follow.
Steve
Thank you for clearify this.
Even if I use the SF macro and set FETCH_ARGS= to en ampty string (I
suppose this will result in a plain fetch command without options)
the result is as described intially.
Applying the -v option to fetch then shows what happens and everything
looks fine to me so far - except that the Makefile-Port-Fetch doesn't
work. This is strange!
The SF macro used with nothing else expects the project on Sourceforge to be
layed out with subdirectories corresponding to the PORTVERSION, which then would
contain the file to be downloaded.
If you use SF/${PORTNAME} for MASTER_SITES, it will fetch the file
${PORTNAME}-${PORTVERSION}.tar.gz from the top-level download directory.
The -A fetch option for ports is something you do not want to ignore: always
go straight to a file location, and don't trust something telling you that
it has moved...
Jimmy
___
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
