Το νήμα του Gentoo, version 1.0

[Gentoo]

Μήπως έχεις ενεργοποιημένα τα "παλιά" "thick manifests" τα οποία καταχωρούσαν πληροφορίες μεγέθους / checksum και για τα ebuilds αντί για μόνο τα sources. Αν ανοίξεις στους δύο καταλόγους το Manifest, δεν έχει μέσα τα μεγέθη να τα αλλάξεις (πχ να λέει 658 και να το κάνεις 657). Αν έχεις εγκατεστημένο το repoman, νομίζω πώς η εντολή repoman manifest στον κάθε κατάλογο θα στα κάνει μόνο του όλα.

Μπορεί να σβήσει το παλιό manifest και να δώσει

ebuild package-name manifest

και να του δημιουργήσει καινούργιο.

Εναλλακτικά, θα πρέπει να ανοίξει το υπάρχον Manifest με editor και εκεί μέσα έχει το hash του κάθε ebuild και το μέγεθος σε bytes.

Μπορεί να το τροποποιήσει τα hashes με το νέο μέγεθος, αν και πιο εύκολο είναι να δώσει την εντολή ώστε να φτιάξει νέο manifest.

[tsigarid]

Μήπως έχεις ενεργοποιημένα τα "παλιά" "thick manifests" τα οποία καταχωρούσαν πληροφορίες μεγέθους / checksum και για τα ebuilds αντί για μόνο τα sources. Αν ανοίξεις στους δύο καταλόγους το Manifest, δεν έχει μέσα τα μεγέθη να τα αλλάξεις (πχ να λέει 658 και να το κάνεις 657). Αν έχεις εγκατεστημένο το repoman, νομίζω πώς η εντολή repoman manifest στον κάθε κατάλογο θα στα κάνει μόνο του όλα.

- - - Updated - - -

Ουφ! Τώρα όταν πάω να κάνω update με emerge παίρνω αυτό:

!!! The following installed packages are masked:
- x11-libs/libXp-1.0.3::local (masked by: invalid: DEPEND: Invalid atom (Invalid use dep: ''), token 1 in '/var/db/pkg/x11-libs/libXp-1.0.3/DEPEND', invalid: RDEPEND: Invalid atom (Invalid use dep: ''), token 1 in '/var/db/pkg/x11-libs/libXp-1.0.3/RDEPEND')
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

[imitheos]

Ναι φυσικά και το ebuild τάδε.ebuild manifest που πρότεινε ο Gentoo θα σου κάνει την δουλειά χωρίς να χρειάζεται να έχεις στημένο το repoman. Το repoman είναι overkill μόνο για τα manifests απλά στο μυαλό μου συνέδεσα το "έχω τοπική overlay" με το "έχω στημένο το repoman ώστε να τρέχω τα τεστς που λένε αν είναι δόκιμα τα ebuilds, κάνω commit, κτλ".

Edit: Για ανέβασε ή εδώ σε code tags ή σε κάποιο pastebin λίγο το ebuild να δούμε. Πολλές φορές λόγω αναβαθμίσεων στα EAPI χρειάζονται μικρο-αλλαγές.

Άκυρο, το βρήκα από το ιστορικό του git-tree. Η πρώτη αλλαγή που έκανα ήταν το "inherit xorg-2" στο νέο "inherit xorg-3" και αυτό έλυσε το πρόβλημα που έγραψες με το autotools-multilib. Από εκεί και πέρα παίρνω το μήνυμα με το invalid dep που σου έβγαλε αλλά μόνο όταν αλλάξω το XORG_MULTILIB σε no όπως είδα ότι έκανες. Αυτό το κάνεις για κάποιο λόγο και δεν το αφήνεις όπως έχει;

Με MULTILIB=no λοιπόν, δεν καταλαβαίνει τι σημαίνει το [${MULTILIB_USEDEP}] για αυτό σου βγάζει invalid dep. Αν σβήσεις αυτό (δηλαδή αλλάξεις τις καταχωρήσεις σε σκέτο >=x11-libs/libX11-1.6.2 ώστε να φύγουν οι αγκύλες με το multilib) θα πρέπει να παίξει ξανά σωστά.

[tsigarid]

Ο προγραμματιστής μέσα μου επαναστατεί με αυτά που λες! Θα έπρεπε να είναι ένα empty string η τιμή του ${MULTILIB_USEDEP} όταν έχω XORG_MULTILIB=no. Αρνούμαι να κάνω αυτή την αλλαγή, είναι ενάντια στις αρχές μου.

Spoiler:

Εννοείται την έκανα, και τώρα δεν έχω κανένα πρόβλημα, ευχαριστώ πολύ!

[Gentoo]

Σήμερα έκανα το switch από xdm σε display-manager, ύστερα από γενικό update του συστήματός μου.

Όλα πήγαν καλά. Κανένα πρόβλημα. Το νέο script (display-manager) "σήκωσε" το KDE X11 session μου απροβλημάτιστα, χωρίς reboot.

Είχα ένα άγχος γιατί έκανα update γύρω στα 100 πακέτα που τα περισσότερα εξ'αυτών αφορούσαν το KDE και το xorg

[tsigarid]

Σήμερα έκανα το switch από xdm σε display-manager, ύστερα από γενικό update του συστήματός μου.

Όλα πήγαν καλά. Κανένα πρόβλημα. Το νέο script (display-manager) "σήκωσε" το KDE X11 session μου απροβλημάτιστα, χωρίς reboot.

Είχα ένα άγχος γιατί έκανα update γύρω στα 100 πακέτα που τα περισσότερα εξ'αυτών αφορούσαν το KDE και το xorg

Και εδώ το ίδιο, 2 μηχανήματα (το ένα virtual) δεν είχαν θέμα.

[GoofyX]

Κάθε πότε γενικά κάνετε sync στο σύστημα; Στο σταθερό (που χρησιμοποιώ εγώ) κάνω συνήθως μια φορά τη βδομάδα, στα άλλα που χρησιμοποιούν γυναίκα και παιδιά, όποτε μπαίνουν μέσα κάνω ένα sync από μακριά και κάνει μόνο του στο background, αυτό μπορεί πέρα παρά μέρα.

Σήμερα έκανα πριν λίγο σε αυτό που κάθομαι τώρα και βλέπω έχει αρκετά πακέτα (>100). Έχει μέσα νέο kde-frameworks, οπότε κάνει αρκετό πράμα.

[Gentoo]

Κάθε πότε γενικά κάνετε sync στο σύστημα; Στο σταθερό (που χρησιμοποιώ εγώ) κάνω συνήθως μια φορά τη βδομάδα, στα άλλα που χρησιμοποιούν γυναίκα και παιδιά, όποτε μπαίνουν μέσα κάνω ένα sync από μακριά και κάνει μόνο του στο background, αυτό μπορεί πέρα παρά μέρα.

Σήμερα έκανα πριν λίγο σε αυτό που κάθομαι τώρα και βλέπω έχει αρκετά πακέτα (>100). Έχει μέσα νέο kde-frameworks, οπότε κάνει αρκετό πράμα.

Κάνω κάθε μέρα, αλλά επιλέγω τι θα εγκαταστήσω, πότε.

Δηλαδή αν δω να σκάνε 100 πακέτα όπως αυτές τις μέρες λόγω kde, συνήθως αναβαθμίζω επιλεκτικά αυτά που θέλω (πχ, firefox, signal, κλπ) και όταν έχω χρόνο, κάνω ολική αναβάθμιση.

Πάντα κάνω ολική αναβάθμιση όταν έχω αρκετό ελεύθερο χρόνο γιατί κάτι μπορεί να πάει στραβά και να χρειαστεί να ψαχτώ.

Και πριν κάνω το update, παίρνω κι ένα image backup με το fsarchive.

[imitheos]

Και εγώ θεωρητικά κάθε σάββατο αλλά πρακτικά πιο συχνά. Μερικές φορές βαριέμαι και δεν έχω τι να κάνω οπότε τρέχω ένα eix-sync και βλέπω τι παίζει, και όπως είπε ο gentoo, κάνω emerge -1 τα μικρά και αφήνω τα μεγάλα για άλλη φορά.

[GoofyX]

Βασικά έχω το καλό ότι έχω τα άλλα PC που κάνω πρώτα sync, βλέπω γενικά τι πακέτα έρχονται και τότε θα κάνω sync και σε αυτό που κάθομαι εγώ, αν χρειάζομαι κάτι να ενημερωθεί και στο δικό μου που το χρειάζομαι.

[tsigarid]

Κάθε πότε γενικά κάνετε sync στο σύστημα; Στο σταθερό (που χρησιμοποιώ εγώ) κάνω συνήθως μια φορά τη βδομάδα, στα άλλα που χρησιμοποιούν γυναίκα και παιδιά, όποτε μπαίνουν μέσα κάνω ένα sync από μακριά και κάνει μόνο του στο background, αυτό μπορεί πέρα παρά μέρα.

Σήμερα έκανα πριν λίγο σε αυτό που κάθομαι τώρα και βλέπω έχει αρκετά πακέτα (>100). Έχει μέσα νέο kde-frameworks, οπότε κάνει αρκετό πράμα.

Γενικά κάθε μέρα, εκτός αν το ξεχάσω. Το σύστημά μου το χρησιμοποιώ για gateway κυρίως, οπότε δεν με πειράζει να κάνει compile τις ώρες που δουλεύω, γιατί δεν με ενδιαφέρουν οι επιδόσεις του.

- - - Updated - - -

Έχω πέσει πάνω σε αυτό το bug, αλλά δεν βλέπω να ασχολείται κανείς, μάλλον γιατί το συγκεκριμένο πακέτο έχει λίγους χρήστες. Υπάρχει κάτι που να μπορώ να κάνω;

[GoofyX]

Να πεις κι εσύ ένα "me too" και να ανεβάσεις το build.log σου και τα σχετικά...;

[tsigarid]

Δεν νομίζω να κουνήσει κανέναν, αλλά θα το κάνω. Αναρωτιόμουνα αν μπορώ να βρω τι φταίει...

[imitheos]

Δεν νομίζω να κουνήσει κανέναν, αλλά θα το κάνω. Αναρωτιόμουνα αν μπορώ να βρω τι φταίει...

Τι έκδοση compiler χρησιμοποιείς; Κάποια στιγμή άλλαξε η έκδοση openmpi και πρέπει ο κώδικας να το υποστηρίζει (ή κάτι τέτοιο). Μία από τις αλλαγές είναι ότι οι μεταβλητές που δηλώνονται ως "const" δεν γίνονται αυτόματα shared όπως πριν. Σίγουρα το περιγράφω λάθος αλλά σε γενικές γραμμές κάτι έγινε πιο strict στον gcc (και στον clang ? ) με συνέπεια να μην παίζει ο κώδικας. Σε κάθε νέα major έκδοση gcc, ανοίγει ένα bug το οποίο blockάρει τον gcc μέχρι να λυθούν τέτοια bugs με βάση την "porting to GCC X" τεκμηρίωση του gcc αλλά μάλλον αυτό το πρόγραμμα δεν το χρησιμοποιεί κανείς οπότε ξέφυγε. Τι μπορείς λοιπόν να κάνεις με βαθμό από πιο δόκιμο - δύσκολο σε λιγότερο δόκιμο αλλά πιο εύκολο:

1) Να δεις ποιες μεταβλητές δηλώνονται ως const (πχ το fp_stderr) και να δεις σε κάθε μία αν πρέπει να δηλωθεί ως shared ή να φύγει το const. Ειδικά έτσι που είναι γραμμένος ο κώδικας δεν νομίζω να είναι εύκολο να το κάνει κάποιος που δεν έχει ευχέρεια με τον κώδικα.
2) Να αφαιρέσεις το default(none) από κάθε δήλωση parallel. Αυτό είναι πολύ πιο εύκολο και μπορεί να γίνει απλά με ένα sed.

diff --git a/sci-misc/nco/nco-4.5.1-r2.ebuild b/sci-misc/nco/nco-4.5.1-r2.ebuild
index f4733a08d8..67a1b68648 100644
--- a/sci-misc/nco/nco-4.5.1-r2.ebuild
+++ b/sci-misc/nco/nco-4.5.1-r2.ebuild
@@ -43,6 +43,8 @@ src_configure() {
 		$(use_enable openmp) \
 		$(use_enable static-libs static) \
 		$(use_enable udunits udunits2)
+
+	sed -ie "s#default(none) ##" $(grep -r "default(none)"|cut -d: -f1|sort -u)
 }
 
 src_install() {

3) Να απενεργοποιήσεις την σημαία openmp ώστε να παρακαμφθεί όλος αυτός ο "προβληματικός" κώδικας αλλά να μην έχεις παραλληλία.

Δοκίμασα τοπικά σε εμένα τα 2, 3 και το πρόγραμμα γίνεται σωστά compile και στις δύο περιπτώσεις αλλά δεν ξέρω τι κάνει οπότε δεν μπορώ να τεστάρω αν λειτουργεί σωστά.

[tsigarid]

Τι έκδοση compiler χρησιμοποιείς; Κάποια στιγμή άλλαξε η έκδοση openmpi και πρέπει ο κώδικας να το υποστηρίζει (ή κάτι τέτοιο). Μία από τις αλλαγές είναι ότι οι μεταβλητές που δηλώνονται ως "const" δεν γίνονται αυτόματα shared όπως πριν. Σίγουρα το περιγράφω λάθος αλλά σε γενικές γραμμές κάτι έγινε πιο strict στον gcc (και στον clang ? ) με συνέπεια να μην παίζει ο κώδικας. Σε κάθε νέα major έκδοση gcc, ανοίγει ένα bug το οποίο blockάρει τον gcc μέχρι να λυθούν τέτοια bugs με βάση την "porting to GCC X" τεκμηρίωση του gcc αλλά μάλλον αυτό το πρόγραμμα δεν το χρησιμοποιεί κανείς οπότε ξέφυγε. Τι μπορείς λοιπόν να κάνεις με βαθμό από πιο δόκιμο - δύσκολο σε λιγότερο δόκιμο αλλά πιο εύκολο:

1) Να δεις ποιες μεταβλητές δηλώνονται ως const (πχ το fp_stderr) και να δεις σε κάθε μία αν πρέπει να δηλωθεί ως shared ή να φύγει το const. Ειδικά έτσι που είναι γραμμένος ο κώδικας δεν νομίζω να είναι εύκολο να το κάνει κάποιος που δεν έχει ευχέρεια με τον κώδικα.
2) Να αφαιρέσεις το default(none) από κάθε δήλωση parallel. Αυτό είναι πολύ πιο εύκολο και μπορεί να γίνει απλά με ένα sed.

diff --git a/sci-misc/nco/nco-4.5.1-r2.ebuild b/sci-misc/nco/nco-4.5.1-r2.ebuild
index f4733a08d8..67a1b68648 100644
--- a/sci-misc/nco/nco-4.5.1-r2.ebuild
+++ b/sci-misc/nco/nco-4.5.1-r2.ebuild
@@ -43,6 +43,8 @@ src_configure() {
 		$(use_enable openmp) \
 		$(use_enable static-libs static) \
 		$(use_enable udunits udunits2)
+
+	sed -ie "s#default(none) ##" $(grep -r "default(none)"|cut -d: -f1|sort -u)
 }
 
 src_install() {

3) Να απενεργοποιήσεις την σημαία openmp ώστε να παρακαμφθεί όλος αυτός ο "προβληματικός" κώδικας αλλά να μην έχεις παραλληλία.

Δοκίμασα τοπικά σε εμένα τα 2, 3 και το πρόγραμμα γίνεται σωστά compile και στις δύο περιπτώσεις αλλά δεν ξέρω τι κάνει οπότε δεν μπορώ να τεστάρω αν λειτουργεί σωστά.

Όπως πάντα,

Θα δοκιμάσω το 3. Δεν με ενδιαφέρει η παραλληλία σε αυτό το πρόγραμμα, του οποίου το bottleneck είναι το Ι/Ο. Έχω πετύχει και αλλού τις αλλαγές του openmpi που με βασανίζουν, σε ορισμένες περιπτώσεις απλά γύρισα σε mpich... Χρησιμοποιώ gcc 10.

- - - Updated - - -

-openmp did the trick