AB-Com PULSe 4K SE. Crazy offer only £99! FREE UK DELIVERY!
Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £99! FREE UK DELIVERY! 4K UHD, Enigma 2, Multiboot 4 images & more!...
AB-Com PULSe 4k Rev II Twin tuner only £149! FREE UK DELIVERY!
Superb quality and spec AB-Com PULSe 4K Rev II Twin Satellite tuner only £149! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...

Testers required for OpenViX Python 3 images

Status
Not open for further replies.
FYI the feeds server at 93.x.x.x6 is off the air - assume that's a private server!
 
white_westie said:
No its not the boxes, it's what sources are being used for the builds.
Think it might be down to the fact that the guys building/hosting the images are using their own servers, so probably their own sources as well.
Given that this is alpha/beta testing, then things might be different.

Speaking of sources, is the update to P3 a cross team approach?
Is there a public GIT for the P3 build for VIX?
Also, going forward, will the python source files be part of the finished build, or is that just a temp thing during testing?
Click to expand...
"Think it might be down to the fact that the guys building/hosting the images are using their own servers, so probably their own sources as well.
Given that this is alpha/beta testing, then things might be different."
Hopefully not as all the elements are built from the OE-A see https://github.com/oe-alliance/build-enviroment https://github.com/oe-alliance/oe-alliance-core

"Speaking of sources, is the update to P3 a cross team approach?"
No - every image does its own thing! Both Huevos and I keep an eye on the other images - I atch all the py3 changes (why re-invent the wheel) but most of the other image developers seem totally blind (or NIH) - my view!

"Is there a public GIT for the P3 build for VIX?" https://github.com/OpenViX/enigma2/tree/Dev-python3-compatible

"Also, going forward, will the python source files be part of the finished build, or is that just a temp thing during testing? "
thats python3 in action - only .py/pyc
 
Huevos said:
I don't understand this. I just tried 5.3 and 5.4 backups and they work. Should be able to restore any backup from 4.2 onwards.
https://github.com/OpenViX/vix-core/blob/master/src/BackupManager.py#L74
Click to expand...

I don't know what to say, other than the FIW refused to let me restore from a 5.4 backup - see post #63 for my initial bug report. All has been ok since, apart from the various python 2/3 issues which have been resolved as they are found.

EDIT - having read the remainder of the messages, maybe it's down to the initial build? I was using @twol's build for the AX61.
 
Last edited:
twol said:
Ok - that change all works (I had left a hook in the wizard)
I will post the changes later if not done before by someone


Thanks White_Westie!!


I am assuming it will be backward compatible!
Click to expand...

Repeated test on ET8000 running 5.4.012, and it seems work okay!

Code: 
root@et8000:/media/hdd/backup/tt# which tar
/bin/tar
root@et8000:/media/hdd/backup/tt# ls -l /bin/tar
lrwxrwxrwx    1 root     root            19 May 14 18:16 /bin/tar -> /bin/busybox.nosuid
root@et8000:/media/hdd/backup/tt# tar --version
tar: unrecognized option '--version'
BusyBox v1.31.0 (2021-05-03 12:00:47 UTC) multi-call binary.

Usage: tar c|x|t [-ZzJjahvokO] [-f TARFILE] [-C DIR] [-T FILE] [-X FILE] [--exclude PATTERN]... [FILE]...

Create, extract, or list files from a tar file


Code: 
root@et8000:/media/hdd/backup/tt# ls -l /tmp/backupimageversion
-rw-r--r--    1 root     root             3 Jun 12 13:43 /tmp/backupimageversion

root@et8000:/media/hdd/backup/tt# rm /tmp/backupimageversion

root@et8000:/media/hdd/backup/tt# tar -xzvf ./z1.tar.gz tmp/backupimageversion -C /
tmp/backupimageversion
root@et8000:/media/hdd/backup/tt# ls -l /tmp/backupimageversion
-rw-r--r--    1 root     root             3 Jun 12 13:43 /tmp/backupimageversion

root@et8000:/media/hdd/backup/tt# rm /tmp/backupimageversion

root@et8000:/media/hdd/backup/tt# tar -C / -xzvf ./z1.tar.gz tmp/backupimageversion
tmp/backupimageversion

root@et8000:/media/hdd/backup/tt# ls -l /tmp/backupimageversion
-rw-r--r--    1 root     root             3 Jun 12 13:43 /tmp/backupimageversion
 
twol said:
@All - have updated Restorewiz and BackupManager on Git.
Click to expand...

Cheers, but isn't the problem caused by the wrong version of tar (GNU) being built in some images?

Agreed, moving the -C option does no harm, but it's been where it was for 9 years+.
 
ccs said:
Cheers, but isn't the problem caused by the wrong version of tar (GNU) being built in some images?

Agreed, moving the -C option does no harm, but it's been where it was for 9 years+.
Click to expand...

Both the builds of my p3 images and my own Git images are built off the same OE-A and on the same PC. So why the difference? - I have no idea & providing it works both ways not an issue.
 
twol said:
Both the builds of my p3 images and my own Git images are built off the same OE-A and on the same PC. So why the difference? - I have no idea & providing it works both ways not an issue.
Click to expand...

Surely, getting different versions of tar is the issue? What else might be happening?
 
Just a random google comes up with "BusyBox Tar shows different ownership than GNU Tar".

Might be totally irrelevent.
 
ccs said:
Surely, getting different versions of tar is the issue? What else might be happening?
Click to expand...

For the record, I did a crosscheck between my P2 and P3 versions for busybox commands, and as far as I can see, it's only the tar command has gone standalone!
 
white_westie said:
For the record, I did a crosscheck between my P2 and P3 versions for busybox commands, and as far as I can see, it's only the tar command has gone standalone!
Click to expand...

Cheers, here's my P3 /bin non-busybox commands. :)

Code: 
ls -l /bin |grep -v busy
lrwxrwxrwx    1 root     root            14 Jul 17 09:34 bash -> /bin/bash.bash
-rwxr-xr-x    1 root     root        822380 Jul 10 11:30 bash.bash
lrwxrwxrwx    1 root     root            10 Jul 17 09:34 editor -> /bin/vi.sh
-rwxr-xr-x    1 root     root          2001 Jul 10 11:50 fake-hwclock
lrwxrwxrwx    1 root     root            20 Jul 17 09:34 false -> /bin/false.coreutils
-rwxr-xr-x    1 root     root         18060 Jul 10 11:37 false.coreutils
lrwxrwxrwx    1 root     root            16 Jul 17 09:34 kill -> /bin/kill.procps
-rwxr-xr-x    1 root     root         18060 Jul 10 11:36 kill.procps
-rwxr-xr-x    1 root     root         96168 Jul 10 11:07 kmod
lrwxrwxrwx    1 root     root            17 Jul 17 09:34 login -> /bin/login.shadow
-rwxr-xr-x    1 root     root         31260 Jul 10 11:22 login.shadow
lrwxrwxrwx    1 root     root            15 Jul 17 09:34 lsmod -> /bin/lsmod.kmod
lrwxrwxrwx    1 root     root             4 Jul 17 09:34 lsmod.kmod -> kmod
-rwsr-xr-x    1 root     root         38952 Jul 10 11:38 mount.util-linux
lrwxrwxrwx    1 root     root            24 Jul 17 09:34 mountpoint -> /bin/mountpoint.sysvinit
-rwxr-xr-x    1 root     root          9784 Jul 11 00:32 mountpoint.sysvinit
lrwxrwxrwx    1 root     root            19 Jul 17 09:34 pidof -> /bin/pidof.sysvinit
-rwxr-xr-x    1 root     root          9776 Jul 10 11:35 pidof.procps
lrwxrwxrwx    1 root     root            14 Jul 17 09:34 pidof.sysvinit -> /sbin/killall5
lrwxrwxrwx    1 root     root            14 Jul 17 09:34 ps -> /bin/ps.procps
-rwxr-xr-x    1 root     root         71636 Jul 10 11:35 ps.procps
lrwxrwxrwx    1 root     root            14 Jul 17 09:34 sh -> /bin/bash.bash
lrwxrwxrwx    1 root     root            14 Jul 17 09:34 su -> /bin/su.shadow
-rwsr-xr-x    1 root     root         27232 Jul 10 11:22 su.shadow
lrwxrwxrwx    1 root     root            19 Jul 17 09:34 true -> /bin/true.coreutils
-rwxr-xr-x    1 root     root         18060 Jul 10 11:37 true.coreutils
-rwxr-xr-x    1 root     root            29 Jul 10 13:04 vi.sh
lrwxrwxrwx    1 root     root            17 Jul 17 09:34 watch -> /bin/watch.procps
-rwxr-xr-x    1 root     root         18328 Jul 10 11:35 watch.procps
root@vuultimo4k:~#
 
white_westie said:
Looks like parameter position is important now!
Does that make sense ?
Click to expand...
It does in that it always was position dependent for GNU tar. It takes effect from where it is on the line, so paths before it do not use it whilst those after it do.
Sometimes you want things to be relative to here first, but relative to there later.

From the man page:
-C, --directory=DIR
Change to DIR before performing any operations. This option is
order-sensitive, i.e. it affects all options that follow.
Click to expand...
 
Last edited:
Status
Not open for further replies.

Similar threads

Huevos
  • Locked
OpenViX 6.7 Released!
Replies
7
Views
7K
Huevos
Huevos
Huevos
  • Locked
OpenViX 6.6 Released!
Replies
12
Views
12K
Huevos
Huevos
Huevos
  • Locked
OpenViX 6.4 Released!
Replies
7
Views
13K
Huevos
Huevos
Huevos
  • Locked
OpenViX 6.3 Released!
Replies
8
Views
7K
Huevos
Huevos
Huevos
  • Locked
OpenViX 6.2 Released!
Replies
7
Views
13K
Huevos
Huevos

OpenViX Feeds Status

Back
Top