System tar & restore Project

[tritonas00]

Αλλαξα την συμπεριφορα των dialogs.

 

Πλεον αν δεν οριστει variable (πχ πατηθει cancel ή yes χωρις να εχει επιλεξει κατι ο χρηστης), τοτε βγαινει νεο παραθυρο που λεει οτι πρεπει να επιλεξει κατι, αν ναι τοτε τον γυρναει πισω να επιλξει, αν οχι τοτε abort ολο το script.

[mask2011]

Χαίρομαι που έχει εξελιχθεί τόσο το project. Μακάρι να ήξερα κώδικα να βοηθήσω.

 

ΥΓ. Περαστικά tritona

[mphxths]

Δοκιμαζω το ΜΑΤΕ στο παλιο φορητο που λετε..μιας και αυτο ειναι ελαφρυ και εχει πολυ πραμα για παραμετροποιηση...και αυτο που συνεβη ειναι οτι σουταρε το zenity και εβαλε το matedialog.

 

Απο οτι παρατηρησα παιρνει τις ιδιες παραμετρους με το zenity..οποτε μπορει να χρησιμοποιηθει και αυτο..αν δεν βρισκει το zenity , ας ψαχνει και για το matedialog.Οτι βρισκει να το βαζει σε μια μεταβλητη και να παιζει με μεταβλητη και οχι ξερο "zenity" απο οτι βλεπω στο backup script.

 

Θα μου πειτε τωρα δηλαδη ρε φιλε θα πρεπει να φτιαξουμε υποπεριπτωσεις για καθε υποκαταστατο του zenity?

Ε οχι αλλα μιας και επεσε στην αντιληψη μας γιατι να μην την καλυψουμε αυτην την περιπτωση ?

[mask2011]

Με αυτή την λογική θα πρέπει να έχει παράμετρο και για το kdialog. Δεν νομίζω ότι είναι εφικτό να γίνει κάτι τέτοιο.

 

Δεν μπορεί να μπει το zenity στο mate; Δεν υπάρχει σαν πακέτο ή χτυπάνε τίποτα εξαρτήσεις;

[mphxths]

με το που περασα το mate , εβγαλε μηνυμα (κατα την εγκατασταση δηλ) οτι τα 2 τους conflict-αρουν.Τι να σου πω τωρα...αν μπορουν να συμβιωσουν...χλωμο.

 

Ξερω δεν ειναι λογικη αυτο..να πιασουμε ολες τις υποπεριπτωσεις , αλλα ειναι αληθεια οτι παιζουν πολλα γραφικα περιβαλλοντα , και δεν θα εχουν ολοι zenity..αλλος θα χει kde με kdialog , αλλος ΜΑΤΕ με matedialog , αλλος με zenity.

 

Αν θελουμε να ειναι universal το σκριπτ δυστυχως πρεπει να τα πιασει ολα αλλιως να λεμε "μονο με zenity , μονο με αυτο και το αλλο κλπ"...

[mask2011]

Μα από την αρχή είχε σαν "εξάρτηση" το zenity. Αλλιώς θα έπρεπε να γραφτεί μονο σε bash και να μην είχε καθόλου γραφικό. Αυτό βέβαια(χωρίς να ξέρω πολλά από κωδικα) θα είχε αλλα μειονεκτήματα όπως η επιλογή του φακέλου που βρίσκεται το tar, δεν θα υπηρχε.

 

Ξαναλέω όμως ότι δεν ξέρω από κώδικα και έτσι περιμένω αύριο να μας απαντήσει ο tritonas αν κάτι τέτοιο είναι εφικτό. Μακάρι να γίνεται και να καλύπτει τους πάντες...

 

Αν αφαιρέσεις το matedialog και βάλεις το zenity; Χρειάζεται για κάτι συγκεκριμένο το matedialog;

[mphxths]

Ε λογικα χρειαζεται εκει που χρειαζεται το zenity..για τα dialog παραθυρα...υποθετω

 

 

στην περιγραφη ο τριτωνας εχει βαλει "Only Arch Linux supported for now." ---> Δεν λεει "only archlinux with zenity only is supported"

 

Τι να πω..ξερωγω..ο τριτωνας αποφασιζει.Αλλα το σωστο ειναι οτι αμα θελουμε να καλυψουμε ολες τις περιπτωσεις , πρεπει να προβλεφτουν ολα αυτα.

 

Τωρα να βγαλω matedialog και να βαλω zenity..δεν ξερω τι θα επηρρεασει..αλλα αμα ειναι να αρχισει ο καθενας να ξηλωνει kdialog κλπ και να βαζει zenity...το θεωρω λιγο ακυρο...

 

Μια αλλη λυση θα ηταν να γινοταν detect του window manager με καποιον τροπο (του κερατα καπως θα γινεται) και αυτοματα μετα να επιλεγει το αντιστοιχο του zenity.Αν δεν εχει καποιο συγκεκριμενο wm , να κανει fallback στο zenity...

[pmav99]

Μπορεί να γίνει ένα Python wrapper με Tkinter για γραφικό περιβάλλον. Υποστηρίζει και native εμφάνιση μέσω του ttk.

 

 

Είναι στη standard library οπότε δεν προστίθεται dependency. H python νομίζω μπορεί να υποτεθεί ότι θα βρίσκεται σε όλα τα συστήματα .

[Dr.Fuzzy]

Μπορεί να γίνει ένα Python wrapper με Tkinter για γραφικό περιβάλλον. Υποστηρίζει και native εμφάνιση μέσω του ttk.

 

 

Είναι στη standard library οπότε δεν προστίθεται dependency. H python νομίζω μπορεί να υποτεθεί ότι θα βρίσκεται σε όλα τα συστήματα .

 

+1 από εμένα.

[pmav99]

Proof of concept σε Python3. Γίνεται και αρκετά πιο όμορφο (πχ να έχεις κεντρικό παράθυρο με textwidget και κουμπάκι browse, αλλά θέλει λίγο διάβασα γιατί δεν έχω κάνει ποτέ τίποτα με το tkinter.

 

>
import subprocess
import tkinter
from tkinter.filedialog import askdirectory

root = tkinter.Tk()
root.wm_withdraw()

root_directory = askdirectory(parent=root, initialdir="/", title="Pick the root directory")
home_directory = askdirectory(parent=root, initialdir="/home", title="Pick the home directory")
boot_directory = askdirectory(parent=root, initialdir="/boot", title="Pick the boot directory")

print("Root directory : ", root_directory)
print("Home directory : ", home_directory)
print("Boot directory : ", boot_directory)

# call an external command with arguments.
subprocess.call(["echo", root_directory, home_directory, boot_directory"])

[imitheos]

Μια και μπήκε στο github (και μια και ρωτήθηκα prive) παίρνω το θάρρος να γράψω ένα workflow. Εννοείται πως υπάρχουν 100 τρόποι να δουλέψει κάποιος και δεν υπάρχει ένα τέλειο workflow.

 

Υποθέτω ότι έχουμε λογαριασμό στο github . Πηγαίνουμε στο repo του τρίτονα και πατάμε fork. Αν πρόκειται να κάνουμε μια-δυο μικρές αλλαγές και δεν έχουμε σκοπό να συμμετέχουμε πιο ενεργά, μπορούμε να κάνουμε clone στον υπολογιστή μας απευθείας το repo του τρίτονα και να στείλουμε εδώ τις αλλαγές. Με το fork όμως μπορούμε εύκολα να στέλνουμε pull requests και να ενσωματώνει ο τρίτονας τον κώδικά μας.

 

Αφού λοιπόν κάνουμε fork θα δημιουργήσουμε την δική μας έκδοση του repo. Έστω ότι το github username μου είναι imitheos και ότι ονόμασα το repo tritstar. Έτσι η διεύθυνση του repo μου είναι https://github.com/imitheos/tritstar.

 

>
% git clone https://github.com/imitheos/tritstat.git
% cd tritstat

 

Κάνω λοιπόν clone το repo μου για να δουλέψω τοπικά. Όταν έκανα το clone, δημιουργήθηκε αυτόματα το remote με όνομα origin που δείχνει στο repo μου για να μπορώ να στέλνω αυτά που γράφω. Για να μπορώ όμως να παίρνω και τις αλλαγές που γράφει ο τρίτονας πρέπει να προσθέσω και το δικό του repo το οποίο είναι το "official". Το όνομα που χρησιμοποιείται συνήθως είναι upstream.

 

>
% git remote add upstream https://github.com/tritonas00/system-tar-and-restore.git

 

 

Καλό είναι να δημιουργώ ένα branch για οποιαδήποτε δουλειά κάνω ώστε να αποφεύγονται άσκοπα merge-commits και διπλά commits.

 

>
1) git checkout -b zenity_refactor
2) κάνω δουλειές
3) git status
4) git add -u
5) git commit (ή git commit -m "τάδε μήνυμα")
6) git status

 

Η εντολή 1 δημιουργεί ένα branch με όνομα zenity_refactor και ταυτόχρονα το κάνει τρέχον branch ώστε να δουλέψω εκεί. Δεν μου αρέσει ο τρόπος που έγραψε ο τρίτονας τις κλήσεις του zenity οπότε θα το αλλάξω σε κάτι καλύτερο για αυτό επέλεξα το όνομα zenity_refactor. Αφού κάνω ό,τι αλλαγές θέλω, τρέχω τη 3η εντολή και βλέπω σε τι κάτασταση είναι το repo. Θα μου βγάλει ότι έχω κάποιες αλλαγές που είναι unstaged και πρέπει να τις αποθηκεύσω. Η εντολή "git add -u" βάζει στο index ό,τι αλλαγές έχουν γίνει σε υπάρχοντα αρχεία. Μια και δεν προσθέτουμε νέα αρχεία στο παρόν repo, δεν χρειάζεται κάτι άλλο. Μετά τρέχουμε την εντολή git commit η οποία θα δημιουργήσει το commit που θέλουμε. Αν δεν δώσουμε την παράμετρο -m θα ανοίξει ένα editor για να γράψουμε το μήνυμα που θέλει να έχει το commit. Μπορούμε να συνδυάσουμε τις εντολές add και commit σε μία αλλά έτσι έχουμε μεγαλύτερη εποπτία. Από εκεί και πέρα συνεχίζουμε ξανά από το βήμα 2.

 

Ο κώδικας του τρίτονα για το zenity όμως είναι χάλια και έχω πολύ δουλειά να κάνω. Έτσι στο μεταξύ ο τρίτονας έγραψε και άλλο κώδικα και προστέθηκαν νέα commit στο repo του οπότε πρέπει να τα φέρω και εγώ.

 

>
1) git fetch upstream
2) git checkout master
3) git merge upstream/master

 

Η εντολή 1 θα μας φέρει όλα τα νέα αντικείμενα που προστέθηκαν στο repo με όνομα upstream χωρίς όμως να μας πειράξει τοπικά το repo μας. Η εντολή 2 αλλάζει το τρέχον branch στο master και η 3η κάνει merge τις αλλαγές του τρίτονα. Εδώ τώρα είναι ο ένας λόγος που είπα ότι καλό είναι να δουλεύουμε με branch. Αν έχουμε αλλαγές που δεν υπάρχουν στο repo του τρίτονα, δηλαδή έχουν διασπαστεί οι δρόμοι μας, τότε θα δημιουργηθεί ένα merge-commit που θα τους ενώνει. Μερικοί devs έχουν συνήθειο να φέρνουν πολύ συχνά τις αλλαγές του κυρίου repo με συνέπεια να βλέπουμε 15 άχρηστα merge-commits. Μια εναλλακτική είναι να τρέξουμε "git rebase upstream/master" αλλά η χρήση branch θα μας βολέψει και στις pull request.

 

Όταν τελειώσει η δουλειά μας στο branch, τότε ήρθε η ώρα να το κάνουμε γνωστό στον τρίτονα για να το ενσωματώσει στο "blessed" repo ώστε να το πάρουν και άλλοι.

 

>
git checkout zenity_refactor
git rebase master
git push origin zenity_refactor

 

Πριν όμως το στείλουμε στον τρίτονα, καλό είναι να κάνουμε rebase τις αλλαγές μας ώστε να βασίζονται στον τρέχοντα κώδικα του τρίτονα. Το git θα κάνει τη σωστή δουλειά ακόμη και να παραλείψουμε αυτό το στάδιο. Έτσι όμως γλυτώνουμε τον τρίτονα από περιττή δουλειά γιατί αν υπάρχουν conflicts θα τις λύσουμε εμείς αντί για εκείνον. Εμείς γράψαμε τον κώδικα οπότε τον ξέρουμε καλύτερα και η επίλυση των conflict είναι πιο εύκολη για εμάς. Έτσι λοιπόν κάνουμε πρώτα update το repo του τρίτονα όπως έδειξα πριν και μετά τρέχουμε τις παραπάνω εντολές. Επιλύουμε τις conflict αν υπάρχουν και τρέχουμε οτιδήποτε τεστ έχουμε για να δούμε ότι ο κώδικάς μας δουλεύει και έπειτα στέλνουμε το branch στο github.

 

Τώρα λοιπόν το branch μας είναι έτοιμο να ενσωματωθεί στο κύριο repo οπότε πηγαίνουμε στη σελίδα μας στο github, αλλάζουμε το branch ώστε να δείχνει στο zenity_refactor και επιλέγουμε να στείλουμε pull request.

 

Όταν δούμε ότι ο τρίτονας έχει ενσωματώσει τις αλλαγές μας, τότε αυτές θα υπάρχουν στο master του οπότε και στο δικό μας master και έτσι μπορούμε να σβήσουμε το branch μας. Αυτός είναι ο 2ος λόγος να χρησιμοποιούμε branch γιατί αν κάναμε merge το zenity_refactor στο master μας και στέλναμε εκείνο pull request, μετά θα έπρεπε να κάνουμε μια έξτρα διαδικασία για να μην καταλήξουμε με duplicate commits.

 

Αυτά .Ελπίζω να μην έχω κάποιο λάθος και να μην τα έγραψα ακαταλιβίστικα.

[tritonas00]

@mphxths

 

Ας τελειωσουμε πρωτα με τα βασικα και μετα ας αποφασισουμε αν αλλαξουμε το UI ή οχι.

 

Η πιο standard λυση , ειναι αυτο που ειχε πει ο warlock. Δηλαδη αν δεν βρεθει zenity τοτε γυρναει σε text mode.

 

Δουλευει και χωρις X.

 

Βεβαια ο λογος γινεται για το restore script, αφου το backup δεν ειναι τιποτα. Ο μονος χρησιμος διαλογος ειναι αυτος που σε ρωταει την τοποθεσια, τα αλλα μια χαρα μπορει να στα πει και στην κονσολα.

 

Τωρα και το θεμα που εθιξε ο pmav99 ειναι μια λυση. Αν γινεται ευκολα και αναιμακτα, γιατι οχι.

 

Υπομονη να τελειωσουμε καποια πραματακια ( btrfs subvolumes, progress % στην tar, ξεχωριστο /boot και κατι αλλα), και μετα βλεπουμε.

 

@imitheos

 

respect !

[tritonas00]

Προστεθηκε SUMMARY, πριν ξεκινησει η διαδικασια.

 

[warlock9_0]

το text θα γίνει κάπως έτσι

 

>$ ./s
Select the number of your root partition or enter Q to quit
1) /dev/sda1  3) /dev/sdc1  5) /dev/sdd2
2) /dev/sdb1  4) /dev/sdd1  6) /dev/sdd3
Choice: 4
You selected /dev/sdd1 for your root partition

[mphxths]

το text θα γίνει κάπως έτσι

 

>$ ./s
Select the number of your root partition or enter Q to quit
1) /dev/sda1 3) /dev/sdc1 5) /dev/sdd2
2) /dev/sdb1 4) /dev/sdd1 6) /dev/sdd3
Choice: 4
You selected /dev/sdd1 for your root partition

 

μηπως με καποιον τροπο να φαινεται διπλα απο το καθενα και το μεγεθος/filesystem?Γιατι μπορει να ξεχασε ο αλλος ποιο partition ειναι ποιο