<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.linux.lfs.general">
    <title>gmane.linux.lfs.general</title>
    <link>http://blog.gmane.org/gmane.linux.lfs.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27189"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27188"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27186"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27180"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27167"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27164"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27163"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27158"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27157"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27154"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27146"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27139"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27139"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27137"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27130"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27122"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27115"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27109"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27108"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.lfs.general/27101"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27189">
    <title>lightweight library and utility alternatives</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27189</link>
    <description>&lt;pre&gt;Just wondering if anyone's using any more lightweight alternatives on
their systems rather than the usual standards.  For instance, busybox
or toybox instead of the usual GNU tools, gettext-tiny instead of
gettext, pkg-conf instead of pkg-config.  If you're using any
alternative libraries or utilities as replacements, would be curious
to hear what you're using.  Thanks.

Sincerely,
Laura
http://www.distasis.com/cpp
&lt;/pre&gt;</description>
    <dc:creator>LM</dc:creator>
    <dc:date>2013-05-05T15:17:52</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27188">
    <title>★ Read your message before it gets deleted!</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27188</link>
    <description>&lt;pre&gt;Read the message that Dominic Ringuet left for you before it gets deleted!

To read your message, follow this link:
http://us1.badoo.com/01225901433/in/727H7KEJDFI/?lang_id=3&amp;amp;g=57&amp;amp;m=65&amp;amp;mid=51854c4900000000000300000195b949033dc8ef0019



If clicking the links in this message does not work, copy and paste them into the address bar of your browser.

This email is part of our delivery procedure for the message sent by Dominic Ringuet. If you have received this email by mistake, please ignore it. The message will be deleted soon.

Have fun!
The Badoo Team

You have received this email from Badoo Trading Limited (postal address below).
http://us1.badoo.com/impersonation.phtml?lang_id=3&amp;amp;email=lfs-chat%40linuxfromscratch.org&amp;amp;block_code=72b4cf&amp;amp;m=65&amp;amp;mid=51854c4900000000000300000195b949033dc8ef0019

Badoo Trading Limited is a limited company registered in England and Wales
under CRN 7540255 with its registered office at Media Village, 131 - 151 Great Titchfield Street, London, W1W 5BB.-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-chat
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page&lt;/pre&gt;</description>
    <dc:creator>Badoo</dc:creator>
    <dc:date>2013-05-04T17:58:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27186">
    <title>Live CD</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27186</link>
    <description>&lt;pre&gt;Just wondering, what happen to the LFS LiveCD project?
&lt;/pre&gt;</description>
    <dc:creator>Kenno Han</dc:creator>
    <dc:date>2013-04-30T06:42:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27180">
    <title>init script management</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27180</link>
    <description>&lt;pre&gt;I'm very tempted to try to write something similar to chkconfig but in
Python, primary motive for me is something to have in RPM scriptlets.

But before I do, is there already something? Well, obviously there's
chkconfig but the two versions I know of are compiled (overkill) and a
perl version that apparently is overly complex (I think part of
SuSE ??).

Also, before I do, does it look like LFS is sticking with SystemV init
(my preference) opposed to systemd? I prefer SystemV init but that's
mostly because lately my short term memory isn't so good, and thus it's
hard to learn a new system ;)

If I do write my own, my goal is to try to make it more or less
universal (no need to make special headers in the init script) but have
it potentially use headers (like the dependency part of LFS init script
headers) if they exist.

&lt;/pre&gt;</description>
    <dc:creator>Alice Wonder</dc:creator>
    <dc:date>2013-04-29T09:15:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27167">
    <title>LFS in EPub format</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27167</link>
    <description>&lt;pre&gt;Would anyone be interested in downloading .epub versions of the LFS book?
I'm already working on converting the older ones into .epubs out of boredom
and lack of anything better to do.

Eleanore Boyd
&lt;/pre&gt;</description>
    <dc:creator>Eleanore Boyd</dc:creator>
    <dc:date>2013-04-24T20:41:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27164">
    <title>My experience with rpm and lib64</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27164</link>
    <description>&lt;pre&gt;Round One - I did LFS pretty much by the book and installed the needed
dependencies by the LFS book - lua and elfutils are optional but not in
blfs so I didn't build them.

Python 2 is in the book but make test fails a few tests, probably
because of lack of network - but rpm with python support fails to
compile. I'll investigate later.

Before I started bootstrapping I did something hackish and removed the
{,/usr}/lib64 symlinks, moving the lib to lib64, and then moving none
lib64 stuff (like locale) back. It seemed to work.

The configure system of rpm appears to be broken. It does not detect
that I am linux, but instead uses none. However, config.guess does
correctly identify me as linux. Output of config.guess is same as on any
linux distribution. The compiled binary however does know I'm linux.

So the result is rpmbuild looks for linux macros that aren't there, and
very basic macros like %{_arch} are not defined.

cd /usr/lib/rpm/platforms
cp -ar x86_64-none x86_64-linux
cp -ar noarch-none noarch-linux

fixes that issue.

rpmbuild though then failed to build shared libraries

editing /usr/lib/rpm/macros

and changing

%_host                  x86_64-pc-none
to
%_host                  x86_64-pc-linux

and

%_host_os               none
to
%_host_os               linux

seemed to fix that. Now it would build shared libraries, but it could
not extract the dependency or provides information, it was missing the
tools to do that.

Apparently elfutils is not optional, and I wondered if not having it was
what caused the platform mis-detection during configure.

So I installed elfutils, it's install file indicated it was a
simple ./configure &amp;amp;&amp;amp; make &amp;amp;&amp;amp; make install.

Installing elfutils however broke the compiler. And that is exactly why
I want a proper package management system. My guess is elfutils install
replaced something in the tool chain.

Round 2 - Fortunately I had a second LFS root and scripts for building
LFS (CH5 and CH6) - so I started over from within that root, but this
time modifying the scripts to use {,/usr}/lib64 from the start. That way
it would be cleaner.

There were a few issues:
glibc - the localedef program wants to use /usr/lib64/locale which is
wrong. I did not see an obvious configure switch to make it do the right
thing, probably need to run a post configure sed on a makefile but for
now I manually moved the directory and made a symlink so localedef used
by other programs can find it.

udev - the custom lfs makefile needed a few edits for lib64, I have a
patch if anyone interested, seems to work just fine.

libkmod - it put the libraries in the right place and the .pc file was
correct but it installed into /usr/lib/pkgconfig instead
of /usr/lib64/pkgconfig.

One package from blfs - either nspr or nss (nss I think) put its
libraries in wrong place but it did not have a configure script, so I
suspect a sed will fix that in the future. I manually moved them.

This time I did not build python, I will build python inside of rpm once
I have the system bootstrapped. That will make it easier to try
different configure switches to see if I can get rpm to build against
it. I also did not build elfutils. First I'm going to bootstrap the
system using rpms that don't have the automated dependency stuff, that
way I can build elfutils inside rpm and it will be easier to see what it
conflicts with that broke the compiler, and I can remove it if need be.

But anyway, now I'm in a clean LFS 7.3 with a separate {,/usr}/lib64 and
at least a primitive but working rpm. Tested by building the Fedora 18
lua rpm (it's not in blfs and Fedora has some nice patches that make it
easier to get as a shared library) - it built and installed perfectly :)

So now I'm busy writing spec files, test building them in Fedora 18
(where I can use rpmlint to find issues - mostly documentation that
isn't utf8, iconv usually fixes them - often it's a changelog or old man
page)

nspr and nss are first since one of them (nss I think) wasn't a clean
install into lib64, then I'll go in the order of the book - hopefully
figuring out how to get localedef to use /usr/lib/locale

So - sorry for the length, but I don't have a blog ;) and I thought
someone might be interested.

&lt;/pre&gt;</description>
    <dc:creator>Alice Wonder</dc:creator>
    <dc:date>2013-04-14T02:09:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27163">
    <title>opaque types in C</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27163</link>
    <description>&lt;pre&gt; Anyone looking at blfs-dev will have noticed I've been having fun
with xine-ui [ Open -&amp;gt; File, via the right mouse button, not working
in 0.99.7 ].  I'll be talking to upstream, but I'm still at a loss
to understand what has happened.

 There is status attached to xine streams.  This is manipuliated by
the xine engine in xine-lib.  For users such as xine-ui it is an
incomplete data type and therefore I can't print its value in
xine-ui files (although I can test it against the known values).

 So, nothing in xine-ui can change this opaque data, right ?

 What is baffling me is that the first change where the status is
altered only moves logo files to a different source directory.

 But after instrumenting the code to find out where it was failing,
I find that all tested versions from that changeset to the current hg
version only work in 'Open -&amp;gt; File' if I change a test from
'== XINE_STATUS_STOP' to '== XINE_STATUS_PLAY' (and doing this
doesn't seem to affect how they work when a file is passed to xine,
or if the MRL browser is used to select a file).

 But this seems impossible.  Anyone recall anything that ever looked
at all like this problem ?  I think I'm heading for breakfast at
Milliways ¹

 To be clear, xine-lib is the same version for all of this, 0.99.6
works fine, as do all tested versions before that first problematic
changeset.

ĸen

¹ : if you don't understand the phrase, see
http://www.urbandictionary.com/define.php?term=Milliways&amp;amp;defid=820286
&lt;/pre&gt;</description>
    <dc:creator>Ken Moffat</dc:creator>
    <dc:date>2013-04-11T21:40:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27158">
    <title>rpm in LFS, /lib64 and /usr/lib64</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27158</link>
    <description>&lt;pre&gt;Hello list,
This is neither LFS nor BLFS so I think this list is best?

Built a LFS 7.3 system and first thing I did was build the necessary
dependencies (according to BLFS instructions for them) to build the RPM
Package Manager.

What I would like to do, and I'll need to do it before I start
bootstrapping the system in RPM, is delete the /lib64 and /usr/lib64
symlinks and create directories in their place so that 64 bit shared
libraries can go into them.

This will likely break building at least temporarily.

Plan to fix building is to initially create symlinks for the libraries
in {,usr}/lib pointing to {,usr}/lib64 and a symlink in /usr/lib for
pkgconfig pointing to ../lib64/pkgconfig

eventually as I rebuild everything in RPM the pkg-config files should
correctly point to 64-bit specific library paths and the pkgconfig
symlink and the library symlinks can be deleted.

libtool .la files - I'll back them up somewhere but I really would like
to get rid of them, Fedora world got rid of them long time ago, they
cause problems (as does rpath)

other than pkg-config files, is there anything else anyone can think of
that might end up biting me?

I have no intent of trying to go multilib but if there ever is a need I
would like it to be as painless as possible and 64-bit specific
libraries and data files (kernel modules excepted) in 64-bit specific
directory makes sense because it is already being done that way on other
multilib RPM based systems.

Thanks for comments / suggestions.

&lt;/pre&gt;</description>
    <dc:creator>Alice Wonder</dc:creator>
    <dc:date>2013-04-10T09:15:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27157">
    <title>cpufreq on SandyBridge in 3.9</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27157</link>
    <description>&lt;pre&gt;if anybody cares (;-)

 In the 3.9-rc kernel there is a new cpufreq driver for Intel
SandyBridge CPUs, enabled by CONFIG_X86_INTEL_PSTATE.  The help
says:

 This driver provides a P state for Intel core processors.
 The driver implements an internal governor and will become
 the scaling driver and governor for Sandy bridge processors.

 When this driver is enabled it will become the perferred
 scaling driver for Sandy bridge processors.

 Since I have a SandyBridge processor on this machine, I enabled
this setting.  The first thing I noticed was that my own cpufreq
initscript failed - I set 'ondemand' as the .config default, and in
the initscript I set that for each core.  But this driver only
provides powersave or performance.  A workaround to set the old
acpi driver is to add intel_pstate=disable to the grub command line.

 After fairly extensive testing, I can confirm that the new driver
is reasonable - my .config default of 'ondemand' brings up the
'powersave' setting which is not very useful - a setting slightly
slower than with powersave in the acpi driver, probably good for
battery life but painful when compiling :)

 The 'performance' setting, OTOH, is good - with the acpi driver
'performance' stays at full speed (3300 MHz in my case), but with the
new P-state driver it falls back to the default 48% speed (1584 MHz
in my case) quickly, and ramps up towards full speed equally
quickly.

 Testing builds of gcc-4.7.2 shows the new 'performance' setting is a
little faster (with -j4)  than the old acpi 'ondemand'.  A kernel
(x86_64) -j4 defconfig build is, however, marginally slower and one
build (hopefully just an outlier!) was quite a lot slower [ typically
6m52 for acpi, 6m57 for intel_pstate but that one build took 7m20 ].

 So, for kernels &amp;gt;= 3.9 on SandyBridge use the 'performance' scaling
governor instead of 'ondemand' if you enable this new driver [ e.g.
test for the /sys/devices/system/cpu/intel_pstate/ directory in your
own initscript, or perhaps change the default setting in your
.config ].

 This was a public information bulletin.

ĸen
&lt;/pre&gt;</description>
    <dc:creator>Ken Moffat</dc:creator>
    <dc:date>2013-03-31T04:09:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27154">
    <title>FW: 3/14/2013 11:58:52 AM</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27154</link>
    <description>&lt;pre&gt;
http://www.sandycreekmining.com/ku/srheu.dlws 



 3/14/2013 11:58:52 AM .


t t-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-chat
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page&lt;/pre&gt;</description>
    <dc:creator>t t</dc:creator>
    <dc:date>2013-03-14T10:58:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27146">
    <title>Multiarch LFS</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27146</link>
    <description>&lt;pre&gt;Has anybody entertained the idea of multiarch (not current multilib) on 
an LFS style build yet? I intend to do this, but if anybody has already 
done so, I'd appreciate notes, patches, and what not.

For those unfamiliar: http://wiki.debian.org/Multiarch/
 From my POV, unlike the previous disagreement of lib&amp;lt;qual&amp;gt; amongst 
distributions, this _seems_ to be much cleaner and well thought out, 
especially with a couple of examples in place already (Fedora has been 
doing this in parallel as well as Debian and Ubuntu, but isn't really in 
the spotlight yet).

&lt;/pre&gt;</description>
    <dc:creator>DJ Lucas</dc:creator>
    <dc:date>2013-02-10T19:18:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27139">
    <title>set -e in bash (long)</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27139</link>
    <description>&lt;pre&gt;Hi All,

 I'm revising my buildscripts (long, _slow_ process) and as part of
that I'm changing from prodigious use of '&amp;amp;&amp;amp;', with tests of "$?"
when necessary, to 'set -e' and relying on the script to fail.  But
I'm having some results that aren't what I expected - advice would
be welcome.  Long details, for those who care:

 In general, I have a series of "driver" scripts (build all of
/tools, build all of chroot, build all of xorg, etc), and each of
these invokes a number of other scripts, mostly to build and install
a package : these I call the "client" scripts.

 For the client scripts, 'set -e' seems to be working fine.  But for
the driver scripts I've continued to use '&amp;amp;&amp;amp;', even with 'set -e',
because things started to fall over after a client script failed [
i.e. the driver continued, attempting to run the subsequent client
scripts ].

 Today, I've just discovered that my build of GConf3 was incomplete
(logs seem to start after the main install, which did nothing) -
enough has changed since then that I'm willing to believe that was a
result of some other problem.  The end result was that the
gconf-2.0.pc files was missing.  I've just rerun GConf, now it is
fine so I'm not worrying about that part of the problem.

 What surprises me, and causes me to admit that I'm out of my depth
here, is that my gnome driver script invoked the client script to
build geoclue.  That failed in 'configure' because gconf-2.0.pc was
missing [ so far, so good ], but the '&amp;amp;&amp;amp;'s in the driver script
nevertheless allowed it to invoke webkit, yelp, epiphany,
epiphany-extensions [ which all failed, of course ] together with all
the other gnome packages I build (which all seem to have installed
ok).

 Summary: both the 'driver' and 'client' scripts use 'set -e', the
clients fail as expected if things go wrong, but the driver appears
to be [sometimes] seeing a status of 0 from them.  I'm sure that my
earlier testing implied that a forced failure in a client (invoking
a non-existent command) returned a non-zero status to the driver
script, so '&amp;amp;&amp;amp;' caused the driver to bypass remaining packages.

 Probably, this means that my understanding of set -e is a long way
short of adequate :)  I can live with that, but help in
understanding the problem - and in stopping the driver script after
the client fails - would be much appreciated.

 This is on a build of LFS-7.2, bash --version | head -n1 :
GNU bash, version 4.2.36(2)-release (x86_64-unknown-linux-gnu)

 For anyone who kept reading, Thanks.

ĸen
&lt;/pre&gt;</description>
    <dc:creator>Ken Moffat</dc:creator>
    <dc:date>2012-11-20T17:27:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27139">
    <title>set -e in bash (long)</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27139</link>
    <description>&lt;pre&gt;Hi All,

 I'm revising my buildscripts (long, _slow_ process) and as part of
that I'm changing from prodigious use of '&amp;amp;&amp;amp;', with tests of "$?"
when necessary, to 'set -e' and relying on the script to fail.  But
I'm having some results that aren't what I expected - advice would
be welcome.  Long details, for those who care:

 In general, I have a series of "driver" scripts (build all of
/tools, build all of chroot, build all of xorg, etc), and each of
these invokes a number of other scripts, mostly to build and install
a package : these I call the "client" scripts.

 For the client scripts, 'set -e' seems to be working fine.  But for
the driver scripts I've continued to use '&amp;amp;&amp;amp;', even with 'set -e',
because things started to fall over after a client script failed [
i.e. the driver continued, attempting to run the subsequent client
scripts ].

 Today, I've just discovered that my build of GConf3 was incomplete
(logs seem to start after the main install, which did nothing) -
enough has changed since then that I'm willing to believe that was a
result of some other problem.  The end result was that the
gconf-2.0.pc files was missing.  I've just rerun GConf, now it is
fine so I'm not worrying about that part of the problem.

 What surprises me, and causes me to admit that I'm out of my depth
here, is that my gnome driver script invoked the client script to
build geoclue.  That failed in 'configure' because gconf-2.0.pc was
missing [ so far, so good ], but the '&amp;amp;&amp;amp;'s in the driver script
nevertheless allowed it to invoke webkit, yelp, epiphany,
epiphany-extensions [ which all failed, of course ] together with all
the other gnome packages I build (which all seem to have installed
ok).

 Summary: both the 'driver' and 'client' scripts use 'set -e', the
clients fail as expected if things go wrong, but the driver appears
to be [sometimes] seeing a status of 0 from them.  I'm sure that my
earlier testing implied that a forced failure in a client (invoking
a non-existent command) returned a non-zero status to the driver
script, so '&amp;amp;&amp;amp;' caused the driver to bypass remaining packages.

 Probably, this means that my understanding of set -e is a long way
short of adequate :)  I can live with that, but help in
understanding the problem - and in stopping the driver script after
the client fails - would be much appreciated.

 This is on a build of LFS-7.2, bash --version | head -n1 :
GNU bash, version 4.2.36(2)-release (x86_64-unknown-linux-gnu)

 For anyone who kept reading, Thanks.

ĸen
&lt;/pre&gt;</description>
    <dc:creator>Ken Moffat</dc:creator>
    <dc:date>2012-11-20T17:27:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27137">
    <title>Two networks, default routs and DNS problems</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27137</link>
    <description>&lt;pre&gt;
Short version:
How do I get two dynamic network interfaces on the same machine to play nice
with each other.

Long version:
I'm rebuilding my main desktop from an ancient LFS to current.  This machine is
connected to my private private LAN on eth0. This network does not and never
will connect to the internet.  My internet connection is by dialup on ppp0.  My
old configuration is almost completely static, LAN ip, hosts file, and
resolv.conf.  But with more wireless devices joining the private LAN, keeping
an accurate hosts file is impossible and I'm tired of going over to the laptop
to see what IP number is assigned to it today.

Enter the dynamic stuff.  I've got  dhcpcd installed and working.  I've got
pppd installed and working.  Now for the problem: as log as ppp0 is down DNS
lookup through the LAN router works.  As soon as ppp0 comes up all DNS requests
go through ppp0 and local lookup fails.  I've currently got dhcpcd configured
to not set any default routs by using the "-G" switch, but pppd needs the
"defaultroute" option set or nothing works.  If dhcpcd set its default route
then pppd fails.

Summary:
With only one network device up, with or without a default route, DNS lookups
work.  With both interfaces up, only the one with the default route
works, with no default routes neither work. 

I don't know what to do to get both working at the same time.  Do I need to
install bind and have it forward the query to the correct name server or is
there some dark corner configuration that I'm missing.


&lt;/pre&gt;</description>
    <dc:creator>Steve Jones</dc:creator>
    <dc:date>2012-10-20T00:26:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27130">
    <title>building multimedia applications</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27130</link>
    <description>&lt;pre&gt;Are there any good resources with information on how to build
multimedia applications without libraries and plug-ins that may be
most liable to patent issues.  I managed to find some information on
this at https://fedoraproject.org/wiki/Forbidden_items?rd=ForbiddenItems
I also found a pruned older version of xine at
http://pkgs.fedoraproject.org/repo/pkgs/xine-lib/  Are there any other
references, documentation, sources for stripped tarballs or related
information out there?  If you have any other information or resources
on this topic, please share.  Thanks.
&lt;/pre&gt;</description>
    <dc:creator>LM</dc:creator>
    <dc:date>2012-10-15T13:29:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27122">
    <title>X Windows and alternatives</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27122</link>
    <description>&lt;pre&gt;I'm working with an older, low resource computer.  Was wondering about
the possibility of using an alternative to X Windows or building a
lightweight version.  If anyone has any tips or pointers to
documentation or more information on the subject, would love to hear
about it.

For SDL 1.2  based applications, I've been able to run some using
directfb without needing X Windows.  However, I don't think this will
work with all the SDL applications I use.  I've also been
experimenting with nano-X and it's capable of handling FLTK 1.3 based
applications as well as some programs that just use the X or Win32
APIs.  Am wondering if there are any Linux distributions that just use
nano-X and never bother with X Windows.  I've been hearing about
Wayland ( http://wayland.freedesktop.org/faq.html ) and it's possible
use on Ubuntu, but it doesn't sound like it's ready for general use
yet.  I've also read about doing minimal X Windows builds such as
KDrive, XVesa, etc.  Sounds like everything needed to do that is
bundled in with X Windows itself, but I haven't been able to dig up
any current documentation on how to build a minimal X Windows system
that just supports Vesa and SVGA systems.  Would be curious if there
are other options and also if anyone's had any experience with any of
these.  Any pointers to more information on this type of thing would
be greatly appreciated.

Thanks.

Sincerely,
Laura
http://www.distasis.com/cpp
&lt;/pre&gt;</description>
    <dc:creator>LM</dc:creator>
    <dc:date>2012-10-01T11:32:52</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27115">
    <title>for lfs help</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27115</link>
    <description>&lt;pre&gt;hi,
have a nice day!
actually i am working on lfs from a couple of days and now i've got the 
error which isnt going.
my host system is ubuntu and i am using it in vmware fusion virtual machine.
so, here is the error.

"lfs&amp;lt; at &amp;gt;burhan-virtual-machine:/mnt/lfs/binutils-build$ sudo 
CC=$LFS_TGT-gcc \AR=$LFS_TGT-ar \RANLIB=$LFS_TGT-ranlib 
\../binutils-2.22/configure \--prefix=/tools \--disable-nls 
\--with-lib-path=/tools/lib
[sudo] password for lfs:
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /bin/sed
checking for gawk... gawk
checking for gcc... x86_64-lfs-linux-gnu-gcc
checking for C compiler default output file name...
configure: error: in `/mnt/lfs/binutils-build':
configure: error: C compiler cannot create executables
See `config.log' for more details."

and here is the config.log file

"This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.64.  Invocation command line was

   $ ../binutils-2.22/configure --prefix=/tools --disable-nls 
--with-lib-path=/tools/lib

## --------- ##
## Platform. ##
## --------- ##

hostname = burhan-virtual-machine
uname -m = x86_64
uname -r = 3.2.0-29-generic
uname -s = Linux
uname -v = #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012

/usr/bin/uname -p = unknown
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:2230: checking build system type
configure:2244: result: x86_64-unknown-linux-gnu
configure:2291: checking host system type
configure:2304: result: x86_64-unknown-linux-gnu
configure:2324: checking target system type
configure:2337: result: x86_64-unknown-linux-gnu
configure:2391: checking for a BSD-compatible install
configure:2459: result: /usr/bin/install -c
configure:2470: checking whether ln works
configure:2492: result: yes
configure:2496: checking whether ln -s works
configure:2500: result: yes
configure:2507: checking for a sed that does not truncate output
configure:2571: result: /bin/sed
configure:2580: checking for gawk
configure:2596: found /usr/bin/gawk
configure:2607: result: gawk
configure:3742: checking for gcc
configure:3769: result: x86_64-lfs-linux-gnu-gcc
configure:3998: checking for C compiler version
configure:4007: x86_64-lfs-linux-gnu-gcc --version &amp;gt;&amp;amp;5
../binutils-2.22/configure: line 4009: x86_64-lfs-linux-gnu-gcc: command 
not found
configure:4018: $? = 127
configure:4007: x86_64-lfs-linux-gnu-gcc -v &amp;gt;&amp;amp;5
../binutils-2.22/configure: line 4009: x86_64-lfs-linux-gnu-gcc: command 
not found
configure:4018: $? = 127
configure:4007: x86_64-lfs-linux-gnu-gcc -V &amp;gt;&amp;amp;5
../binutils-2.22/configure: line 4009: x86_64-lfs-linux-gnu-gcc: command 
not found
configure:4018: $? = 127
configure:4007: x86_64-lfs-linux-gnu-gcc -qversion &amp;gt;&amp;amp;5
../binutils-2.22/configure: line 4009: x86_64-lfs-linux-gnu-gcc: command 
not found
configure:4018: $? = 127
configure:4038: checking for C compiler default output file name
configure:4060: x86_64-lfs-linux-gnu-gcc    conftest.c  &amp;gt;&amp;amp;5
../binutils-2.22/configure: line 4062: x86_64-lfs-linux-gnu-gcc: command 
not found
configure:4064: $? = 127
configure:4101: result:
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:4107: error: in `/mnt/lfs/binutils-build':
configure:4111: error: C compiler cannot create executables
See `config.log' for more details.

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=x86_64-unknown-linux-gnu
ac_cv_env_AR_FOR_TARGET_set=
ac_cv_env_AR_FOR_TARGET_value=
ac_cv_env_AR_set=set
ac_cv_env_AR_value=x86_64-lfs-linux-gnu-ar
ac_cv_env_AS_FOR_TARGET_set=
ac_cv_env_AS_FOR_TARGET_value=
ac_cv_env_AS_set=
ac_cv_env_AS_value=
ac_cv_env_CCC_set=
ac_cv_env_CCC_value=
ac_cv_env_CC_FOR_TARGET_set=
ac_cv_env_CC_FOR_TARGET_value=
ac_cv_env_CC_set=set
ac_cv_env_CC_value=x86_64-lfs-linux-gnu-gcc
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CXXFLAGS_set=
ac_cv_env_CXXFLAGS_value=
ac_cv_env_CXX_FOR_TARGET_set=
ac_cv_env_CXX_FOR_TARGET_value=
ac_cv_env_CXX_set=
ac_cv_env_CXX_value=
ac_cv_env_DLLTOOL_FOR_TARGET_set=
ac_cv_env_DLLTOOL_FOR_TARGET_value=
ac_cv_env_DLLTOOL_set=
ac_cv_env_DLLTOOL_value=
ac_cv_env_GCC_FOR_TARGET_set=
ac_cv_env_GCC_FOR_TARGET_value=
ac_cv_env_GCJ_FOR_TARGET_set=
ac_cv_env_GCJ_FOR_TARGET_value=
ac_cv_env_GFORTRAN_FOR_TARGET_set=
ac_cv_env_GFORTRAN_FOR_TARGET_value=
ac_cv_env_GOC_FOR_TARGET_set=
ac_cv_env_GOC_FOR_TARGET_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LD_FOR_TARGET_set=
ac_cv_env_LD_FOR_TARGET_value=
ac_cv_env_LD_set=
ac_cv_env_LD_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_LIPO_FOR_TARGET_set=
ac_cv_env_LIPO_FOR_TARGET_value=
ac_cv_env_LIPO_set=
ac_cv_env_LIPO_value=
ac_cv_env_NM_FOR_TARGET_set=
ac_cv_env_NM_FOR_TARGET_value=
ac_cv_env_NM_set=
ac_cv_env_NM_value=
ac_cv_env_OBJCOPY_set=
ac_cv_env_OBJCOPY_value=
ac_cv_env_OBJDUMP_FOR_TARGET_set=
ac_cv_env_OBJDUMP_FOR_TARGET_value=
ac_cv_env_OBJDUMP_set=
ac_cv_env_OBJDUMP_value=
ac_cv_env_RANLIB_FOR_TARGET_set=
ac_cv_env_RANLIB_FOR_TARGET_value=
ac_cv_env_RANLIB_set=set
ac_cv_env_RANLIB_value=x86_64-lfs-linux-gnu-ranlib
ac_cv_env_STRIP_FOR_TARGET_set=
ac_cv_env_STRIP_FOR_TARGET_value=
ac_cv_env_STRIP_set=
ac_cv_env_STRIP_value=
ac_cv_env_WINDMC_FOR_TARGET_set=
ac_cv_env_WINDMC_FOR_TARGET_value=
ac_cv_env_WINDMC_set=
ac_cv_env_WINDMC_value=
ac_cv_env_WINDRES_FOR_TARGET_set=
ac_cv_env_WINDRES_FOR_TARGET_value=
ac_cv_env_WINDRES_set=
ac_cv_env_WINDRES_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_build_configargs_set=
ac_cv_env_build_configargs_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_host_configargs_set=
ac_cv_env_host_configargs_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_env_target_configargs_set=
ac_cv_env_target_configargs_value=
ac_cv_host=x86_64-unknown-linux-gnu
ac_cv_path_SED=/bin/sed
ac_cv_path_install='/usr/bin/install -c'
ac_cv_prog_AWK=gawk
ac_cv_prog_ac_ct_CC=x86_64-lfs-linux-gnu-gcc
ac_cv_target=x86_64-unknown-linux-gnu
acx_cv_prog_LN=ln

## ----------------- ##
## Output variables. ##
## ----------------- ##

AR='x86_64-lfs-linux-gnu-ar'
AR_FOR_BUILD='$(AR)'
AR_FOR_TARGET=''
AS=''
AS_FOR_BUILD='$(AS)'
AS_FOR_TARGET=''
AWK='gawk'
BISON=''
BUILD_CONFIG=''
CC='x86_64-lfs-linux-gnu-gcc'
CC_FOR_BUILD='$(CC)'
CC_FOR_TARGET=''
CFLAGS=''
CFLAGS_FOR_BUILD=''
CFLAGS_FOR_TARGET=''
COMPILER_AS_FOR_TARGET=''
COMPILER_LD_FOR_TARGET=''
COMPILER_NM_FOR_TARGET=''
CONFIGURE_GDB_TK=''
CPPFLAGS=''
CXX=''
CXXFLAGS=''
CXXFLAGS_FOR_BUILD=''
CXXFLAGS_FOR_TARGET=''
CXX_FOR_BUILD='$(CXX)'
CXX_FOR_TARGET=''
DEBUG_PREFIX_CFLAGS_FOR_TARGET=''
DEFS=''
DLLTOOL=''
DLLTOOL_FOR_BUILD='$(DLLTOOL)'
DLLTOOL_FOR_TARGET=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EXEEXT=''
EXPECT=''
EXTRA_CONFIGARGS_LIBJAVA='--disable-static'
FLAGS_FOR_TARGET=''
FLEX=''
GCC_FOR_TARGET=''
GCC_SHLIB_SUBDIR=''
GCJ_FOR_BUILD='$(GCJ)'
GCJ_FOR_TARGET=''
GDB_TK=''
GFORTRAN_FOR_BUILD='$(GFORTRAN)'
GFORTRAN_FOR_TARGET=''
GNATBIND=''
GNATMAKE=''
GOC_FOR_BUILD='$(GOC)'
GOC_FOR_TARGET=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_GDB_TK=''
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
LD=''
LDFLAGS=''
LDFLAGS_FOR_BUILD=''
LDFLAGS_FOR_TARGET=''
LD_FOR_BUILD='$(LD)'
LD_FOR_TARGET=''
LEX=''
LIBOBJS=''
LIBS=''
LIPO=''
LIPO_FOR_TARGET=''
LN='ln'
LN_S='ln -s'
LTLIBOBJS=''
M4=''
MAINT=''
MAINTAINER_MODE_FALSE=''
MAINTAINER_MODE_TRUE=''
MAKEINFO=''
NM=''
NM_FOR_BUILD='$(NM)'
NM_FOR_TARGET=''
OBJCOPY=''
OBJDUMP=''
OBJDUMP_FOR_TARGET=''
OBJEXT=''
PACKAGE_BUGREPORT=''
PACKAGE_NAME=''
PACKAGE_STRING=''
PACKAGE_TARNAME=''
PACKAGE_URL=''
PACKAGE_VERSION=''
PATH_SEPARATOR=':'
POSTSTAGE1_CONFIGURE_FLAGS=''
RANLIB='x86_64-lfs-linux-gnu-ranlib'
RANLIB_FOR_BUILD='$(RANLIB)'
RANLIB_FOR_TARGET=''
RAW_CXX_FOR_TARGET=''
RPATH_ENVVAR=''
RUNTEST=''
SED='/bin/sed'
SHELL='/bin/bash'
STRIP=''
STRIP_FOR_TARGET=''
SYSROOT_CFLAGS_FOR_TARGET=''
TOPLEVEL_CONFIGURE_ARGUMENTS='../binutils-2.22/configure --prefix=/tools 
--disable-nls --with-lib-path=/tools/lib'
WINDMC=''
WINDMC_FOR_BUILD='$(WINDMC)'
WINDMC_FOR_TARGET=''
WINDRES=''
WINDRES_FOR_BUILD='$(WINDRES)'
WINDRES_FOR_TARGET=''
YACC=''
ac_ct_CC='x86_64-lfs-linux-gnu-gcc'
ac_ct_CXX=''
bindir='${exec_prefix}/bin'
build='x86_64-unknown-linux-gnu'
build_alias=''
build_configargs=''
build_configdirs='build-libiberty build-texinfo build-flex build-bison 
build-m4 build-fixincludes'
build_cpu='x86_64'
build_libsubdir='build-x86_64-unknown-linux-gnu'
build_noncanonical='x86_64-unknown-linux-gnu'
build_os='linux-gnu'
build_subdir='build-x86_64-unknown-linux-gnu'
build_tooldir=''
build_vendor='unknown'
clooginc=''
clooglibs=''
compare_exclusions=''
configdirs='intl libiberty opcodes bfd readline tcl tk itcl libgui zlib 
libcpp libdecnumber gmp mpfr mpc ppl cloog libelf libiconv texinfo flex 
bison binutils gas ld fixincludes gcc cgen sid sim gdb gprof etc expect 
dejagnu m4 utils guile fastjar gnattools'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
do_compare=''
docdir='${datarootdir}/doc/${PACKAGE}'
dvidir='${docdir}'
exec_prefix='NONE'
extra_host_libiberty_configure_flags=''
extra_mpc_gmp_configure_flags=''
extra_mpc_mpfr_configure_flags=''
extra_mpfr_configure_flags=''
gmpinc=''
gmplibs=''
host='x86_64-unknown-linux-gnu'
host_alias=''
host_configargs=''
host_cpu='x86_64'
host_noncanonical='x86_64-unknown-linux-gnu'
host_os='linux-gnu'
host_subdir='.'
host_vendor='unknown'
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${datarootdir}/man'
oldincludedir='/usr/include'
pdfdir='${docdir}'
poststage1_ldflags=''
poststage1_libs=''
pplinc=''
ppllibs=''
prefix='/tools'
program_transform_name='s,y,y,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
stage1_cflags=''
stage1_checking=''
stage1_languages=''
stage1_ldflags=''
stage1_libs=''
stage2_werror_flag=''
sysconfdir='${prefix}/etc'
target='x86_64-unknown-linux-gnu'
target_alias=''
target_configargs=''
target_configdirs='target-libgcc target-libgloss target-newlib 
target-libgomp target-libstdc++-v3 target-libmudflap target-libssp 
target-libquadmath target-libgfortran target-boehm-gc target-libffi 
target-zlib target-libjava target-libobjc target-libada target-libgo 
target-rda'
target_cpu='x86_64'
target_noncanonical='x86_64-unknown-linux-gnu'
target_os='linux-gnu'
target_subdir='x86_64-unknown-linux-gnu'
target_vendor='unknown'
tooldir=''

## ------------------- ##
## File substitutions. ##
## ------------------- ##

alphaieee_frag=''
host_makefile_frag='/dev/null'
ospace_frag=''
serialization_dependencies=''
target_makefile_frag=''

## ----------- ##
## confdefs.h. ##
## ----------- ##

/* confdefs.h */
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL ""

configure: exit 77"

so, can you tell me what happened?
&lt;/pre&gt;</description>
    <dc:creator>Burhan uddin Raizada</dc:creator>
    <dc:date>2012-09-29T12:10:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27109">
    <title>DESTDIR installs in LFS</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27109</link>
    <description>&lt;pre&gt; I'm reworking my own buildscripts to get better logging of what was
installed.  For some time, my attempts to use 'find ... -newer' have
been giving me dubious results : not only omitting files,
particularly headers, which were installed with old dates, but also
repeating files from the previous package.  At one time I altered my
scripts to cope with what was being recorded in error (sleep after
touching hte marker), but although that seemed to work for a little
while, the problem soon resurfaced and it looks as if that approach
is a loser's game.

 So, I decided to try DESTDIR and friends.  I've added su-tools from
old coreutils to the end of chapter 5. In chapter 6 I'm building as
root and then doing a DESTDIR install as someone else (lfs) to ensure
that DESTDIR will be respected), but keep hitting EPERM problems.
Should I just build as a regular user, then chown the tree to root
before installing (i.e. deviate even further from the BOOK) ?

 My current feeling is that trying to log what gets installed might
not be worth the effort.  For the moment, I've given up on
install_root in chapter 6 glibc - worked fine in chapter 5, but
fails in chapter 6 with
../o-iterator.mk:9: *** empty variable name.  Stop.
make[1]: *** [locale/subdir_lib] Error 2
make: *** [install] Error 2

 Might be me, or might be a bad patchset for bash, or a glibc
problem - I've given up on that part for the moment so that I can
see what else breaks, and I'm now at the "well pissed off" stage.

 Anyone got any words of encouragement, or should I just write this
off ?  At least in BLFS the packages are, in the book, built as a
user, even though some don't respect DESTDIR and at least one still
needs root permissions during a DESTDIR install for chown or similar.

ĸen
&lt;/pre&gt;</description>
    <dc:creator>Ken Moffat</dc:creator>
    <dc:date>2012-09-25T01:31:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27108">
    <title>On desktops, gnome, and generally :)</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27108</link>
    <description>&lt;pre&gt; Just found this (almost three weeks old) from a link on /.

https://plus.google.com/115250422803614415116/posts/hMT5kW8LKJk

LMAO

ĸen
&lt;/pre&gt;</description>
    <dc:creator>Ken Moffat</dc:creator>
    <dc:date>2012-09-17T23:50:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27101">
    <title>[fun] unsigned int is not big enough</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27101</link>
    <description>&lt;pre&gt;I just ran into a fun little thing I thought I ought to share with
people.

I am writing a program for calculating the standardised mortality rates
from various diseases, when I noticed that an unsigned int as well as
an unsigned long on 32-bit x86 architectures is simply not big enough.

On x86_32, both are 4 octets wide, while on x86_64, only int is 4
octets wide. That means they can store values up to 2**32-1 which is
about 4.3 billion which is NOT ENOUGH if you want to calculate
world-wide statistics!

And there I was, foolishly believing that unsigned int so BIG, that I
will never in my life really have to worry about its size. Oh, what a
fool I was.

&lt;/pre&gt;</description>
    <dc:creator>Aleksandar Kuktin</dc:creator>
    <dc:date>2012-09-07T20:59:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.lfs.general/27099">
    <title>3D TV, active shutter, does a TV with more than 120Hz exiswt?</title>
    <link>http://comments.gmane.org/gmane.linux.lfs.general/27099</link>
    <description>&lt;pre&gt;Hi All,

I heard every off topic discussion is allowed here, so here it goes :-)
I am looking for a 3D TV. I've tried passive 3D with polorizing glasses,
but then all the even lines goes to one eye, and the odd lines goed to the
other. When I sit too close, I see black lines between the active lines.
When I sit too far, the screen does not occupy enouch field of view. This
cannot be solvd by a larger 3D monitor, as then the pixels simply become
larger.

I have also looked at active shutter 3D. Unfortunately, when I put on these
glasses, I see the whole world flicker. This happens when the shutters alternate
at 120Hz (60Hz per eye). Does anybody know a model or brand of TV's that
alternates the picture faster?

Best regards,
Cedric

       



&lt;/pre&gt;</description>
    <dc:creator>cedric.dewijs&lt; at &gt;telfort.nl</dc:creator>
    <dc:date>2012-09-05T19:15:36</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.lfs.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.lfs.general</link>
  </textinput>
</rdf:RDF>
