Description of problem: It is not possible to install KDE Plasma Desktop + ALL ADDONS. Installation stops with an error at package inkscape, but the screen becomes all-black. packaging.log does not show any error, but it is the last package. no anaconda-tb* file. Version-Release number of selected component (if applicable): F18b TC7 How reproducible: always (should be easy) Steps to Reproduce: 1. Enter STORAGE: INSTALLATION DESTINATION, select the disk 2. Do AUTOMATIC INSTALLATION, Type: PLAIN. (DELETE if necessary) 3. Change package group to KDE Plasma Workspaces and check all Addons 4. Begin Install, error when installing packages Actual results: installation ends at inkscape package Expected results: no error Additional info:
Created attachment 639531 [details] screenshot
Please attach /tmp/syslog and /tmp/anaconda.log to this bug report.
Created attachment 639686 [details] anacona.log
Created attachment 639687 [details] syslog
The packaging.log file would be useful too, trying to duplicate here.
Nevermind. I was able to duplicate, there appears to be a problem with inkscape: Installing inkscape-0.48.3.1-1.fc18.x86_64 (1093/1300) error: unpacking of archive failed on file /usr/share/man/el/man1/inkscape.el.1.gz;5099b1f0: cpio: open failed - No such file or directory Looking into it.
<nirik> -%{_mandir}/fr/man1/inkscape.1* +%{_mandir}/ thats just wrong. ;( <kalev> it should probably use %find_lang --with-man, which generates the list of localized man pages, and also takes care of properly annotating the files with %lang() * nirik nods. <nirik> could file a bug, but instead I'm having a beer. ;)
I changed it to %find_lang %{name} --with-man, and it seems to make no difference, the el man page is present either way. Maybe something else is wrong with inkscape, or I'm misunderstanding the problem?
(In reply to comment #8) > I changed it to %find_lang %{name} --with-man, and it seems to make no > difference, the el man page is present either way. Maybe something else is > wrong with inkscape, or I'm misunderstanding the problem? Honestly, I don't know. I didn't look into the package, just realized it wasn't something wrong anaconda was doing.
Reartes, does increasing the RAM and/or disk available affect this at all?
(In reply to comment #10) > Reartes, does increasing the RAM and/or disk available affect this at all? I attempted installs where only inkscape was selected, and when a ton of other stuff was selected. No difference.
What about non-KDE spins?
Yeah, I did it from just a regular installer environment, not a live spin, and with kickstart just had inkscape selected, nothing else.
Installing inkscape on a running system works fine, I wonder what's tripping this.
Maybe try installing in a fresh chroot where the chroot population package set is @core ?
Just tried that on a fully updated f18 VM, and it went smoothly.
I've come across this bug, too, with 18-Beta-RC1 and the current development/18 repository. I am not using any spins, but I have a kickstart script with a custom package list that includes inkscape. I am encountering basically the same error message as in Comment 6: Installing inkscape-0.48.3.1-2.fc18.x86_64 (1376/3613) error: unpacking of archive failed on file /usr/share/man/el/man1/inkscape.el.1.gz;50ad2ee6: cpio: open failed - No such file or directory I tried copying over the RPM in a bash shell from the installer and running RPM manually: rpm -ivh --root /mnt/sysimage inkscape-0.48.3.1-2.fc18.x86_64.rpm This succeeded without any errors, so this makes me wonder whether it might possibly be a bug in Anaconda rather than Inkscape.
By the way, anyone searching for this bug might find it useful if a comment includes the error message given by the Anaconda GUI: "There was an error installing the inkscape package. This is a fatal error and installation will be aborted."
I got the same error as shown in comment 18. Here is some more information which I dug out of the console which may (or may not) be helpful: Python callback <boundmethod RPMCallback.callback of <pyanaconda.packaging.yumpayload.RPMCallback object at 0xab76c32cc77>> failed, aborting Pane is dead
Discussed at 2012-12-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-12-03/f18final-blocker-review-1.2.2012-12-03-17.25.log.txt . While this doesn't quite hit the existing criterion as written: "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install" we agreed in principle that it should be amended to cover any kind of critical packaging error which causes a package to fail to install, and on that basis, this bug is accepted as a blocker. We will draft up and finalize the criterion change on the test@ mailing list.
Can anyone recreate this in a non-Anaconda situation? That would be helpful in finding the issue. Post-install package installation and chroot installation are OK.
(In reply to comment #21) > Can anyone recreate this in a non-Anaconda situation? That would be helpful > in finding the issue. Post-install package installation and chroot > installation are OK. In Comment #17, I gave some evidence that this may be an Anaconda-specific problem. (In reply to comment #20) > we agreed in principle that it should be amended to cover any kind of > critical packaging error which causes a package to fail to install, and on > that basis, this bug is accepted as a blocker. We will draft up and finalize > the criterion change on the test@ mailing list. And by the way, it's not just that the package fails to install, but also that the installer gives up and quits when it hits this error.
andrew: that's actually more or less by design (it shouldn't outright *crash*, but it is in fact designed to just give up at that point), AIUI. the anaconda devs could give you the detailed explanation of why, but I believe it's basically that an error during package installation just should not happen, and if it does, that means something is very wrong: offering an option to just power on regardless could be making a bad situation worse. It's considered the best option to just give up and leave recovery to the user at that point.
(In reply to comment #23) > andrew: that's actually more or less by design (it shouldn't outright > *crash*, but it is in fact designed to just give up at that point), AIUI. > the anaconda devs could give you the detailed explanation of why, but I > believe it's basically that an error during package installation just should > not happen, and if it does, that means something is very wrong: offering an > option to just power on regardless could be making a bad situation worse. > It's considered the best option to just give up and leave recovery to the > user at that point. I guess that makes sense. In any case, Anaconda crashes, but Yum doesn't.
Isn't this one related to the man-pages-de bug - https://bugzilla.redhat.com/show_bug.cgi?id=878967 - so the wrong directory ownership - https://bugzilla.redhat.com/show_bug.cgi?id=569392 and %{_mandir}/?
Good eye. If that's correct, the forthcoming update should fix this.
inkscape-0.48.3.1-4.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/inkscape-0.48.3.1-4.fc18
Package inkscape-0.48.3.1-4.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing inkscape-0.48.3.1-4.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-19872/inkscape-0.48.3.1-4.fc18 then log in and leave karma (feedback).
inkscape-0.48.3.1-4.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Can somebody please verify this is fixed with the new version? Thank you!
Created attachment 664385 [details] screenshot of the error Selected KDE and all addons. It failed when installed inkscape. No unknown error was issued, the screen remained all-black. No anaconfa-tb-XXX file was generated. Tested with F18 TC2 (18.37.2)
Created attachment 664474 [details] packaging.log I can confirm the problem with F18 TC2 DVD i386. It contains inkscape-0.48.3.1-4.fc18. In my case, I received a screen same as in attachment 639531 [details]. I guess it's a probably race condition with gtk thread whether you received a black screen or not. Quite interestingly, the error is not included in the packaging.log. Neither it is on any tty. I wonder why Reartes see it and I don't.
@Kamil Páral There is a (randomly named) tmpXXXX file in /ymp. (some sort of buffer?). The screen-shot i uploaded is from that file.
@Kamil Páral CORRECTED COMMENT There is a (randomly named) tmpXXXX file in /tmp. (some sort of buffer?). The screen-shot i uploaded is from that file.
In case the last commit was supposed to fix something related to man page dir ownership, it was a half-hearted fix, http://lists.fedoraproject.org/pipermail/scm-commits/2012-December/911922.html because the packages still owns several man page dirs: $ rpmlsv -p inkscape-0.48.3.1-4.fc18.x86_64.rpm|grep /man drwxr-xr-x root root 0 /usr/share/man/el/man1 -rw-r--r-- root root 15160 /usr/share/man/el/man1/inkscape.el.1.gz drwxr-xr-x root root 0 /usr/share/man/fr/man1 -rw-r--r-- root root 12860 /usr/share/man/fr/man1/inkscape.fr.1.gz drwxr-xr-x root root 0 /usr/share/man/ja/man1 -rw-r--r-- root root 13076 /usr/share/man/ja/man1/inkscape.ja.1.gz -rw-r--r-- root root 11625 /usr/share/man/man1/inkscape.1.gz -rw-r--r-- root root 15160 /usr/share/man/man1/inkscape.el.1.gz -rw-r--r-- root root 12860 /usr/share/man/man1/inkscape.fr.1.gz -rw-r--r-- root root 13076 /usr/share/man/man1/inkscape.ja.1.gz -rw-r--r-- root root 12541 /usr/share/man/man1/inkscape.sk.1.gz -rw-r--r-- root root 12240 /usr/share/man/man1/inkscape.zh_TW.1.gz drwxr-xr-x root root 0 /usr/share/man/sk/man1 -rw-r--r-- root root 13076 /usr/share/man/sk/man1/inkscape.ja.1.gz drwxr-xr-x root root 0 /usr/share/man/zh_TW/man1 -rw-r--r-- root root 12240 /usr/share/man/zh_TW/man1/inkscape.zh_TW.1.gz
ah, that's likely the problem, yes. it should not own any.
# repoquery --whatprovides /usr/share/man/el wesnoth-data-0:1.10.5-1.fc18.noarch filesystem-0:3.1-2.fc18.x86_64 wesnoth-data-0:1.10.5-1.fc18.noarch # repoquery --whatprovides /usr/share/man/el/* filesystem-0:3.1-2.fc18.x86_64 inkscape-0:0.48.3.1-4.fc18.x86_64 inkscape-0:0.48.3.1-4.fc18.x86_64
Fixed in the next build.
inkscape-0.48.4-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/inkscape-0.48.4-1.fc17
inkscape-0.48.4-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/inkscape-0.48.4-1.fc18
inkscape-0.48.4-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/inkscape-0.48.4-1.fc16
Package inkscape-0.48.4-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing inkscape-0.48.4-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-20620/inkscape-0.48.4-1.fc17 then log in and leave karma (feedback).
> -%{_mandir}/*/* > +%{_mandir}/*/*gz > +%{_mandir}/*/*/*gz ;-) Considering that all the man pages are for the "inkscape" executable, you could have used inkscape*.1* or even man1/inkscape*.1* instead of *gz and from the packaging hints department store, it's possible to add files to a package with the %files -f option and e.g. use a matching "find -type f …" command to only add man pages it finds. No risk of adding any directories that way.
We're waiting for the updated package to hit mirrors before we can test this.
The problem is fixed with inkscape-0.48.4-1.fc18. We need to push it stable.
inkscape-0.48.4-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
inkscape-0.48.4-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
inkscape-0.48.4-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 891484 has been marked as a duplicate of this bug. ***