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

[petran_18]

Μπαίνει σε καμιά βδομάδα συνήθως. Μέχρι να βγει η εκάστοτε 5.x.1, το έχουν βάλει. Υπομονή.

Περιμένουν την Qt-5.11. Θα πάρει καιρό από ότι φαίνεται.

[GoofyX]

RIP kdelibs4

Και άλλο κουτσομπολιό:

2018-06-23-mpfr-4-update
Title dev-libs/mpfr 4 upgrade
Author Matthias Maier <tamiko@gentoo.org>
Posted 2018-06-23
Revision 1

dev-libs/mpfr-4 introduced an ABI and soname change that has the potential
of breaking the compiler toolchain. In order to minimize potential problems
it is strongly recommended to rebuild mpc and gcc immediately after mpfr.
You can do this by running

emerge --ask --oneshot ">=dev-libs/mpfr-4" dev-libs/mpc sys-devel/gcc

Detailed explanation:

libmpfr.so is used by libmpc.so (provided by dev-libs/mpc), as well as by
internal executables (e.g. cc1, cc1plus) of sys-devel/gcc. Appropriate
subslots in mpfr and slot-operators in dependencies in mpc and gcc will
cause a rebuild of mpc and gcc after an upgrade of mpfr.

However, after mpfr-4 is installed and mpc rebuiltd, but *before* gcc is
rebuilt, gcc will be in an inconsistent state wherein symbols from
incorrect library versions of mpfr might get used. This can result in
segfaults and internal compiler errors. It is therefore important to
rebuild gcc immmediately after mpc.

A detailed update guide with troubleshoot section can be found on the wiki:
https://wiki.gentoo.org/wiki/Mpfr4-update-guide

Όποτε βλέπω κάτι τέτοια rebuild, βγάζω σπυριά...

[alfaeffe]

Εδω παντως δε χρειαστηκε καν να κανω την εντολη του news update. Σκετο emerge -uDNv world και εκανε μονο του τα updates & rebuilds και μαλιστα με τη σειρα που περιγραφει και στο news: πρωτα mpfr-4, μετα mpc, επειτα gcc και στη συνεχεια ολο το υπολοιπο set των updates.
Το portage εχει βελτιωθει παρα πολυ απο την εποχη που επρεπε να κανουμε revdep-rebuild...

[imitheos]

RIP kdelibs4

Και άλλο κουτσομπολιό:

Όποτε βλέπω κάτι τέτοια rebuild, βγάζω σπυριά...

Τι να κλάσει η mpfr. Δεν έκανες ποτέ αναβάθμιση την libpng ?

Μια περίοδο πριν χρόνια που βγήκε η έκδοση 1.Υ και ήταν ασύμβατη με την 1.Χ που υπήρχε πριν και γ..ταν ο Δίας. Μια άλλη περίοδο σε minor εκδόσεις άλλαζε το api και ξαφνικά άρχιζαν να κρασάρουν προγράμματα.

Edit: 40 λεπτά αργότερα έτοιμος ο gcc. Για την ώρα όλα φαίνονται να δουλεύουν τζάμι.

Με την ευκαιρία της mpfr μπήκα και εγώ στο τριπάκι να κάνω την αναβάθμιση. Μόλις είχα κάνει compile τον gcc 8.1.0, βγήκε η έκδοση -r1 και μετά φτάσαμε στην -r3 αλλά δεν με καίγανε τα patches που μπήκανε οπότε απέφευγα το recompile. Όσες ημέρες και να περιμένω, μόλις κάνω compile κάτι βαρύ όπως gcc, glibc, κτλ, τότε θα δουν ότι ξέχασαν κάτι και θα βγει -rX ebuild

Εντωμεταξύ η 4άρα mpfr ήταν ~amd64 και μέχρι τώρα δεν την είχα βάλει οπότε με την ευκαιρία έκανα μετάβαση σε ~amd64 και σε κάποια άλλα προγράμματα.

[tsigarid]

Προσοχή!!! Χάκαραν το gentoo github.

https://www.gentoo.org/news/2018/06/...rg-hacked.html

[alfaeffe]

Since the master Gentoo ebuild repository is hosted on our own infrastructure and since Github is only a mirror for it, you are fine as long as you are using rsync or webrsync from gentoo.org

Οποτε αν εχουμε rsync στο gentoo.conf μας ειμαστε οκ λογικα:

[DEFAULT]
main-repo = gentoo

[gentoo]
location = /usr/portage
sync-type = rsync
sync-uri = rsync://rsync.gentoo.org/gentoo-portage
...

[imitheos]

Για όσους πανικοβλήθηκαν να ξεκαθαρίσουμε ότι το 99% των χρηστών δεν έχουν να φοβούνται.

Όσοι χρησιμοποιούν rsync δεν έχουν να φοβηθούν επειδή χρησιμοποιούν τους servers του .gentoo.org.

Για όσους χρησιμοποιούμε git υπάρχουν τρεις βασικοί "servers":
α) git://anongit.gentoo.org
β) git://github.com/gentoo/*
γ) git://github.com/gentoo-mirror/*

Ο α) είναι ο επίσημος server του gentoo ο οποίος δεν έχει χακευτεί οπότε όσοι τον χρησιμοποιούν δεν έχουν να φοβούνται τίποτα. Είθισται να μην χρησιμοποιείται αυτός από εμάς επειδή χιλιάδες users να κάνουμε sync τοποθετεί φόρτο στα μηχανήματα και καλό είναι να χρησιμοποιείται από devs μόνο. Για αυτό το λόγο δημιουργήθηκε ο mirror β) στο github.

Σίγουρα θα θυμούνται κάποιοι ότι όταν έγινε η μετάβαση στο git υπήρχε πρόβλημα με τα μεταδεδομένα που δημιουργούνται και ευθύνονται για την ταχύτατη απόκριση του eix. Έτσι στο φόρουμ κυκλοφορούσαν διάφορα post-sync scripts τα οποία μετά από κάθε sync έτρεχαν την δημιουργία των μεταδεδομένων. Αυτό όμως είναι χρονοβόρα διαδικασία με αποτέλεσμα να μην ήθελαν οι χρήστες να την κάνουν και για αυτό δημιουργήθηκε ένας ακόμη mirror στον λογαριασμό gentoo-mirror στον οποίο τρέχει κάθε τόσο ένα scriptάκι που δημιουργεί τα μεταδεδομένα για εμάς. Έτσι λοιπόν ο ενδεδειγμένος server για τον κοινό χρήστη είναι ο γ) και ο οποίος δεν χακεύτηκε. Οπότε το 99% των χρηστών δεν έχουν να φοβούνται τίποτα.

Οι μόνοι που ίσως έχουν πρόβλημα είναι όσοι χρησιμοποιούν git με τον β) server και αυτό πάλι είναι χλωμό λόγω του τρόπου που δουλεύει το git.

Ας υποθέσουμε ότι τα commits ακολουθούν το εξής πρότυπο α -> β -> γ -> δ -> ε.

Εμείς την τελευταία φορά που κάναμε sync λάβαμε το commit β σαν tip του branch και από τότε μπήκαν 3 νέα commits τα γ, δ, ε. Αν αυτοί που χάκεψαν τον λογαριασμό πείραξαν οποιοδήποτε commit μέχρι και το β, τότε θα αλλάξουν τα commit ids και όταν κάνουμε git pull θα αποτύχει οπότε θα έχουμε την ένδειξη ότι κάτι έχει πειραχθεί.

Η μόνη περίπτωση να λάβουμε πειραγμένα commits είναι να πειραχθεί κάποιο commits από τα γ, δ, ε που δεν έχουμε οπότε το git δεν ξέρει να μας ειδοποιήσει ότι κάτι έγινε δηλαδή ζήσε μάη μου να φας τριφύλλι. Είναι πάρα πολύ χλωμό να πάρει κάποιος χακεμένο tree.. Άκυρο αυτό που έγραψα πριν. Έφοσον μπορεί να δημιουργήσει νέα commits, είναι εύκολο να εισάγει κακόβουλο περιεχόμενο αλλά μπορούμε να το καταλάβουμε επειδή δεν θα έχει σωστές υπογραφές.

[GoofyX]

Το https://github.com/gentoo/gentoo επανήλθε.

[GoofyX]

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

2018-07-11-portage-sync-allow-hardlinks
Title Portage rsync hardlink support
Author Zac Medico <zmedico@gentoo.org>
Posted 2018-07-11
Revision 1

For users of the rsync tree, beginning with sys-apps/portage-2.3.42,
the default behavior for sync operations will use hardlinks in order
to ensure that a repository remains in a valid state if something
goes wrong [1]. For example, if signature verification fails during a
sync operation, the new hardlink behavior will preserve the previous
state of the repository.

The new behavior may conflict with configurations that restrict the
use of hardlinks, such as overlay filesystems. Therefore, users will
have to set "sync-allow-hardlinks = no" in repos.conf if they have
a configuration that restricts the use of hardlinks, but this should
not be very common:

[DEFAULT]
sync-allow-hardlinks = no

Note that it is possible to sync more efficiently using git [2]
instead of rsync, though git consumes an increasing amount of disk
space over time unless shallow pull is enabled via the sync-depth
option in repos.conf [3] (requires sys-apps/portage-2.3.42 or later).

[1] https://bugs.gentoo.org/660410 sys-apps/portage: use rsync
--link-dest to implement atomic repository updates (and abort if
signature verification fails)
[2] https://wiki.gentoo.org/wiki/Portage...it-mirror_repo
[3] https://bugs.gentoo.org/552814 sys-apps/portage: support shallow
git pull by setting sync-depth = 1 in repos.conf

[tsigarid]

Δεν είμαι σίγουρος αν είναι για εδώ η ερώτηση, αλλά μιας και τρέχω Gentoo θα δοκιμάσω.

Συνδέομαι στο Gentoo μου με Cygwin, και όλα καλά. Πρόσφατα παρατήρησα ότι όταν ανοίγω το vi μέσα από screen ο κέρσορας από block γίνεται γραμμή, και αυτό δεν επανέρχεται παρά μόνο αν κλείσω το παράθυρο του Cygwin τελείως. Αν ανοίξω vi εκτός screen δεν υπάρχει πρόβλημα. Καμία ιδέα; Έκανα rollback σε κάποια παλιά έκδοση του screen και δεν άλλαξε τίποτα. Δεν μπορώ να κάνω rollback σε παλιό vi γιατί έχω την παλιότερη έκδοση (με βάση το eix). Καμία ιδέα;

[imitheos]

Δεν είμαι σίγουρος αν είναι για εδώ η ερώτηση, αλλά μιας και τρέχω Gentoo θα δοκιμάσω.

Συνδέομαι στο Gentoo μου με Cygwin, και όλα καλά. Πρόσφατα παρατήρησα ότι όταν ανοίγω το vi μέσα από screen ο κέρσορας από block γίνεται γραμμή, και αυτό δεν επανέρχεται παρά μόνο αν κλείσω το παράθυρο του Cygwin τελείως. Αν ανοίξω vi εκτός screen δεν υπάρχει πρόβλημα. Καμία ιδέα; Έκανα rollback σε κάποια παλιά έκδοση του screen και δεν άλλαξε τίποτα. Δεν μπορώ να κάνω rollback σε παλιό vi γιατί έχω την παλιότερη έκδοση (με βάση το eix). Καμία ιδέα;

Μήπως κάτι γίνεται με το $TERM ? Συνήθως αυτό φταίει σε τέτοια πρόβλήματα. Όταν μπαίνεις screen συνήθως το screen αλλάζει αυτόματα την μεταβλητή TERM σε "screen" ενώ χωρίς να τρέχει το screen θα έχει ό,τι τιμή θέτει το cygwin. Δοκίμασε να δεις τι τιμή έχει (πχ xterm ή cygwin) και αφού τρέξεις το screen ξανά δώσε αυτή την τιμή πριν τρέξεις vim.

[tsigarid]

Μήπως κάτι γίνεται με το $TERM ? Συνήθως αυτό φταίει σε τέτοια πρόβλήματα. Όταν μπαίνεις screen συνήθως το screen αλλάζει αυτόματα την μεταβλητή TERM σε "screen" ενώ χωρίς να τρέχει το screen θα έχει ό,τι τιμή θέτει το cygwin. Δοκίμασε να δεις τι τιμή έχει (πχ xterm ή cygwin) και αφού τρέξεις το screen ξανά δώσε αυτή την τιμή πριν τρέξεις vim.

Δεν ήταν αυτό. Το cygwin έχει τιμή xterm, μέσα σε screen έχει τιμή screen, και ακόμα και αν την αλλάξω μόλις ανοίγω το vi ο κέρσορας γίνεται γραμμή.

- - - Updated - - -

ΥΓ: Ο κέρσορας γίνεται γραμμή σε όλα τα παράθυρα του screen, ακόμα και όταν αποσυνδεθώ από αυτό ή το τερματίσω, άρα πρέπει να φταίει το vim ή το ίδιο το cygwin, αλλά μόνο στο Gentoo μου το κάνει. Τι να πω... Πως μπορώ να κάνω roll back το vim, παρόλο που το eix μου λέει ότι έχω την παλιότερη έκδοση;

eix -e vim
[I] app-editors/vim
     Available versions:  8.0.1298 ~8.0.1428 ~8.0.1645 ~8.0.1699 ~8.1.0034 **9999 {X acl cscope debug gpm lua luajit minimal nls perl python racket ruby selinux tcl terminal vim-pager PYTHON_SINGLE_TARGET="python2_7 python3_4 python3_5 python3_6" PYTHON_TARGETS="python2_7 python3_4 python3_5 python3_6"}
     Installed versions:  8.0.1298(06:17:00 PM 04/05/2018)(X acl nls python -cscope -debug -gpm -lua -luajit -minimal -perl -racket -ruby -selinux -tcl -terminal -vim-pager PYTHON_SINGLE_TARGET="python2_7 -python3_4 -python3_5 -python3_6" PYTHON_TARGETS="python2_7 python3_6 -python3_4 -python3_5")
     Homepage:            https://vim.sourceforge.io/ https://github.com/vim/vim
     Description:         Vim, an improved vi-style text editor

[pmav99]

Δεν είναι λύση φυσικά, αλλά σαν workaround, αν θες δοκίμασε και το tmux

[GoofyX]

Μόνο ο jim_p θα παραπονιέται για το Debian και την ανανέωση των πακέτων του...; Αμ δε.

Έχει ήδη βγει Firefox 61.0.2 και το Gentoo έχει παραμείνει στην 61. Άνοιξα bug report για bump στην 61.0.1 αλλά η απάντηση είναι το κλασικό "περίμενε, η ομάδα mozilla το παρακολουθεί και συνήθως το ενημερώνει". Αμ δε, πέρασε ένας μήνας από το bug report και τίποτα και ενδιάμεσα βγήκε η 61.0.2. Εν τω μεταξύ και στο mozilla overlay και φυσικά στο portage έχει να ανανεωθεί ο Firefox ο Θεός ξέρει από πότε.

Κατά τα άλλα όμως, ο chrome και ο opera ενημερώνονται σχεδόν σε καθημερινή βάση.

Εγώ είμαι ο περίεργος...;

[imitheos]

Ναι η αργοπορία στα ff ebuilds είναι κλασικό θέμα. Δε θυμάσαι πόσες φορές έχω γκαρίξει ?

Σίγουρα δεν είναι εύκολη δουλειά να παρακολουθείς το build system του firefox αλλά τόσο μεγάλη αργοπορία ? Άσε που στα stable upgrades δεν νομίζω να αλλάζει κάτι στα build requirements. Όσες φορές το έκανα μόνος μου, ένα απλό copy στο ebuild με νέο όνομα ήταν αρκετό.