dpupmaker.sh v1.9 -- compiles source tarballs into Dotpups

[GuestToo]

this is a perfect example ... the dotpup system was created to address these exact issues ... so that i would not have to explain over and over and over again on the forum how to unzip a tar.gz package, how to chmod the permissions, how exectuables in the working dir need the path to begin with ./ (or type bash an-executable) ... etc etc etc

the dotpup system was never intended to be a package manager ... it was intended to be simple and easy to use and familiar to newbies who have installed Windows programs using an install-this-program.exe file (click to download ... click to install)

of course, dotpups are extremely flexible and can easily use any package management tools that are made available ... but it was never intended that package management tools be built into the dotpup system

i deliberately chose zip rather than gzip to compress the packages, because servers are often misconfigured and treat gzip files as text files, which can be confusing when a newbie clicks a tar.gz file and the browser shows a page of gibberish text characters

the dotpup system was targeted at newbies, but i think a simple and easy to use installer is a good thing for more advanced Puppy users too

[jmarsden]

this is a perfect example ...
the dotpup system was never intended to be a package manager ... it was intended to be simple and easy to use and familiar to newbies ...
the dotpup system was targeted at newbies, but i think a simple and easy to use installer is a good thing for more advanced Puppy users too

True, but in this case if a newbie is installing dpupmaker.sh, then they are installing something they have no use for anyway! So making it a neatly packaged and easy to install dotpup just "sends the wrong message" about what this script is.

The application (script) being discussed here is not for newcomers. Really, truly, it's not! It is a quick and still-fairly-dirty command line tool for developers. If it ever expands into a fully-fledged app, complete with a GUI wrapper and man pages (or .info files or similar documentation) etc., then at that stage, wrapping that app into an easily installed bundle (i.e. creating a package containing it) would IMO probably be appropriate.

At this early point in its lifecycle, I want dpupmaker.sh to be just a script, something that is played with by developers. People who can handle the idea of playing with scripts, who can perhaps even read the script to see how it does what it does and suggest improvements... does that make sense? I'm not being elistist, just practical -- at present, my shell script is not likely to be useful to someone, unless they have spent some significant time at a shell prompt already.

However, if someone else (perhaps a strong dotpup advocate such as yourself ) feels that they want to package up dpupmaker.sh right away and distribute dotpups of it (and support the newcomers who install it and have trouble using it??), then that's OK with me. The script is released under GPL, so of course anyone is free to take it and use it within the limits of that licence.

Sumary: You are right, ARAN's issues are a good demo of why simple "just click it" installers are useful to newcomers. But, dupmaker.sh is unlikely to be of any use to them.

Jonathan

[klhrevolutionist]

I will supply feedback as soon as I see something draws my attention.

As of lately there has not been an application that has come out, or I have found that interest me. So when I do come across something draws me in. You will be the first to know.

[ARAN]

I want only to say that i have just developed something very interessting thing based on your Script Johnathan.

Its a Rox Application which understand Drag and Drop functionality.

For creating DotPups now the Puppy user dont need any more to use the Shell.

They can only drag and drop the needed source files over the "Dot-Pup Maker" Icon and the hole Building Process beginn automaticly to work.

In the next days i will try to create a DotPup Package of this RoxApplication which extract your
Script in the needed Folder maked it Exuctable Copy the Drag and Drop Rox Application in the RoxApp Folder make the AppRun File in the Folder exucatble and copy the Icon to the Puppy Desktop automaticly.

I will post it here in this Forum Thread.
Here are some Screen Shots

[jmarsden]

I will supply feedback as soon as I see something draws my attention.

As of lately there has not been an application that has come out, or I have found that interest me. So when I do come across something draws me in. You will be the first to know.

OK. Until then... which app were you thinking of when you asked for the extra --strip and --enable-fast-install options to ./configure? I'd like to test that app to see if the current script will handle that sort of thing correctly (it should do). Even if the app is not all that interesting, it would still be a useful test of dpupmaker.sh

Jonathan

[jmarsden]

I want only to say that i have just developed something very interessting thing based on your Script Johnathan.

Its a Rox Application which understand Drag and Drop functionality.

For creating DotPups now the Puppy user dont need any more to use the Shell.

Cool -- this sort of GUI wrapper around dpupmaker.sh is something I have already thought about. I was expecting it to be created rather later, after the script itself has had a lot more testing and real-life use from the command line.

Well done! I am somewhat concerned that making it that easy to install and use may tempt non-developers to try and use it, and that could lead to an explosion of time-consuming "support requests". For example, have you actually successfully used dpupmaker.sh to build xmms-recorder yet? If so, I expect you had to build and install a couple of other things first, right? And how did you know what those pre-requisites were... it often takes some degree of extra knowledge to build medium or large applications successfully.

In the next days i will try to create a DotPup Package of this RoxApplication ...

Go for it! Do make sure the user can see the text output from the script, and to test the exit status of the script (0 means it seems to have worked, 1 or any other non-zero value means it failed. Otherwise the user will not know that they just created a bad or incomplete dotpup!

If you want to just post the Rox app here (not yet Dotpup-ified), ideally with a sentence or two on how to install it into Rox, that would be good too. Or start a separate thread in this forum for your GUI tool, maybe?

Jonathan

[ARAN]

I have just send you a .tar archive of the Rox Application per Private Mail to you.

The Application is not yet finished.
I am searching for a way to open a Bash Terminal Screen and run after this in this window your Skript.
Thats my idea for telling the User what is the actuall status of the dot pup making.
After the ending of the dotpup making the script should then get the Handle of the Bash Window and close after the end of the Process the Window Automaticly.

At the moment the script build the DotPup only quite.
The user dont see the messages of your script.

To try this Application extract it in the Folder
"/usr/local/apps"
and make shure that the File "AppRun" inside the Folder is set as executable by "chmod +x ...."

This drag and drop application is based on this tutorial here.
Maybe it can be for you be also helpfull.

http://rox.sourceforge.net/phpwiki/inde ... ials/Start

[MU]

I had some problems opening terminal-windows in Puppy.
However it works, see this program that runs wget:
http://www.murga.org/~puppy/viewtopic.p ... ight=opera

A solution that works fine for me, is using the "real" XTerm:
http://www.murga.org/~puppy/viewtopic.p ... ight=yacas
It also has a nice option "-hold", that avoids it is closed automatically after a command is executed.

However, Alucard reported problems with it:
http://www.murga.org/~puppy/viewtopic.php?p=30074#30074

But I don't know what happened there exactly.
I will try to replace it with the way the opera-installer runs rxvt.

Mark

[jmarsden]

I have just send you a .tar archive of the Rox Application per Private Mail to you. ...
I am searching for a way to open a Bash Terminal Screen and run after this in this window your Skript.

OK.

First, I suggest discussion of this ROX App would be better if it happens in a separate thread (topic) so it is separate from discussion of dpupmaker.sh itself?

Second: A design suggestion: the GUI app does not really need to open a terminal window... or any kind of shell window. Instead, it just needs some kind of text viewer widget, that displays the combined stdout and stderr streams produced by executing dpupmaker.sh. And some sort of "Yes it worked" or "Oh dear, it didn't work" alert dialog when the script completes, depending on the exit status of the script. This way the user gets the feedback and info they need, but they can't do anything potentially damaging, such as accidentally type commands into a root shell your GUI opened for them ... !

I am a complete beginner at GTK+ stuff, but I think that the GtkTextView widget type would be appropriate for the text viewer?
There's a tutorial on it at http://www.bravegnu.org/gtktext/ -- in C, but can be fairly readily translated to the Python GTK+ bindings that ROX Apps in the tutorial you pointed to seem to use, I think. Or use the GTK2 bindings of whatever programming language you prefer.

Please note that I have not tried out any of this with ROX at all, it is just an idea I am hoping someone else will explore!

Jonathan

[MU]

you could even use leafpad as a viewer.

Here is a viewer using Gtkdialog, save as gtk_edit and make it executable:

Code: Select all

#! /bin/bash

export MAIN_DIALOG='
 <vbox>
  <frame Edit>
    <edit>
      <input file>gtk_edit</input>
      <output file>new-file</output>
      <variable>EDIT</variable>
      <width>350</width><height>150</height>
    </edit>
    <hbox>
      <button>
        <label>Save as new-file</label>
        <action>Save:EDIT</action>
      </button>
      <button help>
      </button>
    </hbox>
  </frame>
  <hbox>
   <button ok></button>
   <button cancel></button>
  </hbox>
 </vbox>
'

gtkdialog2 --program=MAIN_DIALOG

Mark

[jmarsden]

you could even use leafpad as a viewer. ...

It seems unnecesary to use an editor as a viewer. I think the gtkdialog2 idea would be fine from a shell-script based ROX app, or the Python approach in the tutorial ARAN pointed at would be fine too, if the ROX app is being done in Python.

Since we don't really want or expect the user to edit the output of the underlying script (it makes no sense), wouldn't GtKTextViewer be more appropriate than GtkEdit ? Or am I just demonstrating how poor my knowledge of GTK2 truly is ...?!

Jonathan

[MU]

http://dotpups.de/tests/gtkdialog-0.59.8.tar.gz

This includes example-scripts for all (?) currently supported Dialogs.

You don't need to compile it.
Just in the examples, replace "gtkdialog" with "gtkdialog2".

Puppy uses 2 versions of gtkdialog for backward-compatibility, but everybody is encouraged to use gtkdialog2, which is gtkdialog-0.59.8.

There also is "Xdialog" in Puppy, but I don't know all the widgets.
grep Xdialog /usr/sbin/*
gives examples. Or see here: http://xdialog.dyns.net/ , it has a "textbox" you could use.


Mark

[ARAN]

@ Mark !

Tank you very much for your very interessting and helpfull links about GTKDialog.

@ Jonathan

What for installed tools does your Script expect to be installed on the PC exactly.
I have seen that it checks for mingw and maybe gcc.
Does it need also other Programms ?

I will open a new Thread for questions and answers how are not related to your dpupmaker.sh Skript.

[jmarsden]

What for installed tools does your Script expect to be installed on the PC exactly.
I have seen that it checks for mingw and maybe gcc.
Does it need also other Programms ?

It needs whatever the ./configure script within the tarball needs to build the package being built! Other than bash, tar, which, make, touch, sleep, mkdir, rm, cat, cut, sed, md5sum, zip and mv, the script itself doesn't use anything directly. [[ well, and the ./configure script it expects to find in each tarball, of course! ]]

But -- you can see that just by reading my script anyway

I think it might help you (or anyone!) to build a working GUI for dpupmaker.sh, to first read about the GNU autotools suite, and how these tools are used to create source code tarballs that build in a standard way, and install, on a wide variety of different systems. The knowledge gained by taking the time to do this will also be useful for manually running ./configure to build packages.

There is an online browseable copy of the book GNU Autoconf, Automake and Libtool by Gary V. Vaughan, Ben Elliston, Tom Tromey and Ian Lance Taylor, at http://sources.redhat.com/autobook/ . This is a great introduction to this set of tools. Definitely recommended.

There is also a decent little tutorial for those creating programs using this set of tools at http://inti.sourceforge.net/tutorial/li ... oject.html which has a handy list of links to other related documentation.

That combination (and a little experimentation!) should be enough for any moderately experienced software developer to understand and use these tools, and therefore to understand what dpupmaker.sh is automating. Google will also find the online manuals for each tool, if you want or need more detailed information about them.

Jonathan

[ARAN]

Thanks a lot for the very interessting Links Jonathan and the very helpfull answer.

[jmarsden]

Here's the list of changes to dpupmaker.sh since 1.4. The big new (and so experimental!) feature is the generation of "source dotpups", making it very easy to publish the sources used alongside the compiled binaries.

Code: Select all

# Revision 1.6  2006/01/13 09:07:51  root
# Source code now installed in /usr/local/archive
# Fixed size calculation for source dotpups
# Fixed registration of source dotpups with pupget database
#
# Revision 1.5  2006/01/13 05:34:19  root
# Removed make distclean as it is no longer a common target.
# Check exit status of ./configure command and exit upon failure.
# Include dpupmaker.sh version in created dotpup.sh files.
# Add creation of "source dotpup" files (experimental new feature).

Jonathan

P.S. The change log above was generated using RCS, which was itself installed from a dotpup created using dpupmaker.sh -- this means dpupmaker.sh helped build and package RCS, which is now helping maintain dpupmaker.sh

[MU]

Used it to create a dotpup:
http://www.murga.org/~puppy/viewtopic.php?p=32791#32791

I wanted to compile to /usr (because /usr/local/lib is not in Puppys /etc/ld.so.conf), so I ran
# ./dpupmaker.sh /mnt/hda11/_installfiles/bridge-utils/bridge-utils-1.0.6.tar.gz "" CONSAPPS --prefix=/usr

Did not work, so I changed 2 lines from "/usr/local" to "/usr"
I also added
xmessage -center installation finished!
in the end of the parts, where dotpup.sh is created.

Good work!
Thanks,Mark

[jmarsden]

Used it to create a dotpup: http://www.murga.org/~puppy/viewtopic.php?p=32791#32791

Cool, that is the first reported successful use of it by someone other than me

I wanted to compile to /usr (because /usr/local/lib is not in Puppys /etc/ld.so.conf)

Understood. I've added it to mine, a few days ago. Maybe there should be some discussion about adding /usr/local/lib to the default ld.so.conf for Puppy 1.0.8 or 2.0, or both?? Or, just like the use of /etc/profile.local , it might be useful to add a line

Code: Select all

include /etc/ld.so.conf.local

to it, so that people can customize their library load paths without editing the "official" config? Fedora uses local config directories rather than a single .local file, for both /etc/profile and ldconfig, which makes it easy for packages to drop in additions to either the profile or their library path as they install, so it uses

Code: Select all

include ld.so.conf.d/*.conf

which also seems a good approach.

Did not work, so I changed 2 lines from "/usr/local" to "/usr"

Yes, I hard-coded Barry's request to all dotpup creators to have their dotpups install into /usr/local. Maybe that was a bit too inflexible?

I also added xmessage -center installation finished! in the end of the parts, where dotpup.sh is created.

If you like that, that's fine. I'm personally less comfortable with using xmessage within dotpup.sh -- it makes the install fail if the end user chooses to install from the command line in text mode, instead of from Rox under X. Even under X, it forces the end user to click on OK (to get rid of the message) for each package installed if run in a loop (I have a couple of little scripts, including a simple command line dotpup installer, so that I can compile and build and install a whole set of packages totally unattended, based on a text config file listing them and the options they need to give to dpupmaker.sh, for example). If I downloaded 50 dotpups and wanted to install them all, I'd perhaps be a little irritated at being forced to click OK that many times The Unix / Linux convention for scripts (and for commands in general) is that "silence means it worked".

My thinking on this is that, if you like having that message appear at the end of every dotpup install done by Rox, then it would be more suitable to put the xmessage call into the script within Rox that handles .pup files, once, than to include it in every dotpup.sh. That approach also makes localization simpler (just one place to change the message to the user's preferred language, and you don't have to recreate every dotpup.sh file in every dotpup to support a new language!). The dotpups, and so the dotpup.sh files, that I create are 100% end-user-language-independent, by design. But I do understand that this is a personal choice, and that some of the dotpups out there do not currently follow that philosophy.

Jonathan

[bugman]

I would like to say that I am a new user and a complete idiot (the total package!) but I like doing stuff in a terminal. I learn things, I feel cool, I get to whine and complain in this forum when nothing works!

That being said, I downloaded, unzipped, and ran dpupmaker on the Chimera tarball. I got:

./dpupmaker.sh: line 121: ./configure: No such file or directory
dpupmaker.sh: Error: Unable to configure application chimera-2.0a19

I checked line 121 and it said:

./configure ${4:-"--prefix=/usr/local"} ||

Should I change this to something else (there were earlier posts in this thread about /usr that I did not understand)? Is Chimera un-puppable (I think I saw someone in here--or was it the DSL forum--using it)? Should I put aside a week and read the f'ing Rute manual?

[MU]

you should provide a link to the download, so we could look it up.

The standard way of compiling (used by this script, too) is
./configure
make
make install

But not every program uses this way.
Some only have
make

some only have
install.sh

some have
whatever.suffix

This is one of the reasons, why my Dotpup-wizard was based on binary files, you could "prepare" (compile) a program the way it wants it (manually), and then create a dotpup from the resulting binaries.

Mark