Re: gtkdoc problem
On Tue, 2008-07-01 at 19:13 -0400, Todd Zullinger wrote: Erwin Rol wrote: I ran into problems with some stuff i was working on, but to be sure it isn't my own poor automake knowledge I just downloaded the official glib tar.gz (not rpm) sources and used those to test (with the same result). Okay. I grabbed glib-2.16.3 and successfully built it with: ./configure --enable-gtk-doc make I tried adding --verbose to the xsltproc call in gtkdoc-mkhtml but it made it take longer than I was willing to wait. Instead, I used strace on xsltproc to see what files it was reading. Anyway, perhaps you'd like to poke through the output and see what files you might be missing. The gzipped strace output is at: http://tmz.fedorapeople.org/tmp/xsltproc.strace.gz The trivial diff for the gtkdoc-mkhtml change is: --- gtkdoc-mkhtml.orig2008-01-08 10:39:11.0 -0500 +++ gtkdoc-mkhtml 2008-07-01 17:33:05.0 -0400 @@ -42,7 +42,7 @@ fi if $is_xml; then - /usr/bin/xsltproc --nonet --xinclude \ + strace -o /tmp/xsltproc.strace /usr/bin/xsltproc --verbose --nonet --xinclude \ --stringparam gtkdoc.bookname $module \ --stringparam gtkdoc.version 1.9 \ $gtkdocdir/gtk-doc.xsl $document || exit $? I grepped the strace for files it was opening and I think they boiled down to coming from the following packages: docbook-dtds-1.0-35.fc9.noarch docbook-style-xsl-1.73.2-9.fc9.noarch gtk-doc-1.9-4.fc9.noarch xml-common-0.6.3-23.fc9.noarch Well I fixed the problem, but I have no idea what was wrong. The fix was uninstall gtkdoc and several docbook rpms, and reinstall them, and after that tings worked fine. The install is a x86_64 clean F9, not some F8-F9 update, so i have no idea why it didn't work before. - Erwin -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
gtkdoc problem
Hello all, I have a problem with gtkdoc on Fedora 9. It doesn't want to resolve external references like; ?xml version=1.0? !DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.1.2//EN http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd; [ ] After trying to see if it was a network problem i noticed that there was never any network traffic for that URL. With strace i noticed it tried to stat() the URL and that of course returns an error. When i than looked into gtkdoc-mkhtml i found a --nonet option was used for xsltproc. When i removed that option everything worked fine. (I also tried this with the glib sources, not just my own stuff). The following patch does the trick; --- /usr/bin/gtkdoc-mkhtml.orig 2008-07-01 15:45:25.0 +0200 +++ /usr/bin/gtkdoc-mkhtml 2008-07-01 15:45:34.0 +0200 @@ -42,7 +42,7 @@ fi if $is_xml; then - /usr/bin/xsltproc --nonet --xinclude \ + /usr/bin/xsltproc --xinclude \ --stringparam gtkdoc.bookname $module \ --stringparam gtkdoc.version 1.9 \ $gtkdocdir/gtk-doc.xsl $document || exit $? But somehow this can't be the right solution :-) anybody know what the real fix for the problem is ? TIA, Erwin -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: gtkdoc problem
On Tue, 2008-07-01 at 12:14 -0400, Todd Zullinger wrote: Erwin Rol wrote: You're probably missing a dockbook package. I believe it may be docbook-dtds (which provides docbookx.dtd), but I'm not sure. I have run into this problem before and it was invariably a missing package with needed docbook dtd's or other parts. docbook-dtds-1.0-35.fc9.noarch is installed on my system. But I don't think that is the root of the problem. The SGML files have a reference to a http URL, not a local file. And gtkdoc-mkhtml seems to decide that it will not load anything from the net. Hopefully that gets you going in the right direction. Well i fixed gtkdoc-mkhtml by removing the --nonet, so for now it is OK, but I am just wondering if it is just me being stupid, or if the tool is broken. - Erwin -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: gtkdoc problem
On Tue, 2008-07-01 at 15:40 -0400, Todd Zullinger wrote: Erwin Rol wrote: docbook-dtds-1.0-35.fc9.noarch is installed on my system. But I don't think that is the root of the problem. The SGML files have a reference to a http URL, not a local file. And gtkdoc-mkhtml seems to decide that it will not load anything from the net. I'm still of the opinion that this is caused by missing packages, as it has been in the cases I've run across. What is it that you're building? Can you post the output (or a link to it if it's really large)? I ran into problems with some stuff i was working on, but to be sure it isn't my own poor automake knowledge I just downloaded the official glib tar.gz (not rpm) sources and used those to test (with the same result). Well i fixed gtkdoc-mkhtml by removing the --nonet, so for now it is OK, but I am just wondering if it is just me being stupid, or if the tool is broken. When building official fedora packages, mock doesn't have a network connection on the buildsystem, so removing the --nonet wouldn't work there and we need to find a better solution. :) OK that than explains why the --nonet is there. But some ppl might want to be able to load things from the net. Would it be an idea to have something like a --enable-net option for gtkdoc-mkhtml ? That way ppl can just add that option in their Makefile.am and there is no change to the Fedora buildsystem. It might help to add the --verbose flag to the xsltproc call in gtkdoc-mkhtml. - Erwin -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: rawhide e2fsprogs yum
On Mon, 2006-03-13 at 08:50 -0500, Jeff Spaleta wrote: On 3/13/06, Steve G linux_4e...@yahoo.com wrote: Well, I guess it is needed...is the repo broken ? Its been like this for a week or so. the 32bit tree has e2fsprogs-libs-1.38-12 currently. and the 32bit version is in the rawhide tree... so I don't understand your problem...unless your yum is hitting a stale mirror. The problem seems (I had it too), that yum/rpm are not able to do the update, because there is a collision between a man file from the two versions. I used rpm -e --nodeps to remove the old version and than used yum to install the new version. Without it yum wouldn't want to update it. Since i didn't think much of it, i never bothered to report it. But yes i have seen that error to, and i didn't use a mirror, so it is very unlikely an stale mirror problem. - Erwin
Re: rawhide e2fsprogs yum
On Mon, 2006-03-13 at 06:16 -0800, Steve G wrote: Well, I guess it is needed...is the repo broken ? Its been like this for a week or so. the 32bit tree has e2fsprogs-libs-1.38-12 currently. Its the main package...not the libs. Maybe the manpage was moved from the main package in 1.38-1 to the lib in 1.38-11. And 1.38-12 also has it in the lib so now the update collides with the left over (how ever that happened) 1.38-1 package. just a guess. - Erwin [r...@dhcp83-35 ~]# rpm -e e2fsprogs-1.38-1.i386 error: Failed dependencies: locate + rpm -qf does show that /lib/libcom_err.so.2 is owned by e2fsprogs-1.38-1.i386. --nodeps worked for me (of course you need to quickly install the new version, cause else the programs that need the library will fail). - Erwin
Re: dropdown menu's
On Wed, 2006-03-08 at 18:04 +0530, Rahul Sundaram wrote: Being fixed in GTK 2.10 FYI http://inverted-tree.livejournal.com/49201.html. From the page; A scroll menu patch went in, which gets rid of the blank area which sometimes appeared in for example popup menus and annoyed/confused a lot of people. I am glad to see it says a lot of people :-) - Erwin
