abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 12:33 | Komunita

Příspěvek na blogu Signalu (Wikipedie) informuje o založení neziskové nadace Signal Foundation, jež bude zastřešovat další vývoj tohoto svobodného bezpečného komunikátoru běžícího také na Linuxu (Signal Desktop). Brian Acton, spoluzakladatel WhatsAppu, věnoval nadaci 50 milionů dolarů [Hacker News].

Ladislav Hagara | Komentářů: 0
dnes 05:55 | Zajímavý článek

Článek na Fedora Magazine krátce představuje programovací jazyk Rust a několik zajímavých v Rustu naprogramovaných terminálových aplikací. Jedná se o alternativu k příkazu grep ripgrep, moderní barevnou alternativu k příkazu ls exa, příkazem cloc inspirovaný tokei a zvířátko v terminálu ternimal.

Ladislav Hagara | Komentářů: 0
včera 23:55 | Zajímavý projekt

Byl spuštěn Humble Classics Return Bundle. Za vlastní cenu lze koupit hry Broken Sword 5 - The Serpent's Curse, Shadowrun Returns a Shadowrun: Dragonfall - Director's Cut. Při nadprůměrné platbě (aktuálně 8,48 $) také Shadowrun: Hong Kong - Extended Edition, Wasteland 2: Director's Cut - Standard Edition, Age of Wonders III a Xenonauts. Při platbě 15 $ a více lze získat navíc Torment: Tides of Numenera a Dreamfall Chapters: The Final Cut Edition.

Ladislav Hagara | Komentářů: 0
včera 00:11 | Bezpečnostní upozornění

Vývojáři linuxové distribuce Mageia na svém blogu upozorňují na narušení bezpečnosti Mageia Identity. Narušitel získal přístup k LDAP databázi a zveřejnil jména uživatelů, jejich emailové adresy a haše hesel. Hesla uživatelů byla resetována.

Ladislav Hagara | Komentářů: 3
20.2. 21:55 | Nová verze

Byla vydána verze 2.0.0 nástroje pro záznam a sdílení terminálových sezení asciinema (GitHub). Z novinek je nutno upozornit na nový zpětně nekompatibilní formát záznamu asciicast v2. S novým formátem si poradí nové verze asciinema-playeru a asciinema-serveru [Hacker News].

Ladislav Hagara | Komentářů: 0
20.2. 05:55 | Zajímavý projekt

Dle příspěvku na blogu zaměstnanců CZ.NIC byl spuštěn ostrý provoz služby Honeypot as a Service (HaaS). Zapojit se může kdokoli. Stačí se zaregistrovat a nainstalovat HaaS proxy, která začne příchozí komunikaci z portu 22 (běžně používaného pro SSH) přeposílat na server HaaS, kde honeypot Cowrie (GitHub) simuluje zařízení a zaznamenává provedené příkazy. Získat lze tak zajímavé informace o provedených útocích. K dispozici jsou globální statistiky.

Ladislav Hagara | Komentářů: 12
20.2. 04:44 | Komunita

Před týdnem společnost Feral Interactive zabývající se vydáváním počítačových her pro operační systémy macOS a Linux oznámila, že pro macOS a Linux vydají hru Rise of the Tomb Raider. Včera společnost oznámila (YouTube), že pro macOS a Linux vydají také hru Total War Saga: Thrones of Britannia. Verze pro Windows by měla vyjít 19. dubna. Verze pro macOS a Linux krátce na to.

Ladislav Hagara | Komentářů: 0
19.2. 21:33 | Nová verze

Byla vydána nová major verze 7.10 svobodného systému pro řízení vztahů se zákazníky (CRM) s názvem SuiteCRM (Wikipedie). Jedná se o fork systému SugarCRM (Wikipedie). Zdrojové kódy SuiteCRM jsou k dispozici na GitHubu pod licencí AGPL.

Ladislav Hagara | Komentářů: 0
19.2. 16:44 | Nová verze

Byla vydána nová verze 0.30 display serveru Mir (Wikipedie) a nová verze 2.31 nástrojů snapd pro práci s balíčky ve formátu snap (Wikipedie). Z novinek Miru vývojáři zdůrazňují vylepšenou podporu Waylandu nebo možnost sestavení a spouštění Miru ve Fedoře. Nová verze snapd umí Mir spouštět jako snap.

Ladislav Hagara | Komentářů: 0
19.2. 14:00 | Komunita

Na Indiegogo běží kampaň na podporu Sway Hackathonu, tj. pracovního setkání klíčových vývojářů s i3 kompatibilního dlaždicového (tiling) správce oken pro Wayland Sway. Cílová částka 1 500 dolarů byla vybrána již za 9 hodin. Nový cíl 2 000 dolarů byl dosažen záhy. Vývojáři přemýšlejí nad dalšími cíli.

Ladislav Hagara | Komentářů: 1
Který webový vyhledávač používáte nejčastěji?
 (2%)
 (28%)
 (61%)
 (3%)
 (3%)
 (0%)
 (1%)
 (1%)
Celkem 426 hlasů
 Komentářů: 35, poslední včera 19:51
    Rozcestník

    openSUSE buildservice - 4 (spolupráce s upstreamem)

    7. 11. 2008 | Marek Stopka | Návody | 2397×

    openSUSE buildservice obsahuje mnoho projektů, které obsahují obrovské množství balíčků. Občas se stane, že objevíte v nějakém balíčku chybu a nemůžete si dovolit čekat, než ji opraví správce projektu. Z toho důvodu se rozhodnete bastlit patch vlastními silami.

    Pokud je patch dostatečně kvalitní, tak jistě chcete v duchu svobodného softwaru ušetřit práci balíčkáři, který za balíček zodpovídá. Jistě, můžete tento patch poslat maintainerovi e-mailem, ale proč to dělat, když má buildservice takovou skvělou funkci, které říká Build Service Collaboration?

    Princip spolupráce je poměrně prostý, nejdříve si ve svém domácím namespace home:nick (např. home:m4r3k) vytvoříte branch nadřazeného projektu, ve kterém chcete něco změnit. Pak provedete požadované úpravy a pomocí příkazu osc submitreq provedete odeslání požadavku na začlenění vašich změn. Správci patřičného balíčku v nadřazeném projektu přijde e-mail, ve kterém bude o události informován, a jakmile si najde chvilku, tak provede kontrolu (code-review) a v případě, že nenajde problém, tak vaše úpravy začlení. Pokud problém nalezne, není nic snažšího, než vaše úpravy spolu s komentářem, co musíte ještě opravit/pozměnit, zamítnout.

    Poněkud komplikovanější to je, pokud chcete přispívat do projektu openSUSE:Factory. Struktura je následující: Balíčky, které spravuje maintainer A ve Factory, má maintainter také ve svém home:A:Factory (jeden příklad za všechny, Anička, která má pod palcem balíčky jako perlovské moduly, eject nebo openssh, má svůj vývojový strom k testování v projektu s názvem home:anicka:Factory). A to je právě ten repositář, který byste měli branchovat, pokud chcete přispět patchem do některého z balíků ve Factory. Proč to tak je, se dá snadno odpovědět: Aby mohl správce balíček dostatečně otestovat a do distribuce se tak nezavleklo více zbytečných problémů. Jakmile správce uzná, že je balíček dostatečně otestován, provede také osc submitreq. Až bude správcem projektu openSUSE:Factory tento požadavek přijat, tak se změna promítne do openSUSE Factory stromu. Více o struktuře vývoje openSUSE Factory prostřednictvím Collaboration je vidět na těchto slidech.

    Praktický příklad

    Řekněme, že mám projekt home:m4r3k:R-project a vy mi chcete poslat takový malý, hezký patch na balíček R-base (ten projekt opravdu mám a každý patch je opravdu vítán :-)). Nejdříve pomocí příkazu

    marek@mantisha:~/Files/prace/buildservice> osc branch home:m4r3k:R-project R-base
    A working copy of the branched package can be checked out with:
    
    osc co home:m4r3k:branches:home:m4r3k:R-project/R-base
    marek@mantisha:~/Files/prace/buildservice>
    

    provedete vytvoření virtuální kopie projektu home:m4r3k:R-project ve vašem jmeném prostoru home:nick:branches. Vznikne tak projekt home:nick:branches:home:m4r3k:R-project (např. home:m4r3k:branches:home:m4r3k:R-project) , který má jako sestavovací cíl nastaven projekt home:m4r3k:R-project/openSUSE_11.0, což znamená, že se budou primárně používat balíčky z repositáře home:m4r3k:R-project/openSUSE_11.0 a až poté z jiných repositářů (jako třeba openSUSE_11.0). Nyní si checkoutněte projekt home:nick:branches:home:m4r3k:R-project/R-base příkazem

    marek@mantisha:~/Files/prace/buildservice> osc co home:m4r3k:branches:home:m4r3k:R-project/R-base
    A    home:m4r3k:branches:home:m4r3k:R-project
    A    home:m4r3k:branches:home:m4r3k:R-project/R-base
    A    home:m4r3k:branches:home:m4r3k:R-project/R-base/R-2.7.1.tar.lzma
    A    home:m4r3k:branches:home:m4r3k:R-project/R-base/R-base.spec
    marek@mantisha:~/Files/prace/buildservice>
    

    Když se podíváte na to, co osc stahoval, a pak se podíváte třeba pomocí webového rozhraní do skutečného obsahu nově vytvořené kopie, tak zjistíte, že osc stáhl skutečné soubory ze serveru, kdežto ve vytvořené kopii je jen soubor _link, který již jistě důvěrně znáte z druhého dílu seriálu. Pokud jste četli i třetí díl tohoto seriálu, pak jistě vítě, že soubor _link může obsahovat i různé patche, a to je v podstatě způsob, jak funkce Collaboration funguje. Vždycky, když v branchnutém balíčku něco změníte a provedete osc commit, tak se vygeneruje diff, který se na serveru uloží, a poté se balíček zkusí sestavit i s provedenými změnami.

    Zde bych si dovolil apelovat na každého uživatele OBS: Vyzkoušejte prosím nejdříve baliček lokálně pomocí

    osc build cílová-distribuce cílová-architektura nějaký.spec

    a až poté provádějte commit - šetříte tím cenný strojový čas buildovacích serverů.

    Pokud máte zdrojové kódy úspěšně stažené, tak se můžete přesunout do adresáře, kam jste si je stáhli, a provést libovolné úpravy. Přidávat a odebírat soubory, upravovat jednotlivé soubory, ... jakmile své úpravy provedete a patřičně otestujete jak lokálně, tak na buildserveru, není nic snazšího, než je poslat správci nadřazeného projektu kontrole. Napište příkaz

    osc submitreq create -m "Nějaká zpráva, nejlépe anglicky"

    a systém automaticky vygeneruje zprávu pro správce cílového projektu a pošle mu e-mail, aby o vašem požadavku věděl.

    Případně můžete vytvořit požadavek i bez toho, abyste měli stažený obsah repositáře. Provedete to pomocí příkazu

    osc submitreq create home:nick:branches:home:m4r3k:R-project R-base home:m4r3k:R.project -m "nějaká zpráva, nejlépe anglicky"

    Pohled z druhé strany barikády

    Nyní už víte, jak takový "submit request" vytvořit - možná by vás však také zajímalo, co všechno musí udělat správce nadřazeného projektu, aby váš požadavek přijal, nebo zamítl. Opět se nejedná o nic složitého. Když se správce podívá na svou stránku My Projects, tak tam mimo jiné najde část Requests concerning me. Obsahuje všechny submit requesty, u nichž má právo rozhodnout o začlenění, nebo odmítnutí. Každý takový požadavek má své vlastní ID. Prostřednictvím tohoto ID může správce s požadavkem dále pracovat. Například příkazem osc submitreq show -d ID si může maintainer zobrazit, co všechno pozměnil ten, kdo zaslal požadavek. O koho se jedná (tedy zdrojový projekt požadavku), cílový projekt požadavku a zprávu, která byla k požadavku přiložena pomocí parametru -m. Dále se správci zobrazí diff mezi původní verzí balíčku a větví, z níž požadavek přichází. Správce tak má k dispozici všechny důležité informace k tomu, aby mohl o požadavku rozhodnout - zda má skončit v jeho opečovávaném projektu, nebo raději v /dev/null.

    Svůj názor na balíček může správce vyjádřit pomocí dvou příkazů - buď příkazem

    osc submitreq accept ID

    pro přijetí, nebo příkazem

    osc submitreq decline -m "jistě je slušné říci, proč požadavek zamítáme, nemyslíte?" ID

    poslat požadavek do /dev/null.

    Na již zmiňované stránce My Projects vidíte také seznam všech submit requestů, které jste sami vytvořili a které dosud nebyly obslouženy správcem. Nacházejí se v části s nadpisem Requests by me.

    Nejčtenější články posledního měsíce

    Jaderné noviny – 18. 1. 2018: Přehled několika svobodných fuzzovacích nástrojů
    MapTiler – proměňte obrázek v zoomovatelnou mapu
    Jaderné noviny – 11. 1. 2018: Nové jaderné rozhraní pro dotazování

    Nejkomentovanější články posledního měsíce

    MapTiler – proměňte obrázek v zoomovatelnou mapu
    Jaderné noviny – 25. 1. 2018: Datová struktura XArray
    Týden na ScienceMag.cz: Kvantová komunikace bez přenosu částic
      všechny statistiky »

    Seriál openSUSE Build Service (dílů: 5)

    openSUSE Build Service (OBS) aneb jak ho sbalit (první díl)
    <—« OBS - 3 (backportujeme kernel a další balíčky)
    »—> Lokální Buildservice (OBS) – sestavujte vlastní balíčky
    Lokální Buildservice (OBS) – sestavujte vlastní balíčky (poslední díl)

    Související články

    Na co se často ptáme: Balíčkovací systémy
    Seriál: Instalace softwaru v Linuxu
    Seriál: Gentoo ebuild
    Seriál: Rukověť baliče RPM
    Seriál: Balíčky pro Debian
    Seriál: Balíčkovací systém Arch Linuxu
    Smart Package Manager - instalujeme chytře
    Zdroje balíčkov pre Ubuntu
    Balíčkovací systém Mandrake Linuxu
    Balíčkovací systém Gentoo Linuxu
    openSUSE 11.0

    Odkazy a zdroje

    Build Service
    build.opensuse.org

    Další články z této rubriky

    MapTiler – proměňte obrázek v zoomovatelnou mapu
    Syncthing
    Twibright Registrator: Instalace, odinstalace, test, základní použití
    Twibright Registrator: fotografie v šeru bez stativu 2
    Twibright Registrator: fotografie v šeru bez stativu 1
           

    Hodnocení: 67 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    7.11.2008 06:55 Zdenek
    Rozbalit Rozbalit vše Re: openSUSE buildservice - 4 (spolupráce s upstreamem)
    A kde je ta spoluprace s upstreamem? Jak vidim porad je to na pisecku openSUSE buildservice. Autori prislusneho software (tj. upstream) z toho nemaji vubec nic.
    belisarivs avatar 7.11.2008 09:15 belisarivs | skóre: 22 | blog: Psychobláboly
    Rozbalit Rozbalit vše Re: openSUSE buildservice - 4 (spolupráce s upstreamem)
    No asi takhle.

    Pro maintainera baliku openSUSE je lepsi poslat opravu upstreamu. Ulehci si praci, protoze pak nemusi svuj patch priohybat na novou verzi programu.

    Ja jsem v SUSE vyzyvan nadrizenym at patche do upstreamu posilam. A taky to delam. A nemyslim si, ze bych byl vyjimka.
    IRC is just multiplayer notepad.
    7.11.2008 09:29 Zdenek
    Rozbalit Rozbalit vše Re: openSUSE buildservice - 4 (spolupráce s upstreamem)
    Ja to chapu (jsem upstream :), ale clanek ma v nazvu "spolupráce s upstreamem" a pritom v nem nic takoveho neni.
    Rezza avatar 7.11.2008 14:49 Rezza | skóre: 25 | blog: rezza | Brno
    Rozbalit Rozbalit vše Re: openSUSE buildservice - 4 (spolupráce s upstreamem)
    Mozna je tu myslen upstream jako originalni balicek...
    Marek Stopka avatar 7.11.2008 14:51 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: openSUSE buildservice - 4 (spolupráce s upstreamem)
    To jasně, je to takový dvojsmysl. Běžně to tak na IRCčku označujeme a tak mi to nějak nedošlo.
    7.11.2008 14:55 Zdenek
    Rozbalit Rozbalit vše Re: openSUSE buildservice - 4 (spolupráce s upstreamem)
    A jak oznacujete upstream? :-)
    Ilfirin avatar 7.11.2008 07:07 Ilfirin | skóre: 32 | blog: ilfblog | Liberec
    Rozbalit Rozbalit vše Re: openSUSE buildservice - 4 (spolupráce s upstreamem)
    Skvělý článek (a ještě lepší seriál). Díky.

    Jen malinký dotaz. Plánuješ ještě nějaké díly?
    Marek Stopka avatar 7.11.2008 11:23 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: openSUSE buildservice - 4 (spolupráce s upstreamem)
    Když mi řekneš co by si se v dalším díle chtěl dozvědět, tak jej můžu napsat. :-)
    8.11.2008 20:01 Marex
    Rozbalit Rozbalit vše Re: openSUSE buildservice - 4 (spolupráce s upstreamem)
    0verkill ... kosti, maso, ... :-E~~~

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.