Ötödik napom Haikuval: portoljunk ki néhány programot

TL, DR: Egy újonc látott először Haiku-t, amikor megpróbált átvinni néhány programot a Linux világából.

Az első Haiku portolt programom, hpkg formátumban csomagolva

Nemrég Felfedeztem a Haiku-t, egy meglepően jó operációs rendszert PC-k számára.
Ma megtanulom, hogyan kell új programokat portolni erre az operációs rendszerre. A fő hangsúly a Haikura váltás első tapasztalatainak leírásán van egy Linux-fejlesztő szemszögéből. Elnézést kérek az útközben elkövetett hülye hibákért, mert még egy hét sem telt el azóta, hogy először letöltöttem a Haiku-t.

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

• Portál egy egyszerű CLI-alkalmazást
• Portol egy alkalmazást a grafikus felhasználói felületről a Qt-re
• Utána csomagold be őket hpkg formátumba (mivel még mindig azon gondolkodom, hogy az AppDir-t és az AppImage-et Haikuhoz adaptáljam...)

Kezdjük el. Szakaszokban a dokumentáció и fejlődés, valamint a wiki a HaikuPortsból megtaláltam a helyes irányt. Még egy online PDF-könyv is létezik BeOS: Unix-alkalmazás portolása.
467 oldal – és ez 1997-ből való! Ijesztő belenézni, de remélem a legjobbakat. A fejlesztő szavai biztatóak: „sokáig tartott, mert a BeOS nem volt POSIX-kompatibilis”, de a Haiku „nagyrészt” már ilyen.

Egyszerű CLI alkalmazás portolása

Az első gondolat az alkalmazás áthelyezése volt avrdude, de mint kiderült, ez már az megtettem régen.

Első próbálkozás: nincs mit nézni

Amit nem értek, az már az Az alkalmazásokat több mint 10 éve portolják át a Haiku-ra - annak ellenére, hogy maga az operációs rendszer még nem is 1.0 verzió.

Második próbálkozás: át kell írni

Szóval használom ptouch-770, CLI a címkék nyomtatására használt Brother P-Touch 770 nyomtató vezérléséhez.
Különféle címkéket nyomtatok rá, és az előző cikkben már láthattad. Kicsit korábban írtam egy kis GUI-burkoló programot Pythonban (mivel Gtk+-ban van, át kell írni, és ez jó ok a tanulásra).

Brother P-Touch 770 címkenyomtató. Működik a Haikuval?

A Haiku csomagkezelő ismeri a könyvtárakat és a parancsokat, így ha futás közben "nem találom libintl" üzenetet kapok configure - Csak elindítom pkgman install devel:libintl és megkeresik a szükséges csomagot. Hasonlóképpen pkgman install cmd:rsync. Hát stb.

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

Talán az udev túlságosan Linux-alapú, és ezért nem létezik a Haiku számára. Ez azt jelenti, hogy szerkesztenem kell a forráskódot, amit le akarok fordítani.
Eh, nem tudod átugrani a fejed felett, és nem is tudom, hol kezdjem.

Harmadik próbálkozás

Jó lenne tmate Haiku esetén megengedem a Haiku fejlesztőknek, hogy csatlakozzanak a terminál-munkamenetemhez - ha valami baj lenne. Az utasítások meglehetősen egyszerűek:

./autogen.sh
./configure
make
make install

Jól néz ki, miért nem próbálja ki a Haiku-n?

/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

Ebben a lépésben megnyitom a HaikuDepotot és keresek curses.
Találtunk valamit, ami támpontot adott egy kompetensebb lekérdezé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 elmentem a HaikuDepotba, és természetesen megtalá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

Ennél a lépésnél rájöttem, hogy egy program Haiku-ra portolása sokkal több tudást igényel, mint amennyi egy egyszerű újraépítéshez szükséges.
Beszéltem a barátságos Haiku fejlesztőkkel, kiderült, hogy hiba van az msgpackben, és néhány perc múlva látok egy javítást a HaikuPortsban. Saját szememmel látom, hogy a korrigált csomag ide megy (buildslave - virtuális gépek).

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

Közben küldök egy javítást az upstream-nek Haiku támogatás hozzáadásához az msgpackhez.

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

/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.

Váratlanul jó. Ezt mondtam?!

Visszatérek az eredeti problémához:

/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 nem az msgpack a hibás. kommentálom IMAXLABEL в tty.c így:

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

Eredmény:

osdep-unknown.c: In function 'osdep_get_cwd':
osdep-unknown.c:32:19: warning: unused parameter 'fd' [-Wunused-parameter]
 osdep_get_cwd(int fd)
               ~~~~^~
make: *** No rule to make target 'compat/forkpty-unknown.c', needed by 'compat/forkpty-unknown.o'.  Stop.

Nos, újra megyünk... Apropó:

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

úr. waddlesplash megmondja, hol 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 tettem közzé config.log.

Elmagyarázták nekem, hogy van még valami a libnetworkben a libresolv mellett a Haiku-n. Úgy tűnik, a kódot tovább kell szerkeszteni. Gondolkodni kell…

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

Az ö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

Ugyanaz, csak profilban. Googled és ezt találta. Ha hozzáteszed -lssp "néha" segít, megpróbálom:

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

Azta! Kezdődik! De…

[tmate] ssh.tmate.io lookup failure. Retrying in 2 seconds (non-recoverable failure in name resolution)

Megpróbálom a hibakeresést fájl itt:

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

A „rossz portazonosító” már olyan, mint egy névjegykártya haiku. Esetleg van valakinek ötlete, hogy mi lehet a hiba és hogyan lehetne orvosolni? Ha igen, frissítem a cikket. Link ehhez GitHub.

A GUI-alkalmazás portolása Qt-re.

Egy 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!

Nagyon egyszerű. Kevesebb, mint egy perc!

Alkalmazások csomagolása hpkg-ban haikuporter és haikuports segítségével.

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

• Csapat package - csomagok létrehozásának alacsony szintű módja. Legtöbbször elég neki a PackageInfo, amint azt a "Megfelelő .hpkg csomaggá alakítás" részben leírtuk.
• Valamit tennem kell ilyen a
• Használhatja hpkg-creator (nekem összeomlik, hibajelentés)

Nem világos, mit kell tenni. Azt hiszem, szükségem van egy Hello World stílusú kezdő útmutatóra, ideális esetben egy videóra. Jó lenne egy kényelmes bemutatkozás a HaikuPorterrel is, ahogy az a GNU hello-ban történik.

A következőket olvastam:

haikuporter egy eszköz a Haiku közös csomagprojektek létrehozására. A HaikuPorts adattárat használja minden csomag alapjaként. Haikuporter recepteket használnak csomagok létrehozásához.

Ezen kívül megtudom, hogy:

Nincs szükség a receptek tárolására a HaikuPorts tárhelyen. Készíthetsz még egy tárat, ebbe helyezheted el a recepteket, majd mutasd rá a haikuportert.

Pont amire szükségem van – ha nem keresem a módot a csomag nyilvános kiadására. De ez egy másik bejegyzés témája.

Haikuporter és haikuportok 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/ # make it runnable from anywhere
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

Receptet írni

SUMMARY="Demo QtQuick application"
DESCRIPTION="QtQuickApp is a demo QtQuick application for testing Haiku porting and packaging"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="None"
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
}

A recept összeállítása

néven mentem el a fájlt QtQuickApp-1.0.recipe, ami után elindítom aikuporter -S ./QuickApp-1.0.recipe. A függőségek a lerakatban lévő összes csomagnál ellenőrzik haikuportok, ami némi időt vesz igénybe. Megyek kávézni.

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

szerint mr. waddlesplash:

Olyannal, hogy a repositoryban bármilyen fájlt átírhatsz 😉 Ezt egy kicsit optimalizálhatod, szükség esetén kiszámolva a szükséges információkat, mert az utolsó változtatások elég ritkák.

~/QtQuickApp> haikuporter  QtQuickApp-1.0.recipe
Checking if any dependency-infos need to be updated ...
Looking for stale dependency-infos ...
Error: QtQuickApp not found in repository

Kiderült, hogy nem létezik olyan szokásos receptfájl, amely az alkalmazás forráskódját tartalmazza. HaikuPorts formátumú adattárban kell tartania.

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

Ez a tény még körülményesebbé teszi az összeszerelést. Nem különösebben szeretem, de szükségesnek tartom, hogy végül minden nyílt forráskódú szoftver megjelenjen a HaikuPortsban.

A következőket kapom:

~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe
Checking if any dependency-infos need to be updated ...
        updating dependency infos of QtQuickApp-1.0
Looking for stale dependency-infos ...
Error: QtQuickApp-1.0.recipe not found in tree.

Mi a baj? Az irc elolvasása után:

~/QtQuickApp> haikuporter -S QtQuickApp
Checking if any dependency-infos need to be updated ...
        updating dependency infos of QtQuickApp-1.0
Looking for stale dependency-infos ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Downloading: https://github.com/probonopd/QtQuickApp.git ...
--2019-07-14 16:12:44--  https://github.com/probonopd/QtQuickApp.git
Resolving github.com... 140.82.118.3
Connecting to github.com|140.82.118.3|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://github.com/probonopd/QtQuickApp [following]
--2019-07-14 16:12:45--  https://github.com/probonopd/QtQuickApp
Reusing existing connection to github.com:443.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘/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’ saved [90094]
Validating checksum of QtQuickApp.git
Warning: ----- CHECKSUM TEMPLATE -----
Warning: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Warning: -----------------------------
Error: No checksum found in recipe!

Felmerült egy érdekes kérdés. Ha hozzáadok egy ellenőrző összeget a recepthez - megfelel-e a legújabb git commit a folyamatos integrációhoz? (A fejlesztő megerősíti: "Nem fog működni. A recepteket úgy tervezték, hogy viszonylag stabilak legyenek.")

A szórakozás kedvéért add hozzá a recepthez:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Még mindig nem elégedett:

~/QtQuickApp> haikuporter -S QtQuickApp
Checking if any dependency-infos need to be updated ...
        updating dependency infos of QtQuickApp-1.0
Looking for stale dependency-infos ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------
Skipping download of source for QtQuickApp.git
Validating checksum of QtQuickApp.git
Unpacking source of QtQuickApp.git
Error: Unrecognized archive type in file /boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git

Mit csinál? Hiszen ez egy git repository, a kód már direktben van, nincs mit kicsomagolni. Az én szempontom szerint az eszköznek elég okosnak kell lennie ahhoz, hogy ne keressen kicsomagolót, ha a GitHub URL felett van.

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

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

Most így panaszkodik:

Downloading: git://github.com/probonopd/QtQuickApp.git ...
Error: Downloading from unsafe sources is disabled in haikuports.conf!

Hmm, miért olyan bonyolult minden, miért nem lehet „csak dolgozni”? Végül is nem olyan ritka, hogy a GitHubból építenek valamit. Legyen szó olyan eszközökről, amelyek azonnal működnek, beállítás nélkül, vagy ahogy én nevezem "nyavalygás".

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

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

Dehogy. Még mindig kapom ezt a furcsa hibát, és az itt leírtak szerint

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

Kicsit arrébb megyek, de miért üvöltözik velem (a GitHub nem biztonságos!) és még mindig próbál kicsomagolni valamit.

Szerint úr. waddlesplash:

Nos, igen, az ok az összeállításhoz kapott adatok sértetlenségének ellenőrzése volt. Az egyik lehetőség az archívum ellenőrző összegének ellenőrzése, de természetesen az egyes fájlokat is kivonatolja, ami nem kerül megvalósításra, mert sokkal tovább tart. Ennek a következménye a git és más VCS „bizonytalansága”. Ez valószínűleg mindig így lesz, mivel az archívum létrehozása a GitHubon meglehetősen egyszerű és gyakran gyorsabb. Nos, a jövőben talán nem lesz ilyen feltűnő a hibaüzenet... (a HaikuPortokban már nem egyesítünk ilyen recepteket).

~/QtQuickApp> haikuporter -S QtQuickApp
Checking if any dependency-infos need to be updated ...
Looking for stale dependency-infos ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Downloading: git+https://github.com/probonopd/QtQuickApp.git ...
Warning: UNSAFE SOURCES ARE BAD AND SHOULD NOT BE USED IN PRODUCTION
Warning: PLEASE MOVE TO A STATIC ARCHIVE DOWNLOAD WITH CHECKSUM ASAP!
Cloning into bare repository '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Unpacking source of QtQuickApp.git
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
Command 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' returned non-zero exit status 2

Régi megszokásból jó embereket kérdezek az irc.freenode.net hálózat #haiku csatornáján. És hol lennék nélkülük? A tipp 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"

Oké, világossá vált, hogy mit csinál – letölt egy archívumot egy bizonyos változat forráskódjával. Az én szemszögemből hülyeség, és nem pont az, amit szerettem volna, nevezetesen letölteni a legújabb verziót a fő ágról.

Az egyik fejlesztő így magyarázta:

Saját CI-vel rendelkezünk, így minden, ami a haikuportok tárolójában van, minden felhasználó számára csomagolva lesz, és nem akarjuk megkockáztatni, hogy „mindent a legújabb verzióban upstream” összegyűjtsünk és kézbesítsünk.

Értem! Mindenesetre ez történt:

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
(...)

Ezt a végtelenségig megismétli. Úgy tűnik, ez egy hiba (van alkalmazás? Nem találtam).

С haikuporter és tárház haikuportok Nincs "csak működik" érzése, de fejlesztőként van néhány dolog, amit szeretek a Haikuval való munka során. Legtöbbször hasonlít az Open Build Service-hez, a Linux buildek készítéséhez szükséges eszközkészlethez: rendkívül erős, szisztematikus megközelítéssel, de túlzás az én kis "hello world" alkalmazásomhoz.

Ismét, mr. waddlesplash:

Valójában a HaikuPorter alapértelmezés szerint meglehetősen szigorú (plusz, van egy szöszös mód, valamint egy szigorú mód, hogy még szigorúbb legyen!), de csak azért, mert olyan csomagokat hoz létre, amelyek működni fognak, nem csak csomagokat. Ezért panaszkodik a be nem jelentett függőségekre, a nem megfelelően importált könyvtárakra, a hibás verziókra stb. A cél az, hogy minden problémát – beleértve a jövőbelieket is – elkapjunk, mielőtt a felhasználó értesülne róla (ezért nem lehetett az avrdude-t telepíteni, mert a függőséget a receptben valóban megadták). A könyvtárak nem csupán egyedi csomagok vagy akár konkrét SO-verziók. A HaikuPorter biztosítja, hogy mindezt betartsák magukban a receptekben, hogy elkerüljék a hibákat a végrehajtás során.

Ez a szigor elvileg indokolt operációs rendszer készítésekor, de egy „hello world” alkalmazásnál számomra feleslegesnek tűnik. Úgy döntöttem, hogy megpróbálok valami mást.

Alkalmazások létrehozása hpkg formátumban a „package create” paranccsal

Lehet, ezt Az egyszerű utasítások jobban működnek nekem?

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

summary "Demo QtQuick application"
description "QtQuickApp is a demo QtQuick application for testing Haiku porting and packaging"

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# See below if you also want the application
# to appear in the menu

Váratlanul gyors, váratlanul egyszerű, váratlanul hatékony. Pontosan ahogy szeretem, csodálatos!

Telepítés - mit és hol?

A QtQuickApp.hpkg fájl áthelyezve ide ~/config/packagesfájlkezelővel, ami után varázsütésre megjelent a QtQuickApp ~/config/apps.
Ismét váratlanul gyors, egyszerű és hatékony. Elképesztő, hihetetlen!

De... (hol lennénk nélkülük!)

Az alkalmazás még mindig hiányzik az alkalmazások menülistájából és a QuickLaunchból. Azt hiszem, már tudom, hogyan kell megjavítani. A fájlkezelőben áthelyezem a QtQuickApp.hpkg fájlt a ~/config/packages mappából a /system/packages mappába.

Nem, még mindig hiányzik. Úgy tűnik, én (na és az utasítások) kihagytam valamit.

Miután megnéztem a HaikuDepot „Tartalom” lapját néhány más alkalmazásért, láttam, hogy vannak olyan fájlok, mint pl. /data/mimedb/application/x-vnd... ami még figyelemre méltó /data/deskbar/menu/Applications/….

Na, mit tegyek oda? Gyerünk...

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

Egészen biztos vagyok benne, hogy ez a trükk beválik, de a kérdések továbbra is felmerülnek: miért van erre szükség, mire való? Szerintem ez tönkreteszi azt az általános benyomást, hogy a rendszer ennyire kifinomult.

Amint azt Mr. waddlesplash:

Néha vannak olyan alkalmazások, amelyekre más alkalmazásoknak szüksége van, de nincsenek a menüben. Például a LegacyPackageInstaller a képernyőképen, .pkg archívumok feldolgozása BeOS formátumban. Szeretném, ha a felhasználók telepítenék őket, de a menüben való jelenlétük zavart okoz.

Valamiért nekem úgy tűnik, hogy van egyszerűbb megoldás pl Hidden=true fájlokban .desktop Linuxon. Miért nem teszi a „rejtett” információt a fájlrendszer erőforrásává és attribútumaként?

Ami különösen nem finom, az a menüt megjelenítő (egyes) alkalmazás neve, deskbar, útközben mereven megkötözve.

úr. A waddlesplash ezt magyarázza:

A „Deskbar” ebben az esetben egyfajta általános kifejezésként értendő (nagyjából ugyanúgy, mint a „tálcán”, amely mind a Windows alkalmazásra, mind az általános koncepcióra vonatkozik). Nos, azóta deskbar, nem a „Deskbar”, ez is hasonlóképpen érthető.

2 "majdnem azonos" könyvtár, benne alkalmazásokkal

Miért van 2 könyvtár az alkalmazásokkal, és miért van az egyikben a QtQuickApplication, a másikban miért nincs? (Végül is ez nem egy rendszer, hanem egy második felhasználói, ami számomra személy szerint érthető lenne).
Nagyon össze vagyok zavarodva, és úgy gondolom, hogy ezt egységesíteni kellene.

megjegyzés: mr. waddlesplash

Az Alkalmazások katalógusa olyan alkalmazásokat tartalmaz, amelyekre nincs szükség a menüben. De az étlap helyzetén valóban javítani kell, testreszabhatóbbá tenni.

Jelentkezés, különben nem történik meg 😉

Elgondolkodtam: valóban szükséges-e az alkalmazások tárolása /system/apps, ha a felhasználók ott látják őket, az nem kívánatos. Lehet, hogy jobb lenne egy másik helyen elhelyezni őket, ahol a felhasználó nem találkozik velük? Csakúgy, mint a Mac OS X-ben, ahol a csomagok tartalma .app, amely nem lehet látható a felhasználó számára /Applications, a /Rendszer/Könyvtár/…“` mélyén megbújva.

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

Szerintem érdemes valahogy konkretizálni a függőségeket, nem? Alapértelmezés szerint a Qt a Haiku telepítés kötelező részének tekinthető? Dehogy! A Qt alapértelmezés szerint nincs telepítve. A csomagkészítő automatikusan felismerheti a függőségeket az ELF-fájlok ellenőrzésével? Azt mondták nekem, hogy a HaikuPorter valóban ezt csinálja, de package Nem. Ez azért van, mert ez csak egy "csomagkészítő", amely csak önmagában hoz létre fájlokat hpkg.

Kell-e kifinomultabbá tenni a haikukat egy olyan irányelv hozzáadásával, amely szerint a csomag nem függhet a haikukon kívüli csomagoktól? haikuports? (Szeretném, mert egy ilyen házirend nagyban megkönnyítené a dolgokat – a rendszer képes lenne automatikusan feloldani minden bárhonnan letöltött csomag függőségét anélkül, hogy további csomagforrásokkal kellene vacakolni.)

úr. waddlesplash elmagyarázza:

Nem szeretnénk ennyire korlátozni a fejlesztők szabadságát, mert nyilvánvaló, hogy ha a CompanyX a saját szoftverkészletét akarja függőséggel (és ezáltal repository-val) támogatni, akkor azt teljesen szabadon megteszi.

Ebben az esetben érdemes lehet azt javasolni, hogy a harmadik féltől származó csomagok kerüljék el a haikuportokban nem szereplő dolgoktól való függőséget azáltal, hogy mindent, ami szükséges, teljesen becsomagolnak az alkalmazásba. De azt hiszem, ez egy témája ennek a sorozatnak a jövőbeni cikkében. [A szerző az AppImage felé tart? — kb. fordító]

Alkalmazásikon hozzáadása

Mi a teendő, ha szeretném hozzáadni az egyik ügyes beépített ikont az újonnan létrehozott alkalmazásom erőforrásaihoz? Kiderült, hogy ez egy elképesztő téma, így ez lesz a következő cikk alapja.

Hogyan szervezzük meg a folyamatos alkalmazásépítéseket?

Képzeljünk el egy olyan projektet, mint az Inkscape (igen, tisztában vagyok vele, hogy még nem érhető el Haikuban, de kényelmesen megjeleníthető rajta). Forráskód-tárral rendelkeznek https://gitlab.com/inkscape/inkscape.
Minden alkalommal, amikor valaki végrehajtja a módosításait a tárolóban, build folyamatok indulnak el, amelyek után a változtatások automatikusan tesztelésre, összeépítésre és az alkalmazás különböző csomagokba, köztük az AppImage for Linux-ba (egy önálló alkalmazáscsomag, amely ettől függetlenül letölthető helyi tesztelésre) csomagolódnak. mit lehet vagy nem telepített a rendszerre [Tudtam! — kb. fordító]). Ugyanez történik minden fiókegyesítési kérelemnél, így az összevonás előtt letöltheti az összevonási kérelemben javasolt kódból épített alkalmazást.

A kérések egyesítése build állapotokkal és a lefordított binárisok letöltésének lehetőségével, ha a felépítés sikeres (zöld színnel jelölve)

A build Docker-tárolókban fut. A GitLab ingyenes futókat kínál Linuxon, és úgy gondolom, hogy lehetséges lenne saját futókat is beépíteni (egyébként nem értem, hogy ez hogyan működne olyan rendszereken, mint a Haiku, amelyekről tudom, hogy nincs Docker vagy azzal egyenértékű, de a FreeBSD-hez sem létezik Docker, így ez a probléma nem csak a Haikura jellemző).

Ideális esetben a Haiku-alkalmazások egy Docker-tárolóba építhetők Linuxhoz. Ebben a helyzetben a Haiku összeállítás beilleszthető a meglévő csővezetékekbe. Vannak keresztfordítók? Vagy emuláljam az összes Haiku-t egy Docker-tárolóban, olyasmivel, mint QEMU/KVM (feltételezve, hogy a Dockerben is így fog működni)? Egyébként sok projekt hasonló elveket alkalmaz. Például a Scribus megteszi ezt – már elérhető a Haiku számára. Egyszer eljön a nap, amikor küldhetek ilyen Húzza le a kéréseket más projektekhez a Haiku támogatás hozzáadásához.

Az egyik fejlesztő elmagyarázza:

Más projektek esetében, amelyek maguk kívánnak csomagokat létrehozni, a szokásos CMake/CPack metódus támogatott. Más összeállítási rendszerek is támogathatók, ha közvetlenül hívjuk a csomag build programját, ami jó, ha az embereket érdekli. A tapasztalatok azt mutatják, hogy eddig nem volt nagy érdeklődés, így a haikuporter a számunkra megfelelő módon működött, de végső soron mindkét módszernek együtt kell működnie. Be kell vezetnünk egy eszközkészletet a Linux vagy bármely más szerver operációs rendszerből származó szoftverek keresztépítéséhez (a Haiku nem szervereken való futtatásra készült).

vastapsot adok. A rendszeres Linux-felhasználók mindezt a plusz terhelést és plusz poggyászt (biztonság, szigorú ellenőrzés stb.) hordozzák, ami egy szerver operációs rendszerhez szükséges, de a személyeshez nem. Teljesen egyetértek tehát azzal, hogy a Haiku-alkalmazások Linuxon való elkészítése a helyes út.

Következtetés

A POSIX-alkalmazások Haiku-ra portolása lehetséges, de drágább lehet, mint egy tipikus újraépítés. Biztosan sokáig leragadnék ennél, ha nem segítenének az irc.freenode.net hálózat #haiku csatornájáról. De még ők sem mindig látták azonnal, mi a baj.

A Qt nyelven írt alkalmazások egyszerű kivételt képeznek. Probléma nélkül összeállítottam egy egyszerű bemutató alkalmazást.

Egyszerű alkalmazásokhoz is elég egyszerű csomagot építeni, de csak a „hagyományosan kiadottaknak”, pl. verziózott forráskód-archívumokkal, amelyek a haikuportokban való támogatásra szolgálnak. Úgy tűnik, hogy a GitHubdal történő folyamatos építkezés (a változtatások minden elfogadásához szükséges összeállítás) minden nem olyan egyszerű. Itt a Haiku inkább egy Linux disztribúciónak tűnik, mint egy Mac-en, ahol az XCode „Build” gombjára kattintva egy csomagot kapunk. .app, készen áll a lemezképbe való beillesztésre .dmg, letölthető a honlapomon.
A „szerver” operációs rendszerre, például Linuxra épülő alkalmazások folyamatos építése nagy valószínűséggel fejlesztői igény esetén válik lehetővé, de jelenleg a Haiku projektnek más, sürgetőbb feladatai is vannak.

Próbáld ki magad! Végül is a Haiku projekt képeket biztosít a DVD-ről vagy USB-ről történő indításhoz, generált formában napi. A telepítéshez csak töltse le a képet, és írja be egy flash meghajtóra Rézmetsző

Van kérdésed? Meghívjuk Önt az orosz nyelvű távirati csatorna.

Hiba áttekintése: Hogyan lődd lábon magad C és C++ nyelven. Haiku OS receptgyűjtemény

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

Cikkek listája: Első A második harmadik negyedik

Forrás: will.com