Bug 19105 - mupdf executable is not supplied in the package. Then mupdf can't be used.
Summary: mupdf executable is not supplied in the package. Then mupdf can't be used.
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 5
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: Rémi Verschelde
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 19126
Blocks:
  Show dependency treegraph
 
Reported: 2016-07-30 09:26 CEST by Louis Pénavaire
Modified: 2016-09-09 16:37 CEST (History)
1 user (show)

See Also:
Source RPM: mupdf-1.5-4.2.mga5
CVE:
Status comment:


Attachments

Description Louis Pénavaire 2016-07-30 09:26:00 CEST
The packages supplied with mageia 5 do not contain mupdf executable file. I also have checked that there is the same problem with 	mupdf-1.8-4.mga6.x86_64.rpm and mupdf-1.8-4.mga6.i586.rpm
Comment 1 Rémi Verschelde 2016-07-30 09:33:08 CEST
The executable seems to be named "mupdf-x11":

$ urpmq -l mupdf
/usr/bin/mujstest
/usr/bin/mupdf-x11
/usr/bin/mutool
/usr/share/applications/mupdf.desktop
/usr/share/doc/mupdf
/usr/share/doc/mupdf/CHANGES
/usr/share/doc/mupdf/CONTRIBUTORS
/usr/share/doc/mupdf/COPYING
/usr/share/doc/mupdf/README
/usr/share/doc/mupdf/naming.txt
/usr/share/doc/mupdf/overview.txt
/usr/share/doc/mupdf/progressive.txt
/usr/share/doc/mupdf/refcount.txt
/usr/share/doc/mupdf/thirdparty.txt
/usr/share/man/man1/mupdf.1.xz
/usr/share/man/man1/mutool.1.xz

But indeed the manpage hints at a "mupdf" binary, so a symlink is probably missing.

Assignee: bugsquad => rverschelde

Comment 2 Rémi Verschelde 2016-07-30 10:26:29 CEST
Fixed in Cauldrin with various packaging improvements. For Mageia 5 I'll just add the symlink to make the update easy to test.
Comment 3 Rémi Verschelde 2016-07-30 10:32:12 CEST
Pushed an update candidate to core/updates_testing, please test :)

Advisory:
=========

Updated mupdf package provides /usr/bin/mupdf symlink

  mupdf already contained the X11 viewer /usr/bin/mupdf-x11 but no mupdf binary
  to match the man page instructions. A symlink to mupdf-x11 now provides this.


RPMs in core/updates_testing:
-----------------------------

mupdf-1.5-4.3.mga5
lib(64)mupdf-devel-1.5-4.3.mga5  <-- no need to test it, unchanged

SRPM in core/updates_testing:
-----------------------------

 - mupdf-1.5-4.3.mga5

Assignee: rverschelde => qa-bugs
QA Contact: (none) => rverschelde

Comment 4 Rémi Verschelde 2016-07-30 10:32:56 CEST
Testing procedure:
==================

Install mupdf, use "mupdf", it should work :)

$ ls -l /usr/bin/mupdf
lrwxrwxrwx 1 root root 9 juil. 30 10:09 /usr/bin/mupdf -> mupdf-x11*

Whiteboard: (none) => has_procedure

Comment 5 Alexander Sirris 2016-08-02 19:48:19 CEST
Newbie day 3. I know that it was assigned to Rémi but Iâm still pushing to learn and work at this. I have selected the following repository sources.
	- Core Updates Testing
	- Nonfree Updates Testing
	- Tainted Updates Testing
	- Core 32bit Updates Testing (x86_64 Only)
	- Nonfree 32bit Updates Testing
	- Tainted 32bit Updates Testing 

I then go to install the relevant updates from the list of software package updates. But i cannot find mupdf (mupdf x-11) in that software update list. Do I need to manually install the RPM? So the way I figured
this to work is, all the âUpdates Testingâ repositoryâs hold all the updated packages waiting for validation. Thatâs where I come in, I have Mageia loaded on Parallels and have the selected repository sources
marked above. Then Mageia notifies me that there are new updates and I use MageiaUpdate to select the âupdated packageâ that I am working on.

CC: (none) => alexandersirris

Rémi Verschelde 2016-08-03 21:32:23 CEST

Source RPM: mupdf-1.5-4.2.mga5 and mupdf-1.5-4.mga5 => mupdf-1.5-4.2.mga5

Comment 6 Rémi Verschelde 2016-08-03 21:51:10 CEST
As discussed on IRC, Alexander's issue is not with his configuration, but apparently half our mirrors are broken and stuck at the state of July 30th 09:05 UTC: http://mirrors.mageia.org/status

I've notified the sysadmins about it.
Comment 7 Rémi Verschelde 2016-08-04 00:19:27 CEST
Regarding comment 6, it was actually a configuration issue.

Grabbing this one back as it is superseded by the security bug 19126, which I will assign to QA.

Depends on: (none) => 19126
Assignee: qa-bugs => rverschelde
QA Contact: rverschelde => (none)
Whiteboard: has_procedure => (none)

Comment 8 Rémi Verschelde 2016-09-09 16:37:11 CEST
Was fixed when bug 19126 was validated.

Status: NEW => RESOLVED
Resolution: (none) => FIXED


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