🥇Moj peti dan s Haikujem: prenesimo nekaj programov

TL; DR: Novinec je prvič videl Haiku, ko je poskušal prenesti nekatere programe iz sveta Linuxa.

Moj prvi preneseni program Haiku, zapakiran v formatu hpkg

Nedavno Odkril sem Haiku, presenetljivo dober operacijski sistem za osebne računalnike.
Danes se bom naučil prenesti nove programe v ta operacijski sistem. Glavni poudarek je opis prve izkušnje prehoda na Haiku z vidika razvijalca Linuxa. Opravičujem se za morebitne neumne napake, ki sem jih naredil na poti, saj ni minil niti en teden, odkar sem prvič prenesel Haiku.

Želim doseči tri cilje:

Prenesite preprosto aplikacijo CLI
Prenesite aplikacijo iz GUI v Qt
Nato jih zapakirajte v format hpkg (ker še vedno razmišljam o prilagoditvi AppDir in AppImage za Haiku ...)

Začnimo. V razdelkih dokumentacijo и razvoj, kot tudi v wiki od HaikuPorts sem našel pravo smer. Obstaja celo spletna knjiga PDF BeOS: Prenos aplikacije Unix.
467 strani - in to je iz leta 1997! Grozljivo je pogledati notri, a upam na najboljše. Razvijalčeve besede so spodbudne: »trajalo je dolgo, ker BeOS ni bil združljiv s POSIX-om,« a Haiku je »večinoma« že tak.

Prenos preproste aplikacije CLI

Prva misel je bila prenos aplikacije avrdude, a, kot se je izkazalo, je to že Končano dolgo časa nazaj.

Prvi poskus: nič za gledati

Kar ne morem razumeti, je že to Aplikacije so bile prenesene v Haiku že več kot 10 let - kljub dejstvu, da sam OS sploh še ni različica 1.0.

Drugi poskus: potrebno je prepisati

Torej bom uporabil dotik-770, CLI za krmiljenje tiskalnika Brother P-Touch 770, ki ga uporabljam za tiskanje nalepk.
Nanj tiskam različne nalepke, morda ste ga že videli v prejšnjem članku. Malo prej sem napisal majhen GUI wrapper program v Pythonu (ker je v Gtk+, ga bo treba napisati na novo, in to je dober razlog za učenje).

Tiskalnik nalepk Brother P-Touch 770. Ali bo deloval s Haiku?

Upravitelj paketov Haiku pozna knjižnice in ukaze, tako da, če med zagonom dobim sporočilo "ne najdem libintl" configure - Samo zaženem pkgman install devel:libintl in zahtevani paket bo najden. Prav tako pkgman install cmd:rsync. No itd.

Razen ko to ne deluje:

/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

Morda udev preveč temelji na Linuxu in zato ne obstaja za Haiku. Kar pomeni, da moram urediti izvorno kodo, ki jo poskušam prevesti.
Eh, čez glavo ne moreš skočiti, pa sploh ne vem, kje naj začnem.

Tretji poskus

Lepo bi bilo imeti tmate za Haiku, potem bi razvijalcem Haikuja dovolil, da se povežejo z mojo terminalsko sejo - če gre kaj narobe. Navodila so precej preprosta:

./autogen.sh
./configure
make
make install

Izgleda dobro, zakaj ga torej ne bi preizkusili na Haiku?

/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

V tem koraku odprem HaikuDepot in iščem curses.
Nekaj se je našlo, kar mi je dalo namig za kompetentnejšo poizvedbo:

/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

Spet sem šel v HaikuDepot in seveda našel devel:msgpack_c_cpp_devel. Kakšna so ta čudna imena?

/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

Na tem koraku sem spoznal, da prenos programa v Haiku zahteva veliko več znanja, kot je potrebno za preprosto vnovično gradnjo.
Pogovarjal sem se s prijaznimi Haiku razvijalci, izkazalo se je, da je napaka v msgpacku in po nekaj minutah vidim popravek v HaikuPorts. Na lastne oči vidim, kako je popravljen paket grem sem (buildslave - virtualni stroji).

Gradnja popravljenega paketa msgpack na buildmaster

Vmes pošljem popravek proti toku da dodate podporo za Haiku v msgpack.

Pet minut kasneje je posodobljeni msgpack že na voljo v Haiku:

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

Nepričakovano dobro. Sem to rekel?!

Vračam se k prvotni težavi:

/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

Zdaj je videti, da msgpack ni kriv. komentiram IMAXLABEL в tty.c takole:

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

Rezultat:

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.

No, pa smo spet ... Mimogrede:

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

gospod. waddlesplash vam pove, kje kopati:

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

Tukaj sem objavil config.log.

Pojasnili so mi, da je v libnetwork poleg libresolv na Haiku še nekaj drugega. Očitno je treba kodo še dodatno urediti. Treba je razmisliti ...

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

Večno vprašanje: kaj se dogaja?

/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

Ista stvar, samo v profilu. Googled in našel to. Če dodate -lssp »včasih« pomaga, poskušam:

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

Vau! Začenja se! ampak...

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

Poskušal bom odpraviti napake datoteko tukaj:

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

»Bad port ID« je že kot vizitka haiku. Ima mogoče kdo kakšno idejo kaj je narobe in kako to popraviti? Če je tako, bom članek posodobil. Povezava do GitHub.

Prenos aplikacije GUI v Qt.

Izberem preprosto aplikacijo QML.

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

Res preprosto. Manj kot minuta!

Pakiranje aplikacij v hpkg z uporabo haikuporterja in haikuportov.

S čim naj začnem? Preproste dokumentacije ni, grem na kanal #haiku na irc.freenode.net in slišim:

Ekipa package - nizko nivojski način ustvarjanja paketov. Večinoma ji zadošča PackageInfo, kot je opisano v razdelku "Izdelava ustreznega paketa .hpkg"
Nekaj moram narediti ta
Lahko uporabljam hpkg-ustvarjalec (zruši se mi, poročanje o napakah)

Ni jasno, kaj storiti. Predvidevam, da potrebujem priročnik za začetnike v slogu Hello World, najbolje video. Lepo bi bilo imeti tudi priročen uvod v HaikuPorter, kot je to storjeno v GNU hello.

Berem naslednje:

haikuporter je orodje za ustvarjanje skupnih paketnih projektov za Haiku. Kot osnovo za vse pakete uporablja repozitorij HaikuPorts. Za izdelavo paketov se uporabljajo recepti Haikuporter.

Poleg tega ugotavljam, da:

Receptov ni treba shranjevati v shrambo HaikuPorts. Lahko naredite drugo skladišče, vanj postavite recepte in nato nanj usmerite haikuporter.

Ravno to, kar potrebujem - če ne iščem načina za javno objavo paketa. Ampak to je tema za drugo objavo.

Namestitev haikuporterja in haikuportov

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

Pisanje recepta

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
}

Sestavljanje recepta

Datoteko shranim pod imenom QtQuickApp-1.0.recipe, po katerem zaženem aikuporter -S ./QuickApp-1.0.recipe. Odvisnosti so preverjene za vse pakete v repozitoriju haikuports, kar traja nekaj časa. Grem po kavo.

Zakaj za vraga bi bilo to preverjanje opravljeno na mojem lokalnem računalniku in ne centralno na strežniku enkrat za vse?

Po mnenju g. waddlesplash:

S tako, da lahko prepišete katero koli datoteko v repozitoriju 😉 To lahko malo optimizirate, izračunate potrebne informacije, ko je to potrebno, ker so zadnje spremembe precej redke.

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

Izkazalo se je, da ne obstaja običajna datoteka z recepti, ki bi vsebovala izvorno kodo vaše aplikacije. Hraniti ga morate v skladišču v formatu HaikuPorts.

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

Zaradi tega je montaža bolj okorna. Ni mi posebej všeč, vendar mislim, da je potrebno, da se bo sčasoma vsa odprtokodna programska oprema pojavila v HaikuPorts.

Dobim naslednje:

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

Kaj je narobe? Po branju irc naredim:

~/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!

Pojavilo se je zanimivo vprašanje. Če receptu dodam kontrolno vsoto – se bo ujemala z najnovejšo potrditvijo git za neprekinjeno integracijo? (Razvijalec potrjuje: »Ne bo delovalo. Recepti so zasnovani tako, da so relativno stabilni.«)

Za zabavo dodajte receptu:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Še vedno nezadovoljen:

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

Kaj dela? Navsezadnje je to repozitorij git, koda je že neposredno tam, ni ničesar za razpakirati. Z mojega vidika bi moralo biti orodje dovolj pametno, da ne išče programa za razpakiranje, če je nad URL-jem GitHub.

Morda bo deloval uri git://

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

Zdaj se pritožuje takole:

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

Hmm, zakaj je vse tako zapleteno, zakaj ne moreš "samo delati"? Navsezadnje ni tako neobičajno, da nekaj zgradite iz GitHuba. Ne glede na to, ali gre za orodja, ki delujejo takoj, brez potrebe po namestitvi ali, kot jaz temu rečem, "fušanje".

Mogoče bo delovalo takole:

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

Ne. Še vedno dobivam to čudno napako in delam, kot je opisano tukaj

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

Grem malo naprej, ampak zakaj se mi dere (GitHub ni varen!) in še vedno poskuša nekaj razpakirati.

Glede na gospod. waddlesplash:

No, ja, razlog je bila želja po preverjanju celovitosti podatkov, prejetih za montažo. Ena izmed možnosti je tudi preverjanje kontrolne vsote arhiva, lahko pa seveda zgostite posamezne datoteke, kar pa ne bo implementirano, ker traja veliko dlje. Posledica tega je "negotovost" gita in drugih VCS. Najverjetneje bo tako vedno, saj je ustvarjanje arhiva na GitHubu precej enostavno in pogosto hitrejše. No, v prihodnje morda sporočilo o napaki ne bo tako bliskovito ... (v HaikuPorts takih receptov ne združujemo več).

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

Iz stare navade grem vprašat dobre ljudi na #haiku kanal v omrežju irc.freenode.net. In kje bi bil brez njih? Po namigu sem ugotovil, da bi moral uporabiti:

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

V redu, postalo je jasno, kaj počne - prenese arhiv z izvorno kodo določene revizije. Z mojega vidika je neumno in ni ravno tisto, kar sem hotel, namreč prenesti najnovejšo revizijo iz glavne veje.

Eden od razvijalcev je to razložil takole:

Imamo svoj CI, tako da bo vse, kar je postavljeno v repozitorij haikuports, zapakirano za vse uporabnike, in ne želimo tvegati zbiranja in dostave »vsega v najnovejši različici navzgor«.

Razumem! V vsakem primeru se je zgodilo tole:

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

To ponavlja ad infinitum. Očitno je to napaka (ali obstaja aplikacija? Nisem je našel).

С haikuporter in repozitorij haikuports Nima občutka, da "samo deluje", a kot razvijalec mi je pri delu s Haikujem všeč nekaj stvari. Večinoma je podoben storitvi Open Build Service, naboru orodij za gradnjo zgradb Linuxa: izjemno zmogljiv, s sistematičnim pristopom, vendar pretiran za mojo majhno aplikacijo "zdravo, svet".

Spet po besedah g. waddlesplash:

Dejansko je HaikuPorter privzeto precej strog (poleg tega sta na voljo način lint in strogi način, ki ga naredita še bolj strogega!), vendar samo zato, ker ustvarja pakete, ki bodo delovali, namesto da samo ustvarja pakete. Zato se pritožuje nad neprijavljenimi odvisnostmi, nepravilno uvoženimi knjižnicami, nepravilnimi različicami itd. Cilj je ujeti vse težave, vključno s prihodnjimi, preden uporabnik izve zanje (zato ni bilo mogoče namestiti avrdude, ker je bila odvisnost dejansko podana v receptu). Knjižnice niso le posamezni paketi ali celo posebne različice SO. HaikuPorter zagotavlja, da je vse to upoštevano v samih receptih, da bi se izognili napakam med izvajanjem.

Načeloma je ta stopnja strogosti upravičena pri izdelavi operacijskega sistema, vendar se mi zdi nepotrebna za aplikacijo »hello world«. Odločil sem se poskusiti nekaj drugega.

Gradnja aplikacij v formatu hpkg z uporabo ukaza “package create”.

Mogoče je, to Bodo preprosta navodila bolje delovala zame?

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

Nepričakovano hitro, nepričakovano preprosto, nepričakovano učinkovito. Točno tako mi je všeč, neverjetno!

Montaža - kaj in kje?

Datoteka QtQuickApp.hpkg je premaknjena v ~/config/packagesz uporabo upravitelja datotek, po katerem se je čarobno pojavil QtQuickApp ~/config/apps.
Spet nepričakovano hitro, preprosto in učinkovito. Čudovito, neverjetno!

Ampak... (kje bi bili brez njih!)

Aplikacija še vedno manjka na seznamu menijev aplikacij in QuickLaunch. Mislim, da že vem, kako to popraviti. V upravitelju datotek premaknem QtQuickApp.hpkg iz ~/config/packages v /system/packages.

Ne, še vedno manjka. Očitno sem (no, in navodila) nekaj spregledal.

Ko sem pogledal zavihek "Vsebina" v HaikuDepot za nekatere druge aplikacije, sem videl, da obstajajo datoteke, kot /data/mimedb/application/x-vnd... kar je še bolj izjemno /data/deskbar/menu/Applications/….

No, kaj naj dam tja? daj no...

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

Prepričan sem, da bo ta trik deloval, ostajajo pa vprašanja: zakaj je to potrebno, čemu služi? Mislim, da to pokvari splošni vtis, da je sistem tako sofisticiran.

Kot je pojasnil g. waddlesplash:

Včasih obstajajo aplikacije, ki jih druge aplikacije potrebujejo, vendar jih ni v meniju. Na primer, LegacyPackageInstaller na vašem posnetku zaslona obdeluje arhive .pkg v formatu BeOS. Želel bi, da jih uporabniki namestijo, vendar bo njihova prisotnost v meniju povzročila zmedo.

Iz nekega razloga se mi zdi, da obstaja enostavnejša rešitev, npr Hidden=true v datotekah .desktop v sistemu Linux. Zakaj ne bi "skrite" informacije postale vir in atribut datotečnega sistema?

Še posebej ni subtilno ime (neke) aplikacije, ki prikazuje meni, deskbar, togo privezan na poti.

gospod. waddlesplash to pojasnjuje:

V tem primeru je treba »namizno vrstico« razumeti kot nekakšen splošen izraz (približno podobno kot »opravilna vrstica«, ki se nanaša tako na aplikacijo Windows kot na splošni koncept). No, od tega deskbar, ne »Deskbar«, lahko tudi to razumemo na podoben način.

2 "skoraj enaka" direktorija z aplikacijami v njih

Zakaj obstajata 2 imenika z aplikacijami in zakaj je moja aplikacija QtQuickApplication v enem, v drugem pa ne? (Saj to ni en sistemski, ampak drugi uporabniški, kar bi bilo meni osebno razumljivo).
Res sem zmeden in mislim, da bi bilo to treba poenotiti.

komentar g. waddlesplash

Katalog aplikacij vsebuje aplikacije, ki jih v meniju ne potrebujete. Toda stanje z menijem je res treba izboljšati, da bo bolj prilagodljiv.

Prijava, sicer se ne bo zgodilo 😉

Spraševal sem se: ali je res potrebno gostiti aplikacije v /system/apps, če jih uporabniki vidijo tam, je nezaželeno. Mogoče bi jih bilo bolje postaviti na drugo mesto, kjer jih uporabnik ne bo srečal? Tako kot je to storjeno v Mac OS X, kjer je vsebina paketov .app, ki naj ne bi bila vidna uporabniku v /Applications, ki se skriva v globinah /System/Library/…“`.

Kaj pa odvisnosti?

Mislim, da je vredno nekako določiti odvisnosti, kajne? Ali se Qt privzeto šteje za obvezen del namestitve Haiku? Ne! Qt ni privzeto nameščen. Ali lahko graditelj paketov samodejno zazna odvisnosti s preverjanjem datotek ELF? Povedali so mi, da HaikuPorter to dejansko počne, vendar package št. To je zato, ker je samo "graditelj paketov", ki sam ustvarja datoteke hpkg.

Ali naj postane Haiku bolj sofisticiran z dodajanjem pravilnika, da paket ne sme imeti odvisnosti od paketov zunaj Haikuja? haikuports? (Želel bi, ker bi takšna politika precej olajšala stvari – sistem bi bil sposoben samodejno razrešiti odvisnosti vsakega paketa, prenesenega od koder koli, brez zapletanja z dodatnimi viri paketov.)

gospod. waddlesplash pojasnjuje:

Ne bi radi toliko omejevali svobode razvijalcev, saj je očitno, da če CompanyX želi podpirati lasten nabor programske opreme z odvisnostmi (in s tem repozitorij), bo to počel popolnoma svobodno.

V tem primeru bi bilo morda vredno priporočiti, da se paketi tretjih oseb izognejo odvisnosti od česar koli, kar ni vključeno v haikuport, tako da popolnoma zapakirajo vse, kar je potrebno z aplikacijo. Ampak mislim, da je to tema za prihodnji članek v tej seriji. [Ali se avtor usmerja k AppImage? — pribl. prevajalec]

Dodajanje ikone aplikacije

Kaj pa, če želim virom svoje na novo ustvarjene aplikacije dodati eno od čednih vgrajenih ikon? Izkazalo se je, da je to neverjetna tema, zato bo osnova za naslednji članek.

Kako organizirati neprekinjene gradnje aplikacij?

Predstavljajte si projekt, kot je Inkscape (ja, vem, da še ni na voljo v Haikuju, vendar je priročno prikazati na njem). Imajo repozitorij izvorne kode https://gitlab.com/inkscape/inkscape.
Vsakič, ko nekdo objavi svoje spremembe v repozitoriju, se zaženejo gradbeni cevovodi, po katerih se spremembe samodejno testirajo, zgradijo in aplikacija zapakira v različne pakete, vključno z AppImage za Linux (samostojen paket aplikacij, ki ga je mogoče prenesti za lokalno testiranje ne glede na to). kaj je lahko ali ne sme biti nameščeno v sistemu [Vedel sem! — pribl. prevajalec]). Enako se zgodi z vsako zahtevo za združitev veje, tako da lahko pred združitvijo prenesete aplikacijo, zgrajeno iz kode, predlagane v zahtevi za združitev.

Zahteve za spajanje s statusi gradnje in zmožnostjo prenosa prevedenih binarnih datotek, če je sestavljanje uspešno (označeno z zeleno)

Zgradba teče v vsebnikih Docker. GitLab ponuja brezplačne izvajalce v Linuxu in mislim, da bi bilo mogoče vključiti svoje lastne izvajalce (mimogrede, ne vidim, kako bi to delovalo za sisteme, kot je Haiku, za katere vem, da nimajo Dockerja ali enakovrednega, vendar tudi za FreeBSD ni Dockerja, tako da ta težava ni edinstvena za Haiku).

V idealnem primeru je mogoče aplikacije Haiku zgraditi znotraj vsebnika Docker za Linux. V tej situaciji se lahko sklop za Haiku vnese v obstoječe cevovode. Ali obstajajo navzkrižni prevajalniki? Ali pa naj posnemam ves Haiku znotraj vsebnika Docker z uporabo nečesa podobnega QEMU/KVM (ob predpostavki, da bo tako deloval znotraj Dockerja)? Mimogrede, mnogi projekti uporabljajo podobna načela. To na primer počne Scribus – za Haiku je že na voljo. Nekega dne bo prišel dan, ko bom lahko poslal takih Potegnite zahteve drugim projektom, da dodate podporo za Haiku.

Eden od razvijalcev pojasnjuje:

Za druge projekte, ki želijo sami ustvariti pakete, je podprta običajna metoda CMake/CPack. Druge gradbene sisteme je mogoče podpreti z neposrednim klicem gradbenega programa paketa, kar je v redu, če ljudi to zanima. Izkušnje kažejo: do zdaj ni bilo velikega zanimanja, tako da je haikuporter deloval tako, kot nam je ustrezalo, a navsezadnje bi obe metodi morali delovati skupaj. Uvesti bi morali nabor orodij za navzkrižno gradnjo programske opreme iz Linuxa ali katerega koli drugega strežniškega operacijskega sistema (Haiku ni zasnovan za delovanje na strežnikih).

Stoje zaploskam. Redni uporabniki Linuxa nosijo vso to dodatno obremenitev in dodatno prtljago (varnost, strog nadzor itd.), ki je potrebna za strežniški operacijski sistem, ne pa tudi za osebnega. Zato se popolnoma strinjam, da je možnost izdelave aplikacij Haiku v Linuxu prava pot.

Zaključek

Prenos aplikacij POSIX na Haiku je možen, vendar je lahko dražji od običajne obnove. Zagotovo bi se s tem ukvarjal dolgo časa, če ne bi bilo pomoči ljudi s kanala #haiku v omrežju irc.freenode.net. Toda tudi oni niso vedno takoj videli, kaj je narobe.

Aplikacije, napisane v Qt, so preprosta izjema. Enostavno demo aplikacijo sem sestavil brez težav.

Gradnja paketa za preproste aplikacije je prav tako precej enostavna, vendar le za "tradicionalno izdane", tj. imeti arhive izvorne kode z različicami, namenjene podpori v haikuports. Za neprekinjeno gradnjo (gradnja za vsako objavo sprememb) z GitHubom se zdi, da vse ni tako preprosto. Tu je Haiku bolj podoben distribuciji Linuxa kot rezultatu v Macu, kjer, ko kliknete gumb »Build« v XCode, dobite paket .app, pripravljen za vstavljanje v sliko diska .dmg, pripravljen za prenos na moji spletni strani.
Nenehna izgradnja aplikacij, ki temeljijo na "strežniškem" operacijskem sistemu, na primer Linuxu, bo najverjetneje možna, če bo povpraševanje razvijalcev, trenutno pa ima projekt Haiku druge, bolj pereče naloge.

Poskusite sami! Navsezadnje projekt Haiku nudi ustvarjene slike za zagon z DVD-ja ali USB-ja vsak dan. Za namestitev preprosto prenesite sliko in jo zapišite na bliskovni pogon USB z uporabo Bakropisac

Imate vprašanja? Vabimo vas na rusko govoreče telegramski kanal.

Pregled napak: Kako se ustreliti v nogo v C in C++. Zbirka receptov Haiku OS

Od avtor prevod: to je peti članek v seriji o haikuju.

Seznam člankov: Prvič 2. Tretji Četrtič

Vir: www.habr.com

Moj peti dan s Haikujem: prenesimo nekaj programov