headers
+Jan | 1 Aug 2011 17:59
Picon

Re: The State of BLFS

On Sat, Jul 30, 2011 at 6:22 PM, Rob Landley <rob <at> landley.net> wrote:
> So I grabbed the SVN, which produced nothing interesting in the top
> level directory, guessed I wanted "book", there was a readme in there,
> told me I could run make, and I did.  It sat there for three minutes
> "validating the book" before I gave up and killed it.  Looked at the
> readme some more, it said I could do "make nochunks", which i did, and
> it started validating xml again.  Killed it, opened up the makefile,
> searched for nochunks, it didn't have an obvious dependency on
> validating (oh great, another crawling makefile horror) searched for the
> "Validating the book" string, put an echo in front of its targets, that
> did nothing, searched again and found a SECOND instance of this, put an
> echo in front of THOSE targets, and then make nochunks died with:
>
> Generating profiled XML for XHTML...
> warning: failed to load external entity "tmp/blfs-full.xml"
> unable to parse tmp/blfs-full.xml
> make: *** [tmp/blfs-html.xml] Error 6
>
> That was about the limit of my interest for the moment.  I have a guess
> why you have no new developers.
>

Not everyone who uses or develops against BLFS automates it.  Of
course some of us don't have time to sift through the plethora of
packages either.  In my case, the items I use from BLFS work just
fine, so there's no need for help in developing those sections.  If
one of them broke then I'd definitely speak up.

I wish I had the time to build more sections to help with this
project.  I can see that happening in the near future fortunately.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bruce Dubbs | 1 Aug 2011 18:20
Picon

Re: The State of BLFS

+Jan wrote:

> I do have a question directed to the maintainers.  I know a lot
> of the packages have three types of dependencies listed:  Required,
> Recommended and Optional.  Are all of these conditions expected to be
> tested to consider it stable?  I would imagine that the Required and
> Recommended are, but the Optional is just listed for reader
> convenience under the assumption that they have never worked with the
> package before.

The required dependencies are those where the editor determines that the 
package will not build without them.

The recommended dependencies are a personal opinion of the editor that 
the package needs to be useful, but is not, strictly speaking, 
essential.   There is a difference of opinion whether a recommended 
section should exist at all.

The optional dependencies are those that the editor has determined can 
be used by the package, usually by examining the ./configure output or 
documentation from different sources.  Many times the editor has not 
built the optional dependencies at all, especially if that package is 
not already in BLFS.

   -- Bruce
--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Moffat | 1 Aug 2011 21:38
Picon
Favicon

Re: The State of BLFS

On Mon, Aug 01, 2011 at 10:59:02AM -0500, +Jan wrote:
> 
> Perhaps what is needed is a way to easily determine what is broken and
> what is not.  There seems to be a split consensus of whether releases
> are necessary or not.  If BLFS was to do a release in the near future,
> I think the easiest way would be to mark packages with a category tag
> of some sort indicating the status of that particular segment of the
> project.  As purely part of the suggestion, here's three categories I
> think would be useful:
> 
>  * Stabilized (tested against the current LFS)
>  * Unstable (as in no longer builds against current LFS)
>  * Development (as in new to the book and YMMV)
> 
 That was part of the thinking for the tags such as -
This package is known to build and work properly using an LFS-6.7
platform.

 Of course, since BLFS hasn't managed a release, the older tags are
not tremendously helpful.  However, the absence of a tag may
indicate that nobody cares about a package.

 The problem with "tested against the current LFS" is that you can
only do that after an LFS release - all sorts of version increments
in LFS sometimes have knock-on effects.

 I would hope that anything added to BLFS will at least build with
the current LFS release.

 Of course, when LFS upgrades the toolchain, all manner of things
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jonathan Oksman | 2 Aug 2011 17:09
Picon

Re: The State of BLFS

On Mon, Aug 1, 2011 at 3:38 PM, Ken Moffat <ken <at> linuxfromscratch.org> wrote:
>  The problem with "tested against the current LFS" is that you can
> only do that after an LFS release - all sorts of version increments
> in LFS sometimes have knock-on effects.
>

Very good point.  I guess whether things have been tested or not would
have to be flagged as untested every time LFS pushed a minor release
or errata, especially when talking about the compiler tools and
libraries.  Even if the tags were automatically reset through xml
processing somehow, it would still mean a complete check of the book
on version changes.

With that in mind, it definitely seems better to flag the last version
of LFS a package was built against, instead of some obscure
development flag.

>  I would hope that anything added to BLFS will at least build with
> the current LFS release.
>
>  Of course, when LFS upgrades the toolchain, all manner of things
> break.  In those cases, as with looking for security fixes,
> builders need to look at the distros.
>
> ĸen

As someone who wants to help BLFS I was just thinking it would be
useful to have a faster way to determine what needs work and what
doesn't without flipping through every single page.  Tags on the
development index indicating the last good build versus LFS (eg. a
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ken Moffat | 2 Aug 2011 18:37
Picon
Favicon

Re: The State of BLFS

On Tue, Aug 02, 2011 at 11:09:25AM -0400, Jonathan Oksman wrote:
> 
> I'm not sure how the tags you're talking about are actually
> implemented though, Ken.  I haven't looked at the xml version of the
> book in a couple of years.  They might be implemented on the page
> level, complicating propagation outside of the individual package
> pages.
> 
 Yes, they are on the individual pages.  Various lfs{65..67}_checked,
lfs{65..67}_built, also lfssvn versions (with the svn date
hardcoded in the page) and lfs65_needs_update - these are all defined
in general.ent.  If anyone cares about what might be out of date,
it's probably quicker to go through the pages in a browser and check
them.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Permalink | Reply | 0 comments |
headers
Partha Chowdhury | 13 Aug 2011 07:29
Picon

Can I build only libreoffice-writer component instead of whole suite ?

I have successfully built libreoffice-3.3.3.1. However, I see that on 
libreoffice website,each component is offered as a separate tarball.So 
now is it possible to build only the specific components i.e I want to 
build only libreoffice-writer component.
--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Permalink | Reply | 0 comments |
headers
akhiezer | 17 Aug 2011 19:06

Re: The State of BLFS


Hi,

I'd suggest that the best way forward from here, is to pick a released 
LFS version, base a BLFS version off of it, and release the completed 
BLFS version within 18 months of the LFS release.

For example, LFS-6.7 was released on 18/Sept/2010: can BLFS-6.7 be 
released by 18/Mar/2012 ?

If in practice 'BLFS-6.7' can't be based exactly off LFS-6.7, but 
instead needs some adjustment (say, a minor version of perl - just for 
example), then by all means do so, and call the release 'BLFS-6.7.1' 
(or similar); and include a section at the start of the released BLFS 
book, detailing the what/why/&c of the adjustment. *NB* that the 
adjustment need not necessarily be backported or otherwise applied to 
LFS itself: i.e. there's no essential need to release LFS-6.7.1 - don't 
get hidebound.

During said development period of BLFS-6.7, there will of course be LFS 
releases further to LFS-6.7, namely LFS-6.8 (4/Mar/2011), LFS-7.0 (early 
Sept 2011), and perhaps also LFS-7.1 (early March 2012). *But*, there's 
no essential need for BLFS-6.7 to try to keep up with and incorporate 
anything from LFS-6.8 et seq: you're aiming to release BLFS-6.7(.x) - 
not BLFS-6.8(.x), etc; again, don't be/get hidebound.

After BLFS-6.7(.x) is released, the focus can shift to the next BLFS 
version. Which does not necessarily need to be 'BLFS-6.8' based off 
LFS-6.8  . Instead, the BLFS folks would decide what next version of 
LFS (subsequent to LFS-6.7) would be the best one to use as a basis.
(Continue reading)

Permalink | Reply | 0 comments |
headers
akhiezer | 21 Aug 2011 23:04

"BLFS-6.7.x"


Hi,

I'm considering building a system based on BLFS-svn-20110728 and LFS-6.7  .

Are Wayne/Guy/Randy/etal interested in receiving any 
patches/confirmations/feedback/&c from that process, towards a release 
of BLFS-6.7.x by end March 2012 at latest?

If yes, then is it ok to mail the info mainly as patch-format attachments, 
to the 'blfs-book <at> ...' list; with the patches being generated from diffs 
of the xml tree of the svn book? And those with commit &c rights, can 
pick 'em up from there?

The areas covered here, in the first instance at least, would be - in 
approximate order of 'requirements' and their 'dependencies':
----
* X/Print software: SeaMonkey, Xpdf/ePDFView/GSview, CUPS/LPRng.

* X Windows, running twm. (Besides, KDE/GNOME seem handled just fine by 
  Randy/Thomas/&c).

* some userland stuff from chapters 6, 10, 11, 15, 16, & 18 : mostly 
  'classical'.

* some sysadmin stuff from chapters 4, 11, 16, & 17 : mostly 'classical'.

* servers - much of chapter 19, plus ntp/sendmail/procmail/bdb/rsync. 
  (The machine is partly a general test-area.)
(Continue reading)

Permalink | Reply | 7 comments |
headers
Randy McMurchy | 22 Aug 2011 00:43
Picon
Favicon

Re: "BLFS-6.7.x"

On 8/21/2011 4:04 PM, akhiezer wrote:
> I'm considering building a system based on BLFS-svn-20110728 and LFS-6.7  .
>
>
> Are Wayne/Guy/Randy/etal interested in receiving any
> patches/confirmations/feedback/&c from that process, towards a release
> of BLFS-6.7.x by end March 2012 at latest?

Yes, bring 'em on! If the patches are in the correct format and
it appears you have a good handle on the book and the XML, I'll
set you up so that you can commit them yourself!

Regards,
Randy

--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Permalink | Reply | 1 comment |
headers
DJ Lucas | 22 Aug 2011 01:16
Picon
Favicon

Re: "BLFS-6.7.x"

On 08/21/2011 05:43 PM, Randy McMurchy wrote:
> On 8/21/2011 4:04 PM, akhiezer wrote:
>> I'm considering building a system based on BLFS-svn-20110728 and LFS-6.7  .
>>
>>
>> Are Wayne/Guy/Randy/etal interested in receiving any
>> patches/confirmations/feedback/&c from that process, towards a release
>> of BLFS-6.7.x by end March 2012 at latest?
> Yes, bring 'em on! If the patches are in the correct format and
> it appears you have a good handle on the book and the XML, I'll
> set you up so that you can commit them yourself!
>
> Regards,
> Randy
>
Cool!

-- DJ Lucas

-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Permalink | Reply | 0 comments |

Gmane