Re: List of packages upgraded last time `pkg upgrade` was executed
On Wed, Jan 27, 2021 at 10:57:22AM +0900, Yasuhiro Kimura wrote: > From: Freddie Cash > Subject: Re: List of packages upgraded last time `pkg upgrade` was executed > Date: Tue, 26 Jan 2021 17:26:29 -0800 > > > /var/log/messages and I think /var/log/daemon include the output of the pkg > > commands. If you have the log files backed up from the last time it was > > run, you could grep for pkg in those. > > > > No idea if this info is also stored in the sqlite databases pkg uses. > > Thank you for reply. But my intention is to write shell script that > gets the list of upgraded packages and does something by using > it. Because of that the list need to be gotton without any user > interaction. So unfortunately your method is not applicable to my > case. Well, there is the option of running a pkg query before and after the upgrade and comparing the results... especially if you write it in a higher-level language than the shell, it Should Not Be Too Hard(tm) to figure out which packages have changed their version, what new ones have appeared, which ones have been removed... But, yeah, it is certainly easy for me to suggest that somebody else write something "simple" :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Dropping maintainership of my Ports
On Sat, Mar 28, 2020 at 07:25:32PM +0100, Mateusz Piotrowski wrote: > On 3/28/20 5:33 PM, Peter Pentchev wrote: > > On Fri, Mar 27, 2020 at 05:35:44PM -0700, Neel Chauhan wrote: > > > Hi freebsd-ports@, > > > > > > I would like to drop maintainership for the following Ports: > Thanks, Neel! > > [snip] > > > net/librsync2 > > > sysutils/ioping > > > sysutils/pick > > Hi, > > > > If no one has already stepped up, I'd like to try my hand at maintaining > > these three as a way of tentatively slowly coming back to FreeBSD. > > Sure! Could you submit appropriate patches to bugzilla? Bah, nevermind, people beat me to it for all three :) No worries :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Dropping maintainership of my Ports
On Fri, Mar 27, 2020 at 05:35:44PM -0700, Neel Chauhan wrote: > Hi freebsd-ports@, > > I would like to drop maintainership for the following Ports: > [snip] > net/librsync2 > sysutils/ioping > sysutils/pick Hi, If no one has already stepped up, I'd like to try my hand at maintaining these three as a way of tentatively slowly coming back to FreeBSD. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: GSoC: Separation of Ports Build Process from Local Installation
On Tue, May 28, 2019 at 08:28:41PM -0700, Rodney W. Grimes wrote:
> [ Charset UTF-8 unsupported, converting... ]
> > Hello All,
> >
> > For Google Summer of Code 2019 I am working on FreeBSD's ports tree
> > makefiles towards eliminating the dependency of the ports building
> > process on the local system's installed packages.? Currently this level
> > of separation can only be accomplished in practice through chroot or
> > Jail.? The project will eliminate the need for cooperation of the root
> > user since /usr/local will not need to be touched.
> >
> > The major technical obstacle to be overcome is that ports expect to find
> > files of their dependencies installed in /usr/local.? To support this
> > without touching that location on the installed system, file accesses
> > will be redirected to a location controlled by the ports build process
> > through use of a library to intercept file accesses.
>
> Assumption of /usr/local was considered wrong long long ago and it
> should always be ${PREFIX}. Any place that actually assumes this
> value to be /usr/local should be fixed.
>
> Had this policy been properly maintained it would simply be a mater
> of changing ${PREFIX} to a new and empty place before starting
> a ports build and things should of just worked.
>
> Restoration to this ancient and functional behavior is desirable
> at least on my part.
Hmm, I could be wrong, but isn't ${LOCALBASE} supposed to be where
ports find stuff *during the build*, and ${PREFIX} where they
install the built files? Of course, I haven't actually touched
a FreeBSD ports build in years, so I might very likely be wrong.
I also seem to remember a series of test port builds done a long
time ago with a different value for LOCALBASE, specifically to catch
ports that do not honor the policy in this regard.
> > Once I have that working (well enough to build one port at a time) I
> > will move on to modify bsd.port.mk itself (and related files) to utilize
> > this mechanism for virtual installation of port dependencies during builds.
> >
> > The full project proposal can be seen at
> > https://docs.google.com/document/d/1B30U9csgY299W59tNraSX1LYjzsba2i04OrYAUpdIZs/edit
> >
> > .
> >
> > My goal is that this work can be integrated well enough into
> > /usr/ports/Mk so that unlike Jail, no set up work should be required for
> > using ports tree to build a set of installable packages.
> >
> > Please let me know if you are interested in this project; feedback is
> > appreciated.? If someone would like to provide ongoing feedback or
> > mentorship that would be especially helpful.? Bakul Shah is my mentor
> > officially for GSoC but I would be happy to have additional support from
> > someone who is experienced with internals of the port infrastructure
> > makefiles.
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Re: www/joomla3 port installs from GitHub, why?
On Sun, May 20, 2018 at 04:49:34PM -0700, Dan Mahoney (Gushi) wrote:
> On Sun, 20 May 2018, Per olof Ljungmark wrote:
>
> > On 05/20/18 21:15, Eugene Grosbein wrote:
> > > 21.05.2018 2:02, Per olof Ljungmark wrote:
>
> > OK, I'll try to explain a bit more.
> >
> > Firstly, this port is PHP code and needs no compilation, so they are
> > both source files. NO_BUILD= yes
> >
> > www/wordpress is a similar port, correctly implemented in the ports
> > tree, if you install it from ports you will have identical result to
> > downloading from wordpress.org and extract it manually.
> >
> > The difference as stated above, is that the FreeBSD port includes the
> > files for *development* of Joomla, the official download has all the
> > files necessay to build a website based on Joomla.
> >
> > It may be that there are people using FreeBSD to develop Joomla, then of
> > course this port are for them, although a more proper naming would be
> > joomla3-devel or somesuch.
>
> joomla-devel would kind of imply that you're installing the "devel" version
> of it, not that it includes the devel LIBS. This seems to be a standard
> wording for ports (see locate /usr/ports/ | grep \\\-devel | grep pkg-descr
> | xargs cat )
>
> What makes more sense to me is that the Dev files would be part of a
> non-default option -- whether that's included with the normal .tar.gz or
> requires the github copy, I can't say.
>
> I don't know if there's a *canonical* naming that universally means this is
> what '-devel' means.
Errr, ICBW (one needs to look at the history of the port), but in
FreeBSD a -devel version of the port is usually created when somebody
wants to be able to install a version that is currently under
development and yet keep the ability for normal users to use the stable
version. In these cases, a second port is created (once upon a time
this was done by a repository copy to preserve the port's history) that
is exactly the same as the first one, and then the port maintainer
updates the second port (the -devel one) to a newer version.
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Re: poudriere, Go and networking
On Fri, Dec 11, 2015 at 03:55:22PM +, Malcolm Matalka wrote: > Piotr Florczyk <piotr.florc...@gemius.com> writes: > > > W dniu 11.12.2015 o 15:36, Kurt Jaeger pisze: > >> Hi! > >> > >>> Recently I had to package couple of programs written in Go and godep is > >>> becoming the standard for dependency tracking in Go projects. > >>> For example I currently had to package telegraf. Here is the thing. > >>> Poudriere > >>> disables networking after fetch phase and I don't know before extract > >>> phase what dependencies are inside. > >> > >> We recently upgraded maven, the java-world 'make and godep' and all > >> the ports that need maven to build have the same problem, see: > >> > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188110#c37 > >> > >>> So here is the question: would it be possible to have networking > >>> enabled during extract phase ? > >>> Or maybe there is another solution (some flag in ports maybe that > >>> I'm missing ?) > >> > >> I think we need some fancy fetch target per distfile which basically > >> uses technology-dependend (maven, godep, etc) ways to trigger > >> the 'fetch' during the fetch-phase. Probably some sort > >> of base-fetch vrs. dep-fetch ? > >> > > New target might not be needed but I think this is good idea. Altough it > > does not solve my problem with poudriere. In my case, the soonest I > > can fetch dependencies is in post-extract target. So if poudriere didn't > > cut off networking at this stage we wouldn't need any changes and > > every one would be happy. > > This sounds like it would be a security hole to let a package download > extra things that the FreeBSD package system does not know about and > cannot validate. FWIW, this is my personal opinion, too. The FreeBSD Ports Collection is supposed to be self-sufficient: - anything a port needs should be available as, well, another port - any changes to what a port needs should be vetted by the maintainer at the time of updating the port - anybody should, at any time, be able to find out what a port depends on and what other ports depend on it using only "static" information from the ports tree That last point is pretty important for people who maintain ports of libraries or other widely-used software: sometimes, when preparing an update to a new upstream version with important changes, it is very nice to be able to test by yourself if these changes will break other ports that depend on yours (or, of course, drop an e-mail to the maintainers of these other ports saying "hey, here's a proposed update to my port, could you check if it'll break yours?"). > > Even if we come up with proper solution it will require cutting off network > > at some later stage than post-extract. In my opinion we might > > aswell move it to that point right now. > > Perhaps you should make a tool which takes a go project as input and a > FreeBSD package as output? This sounds like the way to go. The Debian Perl group has a tool that goes by many names, but in at least one of its incarnations, cpan2deb, it does exactly that - downloads a package from the CPAN archive, examines its metadata files to find out what it needs, looks for these dependencies in the Debian package archive, and outputs a skeleton of a package that has these dependencies listed in the proper fields. Of course, it may also do this later, after the package has been updated and its dependencies have changed. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: DESTDIR support broken?
On Fri, Nov 22, 2013 at 02:02:28PM +0100, Dominic Fandrey wrote: On 19/11/2013 18:44, Dominic Fandrey wrote: On 18/11/2013 20:28, Kimmo Paasiala wrote: On Mon, Nov 18, 2013 at 10:05 AM, Dominic Fandrey kamik...@bsdforen.de wrote: On 18/11/2013 04:10, Eitan Adler wrote: On Thu, Nov 14, 2013 at 1:00 PM, Dominic Fandrey kamik...@bsdforen.de wrote: # make DESTDIR=/root/tmpdest install === Creating some important subdirectories Are you sure you don't mean make PREFIX=/root/tmpdest/ ? Yes. -- I would expect DESTDIR=/some/path just work for any port. Last commit to bsd.destdir was over a year ago so either it has been broken for a long time or some other more recent commit has broken it. /root/tmpdest is a complete FreeBSD chroot (I did a make installworld distribution DESTDIR=/root/tmpdest right beforehand). I tried several ports, they all exhibit the same failure. The issue is that BSD make (in stable/10) passes set -e to the shell by default. I submitted the details and a fix: http://www.freebsd.org/cgi/query-pr.cgi?pr=184170 Hmm, even if this is so, I wonder if there would not be another funny problem later: for ports that actually use staging, bsd.stage.mk tries to pass a DESTDIR of its own to upstream's build system, so the DESTDIR specified on the make(1) command line might not be passed to upstream's build system at all. So bsd.destdir.mk might do its thing, but then bsd.stage.mk would override the DESTDIR setting during the actual build and installation of the upstream sources, so I wonder if anything at all would be installed into the chroot. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 If this sentence were in Chinese, it would say something else. signature.asc Description: Digital signature
Re: Staging DOs DON'Ts
On Thu, Oct 31, 2013 at 10:30:03AM +0200, Kimmo Paasiala wrote:
Could we have this as an example what not to in the Makefile. It is
from the latest change to the Makefile of sysutils/kiconvtool.
MAKE_ARGS= PREFIX=${STAGEDIR}${PREFIX}
This breaks stuff that edits scripts in place trying to replace paths
that depend on the value of PREFIX.
The proper way to do this - and the way it's done on other OSs and other
packaging systems that have the staging directory feature - is to:
1. Pass ${STAGEDIR} as a separate build option to the actual build;
it's traditional to pass it as the DESTDIR option:
MAKE_ARGS+= DESTDIR=${STAGEDIR}
2. Make sure that the actual build honors DESTDIR. Yes, this does mean
that in some cases you have to patch the upstream build system; please
do this, and please forward the patches to the upstream authors, so
that their piece of software builds properly everywhere and is that
much easier to package for everyone :)
Yes, this does involve a bit more work for the port maintainer in cases
when the upstream build system is not yet DESTDIR-aware. Yes, this is
actually a good thing, this is practically an omission of the upstream
authors that will be corrected sooner or later by somebody, either
the FreeBSD port maintainer or some other packager :)
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
If you think this sentence is confusing, then change one pig.
signature.asc
Description: Digital signature
Re: non-destructive ports/packages update
On Sat, Apr 20, 2013 at 06:03:17PM -0700, Perry Hutchison wrote: Xin Li delp...@delphij.net wrote: On 4/19/13 11:34 PM, Perry Hutchison wrote: I'm looking for a way to move everything connected with ports and packages aside, so that I can start fresh but with the ability to easily roll it back when things go badly (as they surely will). I have in mind to something like this: # cd /usr # mkdir old # mv ports local old # mkdir ports local # cd /var/db # mkdir old # mv ports pkg old # mkdir ports pkg Is there anything else that needs to be saved before fetching a new ports tree and starting to build things (or install prebuilt packages)? If you use ZFS, it's possible to take snapshot, then install new ports, then if something blows up, you can rollback. With UFS, it's still possible to take snapshot but rollback is not atomic. I'm aware of filesystem snapshots, but I only want to checkpoint the ports and packages, not the whole filesystem -- a rollback needs to be fast, easy, and obviously correct; preserve the failure logs; and not undo changes that may have been made elsewhere in the meantime. (BTW I don't use ZFS: the machine doesn't have enough memory, and to me ZFS -- especially on 8.x -- doesn't yet seem sufficiently proven.) If you use portmaster, it can save packages (I think portupgrade can do it too). But this approach depends on the fact that the port is well written, and is not atomic in terms of package set. And then a rollback requires re-installing the saved packages, which is surely slower than moving a few directories and/or files around. The question is, what (if anything) else -- besides /usr/ports, /usr/local, /var/db/ports, and /var/db/pkg -- needs to be checkpointed? Some ports might store run state in /var/db/portname or a similarly named directory. The thing is, the decision whether to save this and restore it or to keep it across runs actually depends on the port: for database management systems such as MySQL, PostgreSQL, etc, you'll probably want to keep the databases even if the ports themselves are reinstalled, rolled back, restored, whatever. For some other systems, you might want to remove the current state information of the version that you are about to replace. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 Thit sentence is not self-referential because thit is not a word. signature.asc Description: Digital signature
Re: Ports should provide knobs disabling unwanted network services
On Tue, Mar 26, 2013 at 09:13:38AM +0100, Florent Peterschmitt wrote: Le 25/03/2013 04:40, Scot Hetzel a écrit : On Sun, Mar 24, 2013 at 10:33 PM, Florent Peterschmitt flor...@peterschmitt.fr wrote: Le 24/03/2013 17:34, Scot Hetzel a écrit : On Sun, Mar 24, 2013 at 7:00 AM, Beeblebrox zap...@berentweb.com wrote: I would be very happy to submit a patch, if I actually knew how to write one... It is quite simple to create the patch. If you have a working copy checked out with svn, then it would be: cd /usr/ports/[category]/[port] - Make the necessary changes to the port - After testing the port make sure to do a 'make clean' svn diff port.diff Otherwise make a copy of the port: cd /usr/ports/[catagory] cp port port-orig cd port - Make the necessary changes to port - After testing port make sure to do a 'make clean' cd .. diff -ruN port-orig port port.diff Then just submit the port.diff in a PR using either send-pr or http://www.freebsd.org/send-pr.html. Is there a way to manually make a patch that will say : --- MyFile +++ MyFile Even if these files are in two distinct trees ? There is always a way to do that: diff -u /path/to/original/port/MyFile /path/to/modified/port/MyFile /place/to/save/patch/port.diff or if you modifed several files: diff -ruN /path/to/original/port /path/to/modified/port /place/to/save/patch/port.diff Hum yes but what I mean is that we'll have, for example: --- /home/florent-gentoo/patch/old/one2013-03-24 14:04:20.757200724 +0100 +++ /home/florent-gentoo/patch/new/one2013-03-24 14:04:08.541201548 +0100 […] And what I want is: --- /home/florent-gentoo/patch/old/one2013-03-24 14:04:20.757200724 +0100 +++ /home/florent-gentoo/patch/old/one2013-03-24 14:04:08.541201548 +0100 […] SCM make patches like the second one and I'm no sure it is possible to do without modifying by hand the patch generated. Well, one way to do it would be to actually *use* an SCM :) My preferred way would be a Git copy of the Subversion repository - then you do your changes in your local Git tree and periodically pull down the changes from the FreeBSD Subversion repo and merge them into yours. But really, is there actually a reason why you don't want two separate directories? To be honest, before the advent of Subversion and Git everyone did their patches that way (well, there *were* local CVS repositories and checkouts from there, but most of the patches were diffs between two side-by-side directories) - and I don't think anyone ever complained. Are there any problems you are seeing with two paths in the diff headers, or is it just aesthetic? G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 I am jealous of the first word in this sentence. signature.asc Description: Digital signature
Re: Unable to install new dialog for ports on FreeBsd 7.0
On Thu, Mar 21, 2013 at 11:02:33AM +0300, Sergey V. Dyatko wrote: On Thu, 21 Mar 2013 08:56:34 +0100 Baptiste Daroussin b...@freebsd.org wrote: On Thu, Mar 21, 2013 at 11:39:07AM +0530, Vikas Mahajan wrote: Hi all, After updating portsnap I tried to install php5. Now make config fails with following error: === Building for dialog4ports-0.1 Warning: Object directory not changed from original /usr/ports/ports-mgmt/dialog4ports/wor k/dialog4ports-0.1 cc -O2 -fno-strict-aliasing -pipe -I/usr/ports/ports-mgmt/dialog4ports/work/dialog-1.1-20 120706 -D_XOPEN_SOURCE_EXTENDED -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unu sed-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -o dialog4ports dialog4ports.o mixedlist.o arrows.o buttons.o dlg_keys. o help.o inputstr.o mouse.o mousewget.o textbox.o rc.o trace.o ui_getc.o util.o version.o -lncursesw util.o(.text+0x2e02): In function `dlg_auto_size': : undefined reference to `sqrt' *** Error code 1 1 error *** Error code 1 Stop in /usr/ports/ports-mgmt/dialog4ports. If I set NO_DIALOG=yes in /etc/make.conf, I am getting: === Skipping 'config' as NO_DIALOG is defined How can solve this problem? Any way to fix this error or using old make config dialog. Please help. Try replacing the ports-mgmt/pkg/files/patch-Makefile by this one: http://people.freebsd.org/~bapt/patch-Makefile And tell me if it works. But please notice that 7.x is EOLed 28 feb, more and more the ports tree will get incompatible, and if we want to follow the direction for FreeBSD 10 (replace our make by bmake) we will need to a day or another break totally compatibility with 7. Consider upgrading your boxes. but ports/tags/RELEASE_7_EOL will not be broken for 7.x ? It cannot be broken, since it is not going to change. It's a tag, not a branch. A tag is a snapshot of the tree at a specific point in time, mainly for reference purposes later. A branch is a copy of the main part of the tree (the trunk, which also happens to be a branch, even if the main one) that can - and probably will - be updated by further commits. RELEASE_7_EOL is just a snapshot of the last version of the ports tree that was guaranteed to work with FreeBSD 7.x. It is not suitable as a csup/cvsup/svn up target - once you check it out, there is absolutely no point in updating to it later, since it is not going to ever change. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 This sentence was in the past tense. signature.asc Description: Digital signature
Re: ports include /etc/src.conf? i.e. graphics/libfpx
On Thu, Feb 14, 2013 at 01:55:58PM +, Tom Evans wrote: On Thu, Feb 14, 2013 at 1:12 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: I may sound defensive here, but I'll still repeat, that this singular port (and I do, in fact, have other ones like it) started using bsd.lib.mk 5 years before src.conf (and its man-page) was added to the tree. -mi This is true. But what is the bug, that the port's Makefile.bsd was not updated on the introduction of src.conf to DTRT (and no-one noticed for 7 years), or that the purpose of src.conf has been mistakenly documented for 7 years? To be brutally honest, and at some cost to myself, I would have to say both :( There are some people - and some of them are well-respected long-term Free-and-other-BSD developers - who are of the opinion that the /usr/share/mk/bsd.*.mk infrastructure is meant for the base system build only. I do indeed understand this point of view - and from this point of view, the port's Makefile.bsd is buggy because it allegedly abuses internal parts of the base system. At the same time (see the last paragraph) I do quite understand the other point of view - that FreeBSD is not merely an operating system or a combination of an operating system and third-party software adapted to work on it consistently, but that it is a software distribution (what, after all, does BSD mean? :). Hence, its source code is meant to be adopted, adapted and used in everyone's software projects when everyone feels like it (under the conditions of the respective licenses, of course). If this is taken to mean that if we have bsd.*.mk, we are free to use it, then it will turn out that bsd.*.mk is not really an internal part of the base system, and that the documentation for src.conf maybe ought to mention that the settings there may affect the build of third-party programs that use the bsd.*.mk infrastructure (and of course there would be no way to list all such programs). However... However, there is then the argument of well, if you want to use the bsd.*.mk infrastructure, then why don't you just copy it into your project and include it from there - just like many, many projects do with, say, the sys/queue.h header, or parts of libc, or whatever? And it is, indeed, a very good argument, since this is how a software distribution's parts are supposed to be used - you copy them into your project and use them even when they are not available on the host system. So one might argue that the port is, indeed, buggy, that the src.conf documentation is, indeed, correct, and that the proper way for people to use the bsd.*.mk infrastructure in their own projects is to take a snapshot, remove the include /etc/rc.conf part, change the include statements to be relative to the current directory or something, and then include the bsd.*.mk files from their own project's source directory. I'm not sure if there are any projects that actually do that, but IMHO this is the correct way to do it :) Now, in this particular case, we have a slightly different situation when the code that uses the bsd.*.mk infrastructure is not part of the upstream software source code, but is part of the FreeBSD port - that is, it is supposed to work mostly on FreeBSD, and the port is supposed to keep up with the times and work around any incompatible bsd.*.mk changes. So... with all due respect to Mikhail, I do believe that in this case the port's Makefile.bsd ought to add the without src.conf definition before including the bsd.*.mk parts. The at some cost to myself part at the start of this message is because some of my released software uses the bsd.prog.mk/bsd.lib.mk infrastructure, with the unspoken assumption that I'll update it when the bsd.*.mk infrastructure changes in incompatible ways (this has not really happened for the past twelve years, mostly because my Makefiles do not try to use NO_MAN or similar options - they define everything they need, and it is not a whole lot :) So... yeah, I've been lazy, and yeah, some weird src.conf settings might confuse the build of some of my software on FreeBSD. And, of course, my software might very well not build at all on other BSD-like host platforms. But... yeah, well, I've been lazy ;) ...thanks for reading so far, I guess :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 When you are not looking at it, this sentence is in Spanish. signature.asc Description: Digital signature
Re: [PKGNG] where I can find $ABI?
On Mon, Jan 21, 2013 at 07:13:34PM +0400, Alex Keda wrote:
21.01.2013 17:29, Baptiste Daroussin пишет:
On Mon, Jan 21, 2013 at 05:08:09PM +0400, Alex Keda wrote:
I create my own repository.
but, $ABI I create as:
v1=`uname -s | tr [:upper:] [:lower:]`
v2=`uname -r | awk -F '.' '{print $1}'`
v3=x86
v4=`sysctl -n hw.machine_arch | tr -d [:alpha:]`
ABI=$v1:$v2:$v3:$v4
(for example)
may be add some key to pkg command, for output pkg_get_myabi() result?
okg -vv should output you ABI
If you want to get the information out of a package pkg info -fF mypkg.txz |
grep ^arch: Should output the ABI for you
regards,
Bapt
OK, thanks
pkg -vv | grep abi | awk '{print $2}'
With the risk of this disintegrating into yet another round of Perl
Golf, you do realize that there is almost never a reason to use grep and
awk one after the other, right? :)
pkg -vv | awk '$1 == abi: {print $2}'
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
I am the thought you are now thinking.
signature.asc
Description: Digital signature
Re: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)
On Wed, Dec 12, 2012 at 09:38:29AM +0100, Alex Dupre wrote: Kurt Jaeger ha scritto: I have a few question about what happens if you always use this flag: * Do you keep every version of the shlibs you ever built on your system? No, only those that still needed. * Are there any method to clean the unused ones? sysutils/libchk or pkg_libchk from sysutils/bsdadminscripts. Uh? One of the two: 1) it keeps all versions and you need to clean them up 2) it keeps only needed and so you shouldn't clean up The correct answer is 1) I think that Kurt answered the question Do you - you personally - keep every version of the shlibs you ever built, as opposed to somehow - not necessarily automagically on port installation/upgrade or periodically - clean up the unused ones :) You are correct that the original question was probably meant to differentiate between the two options you listed. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 This would easier understand fewer had omitted. signature.asc Description: Digital signature
Re: FreeBSD ports you maintain which are out of date
On Wed, Nov 28, 2012 at 09:06:59PM +0200, Alexander Yerenkow wrote: 2012/11/28 Kevin Oberman kob6...@gmail.com On Wed, Nov 28, 2012 at 7:45 AM, Alexander Yerenkow yeren...@gmail.com wrote: In that case, near each port should be.mntr contact mentioned, to.make it easier for anyone to contact mntr immediately, instead making additional unnecessary steps. I suspect that you are missing the fact that all ports which lack a specific maintainer (most of them) are maintained by ports@. So the messages to ports are only for the vast array of ports that are unmaintained. There is no one else to contact. Ideally, if someone has a little free time, they can look at the list and pick a couple to update and submit the update in a PR to ports with a category of update. Or even better, become the maintainer, yourself. I have been maintainer for a couple of ports that were critical to my work, so I could be sure that they would be updated promptly. Not exactly :) My suggestion about including current maintainer contact info was about this part of discussion: Probably more to the point is that it shouldn't get sent to the ports mailing list - just to port maintainers. Did you ever think that sending it to the list might motivate someone else to take over the port? There's a reason ports get out of date. One of the reasons is because the port maintainer has lost interest or no longer has the time. If people on the list see it, someone who is motivated might update the port and end up being its new maintainer. So, my thought was, if you ever came to sending portscout messages with alive maintainer to all ports@ list, would be nice to see contacts immediately. You could learn that some maintainer is inactive last time, and next time you see update for his port, you could get it to work. Something like that. But this is exactly the point - portscout *only* sends messages to the e-mail address listed in the port's MAINTAINER line. If portscout's message goes to the po...@freebsd.org list, then there *is* no active maintainer - what Paul means is that the maintainer has lost interest (or the ability / resources / time to work on the port) and somebody has reset the port's maintainership to po...@freebsd.org. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 If I had finished this sentence, signature.asc Description: Digital signature
Re: do I need to specify explicity what to install for make install to work?
On Wed, Sep 26, 2012 at 03:12:39PM +0100, Anton Shterenlikht wrote:
From m.sea...@infracaninophile.co.uk Wed Sep 26 14:21:51 2012
On 26/09/2012 13:06, Anton Shterenlikht wrote:
I was updating my port until I got to
make: don't know how to make install. Stop
*** [do-install] Error code 2
and I realised that I don't really understand
the sequence of commands involved in make install.
I've looked through the porter's handbook,
but still not clear.
I see lots of post-install targets in
Makefiles, but never just install.
I presume it should be pulled into by
.include bsd.port.mk
Still, if I have a set of source files,
generated object files, and just one
executable I want to install, I probably
have to specify somewhere in the Makefile
the name of this executable, right?
Or are PLIST_FILES and PLIST_DIRS used
to let make know what to install?
The ports 'make install' generally does one of two things: either it
runs appropriate make install commands from $WRKDIR -- ie. what the
ported software provides itself -- or it has a list of files,
directories etc. from within $WRKDIR which it copies into place itself,
which is usually only done if the ported software doesn't provide its
own installation routines. As I recall, if you don't provide an
explicit install target yourself, the default is to run 'make install'
from $WRKDIR.
PLIST_FILES, PLIST_DOCS or the pkg-plist file don't tell the ports what
to install. Instead, they document what the installation process should
be installing, and so what files to include in a pkg tarball and what to
delete at pkg deinstallation time. Hence the effort required to make
sure your plist is accurate.
Ok, I think I get it.
All I need is the install target
in $WRKDIR/Makefile.
If I make this target empty, then
I can add the real install commands
under post-install in the port's
Makefile.
However, it seems if there is no
install target in $WRKDIR/Makefile,
then I must add install target to
port's Makefile.
Actually, since the install target in bsd.port.mk does a lot of other
things (generating/handling package lists, registering the package
installation, etc), what you need to override is the do-install
target (in the port's Makefile). For the upstream's Makefile (the one
in $WRKSRC) it is the install target that is looked for.
This is true for almost all of the high-level bsd.port.mk targets (the
ones that the user invokes with make in the port's directory) -
bsd.port.mk does some magic, determines whether anything needs to be
done at all, and if there is indeed a need to do something, it invokes
the do-* target. Thus, if bsd.port.mk determines that it needs to
fetch an upstream tarball, it will invoke the do-fetch target that, by
default, tries to fetch ${DISTFILES} from ${MASTER_SITE} and so on. If
it determines that it needs to build a program, it invokes the
do-build target that, by default, goes into ${WRKSRC} and does make
all (but of course, you can also override the all part using another
variable). For the install target, if bsd.port.mk determines that it
needs to install the already-built-in-${WRKSRC} files to ${PREFIX}, it
will invoke do-install; if you don't override do-install, it will
change into ${WRKSRC} and run make install - and then it will go on
with the rest of what the install bsd.port.mk target does.
In general, you don't really need to do this very often - most of what
you might need to do in the do-* targets is already configurable by
other variables. I guess that's why nobody felt the need to document
this in the Porter's Handbook so far :)
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
.siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI
signature.asc
Description: Digital signature
Re: Re-starting daemons across upgrades?
On Sat, Sep 17, 2011 at 11:08:46AM +0200, Matthias Andree wrote: Am 16.09.2011 22:00, schrieb Gabor Kovesdan: On 2011.09.16. 17:51, Matthias Andree wrote: Am 16.09.2011 11:51, schrieb Lev Serebryakov: Hello, Freebsd-ports. You wrote 16 сентября 2011 г., 0:28:07: Really? I thought it was supposed to be standard behaviour- the @stopdaemon line in pkg-plist facilitates that. While I totally understand why we do this, I have to say it's VERY VERY annoying behavior especially when one upgrading a remote system with multiple server daemon ports. One have to watch the whole process carefully and restart the daemon manually. Yep, and even more annoyingly is that it is completely inconsistent: some daemons are stopped, some not, etc. We do not currently have a standard procedure for that, nor do we record the necessary state -- perhaps we should just discuss, vote, and add a paragraph to the porter's handbook. We also need to bring the authors (or volunteers) for the de-facto standard upgrade tools into the loop. My thoughts: - give the user a choice to configure whether to restart services - optional: give the users a chance to configure this per-service - discuss whether we want/need to support this (a) in the framework that we currently use, (b) only in pkgng, (c) in portmaster and portupgrade where necessary. Or we could have a facility to check whether services are running. For example, I have some cron scripts, which are similar for all of the services that I'm watching. They run periodically and restart services if they are down. It does not matter if they are down because of an upgrade or a failure, so this solution is more general. Here's an example that I have for MySQL: Before we go that way, we should consider using runit by Gerrit Pape (smarden.org), Upstart, or port systemd. Or (bet you didn't expect that from a hardcore daemontools user like me ;) our own FreeBSD Services Control - http://people.FreeBSD.org/~trhodes/fsc/ (once it's ready to enter the tree) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 because I didn't think of a good beginning of it. signature.asc Description: Digital signature
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
On Sun, Sep 11, 2011 at 01:01:31PM +0400, Lev Serebryakov wrote: Hello, Perryh. You wrote 11 сентября 2011 г., 10:05:59: I can't address the non-specific etc, but I would claim that each of those 3 specific examples is a VCS bug. Creating a tarball of a particular content set _should_ be a deterministic process: Once again: gzip, for example, has timestamp field in header. Try this locally, without any [D]VCS: % mkdir test echo one test/one.txt echo two test/two.txt % tar czf test1.tar.gz test sleep 5 tar czf test2.tar.gz test % md5 test1.tar.gz test2.tar.gz MD5 (test1.tar.gz) = 7b7c763a9d1d4edca7b5b415ab297fec MD5 (test2.tar.gz) = 703ac5387b2bd1146434516f1d761ed9 % gzip -d test1.tar.gz test2.tar.gz % md5 test1.tar test2.tar MD5 (test1.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 MD5 (test2.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 % Now try the same with the -n option :) (and yes, I realize that you are probably aware of this, but so should any author of a system that automatically creates compressed tarballs out of not-ridigly-structured data) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 No language can express every thought unambiguously, least of all this one. signature.asc Description: Digital signature
Re: porter handbook MASTER_SITES section outdated?
On Mon, Aug 01, 2011 at 10:42:13AM -0400, b. f. wrote:
In sec 5.4.2 MASTER_SITES in the porter handbook:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html#AEN1512
the example given is:
MASTER_SITES= ${MASTER_SITE_GNU}
However, sunpoet@ has just committed my patch
changing my ${IGNORE_MASTER_SITE_XCONTRIB} and
${MASTER_SITE_LOCAL} to:
MASTER_SITES= XCONTRIB/applications \
http://seis.bris.ac.uk/~mexas/ \
LOCAL/simon
Are both forms acceptable? Or is the form
given in the porters handbook outdated?
Yes. No. He is just making use of an abbreviation that is translated
into the full urls by the macros at the end of ports/Mk/bsd.sites.mk.
You can do the same in your own submissions, but you should check that
they actually work by using make fetch-urlall-list or the like.
...and (not or! :) also by using the ports-mgmt/distilator port.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
I had to translate this sentence into English because I could not read the
original Sanskrit.
signature.asc
Description: Digital signature
Re: patch for force fetch
On Mon, May 16, 2011 at 10:14:11AM +0200, David Demelier wrote: On 16/05/2011 09:02, Andriy Gapon wrote: I've noticed the following problem. If a distfile is updated by a distributor without renaming it (so that checksum and possibly size change), then more often than not the port build system would fail to fetch the distfile. An example: ... = SHA256 Checksum mismatch for eclipse/javax.servlet.jsp_2.0.0.v200806031607.jar. ... = javax.servlet.jsp_2.0.0.v200806031607.jar doesn't seem to exist in /usr/ports/distfiles/eclipse. = Attempting to fetch http://download.eclipse.org/tools/orbit/downloads/drops/R20100519200754/bundles/javax.servlet.jsp_2.0.0.v200806031607.jar fetch: http://download.eclipse.org/tools/orbit/downloads/drops/R20100519200754/bundles/javax.servlet.jsp_2.0.0.v200806031607.jar: Requested Range Not Satisfiable = Attempting to fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/eclipse/javax.servlet.jsp_2.0.0.v200806031607.jar fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/eclipse/javax.servlet.jsp_2.0.0.v200806031607.jar: size mismatch: expected 63889, actual 62707 = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles/eclipse and try again. *** Error code 1 I think that this happens because the old version of the distfile is still present in download target location and fetch(1) thinks that it has a partially downloaded file and tries to be smart. [snip simple patch] make -DNO_CHECKSUM=yes ... is probably what you want, I guess. I think that Andriy is referring to the following case which has bit me, too, more than once: 1. Upstream releases a new version. 2. The port is updated to the new version. 3. The user fetches the new version, builds and installs the port. 4. Upstream makes a change without bumping the version. 5. The port maintainer curses a bit and updates the port, possibly bumping PORTREVISION if upstream changed something important 6. The user tries to fetch the new version of the upstream tarball and stumbles into fetch(1)'s outright refusal :) In this case, NO_CHECKSUM would be quite... counterproductive, in case the user really cares about security and integrity :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Nostalgia ain't what it used to be. signature.asc Description: Digital signature
Re: FreeBSD Port: xpra-0.0.7.16p4
On Fri, Feb 04, 2011 at 09:49:39AM +0100, Kurt Jaeger wrote: Hi! I only just noticed that you've added a port for xpra. I wasn't aware of that and you're pointing to the source on my server, so I guess that it means I have to be careful not to remove it from now on? The files should eventually get automatically mirrored to the FreeBSD ftp server at ftp.freebsd.org (and it's mirrors), so worst case users get it from there, but it's always nice to get it from the originator. OK, I normally move old source releases to /old/ eventually. I guess I can still do that as long as the port file has been updated to use the newer source snapshots? There are always hosts out there that still have old port Makefiles on their disks, so having a stable path would be useful. E.g. on cpan, the files just are added to the directory, not moved after newer ones are added. Well, in truth, the port's Makefile may be trivially configured to look into the old/ subdirectory if the distfile is not found in the real one (see the security/stunnel Makefile for an example). G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This inert sentence is my body, but my soul is alive, dancing in the sparks of your brain. signature.asc Description: Digital signature
Re: duplicate entry for graphics/yafray ?
On Fri, Jan 28, 2011 at 01:09:35PM +0100, Torfinn Ingolfsen wrote: Hello, On Fri, Jan 28, 2011 at 11:26 AM, Denise H. G. darc...@gmail.com wrote: Hi guys Is graphics/yafaray a dupicate entry for graphics/yafray? It seems they don't differ at all. Interesting: tingo@kg-v2$ diff -r /usr/ports/graphics/yafray/ /usr/ports/graphics/yafaray/ diff -r /usr/ports/graphics/yafray/Makefile /usr/ports/graphics/yafaray/Makefile 5c5 # $FreeBSD: ports/graphics/yafray/Makefile,v 1.22 2010/02/05 11:39:41 dinoex Exp $ --- # $FreeBSD: ports/graphics/yafaray/Makefile,v 1.22 2010/02/05 11:39:41 dinoex Exp $ Indeed - they seem to be identical. Perhaps somebody made a typo? Well, to me they seem to be identical, including the CVS history. I would guess that this is a repo-copy in progress, nothing to be concerned about; one of them will probably be removed soon, and the other will be updated. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This would easier understand fewer had omitted. signature.asc Description: Digital signature
Re: portmaster: print /usr/ports/UPDATING on update
On Tue, Dec 28, 2010 at 10:07:18AM +0300, Eygene Ryabinkin wrote:
Mon, Dec 27, 2010 at 05:57:53PM -0800, Doug Barton wrote:
The Real AnswerTM is that we need a tool with striking similarities to
portaudit. The basic idea would be that UPDATING entries would be done
in xml, and then the user can either run portupdating (or whatever the
name ends up being, that's a really bad name but I suck at naming tools)
either by default for their whole system, or vs. a specific port. I
would strongly recommend that the behavior, command line options, etc.
be consistent with portaudit. Download it and check the man page if
there are any questions. :)
There are two questions that arise with this approach:
- we should find a way to keep an old UPDATING file in place;
obviously, it can be easily created from the XML file, but
currently UPDATING is delivered via CVS and it will be good
to allow this behaviour even with the XML'ized version;
but keeping the plain-text UPDATING in CVS while UPDATING.xml
will be used is a bad idea -- UPDATING will be non-master
file, so its history will be redundant. From the other hand,
we have no XML tools in the base tree, so UPDATING can't be
easily created from the XML version at the user machine;
Two quick thoughts here:
- I personally would prefer a human-readable file (and yes, I *can*
read XML; that doesn't mean it's easy or I *want* to :)
...so how about a JSON representation? Human-readable, human-editable,
but still capable of being formalized and validated
- ...and as for an implementation, there is a mini-JSON library in
NetBSD's netpgp implementation -
src/crypto/external/bsd/netpgp/dist/src/libmj/ in NetBSD CVS
- currently, UPDATING has only port names, but not their versions;
one takes the entry timestamp and if he had not yet upgraded
the relevant port(s) after this timestamp, then the corresponding
entry is for him. I see there two cases:
a) there is a specific port version at which some crucial change
that demands the UPDATING entry had happened; if the version
specification will be included in UPDATING, then we won't
even need the timestamp -- one should just take the currently
installed version and the version to be installed; the the
entry's version lies between those two, user will surely need
to read the UPDATING entry;
b) there is a infrastructural changes that affect all or some ports
that will be built after some date; again, the logics of choosing
the entry to be presented is the same as above, but one should use
timestamps, not ports versions.
But having thinked about this a bit, now I am favoring another approach:
one should not rely on the portmaster/portupgrade/OtherTool to present
the UPDATING entries: the best place is the ports infrastructure itself
(or pkg_install suite). This way, any tool that will do upgrades will
receive the UPDATING stuff for free.
Currently I am trying to figure out if it will be sufficient to have the
appropriate machinery in the pkg_delete tool: the old port version and
timestamp are already there; the new timestamp is more-or-less the
current date; the only needed piece is the new port version. It can be
provided via the environment variable by the portmaster-like tool; such
variable will trigger the processing of the UPDATING file. This is
rather rough plan, feel free to correct/criticize it or show why it is
not doable using such approach.
The other thing this entails is portmaster actually storing
information of its own completely aside from /var/db/{pkg|ports}. I'm
really sort of nauseous about that whole idea since it's a slippery
slope that I don't want to travel down. But I'm not seeing any other
way to accomplish the task of make sure that the user knows that they
should read UPDATING without doing something very much like this. Of
course, if someone else has a better idea, I'm all ears. :)
What I do _not_ want to do is write an UPDATING text file parser
myself. Not only do I think that's a bad idea generally, it's not a
project that I am at all interested in, and I don't see it as
something that should be part of portmaster to start with. I could be
talked into the UPDATING.xml project if someone were to come up with
funding for it, but (just being frank and honest) it's too big a
project for me to tackle on a volunteer basis atm.
I had shown the simple shell script that will parse the UPDATING and
present the entries for the given port if the fall into the last N
days category. If you had missed it -- ping me, I'll show it to you
once again.
G'luck,
Peter
--
Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This sentence claims to be an Epimenides paradox
Re: FATAL error emitted by portlint -A
On Sun, Dec 19, 2010 at 07:24:44AM -0500, Jerry wrote: I am attempting to update an existing port. When running portlint -A I am receiving an error message. # portlint -A WARN: Makefile: for new port, make $FreeBSD$ tag in comment section empty, to make CVS happy. WARN: Makefile: new ports should not set PORTREVISION. FATAL: README.html: for safety, be sure to cleanup README.html files before committing the port. 1 fatal error and 2 warnings found. The first two are no problem. it is the third one FATAL that I cannot understand. It never appeared before when I was updating this port. Is this really a FATAL error or can I simply disregard it? The port builds and installed fine. Did you run a make describe sometime during the testing of the port? It will generate README.html and a couple of other files, none of which are supposed to be part of the actual port - all of them are autogenerated when the need arises (e.g. building INDEX). So compare all the files in your port's directory with the files from a previous, known-good version of the port, see which are the new ones and if you wrote them or some tool generated them :) If you didn't write them, chances are you can safely remove them and things will work just fine :) G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If this sentence didn't exist, somebody would have invented it. signature.asc Description: Digital signature
Re: FATAL error emitted by portlint -A
On Sun, Dec 19, 2010 at 02:44:22PM +0200, Peter Pentchev wrote: On Sun, Dec 19, 2010 at 07:24:44AM -0500, Jerry wrote: I am attempting to update an existing port. When running portlint -A I am receiving an error message. # portlint -A WARN: Makefile: for new port, make $FreeBSD$ tag in comment section empty, to make CVS happy. WARN: Makefile: new ports should not set PORTREVISION. FATAL: README.html: for safety, be sure to cleanup README.html files before committing the port. 1 fatal error and 2 warnings found. The first two are no problem. it is the third one FATAL that I cannot understand. It never appeared before when I was updating this port. Is this really a FATAL error or can I simply disregard it? The port builds and installed fine. Did you run a make describe sometime during the testing of the port? Uhm, yes, of course, as Matthew Seaman pointed out, it's make readmes that will generate README.html :) It will generate README.html and a couple of other files, none of which are supposed to be part of the actual port - all of them are autogenerated when the need arises (e.g. building INDEX). So compare all the files in your port's directory with the files from a previous, known-good version of the port, see which are the new ones and if you wrote them or some tool generated them :) If you didn't write them, chances are you can safely remove them and things will work just fine :) G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence was in the past tense. signature.asc Description: Digital signature
Re: failed configure of multimedia/handbrake
On Mon, Dec 06, 2010 at 06:27:54PM -0800, Charlie Kester wrote:
I'm getting a strange error while trying to install the handbrake port:
=== Configuring for handbrake-0.9.3
sed:
/usr/ports/multimedia/handbrake/work/HandBrake-0.9.3//usr/ports/multimedia/handbrake/work/HandBrake-0.9.3/configure:
No such file or directory
*** Error code 1
Stop in /usr/ports/multimedia/handbrake.
Looking at the port Makefile and bsd.port.mk, I can't see why sed is
being run here. Nor can I see why ${WRKSRC} is appearing twice in the
path to the configure script.
I'd say lines 110-112 of the Makefile (REINPLACE_CMD on configure) are why
sed is being run :)
As to why ${WRKSRC}/configure expands to this weird thing... can you show
us the output of the following two commands:
make -V WRKDIR -V WRKSRC -V WRKDIRPREFIX
make -X -V WRKDIR -V WRKSRC -V WRKDIRPREFIX
...in the same (ports/multimedia/handbrake) directory?
G'luck,
Peter
--
Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This sentence contains exactly threee erors.
signature.asc
Description: Digital signature
Re: Renaming a shared library in the port-framework to match FreeBSD naming schemes?
On Mon, Nov 22, 2010 at 08:20:28PM +0200, Andrew W. Nosenko wrote: [snip] Seems, like you think that Xerces authors use libNAME-VER.so naming scheme, while FreeBSD uses libNAME.so.VER ... Just as a data point, it's possible (I'm not sure if it's the case with Xerces, but it *is* the case with other libraries) that the OP is right. The Debian Policy Manual recently had to be amended a bit to allow for shared library files named as libfoo-version.so; for a full discussion (long!... no, I mean it - *really* long!), see: http://bugs.debian.org/509932 So it seems that there are projects that actually do it that way. G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 yields falsehood, when appended to its quotation. yields falsehood, when appended to its quotation. signature.asc Description: Digital signature
Re: Conflict between netpipes-4.2 and timelimit-1.7
On Sun, Nov 14, 2010 at 12:04:33AM -0500, jhell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The above two listed ports have a conflict with the installed binary '/usr/local/bin/timelimit' but do not list each-other as a conflict and should be adjusted to reflect the conflict with one-another. $ pkg_info -qW /usr/local/bin/timelimit pkg_info: both netpipes-4.2 and timelimit-1.7 claim to have installed /usr/local/bin/timelimit This could also be said for its manual pages as well. After removing the timelimit-1.7 package and then upgrading netpipes-4.2 === Creating a backup package for old version netpipes-4.2 tar: man/man1/timelimit.1.gz: Cannot stat: No such file or directory tar: bin/timelimit: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 === Package creation failed for netpipes-4.2! Though the functionality provided by both timelimit commands are fundamentally the same, timelimit-1.7 offers quite a bit more control over the one that ships with netpipes-4.2 without the need to install files like 'faucet' that may act as a network server. Would it be possible to install the netpipes version of timelimit binary as timelimit-4.2 instead ? or maybe another name so these can coexist ? I'm glad that you think that timelimit's functionality is better than that of its netpipes equivalent, but if others don't share that opinion, I could change the port so that the user may specify a program prefix at build time. Still, I'd prefer to leave the default prefix empty :) *** As well, timelimit-1.7 would be a great candidate for import into world since it is your e-std 2 clause BSD license and a 3 file compile. ;) And if noone else wants to maintain it in tree then ill volunteer. *** Oh! Of course, I, as the upstream author, would only be flattered if people were to decide that timelimit is fit to enter the FreeBSD base system :) And certainly I would be willing to maintain it myself in that case; still, thanks a lot for the offer, and a helping hand or three could never be too much :) G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the thought you are now thinking. signature.asc Description: Digital signature
Re: daemontools port options
On Sun, Oct 17, 2010 at 10:31:07AM -0400, Jerry wrote: The sysutils/daemontools port has a few options for the port. The three I have a question about are listed below along with their default settings: S_EARLY Start early, before the normal daemons off S_NORMAL Start normally in the usual boot sequence on SIGQ12 Add svc support for QUIT, USR1, and USR2 signals off I was wondering if there is any strategic advantage to using the S_EARLY option as opposed to the default setting. Imagine your DNS server is running as a service. You want it to start before most of the network services have a chance to try using it :) Also, if I have a program(s) that are routinely restarted via USR1, such as clamav, should I activate the SIGQ12 option? I am not even sure exactly what support it enables. It adds the -1, -2, and -q options to the svc(8) command-line tool, and yes, that's pretty much exactly what you want - if you're running clamav as a service, you can now do svc -1 /var/service/clamav and it'll get a USR1 signal. G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If I had finished this sentence, signature.asc Description: Digital signature
Re: No-op port updates
On Sat, Oct 16, 2010 at 09:47:55AM -0700, Doug Barton wrote: On 10/16/2010 8:30 AM, Rob Farmer wrote: What is the best practice for no-op port updates - i.e. version 1.0 and 1.1 produce identical FreeBSD packages but they might be different on Linux/elsewhere? Update to have to port appear current or avoid forcing people to do unnecessary updates? When faced with similar situations in the past I have chosen not to update, until the whinging became too extreme. :) This is one of those where there is no right answer. I've sometimes added a comment to the port's Makefile explaining the needlessness of an update. G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence was in the past tense. signature.asc Description: Digital signature
Re: RFC: Mk/bsd.jpeg.mk to automagically handle jpeg dependency
On Tue, Jun 15, 2010 at 10:09:57PM -0300, Mario Sergio Fujikawa Ferreira wrote: Hi, Ever since the addition of graphics/libjpeg-turbo, I had been wondering how one could possibly build the whole ports tree with it instead of graphics/jpeg. I wanted the choice. Therefore, I wrote the attached bsd.jpeg.mk as a suggestion. With it, we just add USE_JPEG= yes to any port that requires a jpeg library (either a build or a link dependency). Sounds great! Thanks for your work! Just one small worry, see below... It will automagically detected the already installed jpeg port variant (libjpeg-turbo or jpeg) and depend on it. If the user prefers to set the variant, he can do so using WITH_JPEG=jpeg or WITH_JPEG=libjpeg-turbo Is it possible that this will conflict with ports that have a JPEG item in their OPTIONS list? There are at least the astro/xplanet, editors/emacs, graphics/devil, graphics/gdal, graphics/gegl, graphics/grx, graphics/imlib2, graphics/ocaml-images, graphics/opencv, graphics/podofo, graphics/tumbler, mail/spamprobe, math/R, multimedia/gmerlin, multimedia/gpac-libgpac, multimedia/libquicktime, multimedia/spook, multimedia/transcode, x11/aterm, x11-fm/thunar, x11/mrxvt-devel, and x11-wm/jwm ports that do that, and there might be more that a simple fgrep -le WITH_JPEG -e WITHOUT_JPEG did not catch. G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 signature.asc Description: Digital signature
Re: Data files and ports
On Fri, Jun 11, 2010 at 10:17:46AM -0400, Greg Larkin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Smith wrote: I'm trying to teach myself how to build a FreeBSD port and, with a lot of help from the manual, it's going well. I have a question though concerning policy/style. I'm trying to port a program which is distributed in two separate packages from the upstream project. One package contains the executable program and the other contains data files. The Data package rarely changes. The idea being packaging them together would use up a lot of extra bandwidth. Which brings me to the question: Since the executable relies on the data files being in place before it's run, how should I handle that in the port? Should I just get the executable to install and let the user manually get the data files? Should I create a second port for the data package? Or should I find some way of making the executable's makefile download and unpack the data package? My instinct is to create a separate port for the Data package and list it as a dependency for the Executable port. I'd appreciate some guidance. Thanks. Hi Jesse, Welcome to the fray, and I'm glad to hear that you're learning how to develop FreeBSD ports! To answer your question - your port Makefile can download multiple distribution files from the upstream download site. For a couple of examples, see these Makefiles: [snip] All good points, and good examples. However... :) Well, I do believe that if the Data package rarely changes, then it would be unnecessary not only to distribute it each time as a port's source distfile, but also to include it (unchanged) in different releases of the *packages* that the port builds. Thus, IMHO it would be best to make a separate port for the data file and have the main program (port) depend on it. This would make sure that not only people who build the port by hand do not download the data file more often than necessary, but also the people who use packages do not download needlessly big packages for each program update with no data change. Hope that came out clear enough; I know I'm not thinking straight today. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 signature.asc Description: Digital signature
Re: GSoC: Making ports work with clang
On Sun, May 02, 2010 at 11:51:52PM +0300, Andrius Mork??nas wrote: On Sun, 02 May 2010 10:25:22 +0300, Yuri y...@rawbw.com wrote: Having tried clang++ I have a feeling that it's not quite ready to be a generic c++ compiler. [snip] Very immature. Many problems that C++ ports have with clang is not related to it being immature, they're related to the fact that clang isn't gcc and that those ports aren't written in standard C++. Too true. [snip] You will just keep stumbling upon various problems with various ports I've mentioned that I've been involved with ports+clang since last October. Stumbling upon various problems is what I do. I'm still here, even doing a GSoC project, so it doesn't look like various problems will scare me off. And as I've mentioned above, just because some ports don't compile, it doesn't affect this project too much. Well said, well meant. Kudos. Thanks for your work so far, and thanks for taking up that GSoC project. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 I am the meaning of this sentence. pgpGlPfkbxVdU.pgp Description: PGP signature
[CFT] security/stunnel update to 4.33
Hi,
It's been a long time and four upstream releases since stunnel-4.29
which is in the Ports Collection now. The reason I've not updated
the port is that there were user reports of various instabilities
and regressions in the logging, chroot support, and some other newly
introduced features.
Now, with stunnel-4.33, it seems all of those are resolved, and
the new features are worth upgrading. So here's the patch to
update the security/stunnel port; if anybody is willing to test it,
it'd be great. If no problems should arise, I intend to commit it
in a couple of days.
The patch is also available at
http://people.FreeBSD.org/~roam/patches/stunnel/stunnel-4.33-01.patch
G'luck,
Peter
Description: Update the security/stunnel port to version 4.33.
Author: Peter Pentchev r...@freebsd.org
Last-Update: 2010-04-07
--- a/security/stunnel/Makefile
+++ b/security/stunnel/Makefile
@@ -6,7 +6,7 @@
#
PORTNAME= stunnel
-PORTVERSION= 4.29
+PORTVERSION= 4.33
CATEGORIES=security
MASTER_SITES= http://www.stunnel.org/download/stunnel/src/ \
ftp://stunnel.mirt.net/stunnel/ \
--- a/security/stunnel/distinfo
+++ b/security/stunnel/distinfo
@@ -1,6 +1,3 @@
-MD5 (stunnel-4.29.tar.gz) = 14dc3f8412947f0548975cbce74d6863
-SHA256 (stunnel-4.29.tar.gz) =
018064e852a2a125bcfb4b81baa77b5701ccf6aabe6a47564bfc046b18d11f9b
-SIZE (stunnel-4.29.tar.gz) = 544292
-MD5 (execargs.patch) = c893028f869f6d1f527373334605d639
-SHA256 (execargs.patch) =
88e682c0deee13d9768c8cbdd3e71f90dd26d92621d2e64542d5379a3939ac4c
-SIZE (execargs.patch) = 756
+MD5 (stunnel-4.33.tar.gz) = 559a864066d8cc4afd8a97682c90d41c
+SHA256 (stunnel-4.33.tar.gz) =
24076314dea6ab76b30f5f5571a8ef4d22ba0712176a9c31c221bb9a48fc
+SIZE (stunnel-4.33.tar.gz) = 560103
--- a/security/stunnel/files/patch-Makefile.in
+++ b/security/stunnel/files/patch-Makefile.in
@@ -2,11 +2,11 @@
This is handled by the FreeBSD port's Makefile.
Forwarded: not-needed
Author: Peter Pentchev r...@freebsd.org
-Last-Update: 2009-11-13
+Last-Update: 2010-04-07
--- tools/Makefile.in.orig
+++ tools/Makefile.in
-@@ -339,7 +339,7 @@
+@@ -334,7 +334,7 @@
info-am:
@@ -14,4 +14,4 @@
+install-data-am: install-confDATA \
install-examplesDATA
- install-exec-am:
+ install-dvi: install-dvi-am
--- a/security/stunnel/files/patch-src::common.h
+++ b/security/stunnel/files/patch-src::common.h
@@ -1,11 +1,11 @@
Description: Build on FreeBSD versions of OpenSSL 0.9.8b.
Forwarded: not-needed
Author: Peter Pentchev r...@freebsd.org
-Last-Update: 2010-02-01
+Last-Update: 2010-04-07
--- src/common.h.orig
+++ src/common.h
-@@ -344,9 +344,6 @@
+@@ -350,9 +350,6 @@
#define OPENSSL_THREAD_DEFINES
#include openssl/opensslconf.h
--- a/security/stunnel/files/ssl-noengine.patch
+++ b/security/stunnel/files/ssl-noengine.patch
@@ -1,16 +1,16 @@
Description: Disable the OpenSSL engine support for the FreeBSD port.
Forwaded: not-needed
Author: Peter Pentchev r...@freebsd.org
-Last-Update: 2009-11-13
+Last-Update: 2010-04-07
--- src/ssl.c.orig
+++ src/ssl.c
-@@ -276,6 +276,8 @@
+@@ -288,6 +288,8 @@
}
- static void init_engine() {
+ static char *init_engine(void) {
+s_log(LOG_ERR, This version of stunnel was compiled WITHOUT support for
OpenSSL hardware engines! If you need this functionality, rebuild the FreeBSD
port with the WITH_STUNNEL_SSL_ENGINE option set to 'yes'; contact Peter
Pentchev r...@freebsd.org for details.);
+exit(1);
if(engine_initialized)
- return;
+ return NULL; /* OK */
engine_initialized=1;
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Do you think anybody has ever had *precisely this thought* before?
pgpfIekxKXPwu.pgp
Description: PGP signature
curl, c-ares, and IPv6
Hi, If this is of interest to anybody, I just committed an update to the c-ares asynchronous DNS resolver library, and also a little change to the cURL port, finally allowing it to do async DNS lookups when IPv6 support is enabled. I intend to turn IPv6 support on by default for the upcoming curl-7.20.0 update in a couple of days. If anybody has any strong reasons why this should not be done[1], please speak up now :) G'luck, Peter [1] I mean, besides the obvious one more DNS query and a failed connect() call - too many other applications have done this by default for the past five, if not ten, years, and there's a growing number of instalations (well, okay, still a minority, but still...) where the connect() call will *not* fail :) -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 This sentence would be seven words long if it were six words shorter. pgpJPQxAH0mQb.pgp Description: PGP signature
Re: curl, c-ares, and IPv6
On Mon, Mar 22, 2010 at 01:05:59PM +0200, Peter Pentchev wrote: Hi, If this is of interest to anybody, I just committed an update to the c-ares asynchronous DNS resolver library, and also a little change to the cURL port, finally allowing it to do async DNS lookups when IPv6 support is enabled. I intend to turn IPv6 support on by default for the upcoming curl-7.20.0 update in a couple of days. If anybody has any strong reasons why this should not be done[1], please speak up now :) Okay, so I wasn't thinking straight here, sorry people :) IPv6 support *has been* turned on for the cURL port for quite some time now, it's just that it was off on my couple of machines because of the incompatibility with c-ares :) So... so my previous message basically boils down to hi, you can use c-ares and IPv6 with curl now, and while I'm here, let me also demonstrace my absent-mindedness :) [1] I mean, besides the obvious one more DNS query and a failed connect() call - too many other applications have done this by default for the past five, if not ten, years, and there's a growing number of instalations (well, okay, still a minority, but still...) where the connect() call will *not* fail :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 This sentence would be seven words long if it were six words shorter. pgpGJyvtBnpYE.pgp Description: PGP signature
Re: Bluefish 2.0.0 released!
On Thu, Feb 25, 2010 at 12:59:00PM -0800, Charlie Kester wrote: On Thu 25 Feb 2010 at 12:17:59 PST simp...@gmail.com wrote: News 2010 - February 15 - Bluefish 2.0.0 released! I can't find it in the latest ports collection. Others have explained how to contact the maintainer of a port, and how to determine that it has no maintainer. But perhaps some expectation-setting is needed here. Bluefish 2.0.0 was released a mere ten days ago. Before it will appear in the ports collection, two things have to happen. First the maintainer must modify the port as needed to get it to compile on FreeBSD. Sometimes that's trivially simple, sometimes it's diabolically complex. If the port is depended upon by others, for example, there might be a need to coordinate the update with them. So it's not unusual for the maintainer's part of the porting process to take several days or even weeks. That's true - and yes, there are port updates that take weeks sometimes. (although, well, some of *my* updates in the past have been known to take weeks for other reasons, not just the review and technical work) Second, after the maintainer has submitted a PR with the update, the committers need to test it. That takes time. Also, judging by what I can see in the list of currently-open PR's, many committers always have a dozen or more in process. It's not uncommon (or unreasonable) that this part of the porting process will take several days or even weeks in addition to the time the maintainer needed. Well, in this particular case, the maintainer of www/bluefish is a FreeBSD committer himself, so this part might take a bit less time :) But in general, it's true enough. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 No language can express every thought unambiguously, least of all this one. pgplNcg82tj9f.pgp Description: PGP signature
Re: FreeBSD Port: php5-mhash-5.2.11_1
On Thu, Dec 17, 2009 at 09:46:25AM +0100, Alex Dupre wrote:
Simon Shapiro ha scritto:
Hey,
I just updated ports on a few machines and the CLI version of php dumps
its core rather than end nicely. The mhash module appears to be the
trigger (an extensions.ini with only mhash causes failure, all others
minus mhash: no failure).
Simply recompile security/mhash removing the following configure arg:
--with-LDFLAGS=${PTHREAD_LIBS}
I'm waiting approval from maintainer.
I've just committed this fix. Sorry for not reacting a bit sooner.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
If there were no counterfactuals, this sentence would not have been paradoxical.
pgpTqhh27Ixoq.pgp
Description: PGP signature
Re: Port version difficulties (maybe one for the Python crowd)
On Mon, Dec 07, 2009 at 05:12:03PM -0500, Greg Larkin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin Golding wrote: In article 4b1d617a.6020...@freebsd.org, Greg Larkin glar...@freebsd.org writes This might get you further: fbsd70# make -V \ PYDISTUTILS_PKGVERSION:C/\(\[\[:digit:\]\]\.\[\[:digit:\]\]\)\./\\1_/g 0.1_0 fbsd70# Well that does indeed work in that context, but I have no idea why it appears to do nothing in the Makefile. It seems completely unchanged: pkg_delete: unexec command for '/usr/local/bin/easy_install-2.6 -q -m -S /usr/local/lib/python2.6/site-packages django-signals-ahoy==0.1.0' failed I actually had to double check I did indeed update the correct file. A bit strange anyway. Kevin Hi Kevin, There's a lot more backslash escaping required in the :C suffix above when running the make command directly in the shell. If you remove some of the backslashes in the equivalent line in the Makefile, should be all set. Then you can check to make it's working by running make -V PYEASYINSTALL_UNINSTALLARGS. A bit off-topic, and a bit late, but you can avoid the need for those additional backslashes by simply placing the string in apostrophes (single quotes). It's the shell that tries to interpret the string before passing it to make itself, and the single quotes tell the shell to not even try to interpret the string. So, just do: make -V 'PYDISTUTILS_PKGVERSION:C/([[:digit:]]\.[[:digit:]])\./\1_/g' ...and you'll see what make(1) thinks of the quoted string, just as if you'd put it in the Makefile. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI pgpXa9EbTWuFM.pgp Description: PGP signature
Re: Newbie question about additional documentation
On Tue, Nov 24, 2009 at 06:26:34AM +, Matthew Seaman wrote:
dave wrote:
On Mon, 2009-11-23 at 22:20 +, Matthew Seaman wrote:
Correct. In fact, it possibly means the LICENSE ends up in the plist
twice, which is almost as bad as it not being mentioned at all.
Ok, I think I'm starting to get a hang of this. Personally, I prefer the
static pkg-plist.
There's one last minor detail, though. The where's the final packing
list located? Is it in /var/db/pkg/${DISTNAME}?
While you're building the port, the packing list is assembled as
${WRKDIR}/PLIST where ${WRKDIR} is by default /usr/ports/foo/bar/work/
although it's not uncommon to locate it somewhere else by modifying
$WRKDIRPREFIX.
Once installed the PLIST is turned into /var/db/pkg/${DISTNAME}/+CONTENTS
which adds information about the ports this one depends on, plus the
md5 sumes of all of the installed files.
Just a small correction: it's /var/db/pkg/${PKGNAME}, not ${DISTNAME} :)
A slight difference, but important sometimes, most often when
PORTREVISION 0, but also when there are differences between
the representation of the version in the upstream distribution and in
the FreeBSD port.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
I am not the subject of this sentence.
pgpzPCW1hlGij.pgp
Description: PGP signature
Re: RFC: svn for make fetch
On Tue, Nov 10, 2009 at 08:51:25AM +0200, Eitan Adler wrote: Correct me if I'm wrong but I thought that svn did its own checksumming. If so why do we need to our own? Subversion's checksumming makes sure that you get exactly the same files that are on the Subversion server at this particular moment in time. The Ports Collection's distfile checksums make sure that you get exactly the same files *as the port maintainer examined at some previous moment in time*. The difference is crucial. svnadmin create /home/svn/foo svn import http://.../foo/trunk/mycoolproject create a port of mycoolproject rm -rf /home/svn/foo svnadmin create /home/svn/foo svn import http://.../foo/trunk/mycoolproject ...and suddenly the port fetches something completely different. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This would easier understand fewer had omitted. pgpgo8opOFsxg.pgp Description: PGP signature
Re: RFC: svn for make fetch
On Tue, Nov 10, 2009 at 06:12:40PM +, RW wrote: On Tue, 10 Nov 2009 12:32:28 +0200 Peter Pentchev r...@ringlet.net wrote: The Ports Collection's distfile checksums make sure that you get exactly the same files *as the port maintainer examined at some previous moment in time*. More importantly it guards against maliciously modified source code. Someone might break into a legitimate mirror or use dns poisoning to distribute malware. That's the whole point :) That's also why the maintainer is supposed to examine the files before submitting (or committing) a port update - to guard against source code that has been maliciously modified on the master sites (or on fake master sites that the maintainer has been redirected to). G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 If wishes were fishes, the antecedent of this conditional would be true. pgpIONgN43NT0.pgp Description: PGP signature
Re: Enforcing library version in a port Makefile?
to lots of other ports updating their LIB_DEPENDS lines and, usually, bumping their PORTREVISION. Thus, when the end user updates her Ports Collection, she just sees that she needs to update both the curl and scons ports, and everything Just Works(tm) :) If you are relying upon some feature of a port that may change while it's relevant shared library versions remain the same, then you should add the port to the other *_DEPENDS as needed, with appropriate checks on the port version number in those variables. I suspect this is what I shall have to do. Is this what all other port authors do in similar circumstances? It seems kind of a hackish workaround, especially if the library in question doesn't have a corresponding executable to list in RUN_DEPENDS. Do I force a library name into RUN_DEPENDS? It is, indeed, a hackish workaround, and it should only be used in extreme cases, when the build really fails *and* you, as the maintainer of the port, really see a need to allow the users to build it with older versions of ports that it depends on - see my comments about the synchronized ports collection above. In general, it should be really, really rare. It would be nice to be able to express the real dependency as precisely and accurately as possible, say I want = X.Y (in numbering scheme Z) of this library, rather than have to obfuscate intent by using some proxy. True, it would be nice, yet it might require some more work to implement, since it would change the way the checks are done. Somebody(tm) ought to do the work to implement it - maybe :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This would easier understand fewer had omitted. pgpDWxJf9CTIV.pgp Description: PGP signature
Re: security/libgcrypt Following UPDATING 20090107 Build failure
On Wed, Sep 23, 2009 at 05:41:34PM +0100, David Southwell wrote: On Wed, Sep 23, 2009 at 12:00:01PM +0100, David Southwell wrote: ../src/gcrypt.h:29:23: error: gpg-error.h: No such file or directory In file included from ../src/visibility.h:243, from ../src/g10lib.h:39, from ../src/mpi.h:37, from mpi-internal.h:52, from mpi-add.c:31: something wrong with your libgpg-error installation. Try reinstalling it. Regards, Rong-En Fan Thank Rong-En Right on the button It looks to me as though libpg-error could be a dependency of libgcrypt Errr, but it is, and it has been ever since May 2004... G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the thought you are now thinking. pgpnGz1x51D4s.pgp Description: PGP signature
Re: Open discution for a fakeroot support for the ports infrastructure
On Mon, Aug 31, 2009 at 11:26:43PM +0200, Baptiste Daroussin wrote:
Hi,
I've written some patches for the ports infrastructure importing the
fakeroot implementation from midnightbsd ports.
That's actually a good idea. I'm quite used to fakeroot already from
some work I've been doing in Debian.
In my first implementation the fake directory was enabled by default, no
ports had to be modified to support it.
My second implementation added a knob to add to make.conf (USE_FAKE) to
enable it for people wanting it and want to tested. still no ports to be
modified (except perhaps some buggy one)
Now the patches are quite old (they won't apply cleanly) so I'm on updating
it again.
Before rewriting it, I think it is a better idea to first discuss about it,
to improve it, see if there are interests, etc.
So basically here is what is done and how it works.
the changes are only in the infrastructure not in ports themselves (except
that some will be able to benefit some cleanup)
do-fake (with post and pre) replaces do-install (pre/post) it creates a
$WRKSRC/fakeroot where the binaries are copied by the ports (during the
do-install of the port)
then do-package create a package using pkg-plist (or the generated one)
using the binary in fakeroot.
do-install (ie make install) now only does a pkg_add of the created pkg.
Just one comment: there are some ports, and not quite so few, either,
which override the do-install target to do some maintenance of their own.
A trivial run of
find . -mindepth 3 -maxdepth 3 -name Makefile -type f -print0 |
xargs -0 fgrep do-install
...from /usr/ports gives just about 6000 results here, and most of them are,
indeed, real cases of port Makefiles doing the install thing for themselves.
This is done either for very, very simple programs where it would be
unnecessary overhead to recurse into the upstream's Makefile and run
its install target, or for programs where the upstream doesn't even
*have* an install target, or for programs where there is, quite simply,
no upstream - like devel/portilnt :)
So the fakeroot implementation should take that into account, too -
and that could be a problem, since most of the do-install targets
actually do install their files directly into ${PREFIX}.
This could actually be easier if DESTDIR were implemented first :)
What is the interest of that :
the installed files will now always respects the pkg-plist which simplify
the QA work.
the developpers will have to focus on the pkg-plist to choose which file
will be installed according to the desired KNOBS/OPTIONS : no more ugly hack
to respect NOPORTDOCS and NOPORTDATA for example.
certainly a lot more that i don't see now.
what could be seen in the future is an equivalent of the update-plist target
of openbsd ports infrastructure.
it will easier implementation of multipackage ports (if ever wanted :)), one
port with multiple pkg-plist.
the discussion is open :)
here is the PR concerned :
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/133815
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This inert sentence is my body, but my soul is alive, dancing in the sparks of
your brain.
pgpLxmMiry5xu.pgp
Description: PGP signature
Re: Open discution for a fakeroot support for the ports infrastructure
On Tue, Sep 01, 2009 at 11:02:24AM +0300, Peter Pentchev wrote: [snip] This is done either for very, very simple programs where it would be unnecessary overhead to recurse into the upstream's Makefile and run its install target, or for programs where the upstream doesn't even *have* an install target, or for programs where there is, quite simply, no upstream - like devel/portilnt :) Of course, this should read like ports-mgmt/portlint :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I had to translate this sentence into English because I could not read the original Sanskrit. pgpiUAWR1GEY3.pgp Description: PGP signature
Re: serpentine port forces dependency on muine
On Wed, Aug 26, 2009 at 09:29:10PM -0700, Kevin Oberman wrote:
Date: Thu, 27 Aug 2009 02:10:06 +0300
From: Peter Pentchev r...@ringlet.net
On Wed, Aug 26, 2009 at 11:47:48AM -0700, Kevin Oberman wrote:
Date: Wed, 26 Aug 2009 07:05:12 +0100
From: Matthew Seaman m.sea...@infracaninophile.co.uk
Kevin Oberman wrote:
If muine found in /usr/local/bin/, it will be built with the plug-in,
regardless of which way the MUINE configure option is set because:
.if (defined(MUINE) || exists(${LOCALBASE}/bin/muine))
${ARCH}==i386
This is incorrect behaviour in any case: ports should not arbitrarily
change configuration depending on what is or is not already installed,
and user
choices from OPTIONS dialogues should be paramount. The test should be:
.if defined(WITH_MUINE) !defined(WITHOUT_MUINE) ${ARCH} ==i386
The more I look at this port, the stranger it is.
Uhm, no it isn't, not really :)
It has OPTIONS=, but does not include bsd.port.options.mk.
It includes bsd.port.pre.mk before testing the option. The part that
takes care of displaying the dialog window to the user is in
bsd.port.pre.mk. This part of the port's Makefile is correct.
Whole this may work, it is not recommended by the Porter's
Handbook. (See 5.11.2.2). Still, I suspect it does work as used here.
Errr, this part of the Porter's Handbook only appeared three months
ago, when portmgr@ (Pav Lucistnik in particular, I guess, since it was
he who did most of the work) decided that bsd.port.options.mk was ready
for production use :) Okay, so the serpentine port hasn't been updated
to use options.mk, but there are a lot of other ports that haven't yet
(and yes, I know that some of them are mine ;)
[snip]
OK. I totally mis-read the Makefile and got most of my comments wrong.
Nah, it's really not that hard to mis-parse a port Makefile - there are
many knobs controlling many aspects of the build, and some of them are
quite alike and can be mistaken for each other. Happens to everyone :)
(and before someone misparses this, I'm *not* criticizing the Ports
Collection - it's great, it just takes some getting used to - continually -
as any more-or-less complex thing in constant development should)
I do hope that ahze will fix this so that it behaves as people are most
likely to expect it to behave. I will go ahead and update the PR I
submitted on this to simply suggest the removal of the
|| exists(${LOCALBASE}/bin/muine.
Thanks for you patience in this.
No problem, and apologies if my last message has struck you as maybe
a bit confrontational. It was meant as a friendly explanation, and
the reason it started off with a couple of No, that's not right
points is that I wasn't thinking too clearly at two in the morning.
Thanks for *your* patience and understanding!
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If I were you, who would be reading this sentence?
pgprYcjAFEbum.pgp
Description: PGP signature
Re: serpentine port forces dependency on muine
- now there *is* an easy way for the user to specify whether she wants muine or not. This part I agree with, and I think that it should be removed now. I'm just writing all of this to try to explain the point of view that led to this situation in the first place, in revision 1.2 of the Makefile, four years ago. At that time, the options framework was not completely finished yet, and users still had to specify WITH_* and WITHOUT_* variables manually, either on the command line or in elaborate config files; thus, the autodetection of muine was, indeed, considered by some to be a useful thing. Now, I think it's outgrown its usefulness. As serpentine is a part of the gnome2-power-tools metaport and a LOT of folks are likely to be re-building a lot of ports due to the V8.0 release, I'd really like to see it fixed. This does not effect me any longer as I have commented out the part of the configuration that enables the muine plug-in, rebuilt serpentine, and deinstalled muine, but I am sure it will cause problems for others. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the meaning of this sentence. pgp20Iuo1ZuKt.pgp Description: PGP signature
Re: serpentine port forces dependency on muine
On Tue, Aug 25, 2009 at 11:06:18AM -0700, Kevin Oberman wrote:
I have been trying to remove all dependencies on the broken muine port
and discovered that an error in the serpentine port Makefile causes
serpentine to always depend on muine.
The Makefile uses the config option MUINE to indicate whether to build
the muine plugin, but the script then checks WITH_MUINE and always
build the muine plugin and creates a dependency on muine.
I have opened PR ports/138179.
I patched the Makefile with:
--- sysutils/serpentine/Makefile.orig 2009-08-25 10:45:24.0 -0700
+++ sysutils/serpentine/Makefile 2009-08-25 10:07:00.0 -0700
@@ -29,7 +29,7 @@
.include bsd.port.pre.mk
-.if (defined(WITH_MUINE) || exists(${LOCALBASE}/bin/muine))
${ARCH}==i386
+.if (defined(MUINE) || exists(${LOCALBASE}/bin/muine)) ${ARCH}==i386
BUILD_DEPENDS+= muine:${PORTSDIR}/audio/muine
RUN_DEPENDS+=muine:${PORTSDIR}/audio/muine
PLIST_SUB+= MUINE=
E...
I strongly doubt that this is the reason for your problems.
Actually, this is exactly how the Ports Collection's options framework
is supposed to work: the OPTIONS variable lists just the names of
the options, then bsd.port.mk prompts the user through a dialog
(or just uses the options' default values) and sets either WITH_name
or WITHOUT_name. The port then checks for WITH_name or WITHOUT_name,
just as it does in this case. The option is named MUINE, but
the bsd.port.mk framework will set WITH_MUINE if the user wants it,
or WITHOUT_MUINE if she doesn't (or building in batch mode, since
the option defaults to Off).
So the Makefile check is actually correct.
I find it a little bit hard to believe that it is exactly this change
to the Makefile that helped you get a serpentine build without muine.
Could it be that, in the meantime, you had also removed the muine
port itself? The Makefile check will be satisfied if the MUINE option
is enabled *or* if the muine executable is present in /usr/local/bin.
This is most probably because the serpentine configure script looks for
muine itself and uses it unconditionally if it finds it.
So... maybe you just had a /usr/local/bin/muine, and that made
the serpentine port always build with it? Because the Makefile check
is actually correct as per the ports options framework :/
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
The rest of this sentence is written in Thailand, on
pgps1JG0T34Nn.pgp
Description: PGP signature
Re: serpentine port forces dependency on muine
On Tue, Aug 25, 2009 at 04:15:51PM -0700, Kevin Oberman wrote:
Date: Wed, 26 Aug 2009 01:50:01 +0300
From: Peter Pentchev r...@ringlet.net
On Tue, Aug 25, 2009 at 11:06:18AM -0700, Kevin Oberman wrote:
I have been trying to remove all dependencies on the broken muine port
and discovered that an error in the serpentine port Makefile causes
serpentine to always depend on muine.
The Makefile uses the config option MUINE to indicate whether to build
the muine plugin, but the script then checks WITH_MUINE and always
build the muine plugin and creates a dependency on muine.
I have opened PR ports/138179.
I patched the Makefile with:
--- sysutils/serpentine/Makefile.orig 2009-08-25 10:45:24.0
-0700
+++ sysutils/serpentine/Makefile 2009-08-25 10:07:00.0 -0700
@@ -29,7 +29,7 @@
.include bsd.port.pre.mk
-.if (defined(WITH_MUINE) || exists(${LOCALBASE}/bin/muine))
${ARCH}==i386
+.if (defined(MUINE) || exists(${LOCALBASE}/bin/muine)) ${ARCH}==i386
BUILD_DEPENDS+= muine:${PORTSDIR}/audio/muine
RUN_DEPENDS+=muine:${PORTSDIR}/audio/muine
PLIST_SUB+= MUINE=
E...
I strongly doubt that this is the reason for your problems.
Actually, this is exactly how the Ports Collection's options framework
is supposed to work: the OPTIONS variable lists just the names of
the options, then bsd.port.mk prompts the user through a dialog
(or just uses the options' default values) and sets either WITH_name
or WITHOUT_name. The port then checks for WITH_name or WITHOUT_name,
just as it does in this case. The option is named MUINE, but
the bsd.port.mk framework will set WITH_MUINE if the user wants it,
or WITHOUT_MUINE if she doesn't (or building in batch mode, since
the option defaults to Off).
So the Makefile check is actually correct.
I find it a little bit hard to believe that it is exactly this change
to the Makefile that helped you get a serpentine build without muine.
Could it be that, in the meantime, you had also removed the muine
port itself? The Makefile check will be satisfied if the MUINE option
is enabled *or* if the muine executable is present in /usr/local/bin.
This is most probably because the serpentine configure script looks for
muine itself and uses it unconditionally if it finds it.
So... maybe you just had a /usr/local/bin/muine, and that made
the serpentine port always build with it? Because the Makefile check
is actually correct as per the ports options framework :/
Ack. You are correct.
If muine found in /usr/local/bin/, it will be built with the plug-in,
regardless of which way the MUINE configure option is set because:
.if (defined(MUINE) || exists(${LOCALBASE}/bin/muine)) ${ARCH}==i386
As a result, you can't deinstall muine as serpentine depends on it, but
you can't build serpentine without a dependency on muine until you
deinstall muine. I am confused as to the whole point of this structure.
If muine is installed, serpentine will be built with the plugin...end of
story. The configuration option does nothing. The only effect it has is
to force the installation of muine on the initial install muine is not
already installed.
This structure is probably targeted at the case of the port being built
on a clean system (or at least a clean-ish system). From your
explanations, it seems to me that you are considering the case of
the port being built while a previous version of serpentine is still
installed on the system. While this is, indeed, convenient, and
maybe it is the way it's done by some port building helper tools,
IMHO it's a bit risky: I always prefer to build ports without having
another instance of the port installed to avoid the danger of
the port picking up some of its own pieces from the older, currently
installed version. I've had trouble in the past with ftp/curl -
for some reason or other, the test suite sometimes picked up
the libcurl.so from /usr/local/lib/ and not the one it was *supposed*
to use (its own, in its own build directory) - thus the tests for
*newer* features failed. There could be other ways in which this
could pose problems.
Of course, this is merely my humble opinion, and I do realize
the convenience of still having the port installed while you build
its newer version - the old-fashioned way I do things leaves me
X-less and Firefox-less for hours at a time on big upgrades :)
Still, I'm saying this in the hope that you will see the case that
the port maintainer had in mind when writing the Makefile :)
(it's valid for the automated package build systems, too)
I guess the right way is to change the statement to read:
.if defined(MUINE) ${ARCH}==i386
MUINE is never defined, or at least not by the Ports Options framework.
It's either WITH_MUINE or nothing.
In this particular case, removing the check could work. In my
previous message I mentioned the possibility
Re: openssl port - patch file
On Fri, Aug 14, 2009 at 10:19:27AM +0200, Oliver Lehmann wrote:
Hi,
you've changed the PATCHFILES to dtls-bugs-2009-05-18.patch for openssl -
but I'm not able to fetch this file nor does google found it... so where
can I get it from?
I think that there are two problems here.
First, Dirk Meyer has placed this file in his local distfiles directory
on the FreeBSD cluster, but it has not yet propagated to the FTP servers.
This should take a couple of hours, a day at most.
Second, the security/openssl/Makefile is indeed referring to
${MASTER_SITE_LOCAL} in PATCH_SITES, but it is missing a subdirectory
there. Thus, even after the patch propagates to the FreeBSD FTP mirrors,
the port's Makefile will still be looking for it in the wrong place.
The following trivial patch should fix that; Dirk, I could commit it
if you are busy.
Index: ports/security/openssl/Makefile
===
RCS file: /fs/ncvs/ports/security/openssl/Makefile,v
retrieving revision 1.153
diff -u -r1.153 Makefile
--- ports/security/openssl/Makefile 14 Aug 2009 06:32:22 - 1.153
+++ ports/security/openssl/Makefile 14 Aug 2009 08:29:53 -
@@ -16,6 +16,7 @@
MASTER_SITE_SUBDIR=source
#PATCH_SITES= http://sctp.fh-muenster.de/dtls/
PATCH_SITES= ${MASTER_SITE_LOCAL}
+PATCH_SITE_SUBDIR= dinoex
PATCHFILES=dtls-bugs-2009-05-18.patch
DISTNAME= ${PORTNAME}-${PORTVERSION}
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This inert sentence is my body, but my soul is alive, dancing in the sparks of
your brain.
pgpckqXSNpFpu.pgp
Description: PGP signature
Re: FreeBSD Port: mplayer-0.99.11_14
On Thu, Jul 23, 2009 at 10:52:30AM -0400, Michael D. Stackhouse wrote: Downloaded most current source snapshot, ran the configure command which completed successfully. When I tried make command - get this error: config.mak, line 4: Need an operator Makefile, line 820: warning: duplicate script for target %.d ignored Makefile, line 823: warning: duplicate script for target %.d ignored Error expanding embedded variable. Any ideas? Did you run exactly the make command? The mplayer port uses the GNU version of the make utility, which is installed as gmake on FreeBSD systems. Try running gmake instead. Note that this might still fail, since the mplayer port has quite a lot of patches to the mplayer source, some of which may fix build failures that you may run into when building the pristine SVN source. Other patches may influence the mplayer behavior later on :) Those patches are in the files/ subdirectory of the mplayer port; you might want to try to apply them to the source after checking it out of their Subversion repository (or after extracting the snapshot). G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? pgpALeUI8hD7F.pgp Description: PGP signature
Re: Honoring NOPORTDOCS with GNU_CONFIGURE?
On Thu, Jun 25, 2009 at 09:40:42AM -0500, Kirk Strauser wrote:
Is there a standard way to write ports which use GNU_CONFIGURE to follow
NOPORTDOCS? Ideally it'd be something as simple as setting --docdir=NULL or
similar, and even more ideally by having bsd.port.mk taking care of that. :-)
Not really. What I usually do is have a post-patch: target that
does a REINPLACE_CMD on all the Makefile.in's found in the port's
directpry and just removes the install-doc target; something like:
.ifdef(NOPORTDOCS)
@${REINPLACE_CMD} -E -e 's/ install-docDATA/ /; s/^(SUBDIRS.+)doc/\1/' \
${WRKSRC}/Makefile.in
@${REINPLACE_CMD} -E -e 's/([^n])install-examplesDATA/\1/' \
${WRKSRC}/tools/Makefile.in
.endif
This is taken from the security/stunnel port; you may need to fit it
for your specific port's needs, or, if there are many Makefile.in files,
use ${FIND} | ${XARGS} to process them all at once.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
Hey, out there - is it *you* reading me, or is it someone else?
pgpn3xqcd84du.pgp
Description: PGP signature
Re: [RFC] New category proposal, i18n
On Wed, Jun 24, 2009 at 03:13:53PM +0100, Chris Rees wrote: [snip] Though I still reserve the right to hate the inconsistent use of 'z' (why internationalize but surmise; I guess surmise just hasn't been US-ized yet :P realize but enterprise, etc etc)! Er, isn't this a verb-vs-noun difference? :) I don't think nouns are -ize'd, too :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence was in the past tense. pgprQkAmle4pV.pgp Description: PGP signature
Re: Unrealircd problems with last patch
On Wed, Jun 17, 2009 at 11:52:02AM +0300, Peter Pentchev wrote: On Wed, Jun 17, 2009 at 08:24:38AM +0200, Andrea 'simplex' Zulato wrote: Hi, i've upgraded c-ares and Unreal from ports but Unreal won't work. It start without a problem but when someone try to connect to the server it crash with a core dump error: Jun 16 09:03:33 hazard kernel: pid 57652 (ircd), uid 0: exited on signal 11 (core dumped) I've tried to recompile unreal and c-ares whitout any result (make install finish without problems on both ports). If there's something that i could try, please tell me... I'm on a FreeBSD 7.2-RELEASE-p1 #0. Hi, I've CC'd Gerrit Beine (the actual maintainer of the irc/unreal port :) and Ilya Andreev, who reported the same problem to me yesterday. Some time ago, I sent my proposed c-ares update for testing to all the maintainers of ports that depend on c-ares directly. My patches made the ports compile, but I didn't have the proper setup to actually test them working, since I'm not quite familiar with the programs themselves. Thus, I asked the maintainers for help with testing, and after nobody replied for a week or so, I went ahead and commited the update. Now Ilya Andreev and you have both hit a problem with UnrealIRCd, and Ilya seems to have found a solution. Could you try putting the attached patch-res.c into the irc/unreal/files/ directory and rebuilding UnrealIRCd? If this patch helps, I could commit it if Gerrit Beine does not mind. Actually, here's another patch from Ilya who wrote to me privately to say that the previous one didn't quite work. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This would easier understand fewer had omitted. pgpounnPIOT9F.pgp Description: PGP signature
Re: Unrealircd problems with last patch
On Thu, Jun 18, 2009 at 05:07:08PM +0300, Peter Pentchev wrote:
On Wed, Jun 17, 2009 at 11:52:02AM +0300, Peter Pentchev wrote:
On Wed, Jun 17, 2009 at 08:24:38AM +0200, Andrea 'simplex' Zulato wrote:
Hi, i've upgraded c-ares and Unreal from ports but Unreal won't work.
It start without a problem but when someone try to connect to the server
it crash with a core dump error:
Jun 16 09:03:33 hazard kernel: pid 57652 (ircd), uid 0: exited on signal
11 (core dumped)
I've tried to recompile unreal and c-ares whitout any result (make
install finish without problems on both ports).
If there's something that i could try, please tell me...
I'm on a FreeBSD 7.2-RELEASE-p1 #0.
Hi,
I've CC'd Gerrit Beine (the actual maintainer of the irc/unreal port :)
and Ilya Andreev, who reported the same problem to me yesterday.
Some time ago, I sent my proposed c-ares update for testing to all
the maintainers of ports that depend on c-ares directly. My patches
made the ports compile, but I didn't have the proper setup to actually
test them working, since I'm not quite familiar with the programs
themselves. Thus, I asked the maintainers for help with testing, and
after nobody replied for a week or so, I went ahead and commited the update.
Now Ilya Andreev and you have both hit a problem with UnrealIRCd,
and Ilya seems to have found a solution. Could you try putting
the attached patch-res.c into the irc/unreal/files/ directory and
rebuilding UnrealIRCd? If this patch helps, I could commit it if
Gerrit Beine does not mind.
Actually, here's another patch from Ilya who wrote to me privately
to say that the previous one didn't quite work.
And once again, with the patch inline this time, mainly for the benefit
of the ports@ mailing list and other poor souls who might stumble upon
this problem.
G'luck,
Peter
--- src/res.c 2006-09-19 15:45:18.0 +0300
+++ src/res.c 2009-06-17 17:50:18.0 +0300
@@ -48,10 +48,15 @@
#include res.h
+/* Prevent crashes due to invalid prototype/ABI */
+#if ARES_VERSION 0x010600
+ #error You have an old c-ares version on your system and/or Unreals c-ares
failed to compile!
+#endif
+
/* Forward declerations */
-void unrealdns_cb_iptoname(void *arg, int status, struct hostent *he);
-void unrealdns_cb_nametoip_verify(void *arg, int status, struct hostent *he);
-void unrealdns_cb_nametoip_link(void *arg, int status, struct hostent *he);
+void unrealdns_cb_iptoname(void *arg, int status, int timeouts, struct hostent
*he);
+void unrealdns_cb_nametoip_verify(void *arg, int status, int timeouts, struct
hostent *he);
+void unrealdns_cb_nametoip_link(void *arg, int status, int timeouts, struct
hostent *he);
void unrealdns_delasyncconnects(void);
static unsigned int unrealdns_haship(void *binaryip, int length);
static void unrealdns_addtocache(char *name, void *binaryip, int length);
@@ -240,7 +245,7 @@
#endif
}
-void unrealdns_cb_iptoname(void *arg, int status, struct hostent *he)
+void unrealdns_cb_iptoname(void *arg, int status, int timeouts, struct hostent
*he)
{
DNSReq *r = (DNSReq *)arg;
DNSReq *newr;
@@ -290,7 +295,7 @@
}
-void unrealdns_cb_nametoip_verify(void *arg, int status, struct hostent *he)
+void unrealdns_cb_nametoip_verify(void *arg, int status, int timeouts, struct
hostent *he)
{
DNSReq *r = (DNSReq *)arg;
aClient *acptr = r-cptr;
@@ -363,7 +368,7 @@
unrealdns_freeandremovereq(r);
}
-void unrealdns_cb_nametoip_link(void *arg, int status, struct hostent *he)
+void unrealdns_cb_nametoip_link(void *arg, int status, int timeouts, struct
hostent *he)
{
DNSReq *r = (DNSReq *)arg;
int n;
@@ -390,9 +395,11 @@
/* fatal error while resolving */
sendto_realops(Unable to resolve hostname '%s', when trying to
connect to server %s.,
r-name, r-linkblock-servername);
+ r-linkblock-refcount--;
unrealdns_freeandremovereq(r);
return;
}
+ r-linkblock-refcount--;
#ifdef INET6
if (((he-h_length != 4) (he-h_length != 16)) ||
!he-h_addr_list[0])
@@ -715,21 +722,34 @@
} else
if (*param == 'i') /* INFORMATION */
{
- struct ares_config_info inf;
+ struct ares_options inf;
int i;
+ int optmask;
- ares_get_config(inf, resolver_channel);
+ ares_save_options(resolver_channel, inf, optmask);
sendtxtnumeric(sptr, ** DNS Configuration Information
**);
sendtxtnumeric(sptr, c-ares version: %s,ares_version(NULL));
- sendtxtnumeric(sptr, timeout: %d, inf.timeout);
- sendtxtnumeric(sptr, tries: %d, inf.tries);
- sendtxtnumeric(sptr,# of servers: %d, inf.numservers);
- for (i = 0; i inf.numservers; i
Re: Unrealircd problems with last patch
On Wed, Jun 17, 2009 at 08:24:38AM +0200, Andrea 'simplex' Zulato wrote: Hi, i've upgraded c-ares and Unreal from ports but Unreal won't work. It start without a problem but when someone try to connect to the server it crash with a core dump error: Jun 16 09:03:33 hazard kernel: pid 57652 (ircd), uid 0: exited on signal 11 (core dumped) I've tried to recompile unreal and c-ares whitout any result (make install finish without problems on both ports). If there's something that i could try, please tell me... I'm on a FreeBSD 7.2-RELEASE-p1 #0. Hi, I've CC'd Gerrit Beine (the actual maintainer of the irc/unreal port :) and Ilya Andreev, who reported the same problem to me yesterday. Some time ago, I sent my proposed c-ares update for testing to all the maintainers of ports that depend on c-ares directly. My patches made the ports compile, but I didn't have the proper setup to actually test them working, since I'm not quite familiar with the programs themselves. Thus, I asked the maintainers for help with testing, and after nobody replied for a week or so, I went ahead and commited the update. Now Ilya Andreev and you have both hit a problem with UnrealIRCd, and Ilya seems to have found a solution. Could you try putting the attached patch-res.c into the irc/unreal/files/ directory and rebuilding UnrealIRCd? If this patch helps, I could commit it if Gerrit Beine does not mind. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This inert sentence is my body, but my soul is alive, dancing in the sparks of your brain. pgp9sY6QwwSdg.pgp Description: PGP signature
Re: Unrealircd problems with last patch
On Wed, Jun 17, 2009 at 11:52:02AM +0300, Peter Pentchev wrote:
On Wed, Jun 17, 2009 at 08:24:38AM +0200, Andrea 'simplex' Zulato wrote:
Hi, i've upgraded c-ares and Unreal from ports but Unreal won't work.
It start without a problem but when someone try to connect to the server
it crash with a core dump error:
Jun 16 09:03:33 hazard kernel: pid 57652 (ircd), uid 0: exited on signal
11 (core dumped)
I've tried to recompile unreal and c-ares whitout any result (make
install finish without problems on both ports).
If there's something that i could try, please tell me...
I'm on a FreeBSD 7.2-RELEASE-p1 #0.
Hi,
I've CC'd Gerrit Beine (the actual maintainer of the irc/unreal port :)
and Ilya Andreev, who reported the same problem to me yesterday.
Some time ago, I sent my proposed c-ares update for testing to all
the maintainers of ports that depend on c-ares directly. My patches
made the ports compile, but I didn't have the proper setup to actually
test them working, since I'm not quite familiar with the programs
themselves. Thus, I asked the maintainers for help with testing, and
after nobody replied for a week or so, I went ahead and commited the update.
Now Ilya Andreev and you have both hit a problem with UnrealIRCd,
and Ilya seems to have found a solution. Could you try putting
the attached patch-res.c into the irc/unreal/files/ directory and
rebuilding UnrealIRCd? If this patch helps, I could commit it if
Gerrit Beine does not mind.
Hmm, that's funny. I keep forgetting that sometimes mailing lists
may strip attachments :) Here's the patch (sorry if you're receiving
it twice)
G'luck,
Peter
diff -u -r1.1.1.1.6.1.2.71.2.26 -r1.1.1.1.6.1.2.71.2.27
--- src/res.c 2009/02/01 16:43:33 1.1.1.1.6.1.2.71.2.26
+++ src/res.c 2009/05/13 10:28:06 1.1.1.1.6.1.2.71.2.27
@@ -722,21 +722,34 @@
} else
if (*param == 'i') /* INFORMATION */
{
- struct ares_config_info inf;
+ struct ares_options inf;
int i;
+ int optmask;
- ares_get_config(inf, resolver_channel);
+ ares_save_options(resolver_channel, inf, optmask);
sendtxtnumeric(sptr, ** DNS Configuration Information
**);
sendtxtnumeric(sptr, c-ares version: %s,ares_version(NULL));
- sendtxtnumeric(sptr, timeout: %d, inf.timeout);
- sendtxtnumeric(sptr, tries: %d, inf.tries);
- sendtxtnumeric(sptr,# of servers: %d, inf.numservers);
- for (i = 0; i inf.numservers; i++)
- sendtxtnumeric(sptr, server #%d: %s, i+1,
inf.servers[i] ? inf.servers[i] : [???]);
-
- /* TODO: free or get memleak ! */
+
+ if(optmask ARES_OPT_TIMEOUTMS)
+ sendtxtnumeric(sptr, timeout: %d,
inf.timeout);
+ if(optmask ARES_OPT_TRIES)
+ sendtxtnumeric(sptr, tries: %d, inf.tries);
+ if(optmask ARES_OPT_SERVERS)
+ {
+ sendtxtnumeric(sptr,# of servers: %d,
inf.nservers);
+ for (i = 0; i inf.nservers; i++)
+ sendtxtnumeric(sptr, server #%d: %s,
i+1, inet_ntoa(inf.servers[i]));
+ }
+ if(optmask ARES_OPT_DOMAINS)
+ {
+ sendtxtnumeric(sptr,# of search domains: %d,
inf.ndomains);
+ for (i = 0; i inf.ndomains; i++)
+ sendtxtnumeric(sptr, domain #%d: %s,
i+1, inf.domains[i]);
+ }
sendtxtnumeric(sptr, ** End of DNS Configuration Info
**);
+
+ ares_destroy_options(inf);
} else /* STATISTICS */
{
sendtxtnumeric(sptr, DNS CACHE Stats:);
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
I am the thought you are now thinking.
pgpJSC2VMwUOx.pgp
Description: PGP signature
Re: Installing files to PREFIX and LINUXBASE - is it possible?
On Thu, Jun 11, 2009 at 04:38:58AM +0400, Yuri Pankov wrote: Hi, I'm trying to create port of linux version of Gens (Sega Genesis/CD/32X emulator). Benefits of using linux version are most recent release and ability to run it on amd64 (native version doesn't compile on amd64). However, I need to install binary to PREFIX and some files should go to /usr/share/gens (paths are hardcoded, checked with ktrace, gens is trying to open /usr/share/gens/file or /compat/linux/usr/share/gens/file), and installing to /usr isn't really an option, so LINUXBASE/usr/share/gens looks like an only choice. Installing everything under LINUXBASE doesn't look like option too - /compat/linux/usr/bin isn't in path by default. Is it possible at all (and welcomed) and how would I create pkg-plist in this case or are there any other solutions? I've attached shar of what's there at the moment (with incorrect pkg-plist). You could install to $LINUXBASE and just make a symlink for the binary itself into $PREFIX/bin/. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the thought you are now thinking. pgpQjA3lT1z8b.pgp Description: PGP signature
Re: make.conf no x option
On Tue, May 26, 2009 at 08:32:50PM +0900, Randy Bush wrote: as so many folk build server-only, there must e a make.conf or whatever option to tell ports that you just do not want an x server or any of it's 500kg friends. but i can not seem to find it. i do cvsup-without-gui, emacs-nox11, etc. but one mistake with some port, and you get the whole boatload, and you can never scrape it all out. I think you're looking for WITHOUT_X11=yes :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence contradicts itself - or rather - well, no, actually it doesn't! pgp2ym69pKw2J.pgp Description: PGP signature
Re: squidguard and default blacklists in plist
On Thu, Apr 09, 2009 at 11:45:45AM +0200, Guido Falsi wrote: Hi, I'm the maintainer of the www/squidguard port. Some time ago I have been asked to try not make the port remove the blacklists when, after installing the default ones, they were modified by the user. [snip] I have few options at this point: The usual approach is to install them as .dist or .sample or something like that, copy them with their real names, and only remove the real ones if they are the same as the sample ones. This involes several steps: - modify the upstream source to install them with a .dist or .sample extension, or install them in a different subdirectory if the program will process them even with a different extension; - modify pkg-plist to refer to the sample files, not the real ones; - when installing, use either pkg-plist's @exec directive or a pkg-install script to check if the real files exist and, if they don't, copy the .dist file to one with the real filename; - when deinstalling, use either pkg-plist's @unexec directive or a pkg-install script to check if the real files are the same as the sample ones and, if they are, remove them. For an example of doing this with a .dist extension, take a look at the mail/vpopmail port's handling of the etc/vpopmail.mysql and etc/vlimits.default files: - files/patch-Makefile.in installs them as .dist files; - pkg-plist contains the .dist files; - pkg-plist contains an @exec if [ ! -f ... ]; then cp... - pkg-plist contains an @unexec if cmp -s ...; then rm... G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I had to translate this sentence into English because I could not read the original Sanskrit. pgphb2JflP2qc.pgp Description: PGP signature
Re: nmap broken on current
*)' with 'C++' linkage nmap.cc:2705: error: conflicts with new declaration with 'C' linkage nmap.h: In function 'int nmap_fetchfile(char*, int, const char*)': nmap.h:436: error: previous declaration of 'int nmap_fetchfile(char*, int, const char*)' with 'C++' linkage nmap.cc:2709: error: conflicts with new declaration with 'C' linkage nmap.cc: At global scope: nmap.cc:2837: error: expected `}' at end of input gmake[1]: *** [nmap.o] Error 1 gmake[1]: Leaving directory `/usr/ports/security/nmap/work/nmap-4.76' gmake: *** [all] Error 2 *** Error code 1 Stop in /usr/ports/security/nmap. Manfred Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If there were no counterfactuals, this sentence would not have been paradoxical. pgpkHt4S7PoA8.pgp Description: PGP signature
Re: Installing in cgi-bin
On Sat, Mar 28, 2009 at 06:42:50PM -0500, Brooks Davis wrote:
On Sat, Mar 28, 2009 at 04:07:30PM -0400, Jerry wrote:
On Sat, 28 Mar 2009 12:43:13 -0500
Brooks Davis bro...@freebsd.org wrote:
On Sat, Mar 28, 2009 at 01:33:15PM -0400, Jerry wrote:
I have a Perl program that I am thinking of porting to FreeBSD. The
program has to be installed in the 'cgi-bin'.
I was thinking something like:
$(WWWDIR}/apache${APACHE_VERSION}/cgi-bin might be the way to
direct the install to the correct directory. Is there a better way?
I cannot find a macro that directly references the cgi-bin.
We have a policy against installations that would automaticlly be on
the network. You need to install it elsewhere (often a directory
under WWWDIR) and tell people how to add the appropriate configuration
directives to http.conf or to copy the file into cgi-bin in
pkg-message.
The program is DADA Mail. It installs a 'mail.cgi' in the cgi-bin and
then installs the rest of its files, perl modules, etc. in a hierarchy
several layers deep in the cgi-bin directory. We are talking
about a lot of files here. Expecting the end user to properly move the
files from a temporary directory to the cgi-bin and then properly
changing the file(s) properties would seem a little extreme. However,
if that is the only way I can do it, I will investigate writing a
script that the end user could invoke to accomplish this feat. It does
seem a little over the top however. Due to the way DADA Mail is
written, the author does not believe it can be run from other than that
directory along with its associated files.
Sounds seriously broken. :) I might suggest installing in www/dada and
providing a script to make appropriate symlinks along with an instruction
to enable following symlinks in cgi-bin. It seems like shockingly bad
design to require that it live at http://.../cgi-bin/mail.cgi, but
that's certainly not uncommon. :(
Jerry, take a look at how other ports do it - e.g. mail/qmailadmin
or devel/viewvc. Both of those install files into separate directories
and then expect the user to symlink the CGI directory to something
within the user's real cgi-bin directory, and possibly symlink a data
directory into something within the user's real data directory.
Thus, the CGI script is at http://hostname/cgi-bin/qmailadmin/qmailadmin.cgi
with the option of someday adding e.g. cgi-bin/qmailadmin/somethingelse.cgi
by simply placing it within the symlinked directory.
Of course, the symlinks may also be avoided by using Apache's Alias and
ScriptAlias directives :)
Either way, the major point is that once you learn to live with all
files being in cgi-bin/progname/ instead of just cgi-bin/, it's just
a matter of symlinking (or aliasing) a single directory instead of
each and every file within it.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
.siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI
pgpioOldm8pFe.pgp
Description: PGP signature
Re: always-interactive ports
On Mon, Nov 24, 2008 at 12:47:13PM +, RW wrote: On Mon, 24 Nov 2008 13:55:55 +0200 Andriy Gapon [EMAIL PROTECTED] wrote: I wonder if we have any flag for always-interactive ports i.e. ports that prompt user for something regardless of all batch/interactivity options. One example is java/jdk* ports that prompt user for license acceptance. If we don't have such a flag, maybe we should add one. One use, for instance, is to skip such ports for portupgrade --batch. From man ports: INTERACTIVE If defined, only operate on a port if it requires interaction. BATCH If defined, only operate on a port if it can be installed 100% automatically. That's from the building user's point of view. The easiest way to handle this in the port itself is to set IS_INTERACTIVE=yes in the port's Makefile, as documented in bsd.port.mk. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If wishes were fishes, the antecedent of this conditional would be true. pgpSo2cWoVW39.pgp Description: PGP signature
Re: Source install to look like installed package
On Wed, Sep 17, 2008 at 04:40:59PM -0400, Francisco Reyes wrote: Matthew Seaman writes: You mean you want to generate a /var/db/pkg/portname-1.2.3 directory with appropriate contents so you can wrangle a bunch of files already on your hard drive as if they were a port? Yes. Actually, that's pretty much what the ports system does when you do an install from source. Check out the commands the 'do-package' target runs as shown in /usr/ports/Mk/bsd.port.mk Ok. Submitting PRs with updates to bring the FreePascal port up to date will earn you karma points... I am thinking perhaps start out with a binary port or a package until I get familiar with the port system. In most cases that's actually a bit harder than doing a simple port :) Of course, there are applications that do not lend themselves to porting simply, but in most cases even the Quick Porting procedure described in the Porters Handbook[1] is enough to get you a working, albeit not picture-perfect, package. [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 You have, of course, just begun reading the sentence that you have just finished reading. pgpJvoNTRvwDE.pgp Description: PGP signature
Re: devel/libtool15 unconditionally hardcodes autodetected textproc/gsed
On Tue, Sep 09, 2008 at 05:20:06PM +0400, Dmitry Marakasov wrote: * Alexey Shuvaev ([EMAIL PROTECTED]) wrote: While the ports are in freeze just want to point to the problem I have encountered. Not sure if this is a critical bug, just a bug or not a bug at all (so, no PR yet). This is definitely a bug, so better send-pr for this issue not to be lost while we're in freeze. I think Alexey's point might have been that this should be fixed during the freeze, before 6.4 and 7.1 ship with the ports tree - and I think it might be a good idea, if libtool uses sed (resp. gsed) in any files in the already-built target application / library. From a quick look, that does not seem to be the case, but if it is, it's important. What I mean is the following scenario: - libfoo uses libtool for its build - libfoo depends on libbar which depends on GNU sed - during libfoo's build, libbar is built, thus gsed is installed - during libfoo's build, libtool detects gsed installed and remembers it - in libfoo's binary package, there is a shell script that uses gsed, because libtool knows gsed is present on the system - an unsuspecting user installs the libfoo binary package without previously building libbar - the unsuspecting user gets a shell script that tries to run gsed and fails. Of course, this all hinges on the idea that libtool uses gsed in any files that are part of the binary package. From a quick look, the .la files do not contain any shell commands apart from variable assignments, but I'm not too familiar with libtool and I don't know if there are any other files that it might generate in the binary package. If libtool may put gsed into libfoo's binary package, this should be fixed before the freeze. If libtool only uses gsed during libfoo's build, then it is not a critical problem. Of course, if Dmitry is more familiar with libtool than I am, and he knows that libtool does not leave any such files, then I've just wasted everybody's time with unneeded idle speculation, for which I apologize :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 No language can express every thought unambiguously, least of all this one. pgprZ8yIal68Y.pgp Description: PGP signature
Re: Curious problem with MASTER_SITE_GOOGLE_CODE
On Mon, Sep 01, 2008 at 12:57:26PM -0700, Doug Barton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I need to move one of my ports to the google code site, and ran into a problem where in spite of the fact that PROJECTHOST is not defined, it still tries to use it: = Net-DNS-Fingerprint-0.9.3.tar.gz doesn't seem to exist in /usr/local/distfiles/. = Attempting to fetch from http://.googlecode.com/files/. fetch: http://.googlecode.com/files/Net-DNS-Fingerprint-0.9.3.tar.gz: No address record = Attempting to fetch from http://fpdns.googlecode.com/files/. Net-DNS-Fingerprint-0.9.3.tar.gz 100% of 10 kB 1570 kBps echo x`make -V PROJECTHOST`x xx make -V MASTER_SITE_GOOGLE_CODE http://.googlecode.com/files/ http://fpdns.googlecode.com/files/ Any ideas? That's... kinda weird. With what I see in bsd.sites.mk (rev. 1.455), MASTER_SITE_GOOGLE_CODE should *never* have *both* forms defined - unless you have somehow managed to include bsd.sites.mk twice, and even then something is too weird. Can you post the port's Makefile? G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 The rest of this sentence is written in Thailand, on pgpeThfLYK8yW.pgp Description: PGP signature
Re: Curious problem with MASTER_SITE_GOOGLE_CODE
On Mon, Sep 01, 2008 at 02:52:25PM -0700, Doug Barton wrote: On Tue, 2 Sep 2008, Peter Pentchev wrote: That's... kinda weird. With what I see in bsd.sites.mk (rev. 1.455), MASTER_SITE_GOOGLE_CODE should *never* have *both* forms defined - unless you have somehow managed to include bsd.sites.mk twice, and even then something is too weird. Agreed on all counts. :) Can you post the port's Makefile? ports/dns/fpdns/Makefile Okay then, with rev. 1.7 of ports/dns/fpdns/Makefile, both on my RELENG_6 machine (as of about 12 hours ago) and on the 7.0-STABLE from April on freefall, make -V MASTER_SITES shows only the correct ones: [EMAIL PROTECTED] ~/fbsd/ports/dns/fpdns] make -V MASTER_SITES http://fpdns.googlecode.com/files/ http://dougbarton.us/Downloads/ [EMAIL PROTECTED] ~/fbsd/ports/dns/fpdns] I'm starting to think you have something strange either in your environment or in /etc/make.conf or something. Could you post the output of printenv and (the relevant parts of) /etc/make.conf? G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am not the subject of this sentence. pgpgmSQ6WgaYd.pgp Description: PGP signature
Re: pkg_add feature proposal
On Mon, Aug 25, 2008 at 05:48:06AM -0700, Jeremy Chadwick wrote: On Mon, Aug 25, 2008 at 02:37:16PM +0300, Anton - Valqk wrote: Hi everyone, I've just got an Idea (maybe others had it too?). When doing pkg_add [-r] wouldn't it be better if pkg_add checks if _all_ dependent packages exists and checksums are ok (after downloaded if with -r), etc. checks _before_ installing the packages, because if you get 3-4 packages broken/missing when one package depends on 30-40 (X apps etc.) you should delete all already installed... I've got this problem when did pkg_add -r mod_musicindex and for some reason mod_musicindex didn't build the flac and libogg when $ make package-recursive specified. When the pkg_add get to these packages and they were not found on the web server, I've had to delete all installed packages by hand... uhh... so, what would you say about that? I'd say it's a great idea (and an ideal idea), but it's not easily implementable. Where would pkg_add get its list of dependencies from? The port Makefile? And what if the user doesn't have ports installed? This is one of the many quirks of the ports vs. package system. Well, pkg_add *already* gets the list of dependencies from the .tbz file that it is either passed on the command line or it downloads. I believe that Anton is asking for a bit more separation between the fetch all packages to be installed and the install all fetched (fought?) packages phases of pkg_add's operation. However, given the way that pkg_add operates by invoking itself recursively, it might not be easy to do this without a major rewrite and algorithm change. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 No language can express every thought unambiguously, least of all this one. pgpUuzGObLGgm.pgp Description: PGP signature
Re: Vlc
On Thu, Jul 17, 2008 at 04:11:37PM +0200, Tino Engel wrote: On Thu, 17 Jul 2008 14:18:33 +0300 Okalany Daniel [EMAIL PROTECTED] wrote: Is there a way to install vlc media player without the X11 or any other gui tools? WITHOUT_X11 doesn't seem to be working hmmm. it is a movie player... without_x11 would not make too much sense though... for listening to audio files look at mpg123 for mp3 or at mpc for any kind of audio format. Actually vlc does a great job of transcoding files and providing streamed movie playing (rtsp:// and stuff), and it definitely does not need an X display for that :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? pgpZoEPtRbQTe.pgp Description: PGP signature
Re: FreeBSD Port: openldap-server-2.4.10
On Fri, Jul 04, 2008 at 10:34:32PM -0400, Mikhail Goriachev wrote:
Quoting Peter Pentchev [EMAIL PROTECTED]:
On Fri, Jul 04, 2008 at 01:22:15PM -0400, Mikhail Goriachev wrote:
Hi,
[snip]
I slapped together a workaround. Here's a patch, maybe the idea of
it will be of some use.
Just a minor comment on the patch:
+DBDIR=`grep directory /usr/local/etc/openldap/slapd.conf | awk '{
print $2 }'`
This is better written as
awk '/directory/ {print $2}' /usr/local/etc/openldap/slapd.conf
Nice one!
or possibly (I'm not quite familiar with the slapd.conf syntax) even:
awk '$1 == directory {print $2}' /usr/local/etc/openldap/slapd.conf
They both work but I like the first one more.
Actually the second one might be better - the first one may be confused
by the string directory appearing either in a comment or in the string
value of some other parameter or even in the *name* of some other
parameter.
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This sentence was in the past tense.
pgpO1jGnVO9tD.pgp
Description: PGP signature
Re: FreeBSD Port: openldap-server-2.4.10
On Fri, Jul 04, 2008 at 01:22:15PM -0400, Mikhail Goriachev wrote:
Hi,
[snip]
I slapped together a workaround. Here's a patch, maybe the idea of
it will be of some use.
Just a minor comment on the patch:
+DBDIR=`grep directory /usr/local/etc/openldap/slapd.conf | awk '{
print $2 }'`
This is better written as
awk '/directory/ {print $2}' /usr/local/etc/openldap/slapd.conf
or possibly (I'm not quite familiar with the slapd.conf syntax) even:
awk '$1 == directory {print $2}' /usr/local/etc/openldap/slapd.conf
Then there's another thing - it might be better to make this depend on
the actual prefix where the OpenLDAP server is installed (it is not
necessarily /usr/local), but that's a whole different can of beer that
I'm not familiar with, since I don't even have an OpenLDAP server
installed on my system :)
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This sentence is false.
pgpb8FQ50dCeY.pgp
Description: PGP signature
Re: devel/subversion : java + python bindings
On Wed, Jul 02, 2008 at 06:55:19PM +1000, Norberto Meijome wrote: Hi guys, thanks for the upgrade to subversion 1.5! Would it be possible to add back the WITH_JAVA and WITH_PYTHON knobs ? As far as I can see, they are available as separate ports now - devel/py-subversion and java/subversion-java, as well as devel/ruby-subversion and devel/p5-subversion for other languages. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If I had finished this sentence, pgppmUYEO9d3o.pgp Description: PGP signature
Re: how to determine the date a port is installed
On Tue, Jun 10, 2008 at 10:41:25PM -0700, Jeremy Chadwick wrote: On Wed, Jun 11, 2008 at 12:09:33AM -0500, Novembre wrote: Two questions: 1) Is it possible to determine the date a port/package is installed? ls -ld /var/db/pkg/port, use the mtime of the directory. 2) How can I delete all the ports/packages installed after a certain date? Use a combination of find with the -mtime flag, and pkg_delete. Not really. This is a bit dangerous. The dangerous part is the mtime of the directory. It would be much better to use the mtime of the +CONTENTS file, since it never changes *after* the package has been installed. It is possible, though not certain, that the mtime of the directory may change if another package is installed later which depends on this one - pkg_add(1) then updates some files, most notably +REQUIRED_BY, to reflect the new dependency, so that pkg_delete(1) may warn you later if you try to delete something that other packages depend on. Of course, the part with the mtime of the directory may change depends a bit on the filesystem used, but I find it easier to just rely on the +CONTENTS file that I'm sure should never change - unless I edit it by hand, but then all bets are off :) Novembre, you might want to try something like: # Change the working directory for easier path handling cd /var/db/pkg # Create a temporary file with the modification time set to the date # that you want to examine (in this case, May 15, 2008, 11:00am) touch -t 200805151100 /tmp/stamp # Find all +CONTENTS files that have a modification time later than that # of the stamp file find . -type f -name '+CONTENTS' -mnewer /tmp/stamp # Extend the previous command - get only the second component of the # file path, which is the name of the package directory, which coincides # with the name of the package :) find . -type f -name '+CONTENTS' -mnewer /tmp/stamp | cut -d/ -f2 That should give you a list; you may redirect it to a file or, if you are feeling really adventurous, just pipe it to | xargs pkg_delete :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I had to translate this sentence into English because I could not read the original Sanskrit. pgpVoLOmQ9urw.pgp Description: PGP signature
Re: Where should contrib scripts and utilities be installed?
On Mon, Jun 09, 2008 at 08:54:49PM -0400, Sahil Tandon wrote: Jeffrey Goldberg [EMAIL PROTECTED] wrote: When some project includes a contrib/ directory with its source where should those canonically be installed? /usr/local/share/$PORT or /usr/local/share/doc/$PORT or someplace else. In particular, I'm planing on submitting a patch to sysutils/rsnapshot port to also install, somewhere, the contrib directly that comes out of the tarball. The existence of ports with a -contrib suffix suggests you may need to create a distinct port for the contrib files. databases/postgresql-contrib, for example. Actually, that is not strictly necessary. There are other ports that do things in slightly different ways: - some things in contrib/ are merely documentation snippets that belong in share/doc/$PACKAGE, as Jeffery suggested - some things in contrib/ are sample additions, implementations, clients, add-ons and such that *might* belong in share/examples/$PACKAGE - some things in contrib/ are scripts, clients, add-ons and such that might also belong in libexec/$PACKAGE (if they are executable files) or share/$PACKAGE (if they are not... I can't think of any examples right now, but there might be) - some things in contrib/ are really best left in a separate port :) For rsnapshot itself - erm, I don't see a contrib/ directory in its source; do you mean the utils/ directory, or are you looking at some version that is not in the Ports Collection yet? :) If it is utils/ that you mean, then, well, it's actually your choice - the things there seem to be little scripts that may live in $EXAMPLESDIR, may live in libexec/rsnapshot/, and may live in a separate rsnapshot-utils port. Either way would be fine, at least IMHO. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? pgptdjFXaz8cn.pgp Description: PGP signature
Re: FreeBSD Port: sysutils/daemontools
On Sun, Jun 08, 2008 at 09:39:45AM -0400, William Olson wrote: Hello, I am having issues installing daemontools from the ports system. Please see below: whateva# pwd /usr/ports/sysutils/daemontools whateva# make install clean === Vulnerability check disabled, database not found === Found saved configuration for daemontools-0.76_12 = daemontools-0.76-man-20010714.tar.gz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch from http://smarden.org/pape/djb/manpages/. fetch: http://smarden.org/pape/djb/manpages/daemontools-0.76-man-20010714.tar.gz: Operation timed out Hmm, looks like there's some sort of problem with Gerritt Pape's site where the port tries to fetch the manual pages from. Right now, you can fetch the daemontools-0.76-man-20010714.tar.gz from my FreeBSD site - http://people.FreeBSD.org/~roam/ports/sysutils/daemontools/daemontools-0.76-man-20010714.tar.gz I've placed the file in the publicly mirrorred directory, so it will appear on other mirrors, too; once it does, I'll add this local distribution site to the port, too. = Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/. fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/daemontools-0.76-man-20010714.tar.gz: File unavailable (e.g., file not found, no access) Yep, as explained below, the port has been marked RESTRICTED for ages and I've not changed that since December; thus, the package building cluster does not try to build it, and the distribution files have not appeared on the FreeBSD FTP site. This will change soon. = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles/ and try again. *** Error code 1 Stop in /usr/ports/sysutils/daemontools. *** Error code 1 Stop in /usr/ports/sysutils/daemontools. whateva# I took a look at freshports this morning and saw this: http://www.freshports.org/search.php?query=daemontoolssearch=gonum=10stype=namemethod=matchdeleted=excludedeletedstart=1casesensitivity=caseinsensitive It looks like it's now restricted? Please let me know. It's not restricted now; the port has had the RESTRICTED line in its Makefile ever since version 1.1 (well, okay, it was NO_PACKAGE then) about nine years ago :) It's quite another question that I haven't removed it after Prof. Bernstein put all his software in the public domain in December 2007; I'll do so soon, right after the files I've placed in my FreeBSD home directory are mirrorred onto the FTP sites. Thanks for the heads-up! G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Thit sentence is not self-referential because thit is not a word. pgp1aNba0T0Ib.pgp Description: PGP signature
Re: net/grsync fails to build on i386
On Tue, Mar 25, 2008 at 08:46:47PM +0100, Ganael LAPLANCHE wrote: Hi everybody, I try to understand what happens here : http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.2008032407/grsync-0.6.1.log Since yesterday, my net/grsync port seems to refuse to build on i386. The configure script uses (expanded) : pkg-config --exists --print-errors 'gtk+-2.0' which leads to the error 'No package 'gtk+-2.0' found'. This error message is clear. What I don't understand is that the dependency against gtk20 is explicitly specified in the Makefile, so why has gtk+-2.0 not been installed during the build process (and does not appear in the log file) ? Am I missing something ? It is quite possible that you caught the small time window just after the GNOME upgrade, in which bsd.gnome.mk was missing two lines that recorded LIB_ and RUN_DEPENDS. Thus, even though you specified gtk20 in your port's Makefile, bsd.gnome.mk just didn't add a dependency on libgtk - so your port's build did not find it. Since this was corrected a couple of hours later, I strongly suspect that the next automated build will go just fine. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am not the subject of this sentence. pgpRPJtpCA9bC.pgp Description: PGP signature
Re: Transferring ports
On Fri, Mar 14, 2008 at 12:02:42AM +0300, Dmitry Marakasov wrote:
* Ivan Voras ([EMAIL PROTECTED]) wrote:
Is there a utility that would do that, and if not, does anyone have the
time to write one?
Actually, I've already had an idea of utility with pretty similar
functionality for a long time. The utility would copy directory
hierarchies recursively based on file include/exclude list, like this:
+/{etc,bin,sbin,lib}
+/usr
-/usr/local
+/usr/local/{bin,sbin,libexec,share,lib}
-/usr/share/locale
+/usr/share/locale/ru_RU*
so `my_cool_copy_utility / /path/to/jail` will copy /etc,/bin,/sbin,/lib
and /usr dirs to jail, but in /usr/share/locale will only copy
russian locales, but no others, and in usr/local it won't copy
man, include and other dirs not needed in a jail.
The purpose is similar - creating jails out of host system in fast
and easy way, possibility to strip everything unneeded (useful for
secure minimal jails or flash/livecd/embedded installations of
minimal size) and add something extra, like stuff from /usr/local
without installing full packages in a jail, or, say, copying over
additional tree of jail-specific changes (mostly stuff under /etc
and /usr/local/etc).
Such an utility is something I still might start working on.
Err... why not use rsync for that? It works locally, too -
I use it to copy directories all over the place all the time.
Come to think of it... oh, just go install net/rsync, take a look at
its manual page and the FILTER RULES section in particular - it even
supports rules with prefixes, - for exclude, + for include, just
like you want them :) Well, okay, you might need to list separate
directories on separate lines (it doesn't seem to support the {bin,sbin}
syntax), but other than that, it seems to fit your requirements pretty
well :)
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This sentence claims to be an Epimenides paradox, but it is lying.
pgpvZaprrNwIx.pgp
Description: PGP signature
Re: vdelivermail.c - dot-qmail processing, FreeBSD Port: vpopmail-5.4.26
On Sat, Mar 15, 2008 at 02:56:24PM +0100, Michal Sviba wrote: Hi Tom, there are some #ifdef quotas, but not exactly in part witch I mean. When I've done #diff between vdelivermail.c 5.4.25 and .26, there are no differences. But I've luckily found/repair the problem :))) Problem was in variable DeleteEmail witch is set just one time (DelteEmail = 1) and default is 0. So, I've tried this: vdelivermail.c:660 655 656 /* rewind the message */ 657 lseek(0,0L,SEEK_SET); 658 659 /* same env. for each line .qmail */ 660 DeleteMail = 0; // set default Great catch! I've just committed this patch to the FreeBSD port of vpopmail - probably as a band-aid that will go away with 5.4.27, but still quite important for the 5.4.26 users :) Thanks for tracking this down! G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. pgpxQw6TJnD0P.pgp Description: PGP signature
Re: net-im/openfire port related question.
On Wed, Feb 13, 2008 at 06:09:38PM +, Matthew Seaman wrote: Scot Hetzel wrote: On 2/13/08, Nikolay Pavlov [EMAIL PROTECTED] wrote: Hello all. I am a maintainer of the net-im/openfire port. I have a report from Dmitri Frolov [EMAIL PROTECTED] that openfire uses the same uid as security/stunnel port. Could someone please suggest me as how i can resolve this situation? If you look at security/cyrus-sasl2/pkg-install, it checks to see if the username exists, if it doesn't exist, then it checks if the uid is available, if it is not available, it increments the uid until it finds an available uid. Both ports should be using a similar routine to check if the uid/gid they are requesting is available. Actually, that's old hat. The current standard is that you should pick an otherwise unused UID (and/or GID) from /usr/ports/UIDs and register that as belonging to your port. Submit a maintainer update with patches to UIDs and GIDs plus modifications to the way the port is installed so that it uses the allocated numbers, and you're golden. If another port has a UID clash with yours and you have established rights by registering the uid in this way, then you can insist that the other port is changed to not clash with yours. ...and that's precisely what I did with the stunnel port five months ago, in rev. 1.48 of the ports/UIDs file :) Before that, stunnel just invoked pw groupadd and then pw useradd without any specific ID's, but now it always uses 341. Hmmm, that might indeed be a problem if this user ID is already taken by another account on the user's system; I'll see if I can work something out on the autodetection front, but my advice to Nikolay would be to pick another user ID and register it in the ports/UIDs file, at least for the benefit for people who have not yet installed openfire and shall do so for the first time in the future :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence would be seven words long if it were six words shorter. pgpoLDl19Fp2M.pgp Description: PGP signature
Re: FreeBSD Port: curl-7.16.3
On Tue, Feb 12, 2008 at 12:32:30PM +, Ben Suffolk wrote: Hi, I was just wondering if there was a roadmap for updating curl to the latest version in ports? I've been working on it (reviewing the changes, testing on various architectures and options, etc) on and off for the past couple of weeks. It ought to be done in at most another week. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I've heard that this sentence is a rumor. pgpLWmxG8jcju.pgp Description: PGP signature
Re: Updating 'mail/freepops' port
On Sun, Dec 23, 2007 at 07:04:08AM -0500, Gerard wrote: On Sun, 23 Dec 2007 22:09:43 +1100 Edwin Groothuis [EMAIL PROTECTED] wrote: On Sat, Dec 22, 2007 at 06:47:01PM -0500, Gerard wrote: Evidently, the '/mail/freepops/' port does not have a maintainer. If I knew more about it, I would attempt to do it myself; however, that might well lead to a disaster. Just do it, we're here to hold your hand and guide you through it. Edwin Well, only if you promise. ;-) That's one of the purposes of this mailing list :) Seriously though, the only thing I have written are a few bash scripts. I guess I could attempt to work on this though. I'll download the Porters Hand book and start from there. Just a suggestion. It occurred to me that having a compressed copy of the Porters Hand book for downloading would be a good idea. I just checked, and it is something like 150 pages or so to download and print out. Actually, it is already available in archived form on the FreeBSD FTP server; check out this directory: ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/en_US.ISO8859-1/books/porters-handbook/ ...and, specifically, the book.html-split.tar.bz2 file there. It's just that there are no links to this directory on the FreeBSD website. BTW, who do I contact if (when) I need assistance? This list. That's what it's for :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? pgpjOpPksEyCO.pgp Description: PGP signature
Re: 'make -DNO_DEPENDS install' causing error
On Tue, Oct 30, 2007 at 01:24:13PM -0700, Doug Barton wrote: I'm really stumped on this one, and I'm wondering if someone can come up with something clever here. In the last revision of portmaster I changed the order of how things are installed (parent port first, then any run-depends) and added -DNO_DEPENDS to the make install line so that portmaster could handle installation of the run-depends. Errr... maybe I should actually take a careful look at portmaster first, but after a cursory look at portmaster.sh.in... how do you handle the case of a port installation that executes commands from a runtime dependency? That is, a runtime dependency that is actually used at install time, too? The first example that comes to mind is net/dictd-database, which uses the 'dictzip' utility from net/dictd in the install target, but surely there are lots of other similar examples :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence no verb. pgpEeSnOC3Kei.pgp Description: PGP signature
Re: 'make -DNO_DEPENDS install' causing error
On Wed, Oct 31, 2007 at 09:21:54AM -0700, Doug Barton wrote: On Wed, 31 Oct 2007, Peter Pentchev wrote: Errr... maybe I should actually take a careful look at portmaster first, but after a cursory look at portmaster.sh.in... how do you handle the case of a port installation that executes commands from a runtime dependency? That is, a runtime dependency that is actually used at install time, too? That should be a build dependency then. I'll take a look at the example you cited, but my gut feeling is that what you're describing shouldn't happen. Erm, nope... A build dependency is not meant to modify anything on the user's system, but the installation process may need to, say, rebuild indexes or otherwise update some kind of configuration. Think add-on packages - some of them might need some kind of registration in the main package's configuration. At least that's the way I see it, and ICBW, but I think that there are various legitimate cases when a run-time dependency ought to be installed before the package installation itself. For more examples, take a look at the plist of most X11 fonts (@exec fc-cache), most JDK implementations (@exec registervm), most docbook-* ports (@exec xmlcatmgr), some GNOME ports like gnomevfs (@exec gconftool-2), and many others. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the thought you are now thinking. pgpeTCkSXF0M5.pgp Description: PGP signature
Re: parallel builds revisited
On Tue, Apr 10, 2007 at 07:44:47PM +0200, Pav Lucistnik wrote: Benjamin Lutz p??e v ?t 10. 04. 2007 v 04:52 +0200: [snip] 3) Save this to /usr/local/etc/parallel_builds.conf: http://www.maxlor.com/temp/parallel_builds.conf . This is a list of ports as stored in PKGORIGIN, or as pkg_info -o reports them. I was thinking about having it embedded in every port's Makefile directly, instead. Something like USE_MAKE_JOBS=2 Funny that this discussion should come up here at about the same time as a very similar discussion on a Debian list :) IMHO, hardcoding the number of jobs in the port's Makefile would not be the best approach. I think a port should only flag whether it supports parallel building at all or not - and leave the number of jobs to either the ports framework or the administrator's choice. The ports framework may pick a value - ncpus, or ncpus+1, or ncpus*2, or something like that - but, again IMHO, the administrator ought to be able to override it in any case. Other than that, it's great that y'all are actually doing something about supporting parallel builds! :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence every third, but it still comprehensible. pgpQYpDRoDPEY.pgp Description: PGP signature
Re: irc/unreal
On Mon, Mar 26, 2007 at 08:00:50AM -0700, Jeremy Chadwick wrote:
On Sat, Mar 24, 2007 at 03:41:20PM +0300, sekes wrote:
I'm trying to build irc/unreal on 6.2-RELEASE and failing:
=== Building for Unreal-3.2.6
Building src
cc -I../include
-I/usr/ports/irc/unreal/work/Unreal3.2/extras/regexp/include -pipe
-I/usr/local/include -O2 -fno-strict-aliasing -pipe -funsigned-char
-fno-strict-aliasing -export-dynamic -L/usr/local/lib -c timesynch.c
cc -I../include
-I/usr/ports/irc/unreal/work/Unreal3.2/extras/regexp/include -pipe
-I/usr/local/include -O2 -fno-strict-aliasing -pipe -funsigned-char
-fno-strict-aliasing -export-dynamic -L/usr/local/lib -c res.c
res.c: In function `m_dns':
res.c:718: error: storage size of 'inf' isn't known
*** Error code 1
Stop in /usr/ports/irc/unreal/work/Unreal3.2/src.
*** Error code 1
Stop in /usr/ports/irc/unreal/work/Unreal3.2.
*** Error code 1
Stop in /usr/ports/irc/unreal.
[xnet] /usr/ports/irc/unreal#
Ideas?
I've discussed the problem on #bsdports on IRC in the past; dvl brought
it to my attention.
The problem, from my perspective, is this:
dns/c-ares was modified to support an OPTIONS knob for CONFIG_INFO.
This option *must be on*, and adds the ares_config_info patch, which
provides the necessary header information for type inf. irc/unreal
depends on this information.
Yep, I added the patch to c-ares especially for irc/unreal :) As a matter
of fact, I *took* it from the irc/unreal sources :)
The knob itself defaults to ON. However, for people who have built
dns/c-ares in the past (prior to this knob being added), there will
obviously be no support for ares_config_info.
Thus, you need to pkg_delete or deinstall dns/c-ares, and either rebuild
it (make clean make install) or let irc/unreal rebuild it for you.
I'm about 90% sure this is the problem, because when I heard of the
issue, I tried to reproduce it on two of my systems (neither of which
had ever built dns/c-ares or irc/unreal before), and I had no issue.
Ideally, what needs to happen is that the irc/unreal port needs to
check to make sure that the appropriate storage type (inf) is
available prior to irc/unreal being built. Usually this is done in
autoconf (and that makes it the responsibility of the authors of
Unreal). If there's some way the port itself could check to see if
dns/c-ares was built with CONFIG_INFO enabled (otherwise refuse to
build), that would be a workaround.
A run-time check would be nice, indeed. However, how about this as
an additional check at the dependencies' level?
Index: ports/irc/unreal/Makefile
===
RCS file: /home/ncvs/ports/irc/unreal/Makefile,v
retrieving revision 1.13
diff -u -r1.13 Makefile
--- ports/irc/unreal/Makefile 3 Jan 2007 15:29:54 - 1.13
+++ ports/irc/unreal/Makefile 27 Mar 2007 08:41:36 -
@@ -7,6 +7,7 @@
PORTNAME= Unreal
PORTVERSION= 3.2.6
+PORTREVISION= 1
CATEGORIES=irc ipv6
MASTER_SITES= http://www.ilmarinen.us/unreal/ \
http://unrealircd.alert-net.com/ \
@@ -20,7 +21,9 @@
MAINTAINER=[EMAIL PROTECTED]
COMMENT= Unreal - the next generation ircd
+BUILD_DEPENDS= c-ares-config=1.3.2:${PORTSDIR}/dns/c-ares
LIB_DEPENDS= cares.1:${PORTSDIR}/dns/c-ares
+RUN_DEPENDS= c-ares-config=1.3.2:${PORTSDIR}/dns/c-ares
WRKSRC=${WRKDIR}/${PORTNAME}3.2
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This sentence is false.
pgpmzyqN7erat.pgp
Description: PGP signature
Re: irc/unreal
On Sat, Mar 24, 2007 at 03:41:20PM +0300, sekes wrote: I'm trying to build irc/unreal on 6.2-RELEASE and failing: === Building for Unreal-3.2.6 Building src cc -I../include -I/usr/ports/irc/unreal/work/Unreal3.2/extras/regexp/include -pipe -I/usr/local/include -O2 -fno-strict-aliasing -pipe -funsigned-char -fno-strict-aliasing -export-dynamic -L/usr/local/lib -c timesynch.c cc -I../include -I/usr/ports/irc/unreal/work/Unreal3.2/extras/regexp/include -pipe -I/usr/local/include -O2 -fno-strict-aliasing -pipe -funsigned-char -fno-strict-aliasing -export-dynamic -L/usr/local/lib -c res.c res.c: In function `m_dns': res.c:718: error: storage size of 'inf' isn't known *** Error code 1 Stop in /usr/ports/irc/unreal/work/Unreal3.2/src. *** Error code 1 Stop in /usr/ports/irc/unreal/work/Unreal3.2. *** Error code 1 Stop in /usr/ports/irc/unreal. [xnet] /usr/ports/irc/unreal# Ideas? Do you have the c-ares library installed? What is the output of pkg_info | fgrep -e c-ares -e curl If this does not display a line saying c-ares-config-1.3.2, then you need to either upgrade or reinstall your c-ares library, with the ares_config_info patch. To do that: - deinstall anything that provides a libcares.so in your path (you can find out what it is by first running ldconfig -r | fgrep cares to find the library itself and then pkg_info -qW /usr/local/lib/libcares.so.1 to see which package has installed it) - cd /usr/ports/dns/c-ares - make config (as root) - make sure the CONFIG_INFO option is checked - make all install clean After that, try building unreal-ircd again. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence would be seven words long if it were six words shorter. pgp6I1XKbhnyT.pgp Description: PGP signature
Re: SQUID PACKAGE
On Thu, Mar 15, 2007 at 02:18:18PM -0400, Kris Kennaway wrote: On Thu, Mar 15, 2007 at 09:06:49PM +0500, VAD wrote: Hello. Please add to ports the package of Squid - 2.6.10 Thank you/ OK, miwi travelled back in time by 8 days and did it especially for you! :) Or maybe VAD is talking about a precompiled *package*, not port; and it does seem that on the FTP mirrors the squid package is still at 2.6.9. I guess this could be related to the pointyhat disk failures that you (Kris) mentioned yesterday, in which case, VAD, there will most probably be a squid-2.6.10 package in a couple of days' time. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I had to translate this sentence into English because I could not read the original Sanskrit. pgpuDMn4LHngI.pgp Description: PGP signature
Re: wireshark build problem...
On Fri, Feb 23, 2007 at 09:57:19AM -0500, Robert Huff wrote: Eric Schuele writes: On 02/21/2007 19:50, George W. Dinolt wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/108776 Unfortunately, the PR is closed because it is not reproducible. At Quite reproducible on my machine. :/ And mine, with both -0 and -02. Errr, did you actually try with -0 and -02? The gcc flags ought to be -O and -O2 - that's the letter O, not the digit 0... G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If this sentence didn't exist, somebody would have invented it. pgpZlBaSqwG7I.pgp Description: PGP signature
Re: HEADS UP : security/gnupg will be upgraded to 2.0.1
On Tue, Dec 12, 2006 at 05:46:50PM +0900, Jun Kuriyama wrote: At Mon, 11 Dec 2006 23:43:48 -0800, Doug Barton wrote: If this is your plan, it leads me to the next question, which is how are you going to handle the fact that GnuPG 2.x does not install a binary named gpg? Will you install a symlink if gnupg1 is not installed? And if so, will it CONFLICT with that port? If we are going to suggest to users that 2.x is the default, I think we need to provide support for those legacy(?) apps that think gnupg is spelled gpg. Yes, that's my difficult decision in this upgrade. I understand you care about existing users not to violate POLA, but I basically choose this way for new users. :-( If gpg binary consumer is ports-installed one and have explicit dependency on its Makefile, portupgrade -R gnupg will install security/gnupg *AND* security/gnupg1. But if is is not from ports, just only users from command line or have implicit dependency (like mail/mailcrypt which I'm using), only gpg2 binary is exist after portupgrade. I have no clue about last problem for now (only pkg-message or UPDATING). This maybe critical for casual portupgrade users. Err... I wonder... How about repo-copying (or rather, repo-moving) the current security/gnupg to security/gnupg1, and creating a new security/gnupg meta-port with runtime dependencies on *both* gnupg1 and gnupg2? G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If there were no counterfactuals, this sentence would not have been paradoxical. pgp5Oie29orrV.pgp Description: PGP signature
Re: [CFR] ftp/curl update and API incompatibility
On Fri, Dec 08, 2006 at 08:24:25PM +0200, Peter Pentchev wrote: On Fri, Dec 08, 2006 at 07:57:59PM +0200, Peter Pentchev wrote: On Wed, Dec 06, 2006 at 02:56:57PM +0200, Peter Pentchev wrote: Hi, I'm writing to you all because you are listed as maintainers of ports that depend directly on ftp/curl. Attached is a patch that updates ftp/curl to version 7.16.0; however, this update might need some testing. After some comments from some of the maintainers, here's an updated version of the patch, which also takes care of the ports that do not specify a shared library version in the curl dependency (i.e. they depend on curl, not curl.3). This patch also: - bumps the PORTREVISION of the ftp/php4-curl, ftp/php5-curl, and www/pecl-pecl_http ports; [snip] And of course, as Alex Dupre kindly pointed out, the PORTREVISION on php5-curl should be 1, not 2. Updated curl-16-03.patch available at http://people.FreeBSD.org/~roam/patches/curl/ Now, for final testing, curl-16-04.patch is available at http://people.FreeBSD.org/~roam/patches/curl/ It includes some catching-up with recent updates to astro/gaia (it compiles fine now), audio/herrie, audio/xmms2, comms/xastir, security/gnupg, and textproc/libnxml, as well as a fix to the (also updated) textproc/raptor so that the configure script actually uses curl-config --cflags and realizes that libcurl is, indeed, installed. If there are no objections, I'll commit the cURL update (and this patch) tomorrow. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if it weren't self-referential? pgptMBShEIGvc.pgp Description: PGP signature
Re: [CFR] ftp/curl update and API incompatibility
On Fri, Dec 08, 2006 at 07:57:59PM +0200, Peter Pentchev wrote: On Wed, Dec 06, 2006 at 02:56:57PM +0200, Peter Pentchev wrote: Hi, I'm writing to you all because you are listed as maintainers of ports that depend directly on ftp/curl. Attached is a patch that updates ftp/curl to version 7.16.0; however, this update might need some testing. After some comments from some of the maintainers, here's an updated version of the patch, which also takes care of the ports that do not specify a shared library version in the curl dependency (i.e. they depend on curl, not curl.3). This patch also: - bumps the PORTREVISION of the ftp/php4-curl, ftp/php5-curl, and www/pecl-pecl_http ports; [snip] And of course, as Alex Dupre kindly pointed out, the PORTREVISION on php5-curl should be 1, not 2. Updated curl-16-03.patch available at http://people.FreeBSD.org/~roam/patches/curl/ G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If this sentence didn't exist, somebody would have invented it. pgp7Zc63SflvD.pgp Description: PGP signature
Re: bsdstats 5.3 on 6-STABLE and netcat weirdness
On Wed, Dec 06, 2006 at 10:19:06PM +0800, LI Xin wrote:
Marc G. Fournier wrote:
'k, I don't know how to fix this one ... I thought about doing:
.if ${OSVERSION} = 492101
RUN_DEPENDS=nc:${PORTSDIR}/net/netcat
.endif
not sure which version brought in nc, but 492101 is the last of the 4.x
series
... but it portlint fails miserably if I don't put bsd.port.pre.mk before
it,
but also fails if I do:
WARN: Makefile: no MASTER_SITES found. is it ok?
WARN: Makefile: RUN_DEPENDS has to appear earlier.
0 fatal errors and 2 warnings found.
Is there a better way of doing this ... ?
I think you want something like:
.if ${OSVERSION} 503102 || (${OSVERSION} = 60 ${OSVERSION}
600010)
instead of just considering 492101.
That's a good suggestion.
Mark, as to the portlint problem - well, portlint cannot really be
expected to handle each and every corner case in a port Makefile :)
It is doing a wonderful job as it is, but every now and then you have
to make a choice between a working port and a clean port ;)
To make the OSVERSION check work, you do indeed need a bsd.port.pre.mk
inclusion before it. Then... just ignore the portlint warnings.
And... thanks for a great utility! :)
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
I am the meaning of this sentence.
pgpgfGwBpJiKC.pgp
Description: PGP signature
Re: FreeBSD Port: ftp/curl
On Thu, Jul 20, 2006 at 04:04:49PM -0500, Scot Hetzel wrote: On 7/20/06, Andrew Pantyukhin [EMAIL PROTECTED] wrote: I wonder if it's possible to resolve the situation when (defined(WITH_GNUTLS) !defined(WITHOUT_SSL)) in a friendlier way than a simple IGNORE. I have WITH_GNUTLS in my make.conf and I don't have WITHOUT_SSL there. It would be great if you could make the port choose on its own, either way would be perfect. I had a look at the ports Makefile, and there is only one thing that is holding the port back, from doing what you want... For the record, Scot sent me a patch to the ftp/curl port later on, and now I've committed it along with the update to cURL 7.15.5. Thanks a lot to Andrew for bringing this up, and to Scot for digging in and coming up with the patch that looks quite simple in retrospect, but... most things do look simple once somebody else has gone and done them :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Nostalgia ain't what it used to be. pgp8EYSORAX38.pgp Description: PGP signature
Re: FreeBSD Port: ftp/curl
On Thu, Jul 20, 2006 at 04:04:49PM -0500, Scot Hetzel wrote: On 7/20/06, Andrew Pantyukhin [EMAIL PROTECTED] wrote: I wonder if it's possible to resolve the situation when (defined(WITH_GNUTLS) !defined(WITHOUT_SSL)) in a friendlier way than a simple IGNORE. I have WITH_GNUTLS in my make.conf and I don't have WITHOUT_SSL there. It would be great if you could make the port choose on its own, either way would be perfect. I had a look at the ports Makefile, and there is only one thing that is holding the port back, from doing what you want. The port defines: .if !defined(WITHOUT_SSL) USE_OPENSSL= yes .endif before it includes bsd.port.pre.mk. If this could be included after the bsd.port.pre.mk, then the port could have been made to work as you wanted. Since USE_OPENSSL is defined in bsd.port.pre.mk, it needs to be defined before this *.mk file. If it could be moved into bsd.port.post.mk, then the ports Makefile could be changed as follows; [snip would-be-nice patch moving USE_OPENSSL after the OPTIONS processing] Yes, this was indeed the main problem I had with OPTIONS'ifying the curl port - the fact that USE_OPENSSL cannot be reconciled with the options handling framework, simply because it needs to be defined before including bsd.port.pre.mk. Your patch is good, and it would really be nice if it could be applied, but unfortunately, it is not possible for the present :) And to Andrew - as noted above, unfortunately, for the present it is not possible to only use OpenSSL if WITH_GNUTLS is *not* specified, simply because the USE_OPENSSL processing is done before any options processing, and it has to be that way :( G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI pgp6kVWvwn50a.pgp Description: PGP signature
