🥇Minu viies päev Haikuga: portime natuke rakendusi

TL;DR: Algaja nägi Haiku esmakordselt, proovib portida mõned programmid Linuxi maailmast.

Minu esimene Haiku jaoks portitud programm, pakitud selle hpkg formaati

Hiljuti avastasin Haiku, üllatavalt hea operatsioonisüsteem PC jaoks.
Täna kavatsen õppida, kuidas uusi programme sellele operatsioonisüsteemile portida. Peamine fookus on kirjeldada esimest kogemust Haiku-sse üleminekul arendaja vaatenurgast Linuxilt. Vabandan tobedate vigade eest, mis protsessi käigus on tehtud, sest sellest ajast, kui ma esmakordselt Haiku't käivitasin, pole möödunud isegi nädalat.

Soovin saavutada kolme eesmärki:

Portida lihtne CLI rakendus
Portida Qt-l põhinev GUI rakendus
Pakendada need seejärel hpkg formaati (kuna ma mõtlen AppDir ja AppImage kohandamisele Haiku jaoks…)

Alustame. Jaotistes dokumentatsioon ja arendus, samuti wiki HaikuPorts'ist leidsin õige suuna. Seal on isegi veebiraamat PDF BeOS: Unix rakenduse portimine.
467 lehekülge – ja see on alates 1997. aastast! Sisse vaatamine on hirmutav, kuid loodan parimat. Julgustavad arendaja sõnad: „pikk, sest BeOS ei olnud POSIX-i ühilduv”, kuid Haiku on „enamikul juhtudel” juba selline.

Lihtsa CLI rakenduse portimine

Esimene mõte oli portida rakendus avrdude, kuid nagu selgus, on see juba on teinud ammu.

Esimene katse: pole millelegi vaadata

Mida ma ei saa ühestki küljest aru, on see, et rakendusi on Haikule portitud juba üle 10 aasta — samas kui üldiselt pole operatsioonisüsteemi versiooni 1.0 isegi välja antud.

Teine katse: tuleb ümber kirjutada

Nii et ma kavatsen kasutada ptouch-770, CLI Brother P-Touch 770 printeri haldamiseks, millel ma trükin etikette.
Trükkin sellel erinevaid etikette ja olete seda võib-olla juba eelmine kord näinud. Veidi varem kirjutasin väikese GUI-ga Pythoniga sissekande (kuna see on Gtk+ pean selle ümber kirjutama, ja see on hea põhjus õppimiseks).

Brother P-Touch 770 etikettide printer. Kas see töötab Haiku all?

Haiku pakihaldur teab teeke ja käske, seega kui ma saan sõnumi „can’t find libintl” käivitamisel konfigureeri — käivitan lihtsalt pkgman install devel:libintl ja vajalik pakk leitakse. Samamoodi pkgman install cmd:rsync. Noh, jne.

Välja arvatud juhul, kui see ei tööta:

/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

Võib-olla on udev liiga Linuxi moodi, seega pole Haiku jaoks olemas. Mis tähendab, et pean muutma lähtekoodi, mille ma üritan kompileerida.
Ah, you can't jump higher than your head, and I don't even know where to start.

The third attempt

It would be nice to have tmate for Haiku, then I would allow Haiku developers to connect to my terminal session — just in case something goes wrong. The instructions are pretty straightforward:

./autogen.sh
./configure
make
make install

Looks good, so why not try it on 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

At this stage, I open HaikuDepot and search for curses.
Something was indeed found, which gave me a hint for a more accurate query:

/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

Again I went to HaikuDepot, and of course, I found devel:msgpack_c_cpp_devel. What strange names?

/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

At this stage, I realized that porting the program to Haiku requires significantly more knowledge than what's needed for a simple rebuild.
I talked to the friendly Haiku developers, and it turned out there’s a bug in msgpack, and within a few minutes I see a patch in HaikuPorts. I witness how the fixed package is being built here (buildslave — virtual machines).

Building the patched msgpack on buildmaster

In the meantime, I send the patch upstream to add Haiku support in msgpack.

Five minutes later, the updated msgpack is already available on 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.

Surprisingly good. Did I really say that?!

I return back to the original task:

/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

Now, it seems msgpack isn’t to blame. I comment out IMAXLABEL ja tty.c nii:

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

Tulemus:

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.

Well, here we go again… By the way:

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

mr. waddlesplash hints where to dig:

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

Here I posted config.log.

I was informed that there’s something else related to libresolv on Haiku in libnetwork. Apparently, I need to edit the code further. I need to think…

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

The eternal question: what is happening.

/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

The same, but for the profile. Googled and found this. If I add -lssp it sometimes helps, so I try:

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

Wow! It's starting! But…

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

I’ll try to debug, the file is here:

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

"Bad port ID" — now that’s something like a business card for Haiku.Maybe someone has an idea of what’s wrong and how to fix it? If so, I’ll update the article. Link to GitHub.

Porting a GUI application to Qt.

I choose a simple QML application.

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

Really simple. Less than a minute!

Packaging applications in hpkg using haikuporter and haikuports.

Where to start? There’s no straightforward documentation, I’m going to the #haiku channel on irc.freenode.net and hear:

Meeskond pakett — madal tasemel pakettide loomise viis. Enamasti piisab PackageInfo'st, nagu on kirjas jaotises "Tehes sellest korraliku .hpkg paketi"
Mul on vaja midagi teha sellist
Seda saab kasutada hpkg-creator (mul kukub alla, veateade)

Ei oska öelda, mida teha. Arvan, et mul on vaja algajatele mõeldud juhendit stiilis "Tere, maailm!", ideaalis – videot. Samuti oleks hea, kui saaksin mugava sissejuhatuse HaikuPorterisse, nagu on tehtud GNU hello's.

Lugesin järgmist:

haikuporter on tööriist, mis võimaldab luua üldprojektide pakette Haiku jaoks. See kasutab HaikuPorts'i hoidlat kõigi paketide alusena. Pakettide loomiseks kasutatakse haikuporteri retsepte.

Lisaks saan teada, et:

Ei ole vajalik hoida retsepte HaikuPorts'i hoidlas. Võib luua veel ühe hoidla, paigutada retseptid sinna ja seejärel suunata haikuporter sellele.

Just see, mida mul vaja on — kui mitte otsida viisi paketi avalikuks jagamiseks. Kuid see on teema teiseks postituseks.

haikuporteri ja haikuports'i installimine

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/ # tee see kõikjal käivitatavaks
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

Retsepti kirjutamine

SUMMARY="Demo QtQuick rakendus"
DESCRIPTION="QtQuickApp on näidis QtQuick rakendus Haiku portimise ja pakkimise testimiseks"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="Ei ole"
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
}

Retsepti koostamine

Salvestan faili nimega QtQuickApp-1.0.recipe, mille järel käivitan haikuporter -S ./QuickApp-1.0.recipe. Kontrollitakse sõltuvusi kõigi pakettide jaoks hoidlas haikuports, mis võtab aega. Lähen joon kohvi.

Miks peaks see kontroll toimuma minu kohalikus masinas, mitte keskelt ühe korra kõikide jaoks?

Vastavalt mr. waddlesplashile:

Sellisega, et võib kirjutada ümber ükskõik millise faili hoidlas 😉 Seda saab pisut optimeerida, arvutades vajaliku teabe siis, kui seda on vaja, kuna viimasel ajal tehtud muudatused on piisavalt haruldased.

~/QtQuickApp> haikuporter QtQuickApp-1.0.recipe
Kontrollin, kas mõni sõltuvuste info vajab uuendamist ...
Otsin aegunud sõltuvuste infosid ...
Viga: QtQuickApp ei leitud hoidlast

Selgub, et tavapärast retseptifaili, kus oleks teie rakenduse lähtekood, ei eksisteeri. Seda tuleb hoida HaikuPortsi hoidlas HaikuPorts formaadis.

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

See fakt muudab kogumise keerukamaks. Mulle see väga ei meeldi, kuid arvan, et see on vajalik, et lõpuks kõik avatud lähtekoodiga tarkvara jõuaks HaikuPortsisse.

Saan järgmise tulemuse:

~\/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe\nKontrollin, kas sõltuvuste teavet tuleb värskendada ...\n        värskendatakse QtQuickApp-1.0 sõltuvuste teavet\nOtsin aegunud sõltuvuste teavet ...\nViga: QtQuickApp-1.0.recipe ei leitud puust.

Mis on valesti? Pärast IRC-i lugemist teen:

~\/QtQuickApp> haikuporter -S QtQuickApp\nKontrollin, kas sõltuvuste teavet tuleb värskendada ...\n        värskendatakse QtQuickApp-1.0 sõltuvuste teavet\nOtsin aegunud sõltuvuste teavet ...\n----------------------------------------------------------------------\napp-misc::QtQuickApp-1.0\n        \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe\n----------------------------------------------------------------------Laen allalaadimist: https:\/\/github.com\/probonopd\/QtQuickApp.git ...\n--2019-07-14 16:12:44--  https:\/\/github.com\/probonopd\/QtQuickApp.git\nResolving github.com... 140.82.118.3\nConnecting to github.com|140.82.118.3|:443... connected.\nHTTP request sent, awaiting response... 301 Moved Permanently\nLocation: https:\/\/github.com\/probonopd\/QtQuickApp [following]\n--2019-07-14 16:12:45--  https:\/\/github.com\/probonopd\/QtQuickApp\nReusing existing connection to github.com:443.\nHTTP request sent, awaiting response... 200 OK\nLength: unspecified [text\/html]\nSaving to: ‘\/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git’\n     0K .                                                     1.34M=0.06s\n2019-07-14 16:12:45 (1.34 MB\/s) - ‘\/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git’ saved [90094]\nKontrollin QtQuickApp.git kontrollsummat\nHoiatus: ----- KONTROLLSUMMA TEMPLAAT -----\nHoiatus: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"\nHoiatus: -----------------------------\nViga: Retseptis ei leitud kontrollsummat!

Tekkis huvitav küsimus. Kui ma lisan kontrollsummat retsepti, kas see vastab viimasel git commitile pideva integratsiooni jaoks? (Arendaja kinnitab: „Midagi ei juhtu. Retseptid on disainitud üsna stabiilsete olema”).

Ühe nalja jaoks lisatakse retseptile:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

See ei rahulda mind ikka veel:

~\/QtQuickApp> haikuporter -S QtQuickApp\nKontrollin, kas sõltuvuste teavet tuleb värskendada ...\n        värskendatakse QtQuickApp-1.0 sõltuvuste teavet\nOtsin aegunud sõltuvuste teavet ...\n----------------------------------------------------------------------\napp-misc::QtQuickApp-1.0\n        \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe\n----------------------------------------------------------------------\nKipub allalaadimist QtQuickApp.git jooksul\nKontrollin QtQuickApp.git kontrollsummat\nLahtipakkimine QtQuickApp.git allika\nViga: Tuvastamata arhiivityyp failis \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git

Miks ta nii käitub? See on git-repositoorium, kood on juba seal otse, pole midagi lahti pakkida. Minu arvates peaks tööriist olema piisavalt intelligentne, et mitte otsida lahtipakkijat, kui tal on GitHubi url.

Võib-olla töötab uri git://

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

Nüüd kurdab see niimoodi:

Allalaadimine: git://github.com/probonopd/QtQuickApp.git ...
Viga: Allalaadimine ebatohututest allikatest on haikuports.conf'is keelatud!

Hmm, ja miks on kõik nii keeruline, miks ei saa "lihtsalt töötada"? Lõppkokkuvõttes pole sugugi haruldane midagi GitHubist kokku panna. Ega pole ju raske kasutada tööriistu, mis töötavad kohe, ilma seadistamiseta, või nagu ma seda nimetan, "töömahukalt".

Võib-olla töötab see niimoodi:

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

Ei, ikka saan selle kohutava vea ja teen seda, nagu siin on kirjas

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

Saan veidi edasi, aga miks see mind karjub (GitHub pole ju ohutu!) ja proovib ikka midagi lahti pakkida.

Vastavalt mr. waddlesplash:

Jah, põhjus oli soov kontrollida ehitamiseks saadud andmete terviklikkust. Üks võimalus on arhiivi kontrollsumma kontrollimine, aga muidugi saab ka eraldi faile hash'ida, mis ei tule kõne allagi, kuna see võtab oluliselt rohkem aega. Selle tagajärjeks on ka et "ebaturvalisus" git'i ja teiste VCSide puhul. Tõenäoliselt jääb see alati nii, kuna arhivi loomine GitHubis on piisavalt lihtne ja tihti kiiremini. Ja tulevikus, võib-olla ei ole vea teade enam nii karjuv... (me ei tee enam selliste retseptide ühendamisi HaikuPortsis).

~QtQuickApp> haikuporter -S QtQuickApp
Kontrollin, kas mingeid sõltuvuste teavet tuleb uuendada ...
Otsin vananenud sõltuvuste teavet ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Allalaadimine: git+https://github.com/probonopd/QtQuickApp.git ...
Hoiatus: EBATOHUTUD ALLIKAD ON KOHUTAVAD JA EI TOHIKS KASUTUSES OLLA
Hoiatus: PALUN LIIGUGE KIIRESTI STATIC ARHIIVI ALLALAADIMISELE KONTROLLSUMMA KAASTAMISEGA!
Kloonimine paljas repositooriumisse '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Lahtipakkimine QtQuickApp.git allikast
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Ei saa avada: Sellist faili või katalooge ei ole
 tar: Viga ei ole taastatav: lahkumine nüüd
Käsk 'git archive HEAD | tar -x -C "'/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0'"' ebaõnnestus väljundi staatusega 2

Vanast harjumusest lähen küsima häid inimesi kanalil #haiku irc.freenode.net. Ja kuhu ma ilma nendeta läheksin? Pärast vihjet sain aru, et pean kasutama:

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

On selge, mida see teeb — laadib alla arhiivi teatud revisjoni lähtekoodidest. Minu arvates on see rumal ja mitte just see, mida ma tahtsin, nimelt — laadida alla viimane revisjon master-haru.

Üks arendajatest selgitas seda nii:

Meil on oma CI, nii et kõik, mis paigutatakse haikuportsi ladudesse, pakitakse kokku kõigile kasutajatele, aga me ei soovi riskida, et koguda ja edastada "kõik viimase versiooni upstream'.

Sain aru! Igatahes on selline olukord:

ootab paketi QtQuickApp-1.0-1 aktiveerimist
ootab paketi QtQuickApp-1.0-1 aktiveerimist
ootab paketi QtQuickApp-1.0-1 aktiveerimist
ootab paketi QtQuickApp-1.0-1 aktiveerimist
ootab paketi QtQuickApp-1.0-1 aktiveerimist
(...)

See kordab seda lõputult. Tundub, et see on viga (kas on tehtud avaldust? Ma ei leidnud).

A haikuporter ja hoidla haikuports Ei tunneta taset "lihtsalt töötab", kuid arendajana meeldib mulle mõned asjad Haiku tööprotsessis. Suuresti sarnaneb see Open Build Service'iga — tööriistade kogum Linuxi kogumike loomiseks: äärmiselt võimas, süsteemne lähenemine, kuid liigsete nõudmistega minu väikese "hello world" taseme rakenduse jaoks.

Jälle, mr. waddlesplash'i sõnul:

Tõepoolest, HaikuPorter on vaikimisi üsna range (pluss on lint-režiim ja rangem režiim, mis teeb selle veelgi rangemaks!), kuid ainult seetõttu, et see loob pakette, mis töötavad, mitte lihtsalt pakette. Seetõttu peetakse peediks teavitatud sõltuvusi, valesti imporditud teeke, valeversioone jne. Eesmärk on tabada kõik võimalikud probleemid, sealhulgas tulevased, enne, kui kasutaja sellest kuuleb (seetõttu ei saanud avrdude't installida, kuna retseptis oli tegelikult märgitud sõltuvus). Teegid ei ole lihtsalt eraldi paketid ega isegi määratud SO versioonid. HaikuPorter jälgib selle nõuete täitmist retseptide endi kaudu, et vältida käitamisvigu.

Põhimõtteliselt on selline ranguse tase õigustatud operatsioonisüsteemi loomisel, kuid mulle tundub see liialt karm „hello world“ rakenduse jaoks. Otsustasin proovida midagi muud.

Rakenduste kogumine hpkg formaadis, kasutades käsku "package create"

Võib-olla, see lihtne juhend sobib mulle paremini?

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# Vaata allpool, kui soovid, et rakenduse
# ilmuks ka menüüsse

Ükski asja pole olnud nii kiire, lihtne ja efektiivne. Just nii, nagu mulle meeldib, imelises!

Installatsioon — mis ja kuhu?

Liigutasin faili QtQuickApp.hpkg kausta ~ /config/packages, kasutades failihaldurit, mille järel QtQuickApp ilmus maagiliselt kausta ~ /config/apps.
Taaskord üllatavalt kiiresti, lihtsalt ja efektiivselt. Imeline, uskumatu!

Aga… (kuhu ilma nendeta!)

Rakendus puudub jätkuvalt rakenduste menüüst ja QuickLaunchist. Arvan, et tean, kuidas seda lahendada. Failihalduris liigutan QtQuickApp.hpkg kaustast ~ /config/packages kausta /system/packages.

Ei, ikka pole. Tundub, et ma (noh, ja juhend) jätsin midagi tähelepanuta.

Uurides mõne teise rakenduse „Contents“ vahekaarti HaikuDepotis, nägin, et seal on selliseid faile /data/mimedb/application/x-vnd... mida veel tähelepanuväärsem, /data/deskbar/menu/Applications/….

Noh, mida ma sinna panen? Ootan...

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

Olen üsna kindel, et see trikk töötab, kuid küsimused jäävad: miks ja milleks seda vaja on? Minu arvates rikub see üldist muljet, et süsteem on nii rafineeritud.

Kuna mr. waddlesplash selgitas:

Mõnikord on rakendusi, mida teised rakendused vajavad, kuid mitte menüüs. Näiteks LegacyPackageInstaller teie ekraanipildil, mis töötleb .pkg arhiive BeOS-is. Tahan, et kasutajad saaksid need installida, kuid nende kohalolek menüüs tekitab segadust.

Kuid arvan, et on lihtsam lahendus, näiteks Hidden=true failides .desktop Linuxis. Miks mitte teha „peidetud“ teave ressursiks ja failisüsteemi atribuudiks?

Eriti mitte rafineeritud on rakenduse (mingi) nimi, mis näitab menüüd, deskbar, fikseeritud teele.

Mr. waddlesplash selgitab sellega seoses:

„Deskbar“ tähendab sel juhul üldist terminit (umbes nagu „taskbar“, mis viitab nii Windowsi rakendusele kui ka üldisele kontseptsioonile). Ja kuna see deskbar, mitte „Deskbar“, võib seda tõlgendada sarnasel viisil.

2 „peaaegu identset“ katalooge rakendustest neis

Miks on kaks rakenduste katalooge ja miks ühes neist on minu QtQuickApplication, teises aga mitte? (Sest see ei ole üks süsteemne, vaid teine kasutaja, mis mulle isiklikult oleks arusaadav).
Olen tõeliselt segaduses ja arvan, et peaksime selle standardiseerima.

kommentaar mr. waddlesplash

Rakenduste kataloogis on rakendusi, mis pole menüüs vajalikud. Menüü olukorda peab tõepoolest parandama, tehes selle kohandatavaks.

Taotlus, või seda ei juhtu 😉

Mõtlesin, et kas on tõesti vajalik rakendusi paikneda /system/apps, kui kasutajad ei peaks neid seal nägema — kas poleks parem paigutada need teise kohta, kus kasutaja nendega ei kohtu? Nii nagu Mac OS X-is, kus pakettide sisu .app, mida ei tohiks kasutajale näidata, peidetakse sügavale /System/Library/…«`. /ApplicationsMis saab sõltuvustest?

Arvan, et sõltuvustega tuleks kuidagi viidata, eks? Kas Qt saab pidada Haiku vaikimisi installatsiooni kohustuslikuks osaks? Ei! Qt ei ole vaikimisi installitud. Kas paketi kogumise programm saab sõltuvusi automaatselt määrata, kontrollides ELF-faile? Mulle öeldi, et HaikuPorter teeb seda tõepoolest, kuid

ei. Kõik kuna ta on lihtsalt "paketi koostaja", mis iseenesest loob faile pakett hpkg Kas tasuks teha Haiku rafineeritumaks, lisades reegli, et paketil ei tohiks olla sõltuvusi pakettidest, mis ei kuulu.

mr. waddlesplash selgitab: haikuports? (Мне бы так хотелось, поскольку подобная политика значительно облегчает задачу — система смогла бы автоматически разрешить зависимости каждого пакета, загружаемого откуда угодно, без возни с дополнительными источниками пакетов).

Me ei soovi piirata arendajate vabadust nii palju, sest on ilmne, et kui EttevõteX soovib toetada oma tarkvarapaketti sõltuvustega (ja seega ka hoidlat) — saavad nad seda täiesti vabalt teha.

Sellisel juhul tasuks võib-olla soovitada vältida kolmandate osapoolte pakette, millel on sõltuvusi millestki, mis ei kuulu haikuports'i, paketiga täielikult koos kõigega, mis on vajalik. Aga arvan, et see on teema tulevase artikli jaoks selles sarjas.

[Autor viitab AppImage'ile? — tõlkija märk.] Rakenduse ikoni lisamine

Aga mis siis, kui soovin lisada oma värskelt loodud rakendusele ühte nende nägusatest sisseehitatud ikoonidest? Tundub, et see on üllatav teema, nii et see saab olema järgmise artikli keskmes.

Kuidas korraldada pidevat rakenduste kogumist?

Kuidas korraldada rakenduste pidevat kogu?

Kujutage ette projekti, nagu Inkscape (jah, ma tean, et seda pole veel Haikus, kuid sellel on mugav demonstreerida). Neil on allika koodide hoidla. https://gitlab.com/inkscape/inkscape.
Iga kord, kui keegi fikseerib oma muudatused hoidlas, käivitatakse ehitusprotsessid, pärast mida muudetud kood testitakse automaatselt, ehitatakse ja rakendus pakitakse erinevatesse pakettidesse, sealhulgas AppImage Linuxi jaoks (oodav rakenduse pakett, mida saab laadida kohaliku testimise jaoks, sõltumata sellest, mis võib või ei pruugi süsteemis olla paigaldatud). [ma lihtsalt teadsin! — tõlkija märkus]). Samamoodi toimub see iga haru ühinemise päringu korral, nii et saad rakenduse alla laadida, mis on ehitatud koodist, mis on esitatud ühinemise päringus, veel enne ühinemist.

Ühinemise päringud koos ehituste staatusetega ja võimalusega alla laadida koostatud binaarid juhul, kui ehitus on edukas (margitud rohelisega).

Ehitus käivitub Docker'i konteinerites. GitLab pakub tasuta jooksjaid Linuxile, lisaks arvan, et on võimalik ühendada ka enda jooksjad (muide, ma ei kujuta ette, kuidas see töötaks süsteemides nagu Haiku, mis, nagu ma tean, ei omada Dockerit või analooge, kuid FreeBSD jaoks pole samuti Dockerit, nii et see probleem pole Haiku jaoks ainulaadne).

Ideaalis saaks rakenduste ehitamine Haiku jaoks toimuda Linuxi Docker'i konteineris. Sellisel juhul saaks Haiku ehitamise integreerida olemasolevatesse torustikesse. Kas on olemas ristkompileerijaid? Või pean kogu Haiku emuleerima Docker'i konteineris, kasutades midagi nagu QEMU/KVM (eeldusel, et see toimib seal Dockeris)? Muide, paljud projektid kasutavad sarnaseid põhimõtteid. Näiteks Scribus teeb seda — see on juba saadaval Haiku jaoks. Koitma peab päev, mil ma saan saata selliseid ühinemise päringud teistesse projektidesse, et lisada neisse Haiku toetus.

Üks arendajatest selgitab:

Teistele projektidele, mis soovivad pakette iseseisvalt luua, toetatakse tavalist CMake/CPack meetodit. Teised koostesüsteemid võivad olla toetatud, kui paketi koostamise programmi otse käivitada, mis on hea, kui inimesed on sellest huvitatud. Kogemus näitab: siiani pole erilist huvi olnud, nii et haikuporter on töötanud meie mugavuse järgi, kuid lõpuks peaksid mõlemad meetodid omavahel koos töötama. Me peaksime esitama tööriistade komplekti tarkvara ristkoostamiseks Linuxist või mis tahes muust serveri operatsioonisüsteemist (Haiku ei ole mõeldud serverites töötamiseks).

Seisan aplodeerides. Tavalised Linuxi kasutajad kannavad kogu selle lisakoormuse ja täiendava pagasi (turvalisus, range kontroll jne), mis on vajalik serveri operatsioonisüsteemile, kuid mitte isiklikule. Seetõttu olen täiesti nõus, et võimalus luua rakendusi Haiku jaoks Linuxis — see on õige tee.

Kokkuvõte

POSIX rakenduste portimine Haikusse on võimalik, kuid see võib nõuda rohkem ressursse kui tavaline ümberkompileerimine. Ma tooksin sellest tõenäoliselt pikaks ajaks kinni, kui mitte inimeste abi kanalist #haiku irc.freenode.net. Kuid isegi nemad ei näinud alati kohe, mis valesti on.

Rakendused, mis on kirjutatud Qt-s, on kerge erand. Koostasime kõige lihtsama näidiserakenduse ilma eriliste probleemideta.

Paketi koostamine lihtsate rakenduste jaoks on samuti piisavalt lihtne, kuid ainult 'traditsiooniliselt välja antud' jaoks, st versioonitud allikaarhiivide jaoks, mis on mõeldud haikuports'i toetamiseks. Jätkuva koostamise (koostamine igale muutuste kinnitusele) korral GitHubis ei tundu kõik nii lihtne. Siin Haiku sarnaneb rohkem Linuxi jaotusele kui tulemusele MAcis, kus XCode'is nupule 'Koosta' vajutades saab paketi .app, mis on valmis ketta kujutisse panemiseks .dmg, laadimiseks minu veebisaidile.
Jätkuv rakenduste koostamine põhineva 'serveri' operatsioonisüsteemi, näiteks Linuxi, alusel, on tõenäoliselt võimalik, kui arendajatelt on nõudlust, kuid hetkel on Haiku projektil teised, tähtsamad ülesanded.

Proovige ise! Lõppude lõpuks pakub Haiku projekt allalaetavaid pilte DVD-le või USB-le, mis on loodud iga päev. Paigaldamiseks piisab pildi allalaadimisest ja selle kirjutamisest mälupulgale, kasutades Etcher

Kas teil on küsimusi? Kutsume teid venekeelsesse telegrami kanalisse.

Vigade ülevaade: Kuidas end C ja C++-ga jalga lasta. Haiku OS retseptide kogu

Alates autor Tõlke osas: see on viies artikkel Haiku tsüklist.

Artiklite nimekiri: Esimene Teine Kolmas Neljas

Allikas: habr.com