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 Sat 19 Oct 2019, 23:36
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
Auto-build a Puppy iso; single script with optional gui
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 21 of 22 [325 Posts]   Goto page: Previous 1, 2, 3, ..., 19, 20, 21, 22 Next
Author Message
666philb


Joined: 07 Feb 2010
Posts: 3491
Location: wales

PostPosted: Mon 18 Mar 2019, 16:03    Post subject:  

does bionic work?
_________________
Bionicpup64 built with bionic beaver packages http://murga-linux.com/puppy/viewtopic.php?t=114311
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1812
Location: not Bulgaria

PostPosted: Mon 18 Mar 2019, 16:05    Post subject:  

That would help greatly 666philb and might well lead to a makepup fix.

I only had a ridiculous 35 MB (!) left on my laptop - hence my resorting to woof-CE builds to a slow external usb HD. However, this morning I've been moving things around so now have 5 GB free on main harddrive so hoping that proves to be enough and should speed things up a lot for me (except for the rural broadband speed issue).

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1812
Location: not Bulgaria

PostPosted: Mon 18 Mar 2019, 16:06    Post subject:  

straight woof-CE-created bionicpup64 booted okay but with the icons missing and menu not starting up apps as far as I remember - I'm not in that now since preparing for a new build.

@666philb I don't know if something odd simply happened during the long build which is why I'm hoping for test results from others - your test would be the best of course.

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1812
Location: not Bulgaria

PostPosted: Mon 18 Mar 2019, 22:31    Post subject:  

s243a wrote:

"/usr/local/apps/ROX-Fler/ROX"
(made similar changes to other users)


EDIT: Drat - just noticed the most recent build I made (via woof-CE scripts and not using makepup) was infact a XenialPup64 (I pressed wrong number at the terminal...). Oh well, currently using makepup to build a BionicPup64... but makes comparison tricky... and slow build since all packages need downloaded 'again'...

Thanks for you comments s243a. That link is already correct in the builds I've tried. I've since made a new woof-CE build (without using makepup) of BionicPup64 (using the testing branch I downloaed yesterday); EDIT: per other EDIT above, was actually a XenialPup64 build. I note that the default background is dark grey but I made it a different image this time so desktop background does actually seems to work ok. However, the icon images certainly still do not appear.

I note that there is no gtk-update-icon-cache program on the (XenialPup64) system (which was one of the error messages), or at least I couldn't find it...; I do know that would mean that if I installed my own dotpet weX program, its icons couldn't be found (since in that dotpet I call up gtk-update-icon-cache). That may or may not be the problem with the woof-CE build for BionicPup64 (not sure if same for XenialPup).

Oh, I also note error message still in ERROR-2CREATEPACKAGES:

Code:
ERROR: 'diffutils' package does not exist.


I'll now attempt another makepup build of the same since my harddisk space proved large enough... Then I'll compare the difference.

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1812
Location: not Bulgaria

PostPosted: Tue 19 Mar 2019, 01:18    Post subject:  

Okay, so now build BionicPup64 using makepup. Iso was created but result was no Rox pinbrd - most everything else seems to work but maybe not rox filer either (I'll have to check that later). I did check in /root/Choices and found there was no ROX-FILER directory... Note that gtk-update-icon-cache binary was on that system though, so nothing to do with that in this case anyway I guess.

So I'm currently suspecting something to do with rox-filer, but I could well be wrong. I note that the dotpet for that is xz compressed, though I presume that isn't a problem? Anyway, seems to be more to do with the configs or at least that missing ROX-FILER directory...

Oh well, I'm going to try making new BionicPup64 again now but without using makepup (just woof-CE scripts) so that I can compare any difference.

wiak

EDIT: Just a note for myself really. I think straight woof-CE build making okay but makepup failing to take root/Choices/ROX-FILER stuff at least out of rootfs-packages into sandbox3 when 3builddistro-Z is running. I'm just guessing from what I see as terminal output as woof-CE scripts running. But I'll take a close look at the 4builddistro-Z script to see where/how that bit is done to see if makepup missed something in something or other that may have changed upstream in woof-CE scripts.

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130

Last edited by wiak on Tue 19 Mar 2019, 02:02; edited 1 time in total
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2131

PostPosted: Tue 19 Mar 2019, 01:53    Post subject:  

wiak wrote:
Note that gtk-update-icon-cache binary was on that system though, so nothing to do with that in this case anyway I guess.

was the "/root/.icons" folder there and did it have at least one subdirectory (or symlink to a sub-directory) that contained an index.theme file? Also I think the name of the icon theme might have to match the name of the subdirectory in the .icons folder.

Quote:
So I'm currently suspecting something to do with rox-filer, but I could well be wrong.

redirect both the standard error and standard output to a file. If you put the following in the files I think it redirects all output streams to a log file:
Code:

exec &> >(tee -a "$log_file")

https://unix.stackexchange.com/questions/145651/using-exec-and-tee-to-redirect-logs-to-stdout-and-a-log-file-in-the-same-time
and if you want more output you can put a "set -x" before the above statment.

Anyway, I have a long shot fix for you:
Code:

cd /usr/share/rox-filer
ln -s rox-filer ROX-Filer
   
cd /usr/bin
ln -s rox-filer roxfiler   

I did this in my attempted build of a TazPup64. I thought that the rox-filler executable might be named differently in the puppy package than the tazpup package. However, maybe the name of the executable changed in more recent versions of rox.

Quote:

I note that the dotpet for that is xz compressed, though I presume that isn't a problem? Anyway, seems to be more to do with the configs or at least that missing ROX-FILER directory...

Oh well, I'm going to try making new BionicPup64 again now but without using makepup (just woof-CE scripts) so that I can compare any difference.

wiak

Last edited by s243a on Tue 19 Mar 2019, 02:14; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
wiak

Joined: 11 Dec 2007
Posts: 1812
Location: not Bulgaria

PostPosted: Tue 19 Mar 2019, 02:07    Post subject:  

Yes, at the moment s243a I'm noticing that woof-CE script seems to have built the sandbox3 ROX-FILER stuff correctly. Makepup's on-the-fly mod of the relevant woof-CE script seems to be missing something. I'm not trying to patch the iso makepup is producing, rather I'm trying to find the error in makepup's on-the-fly mods to that relevant 3builddistro-Z script. I could patch the result to make it work, but that's not my goal. So now I'll test the woof-CE build to double-check that one is okay, and then I'm going to look carefully at 3builddistro-Z mods that makepup makes to see what is going wrong (assuming that is the script where makepup is messing things up...).

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1812
Location: not Bulgaria

PostPosted: Tue 19 Mar 2019, 02:26    Post subject:  

Good news for woof-CE builders! My test build of BionicPup64 seems to be fine (didn't use makepup for this). Posting from the build now. My earlier XenialPup64 woof-CE only build did have some issues though with icon images not appearing - that's not makepup issue.

Unfortunately for me...!... that means makepup is broken somewhere, which isn't surprising since I haven't been keeping up with woof-CE changes...

Anyway, now I need to find where makepup has messed up - it won't be much, since only really ROX pinboard related stuff - but may or may not be easy for me to spot. But like I said in posts above, I have some clues... and will report back later with success or failure...

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
666philb


Joined: 07 Feb 2010
Posts: 3491
Location: wales

PostPosted: Tue 19 Mar 2019, 11:49    Post subject:  

hi wiak,

i've had a look, the problem with your makepup and bionicpup64 is that bionicpup64 needs rox_config="true" setting in /support/rootfs-packages.conf
you may want to look at your version of that file as there's duplicate contradictory entries in it. (probably xenial and tahr need it setting to true as well)

i've fixed the icon issue in xenialpup64 .. this was caused by /usr/sbin/icon_switcher inside the z_xenialfix64.pet which was one of the scripts i had thought i had removed.. it is now.

note that i've made some changes in the z_fixes.pets for xenial & tahr to bring it into line with modern woof and the new location for rox mimetypes in /etc/xdg/rox.sourceforge.net so you will need to delete those and re-download them.

also there's a couple of recipe fixes for the xenials commited to woofce, so you may want to get the latest testing (updated llvm and add libqpdf21 for cups.

as for xerrs.log errors in xenial. i believe these are mostly cause by packages being compiled against older version of libs probably glib (ubuntu have updated lots of libs since xenialpups release).
recompiling geany, rox etc in the new xenial might fix that (but i'm not doing that :p).

_________________
Bionicpup64 built with bionic beaver packages http://murga-linux.com/puppy/viewtopic.php?t=114311
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1812
Location: not Bulgaria

PostPosted: Tue 19 Mar 2019, 16:03    Post subject:  

666philb wrote:
hi wiak,

i've had a look, the problem with your makepup and bionicpup64 is that bionicpup64 needs rox_config="true" setting in /support/rootfs-packages.conf
you may want to look at your version of that file as there's duplicate contradictory entries in it. (probably xenial and tahr need it setting to true as well)

i've fixed the icon issue in xenialpup64 .. this was caused by /usr/sbin/icon_switcher inside the z_xenialfix64.pet which was one of the scripts i had thought i had removed.. it is now.


Thanks phil, I'll do a rebuild using makepup today and taking your comments into account, double check and hopefully make all things with makepup well. Should be simple enough based on your comments above. More generally, when a non-makepup build works and a makepup build doesn't, it is a matter of doing a quick diff between the makepup 'modified' versions of woof-CE scripts against the original, which is what I was going to do today and still will - but first I'll rebuild BionicPup64 using new dowload of testing.zip from woof-CE github.

I'm a bit slow fixing makepup because I'm mult-tasking just now: working on dropbox client installs (official and from the forum here) for my partner on another machine (official client giving me some problems...) and also working on void linux installation matters on a third machine I have running alongside. I'm not too great at such multi-tasking since my brain doesn't then focus long enough on any one issue...

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1812
Location: not Bulgaria

PostPosted: Tue 19 Mar 2019, 16:59    Post subject:  

@phil:

Ah, okay! Since makepup has no ArtificialIntelligence, it cannot know whether rootfs-packages.conf-backup is to be used in the build or not for its attempted purpose of doing an unattended build.

The problem is that woof-CE supplies rootfs-packages list not as support/rootfs-packages.conf but rather as rootfs-packages.conf-backup, which doesn't actually get used unless human intervention renames it! That makes makepup's attempt at unattended build somewhat difficult... I obviously realised that when I wrote makepup because I did put a checkbox in Advanced tab options for 'allow pop-up "choose extra rootfs packages"'.

(If I remember correctly, though have to still check)It is that gui, when it pops up, that then writes/creates-new the rootfs-packages.conf that turns out to be needed for BionicPup64 case. So nothing wrong per se with makepup - just need to click that advanced option before making BionicPup64 build. But why??! cannot woof-CE supply the file rootfs-packages.conf rather than a needing renamed rootfs-packages.conf-backup when the distro builder wants that to be used???

As things stand, in 3builddistro-Z script the user has to perform a Ctrl-C and rename that file (removing -backup part of extension) to avoid getting what should often be unnecessary pop-up). Makepup gets round that Ctrl-C need by generating its own rootfs-packages.conf list, but not everything that is included as possibilities in support/rootfs-packages directory of course. Problem is, without AI it cannot determine what the distro builder wants to use (that is what support/rootfs-packages.conf is for, but alas it is supplied needing renamed from rootfs-packages.conf-backup... But please, it should be somehow supplied not needing that renaming... (or the pop-up...). The code I'm talking about in 3builddistro-Z.

EDIT: Though the issue is really caused by code/idea in merge2out, I think, since that's where rootfs-packages.conf appears to be first created with extension .conf-backup (in some code I see by peebee "to avoid checkbox GUI"). I haven't yet checked what happens to that in terms of what the actual distro builder wants. Yes, I think it is that peebee code that is my issue... I realise of course that unattended build wasn't part of woof-CE design, but I really don't think that conf-backup mechanism is a good one (certainly a pain for makepup....). Rather would be better at that merge2out stage to create rootfs-packages.conf itself? (not rootfs-packages.conf-backup, and think of other way to get optional pop-up for re-selection. Having to break out with a Ctrl-C (as now in builddistro-Z) is ugly (though understandable in the circumstances of current script code) and has these consequencies makepup is facing: EDIT: but maybe fine afterall if my post a couple of posts down is correct about DISTRO_PKGS_SPECS-ubuntu-bionic since woof-CE build did work, just not the makepup one...

In merge2out:
Code:
# new to avoid checkbox GUI; idea from peebee. See 3builddistro-Z
(
cd ${WOOF_OUT}
rm -f support/rootfs-packages.conf-backup 2>/dev/null
ls rootfs-packages|while read pkg;do
   echo -e "$pkg=\"true\"" >> support/rootfs-packages.conf-backup
done
)



[end EDIT]

I guess I'll have to raise an issue on woof-CE github with suggestion how to better do this.

Code:
if [ ! -f support/rootfs-packages.conf ];then
   echo
   echo "If you know what packages you want included from rootfs-packages
you can bypass the checkbox GUI by renaming

'support/rootfs-packages.conf-backup'

to

'support/rootfs-packages.conf'

and edit it to include your customised package list.

You can CTRL-C out of this script and try it right now if you wish
or hit Enter/Return to continue."

   read carry_on

   for d in $(ls rootfs-packages)


Meanwhile, looks like maybe nothing wrong with makepup code itself - just need to check box for rootfs-packages pop-up gui in Advanced options prior to attempting the build. I'll check that now with another build using makepup. Of course maybe I've misunderstood the issue or other things have also gone wrong, but I'm hopeful all will be well this time.

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130

Last edited by wiak on Tue 19 Mar 2019, 18:38; edited 2 times in total
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1812
Location: not Bulgaria

PostPosted: Tue 19 Mar 2019, 17:30    Post subject:  

Come to think of it though (looking at the woof-CE and makepup code again), why is it necessary to manually rename support/rootfs-packages.conf-backup for a BionicPup64 build since the gui popup code looks at DISTRO_PKGS_SPECS-${DISTRO_BINARY_COMPAT}-${DISTRO_COMPAT_VERSION} and should pick that rox_config config is need (EDIT: oh... it doesn't though, or does it? - so I'm not sure yet what goes on here). I have to look more into that, in case something else is wrong or changed comparing pop-up code in 3builddistro-Z compared to that mechanism in makepup.

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1812
Location: not Bulgaria

PostPosted: Tue 19 Mar 2019, 17:41    Post subject:  

Surely this was the error in provided woof-CE BionicPup64 recipe phil:

DISTRO_PKGS_SPECS-ubuntu-bionic

Code:

...
yes|rox-filer||exe,dev,doc,nls
no|rox_config||exe,dev,doc,nls


That wouldn't be a makepup issue but a woof-CE github recipe issue if so. It does look wrong to me.

With that fixed upstream on woof-CE, all the other stuff probably fine?

Except, I seem to be missing something in my understanding since main woof-CE build of BionicPup64 did work so rox_config was being handled somehow despite above 'no'

I note that you've fixed the xenial diffutils error in woof-CE recipe now, phil, but I can't understand why it shouldn't be yes|rox_config for bionicpup64.

wiak

EDIT: This builddistro-Z code for popup seems to be what fixes rox_config to true:
Code:

         *)
            if grep "yes|${d}|" DISTRO_PKGS_SPECS-${DISTRO_BINARY_COMPAT}-${DISTRO_COMPAT_VERSION} ;then
               state=false # don't overwrite user chosen specs
            else
               def=true
            fi


But if pop-up not run then with BionicPup64 recipe as it is then human intervention to rename rootfs-packages.conf-backup to rootfs-packages.conf seems to be necessary. But surely DISTRO_PKGS_SPECS-ubuntu-bionic is actually the culprit here and needs fixed to say yes|root_config rather than 'no'.

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1812
Location: not Bulgaria

PostPosted: Tue 19 Mar 2019, 19:12    Post subject:  

Please refer to my immediately above post.

I have since made a makepup build of BionicDog64 after checking the advanced makepup option to allow rootfs-packages popup gui. The build was successful (booted and all Rox stuff seems fine - posting from it now), so it does indeed seem that nothing is wrong in makepup itself.

Problem is, it seems that pop-up needed to be allowed because, it seems to me, no|rox_config in DISTRO_PKGS_SPECS-ubuntu-bionic is wrong. It should surely be yes|rox_config. I may be wrong, but have raised the issue on woof-CE github for fix or explanation there. Alternatively, the mechanism that employs a rootfs-packages.conf-backup could be changed to allow distro author to make actual required rootfs-packages.conf without human intervention (ctrl-C) that would apparently currently be needed to rename that file to rootfs-packages.conf (in order to avoid that pop-up).

Anyway, unless I receive comments to the contrary, I will now finally (shortly after final small check and a cup of coffee or three) re-upload makepup latest version (only changes are those small filter alterations suggeted by rerwin for pets2add - I have not endeavoured at this stage to tidy up the official repo entries concerned, but that doesn't stop build working. I may leave extra dev work on makepup to others shortly (and hopefully they will also incorporate the use of sc0ttman's pkg program for pets2add/pkgs2add type mechanisms - tho of course woof-CE github should actually replace its own pkg add mechanisms with similar use of pkg).

EDIT: Actually, I might make an internal makepup fix that will also leave rox_config as 'yes', though really I feel the DISTRO_PKGS_SPEC is the place that should really be done (so my change would just cover that having been missed). [EDIT2: Nah, that current woof-CE mechanism seems wrong to me]. I am a bit confused with that pop-up code though - it seems to ignore the no|rox_config entry in existing bionicpup64 DISTRO_PKGS_SPEC and force it to state yes in the pop-up... what's the point of that, or am I missing something? On the basic of that confusion I think I may just post current makepup as it is, since it does work (just remember to check box to allow rootfs-package gui popup selection for now); I'll then briefly experiment with modified makepup and upload that as newer version if it works... (the pop-up code has been changed since makepup written so that could be reflected in makepupextraconf function).

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130

Last edited by wiak on Tue 19 Mar 2019, 20:09; edited 4 times in total
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1812
Location: not Bulgaria

PostPosted: Tue 19 Mar 2019, 19:35    Post subject:  

Note that I also doubt this woof-CE github code change made some time or other is right:

builddistro-Z code for popup seems to be what fixes rox_config to true:
Code:

         *)
            if grep "yes|${d}|" DISTRO_PKGS_SPECS-${DISTRO_BINARY_COMPAT}-${DISTRO_COMPAT_VERSION} ;then
               state=false # don't overwrite user chosen specs
            else
               def=true
            fi


It used to be:

Code:
    *)
      if grep "|${d}" DISTRO_PKGS_SPECS-${DISTRO_BINARY_COMPAT}-${DISTRO_COMPAT_VERSION} |\
        grep -q '^yes' ;then
          : # don't overwrite user chosen specs
      fi
    ;;


Is it not the case that the newer code is in fact overwriting user chosen specs in DISTRO_PKGS_SPECS via def=true? I'm not sure since haven't studied the code enough as yet, but I wonder about it... At least, as written it is overwriting 'no' entries surely? I can no longer remember the difference between state=true and def=true; I'll have to re-read some of the code to work that out again... I think 'state=false' just means not being able to select that checkbox whereas def=true ticks it?; in which case 'no' entries would be getting changed to 'yes' and thus defeating DISTRO_PKGS_SPECS config instructions (why???).

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 21 of 22 [325 Posts]   Goto page: Previous 1, 2, 3, ..., 19, 20, 21, 22 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


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