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 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 > >> wrote: > >>> On 18/11/2013 04:10, Eitan Adler wrote: > >>>> On Thu, Nov 14, 2013 at 1:00 PM, Dominic Fandrey > >>>> 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 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/ 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 > > wrote: > >> Le 24/03/2013 17:34, Scot Hetzel a écrit : > >>> On Sun, Mar 24, 2013 at 7:00 AM, Beeblebrox 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 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. 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: How to descend into the extract to build in a subdir
On Tue, Nov 27, 2012 at 02:45:54PM -0600, Paul Schmehl wrote:
> --On November 27, 2012 2:24:12 PM -0600 Paul Schmehl
> wrote:
>
> >I'm working on a port that requires a separate ./configure and ./make to
> >build libraries before you build the main source. How is this done in
> >ports?
> >
> >I figure you have to do something in pre-build:, but I'm not sure exactly
> >what.
> >(cd ${WRKSRC}/subdir && ${MAKE}) causes make to fail entirely. I'm
> >having trouble finding a comparable example in ports and there doesn't
> >seem to be anything about it in the porters handbook (that I have found.)
>
> Never mind. I figured it outl
>
> .if ${PORT_OPTIONS:MBROCCOLI}
> pre-configure:
>(cd ${WRKSRC}/aux/broccoli && ./configure)
> pre-build:
>(cd ${WRKSRC}/aux/broccoli && ${MAKE})
> .endif
I know I'm a bit late to this party, but still - if this is a GNU
configure script, you might want to pass a couple more options to it.
Take a look at how bsd.port.mk (around line 3735) does it - it basically
runs
${SETENV} ... ${CONFIGURE_ENV} ./${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}
with a couple more environment variables defined (compiler, linker,
paths, etc). If your port does not do at least something similar to
this, it might end up compiling different parts of the source with
different settings (e.g. CC, CFLAGS, CPPFLAGS for -D... and -I... and so
on).
And the same goes for the ${MAKE} invocation - take a look at the
do-build target in bsd.port.mk (just a couple of lines below the
configure one) - at least ${SETENV} ${MAKE_ENV} ${MAKE}, if not a couple
more MAKE_FLAGS and MAKE_ARGS, maybe MAKE_JOBS for parallel building.
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
What would this sentence be like if pi were 3?
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 > > > On Wed, Nov 28, 2012 at 7:45 AM, Alexander Yerenkow > > 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
> >
> > 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: Find a corrupt port
On Sat, Feb 26, 2011 at 03:22:28PM +0100, David Demelier wrote: > Hello, > > It seems I have a corrupted port on my system : > > $ pkg_info > [...] > dmxproto-2.3DMX extension headers > pkg_info: corrupted record (pkgdep line without argument), ignoring > pkg_info: corrupted record (pkgdep line without argument), ignoring > pkg_info: corrupted record (pkgdep line without argument), ignoring > pkg_info: corrupted record (pkgdep line without argument), ignoring > docproj-1.17_4 The "meta-port" for the FreeBSD Documentation Project > [...] > > Because it happens after dmxproto O tought it was this one, but > after a make deinstall reinstall in x11/dmxproto the corrupt message > is still there so I'm guessing if it's the corrupted port. > > How can I easily find? Well, one way is to look for pkgdep lines without arguments: cd /var/db/pkg find . -mindepth 2 -maxdepth 2 -type f -print0 | xargs -0 egrep -e 'pkgdep[[:space:]]*$' If this doesn't work, you can always run pkg_info for all your packages: cd /var/db/pkg for i in */; do pkg_info "$i" 2>&1 >/dev/null | sed -e "s@^@$i "; done Hope that helps. 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 If this sentence were in Chinese, it would say something else. 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. 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 show
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: 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: 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-.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: tabstop setting for port Makefiles
On Tue, Jun 29, 2010 at 03:52:56PM +0100, Chris Rees wrote: > Dear All, > > >From bsd.port.mk: > > [ch...@amnesiac]~% head /usr/ports/Mk/bsd.port.mk |tail -n 1 > # Please view me with 4 column tabs! > [ch...@amnesiac]~% > > However, the Porter's Handbook [1] says: > > Note that [bsd.port.mk] uses a non-standard tab setting. > > So if it's non-standard, does that mean I should use 8-column tabs > while creating/editing port Makefiles, or should I match the > 'non-standard' bsd.port.mk? > > Or is it just personal preference and the committers don't care? Uhm, the standard width of a horizontal tab is 8 characters. Thus, bsd.port.mk's 4 characters *are* non-standard; when writing your own ports, use an eight-character tab like the rest of the world ;) Oh, my coat? Nah, I'll get it myself, an asbestos suit is too heavy for most people to lift anyway. 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: 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 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
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
-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
-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
--- 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
-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 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
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
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: 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 > > 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 06:12:40PM +, RW wrote: > On Tue, 10 Nov 2009 12:32:28 +0200 > Peter Pentchev 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: 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 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: Enforcing library version in a port Makefile?
e dependent ports (at least to see if they build), then maybe contact some of the maintainers so they can *really* test the upgrade before it is committed, and then, at commit time, the library port's maintainer must go through all the ports that specify an exact dependency and bump this dependency himself, so that the users see a smooth transition. The users of the ports collection see two commits - one that updates the library port so it installs a new version, and then, immediately afterwards, a second commit 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 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: 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: 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
> >
> > 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
> > > >
> > > > 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
d and it's all right". Even then, I was one of the people who didn't like this, and I removed such autodetection in all the ports I took over, years ago. Still, other maintainers felt that this was useful and comfortable for the users. This behavior should have been removed when the OPTIONS variable was added to the port - 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: Apache SSL broken after upgrade to 2.2.13?
On Wed, Aug 26, 2009 at 10:59:34AM +0200, Frederique Rijsdijk wrote: > Following todays portaudit advisory, I upgraded Apache on several > machines. On a machine that's running SSL, things broke after the > ugprade with the following error: > > [Wed Aug 26 10:23:39 2009] [error] Server should be SSL-aware but has no > certificate configured [Hint: SSLCertificateFile] > > The previous version was 2.2.11_5. Everything worked fine. The hint that > apache gives is obviously configured in httpd.conf.. > > Rolled back to version 2.2.11_5, all is working again. > > Did I miss something? This was reported in Debian, too; it seems to be an upstream change in Apache. I don't know what they intend to do about it, but it does indeed "break" the setups of a lot of people who only put the SSL certificate, key, and stuff in the virtual hosts that actually require it. As a workaround, just put the SSL cert and key directives somewhere on a global level, outside a vhost, and Apache will start. Stupid, I know, but that's how it is for the present :/ 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 Nostalgia ain't what it used to be. pgpYeCTKcgbRP.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
> >
> > 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
> > >
> > > -.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
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
>
> -.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: 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 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
+/* 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, &am
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 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: 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: 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/ or > /compat/linux/usr/share/gens/), 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
char* scantype2str(stype)' > with 'C++' linkage > nmap.cc:2491: error: conflicts with new declaration with 'C' linkage > nmap.h:422: error: previous declaration of 'const char* statenum2str(int)' > with 'C++' linkage > nmap.cc:2523: error: conflicts with new declaration with 'C' linkage > nmap.h:404: error: previous declaration of 'int ftp_anon_connect(ftpinfo*)' > with 'C++' linkage > nmap.cc:2536: error: conflicts with new declaration with 'C' linkage > nmap.h:425: error: previous declaration of 'void reaper(int)' with 'C++' > linkage > nmap.cc:2614: error: conflicts with new declaration with 'C' linkage > nmap.h:424: error: previous declaration of 'void sigdie(int)' with 'C++' > linkage > nmap.cc:2626: error: conflicts with new declaration with 'C' linkage > nmap.h: In function 'int nmap_fileexistsandisreadable(const char*)': > nmap.h:437: error: previous declaration of 'int > nmap_fileexistsandisreadable(const char*)' 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 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 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: 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: 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 Fri, Jul 18, 2008 at 01:46:53PM +0300, Okalany Daniel wrote: > On Fri, Jul 18, 2008 at 1:14 PM, Garrett Cooper <[EMAIL PROTECTED]> wrote: > [snip] > > >> The following options will need to be passed into configure: [snip] > > >> --disable-freetype Okalany, you seem to have missed this one :) [snip] > > >> DirectFB, SVG, and QTE support should also be disabled. > > >> > > >> Cheers, > > >> -Garrett [snip] > The options i used were: > ./configure --disable-x11 --disable-xvideo --disable-glx --disable-sdl > --disable-sd-disable-mad --without-x --disable-ffmpeg --disable-wxwidgets > --disable-skins > > It cofigures okay, but the make fails with > > > In file included from ../../../include/vlc/intf.h:39, > parser/../src/ft2_font.hpp: At global scope: > parser/../src/ft2_font.hpp:60: error: 'FT_Glyph' does not name a type > parser/../src/ft2_font.hpp:61: error: 'FT_BBox' does not name a type > parser/../src/ft2_font.hpp:74: error: 'FT_Library' does not name a type > parser/../src/ft2_font.hpp:76: error: 'FT_Face' does not name a type Yep, FreeType symbols - see above, you missed an option :) 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 Do you think anybody has ever had *precisely this thought* before? pgptbjl1YF8K5.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: Tgz in tgz...!
On Thu, Jul 10, 2008 at 10:53:13PM +0200, Anders Trob??ck wrote:
> On Thu, 10 Jul 2008 13:34:39 -0700
> "Garrett Cooper" <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Jul 10, 2008 at 10:39 AM, Anders Trob??ck
> > <[EMAIL PROTECTED]> wrote:
> > > On Thu, 10 Jul 2008 14:54:15 +0200
> > > Anders Troback <[EMAIL PROTECTED]> wrote:
> > >
> > >> On Thu, 10 Jul 2008 01:54:10 -0800
> > >> Beech Rintoul <[EMAIL PROTECTED]> wrote:
> > >>
> > >> > On Thursday 10 July 2008, Anders Troback said:
> > >> > > Hi,
> > >> > >
> > >> > > I need some tips about a port that I'm working on!
> > >> > >
> > >> > > The problem that I have are that the source of the code are in
> > >> > > a tgz that are in a sub folder in an other tgz! So first I
> > >> > > need the port to download and extract the first tgz and then
> > >> > > extract, configure and make the second tgz!
> > >> > >
> > >> > > How do I cope with that?
> > >> > >
> > >> > > Thanks!
> > >> >
> > >> > You can probably extract the second time in post-extract, but
> > >> > you're going to have to get creative defining the right
> > >> > ${WRKSRC}. After that it should patch and build normally.
> > >> >
> > >> > Beech
> > >> >
> > >>
> > >> OK! Next problem:-]
> > >>
> > >> The program that I want to build are under a sub folder of
> > >> ${WRKSRC}/src so first I need to make the "main" program and then I
> > >> have to run make in that sub folder! Are there any macros that do
> > >> things like this or is there some other way?
> > >>
> > >> Thanks again!
> > >>
> > >
> > > Is this a "legal" way of solving this issue?
> > >
> > > post-build:
> > >cd ${WRKSRC}/src/extras && make
> >
> > Wouldn't `gmake -C ${WRKSRC}/src/extras' be better?
> > -Garrett
>
> Yes, much nice and cleaner! I don't need gmake but make was the same!
Actually, this might miss a lot of settings in the environment and stuff.
It would be much better to do it the way bsd.port.mk does it:
${SETENV} ${MAKE_ENV} ${GMAKE} ${MAKE_FLAGS} ${MAKEFILE} ${MAKE_ARGS}
${ALL_TARGET}
Yes, this is a command line consisting entirely of variables :)
Well, okay, to do it in a different directory you would need to use:
${SETENV} ${MAKE_ENV} ${GMAKE} -C ${WRKSRC}/src/extras ${MAKE_FLAGS}
${MAKEFILE} ${MAKE_ARGS} ${ALL_TARGET}
The ${SETENV} ${MAKE_ENV} part is really important. The rest - well,
${MAKE_FLAGS} and ${MAKE_ARGS} are most probably not needed in this
particular case, but they still are a good idea in the general case -
although in very few cases, on very weird "make" invocations, there might
be problems because of flag differences between BSD make and GNU make.
The ${MAKEFILE} is very, very rarely *not* "Makefile" - and if you
decide to remove ${MAKE_FLAGS}, be sure to check if you still want to
pass ${MAKEFILE}, too :)
Well, okay, so basically, this could *most probably* be shortened to:
${SETENV} ${MAKE_ENV} ${GMAKE} -C ${WRKSRC}/src/extras
...maybe :)
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 pi were 3?
pgpN9WafGUGZK.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: FreeBSD Port: worldofpadman-1.2_3
On Mon, Jun 23, 2008 at 02:06:59PM +0200, [EMAIL PROTECTED] wrote:
> Alejandro Pulver <[EMAIL PROTECTED]> wrote on 22.06.2008 01:54:38:
>
> > On Mon, 16 Jun 2008 18:03:45 +0200
> > [EMAIL PROTECTED] wrote:
> >
> > > hi bsd port developer team,
> > >
> > > i installed and operate a dedicated wop server based on a
> > > FreeBSD 6.2 box which is public reachable by its ip 212.65.13.88,
> > > or in game servername and modification "Punchy [EMAIL PROTECTED]"
> > >
> > > i installed the dedicated server using the port system,
> > > csup is lokal the current version, and the version check
> > > gives me : worldofpadman-1.2_3 = up-to-date with port back.
> > >
> > > but i find out the server is running version 1.1
> > > returns in serverinfo "ioQ3 r1051 freebsd-i386"
> > > actual version of WorldofPadman is 1.2
> > >
> > > how can i easyly patch this live system to the newest version ?
> > >
> > > thanx for ur help !
> > > thanx from me, and the WOP community
> > >
> > > @spi
> >
> > Hello.
> >
> > I've updated it to the latest SVN version, please update your ports
> > tree and try it.
>
> Hello Ale,
>
> thanx for your activity.
> I update my local ports try to make install but cant fetch the file.
>
> => worldofpadman-1.2.20080621.tar.bz2 doesn't seem to exist in
> /usr/ports/distfiles/.
> => Attempting to fetch from
> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/.
> fetch:
> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/worldofpadman-1.2.20080621.tar.bz2:
>
> File unavailable (e.g., file not found, no access)
>
> i check the ftp, but the file is not on.
>
> Thank you in advance
Please try not to write your message above the text you're replying to;
it makes quoting somewhat difficult and places it out of context :)
Can you try the following patch to worldofpadman's Makefile and see if
it helps? To anybody who reads the patch: yes, I know that bsd.port.mk
ought to handle %SUBDIR%, but it actually doesn't do that if one also
specifies a :tag at the end. Or, at the very least, I couldn't find
a way to make it so :)
Index: ports/games/worldofpadman/Makefile
===
RCS file: /home/ncvs/ports/games/worldofpadman/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- ports/games/worldofpadman/Makefile 21 Jun 2008 23:53:15 - 1.6
+++ ports/games/worldofpadman/Makefile 23 Jun 2008 12:24:47 -
@@ -13,7 +13,7 @@
ftp://ftp.snt.utwente.nl/pub/games/worldofpadman/linux/:full,update \
ftp://ftp.kickchat.com/wop/:update \
http://www.hessenfragger.de/uploads/:update \
- ${MASTER_SITE_LOCAL}
+ ${MASTER_SITE_LOCAL:S@/%SUBDIR%/$@/alepulver/:[EMAIL PROTECTED]
MASTER_SITE_SUBDIR=alepulver
DISTFILES= worldofpadman.run:full \
wop_patch_1_2.run:update \
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.
pgpqcEeXBHNRZ.pgp
Description: PGP signature
Re: how to determine the date a port is installed
On Wed, Jun 11, 2008 at 01:40:19PM +0100, Florent Thoumie wrote: > On Wed, Jun 11, 2008 at 8:31 AM, Peter Pentchev <[EMAIL PROTECTED]> wrote: > > 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/, 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 actually does if you're using portupgrade (and probably > portmaster), see the @pkgdep entries. > > Use +DESC, +COMMENT or +MTREE_DIRS instead. Yep. Sorry. Any of those would be a better candidate. I'd simply forgotten about port management tools modifying the dependencies in-place. 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. pgp3xPff7e8mi.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/, 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=daemontools&search=go&num=10&stype=name&method=match&deleted=excludedeleted&start=1&casesensitivity=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: Cleaning /var/db/ports
On Tue, Mar 25, 2008 at 05:30:18PM -0700, Doug Barton wrote:
> Lars Stokholm wrote:
>> Apart from doing 'rm -r /var/db/ports/*' is there a way of cleaning the
>> folder of stale folders and files?
>
> Not an automated one, no. It would also be somewhat difficult (although not
> impossible) to write an automated tool to do it because of the loose
> relationship between the names in /var/db/ports and the names in
> /var/db/pkg.
Or maybe it's not that difficult, just a bit time-consuming (for the tool,
not the writer :)) - it's just a Simple Matter Of Scripting(tm) something
like:
cd /var/db/pkg
for p in *; do
if [ -d "$p" ] && [ -f "$p/+CONTENTS" ]; then
o=`awk -F: '$1 = /@comment ORIGIN/ {print $2}' "$p/+CONTENTS"`
n=`make -C "/usr/ports/$o" -V UNIQUENAME`
printf '%s:%s:%s\n' "$p" "$o" "$n"
fi
done
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.
pgpg6ssd44SFH.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: cannot install p5-Net-Pcap
On Sat, Jan 05, 2008 at 09:19:13PM -0500, Piotr wrote: > > I've installed the newest libpcap-0.9.7_1, but I'm still getting errors: > > # pkg_info | grep libpcap > libpcap-0.9.7_1 Ubiquitous network traffic capture library > [snip] > In file included from Pcap.xs:43: > stubs.inc:91: error: redefinition of `struct pcap_if' And all this time, *this* is the actual error that is breaking the build. Not the warnings; they are just that - only warnings. But this is a real problem. Unfortunately, I cannot right now understand why this would break; it seems to be somehow related to a HAVE_PCAP_FINDALLDEVS define. For some reason, the Makefile.PL configuration stage did not detect the pcap_findalldevs() function in your pcap library. Can you post the contents of the Makefile in the Net-Pcap-0.15/ work directory? 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 contains exactly threee erors. pgp4RaU67n7EJ.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: Stunnel not working
On Thu, Nov 08, 2007 at 11:59:15PM +0100, Pav Lucistnik wrote:
> RW p??e v ?t 08. 11. 2007 v 22:06 +:
>
> > Stunnel doesn't seem to be working correctly on my 6.2 desktop, I'm
> > getting the following in /var/log/messages, and I have no stunnel
> > process
[snip]
> > stunnel: LOG3[926:134660096]: local socket: Protocol not supported (43)
> > stunnel: warning: can't get client address: Bad file descriptor
[snip]
>
> On my machines, I noticed 4.21 no longer understands domain names in
> connect statement of configuration file.
>
> Try replacing that secure.new.seasynews.com by it's IP.
Could you try the attached patch? According to the stunnel developers,
it should fix the problem.
It has been submitted to the portmgr@ team for commit approval.
I apologize for the apparently insufficient testing before the port
update to version 4.21.
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.
Index: ports/security/stunnel/Makefile
===
--- ports/security/stunnel/Makefile (revision 1430)
+++ ports/security/stunnel/Makefile (revision 1431)
@@ -7,6 +7,7 @@
PORTNAME= stunnel
PORTVERSION= 4.21
+PORTREVISION= 1
CATEGORIES= security
MASTER_SITES= http://www.stunnel.org/download/stunnel/src/ \
ftp://stunnel.mirt.net/stunnel/ \
Index: ports/security/stunnel/files/patch-src::stunnel.c
===
--- ports/security/stunnel/files/patch-src::stunnel.c (revision 0)
+++ ports/security/stunnel/files/patch-src::stunnel.c (revision 1431)
@@ -0,0 +1,92 @@
+An official patch obtained from ftp://stunnel.mirt.net/stunnel/setuid.patch
+
+--- src/stunnel.c.old 2007-11-12 11:30:38.0 +0200
src/stunnel.c 2007-11-12 11:30:48.0 +0200
+@@ -3,8 +3,8 @@
+ * Copyright (c) 1998-2007 Michal Trojnara <[EMAIL PROTECTED]>
+ * All Rights Reserved
+ *
+- * Version: 4.21 (stunnel.c)
+- * Date: 2007.10.27
++ * Version: 4.22 (stunnel.c)
++ * Date: 2007.11.xx
+ *
+ * Author: Michal Trojnara <[EMAIL PROTECTED]>
+ *
+@@ -41,7 +41,7 @@
+ static void accept_connection(LOCAL_OPTIONS *);
+ static void get_limits(void); /* setup global max_clients and max_fds */
+ #if !defined (USE_WIN32) && !defined (__vms)
+-static void make_chroot(void);
++static void drop_privileges(void);
+ static void daemonize(void);
+ static void create_pid(void);
+ static void delete_pid(void);
+@@ -111,9 +111,6 @@
+ } else { /* inetd mode */
+ #if !defined (USE_WIN32) && !defined (__vms)&&!defined(USE_OS2)
+ max_fds=FD_SETSIZE; /* just in case */
+-#ifdef HAVE_CHROOT
+-make_chroot();
+-#endif /* HAVE_CHROOT */
+ drop_privileges();
+ #endif
+ num_clients=1;
+@@ -171,9 +168,6 @@
+ #if !defined (USE_WIN32) && !defined (__vms) && !defined(USE_OS2)
+ if(!(options.option.foreground))
+ daemonize();
+-#ifdef HAVE_CHROOT
+-make_chroot();
+-#endif /* HAVE_CHROOT */
+ drop_privileges();
+ create_pid();
+ #endif /* !defined USE_WIN32 && !defined (__vms) */
+@@ -299,24 +293,9 @@
+ #endif
+ }
+
+-#ifdef HAVE_CHROOT
+-static void make_chroot(void) {
+-if(options.chroot_dir) {
+-if(chroot(options.chroot_dir)) {
+-sockerror("chroot");
+-exit(1);
+-}
+-if(chdir("/")) {
+-sockerror("chdir");
+-exit(1);
+-}
+-}
+-}
+-#endif /* HAVE_CHROOT */
+-
+ #if !defined (USE_WIN32) && !defined (__vms)
+-/* set process user and group(s) id */
+-void drop_privileges(void) {
++/* chroot and set process user and group(s) id */
++static void drop_privileges(void) {
+ int uid=0, gid=0;
+ struct group *gr;
+ #ifdef HAVE_SETGROUPS
+@@ -350,6 +329,20 @@
+ }
+ }
+
++#ifdef HAVE_CHROOT
++/* chroot */
++if(options.chroot_dir) {
++if(chroot(options.chroot_dir)) {
++sockerror("chroot");
++exit(1);
++}
++if(chdir("/")) {
++sockerror("chdir");
++exit(1);
++}
++}
++#endif /* HAVE_CHROOT */
++
+ /* Set uid and gid */
+ if(gid) {
+ if(setgid(gid)) {
Index: ports/security/stunnel/files/patch-src::prototypes.h
===
--- ports/security/stunnel/files/patch-src::prototypes.h (revision 0)
+++ ports/security/stunnel/files/patch-src::prototypes.h (revision 1431)
@@ -0,0 +1,12 @@
+An official patch obtained from ftp://stunnel.mirt.net
Re: 'make -DNO_DEPENDS install' causing error
On Wed, Oct 31, 2007 at 09:44:13AM -0700, Doug Barton wrote:
> On Wed, 31 Oct 2007, Peter Pentchev wrote:
>
>> 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,
>
> Except building the new port of course. :)
Well, sure :) I should have mentioned "not meant to modify anything
in ${PREFIX}" - and, of course, this does not cover the case when
${WKRDIRPREFIX} is within ${PREFIX}, but that's a whole 'nuther kettle
of fish there :)
>> 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.
>
> I guess what I'm getting at is that (as far as I can see) that's not what
> happens now. The parent port is installed first, then run depends are
> checked. But like I said, I'll take a look at your original example, and
> those below.
E... do you mean that's what happens now in the ports collection,
when a "make install" is issued in a directory with a Makefile which
includes bsd.port.mk?! 'Cause, you know, that's just... not true :)
You could either check it yourself, by running "make install" in
a port directory and looking at the sequence of actions :) Or you could
check the _INSTALL_SEQ and _INSTALL_SUSEQ variables in bsd.port.mk around
line 4117 - "run-depends" is in _INSTALL_SEQ, "do-install" is in
_INSTALL_SUSEQ, and bsd.port.mk runs the _SEQ targets before _SUSEQ
(bsd.port.mk around line 4176 for the normal case and 4161-4167 for
the su-use case).
The Ports Collection as such processes the runtime dependencies before
actually running the port's install target.
>> 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
This sentence is false.
pgpP7aVhdR1tV.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: '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: 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
