This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch for MojoSetup slowdown on filenames with points (pointfix.patch, text/plain, 2009-02-26 16:34:58 -0500, 1113 bytes)

Reported in version: unspecified Reported for operating system, platform: Linux, PC

Comments on the original bug report:

On 2009-02-26 16:33:28 -0500, Reto Schneider wrote:

MojoSetup doesn't recognize the suffix of filenames when there are any point inside the filename (eg. glest-data_3.2.1.tar). MojoSetup tries every single archive format until it finds the correct one. This takes a lot of time.

I'll attach a patch that enables MojoSetup to search a little bit harder to find the correct suffix.

On 2009-02-26 16:34:58 -0500, Reto Schneider wrote:

Created attachment 1983 Patch for MojoSetup slowdown on filenames with points

On 2009-05-09 02:24:20 -0400, Ryan C. Gordon wrote:

Should be fixed in hg changeset 671:ab9a0b4883fa.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified Reported for operating system, platform: All, All

Comments on the original bug report:

On 2007-05-22 04:07:47 -0400, Ryan C. Gordon wrote:

There are several uses for launching a web browser, but the installer can't. This needs support in the platform layer, and maybe some sort of UI for it, too.

--ryan.

On 2007-05-22 04:40:43 -0400, Ryan C. Gordon wrote:

(Changing platform and OS fields...)

--ryan.

On 2008-03-09 01:41:59 -0500, Ryan C. Gordon wrote:

There's no UI for it, but it's built into the platform layer and Lua bindings now...

--ryan.

On 2009-09-22 18:00:11 -0400, Ryan C. Gordon wrote:

Resolving bug.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified Reported for operating system, platform: Linux, PC

Comments on the original bug report:

On 2009-01-17 06:13:23 -0500, wrote:

In my test setup two files get installed:

file1: is a regular file file2: is a symbolic link to file1

If I run the uninstall script the symlink is not deleted and the uninstallation fails because the installer can not remove the installation directory which is not empty.

Problem is file1 is deleted before file2.

mojosetup_mainline.lua:146 - function do_delete The call to MojoSetup.platform.exists returns false for file2 and so this function does not delete file2.

The cause of this is in: platform_unix.c:564 - function MojoPlatform_exists access(dir, F_OK) return -1 because file1 was deleted and file2 is now a broken symlink.

On 2009-01-31 19:08:42 -0500, Reto Schneider wrote:

Is this but extremely hard to fix? Is there a ETA for a (hopefully coming) fix?

Thanks, Reto

On 2009-02-05 01:27:46 -0500, Ryan C. Gordon wrote:

Should be fixed in hg revision 616:f7597a3863cd ... please let me know if it isn't.

--ryan.

On 2009-02-06 12:57:15 -0500, wrote:

My test installer scenario uninstalls fine now. Thanks for the fix.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• config.lua (config.lua, text/plain, 2009-01-12 12:47:27 -0500, 692 bytes)

Reported in version: unspecified Reported for operating system, platform: Linux, PC

Comments on the original bug report:

On 2009-01-06 06:14:25 -0500, Reto Schneider wrote:

MojoSetup throws "BUG: no options" when Setup.Option and Setup.OptionGroup used in Setup.Package.

Line 1132 in mojosetup_mainline.lua seems to cause it. Replace ~= with == helps.

Thanks, Reto

On 2009-01-12 12:46:15 -0500, wrote:

I think Reto is right, see the attached config.lua. I get the same error as long as I don't comment out either the Setup.Option or the Setup.OptionGroup block.

From mojosetup_mainline.lua:1132

if install.options ~= nil and install.optiongroups ~= nil then
    MojoSetup.fatal(_("BUG: no options"))
end

This does not look right. For the attached test case this would mean install.options is not nil and install.optionsgroups is not nil too. As Reto stated it should look like:

if install.options == nil and install.optiongroups == nil then
    MojoSetup.fatal(_("BUG: no options"))
end

So the installer bails out only if both install.options and install.optiongroups are nil but not if both are unlike nil.

On 2009-01-12 12:47:27 -0500, wrote:

Created attachment 1954 config.lua

On 2009-01-12 21:59:28 -0500, Ryan C. Gordon wrote:

Ah, yeah, good catch. Basic logic mistake on my part.

Fixed in hg changeset 614:d3280f946e01, thanks!

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified Reported for operating system, platform: Linux, PC

Comments on the original bug report:

On 2014-09-12 16:18:19 -0400, Xodetaetl wrote:

I'm on Xubuntu 14.04 and all I get is a CLI with Braid and Aquaria's HumbleBundle installers.

On 2014-09-16 00:19:13 -0400, Ryan C. Gordon wrote:

Likely your system doesn't have 32-bit GTK+ libraries, or it has an incompatible version of those libraries, so the installer gives up and moves to the stdio interface.

--ryan.

On 2014-11-24 10:25:43 -0500, Xodetaetl wrote:

Well, I can't see 32-bit packages of GTK in ubuntu 14.04's repos.

Is there a list of deps for MojoSetup somewhere anyway?

I'm writing install scripts for the gaming platform Lutris but I can only do it for mojosetup installers if I can ensure everyone will get the GUI. I can bundle the dependencies if I know them.

On 2015-03-14 03:56:39 -0400, Xodetaetl wrote:

Bump Thanks :)

On 2016-01-25 12:19:54 -0500, Xodetaetl wrote:

Found my answers.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• ~~My compiler gives me a warning about that (gui_stdio.c_patch, text/plain, 2009-06-05 12:44:10 -0400, 732 bytes)~~
• ~~exports chmod() into lua (lua_glue.c_chmod_patch, text/plain, 2009-06-05 12:44:46 -0400, 1262 bytes)~~
• ~~Makes it faster (mojosetup_mainline.lua_patch, text/plain, 2009-06-05 12:45:03 -0400, 10202 bytes)~~

Reported in version: unspecified Reported for operating system, platform: Mac System 7, PC

Comments on the original bug report:

On 2009-01-05 09:01:10 -0500, Reto Schneider wrote:

When installing 10'000+ files with MojoSetup it eats up my whole 2 GB Ram while writing the metadata. Eventually it will finish, but it hangs my PC for about 5 minutes. write_manifest = false solves the problem, but forces me to use support_uninstall = false.

I created a minimalistic package to show the problem, hope it helps: ftp://reto-schneider.ch/10kfiles.tar.bz2

Thanks, Reto

On 2009-01-05 23:24:00 -0500, Ryan C. Gordon wrote:

Yeah, we currently build the manifest as one long string, and write it as a text file in one shot. This was basic laziness on my part. I'll fix it.

--ryan.

On 2009-06-05 12:44:10 -0400, Reto Schneider wrote:

Created attachment 2070 My compiler gives me a warning about that

On 2009-06-05 12:44:46 -0400, Reto Schneider wrote:

Created attachment 2071 exports chmod() into lua

On 2009-06-05 12:45:03 -0400, Reto Schneider wrote:

Created attachment 2072 Makes it faster

On 2009-06-05 12:47:06 -0400, Reto Schneider wrote:

I tried to make things faster (expect failures... I'm not strong at programming). Now it works within seconds.

On 2009-06-15 15:07:59 -0400, Ryan C. Gordon wrote:

Comment on attachment 2072 Makes it faster

You have the right idea here with the speedup patch. Lua's '..' operator isn't meant for heavy lifting.

In fact, Lua's primary developer recommends the string table approach you took for a speed boost:

http://www.lua.org/gems/sample.pdf

("About Strings" section, page 22.)

The only problem is that this still leaves a big pile of immutable string fragments on the heap, just waiting for garbage collection, so I might move this into C code. I have to think about it a little more.

--ryan.

On 2009-06-15 15:16:53 -0400, Ryan C. Gordon wrote:

Comment on attachment 2070 My compiler gives me a warning about that

Compiler warnings over printf() patch in now in revision control, hg changeset 680:9688bf9c72b3. Thanks!

--ryan.

On 2009-07-07 03:26:13 -0400, Ryan C. Gordon wrote:

hg changeset 681:4d1097947759 should fix the performance. Please note I haven't tested this change yet, and it might be totally broken, so don't rely on it tonight or anything.

--ryan.

On 2009-07-07 18:29:20 -0400, Ryan C. Gordon wrote:

Comment on attachment 2072 Makes it faster

Okay, I've optimized and debugged by version of the performance patch, as of hg changeset 688:daaf73ab4961.

This should be safe to use now.

--ryan.

On 2009-07-07 18:32:39 -0400, Ryan C. Gordon wrote:

Comment on attachment 2071 exports chmod() into lua

Obsoleting the chmod patch, as it isn't necessary anymore.

--ryan.

On 2009-07-07 18:33:19 -0400, Ryan C. Gordon wrote:

Resolving bug as fixed!

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified Reported for operating system, platform: Linux, PC

Comments on the original bug report:

On 2008-01-12 00:03:13 -0500, Ryan C. Gordon wrote:

We can't really use printf(), because that's flakey in general (what if a translator forgets a %s or whatnot?), but also because strings may need reordering in a translation...so maybe %1, %2 is beter than %s, %s?

--ryan.

On 2008-01-12 05:48:46 -0500, Ryan C. Gordon wrote:

Fixed in svn revision # 400.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified Reported for operating system, platform: Linux, PC

Comments on the original bug report:

On 2011-01-06 16:49:30 -0500, Hector Martin wrote:

I reported this through the livechat, but I haven't heard back so here's a more formal report.

Mojosetup crashes on filesystems where any component of the path has an inode number that does not fit in 32 bits (this can happen e.g. on XFS mounted with inode64). It looks like this:

PANIC BUG: crash at startup

The crash occurs in MojoArchive_initBaseArchive, where MojoPlatform_appBinaryPath is called and the return value is not checked for NULL. appBinaryPath fails when MojoPlatform_realpath walks all the path components and lstat() fails on any one of them due to the 32-bit limitation.

The solution is to simply compile mojosetup in 64-bit file IO mode (-D_FILE_OFFSET_BITS=64). This also makes it use a 64-bit inode field in 'struct stat' and everything works. I haven't tested this with mojosetup but I wrote a simple testcase, compiled in 32-bit mode (I run a 64-bit distro) with and without -D_FILE_OFFSET_BITS=64 and was able to confirm that lstat() on the problem dir works when compiled that way.

On 2011-01-12 19:16:01 -0500, Ryan C. Gordon wrote:

I added the preprocessor define in hg changeset 808:dac276dc6e79, and check for that NULL in changeset 809:1835f18093d3.

Thanks!

--ryan.

On 2011-01-12 19:21:50 -0500, Hector Martin wrote:

Thanks! Please let me know when an updated version of the Braid installer with the new MojoSetup is available :)

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• require_cmake2.4.4.patch (require_cmake2.4.4.patch, text/plain, 2008-09-01 17:05:26 -0400, 406 bytes)

Reported in version: unspecified Reported for operating system, platform: Linux, PC

Comments on the original bug report:

On 2008-09-01 17:05:07 -0400, wrote:

This module was introduced with cmake version 2.4.4. The patch changes the minimum required version of cmake to 2.4.4

On 2008-09-01 17:05:26 -0400, wrote:

Created attachment 1851 require_cmake2.4.4.patch

On 2008-09-07 16:44:05 -0400, Ryan C. Gordon wrote:

Fixed in hg changeset 586:7e31414ac037, thanks!

--ryan.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• use_g++_only_on_beos.patch (use_g++_only_on_beos.patch, text/plain, 2008-09-01 16:48:31 -0400, 482 bytes)

Reported in version: unspecified Reported for operating system, platform: Linux, PC

Comments on the original bug report:

On 2008-09-01 16:48:02 -0400, wrote:

I don't know why but it looks like that the only platform which needs a c++ compiler is Beos. With this patch mojosetup requires only a c compiler on all other platforms than Beos.

On 2008-09-01 16:48:31 -0400, wrote:

Created attachment 1850 use_g++_only_on_beos.patch

On 2008-09-07 16:16:00 -0400, Ryan C. Gordon wrote:

Comment on attachment 1850 use_g++_only_on_beos.patch

(changing mimetype of patch.)

On 2008-09-07 16:46:25 -0400, Ryan C. Gordon wrote:

Fixed in hg changeset 587:9dccead95bbc, thanks!

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified Reported for operating system, platform: All, Macintosh

Comments on the original bug report:

On 2007-05-22 02:38:05 -0400, Ryan C. Gordon wrote:

If a user cancels an install, they get a "ARE YOU SURE?!" message, then a msgbox saying "you cancelled this." Then a final stage page they have to click through. Can we lose some of these?

--ryan.

On 2008-01-11 23:59:05 -0500, Ryan C. Gordon wrote:

Fixed in svn revision # 397.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified Reported for operating system, platform: Linux, PC

Comments on the original bug report:

On 2009-02-26 15:33:15 -0500, FJA wrote:

I installed Prey as root to make it system-wide, but I don't see a launcher in my K-Menu, I guess in Gnome the launcher lacks too. Would be nice if you could implement this for non-experienced users, who don't know how to create it.

On 2009-03-02 01:18:47 -0500, Ryan C. Gordon wrote:

This should be creating a launcher with xdg-utils, and should handle Gnome and KDE (and some other desktop environments, too).

It tries the system-installed version of xdg-utils first; is it possible that it is buggy on your distro?

Or perhaps it installed a launcher for "root" and not for everyone (which is probably a bug in the installer)?

--ryan.

On 2009-03-02 01:20:12 -0500, Ryan C. Gordon wrote:

I'm kicking this bug over to the MojoSetup product, since it's not a Prey bug, really. This is just for record keeping: disregard this message.

--ryan.

On 2009-03-02 10:47:56 -0500, FJA wrote:

My system is OpenSuse 11.1, xdg-utils-1.0.2-56.1. The launcher should be placed into /usr/share/applications/ if one installs Prey as root. I created a .desktop file and put into this directory and all users see it in the menu now. If you need logs, I can install the game once again, perhaps it tells you why the launcher doesn't get created in my case.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified Reported for operating system, platform: All, All

Comments on the original bug report:

On 2007-05-22 04:06:49 -0400, Ryan C. Gordon wrote:

There's no way to refuse to install a package if the installer isn't running as the superuser.

MojoSetup.info.isadmin should be a boolean of whether the given account has administrator rights, and there might be some use in having a formal attribute to Setup.Package that tests this...but then, what do you do if you have several Setup.Packages and only one needs admin?

Is "admin" enough, or should we deal with finer-grained rights?

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified Reported for operating system, platform: All, All

Comments on the original bug report:

On 2007-05-22 04:00:09 -0400, Ryan C. Gordon wrote:

It would be nice if an installer could be paused, in case the download is using network bandwidth (or the primary install is using disk bandwidth) that the user has an immediate need for elsewhere.

This could be done largely with a "pause" button in the progress UI's page that loops and pumps the event queue without returning until resumed, but some extra help might be needed for the stupid network thread, which won't really pause until the ring buffer fills.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified Reported for operating system, platform: All, All

Comments on the original bug report:

On 2007-05-22 03:56:34 -0400, Ryan C. Gordon wrote:

Right now, if a download from an http:// or ftp:// source fails for any reason, the half-complete download and all others are deleted during fatal()'s cleanup.

It would be nice to be able to leave these there, including half-completed downloads, and pick up where we left off, or at least have an option to retry or resume a download if it fails during a given run.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified Reported for operating system, platform: Windows XP, PC

Comments on the original bug report:

On 2007-12-07 08:45:09 -0500, Ryan C. Gordon wrote:

...we need a UI (not even started), and we need to finish the platform layer (almost done). A lot of the code relies on Unix-style '/' paths, too, and that's a problem.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified Reported for operating system, platform: All, All

Comments on the original bug report:

On 2007-05-22 04:39:44 -0400, Ryan C. Gordon wrote:

...since it demonstrates archive-in-archive installation.

--ryan.