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

[imitheos]

Δεν ξέρω, ίσως. Πάντως πριν είχα το ebuild από το overlay του jorgicio, αλλά στην τελευταία έκδοση (zoom-3.5.374815.0324) είδα ότι και αυτός έβαλε την qtwebengine ως εξάρτηση.

Αφού μπήκε στο σταθερό, τώρα βλέπω ότι δε δείχνει video, ενώ η πρώτη έκδοση (3.5.361976.0301) έπαιζε μια χαρά.

Βάλε τότε την παλιά όπως είπε και ο vtester αφού παίζει οκ. Παρεμπιπτώντος κατέβασα και την έκδοση που ανέφερες και έχει και αυτή την qtwebengine ενσωματωμένη οπότε μάλλον θα την δίνουν από εδώ και πέρα πάντα ενσωματωμένη. Δεν θα χρειάζεται να την κάνεις compile ώρες.

Πολύ πιθανώς να μην σε ενδιαφέρει αλλά κατά σύμπτωση έβαλε ο jwz (ο developer του xscreensaver και παλιά major contributor στον emacs) σήμερα ένα post που βρίζει το zoom για ανήθικες τακτικές (αν κατάλαβα καλά από τη σύνοψη. δεν έκατσα να το διαβάσω).

[GoofyX]

https://bugs.gentoo.org/669082: ζητούν binary πακέτο για το qtwebengine.

Πειράζοντας το πακέτο από το overlay του jorgicio και φτιάχνοντας νέο ebuild με την τελευταία έκδοση, παίζει και το βίντεο. Άρα φταίει το «δέσιμο» με τις βιβλιοθήκες του συστήματος και η έλλειψη μιας άλλης βιβλιοθήκης (σχετικό bug).

Από την άλλη ο Ulrich στο bug έχει δίκιο λέγοντας ότι η Qt 5.9.6 που δίνει το Zoom bundled έχει θέματα ασφαλείας και ότι γενικά είναι στην πολιτική του Gentoo να χρησιμοποιούν τα πακέτα όσο γίνεται τις βιβλιοθήκες συστήματος και όχι τα bundled του πακέτου. Οκ, αλλά με το qtwebengine μας έσκισαν. Στο laptop το ξεκίνησα το πρωί και λίγο πριν τις 5 ώρες compilation (!!!), το έκοψα βλέποντας με το κόλπο με το ebuild του jorgicio παίζει. Ας δώσουν μια binary έκδοση του qtwebengine και το ξανασυζητάμε.

[Vtester]

Ζητάνε αλλά οι dev στις απαντήσεις δεν πολύ ψήνονται

[Gentoo]

https://bugs.gentoo.org/669082: ζητούν binary πακέτο για το qtwebengine.

Πειράζοντας το πακέτο από το overlay του jorgicio και φτιάχνοντας νέο ebuild με την τελευταία έκδοση, παίζει και το βίντεο. Άρα φταίει το «δέσιμο» με τις βιβλιοθήκες του συστήματος και η έλλειψη μιας άλλης βιβλιοθήκης (σχετικό bug).

Από την άλλη ο Ulrich στο bug έχει δίκιο λέγοντας ότι η Qt 5.9.6 που δίνει το Zoom bundled έχει θέματα ασφαλείας και ότι γενικά είναι στην πολιτική του Gentoo να χρησιμοποιούν τα πακέτα όσο γίνεται τις βιβλιοθήκες συστήματος και όχι τα bundled του πακέτου. Οκ, αλλά με το qtwebengine μας έσκισαν. Στο laptop το ξεκίνησα το πρωί και λίγο πριν τις 5 ώρες compilation (!!!), το έκοψα βλέποντας με το κόλπο με το ebuild του jorgicio παίζει. Ας δώσουν μια binary έκδοση του qtwebengine και το ξανασυζητάμε.

genlop -t qtwebengine
 * dev-qt/qtwebengine

     Tue Jul 30 06:39:35 2019 >>> dev-qt/qtwebengine-5.12.3
       merge time: 9 hours, 19 minutes and 31 seconds.

     Sat Sep  7 02:02:11 2019 >>> dev-qt/qtwebengine-5.12.3
       merge time: 14 hours, 37 minutes and 29 seconds.

     Tue Oct 29 16:01:44 2019 >>> dev-qt/qtwebengine-5.12.5
       merge time: 18 hours, 7 minutes and 11 seconds.

Μερικοί χρόνοι από δικά μου merge

[imitheos]

genlop -t qtwebengine
 * dev-qt/qtwebengine

     Tue Jul 30 06:39:35 2019 >>> dev-qt/qtwebengine-5.12.3
       merge time: 9 hours, 19 minutes and 31 seconds.

     Sat Sep  7 02:02:11 2019 >>> dev-qt/qtwebengine-5.12.3
       merge time: 14 hours, 37 minutes and 29 seconds.

     Tue Oct 29 16:01:44 2019 >>> dev-qt/qtwebengine-5.12.5
       merge time: 18 hours, 7 minutes and 11 seconds.

Μερικοί χρόνοι από δικά μου merge

Χαρά στο κουράγιο σας. Βγήκε update σε llvm / clang που θέλει καμμιά ώρα και όλο το αναβάλλω να το κάνω, πόσο μάλλον 9 ώρες (ή θεός φυλάξοι 18 ώρες). Θυμάσαι μήπωε γιατί τόσο μεγάλη διαφορά 9 -> 14 -> 18; Είναι λόγω των διαφόρων mitigations που έβγαιναν κατά καιρούς;

[GoofyX]

Αν δείτε στο bug, δοκίμασα νέο build του qtwebengine στο κύριο μηχάνημά μου (i5 8600) με ενεργό το flag jumbo-build (δεν ξέρω αν έχει καμία σχέση με το κατάστημα...) και ο χρόνος έπεσε στο μισό. Αν είναι να το κάνετε κι εσείς, ενεργοποιήστε το flag σίγουρα. Θα θέλει όμως πολλή μνήμη, εγώ έχω 16GB, ίσως με 8GB να παίζει, δεν ξέρω.

[Gentoo]

Χαρά στο κουράγιο σας. Βγήκε update σε llvm / clang που θέλει καμμιά ώρα και όλο το αναβάλλω να το κάνω, πόσο μάλλον 9 ώρες (ή θεός φυλάξοι 18 ώρες). Θυμάσαι μήπωε γιατί τόσο μεγάλη διαφορά 9 -> 14 -> 18; Είναι λόγω των διαφόρων mitigations που έβγαιναν κατά καιρούς;

Δεν γνωρίζω γιατί πήρε τόσο πολύ. Αυτά τα rebuilds τα έκανα λόγω empty tree που χρειάστηκε να κάνω 2-3 φορές.

Δεν με πολυαπασχολεί όμως, απ'τη στιγμή που το αφήνω να κάνει compiling στο background, ας κάνει όσο θέλει.

Στα 900+ πακέτα που έχω εγκατεστημένα, είναι μετρημένα στα δάχτυλα τα "χρονοβόρα", επομένως δεν με απασχολεί.

Αν δείτε στο bug, δοκίμασα νέο build του qtwebengine στο κύριο μηχάνημά μου (i5 8600) με ενεργό το flag jumbo-build (δεν ξέρω αν έχει καμία σχέση με το κατάστημα...) και ο χρόνος έπεσε στο μισό. Αν είναι να το κάνετε κι εσείς, ενεργοποιήστε το flag σίγουρα. Θα θέλει όμως πολλή μνήμη, εγώ έχω 16GB, ίσως με 8GB να παίζει, δεν ξέρω.

Στα 16gb παίζω μπάλα κι εγώ. Θα το 'χω υπόψιν αν χρειαστεί να το ξαναπεράσω.

[GoofyX]

Ερώτηση: Το mysql-connector-c, αν το έχετε, ποιά έκδοσή του έχετε; Την 8.0.19; Σε μένα και στα 3 μηχανήματα, δεν γίνεται compile με τίποτα. Έχω ανοικτό bug, αλλά δεν έχω βρει άκρη. Είναι δυνατόν και στα 3 μηχανήματά μου να μη μεταγλωττίζεται; Πείραξα τα C{XX}FLAGS, αλλά τίποτα.

[Gentoo]

Ερώτηση: Το mysql-connector-c, αν το έχετε, ποιά έκδοσή του έχετε; Την 8.0.19; Σε μένα και στα 3 μηχανήματα, δεν γίνεται compile με τίποτα. Έχω ανοικτό bug, αλλά δεν έχω βρει άκρη. Είναι δυνατόν και στα 3 μηχανήματά μου να μη μεταγλωττίζεται; Πείραξα τα C{XX}FLAGS, αλλά τίποτα.

Δεν το είχα, αλλά το έκανα compile για πάρτη σου

Χτίστηκε κανονικά. Η έκδοση dev-db/mysql-connector-c-8.0.19.

Τα C{XX}FLAGS μου:

COMMON_FLAGS="-O2 -pipe"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"

Αν θέλεις, στο ανεβάζω binary να κάνεις τη δουλειά σου μέχρι να βγάλεις άκρη.
Οι ρυθμίσεις μου το κάνουν να δουλεύει σε οποιοδήποτε σύστημα.

[imitheos]

Και σε εμένα έπαιξε τζάμι σε hardened LTO μάλιστα. Τα μόνα που μου ήρθαν στο μυαλό είναι:

1) Ninja: Θυμάμαι ότι κάποια έκδοση είχε ένα bug και έκανε miscompile το wayland ή κάτι τέτοιο. Δοκίμασα διάφορες εκδόσεις και γίνεται compile με όλες.
Edit: Πρόσεξα ότι σε εσένα το cmake λέει ότι δημιούργησε unix makefile ενώ σε εμένα ninja. Οπότε σε σένα τρέχει απλό make και δεν είχε να κάνει με το ninja έτσι και αλλιώς.
2) CFLAGS: Έβαλα τα δικά σου και ό,τι άλλες επιλογές βρήκα όπως USE, κτλ αλλά έπαιξε με όλες τις δοκιμές.
3) LLD: Έκανα vimdiff το build.log σου με το δικό μου και η πρώτη διαφορά που βλέπω είναι η εξής:

GoofyX
-- Performing Test C_LD_LLD_RESULT
-- Performing Test C_LD_LLD_RESULT - Success
-- Performing Test CXX_LD_LLD_RESULT
-- Performing Test CXX_LD_LLD_RESULT - Success
Imitheos
-- Performing Test C_LD_LLD_RESULT
-- Performing Test C_LD_LLD_RESULT - Failed
-- Performing Test CXX_LD_LLD_RESULT
-- Performing Test CXX_LD_LLD_RESULT - Failed
-- Performing Test C_LD_GOLD_RESULT
-- Performing Test C_LD_GOLD_RESULT - Success
-- Performing Test CXX_LD_GOLD_RESULT
-- Performing Test CXX_LD_GOLD_RESULT - Success

Ίσως να φταίει κάτι άλλο (δεν κοίταξα από εκεί και κάτω) αλλά μήπως φταίει ότι χτησιμοποιείς το LLD ενώ εγώ (και ίσως και ο gentoo) το GOLD; Πάει πολύς καιρός που έχω ασχοληθεί αλλά το LLD θεωρείται ready to use τώρα; Θυμάμαι ότι παλαιότερα που είχα γυρίσει όλο το σύστημα σε default clang, όλο το stack του LLVM (compiler-rt αντί για libgcc, libc++ αντί για libstdc++, κτλ) θεωρούταν σχεδόν-stable αλλά όλοι πρότειναν να μην ενεργοποιήσεις τον LLD. Εδώ και ο GOLD δεν έκανε compile ένα κάρο προγράμματα.

Αν δεν βαριέσαι, κάνε μια δοκιμή με GOLD ή gnu LD.

Edit2: Άσχετο με το παρόν bug αλλά δεν χρειάζεται να δηλώνεις χειροκίνητα στην CFLAGS όλες τις παραμέτρους. Μπορείς να χρησιμοποιήσεις κατευθείαν ένα προφίλ.

CFLAGS="-O2 -pipe -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mfma -mbmi -msgx -mbmi2 -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt -mclflushopt -mxsavec -mxsaves --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=9216"

Αν δεν μου ξέφυγε κάτι, όλες οι παράμετροι που έχεις εκφράζονται από το προφίλ skylake με μόνο λίγες να μένουν που δεν είναι ενεργοποιημένες σε κανένα προφίλ από ό,τι είδα. Οπότε με μικρή επιφύλαξη μήπως έκανα κάποιο λάθος, το παραπάνω μπορεί να γραφτεί ως

CFLAGS="-O2 -pipe -march=skylake -maes -mabm -mrtm --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=9216"

[GoofyX]

Αν θέλεις, στο ανεβάζω binary να κάνεις τη δουλειά σου μέχρι να βγάλεις άκρη.
Οι ρυθμίσεις μου το κάνουν να δουλεύει σε οποιοδήποτε σύστημα.

Αν δεν παίξουν οι χακιές που λέει ο imitheos, μάλλον θα το κάνεις... Θα σου πω, thanks anyway.

Και σε εμένα έπαιξε τζάμι σε hardened LTO μάλιστα. Τα μόνα που μου ήρθαν στο μυαλό είναι:

1) Ninja: Θυμάμαι ότι κάποια έκδοση είχε ένα bug και έκανε miscompile το wayland ή κάτι τέτοιο. Δοκίμασα διάφορες εκδόσεις και γίνεται compile με όλες.
Edit: Πρόσεξα ότι σε εσένα το cmake λέει ότι δημιούργησε unix makefile ενώ σε εμένα ninja. Οπότε σε σένα τρέχει απλό make και δεν είχε να κάνει με το ninja έτσι και αλλιώς.

Το έχω το ninja.

2) CFLAGS: Έβαλα τα δικά σου και ό,τι άλλες επιλογές βρήκα όπως USE, κτλ αλλά έπαιξε με όλες τις δοκιμές.
3) LLD: Έκανα vimdiff το build.log σου με το δικό μου και η πρώτη διαφορά που βλέπω είναι η εξής:

GoofyX
-- Performing Test C_LD_LLD_RESULT
-- Performing Test C_LD_LLD_RESULT - Success
-- Performing Test CXX_LD_LLD_RESULT
-- Performing Test CXX_LD_LLD_RESULT - Success
Imitheos
-- Performing Test C_LD_LLD_RESULT
-- Performing Test C_LD_LLD_RESULT - Failed
-- Performing Test CXX_LD_LLD_RESULT
-- Performing Test CXX_LD_LLD_RESULT - Failed
-- Performing Test C_LD_GOLD_RESULT
-- Performing Test C_LD_GOLD_RESULT - Success
-- Performing Test CXX_LD_GOLD_RESULT
-- Performing Test CXX_LD_GOLD_RESULT - Success

Ίσως να φταίει κάτι άλλο (δεν κοίταξα από εκεί και κάτω) αλλά μήπως φταίει ότι χρησιμοποιείς το LLD ενώ εγώ (και ίσως και ο gentoo) το GOLD; Πάει πολύς καιρός που έχω ασχοληθεί αλλά το LLD θεωρείται ready to use τώρα; Θυμάμαι ότι παλαιότερα που είχα γυρίσει όλο το σύστημα σε default clang, όλο το stack του LLVM (compiler-rt αντί για libgcc, libc++ αντί για libstdc++, κτλ) θεωρούταν σχεδόν-stable αλλά όλοι πρότειναν να μην ενεργοποιήσεις τον LLD. Εδώ και ο GOLD δεν έκανε compile ένα κάρο προγράμματα.

Αν δεν βαριέσαι, κάνε μια δοκιμή με GOLD ή gnu LD.

Πώς αλλάζω το linker;

Edit2: Άσχετο με το παρόν bug αλλά δεν χρειάζεται να δηλώνεις χειροκίνητα στην CFLAGS όλες τις παραμέτρους. Μπορείς να χρησιμοποιήσεις κατευθείαν ένα προφίλ.

CFLAGS="-O2 -pipe -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mfma -mbmi -msgx -mbmi2 -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt -mclflushopt -mxsavec -mxsaves --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=9216"

Αν δεν μου ξέφυγε κάτι, όλες οι παράμετροι που έχεις εκφράζονται από το προφίλ skylake με μόνο λίγες να μένουν που δεν είναι ενεργοποιημένες σε κανένα προφίλ από ό,τι είδα. Οπότε με μικρή επιφύλαξη μήπως έκανα κάποιο λάθος, το παραπάνω μπορεί να γραφτεί ως

CFLAGS="-O2 -pipe -march=skylake -maes -mabm -mrtm --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=9216"

Το -march=skylake και -mtune=skylake τα έβαλα εκ των υστέρων στο CFLAGS. Τελοσπάντων, θα δοκιμάσω αυτά που λες και βλέπουμε.

Ευχαριστώ παίδες!

- - - Updated - - -

Εντάξει είναι να τρελαίνεσαι. Ρε συ imithee, δεν πας να υποστηρίξεις κανά Gentoo; Θα σου κόβουμε μισθό. Δηλαδή ένα κωλο-ποστ έριξα εδώ και βρήκες λύση!!! Ο άλλος ο developer στο bug που άνοιξα τι σκατά έκανε; Με το που έβγαλα το lld, έκανε compile κανονικά χωρίς να πειράξω CFLAGS ή δεν ξέρω 'γω τι! Και όχι μου έλεγε να κάνω debug με τον gdb και ό,τι να 'ναι!!!

ΕΥΧΑΡΙΣΤΩ ΗΜΙΘΕΕ!!!!!

[imitheos]

Εντάξει είναι να τρελαίνεσαι. Ρε συ imithee, δεν πας να υποστηρίξεις κανά Gentoo; Θα σου κόβουμε μισθό. Δηλαδή ένα κωλο-ποστ έριξα εδώ και βρήκες λύση!!! Ο άλλος ο developer στο bug που άνοιξα τι σκατά έκανε; Με το που έβγαλα το lld, έκανε compile κανονικά χωρίς να πειράξω CFLAGS ή δεν ξέρω 'γω τι! Και όχι μου έλεγε να κάνω debug με τον gdb και ό,τι να 'ναι!!!

ΕΥΧΑΡΙΣΤΩ ΗΜΙΘΕΕ!!!!!

Σε σχέση με τον Thomas στο bug report, εγώ είχα το πλεονέκτημα ότι μας είπες να δοκιμάσουμε να κάνουμε compile το πακέτο οπότε είπα "δε συγκρίνεις τα logs;" και έκανα vimdiff τα logs μας.

Χωρίς αυτό δεν υπήρχε καμμία μα καμμία περίπτωση να πάει το μυαλό μου ότι α) θα έχεις εγκαταστήσει τον LLD που δεν είναι και τόσο stable (ειδικά ξέροντας ότι δεν έχεις πολλά ~amd64 προγράμματα) και β) το build system του connector, χωρίς κανένα use flag ή configure flag ή whatever, θα πήγαινε και θα προτιμούσε τον LLD απλά και μόνο επειδή τον βρήκε εγκατεστημένο. Μου έκανε εντύπωση ακόμη και το γεγονός ότι προτίμησε τον GOLD σε σχέση με τον Gnu LD.

[GoofyX]

Κουτσομπολιό:

2020-04-03-deprecation-of-legacy-x11-input-drivers
Title Deprecation of legacy X11 input drivers
Author Piotr Karbowski <slashbeast@gentoo.org>
Posted 2020-04-03
Revision 2

The Gentoo X11 Team is announcing the deprecation and future removal of
the legacy X11 input drivers x11-drivers/xf86-input-mouse and
x11-drivers/xf86-input-keyboard. As of 2020-05-01 those input drivers
will be masked for removal.

These drivers have been deprecated for many years, first by
xf86-input-evdev and then by xf86-input-libinput.

The only use for those drivers remain in deployments which intentionally
opt-out of using udev, as both evdev and libinput require udev during
runtime, however given that upstream has already removed the Linux
support from xf86-input-keyboard, future X11 releases will no longer
support xf86-input-keyboard on Linux rendering those installation
infeasible to use without udev.

In order to ensure frictionless upgrade path for future X11 releases, we
have decided to deprecate those drivers that are not in active use by
pretty much any installation of Gentoo.

No action is required from end-users who are already using libinput (or
evdev). To check which driver is in use, one can use

$ grep 'Using input driver' ~/.local/share/xorg/Xorg.0.log

for the systems running xorg-server as regular user (-suid
+elogind/+systemd) or by running

# grep 'Using input driver' /var/log/Xorg.0.log

for those running xorg-server as root.

If however neither libinput or evdev is in use, one should append
'libinput' to the INPUT_DEVICES variable inside /etc/portage/make.conf
while removing 'keyboard' and 'mouse' if present, then update @world
with new USE flags

# emerge -N @world

[Gentoo]

Modern desktop environments make use of PAM session tracking for users, login
sessions and seats. [1] The most user-visible part of that is device and file
permissions management and reboot/shutdown handling without superuser rights.

Users with systemd can stop reading here and continue with their daily
routine.

ConsoleKit2 is unmaintained upstream for more than two years [2]. There are
many longstanding bugs and papercuts with consumers that aren't being fixed,
not least because these code paths receive very little testing.

Enter the elogind project [3], which is a standalone logind implementation
based on systemd code, currently maintained by a fellow Gentoo user. We have
had sys-auth/elogind available in Gentoo since the beginning of 2017, and
meanwhile it has gained support [4] in KDE Plasma, Gnome [5], Cinnamon, MATE
and Xfce, as well as most other former consolekit consumers.

Consequently, the desktop profile is switching away from consolekit to
elogind. Users of sys-auth/consolekit who selected a different profile should
consider doing the same. A guide is available [6]. Migration is easy, but any
existing consolekit session will be broken, and elogind will only begin to work
on relogin.

Rely either on the profile, or set USE="elogind -consolekit" in make.conf
yourself. Make sure there is no consolekit debris in /etc/portage/package.use:

# grep -R consolekit /etc/portage/package.use

Rebuild all affected consumers and remove sys-auth/consolekit:

# emerge --ask --changed-use --deep @world
# emerge --depclean consolekit

Optional, but recommended in case of trouble such as missing reboot/shutdown
capabilities in the display manager:

# rc-update add elogind boot

For users of ~/.xinitrc instead of one of the supported DMs, do not forget to
update accordingly (ck-launch-session is gone without replacement).

PS: Subsequently, this will lead to the last-riting of sys-power/pm-utils [7]
which is dead even longer than the original ConsoleKit(1) project. KDE Plasma
users sticking with sys-auth/consolekit are then going to lose suspend from
GUI without superuser rights.

Μεγάλο κρίμα

Μόλις έκανα το switch διαπίστωσα τα λεγόμενα στο bold κείμενο...

Επαναφορά στο consolekit λοιπόν, μέχρι νεοτέρας κι ας ελπίσουμε να βρεθεί μια λύση για το suspend γιατί είναι απαραίτητο σε αρκετούς χρήστες θέλω να πιστεύω.

[imitheos]

Μεγάλο κρίμα

Επαναφορά στο consolekit λοιπόν, μέχρι νεοτέρας κι ας ελπίσουμε να βρεθεί μια λύση για το suspend γιατί είναι απαραίτητο σε αρκετούς χρήστες θέλω να πιστεύω.

Γιατί να γυρίσεις στο consolekit; Είμαι ζαλισμένος και το μυαλό μου δεν λειτουργεί αυτή τη στιγμή αλλά το αντίθετο δεν λέει το bold; Δεν θα έχουν suspend εικονίδιο στο gui όσοι παραμείνουν στο consolekit δεν λέει;