Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 01 Oct 2014, 17:08
All times are UTC - 4
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Utilities
src2pkg-2.7 - create packages from any source code
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 1 of 4 Posts_count   Goto page: 1, 2, 3, 4 Next
Author Message
amigo

Joined: 02 Apr 2007
Posts: 2252

PostPosted: Wed 15 Feb 2012, 12:52    Post_subject:  src2pkg-2.7 - create packages from any source code  

After two months of intensive development, src2pkg-2.7 is now released. The last release was only in December, but I started coding wildy the very next day...

Most of the changes are related to package-splitting and the new kiss *.tpkg format, but there were a few small bug-fixes which affected all package formats.

From the CHANGES file:
== Version 2.7 == 15 Feb 2012

This version fixes a couple of minor bugs and adds many
enhancements for the KISS-linux 'tpkg' package format.
Some of that code was separated from routines for
Slackware packages, so the Slackware routines are cleaner.

Notes on upgrading:
As user root, run 'src2pkg --setup' after upgrading
from any earlier version.

Some new configuration options have been implemented,
so check the new version against any existing one.

The full ChangeLog is here:
http://distro.ibiblio.org/amigolinux/download/src2pkg/CHANGES

The installable pet package for Puppy is here:
http://distro.ibiblio.org/amigolinux/download/src2pkg/src2pkg-2.7/src2pkg-2.7-noarch-2.pet

Thanks to Jemimah for reporting a problem with invalid links when splitting packages.

Edit: I forgot to mention that the pet package now installs a pre-configured conf file which should allow instant usage on Puppy, with all the configurations options set to produce pet packages, without the user needing to edit the conf file.

If installing src2pkg for the first time, you will automatically get this conf file. But, if you have installed src2pkg before and have an existing /etc/src2pkg/src2pkg.conf file, you should rename it so that the new gets installed *and activated*. Then, compare your old file with the new one to see if you have any extra options which are not already set up in the new one.

Edited to update link to fixed package -there was a problem with syntax when using bash4.

Edited_times_total
Back to top
View user's profile Send_private_message 
Flash
Official Dog Handler


Joined: 04 May 2005
Posts: 11081
Location: Arizona USA

PostPosted: Wed 15 Feb 2012, 12:58    Post_subject:  

Would you mind telling us what src2pkg is supposed to do?
Back to top
View user's profile Send_private_message 
amigo

Joined: 02 Apr 2007
Posts: 2252

PostPosted: Wed 15 Feb 2012, 15:40    Post_subject:  

Flash, src2pkg creates packages from source code or other content. In can create packages for Slackware, KISS Linux, *.rpm packages, *.deb packages, *.taz packages for slitaz and *.pet packages for Puppy (new-style or old-style).

src2pkg is an 8-year-old project now, so it has become quite mature at what it does:

Create a package from source code or other content with a single command -sometimes without any 'recipe' or extra arguments. It can download a given source URL, configure the sources, compile them, create the package and install it with a single command. It is still the only packaging system out there which can *sometimes* create a package without any expertise on the part of the user vis-a-vis compiling and/or creating sane packages, and often do so without any sort of 'recipe', 'spell', 'port', SlackBuild script. or whatever the distro uses to create packages.

src2pkg has supported the pet format for several years now. src2pkg focuses on creating really sane, uniform packages in a repeatable fashion. The recipes (*.srcpkg scripts), when used, are very brief, flexible and easy to edit so that it is possible to create even the most complex packges from them -no matter what. The *.src2pkg scripts are architecture-agnostic, so the same script can be used no matter what architecture they are used on.

src2pkg is script-based, but also depends on several binary programs and libraries. The sources for these are all included in the src2pkg package, and will be compiled, packaged and installed *on your system* after installation of the src2pkg package. This is done so that every user gets the bins and libs compiled for their exact system -no chance for incompatibilities.

The really shortest tutorial:
1. Install the pet package linked to in the original post.
2. Open a terminal (xterm or rxvt) anywhere and type the command:
src2pkg --setup
That will configure and compile the included sources, and create and install a pet package called src2pkg-helpers-VERSION-ARCH-BUILD.pet
3. Build the example package like this:
src2pkg http://distro.ibiblio.org/amigolinux/examples/di-3.11/di-3.11.tar.bz2
or:
src2pkg http://distro.ibiblio.org/amigolinux/examples/di-3.11/di.src2pkg.auto

As far as I know, Jemimah uses src2pkg to create some of her pets for Saluki. big_bass uses src2pkg to create *.txz packages for his Slaxer derivative. There are others here who are using src2pkg to build pets with.

src2pkg knows how to handle sources which use a plethora of configuration methods, including, autoconf, cmake, imake, jam and many others -perl, python and tcl sources included. src2pkg has five distinct methods for creating initial package content(normally the 'make install' command. The 5 methods allow for safe content creation without over-writing exisiting files -even when DESTDIR is not supported. One of the methods will always work. src2pkg performs many hundreds of sanity checks on the package content, correcting common errors in a flexible, configurable manner. src2pkg can automatically split packages into their run-time, development, documents and language files components.

src2pkg is meant for use by both rank beginners and packaging profis. src2pkg forms the basis for my KISS Linux distro, where it used to build every package on the system -above 1,000 at this time(from around 400 sources). src2pkg also includes a drop-in replacement for installwatch/checkinstall (libsentry/sentry) which is more robust and accurate than the originals. src2pkg includes ample documentation and examples. The script code used by src2pkg is over 10,000 lines and has been actively developed since 2004, tested and heartily approved of by many skeptical animals -er Slackers I mean.

Hope that gives you a hint about -searching the forum will show src2pkg mentioned and announced here many times.
Back to top
View user's profile Send_private_message 
majorfoo

Joined: 07 Mar 2011
Posts: 445
Location: Wish I knew

PostPosted: Wed 15 Feb 2012, 17:04    Post_subject:  

amigo wrote:
Flash, src2pkg creates packages from source code or other content. In can create packages for Slackware, KISS Linux, *.rpm packages, *.deb packages, *.taz packages for slitaz and *.pet packages for Puppy (new-style or old-style).



Will this application handle source files like xxxxxx.tar.gz
In other words, with a tar.gz extension

I would like to create pet packages from source files with this extension without going through the make, make install, etc routine.

thanks
majorfoo
Back to top
View user's profile Send_private_message 
amigo

Joined: 02 Apr 2007
Posts: 2252

PostPosted: Wed 15 Feb 2012, 17:20    Post_subject:  

That's exactly what it does. Follow steps 1, 2 and 3 in the post above and let me know if you have any problems.
Back to top
View user's profile Send_private_message 
stu90


Joined: 25 Feb 2010
Posts: 1401
Location: England. Dell Inspiron 1501. Dpup

PostPosted: Wed 15 Feb 2012, 17:50    Post_subject:  

Hi Amigo,
Does the devx need to installed to use src2pkg-2.7
just tried to run on puppy exprimo 5.x.13 without devx.

# src2pkg --setup
Notice - Creating src2pkg-helpers:
src2pkg uses a shared library and a few programs
when creating packages. For best compatibility,
these binaries will be compiled on your system.
They are then installed in a private directory.
When done, src2pkg is ready for use.

TEMP_DIR=/usr/src/src2pkg/builds/src2pkg-helpers
Starting build in 5 seconds
/usr/libexec/src2pkg/FUNCTIONS: line 275: syntax error near unexpected token `}'
/usr/libexec/src2pkg/FUNCTIONS: line 275: `}'
/usr/src/src2pkg/src2pkg-helpers/src2pkg.setup: line 601: get_flags: command not found
Unpacking sources - OK
Creating libsentry - Ooops! Can't live without it...
Back to top
View user's profile Send_private_message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Wed 15 Feb 2012, 18:26    Post_subject:  

Here is my preliminary feedback after a quick test.

The installer script should display the messages using xdialog or gxmessage or something. No one will see them if they only echo.

I think the following settings should be default:
Code:
QUIET="NO"
QUERY_FOR_EXTRA_CONFIGS=YES

Otherwise it's impossible to diagnose and fix build problems.

--splitpkg flag should be documented in src2pkg --help. Right now the only place I can find it mentioned at all is the changelog. I think splitpkg should be the default on puppy.

Package names end up like pkgname-2.0-i486-1. What does the '-1' mean? Can it be turned off?

Docs remained in the bin package, even though I requested them split.

Static libs and .la files in the plugins directory didn't get split into the DEV package

Code:
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/demosaic.la
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/dcp.a
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/fuji_rotate.so
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/meta_raf.la
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/rotate.so
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/colorspace_srgb.la
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/meta_tiff.la
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/input_file.so
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/load_gdk.so
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/meta_ciff.so
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/crop.a
rawstudio-2.0-i486-1/usr/share/rawstudio/plugins/load_rawspeed.a



Other than that is is working great! Thanks!
Back to top
View user's profile Send_private_message Visit_website 
majorfoo

Joined: 07 Mar 2011
Posts: 445
Location: Wish I knew

PostPosted: Wed 15 Feb 2012, 20:30    Post_subject:  

amigo wrote:
That's exactly what it does. Follow steps 1, 2 and 3 in the post above and let me know if you have any problems.


Installed src2pkg in copy of lucid 528 which also has devx files installed.

received following:

Code:
# src2pkg --setup
  Notice - Updating src2pkg-helpers:
  Your installed version of src2pkg-helpers needs to
  be updated. src2pkg will now compile, package
  and install the new version of src2pkg-helpers.

  TEMP_DIR=/usr/src/src2pkg/builds/src2pkg-helpers
  Starting build in 5 seconds
/usr/libexec/src2pkg/FUNCTIONS: line 275: syntax error near unexpected token `}'
/usr/libexec/src2pkg/FUNCTIONS: line 275: `}'
/usr/src/src2pkg/src2pkg-helpers/src2pkg.setup: line 601: get_flags: command not found
Unpacking sources - OK
Creating libsentry - OK
Creating tar-1.13 - OK
Creating coreutils - OK
Notice - Skipping creation of unionfs-fuse -you don't have fuse installed.
Creating pet package - Done
Finished pet package is:
/usr/src/src2pkg/src2pkg-helpers/src2pkg-helpers-1.5-i486-1.pet
Installing pet package - Done src2pkg is now ready to use.
/root


appears devx files must be installed to use this app..

what about the errors on line 275 and 601.
also the skipping of unionfs-fuse

how do I correct these

majorfoo
Back to top
View user's profile Send_private_message 
stu90


Joined: 25 Feb 2010
Posts: 1401
Location: England. Dell Inspiron 1501. Dpup

PostPosted: Thu 16 Feb 2012, 03:08    Post_subject:  

yes devx seems to be needed - i have loaded Exprimo puppy devx and get the same message as Majorfoo.
src2pkg-helpers .pet was created then installed - Attempting to build example package returns:

# src2pkg http://distro.ibiblio.org/amigolinux/examples/di-3.11/di-3.11.tar.bz2
/usr/libexec/src2pkg/FUNCTIONS: line 275: syntax error near unexpected token `}'
/usr/libexec/src2pkg/FUNCTIONS: line 275: `}'
/usr/libexec/src2pkg/FUNCTIONS: line 275: syntax error near unexpected token `}'
/usr/libexec/src2pkg/FUNCTIONS: line 275: `}'
/usr/bin/src2pkg: line 471: do_all_processes: command not found


cheers.
Back to top
View user's profile Send_private_message 
amigo

Joined: 02 Apr 2007
Posts: 2252

PostPosted: Thu 16 Feb 2012, 04:25    Post_subject:  

Found the problem. There were several reports also from folks on the Slackware forum also.

The qick fix is to simply edit /usr/libexec/src2pkg/FUNCTIONS
at line 135 from:
case $LINE in *' ') LINE=$(echo ${LINE:0:$((${#LINE}-1))) ;; esac
to:
case $LINE in *' ') LINE=$(echo ${LINE:0:$((${#LINE}-1))}) ;; esac
Notice the extra curly bracket near the end of the line.

When I first saw the reports I had a dread. Finding these errors can be very hard among thousands of lines of code. And, as you can see from this example, bash doesn't report the line number correctly. But it turned out to be easy to find.

I run bash3 here and was unable to reproduce the problem here at first. Both Slackware and some recent Puppies use bash4, so I figured it might be a bash4 problem. Using bash4 here I had the error too.

Fixing and upgrading for upload after a short while, so you can re-install. Or just use the quick-fix above.
Back to top
View user's profile Send_private_message 
pemasu


Joined: 08 Jul 2009
Posts: 5463
Location: Finland

PostPosted: Thu 16 Feb 2012, 05:22    Post_subject:  

Dpup Exprimo has bash 4.1 or 4.2 depending on version.
Back to top
View user's profile Send_private_message 
amigo

Joined: 02 Apr 2007
Posts: 2252

PostPosted: Thu 16 Feb 2012, 07:23    Post_subject:  

Okay, this has been fixed and the original post has been edited to point to the new link.

Now, let me try to answer a couple of the questions:
majorfoo, "Notice - Skipping creation of unionfs-fuse -you don't have fuse installed." This is not a critical error. One of the five ways that src2pkg uses to isolate the files when something like 'make install' is run, is to use a temporary union mount using the real union file system *or* by using unionfs-fuse. In order to compile unionfs-fuse you need libfuse and the headers from libfuse, which is not present AFIK in your devx.sfs. It just means you lose one of 5 available methods which is not often used, nor required.

Jemimah, "script should display the messages using xdialog or gxmessage". Hmm, I'll work on a dedicated pinstall.sh script which does this, unless you wanna look at modifying the doinst.sh which gets converted to a pinstall.sh when I create the packages.

"QUERY_FOR_EXTRA_CONFIGS=YES" You won't want this if your start using *.src2pkg scripts to record your builds. If you are really needing to manually input certain configure options, that is exactly when you should be using build scripts you you don't forget what options were needed, and to save the pause during building. But you could simply do this:
src2pkg -Q -A ....
and have src2pkg automatically create the build script for you on successful completion of the package -it will write those options into the script for you, of course. At any rate, I'd suggest you use the command-line '-Q' option instead of making it the default so you can conveniently not use the option. Have a look at using the -ACF or -ACN
options as an alternative for commonly-used configure options.
You can also create a script before hand like this:
src2pkg -N -e='your configure options here' name-of-tarball
Then you only need to do this to execute that script:
src2pkg -X
and it's available for easy editing to customize anything you like.

"--splitpkg flag should be documented" It is. You have to look at the extended help:
src2pkg -hh (or src2pkg --more-help)
But it doesn't doesn't tell you much about the inner workings which you maybe are interested in. I use this for kiss:
src2pkg --splitpkg=devel,docs,nls
(there is also an option for 'solibs' which not often needed)
I first implemented doc-splitting as an all-or-nothing option, but that caused lots of tiny little docs packages to be created -sometimes with just one file in them. So, I implemented DOC_SPLIT_SIZE to let you control the cutoff-point. If the size of all the documents in the package is less than this minimum, the docs will not be split. This new option is at the very bottom of the new src2pkg.conf file. If you have upgraded or simply overinstalled this new version, then the new conf file will be at: /etc/src2pkg/src2pkg.conf.new
The pinstall.sh script uses a 'config ()' function which avoids the new package ober-writing your possibly-customized exisiting conf file. So you'll need to either copy the config option from the src2pkg.conf.new file, or backup and replace your old conf file with the new one. This 'config()' routine is commonly-used to avoid over-writing existing files and is generated automatically by src2pkg whenever it finds *.new files in the package. If you want to follow good-practice here when creating packages, then put a line in the *.src2pkg script for the package, which changes the name just after 'fake_install':
fake_install
mv $PKG_DIR/etc/my.conf $PKG_DIR/etc/my.conf.new
src2pkg will take care of the rest for you of writing the pinstall.sh

"Static libs and .la files in the plugins directory" Hmm, I'm still working to find ways to improve the algorithm used for this, so I'm very glad for another example package which poses this challenge and helps improve the heuristics. First, real plugins should not be part of a devel package. and plugins *can* be static archives, as far as I can tell. And *.la files are always required by plugins even when they are shared objects. Can you confirm that the static objects really aren't needed by the other plugins and are not plugins themselves? (by temporarily removing them and checking functionality). By default, src2pkg copies *.la files into the dev package tree instead of moving them, because there are some corner cases where the *.la files are need to properly link shared libs. There is a lot of debate about 'allowing' other progs/libs to depend on *.la files- debian goes to great lengths to avoid this -implies removing all *.la files. You can do this with src2pkg, but I can't help you with any compiling-linking problems which come up...
You can do that by putting this in your conf file:
REMOVE_LIBTOOL_FILES="YES"

The code which tries to make sense of *.la and *.a files is located in 09-fix_pkg_perms starting at line 96, where lists of certain file-types are being created. The lists are then used later when segregating package content in 14-last_minute_details starting at line 544. On the one hand, if the static files are not plugins, nor used by the other plugins, then should never have been installed there -a bug in the source Makefiles, which could be fixed with a tiny patch to the Makefile.am/Makefile.in files in that source subdir. However, this new src2pkg version offers and arbitrary method for fixing this -you can supply a list of wanted files for use when creating 'devel' or 'solibs' packages, instead of relying on the algorithm. So, a file named rawstudio-devel.files in the CWD would take care of that for you. Also, if using a *.src2pkg script (hint, hint), you could remove the offending static files from the main package content before package-splitting occurs. Just after fake_install:
rm -f $PKG_DIR/usr/share/rawstudio/plugins/*.a

That really is an interesting example which I will try out -I see *.la files there with no corresponding *.a or *.so files, so it really does get thick...

"What does the '-1' mean?" That number is the BUILD number which is very important for packages. When you rebuild a package which has changes apart from the VERSION of the sources, this number should be incremented so that the rebuilt package is clearly distinguished from the original build -both visually and for being able to sanely upgrade a package. pets do not require it, but apparently the package manager can work work with them -they are used by slack packages and every ohter form of packaging except slitaz *.taz packages. What should trigger bumping this number? Re-compiling using different configuration options, or edits you have made to files included in the package -any minor changes at all. When you upgrade to a newer source version, then you use '1' again. You can set the BUILD from the command-line using the '-b=?' option, or preferably, you bump it in that nice *.src2pkg script you are using, accompanied by a comment to yourself about why you rebuilt it, what was changed.
Remember that, once you have a script, you only need to 'src2pkg -X' to run it as many times as needed till you have fixed everything needed to create the perfect package. Use the '--resume=fake_install' command-line option to avoid having to re-compile everything for long builds.

To all, of course src2pkg requires the devx file since what it normally does is to compile sources...

Did I get all the questions for now?
Back to top
View user's profile Send_private_message 
stu90


Joined: 25 Feb 2010
Posts: 1401
Location: England. Dell Inspiron 1501. Dpup

PostPosted: Thu 16 Feb 2012, 10:13    Post_subject:  

Hi Amigo,
I went a head an installed the updated version - it runs through the setup now with out any errors.

So far i have built yad and this worked Very Happy

Now onto something more complicated ( for a noob like me anyway ) i wish to build the latest version of tint2 panel.

running command to download tint2 source: svn checkout http://tint2.googlecode.com/svn/trunk/ tint2-read-only

i made the directory into a .tar.gz - then i run src2pkg on it, it get part way then fails on FAILED!! No INSTALL_LINE given. i know i should read the documentation but any quick tips would be appreciated.

Full terminal output:
# src2pkg /usr/src/src2pkg/builds/tint2.tar.gz
Found source archive: tint2.tar.gz
Creating working directories:
PKG_DIR=/usr/src/src2pkg/builds/tint-2-i486-1
SRC_DIR=/usr/src/src2pkg/builds/tint-2-src-1
Unpacking source archive - Done
Correcting source permissions - Done
Checking for patches - None found
Found 'cmake' configuration - Configuring using:
cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr -DLIB_SUFFIX= -DCMAKE_BUILD_TYPE=Release -DLOCALSTATE_INSTALL_DIR=/usr/var -DSYSCONF_INSTALL_DIR=/usr/etc
Skipping compile_source -
FAILED!! No INSTALL_LINE given.


cheers.

UPDATE:
ok i run through again this time with the option -VV i see there was a missing dependency - once installed and run again build completed and make a .pet - nice! Smile
Back to top
View user's profile Send_private_message 
amigo

Joined: 02 Apr 2007
Posts: 2252

PostPosted: Thu 16 Feb 2012, 11:18    Post_subject:  

This litle bit of output:
"Skipping compile_source -
FAILED!! No INSTALL_LINE given."
points there being no Makefile. In this case it means that configuration has failed. If you wonder why it didn't flatly fail when trying to configure, it is because the cmake routines are a little crude compared to autocnf configuration routines.

"So far i have built yad and this worked" -glad to hear that as it encourages you to keep on. It really is surprising how many sources are just that easy.

"src2pkg /usr/src/src2pkg/builds/tint2.tar.gz" That's really not a very useful version number. It would be good to re-name the original downloaded directory to something like:
tint-2-svn-20120216 and re-create your tarball. Then to make things really pretty (and useful), use:
src2pkg -n=tint2 -v=20120216 tint-2-svn-20120216.tar.gz
(if src2pkg fails to guess such values for such a name. Or you could ensure that by naming the archive tint2-20120216) Anyway, this illustrates how you can override the name or version number when needed. If you are using a *.src2pkg script then these options become:
ALT_NAME=tint2
ALT_VERSION=20120216

"noob like me anyway" src2pkg will make you shine and produce really professional-quality packages!
Back to top
View user's profile Send_private_message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Thu 16 Feb 2012, 11:54    Post_subject:  

amigo wrote:

"QUERY_FOR_EXTRA_CONFIGS=YES" You won't want this if your start using *.src2pkg scripts to record your builds. If you are really needing to manually input certain configure options, that is exactly when you should be using build scripts you you don't forget what options were needed, and to save the pause during building. But you could simply do this:


The primary use case for src2pkg on puppy is to enable non-experts to build things. More advanced users can easily turn this off, but newbies aren't going to read the documentation or understand what a recipe is or how to make one.

amigo wrote:
"Static libs and .la files in the plugins directory" Hmm, I'm still working to find ways to improve the algorithm used for this, so I'm very glad for another example package which poses this challenge and helps improve the heuristics. First, real plugins should not be part of a devel package. and plugins *can* be static archives, as far as I can tell. And *.la files are always required by plugins even when they are shared objects. Can you confirm that the static objects really aren't needed by the other plugins and are not plugins themselves? (by temporarily removing them and checking functionality). By default, src2pkg copies *.la files into the dev package tree instead of moving them, because there are some corner cases where the *.la files are need to properly link shared libs


Barry's packaging tool always moves all .a and .la files the the DEV package. So far, I have never seen a case where this has caused an issue. (Sometimes, however, it moves .so files that it should not, which does cause a problem).
Back to top
View user's profile Send_private_message Visit_website 
Display_posts:   Sort by:   
Page 1 of 4 Posts_count   Goto page: 1, 2, 3, 4 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Utilities
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1323s ][ Queries: 12 (0.0068s) ][ GZIP on ]