Bug 873817

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.

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.

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