Hardy package for tovid doesn't place makemenu, makexml etc. into user's path

[Christopher Tozzi]

Binary package hint: tovid

As described at http://ubuntuforums.org/showthread.php?t=830499, the Debian package for tovid available in the repositories on Hardy installs makemenu, makexml, makedvd and makevcd (and possibly other scripts) into /usr/share/tovid, but these utilities are not placed into the user's path. The only way to call them is to give the full path; i.e., simply typing "makemenu" returns a "command not found" error, but "/usr/share/tovid/makemenu" works.

This was not the case on Gutsy, so I think it's a bug. To make things worse, tovidgui (installed from the same repository) fails because it complains about not being able to find makemenu, etc., because it expects them to be in the user's path and they're not.

Symlinking the programs in /usr/share/tovid to /usr/bin works around the problem, but that solution is not obvious to non-technical users. Unless there's an obscure logic behind not placing makemenu, etc. in the user's path, why don't we fix this?

I'm using amd64; I'm not sure if this problems exists with the i386 package as well.

[Andy (acreech2330)]

Using 64 bit system unable to Burn DVD as well. The first error that stops the system from finishing is:
Running command: makemenu
The button ">" doesn't exist in "Helvetica"
The font "Helvetica" will be used instead.
It looks like something went wrong, because there is no output file.

makemenu -debug -overwrite -ntsc -dvd -align south -menu-title "80th_Birthday" -menu-title-fontsize 32 -background "/home/acreech/Pictures/Irene Carnahan/Final_Copy/1911_0526_001.JPG" -audio "/media/disk/Music/Yello/Stella/03 - Oh Yeah.ogg" -length 184 -font "Helvetica" -fontsize 24 -textcolor "rgb(255,255,255)" -fontdeco '-stroke rgb(0,0,0) -strokewidth 1' -button ">" -highlightcolor "rgb(255,255,0)" -selectcolor "rgb(255,0,0)" -button-outline "rgb(0,255,0)" "Grandma Irene 80th ver1 1.mpeg" -out "/tmp/80th_Birthday"

vi /tmp/makemenu.log

[Brent Creech (brentcreech)]

My brother and I have had the same problems. With the information you provided in your post I was able to complete the last bit I needed to get it working.

Packages to add with Synaptic
tcl8.4
tcl8.4-dev
tcl8.4-doc
mencoder
spumux <- Not found in Synaptic Package Manager
dvdauthor
gdvdauthor

Commands to run from the terminal
cd /usr/share/tovid
brcre@chimera:/usr/share/tovid$ sudo ln makemenu makexml /usr/bin
brcre@chimera:/usr/share/tovid$ which makemenu
/usr/bin/makemenu
brcre@chimera:/usr/share/tovid$ which makexml
/usr/bin/makexml

We've been using images2mpg to create videos from photos, so I'm not sure if that decreased the amount of packages I had to install at the point I was trying to get tovid to work, but it has now ran and produced the first DVD which appears to run on the Panasonic TV/DVD combo I have here in the room to test it on.

This worked on my 32-bit system, but I've been unable to get it to work on my brother's 64-bit system.

[Maia Everett (linneris)]

This is not a bug - these utilities were diverted for a reason. They are low-level utilities that most users aren't interested in, and they have generic names that pollute the namespace.

There is no tovid package in Gutsy - it was added to the repository in Hardy.

[Maia Everett (linneris)]

As for tovidgui, it shouldn't fail - it was patched to find the utilities where they are. If it does fail (and if you're sure that both tovidgui and the utilities are from the Hardy package), then it _is_ a bug - but I can't reproduce it.

[Andy (acreech2330)]

I hate to admit this, but I just re ran the program the same as I did
before and it seems to have worked. As far as I am aware I have not done
anything to the package manager that concerns this program, however it
does work now.

Thanks

Andy

-----Original Message-----
From: Matvey Kozhev <email address hidden>
Reply-To: Bug 252026 <email address hidden>
To: <email address hidden>
Subject: [Bug 252026] Re: Hardy package for tovid doesn't makemenu,
makexml etc. into user's path
Date: Mon, 11 Aug 2008 14:23:39 -0000

As for tovidgui, it shouldn't fail - it was patched to find the
utilities where they are. If it does fail (and if you're sure that both
tovidgui and the utilities are from the Hardy package), then it _is_ a
bug - but I can't reproduce it.

[Christopher Tozzi (cjt34)]

I tested tovidgui (installed from repositories) on a new Hardy install and it does seem to work properly. I'm not sure what was wrong before, but it's possible that I was using the package from the tovid site, which may not be fixed to address the removal of makemenu from the user's path. If that's the case, I apologize; I really thought I was using the package from the repositories, but maybe in the initial confusion of trying to figure out what was going on, I installed the tovid project's .deb instead and didn't realize it. In any case, it seems that tovidgui works as long as it's installed from the Ubuntu repositories.

Also, all of the tovid tutorials that I know of assume that makemenu, etc. are in the user's path. In order to make things easier, how difficult would it be to tell users where to find makemenu when they try to call it unsuccessfully? I'm thinking of something along the lines of the messages that come up when a non-installed program is called, e.g.:

The program 'makemenu' is installed but is not in your path. You can run it by typing:
/usr/share/tovid/makemenu

I don't know how hard it would be to implement something like that, but I think it would make things easier on users who don't know how to locate makemenu manually.

[j1p (j1peirce)]

If you are going to leave out makexml and makemenu from the path, at least patch tovid to tell users to run /usr/share/tovid/makexml when it tells them to use makexml.

[N7DR (doc-evans)]

You may not want to call this a bug, but to a user the behaviour is indistinguishable from a bug. When something is installed, the user expects to be able to execute the program without having to figure out that it's been somewhere elsewhere than in his path. At the very least, there should be some sort of warning about this unexpected behavioue when the package is installed. However, I would urge you to reconsider the "this is not a bug" stance.

In detail, the reasons I think that you should reconsider this stance:

"They are low-level utilities"

What does "low-level" mean? They are scripts, so by definition they can hardly be "low-level". System calls are low-level.

"that most users aren't interested in"

But the user has explicitly installed this package. Therefore, by definition, *this* user *is* interested in them.

"and they have generic names that pollute the namespace"

So are there other programs that are in other packages and which ARE installed into the path that duplicate these names? If there is indeed a name clash, then I agree that there is a problem and someone should consider changing the names in one of the packages. If there is no name clash, then what is the issue?

[N7DR (doc-evans)]

Incidentally, I assume that it's obvious that we're now talking about intrepid, not hardy.

[Alessio Treglia (quadrispro)]

Can anyone reproduce/confirm this bug on Jaunty?

[Alex Mauer (hawke)]

Yes, this is still a problem in Jaunty.

[Leo Arias (elopio)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner.
There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test the current Ubuntu development version (10.10). If you can test it, and it is still an issue, we would appreciate if you could upload updated logs by running apport-collect 252026, and any other logs that are relevant for this particular issue.

[Alex Mauer (hawke)]

It's still a problem in Maverick. No logs are relevant. The programs are placed in /usr/share/tovid/ instead of somewhere that’s in the $PATH.

[Liam Parker (liam-eliam)]

Hello,

I've got the same issue in Lucid, although, reading around the issue it appears this has been done on purpose. I've fixed the problem with the symlink solution. Not sure why I was forced to hunt for a file and create a symlink and I definitely expected the package manager to have done this for me.

If symlink's are considered evil (not sure why, as they appear to be used by plenty of other packages) could /usr/share/tovid/ be added to the default path or something when the package is installed?

PS It doesn't appear relevant but I'm on AMD64

[Liam Parker (liam-eliam)]

EDIT: I've just found Bug #412373, so, it actually appears both solutions have already been suggested!

PS Bug #412373 is a duplicate.

[Launchpad Janitor (janitor)]

This bug was fixed in the package tovid - 0.33-0ubuntu1

---------------
tovid (0.33-0ubuntu1) oneiric; urgency=low

  * New upstream release. (LP: #622937)
    - Helper scripts are no longer supposed to be invoked directly, but
      rather via the tovid command. (LP: #252026)
  * Switch to 3.0 (quilt) format.
  * Remove README.Debian and README.source, not needed anymore.
  * debian/control:
    - Switch section to video.
    - Depend on debhelper 7 rather than cdbs.
    - Remove txt2tags dependency, unused now.
    - Bump Standards-Version to 0.9.2.
    - Remove todraw package, make todiscgui transitional to tovidgui,
      adjust descriptions.
    - Depend on growisofs, listed as a dependency on the tovid website.
  * debian/rules:
    - Upstream uses python_distutils now. Convert to a minimal dh 7 file.
  * Removed custom manpages and the rules to install them. There is now only
    one executable (tovid), and upstream provides a manpage for it.
  * Removed obsolete patches:
    - 01_paths.diff
    - 02_todisc_manpage.diff
    - 03_desktop_files.diff
    - 04_name_sections.diff
    - 05_makemenu_man_apostrophes.dif
  * Removed patches for issues fixed upstream:
    - 03_sox_sample_size_fix.diff
    - 06_svn-r2494_fix_nav_log_parsing.patch
    - 07_todisc_progress_meter_fix.patch
    - 08_wrong_videos_order.patch
  * This means all previous patches were removed.
  * Added lookup_scripts_in_usr_share.patch:
    - Look up helper scripts in /usr/share/tovid, not /usr/lib/tovid
      (architecture-independent files go to /usr/share per Debian policy).
  * Added desktop_file_categories.patch:
    - End the categories list in the desktop file with a semicolon,
      per the XDG standard (checked by desktop-file-validate).
  * Added tovid_manpage.patch:
    - Edits to tovid.1 to make Lintian happy.
 -- Maia Kozheva <email address hidden> Sat, 30 Apr 2011 19:02:33 +0700