Headsup: new API and ABI changing goffice update headed towards rawhide
by Hans de Goede
Hi All,
I've been working on updating gnumeric to the 1.8.x tree, this needs the latest
stable 0.6 series of goffice, therefor I'm also updating goffice from 0.2 to
0.6, which means a change in soname, and in API.
The only other user is abiword, a patch for abiword for the 0.5 devel series of
goffice, which lead to the 0.6 release is available here:
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/abiword-goffice05.pat...
It should be trivial to adjust this patch to make abiword 's charting plugin
work with goffice-0.6 (search replace 0.5 with 0.6).
---
Another problem is that we also have the special goffice04 package as some
packages needed goffice-0.4, while others where still using 0.2 . For now we
can keep this package until the 0.4 users move over to 0.6, but there is a
conflict between goffice04 and the new goffice-devel . The problem are a bunch
of files under /usr/share/gtk-doc/html/goffice. Notice that this are API
reference doc, so in the goffice04 case the are wrongly in the main package and
they should be moved to the -devel package. This would make the conflict less
severe as it then is a conflict between devel files, but still a conflict.
Suggestion, move those files to the -devel package of goffice04 and put them
under /usr/share/gtk-doc/html/goffice04 to avoid the conflict.
Thanks & Regards,
hans
16 years, 3 months
Fedora 8 installation crash
by Thomas Swan
I don't think this is just you. When trying to install F8 on an HP laptop
(in text mode)
loader received SIGSEGV! Backtrace:
[0x804a030]
[0x110420]
[0x81a3f42]
[0x805b750]
[0x805c153]
[0x804b207]
[0x8175004]
0x8048151]
Installing in graphical mode yields the following error messages:
*** glibc detected *** /sbin/loader: munmap_chunk(): invalid pointer:
0x0850c810
=== Backgrace: ===
[0x81a4083]
[0x805b750]
[0x805c153]
[0x804b207]
[0x8175004]
[0x8048151]
======= Memory map =======
00110000-00111000 r-xp 001110000 00:00 0 [vdso]
08048000-0828e000 r-xp 00000000 00:01 36 /sbin/loader
0828e000-08299000 rw-p 00245000 00:01 36 /sbin/loader
08299000-082d3000 rw-p 08299000 00:00 0
0849b000-08589000 rw-p 0849b000 00:00 0
b7f36000-b7f39000 rw-p b7f36000 00:00 0
bfedb000-bfef0000 rw-p bffea000 00:00 0
loader received a SIGABRT! Backtrace:
[0x804a030]
[0x110420]
[0x81e7f80]
[0x8182a30]
[0x819930b]
[0x81a4003]
[0x805b750]
[0x805c153]
[0x804b207]
[0x8175004]
[0x8048151]
install exited abnormally [1/1]
This exact same problem happens when installing from known good media on
both USB DVD drives and the local dvd drive.
I am using the Fedora-8-i386-DVD.iso. Memtest has been run on this system
and there are no memory errors.
This doesn't seem to be isolated. <
http://www.nabble.com/F8-Installation-Issue---Second-Try-tf4806216.html#a...
>
--
The early bird may get the worm, but the it's the second mouse that gets the
cheese.
16 years, 3 months
Headsup: new API breaking libgda on its way to rawhide
by Hans de Goede
Hi,
I'm working on updating gnumeric to the stable 1.8.x version, however in true
gnumeric fashion (they've done this before). This requires the development
version of libgda-3.1.2.
This sounds worse then it is as the development version has mainly received
bugfix and for the mostly libgda-3.0.so.3 its fully compatible with the 3.0.x
series, the main reason why its a development series is because the API of
libgda-report-3.0.so.3 has changed (but not the soname ???).
This probably affects the following packages:
gnome-python2-gda-0:2.19.1-11.fc8.i386
libgdamm-0:2.9.8-1.fc8.i386
gnumeric-1:1.6.3-13.fc8.i386
libgnomedbmm-0:2.9.5-2.fc8.i386
glom-0:1.6.5-1.fc8.i386
gnumeric-1:1.6.3-12.fc8.i386
libgnomedb-1:3.0.0-3.fc8.i386
I say probably because there are false positives in this list, the libgda-3.0.1
.pc file contains:
-lgda-report-3.0 -lgda-3.0 -lgdasql-3.0
Which causes all applications linking to libgda to depend on gda-report-3.0,
even though they most likely in reality do not.
One of the fixes in the new libgda-3.1.2, is that the .pc file now only contains:
-lgda-3.0 -lgdasql-3.0
And a new seperate libgda-report-3.0.pc has been added. For example of a false
positive caused by this, "rpmlint libgnomedb" gives the following on a system
with libgnomedb installed:
libgnomedb.i386: W: unused-direct-shlib-dependency
/usr/lib/libgnomedb_graph-3.0.so.4.0.0 /usr/lib/libgda-report-3.0.so.3
So libngomedbmm most likely is a false positive to, still when in doubt do a
rebuild. I'll send another mail once the new libgda is available in the buildroot.
Thanks & Regards,
Hans
16 years, 3 months
Re: Yum, Proxy Cache Safety, Storage Backend
by chasd
Les Mikesell wrote:
> It sounds fairly horrible to me to have every single application you
> might run that could share something set up its own file sharing
> service
> and client
As usual, I my idea didn't come out that well in words.
My plan is as follows :
1)
Configure yum to keep downloaded rpms.
Put a file in /etc/httpd/conf.d to share the contents of /var/cache/
yum/updates-released/packages.
2)
Publish a service via mdns-avahi-Bonjour that would allow yum to
discover packages stored on nearby machines.
3)
Write a yum plugin that looks for those published services and
consumes them instead of from an Internet source.
An occasional "yum clean all" ( monthly cron ? ) would clear out cruft.
Instead of configuring and maintaining a server to store update rpms,
any node that has installed an update can share it with another node.
Charles Dostale
16 years, 3 months
In rawhide prelink -avR doesn't work, switch to -avmR
by Bruno Wolff III
This might not really impact things. I didn't test using -av as the cron
scripts do. But if the -R option doesn't use up address space faster (which
I don't know), then the cron scripts may need to be modified.
This is sample output that I got:
[root@cerberus bruno]# /usr/sbin/prelink -vaR
/usr/sbin/prelink: /usr/bin/kbabeldict.#prelink#.UJB6Nz: Could not find one of the dependencies
/usr/sbin/prelink: /usr/bin/kbabel.#prelink#.PUsLOh: Could not find one of the dependencies
/usr/sbin/prelink: /usr/bin/gnucash-bin: Could not find one of the dependencies
/usr/sbin/prelink: /sbin/mdassemble.static: PT_INTERP segment not corresponding to .interp section
/usr/sbin/prelink: /sbin/fence_xvmd: Could not find one of the dependencies
Laying out 518 libraries in virtual address space 00101000-50000000
Random base 0x3b0f0000
/usr/sbin/prelink: Could not find virtual address slot for /usr/lib/libwireshark.so.0
The last message about wireshark is the fatal one. The other messages showed
up when using the -m option, but did not prevent prelinking.
16 years, 3 months
Re: Yum, Proxy Cache Safety, Storage Backend
by chasd
Alexander Bostr?m wrote:
> Wild idea:
>
> A yum plugin that short-circuits any downloading where the expected
> checksum of the data is known beforehand. It would first ask on the
> local network for the file, providing:
>
> * The baseurl or mirrorlist url.
> * The path relative to the root of the repo.
> * The name of the file.
> * The expected checksum.
>
> If no yum cache service is available on the network, no such
> service has
> a suitable file or the request times out (a short timeout, 1 second
> perhaps), the plugin would fall back to the baseurl or mirrors as
> usual.
That looks to me like an ad-hoc peer-to-peer network.
If you have a small network of machines and want to take advantage of
caching, share the files yum has cached locally to other Fedora
network nodes.
Sounds like a project for me, eh ?
Charles Dostale
16 years, 3 months
Heads up: cracklib license changed
by Nalin Dahyabhai
Heads up: the cracklib license has changed from "Artistic" to "GPLv2" in
the version which is building now.
The consumers I found using repoquery (netatalk, pam, revelation) should
all be fine with that, but I'm sending this anyway just in case.
Cheers,
Nalin
16 years, 3 months
