FC4 wishes
by Amitabha Roy
Sorry if someone has already beaten me to it...
Better ACPI support on laptop (battery applet still wants to use APM to suspend)
(I think this might be a more upstream problem). I want to close my laptop lid
and have it hibernate. It should just work (TM).
NetworkManager has bugs and UI problems ironed out.
(again this might be a issue with not-so-great orinoco drivers I am using)
Amitabha
19 years, 5 months
RFC: "Include .la files" rule for packages - revisited
by Michael Schwendt
[Since some guess-work is involved here, I'd like to ask politely for
comments from "people in the know"...]
Some individuals will surely remember the times at fedora.us when it
was discussed whether to delete or include libtool archives (= *.la
files) in RPM packages.
Neither Linux's build-time linkers nor its run-time linkers need these
.la files.
Not even libtool's own dlopen function needs these files anymore to
resolve library dependencies at run-time.
Almost everyone who has done application development with libtool and
automake (and friends) some time in the past, has run into problems
with .la files. Such as unresolvable inter-library dependencies or
build-time problems with moved or non-finalized or wrong libtool
archive files.
So, over time many people have build up the opinion that in RPM
packages, it's better to not include .la files. That reduced the
cases, where .la files are needed, to software which includes old
implementations of libtool dlopen, which strictly require .la files.
At fedora.us, a few such cases have been found during the first months
of activity. But, if memory serves correctly, also a few cases of bad
libtool files.
KDE, on the other hand, provides a library loader class, which depends
on availability of .la files to work correctly. Hence for most KDE
applications it is a good idea to not delete any .la files, because
else the app might fail loading its plugins/components at run-time.
A rule about .la files has never been set in stone. Backed up by many
packages in Red Hat Linux/Fedora Core, where .la files are not
included either, fedora.us packagers have decided to delete .la files
where no obvious breakage is discovered during QA.
Based on fedora.us bug #2284 I've discovered something which I didn't
know before. Could be that it's old news to KDE people:
It has been noticed that Imlib2, a library which uses libtool's API
for loading plugins at run-time, fails in Digikam 0.7. Imlib2 passes
an extension-less library name to lt_dlopenext, which then either
loads .la or .so files, if found. So, including .la files in the imlib
imlib package is not necessary. However, when called from within
Digikam, which is a KDE application, Imlib2's plugin loader fails to
find its *.so files. It does not even search for them. Why? It seems
KDE's libkdecore preloads some libtool related symbols to shield KDE
applications from accessing libtool's lt_dlopenext, lt_dlopen and
lt_dlopen_flag interface functions. A guess without reading the KDE
core source. But I found those symbols being mentioned in libkdecore
(did I guess right?). The shadow lt_dlopennext function from KDE
ignores *.so files and wants *.la files only. Hence Imlib2 fails.
This changes the .la/.so matter a good bit IMO. Where are we now? Do
we still delete .la files till we find out that it breaks something at
run-time? Or do we include .la files (it's a policy for Debian, isn't
it?) till we find that something doesn't build? What is worse?
--
Fedora Core release 3 (Heidelberg) - Linux 2.6.9-1.667
loadavg: 1.55 1.35 1.31
19 years, 5 months
Java status for FC4?
by Tadej Janež
Hi,
I noticed a bunch of new Java packages added to rawhide on 6th of
November, so the following question came to my mind:
Is FC4 geared towards full scale Java adoption?
How does that relate to the jpackage efforts (which are more
distro-independent, I think)?
Lastly, new packages also include Java bindings for gtk, libgnome,
libglade and gconf, so does that mean we can expect desktop applications
written in Java being added to FC in the future?
Thanks,
tadej
19 years, 5 months
Re: Courier-0.47 RPMBuild error
by Sam Varshavchik
Fedora List Subscriber writes:
> Hi list
>
> When trying to build an RPM [yes, I don't have an anvil to drop on my
> foot instead! ;-P ] in FC2 (patched up2date):
>
> // rpmbuild -ta -v courier-0.47.tar.bz2
>
> results in the following error:
>
> // A few lines of output to indicate at what stage this failed ...
> //
> // Processing files: courier-debuginfo-0.47-1.2
> // Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
> // rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> //
>
> RPM build errors:
> File not found by glob:
> /var/tmp/courier-0.47-1.2-buildroot/usr/local/bin/*
This is a bug in rpm/glibc. stracing rpm shows that it globs out
"%{_bindir}/*" by calling stat() on each filename.
In an RPM buildroot image, intra-package soft links are obviously broken,
since they point outside the buildroot. stat() fails on them.
Bug 139460.
Looks like recently rpm switched from lstat() to stat(), when globbing out
%files.
This bug must've been hiding for quite some time. You'll only hit it if
you're building a package that installs softlinks for the first time, or if
the newer version of an installed package installs new soft links.
Otherwise, inside the build root the softlinks point to the existing
installation's files, outside of the buildroot, stat() succeeds, and rpm
processes the results from glob().
19 years, 5 months
glibc-2.3.3-76 problem starting httpd
by Salane KIng
service httpd start
Starting httpd: /usr/sbin/httpd: error while loading shared libraries:
librt.so.1: failed to map segment from shared object: Permission denied
rpm -q --whatprovides /lib/librt.so.1
glibc-2.3.3-76
ls -la /lib/librt.so.1
lrwxrwxrwx 1 root root 14 Nov 14 14:36 /lib/librt.so.1 -> librt-2.3.3.so
ls -la /lib/librt-2.3.3.so
-rwxr-xr-x 1 root root 47896 Nov 10 07:37 /lib/librt-2.3.3.so
19 years, 5 months
FC3, harddisc install and reiserfs.
by dima
How I may install fc3 if my iso images placed on reiserfs partition?
I was burned 2 disc -> cd5 (rescue) and cd1 (install).
I have 4 linux partitions.
/dev/hdb5 (boot, reiserfs) -> format
/dev/hdb6 (/, reiserfs) -> format
/dev/hdb7 (/temp, reiserfs) -> do not format (isos placed on /fedora/iso/{FC3-...cd1.iso and etc})
/dev/hdb8 (swap) -> format.
First try.
1. Boot from cd5, boot: linux vga=792... bla bla bla askmethod reiserfs selinux=0
2. In "installation type" menu I was select "install from harddisk".
3. Select /dev/hdb7, and write in the path "/fedora/iso/" (with/without first and last slashes)
4. Get error: "cannot find isos".
5. In console (alt+f2,f3) i saw messages: cannot mount partition, not ext2, not vfat.
Second try.
1. Boot from cd1, boot: linux vga=792... bla bla bla askmethod reiserfs selinux=0
2. In "installation type" menu I was select "install from harddisk".
3. Select /dev/hdb7, and write in the path "/fedora/iso/" (with/without first and last slashes)
4. Get error: "cannot find isos".
5. In console (alt+f2,f3) i saw messages: cannot mount partition, not ext2, not vfat.
Third try.
1. Boot from cd1, boot: linux vga=792... bla bla bla reiserfs selinux=0
2. Do all steps, make partitions, select packages.
3. When installation wants cd2 (disk was ejected), goto console and write:
cd mnt
mkdir hdb7
mount -t reiserfs /dev/hdb7 /mnt/hdb7
cd hdb7
cd fedora
cd iso
mount -o loop FC3-i386...cd2.iso /mnt/source
get error about unknown loop devices.
How install fc3 from reiserfs partitions, without burning all 4 disks?
In previsious installations (fc2, fc3), I was may install from isos that placed on reiserfs discs.
Thanx.
19 years, 5 months
logwatch: patch for zz-disk_space
by Dario Lesca
This patch for logwatch is usefull when there are device whit long name
into the first column:
#######################################
--- /etc/log.d/scripts/services/zz-disk_space.orig 2004-11-15
00:35:15.875785762 +0100
+++ /etc/log.d/scripts/services/zz-disk_space 2004-11-15
00:36:48.774989023 +0100
@@ -17,7 +17,8 @@
echo
echo "------------------ Disk Space --------------------"
echo
- df -h | grep '^/dev/'
+ #df -h | grep '^/dev/'
+ df -Ph|awk 'NR==1||$1~/^\/dev/ {printf("%-30s %7s %7s %7s %5s %s\n",
$1,
$2, $3, $4, $5, $6)}'
echo
elif [ "$PRINTING" = "y" ] ; then
echo
#######################################
Example, on my FC3 system the df -h command show:
Filesystem Dimens. Usati Disp. Uso% Montato su
/dev/mapper/Vol0-LvRoot
4,9G 2,1G 2,9G 43% /
/dev/hda1 92M 3,6M 88M 4% /boot
none 121M 0 121M 0% /dev/shm
/dev/mapper/Vol0-LvHome
3,0G 184K 3,0G 1% /home
/dev/mapper/Vol0-LvU 24G 22G 2,1G 92% /u
/dev/mapper/Vol0-LvVar
3,9G 95M 3,9G 3% /var
The logwatch report show:
/dev/mapper/Vol0-LvRoot
/dev/hda1 92M 3,6M 88M 4% /boot
/dev/mapper/Vol0-LvHome
/dev/mapper/Vol0-LvU 24G 22G 2,1G 92% /u
/dev/mapper/Vol0-LvVar
and the view is not completed.
It is enough to signal this little problem to this ML or I must do some
other thing ?
Many thanks
--
Dario Lesca <d.lesca(a)solinos.it>
19 years, 5 months
stateless-snapshooter problems
by Carlos Knowlton
Hi,
I trying to install Stateless Linux on a computer lab using FC3 (release
version). I've been following the tutorial, and it's been a breeze so
far, but now I'm at the "4. Creating a snapshot of a prototype system"
section. While attempting to create a snapshot, I get the following
message:
"
[root@localhost user]# stateless-snapshooter -n -p DemoSystem
Traceback (most recent call last):
File "/usr/share/stateless/stateless-snapshooter.py", line 142, in ?
snapshooter.get_next_id (protosystem))
File "/usr/share/stateless/snapshooter.py", line 71, in get_next_id
for snapshot in list_snapshots (protosystem):
File "/usr/share/stateless/snapshooter.py", line 62, in list_snapshots
srv = get_readonly_service ()
File "/usr/share/stateless/snapshooter.py", line 50, in
get_readonly_service
return LDAPUtils.StatelessService (LDAPUtils.ReadOnlyDirectory (cfg))
File "/usr/share/stateless/LDAPUtils.py", line 81, in __init__
Directory.__init__ (self, cfg)
File "/usr/share/stateless/LDAPUtils.py", line 65, in __init__
self.uri = cfg.get_ldap_uri ()
File "/usr/share/stateless/config.py", line 43, in get_ldap_uri
server = self["LDAP_SERVER"].lstrip()
AttributeError: 'NoneType' object has no attribute 'lstrip'
"
Any ideas what I'm doing wrong? Are there any undocumented dependencies
to the "stateless-servers" package that I should may be missing?
Thanks!
Carlos Knowlton
19 years, 5 months
mime types and file icons
by Gérard Milmeister
As I understand it, the new mime type system uses /usr/share/mime
and /usr/share/applications. Are the former locations /usr/share/mime-
info and /usr/share/application-registry now irrelevant. Previously the
icon for a file type was set in .keys file, but I don't see how to do it
in the new system.
19 years, 5 months