🥇Min femte dag med Haiku: lad os portere lidt programmer

TL;DR: Nybegynderen så Haiku for første gang og prøver at portere nogle programmer fra Linux-verdenen.

Mit første portede program til Haiku, pakket i dens hpkg format.

For nylig Jeg har opdaget Haiku, et overraskende godt operativsystem til pc.
I dag vil jeg lære at portere nye programmer til dette operativsystem. Hovedfokus er beskrivelsen af den første oplevelse med at skifte til Haiku set fra en udviklers synspunkt for Linux. Jeg undskylder for de dumme fejl, der blev begået i processen, da der ikke er gået mere end en uge siden jeg første gang bootede Haiku.

Jeg har tre mål, jeg gerne vil nå:

At portere en simpel CLI-applikation.
At portere en GUI-applikation med Qt.
At pakke dem i hpkg format (da jeg stadig overvejer tilpasningen af AppDir og AppImage til Haiku ...)

Lad os komme i gang. I sektionerne dokumentation og udvikling, samt i wiki fra HaikuPorts fandt jeg den nødvendige retning. Der er endda en online PDF-bog. BeOS: Portering af Unix-applikationer..
467 sider – og det er siden 1997! Det ser skræmmende ud at dykke ind, men jeg håber på det bedste. Beroligende ord fra udvikleren: "Det tager lang tid, fordi BeOS ikke var POSIX-kompatibel", men Haiku er "i det store og hele" allerede det.

Portering af en simpel CLI-applikation.

Den første tanke var at portere applikationen cli). Det må åbenbart være et flueben, der viser CLI-applikationer i HaikuDepot-interfacet, men jeg fandt det ikke, eller også eksisterer det ikke. ("Anbefalede" eller "Alle pakker"... ønsker du det? Nej, jeg vil ikke se "alle" pakker, jeg antager, der vises mange biblioteker. Noget som det gode gamle, men som det viste sig, så er det allerede world-executable, hvilket gør det muligt at køre denne container uden behov for root-rettigheder. Desuden har migration containeren for etcd for længe siden.

Første forsøg: der er ikke noget at kigge på.

Det, jeg ikke kan forstå, er, at applikationer allerede er blevet porteret til Haiku i over 10 år. — selvom operativsystemet endnu ikke har version 1.0. Andet forsøg: det skal skrives om.

Så jeg vil bruge

ptouch-770 , CLI til at styre Brother P-Touch 770 printeren, hvor jeg printer etiketter.Jeg printer forskellige etiketter på den, og du har måske allerede set den i den tidligere artikel. Tidligere skrev jeg et lille wrapper-program med GUI i Python (da det er på Gtk+ — jeg skal omskrive det, hvilket er en god mulighed for at lære).
Brother P-Touch 770 etiket printer. Vil den fungere under Haiku?

Haiku's pakkehåndtering er klar over biblioteker og kommandoer, så hvis jeg får besked om "kan ikke finde libintl" ved opstart

— så kører jeg bare configure pkgman install devel:libintl og den nødvendige pakke vil blive fundet. Ligesom pkgman install cmd:rsync. . Nå ja, og så videre.Undtagen når det ikke virker:

Måske er udev for linuksagtig, så den findes ikke til Haiku. Hvilket betyder, at der er behov for at ændre kildekoden, som jeg prøver at kompilere.

/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

Suk, man kan ikke springe højere end ens hoved, og jeg ved endda ikke, hvor jeg skal begynde.
Det ville være godt at have.

Tredje forsøg

Det ville være rart at have tmate til Haiku, så ville jeg have tilladt Haiku-udviklerne at tilslutte sig min terminalsession - i tilfælde af at noget gik galt. Instruktionerne er ret enkle:

.\/autogen.sh
.\/configure
make
make install

Det ser godt ud, så hvorfor ikke prøve det på 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

På dette trin åbner jeg HaikuDepot og søger curses.
Der blev faktisk fundet noget, som gav mig et hint til en bedre forespørgsel:

/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

Gik igen ind i HaikuDepot, og selvfølgelig fandt jeg devel:msgpack_c_cpp_devel. Hvad er det for nogle mærkelige navne?

/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

På dette trin indså jeg, at porteringen af programmet til Haiku kræver betydeligt mere viden, end hvad der er nødvendigt for en simpel genkompilering.
Jeg talte med de venlige Haiku-udviklere, og det viste sig, at der var en fejl i msgpack, og efter få minutter ser jeg patchen i HaikuPorts. Jeg ser, hvordan den rettede pakke bliver bygget her (buildslave - virtuelle maskiner).

Bygningen af den rettede msgpack på buildmaster

I mellemtiden sender jeg patchen videre til upstream for at tilføje support til Haiku i msgpack.

Fem minutter senere er den opdaterede msgpack allerede tilgængelig i 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.

Overraskende godt. Sagde jeg det?!

Jeg vender tilbage til den oprindelige opgave:

/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

Det ser nu ud til, at msgpack ikke er skyld i det. Jeg kommenterer IMAXLABEL i tty.c sådan ud:

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

Resultat:

osdep-unknown.c: I funktionen '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.

Nå ja, igen… For resten:

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

mr. waddlesplash peger på, hvor jeg skal lede:

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

Her har jeg uploadet config.log.

Jeg fik at vide, at der er noget til libresolv på Haiku i libnetwork. Tilsyneladende skal koden rettes yderligere. Jeg må tænke lidt...

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

Det evige spørgsmål: hvad sker der egentlig.

/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

Det samme, bare i profilen. Jeg googlede og fandt dette. Hvis jeg tilføjer -lssp hjælper det "nogle gange", så jeg prøver:

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

Wow! Det starter! Men…

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

Jeg prøver at debugge, filen ligger her:

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

"Bad port ID" - det er allerede som et visitkort haiku.Måske er der nogen, der kan forstå, hvad der er galt, og hvordan man ordner det? Hvis noget ændrer sig, vil jeg opdatere artiklen. Link til GitHub.

Portering af GUI-applikation på Qt.

Jeg vælger en simpel QML-applikation.

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

Rigtig simpel. Mindre end et minut!

Pakning af applikationer i hpkg ved hjælp af haikuporter og haikuports.

Hvor skal jeg starte? Der er ikke nogen simpel dokumentation, jeg går til kanalen #haiku på irc.freenode.net og hører:

Kommandoen pakke — en lavniveau måde at oprette pakker på. Det kræver mest PackageInfo, som beskrevet i afsnittet "Making it into a proper .hpkg package"
Jeg skal gøre noget sådan
Kan bruges hpkg-creator (jeg får et nedbrud, fejlrapport)

Jeg ved ikke, hvad jeg skal gøre. Jeg tror, jeg har brug for en nybegynderguide i stil med "Hello World!", helst en video. Det ville også være godt at have en brugervenlig introduktion til HaikuPorter, sådan som det er lavet i GNU hello.

Jeg læser følgende:

haikuporter er et værktøj til at oprette generelle pakkebaserede projekter til Haiku. Det bruger HaikuPorts-repositoriet som fundament for alle pakker. Opskrifterne til pakkerne laves med haikuporter.

Jeg finder yderligere ud af, at:

Der er ikke behov for at holde opskrifterne i HaikuPorts-opbevaringen. Man kan lave et andet repository, placere opskrifterne dér, hvorefter man angiver haikuporter til dette.

Lige hvad jeg har brug for — medmindre jeg leder efter en måde at offentliggøre pakken på. Men det er emnet for et andet indlæg.

Installation af haikuporter og haikuports

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/ # gør det kørbart fra hvor som helst
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

Skriv opskrift

SUMMARY="Demo QtQuick-applikation"
DESCRIPTION="QtQuickApp er en demo QtQuick-applikation til test af Haiku-porting og pakkehåndtering"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="Ingen"
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
}

Kompilering af opskrift

Jeg gemmer filen som QtQuickApp-1.0.recipe, hvorefter jeg kører haikuporter -S ./QuickApp-1.0.recipe. Afhængighederne for alle pakker i repositoryet haikuports, som tager lidt tid. Jeg smutter lige en tur for at drikke kaffe.

Og hvorfor skal denne kontrol udføres på min lokale maskine og ikke centraliseret på serveren én gang for alle?

Ifølge hr. waddlesplash:

Fordi man kan overskrive enhver fil i repositoryet 😉 Man kan optimere dette lidt ved at beregne de nødvendige oplysninger, når det er nødvendigt, da de seneste ændringer er ret sjældne.

~/QtQuickApp> haikuporter QtQuickApp-1.0.recipe
Tjekker om der er nødvendige opdateringer af afhængighedsinformationer ...
Leder efter forældede afhængighedsinformationer ...
Fejl: QtQuickApp blev ikke fundet i repositoryet

Det viser sig, at der ikke findes en almindelig opskriftsfil, der indeholder kildekoden til din applikation. Den skal holdes i repositoryet i HaikuPorts-format.

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

Denne kendsgerning gør samlingen mere besværlig. Jeg er ikke særlig glad for det, men jeg tror, det er nødvendigt for at sikre, at al open source software til sidst kommer til HaikuPorts.

Jeg får følgende:

~\/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe
Kontrollerer, om der er behov for at opdatere afhængighedsoplysninger ...
        opdaterer afhængighedsoplysninger for QtQuickApp-1.0
Leder efter forældede afhængighedsoplysninger ...
Fejl: QtQuickApp-1.0.recipe ikke fundet i træet.

Hvad er galt? Efter at have læst irc, gør jeg:

~\/QtQuickApp> haikuporter -S QtQuickApp
Kontrollerer, om der er behov for at opdatere afhængighedsoplysninger ...
        opdaterer afhængighedsoplysninger for QtQuickApp-1.0
Leder efter forældede afhængighedsoplysninger ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Henter: https:\/\/github.com\/probonopd\/QtQuickApp.git ...
--2019-07-14 16:12:44--  https:\/\/github.com\/probonopd\/QtQuickApp.git
Opløser github.com... 140.82.118.3
Forbinder til github.com|140.82.118.3|:443... forbundet.
HTTP-anmodning sendt, afventer svar... 301 Flyttet permanent
Placering: https:\/\/github.com\/probonopd\/QtQuickApp [følger]
--2019-07-14 16:12:45--  https:\/\/github.com\/probonopd\/QtQuickApp
Genbruger eksisterende forbindelse til github.com:443.
HTTP-anmodning sendt, afventer svar... 200 OK
Længde: uspecificeret [text\/html]
Gemmer til: ‘\/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’ gemt [90094]
Validerer checksum for QtQuickApp.git
Advarsel: ----- CHECKSUM TEMPLAT -----
Advarsel: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Advarsel: -----------------------------
Fejl: Ingen checksum fundet i opskriften!

Der opstod et interessant spørgsmål. Hvis jeg tilføjer en checksum til opskriften — vil den matche den seneste git commit til kontinuerlig integration? (Udvikleren bekræfter: "Der vil ikke komme noget ud af det. Opskrifter er designet til at være relativt stabile").

Som en spøg tilføjer de til opskriften:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Det er stadig ikke tilfredsstillende:

~\/QtQuickApp> haikuporter -S QtQuickApp
Kontrollerer, om der er behov for at opdatere afhængighedsoplysninger ...
        opdaterer afhængighedsoplysninger for QtQuickApp-1.0
Leder efter forældede afhængighedsoplysninger ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe
----------------------------------------------------------------------
Springer over download af kilde for QtQuickApp.git
Validerer checksum for QtQuickApp.git
Udpakker kilde af QtQuickApp.git
Fejl: Ugenkendt arkivtype i fil \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git

Hvad sker der? Det er jo et git-repositorium, koden er allerede der direkte, der er ikke noget at udpakke. Efter min mening skal værktøjet være smart nok til ikke at lede efter en udpakkingsprogram, hvis det er en URL fra GitHub.

Måske fungerer uri git:\/\/

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

Nu klager den således:

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

Hmm, og hvorfor er alt så kompliceret, hvorfor kan man ikke "bare arbejde"? I sidste ende er det ikke så sjældent, at man kan samle noget fra GitHub. Gad vidst om værktøjer, der fungerer straks, uden behov for opsætning, eller hvad jeg kalder "besvær".

Måske vil det fungere sådan her:

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

Nej, jeg får stadig denne mærkelige fejl, og jeg gør det, som beskrevet her

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

Jeg kommer lidt længere, men hvorfor skriger det på mig (GitHub er ikke sikkert!) og forsøger stadig at pakke noget ud.

Ifølge mr. waddlesplash:

Ja, grunden er ønsket om at kontrollere integriteten af de data, der modtages til bygning. En mulighed er at tjekke kontrolsummen af arkivet, men man kan selvfølgelig også hashe enkelte filer, hvilket ikke vil blive implementeret, da det tager meget længere tid. Dette er også konsekvensen af den "usikkerhed", som git og andre VCS medfører. Det vil sandsynligvis altid være sådan, da det er relativt nemt at oprette et arkiv på GitHub og ofte hurtigere. Og i fremtiden, måske vil fejlmeldingen ikke være så skrigende... (vi laver ikke længere sammenslutninger af sådanne opskrifter i HaikuPorts).

~/QtQuickApp> haikuporter -S QtQuickApp
Tjekker, om nogle af afhængighedsinformationerne skal opdateres ...
Søger efter forældede afhængighedsinformationer ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Downloader: git+https://github.com/probonopd/QtQuickApp.git ...
Advarsel: UNSAFE SOURCES ER DÅRLIGE OG BØR IKKE BRUGES I PRODUKTION
Advarsel: FLYT VENLIGST TIL EN STATISK ARKIVDOWNLADNING MED CHECKSUM HURTIGST MULIGT!
Kloner ind i bare repository '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Pakker kilden til QtQuickApp.git
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Kan ikke åbne: Ingen sådan fil eller mappe
tar: Fejl er ikke genoprettelig: stopper nu
Kommando 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' returnerede exit-status 2

Af gammel vane går jeg for at spørge gode mennesker på #haiku-kanalen i netværket irc.freenode.net. Og hvor ville jeg være uden dem? Efter et tip indså jeg, at jeg skulle bruge:

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

Okay, nu blev det klart, hvad det gør — downloader et arkiv med kilden til en specifik revision. Dumt, efter min mening, og ikke helt hvad jeg ønskede, nemlig at downloade den nyeste revision fra master-grenen.

En af udviklerne forklarede det således:

Vi har vores eget CI, så alt hvad der lægges i haikuports-repositoriet, vil blive pakket til alle brugere, og vi ønsker ikke at tage risikoen ved at samle og levere 'alle de nyeste versioner fra upstream'.

Forstået! Under alle omstændigheder er resultatet blevet sådan her:

venter på at bygge pakken QtQuickApp-1.0-1 aktiveres
venter på at bygge pakken QtQuickApp-1.0-1 aktiveres
venter på at bygge pakken QtQuickApp-1.0-1 aktiveres
venter på at bygge pakken QtQuickApp-1.0-1 aktiveres
venter på at bygge pakken QtQuickApp-1.0-1 aktiveres
(...)

Det gentager sig således ubegribeligt. Det må åbenbart være en fejl (er der en bug-rapport? Jeg fandt ikke nogen).

Med haikuporter and the repository haikuports Det føles ikke som et niveau, hvor det 'bare virker', men som udvikler kan jeg godt lide visse ting ved at arbejde med Haiku. Det ligner i høj grad Open Build Service — et værktøjssæt til at bygge Linux-udgivelser: ekstremt kraftfuldt, med en systematisk tilgang, men måske for meget til min lille 'hello world'-applikation.

Igen, ifølge mr. waddlesplash:

Faktisk er HaikuPorter ret striks som standard (plus der er en lint-tilstand samt en striks tilstand, der gør det endnu mere stringent!), men det er kun fordi, at det skaber pakker, der rent faktisk virker, og ikke blot laver pakker. Derfor skælder det ud over udeblevne afhængigheder, forkert importerede biblioteker, forkerte versioner osv. Målet er at fange alle problemer uden undtagelse, inklusive fremtidige, før brugeren opdager dem (derfor kunne avrdude ikke installeres, da afhængigheden faktisk var angivet i opskriften). Biblioteker er ikke blot separate pakker og ikke engang specifikke versioner af SO. HaikuPorter holder øje med overholdelse af alt dette i selve opskrifterne for at undgå køretidsfejl.

Generelt er et sådant striks niveau berettiget ved oprettelsen af et operativsystem, men jeg synes, det er for meget til en 'hello world'-applikation. Jeg besluttede at prøve noget andet.

Bygge applikationer i hpkg-format ved hjælp af kommandoen 'package create'

Måske, denne ville en enkel vejledning passe mig bedre?

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

summary "Demo QtQuick-applikation"
description "QtQuickApp er en demo QtQuick-applikation til test af Haiku portering og pakker"

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# Se nedenfor, hvis du også vil have applikationen
# til at vises i menuen

Overraskende hurtigt, overraskende nemt, overraskende effektivt. Lige som jeg kan lide det, fantastisk!

Installation — hvad og hvor?

Jeg har flyttet filen QtQuickApp.hpkg til ~/config/packages, ved at bruge filhåndtereren, hvorefter QtQuickApp magisk dukkede op i ~/config/apps.
Igen overraskende hurtigt, nemt og effektivt. Fantastisk, utrolig!

Men… (hvad ville vi gøre uden dem!)

Appen mangler stadig i app-menuen og i QuickLaunch. Jeg tror, jeg ved, hvordan jeg kan fixe det. I filhåndtereren flytter jeg QtQuickApp.hpkg fra ~/config/packages til /system/packages.

Nej, den mangler stadig. Tilsyneladende har jeg (nå, og instruktionen) overset noget.

Ved at kigge på 'Contents'-fanen i HaikuDepot for nogle andre apps så jeg, at der er filer af typen /data/mimedb/application/x-vnd... hvad der er endnu mere bemærkelsesværdigt, /data/deskbar/menu/Applications/….

Nå, hvad skal jeg putte derind? Lad os se...

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

Jeg er ret sikker på, at dette trick vil fungere, men der er stadig spørgsmål: hvorfor er dette nødvendigt, hvad er formålet med det? Jeg synes, det ødelægger den generelle oplevelse af, at systemet er så raffineret.

Som mr. waddlesplash forklarede:

Nogle gange er der apps, som andre apps har brug for, men som ikke skal være i menuen. For eksempel, LegacyPackageInstaller på dit screenshot, der håndterer .pkg-arkiver i BeOS-format. Man ønsker, at brugerne skal installere dem, men deres tilstedeværelse i menuen vil føre til forvirring.

Jeg får underligt nok fornemmelsen af, at der findes en enklere løsning, som f.eks. Hidden=true i filerne .desktop på Linux. Hvorfor ikke gøre 'skjult' information til en ressource og et attribut i filsystemet?

Det er særligt ikke raffineret — navnet (af en vis) app, der viser menuen, deskbar, er hårdt bundet i stien.

mr. waddlesplash kommenterer dette:

‘Deskbar’ skal her forstås som et generelt udtryk (ligesom ‘taskbar’, der refererer til både et Windows-program og en generel konzeption). Og da det er deskbar, og ikke ‘Deskbar’, kan det også forstås på en lignende måde.

2 ‘næsten identiske’ kataloger med apps i dem

Hvorfor er der 2 kataloger med apps, og hvorfor er min QtQuickApplication i den ene, men ikke i den anden? (Da den ikke kun er systemets, men også en brugerkatalog, hvilket ville give mening for mig).
Jeg er virkelig forvirret og tænker, at det bør standardiseres.

kommentar fra mr. waddlesplash

I kataloget Apps findes der applikationer, der ikke er nødvendige i menuen. Men situationen med menuen skal faktisk forbedres, så den bliver mere tilpasselig.

Ansøgningen, eller det sker ikke 😉

Jeg har tænkt: er det virkelig nødvendigt at placere applikationer i /system/apps, hvis brugerne ikke ønsker at se dem der? Måske ville det være bedre at placere dem et andet sted, hvor brugeren ikke støder på dem? Ligesom det er gjort i Mac OS X, hvor indholdet af pakkerne .app, som ikke skal være synligt for brugeren i /Applications, skjules dybt inde i /System/Library/…«`.

Hvad med afhængigheder?

Jeg tror, det ville være en god idé at angive afhængigheder, ikke? Kan Qt betragtes som en obligatorisk del af installationen af Haiku som standard? Nej! Qt er ikke installeret som standard. Kan pakkeopbygningsprogrammet automatisk bestemme afhængigheder ved at tjekke ELF-filerne? Jeg har hørt, at HaikuPorter faktisk gør det, men pakke nej. Det er fordi det bare er en 'pakkeopbygger', der i sig selv bare skaber filer hpkg.

Er det værd at gøre Haiku mere sofistikeret ved at tilføje en politik om, at pakker ikke må have afhængigheder fra pakker, der ikke er en del af haikuports? (Мне бы так хотелось, поскольку подобная политика значительно облегчает задачу — система смогла бы автоматически разрешить зависимости каждого пакета, загружаемого откуда угодно, без возни с дополнительными источниками пакетов).

mr. waddlesplash forklarer:

Vi ønsker ikke at begrænse udviklernes frihed så meget, da det er tydeligt, at hvis FirmaX ønsker at understøtte deres eget softwarebibliotek med afhængigheder (og dermed et repository) - så kan de gøre det frit.

I så fald ville det måske være en god idé at anbefale tredjepartspakker at undgå afhængigheder fra noget, der ikke er i haikuports, ved helt at pakke alt nødvendigt sammen med applikationen. Men jeg tror, det er et emne for en fremtidig artikel i denne serie. [Forfatteren hentyder til AppImage? — bem. oversætter]

Tilføjelse af app-ikon

Hvad hvis jeg vil tilføje et af de pæne indbyggede ikoner til ressourcerne i min nyoprettede applikation? Det viser sig at være et spændende emne, så det bliver hovedfokus for næste artikel.

Hvordan organiserer man kontinuerlig opbygning af applikationer?

Forestil dig et projekt som Inkscape (ja, jeg ved godt, at det ikke er tilgængeligt i Haiku endnu, men det er praktisk til demonstration). De har et repository med kildekoden. https://gitlab.com/inkscape/inkscape.
Hver gang en person registrerer sine ændringer i et arkiv, starter build-pipelines, hvorefter ændringerne automatisk testes, bygges, og applikationen pakkes i forskellige formater, inklusive AppImage til Linux (en selvstændig applikationspakke, der kan downloades til lokal test uafhængigt af hvad der måtte eller ikke måtte være installeret på systemet. [jeg vidste det! — bem. oversætter]). Ligeledes sker alt, når der er hver anmodning om at fusionere grene, så man kan downloade applikationen bygget fra koden, der foreslås i anmodningen om fusion, før fusionen.

Anmodninger om fusion med build-statusser og mulighed for at downloade de byggede binære filer i tilfælde af succesfuld build (markeret med grønt)

Buildprocessen kører i Docker-containere. GitLab tilbyder gratis runners på Linux, og jeg tror, det er muligt at tilslutte egne runners (forresten, jeg kan ikke forestille mig, hvordan det vil fungere for systemer som Haiku, som jeg ved, ikke har Docker eller en analog, men for FreeBSD er der heller ikke Docker, så dette problem er ikke unikt for Haiku).

Ideelt skulle app-byggene til Haiku kunne udføres inden i en Docker-container for Linux. I så fald kan bygget til Haiku integreres i eksisterende pipelines. Er der kryds-kompilatorer? Eller skal vi emulere hele Haiku inden i en Docker-container ved at bruge noget som QEMU/KVM (forudsat at det vil fungere inden i Docker)? For resten bruger mange projekter lignende principper. For eksempel gør Scribus dette — det er allerede tilgængeligt for Haiku. En dag vil jeg kunne sende sådanne anmodninger om fusion til andre projekter for at tilføje support for Haiku.

En af udviklerne forklarer:

For andre projekter, der ønsker at oprette pakker selv, understøttes den almindelige metode CMake/CPack. Andre build-systemer kan understøttes, hvis man kalder pakke-build-programmet direkte, hvilket er godt, hvis folk har interesse her. Erfaringen viser: indtil videre har der ikke været meget interesse, så haikuporter har fungeret, som det passer os, men til sidst skal begge metoder fungere sammen. Vi bør præsentere et værktøjssæt til krydsbygning af software fra Linux eller ethvert andet server-operativsystem (Haiku er ikke designet til at køre på servere).

Jeg applauderer stående. Almindelige Linux-brugere slæber al denne ekstra belastning og det ekstra bagage (sikkerhed, stram kontrol osv.), som er nødvendig for en serveroperativsystem, men ikke for personlig brug. Derfor er jeg helt enig i, at muligheden for at samle applikationer til Haiku på Linux er den rigtige vej.

Konklusion

Portering af POSIX-applikationer til Haiku er muligt, men kan kræve mere ressourcer end en almindelig genopbygning. Jeg ville bestemt have givet op længe siden, hvis det ikke var for hjælpen fra folk på #haiku-kanalen på irc.freenode.net. Men selv de så ikke altid straks, hvad der var galt.

Applikationer skrevet i Qt er en let undtagelse. Jeg samlede en simpel demonstrationsapplikation uden større problemer.

At bygge pakker til enkle applikationer er også relativt let, men kun for dem, der "udgives på den traditionelle måde", dvs. som har versionsstyrede kildefiler, der er beregnet til at understøtte i haikuports. For kontinuerlig bygning (bygning ved hver ændringscommit) fra GitHub er det ikke så ligetil. Her minder Haiku mere om et Linux-distro end om resultatet på Mac, hvor man ved at trykke på knappen "Byg" i XCode får en pakke .app, klar til at blive indsat i diskbilledet .dmg, forberedt til at blive uploadet på mit website.
Kontinuerlig bygning af applikationer baseret på en "server"-operativsystem, som Linux, vil sandsynligvis blive muligt, hvis der er efterspørgsel fra udviklerne, men på nuværende tidspunkt har Haiku-projektet andre, mere presserende opgaver.

Prøv selv! Haiku-projektet tilbyder billeder til download fra DVD eller USB, der genereres dagligt. For installationen er det nok at downloade billedet og skrive det til en USB-nøgle ved hjælp af Etcher

Har du spørgsmål? Vi inviterer dig til vores russisktalende telegram-kanal.

Fejloversigt: Hvordan man skyder sig selv i foden i C og C++. En opskriftsamling fra Haiku OS

Fra forfatter til oversættelse: dette er den femte artikel i serien om Haiku.

Liste over artikler: Den første Anden Tredje Fjerde

Kilde: habr.com