Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 452349 - rpm -i hangs on unopkg.bin
Summary: rpm -i hangs on unopkg.bin
Alias: None
Product: Fedora
Classification: Fedora
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Alex Lancaster
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-06-21 07:56 UTC by J. Randall Owens
Modified: 2009-01-22 10:40 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-01-22 10:40:01 UTC

Attachments (Terms of Use)

Description J. Randall Owens 2008-06-21 07:56:29 UTC
Description of problem:
When installing the RPM with smart --gui, it looks like
it runs unopkg.bin for an infinite number of cycles (32m 15s of CPU time so far
here).  This is a first install, not an upgrade.  I don't have any idea how it
would act on upgrade.

Version-Release number of selected component (if applicable):

How reproducible:
Attempt to install RPM

Steps to Reproduce:
1. gsmart --gui
2. select for installation
3. click apply button

Alternative steps that would probably work:
1: rpm -ihv
2: top
Actual results:
unopkg.bin sits at the top of the top list, chewing up cycles innumerable.

Expected results:
For a 58 KB package, I'd expect it to install in maybe 5 seconds, tops.

Additional info:
Ah, I see rpm -qp --scripts shows a postinstall scriptlet, echoing "yes" to
unopkg add.  I don't know just what that's supposed to be doing, but I don't
think it's doing it right.

Comment 1 J. Randall Owens 2008-06-21 07:58:27 UTC
I eventually killed -1 the process, and smart recovered fairly well and moved on
to the rest of the installations.

Comment 2 J. Randall Owens 2008-06-21 08:14:10 UTC
I found the unopkg.bin binary in /usr/lib/; there's a
small /usr/bin/unopkg sh script, which runs a bigger
/usr/lib/ sh script, which in turn runs the actual
binary; the redirection seems to be mostly all for the purpose of setting up
environment variables.  (They're all part of the OOo-core package.)  So I ran
ldd on the .bin one, and it's coming up clean, nothing missing.  Beyond that, I
don't know yet.

Comment 3 J. Randall Owens 2008-06-21 08:25:49 UTC
Oh my, is it that simple?!?  The GPL that it's sending "yes" to has a footnote
and a "<<ja>> eller <<nei>>" at the end, I think it's in Norwegian, but I
wouldn't know it from Swedish for sure.  So when I ran the unopkg with the
arguments but without the piped input, and typed "yes" anyway, it asked me for
"'ja' eller 'nei'" again.  All that needs to be done to fix it is to change the
"echo yes" in line 75 of the SRPM to "echo ja".  Alternatively, put the license
all in English, which it mostly is anyway.

However, it does bother me that unopkg.bin would use all the spare CPU while it
waits for an answer.  But that's a bug for

Comment 4 J. Randall Owens 2008-06-21 09:20:37 UTC
Ah, from the initial creation of this package, bug #441027#3 (I don't know if
that works to refer to comments in other bugs, but I'll try):

"Comment #3 From Caolan McNamara (  	 on 2008-04-05 09:22
EST  	[reply]   	 

"FWIW, you could probably use 
echo yes | unopkg add --shared --link %{ooolatexext} || :
instead of patching out the "do you agree to GPL" foo to reduce the patch.

"Maybe it'd be worth just unpacking it and applying the patch in %prep and doing
a standard copy of that tree in %install rather than unpacking %{SOURCE0} in
%install. Just to try and look as "normal" as possible."

Perhaps you should go back to using that original ooolatex-fix-path.patch, where
you removed the <registration> and <update-information> elements from
description.xml.  I know I have a somewhat odd setup, I'm a bit of an amateur
linguist, so I have the de, en, es, fr, nb_NO, nn_NO, & ru langpacks installed.
 But I've never chosen anything but English as my default language, and yet it
hit me with the Norwegian Bokmal text anyway.  (I've narrowed it down with grep,
the leading phrase of the quote occurs in
/usr/lib/ (Similarly,
Thunderbird and Firefox have been spellchecking everything I write as German!)

But my own eccentricities aside, it seems this wouldn't work at all for those
who don't bother to install the English, and would be unlikely to work for those
who install English and other languages.  Not good for the i18n and l10n!  So
there has to be some way around it, much like you first proposed.

Comment 5 J. Randall Owens 2008-06-25 21:06:35 UTC
Should this have been fixed by the update to 2.4.1-17.3?  The changelog for that
release notes "remove pointless 'register' dialog request".  I'm pretty sure I
already had 2.4.1-17.3 at the time of the ooolatex installation, though.  (Got
2.4.1-17.4 now, so I can't just check the installation time.)

Comment 6 Alex Lancaster 2008-07-04 08:45:25 UTC
Sorry, I haven't had a chance to look at this yet.  I'll check what 2.4.1 does
in F-9 later (currently I'm on my F-8 box which is still on 2.4.3 for OOo).  

I'll look at removing the registration requirement from the description.xml by
re-enabling that part of the patch because this will still effect people
installing it on older releases of OOo (such as on F-8) if they don't use LANG=en*.

Comment 7 Joachim Frieben 2008-07-30 12:19:48 UTC
The some issue appears when installing/updating subpackage from the "rawhide" tree. In the "top"
list, there is an entry like:

 8390 root      20   0 81904  14m  11m R 50.3  3.0  13:12.36 unopkg.bin

and this will continue for hours. Well, actually until the user decides
to abort the (yum) transaction. The latest 3.0.0- package
is also affected.

Comment 8 Alex Lancaster 2008-08-01 09:43:29 UTC
I've had problems getting the OOoLatex extension to work at all with OOo 2.4 in
F-9.  There appears to be some compatibility issues.  I'll try and fix the
registration bit in the meantime.

Comment 9 Alex Lancaster 2008-12-09 08:15:08 UTC
Can you verify if this bug is still in F-10 or F-9 for non-en locales? (F-8 is about to become obsolete).

Comment 10 Alex Lancaster 2009-01-22 10:40:01 UTC
Closing bug as this appears to be fixed in F-9 and later, at least no confirming reports (however, feel free to re-open if you can reproduce it) and F-8 is now EOL.

Note You need to log in before you can comment on or make changes to this bug.