Hello, This is my first bug report. If more info is needed jsut let me know and it will be provided. The attached log contains the full emerge attempt. It was generated using #emerge scrollkeeper &>log Here is the short form of the error: mkdir /var/tmp/portage/scrollkeeper-0.3.11- r1/image/usr/share/scrollkeeper/Templates/C mkdir /var/tmp/portage/scrollkeeper-0.3.11- r1/image/usr/share/scrollkeeper/Templates/ca /bin/install: cannot stat `./ca/scrollkeeper_cl.xml': No such file or directory mkdir /var/tmp/portage/scrollkeeper-0.3.11- r1/image/usr/share/scrollkeeper/Templates/da /bin/install: cannot stat `./da/scrollkeeper_cl.xml': No such file or directory I'm new to gentoo and I'm attempting to install and configure GNOME it appears to me that scrollkeeper is required before I can fully install GNOME. Thanks, Greg
Created attachment 6627 [details] emerge scrollkeeper log
well yeah, you need it.. but it works fine here. Does re-emerging help maybe ? Maybe try another version of portage ?
Sorry for what may be a stupid question but "How do you use another version of portage?" I haven't been using gentoo for that long. I just downloaded it and followed the instructions in the install guide. Then I followed the instructions in the desktop guide. I don't know what I could have done wrong. I emerge rsync almost every day and attmept this. A friend of mine thought that maybe between the lines: /var/tmp/portage/scrollkeeper-0.3.11-r1/image/usr/share/scrollkeeper/Templat es/ca /bin/install: cannot stat `./ca/scrollkeeper_cl.xml': No such file or directory there was an unlogged copy statement - so I made sure that umask 022 was in my /etc/profile so that the file would be copied with the right permissions. there are three different .ebuilds 0.2-r4 or soemthing like that 0.3.11 0.3.11-r1 0.2 emerges fine, but the gnome install is looking for 0.3.11-r1 so I think that I could upgrade from 0.3.11 to 0.3.11-r1 but when I try 0.3.11 I'm asked about which file to patch but no matter what I type in the answer appears to be wrong. originally my make.conf file had a huge USE line - my friend also thought that this may be the issue - but I cleaned it out to just gtk -kde -qt. all of the requirements for scrollkeeper (based off of scrollkeeper.scourceforge.org) are upto date on my system: libxml2, libxslt,intltool, libxml2-devel, docbook-dtd412-xml, docbook-xsl-1.48 any ideas? anywhere else I can look? I don't understand how I could get this error and no one else is. and I'm realizing that I probably should have posted this in the forums first... sorry. -Greg
Hi Greg. I had the exact same problem until five minutes ago. :) I got scrollkeeper to install, but I had to do it manually. Here's how I did it. The problem seems to be in the install step - the compile goes fine. So, I did (while in /usr/portage/app-text/scrollkeeper/) ebuild scrollkeeper-0.3.11-r1.ebuild compile; ebuild scrollkeeper-0.3.11-r1.ebuild install; and on install it gave errors. I narrowed it down to this while loop in /var/tmp/portage/scrollkeeper-0.3.11-r1/work/scrollkeeper-0.3.11/cl/templates/Makefile.am: install-data-local: for locale in $(TRANSLATED_LOCALES); do \ $(mkinstalldirs) $(DESTDIR)$(datadir)/scrollkeeper/Templates/$$locale; \ $(INSTALL_DATA) $(srcdir)/$$locale/scrollkeeper_cl.xml \ $(DESTDIR)$(datadir)/scrollkeeper/Templates/$$locale; \ done For whatever reason, this just doesn't work. I wrote a little shell script to make the directories it wants to make, and copy scrollkeeper_cl.xml to them, #!/bin/bash for locale in C ca da de el es fr hu it ja ko nb nl no pl pt_BR ru sk sl sv tr uk vi zh_TW; do \ mkdir ./$locale; cp ./scrollkeeper_cl.xml ./$locale/;\ done and then did ebuild scrollkeeper-0.3.11-r1.ebuild install; ebuild scrollkeeper-0.3.11-r1.ebuild qmerge; And this worked. I don't know enough about Linux or Gentoo to know why that install script doesn't work as is, but this might work as a work-around for you, Greg, until the Gentoo guys fix this for real. If there's any more information I can provide that can help fix this bug, I'll be happy to provide it, if I can. Cheers, Aleksey
if i cant reproduce the problem theres not much change i can fix anything (if theres something to fix).
The steps/info provided by Aleksey - allowed me to get past the bug. I don't know why only two of us seem to have ever recieved this error. If you're going to close this bug as 'Non-reproduceable' or 'Not a Bug' - I would ask that those steps be held in reserve incase anyone else does eventually have the error. Thanks, Greg
i dont have much to go on here, the bug will stay around ofcourse It might be that the output at the end may not be the real error. Any idea what exact glibc ebuild you were using at the time ?
Well, Ive added the bugfixing 0.3.12 version of scrollkeeper.. Does this also inhibit such a bug? Also, the iconv errors you have there. have you ever emerged libiconv?? what versions of glibc?
needinfo
test, i swear i set needinfo
and again needinfo
Created attachment 16480 [details] Transcript. Transcript
Tried to add some comments previously, but BugZilla fell over would you believe! Just done a brand enw stage 1 install today, just trying to emerge Gnome. Experiencing the same bug. A colleague is also experiencing it, but has got around it by switching to KDE! The propsed manual workaround might not have worked for me. The next thing to be built when trying to emerge Gnome is gnome-terminal - the ebuild for which has just fallen over too.
Just re-emerged scrollkeeper to check the outputs, I notice this: >>> Updating Scrollkeeper database... /usr/sbin/ebuild.sh: line 1225: 3716 Segmentation fault scrollkeeper-update -v >&[T]/foo
well yeah we know by now it segfaults for some people on some systems with probably some CFLAGS, now its time to pinpoint exactly what causes it. Thats pretty much up to you, since we can't reproduce it. Getting a proper debug backtrace could be helpful.
I'd have to disagree. Gnome worked perfectly 3 days ago with the same hardware and same CFLAGS. This is an installation / ebuild issue. Every person I know who uses Gentoo is reporting Gnome as broken.
that sais nothing, nothing major happened to the default gnome install last couple of days and there are few bugs on this, which are all vague and seem to be related to a live cd at best. I havent seen one proper backtrace so far or anything we can do something with. Don't jump to conclusions. The only thing i see is that you comment on 3 different bugs with the same sort of comments and especially this one isn't related at all.
