Re: RFC: svn for make fetch
Correct me if I'm wrong but I thought that svn did its own checksumming. If so why do we need to our own? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Issues with devel/boost-* on Sparc64
Guys, Boost mailing list contains a record about using CAS instruction for shared_ptr. It is of 2004. I'll investigate into it further. It is necessary to understand why that library was working before 1.39. Alexander Churanov ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Issues with devel/boost-* on Sparc64
Folks, I've identified the root cause of the issue. Boost folks are using custom routine written in assembly language for SPARC. If the line 57 of boost/smart_ptr/detail/sp_counted_base.hpp is commented, the implementation switches to spin-locked and code compiles successfully. I will contact Boost developers in order to fix this in upstream. I'll also create a patch for devel/boost-libs port for using in the meanwhile. Alexander Churanov ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: RFC: svn for make fetch
On Mon, Nov 09, 2009 at 02:28:52PM -0800, Xin LI wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Eitan Adler wrote: > > I was hoping to get a bit more of a response to a recent posting of > > mine with regard to using svn to fetch files for ports > > My proposal: > > http://www.mail-archive.com/freebsd-ports@freebsd.org/msg23776.html > > A summary of what has been going on: > > http://wiki.freebsd.org/EitanAdler/ports-svn > > > > This is something that more than 2 people should have an input on > > Just my $0.02 but I think it would be great if we can do: > > - "make fetch" would prefer using a pre-packaged tarball, but fallback > to a svn/whatever checkout with a specific revision number, then > generate a tarball from the export. > - "make checksum" would check the tarball's checksum. It's probalby not practical to generate an archive with consistently identical checksums due to the various timestamps (at least without adding a tar writer to svn which would be kind of cool. :) > Maybe we can also have some variables to control that we actually want > the 'HEAD' revision without checking any checksum. However, I think it > would be nice if we can do a checksum'ed checkout for specific SCM > revision, especially if we want to have ports to work not only for > *-devel ports where we would prefer signed source code. While this wasn't the intent of the -DBOOTSTRAP stuff I added to the llvm port, people are finding it useful so if we can find I clean way to support this I think it would be cool. -- Brooks pgpJG8wxgpti5.pgp Description: PGP signature
Re: FreeBSD Port: databases/sqlite3
On Mon, November 9, 2009 4:29 pm, Mike Jakubik wrote: > Hello, > > It seems that a recent version of sqlite3 has gained a build dependency on > TCL. How can i build this port without TCL? Sqlite3-3.6.14.2 did not > require this. The TCL wrapper is disabled in the make config. > > Thanks. After further research, it appears that the distribution that the port uses requires TCL to build, I'm guessing this is a recent change. --- SQLite does not require TCL to run, but a TCL installation is required by the makefiles. SQLite contains a lot of generated code and TCL is used to do much of that code generation. The makefile also requires AWK. --- I downloaded the sqlite-amalgamation-3.6.20.tar.gz distribution and i was able to compile this one without TCL, a simple ./configure && make did the job. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: RFC: svn for make fetch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eitan Adler wrote: > I was hoping to get a bit more of a response to a recent posting of > mine with regard to using svn to fetch files for ports > My proposal: > http://www.mail-archive.com/freebsd-ports@freebsd.org/msg23776.html > A summary of what has been going on: > http://wiki.freebsd.org/EitanAdler/ports-svn > > This is something that more than 2 people should have an input on Just my $0.02 but I think it would be great if we can do: - "make fetch" would prefer using a pre-packaged tarball, but fallback to a svn/whatever checkout with a specific revision number, then generate a tarball from the export. - "make checksum" would check the tarball's checksum. Maybe we can also have some variables to control that we actually want the 'HEAD' revision without checking any checksum. However, I think it would be nice if we can do a checksum'ed checkout for specific SCM revision, especially if we want to have ports to work not only for *-devel ports where we would prefer signed source code. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkr4l6QACgkQi+vbBBjt66CD/wCbBcIFcfbK4a0533PAcNxbZuV5 WXAAnjQfl07w/vcHicVS0s+FOrOs5CMS =1Hly -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gscan2pdf Perl errors
On Mon, Nov 9, 2009 at 8:26 AM, Glenn and Sheryal wrote: > I am getting the following error when I attempt to run gscan2pdf on a > newly built system. The port was installed using portinstall. > Yes, gscan2df 0.9.28 have missing dependencies. in addition to p5-sigaction, a couple of others are missing too. Haven't reported it yet, because I was in a hurry, and it was easier to portdowngrade to the latest 0.9.27 version. I don't remember the details now. So I tried to portinstall devel/p5-Sys-SigAction and although it > reported that it was looking good it failed to compile. What am I doing > wrong? > Sorry, I cant help with that one. -- Regards, Torfinn Ingolfsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD Port: databases/sqlite3
Hello, It seems that a recent version of sqlite3 has gained a build dependency on TCL. How can i build this port without TCL? Sqlite3-3.6.14.2 did not require this. The TCL wrapper is disabled in the make config. Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: RFC: svn for make fetch
On Sun, Nov 08, 2009 at 07:07:25PM +, Marcin Wisnicki wrote:
> On Sun, 08 Nov 2009 17:31:57 +0200, Eitan Adler wrote:
>
> > I was hoping to get a bit more of a response to a recent posting of mine
> > with regard to using svn to fetch files for ports My proposal:
> > http://www.mail-archive.com/freebsd-ports@freebsd.org/msg23776.html A
> > summary of what has been going on:
> > http://wiki.freebsd.org/EitanAdler/ports-svn
> >
> > This is something that more than 2 people should have an input on
>
> Unless you solve plist problem (and completely automated plist generation
> would be a fantastic thing to have!), such functionality should not be
> available (or at least advertised) to end-users.
> You may also consider moving it to separate file (bsd.maintainer.mk).
>
> I don't quite get the logic behind ${USER} == ${SVN_USER} conditional.
> Why do you assume that if my username is the same as username for svn
> checkout then I want to upload snapshot to freefall ? In addition not
> every maintainer has @freebsd.org account. Uploading should be
> customizable (maybe UPLOAD_CMD - like FETCH_CMD).
It's a generalization of an ugly hack I put in my llvm-devel port. I
don't really think it should be part of the base.
-- Brooks
pgp9vsVWHpiAN.pgp
Description: PGP signature
Re: Portmaster with package support ready for beta testing!
On 2009-Nov-08 12:56:52 -0800, Doug Barton wrote:
>I'm very pleased to announce that the first version of portmaster with
>package support is ready for beta testing. :)
Thank you for your efforts.
>support next. I don't think ftp support is going to be possible unless
>I can find a creative way to download a remote directory list.
This is possible using only base system tools:
aspire% echo dir | ftp ftp://ftp.freebsd.org/pub/FreeBSD/
Trying 204.152.184.73...
Connected to ftp.freebsd.org.
220 Welcome to freebsd.isc.org.
331 Please specify the password.
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
200 Switching to Binary mode.
250 Directory successfully changed.
250-If you're looking for one of the FreeBSD releases, please look in the
250-releases/${ARCH}/${RELNAME} directory, where ARCH = "alpha", "amd64",
250-"i386", "ia64", "pc98", or "sparc64" and RELNAME = the release
250-you're interested in, e.g. "6.1-RELEASE" or "5.5-RELEASE".
250-
250 Directory successfully changed.
227 Entering Passive Mode (204,152,184,73,225,24).
150 Here comes the directory listing.
drwxrwxr-x6 110 1002 512 Jan 22 2009 CERT
lrwxrwx--x1 110 1002 15 Oct 23 2006 CTM -> development/CTM
lrwxrwx--x1 110 1002 17 Oct 23 2006 CVSup ->
development/CVSup
drwxrwxr-x4 110 1002 512 Oct 23 2006 ERRATA
lrwxrwx--x1 110 1002 17 Oct 23 2006 FreeBSD-current ->
branches/-current
lrwxrwx--x1 110 1002 19 Oct 23 2006 FreeBSD-stable ->
branches/4.0-stable
lrwxrwx--x1 110 1002 25 Oct 23 2006 ISO-IMAGES-alpha ->
releases/alpha/ISO-IMAGES
lrwxrwx--x1 110 1002 25 Oct 23 2006 ISO-IMAGES-amd64 ->
releases/amd64/ISO-IMAGES
...
--
Peter Jeremy
pgp4uNQsv6GUg.pgp
Description: PGP signature
Re: math/py-numpy vs. math/atlas-devel
b. f. wrote: > 1) +IGNOREME files only work with installed ports (just because the > package database is naturally associated with installed ports doesn't > mean that someone won't create an +IGNOREME for one that isn't > installed), and > 2) when trying to prevent the build or installation of a port that is > not currently installed, the exclusion glob will be compared with the > port directory, rather than the PKGNAME, as is done for installed > packages. I've updated my working copy of the man page with these suggestions, thanks! > And with regard to the selection of exclusion > globs, we should note that a glob that matches too many ports may be > as problematic as one that matches too few. But, of course. :) Regexp creation is both one of the rites of passage for all system administrators and a never-ending journey. If the -x or other glob option is not suitable there are always other options. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Portmaster with package support ready for beta testing
Miroslav Lachman wrote: > Does it mean that one needs ports tree or provide custom INDEX in case > of custom packages with non default options (different dependencies) to > compute order od dependencies? The INDEX file is not involved at all. Portmaster still uses the ports tree only to determine dependencies. This actually leads to the ability to set different dependencies from the default while still using packages, although for the moment I have it set up so that if you use one of the --packages options it implies -G (no config run) since I'm not 100% sure that using dependencies different from how the packages were built will work in all cases. > (AFAIK plain pkg_add works without ports tree and INDEX, that's why I am > asking) AFAIK you're correct. However plain pkg_add is a plain installation tool, it's not an upgrade/management tool. In order to determine whether something needs to be upgraded you have to have a frame of reference. :) One of the items on my funding proposal is to incorporate support for the INDEX file into portmaster, although no one has specifically chosen that as a feature to support yet (while several have specifically requested package support). My plan once the package code is "done" is to add up the "General" contributions that haven't been allotted to the work on package support and go back up the list of features, including INDEX support. > It is related to my idea of extending packages with more metadata, for > example OS version + arch, used build options (WITH_ / WITHOUT_ etc.) so > one can easily determine "how this package was built". I agree that this would be useful. See also http://www.freebsd.org/cgi/query-pr.cgi?pr=106483 which portmaster is doing currently in its own code. > But it seems as > not so easy task to me, as I don't know how to get all the options (from > /etc/make.conf, environment variables, /var/db/ports, commandline...) > and record them to file in useful way. Well some of those things that you mentioned have fairly straightforward solutions, but I agree that the not-directly-ports-related stuff (like make.conf) would be harder. Good luck with that. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: RFC: svn for make fetch
Doug Barton wrote:
Eitan Adler wrote:
I was hoping to get a bit more of a response to a recent posting of
mine with regard to using svn to fetch files for ports
My proposal: http://www.mail-archive.com/freebsd-ports@freebsd.org/msg23776.html
A summary of what has been going on:
http://wiki.freebsd.org/EitanAdler/ports-svn
I was really hoping that others would have more to say as well. My
chief concern is that unless I'm missing something there is no way to
provide checksums for the source files, correct? If that's true my gut
reaction is "no freakin' way" but I'm willing to listen to arguments
as to why this should be ok.
I tend to agree with the other sentiments already expressed that in
cases where svn is the only way a project distributes its source that
maintainers ought to be putting together tarballs of specific
versions. I don't really see that this is an overwhelming burden, but
again I'm open to arguments as to why I might be wrong about this.
OK - "I think you might be wrong about this"
A classic example is the net/freeswitch port where the porter has done
exactly what you say.
(IMHO they've not done it in an optimal way but...)
1) It is not clear from the Makefile what version they are actually using.
2) It is indeed unclear from the Makefile what the provenance of the
fetched tarball is at all.
3) It is very difficult for anyone other than the maintainer to create
an update of the port either for local use or for submission of a patch.
(and writing this I note that (4) the distfile location has dropped off
the net)
(1) and (2) could be _improved_ by more documentation in the Makefile
and better choice of versioning scheme but 3 is fairly fundamental.
What _I'd_ like to see is a development of a combination of "method 1" &
"method 2" from the wiki page referenced above.
Running "make fetch" would perform an svn export, and would generate a
tarball from this in ${DISTDIR} named as ${PORTNAME}-${PORTVERSION}.t[gb]z.
A maintainer can then upload this (or the ports distfile handling system
at freebsd.org could even be modified to do this automagically) BUT it
now exists on the users system which means that all the rest of the
ports system including
* _not_ refetching every time the port is built _unless_ the distfile
has changed
* the ability to checksum the (generated) distfile
* (depending on the exact implementation of the new fetch target) the
ability to fallback on fetching a distfile copy from
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/[distfile]
works as for a "normal" port.
However it is now:
* transparent exactly what is being fetched.
* easy to update the port to fetch a later version by a one line
Makefile edit followed by "make makesum" as is the case for a "standard"
port.
(Obviously the editor of the Makefile needs to carry out checks to
ensure that the PLIST doesn't need to be updated, or other changes made,
to work with the updated revision - as for any other port update).
--
Thomas Sandford
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Issues with devel/boost-* on Sparc64
Mon, Nov 09, 2009 at 04:12:01PM +0300, Eygene Ryabinkin wrote:
> Sat, Nov 07, 2009 at 09:11:56PM -0500, Boris Kochergin wrote:
> > > As I know, currently devel/boost-libs port fails to build on sparc64.
> > > I had a discussion of this in September. The root cause is unknown for
> > > me. To investigate into this further I need either access to a sparc64
> > > box or a person who has access and whom I may instruct with the
> > > actions to perform.
>
> From the preliminary investigations I done on the Boris's machine,
> it turns out that as(1) chokes on the "cas" instruction that looks
> like "cas [%l0+12], %g2, %g1". The instruction itself looks sane,
> so I'll try to understand if as(1) has some bugs inside it or something
> isn't good with the instruction itself.
Hmm, looks like only memory address taken straight from the register is
allowed for the Sparc. So, [%l0] will be good, but [%l0+12] -- won't.
So it seems to me that g++ is generating improper assembly code. Will
look into it a bit further.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Portmaster with package support ready for beta testing
Michel Talon wrote: On Mon, Nov 09, 2009 at 12:05:45PM +0100, Miroslav Lachman wrote: [...] For the above reasons i think that using precompiled packages should be restricted to people who don't mess with the standard settings. When you install some Debian packages you take them as is, and things generally work because mostly everybody use the same packages which are well tested and coherent. If, on your machine, you want to use a specially configured program, you download the sources and compile it. But you take care yourself of the upgrades of this program. I think that a similar behaviour should be viable on FreeBSD. If you extensively modify the configuration of a large number of ports, you cannot expect a packages-based upgrade to work. In this case the only reasonable way is to upgrade from source. There are more than one scenario why people may use packages. I am sure many people are using portmaster or portupgrade with auto creation of packages for backup purpose - if I install newer version I need a backup of old package with dependencies for the case where newer version doesn't work well and needs to be rolled back. Similar to when I have more machines and want few of them used as building and testing environment, then deploy packages to production machines. So the extended metadata for packages will be useful for staff, debuging, recovery etc. I am fine with source upgrade for this moment, but source upgrade causes long downtime of services in some cases - longer than upgrade based on packages. And as number of maintained servers grows it will becomes more important. This is why I am interrested in better support of custom built packages for easier upgrade and I am not saying anything bad on current state of packages support in portmaster. It is definitely step forward. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Portmaster with package support ready for beta testing
On Mon, Nov 09, 2009 at 02:21:06PM +0100, Michel Talon wrote:
> ...
> For the above reasons i think that using precompiled packages should be
> restricted to people who don't mess with the standard settings. When you
> install some Debian packages you take them as is, and things generally
> work because mostly everybody use the same packages which are well
> tested and coherent. If, on your machine, you want to use a specially
> configured program, you download the sources and compile it. But you
> take care yourself of the upgrades of this program. I think that a
> similar behaviour should be viable on FreeBSD. If you extensively
> modify the configuration of a large number of ports, you cannot expect
> a packages-based upgrade to work. In this case the only reasonable way
> is to upgrade from source.
> ...
In fairness, while I believe that the above analysis is reasonable if
one confines the packages in question to those built outside the control
of the one changing configurations, one of the reasons I have been
interested in "package" support for portmaster is precisely so I could
build packages of ports that I had configured for my environment, then
merely install (vs. "build") them on other ("target") machines.
Rebuilding (say) firefox3 on each machine where I want that
configuration of firefox3 seems ... rather less than ideal. :-} I
should be able to build the ports as I choose to configure them, create
packages, and install those packages on the various target machines.
Later, when the port gets updated, I'd want to use portmaster to update
the port on one machine, build a package for it, then on other machines,
use my package to update the port on other machines when I run
portmaster on those machines.
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgp70DlOjsbJI.pgp
Description: PGP signature
Re: Portmaster with package support ready for beta testing
On Mon, Nov 09, 2009 at 12:05:45PM +0100, Miroslav Lachman wrote: > > Does it mean that one needs ports tree or provide custom INDEX in case > of custom packages with non default options (different dependencies) to > compute order od dependencies? > (AFAIK plain pkg_add works without ports tree and INDEX, that's why I am > asking) This is because a package contains a list of requirements. However problems may appear, for example if requirements have changed between the installation of the ports you have on your machine and the moment when the package has been compiled. Moreover some ports compile different stuff according to what is present on your machine. The configure script may autodetect stuff like gnome, etc. and automatically compile for example a gnome version of the program. For all these reasons there may be divergences between the dependencies as seen on your machine and the ones recorded in the package which has been compiled elsewhere. > > It is related to my idea of extending packages with more metadata, for > example OS version + arch, used build options (WITH_ / WITHOUT_ etc.) so > one can easily determine "how this package was built". But it seems as > not so easy task to me, as I don't know how to get all the options (from > /etc/make.conf, environment variables, /var/db/ports, commandline...) > and record them to file in useful way. > It can be useful in case where I have some backup of packages from many > machines, but have not the original environment, where packages were > built etc. For the above reasons i think that using precompiled packages should be restricted to people who don't mess with the standard settings. When you install some Debian packages you take them as is, and things generally work because mostly everybody use the same packages which are well tested and coherent. If, on your machine, you want to use a specially configured program, you download the sources and compile it. But you take care yourself of the upgrades of this program. I think that a similar behaviour should be viable on FreeBSD. If you extensively modify the configuration of a large number of ports, you cannot expect a packages-based upgrade to work. In this case the only reasonable way is to upgrade from source. > > Miroslav Lachman -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Issues with devel/boost-* on Sparc64
Sat, Nov 07, 2009 at 09:11:56PM -0500, Boris Kochergin wrote:
> > As I know, currently devel/boost-libs port fails to build on sparc64.
> > I had a discussion of this in September. The root cause is unknown for
> > me. To investigate into this further I need either access to a sparc64
> > box or a person who has access and whom I may instruct with the
> > actions to perform.
From the preliminary investigations I done on the Boris's machine,
it turns out that as(1) chokes on the "cas" instruction that looks
like "cas [%l0+12], %g2, %g1". The instruction itself looks sane,
so I'll try to understand if as(1) has some bugs inside it or something
isn't good with the instruction itself.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
MailScanner problem with perl-5.10.1
Hi all,
I need some help with this one please, MailScanner and Perl are really
starting to tick me off :(
I upgraded MailScanner a little while along with a number of other
ports, which unfortunately included a micro update to Perl. On FreeBSD
it went from perl-5.10.0 to perl-5.10.1, and judging by the error
messages in the maillog, it seems that the old taint mode problem has
resurfaced. Basically these errors are shown in the maillog and
MailScanner cannot run properly:
Could not use Custom Function code
/usr/local/lib/MailScanner/MailScanner/CustomFunctions/SpamWhitelist.pm,
it could not be "require"d. Make sure the last line is "1;" and the
module is correct with perl -wc (Error: Insecure dependency in require
while running with -T switch at
/usr/local/lib/MailScanner/MailScanner/Config.pm line 754.
I'm seeing this same error message being shown for these files as well:
MyExample.pm, DavidHooton.pm, LastSpam.pm, GenericSpamScanner.pm,
CustomAction.pm, Ruleset-from-Function.pm and ZMRouterDirHash.pm.
From what I understand, FreeBSD runs perl programs with the -T option
(taint mode), which is basically some additional security check. If I'm
reading this right, the additional security check (for some reason)
seems to have a problem with 'eval { require $fullfile; };', the code
used to require the CustomFunction modules MailScanner uses:
$fullfile = "$dir/$filename";
next unless -f $fullfile and -s $fullfile;
eval { require $fullfile; };
if ($@) {
MailScanner::Log::WarnLog("Could not use Custom Function code %s, " .
"it could not be \"require\"d. Make sure " .
"the last line is \"1;\" and the module " .
"is correct with perl -wc (Error: %s)",
$fullfile, $@);
}
I don't believe other OSs are having this problem, so it seems to be
something FreeBSD specific. This has happened before following a Perl
upgrade (I believe it was when we went from 5.8.8 to 5.8.9), but the
solution to it at the time was to upgrade to 5.10.0, which made the
problem go away.
Unfortunately, as we can see, upgrading from 5.10.0 to 5.10.1 has made
the issue manifest itself again and I can't figure out what the hell is
going wrong.
Does this make sense to anyone? Naturally I've reported this problem to
the MailScanner people as well; but I think due to time constraints and
because this isn't affecting other OSs, they don't seem to be able to
offer much help at the moment.
Some people have said they have been able to get it to upgrade
successfully using 5.10.1, but still a large number of people haven't
(despite following the exact same upgrade procedure they did). Even when
doing a fresh FreeBSD 7.2 install completely from scratch, it seems this
problem still occurs - it just doesn't make sense.
Thank you in advance for your time and consideration.
Regards,
mog
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: MSI RAdeon R4670/512 and xf86-video-ati/xf86-video-radeonhd-devel crashes!
On Mon, 2009-11-09 at 10:16 +, O. Hartmann wrote: > Hello. > > Please respond also to my eMail address, since I'm not subscriber of > these lists! Thanks. > > Since I utilise a MSI Radeon R4670/512 RV730-based graphics card, I'im > incapable of using either > > x11-drivers/xf86-video-ati or > x11-drivers/xf86-video-radeonhd[-devel] Try updating xf86-video-ati, patch attached. robert. > > The box is a ASUS P5K-Premium based system (Intel P35 chipset, CPU Intel > Q6600), running FreeBSD 8.0-RC2/amd64 successfully. The X11 subsystem > ist the most recent as one can find in the ports collection. I'll attach > the logfile of the currently running Xserver. > > My box got a new 24 inch TFT display so using VESA driver or lower > resolutions than 1920x1200 isn't acceptable. The situation is as follows: > > In all cases it doesn't matter wheter kernel module 'drm.ko' is loaded > or not. > > Driver 'radeon' (x11-drivers/xf86-video-ati) crashes the box immediately > without any messages. I can see the xdm-login requester, but just > before this shows up, I realise that the mousepointer sprite gets a kind > of 'distorted', it shows up some 'stripes'. They vanish. When log in and > the desktop is about to show up (using windowmaker), the screen stays > black, the box crahes and in some lucky situations, it reboots, in less > lucky situations it remains frozen. > > Driver 'radeonhd' (xf86-video-radeonhd-1.2.5_2) works, but without > 'options EXA' and without 'options DRI'. It is bumpy, but shows a > 1920x1200 pixel screen in full colours. > > Driver 'radeonhd' (xf86-video-radeonhd-1.3.0) doesn't work, it shows the > same behaviour as 'radeon' (xf86-video-ati). I can wathc the mouse > pointer sprite getting striped and a kind of distorted, then the box > crashes. > > Those crashes occur mostly when switching from xdm-login requester to > desktop. In some cases I can switch to the console (pressing > ctrl-alt-[F1--F7]), but at some point, this also freezes/crashes the box. > > I'm a little bit confused, since the ATi-RV730LE chipset is supposed to > be supported. I run another box, an older nVidia CK804-based Athlon3500+ > box equipted with a MSI R4830/512 graphics card. The same base OS > (FreeBSD 8.0-RC2/amd64. The graphics board runs perfectly with ALL(!) > radeon-type drivers, options EXA and DRI enabled, kernel module drm.ko > loaded. > > Can someone help? Since I do not have Windows XP/Vista/7 running on the > box in question, I can not update the firmware of the MSI R4760 with a > potentially existing firmware-update (since those tasks can only be > performed via a special software from MSI running on XP/Vista as far as > I know). > > Thanks in advance, > Oliver > > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- Robert Noland FreeBSD Index: Makefile === RCS file: /home/ncvs/ports/x11-drivers/xf86-video-ati/Makefile,v retrieving revision 1.18 diff -u -r1.18 Makefile --- Makefile 7 May 2009 19:42:35 - 1.18 +++ Makefile 9 Nov 2009 12:36:21 - @@ -6,8 +6,7 @@ # PORTNAME= xf86-video-ati -PORTVERSION= 6.12.2 -PORTREVISION= 1 +PORTVERSION= 6.12.4 CATEGORIES= x11-drivers MAINTAINER= x...@freebsd.org Index: distinfo === RCS file: /home/ncvs/ports/x11-drivers/xf86-video-ati/distinfo,v retrieving revision 1.14 diff -u -r1.14 distinfo --- distinfo 8 Apr 2009 15:18:49 - 1.14 +++ distinfo 9 Nov 2009 12:36:21 - @@ -1,3 +1,3 @@ -MD5 (xorg/driver/xf86-video-ati-6.12.2.tar.bz2) = 2bf50461378771497501ca7f678d36f3 -SHA256 (xorg/driver/xf86-video-ati-6.12.2.tar.bz2) = 1beebba17719f7b9bfbbede156dc33a2dd29ed164657badcb62c7149cfae2750 -SIZE (xorg/driver/xf86-video-ati-6.12.2.tar.bz2) = 902480 +MD5 (xorg/driver/xf86-video-ati-6.12.4.tar.bz2) = e662348f6f957fcedf52818d668ab9f5 +SHA256 (xorg/driver/xf86-video-ati-6.12.4.tar.bz2) = cfde066a7087a19b624f79e95cb9a6c97a847b8802cf38d4ae6022758bf338f6 +SIZE (xorg/driver/xf86-video-ati-6.12.4.tar.bz2) = 915124 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: make config in editors/vim port
> Defining WITH_OPTIONS or WITH_VIM_OPTIONS in /etc/make.conf will enable > the regular dialog configuration screen. Why does the vim port require extra configuration to get the options configuration screen? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Current unassigned ports problem reports
(Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .) The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o ports/140411New port: www/p5-ZConf-RSS-GUI-GTKProvides a GTK b f ports/140409Cannot work ports/security/tor-devel + openssl-0.9.8l o ports/140399Update port: security/webfwlog Add needed patch and ot o ports/140381new port: shells/dash f ports/140379net-im/pidgin-msn-pecan won't compile o ports/140373[MAINTAINER PATCH] sysutils/moreutils: remove dependen o ports/140365[patch] databases/firebird20-client coredumps f ports/140363Update net-mgmt/nagios-devel to 3.2.0 o ports/140360[patch] fixed distinfo for net-mgmt/lanmap o ports/140348New port: www/mod_auth_cas Apache 2.0/2.2 compliant mo f ports/140347security/dirmngr needs updated BUILD_DEPENDS requireme o ports/140322update of port www/weave f ports/140303net-mgmt/docsis can not compile filters under amd64 pl o ports/140282Update lang/clisp to 2.48 o ports/140232Resolve conflicts w/ devel/antlr & devel/pccts o ports/140177new port : textproc/glpi-plugins-DataInjection : This o ports/140176new port : textproc/glpi-plugins-AdditionalReports : T o ports/140174New port: net-mgmt/glpi-plugins-tracker-agent : Agent o ports/140168new port: net-mgmt/glpi-plugins-tracker-server, plugin o ports/140157New port: www/trac-bitten Continuous integration for T f ports/140155Update port: emulators/bsnes update to v0.54 f ports/140146[patch] www/squid: Add squid_fib option for alternate o ports/140133New port: sysutils/Plugtools Manages POSIX users f ports/140109www/validator 0.8.3_1: /usr/local/lib/perl5/site_perl/ o ports/140107[PATCH] Enhance net/nss_ldap to support FreeBSD login o ports/140084[patch] security/amavisd-milter - minor port improveme o ports/140059[MAINTAINER] security/gpa: Mark IGNORE if gpgsm is not o ports/140058[MAINTAINER] security/gpgme: Specifically disable gpgs f ports/140046[PATCH] www/phpsysinfo-dev update to 3.0-RC9 f ports/140012Error in sysutils/heartbeat 2.1.4_3, find_interface_bs f ports/140007[repocopy] devel/gdb6 to devel/gdb66 f ports/139937[PATCH] math/mingw32-libgmp4: update to 4.3.1 f ports/139867mail/isoqlog catch segmentation fault under AMD64 s ports/139848add pre-caching to net-mgmt/nagios rc.d script o ports/139801[patch] port security/gorilla does not work after inst f ports/139760www/squid31 fails to build without NIS/Kerberos f ports/139680Is editors/emacs out-dated? f ports/139652[devel/icu] Little patch for compiling with gcc44 o ports/139629new port security/pam_memcache: a PAM module for authe o ports/139552science/paraview 2.2.4: ParaView error: InitializeTcl f ports/139460security/snortsam broken on 64 bit platforms f ports/139452[patch] krb5 support in java/openjdk6 o ports/139448[NEW PORT] japanese/asterisk16-sounds: Japanese sound o ports/139435print/cups-smb-backend: Add ability to use difference o ports/139372java/jboss5 reorganization. s ports/139361[FIX] net/ntop 3.3.10 don`t install needed file f ports/139348[PATCH] devel/p5-Gearman-XS: [SUMMARIZE CHANGES] f ports/139347[patch]finance/kmymoney2 port update to 1.0.0 o ports/139342[maintainer update] Mk/bsd.octave.mk: problems with oc o ports/139341NEW PORT: devel/aegis-devel o ports/139340New port -- x11-fonts/gentium-basic f ports/139339[patch] www/lynx update to 2.8.7.1 f ports/139317[PATCH] devel/p5-Gearman-XS: [SUMMARIZE CHANGES] o ports/139271[PATCH] sysutils/hpacucli does not work on the amd64 k f ports/139203sysutils/freebsd-snapshot more careful patch not depen o ports/139163[patch] textproc/flex: install info documentation s ports/139150www/bluefish request for DEVELOPMENT version f ports/139140textproc/lucene: fails to install WITH_CONTRIB f ports/139107[patch] sysutils/jfbterm: convert to bsdmake f ports/139078sysutils/cfengine3: startup scripts broken, update nee f ports/139077Cannot install ports/sysutils/bacula-bat f ports/139075Please repo copy lang/squeak to lang/squeak-dev
Re: Portmaster with package support ready for beta testing
Doug Barton wrote: Michel Talon wrote: Miroslav Lachman wrote: I take a quick look at the code and I have one question. Can you explain way --no-deps and --force are used for pkg_add? I can only venture an explanation. Once you have computed a good order for upgrading via packages, you cannot accept that pkg_add ruins your computation by doing things on its own. In principle you have a global view of the problem, which is better than the local view embedded in each package. Hence forcing pkg_add is the only sane way. Very elegantly stated. :) This is all subject to change of course based on refinement from experience, but this usage matches the way that ports are installed in the well-traveled port building code. Does it mean that one needs ports tree or provide custom INDEX in case of custom packages with non default options (different dependencies) to compute order od dependencies? (AFAIK plain pkg_add works without ports tree and INDEX, that's why I am asking) It is related to my idea of extending packages with more metadata, for example OS version + arch, used build options (WITH_ / WITHOUT_ etc.) so one can easily determine "how this package was built". But it seems as not so easy task to me, as I don't know how to get all the options (from /etc/make.conf, environment variables, /var/db/ports, commandline...) and record them to file in useful way. It can be useful in case where I have some backup of packages from many machines, but have not the original environment, where packages were built etc. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: valgrind-3.5.0_1,1
On Sun, 08 Nov 2009 23:34:49 +0100 Nikolaj Thygesen mentioned: > Hi, > > Valgrind still seems troubled when it comes to multithreaded > programs. It seems pthread_self() always returns the same id no matter > which thread calls it - possibly the id of last created thread. Running > a simple test program under Valgrind fails whereas running it as a > regular binary works fine. > > No matter how you twist and turn the creation of mutex'es they seem > to always end up recursive, and don't really protect anything as thay > can be taken by multiple threads simultaneously. They also seem to > behave differently depending on whether they were initialized > dynamically - as in using pthread_mutex_init() - or statically as in > using PTHREAD_MUTEX_INITIALIZER. > Thanks! I'll look into this soon. -- Stanislav Sedov ST4096-RIPE pgpLuDwbfiKNG.pgp Description: PGP signature
MSI RAdeon R4670/512 and xf86-video-ati/xf86-video-radeonhd-devel crashes!
Hello. Please respond also to my eMail address, since I'm not subscriber of these lists! Thanks. Since I utilise a MSI Radeon R4670/512 RV730-based graphics card, I'im incapable of using either x11-drivers/xf86-video-ati or x11-drivers/xf86-video-radeonhd[-devel] The box is a ASUS P5K-Premium based system (Intel P35 chipset, CPU Intel Q6600), running FreeBSD 8.0-RC2/amd64 successfully. The X11 subsystem ist the most recent as one can find in the ports collection. I'll attach the logfile of the currently running Xserver. My box got a new 24 inch TFT display so using VESA driver or lower resolutions than 1920x1200 isn't acceptable. The situation is as follows: In all cases it doesn't matter wheter kernel module 'drm.ko' is loaded or not. Driver 'radeon' (x11-drivers/xf86-video-ati) crashes the box immediately without any messages. I can see the xdm-login requester, but just before this shows up, I realise that the mousepointer sprite gets a kind of 'distorted', it shows up some 'stripes'. They vanish. When log in and the desktop is about to show up (using windowmaker), the screen stays black, the box crahes and in some lucky situations, it reboots, in less lucky situations it remains frozen. Driver 'radeonhd' (xf86-video-radeonhd-1.2.5_2) works, but without 'options EXA' and without 'options DRI'. It is bumpy, but shows a 1920x1200 pixel screen in full colours. Driver 'radeonhd' (xf86-video-radeonhd-1.3.0) doesn't work, it shows the same behaviour as 'radeon' (xf86-video-ati). I can wathc the mouse pointer sprite getting striped and a kind of distorted, then the box crashes. Those crashes occur mostly when switching from xdm-login requester to desktop. In some cases I can switch to the console (pressing ctrl-alt-[F1--F7]), but at some point, this also freezes/crashes the box. I'm a little bit confused, since the ATi-RV730LE chipset is supposed to be supported. I run another box, an older nVidia CK804-based Athlon3500+ box equipted with a MSI R4830/512 graphics card. The same base OS (FreeBSD 8.0-RC2/amd64. The graphics board runs perfectly with ALL(!) radeon-type drivers, options EXA and DRI enabled, kernel module drm.ko loaded. Can someone help? Since I do not have Windows XP/Vista/7 running on the box in question, I can not update the firmware of the MSI R4760 with a potentially existing firmware-update (since those tasks can only be performed via a special software from MSI running on XP/Vista as far as I know). Thanks in advance, Oliver ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/py-numpy vs. math/atlas-devel
On 11/9/09, Doug Barton wrote:
> First, sorry I missed the original problem report, I'm not subscribed
> to -questions. Usually ports questions (including those about tools)
> are handled on freebsd-ports@freebsd.org, but OTOH if you're not sure
> where to send a question it's always better to start on the -questions
> list. :)
>
> Second, thanks to b.f. for the very thorough analysis of the problem.
> I will respond and trim a bit as I go.
>
> Third, I've cc'ed maho@ since the genesis of the problem is that
> math/atlas and math/atlas-devel aren't setting CONFLICTS when
> apparently they should be. maho, if you need any help with this let me
> know.
>
> b. f. wrote:
>> Scott Bennett wrote:
>>> I would like to install science/gnudatalanguage but have been running
>>> into various obstacles. Lars Engels very kindly just fixed one of them
>>> (devel/lasi) (Thanks, Lars!), so now I'm on to the next one, which may
>>> not
>>> be a showstopper, but it's at least a nuisance. One of the
>>> gnudatalanguage
>>> dependencies is math/py-numpy, which, in turn, depends upon math/atlas.
>>> However, I have math/atlas-devel installed and do not wish to revert to
>>> an
>>> older, slower version of the ATLAS library. Adding a "-x atlas-\*" onto
>>> the portmaster command to build math/py-numpy fails to prevent portmaster
>>>from trying to build math/atlas.
>
> As was pointed out, that definitely won't work. With the glob patterns
> for exclusions, or specifying ports on the command line you want to be
> as conservative as possible. Also, it's not necessary to include a *
> at the end, portmaster will handle that for you.
>
>>> Creating a
>>> /var/db/pkg/atlas-3.8.3_1,1/+IGNOREME file in addition doesn't help.
>
> +IGNOREME files are only relevant to installed ports.
>
>>> How
>>> can I force math/py-numpy to accept the already installed
>>> math/atlas-devel
>>> libraries?
>>> Thanks in advance for any help!
>
> The easiest way for you to accomplish this would have been to use '-x
> atlas', the second-easiest would have been to use the -i command line
> option. See the man page for more information on that.
>
>> Congratulations, you've managed to defeat three sets of safeguards in
>> portmaster.
>>
>> Problem #1
>>
>> math/atlas and math/atlas-devel don't have proper CONFLICTS entries in
>> their Makefiles (this should be fixed),
>
> Yes, this analysis was essentially correct.
>
>> Problem #2:
>>
>> You're using the -x flag incorrectly. Or portmaster isn't
>> implementing it properly when the port to be excluded is not actually
>> installed, take your pick.
>
> The way that -x is implemented currently really depends on the user's
> definition of the exclude pattern, and is designed to exclude things
> as early as possible so as to avoid what would ultimately become
> wasted effort. It's hard to justify modifying the code to guess that
> something we've already started working on might match what we think
> the user MEANT instead of what they SAID.
>
>> Problem #3:
>>
>> The +IGNOREME checks in portmaster aren't properly implemented for
>> this case, so they fail to prevent math/atlas from being built.
>
> s/properly implemented for/designed to handle/
>
> If you think about this for a second, the entries in /var/db/pkg are
> exclusively related to installed ports, so trying to use an +IGNOREME
> file for this purpose doesn't make sense, although I can sympathize
> with the OPs sense of desperation here. :)
>
>> So what can you do while these problems are being fixed?
>
> Just to be clear, I didn't see anything that needs to be fixed in your
> message, and I hope my explanation makes it clear why. If you think
> that there are actual bugs that need to be fixed please feel free to
> create a thread on -ports to discuss them.
>
The CONFLICTS for math/atlas* should be fixed, as you remarked. As
for portmaster, I'll allow that your choices were reasonable, but it
would be wise to note in the manpage that:
1) +IGNOREME files only work with installed ports (just because the
package database is naturally associated with installed ports doesn't
mean that someone won't create an +IGNOREME for one that isn't
installed), and
2) when trying to prevent the build or installation of a port that is
not currently installed, the exclusion glob will be compared with the
port directory, rather than the PKGNAME, as is done for installed
packages. Using something like:
#!/bin/sh
for _dir in `make -C /usr/ports -V SUBDIR` ; do
for _dir2 in `make -C /usr/ports/${_dir} -V SUBDIR` ; do
_pkgname=`make -C /usr/ports/${_dir}/${_dir2} -V PKGNAME`
case "${_dir}/${_dir2}" in
*${_pkgname%%-[0-9]*}*) ;;
*) echo "${_dir}/${_dir2} ${_pkgname}" ;;
esac ;
done ;
done
one can find a number of ports that might surprise a user that was not
aware of this fact. And with regard to the selection of exclusion
globs, we should note that a glob that matches too many ports may be
as pr
Re: RFC: svn for make fetch
Eitan Adler wrote: > I was hoping to get a bit more of a response to a recent posting of > mine with regard to using svn to fetch files for ports > My proposal: > http://www.mail-archive.com/freebsd-ports@freebsd.org/msg23776.html > A summary of what has been going on: > http://wiki.freebsd.org/EitanAdler/ports-svn I was really hoping that others would have more to say as well. My chief concern is that unless I'm missing something there is no way to provide checksums for the source files, correct? If that's true my gut reaction is "no freakin' way" but I'm willing to listen to arguments as to why this should be ok. I tend to agree with the other sentiments already expressed that in cases where svn is the only way a project distributes its source that maintainers ought to be putting together tarballs of specific versions. I don't really see that this is an overwhelming burden, but again I'm open to arguments as to why I might be wrong about this. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
