headers
Fernando de Oliveira | 1 Dec 2011 01:04
Picon
Favicon

Xorg wget (was BLFS Progress)

--- Em seg, 14/11/11, Fernando de Oliveira <famobr <at> yahoo.com.br> escreveu:

> De: Fernando de Oliveira <famobr <at> yahoo.com.br>
> Assunto: Re: BLFS Progress
> Para: "BLFS Development List" <blfs-dev <at> linuxfromscratch.org>
> Data: Segunda-feira, 14 de Novembro de 2011, 17:15
> --- Em seg, 14/11/11, Bruce Dubbs
> <bruce.dubbs <at> gmail.com>
> escreveu:
> 
> > De: Bruce Dubbs <bruce.dubbs <at> gmail.com>
> > Assunto: BLFS Progress
> > Para: "BLFS Development List" <blfs-dev <at> linuxfromscratch.org>
> > Data: Segunda-feira, 14 de Novembro de 2011, 2:56
> 
>  If someone could
> > help me out and let 
> > me know what the current version is and what the
> contents
> > of the various 
> > wget lists should be, it would help me a lot.
> > 
> > I'll be glad to do the testing and update the book.
> 
> I will check the wget's in a couple of days.
> 

Hi, Bruce,

Sorry for being so late. I still cannot be completely sure if I the wget's are actually the ones I used. And I do
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bruce Dubbs | 1 Dec 2011 01:11
Picon

Re: Xorg wget (was BLFS Progress)

Fernando de Oliveira wrote:

> Sorry for being so late. I still cannot be completely sure if I the
> wget's are actually the ones I used. And I do not know if these will
> be usefull so late, but just to fulfill my promess, you can find them
> attatched. They are much probably the ones I used. Again, I delayed,
> because I believe they are the ones used, but still can't be sure.
> 
> Please, notice that xf86-video-vmware-11.0.3.tar.bz2 is uncommented.

Thanks.  I'll still be a little while before I can get to Xorg, but I'm 
sure the wget files will be useful.

   -- Bruce

--

-- 
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
Andrew Benton | 1 Dec 2011 02:51
Picon

Re: Firefox

On Sun, 27 Nov 2011 00:15:33 +1100
Wayne Blaszczyk <wblaszcz <at> bigpond.net.au> wrote:

> Could I make one suggestion.
> Can we have the /usr/lib/mozilla/plugins as the directory, and symlink
> to this rather than the other way around as it is now.
> This way, the plugins will not be tie to a specific version of Firefox
> and save the user trouble of copying them across every time Firefox is
> upgraded.

Fernando de Oliveira has just made a good point about this on BLFS
Support. If we put plugins in /usr/lib/mozilla/plugins they'll be found
by all Mozilla products including Thunderbird. This raises security
concerns, if there is an exploitable bug in a plugin. I seem to recall
that there were some problems with Adobe's pdf plugin. Certainly flash
has its bugs. Whatever. The bugs are all there in the browser. If the
user wants an email application that can render html they may well like
to have plugins enabled too. Personally I prefer Sylpheed because it
doesn't render html but each to their own.

What do other people think? Should I change the Firefox/Xulrunner pages
so they don't suggest putting the plugins in /usr/lib/mozilla/plugins?

Andy
--

-- 
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 | 3 comments |
headers
Ken Moffat | 1 Dec 2011 02:48

Re: nfs server problems

On Wed, Nov 30, 2011 at 03:40:08PM -0600, Bruce Dubbs wrote:
> The other thing that is might be is the kernel config.  I have:
> 
 Sorry about the delay replying, but I've been exploring dhcp
options.

> CONFIG_NETWORK_FILESYSTEMS=y
> CONFIG_NFS_FS=y
> CONFIG_NFS_V3=y
> CONFIG_NFS_V3_ACL=y
> CONFIG_NFS_V4=y
 I haven't set v4, so far.
> # CONFIG_NFS_V4_1 is not set
> CONFIG_ROOT_NFS=y
> # CONFIG_NFS_USE_LEGACY_DNS is not set
> CONFIG_NFS_USE_KERNEL_DNS=y
> # CONFIG_NFS_USE_NEW_IDMAPPER is not set
 I don't see any of these five options!  Are they all for v4 ?  If
not, the two you have set *might* be problematic, dunno. I'm running
3.1.1 at the moment.

> CONFIG_NFSD=y
> # CONFIG_NFSD_DEPRECATED is not set
 again, I don't see this
> CONFIG_NFSD_V3=y
> # CONFIG_NFSD_V3_ACL is not set
> # CONFIG_NFSD_V4 is not set
> CONFIG_LOCKD=y
> CONFIG_LOCKD_V4=y
> CONFIG_NFS_ACL_SUPPORT=y
(Continue reading)

Permalink | Reply | 5 comments |
headers
Aleksandar Kuktin | 1 Dec 2011 03:59
Picon

Fast tracking dependency resolving

I have a tip to share regarding the dependency checking currently
going on.

While I do not know what exactly is the way editors check for
dependencies of packages, there is a way to fast track them, if your
main method is to build and wait to see which is the combination that
does not fail - a horrendous experience.

Now, dependencies are checked by the configure script, which itself is
generated from configure.ac (I am not sure what is the position of
configure.in in all this..).

Therefore, one can gain a lot of information on which packages are
required by inspecting the configure* files.

Say, like this:
grep -h -v '^[[:space:]]*dnl' <package_dir>/configure* | \
grep -v '^[[:space:]]*#' | grep --color -i req

A sample output, this one from pan, the newsreader:

AC_PREREQ(2.54)
GLIB_REQUIRED=2.14.0
GMIME_REQUIRED=2.4.0
GTK_REQUIRED=2.16.0
GTK3_REQUIRED=3.0.0
GTKSPELL_REQUIRED=2.0.7
AC_SUBST(GLIB_REQUIRED)
AC_SUBST(GMIME_REQUIRED)
AC_SUBST(GTK_REQUIRED)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ken Moffat | 1 Dec 2011 04:25
Picon
Favicon

Re: Fast tracking dependency resolving

On Thu, Dec 01, 2011 at 03:59:41AM +0100, Aleksandar Kuktin wrote:
> I have a tip to share regarding the dependency checking currently
> going on.
> 
> While I do not know what exactly is the way editors check for
> dependencies of packages, there is a way to fast track them, if your
> main method is to build and wait to see which is the combination that
> does not fail - a horrendous experience.
> 
> Now, dependencies are checked by the configure script, which itself is
> generated from configure.ac (I am not sure what is the position of
> configure.in in all this..).
> 
> Therefore, one can gain a lot of information on which packages are
> required by inspecting the configure* files.
> 
> Say, like this:
> grep -h -v '^[[:space:]]*dnl' <package_dir>/configure* | \
> grep -v '^[[:space:]]*#' | grep --color -i req
> 

 The grep looks handy, thanks!  Personally, I mostly build *before*
I double-check the dependencies.  Then, from my logs I note the
things it checks for as regular names (e.g. for xorg-server xmlto
xsltproc etc) and then list the names of the other things where it
uses pkg-config, e.g. PIXMAN, UDEV, DBUS, ...).  Most packages use
impenetrable names, e.g. libdmx checks for DMX.  I then use vim to
read the configure script and find that in that case it looks for
x11 xext xextproto dmxproto >= 2.2.99.1.  Mostly, but not
always,identifying which package produces a particular .pc file is
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bruce Dubbs | 1 Dec 2011 04:23
Picon

Re: nfs server problems

Ken Moffat wrote:
> On Wed, Nov 30, 2011 at 03:40:08PM -0600, Bruce Dubbs wrote:
>> The other thing that is might be is the kernel config.  I have:
>>
>  Sorry about the delay replying, but I've been exploring dhcp
> options.
> 
>> CONFIG_NETWORK_FILESYSTEMS=y
>> CONFIG_NFS_FS=y
>> CONFIG_NFS_V3=y
>> CONFIG_NFS_V3_ACL=y
>> CONFIG_NFS_V4=y

>  I haven't set v4, so far.

>> # CONFIG_NFS_V4_1 is not set
>> CONFIG_ROOT_NFS=y
>> # CONFIG_NFS_USE_LEGACY_DNS is not set
>> CONFIG_NFS_USE_KERNEL_DNS=y
>> # CONFIG_NFS_USE_NEW_IDMAPPER is not set

>  I don't see any of these five options!  Are they all for v4 ?  If
> not, the two you have set *might* be problematic, dunno. I'm running
> 3.1.1 at the moment.

>> CONFIG_NFSD=y
>> # CONFIG_NFSD_DEPRECATED is not set

>  again, I don't see this
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ken Moffat | 1 Dec 2011 04:44
Picon
Favicon

Xorg packages - building less, and minimal config

 Since we seem to be getting into discussing what to build in xorg,
I'll throw in my tuppence worth.  The following are all working for
me on LFS-7.0, and I don't have an xorg.conf.  What I do have is
/usr/share/X11/xorg.conf.d containing 10-evdev.conf (installed by
xorg-server) and 11-keyboard.conf (included at the end, along
with an alternative 10-keyboard.conf found on the xorg lists).

 My keyboard works correctly (no need to use the xset invocations in
xorg.conf that I have mentioned in the past - the "evdev" keyboard
type takes care of the cursor keys - and no need to specify which
events to use).  Also, I use ctrl-alt-backspace to kill the server.

 As before, I've reduced the xorg-apps, although there is probably
still more here than really necessary - why bother building example
apps just because in xorg-6.9 we had to build them ?  Similarly,
no core fonts (slight detrimental effect to xcalc, see the note).

 Unfortunately, I haven't yet built current Mesa - trying to sort
that out before I'd got a graphical browser didn't seem the best use
of my time - so I'm still on the 7.10 series.

 Also, this is only tested on old radeon R200 cards so I have no
idea about versions of nouveau, intel, unichrome, or other current
video drivers, and I don't know if this version of Mesa needs other
settings (e.g. in libdrm) or dependencies for intel, nouveau.

 Feel free to comment, but PLEASE trim what you are replying to.
Thanks.  This is the order in which I build them.

ĸen
(Continue reading)

Permalink | Reply | 9 comments |
headers
Bruce Dubbs | 1 Dec 2011 05:01
Picon

Re: Fast tracking dependency resolving

Ken Moffat wrote:
> On Thu, Dec 01, 2011 at 03:59:41AM +0100, Aleksandar Kuktin wrote:
>> I have a tip to share regarding the dependency checking currently
>> going on.
>>
>> While I do not know what exactly is the way editors check for
>> dependencies of packages, there is a way to fast track them, if your
>> main method is to build and wait to see which is the combination that
>> does not fail - a horrendous experience.
>>
>> Now, dependencies are checked by the configure script, which itself is
>> generated from configure.ac (I am not sure what is the position of
>> configure.in in all this..).
>>
>> Therefore, one can gain a lot of information on which packages are
>> required by inspecting the configure* files.
>>
>> Say, like this:
>> grep -h -v '^[[:space:]]*dnl' <package_dir>/configure* | \
>> grep -v '^[[:space:]]*#' | grep --color -i req
>>
> 
>  The grep looks handy, thanks!  Personally, I mostly build *before*
> I double-check the dependencies.  Then, from my logs I note the
> things it checks for as regular names (e.g. for xorg-server xmlto
> xsltproc etc) and then list the names of the other things where it
> uses pkg-config, e.g. PIXMAN, UDEV, DBUS, ...).  Most packages use
> impenetrable names, e.g. libdmx checks for DMX.  I then use vim to
> read the configure script and find that in that case it looks for
> x11 xext xextproto dmxproto >= 2.2.99.1.  Mostly, but not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruce Dubbs | 1 Dec 2011 05:17
Picon

Re: Xorg packages - building less, and minimal config

Ken Moffat wrote:
>  Since we seem to be getting into discussing what to build in xorg,
> I'll throw in my tuppence worth.  The following are all working for
> me on LFS-7.0, and I don't have an xorg.conf. 

Good info, but I do think I'll need a xorg.conf file.  I have two hi-res 
monitors and a high end nvidia card and I think I need the proprietary 
driver to get that working properly.

Also I really don't want to install in /usr because it makes upgrades 
while using a GUI much harder.

>  As before, I've reduced the xorg-apps, although there is probably
> still more here than really necessary - why bother building example
> apps just because in xorg-6.9 we had to build them ?  Similarly,
> no core fonts (slight detrimental effect to xcalc, see the note).

> xcalc-1.0.3
>  NB omitting core fonts means that the sqrt key doesn't show the
>  correct symbol.  I used to build the adobe 75 or 100 dpi (according
>  to screen size) and misc-misc fonts for some years, but I stopped
>  bothering - I don't use square roots normally.

I like galculator because it supports RPN.

Generally I build all the apps to just check for the book.  I do use 
xpdf because I can't cut/paste from kpdf.  I probably need to look at 
other options.  I also use xeyes.  Sometimes they are useful for finding 
the mouse cursor.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane