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í
×

včera 12:55 | Nová verze

Byla vydána verze 17.12.0 KDE Aplikací (KDE Applications). Přehled novinek v kompletním seznamu změn a na stránce s dalšími informacemi. Aplikace, které nebyly dosud portovány na KDE Frameworks 5, byly z KDE Aplikací odstraněny.

Ladislav Hagara | Komentářů: 20
včera 03:00 | Komunita

Na Humble Bundle lze získat počítačovou hru Company of Heroes 2 (Wikipedie, YouTube) běžící také v Linuxu zdarma. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 0
včera 02:00 | Zajímavý software

Christian Kellner představil na svém blogu projekt Bolt řešící bezpečnost rozhraní Thunderbolt 3 na Linuxu. Pomocí příkazu boltctl nebo rozšíření GNOME Shellu lze komunikovat s démonem boltd a například zakázat neznámá zařízení a předejít tak útokům typu Thunderstrike nebo DMA.

Ladislav Hagara | Komentářů: 6
včera 01:00 | Nová verze

Po půl roce vývoje od vydání verze 11.0 byla vydána verze 11.1 svobodného softwaru pro vytváření datových úložišť na síti FreeNAS (Wikipedie). Nejnovější FreeNAS je postaven na FreeBSD 11.1. Přehled novinek v příspěvku na blogu. Zdůraznit lze zvýšení výkonu OpenZFS, počáteční podporu Dockeru nebo synchronizaci s cloudovými službami Amazon S3 (Simple Storage Services), Backblaze B2 Cloud, Google Cloud a Microsoft Azure

Ladislav Hagara | Komentářů: 0
14.12. 23:55 | Nová verze

Po dvou měsících vývoje od vydání verze 235 oznámil Lennart Poettering vydání verze 236 správce systému a služeb systemd (GitHub, NEWS).

Ladislav Hagara | Komentářů: 6
14.12. 20:00 | Nová verze Ladislav Hagara | Komentářů: 0
14.12. 19:33 | Pozvánky

Pražská Fedora 27 Release Party, oslava nedávného vydání Fedory 27, se uskuteční 19. prosince od 19:00 v prostorách společnosti Etnetera (Jankovcova 1037/49). Na programu budou přednášky o novinkách, diskuse, neřízený networking atd.

Ladislav Hagara | Komentářů: 0
14.12. 18:11 | Nová verze

Byla vydána verze 2.11.0 QEMU (Wikipedie). Přispělo 165 vývojářů. Provedeno bylo více než 2 000 commitů. Přehled úprav a nových vlastností v seznamu změn.

Ladislav Hagara | Komentářů: 0
14.12. 17:44 | Komunita

Canonical oznámil dostupnost kryptografických balíčků s certifikací FIPS 140-2 úrovně 1 pro Ubuntu 16.04 LTS pro předplatitele podpory Ubuntu Advantage Advanced. Certifikace FIPS (Federal Information Processing Standards) jsou vyžadovány (nejenom) vládními institucemi USA.

Ladislav Hagara | Komentářů: 3
14.12. 16:11 | Zajímavý software

Společnost Avast uvolnila zdrojové kódy svého dekompilátoru RetDec (Retargetable Decompiler) založeného na LLVM. Vyzkoušet lze RetDec jako webovou službu nebo plugin pro interaktivní disassembler IDA. Zdrojové kódy RetDec jsou k dispozici na GitHubu pod open source licencí MIT.

Ladislav Hagara | Komentářů: 3
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (76%)
 (14%)
Celkem 997 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    OBS - 3 (backportujeme kernel a další balíčky)

    2. 7. 2008 | Marek Stopka | Návody | 2245×

    Pokud chcete dostat do své verze distribuce novější jádro, které ještě není v repozitáři, bude se vám hodit umět s pomocí openSUSE Build Service backportovat. Kromě toho se naučíte obyčejné patchování balíčků.

    openSUSE (a pokud vím i všechny ostatní RPM-based distribuce) fungují na principu stabilních vydání, a ne na principu rolling-updates, jako je tomu třeba v případě Gentoo. Proto, když chcete novou verzi nějakého programu (třeba jádra), tak musíte buď přejít na aktuální vývojovou verzi (např. openSUSE Factory), nebo si patřičný balíček backportovat. (Je zde ještě možnost si program zkompilovat mimo balíčkovací systém, ale to je spíš cesta do pekel než elegantní řešení problému.)

    S buildservicem však není nic snažšího, než si takový balíček (třeba jádro jako v našem případě) backportovat. Můžete provádět rozličné backportování. Můžete si do svého openSUSE 10.3 naládovat jádro z openSUSE 11.0 nebo přímo z openSUSE Factory. Například jsem pořeboval na desktop HP dc5800 dát novější jádro, aby mi správně fungovalo ACPI. S buildservicem stačilo vytvořit nový projekt home:m4r3k:kernel-backport (je zbytečné si zaneřádit domácí projekt, když je tu ta skvělá možnost vytvářet podprojekty) pomocí příkazu:

    osc meta prj -e home:m4r3k:kernel-backport

    V nabídnutém XML souboru:

    <project name="home:m4r3k:kernel-backport">
    	 <title>Short title of NewProject</title>
      <description>This project aims at providing some foo and bar.
    It also does some weird stuff.
    </description>
      <person role="maintainer" userid="m4r3k" />
      <person role="bugowner" userid="m4r3k" />
    <!– remove this block to publish your packages on the mirrors –>
      <publish>
        <disable />
      </publish>
      <build>
        <enable />
      </build>
      <debuginfo>
        <disable />
      </debuginfo>
    <!– remove this comment to enable one or more build targets
      <repository name="openSUSE_Factory">
        <path project="openSUSE:Factory" repository="standard" />
        <arch>x86_64</arch>
        <arch>i586</arch>
      </repository>
     <repository name="openSUSE_10.2">
        <path project="openSUSE:10.2" repository="standard"/>
        <arch>x86_64</arch>
        <arch>i586</arch>
      </repository>
      <repository name="SUSE_Linux_10.1">
        <path project="SUSE:SL-10.1" repository="standard" />
        <arch>x86_64</arch>
        <arch>i586</arch>
      </repository>
      <repository name="SUSE_Linux_10.0">
        <path project="SUSE:SL-10.0" repository="standard" />
        <arch>x86_64</arch>
        <arch>i586</arch>
      </repository>
      <repository name="Fedora_7">
        <path project="Fedora:7" repository="standard" />
        <arch>x86_64</arch>
        <arch>i586</arch>
      </repository>
      <repository name="SLE_10">
        <path project="SUSE:SLE-10:SDK" repository="standard" />
        <arch>x86_64</arch>
        <arch>i586</arch>
      </repository>
    –>
    </project>

    Pak pozměníme část <publish> z <disable /> na <enable />, čímž zajistíme vytvoření veřejně přístupného repozitáře, a dále si vybereme architektury a distribuce, pro které chceme balíčky sestavovat. Pokud je naše cílová platforma v zakomentované části XML souboru, tak máme vyhráno a tu část, kterou chceme, odkomentujeme. Ke komentářům se zde používají klasické XML komentářové znaky <!– a –>. V případě, že naše cílová platforma v nabídce není, tak ji prostě přidáme (nezakomentovanou). Můžeme ji přidat jak prostřednictvím editace XML souboru, tak prostřednictvím webového rozhraní, jak jsme si to popsali v druhém dílu seriálu. Nezapomeňte také vyplnit položky <title> a <description> něčím více popisným :-).

    Nyní, když máme projekt vytvořen, je vhodné si stáhnout jeho obsah (stejně je zatím skoro prázdný) na lokální disk. To uděláme opět pomocí příkazu osc co home:m4r3k:kernel-backport. Následně pomocí příkazu osc linkpac nalinkujeme balíčky ze zdrojového projektu do projektu cílového (tím je v našem případě home:m4r3k:kernel-backport. V případě backportování kernelu stačí spustit následující bash skript.

    for i in apparmor-parser device-mapper kernel-default kernel-source kernel-xen lvm2 openais udev apparmor-profiles kernel-debug kernel-docs kernel-syms linux-kernel-headers mkinitrd sysfsutils; do
    	osc linkpac openSUSE:Factory $i home:m4r3k:kernel-backport
    done
    

    Po doběhnutí tohoto krátkého skriptíku a vybuildění balíčků bude k dispozici FTP adresář home:m4r3k:kernel-backport, v němž jsou jednotlivé repozitáře, pro které jste si nechali backportovaný balíček sestavit. Zde bych si dovolil požádat přítomné čtenáře, aby si v případě potřeby nevytvářeli vlastní backport openSUSE jádra pro distribuce openSUSE 10.2, 10.3 a 11.0 z openSUSE Factory, protože tento backport je v mém projektu home:m4r3k:kernel-backport a jednalo by se tak o zbytečné plýtvání prostředky buildservicu. Ale pokud máte zájem o backport nějakého jiného balíčku, tak neváhejte :-).

    Balíčky si do systému můžete nainstalovat například touto posloupností příkazů (otestováno na openSUSE 10.3):

    zypper ar --repo http://download.opensuse.org/repositories/home:/m4r3k:/kernel-backport/openSUSE_10.3/home:m4r3k:kernel-backport.repo
    zypper up -t package
    

    kterou si přizpůsobíte vlastním podmínkám. Například změna URL k *.repo souboru.

    Patchuji, patchuješ, patchujeme

    Pokud jste nahlásili bug a broukobijci vás zásobují patchi k otestování nebo si chcete do nějakého balíčku přidat patch, který doplňuje pro vás zajímavou funkci, a nebo si jen chcete balíček přeložit s trošku jinými volbami, buildservice má pro vás jednoduché a elegantní řešení. Opět se jedná o magii spojenou s příkazem osc linkpac jako v předchozím případě.

    Pokud chcete přidat do balíčku nějaký patch, lze to provést pomocí editace souboru _link, který je v adresáři nalinkovaného balíčku po stažení pomocí příkazu osc co. _link soubor obsahuje něco podobného tomuto:

    <link project="openSUSE:Factory" package="apparmor-parser">
    <patches>
      <!– <apply name="patch" /> –>
      <!– <topadd>%define build_with_feature_x 1</topadd> –>
    </patches>
    </link>

    Jak vidíte, soubor obsahuje zakomentované části <apply name="patch" /> a <topadd>%define build_with_feature_x 1</topadd>. Neobsahuje však jednu stejně důležitou část <add name="somepatch" after="3" popt="1" dir=""/>. Tento element add umožňuje přidat k nalinkovanému balíčku libovolný patch. Například pokud chceme vytvořit balíček opatchovaný patchem cool-feature.patch pomocí makra %patch -p2 tak upravíme _link do následující podoby:

    <link project="openSUSE:Factory" package="apparmor-parser">
    <patches>
      <add name="cool-feature.patch" popt="2"/>
    </patches>
    </link>

    Výsledek úprav musíte v případě, že jste editovali lokální soubor, poslat na server pomocí příkazu osc commit. Pomocí tohoto řešení však můžete přidat jen nějaký patch na samotný tarball se zdrojáky. Co dělat v případě, že chcete upravit daný spec soubor? K tomu zase slouží <apply name="patch" />. Jeho použití si ukážeme třeba na situaci, kdy chceme openSUSE distribuční jádro poupravit tak, aby neobsahovalo App Armor.

    Ze všeho nejdříve si stáhneme původní balíček kernel-default z patřičného projektu (záleží na verzi distribuce, pro kterou tuto změnu budeme provádět). Já použiji jádro z projektu openSUSE:Factory a zneužiji již založený projekt home:m4r3k:kernel-backport.

    osc co openSUSE:Factory kernel-default
    cd openSUSE:Factory/kernel-default
    cp kernel-default.spec kernel-default.spec.orig
    

    Nyní si najdeme v souboru kernel-default.spec řádek 174 s následujícím obsahem: Source110: patches.apparmor.tar.bz2 a pomocí znaku # provedeme zakomentování. Totéž uděláme i s řádkem číslo 192, který obsahuje NoSource: 110. Ještě musíme na řádku číslo 228 odebrat příkaz na rozbalení Source balíčku s číslem 110, což provedeme odstraněním části -a 110. Vzhledem k tomu, že k opatchování se používá soubor %_sourcedir/series.conf, který obsahuje seznam aplikovaných patchů, tak ještě musíme všechny patche týkající se app.armor odstranit, což můžeme udělat nějakým kódem v Bashi (viz můj diff). Následně soubor uložíme a pomocí příkazu diff -u kernel-default.spec.old kernel-default.spec si vytvoříme patřičný patch. Ten by měl vypadat nějak takto (samozřejmě si můžete výstup přesměrovat přímo do nějakého souboru):

    --- kernel-default.spec.old     2008-06-27 14:23:46.936011735 +0200
    +++ kernel-default.spec 2008-06-27 22:03:03.060007138 +0200
    @@ -171,7 +171,7 @@
     Source107:      patches.xen.tar.bz2
     Source108:      patches.addon.tar.bz2
     Source109:      patches.kernel.org.tar.bz2
    -Source110:      patches.apparmor.tar.bz2
    +#Source110:      patches.apparmor.tar.bz2
     Source111:      patches.rt.tar.bz2
     Source120:      kabi.tar.bz2
     %define my_builddir %_builddir/%{name}-%{version}
    @@ -189,7 +189,7 @@
     NoSource:       107
     NoSource:       108
     NoSource:       109
    -NoSource:       110
    +#NoSource:       110
     NoSource:       111
     NoSource:       120
     # The following KMPs have been integrated into the kernel package.
    @@ -225,7 +225,7 @@
     fi
     echo "Architecture symbol(s):" %symbols
     # Unpack all sources and patches
    -%setup -q -c -T -a 0 -a 100 -a 101 -a 102 -a 103 -a 104 -a 105 -a 106 -a 107 -a 108 -a 109 -a 110 -a 111 -a 120
    +%setup -q -c -T -a 0 -a 100 -a 101 -a 102 -a 103 -a 104 -a 105 -a 106 -a 107 -a 108 -a 109 -a 111 -a 120
     # Generate the list of supported modules
     (   %_sourcedir/guards %symbols < %_sourcedir/supported.conf
         for how in external; do
    @@ -253,6 +253,8 @@
     subarch=${1%/*}
     # Apply the patches needed for this architecture.
     %if ! %build_vanilla
    +grep -v "patches.apparmor" %_sourcedir/series.conf > %_sourcedir/series.conf.tmp
    +mv %_sourcedir/series.conf.tmp %_sourcedir/series.conf
     for patch in $(%_sourcedir/guards %symbols < %_sourcedir/series.conf); do
         if ! patch -s -E -p1 --no-backup-if-mismatch -i ../$patch; then
            echo "*** Patch $patch failed ***"
    

    UPOZORNĚNÍ: Správně byste měli ještě opravit část %changelog a přidat tam nějaký záznam o tom, že se jedná o opatchovaný build - ale pro naše cvičné účely to není třeba.

    Poté přejdeme do projektu (a patřičného adresáře), kde máme již nalinkovaný balíček kernel-default (v mém případě se jedná o adresář home:m4r3k:kernel-backport/kernel-default) a tento patch soubor do daného adresáře uložíme třeba pod názvem app_armor_remove.patch. Nyní editujeme soubor _link, abychom dostali podobný výsledek.

    <link project="openSUSE:Factory" package="kernel-default">
    <patches>
      <apply name="app_armor_remove.patch" />
    </patches>
    </link>
    

    Ještě je potřeba to všechno poslat na server; to můžeme udělat třeba následující sekvencí příkazů:

    osc add app_armor_remove.patch # přidá soubor app_armor_remove.patch mezi BuildServicem spravované soubory
    osc commit # odešle změny na server
    

    A k čemu mi to je?

    Pokud jste poctivě četli druhý díl seriálu, tak jistě víte, že místo tohoto řešení můžete prostě do adresáře s _link souborem přidat soubor se stejným názvem, který nahradí ten původní. Důvod pro použití patchování v rámci _link souboru je však jednoduchý (kdo na něj přijde před jeho přečtením, má u mě bonbón :-)), tohle řešení je, na rozdíl od toho prvního, vhodné i do budoucna. Musíme si uvědomit, že když přeplácneme patřičný .spec soubor, tak v případě aktualizace dojde k nepříjemné situaci, kdy se nám balíček přestane aktualizovat automaticky s upstream projektem, jež linkujeme. Toto řešení je do jisté míry (limity příkazu patch, který si s každou situací nemusí poradit) dopředné, a proto, pokud dojde k prostému navýšení verze, to naše metoda s patchováním ustojí a sestaví novější verzi balíčku s potřebnými změnami, které jsme provedli.

           

    Hodnocení: 100 %

            š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ář

    David Šmíd avatar 2.7.2008 09:43 David Šmíd | skóre: 10 | blog: dsmid
    Rozbalit Rozbalit vše Re: OBS - 3 (backportujeme kernel a další balíčky)
    openSUSE (a pokud vím i všechny ostatní RPM-based distribuce) fungují na principu stabilních vydání, a ne na principu rolling-updates, jako je tomu třeba v případě Gentoo.
    Minimálně jedna RPM-based distribuce (PCLinuxOS) funguje na principu rolling-updates.
    Jediné "intuitivní" rozhraní je bradavka. Všechno ostatní se musíte naučit. -- Bruce Ediger, o uživatelském rozhraní
    Marek Stopka avatar 2.7.2008 10:39 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: OBS - 3 (backportujeme kernel a další balíčky)
    Aha, díky za info.
    Ilfirin avatar 2.7.2008 20:27 Ilfirin | skóre: 32 | blog: ilfblog | Liberec
    Rozbalit Rozbalit vše Re: OBS - 3 (backportujeme kernel a další balíčky)
    Ovšem ten není v BuildService podporován, pokud se dobře dívám.
    Marek Stopka avatar 2.7.2008 20:31 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: OBS - 3 (backportujeme kernel a další balíčky)
    No a?
    Ilfirin avatar 2.7.2008 20:34 Ilfirin | skóre: 32 | blog: ilfblog | Liberec
    Rozbalit Rozbalit vše Re: OBS - 3 (backportujeme kernel a další balíčky)
    comment, nic víc.
    Marek Stopka avatar 2.7.2008 20:41 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: OBS - 3 (backportujeme kernel a další balíčky)
    Aha, já myslel, že to má nějaký smysl, který mi uniká. :-)
    2.7.2008 21:37 phero | skóre: 17 | blog: techblog
    Rozbalit Rozbalit vše Re: OBS - 3 (backportujeme kernel a další balíčky)
    podporovat bleeding edge distro ani neni mozny
    Marek Stopka avatar 2.7.2008 22:00 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: OBS - 3 (backportujeme kernel a další balíčky)
    Je možné ho podporovat stejně jako openSUSE:Factory... Jen je to technicky náročné... (hlavně na HW)

    Založit nové vláknoNahoru

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