VectorLinux

Cooking up the Treats => General Development => Topic started by: M0E-lnx on April 09, 2007, 10:57:43 am

Title: Package builder utility
Post by: M0E-lnx on April 09, 2007, 10:57:43 am
A while back, I started looking into slackbuilds, and tried to learn some bash scripting because I wanted to understand what really was going on in the slackbuild... Ran into some good guides, and help from other users in the VL community. So here is the thing.

I've managed to write this script that sort of works like a slackbuild. It helps me shave prescious seconds off the package-building process, by automating some steps.
Here is some information on how to use it

The script is designed to be smart, and interactive.

Download and isntall this http://m0e.lnx.googlepages.com/vl-pbu-0.1.5-i586-2vl58.tlz
Take it for a spin

There is also a way to automate the entire thing by writing a .build file in the same dir as the source tarball...
see vl-pbu -h for help

For those of you who want to take a peek at the script itself,
Code: [Select]
cat /usr/sbin/vl-pbu after you've installed the package above package

This is good for building every-day stuff.. will not build python applications. (maybe later? )

If any of the packagers would like to try it out, and get me some feedback on it, tell me if you see this helps out at all... It's a tool I wrote for my own personal use, but then I thought it might help others too, and decided to share it.

Issues may be reported ON THIS THREAD ONLY or via a PM to me or via email
Title: Re: Package builder utility
Post by: blurymind on April 13, 2007, 04:59:42 am
this is very interesting.
It would be nice to make compiling more accessable and easy for the mainstream user.

There already are some frontends like:
http://www.kde-apps.org/content/show.php/Kompile?content=30223

and i really would love it if there was something like this for tgz/tlz slackware packages:
http://www.kde-apps.org/content/show.php/RPM+Package+Maker?content=33228

A tool to create packages 
~~~~~~~~~~
This is really a good idea and the script is sweet too. Here are a bunch of improvements ideas:

*make it easier to write description files.It would be awesome if it was possible to automate the proces as much as possible. Like,instead of going into howto's if the user gets a little pop-up box ,where he can write name of the app,version of the app,version of the package,architecture,and description of the package+license and home page...
This can be partially automated- it can be possible to pick the name of the app from the name of the tar.gz archive, same applies for its version...but they should be changeable by the user in the dialogue window.
I mean if it was possible to make a very siple frontend to this script which basically works like this:
it has one window in which the user picks the file from anywhere ("browse" button?) or from a certain folder and under that there are text boxes for:
>name of the package
>version
>architecture ?
>version of software
>version of the package
>and where it should be installed (could be done with a slide down menu: /opt/kde ;/opt ;/usr ;custom.. or just a box: Prefix=...)
------------automated description file generator: (sepparate script to work with this one?)-------------
>a box to write description of package
>under it - license
>under it - homepage
-------------------------------------------
and after all this info is inputed the user could just click "make package" and the terminal window pops out and starts "make" and after that "checkinstall"... I know this way the user wont be able to control compile flags,etc...so the advanced user would do it by hand.

This all can be done with a simple gui frontend and needs only one or two windows...idk,atleast that is a packager's dream... :P But this script is also very nice, i just suggest how it can be improved into something user-friendly.. Having a way to generate package description files is a way to go.
Title: Re: Package builder utility
Post by: M0E-lnx on April 13, 2007, 05:51:05 am
That would be sweet blurymind... What you've said is absolutely doable... the one problem I see with it is that I dont know any C or Gambas programming... I dont know if it's possible to create a GUI for a bash script.

I could rigg the script as you said for the description, but you'd still see not much more than a terminal window.
But I have to agree... a GUI package creator would be nice.

Actually, This script already takes care of the compile flags, the packager information, arch and those goodies...
Title: Re: Package builder utility
Post by: blurymind on April 13, 2007, 06:54:17 am
I've seen bash scripts that launch simple gui interface.
Someone at a beryl irc sent me such a script and it had three checkboxes and a one button.The script was less than 20 lines of code..
Zenity or what was it that it used for gui..
http://bashcurescancer.com/man/cmd/zenity
Edit: it was zenity that he used.

Thats not only the question.I think that is completely possible to make a simple description file generator...and not too hard too..
Anyways,m0e you are the one who brought to life this great script and the idea itself for a more easy and less time consuming way to create packages.Not only for mainstream users.

http://www.linuxpackages.net/slackcreator.php
linuxpackages has such a slack-desc file creator.I wonder how to put it in a bash script with zenity..
Title: Re: Package builder utility
Post by: M0E-lnx on April 13, 2007, 07:55:27 am
I've been looking into Zenity and Xdialog (Xdialog looks a lot easier)... and also the slackcreator thing at linuxpackages...
I could probabbly code something like that in php, but it would require a browser window, which I wouldn't really want... I'm also looking into GAMBAS... maybe If I lean that, I could even help do other things for VL to (ie, help into the new installer and stuff)... but I'm a n00b really... for now, I could probabbly make the script try to find a slack-desc in a slack repo somewhere... that's doable right now... but a GUI would be probabbly the better way to go...

but it's prolly further down the road
Title: Re: Package builder utility
Post by: blurymind on April 13, 2007, 08:53:05 am
you are probably right about gambas.
I myself too feel like a noob sometimes,but we are all bount to learn and never reach full knowledge..

I looked into the subject and saw that while zenity is pretty usefull for dialogue boxes,its unpractical for a gui frontend in this case. ::)
Title: Re: Package builder utility
Post by: M0E-lnx on April 13, 2007, 10:51:56 am
I thinik it would prolly be a lot easier to write an entirely new application in gambas than to create a GUI front end to this script. Xdialog looks good, but I believe it lacks some functionality for this script.
I'm digging into gambas... looks easy enough.. I'll see if I can get a hang of it and start writing some code... maybe eventually I can come up with a GUI package builder
Title: Re: Package builder utility
Post by: blurymind on April 13, 2007, 02:06:17 pm
i too am interested in this. Are there any good web manuals and tutorials out there?

All i have now is a book about programming with some basic commands in bash,tcl and perl..From which i could understand best bash.. "programming under linux" by i forgot his name.. :-[ its not an old book.

gambas 2 looks abit like visual basic.. :P Long time since i've seen that one  ;D brings back memories from high school..
Title: Re: Package builder utility
Post by: easuter on April 13, 2007, 02:49:03 pm
I haven't used Gambas2 yet, but Gambas (1.0.x) is pretty simple.
There is a free Gambas manual call "A Beginner's Guide to Gambas" that can help you get started.
I'd been starting and stopping with Gambas since early December, but only during my easter holidays did I commit myself to actually learning it, ad this is the result: http://www.vectorlinux.com/forum2/index.php?topic=2648.msg15316#msg15316

I think the GUI installer is written in Gambas2 and IIRC Gambas1 and Gambas2 projects are incompatible, so I'm not sure which one is best to chose for a long-term project. Joe1962 is the Gambas-man  ;) so he'll be able to tell you a lot more about Gambas2/Gambas1 pros-and-cons.
Title: Re: Package builder utility
Post by: rbistolfi on April 13, 2007, 03:29:55 pm
Wow, this is a nice project.
Looks like you are not alone in the "learning gambas" thing.
http://www.vectorlinux.com/forum2/index.php?topic=2524.0
We could start a wiki or a blog or something to join efforts and make the learning process more easy, dont you think?.
May be in that way we can make more easy to a noob like me and others to get involved in the vl development. Just an idea.
PS: my only coding experience is some php, do you think that is enough to take a shot with gambas?
Title: Re: Package builder utility
Post by: Joe1962 on April 13, 2007, 03:47:54 pm
Gambas2 is far beyond Gambas 1.0.x in language and IDE features, but it was in a very unstable phase where even the syntax could change from one release to the next. For this reason, I have stuck to 1.0.x for the official VL utilities. The Gambas 1.0.x runtime is a standard part of VL 5.8 base. I went with Gambas2 for the installer because I needed (or maybe wanted is more precise) the window embedding functionality to get cfdisk and gparted inside the installer window. However, in the Gambas mailing list as of last week, Benoit (the main Gambas author) has posted the following:
Quote
Hi everyone,

In the current SVN trunk, you will find a new IDE packager that allows you to
make RPM packages from a gambas project.

At the moment, this packager only supports Mandriva and Fedora distributions.

---- Why?

Because at the moment I have a clear documentation for these two distributions
only. In the future, I want to support OpenSuse, Debian, and Slackware.

---- How does it work?

These RPM packages:
1) Install the project executable in /usr/bin.
2) Install an icon in the distribution icon directory. (this is not a
standard).
3) Install the XDG *.desktop menu file, so that you see the application in
your menu.
4) Depends on distribution specific gambas binary packages.

---- What are the problems?

1) is not a problem.

2) depends on the distribution. Fedora needs one icon in /usr/share/pixmaps.
Mandriva has three icon directories. And I don't know for the other
distributions.

** I need information about that for the other distributions **

3) works only if the distribution supports the free-desktop XDG menu system.
This is the case for Mandriva and Fedora, even if these two distributions
don't have the same menu organization.

** I need information about that for the other distributions. Do they support
XDG menu system, or another one? **

4) relies on the distribution packagers. At the moment, if you want to install
a package made by the IDE, you have to force it.

There are other problems:

5) Debian and Slackware are not RPM-based. The Gambas 1.0.x IDE relied
on 'alien' to make a debian package from a RPM, but I am not sure that it is
the good solution.

6) There are many Debian-based distributions, and Debian packages do not
necessarilly work on these distributions! (Somebody said 'Ubuntu' ?)

** I need information about how to make packages on these distributions **

---- How can you help?

By making gambas binary packages for your distribution, if you can of course!
The gambas binary packages specifications are at:

http://gambasdoc.org/help/howto/package

By testing the packager on your distribution. The packagers relies on the
rpmbuild tool at the moment. Which tool is needed on your distribution? How
does that tool work? This is especially important on non-RPM distribution
like Debian or Slackware.

By giving me information about your distribution if it is different from the
standard ones.

Please help me making a really working packager for Gambas 2.0. This is the
last big step before making a release candidate! With a few other little
things of course... :-)

Thanks in advance!

Regards,

--
Benoit Minisini
A bit long, but I thought it important to quote here in it's entirety. This means a Gambas 2.0 RC is coming in the near future, but also, that we should chime in with the new packager, so it supports Slackware packages properly, but maybe even VL packages with full dependency info.

WRT a joint Gambas discussion place, I can offer this forum I was experimenting with a while back and sort of abandoned (time to make it work, hehe): http://jjrweb.byethost.com/forum/index.php

Post away in Vector Linux Development: Gambas.


EDIT: Give me a name and I'll create another sub-sub-Forum inside Gambas for this project, or any other.
Title: Re: Package builder utility
Post by: easuter on April 16, 2007, 10:42:42 am
Quote from: Joe1962
Give me a name and I'll create another sub-sub-Forum inside Gambas for this project, or any other.

Maybe "Lobbying for VectorLinux package support in Gambas2"?  :)
Title: Re: Package builder utility
Post by: cintyram on April 16, 2007, 11:57:31 am
Moe and blurrymind,
  this is an awesome project. May the force be with you:).
in order to simplify the process, i will first review your script and give you feedback.
as for the gui part, i suggest that we collect all feature requests in a thread, and summarize so that you can freeze the requirements and aim for a stable release.  This approach has helped hanumizzle work on VASM2 in the past.

So lets start with the most significant problems, and wants.

the most significant problem i find when trying to build packages is dependencies.
i agree that the other features like automated desc file generator etc.. are helpful too. but for me something that confirms that all the dependencies are in place is a boon.  ususally this is the job of
configure if you do everything by hand.  how to go about implementing a solution for this is a different discussion, lets not get into that in this thread.

the second most important point is to have some test packages that this tool can make life simple with.
i suggest we go with some tough ones too.

1 cinelerra
2 kinodv
3 gnustep [ they even have their own script like xfce does ]
4 VLC

thanks
cheers
ram

Title: Re: Package builder utility
Post by: M0E-lnx on April 16, 2007, 12:23:25 pm
Thank you guys for the replies... It's great to know other are interested on this kind of thing as well.

I'd like to point out a few more things about the script.
First off, the GUI is no where close, so for now, I'd be happy with just a working script. (Although, I am in the process of learning gambas (1.x) and getting very familiar with it.)

The script can already generate the slack-desc file. Here is how you do it
Simply write out the description in a text file. Call it <name-of-application>.desc. This should be done before executing the script, if it's not there, you should see a red warning, telling you no description is found.
You can also write a description-pak file, the script will test both of these for compatibility before using them...

@ cintyram
I understand exactly what you mean with the dependancy thing... Not much we can do there, however... on tough applications to build, you can extend the functionality of the script by creating a <name-of-application>.build file
This helps the script more accurately identify values to variables it needs in order to build a package.

Keep in mind though, that it is still a work in progress, which is why I must go back and thank all of you for your input
Title: Re: Package builder utility
Post by: M0E-lnx on April 20, 2007, 12:01:10 pm
I've been trying to come up with a GUI layout of the program...
Here is what I got so far. Functinality ATM is limited.

Fist screen:
(http://xs414.xs.to/xs414/07165/Main.JPG.xs.jpg) (http://xs.to/xs.php?h=xs414&d=07165&f=Main.JPG)

Second Screen
(http://xs414.xs.to/xs414/07165/Step01.JPG.xs.jpg) (http://xs.to/xs.php?h=xs414&d=07165&f=Step01.JPG)

@ Blurymind
I could prolly use some graphics to add in the buttons...
maybe in the next screen, have a summary of what's about to happen, and have one button with a bzip / gzip to .tlz/.tgz graphic
Title: Re: Package builder utility
Post by: blurymind on April 20, 2007, 02:14:25 pm
well,i'll be! This looks very promissing,M0e.  :)

I will LOve to do any graphics for this. But please,be more specific about the graphics that will be needed. You need a graphic that will symbolice a tlz package? I can make one of a tukaani, or my old idea with the coconut,if not that- use a graphic from a gpl icon set of a tar archive and make some changes to it-add this and that...
We could talk over irc or pm ?
I wanna help.I really admire your effort and dedication.
=)
Title: Re: Package builder utility
Post by: M0E-lnx on April 26, 2007, 11:37:26 am
I've made a few changes... Moved a couple of things around.
Here is a new screenie

The new first window --> http://xs314.xs.to/xs314/07174/window1.JPG

The new second window --> http://xs314.xs.to/xs314/07174/window2.JPG

I need your input... do you think that first window is annoying/unnesessary? or is it ok as it is?

Graphics are courtesy of Blurymind... (Thanks again dude ;) )
Title: Re: Package builder utility
Post by: Freeman on April 26, 2007, 11:41:24 am
Wow!! Looks awesome!

Really nice could be if it detected the running version of VL and choose that one as a default tag in the end of the package name  ;)
Title: Re: Package builder utility
Post by: M0E-lnx on April 26, 2007, 11:47:42 am
Absolutely possible. But keep in mind this is a work in progress... I'm writing and designing this stuff as I learn new things.

Thanks for the input
Title: Re: Package builder utility
Post by: exeterdad on April 26, 2007, 12:25:50 pm
For the short time you have invested in learning/creating this thing...  I'm impressed!
Title: Re: Package builder utility
Post by: M0E-lnx on April 26, 2007, 12:42:07 pm
For the short time you have invested in learning/creating this thing...  I'm impressed!

I tried VB a long time ago in Wind OS... The Gambas syntax looks very familiar to me, so I guess that's an advantage
Title: Re: Package builder utility
Post by: blurymind on April 26, 2007, 12:47:28 pm
this looks very good,Moe.If there is anything ,i will help test it or with graphics..

I used to learn visualbasic back in high school,and they teached us how to make pretty basic apps, but i dont remember anything...Maybe only how to make menus and the gui..
Title: Re: Package builder utility
Post by: M0E-lnx on April 26, 2007, 12:52:08 pm
I bet if you start seeing the gambas syntax it'll start coming back to you...

It's very similar.
Title: Re: Package builder utility
Post by: M0E-lnx on May 07, 2007, 07:59:06 am
I've managed to get this to a point where it does build a package.

It is however far from finished. For those who would like to take a peek...

ABOUT THIS RELEASE

You will need the gambas2 package to run this
Run it as root (It still can't tell the difference just yet)
It not doing the descriptions yet.

You can find it at http://m0e.lnx.googlepages.com (http://m0e.lnx.googlepages.com)

DO NOT SUBMIT ANY PACKAGES CREATED WITH THIS TOOL TO THE REPOS.


Title: Re: Package builder utility
Post by: The Headacher on May 07, 2007, 03:33:23 pm
Seems to work nicely here, qjackctl built fine!

I realize there's still a lot left to do and you probably thought of this anyways, but here's some stuff that would nice:
- option to select docs from the source instead of the default docs included by checkinstall would be nice.
- the gui doesn't make a difference between a warning and an error.
- I don't recall a way to save the package where I want it.

Keep up the good work!
Title: Re: Package builder utility
Post by: M0E-lnx on May 08, 2007, 05:49:29 am
Like I said, it's a work in progress... All of those features will be available later, along with the option to write a description (or locate an existing description file in the system).

BTW, Thanks for the feedback
Title: Re: Package builder utility
Post by: M0E-lnx on May 18, 2007, 02:04:56 pm
After a complete turn around, I decided to do this using Gambas1 instead...
Here is a new attempt at the target.

http://m0e.lnx.googlepages.com/vlpbu2-0.0.25-i586-1vl58.tlz

You will need again the gambas-runtime package to run this.

This one consists of a bash script using the gambas GUI as a front end.

Take this one for a spin, and let me know how it can be inproved. Again.... Work in progress... some functions are still not fully implemented
Although, you should be able to build a package, add a description file, and it should even append the slack-desc for you.

Title: Re: Package builder utility
Post by: Joe1962 on May 18, 2007, 03:02:59 pm
gambas-runtime-1.0.17 is part of the VL base since the 5.8 Dynamites.

EDIT: BTW, Gambas 2 1.9.49 is out today, I already downloaded and should be building it later tonight. The point of this is that, as I've warned before, the bytecode has again changed, and all apps would need to be recompiled.
Title: Re: Package builder utility
Post by: LLL on May 18, 2007, 04:24:34 pm
This is neat. Thanks!

Only feedback I have is cosmetic: Move the VL-globe to upper-right of dialog, and then center TAR --> TLZ graphic where it is.

Have fun! :)

LLL
Title: Re: Package builder utility
Post by: M0E-lnx on May 22, 2007, 06:17:35 am
@ LLL

You must have looked at the first one on the screen shots at the beginning of the thread. I kinda stopped working on that one, because I moved the project over to Gambas 1, so it now looks quite a bit different. It has like you said the VL globe to the top right of the screen, and the Tar --> TLZ graphic is centered.

I'm still not happy with the looks, but I guess as long as it does it's thing.

Thanks for the feedback. Again, the latest can be found at http://m0e.lnx.googlepages.com
Title: Re: Package builder utility
Post by: Joe1962 on May 23, 2007, 04:36:37 pm
Heh, I "lost" this thread today, couldn't find it in the usual places. Then Masta gave me the link. Turns out it was in The Lounge for some reason, as if this wasn't a serious piece of work, lol. So here it is in General Development now, where it belongs... ;D
Title: Re: Package builder utility
Post by: blurymind on May 24, 2007, 12:54:20 am
i just saw vlpbu2 and i must say that it turns out great. Moe has done a wonderfull job with this utility.

Idea suggestions:
Is it possible to have something to encourage the user to submit the created packages? Like a promt message with a link to "submit package" thread at the forum or something like that? After the package is created of course..
or even ask the user whether he would like to upload this package to a submiting repository or something like that. Of course the user should be prompted for a password and a username...but still,this automation leads to security issues and other things to question.

One thing that has always been a pain in the neck about making packages, making the packager untar and makepkg them again, is the need to add a launcher in the start menu for many packages. The need to find a pixmap,then move it to a directory, then make a *.desktop file,etc etc. I wonder if its possible for the utility to pick up the lack of a *.desktop file in a package and prompt the user to create one ...with a simple window (yet another module for this utility) where the user has to pick name of the entry,type of the app,pixmap file with the correct size,and the command to execute the app.. :P This module can create a *.desktop file and put it in the correct dir (which is the same always) and move the correct pixmap to the pixmaps dir.
------------------------------------
BUG report?:
When i tried it on a few source archives:

on the first i had a configure error due a dependency...which is not vlpbu's fault,but it kept on saying that it created a tlz package and ended saying:  "*.tlz doesn't look too good... I'll fix it"

now on the second,configure and make went fine, it compressed it into a tlz,but it ended saying the same thing:
"*.tlz doesn't look too good... I'll fix it"
Where did it create the tlz package?  I waited for a minute with the hope it will tell me or i will find it in the same dir where the source archive was (~/), then clicked abort and got the message "built process has not yet begun"

EDIT:
I looked at /tmp/packagename and in there i could find a tlz.. in the subdir "Package-pkgname"... all i can say is that while this isnt an error, the package end result is very hard to find by the user. After the package is created the user should be asked where to move that package or something like that.. :-\
And the message itself suggests that there is a problem with the package.

console messages:
Code: [Select]
root:# vlpbu2
Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed
WARNING: circular references detected
Form1 (1)
Mutex destroy failure: Device or resource busy
WARNING: 39 allocation(s) non freed.

hope it helps
--------------------
a little cosmetic fix:
Is it possible when you browse for the source archive,you are sent to /home directory by default,instead of /usr/bin
---------------
Also,this version looks alot better than the previous. Its good that the user can now see whats going on on configure and make steps.
----------
i will work out some new graphic files for vl-pbu these days..
Title: Re: Package builder utility
Post by: M0E-lnx on May 24, 2007, 05:50:23 am
Thanks to all of you following my slow pased project.

@ joe1962:

I originally posted this in the launge because it was nothing more than an idea, didn't know how far I was going to get with gambas, or if I would stick to it at all. Turns out, I did, and hope to get even further with it.

@ Blurymind
As far as encouraging the user to submit a package goes, I'm not sure that's the best thing to do, since all packagers must be registered and need to have ssh keys in place at OSL. We could go as far as encouraging them into looking at contributing to the project, by registering themselves as packages, but they'd still need to submit the packages themselves. I'm not sure I want to automate that.

As far as yoru experience with the sources, I guess it's just the wording of the message that threw you off. Here is what happens
instead of checkinstall, I use makeslapt to create the package and get slapt-get deps rules on there too. Now that's where it gets tricky, because I have to parse the package name in format that is not really valid for a package name.
Code: [Select]
makeslapt --tlz ${APP}-${APP_VER}_${PKG_ARCH}_${PKG_REL}.tlzwhich results in something like this: Name-Version_Arch_Rel.tlz
Note how the "-" changes to "_" after the second instance, that's because makeslapt has to be called like that, or the package name will be really bad.
So I just let it do it like that, and then simply rename the package as: Name-Version-Arch-Rel.tlz

I have however modified the message to avoid any more misunderstandings

The final package is sent to /tmp/application-version/package-application.
Again, this will not be the standard. Eventually, I'll add provisions to offer the user the final path of the resulting package, and a cleanup option to clean up the build dir.

As far as the console message goes, I get that too, I think it's a gambas thing, I'll have to research it.

Again, thanks for the graphics and testing, it really helps a lot

PS. I need to see if maybe you can draw me an icon for this thing, so I can create a .desktop file for it, and make it start with a click instead of a console command.
Title: Re: Package builder utility
Post by: Joe1962 on May 24, 2007, 06:15:53 am
Dang, blurymind... Now you got me roaring to cook up a .desktop file generator in gambas!!! I studied the .desktop specs extensively when doing vl-hot (this helped me with packaging too), might as well put that time to yet another use.

As for those console errors, the first one is from the session manager and you'll get that a it lot if you launch qt/kde apps from terminal. The second part is probably due to the way you exit the app, not releasing all the windows, etc. I used to get that till I researched / figured out how to end gracefully.
Title: Re: Package builder utility
Post by: M0E-lnx on May 24, 2007, 02:39:26 pm
With the help of Joe1962, I have accomplished one of the most useful parts of this project.

The slack-desc generator is now fully functional (thanks again joe1962 for your help).

As I now prepare to make the first beta release for testing, I'd like to open up for suggestions for the name for this project.
I've been calling it vlpbu2 (since vlpbu was the other terminal based package builder). However, I can't say I'm fully satisfied with the name i've chosen. So I'd like to get some input so you guys help me come up with a good descriptive name.

I've thought about "vpackager".

Any other suggestions, please shoot away
Title: Re: Package builder utility
Post by: Joe1962 on May 24, 2007, 02:42:43 pm
I've thought about "vpackager".
Sounds fitting.
Title: Re: Package builder utility
Post by: rbistolfi on May 24, 2007, 03:56:30 pm
Thats name sounds nice. Congratulations for the great job! I think you are figthing with Joe for the "developer of the month" prize. You have some advantage, because of your nice app, but joe is the gambas man, and we have easuter too with that ndiswrapper tool... will be hard to choose...  ;D

PS: The soho team have the "developer of the year" prize, they dont fit on this contest.
Title: Re: Package builder utility
Post by: blurymind on May 25, 2007, 01:57:20 am
awesome!!  ;D  This utility will save sooo much time and will make the installing from source archives  more accessible and easy for the newbie user,who is dependable too much of the repository.

Moe>  u are right for the package submiting. The only kind of way to encourage the user is to ask him somewhere if he would like to become a packager and submit packages and link to the forum or to VL's website (maybe a new section of the site,called "latest packages" or something like that)
Your utility does what its supposed to do very well. My only remark is that after the packaging is complete,it points to the user where the package is,or puts the tlz package in the same directory where the source package is. :) , which ofcourse is already planned,so no problems here. Vlpbu2 perfectly picks the version number of the package.I think you managed to do that very well! =)
The "tag" feature is abit limited,because it can do only vl58 and vl6, i think it would be great if it could assign a custom tag,this way there will be no limitation of vector's version.

I will try to make better graphics for next version. It already looks awesome...

Joe1962>i agree vpackager sounds awesome too. Thanks for helping Moe and yeah- the module for generating a custom *desktop file will surelly be a great addition to this tool.It will make it a priceless time-saver! I remember playing around with a package for like a whole hour just to get the right pixmap and desktop file in it (i didnt know how to do it before and it really was a pain in the neck). :P

I think Moe deserves to be a developer of the month or whatever.  :D This is great job and  the tool is good enough to be included in some of VL's next releases.Its an app like no other.Something that other distros dont have. Worth including in the vl system menu,right under gslapt!   
Title: Re: Package builder utility
Post by: M0E-lnx on May 25, 2007, 05:53:30 am
@ blurymind:
The reason I left the VL tag choices limited to vl58 and vl60 is because that way you keep a consistant naming scheme. I certainly wouldn't want someone to submit a package that's not named or created properly.

What I need now is an icon (24x24 ??) to include in the app's title bar and for the menu entry. In the future, maybe a theme for the buttons would be nice.

But really, thanks blurymind. You made this skeleton look nice ;)

@ all others:

Question... Should I offer an option to override default CFLAGS?
Title: Re: Package builder utility
Post by: easuter on May 25, 2007, 06:34:50 am
Quote
Question... Should I offer an option to override default CFLAGS?

That may be a good idea.
Title: Re: Package builder utility
Post by: Joe1962 on May 25, 2007, 09:32:43 am
I think Moe deserves to be a developer of the month or whatever.
I agree! But only if I get 2 retrospective awards for vl-hot and vcpufreq... ;D
Title: Re: Package builder utility
Post by: M0E-lnx on May 25, 2007, 10:05:02 am
LOL @ Joe1962

I dont think I'm even close to wining any kind of award... I'm just a n00b. Had lots of help building this beast (see the credits tab in about)
Title: Re: Package builder utility
Post by: blurymind on May 25, 2007, 10:21:54 am
No noob can get this far with such a great utility.  :P
i created a bunch of graphic files that you can use:

http://www.garbagewars.com/gallery/thumbnails.php?album=20

check the album later,i think of uploading some more. For now there are 3 variations of the previous graphic and a launcher icon for vl-pbu... Vlpbu is easier to type in console than vpackager ::)
Title: Re: Package builder utility
Post by: Joe1962 on May 25, 2007, 10:50:47 am
Vlpbu is easier to type in console than vpackager ::)
Maybe, but it's way harder to remember... ;)
Title: Re: Package builder utility
Post by: M0E-lnx on May 25, 2007, 10:52:53 am
I just thought that since this is a GUI, it woudlnt' make sense if the user has to type the name to run it. which is why it will go on the menu, so you can point and click away...

BTW.. Thanks again for your help BM
Title: Re: Package builder utility
Post by: M0E-lnx on May 25, 2007, 01:03:26 pm
Here goes nothing:

I'm gonna call this 1.0beta1.

Here it is to all of you who contributed...

Cheers.
Title: Re: Package builder utility
Post by: easuter on May 25, 2007, 02:01:50 pm
Looking pretty good! Really nice app  :)

One thing I noticed though: if you click on the "Load..." button to select a description and then hit Cancel in the dialog, the "Create..." button does not re-appear.
Title: Re: Package builder utility
Post by: M0E-lnx on May 25, 2007, 02:30:52 pm
Adding to the TODO list
Title: Re: Package builder utility
Post by: thegeekster on May 25, 2007, 02:38:08 pm
Vlpbu is easier to type in console than vpackager ::)
Maybe, but it's way harder to remember... ;)
Not to mention there's tab completion.........'vpac<tab key>'..... ;)
Title: Re: Package builder utility
Post by: blurymind on May 26, 2007, 01:08:14 am
Bug repport:
When i choose to save the package to another directory (a home directory /home/shadow) , the package simply doesnt show up there and dissapears. But when i just hit "quit" i can still find it at /tmp/*

I said that at the packages thread,but the icon doesnt have a transparent bg:
http://www.vectorlinux.com/forum2/index.php?topic=3114.0

-----------------
feature request for next versions:

 >It would definatelly be great if it has a *.desktop generator for the gui apps. There are just so many that lack a desktop entry. ;D

More Feature requests:
 > add the option "install package" at "vpackager-save package" window...and change the button "quit" to "Ok" or "Done"
 >Better dettection if the source tarball is invalid (if there is no configure+/make found, a message pops out that this package is not a standart source package and the option to open $filemanager at the directory where it is untarred,so the user can look for a "Readme" file.
 >More time at the window where it shows whats going on at Configure and Make ("vpackager Building"), meaning... after configure and make and packaging is done, the "vpackager- save package" window doesnt pop up instantly,closing the logs ("vpackager Building")...instead,after configure,make and packaging is ready,a "save package" or "move on" something like that button at the bottom (next to "Abort" button) becomes clickable and when the user clicks it,only then the "vpackager Building" is closed and "vpackager-save package" (the last) window pops up. This way,if there is an error at make or configure,the user will have time to copy it and find the needed deps.

------------------------
Great job on the slack-desc utility.I absolutely love it. Its way better than what checkinstall had to offer.

Btw,some minor bugfixes and this utility will definatelly be one of VL's killer apps (vasm,vl-hot,vcpufreq,etc).Something to make other distros envious and to magnet new users' curiousity. I can already see a DW weekly review mentioning it...I vote two thumbs to include it in vl6 (+all the upgrades that slack11.1 will bring- it will definatelly make vl6 a release to remember)

Title: Re: Package builder utility
Post by: LLL on May 26, 2007, 07:44:26 am
Wow...great! :)

Just built a synaptics package to test the utility - a very exciting tool to expand our packaging pool to less experienced users!

SUGGESTIONS:

1. Users would be more comfortable if the background windows always stay visible.
- e.g., When I click the the "Create" slack-desc, I lose the originating window, and jump into a new one. The parent window should stay visible to give context to the child window.

2. The  output terminal when building the package is great...but it whizzes by quickly, then disappears. Could it have a "NEXT" button that would allow users to view the content as long as they would like before advancing to the next window? I think I saw the word "Error" but couldn't catch it in time.

3. The "Go" button would be better off as "Build Package"

4. The "Save Package" page left me confused. Still not sure where it went, or what clicking the "Quit" button was going to do, or exactly how to choose the file destination.
-----

Keep up the great work! :)

LLL
Title: Re: Package builder utility
Post by: blurymind on May 26, 2007, 08:11:56 am
even for the experienced users- this utility saves a lot of time.  ;D

But yeah,LLL suggestion 2 is the same as mine.
3>I think "go" sounds good too,but "build package" is notthe bes choice,considering it goes through configure and make before doing the actual building. I vote it stays "go" or is changed to "start"

1> another one that i dont agree with. One window is best (the way it is in Vasm).Less windows make it look and act more straightforward,simpler. When the user sees two or more opened windows of the same app,it makes it look the more frustating and complicated task.

Also the credits should be at the "about" window,not at help. Thanks for mentioning me. =)

A question: should i make more graphic files? Adding more graphics to window- does that make vpackager load slower?
Title: Re: Package builder utility
Post by: M0E-lnx on May 28, 2007, 01:03:15 pm
OK.. I've been doing some improvements based on your input... here are the changes

Added the better icon (and expanded it to all the windows)
Fixed the problem with the buttons for the slack-desc create/load
Once the package is created, the second window remains open so the user can analyze the output, and made a "next" button (disabled during the build process) to go to the next window.
Currently working on the issue with the final window saving the package.

Is there any more things you'd like to see changed / done ??

Thanks for the input. I too believe this could be a great application to aid newbies install things the right way, and keep them from messing up a perfectly good install.

@ blurymind:

This application is way too small for graphics to make it load slowly. The only thing I'd like to see in the future maybe is theme for the buttons.
Title: Re: Package builder utility
Post by: blurymind on May 28, 2007, 01:29:52 pm
Moe,for the next version i can provide a better graphic file. The curent one has a hard to notice little smudge. I will fix that soon,and add/change anything if you want to.

 I want to make a small graphic for the "save package" window...I think i know what will look pretty nice there..But we shouldnt put too much graphics on this. For the "slack-desc" window - we will only clutter it. adding graphics to the buttons,will make them bigger and taking more space...so we should use graphics for the bottom buttons only or for the most important buttons,but not all buttons.... anyways, if we have a very small graphics for the butons,that are simple...I think i can compile a theme for the buttons (maybe even all buttons if you want to). I will get on that.

for those who are curious,here is how the curent vpackager at the repo looks like.
http://xs215.xs.to/xs215/07221/screenshot-vlpbu.jpg
Title: Re: Package builder utility
Post by: M0E-lnx on May 29, 2007, 01:29:48 pm
1.0beta2 Now in the repos... Please upgrade

IN THIS RELEASE:

VERSION 1.0beta2
 + Fixed issue with the "create" button dissapearing after the user clicks "cancel"
 + Added support for Custom CFLAGS (needs testing)
 + Changed the way strings are parsed to the bash script.
 - Eliminated About/Usage window (not necessary)
 + Corrected graphics (icons, and on main window, also added one to save package)
 + Fixed the bug where the package was not getting saved to the right place
 + Allowed the user to look at the std output before moving on to the next step
 + Inproved the 'Status' area so the user knows what's happening in the background
 / Changed the 'Go ...' button to 'Start' (Hope it doesn't remind anyone of a bad OS ;)
 + Fixed the .desktop file (to make it show up in the KDE menu as well for KDE users)

The new release is now available via slapt-get

Hope this one is better
Title: Re: Package builder utility
Post by: blurymind on May 30, 2007, 01:15:34 am
Vlpackager beta 2- it untars the source but afterwards can't find configure script. I go to the /tmp where it was untared and i see that there is a configure script there.
Code: [Select]
Error: configure script not found... I dont know how to build this.
Anybody else with the same problem?  :-\

Weird, i downgraded to old version and it still can't find the configure script!

the package i tried was:
http://downloads.sourceforge.net/liferea/liferea-1.2.15b.tar.gz?modtime=1179442457&big_mirror=0

also tried with LIVE,and a bunch of other source archives. It can't find their configure file,altho there is one right there !

I think something broke it along the upgrade.


EDIT: weird, i tried to build some of the old packages ,that i did on vpackagerbeta1 and it finds their configure script both on beta1 and beta2

EDIT2: Ok,its not from the version, it seems that vpackager can't sometimes find the configure file!
Packages that cant configure:
Liferea-1.2.15b.tar.gz
LiVES-0.9.8.4.tar.gz ( http://www.xs4all.nl/~salsaman/lives/current/LiVES-0.9.8.4.tar.gz )


Suggestion: Add the vpackager icon at its about window.
Title: Re: Package builder utility
Post by: M0E-lnx on May 30, 2007, 05:52:51 am
That is odd. That part of the project didn't change, but I'll look into it. I tried it many times before uploading the new release and it worked every time.


Try completely removing the application
Code: [Select]
removepkg /var/log/packager/vpackager-*and then slapt-get it again
Title: Re: Package builder utility
Post by: blurymind on May 30, 2007, 06:27:13 am
Code: [Select]
root:# removepkg /var/log/packager/vpackager-*

No such package: /var/log/packages/vpackager-*. Can't remove.

no,no it upgrades fine... I've come to the conclusion that the problem is in the packages that i am trying to build. It seems that vpackager can't find the config file in some packages,altho there is a configure file.

Try to build the two packages that i linked to.

-----------------
Also, is it possible from stopping it to create a tlz if make didnt went fine?if the user doesnt notice the error message, he is left with an empty package. If it was possible to color the text "no such file or directpry" in red color at the output.. ::)
Title: Re: Package builder utility
Post by: uelsk8s on May 30, 2007, 06:29:56 am
is the configure file there set to executable?
Title: Re: Package builder utility
Post by: blurymind on May 30, 2007, 06:52:30 am
is the configure file there set to executable?
yes, on both lives and liferea!

do you get the same error when trying to build them with vpackager? Its possible that the directory path that they are in somehow stops vlpbu script to find them?

Edit: Yes! Thats exactly where the bug lies! The name of the source folder in the tar.gz...

I untarred liferea and renamed the folder from liferea-1.2.15 to liferea-1.2.1 , tarred it again and when i opened it with vpackager, it managed to find its configure file!

Thus vpackager is unable to find "configure" in the directory /tmp/liferea-1.2.15
but it managed to find it in the directory  /tmp/liferea-1.2.1  !!
For the protocol- vpackager did pick its version right, vlpbu script can't find the configure file if the version number is longer than *.*.*
Title: Re: Package builder utility
Post by: M0E-lnx on May 30, 2007, 07:00:08 am
I know exactly what's wrong here, and it's probabbly going to be hard to avoid it.

The problem is in the naming scheme of the source tarball

notice how it's named LiVES, So ovbiously, when vpackager extracts, it does this
Code: [Select]
tar xfv LiVES-xxx
and that part works. The problem is that this becomes /tmp/lives-xxxx not /tmp/LiVES-xxx.

so vpackager will look for a configure file in /tmp/LiVES-xxx not /tmp/lives-xxx, because as far a vpackager is concerned, the application name is LiVES and not lives.

So this is a problem with the source naming scheme.

This is a reminder that no matter how good this application gets, it will never be able to build EVERYTHING.
Title: Re: Package builder utility
Post by: blurymind on May 30, 2007, 07:33:05 am
hmm,there should be a way around this problem.Vpackager picks the version number correctly from the package name (no matter how long it is) ,extracts it correctly,but then it can't find its configure properly...
Title: Re: Package builder utility
Post by: M0E-lnx on May 30, 2007, 07:48:51 am
because of the way the compressed the source

I can try to make it guess the results of the tarball, but that could get troublesome. Some conflicts may raise if I throw a wild flag there.
Title: Re: Package builder utility
Post by: easuter on May 30, 2007, 07:53:36 am
hmm,there should be a way around this problem.Vpackager picks the version number correctly from the package name (no matter how long it is) ,extracts it correctly,but then it can't find its configure properly...

This was also a problem when packaging some GNOME stuff, the archive name was not the same as the source directory name. So before running the build script, I would unpack the tarball, change the name of the directory and then repack it.

I'm not aware of any other way around this. vpackager doesn't "detect" the names or versions "automagicaly", it cuts the text from the tarball string:

name | - | version | .extension

And then when extracted the source directory should use that exact name.
This is probably something to point out to the developers of the program in question since they aren't following standards.
Title: Re: Package builder utility
Post by: blurymind on May 30, 2007, 07:56:23 am
Quote
This was also a problem when packaging some GNOME stuff, the archive name was not the same as the source directory name. So before running the build script, I would unpack the tarball, change the name of the directory and then repack it.

No no, its not the same here!
The archive name is exactly the same as the directory (the name of the folder inside)! Its just that its longer than the ordinary:
its not 1.2.3  but 1.2.3.4b and that causes vpackager to not find the configure script


maybe if not possible to build the package because of this (source directories with a version that is not x.x.x but x.x.x.x1,we should somehow detect the problem and tell the user to rename the folder inside the tarball to have a shorter version name?
Title: Re: Package builder utility
Post by: easuter on May 30, 2007, 08:05:19 am
What is the program you are trying to build?
Title: Re: Package builder utility
Post by: M0E-lnx on May 30, 2007, 08:06:53 am
The problem with liferea is exactly the same

The developer named the source liferea-1.2.15b.tar.gz which is good for the extract command.
But the directory inside that tarball is named liferea-1.2.15 (missing the "b")

It's not that vpackager can't find it, or that ii can't handle version numbers x.x.x.x. Like easuter said, all it does is split the string into sections. This should work most of the time, but it will never work on a source archive that doesn't have the correct name.

If in any case vpackager fails to pick up the name and version parts of the string, the source will not even untar.

Now, once it untars, it needs to cd to the source dir.

of course if vpackager untarred liferea-1.2.15b, it will try to cd to /tmp/liferea-1.2.15b. which is why it's failing.

Title: Re: Package builder utility
Post by: blurymind on May 30, 2007, 08:12:50 am
oh,i didnt notice... it seems that the problem with Lives is the same?

ok,then if its not a common problem,Moe shouldnt try to fix it. Its the packager/developer's fault.


The only other problem i see is the generating of "broken" (empty) tlz packages when configure or make fails. Is there a way to detect that something didnt went fine and tell the user,or color keywords such as "not found" or "no" , "error" ,etc in red? Hint the user if it worked or not.

Maybe check if in the /tmp directory where the package was build,to see if its size is bigger than 1kb before asking the user where to move it...

empty tlz packages are 291b big, empty tgz packages are 954b big (both less than a kb)

If the script finds out that the package is empty,instead of asking the user where to move it, tells the user that something went wrong and to look at the log file carefully.
Title: Re: Package builder utility
Post by: M0E-lnx on May 30, 2007, 08:25:22 am
As far as I can tell, there is nothing I can do here... Except hope that the developer uses common-sense when compressing their source.

As far as the empty package thing goes, I can't promise colors on the output. However, I've added a status label at the bottom. In the next release, this label will let the user know if an error has ocurred. The process will also abort if the configure or make fail, and the label will tell you.

Also, as a security measure, the next button will be disabled if the process fails for any reason.
Thanks for pointing that out. I had completely left that out of the equation.
Title: Re: Package builder utility
Post by: blurymind on May 30, 2007, 08:37:03 am
As far as I can tell, there is nothing I can do here... Except hope that the developer uses common-sense when compressing their source.

As far as the empty package thing goes, I can't promise colors on the output. However, I've added a status label at the bottom. In the next release, this label will let the user know if an error has ocurred. The process will also abort if the configure or make fail, and the label will tell you.

Also, as a security measure, the next button will be disabled if the process fails for any reason.
Thanks for pointing that out. I had completely left that out of the equation.
is it possible to determine if they fail? I thought that the filesize check was the only way to be sure if the package is a proper one.
Don't disable it for now.It might be possible that the error-check goes wrong and even if the package compile went fine,vpackager to think that its broken and not want to package it... :-\  ( *me just being afraid of possible bugs with the checking for errors system* )
Title: Re: Package builder utility
Post by: M0E-lnx on May 30, 2007, 08:44:59 am
Yes, it is absolutely possible to determine if the process has failed.

To accomplish that, I have written the backend script in a way that will allow gambas to determine if the process has failed.

After the build process has stopped, Gambas analizes the output, looking for keywords or strings (error, "source not found", "Failed!", etc)

If any of those are present in the output, it means it will be a bad package, which is why I've disabled the next button, so that the user doesn't get the impression that the package has built correctly. The status label will also keep the user informed.
Title: Re: Package builder utility
Post by: blurymind on May 30, 2007, 09:47:23 am
idk, in future builds it would be great if the user has control over the error-check somehow...just in case..

to enable/disable or pick
*tlz/tgz file size check  => message "The package seems to be empty,something went wrong...")
*smart error check => the message(s) that show errors highlighted or shown somehow...

there is no system that can be sure, the second one -can it be done 100% accurate?
Title: Re: Package builder utility
Post by: M0E-lnx on May 30, 2007, 10:30:28 am
Well, I've modified the backend so that if it fails, no package will be created at all.

Now, if anyone plans on submitting packages built with this up to the repos, I recommend you test the package yourself first to make sure everything is right before you upload it as you would if you were to build the package manually.

Fix .desktop files if necessary, and things like that.

The error control thing could be implemented in the future, along with some kind of settings/profile control that allows the user to set up settings and preferences (packager id, default package output directory, and things like that)

But for now, I'm interested on getting the build process to complete right. If there is errors, abort the whole thing and in any case, inform the user.

I'm not sure this could ever be 100% accurate, but there is certainly room for expansion (add support for building python apps, etc)
Title: Re: Package builder utility
Post by: blurymind on May 30, 2007, 11:12:15 am
as it is,if it fails,it just creates an empty package,which is pretty obvious to spot.  ;D
I test about every single package i ever build with this,makepkg or checkinstall. ;)

The packages that i picked to test were hard to build and dont spit out obvious messages when there is something wrong at the end, only checkinstall dont wants to package them after configure and make went without saying much. I did it to see what will vpackager do with them.

As for the desktop files,I think it would be pretty simple to implement somehow in vpackager, its worth having- it is a pain to write proper .desktop files and link them with a proper xpm :-\ ...Maybe without autoresizing/converting,because that will have a imagemagick dependency.

But in any case, to add a desktop file,one must explodepkg,add the desktop file and the icon,and then makepkg it again.This changes user permisions over the directory where its done,so the user has to erase them as root later.

Most applications that are gui and need a desktop file,have a desktop file and an icon...but yet again-there are so many that dont.
Title: Re: Package builder utility
Post by: M0E-lnx on May 31, 2007, 08:43:45 am
OK.. Here comes 1.0beta3

I've added better 'error awareness' and moved a couple of things around.

Thake this one for a spin.

Now available via slapt-get

Here is the change log
http://m0e.lnx.googlepages.com/vpackager_changelog
Title: Re: Package builder utility
Post by: blurymind on May 31, 2007, 09:49:55 am
This one seems to have a better error detection. Only one thing...

(http://xs215.xs.to/xs215/07224/notshow-vlpbu2.jpg.xs.jpg) (http://xs.to/xs.php?h=xs215&d=07224&f=notshow-vlpbu2.jpg)

It doesnt show everything thats written in the console. When you manually run configure from console, when it finds error, it tells you a little bit about the problem...When vpackager finds the error,it instantly cuts off that text and prevents it to be shown:
this text
Code: [Select]
configure: error:

 txt2tags cannot be found on your system, but tovid needs it to build
 the man pages. Please install txt2tags (http://txt2tags.sf.net) and
 run ./configure again. Thanks!

     -- http://tovid.org

great work....i'll need some time to get used to the new main window layout tho...

A screenshot for everybody who wants to see how vl-pbu looks like:
(http://xs215.xs.to/xs215/07224/vlPbub3.jpg.xs.jpg) (http://xs.to/xs.php?h=xs215&d=07224&f=vlPbub3.jpg)

there is too much unused space under the "packager id" [] clean up  line ... i think you will save much space if you move the start button next to the quit button and the package name and version namber right back up where it was.. ::)
Title: Re: Package builder utility
Post by: M0E-lnx on May 31, 2007, 10:30:44 am
Yeah, after messing with the layout for a bit I got a little confused myself.

But that could change even in the future.

As far as the errors go, I guess I'll need to spend some more time with it so I can get it to display the error details too.

I had it displaying all the errors, but the problem with that is that it was throwing the error message at the beginning of the std output and not at the end or wherever the error occurred. But that was in gambas2, I'll need to try that in gambas1 and see what happens

For now, the important thing is that if it fails, then you wont end up with an empty package. It'll probabbly be longer before I can start working on it again. I'm in the process of backing up my data getting ready to do a major upgrade. After that's done, I'll continue the quest
Title: Re: Package builder utility
Post by: blurymind on May 31, 2007, 12:42:02 pm
you've done a great job with this utility.  ;D
Title: Re: Package builder utility
Post by: M0E-lnx on May 31, 2007, 01:14:58 pm
It's really kool, and I happen to like gambas. In the future, I may switch the project to gambas2, and add even more features. In the mean time, the general idea is already working.

You point, click, select source and out comes a package. I think it's really kool, not too bad for my first serious gambas project.

Hope I can do a lot more in the future.
Title: Re: Package builder utility
Post by: exeterdad on June 03, 2007, 10:16:08 pm
Back to the LiVES extraction.

Couldn't you generate a random number, then
Code: [Select]
mkdir /tmp/$RANDOMNUMBER.
Code: [Select]
tar xfv LiVES-xxx /tmp/$RANDOMNUMBER
Then
Code: [Select]
FOLDERNAME=`ls /tmp/$RANDOMNUMBER` to find out the name of the folder, then make your cut?

Extracting to a unique folder would make it possible to find the foldername of the extracted package.

Just a thought  :)
Title: Re: Package builder utility
Post by: M0E-lnx on June 04, 2007, 05:58:52 am
I guess that could work, but it would make one ugly tmp dir. I'll try something like that in the next release
Title: Re: Package builder utility
Post by: exeterdad on June 04, 2007, 08:42:52 am
I guess that could work, but it would make one ugly tmp dir. I'll try something like that in the next release


You're right I didn't think about how messy it would look.  And not so "human readable" for the user.

This will get it done:
Code: [Select]
#!/bin/sh
FOLDERNAME=`tar -tf LiVES-0.9.8.5.tar.bz2 | head --lines=1`
echo $FOLDERNAME

lists the files in archive and pipes to head and reads first line.
This is the output of the above:
Code: [Select]
lives-0.9.8.5/

I didn't filter off the trailing slash as it may be useful in your code.
Title: Re: Package builder utility
Post by: M0E-lnx on June 04, 2007, 09:16:17 am
The problem with this is that the name splitting is done in gambas, while the untarring and building / packaging is done in bash. Here is the sequence of events:

User selects source
  |__ Gambas splits the name to determine app and version #
       |__ Gambas calls the bash script with specifying (with flags) the app and version (for package name)
            |__ the script tries to cd to /tmp/$APP (Gambas tells the bash script what $APP will be in each case)

I'm not sure how that would work... because if gambas says it's "LiVES" then "LiVES" it is to the bash script.
I can easily have it extracted to a dir created based on like a date/time scheme, that way dir names will be unique and no need to random anything.
But it would make one ugly /tmp dir unless I create a /tmp/vpackager-builds/<date/time-named-dir> or something like that
Title: Re: Package builder utility
Post by: blurymind on June 05, 2007, 09:13:37 am
forget about that dir problem.The way it handles archives now is perfect.


Feature request:

*scons support
*the ability to open tlz/tgz files and edit their slack-required and slac-desc files.(this should require a sepparate window)
Title: Re: Package builder utility
Post by: M0E-lnx on June 05, 2007, 10:57:16 am
I'm not sure about scons.... Never built anything that needs it, so I have no idea how it works...
Unless I can get some input from prople who have used it, how it works, and maybe a (unique?) way to find out if an app needs it or not.

The ability to open tlz/tgz and edit their slack-desc and required files would be nice I guess... This could also make room for the implementation of a .desktop file writer (maybe not a generator, but a simple tool that would let you write the file, and place it in the right location)
Title: Re: Package builder utility
Post by: Triarius Fidelis on June 06, 2007, 06:43:11 am
I've been kind of lurking this thread and there are two things that come to mind. First of all, I'm very proud of you, M0E, for putting vpackager together. The other thing I notice is that I must be missing out on the advantages of Gambas. I could come to terms with the static binding (dealt with them in C, C++, and Java to different degrees so far), but for some reason the rest of it just doesn't 'click'. I've recently had some success with the designer Not sure what to do here...there is only so much documentation for Gambas, so I wonder how much VB documentation would carry over. :-\
Title: Re: Package builder utility
Post by: Triarius Fidelis on June 06, 2007, 07:05:19 am
I'm not sure how that would work... because if gambas says it's "LiVES" then "LiVES" it is to the bash script.
I can easily have it extracted to a dir created based on like a date/time scheme, that way dir names will be unique and no need to random anything.
But it would make one ugly /tmp dir unless I create a /tmp/vpackager-builds/<date/time-named-dir> or something like that


The ugliness of the /tmp dir created isn't such a problem at all, because the user shouldn't see it. If you don't believe me, look at some of the names that KDE services---KDE being a very well-planned software package---leave behind. :P

What I'd really be worried about is the permissions for the temp dir. I searched in the Perl code for File::Temp, and when it creates a temporary directory, it sets the permission to 0700. If that's not in the utility anywhere, it'd be a good idea.
Title: Re: Package builder utility
Post by: M0E-lnx on June 06, 2007, 08:19:07 am
I've been kind of lurking this thread and there are two things that come to mind. First of all, I'm very proud of you, M0E, for putting vpackager together. The other thing I notice is that I must be missing out on the advantages of Gambas. I could come to terms with the static binding (dealt with them in C, C++, and Java to different degrees so far), but for some reason the rest of it just doesn't 'click'. I've recently had some success with the designer Not sure what to do here...there is only so much documentation for Gambas, so I wonder how much VB documentation would carry over. :-\

That is true... there is not a whole lot of documentation for gambas, and the user community must be small, because the forums dont have too many users either. I'm not sure you can carry much VB documentation over to gambas, however, if you know or have fiddled with VB in the past, there is a good change you'll pick it up right away.

I mean, I only fiddled with VB for a bit late last year, read a lot of it's documentation, and followed a couple of on-line sessions, then when I moved to gambas, everything made almost perfect sense. This may be because I didn't dig that deep into VB to get into all the technical stuff... but having some VB knowledge does help... Besides, I tried C++ some time ago, Gambas is so much easier.

About the tmp thing, vpackager doesn't really create the tmp dir, it just as if you did this
Code: [Select]
# cd /tmp && tar xfv $SRCthat will of course result in a new dir in /tmp.

Not sure what permissions that new dir will enherit, but I would assume something like read-only for normal users and full access for root (because root is running the app, so root is really untarring the source).
Let me know if I need to change this somehow.
Title: Re: Package builder utility
Post by: Triarius Fidelis on June 06, 2007, 09:02:37 am
I've been kind of lurking this thread and there are two things that come to mind. First of all, I'm very proud of you, M0E, for putting vpackager together. The other thing I notice is that I must be missing out on the advantages of Gambas. I could come to terms with the static binding (dealt with them in C, C++, and Java to different degrees so far), but for some reason the rest of it just doesn't 'click'. I've recently had some success with the designer Not sure what to do here...there is only so much documentation for Gambas, so I wonder how much VB documentation would carry over. :-\

That is true... there is not a whole lot of documentation for gambas, and the user community must be small, because the forums dont have too many users either. I'm not sure you can carry much VB documentation over to gambas, however, if you know or have fiddled with VB in the past, there is a good change you'll pick it up right away.

I mean, I only fiddled with VB for a bit late last year, read a lot of it's documentation, and followed a couple of on-line sessions, then when I moved to gambas, everything made almost perfect sense. This may be because I didn't dig that deep into VB to get into all the technical stuff... but having some VB knowledge does help... Besides, I tried C++ some time ago, Gambas is so much easier.

It's interesting what kinds of optimizations C++ makes to run efficiently, but some of it really just sucks. Objective C is better in many respects (although it has nowhere near as many libraries), because the object model is much simpler (based largely on Smalltalk!!) and doesn't sell out completely. It does late binding by default, for instance.

About the tmp thing, vpackager doesn't really create the tmp dir, it just as if you did this
Code: [Select]
# cd /tmp && tar xfv $SRCthat will of course result in a new dir in /tmp.

Not sure what permissions that new dir will enherit, but I would assume something like read-only for normal users and full access for root (because root is running the app, so root is really untarring the source).
Let me know if I need to change this somehow.

I think it might be a good precaution to limit it to root, and set the permission to 0700. It can't be much code at any rate.
Title: Re: Package builder utility
Post by: M0E-lnx on June 06, 2007, 09:59:03 am
It's not really.. So you're suggesting to chmod 0700 /tmp/$APP-$APP_VER ??
Title: Re: Package builder utility
Post by: Triarius Fidelis on June 06, 2007, 10:04:32 am
It's not really.. So you're suggesting to chmod 0700 /tmp/$APP-$APP_VER ??

Ya. Can't hurt at any rate. I'll see if I can finally grok Gambas this time, and have a look at the source code myself...
Title: Re: Package builder utility
Post by: M0E-lnx on June 08, 2007, 08:58:45 am
Ok.. Here is the latest on the development:

I Have implemented the requested features (including the chmoding of the build dir).

I am now in the process of building a "Preferences" window to store a couple of default settings
So far these include
I kind of need some help in the last one. I do not wish to start a war as to which text editor is better, but rather I'd like to get the user's input on choices
As of now, I have listed

The whole idea behind a text editor selection is because I will add the ability to explore the contents of an existing package, at which time the user will have the ability to edit the slack-desc and .desktop file in the package using the selected text editor. Then we would put the package back together.

Shoot away
Title: Re: Package builder utility
Post by: lagagnon on June 08, 2007, 09:05:32 am
I would suggest including only those text editors which come pre-installed with either Standard or SOHO. So that would include mousepad, mcedit, vim, kedit, ???
Title: Re: Package builder utility
Post by: Triarius Fidelis on June 08, 2007, 09:22:52 am
Why not just allow the user to type in any pathname, then follow it up with the file?

For instance, I wouldn't want another instance of Vim to start running when one has already started. To that end, I would tell the package to use 'vim --servername server --remote'
Title: Re: Package builder utility
Post by: M0E-lnx on June 08, 2007, 09:24:51 am
Well, The general idea is what Lagagnon said, the ones that ship with the VL releases should be in the options, but I also have an option for other. When the user clicks other, a dialog appears, and allows the user to select their own.

EDIT:

BTW, should I offer the option to edit the slack-required file? ... I know this could be dangerous
Title: Re: Package builder utility
Post by: blurymind on June 09, 2007, 09:58:28 am
YES!

This utility is evolving really nicely,making packaging and editing of packages a easier,less time consuming task!

Editing the slack-desc file is a needed feature if you ask me,but its needed for tlz packages that were created by makepkg procedure (no configure and make)... Some apps under linux that are written in python can't be packaged by vpackager,but vpackager can have the powerful feature ,give the ability to the user to write a slack-required file and put it inside,without the need to explodepkd and makepkg again and again just to fix a typo. ( what i had to do with my last packages - fontpage and acetoneiso ).... so here my feature requests:

packageeditor should be a sepparate module of vpackager. Can you make it that,the user who starts vpackager,starts it only to package stuff,not to edit packages...no clutter with buttons that have nothing to do
with the main thing.Just include it in the file> menu,above the "quit" option)
So make package editor a sepparate module of vpackager,that can be called to open a package,just by opening the package.tlz file with it (no browse for package buttons and dialogues)
Quote
vpackage-edit packagename.tlz
...
Vpackage-edit could be called from vpackager's file>edit a package menu....but it should be able to directly open tlz files with it...

and it should have the following features:
*directory listing of files inside the package (showing the dirs and the files inside)
*check if package has a proper slack-required and slack-desc  file (not a must,but a sweet feature) and "slack-required" and "slack-desc" butttons that will open the files for edit, since they are always in install folder.. maybe slack-desc button could call the slack-desc editor that vpackager already has. This way the user could easily change whats written in the description,in case there are typos or old information that is absolete (old website url,wrong license,etc etc)
and if there is no slack-desc or slack-required file found inside,the user could write one (a very important feature)
*cancel,quit and apply changes buttons at the bottom =P (it will have to uncompress the package first,before the user can edit and put stuff inside,right?) Apply button should package it again and overwrite the original file.
*the ability to import file in the package (in any of the dirs it has)
*the ability to edit files (slack-required) with a text editor (i vote for mousepad,since its the fastest,but this can also be done with the preferences window,where the user can just type the command which is for the text editor,and not chose from a list or anything)...when opening a file inside the package,the user should have the ability to change it and overwrite the old file...

*the ability to create a package with makepkg out of any directory that the user choses. (maybe this could be sepparate from vpackage-edit,but it can use it --- include the option "make package from folder" in vpackagers file> menu)

the ability to import files and delete files in a package is priceless for managing packages that can't create a slack-required file and the user must write one!

Anyways,i really think that this will deliver a great support for packages that dont build with the standart procedure. Then they can be installed with a prefix to a given dir and then packaged and a slack-required file could be written for them easily.  :-*

...please don't change the way it uses the tmp directory.Its not broken,dont fix it, plus its easier for the packager to find and open the slack-desc and slack-required file of the package he/she made, so its easy to copy and paste at the forum.
Title: Problems with package builder utility so far
Post by: caitlyn on June 10, 2007, 12:30:06 pm
I haven't read every post in the thread so there may be some duplication.  My apologies in advance if that is the case.

My overall impression is that this is a wonderfully thought out and well designed tool that will eventually be a great addition to VL, but... the version currently in the testing repository is nowhere near ready for prime time.

Problems:

1.  Adding an existing slack-desc file:  it looks for slack-dec instead.
2.  Save package to non-standard directory still doesn't work.
3.  Most serious:  Error handling (i.e.: failed dependency) is pretty much not there at all.

I deliberately tried the gnumeric 1.7.10 compressed tarball knowing full well that I hadn't installed the new version of goffice.  Instead of telling me that the configure script had failed it told me that the package was built.  (Not true, of course.)  No output or error message was saved.  I don't know about anyone else but IME not all developers accurately or completely detail dependencies.  This sort of error is the one I run into most when building a new package.

One other thought:

Choice of build options is default or custom.  A third choice should be VL standard.  IMHO that should include --prefix=/usr and --with-included-gettext.  The latter builds gtk2 and GNOME apps with full multilingual support.  Very few configure scripts will actually fail if that is included but not supported (there are a few, though).

I consider vlpackager very promising and I congratulate the developers for bringing it so far along already.  It just needs a bit more work before I'd actually consider using it regularly.

Thanks,
Cait
Title: Re: Package builder utility
Post by: blurymind on June 10, 2007, 01:32:36 pm
i too found a bunch of errors.

you specified some but...

First of all,the save package to alternative directory WORKS for me.
and i build a few packages and it always stopped when some dependency wasnt satisfied,but it didnt spit the error message as in the console..

the error:
*when i click on next,without specifiing a package, the message "no source package" just keeps on popping out countless times and i cant close the window at all.Instead the error message keeps popping out.




Title: Re: Package builder utility
Post by: M0E-lnx on June 11, 2007, 05:55:52 am
@ Caitlyn:

The slack-desc thing is intended that way. You are given 2 options, One, pick out an existing slack-desc file, or create a new one.

The other 2 issues on your list have been fixed (but I still haven't uploaded a new revision to the repos).

About the build choices, I consider it unnecessary to include any custom build options and call them "default for STD", which is why I included the ability to add these when you click on the custom build.

@ blurymind

Your issue has alson been fixed. The save package window and functions have been re-done, everything should work a lot better now.

This is where it currently stands.

The package editor tool will be available from the menu, of course the user will browse for a package (no command line tool here) after that, you'll be able to edit the slack-desc and .desktop file.

I'm not sure editing the slack-required would be such a safe feature, because this could lead to bad packages.

I'm curious, why would you want to add other files to an existing package? ... It may not be a bad feature, but I wouldn't want to turn this into a file manager

Will be uploading a new version soon
Title: Re: Package builder utility
Post by: blurymind on June 11, 2007, 06:16:03 am
my intention is to edit packages that i've created with makepkg...packages like acetoneiso or fontpage and many other python apps that use a simple copy to dir install script and dont go through the standart configure and make procedure that vpackager uses.

Some apps that are like so need other packages to operate,but their install script doesnt look for the dependencies or create a slack-required file. Of course a naturaly created slack-required files doesnt need to be edited.When there is no slack-required file (for the packages created by using makepkg to put all thats needed),one must write one, so whenever someon installs it,he or she wouldnt have to bother looking for a README file to find out why its not working and what has to be installed. ::)

look at the site gnomefiles.org
Most of the stuff there,written in python can only be installed by a install script that just copies the files where needed (the one thing that a tlz package can do as well)
...
they usually say what needs to be installed in the README file. I dont want the casual user to have to bother with that,when a tlz package is capable of doing it automagically.
Title: Re: Package builder utility
Post by: M0E-lnx on June 11, 2007, 06:23:11 am
I do plan on adding support for python apps later on, so eventually vpackager may be able to create a package out of a python source tarball. But I would have vpackager run the install script and package the stuff. There is ways to do this, just need to get them in there.. for now, I'd like to get the current phase working right before I move on to more features.
Title: Re: Package builder utility
Post by: blurymind on June 11, 2007, 07:02:00 am
alot of the apps have completely different install scripts,named differently.
Title: Re: Package builder utility
Post by: Joe1962 on June 11, 2007, 07:03:24 am
I find I need to tweak most packages. Stuff like adding different .desktop files for KDE and XFCE, deleting duplicate documentation, or even the documentation sources, retouching the dependencies, adding a slack-suggests ot slack-conflicts, etc, etc...
Title: Re: Package builder utility
Post by: M0E-lnx on June 11, 2007, 07:11:24 am
Would it be enough to explode the package and open a file manager to the location?

or do I need to do anything more than that?
I figure, If I get it to do that, then you can pretty much do whatever you need from there... add/remove contents, move thigns around, edit files, etc.
Title: Re: Package builder utility
Post by: blurymind on June 11, 2007, 07:34:24 am
well,you could do that,but some things can be automated to save time:

*check if in the install directory there are slack-required and/or slack-desk file
if not promp user to create them,opening mousepad or vpackager's slack-desc editor!
*Check for the presence of a *.desktop file, it can also be automated for editing...
*even if there are have the ability to open them directly without the need to navigate..
*list the contents of the package in one list and the number of files. (no need to browse)
...

=========EDIT===================
VVVVVV

a *.desktop creator could eliminate human mistakes that the user could make (specify a png/pixmap icon and give it wrong name in the desktop file,thus it wouldnt show in the start menu when installed)

...orr the mistake to type a wrong cathegory name,so it might not show in the start menu at all.. ( a drop down menu could fix that and would be very neat) :P

lol,this might look like a little too much,but some non-gui applications wouldnt need a desktop file at all,so the user should decide whether its needed or not.... maybe this package-explorer can be included as an option in the Save package window,so the user could examine the package before saving it... :-*

there is also the question after exploring and adding something,how will it be tlz-ed again. Makepkg?
Title: Re: Package builder utility
Post by: Triarius Fidelis on June 12, 2007, 12:30:22 am
M0E, where is the original source for vpackager? The tlz just has the bytecode.

Something else I noticed after running vpackager is that Gambas was unable to free a significant amount of memory after every run. Apparently, there is a cyclic reference in Form1, and it would seem that the Gambas runtime has only a reference-counting based GC. >:(

(which can also be said of Perl, btw...)
Title: Re: Package builder utility
Post by: easuter on June 12, 2007, 03:19:24 am
I think the problem with the memory not being cleared in Gambas is when the app is closed using QUIT.
I've found that if you close the startup form, or the first form that is opened, then the rest of the forms opened after that will close too, and in a clean manner.
QUIT terminates the app abruptly and leaves a mess behind, while for example Form1.Close will close the Form1 form and any others "gracefully" and the Gambas interpreter will clean out used memory.
Title: Re: Package builder utility
Post by: M0E-lnx on June 12, 2007, 06:03:33 am
I always wondered about that... but I thought there was no way around it... thanks easuter ;)
Title: Re: Package builder utility
Post by: caitlyn on June 12, 2007, 09:49:24 am
Quote
The slack-desc thing is intended that way. You are given 2 options, One, pick out an existing slack-desc file, or create a new one.

I think you misunderstood me.  When it looks for an existing slack-desc file it wants one with the incorrect name slack-dec, missing the 's' in desc.  It looks like a typo in the code.  Otherwise the functionality is just fine.

Quote
The other 2 issues on your list have been fixed (but I still haven't uploaded a new revision to the repos).

Great to hear!  I'll try it again as soon as the new version is posted.

Quote
About the build choices, I consider it unnecessary to include any custom build options and call them "default for STD", which is why I included the ability to add these when you click on the custom build.

I don't and I'll tell you why:

1.  --prefix=/usr is a standard according to the docs.  A lot of packages build into /usr/local or /opt or /usr/local/games or other interesting and non-standard places.  It's nice to keep to a standard.  Some new package builders may not realize they have to specify this.

2.  --with-included-gettext  Without this you don't get full internationalization/localization.  The original package of Xfce 4.3.99rc2 wasn't built this way and only provided menus, help, etc... in a few languages.  the 4.4.0 build done by vector has full support.  This has been discussed in the fora often enough and I know a lot of developers and packagers have taken it to heart, but... if we want VL to be truly international we need it included in all package builds that support it.  Most of my family lives overseas and I am multilingual so this is near and dear to my heart.

The choices I would have:

-developer default
-VL default (or) VL standard
-custom

You, of course, may still disagree.

All the best,
Cait
Title: Re: Package builder utility
Post by: M0E-lnx on June 12, 2007, 09:56:18 am
Quote
The slack-desc thing is intended that way. You are given 2 options, One, pick out an existing slack-desc file, or create a new one.

I think you misunderstood me.  When it looks for an existing slack-desc file it wants one with the incorrect name slack-dec, missing the 's' in desc.  It looks like a typo in the code.  Otherwise the functionality is just fine.


[/quote]

You are absolutely right... that is a typo in the source code... I just noticed, thanks.

as for the build options, I'll break a deal with you, I'll another option, but it will default to "Default" which means "--prefix=/usr --sysconfdir=/etc" only.
Then, there will be the 5.8 STD or (need naming) option with your suggested configure scheme.

I'd just hate to get complaints about things that dont build using the "default" choice on my app, because if anything, a default action *should* work.
In this case, it may not be true 100% of the time, because the build depends on more than just the configure options passed to the shell, but also on dependancies, and correct paths and things like that... but I'll put it on there. There is plenty of room for expansion in this project.
Title: Re: Package builder utility
Post by: blurymind on June 12, 2007, 10:35:24 am
i vote to keep the configure at the package's default always! If a packager knows its supposed to be a kde app,he/she would use the proper prefix...If the packager is to add configure options,he or she will have to type them her/himself...and vpackager shouldnt add configure options that are supposed to be default without showing it. :-\

Maybe for lazy packagers you cauld make it remember the last typed configure custom options and finish the text or something.
Title: Re: Package builder utility
Post by: M0E-lnx on June 12, 2007, 11:01:20 am
In that case, I can add them to the "settings" and the user can chose to always build in a certain way, but then again, that doesn't sound right to me, because configure options will most likely vary from one package to another
Title: Re: Package builder utility
Post by: blurymind on June 12, 2007, 11:04:02 am
In that case, I can add them to the "settings" and the user can chose to always build in a certain way, but then again, that doesn't sound right to me, because configure options will most likely vary from one package to another
i agree...this seems like a bad idea...Maybe the user could use configure profiles,created by him/her in yet another settings window? I dont think this is a die-for feature.
Title: Re: Package builder utility
Post by: Triarius Fidelis on June 12, 2007, 11:04:47 am
Virtually all ./configure runs are --prefix=/usr --sysconfdir=/etc.

It's a good default to go with. If packagers have to choose otherwise (e.g., /opt/kde), they'll have to know it anyway.
Title: Re: Package builder utility
Post by: M0E-lnx on June 12, 2007, 11:12:15 am
Virtually all ./configure runs are --prefix=/usr --sysconfdir=/etc.

It's a good default to go with. If packagers have to choose otherwise (e.g., /opt/kde), they'll have to know it anyway.

Agreed!  ;)

Which exactly why I had only limited them to "default" and "custom" where the custom option will let you pass any config flags you want
Title: Re: Package builder utility
Post by: blurymind on June 12, 2007, 11:31:54 am
Virtually all ./configure runs are --prefix=/usr --sysconfdir=/etc.

It's a good default to go with. If packagers have to choose otherwise (e.g., /opt/kde), they'll have to know it anyway.

Agreed!  ;)

Which exactly why I had only limited them to "default" and "custom" where the custom option will let you pass any config flags you want
which is perfect  :P

sry,no spamming from me

feature request idea:
option to Send to tray while its compiling.
Title: Re: Package builder utility
Post by: caitlyn on June 12, 2007, 11:41:54 am
I agree with the two default options that have been suggested since, as has already been pointed out, most every package should be built that way (with KDE as the obvious exception).

The --with-included-gettext applies to most all gtk2 and GNOME packages and is VERY important in my view.  If it's not included in the configure options (will cause rare but real failures) then it at least needs to be documented somewhere rather prominently both in the package help and in the package building HOWTO, IMHO. 

One of the negative (as in "Vector sucks") replies I got to my review for O'Reillynet was because Danish wasn't supported.  If we had built everything --with-included-gettext then Danish translations would have been included in Xfce, AbiWord, Gnumeric, and most all of our other popular apps in VL 5.8 Standard.

I guess what I am asking for is a way to make all packagers aware of this issue.  Americans are notoriously monolingual and too many think the whole world should just speak English.  Since this is a Canadian distro I kind of expect a higher level of concern coming from an officially bilingual country.

Thanks,
Cait

Title: Re: Package builder utility
Post by: easuter on June 12, 2007, 11:44:00 am
It would be nice if --with-included-gettext could be added as a default flag. If vpackager is going to be used to build packages for the repo, then that flag will make sure that GTK apps will have proper internationalization support.

I have that flag as a default in my build scripts and so far it hasn't interfered with building anything non-gtk, so its not a "danger" to have it as a default I guess...

EDIT: beat me to the post caitlyn  ;)
Title: Re: Package builder utility
Post by: Triarius Fidelis on June 12, 2007, 11:49:14 am
The --with-included-gettext applies to most all gtk2 and GNOME packages and is VERY important in my view.  If it's not included in the configure options (will cause rare but real failures) then it at least needs to be documented somewhere rather prominently both in the package help and in the package building HOWTO, IMHO.

I hate to admit this, but I didn't know about --with-included-gettext before.
Title: Re: Package builder utility
Post by: easuter on June 12, 2007, 11:52:30 am
Quote from: blurymind
feature request idea:
option to Send to tray while its compiling.

I don't think thats possible with Gambas 1.0.x
Title: Re: Package builder utility
Post by: Triarius Fidelis on June 12, 2007, 11:54:18 am
Yeah dude.

You can only expect so much. :)
Title: Re: Package builder utility
Post by: caitlyn on June 12, 2007, 11:56:07 am
hanumizzle:  I didn't know about it either until I started working on Hebrew support for VL 5.8.  I wanted to know why Ubuntu's version of Xfce had Hebrew menus and VL's didn't.  I researched the issue and... well... now y'all are stuck with me and my meddling.

-Cait
Title: Re: Package builder utility
Post by: blurymind on June 12, 2007, 11:58:48 am
Well, I'd say that it would be nice if we have documentation written for vpackager that has this information.

Vpackager should always use the package's defaults, so if a configure option is added,the user should know it,see it,have the freedom to edit it...
Maybe in future versions we could have configure profiles that the user could create and choose from the drop down menu (default,configure profile,custom)... and have profiles in the list of custom profiles as default.

Default custom profiles that can be included in vpackager could be:

kde app :  --prefix=/opt/kde
gnome app:  --with-included-gettext
games: --prefix=/usr/games
etc etc... this is yet another sweet feature,i guess

....but that calls for more entries in vpackager's settings file and another settings window ( configure profiles editor?)
about the tray... yeah i expected to hear that.. :( i knew it
Title: Re: Package builder utility
Post by: Triarius Fidelis on June 12, 2007, 12:00:31 pm
hanumizzle:  I didn't know about it either until I started working on Hebrew support for VL 5.8.  I wanted to know why Ubuntu's version of Xfce had Hebrew menus and VL's didn't.  I researched the issue and... well... now y'all are stuck with me and my meddling.

-Cait

Very observant of you then. Glad you found it.

Shalom...
Title: Re: Package builder utility
Post by: easuter on June 12, 2007, 12:04:10 pm
Quote from: blurymind
kde app :  --prefix=/opt/kde
gnome app:  --with-included-gettext
games: --prefix=/usr/games

The thing is that the --with-included-gettext option is NOT only for GNOME. Its valid for just about all GTK apps, including Xfce for example.
And like I said before, using it on non-gtk apps doesn't seem to create any disturbances in the build process, so there should be no problems having it as a default.
Title: Re: Package builder utility
Post by: M0E-lnx on June 12, 2007, 12:08:23 pm
Ok... I feel like i'm outnumbered here, so I'll add it on as default for the next release...
Title: Re: Package builder utility
Post by: caitlyn on June 12, 2007, 12:15:18 pm
Quote
The thing is that the --with-included-gettext option is NOT only for GNOME. Its valid for just about all GTK apps, including Xfce for example.

Even some non-gtk apps use it now.

Quote
And like I said before, using it on non-gtk apps doesn't seem to create any disturbances in the build process,

I have had it cause the configure script to fail exactly once.  I don't remember what I was building at the time but it can happen in rare cases. 

Quote
so there should be no problems having it as a default.

You're mostly right but it's not quite 100% which is why I suggested a separate option. So long as, in the rare case where it does cause a problem, the user can disable it within vpackager (i.e.: using custom build options) then I agree it shouldn't be an issue.

I realize this may be seen as taking a devil's advocate position as I am the one who is so all fired up about having it, but... I do want Moe-lnx to have all the facts, not just a bunch of us shouting at him :)

Thanks,
Cait
Title: Re: Package builder utility
Post by: M0E-lnx on June 12, 2007, 12:25:31 pm
At the end of the day, this is always good for development...

Of course, it's impossible to get all the functions implemented in one shot, so bare with me.

Title: Re: Package builder utility
Post by: easuter on June 12, 2007, 04:41:33 pm
Oh! just one more :P:

--mandir=/usr/man

That is the Slackware prefix for all manpages. Debian and others use /usr/share/man, which is normally what the configure scripts use by default...
Title: Re: Package builder utility
Post by: Joe1962 on June 12, 2007, 05:59:20 pm
Quote from: blurymind
feature request idea:
option to Send to tray while its compiling.

I don't think thats possible with Gambas 1.0.x
No, it is possible in Gambas 2, but was buggy last time I tried it$.
Title: Re: Package builder utility
Post by: blurymind on June 13, 2007, 01:30:14 am
ok,but is it possible that the packager could disable --with-included-gettext when the build fails...vpackager should give 100% control over the user. Maybe at its settings window have enable/disable recomended configure options.... with something written when you move the cursor over it "( [ --with-included-gettext  --mandir=/usr/man ] this should be enabled by default. If you get an error message that has to do with it at configure,disable it"
Title: Re: Package builder utility
Post by: M0E-lnx on June 13, 2007, 05:47:46 am
IMO, that would be a little too much. Let's not forget that not all apps will build with this anyway, so I think it should include only a couple of building profiles, anything after that, or a re-attempt can be done using the "custom" option.

EDIT:
Just uploaded 1.0beta4
New features include:
+ Package editor
+ Stand-alone slack-desc writer
+ Settings panel.
The mentioned bugs have been squashed.

Test away
Title: Re: Package builder utility
Post by: blurymind on June 14, 2007, 05:02:06 am
very good ...

I like the package editor.there are some bugs to squash and some other things to iron out.

Bug report:
Package editor- when i click on "edit slack-desc" i get
Code: [Select]
sh: /usr/bin/medit: No such file or directory
I like the browse contents button.

The "done" button should say "repackage" or something like that..
The exit button should be clickable even before a package has been selected.
Title: Re: Package builder utility
Post by: Joe1962 on June 14, 2007, 05:12:56 am
M0E-lnx: why not just cook up your own simple editor in Gambas, there are examples and such around. That way you can preset a fixed-width font to make things easier with slack-desc.

EDIT: Plus you can be sure it will always be there... ;)
Title: Re: Package builder utility
Post by: blurymind on June 14, 2007, 05:18:52 am
M0E-lnx: why not just cook up your own simple editor in Gambas, there are examples and such around. That way you can preset a fixed-width font to make things easier with slack-desc.

EDIT: Plus you can be sure it will always be there... ;)
is it possible to use the one that vpackager already has (slack-desk editor)? I think it does its job very well. Plus if you think of writing a new editor,why not make a *.desktop editor?
Title: Re: Package builder utility
Post by: M0E-lnx on June 14, 2007, 05:42:58 am
@ blurymind try choosing other editors from the settings panel.
It's kinda hard to use the existing slack-desc editor to edit an existing slack-desc because of the structure of the file. You'd get overbuffer errors and that kind of thing. So I thought it'd just be enough to open the slack-desc in a normal text editor.


@ Joe1962. Good point.

Title: Re: Package builder utility
Post by: blurymind on June 14, 2007, 08:16:46 am
@ blurymind try choosing other editors from the settings panel.
It's kinda hard to use the existing slack-desc editor to edit an existing slack-desc because of the structure of the file. You'd get overbuffer errors and that kind of thing. So I thought it'd just be enough to open the slack-desc in a normal text editor.


@ Joe1962. Good point.


its set to mousepad, yet i still get the same error message.
Title: Re: Package builder utility
Post by: M0E-lnx on June 14, 2007, 10:26:34 am
I may be hard coded the wrong path to mouse pad then. I've got a working text editor for the next release any way. so that wont happen in the future.
Title: Re: Package builder utility
Post by: blurymind on June 14, 2007, 11:47:02 am
I may be hard coded the wrong path to mouse pad then. I've got a working text editor for the next release any way. so that wont happen in the future.
can you make the built in editor to be able to create new files or edit existing ones in the package? (slack-required,*.desktop)

I noticed that its kinda hard to create a desktop file,specially if you have no knowledge how to do it from scratch. I just copy from another desktop file and change some things,such as app name and command to execute it,and the name of the icon that will be at /usr/share/pixmaps..

Title: Re: Package builder utility
Post by: M0E-lnx on June 14, 2007, 12:04:49 pm
I am working on a built-in text editor as joe1962 suggested. As a matter of fact, it is now fully functinoal, It's just that I'm taking a little more time to add more functionality to it (ie, character count so the user doesn't end up with a bad slack-desc file).

This one will be specially for editing the existing slac-desc file, but you can also access the text editor from the menu, in case you want to write a .desktop file in it (no preformat exists as of yet) and just use the "Save as..." option to save the file.

Here is a sneak peek at it
(http://xs116.xs.to/xs116/07244/vnotepad.JPG.xs.jpg) (http://xs.to/xs.php?h=xs116&d=07244&f=vnotepad.JPG)
Title: Re: Package builder utility
Post by: Triarius Fidelis on June 14, 2007, 10:31:33 pm
Well, M0E, I must say I'm completely overwhelmed by Gambas. Really.

So not sure what to do about the .desktop file creator for now... :(

I guess what's really confusing to me is how you would hook everything together. Should I make a standalone .desktop file creator in Gambas, and then you can figure out how to work the form in?

I'm really not even sure I would know how to do it.
Title: Re: Package builder utility
Post by: Joe1962 on June 15, 2007, 04:02:49 am
I have serious plans to work on a .desktop file creator/editor, since I studied the specs extensively when starting vl-hot, but please feel free to start your own, since I'm pretty busy ATM.
Title: Re: Package builder utility
Post by: M0E-lnx on June 15, 2007, 05:32:40 am
I would do it, but I dont have the knowledge about the desktop file itself or the time to learn it and code it here...

I guess we can wait for joe1962's
Title: Re: Package builder utility
Post by: blurymind on June 15, 2007, 10:03:07 am
xfce,kde and most other gui environments have a desktop (launcher) creator..only that it puts the desktop files on the desktop,instead in /usr/share/applications. I am sure that there is already something written....but probably never in gambas (i might be wrong)

This desktop creator thing is not something that one can't live without.I admit it would look very nicely on the package editor.

What it has to generally do is write a basic dekstop file...and the user would need to put only (browse for it) the pixmap file (or png) and enter the command or the path to the executable of the app, aand chose from a slide down list a cathegory of the start menu ,where the desktop file would appear. Thats how i generally picture it,altho i admit more advance features can be implemented.

This vpackager utility is very actively evolving and Moe is really pushing it into something thats usable and handy.I admire the dedication, and that this is the first gui utility not only for packaging under slackware,but also for checking , editing and  installation of tlz packages or even installation from source and making the configure>make>checkinstall procedure more accessable and easy and fast to do.  :)
I am now making the configuration window icon.Will pm it later.Sorry for the delay.

the text editor looks very nice.

Title: Re: Package builder utility
Post by: M0E-lnx on June 15, 2007, 11:05:51 am
The text editor is now complete... Anyone seen anything else that may need to be fixed before I put it back together?
Title: Re: Package builder utility
Post by: blurymind on June 16, 2007, 04:32:58 am
moe, please remove the root only access on the created by package temp dir!!!  When i announce the package at the forum i have to copy its slack-required and desc file...and to do that i have to open the dir as root and navigate to the files,which is a pain in the neck. We dont need to lock those dirs at all. :-X
Title: Re: Package builder utility
Post by: M0E-lnx on June 17, 2007, 05:57:16 pm
I only added that on because it was a request... if it's causing probs, I guess we could revert that
Title: Re: Package builder utility
Post by: blurymind on June 18, 2007, 10:04:40 am
i made a mockup for a *.desktop editor with gimp:

(http://farm2.static.flickr.com/1225/565226820_37ae5d5b01_o.png)

note: the menu editor will copy the chosen graphic icon file to the needed place in the package and rename it with the value chosen in "entry name" .

also the *.desktop file's name can take its filename from the $entryname.

Cathegories is not a must to be that way,but it will eliminate the risks of human mistakes.

Icon preview is not a must (and will probably make it harder for you) ,but its a nice feature,altho you dont have to include it in the first versions.

I could add more feature ideas such as "open pixmap file with Gimp/command/whats set it settings window(graphiceditor" button, but that would be asking too much (altho bringing innovation to such a tool)

Maybe you could use funny abbrievations to name some of the modules. (mine is terrible,lol)

>>offtopic question/suggestion: can you make vnotepad into a sepparate tlz package,and make it possible to open/associate files with it as user or root. It looks like a nice,lightweight text editor.  :P
If only it had a "undo" feature.
Title: Re: Package builder utility
Post by: M0E-lnx on June 18, 2007, 10:53:01 am
As much as I'd like to get that done in such a nice way, I do believe it'll be kind of hard to pull it off because of the complexity of the .desktop file.

What if there is an existing .desktop file?.. in that case I'd need to read such a file, and fill in the form with it's contents.
That is where it gets tricky, not only to read the file (in it's correct format) but because there are no set rules for the contents of this file.
It may have 10 language lines, 10 comment lines, and so on.

Considering all of these factors, I've added a simpler function to vpackager that allows you to edit the .desktop file in the text editor (vNotePad).

The text editor has common functions like copy/paste/cut/undo, etc but
i'm not sure I'd like to be linking any file types to this simple text editor (VL already has many good text editors).

Any text editor will do for this.

I'm almost done implementing the support to edit .desktop file. Once that's done, I'll upload a new release
Title: Re: Package builder utility
Post by: lagagnon on June 18, 2007, 12:19:25 pm
Excellent idea about doing the editing oneself. I don't even think the best Perl programmer around (let alone Gambas) could deal with the complexities of those .desktop files, especially where one already exists and one does not really know the number of lines in it.

Title: Re: Package builder utility
Post by: M0E-lnx on June 18, 2007, 12:31:15 pm
RC1 is now in the repos. Please upgrade and provice feedback

I think we are getting closer to completing an usable tool here.

This release includes the .desktop file editor (in text mode only)
It will detect an existing .desktop file in the source code. If it exists it will then move it to /usr/share/applications. This allows for editing this file after the package is created.

I believe /usr/share/applications is where most of the .desktop files go, so I placed it there. If anyone has reason to believe differently, this can be addressed in future releases.

Enjoy, and keep that feedback coming
Title: Re: Package builder utility
Post by: blurymind on June 19, 2007, 05:05:12 am
RC1 is now in the repos. Please upgrade and provice feedback

I think we are getting closer to completing an usable tool here.

This release includes the .desktop file editor (in text mode only)
It will detect an existing .desktop file in the source code. If it exists it will then move it to /usr/share/applications. This allows for editing this file after the package is created.

I believe /usr/share/applications is where most of the .desktop files go, so I placed it there. If anyone has reason to believe differently, this can be addressed in future releases.

Enjoy, and keep that feedback coming
oh,
Code: [Select]
vector://home/shadow
root:# vpackager
bash: /usr/bin/vpackager: Permission denied

fixed with
Code: [Select]
root:# chmod a=r+w+x vpackager
vector://usr/bin
root:# vpackager
Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed

and
Code: [Select]
sh: /usr/sbin/vlpbulib: Permission denied
 same fix

package editor:

edit slack-desc opens a blank file,while there is something in the slack-desc file of the package
edit desktop file is supposed to create a desktop file,not edit it. There was a desktop file in the package and still package editor said there wasnt and when i told it to "edit it" it didnt create,nor find it for edit. (note the package was bookreader,a kde app)

Also,i would prefer to have a "create a desktop file",and highlighted when there is no desktop file, i never need to edit the desktop file.

Still,grat progress.  ;D
Title: Re: Package builder utility
Post by: M0E-lnx on June 19, 2007, 06:56:23 am
@ blurymind.

Can you try building a non-kde application?

I've been testing for a while, and it finds everything in my packages.

I'm not sure why you're getting that error.

I have done some more work on it though ( I had forgot to implement the correct file.save functions for the different files)

As far as the .desktop file editor thing goes, I think it'll be a while 'till we can get a GUI .desktop file generator/creator.
I will be uploading a bug fix release later on today

EDIT:

I've tracked down the permisions problem
Uploaded a bug fix release that fixes the problem
vpackager-1.0RC1-i586-5vl58.tlz


Title: Re: Package builder utility
Post by: blurymind on June 19, 2007, 09:22:31 am
ah, dont worry about that. The desktop editor is a nice feature,but dont put it at top of the priority list. Just let it stay as an idea.
The text editor can do as much,although the user might make human mistakes...

I have a couple of packages to test it out and a whole lot of source archives,so im testing it now. For now the main vpackager that uses vlpbu works without any problems.
Maybe a nice feature to include would be "user defined configure profiles" for the drop-down list,while keeping "custom".This would add some glitter to the settings window  :P

Ideas are hard to implement ,Moe and you are the main manpower behind this. I can understand if some features are for now impossible for just one man.
I say,lets focus to remove the remaining bugs  (if any) and polish this baby ....its so close now.
Title: Re: Package builder utility
Post by: M0E-lnx on June 19, 2007, 09:33:39 am
Quote
I say, lets forus to remove the remaining bugs (if any) and polish this baby ....its so close now.

I agree. I believe it is fairly functional now, so I'd just like to start polishing it up and getting it ready for prime-time

I have to say, I'm not exactly satisfied myself with the looks of the Main window, so if anyone has any suggestions as to how thing should look, please make a sketch or whatever you have to do to get your point around, and let's see how this baby dresses up
Title: Re: Package builder utility
Post by: easuter on June 19, 2007, 10:20:08 am
How about publishing the sources?  ;D
Title: Re: Package builder utility
Post by: M0E-lnx on June 19, 2007, 10:31:39 am
I've setup a project page @ google code, but can't figure out how to upload the stuff.

Do you mind lending me a hand here?

EDIT:

I just managed to get this up in SVN

Source code is now available via SVN... here is the url
svn checkout http://vpackager.googlecode.com/svn/trunk/ vpackager

Title: Re: Package builder utility
Post by: M0E-lnx on June 25, 2007, 11:14:13 am
Latest developments:

Great news!. Hanumizzle has offered to write a python backend to vpackager, so we will be making the switch soon (nothing different to the users, vpackager will still be as easy to use)

As we approach the final release of this project, I'd like ask once againg for your input to make sure we shape this baby up nicely.

Should we offer an option to hide the output of the build process (the scolling text that shows the build process)?
Should this be disabled by default (the text hidden) ?

I for one, like to see all the matrix crap scrolling across the screen, but that's just My opinion. I'd like to know what others think.
Title: Re: Package builder utility
Post by: easuter on June 25, 2007, 11:34:35 am
Quote
I for one, like to see all the matrix crap scrolling across the screen, but that's just My opinion. I'd like to know what others think.

Yeah, I like to see it too... ;D

I have an idea to make a build script generator for vpackager, since it looks like many will be using it to contribute packages to the repo, that way they could include the source with it...dunno, IMO it would be cool to have that option.
Title: Re: Package builder utility
Post by: M0E-lnx on June 25, 2007, 11:47:47 am
Indeed it would ;)
Title: Re: Package builder utility
Post by: Triarius Fidelis on June 25, 2007, 12:46:52 pm
Latest developments:

Great news!. Hanumizzle has offered to write a python backend to vpackager, so we will be making the switch soon (nothing different to the users, vpackager will still be as easy to use)

...and damned if I don't learn the frontend language, Gambas, already...
Title: Re: Package builder utility
Post by: Joe1962 on June 25, 2007, 12:59:09 pm
Just curious, what does the backend do that can't be done natively in Gambas?
Title: Re: Package builder utility
Post by: M0E-lnx on June 25, 2007, 01:12:26 pm
The backend automates the entire build process.

It was just an easy way for me to do it, didn't want to call a lot of processes, so I wrote a bash script and equipped it with a ton of flags that vpackager passes on to it, and then start just one process from gambas.
Title: Re: Package builder utility
Post by: Joe1962 on June 25, 2007, 01:29:02 pm
Not sure I understand. But don't worry, I'll have a look at the source first chance I get... ;D
Title: Re: Package builder utility
Post by: M0E-lnx on June 28, 2007, 06:26:27 am
RC2 is now in the repos.

A few bugs have been squashed, a few things have also been added.

This is as of SVN Revision 75.
Title: Re: Package builder utility
Post by: Triarius Fidelis on June 28, 2007, 03:03:04 pm
RC2 is now in the repos.

A few bugs have been squashed, a few things have also been added.

This is as of SVN Revision 75.

I commited vlpbuild.py to the repository, M0E.
Title: Re: Package builder utility
Post by: blurymind on June 29, 2007, 09:50:34 am
RC2 is now in the repos.

A few bugs have been squashed, a few things have also been added.

This is as of SVN Revision 75.
I get "failed to download" error in gslapt.

I downloaded it from your website. Very nice. =)
 very nice.I love the new features.

Feature request: Generate slackbuild file, move source package and slackbuild to a directory specified by the user (in settings) in a subfolder with the name of the package..

In settings window:
enable/disable (checkbox)- generate a slackbult

when enabled,options:
enable/disable (checkbox) - include slackbuilt in tlz package (it would be great if its default enabled and it puts the slackbuilts somewhere in a special slackbuilt directory for vector ,like zenwalk does)

enable/disable (checkbox) - when done,copy slackbuild and source package in a folder where the tlz package is moved, .(when user wants to upload them at the repo) :P
   OR
Specify directory for saving slackbuld+source of built packages

then the script would create a folder with the name of the build package and put inside the source package,the slackbuild and the compiled package... mkdir /$specifiedbyuserdir/$packagename/<the fileshere>
or /$dirwherethepackagehasbeensaved/$packagename/<fileshere>
----------------
or something like that. That would deffinatelly turn this into a killer app for slackware packaging. :P


--------------------------

[ looking too far at the idea of package management ]

Maybe just dreaming too far with this but... vpackager could have a module to download source packages and compile them into tlz packages...something like
http://pisibul.sourceforge.net/en.html

wouldnt that be sweet?  ;D Something like portage or pacman for vector,only that it will package the compiled source archves into packages,that can be uninstallable by gslapt. That would be interesting.

But still not sure,if there will be a vnetpackager ( i can already picture how its icon could look like) , where will it look for the source packages.It should have a package database somewhere...or use the avaiable slackbuilds at the repo...hmm

That would deffinatelly put Vector aside of the other slack based distros as different.
Title: Re: Package builder utility
Post by: M0E-lnx on June 29, 2007, 04:40:09 pm
The slackbuild idea should be possible. I will try to implement that as the progress on this project continues.

The mini-portage system could get complicated.
Where is vpackager going to find the sources? This may call for a place on the www that contains tons of source archives so applications like vpackager can just grab them.

I agree, this would make this a killer app, but it would take a lot of work. (I'm not afraid of the work btw)
Title: Re: Package builder utility
Post by: blurymind on June 30, 2007, 01:17:17 am
vector already has directories at the ftp that contain a source archive+a slackbuild of applications. If vpackager becomes capable of handling slackbuilds,it should only take another module that will list the packages at the ftp and download them. I'm not sure what pisibul is using,but that idea would have to take manpower,because then vecteam will have to take care for a sources repo,and each time we build something,we will have to put its source+slackbuild there too. I'm not sure whether this is a good idea tho. A sources repo should need to have a database,containing the information that such a tool would need- a list with the avaiable packages in the directory with their folders.
It will need only a list of the subdirectories with their names,from there,if every subdirectory contains exactly a source package and a slackbuild,it is possible to automate it
(wget http://vectorlinux.osuosl.org/veclinux-5.8/source/testing/kde/kaffeine/*.tar.*z  and slackbuild)
 I agree it might get complicated. Such a tool to fetch sources should first have a tui version. (vlsfu?)
idk,this is just stretching the idea as much as possible.For a source fetching utility it will be good if to look at pisibul's source.
But even before deciding to do such a thing, we should think about what are the gains from it.Who would need it? Who will put newer versions of source packages f everything there?

Vpackager is stable and working great.It deserves to reach a stable state after this RC2. I havent encountered any errors yet.

My idea for future development,or how to take it to the next level is, first teach it to handle and generate slackbuilds, and maybe if it manages to do that well ,then think about something like source fetching utility to integrate in it.

Pardus is a distribution which i respect alot,because of the innovation those guys brought ( hellavabuggy,but very interesting). If vector has something like pisibul, it will definatelly get noticed more than the others.
Title: Re: Package builder utility
Post by: Triarius Fidelis on June 30, 2007, 01:24:50 am
I humbly suggest we refrain from implementing the pisibul concept. The labor involved dwarfs the benefits.
Title: Re: Package builder utility
Post by: M0E-lnx on July 13, 2007, 01:04:50 pm
1.0 RC3 is now in testing...

I've squashed a few minor bugs.. Not a lot of visible changes to the user. Just a couple:

Added code to be able to resize/maximize the vpackager Building window.
Added a "Hide build process" button that hides the window, and shows a smaller window with a progress bar.

I believe the slackbuild packaging would probably come along after 1.0
haven't had time to mess too much with the build script

SVN REV 107
Title: Re: Package builder utility
Post by: wcs on July 13, 2007, 08:59:08 pm
Just tried rc3. Fantastic job, M0E-lnx. Thank you very much.

I got an error on my first compilation (krecipes).
The error was
Quote
/usr/sbin/vlpbulib: line 73: cd: /tmpkrecipes-1.0-beta1: No such file or directory

So I edited vlpbulib and turned line 72:
Code: [Select]
PKGDIR=${TMP}${APP}-${APP_VER}
into:
Code: [Select]
PKGDIR=${TMP}/${APP}-${APP_VER}(with a forward slash after tmp)

I thought it was strange because TMP is defined earlier as "/tmp/".
What could be causing this?

After this minor correction, it worked like an absolute charm.
Thank you again.
Title: Re: Package builder utility
Post by: Triarius Fidelis on July 15, 2007, 08:57:06 am
Well, M0E-lnx, I set up vlpbuild.py so that it can communicate with vpackager using a socket, /tmp/vlpbuild-remote. I tested it with Gambas' socket programming example and it passed (I still need to tweak it a little), but good news: vlpbuild.py can now cooperate with the progress bar after a few changes.
Title: Re: Package builder utility
Post by: M0E-lnx on July 16, 2007, 05:36:07 am
Just tried rc3. Fantastic job, M0E-lnx. Thank you very much.

I got an error on my first compilation (krecipes).
The error was
Quote
/usr/sbin/vlpbulib: line 73: cd: /tmpkrecipes-1.0-beta1: No such file or directory

So I edited vlpbulib and turned line 72:
Code: [Select]
PKGDIR=${TMP}${APP}-${APP_VER}
into:
Code: [Select]
PKGDIR=${TMP}/${APP}-${APP_VER}(with a forward slash after tmp)

I thought it was strange because TMP is defined earlier as "/tmp/".
What could be causing this?

After this minor correction, it worked like an absolute charm.
Thank you again.

There may be a little miscommunication here between gambas and bash... Check your vpackager settings, and make sure your tmp dir has a "/" (like /tmp/). That's at least how it should be.

I removed all the "/" from the bash script, because gambas is supposed to parse it like "/tmp/" not "/tmp".

But thanks for pointing it out.
Title: Re: Package builder utility
Post by: M0E-lnx on July 16, 2007, 05:38:29 am
Well, M0E-lnx, I set up vlpbuild.py so that it can communicate with vpackager using a socket, /tmp/vlpbuild-remote. I tested it with Gambas' socket programming example and it passed (I still need to tweak it a little), but good news: vlpbuild.py can now cooperate with the progress bar after a few changes.

You and I need to work together a little more... I'm liking this python thing, but I'm having a hard time make it work myself... I'll digg into the socket programming in a bit...

I just dont want this python backend to require a re-build of the entire thing..
Title: Re: Package builder utility
Post by: Joe1962 on July 16, 2007, 06:57:29 am
IIRC, socket programming requires Gambas 2. I thought you were using Gambas 1 now?
Title: Re: Package builder utility
Post by: M0E-lnx on July 16, 2007, 06:58:49 am
I am using gambas1.

That's prolly why I couldn't get it to work then... because although there is examples for Client/Server sockets in g1, this is a whole new concept to me... so I dunno..

Unless hanu can adjust his script to act almost like my bash script
Title: Re: Package builder utility
Post by: Joe1962 on July 16, 2007, 07:05:25 am
Those are for TCP/UDP network sockets.
Title: Re: Package builder utility
Post by: M0E-lnx on July 17, 2007, 08:48:20 am
I'd like to point out that for those of you testing, you can log into the vpackager page @ google code
http://code.google.com/p/vpackager/
and report bugs there. You'll need a google (gmail) account.
Title: Re: Package builder utility
Post by: Triarius Fidelis on July 18, 2007, 07:12:46 am
IIRC, socket programming requires Gambas 2. I thought you were using Gambas 1 now?

Local Unix sockets are totally useful in Gambas 1. In fact, there is an example that comes with, and I shall submit my little vlpbuild.py manipulator to M0E-lnx to demonstrate how it functions.
Title: Re: Package builder utility
Post by: Joe1962 on July 18, 2007, 09:37:31 am
You're right, of course. I was confusing sockets and pipes... ::)
Title: Re: Package builder utility
Post by: Triarius Fidelis on July 18, 2007, 09:52:21 am
You're right, of course. I was confusing sockets and pipes... ::)

Well, as far as 'pipes' go, you can of course open a process as a file handle. It probably uses one of the popen family functions deep down inside there.
Title: Re: Package builder utility
Post by: wcs on July 25, 2007, 08:40:40 am
I have been trying RC3. What a fantastic tool this is.

One bug:

The preview window for the description changes when a user types the description but nothing shows up when pasting text.
In order to see the preview, after pasting I need to edit the description.

One feature request:

It would be nice if the build options were also displayed when choosing "default", or "default for gtk applications". The idea being that one could keep the default options for gtk apps (for example) but add to it, without having to select Custom and writing the whole line of default options.
(incidentally, I suppose kde apps would go into /opt/kde, so maybe a "default for kde apps" option?)

Thank you for the effort of putting this together.
It's great!



Title: Re: Package builder utility
Post by: M0E-lnx on July 25, 2007, 12:49:14 pm
Thanks for your input wcs.
I have addressed the issue in the slack-desc generator. (This is why testing is important)
it will appear fixed in the next release.

You're absolutely right about the configure options. I'll adjust the code to match your suggestion... Thanks again

Edit:
Both suggestions have been implemented.

I also added functions to install the package (if the user choses to) when it finishes building.

keep testing, and report bugs/issues/feature requests



Title: Re: Package builder utility
Post by: wcs on July 26, 2007, 05:19:58 pm
Quote
Both suggestions have been implemented.

Thanks a lot!
Title: Re: Package builder utility
Post by: M0E-lnx on July 27, 2007, 06:14:09 pm
Here is what the new package installer feature looks like
http://xs317.xs.to/xs317/07306/compiz-fusion.jpg

Of course, if I wasn't so lazy, I'd write a description for the package, and the description would show up here
Title: Re: Package builder utility
Post by: uelsk8s on July 27, 2007, 07:15:11 pm
that looks like compiz-fusion running on SOHO 5.8.X to me   ;D
Title: Re: Package builder utility
Post by: M0E-lnx on July 27, 2007, 08:37:02 pm
Check this out! http://xs217.xs.to/xs217/07306/vpackager-at-it2.jpg
Title: Re: Package builder utility
Post by: exeterdad on July 27, 2007, 08:39:41 pm
Quote
Check this out! http://xs217.xs.to/xs217/07306/vpackager-at-it2.jpg

I thought it was a package builder.  Looks more like a cube.  :P
Title: Re: Package builder utility
Post by: M0E-lnx on July 28, 2007, 02:07:50 pm
it is indeed a cube, but vpackager is running inside of it ;)

vpackager + compiz-fusion = eyecandy sweetness

Now, back to vpackager.....
I'll start working on the 1.0 release this coming week.. I've done a lot of testing... but if anyone else has another bug or feature that could be useful to vpackager, please shoot
Title: Re: Package builder utility
Post by: M0E-lnx on July 30, 2007, 05:50:04 am
Heh, I just realized I posted the wrong link in the first place...
This is the installer window

http://xs317.xs.to/xs317/07306/vpackager-at-it.jpg

Title: Re: Package builder utility
Post by: exeterdad on July 30, 2007, 07:30:55 am
That is a thing of beauty.
Title: Re: Package builder utility
Post by: MikeCindi on July 30, 2007, 11:05:12 am
While I find the vpackager to be quite useful seeing portions of your desktop are more interesting to me.  :P
Title: Re: Package builder utility
Post by: M0E-lnx on July 30, 2007, 11:07:22 am
I have a feeling I know which parts of my desktop you're referring to ;)
However, the howtos section of the forums is still missing the useful information we had posted on there about getting all this eye-candy sweetness on VL...
Hope we get it back soon.
Title: Re: Package builder utility
Post by: MikeCindi on July 30, 2007, 11:10:45 am
me too
Title: Re: Package builder utility
Post by: M0E-lnx on August 02, 2007, 10:50:39 am
vpackager-1.0 is now in the repos...

Please upgrade.

Thanks the the input I got from this thread, I do believe this project has reached a useful and solid enough phase to call it 1.0

Development will of course continue. My goal is to provide an application that can build lots of applications from source, with that said, I'll start working on the next phase of this project, which included support for CMake and python applications, integrating a function to package a build script with every package, and things of that nature.

Please continue testing, and as usual report bugs when you find them.
Title: Re: Package builder utility
Post by: blurymind on August 16, 2007, 09:51:52 am
i vote two hands to include gslapt in vector's major upgrade release. It will get alot of attention from reviewers, to vector and to itself. I think that we need to polish it up abit. Write a nice documentation and most of all,if possible add a link to our forum ,or to a section in the website for people who would like to become packagers. (i think it would be nice to have a link between the packager utility and the comunity itself).And at the about window,add a link to its official google code page and to a page to report bugs. :-\
EDIT: oh,you already did that.  :-*


Feature request: The ability to create slackbuild files for every package and include it in the package itself.

Bug report: At build process,the create package message doesnt show fully in the window
(http://xs218.xs.to/xs218/07334/note2.png.xs.jpg) (http://xs.to/xs.php?h=xs218&d=07334&f=note2.png)

I really like how you polished it up at places. It looks very very nice.
Title: Re: Package builder utility
Post by: caitlyn on August 16, 2007, 09:58:55 am
Feature request: The ability to create slackbuild files for every package and include it in the package itself.

YES!  That would be great.
Title: Re: Package builder utility
Post by: blurymind on August 16, 2007, 10:32:13 am
Feature request: The ability to create slackbuild files for every package and include it in the package itself.

YES!  That would be great.
After that is accomplished, the ability to use slackbuild files for the packages. I think that will be vlpbu's next step.
Think of the possible uses of this. It will make this tool absolutely priceless for packages control. We will also have the slackbuilds included in the packages themselves. Maybe we can upload them at a slackbuild repo dir. That will be very helpful for global organisation.
If its too hard to do,don't do it. ::)
Title: Re: Package builder utility
Post by: lagagnon on August 16, 2007, 10:44:08 am
i vote two hands to include gslapt in vector's major upgrade release.
I expect you meant "vpackager" and not "gslapt"?
Title: Re: Package builder utility
Post by: M0E-lnx on August 16, 2007, 10:51:39 am
Is anyone else still getting the same buggy label on the build window?
I thought I submitted a revised package...

a simple slapt-get --install vpackager --reinstall should do the trick ;)
Title: Re: Package builder utility
Post by: blurymind on August 16, 2007, 12:32:20 pm
i vote two hands to include gslapt in vector's major upgrade release.
I expect you meant "vpackager" and not "gslapt"?
yes, i did.
I am sorry guys... these days i am overworked and i tend to be a little bit absent minded.  :-[

Can you believe that this week i have to work saturday and sunday. What are they? Nuts?
Title: Re: Package builder utility
Post by: M0E-lnx on August 16, 2007, 12:46:36 pm
blurymind, can you try a re-install to see if the bug you submitted is still there?
Title: Re: Package builder utility
Post by: blurymind on August 16, 2007, 12:55:42 pm
blurymind, can you try a re-install to see if the bug you submitted is still there?
it is still not at the repo.The one i have,i got from your ftp dir
Title: Re: Package builder utility
Post by: M0E-lnx on August 23, 2007, 05:09:49 pm
There should be one avialable now. I fixed the bug
Title: Re: Package builder utility
Post by: Triarius Fidelis on August 23, 2007, 07:00:15 pm
Development will of course continue. My goal is to provide an application that can build lots of applications from source, with that said, I'll start working on the next phase of this project, which included support for CMake and python applications, integrating a function to package a build script with every package, and things of that nature.

I'll be with you the whole way. :)
Title: Re: Package builder utility
Post by: M0E-lnx on August 23, 2007, 07:40:33 pm
Great. There is a lot going on at the moment with dynamite development so i got my hands busy now. And besides i need more user input for development to continue. After we get enough bug reports we can get back at it


Looks like someone ran into vpackager from the slacky.it forums
http://www.slacky.eu/forum//viewtopic.php?t=20060&highlight=vpackager

Too bad I dont understand italian.

From what I do gather, and with the aid of google translator, I screwed up in the package creation process.. The permissions of the package's /usr dir are screwed... so I've re-submitted once again, another package.

Title: Re: Package builder utility
Post by: blurymind on August 25, 2007, 12:13:01 am
Hey Moe, he might have run an older version. Dont you remember how many bugfixes you made?  ::) How do you know he's running the latest version..
It works fine with us. He is probably using slackware

I would like to suggest on thing!

Integrate SINP into Vpackager's next version, as a module:
http://sinp.sourceforge.net/

or something like that. Imagine vec having its own buildscript repository for packagers. How hard would it be to upgrade packages.  :P

a module to open/browse/search the buildscripts and wget them+the ability of vpackager to handle build scripts and edit them (even if with vnoteedit) = ultimate power
Even buildscripts to work with git,cvs and svn would be awesome to have somewhere on an ftp. ;D  (our own buildscript repository)
One thing that bugs me in slackbuilds repo,is that its buildscripts work with the source of what they have there,older version.If you want to compile wine with a build script from there,first you have to get the latest version of wine from wine website,then edit the build script a bit to change wine version in there,and to change arch to be your (i686), things that vpackager can do. You can make a script that gets the latest avaiable source and compiles it. Vpackager with such a module would be like the gslapt for buildscripts.

sinp doesnt show source version in search :(

you could only use sinp to search and get the scripts/files, but modify it to support our own server in the future, and vpackager to handle the scripts and innitiate them. Build scripts use the same variables,which can be very good for such an utility.
So i see the future of such an utillity in that way. Having access to slackbuilds repo + access to vec's own repo for such scripts,where build scripts get latest source code,not avaiable version. That would be awesome. 
Title: Re: Package builder utility
Post by: M0E-lnx on August 25, 2007, 07:41:08 am
that would be kool
Title: Re: Package builder utility
Post by: blurymind on August 26, 2007, 12:22:53 am
that would save  the effort and time to go and download the sources,it will also greatly improve the time for mass compiling.
 ;D

sinp is very cool. I just write
Code: [Select]
sinp basket and it downloads,compiles,packages and installs it.
One downfall is that its source library is kind of poor (slackbuilds for sw12) and outdated (wine was old,among alot of other things and it lacked quite a bit of basic sources)
 Now if we have scrips for compiling the latest source of everything,we wouldn't have to update them(the scripts) ,and we will get serious attention from people interested in buildscripts.It would be great to have them submit scripts.

And the totally kool build script for compiz fusion you gave me, its just a great example of how quick and awesome these scripts are.
I even though of a buildscript icon and the graphic files for that module,but i wont start forging them before i get confirmation they would be used.  ::)
btw i got vpackager work on the pseudo cd,after installing gambas (package for sw12 from slacky)
Title: Re: Package builder utility
Post by: M0E-lnx on August 26, 2007, 03:03:48 pm
that would save  the effort and time to go and download the sources,it will also greatly improve the time for mass compiling.
 ;D

sinp is very cool. I just write
Code: [Select]
sinp basket and it downloads,compiles,packages and installs it.
One downfall is that its source library is kind of poor (slackbuilds for sw12) and outdated (wine was old,among alot of other things and it lacked quite a bit of basic sources)


This is exactly why I chose to build this application as it is now, because that way, you dont have to worry about repos being updated... if there is new source code out there, run vpackager, point, click, package, and install...

the scripts thing might be a good addition... but I dont like to depend that much on others to keep the script list clean and tidy.
Title: Re: Package builder utility
Post by: blurymind on August 27, 2007, 09:04:45 am
thats why i proposed vec to have its own buidscript repo,where to put all the build scripts:
*static (stable)
and
*dynamic (latest from cvs)

Going mainstream with this idea will make a slacker weep of happiness  :P

I agree that depending on buildscripts.org is not all that glorious,plus they dont use vec's default configure and checkinstall options (generating tgz instead of tlz)
So what it should do is simple,but how simple is it to achieve in gambas?

search for buildscript(s) -----> show all avaiable versions of buildscripts for package ( to build version x.xx ,x.xb or cvs of source ) --->pick one---> wget and innitiate the script --> compile --> question: save package / install package /edit package (whatever is chosen,package is saved to tmp)
the build script repo can have the written slackdesc,icon,desktop files...

So if sinp can do it,we can do it better.It will take time to collect build scripts for everything,but from the start i think that it is a good idea to have one for each package at the repo. One might need to fetch a newer source of something to build something...this will also save everybody the fuss of searching for a source file over and over again..
Having a search feature to vpackager would not only motivate everybody to submit such scripts,it will also make vector linux more interesting. Maybe other slack-based distros will want to have vpackager with such features, but what is VL's buildscript repo,will remain vl's buildscript repo. ::)
Title: Re: Package builder utility
Post by: M0E-lnx on August 27, 2007, 09:17:15 am
This might be hard to pull off... The main problem here is that not all scripts are written in the same manner. Most slackbuilds do not wget their own source, you need to privide it. There is no way of telling which version of a program the slackbuild is written for by just looking at the name, you have to crack it open and find the value of $VERSION.
Needless to say, All slackbuilds might need a bit of tweaking to generate the desired results. Also, the user customization may not be available at all. At first glance, this is what you're saying this gambas program should do

Find a script
  |_ Either locate the source or edit the slackbuild to make it wget it's own source
Run the script
Prompt whether to install or save the package.

That might be kind of hard to control

Title: Re: Package builder utility
Post by: blurymind on August 28, 2007, 09:48:49 am
there must be a nice and simple manner to pull this off.
Too much power is hard to control. Only the basics are good too.

I sepparated the slackbuilds into two types:
static
and dynamic
the dynamic ones would fetch the source from cvs (download the source themselves via svn,git,cvs...) (they should use different variables,or slightly different set of variables)

the static ones could be the standart slackbuilds and every source package could have its own slackbuild..

maybe there is a better way to achieve it.
Title: Re: Package builder utility
Post by: M0E-lnx on August 28, 2007, 09:59:51 am
but the static scripts woul get outdated really quick though. That is my main concern. Most of the time this scripts will work when you modify it to build the newer version and naked minor adjustments such as patching. This is what is difficult to do and control. This is also the downside to this idea. This would inevitably make the application to depend on someone to keep the scripts up to date. i'm not sure we want a whole other type of repository or have the time or manpower to keep up with all of it
Title: Re: Package builder utility
Post by: blurymind on August 28, 2007, 10:27:24 am
but the static scripts woul get outdated really quick though. That is my main concern. Most of the time this scripts will work when you modify it to build the newer version and naked minor adjustments such as patching. This is what is difficult to do and control. This is also the downside to this idea. This would inevitably make the application to depend on someone to keep the scripts up to date. i'm not sure we want a whole other type of repository or have the time or manpower to keep up with all of it
all slackbuilds which have $VERSION variable,which the user can set,and that variable is included in another SRCURL variable,which it uses to get the source in the following matter:
Code: [Select]
SOURCE="SRCDIR/${PRGNAM}-${VERSION}.tar.bz2"
SRCURL="http://dl.sourcefogre.net/<appname>/${PRGNAM}-${VERSION}.tar.bz2"
that variable can be used to get the ssource from somewhere

http://alienbase.nl/slackware/slackbuilds/wxGTK/build/wxGTK.SlackBuild

thats pretty beautifully executing the operation,leaving the user only with the need to define the version of the source ($VERSION),before executing the script...but it leaves the question, how would the user know what avaiable version is there (the latest stable one)... I'd say the way sourceforge handles urls can work.I remember seeing a url for a link to SF that ended with "...downloadlatest" or something like that..butit was for browsers.. well,this one way would work too,right? :P

well,the user will atleast decide... from one script,and you wont have to update it
Title: Re: Package builder utility
Post by: M0E-lnx on August 29, 2007, 04:20:45 pm
but that's exactly what i'm saying. Even when the user knows enough to modify a slack build i do not see the point in writing a graphical front end to a slack build. My point here is if you can edit the script you might as well just execute it while you're at it. there is not much more to do at that point anymore. vpackager is designed to build just about any source by automating the common build procedure. It is not hard coded to build just one version of one application.
Title: Re: Package builder utility
Post by: blurymind on August 30, 2007, 08:41:44 am
well,a graphical frontend to search and download the buildscript would be great...my main point is the buildscript repository and specially buildscripts for live source (git,cvs,svn)
wouldnt that be great to have

if its hard or impossible,lets at least have a library for such scripts somewhere.They are very handy.
Title: Re: Package builder utility
Post by: easuter on September 01, 2007, 04:02:19 am
Blurymind, if you want a slackbuild collection, then you may be interested in DarkVision's SlackBot script collection. It even has an ncurses frontend: http://www.mkanet.de/data/slackbot/0.6_saturn/index.html

Though I don't recommend you use this to build packages for the repo, since there is a lot of Slackware-specific stuff, especially when it comes to init-scripts and package descriptions, but it will give you an idea of what it is you are requesting Moe to do.

This kind of script collection is probably almost a full-time job to maintain, and is *never* complete, since new versions of apps are always coming out, project hosting changes, and distro-specific changes occur.

But turning vpackager into a Slackbuild frontend really creates constraints (that Moe has already explained). Not only will the bash scripts have to be maintained, but the vpackager gambas code might also have to be changed every time a significant modification is made to the Slackbuilds. Its really a lot simpler to maintain *one* codebase that will do everything.
For this, I suggest that you actually take a look at the vpackager svn branches and see what development is taking place there (Cmake, python support, among other things). And it might give you a better perspective of the development work that is already being put into this project (and the coding it takes to make these features possible)....who knows maybe you could help with the coding too ;)
Title: Re: Package builder utility
Post by: blurymind on September 03, 2007, 09:35:55 am
ok,scratch the idea about vpackager's module to get buildscripts... how about having our own repository for vl buildscripts (configure&make options,tlz...) and a way to browse/search through them (even if with google) ..maybe vpackager aint ready to handle build scripts (slackbuilds) but having a repo for svn,cvs,git...ah,its such a dream.

ok,i dont wanna be a nag,it was just a suggestion.  :(
Title: Re: Package builder utility
Post by: M0E-lnx on September 14, 2007, 09:08:34 am
Let's lock this thread, and discuss the new vpackager in a new thread here:
http://www.vectorlinux.com/forum2/index.php?topic=4259.0