🥇Mana piektā diena ar Haiku: portēsim dažas programmas

TL; DR: Iesācējs pirmo reizi redzēja Haiku, mēģinot pārnest dažas programmas no Linux pasaules.

Mana pirmā Haiku portētā programma, kas iepakota hpkg formātā

Nesen Es atklāju Haiku, pārsteidzoši labu operētājsistēmu personālajiem datoriem.
Šodien es uzzināšu, kā portēt jaunas programmas uz šo operētājsistēmu. Galvenā uzmanība tiek pievērsta pirmās pieredzes aprakstam, pārejot uz Haiku no Linux izstrādātāja viedokļa. Es atvainojos par stulbām kļūdām, ko pieļāvu ceļā, jo nav pagājusi pat nedēļa, kopš pirmo reizi lejupielādēju Haiku.

Es vēlos sasniegt trīs mērķus:

Portējiet vienkāršu CLI lietojumprogrammu
Portējiet lietojumprogrammu no GUI uz Qt
Pēc tam iesaiņojiet tos hpkg formātā (jo es joprojām domāju par AppDir un AppImage pielāgošanu Haiku...)

Sāksim. Sadaļās dokumentāciju и attīstību, kā arī iekšā Wiki no HaikuPorts atradu pareizo virzienu. Ir pat tiešsaistes PDF grāmata BeOS: Unix lietojumprogrammas pārnešana.
467 lappuses - un tas ir no 1997. gada! Ir bail skatīties iekšā, bet ceru uz to labāko. Izstrādātāja vārdi ir iepriecinoši: “pagāja ilgs laiks, jo BeOS nebija saderīgs ar POSIX”, bet Haiku “lielākoties” jau tāds ir.

Vienkāršas CLI lietojumprogrammas pārnešana

Pirmā doma bija lietojumprogrammas pārnešana avrdude, bet, kā izrādījās, tas jau ir ir darījuši sen.

Pirmais mēģinājums: nekas nav jāskatās

Ko es nevaru saprast, tas jau ir Lietotnes ir pārnestas uz Haiku vairāk nekā 10 gadus - neskatoties uz to, ka pati OS vēl nav pat versija 1.0.

Otrais mēģinājums: nepieciešams pārrakstīt

Tāpēc es izmantošu ptouch-770, CLI, lai kontrolētu Brother P-Touch 770 printeri, ko izmantoju uzlīmju drukāšanai.
Es uz tā drukāju dažādas etiķetes, un jūs, iespējams, to jau redzējāt iepriekšējā rakstā. Nedaudz agrāk es uzrakstīju nelielu GUI iesaiņojuma programmu Python (tā kā tā ir Gtk+, tā būs jāpārraksta, un tas ir labs iemesls mācīties).

Brother P-Touch 770 uzlīmju printeris. Vai tas darbosies ar Haiku?

Haiku pakotņu pārvaldnieks zina par bibliotēkām un komandām, tādēļ, ja palaižot saņemu ziņojumu "nevaru atrast libintl". configure - Es tikko palaižu pkgman install devel:libintl un vajadzīgā pakete tiks atrasta. Tāpat pkgman install cmd:rsync. Nu utt.

Izņemot gadījumus, kad tas nedarbojas:

/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

Iespējams, udev ir pārāk balstīts uz Linux, un tāpēc tas nepastāv priekš Haiku. Tas nozīmē, ka man ir jārediģē avota kods, ko mēģinu apkopot.
Eh, tu nevari lēkt pāri galvai, un es pat nezinu, ar ko sākt.

Trešais mēģinājums

Būtu jauki, ja būtu tmate Haiku gadījumā es ļautu Haiku izstrādātājiem pieslēgties manai termināļa sesijai - ja kaut kas noiet greizi. Norādījumi ir pavisam vienkārši:

./autogen.sh
./configure
make
make install

Izskatās labi, kāpēc gan neizmēģināt to uz 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

Šajā solī es atveru HaikuDepot un meklēju curses.
Tika atrasts kaut kas, kas man deva mājienu precīzākam vaicājumam:

/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

Atkal devos uz HaikuDepot, un, protams, atradu devel:msgpack_c_cpp_devel. Kādi ir šie dīvainie vārdi?

/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

Šajā solī es sapratu, ka programmas pārnešana uz Haiku prasa daudz vairāk zināšanu, nekā nepieciešams vienkāršai pārbūvei.
Es runāju ar draudzīgajiem Haiku izstrādātājiem, izrādās, ka msgpack ir kļūda, un pēc dažām minūtēm es redzu ielāpu HaikuPorts. Savām acīm redzu kā izlabots iepakojums dodos šeit (buildslave — virtuālās mašīnas).

Labotās ziņu pakotnes izveide vietnē buildmaster

Starplaikos es nosūtu ielāpu uz augšu lai pievienotu Haiku atbalstu msgpack.

Pēc piecām minūtēm atjauninātais msgpack jau ir pieejams Haiku valodā:

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

Negaidīti labi. Vai es to teicu?!

Atgriežos pie sākotnējās problēmas:

/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

Tagad izskatās, ka msgpack nav vainīgs. Es komentēju IMAXLABEL в tty.c tā:

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

Rezultāts:

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.

Nu, lūk, atkal... Starp citu:

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

Mr. waddlespllash norāda, kur rakt:

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

Šeit es ievietoju config.log.

Viņi man paskaidroja, ka bez Haiku libresolv ir vēl kaut kas libresolv tīklā. Acīmredzot kods ir jārediģē tālāk. Jādomā…

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

Mūžīgais jautājums: kas notiek?

/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

Tas pats, tikai profilā. Google un atrada šo. Ja pievienojat -lssp “Dažreiz” palīdz, es mēģinu:

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

Oho! Sākas! Bet…

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

Es mēģināšu atkļūdot failu šeit:

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

“Bad port ID” jau ir kā vizītkarte haiku. Varbūt kādam ir nojausma, kas par vainu un kā to novērst? Ja tā, es atjaunināšu rakstu. Saite uz GitHub.

GUI lietojumprogrammas pārnešana uz Qt.

Es izvēlos vienkāršu QML aplikāciju.

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

Tiešām vienkārši. Mazāk par minūti!

Aplikāciju iepakošana hpkg, izmantojot haikuporter un haikuports.

Ar ko man jāsāk? Nav vienkāršas dokumentācijas, es dodos uz #haiku kanālu vietnē irc.freenode.net un dzirdu:

Komanda package - zema līmeņa pakotņu izveides veids. Lielākoties viņai pietiek ar PackageInfo, kā aprakstīts sadaļā "Pareizas .hpkg pakotnes izveidošana"
Man kaut kas jādara ir
Var izmantot hpkg-radītājs (tas sabrūk man, kļūdu ziņošana)

Nav skaidrs, ko darīt. Man šķiet, ka man ir vajadzīga Hello World stila rokasgrāmata iesācējiem, ideālā gadījumā video. Būtu jauki, ja būtu arī ērts ievads par HaikuPorter, kā tas tiek darīts GNU hello.

Es lasu sekojošo:

haikuporter ir rīks kopēju Haiku pakotņu projektu izveidei. Tas izmanto HaikuPorts repozitoriju kā bāzi visām pakotnēm. Haikuporter receptes tiek izmantotas, lai izveidotu iepakojumus.

Turklāt es atklāju, ka:

HaikuPorts krātuvē receptes nav jāglabā. Varat izveidot citu krātuvi, ievietot tajā receptes un pēc tam norādīt uz to haikuporter.

Tieši tas, kas man vajadzīgs – ja nemeklēju veidu, kā publiski izlaist paketi. Bet šī ir tēma citam ierakstam.

Haikuportera un haikuportu uzstādīšana

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

Receptes rakstīšana

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
}

Receptes salikšana

Es saglabāju failu ar nosaukumu QtQuickApp-1.0.recipe, pēc kura es palaistu aikuporter -S ./QuickApp-1.0.recipe. Atkarības tiek pārbaudītas visām repozitorijā esošajām pakotnēm haikuports, kas aizņem kādu laiku. Es aiziešu pēc kafijas.

Kāpēc šī pārbaude būtu jāveic manā vietējā datorā, nevis centralizēti serverī vienu reizi visiem?

Saskaņā ar mr. waddlesplash:

Ar tādu, lai varētu pārrakstīt jebkuru failu repozitorijā 😉 Šo vari nedaudz optimizēt, nepieciešamības gadījumā aprēķinot nepieciešamo informāciju, jo pēdējās veiktās izmaiņas ir diezgan reti.

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

Izrādās, ka nav tādas lietas kā parasts receptes fails, kas satur jūsu lietojumprogrammas avota kodu. Jums tas jāglabā krātuvē HaikuPorts formātā.

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

Šis fakts padara montāžu apgrūtinošāku. Man tas īpaši nepatīk, bet domāju, ka tas ir nepieciešams, lai galu galā visa atvērtā koda programmatūra parādītos HaikuPorts.

Es saņemu sekojošo:

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

Kas noticis? Pēc irc izlasīšanas es daru:

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

Ir radies interesants jautājums. Ja es pievienošu receptei kontrolsummu, vai tā atbilst jaunākajai git commit nepārtrauktai integrācijai? (Izstrādātājs apstiprina: "Tas nedarbosies. Receptes ir izstrādātas tā, lai tās būtu salīdzinoši stabilas.")

Lai izklaidētos, pievienojiet receptei:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Joprojām neesmu apmierināts:

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

Ko viņš dara? Galu galā šī ir git repozitorija, kods jau ir tieši tur, nav ko izpakot. Manā skatījumā rīkam jābūt pietiekami gudram, lai nemeklētu atpakotāju, ja tas atrodas virs GitHub url.

Varbūt uri git:// darbosies

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

Tagad tas sūdzas šādi:

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

Hmm, kāpēc viss ir tik sarežģīti, kāpēc nevar "tikai strādāt"? Galu galā nav nekas neparasts izveidot kaut ko no GitHub. Neatkarīgi no tā, vai tie ir rīki, kas darbojas uzreiz, bez nepieciešamības pēc iestatīšanas vai kā es to saucu par "uztraukumu".

Varbūt tas darbosies šādi:

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

Nē. Es joprojām saņemu šo dīvaino kļūdu un daru, kā šeit aprakstīts

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

Es virzos nedaudz tālāk, bet kāpēc tas kliedz uz mani (GitHub nav drošs!) un joprojām mēģina kaut ko izpakot.

Saskaņā ar Mr. waddlespllash:

Nu jā, iemesls bija vēlme pārbaudīt montāžai saņemto datu integritāti. Viena no iespējām ir pārbaudīt arhīva kontrolsummu, taču jūs, protams, varat jaukt atsevišķus failus, kas netiks ieviesti, jo tas aizņem daudz ilgāku laiku. Tā sekas ir git un citu VCS “nedrošība”. Visticamāk, tas tā būs vienmēr, jo arhīva izveide vietnē GitHub ir diezgan vienkārša un bieži vien ātrāka. Labi, nākotnē varbūt kļūdas ziņojums nebūs tik spilgts... (šādas receptes vairs HaikuPorts neapvienojam).

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

Pēc vecā ieraduma es eju pajautāt labiem cilvēkiem kanālā #haiku tīklā irc.freenode.net. Un kur es būtu bez viņiem? Pēc mājiena es sapratu, ka man vajadzētu izmantot:

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

Labi, kļuva skaidrs, ko tas dara - tas lejupielādē arhīvu ar noteiktas versijas pirmkodu. Tas ir stulbi, no mana viedokļa, un ne gluži tas, ko es gribēju, proti, lejupielādēt jaunāko versiju no galvenās filiāles.

Viens no izstrādātājiem to paskaidroja šādi:

Mums ir savs CI, tāpēc viss, kas tiek ievietots haikuportu repozitorijā, tiks iesaiņots visiem lietotājiem, un mēs nevēlamies riskēt, apkopojot un piegādāt “visu jaunākajā versijā augšpus”.

Sapratu! Jebkurā gadījumā notika šādi:

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

Tas atkārto to bezgalīgi. Acīmredzot tā ir kļūda (vai ir lietojumprogramma? Es to nevarēju atrast).

С haikuporter un repozitorijs haikuports Tam nav "tikai darbojas" sajūtas, taču kā izstrādātājam man patīk dažas lietas, strādājot ar Haiku. Lielākoties tas ir līdzīgs Open Build Service — rīku komplektam Linux būvējumu veidošanai: ārkārtīgi jaudīgs, ar sistemātisku pieeju, taču pārspīlēts manai mazajai "sveiki pasaulei" lietojumprogrammai.

Atkal, saskaņā ar mr. waddlesplash:

Patiešām, HaikuPorter pēc noklusējuma ir diezgan stingrs (turklāt ir savstarpēja režīms, kā arī stingrs režīms, lai padarītu to vēl stingrāku!), bet tikai tāpēc, ka tas rada pakotnes, kas darbosies, nevis tikai izveido pakotnes. Tāpēc viņš sūdzas par nedeklarētām atkarībām, nepareizi importētām bibliotēkām, nepareizām versijām utt. Mērķis ir noķert visas problēmas, arī turpmākās, pirms lietotājs par to uzzina (tāpēc nebija iespējams instalēt avrdude, jo atkarība faktiski bija norādīta receptē). Bibliotēkas nav tikai atsevišķas pakotnes vai pat konkrētas SO versijas. HaikuPorter nodrošina, ka tas viss tiek ievērots pašās receptēs, lai izvairītos no kļūdām izpildes laikā.

Principā šāds stingrības līmenis ir attaisnojams, veidojot operētājsistēmu, bet man tas šķiet nevajadzīgs "hello world" lietojumprogrammai. Nolēmu pamēģināt ko citu.

Lietojumprogrammu izveide hpkg formātā, izmantojot komandu “package create”.

Var būt, šis Vai vienkāršas instrukcijas man noderēs labāk?

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

Negaidīti ātri, negaidīti vienkārši, negaidīti efektīvi. Tieši tā, kā man patīk, apbrīnojami!

Uzstādīšana - kas un kur?

Pārvietoja failu QtQuickApp.hpkg uz ~/config/packagesizmantojot failu pārvaldnieku, pēc kura maģiski parādījās QtQuickApp ~/config/apps.
Atkal negaidīti ātri, vienkārši un efektīvi. Apbrīnojami, neticami!

Bet... (kur gan mēs būtu bez viņiem!)

Programma joprojām nav iekļauta lietotņu izvēlņu sarakstā un QuickLaunch. Man šķiet, ka es jau zinu, kā to labot. Failu pārvaldniekā es pārvietoju QtQuickApp.hpkg no ~/config/packages uz /system/packages.

Nē, joprojām trūkst. Acīmredzot es (nu un instrukcijas) kaut ko palaidu garām.

Apskatot dažas citas lietojumprogrammas HaikuDepot cilnē "Saturs", es redzēju, ka ir tādi faili kā /data/mimedb/application/x-vnd... kas ir vēl ievērojamāks /data/deskbar/menu/Applications/….

Nu ko man tur likt? Aiziet...

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

Esmu diezgan pārliecināts, ka šis triks darbosies, taču paliek jautājumi: kāpēc tas ir vajadzīgs, kam tas paredzēts? Manuprāt, tas sagrauj kopējo iespaidu, ka sistēma ir tik izsmalcināta.

Kā skaidroja Mr. waddlesplash:

Dažreiz ir lietojumprogrammas, kas ir vajadzīgas citām lietojumprogrammām, bet kuras nav izvēlnē. Piemēram, ekrānuzņēmumā LegacyPackageInstaller, kas apstrādā .pkg arhīvus BeOS formātā. Es vēlētos, lai lietotāji tos instalētu, taču viņu klātbūtne izvēlnē radīs neskaidrības.

Man nez kāpēc šķiet, ka ir, piemēram, vienkāršāks risinājums Hidden=true failos .desktop operētājsistēmā Linux. Kāpēc gan nepadarīt "slēpto" informāciju par failu sistēmas resursu un atribūtu?

Īpaši smalks ir (dažas) lietojumprogrammas nosaukums, kas parāda izvēlni, deskbar, pa ceļam stingri sasiets.

Mr. waddlesplash to izskaidro:

“Darbjosla” šajā gadījumā ir jāsaprot kā sava veida vispārīgs termins (tāpat kā “uzdevumjosla”, kas attiecas gan uz Windows lietojumprogrammu, gan uz vispārējo koncepciju). Nu, kopš šī deskbar, nevis “Deskbar”, arī to var saprast līdzīgi.

2 "gandrīz identiski" direktoriji ar lietojumprogrammām tajos

Kāpēc ir 2 direktoriji ar lietojumprogrammām, kā arī kāpēc vienā ir mana QtQuickApplication, bet otrā nav? (Galu galā tas nav vienas sistēmas, bet gan otrā lietotāja, kas man personīgi būtu saprotams).
Es esmu patiešām apmulsis, un es domāju, ka tam vajadzētu būt vienotam.

komentēja mr. waddlespllash

Programmu katalogā ir lietojumprogrammas, kas izvēlnē nav vajadzīgas. Taču situācija ar ēdienkarti tiešām ir jāuzlabo, lai tā būtu pielāgojamāka.

Pieteikšanās, vai arī nenotiks 😉

Es prātoju: vai tiešām ir nepieciešams mitināt lietojumprogrammas /system/apps, ja lietotāji tos tur redz, tas ir nevēlami. Varbūt labāk tos novietot citā vietā, kur lietotājs ar tiem nesastapsies? Tāpat kā tas tiek darīts operētājsistēmā Mac OS X, kur pakotņu saturs .app, kam nevajadzētu būt redzamam lietotājam /Applications, slēpjas /Sistēma/Bibliotēka/…“` dziļumos.

Kā ar atkarībām?

Es domāju, ka ir vērts kaut kā precizēt atkarības, vai ne? Vai Qt pēc noklusējuma var uzskatīt par obligātu Haiku instalācijas sastāvdaļu? Nē! Qt pēc noklusējuma nav instalēts. Vai pakotņu veidotājs var automātiski noteikt atkarības, pārbaudot ELF failus? Man teica, ka HaikuPorter patiesībā to dara, bet package Nē. Tas ir tāpēc, ka tas ir tikai "pakešu veidotājs", kas tikai izveido failus pats hpkg.

Vai Haiku ir jāpadara sarežģītākas, pievienojot politiku, ka paketei nevajadzētu būt atkarīgām no pakotnēm ārpus haiku? haikuports? (Es gribētu, jo šāda politika padarītu darbu daudz vienkāršāku — sistēma spētu automātiski atrisināt katras no jebkuras vietas lejupielādētas pakotnes atkarības, nejaucoties ar papildu pakotņu avotiem.)

Mr. waddlesplash paskaidro:

Mēs negribētu tik ļoti ierobežot izstrādātāju brīvību, jo ir acīmredzams, ka, ja CompanyX vēlas atbalstīt savu programmatūras komplektu ar atkarībām (un līdz ar to arī repozitoriju), tas to darīs pilnīgi brīvi.

Tādā gadījumā varētu būt vērts ieteikt trešo pušu pakotnēm izvairīties no atkarības no nekā, kas nav iekļauts haikuportā, pilnībā iesaiņojot visu nepieciešamo kopā ar lietojumprogrammu. Bet es domāju, ka šī ir tēma turpmākam šīs sērijas rakstam. [Vai autors dodas uz AppImage? — apm. tulkotājs]

Lietojumprogrammas ikonas pievienošana

Ko darīt, ja es vēlos pievienot kādu no glītajām iebūvētajām ikonām savas jaunizveidotās lietojumprogrammas resursiem? Izrādās, ka šī ir pārsteidzoša tēma, tāpēc tas būs pamats nākamajam rakstam.

Kā organizēt nepārtrauktu lietojumprogrammu veidošanu?

Iedomājieties tādu projektu kā Inkscape (jā, es zinu, ka tas vēl nav pieejams Haiku formātā, bet ir ērti tajā attēlot). Viņiem ir pirmkoda repozitorijs https://gitlab.com/inkscape/inkscape.
Ikreiz, kad kāds veic izmaiņas krātuvē, tiek palaistas izveides konveijerus, pēc kuriem izmaiņas tiek automātiski pārbaudītas, veidotas un lietojumprogramma tiek iepakota dažādās pakotnēs, tostarp AppImage for Linux (atsevišķa lietojumprogrammu pakotne, kuru var lejupielādēt vietējai testēšanai neatkarīgi no ko var vai nevar instalēt sistēmā [ES to zināju! — apm. tulkotājs]). Tas pats notiek ar katru filiāles sapludināšanas pieprasījumu, tāpēc pirms sapludināšanas varat lejupielādēt lietojumprogrammu, kas izveidota no sapludināšanas pieprasījumā piedāvātā koda.

Apvienot pieprasījumus ar būvējuma statusiem un iespēju lejupielādēt kompilētos bināros failus, ja būvēšana ir veiksmīga (atzīmēta zaļā krāsā)

Būvējums darbojas Docker konteineros. GitLab piedāvā bezmaksas skrējējus operētājsistēmā Linux, un es domāju, ka varētu būt iespējams iekļaut savus skrējējus (starp citu, es nesaprotu, kā tas darbotos tādās sistēmās kā Haiku, kurām, kā es zinu, nav Docker vai līdzvērtīga, taču arī FreeBSD nav Docker, tāpēc šī problēma nav raksturīga tikai Haiku).

Ideālā gadījumā Haiku lietojumprogrammas var iebūvēt Docker konteinerā, kas paredzēts Linux. Šādā situācijā Haiku montāžu var ieviest esošajos cauruļvados. Vai ir krusteniski kompilatori? Vai arī man vajadzētu atdarināt visu Haiku Docker konteinerā, izmantojot kaut ko līdzīgu QEMU/KVM (pieņemot, ka tā darbosies Docker iekšpusē)? Starp citu, daudzi projekti izmanto līdzīgus principus. Piemēram, Scribus to dara - tas jau ir pieejams Haiku. Kādu dienu pienāks diena, kad varēšu nosūtīt šāds Pārsūtiet pieprasījumus citiem projektiem, lai pievienotu Haiku atbalstu.

Viens no izstrādātājiem paskaidro:

Citiem projektiem, kas vēlas paši izveidot pakotnes, tiek atbalstīta parastā CMake/CPack metode. Citas būvēšanas sistēmas var atbalstīt, tieši izsaucot pakotnes veidošanas programmu, kas ir labi, ja cilvēkus tā interesē. Pieredze rāda: līdz šim liela interese nav bijusi, tāpēc haikuporter darbojās kā mums ērts, bet galu galā abām metodēm vajadzētu strādāt kopā. Mums vajadzētu ieviest rīku komplektu programmatūras savstarpējai veidošanai no Linux vai jebkuras citas servera operētājsistēmas (Haiku nav paredzēts darboties serveros).

Es sniedzu stāvovācijas. Regulāri Linux lietotāji nes visu šo papildu slodzi un papildu bagāžu (drošība, stingra kontrole utt.), kas nepieciešama servera operētājsistēmai, bet ne personīgajai. Tāpēc es pilnībā piekrītu, ka iespēja izveidot Haiku lietotnes operētājsistēmā Linux ir pareizais ceļš.

Secinājums

POSIX lietojumprogrammu pārnešana uz Haiku ir iespējama, taču tā var būt dārgāka nekā parasta pārbūve. Es noteikti paliktu pie tā uz ilgu laiku, ja nepalīdzētu cilvēki no #haiku kanāla irc.freenode.net tīklā. Bet pat viņi ne vienmēr uzreiz saprata, kas bija nepareizi.

Programmas, kas rakstītas Qt, ir vienkāršs izņēmums. Es bez problēmām izveidoju vienkāršu demonstrācijas lietojumprogrammu.

Pakotnes izveidošana vienkāršām lietojumprogrammām arī ir diezgan vienkārša, taču tikai “tradicionāli izlaistajām”, t.i. kam ir versijas pirmkoda arhīvi, kas paredzēti atbalstam haikuportos. Nepārtrauktai izveidei (veidot katrai izmaiņu veikšanai) ar GitHub, šķiet, ka viss nav tik vienkārši. Šeit Haiku šķiet vairāk kā Linux izplatīšana, nevis rezultāts Mac datorā, kur, noklikšķinot uz pogas “Build” programmā XCode, jūs saņemat pakotni. .app, gatavs ievietošanai diska attēlā .dmg, sagatavots lejupielādei manā vietnē.
Nepārtraukta aplikāciju veidošana uz “servera” operētājsistēmas bāzes, piemēram, Linux, visticamāk, kļūs iespējama, ja būs pieprasījums no izstrādātājiem, taču šobrīd Haiku projektam ir citi, aktuālāki uzdevumi.

Izmēģiniet to pats! Galu galā Haiku projekts nodrošina ģenerētus attēlus palaišanai no DVD vai USB katru dienu. Lai instalētu, vienkārši lejupielādējiet attēlu un ierakstiet to zibatmiņas diskā, izmantojot Etcher

Vai jums ir kādi jautājumi? Aicinām uz krievvalodīgo telegrammas kanāls.

Kļūdu pārskats: Kā iešaut sev kājā C un C++ valodā. Haiku OS recepšu kolekcija

No autors tulkojums: šis ir piektais raksts sērijā par Haiku.

Rakstu saraksts: Pirmais Otrais Trešais Ceturtais

Avots: www.habr.com

Mana piektā diena ar Haiku: portēsim dažas programmas