-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/04/2010 05:59:34, Robert Noland wrote:
> On Sat, 2010-04-10 at 15:18 +0100, Bruce Simpson wrote:
>> On 04/10/10 02:31, Julian Elischer wrote:
>>>
>>> Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some
>>> others and I, felt that these idea
s are so great... tell ya what -- make me and
other folks believers:
You know young fellow, your attitude is kind of annoying for a
topic that is just up for discussion.
1. Produce a port with the magic PBI producing tool.
I hope to be able to do this soon.
2. Produce directions on how to use
revision packages with
unshared dependencies, or are all of the dependencies updated at once?
This becomes a big issue as you can't have dissimilar applications
like dbus, gamin, openssh, etc running on the same system at one time.
How does the PBI layout plan to deal with this kind of conflict
On Sat, 2010-04-10 at 15:18 +0100, Bruce Simpson wrote:
> On 04/10/10 02:31, Julian Elischer wrote:
> >
> > Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some
> > others and I, felt that these ideas seemed to make some sense
> > and so I put them here for comment.
>
> Please do. Someone has
tions at a sane level.
>
> Kernel development could (just like it is on the Macs) be done in some
> kind of virtualization context.
>
> My own experience with helping people who try to run FreeBSD-CURRENT with
> an up-to-date ports tree is that there are far too many moving parts for
done in some
kind of virtualization context.
My own experience with helping people who try to run FreeBSD-CURRENT with
an up-to-date ports tree is that there are far too many moving parts for
it to be dependable. (For more on how often ports get broken by changes
in -CURRENT, see http
Sam Fourman Jr. wrote:
I do have a question, assuming PBI's were merged officially into the
FreeBSD ports tree,
say I had PostgreSQL Server installed, via PBI. then I wanted to tweak
a setting so I:
cd /usr/ports/databases/postgresql84-server/ && make deinstall clean
would th
Julian Elischer wrote:
On 4/10/10 12:07 PM, Tim Kientzle wrote:
[1] Actually, PBI might work just fine even for
embedded if we address the disk bloat issue. One
approach would be to make
/Package/Bar/libfoo-2.8.7.so
a symlink or hardlink to
/Package/Shared/libfoo-2.8.7.so-
This gives easy sharin
ut there hasn't been a new release of A that
works with B7.2.
So I now simply cannot have both C1.0 and A2.7
installed at the same time because they require
different versions of B.
PBI avoids both of these problems. It may
be unsuitable for embedded systems[1], but
I see no reason we sho
't been a new release of A that
works with B7.2.
So I now simply cannot have both C1.0 and A2.7
installed at the same time because they require
different versions of B.
PBI avoids both of these problems. It may
be unsuitable for embedded systems[1], but
I see no reason we should not ext
th. We instead try to write more
> and more complex package resolvers,
>
> while failing to address the main issue, that with such a complex chain of
> dependencies for something as simple
>
> as upgrading firefox, it increases the chances exponentially that something
> wil
e problems, but there doesn't seem to be a
clear
defined set of what is wrong. IMO, there should be a defined set of
goals
to judge possible implementations against.
Let me start by saying FreeBSD ports is by far the best system I have
used to date.
but as good as it is, there is room
On 4/10/10 10:36 AM, Sam Fourman Jr. wrote:
I do have a question, assuming PBI's were merged officially into the
FreeBSD ports tree,
say I had PostgreSQL Server installed, via PBI. then I wanted to tweak
a setting so I:
cd /usr/ports/databases/postgresql84-server/&& make de
On 4/10/10 7:18 AM, Bruce Simpson wrote:
On 04/10/10 02:31, Julian Elischer wrote:
Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some
others and I, felt that these ideas seemed to make some sense
and so I put them here for comment.
Please do. Someone has to do something about deploymen
creases the chances exponentially that
something will break and ruin your day / weekend.
>> PBIs only comprise a small set of packages in FreeBSD; if my
>> understanding is correct based on a mirror referenced in
pbidir.com,
>> the number is currently under 500~750 PBIs -- this i
On 04/10/10 02:31, Julian Elischer wrote:
Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some
others and I, felt that these ideas seemed to make some sense
and so I put them here for comment.
Please do. Someone has to do something about deployment.
For what it's worth, I've tripped over
e
>>>>> and so I put them here for comment.
>>>>>
>>>>>
>>>> FWIW, when I see these discussions I'm always left wondering what's the
>>>> bad
>>>> part? I do think there are problems, but there doesn't se
e a defined set of goals
to judge possible implementations against.
Let me start by saying FreeBSD ports is by far the best system I have
used to date.
but as good as it is, there is room for improvement.
Being a FreeBSD user now for many years, one thing I think would be nice is:
being able
7;m always left wondering what's the bad
>>> part? I do think there are problems, but there doesn't seem to be a clear
>>> defined set of what is wrong. IMO, there should be a defined set of goals
>>> to judge possible implementations against.
>>
>>
>>
t seem to be a clear
>> defined set of what is wrong. IMO, there should be a defined set of goals
>> to judge possible implementations against.
>
>
> Let me start by saying FreeBSD ports is by far the best system I have
> used to date.
> but as good as it is, there is room
; to judge possible implementations against.
Let me start by saying FreeBSD ports is by far the best system I have
used to date.
but as good as it is, there is room for improvement.
Being a FreeBSD user now for many years, one thing I think would be nice is:
being able to have easier access to deve
On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer wrote:
> sorry for the cross-post..
>
> Last night at the Bay Area FreeBSD Users Group meeting we had
> a discussion about ports, and what is good about them and what
> is bad about them. This has been a topic of discussion quite a
On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer wrote:
>
> Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some
> others and I, felt that these ideas seemed to make some sense
> and so I put them here for comment.
>
>
FWIW, when I see these discussions I'm always left wondering what's the ba
sorry for the cross-post..
Last night at the Bay Area FreeBSD Users Group meeting we had
a discussion about ports, and what is good about them and what
is bad about them. This has been a topic of discussion quite a
bit recently and we were looking for a solution that would
allow us to keep the
On Wed, 7 Apr 2010, Eir Nym wrote:
All is good in BIND in system, except it depends on ports tree with
various options.
I have to do followed algorithm, to enable these options:
1) make and install base system
2) install needed dependencies from ports tree
There is another step here, enable
On 7 Apr 2010, at 13:47, Eir Nym wrote:
All is good in BIND in system, except it depends on ports tree with
various options.
WITH_BIND_XML and WITH_BIND_IDN
I have to do followed algorithm, to enable these options:
1) make and install base system
2) install needed dependencies from ports
All is good in BIND in system, except it depends on ports tree with
various options.
I have to do followed algorithm, to enable these options:
1) make and install base system
2) install needed dependencies from ports tree
3) rebuild and reinstall world
This is more complex than:
1) make and
ize that this is most suitable for current@ and I'm
>> >> cross-posting, but I wanted to jot down all of the ports broken since
>> >> the zlib version bump so that we can keep track of what's going on and
>> >> what needs to be fixed.
>> >
>
oss-posting, but I wanted to jot down all of the ports broken since
> >> the zlib version bump so that we can keep track of what's going on and
> >> what needs to be fixed.
> >
> > I have just started a new package build against todays HEAD on pointyhat
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2010/04/05 01:50, Erwin Lansing wrote:
> On Sun, Apr 04, 2010 at 03:06:15PM -0700, Garrett Cooper wrote:
>> Hi all,
>> I realize that this is most suitable for current@ and I'm
>> cross-posting, but I wanted to jot do
On Sun, Apr 04, 2010 at 03:06:15PM -0700, Garrett Cooper wrote:
> Hi all,
> I realize that this is most suitable for current@ and I'm
> cross-posting, but I wanted to jot down all of the ports broken since
> the zlib version bump so that we can keep track of what's going
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2010/04/04 18:58, Garrett Cooper wrote:
[...]
> As jsa@ so kindly pointed out, upgrading to r206057 temporarily
I think you really want >= 206058 :(
Cheers,
- --
Xin LI http://www.delphij.net/
FreeBSD - The Power to Serve! Live f
On Sun, Apr 4, 2010 at 3:06 PM, Garrett Cooper wrote:
> Hi all,
> I realize that this is most suitable for current@ and I'm
> cross-posting, but I wanted to jot down all of the ports broken since
> the zlib version bump so that we can keep track of what's going on and
&g
Hi all,
I realize that this is most suitable for current@ and I'm
cross-posting, but I wanted to jot down all of the ports broken since
the zlib version bump so that we can keep track of what's going on and
what needs to be fixed.
The following 3rd party libraries and al
It probably bears repeating that the tree will be unstable for the next
few days while a number of large commits hit the tree. These were held
off during the release process to make life easier in case portmgr had
to do tag-slips.
Image processing libraries, xorg, kde, and gnome are scheduled to
On Fri, Mar 19, 2010 at 2:56 PM, Adam PAPAI wrote:
> Hi,
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/144792
>
> To remove the compile warnings I've added the required header files. (and a
> small fix for the Makefile NOMAN -> NO_MAN warning)
>
Hi,
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/144792
To remove the compile warnings I've added the required header files.
(and a small fix for the Makefile NOMAN -> NO_MAN warning)
http://www.wooh.hu/freebsd/untar.c.patch.txt
http://www.wooh.hu/freebsd/Makefile.patch.txt
n.
>>> You can try this patch. I don't know why Alexander did't commit it.
>> I've committed it to mpd5 CVS repo. It will be present in next release soon.
>
> If "soon" is not "in the next couple of days" my vote would certainly be
> th
tch. I don't know why Alexander did't commit it.
>
> I've committed it to mpd5 CVS repo. It will be present in next release soon.
If "soon" is not "in the next couple of days" my vote would certainly be
that you patch the port in place until the next mpd r
Andrey V. Elsukov wrote:
> On 16.02.2010 4:51, Bernd Walter wrote:
>> I don't know how difficult it is to fix, but for many of us mpd is
>> important to have network connection.
>
> You can try this patch. I don't know why Alexander did't commit it.
I've committed it to mpd5 CVS repo. It will be
On 16.02.2010 4:51, Bernd Walter wrote:
I don't know how difficult it is to fix, but for many of us mpd is
important to have network connection.
You can try this patch. I don't know why Alexander did't commit it.
--
WBR, Andrey V. Elsukov
--- src/auth.c 2009-12-22 12:02:46.0 +0300
+++
===> Building for mpd-4.4.1_1
===> src (all)
Warning: Object directory not changed from original
/usr/obj/usr/ports/net/mpd4/work/mpd-4.4.1/src
cc -O -pipe -mcpu=arm9 -DNO_IDEA -mcpu=arm9
-DPATH_CONF_DIR=\"/usr/local/etc/mpd4\" -DSYSLOG_FACILITY=LOG_DAEMON
-DMPD_VE
>
> > On Mon, Feb 8, 2010 at 12:03 AM, Ed Schouten wrote:
> >
> > >
> > > * Vincent Poy wrote:
> > > > It appears that after utmpx.h gone into effect, ports/sysutils/screen
> and
> > > > ports/sysutils/tmux are not working correctly af
is installed by
> the imake port, believe it or not). I submitted a bugreport on it in
> July, and hopefully it will be in Xfree86 4.4.0. Installing the
> textproc/rman port may mask the bug until then, or you can drop this
> file into ports/devel/imake-4/files and rebuild imake.
Inst
n it in
July, and hopefully it will be in Xfree86 4.4.0. Installing the
textproc/rman port may mask the bug until then, or you can drop this
file into ports/devel/imake-4/files and rebuild imake.
--
Dan Nelson
[EMAIL PROTECTED]
--- ../extras/rman/rman.c.orig Tue Jul 15 23:53:53 2003
+
On Dec 02, "Jamie Bowden" wrote:
> I have a new machine that I've just installed 5.1-R on, and cvsup'd to -C.
> I'm attempting to build X, and am getting a core dump from rman during the
> process.
I had this happen too. I did something really hack-ish to get around it
(like delete that document
Robert Watson <[EMAIL PROTECTED]> writes:
> (1) Combine / and /usr into a single file system by default, and add
> /usr/local/etc/rc.d to the search order, with appropriate hacks to
> handle old-style scripts. The devil will be in the bikeshed, but the
> implementation is easy, except
On Mon, 1 Dec 2003, Richard Coleman wrote:
> > (2) Reevaluate the order at routine points in the boot where new scripts
> > might now be available (due to file system mounts or whatever).
> > Essentially "insert the new cards into the deck, and shuffle". This
> > requires rethinking
der(8) early in the boot. The devil will be in
the bikeshed, but the implementation is easy.
(4) Continue to ignore the issue and let some ports install into /etc/rc.d
and consider them unorthodox, incorrect, but something we can
overlook. The devil isn't here, or at least, if i
David O'Brien wrote:
For 5.2-CURRENT, I think we should revisit this issue with one of the
following conclusions winning out, and the rest being discarded as
flame-bait:
(1) Combine / and /usr into a single file system by default, and add
/usr/local/etc/rc.d to the search order, with appropri
On Sun, Nov 30, 2003 at 11:47:24PM -0500, Robert Watson wrote:
> On Mon, 1 Dec 2003, Maxim M. Kazachek wrote:
> > On Sun, 30 Nov 2003, Richard Coleman wrote:
..snip..
> For 5.2-CURRENT, I think we should revisit this issue with one of the
> following conclusions winning out, and the rest being disc
On Mon, 1 Dec 2003, Maxim M. Kazachek wrote:
> On Sun, 30 Nov 2003, Richard Coleman wrote:
For 5.2-RELEASE, I think we should ignore the whole issue and let the
couple of ports that insert things in /etc/rc.d "just do it". We're not
going to find any other solution in time t
On Sun, 30 Nov 2003, Richard Coleman wrote:
>Andreas Klemm wrote:
>
>>>I guess I don't see the problem. What is wrong with ports adding
>>>startup scripts to /etc/rc.d? For certain ports, that is the only way
>>>to get the startup dependencies right (like
the typical BSD traditionalism get in the way of using
RCNG for what it's designed. Don't get me wrong. I'm not advocating
Linux-style integration of packages/ports. But this seems fairly
harmless.
Ports belong into /usr/local, not into /etc. There should be some hook
that allows
In message: <[EMAIL PROTECTED]>
Andreas Klemm <[EMAIL PROTECTED]> writes:
: I have a better idea, then we perhaps need something like a
: wrapper script that is part of the FreeBSD basic system under /etc/rc.d
: that checks for the start script under $LOCALBASE/etc/rc.d
: and starts it
;s not let the typical BSD traditionalism get in the way of using
> RCNG for what it's designed. Don't get me wrong. I'm not advocating
> Linux-style integration of packages/ports. But this seems fairly
> harmless.
Ports belong into /usr/local, not into /etc. There should be some hook
it's not doable, but
> we need to think about it carefully (and, unfortunately, it's not as easy
> as simply adding /usr/local/etc/rc.d to the list..) Having wrapper
Since this issue only comes up for a small number of ports, mostly those
ports which can behave as back-end services for thi
Dag-Erling Smørgrav wrote:
Andreas Klemm <[EMAIL PROTECTED]> writes:
I can't recommend doing it this way, since some ports I know
are writing startup scripts to /etc/rc.d :-/
That is very, very bad. I wish we had some kind of ports QA team :(
Can I assign PR 56748 to [EMAIL PROTEC
Melvyn Sopacua wrote:
Isn't that *exactly why* ports should respect $PREFIX? At least than you know
that startup scripts are in one place. Maybe all that is needed is a variable
RCDIR?= etc/rc.d, for people who want to 'deviate' from this convention.
I like that idea. That coul
Robert Watson wrote:
On Sun, 30 Nov 2003, Andreas Klemm wrote:
I have a better idea, then we perhaps need something like a wrapper
script that is part of the FreeBSD basic system under /etc/rc.d that
checks for the start script under $LOCALBASE/etc/rc.d and starts it very
early.
Hmm. I talked wi
ed advantage that you can easily see what you've done
using ls(1) - unlike /usr/sbin/sendmail being a shell script. In this
specific case, postfix already supports the 'start' and 'stop' arguments, so
there's no need for a wrapper script translating arguments.
&g
ust add postfix.sh to /etc/rc.d, rather
than using tricks with symlinks and rc.conf variables. If you have a
small number of ports added, it's not a big deal. But all these hacks
get confusing when you have a lot of ports, each doing it's own special
trick.
The mailer.conf issue (fo
Andreas Klemm wrote:
I guess I don't see the problem. What is wrong with ports adding
startup scripts to /etc/rc.d? For certain ports, that is the only way
to get the startup dependencies right (like making sure openldap or
postgresql starts before your mail system). This will become
Melvyn Sopacua <[EMAIL PROTECTED]> writes:
> Then you can just as easily nuke the entire mailer.conf principle and symlink
> bin/postfix to etc/rc.d/050.postfix.sh.
This is actually one of the two recommended ways of starting postfix
(and the one I prefer). The main reason for mailer.conf to exi
t the person installing the port can
read instructions given in pkg-message.
I don't think any ports/package system is capable of correctly setting all
*runtime* dependencies especially when it allows it's users to change
configurations after installation without recording the ch
On Sun, Nov 30, 2003 at 11:31:34AM -0500, Robert Watson wrote:
>
> On Sun, 30 Nov 2003, Andreas Klemm wrote:
>
> > I have a better idea, then we perhaps need something like a wrapper
> > script that is part of the FreeBSD basic system under /etc/rc.d that
> > checks for the start script under $LO
ier and
> >avoids an ugly hack,
> >which is good, but restrains functionality. I like the idea of account
> >managed in an
> >centralized LDAP directory very much.
> >
> >So, do you still think the scripts should not participate in rcorder(8)?
> >It&#x
On Sun, 30 Nov 2003, Andreas Klemm wrote:
> I have a better idea, then we perhaps need something like a wrapper
> script that is part of the FreeBSD basic system under /etc/rc.d that
> checks for the start script under $LOCALBASE/etc/rc.d and starts it very
> early.
Hmm. I talked with Gordon a
Andreas Klemm wrote:
What about simply putting a number in front of the script,
I didn't check but am really certain that we start scripts
something like this:
cd $LOCALBASE/etc/rc.d
for i in *.sh <--- here you get an alphabetically
still think the scripts should not participate in rcorder(8)?
It's easy to
change the ports, but this is probably not the right fix.
-Oliver
I guess I don't see the problem. What is wrong with ports adding
startup scripts to /etc/rc.d? For certain ports, that is the only w
I have a better idea, then we perhaps need something like a
wrapper script that is part of the FreeBSD basic system under /etc/rc.d
that checks for the start script under $LOCALBASE/etc/rc.d
and starts it very early.
Andreas ///
--
Andreas Klemm - Powered by FreeBSD 5.1-CURRENT
Need a m
On Sun, Nov 30, 2003 at 12:43:06PM +0100, Oliver Eikemeier wrote:
> I don't care whether slapd or slurpd starts first, I even don't care when
> slurpd
> starts. I want to start ldapd early in the boot process to supports
> services like
> nss_ldap and mail. I did things differently e.g. in net/rs
Andreas Klemm wrote:
On Sun, Nov 30, 2003 at 03:41:33AM +0100, Oliver Eikemeier wrote:
Kris Kennaway wrote:
On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Smorgrav wrote:
Andreas Klemm <[EMAIL PROTECTED]> writes:
I can't recommend doing it this way, since some ports
On Sun, Nov 30, 2003 at 03:41:33AM +0100, Oliver Eikemeier wrote:
> Kris Kennaway wrote:
>
> >On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Smorgrav wrote:
> >
> >>Andreas Klemm <[EMAIL PROTECTED]> writes:
> >>
> >>>I can't re
Mark Linimon wrote:
On Sat, 29 Nov 2003, Dag-Erling Smørgrav wrote:
Do you actually review ports Makefiles?
You _are_ kidding here, right?
Yes, the ports team does read over the ports Makefile. Yes, the
bento cluster attempts to find all the problems that can be found
by automated processes
Kris Kennaway wrote:
On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Smorgrav wrote:
Andreas Klemm <[EMAIL PROTECTED]> writes:
I can't recommend doing it this way, since some ports I know
are writing startup scripts to /etc/rc.d :-/
That is very, very bad. I wish we had some ki
Kris Kennaway wrote:
On Sat, Nov 29, 2003 at 03:25:08PM +0100, Andreas Klemm wrote:
All openldapXX-server ports do this for example
[EMAIL PROTECTED] /var/db/pkg grep /etc/rc.d */+CONTEN*
[...]
openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slapd stop 2>&1 >/dev/null || tru
On Sat, 29 Nov 2003, Dag-Erling Smørgrav wrote:
>
> Do you actually review ports Makefiles?
You _are_ kidding here, right?
Yes, the ports team does read over the ports Makefile. Yes, the
bento cluster attempts to find all the problems that can be found
by automated processes. Yes, my ow
Kris Kennaway <[EMAIL PROTECTED]> writes:
> On Sat, Nov 29, 2003 at 11:38:53PM +0100, Dag-Erling Sm?rgrav wrote:
> > Do you actually review ports Makefiles?
> Not pre-review, but post-review, certainly. We also have an cluster
> of ~25 machines and a number of ports commi
On Sat, Nov 29, 2003 at 11:38:53PM +0100, Dag-Erling Sm?rgrav wrote:
> Kris Kennaway <[EMAIL PROTECTED]> writes:
> > On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Sm?rgrav wrote:
> > > That is very, very bad. I wish we had some kind of ports QA team :(
> &g
Kris Kennaway <[EMAIL PROTECTED]> writes:
> On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Sm?rgrav wrote:
> > That is very, very bad. I wish we had some kind of ports QA team :(
> Well, er, a number of us do essentially nothing BUT ports QA.
Do you actually review por
On Sat, Nov 29, 2003 at 03:25:08PM +0100, Andreas Klemm wrote:
> All openldapXX-server ports do this for example
>
> [EMAIL PROTECTED] /var/db/pkg grep /etc/rc.d */+CONTEN*
> [...]
> openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slapd stop 2>&1 >/dev/null || true
On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Sm?rgrav wrote:
> Andreas Klemm <[EMAIL PROTECTED]> writes:
> > I can't recommend doing it this way, since some ports I know
> > are writing startup scripts to /etc/rc.d :-/
>
> That is very, very bad. I wish w
ay not exist on your system.
I can't recommend doing it this way, since some ports I know
are writing startup scripts to /etc/rc.d :-/
Cc'd to port maintainer to sanitize this
All openldapXX-server ports do this for example
[EMAIL PROTECTED] /var/db/pkg grep /etc/rc.d */+CONTEN*
[...]
op
On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Smørgrav wrote:
> Andreas Klemm <[EMAIL PROTECTED]> writes:
> > I can't recommend doing it this way, since some ports I know
> > are writing startup scripts to /etc/rc.d :-/
>
> That is very, very bad. I wish w
Andreas Klemm <[EMAIL PROTECTED]> writes:
> I can't recommend doing it this way, since some ports I know
> are writing startup scripts to /etc/rc.d :-/
That is very, very bad. I wish we had some kind of ports QA team :(
DES
--
Dag-Erling Smørgrav -
ved some time
> ago, so depending on when you installed -CURRENT these scripts
> may or may not exist on your system.
I can't recommend doing it this way, since some ports I know
are writing startup scripts to /etc/rc.d :-/
Cc'd to port maintainer to sanitize t
On Fri, Nov 28, 2003 at 10:53:29AM -0500, Michael L. Squires wrote:
> On both systems I'm running postgreSQL7 from ports. In both cases the
> pgctl (the startup script) is called twice, and obviously it fails the
> second time. It is called both by /etc/rc.d/localdaemons and
"Michael L. Squires" <[EMAIL PROTECTED]> writes:
> On both systems I'm running postgreSQL7 from ports. In both cases the
> pgctl (the startup script) is called twice, and obviously it fails the
> second time. It is called both by /etc/rc.d/localdaemons and by
&g
uf_setmap 13134000, 1000; 0xc340 -> 13134000
pcm0: sndbuf_setmap 134b2000, 1000; 0xc341e000 -> 134b2000
pcm0: sndbuf_setmap 134d, 1000; 0xc341c000 -> 134d
pcm0: sndbuf_setmap 1348e000, 1000; 0xc341a000 -> 1348e000
postgreSQL startup called twice
On both systems I'm run
Actually, the memory is 512MB PC1066 RDRAM (Rambus). The FSB is 533MHz.
Tom Veldhouse
> The subject says it all. Sorry, no DMESG output, as it has not yet been
> installed. My relavent hardware is:
>
> Pentium 4 - 3.06GHz w/800MHz FSB & Hyperthreading
> 512MB Rambus
>
> Dell Dimension 8250
>
The subject says it all. Sorry, no DMESG output, as it has not yet been
installed. My relavent hardware is:
Pentium 4 - 3.06GHz w/800MHz FSB & Hyperthreading
512MB Rambus
Dell Dimension 8250
Tom Veldhouse
___
[EMAIL PROTECTED] mailing list
http://
Perhaps it's unrealistic to expect this to work, but on each of the
machines where I run -CURRENT, I also run -STABLE (on other slices),
but I generally only build ports under -STABLE, and /usr/local is
common to both the -CURRENT and -STABLE environments. (I build -CURRENT
with "COM
Hi...
after updating my 5.1-current machine:
a) new kernel
b) new world
c) all packages (including XFree86)
d) newest gnome-packages (using marcusmerge)
i got these msgs in XFree86.0.log
Warning: font renderer for ".pcf" already registered at priority 0
Warning: f
"Sweetleaf" <[EMAIL PROTECTED]> writes:
> I am trying to get cdparanoia from the port to compile but am running
> into the following:
>
> ===> Building for cdparanoia-3.9.8_5
> cd interface && gmake all
> gmake[1]: Entering directory
> `/usr/por
I am trying to get cdparanoia from the port to compile but am running
into the following:
===> Building for cdparanoia-3.9.8_5
cd interface && gmake all
gmake[1]: Entering directory
`/usr/ports/audio/cdparanoia/work/cdparanoia-III-alpha9.8/interface'
gmake libcdda_interface.a CFL
< said:
> think '-pthread' is a good thing. It's nice to have a portable way to say
> that I want to compile POSIX code. What good is a standard if there's no
> standard way to get to it?
The Standard way to do it is:
c99 foo.c -l pthread
-GAWollman
David Schwartz wrote:
David Xu wrote:
I definitly agree with Dan, -pthread is too ugly, it really really is
nothing to do with compiler and should be removed.
Really? What if invoking the threading library required the compiler to
compile code differently? Surely it might require that on
David Xu wrote:
> I definitly agree with Dan, -pthread is too ugly, it really really is
> nothing to do with compiler and should be removed.
Really? What if invoking the threading library required the compiler to
compile code differently? Surely it might require that on some platforms,
s
Kris Kennaway <[EMAIL PROTECTED]> wrote:
> mp3blaster-3.1.3
I have a patch, will talk to maintainer.
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listin
901 - 1000 of 1651 matches
Mail list logo
