Το thread του Debian (v.6)

[imitheos]

Δεν είναι το libpam-runtime το πακέτο που θέλεις ή κάνω λάθος;

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

1) Το pam-auth-update δεν ενεργοποιούσε παλιά την obscure (ενώ υπήρχε) και άρχισε να το κάνει τώρα.
2) Η υλοποίηση της obscure στον yescrypt είναι πιο πλήρης και ελέγχει πιο πολλά πράγματα από την "παλιά" obscure οπότε παλιά δεν πείραζε που είχες μικρό / εύκολο κωδικό.
3) Ο κωδικός σου είχε πολύ καιρό να αλλαχτεί (είπες στο ένα μηχάνημα το έστησες πιο παλιά και έμεινε από τότε) και χρησιμοποιούσε κάποια deprecated μέθοδο (πχ md5) που υποστηριζόταν παλιά αλλά όχι πλέον για αυτό πλέον σε υποχρέωνε να τον αλλάξεις.

[jim_p]

Το libpam-runtime μπορει να ειναι το πακετο που θελω, αλλα δεν αναβαθμηστηκε προσφατα. Βασικα, κανενα πακετο σκετικο με την pam δεν αναβαθμηστηκε προσφατα.
Το obscure απο εκει το εβγαλα γιατι ετσι ελεγε το howto που βρηκα για το πως οριζω το ελαχιστο μεγεθος του κωδικου.
Ο κωδικος μου δεν ειχε αλλαχτει ποτε και ειχε σαν max number of days 99999 (270κατι χρονια). Το ιδιο εχει και τωρα btw, μετα την αλλαγη.

Για τα υπολοιπα δεν γνωριζω.

[Mintux]

Σε unstable ειναι, το λεω και παραπανω.
Για αρχη, αναγκαστηκα να αλλαξω και τους 2 κωδικους για να με αφησει.
Μετα αλλαξα αυτη τη γραμμη του /etc/pam.d/common-password, απο

password	[success=1 default=ignore]	pam_unix.so obscure yescrypt

σε

password	[success=1 default=ignore]	pam_unix.so yescrypt minlen=2

που ειδα σε ενα howto και μετα τους ξαναβαλα σε οτι τους ειχα πριν. Και ετσι πλεον εχω τους παλιους μου κωδικους, που btw ειχαν οριστει Σεπτεμβριο του 2010, αλλαγμενους και ξαναορισμενους στις 17/8/21.

Αλλα ακομα δεν εμαθα ποιο κ@λοαρχειο ευθυνεται για την αλλαγη στην "πολιτικη". Το /etc/pam.d/common-password δεν ειχε αλλαξει απο κατι. Οταν με το καλο συμβει και στο testing, θα γινει bug report με το αναλογο κραξιμο.

- - - Updated - - -

Και μετα την πρωινη ενημερωση δεν ξεκιναει το δικτυο στην εκκινηση. Λεει μονο

Failed to start: ​raise network interface
See 'systemctl status networking.service' for details
A start job is running for Wait for network to be configured by ifupdown (Xm/no limit)

Γιατι τοσες μαζεμενες αναπηριες στα ξαφνικα?

- - - Updated - - -

Ειναι επειδη του λειπει το /bin/run-parts, το οποιο εινια κομματι του debianutils που σημερα αναβαθμηστηκε στην 5.x και δεν το εχει πλεον.

- - - Updated - - -

Τελικα το εχει το run-parts το debianutils, αλλα τα βοδια το πηγανε απο το /bin στο /usr/bin. Εφτιαξε με ενα

ln -s /usr/bin/run-parts /bin/run-parts

μπραβο ρε jim_p, θενξ για το network. Οι άνθρωποι είναι μλκς, πολύ μλκς!!!

Εγω δεν μιλησα για την 11, μιλησα για το unstable. Και το προβλημα παρουστηκε την μερα μετα το release της 11, που μπηκανε ξανα νεα πακετα στο unstable.

Συγγνώμη, είστε σοβαροί; Μιλάμε για UNSTABLE, το λέει και το όνομα: U N S T A B L E !

Και βρίζετε έτσι τους προγραμματιστές; Είναι ΑΣΤΑΘΕΣ λέμε και είναι απόλυτα φυσιολογικό να σπάνε πράγματα!! Αν δεν θέλετε να σπάνε, πάτε στην stable ή έστω στην testing!!

Με όλο τον σεβασμό, σας βρίσκω απαράδεκτους. Θα εκστομίζατε τέτοιες εκφράσεις αν είσασταν μπροστά τους; Θα τους κατηγορούσατε ότι το UNSTABLE είναι... unstable;

Και στο κάτω κάτω, το όποιο bug διορθώθηκε σε λίγες ημέρες, όπως λέτε και οι ίδιοι. Αν είναι δυνατόν δηλαδή, τέτοιες συμπεριφορές.

[megahead13]

@Mintux: Πώς φαίνεται ότι είσαι καινούργιος σ' αυτά εδώ τα λημέρια!

[jim_p]

Ναι θα εξεφραζα γιατι το προβλημα που δημιουργηθηκε εκανε τα συστηματα unbootable. Οπως ειπε ενας τυπος σε ενα παλιοτερο bug report που επισης εκανε το συστημα unbootable: "εσεις που κανετε το πακεταρισμα ενος τοσο σημαντικου πακετου (κατι σχετικο με το systemd ηταν τοτε), επανεκκινειτε μετα τα συστηματα σας για να δειτε οτι ολα δουλευουν καλα?".
Γιαυτο ξαναλεω οτι ειχα χρονια να δω critical και grave bugs που να κανανε το συστημα unbootable. Χρησιμοποιω unstable τα τελευταια 11 χρονια.

Meanwhile, η αλλαγη/αφαιρεση του which εχει ξεκινησει νεα δραματα και καποια προβατα προτεινουν τρελες εναλλακτικες!
https://bugs.debian.org/cgi-bin/bugr...cgi?bug=992383
https://bugs.debian.org/cgi-bin/bugr...cgi?bug=992466
https://bugs.debian.org/cgi-bin/bugr...cgi?bug=992401
https://bugs.debian.org/cgi-bin/bugr...cgi?bug=992402
https://bugs.debian.org/cgi-bin/bugr...cgi?bug=992411

[manosdoc]

Καλά τα λέει ο mintux.
Δυστυχώς.
Πέρα από μια απλή ενημέρωση προς τα άλλα μέλη για να μην κάνουν προσωρινά update αρκεί. Δεν χρειάζονται νεύρα και χαρακτηρισμοί.

Off Topic

Καλά έκανε ο TopJohnwu και την κοπάνησε...

[jim_p]

Οταν εκανα εγω την ενημερωση και την πατησα και εγραψα οσα εγραψα δεν υπηρχε ΚΑΝΕΝΑ απο τα critical και grave bug reports. Ηθελα να κανω την αρχη, αλλα προτιμησα να ψαξω για μια λυση και τελικα καποιος με προλαβε.
Επισης, τα νευρα και οι χαρακτηρισμοι δεν δημιουργουνται απο ΜΙΑ και απλη αφορμη. Θα πρεπει ειτε οι αφορμες να εινια πολλες, ειτε η αφορμη να εινια σοβαρη. Και στη συγκεκριμενη περιπτωση ηταν μια μεν, αλλα ΠΟΛΥ σοβαρη.

[famous-walker]

5 Reasons why Debian Unstable is Not for End-Users5 Gruende, warum Debian Unstable Nicht fuer End-Benutzer ist

Debian unstable is not conceived as a product for end-users, and for very good reasons. There seems to be some misunderstanding and people trying to push end-users to use unstable. This blog post tries to address the claims raised and put them into proper light.
1. It contains mainly stable versions of the software

The critical part here is the term "mainly". Yes, developers are advised to only upload packages to unstable that they deem to be suitable for the next stable release. This is no hard requirement though and no one actually playing a gate-keeper enforcing this recommendation. Also, there is a fine amount of packages that follow either VCS snapshots or development branches, and only time can tell how stable those releases actually are. That's actually why there is a delay of several days before a package can transition over to testing.
2. It doesn't break badly every other day

That's right—but if you look at it, it also means that it does break badly eventually. And if you don't know how to move on from there, including knowing the location of maintainer scripts and how to edit them in those cases, or even resort to a rescue system, you are in troubles.
3. It's the basis of other distributions

That's right in itself too, but it doesn't address the fact that those other distributions do put a lot of effort into quality assurance to work around the most nasty and annoying bugs that do affect unstable every other day.
4. It's not inherently less secure than Stable or Testing

It's not inherently more secure than stable or testing either. And this is also ignoring the fact that some security bugs don't even get into stable or testing, they only affect unstable and have to get addressed just there.
5. I use it on my main computer

This is the reason that you should ignore as most. People using unstable are often enough deeply involved into Debian maintenance, know how to write maintainer scripts, know where they are located in case of troubles, know how to use a rescue system in case of bootloader or kernel troubles. Just think about whether you would consider yourself to be at the same knowledge level than the person who wrote the blog article you read that used this as a convincing argument.

Conclusion: Stories always have several truths attached to them. If you feel adventurous, like to understand what's going on and have a tendency for digging into things that go wrong, you most probably are using unstable already anyway and are reporting bugs that you find along your way. If you on the other hand rather "just" want to use your computer and don't want to work around (smaller) bugs every other day, you rather should stick with the release that is actually provided as purpose to suit the needs of end-users: stable.

https://rhonda.deb.at/blog/debian/5-...-everyone.html

[imitheos]

Συγγνώμη, είστε σοβαροί; Μιλάμε για UNSTABLE, το λέει και το όνομα: U N S T A B L E !

Και βρίζετε έτσι τους προγραμματιστές; Είναι ΑΣΤΑΘΕΣ λέμε και είναι απόλυτα φυσιολογικό να σπάνε πράγματα!! Αν δεν θέλετε να σπάνε, πάτε στην stable ή έστω στην testing!!

Το πρόβλημα είναι αυτό ακριβώς που έγραψε ο famous-walker. Στο 95% του χρόνου είναι μια χαρά σταθερό οπότε δημιουργείται η εντύπωση ότι μπορεί να το βάλει και ένας αρχάριος "για να έχει τις τελευταίες εκδόσεις προγραμμάτων". Διαβάζει κιόλας κάποιος σε φόρα τον Χ και τον Ψ να λένε ότι το έχουν για χρόνια και δεν έσπασε ποτέ και πάει και το βάζει. Μέχρι και το fedora rawhide έχω διαβάσει να χρησιμοποιούν κάποιοι σε production μηχανήματα. Αν α) έχεις κάποιες γνώσεις και β) δεν σε πειράζει κιόλας να ασχοληθείς όταν μία στο τόσο χαλάσει, τότε οκ, βάλε ό,τι θέλεις. Ο jim_p δεν είναι αρχάριος μεν, θέλει όμως να παίζουν όλα χωρίς να ασχοληθεί και για αυτό γκρινιάζει όταν χαλάει κάτι.

Φταίνε όμως και οι προγραμματιστές . Πρέπει να βάλουν ένα cron job το οποίο μία τυχαία μέρα κάθε μήνα, να χαλάει κάτι τυχαία ώστε να είναι πιο συχνά "unstable" και να αποτρέπει τον κόσμο από το να το εγκαταστήσει

[jim_p]

Ποιο πακετο χρησιμοποιειτε για locate? Παρατηρησα πριν λιγο στο testing πως το mlocate που ειχα βαζει πλεον το plocate.

[patch]

Ποιο πακετο χρησιμοποιειτε για locate? Παρατηρησα πριν λιγο στο testing πως το mlocate που ειχα βαζει πλεον το plocate.

find

[jim_p]

Αργο σε σχεση με το locate και πολυ περιπλοκο σε συνταξη. Για το δευτερο λογο, εχω εδω και ενα χρονο σχεδον το fd-find.

[Jojos170304]

Υπάρχει κ το experimental παίδες για αυτές τις μλκς τους. Όντως ο μίντουξ γράφει ως ο αφελής καλοπροαίρετος νιούμπης. Θα εκπαιδευτεί, δεν πειράζει

Ειδικά αυτό που κάνανε με το network ήταν απαράδεκτο καθώς ουσιαστικά αν δεν είχες άλλη πρόσβαση από άλλο μηχανάκι στο νετ να ψαχτείς την είχες γμσ, δεν υπήρχε τρόπος να αναιρεθεί το σφάλμα. Οπότε ναι, είναι μεγάλοι μλκς που τους ξέφυγε κάτι τέτοιο. Κάτι τέτοια αμαυρώνουν την καλύτερη διανομή.

Κατά τα άλλα το sid είναι βράχος κ με σύγχρονες (σχετικά) ενημερώσεις πακέτων. Τα άλλα, testing κ stable, είναι αιώνες πίσω.

Μπράβο κ πάλι στον jim_p

[ckoul]

Υπάρχει κ το experimental παίδες για αυτές τις μλκς τους. Όντως ο μίντουξ γράφει ως ο αφελής καλοπροαίρετος νιούμπης. Θα εκπαιδευτεί, δεν πειράζει

Ειδικά αυτό που κάνανε με το network ήταν απαράδεκτο καθώς ουσιαστικά αν δεν είχες άλλη πρόσβαση από άλλο μηχανάκι στο νετ να ψαχτείς την είχες γμσ, δεν υπήρχε τρόπος να αναιρεθεί το σφάλμα. Οπότε ναι, είναι μεγάλοι μλκς που τους ξέφυγε κάτι τέτοιο. Κάτι τέτοια αμαυρώνουν την καλύτερη διανομή.

Κατά τα άλλα το sid είναι βράχος κ με σύγχρονες (σχετικά) ενημερώσεις πακέτων. Τα άλλα, testing κ stable, είναι αιώνες πίσω.

Μπράβο κ πάλι στον jim_p

Συντάσσομαι κι εγώ στους αφελείς, καλοπροαίρετους νιούμπηδες και δεν προτίθεμαι να «εκπαιδευτώ» να βρίζω και να χαρακτηρίζω με απαράδεκτο τρόπο αυτούς που μου χαρίζουν όλο αυτό το υπέροχο software-project επειδή έσπασε αυτό που με έχουν προειδοποιήσει ότι θα σπάσει ή επειδή δεν μου πακετάρουν το πακέτο που ΕΓΩ γουστάρω να μου πακετάρουν.

Να με συγχωρείτε κιόλας αλλά αυτά είναι αθλιότητες γι αυτό και έχω σταματήσει να ασχολούμαι από καιρό.. ο μόνος λόγος που σχολιάζω είναι για να μην νομίζει ο mintux ότι βρίσκεται σε άλλο πλανήτη όταν αυτά που γράφει είναι τα προφανή!

[jim_p]

επειδή δεν μου πακετάρουν το πακέτο που ΕΓΩ γουστάρω να μου πακετάρουν.

Επειδη αυτο μαλλον αναφερεται σε μενα, ποιο πακετο ζητησα να μου πακεταρουν?