devel September 2004

devel@lists.fedoraproject.org

251 participants
243 discussions

libsoup / evolution broken dependencies?
by Naoki 03 Sep '04

03 Sep '04

.......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?

4 3

problems running qemu-arm under Fedora Core 2.
by Lennert Buytenhek 03 Sep '04

03 Sep '04

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 -----

1 0

Fedora on DVD-RW?
by Jean-Luc Fontaine 03 Sep '04

03 Sep '04

-----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-----

4 3

CONFIG_HIGHMEM64G=y for x86_64 SMP kernels
by Ed Hill 03 Sep '04

03 Sep '04

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

10 19

Re: [PATCH] net-tools 1.60: deferred ifconfig netmask
by Florin Malita 02 Sep '04

02 Sep '04

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>

2 1

Segfault in update-desktop-database
by Matthias Saou 02 Sep '04

02 Sep '04

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

1 0

RPM debuginfo problems
by Eric Smith 02 Sep '04

02 Sep '04

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

2 1

One update too far - help 2
by Bob Gustafson 02 Sep '04

02 Sep '04

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

5 8

RFC: Fedora Extras shipping ix86 optimized rpms?
by Ralf Corsepius 02 Sep '04

02 Sep '04

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

9 17

[PATCH] net-tools 1.60: deferred ifconfig netmask
by Florin Malita 02 Sep '04

02 Sep '04

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

4 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel September 2004