Aryeh M. Friedman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Remko Lodder wrote:
You Simply dont understand the way it works here and I can
understand that till a certain point of view; take the advise;
discuss it elsewhere, and get back with working code (yeah I repeat
it twice
Pav Lucistnik wrote:
Garrett Cooper píše v pá 14. 12. 2007 v 15:39 -0800:
Jan Henrik Sylvester wrote:
Installing the 7.0-RELEASE package of graphics/xnview, I got some
weird messages that seem to come from the misc/compat5x dependency:
rm: /var/tmp/instmp.qdjoSl/lib/compat/libc.so.5:
Paul Schmehl wrote:
--On December 14, 2007 5:21:02 PM -0800 Brian [EMAIL PROTECTED] wrote:
Information does indeed need to be gathered, and while even the ports
list will only grab a small percentage of FreeBSD users, other options
would likely grab a lot less. Plus, most of the users here
Ade Lovett wrote:
On Dec 13, 2007, at 02:32 , David Southwell wrote:
I suspect antagonistic responsesfrom some people are more about
wounded pride
(i.e - astonishment why should anyone propose to improve on the
procedures,
systems and engineering to which they contributed in the past!)
You
Steven Kreuzer wrote:
This thread was called results of ports re-engineering survey but I
figured I would start a new thread.
On Dec 12, 2007, at 6:45 AM, Ade Lovett wrote:
We *know* it can be done better. We *know* the scaling limits of the
current system, and most of us are completely
Aryeh M. Friedman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Disclaimer:
This does not commit me, anyone else and/or FreeBSD to an course
of action nor does it imply such a commitment.
Assuming that the following is true:
1. There is a proven need to re-engineer the ports
On Wed, 12 Dec 2007, Paul Schmehl wrote:
--On Wednesday, December 12, 2007 04:38:39 -0500 Aryeh M. Friedman
[EMAIL PROTECTED] wrote:
..while I still want to gather more data to pin down the exact
requirements
Don't you get it? You're not GATHERING DATA. You're eliciting responses
On Wed, 12 Dec 2007, Aryeh M. Friedman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephen Montgomery-Smith wrote:
Aryeh M. Friedman wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
I'm not sure what the words refactor and recode mean here.
Refacoring is to use
Paul Schmehl wrote:
--On Monday, December 10, 2007 16:33:20 +0200 Andriy Gapon
[EMAIL PROTECTED] wrote:
From a small research it seems that the only thing needed from cdrtools
is isoinfo utility which gets called in FreeBSD-specific code
(hald/freebsd/probing/probe-volume.c) like follows:
Aryeh M. Friedman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am not comparing a ports freeze to Global warming -- just
likening the responses to a problem.
And like global warming it is something everyone thinks they know
something about but at the end of day it turns out that
3. What is the single best aspect of the current system?
Easy to write ports, or modify those created by others.
4. What is the single worst aspect of the current system?
Slowness of pkg_version and make index.
___
freebsd-ports@freebsd.org
On Sat, 1 Dec 2007, Aryeh M. Friedman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephen Montgomery-Smith wrote:
On Sat, 1 Dec 2007, Aryeh M. Friedman wrote:
Stephen Montgomery-Smith wrote:
Aryeh M. Friedman wrote:
For some reason, people contributing to this mailing list
On Sat, 1 Dec 2007, David Southwell wrote:
On Saturday 01 December 2007 10:28:40 Erik Trulsson wrote:
Personally, as a user, I have never really been even slightly inconvienced
by any of the ports tree freezes.
All I can say is bully for you! The question is how do we get rid of a
p[roblem
On Sat, 1 Dec 2007, Aryeh M. Friedman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Southwell wrote:
On Saturday 01 December 2007 11:54:40 Stephen Montgomery-Smith
wrote:
On Sat, 1 Dec 2007, David Southwell wrote:
On Saturday 01 December 2007 10:28:40 Erik Trulsson wrote
On Sat, 1 Dec 2007, David Southwell wrote:
On Saturday 01 December 2007 11:54:40 Stephen Montgomery-Smith wrote:
On Sat, 1 Dec 2007, David Southwell wrote:
On Saturday 01 December 2007 10:28:40 Erik Trulsson wrote:
Personally, as a user, I have never really been even slightly
inconvienced
Chuck Robey wrote:
Doug Barton wrote:
Jason C. Wells wrote:
Doug Barton wrote:
On Mon, 19 Nov 2007, Jason C. Wells wrote:
What I am trying to do is to build 30 or so packages including the
big ones like X, kde, gnome, plus all of their dependencies on a
build host and then use pkg_add on
Doug Barton wrote:
On Mon, 19 Nov 2007, Jason C. Wells wrote:
What I am trying to do is to build 30 or so packages including the big
ones like X, kde, gnome, plus all of their dependencies on a build
host and then use pkg_add on various machines. I have had a variety
of difficulties with
On Fri, Nov 23, 2007 at 11:25:25PM +0300, Andrew Pantyukhin wrote:
On Fri, Nov 23, 2007 at 10:49:35AM +0100, Lapo Luchini wrote:
Is there a way to discriminate direct dependencies fro indirect
ones, except from reading every single Makefile? (and knowing
to full extent what USE_GNOME and
Thierry Thomas wrote:
Selon Stephen Montgomery-Smith [EMAIL PROTECTED] le Mer 21 nov
22:52:53 2007 :
Now that you mention it, I can see it in the diff file that you sent me.
How do you get patch to behave properly when the file it diffs
against doesn't
already exist?
If you `cd /usr
Aryeh M. Friedman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Who do I report the following issue to (it falls into at least 3 camps)?
If I am downloading a torrent in deluge 0.5.6.2_1 *AND* am logged into
gmail (*WITH* a chat open) my network connection looses about 90% of
it's
Thierry Thomas wrote:
Le Lun 19 nov 07 à 7:28:48 +0100, Thierry Thomas [EMAIL PROTECTED]
écrivait :
Le Lun 19 nov 07 à 3:56:50 +0100, Stephen Montgomery-Smith [EMAIL PROTECTED]
écrivait :
Is anyone working on this? If not, would you guys be kind enough to
make my patch more proper?
I'm
Stephen Montgomery-Smith wrote:
Thierry Thomas wrote:
Le Lun 19 nov 07 à 7:28:48 +0100, Thierry Thomas [EMAIL PROTECTED]
écrivait :
Le Lun 19 nov 07 à 3:56:50 +0100, Stephen Montgomery-Smith
[EMAIL PROTECTED]
écrivait :
Is anyone working on this? If not, would you guys be kind enough
Stephen Montgomery-Smith wrote:
Thierry Thomas wrote:
Le Lun 19 nov 07 à 7:28:48 +0100, Thierry Thomas [EMAIL PROTECTED]
écrivait :
Le Lun 19 nov 07 à 3:56:50 +0100, Stephen Montgomery-Smith
[EMAIL PROTECTED]
écrivait :
Is anyone working on this? If not, would you guys be kind enough
I am trying to get the devel/stlport to work on FreeBSD 7.0. A start is
to add the line
USE_GCC=3.4
in the appropriate place in the Makefile, but then it becomes clear that
some additional change is needed to stlport/config/stl_gcc.h. This file
is the most convoluted mess of #if's I
Stephen Montgomery-Smith wrote:
I am trying to get the devel/stlport to work on FreeBSD 7.0. A start is
to add the line
USE_GCC=3.4
in the appropriate place in the Makefile, but then it becomes clear that
some additional change is needed to stlport/config/stl_gcc.h. This file
Dear Maho,
I noticed that you added lines like:
.if ${OSVERSION} = 700042
.if ${ARCH} == amd64 || ${ARCH} == sparc64
BROKEN= Does not compile with GCC 4.2
.endif
.endif
to the Makefile of math/octave-forge. But it also doesn't build on my
i386 FreeBSD 7.0 machine.
How about doing
Some ports build beautifully on a clean system, but on a well populated
system break at the configure stage. My guess is that some port
somewhere (perhaps something related to gnome) changes the system.
Ports that suffer from this include mutt, libvorbis, and grub.
Here is the output from
Harald Servat wrote:
Hello,
I'm a maintainer of a port which needs a fortran compiler. Due to the
inclusion of GCC 4.2 as the default compiler for FreeBSD 7.0 I'm facing a
problem with the port. My FreeBSD 6.2 box can compile fine my port using
f77, however the build farms do not compile
Brian Josefsen wrote:
Hello all
I installed the openoffice package
ftp://ooopackages.good-day.net/pub/OpenOffice.org/FreeBSD/2.3.0/i386/FreeBSD6/OOo_2.3.0_FreeBSD62Intel_install_da.tbz
yesterday, now when i try to execute openoffice.org-2.3.0 it complaints
about libstdc++.so.6 is missing. As
Harald Servat wrote:
Hello to everybody,
recently I received an automated mail about a port I'm maintaining. Such
mail includes a full report (which is good in order to review the problems
;) ) of the port build on amd64/freebsd7.
The program needs fortran compiler, and looking at the
Here is my next attempt to make a faster pkg_version. This script is
not going to be 100% reliable, but it should work most of the time. It
works by first checking the time difference between
/var/db/pkg/*/+CONTENTS and /usr/ports/*/*/Makefile, and only invokes
pkg_version if the former is
Stephen Montgomery-Smith wrote:
Here is my next attempt to make a faster pkg_version. This script is
not going to be 100% reliable, but it should work most of the time. It
works by first checking the time difference between
/var/db/pkg/*/+CONTENTS and /usr/ports/*/*/Makefile, and only
This is a kludge, but it makes pkg_version 4 times faster on my set up.
The idea is that make -V PKGNAME should ordinarily be a very fast
operation. So it runs a very cut down version of bsd.port.mk. If that
bombs with an error, then it does the full bsd.port.mk.
Maybe portsmanager and
Pav Lucistnik wrote:
Stephen Montgomery-Smith píše v so 28. 07. 2007 v 19:44 -0500:
This is a kludge, but it makes pkg_version 4 times faster on my set up.
The idea is that make -V PKGNAME should ordinarily be a very fast
operation. So it runs a very cut down version of bsd.port.mk
On Sat, 28 Jul 2007, Stephen Montgomery-Smith wrote:
This is a kludge, but it makes pkg_version 4 times faster on my set up. The
idea is that make -V PKGNAME should ordinarily be a very fast operation.
So it runs a very cut down version of bsd.port.mk. If that bombs with an
error
Quite often the x11-toolkits/gnome-sharp20 port does not compile with
the following error:
Making all in gconf
gmake[3]: Entering directory
`/usr/p2/x11-toolkits/gnome-sharp20/work/gnome-sharp-2.16.0/sample/gconf'
MONO_PATH=../../gconf/GConf/gconf-sharp.dll: mono
Erwin Lansing wrote:
On Tue, Jul 24, 2007 at 02:41:04PM -0500, Paul Schmehl wrote:
I'm working on a port upgrade. The existing port has a number of patch
files in FILESDIR that are no longer needed. (The changes they made have
been incorporated into the distro.) What's the appropriate
Alexander Leidinger wrote:
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (Tue, 17 Jul 2007 19:46:11
-0500):
I appreciate that most people won't have this problem, but it has bitten me.
After you have made and installed a port, but don't clean it, and then
made a bunch of other ports
Alexander Leidinger wrote:
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (Tue, 17 Jul 2007 19:46:11
-0500):
I appreciate that most people won't have this problem, but it has bitten me.
After you have made and installed a port, but don't clean it, and then
made a bunch of other ports
If you pkg_delete -f a package and then install the port again (but
after it has been bumped up a version), then the +CONTENTS of ports that
require the original port will be incorrect. This apparently messes up
programs like portmanager. There is a sense in which one should never do
Robert Noland wrote:
On Wed, 2007-07-18 at 15:56 -0500, Stephen Montgomery-Smith wrote:
If you pkg_delete -f a package and then install the port again (but
after it has been bumped up a version), then the +CONTENTS of ports that
require the original port will be incorrect. This apparently
I appreciate that most people won't have this problem, but it has bitten me.
After you have made and installed a port, but don't clean it, and then
made a bunch of other ports, if you go back to the original port and
then do make package, then +CONTENTS can be a bit messed up for the
package.
On Wed, 4 Jul 2007, Sébastien Santoro wrote:
Hi,
slay is a little utility to kill all processes belonging to a
user, it's useful in a script or when you want kill a lot of processes
belonging to one user (slay qmaill).
Furthermore, if the user is logged on the shell, he's warned.
On Wed, 30 May 2007, Bakul Shah wrote:
Peter Jeremy [EMAIL PROTECTED] wrote:
On 2007-May-27 16:12:54 -0700, Bakul Shah [EMAIL PROTECTED] wrote:
Given the size and complexity of the port system I have long
felt that rather than do everything via more and more complex
Mk/*.mk what is is
Here is a C program that does the same as make all-depends-list but
runs four threads at once. I get small time increases on a regular
computer, and twice the speed on dual processor systems.
e.g.
all-depends-list /usr/ports/x11/xorg
___
Stephen Montgomery-Smith wrote:
Here is a C program that does the same as make all-depends-list but
runs four threads at once. I get small time increases on a regular
computer, and twice the speed on dual processor systems.
e.g.
all-depends-list /usr/ports/x11/xorg
The attachment didn't
Hartmut Brandt wrote:
Having done a great deal of rewriting of make some two years ago I can
tell you that even a small change to make is a tough job testing-wise:
run all the combinations of !-j and -j N on all architectures and run
the change through the port-building cluster. That's a
Jeremy Chadwick wrote:
On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote:
I have been thinking a lot about looking for speed increases for make
index and pkg_version and things like that. So for example, in
pkg_version, it calls make -V PKGNAME for every installed
Roman Divacky wrote:
On Mon, May 28, 2007 at 11:34:24AM -0500, Stephen Montgomery-Smith wrote:
Jeremy Chadwick wrote:
On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote:
I have been thinking a lot about looking for speed increases for make
index and pkg_version
I have been thinking a lot about looking for speed increases for make
index and pkg_version and things like that. So for example, in
pkg_version, it calls make -V PKGNAME for every installed package.
Now make -V PKGNAME should be a speedy operation, but the make has to
load in and analyze
On Mon, 28 May 2007, Michel Talon wrote:
Stephen Montgomery-Smith said:
I suggest rewriting make so that variables are only evaluated on a
need to know basis.
or I have tried to do this.
Of course a lot of people have thinked about it, and quickly realized
that it was not going
Jeremy Chadwick wrote:
On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote:
I have been thinking a lot about looking for speed increases for make
index and pkg_version and things like that. So for example, in
pkg_version, it calls make -V PKGNAME for every installed
I'm looking for something that will work with the existing framework.
But yes, I get the feeling that maybe using make to process the ports
might be the source of the problem. Make is a program primarily
designed for figuring out which was made first, the target or the
source, but in the
Ulrich Spoerlein wrote:
Stephen Montgomery-Smith wrote:
That makes perfect sense. It does look like you had to work around a bug in make. I have
actually looked at the code in make where it does the :M (it is the function Str_Match is
str.c) and this bug has clearly been fixed now
Pav Lucistnik wrote:
Stephen Montgomery-Smith píše v st 23. 05. 2007 v 20:04 -0500:
I'm getting kind of uncomfortable with the patch. I looked some more
in
bsd.gnome.mk and it seems to me that the suggested patch is really
equivalent to the patch enclosed here.
Why did the writer
Pav Lucistnik wrote:
Stephen Montgomery-Smith píše v čt 24. 05. 2007 v 07:35 -0500:
Pav Lucistnik wrote:
Stephen Montgomery-Smith píše v st 23. 05. 2007 v 20:04 -0500:
I'm getting kind of uncomfortable with the patch. I looked some more
in
bsd.gnome.mk and it seems to me that the suggested
Stephen Montgomery-Smith wrote:
Pav Lucistnik wrote:
Stephen Montgomery-Smith píše v čt 24. 05. 2007 v 07:35 -0500:
Pav Lucistnik wrote:
Stephen Montgomery-Smith píše v st 23. 05. 2007 v 20:04 -0500:
I'm getting kind of uncomfortable with the patch. I looked some more
in bsd.gnome.mk
Joe Marcus Clarke wrote:
On Thu, 2007-05-24 at 07:35 -0500, Stephen Montgomery-Smith wrote:
Pav Lucistnik wrote:
Stephen Montgomery-Smith píše v st 23. 05. 2007 v 20:04 -0500:
I'm getting kind of uncomfortable with the patch. I looked some more
in
bsd.gnome.mk and it seems to me
Pav Lucistnik wrote:
Stephen Montgomery-Smith píše v út 22. 05. 2007 v 20:29 -0500:
Stephen Montgomery-Smith wrote:
On Wed, 23 May 2007, Pav Lucistnik wrote:
Stephen Montgomery-Smith p?e v ?t 22. 05. 2007 v 16:56 -0500:
I have generated two INDEXes, one with the patch and one without
This small modification cuts off about 25% off pkg_version on my system.
Basically bsd.gnome.mk recursively finds all the dependencies, but many
of them are listed many times. This makes make work extra hard when it
doesn't have to. I simply weed out the repeated entries.
---
Kris Kennaway wrote:
On Tue, May 22, 2007 at 01:47:23AM -0500, Stephen Montgomery-Smith wrote:
This small modification cuts off about 25% off pkg_version on my system.
Basically bsd.gnome.mk recursively finds all the dependencies, but many
of them are listed many times. This makes make
Pav Lucistnik wrote:
Stephen Montgomery-Smith píše v út 22. 05. 2007 v 09:35 -0500:
For example, this
dramatically improves the time for invocations of make -V PKGNAME for
deskutils/alacarte (on my system from about 1.5 seconds to .3 seconds).
It only affects a few ports, but enough, I
Stephen Montgomery-Smith wrote:
Pav Lucistnik wrote:
Stephen Montgomery-Smith píše v út 22. 05. 2007 v 09:35 -0500:
For example, this dramatically improves the time for invocations of
make -V PKGNAME for deskutils/alacarte (on my system from about 1.5
seconds to .3 seconds). It only
On Tue, 22 May 2007, Pav Lucistnik wrote:
Pav Lucistnik p??e v ?t 22. 05. 2007 v 23:16 +0200:
Stephen Montgomery-Smith p??e v ?t 22. 05. 2007 v 13:58 -0500:
Or maybe it is not beyond my skills. This is what I came up with:
Prost? textov? dokument p??loha (ddd)
--- bsd.gnome.mk-orig Tue
On Wed, 23 May 2007, Pav Lucistnik wrote:
Stephen Montgomery-Smith p??e v ?t 22. 05. 2007 v 16:56 -0500:
I have generated two INDEXes, one with the patch and one without.
They
are identical, the timings:
INDEX-orig
real16m32.761s
user18m36.802s
sys 8m38.610s
INDEX-ddd
real
Stephen Montgomery-Smith wrote:
On Wed, 23 May 2007, Pav Lucistnik wrote:
Stephen Montgomery-Smith p?e v ?t 22. 05. 2007 v 16:56 -0500:
I have generated two INDEXes, one with the patch and one without.
They
are identical, the timings:
INDEX-orig
real16m32.761s
user18m36.802s
sys
Kris Kennaway wrote:
On Tue, May 22, 2007 at 04:54:11PM -0700, Bakul Shah wrote:
Would it be possible to check in some of these speedups?
Hoping that helps the xorg-7.2 upgrade some Thanks!
They will be committed later after careful testing. The last thing we
want to do is complicate
Stephen Montgomery-Smith wrote:
2. Profile bsd make and see if there are any bottlenecks. I bet make
was never designed for speed in these kinds of situations. But this
would be a long term project, albeit definitely worth doing.
It looks to me like the variables are stored as a linear
On Sun, 20 May 2007, Doug Barton wrote:
Alexander Leidinger wrote:
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (Sat, 19 May
2007 23:48:52 -0500):
On my system, the program pkg_version can double its speed simply by
replacing make -V PKGNAME by make BEFOREPORTMK=yes -V PKGNAME
Stephen Montgomery-Smith wrote:
On Sun, 20 May 2007, Doug Barton wrote:
Alexander Leidinger wrote:
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (Sat, 19
May 2007 23:48:52 -0500):
On my system, the program pkg_version can double its speed simply by
replacing make -V PKGNAME by make
For those of you who didn't follow the thread where we did this, Alexander
Leidinger and I have made modifications to the port registration process
that make it significantly faster for ports with many dependencies. Sorry
for tooting our horn a bit, but I am really excited about this and I
On Sat, 19 May 2007, Garrett Cooper wrote:
My lord.. now I see what everyone means in terms of taking a long
time to update the ports / package databases. If you use portsnap, it doesn't
take a long time. However, if you use csup/cvsup, it appears to take a long
time running make and ruby
On my system, the program pkg_version can double its speed simply by
replacing make -V PKGNAME by make BEFOREPORTMK=yes -V PKGNAME in
src/usr.sbin/pkg_install/version. Basically what it does is to tell
make to process only about half of bsd.port.mk.
It seems to me that with some clever use
Alexander Leidinger wrote:
Quoting Robert Noland [EMAIL PROTECTED] (Wed, 16 May 2007 18:14:01 -0400):
On Wed, 2007-05-16 at 16:01 -0500, Stephen Montgomery-Smith wrote:
Ok chaps, I think I have it.
This involves no recursive calls of make. Furthermore the
dependencies
it creates
Alexander Leidinger wrote:
Quoting Alexander Leidinger [EMAIL PROTECTED] (Thu, 17 May 2007 11:44:36
+0200):
For the difference between the redirected output case: I think the
gnome terminal needs a lot of time to print all the lines. But still,
the awk version takes around 3/4 of the time
Ulrich Spoerlein wrote:
On 5/15/07, Stephen Montgomery-Smith [EMAIL PROTECTED] wrote:
Ulrich Spoerlein wrote:
I also need to quickly look up origin - pkgname and would suggest
placing this in the INDEX file. Then you have the foundation in
place to
be able to run 'make vim-7.1.2.tbz
Stephen Montgomery-Smith wrote:
Stephen Montgomery-Smith wrote:
[LoN]Kamikaze wrote:
Stephen Montgomery-Smith wrote:
Basically I think we are stuck on making make package-depends go any
faster.
However I do think that the modifications I made to pkg_create go a
very
significant way
Alexander Leidinger wrote:
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (Wed, 16 May 2007 07:59:11
-0500):
Alexander Leidinger wrote:
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (from Tue,
15 May 2007 16:53:35 -0500):
Ulrich Spoerlein wrote:
Stephen Montgomery-Smith wrote:
2
Ok chaps, I think I have it.
This involves no recursive calls of make. Furthermore the dependencies
it creates are the real dependencies on your system, not what ports
thinks it should be, because it gets all the information from
/var/db/pkg. On my system it takes a second or two to
Robert Noland wrote:
On Wed, 2007-05-16 at 16:01 -0500, Stephen Montgomery-Smith wrote:
Ok chaps, I think I have it.
This involves no recursive calls of make. Furthermore the
dependencies
it creates are the real dependencies on your system, not what ports
thinks it should be, because
Pav Lucistnik wrote:
Stephen Montgomery-Smith píše v po 14. 05. 2007 v 09:39 -0500:
Someone pointed out that what I was proposing in +DEPENDENCIES is
already to be found in +CONTENTS. So here is a proof of concept patch
to /usr/ports/Mk/bsd.port.mk (proof of concept because no error
Ulrich Spoerlein wrote:
Stephen Montgomery-Smith wrote:
And also, the only reason it goes slow is because it has to do
(cd $$dir; make -V PKGNAME)
for every dir in _LIB_RUN_DEPENDS. But if instead we kept a file in /var/db/pkg called
something like +PACKAGE_NAMES, where as each port
Ulrich Spoerlein wrote:
Stephen Montgomery-Smith wrote:
1. Pulling in the dependencies. This is in effect doing a make package-depends. You can
do this for yourself, and see that it takes a long time. I honestly don't see how to make
this faster, as presumably it involves calling make
[LoN]Kamikaze wrote:
Stephen Montgomery-Smith wrote:
Basically I think we are stuck on making make package-depends go any
faster.
However I do think that the modifications I made to pkg_create go a very
significant way to solving the problem of registration taking so very long.
Stephen
You
Stephen Montgomery-Smith wrote:
[LoN]Kamikaze wrote:
Stephen Montgomery-Smith wrote:
Basically I think we are stuck on making make package-depends go any
faster.
However I do think that the modifications I made to pkg_create go a
very
significant way to solving the problem of registration
Alexander Leidinger wrote:
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (from
Mon, 14 May 2007 09:39:13 -0500):
Someone pointed out that what I was proposing in +DEPENDENCIES is
Probably me...
Yes
already to be found in +CONTENTS. So here is a proof of concept patch
to /usr/ports
Kris Kennaway wrote:
On Sun, May 13, 2007 at 10:44:19AM +0200, [LoN]Kamikaze wrote:
[LoN]Kamikaze wrote:
Stephen Montgomery-Smith wrote:
OK chaps, this is what I came up with. So for example, if I do make
install on /usr/ports/x11/xorg (having made all the dependencies), on
my computer
I have looked into making the registration and package-building process
even faster. It seems to me that the easiest way would be to redesign
the package database so that it also includes a
package-name/+DEPENDENCIES file, which would be a kind of reverse of
package-name/+REQUIRED_BY. This
Pav Lucistnik wrote:
Stephen Montgomery-Smith píše v ne 13. 05. 2007 v 17:32 -0500:
I have looked into making the registration and package-building process
even faster. It seems to me that the easiest way would be to redesign
the package database so that it also includes a
package-name
Stephen Montgomery-Smith wrote:
I have looked into making the registration and package-building process
even faster. It seems to me that the easiest way would be to redesign
the package database so that it also includes a
package-name/+DEPENDENCIES file, which would be a kind of reverse
On Sat, 12 May 2007, Kris Kennaway wrote:
On Sat, May 12, 2007 at 01:33:40PM -0500, Stephen Montgomery-Smith wrote:
I've done a little poking around. As of right now, I think that the
registering takes a huge amount of time inside of a function called
sortdeps which may be found in /usr
OK chaps, this is what I came up with. So for example, if I do make
install on /usr/ports/x11/xorg (having made all the dependencies), on
my computer it turns the pkg_create from taking about 4 minutes to the
blink of an eye. Now people need to figure out how to speed up the
make
Stephen Montgomery-Smith wrote:
OK chaps, this is what I came up with. So for example, if I do make
install on /usr/ports/x11/xorg (having made all the dependencies), on
my computer it turns the pkg_create from taking about 4 minutes to the
blink of an eye. Now people need to figure out how
Stephen Montgomery-Smith wrote:
Stephen Montgomery-Smith wrote:
OK chaps, this is what I came up with. So for example, if I do make
install on /usr/ports/x11/xorg (having made all the dependencies), on
my computer it turns the pkg_create from taking about 4 minutes to the
blink of an eye
I'm doing an install from scratch on FreeBSD-7, using plain old makle
install clean.
So far: you have to make libXft, and you need to do setenv XORG_UPGRADE
yes, even though the latter apparently should not be needed if you are
not upgrading.
On Wed, 2 May 2007, Kris Kennaway wrote:
On Wed, May 02, 2007 at 02:40:26PM -0500, Stephen Montgomery-Smith wrote:
Secondly, X7.2 as I tried it wouldn't startx if some other login had
created a .Xauthority file. While rm .Xauthority solved the problem
completely, I don't think this is user
On Wed, 2 May 2007, Martin Tournoij wrote:
On Wed 02 May 2007 14:05, Stephen Montgomery-Smith wrote:
On Wed, 2 May 2007, Kris Kennaway wrote:
Hi all,
After many months of hard work (mostly by flz@, as well as others) we
are approaching readiness of the xorg 7.2 upgrade. Because
Are the different versions of tcl and tk really not backwards compatible
with earlier versions? I can guess that there have been heated
conversations about this, but a my look at the mailing list archives
didn't give me anything. But it sure would be much nicer if there was
just a tcl and a
Kris Kennaway wrote:
On Tue, Mar 13, 2007 at 04:09:26PM -0500, Stephen Montgomery-Smith wrote:
Are the different versions of tcl and tk really not backwards compatible
with earlier versions?
No, they are not.
What a pity. So how come the various linux distributions seem to get
away
Forrest Aldrich wrote:
Since a recent update of Spamassassin to:
PORTVERSION=3.1.7
PORTREVISION= 3
I've noticed that each email that gets scanned causes the process to eat
up 80+% of the CPU time, and it's slow...
I'm not really sure what changed.
Likewise, when I start it up for the
201 - 300 of 301 matches
Mail list logo
