[blfs-dev] Why is my message to this list being blocked?
krejzi at email.com
Sat Feb 11 14:23:42 PST 2012
On 11.2.2012 18:52, Ken Moffat wrote:
> On Sat, Feb 11, 2012 at 02:53:35PM +0000, Andrew Benton wrote:
>> On Sat, 11 Feb 2012 15:15:00 +0100
>> "Armin K."<krejzi at email.com> wrote:
> [ replying more to some points in the original than to Andy's reply]
>>> Now I tried again, but failed with same message from mail system. Here
>>> is original mail:
>>> Hello there. I have noticed lot of commits to blfs book lately. Good
>>> job team, just keep it going! I wish I could help.
>>> Yet, I am unable to change anything directly, but here are few notes
>>> that I've noticed when compiling some of packages.
>>> Please, don't attack me with "Why must that be so in the book" or
>>> something like that. I just put this here as a reference.
> Aww, c'mon, attacking people can be so much fun ;) but seriously,
> thanks for the suggestions.
>>> I know what are you guys like. You like minimal stuff and so, but yet
>>> not everyone is like you and not everyone is skilled enough to find
>>> everything he needs for something.
>>> So, let's start from the beginning of the book:
>>> Linux PAM can use libtirpc if someone wants to enable NIS support.
>> I install PAM but I don't use NIS so I've never installed libtirpc. I
>> can check this out and update the PAM dependencies in a day or 2
> I thought NIS was more or less defunct with current glibc ? That
> is my understanding from past threads.
> I *do* install libtirpc (for NFS), but not PAM. It's first on my
> list of things to try (e.g. for gdm) once I've got the first-cut
> gnome-3 into the book. I expect some pain getting PAM working
> adequately, so I'm not attempting it until then.
Yes. NIS/RPC headers were removed from glibc 2.14, and whole RPC/NIS
interface was removed from glibc 2.15 breaking all apps that use it. Yet
devs told us to use libtirpc since it's ipv6 capable or whatever.
>>> polkit does not require seperate user anymore as noted on
>>> If you look at NEWS file in polkit source dir, you can notice this one:
>>> Changes since PolicyKit 0.94:
>>> David Zeuthen (20):
>>> Remove POLKIT_USER from configuration summary
>>> Michael Biebl (8):
>>> Remove POLKIT_USER option
>>> NOTE: This is just stripped output.
>>> Old PolicyKit on
>>> http://www.linuxfromscratch.org/blfs/view/svn/postlfs/policykit.html is
>>> dead for some time and it has became polkit, it can be safely removed
>>> from the book.
>> I don't install
> I haven't read the polkit changes, and understanding the
> implications will take me some time. If anyone else cares, feel
> free to take this. Otherwise, I'll maybe take a look in the spring.
>>> User notes on
>>> http://www.linuxfromscratch.org/blfs/view/svn/postlfs/mdadm.html point
>>> to http://wiki.linuxfromscratch.org/blfs/wiki/xfs Is this correct?
>> I can fix that now.
>>> The glib 2.30 compile will fail if dbus is not installed. (Though it's
>>> only on gdbus tests iirc)
>> Yes, dbus should be listed as an optional dependency to run the tests.
>> I'll fix that now.
> Pedantically, only the tests will fail ;-) We established (two or
> three weeks ago?) that none of us who are currently doing the edits
> have much regard for testsuites for BLFS packages in real life.
>>> colord can use libsane. You can list it as optional.
> Again, added to my 'ToDo if nobody else picks it up' list.
>>> ScrollKeeper from
>>> isn't used anymore. Rarian package provides compatibility for it. It
>>> can be removed.
>> I agree, can we remove scrollkeeper please?
> Sure. Why not.
>>> Besides fcron, you could add cronie from
>>> https://fedorahosted.org/cronie/ which is in fact based on original
>>> vixie cron but with some enhancments.
> fcron works for me - what do you get from cronie that isn't
> available from fcron ?
Well, I like it's PAM and SELinux support.
>>> DBus GObject Bindings from
>>> aren't used nor developed anymore. They can be safely removed.
> I didn't know that.
>>> I note hal is still there, but yet many of software has been ported
>>> from hal to gio/gvfs/gudev. Only package that I know that may use it is
>>> gnome-vfs and yet hal is optional there.
>> I've never used HAL and would also like to see it removed from the book.
> I didn't get as far as investigating what uses it (I regard it as
> junk), but in reviewing gnome-3 it seemed to me that it was probably
> obsolete. I'd put it on my 'ask about this in the summer' list - if
> it's gone, I for one will not miss it.
>>> UPower can also use libimobiledevice. You can add it as optional with
>>> an external link to their site.
>>> gvfs 1.10 can also use libimobiledevice and libbluray libraries. You
>>> can add them as optional.
> Both added to my 'ToDo if nobody else picks it up' list
>>> If you install python3.2 from
>>> first, you won't get /usr/bin/python, but /usr/bin/python3 ... Symlinks
>>> can be made for it to be default.
> Therein lies gentoo, or was it arch ? I have no interest in
> python3, and it's sufficiently different that I think anyone wanting
> to use it should invoke it by name (if upstream no longer install it
> as python).
Agreed. Many python apps are still 2.0 ... Migration is going to take
long time tough.
>>> Samba 3.6 will also fail to compile without libtirpc if using glibc
>>> 2.14 or 2.15 ...
> No interest.
>>> Avahi 0.6.28 (Why 0.28 when there is 0.6.30?) program avahi-autoipd
>>> also requires seperate user avahi-autoipd with home
>>> dir /var/lib/avahi-autoipd.
> I'm waiting to see what emerges from Wayne's review of this - he's
> added bootscripts after I changed something based on input the other
> day. As to why 0.6.28 when 0.6.30 exists - that's easy : Wayne had
> started the preparations for that version. Personally, I have no
> interest in using it at the moment.
Yet I don't think nothing special has changed in 0.6.28 -> 0.6.30 except
some fixes/enhancments. Install layout is still the same, as daemon
>>> In libproxy 0.4.7 WebKit 1.0 library is required, not 3.0, so it would
>>> be nice if mentioned.
> Interesting. I had been going to suggest (if I didn't already),
> half in jest, that libproxy could be dropped from the book since it
> is no longer required by the gnome packages and now uses that
> unpleasant replacement for configure. Do you use it ?
I think glib-networking is only app that uses it now. (previously libsoup)
>>> As for Samba and Linux PAM, xinetd will also fail to compile using
>>> glibc 2.14 or 2.15. Explicitly linking libtirpc with LDFLAGS=-ltirpc
>>> solved that problem for me.
> Why do we still have xinetd in the book ?
>>> gtkmm has been updated to 3.x version, but same as for gtk 2.0 and gtk
>>> 3.0, there may be need for gtkmm 3.0 and gtkmm 2.0 libraries which
>>> don't conflict with each other.
> I don't understand. gtkmm-3.2.0 is either in the book or about to
> be, for gnome-3. What will need the 2.0 version ?
Yet there are not apps in book that use it, but there are apps that use
it! For example, pulseaudio programs - pavucontrol and paprefs.
>>> Same for libwnck.
> Now that definitely is a gnome package, but seems to be only used
> in shell fallback (i.e. for Metacity - which is what I'm using on
> *my* gnome desktop because I have old video cards) and 3.2.1 is used
> there. Why do you think that using the old version is a good idea ?
Same as for gtkmm.
>>> KDE4 section is a mess. Yet even required dependencies don't have links
>>> to the packages in book.
> No interest - I gave up on kde4 years ago, too many straws broke
> this camel's back (figuratively speaking - it was a car that did it
> in the literal sense)
>>> Yet gnome pre installation configuration list
>>> GNOME_SYSCONFDIR=/etc/gnome/3.2.2 even tough many packages have files
>>> that should go into /etc (Yet every sane distribution and person list
>>> only sysconfdir as /etc for every gnome package)
> We've aregued around this in the past. I agree with your comment
> in parenthesis, but we have people who think some of the files in
> /etc/ should be in /var/lib. Wayne prepared GNOME_SYSCONFDIR for
> gnome-3, changing the book to /etc is not a priority for me (for the
> gnome packages).
>>> gstreamer bad plugins list kdebase dependency for kate, but yet there
>>> is standalone libkate on http://code.google.com/p/libkate/ that doesn't
>>> require bunch of qt3 stuff.
> I didn't know that. To be honest, trying to work out what the hell
> is going on in the various parts of gstreamer is impossible for me
> (e.g. -bad appears to reference -ffmpeg and, from memory, perhaps
> -good or -ugly which all sounds unlikely). Note my circumlocution
> for the camera dependencies - I didn't have a problem with them
> when I was ignoring most of gnome-3, but something broke by the time
> I was looking at them fpr the book. Too much else had gone into my
> build by then for me to have any idea which package caused the
> problem (might have been pulse, or qt4, or something totally
>>> libdvdread 0.9.7 can't be used with gstreamer ugly plugins. Newer
>>> version is required.packages
>> Download link for newer version? I can only find an svn download from
> From memory, libdvdread is one of the forked packages - it's in the
> 'plural zones', use whatever works for you. I didn't notice a problem
> with 4.1.3, unless it was the package that broke the camera examples.
Last time when I tried to compile with 0.9.7 it was looking for
dvdread-config and that one is available only in 4+ version iirc.
>>> PulseAudio can also optionally use libasyncns and fftw
> I've no real interest in adding this to my ToDo list - there is a
> newer (1.0) version of pulse - that didn't work for me when I tried
> it in a non-gnome context, and it required one extra package, so like
> all of the packages from that stable I'm reluctant to touch it.
> (Trying to avoid starting a straw man argument, since this is BLFS :)
PulseAudio is a mess, I agree. But yet gnome 3 requires it to build and
even gnome mixer requires it to function. But for pulseaudio to work
properly I install alsa plugins package and create ~/.asoundrc or
/etc/asounrc to route all sound to pulseaudio.
>>> CUPS can use Avahi's libdns-sd compatibility library for DNS-SD
>>> support. Note, there are also CUPS-AVAHI patches that link against
>>> avahi libraries.
> I build cups-1.5 differently from the book, so I have no interest
> in these additions.
> ĸen, wishing he hadn't volunteered to be the gnome-3 monkey ;)
I've sucessfully built gnome 3.0, 3.2 and I am on my way building 3.4
(dev version). If I can help somehow, just say it!
More information about the blfs-dev