Debian: how-can-i-help

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

Αρκεί να ξέρεις λίγο μια γλώσσα προγραμματισμού, δεν είναι ανάγκη να έχεις χρόνια εμπειρία. Άλλωστε από κάπου πρέπει να ξεκινήσει κανείς. Και τι καλύτερο για να αποκτήσεις εμπειρία από το να συμβάλεις σε ένα επιτυχημένο έργο ανοικτού κώδικα; Μια σχολή μπορεί να σε πάει μέχρι ένα σημείο. Αλλά ο μελλοντικός σου εργοδότης θα θέλει και κάτι παραπάνω. Έτσι μπορείς να έχεις κάτι να του δείξεις και ταυτόχρονα να αποδείξεις πως έχεις την ποιο σημαντική ικανότητα για ένα προγραματιστη: ότι μπορείς να δουλεύεις σε υπάρχον κώδικα μέσα σε μια ομάδα.

Είτε λοιπόν τα κίνητρα σου είναι ιδεαλιστικά είτε αφορούν το πορτοφόλι, είτε γιατί όχι και τα δυο ταυτόχρονα, είναι ένα μονοπάτι που μπορεί να σε πάει μακρυά. Αλλά πως μπορείς να ξεκινήσεις; Πως μπορείς να βρεις κάτι στα μέτρα σου;

how-can-i-help ?

Αν έχεις Debian :debian: ή μια διανομή βασισμένη σε αυτό όπως Ubuntu :ubuntu: ή Mint :mint: δώσε τώρα στο τερματικό την εντολή

apt install how-can-i-help

Αυτό που θα κάνει είναι να δείχνει μια λίστα με θέματα που το Debian θέλει βοήθεια κάθε φορά που θα χρησιμοποιείς την εντολή apt. Την πρώτη φορά η λίστα θα είναι μεγάλη, αλλά μην τρομάξεις! Την επόμενη φορά θα είναι 2-3 καταχωρήσεις.

Ακόμα και αν δεν έχεις σκοπό να βοηθήσεις σήμερα, δεν βλάπτει καθόλου να εγκαταστήσεις την εντολή. Δεν χάνεις κάτι και μπορεί να σου έρθει έμπνευση μια μέρα :slight_smile:

Αν θέλεις να δεις περισσότερα γράψε στο τερματικό

how-can-i-help --old --show newcomer

Και θα δεις κάτι σαν το παρακάτω:

how-can-i-help --old --show newcomer
======  How can you help?  (doc: ) ======

Bugs affecting packages, suitable for new contributors (tagged 'newcomer'):
 - alsa-utils - - alsa-base: Front Panel Jack for play audio not working
 - apt - - Pre-Download hook
 - apt - - apt-listchanges: show changes while downloading
 - apt - - apt-cdrom: MultiArch support with a single CD-ROM drive
 - apt - - apt: Removing virtual packages doesn't work as you would expect
 - apt - - apt-get should provide a clear message if not root
 - apt - - command to delete downloaded package lists and package cache, for container building
 - apt-xapian-index - - apt-xapian-index: uses obsolete Xapian method
 - aptitude - - aptitude: fetch and display copyright (like changelog)
 - aptitude - - aptitude: Repeated "Downloaded" lines w/
 - baloo-kf5 - - baloo-kf5: baloo_file 5.62.0-2 (current testing) crashes on amd64 on database creation
 - clang - - clang ships most libraries as static libraries, not shared ones
 - debianutils - - which: doesn't respect $PATH when it contains '~' character
 - file - - file: no detection for dosbox's pcjr rom cartrage format
 - firefox - - firefox: More Plasma compatibility like plasmazilla provides for ubuntu
 - gnome-logs - - gnome-logs does not prompt the user to elevate privileges
 - gnome-logs - - gnome-logs does not prompt to elevate privileges, cannot view system logs
 - gnome-logs - - gnome-logs: gnome-log fails to show log ouput on debian-live-9.0.0-amd64-gnome
 - gnome-logs - - gnome-logs: Launching gnome-logs provides an error "Unable to read system logs"
 - ifupdown - - ifupdown needs better support for complex ip route and rules
 - imagemagick - - imagemagick: Generates wrong image with annotate (missing character,, strange lines)
 - keyboard-configuration - - keyboard-configuration: dpkg-reconfigure keyboard-configuration - changes not persistent unless console-setup is alo run
 - lightdm - - lightdm: does not source ~/.profile
 - lightdm - - lightdm does not source ~/.profile
 - lightdm - - Missing user_readenv=1 in the pam file
 - lightdm - - lightdm does not source ~/.profile
 - lintian - - lintian: Graph (SVG) files on lack tag name
 - pulseaudio-module-bluetooth - - pulseaudio-module-bluetooth: please backport a2dp sync fix from v12 to stretch
 - seahorse - - seahorse: Generic error when you add picture
 - synaptic - - synaptic: 'lock version' harmful; replace with dpkg holds
 - synaptic - - synaptic icon seems pixelated (jessie)
 - synaptic - - synaptic: Synaptic 0.84.5 - same issues as reported in earlier releases
 - unattended-upgrades - - unattended-upgrades: include list of packages requiring reboot, from /var/run/reboot-required.pkgs
 - unattended-upgrades - - unattended-upgrades: explain reasons why packages with upgradable origin are kept back
 - unattended-upgrades - - unattended-upgrades: MOTD mention about packages that could not be upgraded
 - unattended-upgrades - - /usr/bin/unattended-upgrade: unattended-upgrade sets speed to 70kbps even for manual apt runs
 - util-linux - - libmount: provide extra package for pylibmount (Python bindings for libmount)
 - virt-manager - - virt-manager: Virt-manager uses qemu-system-i386 /usr/lib/xen/bin
 - x11-common - - Xsession script to process /etc/profile and ~/.profile
 - xserver-xorg-core - - Add elogind support to Recommends:
 - xz-utils - - xzcmp: SIGPIPE is raised because CMP does exit while the XZ commands are still writing to the pipe
 - zsh - - unnecessary files
 - zsh-common - - zshrc: zsh-common: zsh-line-init should use add-zle-hook-function

Bugs affecting Debian infrastructure (tagged 'newcomer'):
 - - - Only add Bug# to the front if the bug# doesn't exist anywhere in the subject
 - - - Vagrant/virtualbox: Optionally disable rsync synced_folder if vagrant-vbguest is installed
 - - - Please add a mechanism to test mail dispatch
 - - - debsources: make trend charts more readable
 - - - debsources: increase/maximize test coverage
 - - - debsources: improve webapp 404 handling (e.g. jessie -> stretch move)
 - - - debsources: 404 pages should look similar to the version list pages
 - - - improve license rendering
 - - - provide a more explicit error when querying license of a directory
 - - - debsources: deduplicate the html setting the background image
 - - - DDPO: unxz: (stdin): File format not recognized
 - - - britney: Add "block-all udeb" support
 - - - better wording for "old bugs"
 - security-tracker - - security-tracker: use bug report based URLs in preference to TEMP-*-* based URLs
 - security-tracker - - security-tracker: do not mention TEMP-*-* identifiers on security issue pages
 - security-tracker - - security-tracker: do not mention TEMP-*-* identifiers on source package pages
 - - - PTS: Please provide a link to the NEWS file if it exists
 - - - Uploader warning on higher than standard priority packages
 - - - Add long description as a tooltip on top of the short description
 - - - package description don't shown if the package is available in a suite different than unstable
 - - - suboptimal wording with patch/help action short descriptions
 - - - Distro Tracker should rely on "codename" and not "suite" to update its view of repositories
 - - - doesn't understand multiple entries from qa.d.o wnpp_rm
 - - - wrong versioned links for security versions
 - - - .dsc link to packages in update is broken
 - - - Failed to handle Vcs-git: -b situation
 - - - Debian Maintainer display: [dm] links empty, should be uppercase and use parentheses
 - - - linkify bugs in testing removal news items
 - - - does not remove the versions panel when the package has been removed entirely
 - - - removed packages improvements: add snapshot.d.o link, update bugs links
 - - - Tracker shows for berkshelf package a version in unstable altough there is no such package in any release anymore
 - - - JavaScript should support LibreJS
 - - - whitelist account registration for all Debian contributors
 - - - Who's using Debian page - 2014 update
 - - - More/updated Debian women profiles
 - - - updating Debian memberships in other organisations information
 - - - Update the homepage, to show the social face of the project, and be more attractive for newcomers
 - - - Test in small and big screens and fix it if needed
 - - - [] update broken links to (and aliases)
 - - - Broken policy documentation links in p.d.o
 - - - Updating Debian ports web pages

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

Άλλοι τρόποι

Υπάρχουν sites που συγκεντρώνουν εύκολα για αρχάριους προβλήματα ή βοήθεια για νέα χαρακτηριστικά όπως

Μπορείς επίσης να χρησιμοποιήσεις την μηχανή αναζήτησης του Github. Ας πούμε ότι ξέρεις Javascript και αναζητάς κάτι εύκολο. Ψάχνεις ως εξής:

is:issue is:open label:"beginner" language:javascript✓&q=is%3Aissue+is%3Aopen+label%3A"beginner"+language%3Ajavascript

Και μην ξεχνάς πως ακόμα και αν δεν ξέρεις προγραμματισμό μπορείς να βοηθήσεις με καλά bug reports και testing, καθώς και με μεταφράσεις ή να γράψεις documentation. Κανείς προγραμματιστής δεν θέλει να γράφει documentation.



A post was merged into an existing topic: Πώς να γίνω προγραμματιστής;

4 posts were split to a new topic: Πώς να γίνω προγραμματιστής;

Η πιο εύκολη αλλά και ταυτόχρονα σημαντική συνεισφορά είναι το packaging. Δεν χρειάζεται να είναι κάποιος προγραμματιστής. Αρκεί να μάθει μία σειρά από κανόνες (στη προκείμενη περίπτωση Debian packages). Στην ουσία, βρίσκεις ένα πρόγραμμα το οποίο υπάρχει σε καποιος cms, πχ github/gitlab, που και αναλαμβάνεις να “ενημερώνεις” το αντίστοιχο πακέτο του. Με αυτόν το τρόπο μαθαίνεις πως λειτουργεί το οικοσύστημα της εφαρμογής σου και συμμετέχεις με τον πιο ενεργό τρόπο.


Μιας και η ενότητα είναι how… Θα σας ήταν εύκολο να μοιράστητε μαζί μας ένα πακετάρισμα ας πουμε???
με ενδιαφέρει να συνεισφέρω απλά δε γνωρίζω…

1 Like

Προσωπικά έμαθα κυρίως από το παρακάτω


Δεν γνωρίζω από Debian packaging, αλλά αρκετά χρόνια έκανα πακετάρισμα σε RPM, μέσω του OpenBuildService. Στην ουσία είναι κάπως έτσι:

  1. Βρίσκεις το project στο github που σε ενδιαφέρει και θέλεις να το κάνει μέρος της διανομής σου.
  2. Μαθαίνει να το κάνεις build εσύ ο ίδιος. Ανάλογα με τη γλώσσα προγραμματισμού θα είναι διαφορετικό.
  3. Διαβάζεις το documentation της διανομής σου και ρωτάς στο forum/mail/chat για του υπάρχει περισσότερο documentation για να σε βοηθήσει.
  4. Ξεκινάς τοπικά να φτιάχνεις το *.deb αρχείο. Στην ουσία φτιάχνεις ένα *.spec αρχείο όπου βάζεις μέσα ένα κάρο πληροφορίες (του στιλ ποιος ειναι ο προγραμματιστης, την έκδοση, την άδεια κλπ). Μετά βάζεις από που θα τραβάει το αρχείο (δηλαδή το source code link από το github). Εκει γράφεις σε bash τις εντολές που χρησιμοποιείς από το βήμα 2. Εκεί σημαντικό να δηλώσεις τα dependencies (τα οποία χρειάζονται σε build deps, και run deps) ώστε να ξέρει ο package manager τι να κάνει. Τέλος, σκέφτεσαι αν χρειάζεται να γίνεται κάτι μετά την εγκατάσταση (πχ να αλλάζει κάποια permissions). Και τέλος κάνει cp τα αντίστοιχα docs και manpages στα ανάλογα directories της διανομής σου.
  5. Τώρα που έχεις φτιάξει το deb, κάθεσαι και αυτοματοποιείς την όλη φάση, δηλαδή την επόμενη φορά που θα βγει η νέα έκδοση, τότε εσύ είσαι υπεύθυνος για να την κάνεις update. Καλό θα ήταν λοιπόν πράγματα όπως: link με το νέο tar.gz, το version της έκδοσης, το changelog, κλπ να τα κάνεις update αυτόματα και να μην τα παίρνεις με το χέρι (copy paste) κάθε φορά.
  6. Οταν είσαι έτοιμος, κάνεις submit στο repo της διανομής σου και σε έχουν υπο εξέταση.
  7. Αν βάλουν το πακέτο σου στην επίσημη διανομή τότε είσαι υπευθυνος για τα πάντα γυρω από αυτό. πχ αν σκάσει bug, θα σου έρθει mail. Προφανώς δεν θα το φτιάξεις εσύ γιατί το πιο πιθανό είναι να μην έχεις ιδέα για το πως δουλεύει ο κώδικας του προγράμματος (εσύ απλά το πακέταρες), αλλά κάνεις monitoring το github και βλέπεις αν οι προγραμματιστές είναι ενήμεροι (συνήθως είναι). Οπότε μπορείς να χρειαστεί να κάνεις update το πακέτο στην καινούρια έκδοση.

ΥΣ: Είναι σύνηθες έχεις ένα fork στο github το πακέτου σου και με ένα GitHub action να το κρατάς διαρκώς συχγρονισμένο. Ο στόχος είναι πως στο δικό σου github fork, μπορείς να κάνεις πράγματα που δεν μπορείς να κάνεις στο άλλο (το original repo). Τι πράγματα; πχ να βάλεις γίνεται το όλο package building στο github και να σου ετοιμάζει το αρχειάκι *.deb αυτόματα, ώστε να μην πρέπει να κοιτάς κάθε μέρα αν βγήκε καινούρια έκδοση. Φυσικά αυτό είναι θες να είσαι επαγγελματίας στη δουλειά σου και να παρέχεις latest versions όσο πιο γρήγορα γίνεται στην κοινότητα της διανομής σου. Μίλησα για το OpenBuildService γιατί μπορείς να το συνδέσεις με το original project του Github, το οποίο το κάνει poll κάθε τρεις και λίγο, και έτσι αποφεύγεις το step να φτιάξεις δικό σου fork.

Τέλος μπορείς να το κάνεις build σε διάφορες αρχιτεκτονικές (πχ 32bit, arm, arm64, s390x, κλπ).

Οπότε στην ουσία:

  • Πρέπει να ξέρεις πως να κάνεις build το πρόγραμμα που θες να πακετάρεις. Συνήθως είναι ένα ./configure και make.
  • Να μάθεις πώς να γράφεις το spec file για το πακέτο σου.
  • Να μάθεις το πως λειτουργεί η διανομή σου από την άποψη διανομής των πακέτων.
  • Option: να κάνεις όλους τους παραπάνω αυτοματισμους.

Τι προτείνω:

Γράψε ένα helloworld πρόγραμμα σε C. Βάλε το στο github. Και φτιάξε ένα πακέτο για αυτό, με ότι συνεπάγεται. Ετσι θα πάρεις μία ιδέα.

Αφου το κάνεις αυτό, βρες ενα πρόγραμμα που θες να πακετάρεις. Δες τι γλώσσα είναι γραμμένο και μετά πάνε και κατέβασε περίπου 5 αντίστοιχα source πακέτα γραμμένα στην ίδια γλώσσα, και διάβασε το spec file τους για να πάρεις ιδεες.

ΥΣ: Στην περίπτωση που στο Debian packaging δεν υπάρχει specfile θα πρέπει να υπάρχει κάτι αντίστοιχο.

πχ ημουν ο maintainer του minikube στην SUSE. Contribute to minikube in a nutshell · Panos Georgiadis