/var/tmp/rpm-tmp.wZfb8m: line 2: shortfile: command not found warning: %triggerin(texlive-kpathsea-5:svn41139-9.fc26.1.noarch) scriptlet failed, signal 15 Non-fatal <unknown> scriptlet failure in rpm package texlive-kpathsea Note that dnf actually hung during the upgrade. I was only able to continue by killing the shell process. This generated thousands of the "shortfile: command not found" messages.
This is responsible for a hung mock build for me. The issue is this line: shortfile = `basename $file` You can have spaces around = in a Makefile, but not in a shell script. Make that: shortfile=`basename $file` and all will be well.
*** Bug 1384777 has been marked as a duplicate of this bug. ***
That fix is in -10. It is not sufficient. I'm working on a proper fix in -11, but I want to test it locally first before everyone screams at me again. :D
I wanted to say that I also hit this bug, but in my case I just let it run overnight. When I came back, it had finished. So it will finish eventually (or at least it did in my case) ☺
The trigger is now fixed in -11, it may still take a few minutes to complete if you have a lot of texlive font maps installed, but it is no longer the massive infinite loop it was before.
That's great! Thanks for all of the work you put into this, spot.
I just finished updating Rawhide. It did indeed finish after a few minutes, without hanging, but after the last package cleanup message, I saw basename: missing operand Try 'basename --help' for more information. Is this coming from texlive-kpathsea?
Damnit, it is. There's a typo in the %transfiletriggerpostun. Good catch, here comes -12.
When building a package in koji that installs texlive I get these warnings: DEBUG util.py:421: updmap [WARNING]: resetting $HOME value (was /builddir) to root's actual home (/root). DEBUG util.py:421: updmap [WARNING]: resetting $HOME value (was /builddir) to root's actual home (/root). DEBUG util.py:421: updmap [WARNING]: resetting $HOME value (was /builddir) to root's actual home (/root). DEBUG util.py:421: updmap [WARNING]: resetting $HOME value (was /builddir) to root's actual home (/root). DEBUG util.py:421: updmap [WARNING]: resetting $HOME value (was /builddir) to root's actual home (/root). DEBUG util.py:421: updmap [WARNING]: resetting $HOME value (was /builddir) to root's actual home (/root). DEBUG util.py:421: updmap [WARNING]: resetting $HOME value (was /builddir) to root's actual home (/root). DEBUG util.py:421: updmap [WARNING]: resetting $HOME value (was /builddir) to root's actual home (/root). The line is repeated abot 500 times. This is with texlive-kpathsea.noarch 5:svn41139-11.fc26.1
-13 is building now, it will redirect stderr from the updmap calls in the triggers to /dev/null. Should silence that again.
(In reply to Tom "spot" Callaway from comment #8) > Damnit, it is. There's a typo in the %transfiletriggerpostun. Good catch, > here comes -12. Just updated to -12, same as before, including the exact same basename error (it may have appeared after a longer delay than before, though). I suspect that error is being emitted by the old version, though (due to "postun", I can't tell from the output of "rpm -q --scripts texlive-kpathsea").
When updating to -13, I still see the same basename error, so it must not have been fixed in -12.
In this scripts $list, which is feeding 'baseline' one-by-one, is produced by the following: list=`grep "\.map" | sort -n | uniq` I am not really sure what is feeding grep here but could be that this produces somewhere a line with only EOL on it? That would end up with "basename: missing operand. Adding immediately after 'while ...; do' a line like: [ -z "$line" ] && continue should kill this error (although maybe this is only masking the issue). Yes, I am seeing that too. :-)
Same error when updating to -14. However, if I then reinstall texlive-kpathsea by itself, I didn't see the error. Does this mean it was fixed in -13, or does the error come from some other texlive package?
(In reply to Andre Robatino from comment #14) > Same error when updating to -14. However, if I then reinstall > texlive-kpathsea by itself, I didn't see the error. Does this mean it was > fixed in -13, or does the error come from some other texlive package? It may also mean that the "$list", which provides arguments to 'baseline', is not the same during a full update transaction and when you are reinstalling texlive-kpathsea. I checked all packages in an update transaction when I have seen that error and the only occurences of 'baseline' were in "--filetriggers" scriplets from texlive-kpathsea and that seems to identify the culprit. I guess that the other way to shut up this error would be to use baseline "$line" instead of baseline $line without quotes.
Updating from -15 to -16, I didn't see the error (but I'm not absolutely sure since I updated in a VT and couldn't scroll all the way back). Is it fixed?
I sure hope so. I'm doing null checking and quoting the arg passed to basename.
(In reply to Tom "spot" Callaway from comment #17) > I sure hope so. I'm doing null checking and quoting the arg passed to > basename. Belt and suspenders, eh? Quoting should be good enough although checks are fine. Try this echo " extra whitespace simple" | while read line ; do basename "$line" done If you omit quotes from "$line" then basename will start complaining many times and now there are no troubles.
perl-BibTeX-Parser-0.69-1.fc25, perl-LaTeX-ToUnicode-0.04-1.fc25, texlive-2016-17.20160520.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-50a2bc7997
perl-BibTeX-Parser-0.69-1.fc25, perl-LaTeX-ToUnicode-0.04-1.fc25, texlive-2016-17.20160520.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
➜ ~ sudo dnf --refresh reinstall texlive-base RPM Fusion for Fedora 25 - Free - Test Updates 53 kB/s | 1.2 kB 00:00 negativo17 - Steam 106 kB/s | 7.7 kB 00:00 google-chrome 62 kB/s | 3.7 kB 00:00 Fedora 25 - x86_64 - VirtualBox 193 kB/s | 6.4 kB 00:00 MongoDB Repository 15 kB/s | 12 kB 00:00 Dependencies resolved. =============================================================================================================================== Package Arch Version Repository Size =============================================================================================================================== Reinstalling: texlive-base noarch 5:2016-17.20160520.fc25 fedora 1.4 M Transaction Summary =============================================================================================================================== Total size: 1.4 M Is this ok [y/N]: y Downloading Packages: [SKIPPED] texlive-base-2016-17.20160520.fc25.noarch.rpm: Already downloaded Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Reinstalling: texlive-base-5:2016-17.20160520.fc25.noarch 1/2 Erasing : texlive-base-5:2016-17.20160520.fc25.noarch 2/2 warning: %triggerin(texlive-kpathsea-5:svn41139-17.fc25.1.noarch) scriptlet failed, exit status 2 Traceback (most recent call last): File "/usr/lib/python3.5/site-packages/dnf/yum/rpmtrans.py", line 427, in callback self._scriptError(bytes, total, h) File "/usr/lib/python3.5/site-packages/dnf/yum/rpmtrans.py", line 557, in _scriptError pkg, _, _ = self._extract_cbkey(h) File "/usr/lib/python3.5/site-packages/dnf/yum/rpmtrans.py", line 229, in _extract_cbkey return self._extract_str_cbkey(cbkey) File "/usr/lib/python3.5/site-packages/dnf/yum/rpmtrans.py", line 237, in _extract_str_cbkey assert(isinstance(name, basestring)) AssertionError FATAL ERROR: python callback ??? failed, aborting! ➜ ~
Just FWIW, this probably was/is a bug in rpm file triggers, which in some cases feed the file lists into the scripts multiple times, and the bigger the package the worse it gets. Looking at the implemented workaround of using sort|uniq in texlive suggests that was the case here too, sorry for missing it back then. Fixed upstream by https://github.com/rpm-software-management/rpm/commit/e6effe3c91b66e822db571d3129e49164ddc45ba but don't go ripping out the workaround just yet, both rpm 4.13.x and 4.14.x need updates first.