🥇Ötödik napom a Haiku-n: portoljunk egy kicsit a programból

Röviden összefoglalva: A kezdő először találkozott a Haiku-val, és próbálja átportálni néhány programot a Linux világából.

Az első Haiku-ra portolt programom, amelyet hpkg formátumban csomagoltam.

Nemrégiben Felfedeztem a Haiku-t, ami váratlanul jó operációs rendszer a PC-k számára.
Ma azt fogom tanulni, hogyan lehet új programokat átportálni erre az operációs rendszerre. Főként az első tapasztalatomat írom le, hogy a Haiku-ra való átállás milyen volt Linux fejlesztő szemszögéből. Elnézést a folyamat során elkövetett butaságokért, hiszen azóta, hogy először letöltöttem a Haiku-t, még egy hét sem telt el.

Három célt szeretnék elérni:

Egyszerű CLI alkalmazás átportálása
GUI-alapú alkalmazás átportálása Qt-ra
Majd csomagolni őket hpkg formátumba (mivel még mindig gondolkodom az AppDir és AppImage Haiku-ra való alkalmazásán…)

Lássunk hozzá. A dokumentáció és fejlesztés volt, valamint a wiki HaikuPorts szekcióiból találtam a megfelelő irányt. Van egy PDF online könyv is, BeOS: Unix alkalmazás átportálása.
467 oldal — és ez 1997 óta! Rémisztő belenézni, de remélem, a legjobb. A fejlesztő szavai bíztatóak: „hosszadalmas, mert a BeOS nem volt POSIX-kompatibilis”, de a Haiku „nagyrészt” már az.

Egyszerű CLI alkalmazás átportálása

Az első gondolatom egy alkalmazás átportálása volt, avrdudede mint kiderült, ez már hoztak régen megtörtént.

Első kísérlet: nincs mit nézni

Amit meg nem tudok érteni, az az, hogy már több mint 10 éve portálják az alkalmazásokat Haiku-ra, miközben magának az operációs rendszernek még a 1.0-s verziója sincs.

Második kísérlet: át kell írni

Tehát használni fogom ptouch-770,a Brother P-Touch 770 nyomtató kezelésére szolgáló CLI-t, amellyel címkéket nyomtatok.
Különböző címkéket nyomtatok rajta, és valószínűleg már láttad a múltkori cikkemben. Korábban írtam egy kis GUI burkolóprogramot Pythonban (mivel Gtk+-on fut — át kell írnom, ami jó lehetőség a tanulásra).

Brother P-Touch 770 címkenyomtató. Működni fog Haiku alatt?

A Haiku csomagkezelő ismeri a könyvtárakat és a parancsokat, így ha azt az üzenetet kapom, hogy „can’t find libintl” a futtatáskor, configure csak futtatom a pkgman install devel:libintl és a szükséges csomag meg lesz találva. Hasonlóképpen, pkgman install cmd:rsync,. Nos, és így tovább.

Kivéve, ha ez nem működik:

/Haiku/home> git clone https://github.com/probonopd/ptouch-770
Cloning into 'ptouch-770'...
remote: Enumerating objects: 134, done.
remote: Total 134 (delta 0), reused 0 (delta 0), pack-reused 134
Receiving objects: 100% (134/134), 98.91 KiB | 637.00 KiB/s, done.
Resolving deltas: 100% (71/71), done./Haiku/home> cd ptouch-770//Haiku/home/ptouch-770> make
gcc -Wall -O2 -c -o ptouch-770-write.o ptouch-770-write.c
ptouch-770-write.c:28:10: fatal error: libudev.h: No such file or directory
 #include <libudev.h>
          ^~~~~~~~~~~
compilation terminated.
Makefile:16: recipe for target 'ptouch-770-write.o' failed
make: *** [ptouch-770-write.o] Error 1/Haiku/home/ptouch-770> pkgman install devel:libudev
100% repochecksum-1 [65 bytes]
Validating checksum for Haiku...done.
100% repochecksum-1 [64 bytes]
Validating checksum for HaikuPorts...done.
*** Failed to find a match for "devel:libudev": Name not found/Haiku/home/ptouch-770> pkgman install devel:udev
100% repochecksum-1 [65 bytes]
Validating checksum for Haiku...done.
100% repochecksum-1 [64 bytes]
Validating checksum for HaikuPorts...done.
*** Failed to find a match for "devel:udev": Name not found

Lehet, hogy az udev túl linuxos, ezért nincs Haiku-ra. Ez azt jelenti, hogy módosítanom kell a forráskódot, amelyet próbálok lefordítani.
Hát, nem tudom, honnan kezdjem.

Harmadik kísérlet

Jó lenne, ha lenne tmate a Haiku számára, akkor engedném a Haiku fejlesztőit, hogy csatlakozzanak a terminál sessionömhöz - ha valami balul sülne el. Az utasítások elég egyszerűek:

./autogen.sh
./configure
make
make install

Jól néz ki, hát miért ne próbálnám ki a Haikun?

/Haiku/home> git clone https://github.com/tmate-io/tmate/Haiku/home> cd tmate//Haiku/home/tmate> ./autogen.sh
(...)/Haiku/home/tmate> ./configure
(...)
checking for libevent... no
checking for library containing event_init... no
configure: error: "libevent not found"/Haiku/home/tmate> pkgman install devel:libevent
(...)
The following changes will be made:
  in system:
    install package libevent21-2.1.8-2 from repository HaikuPorts
    install package libevent21_devel-2.1.8-2 from repository HaikuPorts
Continue? [yes/no] (yes) :
100% libevent21-2.1.8-2-x86_64.hpkg [965.22 KiB]
(...)
[system] Done.checking for ncurses... no
checking for library containing setupterm... no
configure: error: "curses not found"/Haiku/home/tmate> pkgman install devel:libcurses
(...)
*** Failed to find a match for "devel:libcurses": Name not found/Haiku/home/tmate> pkgman install devel:curses
(...)
*** Failed to find a match for "devel:curses": Name not found

Ezen a lépésen megnyitom a HaikuDepót és keresek curses.
Találtam valamit, ami adott egy javaslatot a pontosabb kereséshez:

/Haiku/home/tmate> pkgman install devel:libncurses
(...)
100% ncurses6_devel-6.1-1-x86_64.hpkg [835.62 KiB]
(...)./configure
(...)
checking for msgpack >= 1.1.0... no
configure: error: "msgpack >= 1.1.0 not found"/Haiku/home/tmate> pkgman install devel:msgpack
(...)
*** Failed to find a match for "devel:msgpack": Name not found/Haiku/home/tmate> pkgman install devel:libmsgpack
(...)
*** Failed to find a match for "devel:libmsgpack": Name not found

Ismét visszamentem a HaikuDepóra, és természetesen találtam devel:msgpack_c_cpp_devel. Mik ezek a furcsa nevek?

/Haiku/home/tmate> pkgman install devel:msgpack_c_cpp_devel
100% repochecksum-1 [65 bytes]
Validating checksum for Haiku...done.
100% repochecksum-1 [64 bytes]
Validating checksum for HaikuPorts...done.
*** Failed to find a match for "devel:msgpack_c_cpp_devel": Name not found# Why is it not finding it? To hell with the "devel:".../Haiku/home/tmate> pkgman install msgpack_c_cpp_devel
(...)
The following changes will be made:
  in system:
    install package msgpack_c_cpp-3.1.1-1 from repository HaikuPorts
    install package msgpack_c_cpp_devel-3.1.1-1 from repository HaikuPorts
Continue? [yes/no] (yes) :
(...)/Haiku/home/tmate> ./configure
(...)
checking for libssh >= 0.8.4... no
configure: error: "libssh >= 0.8.4 not found"/Haiku/home/tmate> pkgman install devel:libssh/Haiku/home/tmate> make
(...)
In file included from /boot/system/develop/headers/msgpack.h:22,
                 from tmate.h:5,
                 from cfg.c:29:
/boot/system/develop/headers/msgpack/vrefbuffer.h:19:8: error: redefinition of struct iovec'
 struct iovec {
        ^~~~~
In file included from tmux.h:27,
                 from cfg.c:28:
/boot/system/develop/headers/posix/sys/uio.h:12:16: note: originally defined here
 typedef struct iovec {
                ^~~~~
Makefile:969: recipe for target 'cfg.o' failed
make: *** [cfg.o] Error 1

Ezen a lépésen rájöttem, hogy egy program Haikura való portolásához lényegesen több tudásra van szükség, mint egy egyszerű újraépítéshez.
Beszéltem a barátságos Haiku fejlesztőkkel, kiderült, hogy hiba van a msgpackban, és néhány percen belül látom a javítást a HaikuPortsban. A szemem előtt bontakozik ki a javított csomag itt épül fel (buildslave - virtuális gépek).

A javított msgpack építése a buildmasteren

Közben elküldöm a javítást az upstreamnek az Haiku támogatásának hozzáadásáért a msgpackhoz.

Öt perccel később a frissített msgpack már elérhető Haiku alatt:

/Haiku/home/tmate> pkgman update
(...)
The following changes will be made:
  in system:
    upgrade package msgpack_c_cpp-3.1.1-1 to 3.2.0-2 from repository HaikuPorts
    upgrade package msgpack_c_cpp_devel-3.1.1-1 to 3.2.0-2 from repository HaikuPorts
Continue? [yes/no] (yes) : y
100% msgpack_c_cpp-3.2.0-2-x86_64.hpkg [13.43 KiB]
(...)
[system] Done.

Meglehetősen jól néz ki. Ezt mondtam?!

Visszatérek az eredeti feladatomhoz:

/Haiku/home/tmate> make
(...)
In file included from tmux.h:40,
                 from tty.c:32:
compat.h:266: warning: "AT_FDCWD" redefined
 #define AT_FDCWD -100

In file included from tty.c:25:
/boot/system/develop/headers/posix/fcntl.h:62: note: this is the location of the previous definition
 #define AT_FDCWD  (-1)  /* CWD FD for the *at() functions */

tty.c: In function 'tty_init_termios':
tty.c:278:48: error: 'IMAXBEL' undeclared (first use in this function); did you mean 'MAXLABEL'?
  tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|IMAXBEL|ISTRIP);
                                                ^~~~~~~
                                                MAXLABEL
tty.c:278:48: note: each undeclared identifier is reported only once for each function it appears in
Makefile:969: recipe for target 'tty.o' failed
make: *** [tty.o] Error 1

Most úgy tűnik, hogy a msgpack nem hibás. Kommentálom IMAXLABEL be. tty.c így nézett ki:

tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|/*IMAXBEL|*/ISTRIP);

Eredmény:

osdep-unknown.c: a 'osdep_get_cwd' függvényben:
osdep-unknown.c:32:19: figyelmeztetés: fel nem használt paraméter 'fd' [-Wunused-parameter]
 osdep_get_cwd(int fd)
               ~~~~^~
make: *** Nincs szabály a 'compat/forkpty-unknown.c' cél eléréséhez, ami szükséges a 'compat/forkpty-unknown.o' -hez. Megáll.

Na, megint... Egyébként:

/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... no

mr. waddlesplash mutatja, hová kell ásni:

/Haiku/home/tmate> ./configure LDFLAGS="-lbsd"
(...)/Haiku/home/tmate> make
(...)
In file included from tmux.h:40,
                 from window.c:31:
compat.h:266: warning: "AT_FDCWD" redefined
 #define AT_FDCWD -100

In file included from window.c:22:
/boot/system/develop/headers/posix/fcntl.h:62: note: this is the location of the previous definition
 #define AT_FDCWD  (-1)  /* CWD FD for the *at() functions */

make: *** No rule to make target 'compat/forkpty-unknown.c', needed by 'compat/forkpty-unknown.o'.  Stop.

Itt feltettem config.log.

Elmagyarázták, hogy a Haiku alatti libresolv esetében van valami más a libnetworkban. Úgy tűnik, a kódot tovább kell javítani. Gondolkodnom kell...

find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} ;

Örök kérdés: mi történik.

/Haiku/home/tmate> ./configure LDFLAGS="-lbsd"
(...)/Haiku/home/tmate> make
(...)
# Success!# Let's run it:/Haiku/home/tmate> ./tmate
runtime_loader: /boot/system/lib/libssh.so.4.7.2: Could not resolve symbol '__stack_chk_guard'
resolve symbol "__stack_chk_guard" returned: -2147478780
runtime_loader: /boot/system/lib/libssh.so.4.7.2: Troubles relocating: Symbol not found

Ugyanez, csak profibban. Keresgettem és megtaláltam ezt. Ha hozzáadom -lssp "néha" segít, megpróbálom:

/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmate

Hűha! Elindul! De...

[tmate] ssh.tmate.io névkérés hiba. Újrapróbálkozás 2 másodperc múlva (nem helyreállítható hiba a név feloldásában)

Megpróbálom debuggolni, a fájl itt van:

/Haiku/home/tmate> strace -f ./tmate >log 2>&1

"Hibás port azonosító" - ez már mint egy névjegykártya haiku. Talán valaki tudja, hogy mi a baj, és hogyan lehet javítani? Ha igen, frissítem a cikket. Link a GitHub.

GUI alkalmazás portolása a Qt-ra.

Egyszerű QML alkalmazást választok.

/> cd /Haiku/home//Haiku/home> git clone https://github.com/probonopd/QtQuickApp
/Haiku/home/QtQuickApp> qmake .
/Haiku/home/QtQuickApp> make
/Haiku/home/QtQuickApp> ./QtQuickApp # Works!

Valóban egyszerű. Kevesebb mint egy perc!

Alkalmazások csomagolása hpkg használatával, haikuporter és haikuports.

Mivel kezdjem? Nincs egyszerű dokumentáció, megyek a #haiku csatornára az irc.freenode.net-en, és hallom:

A parancs csomag — alacsony szintű módszer csomagok létrehozására. Többnyire elegendő számára a PackageInfo, ahogy azt a „Csináljuk meg rendesen a .hpkg csomagot” részben leírták.
Tennem kell valamit. ennyit
Használható hpkg-creator (kidob, hiba jelentés)

Nem tudom, mit tegyek. Úgy gondolom, szükségem van egy kezdőknek szóló útmutatóra a „Helló, Világ!” stílusában, lehetőleg videóval. Jól jönne egy könnyen érthető bevezető a HaikuPorterhez is, mint a GNU hello esetében.

A következőt olvasom:

haikuporter ez egy eszköz a közös csomagprojektek létrehozására a Haiku számára. A HaikuPorts repozitóriumot használja bázisként minden csomaghoz. A csomagok létrehozásához haikuporter recepteket használ.

Ezen kívül megtudom, hogy:

Nincs szükség arra, hogy a receptek a HaikuPorts tárolóban legyenek. Készíthetsz egy másik repozitóriumot, elhelyezheted benne a recepteket, majd a haikuporter-nek megadhatod azt.

Pontosan az, amire szükségem van — hacsak nem keresem a csomag nyilvános elhelyezésének módját. De ez egy másik bejegyzés témája.

haikuporter és haikuports telepítése

cd /boot/home/
git clone https://github.com/haikuports/haikuporter --depth=50
git clone https://github.com/haikuports/haikuports --depth=50
ln -s /boot/home/haikuporter/haikuporter /boot/home/config/non-packaged/bin/ # futtathatóvá teszem bárhonnan
cd haikuporter
cp haikuports-sample.conf /boot/home/config/settings/haikuports.conf
sed -i -e 's|/mydisk/haikuports|/boot/home/haikuports|g' /boot/home/config/settings/haikuports.conf

Recept írása

SUMMARY="Demo QtQuick alkalmazás"
DESCRIPTION="A QtQuickApp egy demo QtQuick alkalmazás a Haiku portolásának és csomagolásának tesztelésére"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="Nincs"
LICENSE="MIT"
REVISION="1"
SOURCE_URI="https://github.com/probonopd/QtQuickApp.git"
#PATCHES=""
ARCHITECTURES="x86_64"
PROVIDES="
    QtQuickApp = $portVersion
"
REQUIRES="
    haiku
"
BUILD_REQUIRES="
    haiku_devel
    cmd:qmake
"BUILD()
{
    qmake .
    make $jobArgs
}INSTALL()
{
    make install
}

Recept összeállítása

Fájl mentése a következő néven QtQuickApp-1.0.recipe, majd elindítom haikuporter -S ./QuickApp-1.0.recipe. Ellenőrizve lesznek a függőségek minden csomagra a repozitóriumban haikuports, ami eltart egy ideig. Elmegyek kávét inni.

Miért kell ezt az ellenőrzést a helyi gépemen végezni, és nem központosítva a szerveren egyszer mindenkinek?

Mr. waddlesplash szerint:

Mert át lehet írni bármely fájlt a repozitóriumban 😉 Lehetne kicsit optimalizálni, és az információt akkor kiszámolni, amikor szükséges, mert az elmúlt változtatások viszonylag ritkák.

~QtQuickApp> haikuporter QtQuickApp-1.0.recipe
Ellenőrizve, hogy szükség van-e a függőség-információk frissítésére...
Keresés régi függőség-információk után...
Hiba: QtQuickApp nem található a repozitóriumban.

Kiderült, hogy nem létezik egyetlen normál receptfájl sem, amely az alkalmazásod forráskódját tartalmazza. Ezt a HaikuPorts-ban kell tárolni.

~\/QtQuickApp> mv QtQuickApp-1.0.recipe ..\/haikuports\/app-misc\/QtQuickApp\/ 
~\/QtQuickApp> ..\/haikuport 
~\/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe

Ez a tény bonyolultabbá teszi a buildelést. Nem különösebben tetszik, de úgy gondolom, hogy szükség van rá, hogy végül minden nyílt forráskódú szoftver megjelenjen a HaikuPorts-ban.

A következőt kapom:

~\/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe
Ellenőrzés, hogy szükség van-e bármilyen függőség-információ frissítésére ...
        a QtQuickApp-1.0 függőségi információinak frissítése
Keresés elavult függőség-információk után ...
Hiba: QtQuickApp-1.0.recipe nem található a fában.

Mi a hiba? IRC olvasása után ezt csinálom:

~\/QtQuickApp> haikuporter -S QtQuickApp
Ellenőrzés, hogy szükség van-e bármilyen függőség-információ frissítésére ...
        a QtQuickApp-1.0 függőségi információinak frissítése
Keresés elavult függőség-információk után ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Letöltés: https:\/\/github.com\/probonopd\/QtQuickApp.git ...
--2019-07-14 16:12:44--  https:\/\/github.com\/probonopd\/QtQuickApp.git
github.com feloldása... 140.82.118.3
Csatlakozás a github.com-hoz|140.82.118.3|:443... csatlakozva.
HTTP kérés elküldve, válaszra várva... 301 Áthelyezve véglegesen
Hely: https:\/\/github.com\/probonopd\/QtQuickApp [tovább követés]
--2019-07-14 16:12:45--  https:\/\/github.com\/probonopd\/QtQuickApp
A meglévő kapcsolatra hivatkozva: github.com:443.
HTTP kérés elküldve, válaszra várva... 200 OK
Hossz: meghatározatlan [text\/html]
Mentés ide: ‘\/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git’
     0K .                                                     1.34M=0.06s
2019-07-14 16:12:45 (1.34 MB\/s) - ‘\/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git’ mentve [90094]
A QtQuickApp.git ellenőrző összegének érvényesítése
Figyelmeztetés: ----- ELLENŐRZŐ ÖSSZEG TEMPLÁTUM -----
Figyelmeztetés: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Figyelmeztetés: -----------------------------
Hiba: Ellenőrző összeg nem található a receptben!

Felmerült egy érdekes kérdés. Ha hozzáadom az ellenőrző összeget a recepthez — az megfelelni fog az utolsó git commitnak a folyamatos integrációhoz? (A fejlesztő megerősíti: „Nem fog működni. A receptek úgy vannak megtervezve, hogy viszonylag stabilak legyenek.”).

Szükségből hozzáadják a recepthez:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Még mindig nem megfelelő:

~\/QtQuickApp> haikuporter -S QtQuickApp
Ellenőrzés, hogy szükség van-e bármilyen függőség-információ frissítésére ...
        a QtQuickApp-1.0 függőségi információinak frissítése
Keresés elavult függőség-információk után ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe
----------------------------------------------------------------------
A QtQuickApp.git forrás letöltését kihagyva
A QtQuickApp.git forrásának kibővítése
Hiba: Ismeretlen archívumtípus a fájlban \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git

Miért is van ez? Hiszen ez egy git tároló, a kód már ott van közvetlenül, nincs mit kibővíteni. Véleményem szerint az eszköznek elég okosnak kell lennie ahhoz, hogy ne keressen kibővítőt, amikor a GitHub URL-t kapja.

Talán működni fog a uri git://

SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"

Most azt mondja:

Letöltés: git://github.com/probonopd/QtQuickApp.git ...
Hiba: A nem biztonságos forrásokból való letöltés le van tiltva a haikuports.conf fájlban!

Hm, miért olyan bonyolult minden, miért nem lehet "csak működni"? Végül is nem olyan ritka, hogy valamit összerakunk a GitHub-ból. Mennyivel jobb lenne, ha az eszközök azonnal működnének, anélkül, hogy bármiféle beállításra lenne szükség, vagy ahogy én hívom, "bonyodalomra".

Talán így fog működni:

SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"

Nem. Még mindig kapom ezt a furcsa hibát, és azt csinálom, ahogy itt van leírva

sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.conf

Kicsit előrébb haladok, de miért kiabál velem (a GitHub nem biztonságos!) és még mindig próbál kibővíteni valamit.

A következő szerint mr. waddlesplash:

Hát igen, az volt az oka, hogy ellenőrizzük az építéshez kapott adatok integritását. Az egyik lehetőség az archívum ellenőrző összegének ellenőrzése, de természetesen hash-elhetjük az egyes fájlokat is, ami nem lesz megvalósítva, mivel az sokkal több időt vesz igénybe. Ennek következménye a git és más VCS-ek "nem biztonságossága". Valószínűleg ez mindig így lesz, mivel archívumot létrehozni a GitHub-on elég könnyű és gyakran gyorsabb. A jövőben talán a hibaüzenet sem lesz annyira kiabáló… (többé nem végezzük el az ilyen recept összeolvasztását a HaikuPorts-ban).

~QtQuickApp> haikuporter -S QtQuickApp
Ellenőrzöm, hogy szükség van-e bármilyen függőségi információ frissítésére ...
Keresem az elavult függőségi információkat ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Letöltés: git+https://github.com/probonopd/QtQuickApp.git ...
Figyelmeztetés: A NEM BIZTONSÁGOS FORRÁSOK ROSSZAK ÉS NEM KELLENE HASZNÁLNI TERMELÉSSEL.
Figyelmeztetés: KÉREM, HOGY AMINT LEHET, MOZOGJON EGY STATIKUS ARCHÍVUM LETÖLTÉSRE AZ ÖSSZEG LEMEZEZÉSEVEL!
Klónozás bare tárolóba '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
A QtQuickApp.git forrásának kibővítése
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Nem lehet megnyitni: Nincs ilyen fájl vagy könyvtár
tar: A hiba nem helyrehozható: most kilépés
A 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' parancs nem nullával egyenlő kilépési állapotot adott vissza 2

Régi szokás szerint elmegyek kérdezni a kedves emberektől a #haiku csatornán az irc.freenode.net hálózaton. Hova is mehetnék nélkülük? A javaslat után rájöttem, hogy használnom kell:

srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8"
SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz"
SOURCE_DIR="QtQuickApp-$srcGitRev"
CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"

Jól van, világos, hogy mit csinál – letölti a forráskódot egy adott revízióból. Véleményem szerint butaság, és nem igazán ez volt a cél, hanem hogy letöltsem az utolsó revíziót a master ágból.

Az egyik fejlesztő így magyarázta ezt:

Van saját CI-nk, tehát minden, ami a haikuports tárolóba kerül, csomagolva lesz minden felhasználó számára, és nem akarunk kockáztatni azzal, hogy 'mindent az upstream legújabb verziójából' összegyűjtünk és szállítunk.

Értem! Mindenesetre ilyen lett:

waiting for build package QtQuickApp-1.0-1 to be activated
waiting for build package QtQuickApp-1.0-1 to be activated
waiting for build package QtQuickApp-1.0-1 to be activated
waiting for build package QtQuickApp-1.0-1 to be activated
waiting for build package QtQuickApp-1.0-1 to be activated
(...)

Ez így folytatódik végtelenítve. Valószínűleg ez hiba (van bejelentett hiba? Én nem találtam).

Késleltetett streaming replikációt is beállíthatunk, de van néhány csapda, amelyek a replikációs slotokkal, a forró tartalék visszajelzésével stb. kapcsolatosak. A WAL archívum lehetővé teszi, hogy elkerüljük ezeket. haikuporter updates-testing haikuports Nem érzek egy olyan szintet, hogy 'csak működik', de mint fejlesztő, van néhány dolog, ami tetszik a Haiku használatában. Túlnyomórészt olyan, mint az Open Build Service — egy rendkívül erőteljes Linux build eszközkészlet, szisztémás megközelítéssel, de túlzás a 'hello world' szintű kis alkalmazásomhoz.

Ismét, mr. waddlesplash szerint:

Valóban, a HaikuPorter alapértelmezés szerint meglehetősen szigorú (és van lint mód, valamint szigorú mód, amelyek még szigorúbbá teszik!), de csak azért, mert olyan csomagokat készít, amelyek működnek, nem csak egyszerűen csomagokat gyárt. Ezért szól a nem deklarált függőségekről, a helytelenül importált könyvtárakról, a hibás verziókról stb. A cél az, hogy minden problémát, a jövőbeliakat is, mielőtt a felhasználó észrevenné, elkapjon (ezért nem tudtuk telepíteni az avrdude-ot, mert a receptben gyakorlatilag meg volt adva egy függőség). A könyvtárak nem csupán külön csomagok vagy a SO-k meghatározott verziói. A HaikuPorter figyelemmel kíséri mindezeket a receptjeiben, hogy elkerülje a futásidejű hibákat.

Elvileg ez a szigorúsági szint indokolt az operációs rendszer készítésekor, de nekem túlzásnak tűnik egy 'hello world' alkalmazás esetében. Eldöntöttem, hogy kipróbálok valami mást.

Alkalmazások csomagolása hpkg formátumban a 'package create' parancs segítségével

Talán, ez egy egyszerűbb utasítás jobban megfelelne nekem?

mkdir -p apps/
cp QtQuickApp apps/cat >  .PackageInfo <<EOF
name QtQuickApp
version 1.0-1
architecture x86_64

summary "Bemutató QtQuick alkalmazás"
description "A QtQuickApp egy demo QtQuick alkalmazás a Haiku portolás és csomagolás tesztelésére"

packager "probono"
vendor "probono"

copyrights "probono"
licenses "MIT"

provides {
  QtQuickApp = 1.0-1
}requires {
  qt5
}
EOFpackage create -b QtQuickApp.hpkg
package add QtQuickApp.hpkg apps# Lásd alább, ha azt is szeretnéd, hogy az alkalmazás
# megjelenjen a menüben

Meglepetésszerűen gyors, meglepetésszerűen egyszerű, meglepetésszerűen hatékony. Pont így, ahogy szeretem, lenyűgöző!

Telepítés — mit és hová?

Áthelyeztem a QtQuickApp.hpkg fájlt a ~ /config/packages, a fájlkezelő használatával, majd a QtQuickApp varázslatos módon megjelent a ~ /config/apps.
Ismét meglepetésszerűen gyors, egyszerű és hatékony. Lélegzetelállító, hihetetlen!

De… (hova nélküle!)

Az alkalmazás még mindig hiányzik az alkalmazások listájából és a QuickLaunch-ból. Azt hiszem, már tudom, hogyan kell ezt megoldani. A fájlkezelőben áthelyezem a QtQuickApp.hpkg-t ~ /config/packages-ból a /system/packages-ba.

Hát, még mindig hiányzik. Úgy tűnik, (hát, és az útmutató) valamit kihagytam.

Némi nyomozás után a HaikuDepot "Tartalom" fülén néhány más alkalmazásnál láttam, hogy vannak fájlok, mint /data/mimedb/application/x-vnd... ami különösen figyelemre méltó, /data/deskbar/menu/Applications/….

Nos, mit is rakjak oda? Nézzük csak…

mkdir -p data/deskbar/menu/Applications/
( cd data/deskbar/menu/Applications ; ln -s .. / .. / .. / .. /apps /QtQuickApp . )
package add QtQuickApp.hpkg apps data

Teljesen biztos vagyok benne, hogy ez a trükk működni fog, de maradtak kérdések: miért van erre szükség, mire jó ez? Szerintem ez rombolja az általános benyomást, hogy a rendszer — egy ilyen kifinomult.

Ahogy mr. waddlesplash magyarázta:

Néha vannak alkalmazások, amik más alkalmazásoknak szükségesek, de nem a menüben. Például a LegacyPackageInstaller a képernyőképen, amely a BeOS formátumú .pkg archívumokat kezeli. Szeretnénk, ha a felhasználók telepítenék őket, de a menüben való megjelenés zűrzavart okozna.

Valamiért úgy érzem, hogy van egy egyszerűbb megoldás, például Hidden=true a fájlokban .desktop Linuxon. Miért ne lehetne a "rejtett" információ egy erőforrás és a fájlrendszer attribútuma?

Ami különösen nem kifinomult — a nevét (egy) alkalmazás, ami megjeleníti a menüt, deskbar, szigorúan kötve van az úthoz.

mr. waddlesplash ezzel kapcsolatban így nyilatkozott:

"Deskbar" ebben az esetben egyfajta általános kifejezésként értendő (körülbelül úgy, mint a "taskbar", amely mind a Windows alkalmazásra, mind az általános koncepcióra vonatkozik). Nos, mivel ez deskbar, és nem "Deskbar", ez is érthető hasonló módon.

2 "majdnem azonos" alkalmazás könyvtár benne

Miért van két alkalmazáskatalógus, és miért van az egyikben az én QtQuickApplication-om, a másikban pedig nincs? (Végül is ez nem egy rendszerkatalógus, hanem egy második felhasználói, amit számomra érthető lenne).
Valóban összezavarodtam, és úgy gondolom, hogy ezt egységesíteni kellene.

mr. waddlesplash megjegyzése

Az Apps katalógusban vannak olyan alkalmazások, amelyekre nincs szükség a menüben. De a menü helyzetét valóban javítani kellene, elérhetőbbé tenni.

Kérelem, vagy ez nem fog megtörténni 😉

Elgondolkodtam: valóban szükséges-e az alkalmazásokat elhelyezni /system/apps, ha a felhasználóknak nem kívánatos ott látni őket. Talán jobb lenne őket egy másik helyen elhelyezni, ahol a felhasználó nem találkozik velük? Ahogyan azt a Mac OS X-ben tették, ahol a csomagok tartalma .app, amelyet a felhasználónak nem kellene látnia a /Applications, el van rejtve a /System/Library/... mélyén.

Mi a helyzet a függőségekkel?

Azt hiszem, érdemes lenne valahogy jelezni a függőségeket, nem? Tekinthető a Qt a Haiku alapértelmezett telepítési részének? Nem! A Qt alapértelmezés szerint nincs telepítve. A csomagépítő program automatikusan képes-e meghatározni a függőségeket az ELF fájlok ellenőrzésével? Azt mondták nekem, hogy a HaikuPorter valóban ezt teszi, de csomag nem. Azért, mert ő csak egy «csomagépítő», aki önállóan csak fájlokat hoz létre. hpkg.

Érdemes lenne-e a Haiku-t kifinomultabbá tenni, bevezetve egy szabályzatot, amely szerint a csomagnak nem lenne szabad olyan csomagok függőségeinek lenni, amelyek nem részei haikuports? (Мне бы так хотелось, поскольку подобная политика значительно облегчает задачу — система смогла бы автоматически разрешить зависимости каждого пакета, загружаемого откуда угодно, без возни с дополнительными источниками пакетов).

mr. waddlesplash tisztázza:

Nem szeretnénk annyira megkötni a fejlesztők kezét, mert nyilvánvaló, hogy ha a CompanyX támogatni szeretné a saját szoftvergyűjteményét függőségekkel (ami tehát azt jelenti, hogy saját tárolót is), akkor teljesen szabadon megteheti.

Ebben az esetben talán ajánlatos lenne elkerülni a harmadik féltől származó csomagok függőségeit bármitől, ami nem része a haikuports-nak, úgy, hogy minden szükségeset teljesen becsomagolunk az alkalmazással. De úgy gondolom, ez már egy jövőbeli cikk témája lesz ebben a sorozatban. [A szerző AppImage-ra utal? — a fordító megjegyzése]

Alkalmazásikon hozzáadása

Mi van, ha szeretnék hozzáadni az újonnan létrehozott alkalmazásom erőforrásaihoz egyet a csinos beépített ikonok közül? Kiderült, hogy ez egy csodálatos téma, így ez lesz a következő cikk középpontjában.

Hogyan lehet folyamatosan építeni az alkalmazásokat?

Képzelj el egy olyan projektet, mint az Inkscape (igen, tudom, hogy nincs még a Haiku-ban, de jól demonstrálható). Van egy forráskód-repozitóriumuk. https://gitlab.com/inkscape/inkscape.
Minden alkalommal, amikor valaki rögzíti a módosításait a repóban, elindulnak a build-pipeline-ok, ezután a módosítások automatikusan tesztelve, összeállítva lesznek, az alkalmazás különböző csomagokba csomagolva, beleértve az AppImage-t a Linuxhoz (ez egy önálló alkalmazáscsomag, amely letölthető helyi tesztelésre, függetlenül attól, hogy mi lehet vagy nem lehet telepítve a rendszeren). [én tudtam! – a fordító megjegyzése]). Hasonlóan fog történni minden merge kérésnél is, így letöltheted az alkalmazást, amely a merge kérésben javasolt kódból készült, még a valódi egyesítés előtt.

A merge kérések a build állapotával és a sikeres build esetén letölthető bináris állományok lehetőségével (zölddel jelölve) rendelkeznek.

A build konténereken belül Docker-ben fut. A GitLab ingyenes runner-eket kínál Linux-ra, ráadásul úgy gondolom, hogy lehetséges saját runner-ek csatlakoztatása is (egyébként nem tudom, hogyan fog működni ez olyan rendszereken, mint a Haiku, amelyekről tudom, hogy nem rendelkeznek Docker-rel vagy annak alternatívájával, de a FreeBSD-nek sincs Docker-e, így ez a probléma nem egyedülálló a Haiku számára).

Ideális esetben a Haiku-hoz való alkalmazások buildelése Docker konténeren belül a Linuxhoz történhet. Ekkor a Haiku buildelése beépíthető a meglévő pipeline-okba. Vannak cross-compiler-ek? Vagy minden Haiku-t le kell emulálni egy Docker konténeren belül, valami QEMU/KVM-hez hasonlóval (feltéve, hogy így fog működni Docker-en belül)? Egyébként sok projekt hasonló elveket alkalmaz. Például a Scribus így működik — már elérhető a Haiku-hoz. Eljön az a nap, amikor tudok ilyen merge kéréseket küldeni más projektekbe, hogy támogassák a Haiku-t.

Az egyik fejlesztő magyarázza:

Más projektek számára, amelyek saját csomagokat szeretnének létrehozni, a hagyományos CMake/CPack módszert támogatják. Más build rendszerek is támogathatók, ha közvetlenül a csomagkészítő programot hívják meg, ami jó, ha az emberek érdeklődnek iránta. A tapasztalat azt mutatja, hogy eddig nem volt különösebb érdeklődés, ezért a haikuporter úgy működött, ahogyan nekünk kényelmes volt, de végső soron mindkét módszernek együtt kell működnie. Eszközkészletet kellene bemutatnunk a Linuxból vagy bármely más szerveroperációs rendszerből történő keresztösszegyűjtéshez (a Haiku nem szerverekhez készült).

Állva tapsolok. A hagyományos Linux felhasználók magukkal cipelik ezt a plusz terhet és plusz csomagot (biztonság, szigorú ellenőrzés stb.), ami szükséges a szerver operációs rendszerhez, de nem a személyeshez. Ezért teljes mértékben egyetértek azzal, hogy a Haiku alkalmazások Linuxon való előállításának lehetősége a helyes út.

Zárás

A POSIX alkalmazások Haiku-ra való portolása lehetséges, de több ráfordítást igényelhet, mint egy szokásos újraépítés. Teljesen belemerülnék ebbe, ha nem lenne segítségem az irc.freenode.net #haiku csatornájáról. De még ők sem mindig látták rögtön, hogy mi a probléma.

A Qt-n írt alkalmazások könnyű kivétel. Egyszerű bemutató alkalmazást állítottam össze különösebb problémák nélkül.

A csomag összeállítása egyszerű alkalmazások számára szintén elég könnyű, de csak a „hagyományos módon kiadott” esetekben, azaz verziózott forráskód archívumokkal, amelyeket a haikuports támogatására szántak. A folyamatos összeszerelés (minden commitra építés) a GitHub-ról nem tűnik olyan egyszerűnek. Itt a Haiku inkább hasonlít a Linux disztribúcióra, mint a Mac eredményt produkáló rendszerére, ahol az XCode-ban a „Build” gombra kattintva egy csomagot kapunk. .app, amely készen áll a lemezképbe való beillesztésre .dmg, készen áll arra, hogy feltöltsem a weboldalamra.
A folyamatos alkalmazásépítés „szerver” operációs rendszerek, például a Linux alapján valószínűleg akkor válik lehetővé, ha igény merül fel a fejlesztők részéről, de jelenleg a Haiku projektnek más, sürgetőbb feladatai vannak.

Próbáld ki te is! A Haiku projekt DVD- vagy USB-ről letölthető képeket biztosít, amelyek napi rendszerességgel. A telepítéshez elegendő letölteni a képet és felírni egy pendrive-ra a Etcher

Kérdéseid vannak? Meghívunk a magyar nyelvű telegram csatornánkra.

Hibák áttekintése: Hogyan lőjön lábon magának C és C++ használatával. A Haiku OS receptgyűjteménye

Től szerző fordítás: ez az ötödik cikk a Haiku-ról szóló cikksorozatból.

Cikkek listája: Első Második Harmadik Negyedik

Forrás: habr.com