BionicPup32 (UPupBB) (27 June 2020)

[musher0]

Would you mind terribly if I wrote a script to combine the adrv, fdrv and ydrv of your Beaver/Bionic/Pup?

No problem whatsoever....

Thanks!

[musher0]

Hello peebee and all.

(I hope this post goes here.)
Please find attached the script announced above. With thanks to peebee
for his permission.

Users, please read the comments inside the script carefully before
running it, including the Notes at bottom.

Once the script has combined all the ?drv*.sfs archives in fdrv*.sfs, the
only thing left for the user to do will be, after rebooting BionicPup, to edit
file defaultbrowser at /usr/local/bin like so:

Code: Select all

#!/bin/sh
exec /usr/local/lib/light/light "$@"
# light "$@"

This edit will call the U_Light browser directly, instead of showing a
warning that the adrv*.sfs is not there (anymore).

Aside from that, don570's right-click menus work fine, as does everything
else, AFAICT. I think I gave this script a good go, but please report any
oddities. TIA.

A final note -- (edited for grammar, 21-06-2018)
Only BionicPup users who wish (was "which", sorry) to free the
"adrv*.sfs" position or archive to convert a BIG pupsave to an adrv -- as
an alternative to traditional remastering -- should use this script.

Because this BionicPup is a little wonder as it is! Bravo, peebee!
(I'm wrting this post from it now.)

TWYL.

~~~~~~~~~~~~~~~

Code: Select all

#!/bin/bash
# combine-drvs.sh
#
# Save this script under / Enregistrer ce script sous 
# /opt/local/bin OR/OU /root/my-applications/bin
# and make executable. / et rendre exécutable.
###
# Goal : reduce the number of ?drv*.sfs archives to one 
# in a Puppy that has a full complement of them. /
#
# Objectif : réduire le nombre d'archives ?drv*.sfs à une 
# dans un Puppy | Toutou qui les a toutes.
###
# Usage -- Important : utiliser ce script d'un autre Puppy | Toutou que BionicPup.
# ........ Ouvrir une console dans le répertoire de BionicPup et lancer ce script. 
# ........ Quand le script est terminé, redémarrer BionicPup. /
#
# Usage -- Important : run this script from another Pup than the BionicPup. <=-
# ........ Open a console in BionicPup's directory and run this script.
# ........ When done, restart BionicPup.
###
# -=> Please read the notes at bottom. / Veuillez lire les notes au bas de ce script. <=-
####
# © Christian L'Écuyer (alias musher0), Gatineau (Qc), Canada, 2018-06-16. GPL3.
# GPL3 licence in English: https://opensource.org/licenses/GPL-3.0
##########
#    Ce programme est libre : vous pouvez le redistribuer ou modifier selon les termes de la
#   Licence Publique Générale GNU publiée par la Free Software Foundation (v. 3 ou toute
#   version ultérieure choisie par vous).
#         Ce programme est distribué dans l'espoir qu'il sera utile, mais SANS AUCUNE
#   GARANTIE, ni explicite ni implicite, y compris des garanties de commercialisation ou
#   d'adaptation à un but spécifique. Pour plus de détails, veuillez vous reporter au
#   texte de cette licence à https://opensource.org/licenses/GPL-3.0 pour le texte officiel, à
#   http://www.linux-france.org/article/these/gpl.html pour une traduction et à
#   https://fr.wikipedia.org/wiki/Licence_publique_générale_GNU pour une explication en français.
################
####

for archive in `ls -1 ?drv* | grep -v zdrv`;do
	unsquashfs -d "${archive:0:4}" "$archive"
	wait
	mv -f $archive $archive.bckp
	wait
done

cd fdrv 
for combine in adrv ydrv;do
	rsync -avzm ../$combine/* .
	wait
done

cd ..
mksquashfs fdrv fdrv_upupbb_18.05.sfs -noappend -all-root -b 1048576 -comp xz -Xdict-size 100%
wait

for ReP in adrv fdrv ydrv;do 
	rm -rdf $ReP/*
	rmdir --ignore-fail-on-non-empty $ReP
done
exit

### Notes ###
EN -- Back-ups of the ?srv*.sfs archives are made: do not erase them.
This script has been tested. But should something go wrong, in console, type
	mv -f ?drv_upupbb_18.05.sfs.bckp ?drv_upupbb_18.05.sfs
(Replace the ? with the letters a, f and y.)

FR -- Des sauvegardes des archives ?srv*.sfs sont faites : ne les effacez pas.
Ce script a été testé. Si quelque chose n'allait pas, en console, taper
	mv -f ?drv_upupbb_18.05.sfs.bckp ?drv_upupbb_18.05.sfs
(Remplacer le ? par les lettres a, f et y.)
##################

[picatrix]

Thanks Peebee, Thanks Musher0,
I'll follow your precious advices!

[Mike Walsh]

Hi, all.

Now then; would appreciate a wee bit of advice.

Currently running 18.05+1. I've swapped over the contents for those of 18.05+5, but could someone please explain to a dunderhead what it is I actually do with the 'delta'.....and how do I use it? And will it do whatever it is that it does with my 'old' save-file from 18.05+1 loaded.....or does this need to be done with 18.05+5 in 'pristine' condition?

My own fault, I confess; I simply haven't got involved enough in the 'testing' side of things to have become aware of this stuff. I've preferred to concentrate on the Pups I have installed which I really like, and to 'develop' those to the extent which I prefer.

TIA.


Mike.

[Terry H]

Hi Mike, hope this helps.
The delta is applied to the original iso generating a new iso image. When delta 1 is applied to upupbb-18.05.iso will generate upupbb-18.05+1.iso. The contents of the deltas for upup bionic are accumulative, so delta-5 applied to upupbb-18.05.iso, generates upupbb18.05+5.iso. Put the delta in the same folder as the iso and click it and it'll do its stuff.

[davids45]

G'day Mike W.,

In the Utility menu is the gui X-delta difference manager.

Drag the specified original iso to its location (see screenshot).
Drag the delta file to its location.
Click the button to generate the new iso.

The new iso will probably be where the old original is.

Note, you can only use the specified original iso, as per the delta file name, not necessarily the last iso you have. I speak from considerable experience (of doing the wrong thing ).

David S.

[Mike Walsh]

Hi, Terry.

Ah. So, having downloaded (and am about to use) the 18.05+5 .iso, then I don't actually need to use the delta at this point in time?

Or I could apply the 'delta' to the existing 18.05+1 that I've been using, and it would then 'generate' a new. 18.05+5 .iso?

('Salright; I ought to get a handle on this stuff at some point.....even though I'm not one of those folks who regularly switch to the very newest versions the instant they come out. I like to let distros 'prove' themselves, and 'get the bugs outta the system' and settle down.....typically not bothering with new versions for around a year.)


Mike.

[Mike Walsh]

Hiya, David.

Mm. O-kayyy....

So; to test my knowledge here, as things stand, I've downloaded the newest iteration (18.05+5), and the 'new' devx (bandwidth hasn't been a problem for me for around 2 1/2 years now, ever since we went 'unlimited' back in Jan 2016).

If I've got this right then, I can just go right ahead and use these with my existing save-file, yes? (Please correct me if I'm wrong; I'd rather get this right from the beginning, instead of messing about and having to re-do things again & again..!)

Haven't quite got the patience I used to have.....to say nothing of having considerably less spare time. And I didn't get hold of the original 18.05 anyway; by the time I decided to try this, peebee had already changed the link in the first post to that of 18.05+1....


Mike.

[mikeslr]

If I've got this right then, I can just go right ahead and use these with my existing save-file, yes?

Yes, and occasionally No. Deltas upgrade the operating system. If a puppy creator has published a system change (as by way of a pet or recommended edit of a system file) and you've applied it, that change is part of your SaveFile/Folder. It would unnecessarily duplicate the change provided by the delta, or perhaps conflict with it. As far as I recall, peebee hasn't done that for upupbb or other Puppies. But other Devs might.

Similarly, you, yourself, may have effected an operating system change.

So if all that your SaveFile/Folder only holds are 'normal-user-work' applications and their configurations nothing needs to be done. But system changes made before upgrading via a delta --just like those before replacing a prior ISO's content with a newer version-- should probably be removed from a SaveFile/Folder.

mikesLr

[jrb]

I didn't get hold of the original 18.05 anyway; by the time I decided to try this, peebee had already changed the link in the first post to that of 18.05+1....

Here's the link to where you can download upupbb-18.05.iso. The deltas are in the updates folder and the devx is in the appropriately named folder. I don't know how good your internet service is but I find it well worth while to download 20MB as opposed to 270MB.

Cheers, J

[Terry H]

There should be some capacity to cheat a bit. I would think you would end up with the same result by changing the 18.05 +1.iso to 18.05.iso and applying the delta to it.

[jrb]

There should be some capacity to cheat a bit.

Good lateral (devious?) thinking there , but it checks the md5 and rejects anything but the original.

[peebee]

There should be some capacity to cheat a bit. I would think you would end up with the same result by changing the 18.05 +1.iso to 18.05.iso and applying the delta to it.

Some comments to the discussion above:

- the deltas do have to be applied to the original 18.05.iso - I will add a link to the 1st post

- you don't have to use the xdelta gui - you just put the delta into the same folder as the 18.05.iso and then click on the delta file

- you can't cheat as the xdelta checks the md5

- the contents of the new .iso are identically named to the original - all you have to replace (in your frugal install) is the puppy.sfs - therefore a savefile can be reused and will not be updated on reboot

- reverse_updates are now available

[jrb]

reverse_updates are now available

Downdates?

[Mike Walsh]

Hm. O-kay. I see..... (I think!)

Right, then; bearing in mind that I started with 18.05+1, and am using a (by now) heavily-customized save-file built using that particular release, what's the best way to achieve 18.05+5 status, and still continue with the existing save-file?

Remember; I've already downloaded the 18.05+5 .iso, and the delta. Surely it makes more sense to simply use the contents of the new .iso file, than to also download the original 18.05 .iso, mess around with the delta, and generate 18.05+5 that way? My save-file wasn't built using the original in any case.....

Ah, well; I'll back Bionic up, then have a go at this. Which brings me to another point I'd forgotten; normally, backing up most of my Pups, which on average have a 50-60% full 6 GB save-file, takes around 3-4 mins, tops. For some reason, backing up Bionic's directory always seems to take the best part of an hour.....but there's exactly the same stuff installed....

Any thoughts?

Here's the link to where you can download upupbb-18.05.iso. The deltas are in the updates folder and the devx is in the appropriately named folder. I don't know how good your internet service is but I find it well worth while to download 20MB as opposed to 270MB.

Since we went 'unlimited', some 2½ years ago, d/l speed is actually darned good. Upload speed, however, is a whole 'nother 'ball-game'.....

Example; I d/l'ed Bionic's .iso in around 8-10 seconds. But if I upload, say, a 5 MB file to MediaFire or Google Drive, it'll take 40-50 seconds once the transfer commences. I know 'net traffic tends to be heavily biased toward d/ls as opposed to u/ls, but the difference there is rather noticeable, don't ya think??


Mike.

[Marv]

Since we went 'unlimited', some 2½ years ago, d/l speed is actually darned good. Upload speed, however, is a whole 'nother 'ball-game'.....

Example; I d/l'ed Bionic's .iso in around 8-10 seconds. But if I upload, say, a 5 MB file to MediaFire or Google Drive, it'll take 40-50 seconds once the transfer commences. I know 'net traffic tends to be heavily biased toward d/ls as opposed to u/ls, but the difference there is rather noticeable, don't ya think??

Our download:upload is 16:1, I think not atypical. Since we're not 'cloud' people we really don't notice and coming from the acoustic modem stone age an honest 16 Mbps download speed still makes me smile

[jrb]

normally, backing up most of my Pups, which on average have a 50-60% full 6 GB save-file, takes around 3-4 mins, tops. For some reason, backing up Bionic's directory always seems to take the best part of an hour.....but there's exactly the same stuff installed....

That does seem excessive! I'd be looking to see what's in that directory, maybe use Gdmap from the filesystem menu to do a thorough analysis. BTW how are you backing it up?

[Mike Walsh]

@ jrb:-

That does seem excessive! I'd be looking to see what's in that directory, maybe use Gdmap from the filesystem menu to do a thorough analysis. BTW how are you backing it up?

Simple copy'n'paste, as I've always done. If in its own partition, I copy the contents of the partition; if in a sub-directory, I copy the contents of the directory. Never used any backup tools, as such; never found there to be any need. Unless of course the new Woof-CE build-system now no longer really supports doing this.....or is this a Canonical 'thing', as opposed to a general Linux 'thing'??

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

Our download:upload is 16:1, I think not atypical. Since we're not 'cloud' people we really don't notice and coming from the acoustic modem stone age an honest 16 Mbps download speed still makes me smile

Yeah; sounds about right (I guess). Your d/l speed is around the same as ours; varies between 15-18 MBps, depending on the day of the week, time of day, the time of year.....etc., etc. I'm more than happy with those kinds of figures, since about the most intensive thing I normally do online is watch NetFlix (which runs quite happily).


Mike.

[davids45]

G'day Mike W.,

I think you could try some of Puppy's back-up packages - I've had little trouble with these for a few years now.

For frugals:
I've found a very efficient save-file back-up package in the Utility menu ("Pupsave Backup").
The appended screenshots show how I use it, now on a very frequent basis.
Two compressions are offered if compression is chosen for the back-up.
The back-up name includes the Frugal's full name, date and time created (last screenshot) so several back-ups of the same Pup can be sorted quickly to find the latest or to delete the earlier ones.
I store these back-ups in a dedicated directory on a data partition.

For partitions:
I use another Puppy back-up ("Puppy Backup" in the menu shot) to regularly back-up (mirror) my data partitions, my frugals' partitions, and my boot partition to a 1TB USB drive.

David S.

[Mike Walsh]

Hi, David.

I take your point, and, er, appreciate what you're saying.

One of the main reasons I back-up the way I do is because it's quicker. I'm not denigrating the effort the writers of these tools have put in to get them to look (and work) correctly. But you must admit, they're really for beginners to Puppy.....to make it as easy as possible for them. And Pup's 'Utility' section does indeed look very professional these days; all credit to everyone involved!

I'm essentially using the mechanism behind the tool, I guess.....in very much the same way as those of us who've been with Puppy for a while often use the 'quick'n'dirty' method for setting up new Pups. We know what we're doing, and just do it.....whereas it'd take longer to explain to a beginner how to do this than it would to let them use the PUI in the first place (which was put together for just this purpose, of course.)

I've often considered putting together my own YAD-based GUI 'front-end' for my back-ups.....just to give me some eye-candy while the process is going on in the background!!

I may have a look at these tools, and try them out. I'll certainly have a look at the scripts, now.


Mike.