Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[M0E-lnx]

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.

[blurymind]

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...

[M0E-lnx]

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.

[easuter]

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.

[blurymind]

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?

[easuter]

What is the program you are trying to build?

[M0E-lnx]

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.

[blurymind]

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.

[M0E-lnx]

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.

[blurymind]

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* )

[M0E-lnx]

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.

[blurymind]

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?

[M0E-lnx]

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)

[blurymind]

as it is,if it fails,it just creates an empty package,which is pretty obvious to spot. 
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.

[M0E-lnx]

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