Помочь GNU/Linux — это просто!

    Эта статья рассказывает о том, как я, внезапно для себя, перешел с уровня простого пользователя GNU/Linux на уровень контрибьютора в мир open source. Надеюсь что она сможет послужить еще кому-то примером для собственного роста.

    Начало

    Все началось с того, что я, как всегда, перешел на новый релиз Ubuntu, на этот раз на 13.04. У меня оказалась не самая удачная материнка для линуксоида, так как в дистрибутивах из коробки редко есть дрова для ее сетевой карты (RLT8168E). Но ведь это не большая беда, верно? Раздобыв сопутствующие для компилирования пакеты, скачал с офф сайта последние дрова на Linux. Я уже делал так с Ubuntu 12.10 и ничто не предвещало подвоха.

    Подвох

    Внезапно эти «дрова» не компилируются. Немного повтыкая в текст ошибок, я пошел просить совета на linux@conference.jabber.ru. Там мне рассказали, что брать дрова с сайта — не всегда хорошая идея и что для моей сетевой карты в репозитории есть пакет. Приятный сюрприз. И действительно, стоило начать с поиска пакета с дровами в репозитории. Но, как оказалось, в нем код того же модуля и при компиляции он точно так же падает.

    Поиск решения

    Проблема в пакете из репозитория Ubuntu — это уже более серьезная ситуация, и я пошел знакомится с Ubuntu MOTU (Masters of the Universe). На их вики можно найти завлекательные инструкции о том, как помогать содержать пакеты в актуальном состоянии и вообще помогать проекту Ubuntu, что сразу меня заинтересовало. Присоединившись к IRC каналу #ubuntu-motu на freenode.net, начал спрашивать, как я могу помочь починке этого пакета из репозитория. Там мне объяснили, что лучшим вариантом будет решить проблему на этапе до Ubuntu, то есть в репозитории debian, откуда они и берут большинство deb пакетов.

    Debian

    Не зная, к кому и как обратиться, я решил написать сразу сопровождающему (maintainer) этого пакета (как я узнал потом, так советуют не делать). У каждого deb пакета есть поле maintainer (посмотреть можно, например, при помощи less file.deb), откуда я и взял контактный e-mail. Написал, что, мол, установка пакета падает с такими-то ошибками, что версия пакета такая-то и версия моей Ubuntu такая-то и что, как владелец этого оборудования, хотел бы помочь с фиксом. Не прошло и дня, как он ответил. Написал, что, да, проблема есть, и нагуглил ее на launchpad, и о том, как на самом деле стоит сообщать в debian о найденных багах. Предполагает, что дело в исчезновении некоторых define в исходном коде новых ядер. Попросил, чтобы я нашел commit, который убирает эти define, или любую документацию по этому случаю. Внезапная просьба, но я нашел этот коммит.

    Фиксаем

    Сопровождающий пакета переслал мне ориентировочный патч, чтобы я опробовал его на своем железе. Чуть его подправив, отправил обратно сообщение об успехе! Таким образом был составлен патч для модуля сетевой карты, в котором фигурирует мое имя как тестера патча. Для меня это был большой повод для гордости и для продолжения начатой работы :)
    Далее я протестил у себя получившийся deb пакет и maintainer отправил его в репозиторий sid, на чем история этого пакета в debian пока заканчивается.

    Назад в MOTU

    Работоспособность для debian — это здорово, но я — пользователь Ubuntu, и этот пакет мне нужен именно там. Пошел обратно к MOTU с надеждой, что сейчас пакет попадет в их репозиторий. Но такая поспешность была слишком оптимистичной :) Оказывается, существует целый протоколированный процесс под названием SRU о попадании пакета в текущий release и в LTS. Документ казался огромным и непрозрачным для меня, и я начал искать ответственных за SRU людей. Нашел их на канале #ubuntu-release. Они оказались весьма приятными людьми и, после недолгого разговора, решили принять пакет в release, так как он берется непосредственно из sid, хорошо документирован и переводит состояние пакета из «не собирается совсем» в «it works for me». Таким образом, к моменту написания статьи все пользователи сетевой карты RLT8168 и ядра любой актуальной версии смогут установить себе дрова прямо из репозитория.
    О существовании проблемы и патча для нее я несколько раз сообщил разработчикам модуля в RealTek, но, увы, никакой реакции от них не последовало.

    Что дальше?

    Почитав уголок разработчика debian, я увидел отличную документацию, множество осиротевших пакетов и пакетов, требующих оформление в deb. Учитывая, что debian сообщество «находится в постоянном поиске новых разработчиков, обладающих некоторыми техническими знаниями, заинтересованных в свободном программном обеспечении и имеющих некоторое свободное время», я начал изучать создание deb пакетов. И мне кажется, это отличная возможность сделать мир Linux чуточку лучше ;)

    Зачем статья?

    Я надеюсь, что статья поможет увидеть, что помочь любимому дистрибутиву реально даже будучи не супер-пупер программистом. Что сообществу нужна новая кровь и Вы на этом можете получить ценный опыт ;)

    P.S.

    Если на хабре найдется человек, который сможет стать моим наставником (mentor) и в перспективе адвокатом в становлении debian maintainer, я буду очень рад.
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 51
    • +37
      Удачи Вам в таких начинаниях.
      • +24
        Как я понимаю, автор хотел сказать, что все мы знаем про OpenSource, но для многих он как млечный путь — он есть, но где-то далеко нереально к нему прикоснуться. А все на самом деле проще и ближе!

        P.S. Немного напоминает статью про первый секс с Linux =)

        • +3
          Вам повезло. Обычно нужно пройти семь кругов ада для того, чтобы реально нужные изменения попали в репозиторий. Посмотрите хотя бы сколько репов на launchpad с какими-нибудь фиксами. У меня на HTPC материнка с APU AMD E350. Я купил ее сразу после выхода и до сих пор (уже наверное года 2) мне приходится пол-системы (Ubuntu 12.10) устанавливать с launchpad чтобы все работало как надо.
          • +3
            Я помню, как я сражался почти полгода за то, чтобы usb_modeswitch включили в дефолтную поставку sid. Было весело.
            • +1
              Видимо надо чтобы кто-нибудь провел эти пакеты через процедуру Stable Release Updates.
              Может быть Вам попробовать?
              • –4
                Как и многим, мне мешает отсутствие свободного времени и (увы) собственная лень.
                • +6
                  Ну вот видите, автор не поленился и таки нашел нужных людей. Мне кажется тут скорее надо не самому пытаться брать на себя обязательства, а найти человека, который уже имеет обязанности позволяющие добавить пакет хоть и через других людей.
            • +11
              Если на хабре найдется человек, который сможет стать моим наставником (mentor) и в перспективе адвокатом в становлении debian maintainer, я буду очень рад.


              Я сам гентушник, но мне кажется, что сначала Вы должны поставить себе дебиан.

              Вообще самое первое и простое, что может сделать пользователь любого дистрибутива — это не проходить мимо проблем, а сообщать о них разработчикам через багзиллы и иже с ними. Только не в стиле «Ааааа, ни работает, почините!», а так как просят разрабы, обычно это указание версии пакета, где есть проблема, описание проблемы, вывод команды с информацией о системе аля emerge --info.

              Потом, перейдя на новый уровень можно репортить в багзилы конкретных разработчиков.

              Потом собирать пакеты.

              Потом писать патчи.

              Потом собрать дистрибутив.

              Потом полететь в космос.

              PROFIT :-D
              • +3
                Мне кажется этот путь проходят все вменяемые линуксоиды со стажем использования системы более пары лет
                • +6
                  Далеко не все. Я так давно и стабильно застрял на первом пункте.
                • +1
                  Совет постить в багтрекер дистрибутива имеет смысл далеко не для «любого дистрибутива». Это в Debian патчить всё и вся — нормальная практика. А там, например, в ArchLinux, могу сказать по собственному опыту, даже если Вы распишите всё в подробностях и приаттачите suggested patch, Вам в 90% отпишутся, что проблема отностится не к дистрибутиву и предложат написать разработчику. Т.о. лучше не тратить лишнее время, а сразу постить в mainstream. А багтрекер дистрибутива оставить на крайний случай, если mainstream уж совсем отмороженный. Ну или на случаи, когда явный баг мейнтейнера, а не разработчика.
                  • +1
                    Не пользовался Arch Linux, но в «страшной», «красноглазой» генте в худшем случае, не закрывая баг в своей багзилле, попросили бы открыть баг в апстриме, подсказав где именно и ссылку добавить в описание бага в гентушной.

                    Ну и очевидно баг в апстриме скорее будет пофикшен. Правда не всегда удается точно понять что же это блин глючит. И вот тут мейнтейнеры дистра помогают, потом уже приходит свой опыт.
                    • +1
                      Тут еще логика заключается в том, что при фиксе в upstream фикс появится во всех дистрибутивах со временем, а не только в том, в котором заметили.
                      В дистрибутиве принято исправлять только те части пакета, которые специфичны для этого дистрибутива.
                      • +1
                        Вопрос в том, кто этим занимается.
                        • 0
                          Ну логично что, maintainer:
                          1. В случае особенностей дистрибутива, правит пакет.
                          2. В случае ошибки в программе, mainteiner создает issue в upsteam.
                          • 0
                            Во втором случае может как создать сам, так и «отфутболить» туда. Зависит как от общей политики дистра, так и от конкретного человека.
                            • 0
                              Кто отфутболить? Если maintainer, то не совсем, так как на его имя в системе bug трекинга дистрибутива вешается баг и он должен что-то предпринять. Иначе можно ставить вопрос о смене мейнтейнера пакета.
                              • 0
                                Поставит стаус «баг апстрима» или типа того.
                • +1
                  Идите в мир Archlinux'а — там комьюнити заметно демократичнее (на моём опыте, в багтрекере быстро отвечают, предложенные патчи быстро попадают в test-репозитории), плюс свои пакеты можно самостоятельно заливать на AUR, чтобы после проверки быть доступным всем пользователям. Из-за этого на моём опыте подобные проблемы с неочевидными зависимостями от ядра решаются гораздо раньше.
                  • +3
                    «Идите в мир CentOS — там вы вряд ли дождетесь патча, но зато всё, что работает — работает правильно».
                    Шутка, конечно.
                    На самом деле в какой мир идти — зависит от того, какое соотношение «свежесть/стабильность» вам нужно.
                    • +1
                      Далеко не только от этого зависит. Дистрибутивы не только по параметру свежесть/стабильность отличаются.
                      • +1
                        Различаются они кучей параметров.
                        Но когда приходит час Ч (выбрать себе mainstream дистрибутив для ...) — то приходится решать именно эту задачу — надежность vs свежесть.
                        Со всем, что из этих вещей проистекает. И от чего они зависят.
                        • +1
                          Параметром вполне может быть поддерживаемые DE. Какой дистр нормально поддерживает Unity?
                          • +1
                            В одном случае параметром может быть даже пакета какой-то специфичной софтины или редкостной железки.
                            Я говорю о своем mainstream — т.е. то, что будешь не раз ставить живым людям, изучать это, знать это.

                            Насчет Unity ничего сказать не могу — не пользуюсь. Даже не видел никогда.
                            • +1
                              Я как бы придерживаюсь «тактики» ставить людям то, что сам активно использую. А если они просят поставить что-то другое, то предупреждаешь, что помочь им если что оперативно не сможешь. А лично для меня нормальная поддержка Unity в дистре — определяющий фактор для личного повседневного использования в работе и для развлечений.
                              • +2
                                Я об том же — ставить надо то, что себе.
                                Другой вопрос — себе-то что ставить :-)

                                Но это уже каждый решается для себя сам.
                                Убедили — параметры выбора — субъективны.
                                Для меня это — надежность vs свежесть.
                                Для Вас — Unity или не Unity.
                                • +1
                                  Вообще говоря даже надёжность и свежесть субъективны. В смысле за 3 года использования Арча на нескольких компьютерах (небольшой сервер, ноут — для всего включая медиа, жирная рабочая станция) с проблемами от ненадёжности софта из-за свежести (вида недостаточно протестировано) так и не встретился. Тогда как проблем вида «эта фигня не поддерживается в ядре/в несвежем модуле видеокарты» — довольно много.
                                  • +1
                                    И снова в точку.
                                    (а на хабре нельзя писать иного — заминусуют, и тогда уже вообще ничего не напишешь :-).
                                    Мы не будем разводить флейм «этот Linux vs другой Linux». Или «кеды против гнома».
                                    Вы правы в том, что понятие «надежность» и «свежесть» — тоже субъективны.
                                    Я — когда выбирал, куда сползти с одного широко известстного в узких кругах отечественного дистрибутива — действительно нарисовал себе планчик-конспектик — требования, их критичность лично для меня (точнее — для моих доходов), куда это можно запихнуть, куда — не можно, поддержка и т.д.

                                    Поэтому каждый выбирает свои дистрибутивы исходя из… ну да — своих личных побуждений ;-)
                                  • +1
                                    Убедили — параметры выбора — субъективны.


                                    Плюсую к этому. Я выбрал генту даже не за свежесть входящих в нее пакетов. stable ветка по некоторым пакетам отстает от Федоры или ОпенСуси. Я выбирал по гибкости и похожести на привычную мне слакварю и фрибзд.
                                    • +1
                                      А вот и еще один критерий — степень автоматизации.
                                      Судя по всему — Вам комфортнее в системах «ручной работы» (BSD/Slak/source-based).
                                      Мне комфортнее в «полу-автоматах» (хотя степень «атоматизации» определить довольно сложно).
                                      А кому-то больше нравится максимальная автоматизация (и здесь уже меняют ОС).
                    • +2
                      Написать бы, как это всё происходит в Fedora (и/или вообще в rpm-based) — но и так минусов дочерта…
                      Хотя в общем и целом — примерно так же.
                      Не без своих приколов, ессно.
                      • +2
                        Пробовал пройти подобный путь, чтобы решить проблемы драйверов тюнера (входит в список официально поддерживаемых, но моя ревизия отказывалась работать), связывался с разработчиками, разбирал тюнер (включая ВЧ-модуль), чтобы определить чипы, методом научного тыка подставлял параметры от других схожих по начинке тюнеров, добился что tvtime нормально показывает картинку, но не может включить звук. Когда речь дошла до того, что снифать usb-трафик под виндой и линуксом, а потом их сравнивать, то я сдался и купил другой тюнер :(
                        • +1
                          > методом научного тыка подставлял параметры от других схожих по начинке тюнеров

                          А можно чуть подробнее?
                          • +4
                            Есть Си-структуры описывающие тот или иной тюнер, в частности через константы, описывающие его железную начинку (названия чипов грубо говоря), плюс какие-то константы (когда с мнемоническими именами через #DEFINE, когда захардкоженные) определяющие, видимо, параметры инициализации. Тюнера с точно таким набором чипов не нашел и стал подставлять константы (и типа чипов, и параметров) от разных, сначала точно такие, потом других версий, потом уже позже вообще грубый брутфорс по всем. Вставишь, скомпилируешь, выгрузишь старую версию модуля, загрузишь новую (иногда приходилось перезагружать ось) и так много-много раз, пока не надоест. Самое обидное, что понимал что буквально несколько байт не хватает, который драйвер не шлет тюнеру (скорее всего шлёт, но немного не те), потому что если включить тюнер в винде, потом выключить комп (из розетки или выключателем сзади БП, чтобы не послал reset тюнеру), включить и загрузиться в лине, то всё работает идеально, звуком можно управлять, он переключается вместе с ТВ каналами и т. п.
                          • +2
                            Я уж молчу про GDI-принтеры :-)
                            • +2
                              Мне кажется почти каждый занимался секасом с линуксом из-за какой нить железяки. Я вот мучался с тач экраном на старом ноуте.
                              • –4
                                но зачем?

                                Windows + VirtualBox + Debian.

                          • –16
                            попробуйте Windows 8
                            • +8
                              Попробуйте меньше кушать.
                              • +5
                                На новом рабочем ноуте стояла восьмёрка, как-то до этого я, как линуксоид, с ней особо дела не имел — решил посмотреть, прежде чем сносить. Поигрался в неё 5 минут, после этого в момент уничтожения инсталлятором убунты таблицы разделов ощущения были, как будто уделал вампира осиновым колом.
                              • +2
                                Недавно помог разработчикам apache httpd найти и исправить баг PR#53963, добавленный исправлением другого бага в версии 2.2.23, за день до выхода релиза 2.2.24 :) Мелочь (ломавшая, кстати, rewritebase у mod_rewrite в субдиректориях), а приятно.
                                • +3
                                  Побольше бы таких success story, желательно даже от менее крупных проектов (всё-такие контрибьютить Linux довольно непростая задача). Больше бы новичков подтягивалось, например, если рассказывали о каком-то проекте о том, что интересного для него надо/можно сделать и к кому обратиться (менторы и т.д.) — хотя я конечно понимаю, что искать это всё должен в первую очередь разработчик (как в Вашем примере).
                                  • –10
                                    Я блин такие дущещипательные хистори и на винде раз в неделю испытываю на работе (я уж молчу про многие кряки для игр. они ставятся людьми с инструкциями на 8 страницах.). К чему статья то? Заработать побольше лайков и плюсиков??? Афтор считает что его трогательное рукоблудие соподвигнет геймеров кинуться ставить убунту??? Объясните мне смысл статьи пж.

                                    Может написать статью про солярку и секс с ней? Многие кинуться на нее перейти???? Линуксоиды были всегда по ущербны. У них комплекс неполноценности. Типо нас так мало и нужно тянуть в это болото еще людей, ибо будет не так мало и не таким ущербным ся будешь чувствовать. Есть конечно люди которые выбрали ее и идут с ней по жизни. а вот все остальное племя из разряда баранов. Для фона так сказать.
                                    • +5
                                      Вы коммитите в Windows каждую неделю?
                                      • 0
                                        Краткое содержание вашего комментария: «Ко-ко-ко-ко-ко!»
                                        — Смысл статьи вполне очевиден из заголовка.
                                        — Причём тут геймеры, не понял.
                                        — К чему ваши брызги слюной насчёт заманивания в «болото»? Статья написана линуксоидом для линуксоидов.

                                        Вообще, если ваша цель — не навалить кучу посреди комментов, а добиться того, чтобы к вам прислушались, перво-наперво перестаньте использовать лишние вопросительные знаки. Это выглядит безграмотно и излишне эмоционально (почти на уровне психоза).
                                      • 0
                                        Кстати после прочтения зашёл на сайт debian(ведь его я собираюсь в течении 2х недель поставить)
                                        Действительно, там много пакетов требующих работы:
                                        Ссылка
                                        • 0
                                          В этом посте очень не хватает ссылки на русскую версию руководства разработчика Ubuntu, где подробно описаны как процессы как собственно сборки пакетов, так и работы с инфраструктурой и взаимодействия в сообществе.
                                          • 0
                                            Кстати, если что-то непонятно, то не стесняйтесь писать на (мой хабраник)@(ubuntu.com).
                                          • 0
                                            Вам ещё много предстоит узнать, например о том, что есть пакеты, а есть ядро, и что драйвера могут быть и там и сям. Если действительно хотели помочь, и сразу всем пользователям ядра Linux, а не одной конкретной ветки дистрибутивов, нужно было посылать свой патч вот в этот код вот сюда.
                                            • 0
                                              Я понимаю что есть пакеты и что есть ядро :) Не первые года за Linux :)
                                              Ядро наоборот осознано выпилило эти define.
                                              Что помочь всем дистрибутивам, я отправлял патч авторам модуля в RealTek, в пакете используется именно их код. Но они не ответили.
                                            • 0
                                              Можно просто денег дать. Баксов 50 или 100 или даже 1000 — никто не откажется. А время потратить на основную работу или свои проекты. Денег вам это больше принесет.

                                              Сам спонсировал FreeType и еще несколько проектов. Со следующей ЗП скину LibJPEG-Turbo.

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                              Самое читаемое