libsoup / evolution broken dependencies?
by Naoki
.......Unable to satisfy dependencies
Package evolution-data-server needs libsoup-2.2.so.6, this is not available.
Package evolution needs libgal-2.2.so.0, this is not available.
Package evolution needs libgal-a11y-2.2.so.0, this is not available.
Package evolution needs libsoup-2.2.so.6, this is not available.
# rpm -q libsoup libgal libgal-a11y
libsoup-2.2.0-1
package libgal is not installed
package libgal-a11y is not installed
Is this my brokenness?
19 years, 8 months
problems running qemu-arm under Fedora Core 2.
by Lennert Buytenhek
Hi all,
qemu (http://www.bellard.org/qemu) is a "FAST! processor emulator
using dynamic translation to achieve good emulation speed", according
to its web site.
qemu contains a program called 'qemu-arm', which will let you run
ARM binaries under an x86 or any other linux host. This program
works fine most of the time, but it doesn't quite work very well
with Fedora 2 and its kernels.
First of all, I need 'setarch i686' to get qemu-arm to run at all
under Fedora 2. Second, since the 2.6.7-1.494.2.2 kernel update,
qemu doesn't work anymore even when using setarch.
Has anyone else seen this? Any idea where I should look?
cheers,
Lennert
----- Forwarded message from Lennert Buytenhek <buytenh> -----
Date: Fri, 3 Sep 2004 16:42:23 +0200
From: Lennert Buytenhek <buytenh>
To: yangh(a)coretek.com.cn, qemu-devel(a)nongnu.org
Subject: Re: cause found for qemu-arm problems on fedora 2 (Re: [Qemu-devel] Problem with running machine code specified in the program)
In-Reply-To: <20040903133400.GA22817(a)xi.wantstofly.org>
User-Agent: Mutt/1.4.1i
On Fri, Sep 03, 2004 at 03:34:00PM +0200, Lennert Buytenhek wrote:
> > I got "qemu: uncaught target signal 11 (Segmentation fault) - exiting" when
> > running program like that:
>
> I was running into this too, and just checked it out. You should do:
>
> 1. Run 'setarch i686 qemu-arm' instead of 'qemu-arm'.
> 2. Downgrade to the original 2.6.5 kernel that came with FC2.
>
> It seems that qemu-arm broke somewhere between fedora's version of
> 2.6.6 and 2.6.8, their current kernel. I'm trying the intermediate
> releases right now.
OK, here are my findings.
I tried qemu-arm from qemu 0.5.5 and from all daily qemu CVS snapshots
between 20040504 and 20040901. Of those, there are actually only 16
different qemu-arm binaries (with a distinct md5 sum), so I only used
those.
I tried the Fedora Core 2 kernels 2.6.5-1.358 (original), 2.6.6-1.427,
2.6.6-1.435, 2.6.6-1.435.2.1, 2.6.6-1.435.2.3, 2.6.7-1.494.2.2 and
2.6.8-1.521 (the latest.)
On all kernels, you get a sig11 if you run without 'setarch i686'.
If you run with 'setarch i686', kernel 2.6.6-1.435.2.3 still runs
everything fine, but 2.6.7-1.494.2.2 breaks all qemu versions except
for the 20040519 CVS snapshot. And on the kernel after that,
2.6.8-1.521, all qemu versions are broken. If I then try to set
vm.legacy_vm_layout to 1, 20040519 starts working again, but all
other snapshots before and after remain broken.
Puzzled.
--L
----- End forwarded message -----
19 years, 8 months
Fedora on DVD-RW?
by Jean-Luc Fontaine
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I just had a (possibly stupid) thought:
Would it be possible to make a live Fedora DVD-RW, a fully operational
system with write access, enabling the user to carry his OS and data at
the same time?
Myabe it has been done already?
Cheers,
- --
Jean-Luc Fontaine mailto:jfontain@free.fr http://jfontain.free.fr/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBN2iokG/MMvcT1qQRAs5BAKCpbdJ2SVdbNGRhK1/I7VM7lCUmXACfXBrL
lSMeLNhu+lJz669P9fBwnFA=
=SDAN
-----END PGP SIGNATURE-----
19 years, 8 months
CONFIG_HIGHMEM64G=y for x86_64 SMP kernels
by Ed Hill
Hi folks,
I've been using FC2 and devel kernels for one of our dual-Opteron
systems and am very happy with recent improvements. Everything works
well for us including:
- AMD IDE interface
- tg3 driver (dual Broadcom BCM5704 GigE)
- 3w_9xxx driver (8-port 3ware SATA card)
The only request I have is that the following be added to the x86_64-SMP
kernel config:
CONFIG_HIGHMEM=y
CONFIG_HIGHMEM64G=y
I've been building custom kernels based on the testing SRPMs with just
this one small change and (for us at least) it works well on:
kernel-2.6.7-1.494
kernel-2.6.8-1.524
kernel-2.6.8-1.533
Would it be possible to make "CONFIG_HIGHMEM64G=y" the default for SMP
x86_64 kernels? I bow to the kernel experts, but it does appear to be a
reasonable default given the likelihood of SMP Opterons having more than
4Gig RAM.
And I'll gladly add this to bugzilla if someone will recommend the best
topic for it.
Ed
--
Edward H. Hill III, PhD
office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave.
Cambridge, MA 02139-4307
emails: eh3(a)mit.edu ed(a)eh3.com
URLs: http://web.mit.edu/eh3/ http://eh3.com/
phone: 617-253-0098
fax: 617-253-4464
19 years, 8 months
Re: [PATCH] net-tools 1.60: deferred ifconfig netmask
by Florin Malita
On Thu, 2004-09-02 at 01:32, Pekka Savola wrote:
> Shouldn't we rather be removing ifconfig or making it ready-only
> instead, as /sbin/ip seems to be vastly superior ?
While I agree that ip is superior, I think lots of people still use
ifconfig for basic network configuration. Removing it will confuse some
users and break many scripts:
grep ifconfig /etc/sysconfig/network-scripts/*
Regards,
--
Florin Malita <florin.malita(a)glenayre.com>
19 years, 8 months
Segfault in update-desktop-database
by Matthias Saou
Hi,
I'm not quite sure what the problem might be exactly, so I'm sending the
backtrace I get from an update-desktop-database segfaut with the latest FC
Devel before bugzilla'ing it.
# gdb update-desktop-database
[...]
(gdb) set args /usr/share/applications
(gdb) run
Starting program: /usr/bin/update-desktop-database /usr/share/applications
** (process:16018): CRITICAL **: file eggdesktopentries.c: line 1044
(egg_desktop_entries_get_string): assertion `group != NULL' failed
Program received signal SIGSEGV, Segmentation fault.
0x08049a55 in process_desktop_files (
desktop_dir=0xfef48c15 "/usr/share/applications", prefix=0x804d0b3 "",
error=0x0) at update-desktop-database.c:121
121 for (i = 0; mime_types[i] != NULL; i++)
(gdb) bt
#0 0x08049a55 in process_desktop_files (
desktop_dir=0xfef48c15 "/usr/share/applications", prefix=0x804d0b3 "",
error=0x0) at update-desktop-database.c:121
#1 0x08049e8b in main (argc=0, argv=0x0) at update-desktop-database.c:356
#2 0x00adea93 in __libc_start_main () from /lib/tls/libc.so.6
#3 0x08049841 in _start ()
(gdb)
I think I've been seeing this segfault from %post scriplets for over a week
already.
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Red Hat Enterprise Linux AS release 3 (Taroon) - Linux kernel 2.6.8-1.521
Load : 0.34 0.55 0.52
19 years, 8 months
RPM debuginfo problems
by Eric Smith
When I try to rebuild Fedora RPMs, I routinely complaints like:
error: Could not open %files file
/home/esmith/rpmbuild/BUILD/kernel-utils-2.4/debugfiles.list: No such
file or directory
Google shows that many other people encounter this as well. The
conventional wisdom seems to be that the solution is to edit the
spec file to add:
%define debug_package %{nil}
Or (better) add to ~/.rpmmacros:
%debug_package %{nil}
While this does allow the RPM to be built, it is not a particularly
satisfying solution. It seems unlikely that these SRPMS are being
distributed in a broken state, so surely there must be some intent that
they build correctly WITH a debug package as output. The Fedora
download server does offer debuginfo RPMs for all of the packages for
which I've seen this problem, so obviously it can be done.
So my question is, how is this SUPPOSED to work? Why doesn't building
these packages work correctly "out-of-the-box", and what is required to
get it to do so?
Thanks,
Eric Smith
19 years, 8 months
One update too far - help 2
by Bob Gustafson
That was modprobe that Segv'ed, not mod_ins
BobG
>I managed to download and yum update this morning, however:
>
>When I boot:
> I see lots of mod_ins segment faults. Seems to be that the arguments to
>mod_ins are illformed.
>
>My network is not ifup after the boot. Moreover, when I do the little trick:
>
>/etc/sysconfig/network-scripts/ifup eth0
>
>there is a complaint that eth0 does not exist.
>
>if I do /sbin/ifconfig I only see the lo device.
>
>----
>
>To get more updates, I need a network.
>
>What is the best way to proceed manually to bring up eth0 so I can contact
>the outside world. (My inside world too - cannot contact this machine
>either).
>
>System is i686 smp scsi ipv4 - smp538 kernel.
>
>BobG
19 years, 8 months
RFC: Fedora Extras shipping ix86 optimized rpms?
by Ralf Corsepius
Hi,
Question: Shall Fedora Extras support ix86 optimized packages but
i386-compiled packages rsp. under shall circumstances shall Fedora
Extras support such packages?
Background: Some folks have started to add i686-built application
packages in addition to i386-built packages to Fedora Extras, claiming
these i686-built, "optimized packages" would result into much better
performance of these packages ("up to factor 2").
I'd rather prefer all packages to be built with RH/FC standard rpm
compilation flags (-march=i386 -mcpu=i686; rpmbuild --target=i386),
because this avoids a lot of the complexity and potential breakdowns of
shipping such "optimized packages" and to ship non-i386 packages only
where absolutely inevitable.
I.e. I'd like to Fedora Extras packaging policy to be extended to make
RH/FC's compilation flags mandatory to packages and to allow building
packages for other rpm-targets only in very rare exceptional cases.
For details of the discussion cf.
https://bugzilla.fedora.us/show_bug.cgi?id=2033
Ralf
--
Registered Linux User #26 http://counter.li.org
19 years, 8 months
[PATCH] net-tools 1.60: deferred ifconfig netmask
by Florin Malita
This has been around for too long:
[root@scox root]# ifconfig eth0:1 192.168.120.12/22
SIOCSIFNETMASK: Cannot assign requested address
[root@scox root]# ifconfig eth0:1 192.168.120.12/22
[root@scox root]#
First time it fails to assign the specified netmask apparently because
it is attempting to do so _before_ assigning the address. Second time it
succeeds as the interface already has an address.
OTOH:
[root@scox root]# ifconfig eth0:1 192.168.120.12 netmask
255.255.252.0
[root@scox root]#
succeeds the first time since the actions are executed in the right
order: SIOCSIFADDR _then_ SIOCSIFNETMASK.
This patch against net-tools-1.60 defers the netmask ioctl when using
implicit/CIDR notation till after the address has been assigned. IOW, it
makes the 2 commands equivalent (as some of us might expect ;).
--
Florin Malita <florin.malita(a)glenayre.com>
diff -aur net-tools-1.60.orig/ifconfig.c net-tools-1.60.new/ifconfig.c
--- net-tools-1.60.orig/ifconfig.c 2001-04-13 14:25:18.000000000
-0400
+++ net-tools-1.60.new/ifconfig.c 2004-08-31 17:07:38.362758712
-0400
@@ -23,6 +23,7 @@
* 20001008 - Bernd Eckenfels, Patch from RH for setting mtu
* (default AF was wrong)
* 20010404 - Arnaldo Carvalho de Melo, use setlocale
+ * 20040831 - Florin Malita <fmalita(a)glenayre.com> delayed
CIDR netmask
*/
#define DFLT_AF "inet"
@@ -227,13 +228,13 @@
int main(int argc, char **argv)
{
- struct sockaddr sa;
+ struct sockaddr sa, sa_netmask;
struct sockaddr_in sin;
char host[128];
struct aftype *ap;
struct hwtype *hw;
struct ifreq ifr;
- int goterr = 0, didnetmask = 0;
+ int goterr = 0, didnetmask = 0, donetmask = 0;
char **spp;
int fd;
#if HAVE_AFINET6
@@ -903,16 +904,16 @@
/* FIXME: sa is too small for INET6 addresses, inet6 should use
that too,
broadcast is unexpected */
if (ap->getmask) {
- switch (ap->getmask(host, &sa, NULL)) {
+ switch (ap->getmask(host, &sa_netmask, NULL)) {
case -1:
usage();
break;
case 1:
if (didnetmask)
usage();
-
- goterr = set_netmask(skfd, &ifr, &sa);
- didnetmask++;
+
+ /* delay setting the CIDR netmask till after setting the
addr */
+ donetmask = 1;
break;
}
}
@@ -960,6 +961,13 @@
}
}
+ /* set CIDR netmask */
+ if (donetmask){
+ donetmask = 0;
+ goterr = set_netmask(skfd, &ifr, &sa_netmask);
+ didnetmask++;
+ }
+
/*
* Don't do the set_flag() if the address is an alias with a -
at the
* end, since it's deleted already! - Roman
19 years, 8 months
