On Sun, 22 Jan 2006 23:17:24 -0600
Bruce Dubbs <[EMAIL PROTECTED]> wrote:
> Probably not much, but it is a lot different from the rest of the
> book. There is also not much difference in just executing the
> commands in the proposed script.
>
> I don't know about you, but I script most of my pac
Dan McGhee wrote:
Here are my notes from today. They may be useful. Or they may not be.
To control the build order in the libraries I used two files that the
'for PKG...' loop could read. If someone decides to use them in the
book, it might be too failsafe but it might prevent "accidents."
Hello!
On Sat, Jan 21, 2006 at 02:08:10AM +, Bernard Leak wrote:
> I have just bumped myself up from teTeX-2.0.2 to TeTeX-3.0, but
> I can't get JadeTeX to work, apparently because of a partial
> eTeX build.
>
> Something similar was reported earlier: the thread begins at
> http://archives.l
Richard A Downing wrote:
> On Sun, 22 Jan 2006 23:17:24 -0600
> Bruce Dubbs <[EMAIL PROTECTED]> wrote:
>
>
>
>>Probably not much, but it is a lot different from the rest of the
>>book. There is also not much difference in just executing the
>>commands in the proposed script.
>>
>>I don't know ab
El Domingo, 22 de Enero de 2006 20:56, Bruce Dubbs escribió:
> 1. The section in the book is formatted as a . I'm not sure
> this has the proper appearance.
What about this?
[tip condition="html"]
[title]User Notes[/title]
[para][ulink url="http://...[/ulink]
[/tip]
--
Manuel Canale
Dear List,
this is in advance a bit, but I thought I might as
well chuck it in.
The latest "stable" release of the OpenLDAP sources (2.3.17 as I write this)
contains an ignominious bug, and won't build using '--without-debug' .
Anyway, the necessary repairs are in the live CVS
M.Canales.es wrote:
> El Domingo, 22 de Enero de 2006 20:56, Bruce Dubbs escribió:
>
>
>>1. The section in the book is formatted as a . I'm not sure
>>this has the proper appearance.
>
>
> What about this?
>
> [tip condition="html"]
> [title]User Notes[/title]
> [para][ulink url="http://
El Lunes, 23 de Enero de 2006 19:10, Bruce Dubbs escribió:
> Doesn't validate, at least where it is located right now.
Yes, it should be inside an existent sec2 bnlock.
> Perhaps it would be better to just insert
>
> [para condition="html" class="usernotes"]User Notes: [ulink
> url="http://.
Bruce Dubbs wrote:
> M.Canales.es wrote:
> Perhaps it would be better to just insert
>
> [para condition="html" class="usernotes"]User Notes: [ulink
> url="http://...[/ulink][/para]
>
> Into the section desired and adjust the appearance with css. For
> instance, I think the best place to pu
Hi all,
i just run thru the gnome core packages and left out nearly all *optional*
dependencies. So the doxygen too. But doing this, libexif wouldn't get
installed.
Shame on me - i cannot provide a detailed error description cause i installed
doxygen and rerun the install if libexif which than
Hi all,
I thought it prudent to add a description of what the "make client.mk"
command does, seeing how we use it now in three different package
instructions. I wrote something, but I don't like it. Anyone care to
make it better?
make -f client.mk ...: Mozilla products are packaged to allow
On 1/23/06, Thomas Trepl <[EMAIL PROTECTED]> wrote:
>
> Did anyone saw that problem too? If yes, i would vote for moving doxygen from
> "optional" to "required" in the libexif chapter.
Yes, I saw this problem, too. Sorry for not reporting.
The problem is that in the doc/Makefile, if configure do
Hi again,
> I haven't had time to check into that during the weekend, but I'll try
> to reproduce this tonight (hopefully).
I cannot reproduce the problem here(*).
This
>> ! I can't read tex.pool; bad path?
does hint to a hiccup with your ls-R 'database'. What does
'kpsewhich tex.pool' gi
Dan Nicholson wrote these words on 01/23/06 15:32 CST:
> On 1/23/06, Thomas Trepl <[EMAIL PROTECTED]> wrote:
>
>>Did anyone saw that problem too? If yes, i would vote for moving doxygen from
>>"optional" to "required" in the libexif chapter.
I would rather fix the problem instead of forcing folks
Randy McMurchy wrote:
>I clearly said that it wasn't so much for the educational standpoint
>that I'm against scripting, it is because that is just not that way
>we've always done it, and I don't see this package as a reason to
>change.
>
>
>
This is just my $0.02. I think blfs should provide th
On 1/23/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Dan Nicholson wrote these words on 01/23/06 15:32 CST:
> > On 1/23/06, Thomas Trepl <[EMAIL PROTECTED]> wrote:
> >
> >>Did anyone saw that problem too? If yes, i would vote for moving doxygen
> >>from
> >>"optional" to "required" in the libex
Dan Nicholson wrote these words on 01/23/06 15:52 CST:
> It's supposed to be optional. They just did a poor job of packaging,
> and apparently no one tested the installation without Doxygen.
You have to hope that upstream does that kind of testing, which
obviously they didn't. Here in BLFSland,
On 1/23/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Dan Nicholson wrote these words on 01/23/06 15:32 CST:
>
> > The problem is that in the doc/Makefile, if configure doesn't find
> > Doxygen, it comments out the targets called install-apidocs
> > install-apidocs-internal. Unfortunately, these
Jeremy Huntwork wrote these words on 01/23/06 16:29 CST:
> However, someone may be developing a plugin for this functionality -
> there is a whole community of plugins and hacks for Trac. I can research
> it more if this is an important feature.
Well, I for one couldn't stand the volume of emai
On 1/23/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> On 1/23/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> >
> > Actually, the installation bombs. However, it is still a problem
> > we gotta fix.
>
> OK, there's a patch upstream. I haven't tested it, and there aren't
> any comments. I don't t
> Can this notification be turned off as it could in Bugzilla?
Sorry, I'm not subscribed to blfs-book. I only happened to see this
because I was looking at the archives list to make sure the notification
went through.
I assume you mean that the reporter can opt to receive notifications or
no
Randy McMurchy wrote:
> Jeremy Huntwork wrote these words on 01/23/06 16:29 CST:
>
>
>>However, someone may be developing a plugin for this functionality -
>>there is a whole community of plugins and hacks for Trac. I can research
>>it more if this is an important feature.
>
>
> Well, I for o
On 1/23/06, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
> Randy McMurchy wrote:
> > Jeremy Huntwork wrote these words on 01/23/06 16:29 CST:
> >
> >
> >>However, someone may be developing a plugin for this functionality -
> >>there is a whole community of plugins and hacks for Trac. I can research
> >>i
Randy,
We need to discuss some minor formatting issues. In Firefox, we now have:
--
Required patch (if using system-installed versions of NSS and NSPR):
http://www.linuxfromscratch.org/patches/blfs/svn/firefox-1.5-system_nss-1.patch
and in Dependencies
Recommended (if you will be installin
Bruce Dubbs wrote these words on 01/23/06 17:54 CST:
> Wouldn't it be better to have:
>
> Optional patch (Needed if using system-installed versions of NSS and
> NSPR):
> http://www.linuxfromscratch.org/patches/blfs/svn/firefox-1.5-system_nss-1.patch
>
> and
>
> Recommended
>
> nss-3.11 (Needed
Tushar Teredesai wrote:
>>Randy McMurchy wrote:
>>>I suppose it wouldn't be too difficult to filter everything from
>>>the bug-tracking part of Trac to /dev/null. Would this be possible?
I believe so. You could filter out messages sent to you AND from
[EMAIL PROTECTED]
> If that also disables se
Randy McMurchy wrote:
> When I asked him about it, he said that the policy of patches was
> that only 'required' patches could be added to the book. Sure enough
> there is text in the book that explains what and why patches are
> put in BLFS. Optional patches don't qualify to the listed criteria.
On 1/23/06, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
> Hmm. We do need to limit the optional patches somewhat. How do you
> feel about "Recommeded Patches" where the editor managing the page makes
> the call about what to recommend?
>
Please, no more recommended section, especially for patches :-)
Bruce Dubbs wrote these words on 01/23/06 18:21 CST:
> Hmm. We do need to limit the optional patches somewhat. How do you
> feel about "Recommeded Patches" where the editor managing the page makes
> the call about what to recommend?
Not sure...
I think then, that patches could end up in the bo
Tushar Teredesai wrote these words on 01/23/06 18:26 CST:
> Please, no more recommended section, especially for patches :-) IMO
> there should be just two things - Required and Optional.
Not to start an argument, or even a discussion about it for that matter,
unless it is wanted, I disagree. Ther
On 1/23/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Not to start an argument, or even a discussion about it for that matter,
> unless it is wanted,
If a discussion is needed, do start a new thread. I do have some comments:)
--
Tushar Teredesai
mailto:[EMAIL PROTECTED]
http://www.linuxfr
Tushar requested that we start a new thread to discuss Optional vs
Recommended patches/dependencies.
The policy has been that patches/dependecies that are required to build
a package go at the top of the instructions. Dependencies that are
needed for runtime go in the configuration section.
The
Tushar Teredesai wrote these words on 01/23/06 18:41 CST:
> If a discussion is needed, do start a new thread. I do have some comments:)
Alrighty then, bring it on. I'll start.
I believe there is a limited, but entirely useful use of recommended
dependencies. Here is a case in point (generalized
On 1/23/06, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
> Tushar requested that we start a new thread to discuss Optional vs
> Recommended patches/dependencies.
Yay:)
> The issue is when should an optional patch be included in the book and
> when either a patch or dependency should be labelled "Recomm
Tushar Teredesai wrote these words on 01/23/06 19:07 CST:
> Additionally, the way the Recommended dependency is treated on the
> lists is different. Basically it is assumed that Recommended ==
> Required.
Indeed. And in my opinion, this is the right thing to do.
Saying that they were required wo
Tushar Teredesai wrote:
> Additionally, the way the Recommended dependency is treated on the
> lists is different. Basically it is assumed that Recommended ==
> Required.
I understand that such an assumption was to make support issues easier.
However, I have never truly agreed with that. Recommend
Jeremy Huntwork wrote these words on 01/23/06 19:17 CST:
> If a
> user decides that they don't want it, BLFS should still attempt to offer
> support.
Why?
This person has deviated from the prescribed method of doing things.
If someone wants (and can) provide support, then they usually do.
Most t
Tushar Teredesai wrote:
> On 1/23/06, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
>>The issue is when should an optional patch be included in the book and
>>when either a patch or dependency should be labelled "Recommended".
>
>
> My opinion is that there should only be two categories: Required and
>
Randy McMurchy wrote:
Jeremy Huntwork wrote these words on 01/23/06 19:17 CST:
If a
user decides that they don't want it, BLFS should still attempt to offer
support.
Why?
This person has deviated from the prescribed method of doing things.
If someone wants (and can) provide support, then the
Chris Staub wrote:
Maybe this goes back to having different definitions of "recommended".
Just because someone doesn't install something that's "recommended" by
the book doesn't mean they should be considered to have "deviated"...at
least that's some peoples' (including me) definition of "rec
Randy McMurchy wrote:
> Why?
>
> This person has deviated from the prescribed method of doing things.
Well, in many ways, that's the motto of LFS, right? Also, why is it
prescribed? Not because it's necessary, otherwise it would be listed
under Required. As Tushar said, usually it represents what
Chris Staub wrote these words on 01/23/06 19:29 CST:
> Maybe this goes back to having different definitions of "recommended".
> Just because someone doesn't install something that's "recommended" by
> the book doesn't mean they should be considered to have "deviated"...at
> least that's some pe
Chris Staub wrote these words on 01/23/06 19:33 CST:
> and any "Recommended"
> package dependencies should state *why* there are "Recommended".
I won't argue with you there. And this would take time and some
thought by someone to do it correctly.
So, I trust that instead of sending in patches for
Chris Staub wrote:
> Chris Staub wrote:
>
>>
>> Maybe this goes back to having different definitions of "recommended".
>> Just because someone doesn't install something that's "recommended" by
>> the book doesn't mean they should be considered to have
>> "deviated"...at least that's some peoples'
Bruce Dubbs wrote:
> Support is something that people volunteer. If a volunteer doesn't want
> to help if the recommendations aren't followed, that is his choice.
> Sometimes a user doesn't say that the recommendations wern't followed
> and that can lead a supporter down a path that wastes time a
Jeremy Huntwork wrote these words on 01/23/06 19:38 CST:
> [snip a bunch of fine comments]
> BLFS is by nature different in this respect. Here you are customizing
> your custom system. You are tweaking it to fit your wants and desires. I
> wouldn't want to be tied down to *any* decision in BLFS - a
Jeremy Huntwork wrote these words on 01/23/06 19:49 CST:
> Yes, this makes sense, and I can appreciate that. Is there perhaps a
> better term to use then? To me, 'Recommended' will always be 'Optional,
> but useful'.
That may be your interpretation. However, Richard made very valid
points about
Randy McMurchy wrote:
> But don't you feel that for the most part, folks that write in asking
> for support that have exhibited a fair amount of research, get the
> BLFS crowd's full attention and best attempt at a resolution? Even
> better is if they've explained their deviation and why they did i
Just a minor point:
Your acknowledgements page, to me, seems way out of date. It lists all
the original helps (which is fine), but with old information, and none
of the recent help/contributions.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/
Jeremy Huntwork wrote:
> Just a minor point:
>
> Your acknowledgements page, to me, seems way out of date. It lists all
> the original helps (which is fine), but with old information, and none
> of the recent help/contributions.
And then, looking at the Credits page (which I see has some of the
m
Chris Staub wrote these words on 01/23/06 19:33 CST:
> and any "Recommended"
> package dependencies should state *why* there are "Recommended".
I agree with this, kind of. However, this question was asked long
ago in this thread, and answered. See the response about OpenSSL.
Summary is, what is d
Jeremy Huntwork wrote these words on 01/23/06 20:12 CST:
> Your acknowledgements page, to me, seems way out of date. It lists all
> the original helps (which is fine), but with old information, and none
> of the recent help/contributions.
With all due respect and consideration for your taking the
Randy McMurchy wrote:
> Sure that information would be nice. But it is expensive. Good
> text describing research takes time and effort. You simply are
> asking too much for Editors to do this when the whole point is
> *We recommend you install X, Y, and Z*.
Well, don't you often mail this list a
On 1/23/06, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
>
> And you can still do that. Recommended means that it is not required,
> but in the opinion of the Book's Editors, should be installed. We are,
> afer all, quite a bit more experienced than the average user.
>
> I believe that users *want* gui
Randy McMurchy wrote:
> With all due respect and consideration for your taking the time to
> let us know your feelings, not providing anything that could help
> make it better is well, umm, just complaining.
>
> C,mon Jeremy, everyone who pitches in on the LFS side contributes
> an idea, or some t
Jeremy Huntwork wrote these words on 01/23/06 20:24 CST:
> Well, don't you often mail this list asking for opinions when making
> changes to the book? Wouldn't many of the reasons for the recommendation
> be stated in those threads? If so, often a summary of the reason(s) in
> the opening thread w
Randy McMurchy wrote:
> You say this, but don't have to do any of the work. Perhaps you don't
> realize how difficult it is to put together text *for a book*. Text
> that needs to be accurate, well-reading, concise, grammatically
> correct and to the point.
I do realize that it's difficult. I rea
* Randy McMurchy <[EMAIL PROTECTED]> [2006-01-23 17:15]:
> Miguel Bazdresch wrote these words on 01/22/06 22:11 CST:
>
> > PCRE is listed as a recommended dependency but it seems to me it's
> > required.
>
> For all practical purposes, recommended=required. At least that is
> how the developers s
Randy McMurchy wrote:
Chris Staub wrote these words on 01/23/06 19:33 CST:
and any "Recommended"
package dependencies should state *why* there are "Recommended".
I agree with this, kind of. However, this question was asked long
ago in this thread, and answered. See the response about OpenSSL.
Jeremy Huntwork wrote these words on 01/23/06 20:47 CST:
> For a well summarized and finished piece
> of text, you could always cast it out to the list and ask for
> opinions/suggestions before you commit.
I am disappointed in my effort in describing the make -f client.mk
text. I mailed into the
Chris Staub wrote these words on 01/23/06 21:04 CST:
> Of course, another option would be to drop the concept of "Recommended"
> altogether - or reserve it only for "Recommended by the developer"
> dependencies." Would certainly simplify things...
And that is what this entire discussion is supp
Randy McMurchy wrote:
> I am disappointed in my effort in describing the make -f client.mk
> text. I mailed into the list asking for help. *Today* It went
> unanswered.
I skipped over it because I had approximately 90 emails in my Inbox when
I arrived home tonight and my interests usually lie out
Miguel Bazdresch wrote these words on 01/23/06 20:50 CST:
> My point, by way of examples:
>
> * GnuPG is recommended for thunderbird. However, I've build thunderbird
> without it. I don't send encrypted or signed email. Not having gnupg
> didn't break my build.
It is not recommended any long
Randy McMurchy wrote:
> make -f client.mk ...: Mozilla products are packaged to allow the
> use of a configuration file which can be used to pass the
> configuration settings to the configure command.
Too many 'config*'s. What about this?
Packaged source code for Mozilla products mak
Jeremy Huntwork wrote:
> Too many 'config*'s. What about this?
>
> Packaged source code for Mozilla products make use of a configuration
> file that can be used to pass various options to the configure command.
Actually, after reading this again. You could almost drop the first
sentence entirely.
Jeremy Huntwork wrote these words on 01/23/06 21:25 CST:
> Actually, after reading this again. You could almost drop the first
> sentence entirely. What it says is implied by the second two - but I
> don't really have an opinion either way.
Though I appreciate your help, and much of what you said
Tushar Teredesai wrote these words on 01/23/06 20:27 CST:
> Sometimes when I go thru the book,
> I find that some optional dependency does not seem that useful. For
> example, arts lists libjpeg as a recommended dependency. Now why would
> I need a sound support application to link against a graph
Randy McMurchy wrote:
> That first sentence was a way of trying to explain in short words
> the .mozconfig file. The next sentence tries to explain why we
> call client.mk. These concepts are independent. Unfortunately, I
> explained it so poorly that my meaning didn't even come across
> to *you*
Jeremy Huntwork wrote these words on 01/23/06 20:47 CST:
> I do realize that it's difficult. I readily admit that in the LFS world,
> you do more of that work than I do, but I have done several textual
> edits on LFS and Cross-LFS.
For example, I entered this text into the Thunderbird instruction
* Randy McMurchy <[EMAIL PROTECTED]> [2006-01-23 21:27]:
Wow... Randy, the only purpose of my nitpicking is to maybe be helpful.
And that's what it is, just nitpicking.
> > I don't believe GnuPG for thunderbird and libjpeg for gtk2 are in the
> > same boat. Yet, both are 'recommended'.
>
> Not a
Miguel Bazdresch wrote these words on 01/23/06 21:58 CST:
> Wow... Randy, the only purpose of my nitpicking is to maybe be helpful.
> And that's what it is, just nitpicking.
You have always been helpful to me. Always. I'm sorry I didn't
recognize your intentions, and try to say things a bit more
* Bruce Dubbs <[EMAIL PROTECTED]> [2006-01-23 20:50]:
> Tushar requested that we start a new thread to discuss Optional vs
> Recommended patches/dependencies.
[snip]
>
> What do you think?
Allow me to copy part of what I just said in another thread, so it's not
lost. Aplogies for the redundancy:
Jeremy Huntwork wrote:
> I said that there isn't any recent
> acknowledgments in the acknowledgements section, and that some of the
> other info is out of date. I also said that there is redundant
> information in the Credits and Acknowledgements section.
>
> Really I was trying to point out a *p
On 1/23/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
>
> What you mention here is a *mistake* by an editor. And that editor
> was probably me. I cannot find where jpeg is mentioned as a recommended
> dependency by the KDE devs in any of the docs. Though it is recommended
> by almost every other pa
Tushar Teredesai wrote these words on 01/23/06 23:15 CST:
> My intention was not to point it out as a mistake coz I don't know it
> was a mistake.
And what my intention was is that when something is discovered that
seems wrong, or doesn't make sense, it should be brought up in the
-dev list so th
Tushar Teredesai wrote:
> Additionally, the recommended thing is very subjective (i.e. based on
> who is updating the instructions). Sometimes when I go thru the book,
> I find that some optional dependency does not seem that useful. For
> example, arts lists libjpeg as a recommended dependency. N
Bruce Dubbs wrote these words on 01/23/06 23:11 CST:
> Sometimes someone gives us something and we put it into
> acknowledgements. Later that person becomes an editor. Do the acks
> change into credits?
Looking over the Acknowledgments page, Jeremy is right. It is old.
I mean ancient. I'm not s
On 1/24/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
>
> Good catch Tushar! Is this all you saw wrong in my instructions?
>
> If so, I feel pretty good about it.
You should, it is a job well done :)
Saw couple of minor shortcuts that can be taken though. The .so files
can be installed with "inst
On 1/24/06, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
> Now what do we do? Change configure so it doesn't make an unnecessary
> check for a package it doesn't need?
Report upstream.
> That's a developer function, not
> ours. Tell the user it is optional and let the warning shout that it
> needs i
Tushar Teredesai wrote these words on 01/24/06 00:46 CST:
> On 1/24/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
>>If so, I feel pretty good about it.
>
> You should, it is a job well done :)
Coming from you makes me think we probably won't have any issues
with the package. Thanks, Tushar. Littl
80 matches
Mail list logo
