ProHoster > Блог > Administrado > Mia kvina tago kun Hajko: ni portu kelkajn programojn

Mia kvina tago kun Hajko: ni portu kelkajn programojn

Mia kvina tago kun Hajko: ni portu kelkajn programojn

TL; DR: Novulo vidis Hajkon unuafoje, provante porti kelkajn programojn el la Linukso-mondo.

Mia kvina tago kun Hajko: ni portu kelkajn programojn
Mia unua hajku-portita programo, pakita en ĝia hpkg-formato

Ĵus Mi malkovris Haiku, surprize bonan operaciumon por komputiloj.
Hodiaŭ mi lernos kiel porti novajn programojn al ĉi tiu operaciumo. La ĉefa fokuso estas priskribo de la unua sperto ŝanĝi al Hajko el la vidpunkto de Linuksa programisto. Mi pardonpetas pro eventualaj stultaj eraroj, kiujn mi faris survoje, ĉar eĉ ne pasis unu semajno de kiam mi unuafoje elŝutis Hajkon.

Mi volas atingi tri celojn:

  • Porti simplan CLI-aplikaĵon
  • Porti aplikaĵon de GUI al Qt
  • Poste paku ilin en hpkg-formato (ĉar mi ankoraŭ pensas pri adapto de AppDir kaj AppImage por Hajko...)

Ni komencu. En sekcioj dokumentado и disvolviĝosame kiel en vikio de HaikuPorts mi trovis la ĝustan direkton. Estas eĉ reta PDF-libro BeOS: Portado de Uniksa Apliko.
467 paĝoj - kaj ĉi tio estas el 1997! Estas timige rigardi enen, sed mi esperas la plejbonon. La vortoj de la programisto estas kuraĝigaj: "ĝi daŭris longan tempon ĉar BeOS ne estis konforma al POSIX", sed Hajko "plejparte" jam estas tia.

Porti simplan CLI-aplikaĵon

La unua penso estis porti la aplikaĵon avrdude, sed, kiel montriĝis, ĉi tio jam estas farita antaŭ longe.

Unua provo: nenio por rigardi

Kion mi ne povas kompreni, estas tio jam Aplikoj estas portitaj al Hajko dum pli ol 10 jaroj - malgraŭ tio, ke la OS mem ankoraŭ ne estas versio 1.0.

Dua provo: necesas reverki

Do mi uzos ptouch-770, CLI por kontroli la Brother P-Touch 770-presilon, kiun mi uzas por presi etikedojn.
Mi presas sur ĝi diversajn etikedojn, kaj vi eble jam vidis ĝin en la antaŭa artikolo. Iom pli frue, mi skribis malgrandan GUI-envolvaĵan programon en Python (ĉar ĝi estas en Gtk+, ĝi devos esti reverkita, kaj ĉi tio estas bona kialo por lerni).

Mia kvina tago kun Hajko: ni portu kelkajn programojn
Etikedprintilo Brother P-Touch 770. Ĉu ĝi funkcios kun Hajko?

La pakaĵa administranto de Haiku scias pri bibliotekoj kaj komandoj, do se mi ricevas mesaĝon "ne povas trovi libintl" kiam mi funkcias configure - Mi ĵus lanĉas pkgman install devel:libintl kaj la bezonata pako estos trovita. same pkgman install cmd:rsync. Nu, ktp.

Krom kiam ĉi tio ne funkcias:

/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

Eble udev estas tro Linukso-bazita kaj tial ne ekzistas por Hajko. Tio signifas, ke mi devas redakti la fontkodon, kiun mi provas kompili.
Eh, vi ne povas salti super vian kapon, kaj mi eĉ ne scias kie komenci.

Tria provo

Estus bone havi tmate por Hajko, tiam mi permesus al la hajko-programistoj konektiĝi al mia fina sesio - en la okazo ke io misfunkcius. La instrukcioj estas sufiĉe simplaj:

./autogen.sh
./configure
make
make install

Aspektas bone, do kial ne provi ĝin sur Hajko?

/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

En ĉi tiu paŝo mi malfermas HaikuDepot kaj serĉas curses.
Io estis trovita, kio donis al mi sugeston por pli kompetenta demando:

/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

Denove mi iris al HaikuDepot, kaj, kompreneble, trovis devel:msgpack_c_cpp_devel. Kio estas ĉi tiuj strangaj nomoj?

/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

Je ĉi tiu paŝo, mi rimarkis, ke porti programon al Hajko postulas multe pli da scio ol necesas por simpla rekonstruo.
Mi parolis kun la amikaj Haiku-programistoj, rezultas ke estas cimo en msgpack, kaj post kelkaj minutoj mi vidas diakilon en HaikuPorts. Mi povas vidi per miaj propraj okuloj kiel la korektita pako irante ĉi tien (buildslave - virtualaj maŝinoj).

Mia kvina tago kun Hajko: ni portu kelkajn programojn
Konstruante la korektitan msgpack sur buildmaster

Inter tempoj mi sendas flikaĵon al kontraŭfluo aldoni hajkon subtenon al msgpack.

Kvin minutojn poste, la ĝisdatigita msgpack jam disponeblas en Hajko:

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

Neatendite bona. Ĉu tion mi diris?!

Mi revenas al la originala problemo:

/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

Nun ŝajnas, ke msgpack ne estas kulpa. Mi komentas IMAXLABEL в tty.c kiel tia:

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

Rezulto:

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, jen ni denove... Cetere:

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

s-ro. waddlesplash diras al vi kie fosi:

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

Jen mi afiŝis agordo.log.

Ili klarigis al mi, ke estas io alia en libnetwork krom libresolv pri Hajko. Ŝajne la kodo devas esti redaktita plu. Necesas pensi...

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

La eterna demando: kio okazas?

/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

La sama afero, nur profile. Guglos kaj trovis ĉi tion. Se vi aldonas -lssp "kelkfoje" helpas, mi provas:

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

Ŭaŭ! Ĝi komenciĝas! Sed…

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

Mi provos sencimigi dosiero ĉi tie:

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

"Malbona haveno ID" jam estas kiel vizitkarto hajko. Eble iu havas ideon, kio estas malbona kaj kiel ripari ĝin? Se jes, mi ĝisdatigos la artikolon. Ligo al GitHub.

Portante la GUI-aplikaĵon al Qt.

Mi elektas simplan QML-aplikaĵon.

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

Vere simpla. Malpli ol unu minuto!

Pakado de aplikoj en hpkg uzante haikuporter kaj haikuports.

Per kio mi komencu? Ne estas simpla dokumentado, mi iras al la kanalo #haiku ĉe irc.freenode.net kaj aŭdas:

  • teamo package - malaltnivela maniero krei pakaĵojn. Plejparte, PackageInfo sufiĉas por ŝi, kiel priskribite en la sekcio "Transformi ĝin en taŭgan pakaĵon .hpkg"
  • Mi devas fari ion tia
  • Povas uzi hpkg-kreinto (ĝi frakasas por mi, erara raportado)

Ne estas klare kion fari. Mi supozas, ke mi bezonas gvidilon por komencantoj de la stilo Hello World, ideale video. Estus bone havi ankaŭ oportunan enkondukon al HaikuPorter, kiel oni faras en GNU saluton.

Mi legas la jenon:

haikuporter estas ilo por krei komunajn pakajn projektojn por Hajko. Ĝi uzas la deponejon HaikuPorts kiel bazon por ĉiuj pakaĵoj. Haikuporter-receptoj estas uzataj por krei pakaĵojn.

Krome mi ekscias, ke:

Ne necesas konservi receptojn en HaikuPorts-stokado. Vi povas fari alian deponejon, meti la receptojn en ĝin, kaj poste indiki haikuporter al ĝi.

Ĝuste kion mi bezonas - se ne serĉas manieron publike liberigi la pakaĵon. Sed ĉi tio estas temo por alia afiŝo.

Instalado de haikuporter kaj 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/ # 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

Skribante recepton

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
}

Kunmeti la recepton

Mi konservas la dosieron sub la nomo QtQuickApp-1.0.recipe, post kio mi lanĉas aikuporter -S ./QuickApp-1.0.recipe. Dependecoj estas kontrolitaj por ĉiuj pakaĵoj en la deponejo haikuportoj, kiu prenas iom da tempo. Mi iros preni kafon.

Kial diable ĉi tiu kontrolo estu farita sur mia loka maŝino, kaj ne centre sur la servilo unufoje por ĉiuj?

Laŭ s-ro. waddlesplash:

Kun tia, ke vi povas reverki ajnan dosieron en la deponejo 😉 Vi povas iom optimumigi ĉi tion, kalkulante la necesajn informojn kiam necesas, ĉar la lastaj ŝanĝoj faritaj estas sufiĉe maloftaj.

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

Rezultas, ke ne ekzistas regula recepta dosiero, kiu enhavas la fontkodon de via aplikaĵo. Vi devas konservi ĝin en deponejo en la formato HaikuPorts.

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

Ĉi tiu fakto faras la muntadon pli maloportuna. Mi ne aparte ŝatas ĝin, sed mi opinias, ke ĝi estas necesa, por ke eventuale ĉiuj malfermkodaj programoj aperos en HaikuPorts.

Mi ricevas la jenon:

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

Kio estas malbona? Post legi irc mi faras:

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

Interesa demando aperis. Se mi aldonas ĉeksumon al la recepto - ĉu ĝi kongruos kun la plej nova git commit por kontinua integriĝo? (La programisto konfirmas: "Ĝi ne funkcios. La receptoj estas dezajnitaj por esti relative stabilaj.")

Por amuzo, aldonu al la recepto:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Ankoraŭ ne kontenta:

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

Kion li faras? Post ĉio, ĉi tio estas git-deponejo, la kodo jam estas tie rekte, estas nenio por malpaki. De mia vidpunkto, la ilo devus esti sufiĉe inteligenta por ne serĉi malpakilon se ĝi estas super la GitHub-url.

Eble uri git:// funkcios

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

Nun ĝi plendas jene:

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

Hmm, kial ĉio estas tiel komplika, kial vi ne povas "nur labori"? Post ĉio, ne estas tiel malofte konstrui ion el GitHub. Ĉu temas pri iloj, kiuj funkcias tuj, sen neceso de agordo, aŭ kiel mi nomas ĝin "fusing".

Eble ĝi funkcios tiel:

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

Ne. Mi ankoraŭ ricevas ĉi tiun strangan eraron kaj faras, kiel priskribite ĉi tie

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

Mi moviĝas iom pli, sed kial ĝi krias al mi (GitHub ne estas sekura!) kaj ankoraŭ provas malpaki ion.

Laŭ s-ro. waddlesplash:

Nu, jes, la kialo estis la deziro kontroli la integrecon de la datumoj ricevitaj por kunigo. Unu el la ebloj estas kontroli la kontrolsumon de la arkivo, sed vi povas, kompreneble, haŝi individuajn dosierojn, kiuj ne estos efektivigitaj, ĉar ĝi prenas multe pli longe. La sekvo de ĉi tio estas la "malsekureco" de git kaj aliaj VCS. Ĉi tio plej verŝajne ĉiam estos tiel, ĉar krei arkivon en GitHub estas sufiĉe facila kaj ofte pli rapida. Nu, estonte, eble la erarmesaĝo ne estos tiom okulfrapa... (ni ne plu kunfandas tiajn receptojn en HaikuPorts).

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

Pro malnova kutimo, mi iras demandi bonajn homojn ĉe la kanalo #haiku ĉe la reto irc.freenode.net. Kaj kie mi estus sen ili? Post la sugesto, mi komprenis, ke mi devus uzi:

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

Bone, evidentiĝis kion ĝi faras - ĝi elŝutas arkivon kun la fontkodo de certa revizio. Estas stulte, el mia vidpunkto, kaj ne ĝuste tio, kion mi volis, nome, elŝuti la lastan revizion de la majstra branĉo.

Unu el la programistoj klarigis ĝin jene:

Ni havas nian propran CI, do ĉio, kio estas metita en la haikuports-deponejon, estos pakita por ĉiuj uzantoj, kaj ni ne volas riski kolekti kaj liveri "ĉion en la plej nova versio kontraŭflue."

Komprenita! Ĉiukaze, jen kio okazis:

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

Ĝi ripetas ĉi tion ad infinitum. Ŝajne ĉi tio estas eraro (ĉu ekzistas aplikaĵo? Mi ne trovis ĝin).

С haikuporter kaj deponejo haikuportoj Ĝi ne havas "nur funkcias" senton al ĝi, sed kiel programisto, estas kelkaj aferoj, kiujn mi ŝatas labori kun Hajko. Plejparte, ĝi similas al la Malferma Konstrua Servo, aro da iloj por konstrui Linuksajn konstruojn: ege potenca, kun sistema aliro, sed troa por mia malgranda aplikaĵo "saluton mondo".

Denove, laŭ s-ro. waddlesplash:

Efektive, HaikuPorter estas sufiĉe strikta defaŭlte (plie ekzistas lint-reĝimo same kiel strikta reĝimo por igi ĝin eĉ pli strikta!), sed nur ĉar ĝi kreas pakaĵojn kiuj funkcios, prefere ol nur krei pakaĵojn. Tial li plendas pri nedeklaritaj dependecoj, bibliotekoj ne ĝuste importitaj, malĝustaj versioj ktp. La celo estas kapti iujn kaj ĉiujn problemojn, inkluzive de estontaj, antaŭ ol la uzanto scias pri ĝi (tial ne eblis instali avrdude, ĉar la dependeco estis fakte specifita en la recepto). Bibliotekoj ne estas nur individuaj pakaĵoj aŭ eĉ specifaj SO-versioj. HaikuPorter certigas, ke ĉio ĉi estas observita en la receptoj mem por eviti erarojn dum ekzekuto.

Principe, ĉi tiu nivelo de rigoro estas pravigita dum kreado de operaciumo, sed ŝajnas al mi nenecesa por aplikaĵo "saluton mondo". Mi decidis provi ion alian.

Konstrui aplikaĵojn en hpkg-formato uzante la komandon "pako krei".

Eble, ĉi tio Ĉu simplaj instrukcioj funkcios pli bone por mi?

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

Neatendite rapida, neatendite simpla, neatendite efika. Ĝuste kiel mi ŝatas ĝin, mirinda!

Instalado - kio kaj kie?

Movis la dosieron QtQuickApp.hpkg al ~/config/packagesuzante dosieradministradon, post kiu QtQuickApp magie aperis en ~/config/apps.
Denove, neatendite rapida, simpla kaj efika. Mirinda, nekredebla!

Sed... (kie ni estus sen ili!)

La aplikaĵo ankoraŭ mankas el la menulisto de la aplikaĵoj kaj QuickLaunch. Mi pensas, ke mi jam scias kiel ripari ĝin. En la dosieradministranto mi movas QtQuickApp.hpkg de ~/config/packages al /system/packages.

Ne, ankoraŭ mankas. Ŝajne, mi (nu, kaj la instrukcioj) maltrafis ion.

Rigardante la langeton "Enhavo" en HaikuDepot por iuj aliaj aplikaĵoj, mi vidis, ke ekzistas dosieroj kiel /data/mimedb/application/x-vnd... kio estas eĉ pli rimarkinda estas /data/deskbar/menu/Applications/….

Nu, kion mi metu tien? Venu...

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

Mi estas tute certa, ke ĉi tiu lertaĵo funkcios, sed la demandoj restas: kial ĉi tio estas necesa, por kio ĝi estas? Mi pensas, ke ĉi tio ruinigas la ĝeneralan impreson, ke la sistemo estas tiel kompleksa.

Kiel klarigite de Mr. waddlesplash:

Kelkfoje ekzistas aplikaĵoj, kiujn aliaj aplikoj bezonas sed ne estas en la menuo. Ekzemple, LegacyPackageInstaller en via ekrankopio, prilaborante .pkg-arkivojn en BeOS-formato. Mi ŝatus, ke uzantoj instalu ilin, sed ilia ĉeesto en la menuo kondukos al konfuzo.

Ial ŝajnas al mi, ke ekzistas pli simpla solvo, ekzemple Hidden=true en dosieroj .desktop sur Linukso. Kial ne fari la "kaŝitajn" informojn rimedo kaj atributo de la dosiersistemo?

Kio precipe ne estas subtila estas la nomo de (iu) aplikaĵo, kiu montras la menuon, deskbar, rigide ligita survoje.

s-ro. waddlesplash klarigas ĉi tion:

"Tabultabulo" ĉi-kaze devus esti komprenata kiel speco de ĝenerala termino (en la sama maniero kiel "taskbaro", kiu rilatas kaj al la Vindoza aplikaĵo kaj al la ĝenerala koncepto). Nu, ekde ĉi tio deskbar, ne "Deskbar", ĉi tio ankaŭ povas esti komprenata simile.

Mia kvina tago kun Hajko: ni portu kelkajn programojn
2 "preskaŭ identaj" dosierujoj kun aplikaĵoj en ili

Kial estas 2 dosierujoj kun aplikaĵoj, kaj ankaŭ kial mia QtQuickApplication estas en unu, sed ne en la alia? (Fin tio ĉi ne estas unu sistemo, sed dua uzanta, kio estus komprenebla por mi persone).
Mi estas vere konfuzita kaj mi pensas, ke ĉi tio devus esti unuigita.

komento de s-ro. waddlesplash

La Apps-katalogo enhavas aplikaĵojn, kiuj ne estas bezonataj en la menuo. Sed la situacio kun la menuo vere devas esti plibonigita, por igi ĝin pli agordebla.

Apliko, aŭ ĝi ne okazos 😉

Mi demandis min: ĉu vere necesas gastigi aplikaĵojn enen /system/apps, se uzantoj vidas ilin tie, ĝi estas nedezirinda. Eble estus pli bone meti ilin en alian lokon, kie la uzanto ne renkontos ilin? Same kiel ĝi estas farita en Mac OS X, kie la enhavo de pakoj .app, kiu ne devus esti videbla por la uzanto en /Applications, kaŝante en la profundoj de /System/Library/…“`.

Kio pri dependecoj?

Mi pensas, ke indas iel precizigi la dependecojn, ĉu ne? Ĉu Qt povas esti konsiderata deviga parto de la Haiku-instalaĵo defaŭlte? Ne! Qt ne estas instalita defaŭlte. Ĉu pakkonstruanto povas aŭtomate detekti dependecojn kontrolante ELF-dosierojn? Oni diris al mi, ke HaikuPorter efektive faras tion, sed package Ne. Tio estas ĉar ĝi estas nur "pakaĵkonstruanto", kiu nur kreas dosierojn memstare hpkg.

Ĉu Hajko devus esti pli kompleksa aldonante politikon, ke pakaĵo ne havu dependecojn de pakaĵoj ekster Hajko? haikuports? (Mi ŝatus, ĉar tia politiko multe plifaciligus la aferojn - la sistemo kapablus aŭtomate solvi la dependecojn de ĉiu pakaĵo elŝutita de ie ajn, sen fuŝi kun pliaj pakaĵfontoj.)

s-ro. waddlesplash klarigas:

Ni ne ŝatus tiom limigi la liberecon de programistoj, ĉar estas evidente, ke se CompanyX volas subteni sian propran programaron kun dependecoj (kaj do deponejo), ĝi faros tion tute libere.

En tiu kazo, eble indas rekomendi, ke triapartaj pakaĵoj evitu dependecojn de io ajn ne inkluzivita en haikuports, tute enpakante ĉion necesan kun la aplikaĵo. Sed mi pensas, ke ĉi tio estas temo por estonta artikolo en ĉi tiu serio. [Ĉu la aŭtoro iras al AppImage? — ĉ. tradukisto]

Aldono de aplika ikono

Kio se mi volas aldoni unu el la belaj enkonstruitaj ikonoj al la rimedoj de mia lastatempe kreita aplikaĵo? Montriĝas, ke ĉi tio estas mirinda temo, do ĝi estos la bazo por la sekva artikolo.

Kiel organizi kontinuajn aplikaĵkonstruaĵojn?

Imagu projekton kiel Inkscape (jes, mi konscias, ke ĝi ankoraŭ ne haveblas en Hajko, sed estas oportune montri ĝin sur ĝi). Ili havas fontkodon deponejon https://gitlab.com/inkscape/inkscape.
Ĉiufoje kiam iu faras siajn ŝanĝojn al la deponejo, konstruo-duktoj estas lanĉitaj, post kiuj la ŝanĝoj estas aŭtomate testitaj, konstruitaj, kaj la aplikaĵo enpakita en diversajn pakaĵojn, inkluzive de AppImage por Linukso (memstara aplikaĵpakaĵo kiu povas esti elŝutita por loka testado sendepende. kio povas aŭ ne esti instalita en la sistemo [Mi sciis ĝin! — ĉ. tradukisto]). La sama afero okazas kun ĉiu peto kunfandi de branĉo, do vi povas elŝuti la aplikaĵon konstruitan el la kodo proponita en la peto kunfandi antaŭ ol kunfandi.

Mia kvina tago kun Hajko: ni portu kelkajn programojn
Kunfandi petojn kun konstruaj statoj kaj la kapablo elŝuti la kompilitajn binarojn se la konstruo sukcesas (markite verde)

La konstruo funkcias en Docker-ujoj. GitLab ofertas senpagajn kuristojn en Linukso, kaj mi pensas, ke eble estos inkluzivi viajn proprajn kuristojn (cetere, mi ne vidas kiel tio funkcius por sistemoj kiel Hajko, kiuj mi scias ne havas Docker aŭ ekvivalenton, sed ankaŭ por FreeBSD ne ekzistas Docker, do ĉi tiu problemo ne estas unika al Hajko).

Ideale, Haiku-aplikoj povas esti konstruitaj ene de Docker-ujo por Linukso. En ĉi tiu situacio, la asembleo por Hajko povas esti enkondukita en ekzistantaj duktoj. Ĉu ekzistas kruc-kompililoj? Aŭ ĉu mi kopiu ĉiujn Hajkojn ene de Docker-ujo uzante ion kiel QEMU/KVM (supoze ke ĝi funkcios tiel ene de Docker)? Cetere, multaj projektoj uzas similajn principojn. Ekzemple, Scribus faras tion - ĝi jam haveblas por Hajko. Iun tagon venos la tago, kiam mi povos sendi tia Tiru petojn al aliaj projektoj por aldoni Haiku-subtenon.

Unu el la programistoj klarigas:

Por aliaj projektoj dezirantaj mem krei pakaĵojn, la regula CMake/CPack-metodo estas subtenata. Aliaj konstrusistemoj povas esti subtenataj per vokado de la konstruprogramo de la pakaĵo rekte, kio estas bone se homoj interesiĝas pri ĝi. Sperto montras: ĝis nun ne estis multe da intereso, do haikuporter funkciis kiel oportune por ni, sed, finfine, ambaŭ metodoj devus funkcii kune. Ni devus enkonduki aron da iloj por interkonstrua programaro de Linukso aŭ ajna alia servila operaciumo (Hajko ne estas desegnita por funkcii per serviloj).

Mi donas ovacion. Regulaj uzantoj de Linukso portas ĉi tiun aldonan ŝarĝon kaj aldonan bagaĝon (sekureco, strikta kontrolo, ktp.), kiuj estas necesaj por servila operaciumo, sed ne por persona. Do mi tute konsentas, ke povi konstrui Haiku-apojn en Linukso estas la vojo.

konkludo

Porti POSIX-aplikaĵojn al Hajko eblas, sed eble estas pli multekosta ol tipa rekonstruo. Mi certe longe restus pri tio, se ne estus la helpo de homoj de la kanalo #haiku en la reto irc.freenode.net. Sed eĉ ili ne ĉiam tuj vidis, kio estas malbona.

Aplikoj skribitaj en Qt estas facila escepto. Mi kunmetis simplan demo-aplikaĵon sen problemoj.

Konstrui pakaĵon por simplaj aplikoj ankaŭ estas sufiĉe facila, sed nur por "tradicie liberigitaj", t.e. havante versionitajn fontkodarkivojn destinitajn por subteno en haikuports. Por daŭra konstruo (konstruo por ĉiu kompromiso de ŝanĝoj) kun GitHub, ĉio ŝajnas ne tiel simpla. Ĉi tie Haiku sentas pli kiel Linuksa distribuo ol la rezulto en Mac, kie kiam vi alklakas la butonon "Konstrui" en XCode, vi ricevas pakaĵon. .app, preta por esti enmetita en diskobildon .dmg, preta por elŝuto en mia retejo.
Daŭra konstruado de aplikaĵoj bazitaj sur "servilo" operaciumo, ekzemple, Linukso, plej verŝajne fariĝos ebla se estos postulo de programistoj, sed nuntempe la Haiku-projekto havas aliajn, pli urĝajn taskojn.

Provu ĝin mem! Post ĉio, la Haiku-projekto provizas bildojn por ekfunkciigo de DVD aŭ USB, generitaj ĉiutaga. Por instali, simple elŝutu la bildon kaj bruligu ĝin al USB-memorilo uzante Etcher

Ĉu vi havas demandojn? Ni invitas vin al la ruslingva telegramkanalo.

Superrigardo de eraroj: Kiel pafi vin en la piedon en C kaj C++. Kolekto de Receptoj de Haiku OS

el la verkisto traduko: jen la kvina artikolo en la serio pri Hajko.

Listo de artikoloj: La unua La dua La tria Kvara

fonto: www.habr.com

Aldoni komenton