Mano penkta diena su Haiku: perkelkime keletą programų

Lt; DR: Naujokas pirmą kartą pamatė Haiku, bandydamas perkelti kai kurias programas iš Linux pasaulio.

Mano pirmoji perkelta programa Haiku, supakuota hpkg formatu

Neseniai Atradau Haiku – stebėtinai gerą operacinę sistemą kompiuteriams.
Šiandien išmoksiu, kaip į šią operacinę sistemą perkelti naujas programas. Pagrindinis dėmesys skiriamas pirmosios perėjimo prie Haiku patirties aprašymas Linux kūrėjo požiūriu. Atsiprašau už visas kvailas klaidas, kurias padariau pakeliui, nes nepraėjo nė savaitė, kai pirmą kartą atsisiunčiau Haiku.

Noriu pasiekti tris tikslus:

• Prijunkite paprastą CLI programą
• Programos perkėlimas iš GUI į Qt
• Tada supakuokite juos hpkg formatu (nes vis dar galvoju apie AppDir ir AppImage pritaikymą Haiku...)

Pradėkime. Skyriuose dokumentacija и plėtrą, taip pat in wiki iš HaikuPorts radau teisingą kryptį. Yra net internetinė PDF knyga BeOS: „Unix“ programos perkėlimas.
467 puslapiai – ir tai nuo 1997 m.! Baisu žiūrėti į vidų, bet tikiuosi geriausio. Kūrėjo žodžiai padrąsina: „užtruko ilgai, nes BeOS nebuvo suderinamas su POSIX“, tačiau „Haiku“ „daugiausia“ jau toks.

Paprastos CLI programos perkėlimas

Pirma mintis buvo perkelti programą avrdude, bet, kaip paaiškėjo, tai jau yra pagamintas prieš daug laiko.

Pirmas bandymas: nėra ko žiūrėti

Ko aš negaliu suprasti, tai jau Programos buvo perkeltos į Haiku daugiau nei 10 metų - nepaisant to, kad pati OS dar nėra net 1.0 versija.

Antras bandymas: reikia perrašyti

Taigi naudosiu ptouch-770, CLI, skirtas valdyti Brother P-Touch 770 spausdintuvą, kurį naudoju etikečių spausdinimui.
Ant jos spausdinu įvairias etiketes, galbūt jau matėte ankstesniame straipsnyje. Šiek tiek anksčiau aš parašiau nedidelę GUI įvyniojimo programą Python (kadangi ji yra Gtk+, ją reikės perrašyti, ir tai yra gera priežastis mokytis).

Brother P-Touch 770 etikečių spausdintuvas. Ar jis veiks su Haiku?

Haiku paketų tvarkyklė žino apie bibliotekas ir komandas, taigi, jei paleisdamas gaunu pranešimą „nerandu libintl“ configure - Ką tik paleidžiu pkgman install devel:libintl ir bus rasta reikiama pakuotė. taip pat pkgman install cmd:rsync. Na ir t.t.

Išskyrus atvejus, kai tai neveikia:

/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

Galbūt udev yra per daug pagrįstas „Linux“ ir todėl neegzistuoja Haiku. Tai reiškia, kad turiu redaguoti šaltinio kodą, kurį bandau kompiliuoti.
Ech, tu negali peršokti per galvą, ir aš net nežinau, nuo ko pradėti.

Trečias bandymas

Būtų malonu turėti tmate Haiku, tada leisčiau Haiku kūrėjams prisijungti prie mano terminalo seanso - jei kas nors nutiktų. Instrukcijos yra gana paprastos:

./autogen.sh
./configure
make
make install

Atrodo gerai, tad kodėl gi nepabandžius ant 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

Šiame žingsnyje atidarau HaikuDepot ir ieškau curses.
Kažkas buvo rastas, o tai davė užuominą į kompetentingesnę užklausą:

/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

Vėl nuėjau į HaikuDepot ir, žinoma, radau devel:msgpack_c_cpp_devel. Kokie tai keisti vardai?

/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

Šiame žingsnyje supratau, kad programos perkėlimas į Haiku reikalauja daug daugiau žinių, nei reikia paprastam atkūrimui.
Kalbėjausi su draugiškais Haiku kūrėjais, paaiškėjo, kad msgpack yra klaida, o po kelių minučių matau pataisą HaikuPorts. Savo akimis matau, kaip pakoreguota pakuotė einu čia (buildslave – virtualios mašinos).

Pataisyto msgpack kūrimas naudojant buildmaster

Tarp kartų siunčiu pleistrą į prieš srovę pridėti Haiku palaikymą prie msgpack.

Po penkių minučių atnaujintas msgpack jau pasiekiamas 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.

Netikėtai geras. Ar aš taip sakiau?!

Grįžtu prie pradinės problemos:

/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

Dabar atrodo, kad msgpack nėra kaltas. Aš komentuoju IMAXLABEL в tty.c taip:

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

Rezultatas:

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.

Na, štai ir vėl... Beje:

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

Ponas. vandens purslai pasako kur kasti:

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

Čia aš paskelbiau config.log.

Jie man paaiškino, kad be libresolv Haiku tinkle yra dar kažkas. Matyt, kodą reikia redaguoti toliau. Reikia pagalvoti…

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

Amžinas klausimas: kas vyksta?

/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, tik profilyje. Google ir rado tai. Jei pridėsite -lssp „Kartais“ padeda, bandau:

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

Oho! Tai prasideda! Bet…

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

Pabandysiu derinti failas čia:

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

„Blogas prievado ID“ jau yra kaip vizitinė kortelė haiku. Gal kas turi minčių kas negerai ir kaip ją ištaisyti? Jei taip, atnaujinsiu straipsnį. Nuoroda į GitHub.

GUI programos perkėlimas į Qt.

Aš renkuosi paprastą QML programą.

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

Tikrai paprasta. Mažiau nei minutė!

Programų pakavimas hpkg naudojant haikuporter ir haikuports.

Nuo ko turėčiau pradėti? Nėra paprastos dokumentacijos, einu į #haiku kanalą irc.freenode.net ir girdžiu:

• Komanda package - žemo lygio paketų kūrimo būdas. Jai dažniausiai užtenka „PackageInfo“, kaip aprašyta skyriuje „Padaryti tinkamą .hpkg pakuotę“
• Man reikia ką nors padaryti tokių
• Gali naudoti hpkg kūrėjas (man sugenda, klaidų pranešimas)

Neaišku ką daryti. Manau, man reikia „Hello World“ stiliaus pradedančiųjų vadovo, geriausia – vaizdo įrašo. Būtų gerai, kad taip pat būtų patogu susipažinti su HaikuPorter, kaip tai daroma GNU hello.

Skaičiau štai ką:

haikuporter yra įrankis bendriems Haiku paketų projektams kurti. Jis naudoja HaikuPorts saugyklą kaip visų paketų bazę. Haikuporter receptai naudojami kuriant pakuotes.

Be to, sužinojau, kad:

Nereikia saugoti receptų HaikuPorts saugykloje. Galite sukurti kitą saugyklą, įdėti į ją receptus ir tada nukreipti į ją haikuporter.

Kaip tik tai, ko man reikia – jei neieškau būdo viešai išleisti paketą. Bet tai jau kito įrašo tema.

Haikuporterio ir haikuportų montavimas

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

Recepto rašymas

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
}

Recepto surinkimas

Išsaugau failą pavadinimu QtQuickApp-1.0.recipe, po kurio paleidžiu aikuporter -S ./QuickApp-1.0.recipe. Tikrinamos visų saugykloje esančių paketų priklausomybės haikuportai, tai užtrunka šiek tiek laiko. Eisiu išgerti kavos.

Kodėl po velnių šis patikrinimas turėtų būti atliekamas mano vietiniame kompiuteryje, o ne centralizuotai serveryje kartą visiems?

Pasak p. waddlesplash:

Su tokia, kad galėtumėte perrašyti bet kurį saugykloje esantį failą 😉 Tai galite šiek tiek optimizuoti, prireikus paskaičiuodami reikiamą informaciją, nes paskutiniai pakeitimai yra gana 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

Pasirodo, nėra tokio dalyko kaip įprastas recepto failas, kuriame būtų jūsų programos šaltinio kodas. Turite jį laikyti HaikuPorts formato saugykloje.

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

Dėl šio fakto surinkimas tampa sudėtingesnis. Man tai nelabai patinka, bet manau, kad tai būtina, kad galiausiai visa atvirojo kodo programinė įranga atsirastų HaikuPorts.

Gaunu šiuos dalykus:

~/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 negerai? Perskaitęs irc darau:

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

Iškilo įdomus klausimas. Jei prie recepto pridėsiu kontrolinę sumą – ar ji atitiks naujausią nuolatinio integravimo git įsipareigojimą? (Kūrėjas patvirtina: „Tai neveiks. Receptai sukurti taip, kad būtų gana stabilūs.“)

Kad būtų smagu, pridėkite prie recepto:

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Vis dar nepatenkintas:

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

Ką jis daro? Juk čia git saugykla, kodas jau yra tiesiogiai, nėra ką išpakuoti. Mano požiūriu, įrankis turėtų būti pakankamai protingas, kad neieškotų išpakavimo, jei jis yra virš GitHub URL.

Galbūt uri git:// veiks

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

Dabar skundžiasi taip:

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

Hmm, kodėl viskas taip sudėtinga, kodėl negalima „tiesiog dirbti“? Galų gale, nėra taip neįprasta ką nors sukurti iš „GitHub“. Nesvarbu, ar tai įrankiai, kurie veikia iš karto, nereikalaujant sąrankos, ar kaip aš tai vadinu „nerimavimu“.

Gal tai veiks taip:

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

Ne. Aš vis dar gaunu šią keistą klaidą ir darau kaip čia aprašyta

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

Judu šiek tiek toliau, bet kodėl jis ant manęs rėkia (GitHub nėra saugus!) ir vis dar bando ką nors išpakuoti.

Pagal Ponas. vandens purslai:

Na taip, priežastis buvo noras patikrinti surinkimui gautų duomenų vientisumą. Viena iš variantų yra patikrinti archyvo kontrolinę sumą, tačiau, žinoma, galite maišyti atskirus failus, kurie nebus įdiegti, nes tai užtrunka daug ilgiau. To pasekmė yra „git“ ir kitų VCS „nesaugumas“. Greičiausiai taip bus visada, nes archyvo kūrimas „GitHub“ yra gana paprastas ir dažnai greitesnis. Na, o ateityje gal klaidos pranešimas nebebus toks ryškus... (HaikuPorts tokių receptų nebejungiame).

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

Iš seno įpročio einu klausti gerų žmonių #haiku kanale irc.freenode.net tinkle. O kur aš būčiau be jų? Po užuominos supratau, kad turėčiau naudoti:

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

Gerai, tapo aišku, ką jis daro – atsisiunčia archyvą su tam tikros versijos šaltinio kodu. Mano akimis žiūrint, tai kvaila ir ne visai tai, ko norėjau, būtent atsisiųsti naujausią versiją iš pagrindinės šakos.

Vienas iš kūrėjų tai paaiškino taip:

Turime savo CI, todėl viskas, kas patalpinta į „haikuports“ saugyklą, bus supakuota visiems vartotojams, todėl nenorime rizikuoti rinkdami ir pristatydami „viską naujausioje versijoje prieš srovę“.

Supratau! Bet kokiu atveju atsitiko štai kas:

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

Tai kartojasi iki begalybės. Matyt, tai klaida (ar yra programa? Neradau).

С haikuporter ir saugykla haikuportai Jame nėra „tiesiog veikia“ jausmo, tačiau kaip kūrėjas man patinka kai kurie dalykai dirbant su Haiku. Daugeliu atvejų jis panašus į „Open Build Service“ – įrankių rinkinį, skirtą „Linux“ versijų kūrimui: itin galingas, su sistemingu požiūriu, tačiau perteklinis mano mažajai „hello world“ programai.

Vėlgi, pasak p. waddlesplash:

Iš tiesų, HaikuPorter pagal numatytuosius nustatymus yra gana griežtas (be to, yra pūkelių režimas ir griežtas režimas, kad jis būtų dar griežtesnis!), bet tik todėl, kad sukuria paketus, kurie veiks, o ne tik sukuria paketus. Štai kodėl jis skundžiasi nedeklaruotomis priklausomybėmis, netinkamai importuotomis bibliotekomis, neteisingomis versijomis ir pan. Tikslas yra pagauti visas problemas, įskaitant ir būsimas, prieš vartotojui apie tai sužinojus (todėl avrdude nebuvo įmanoma įdiegti, nes priklausomybė iš tikrųjų buvo nurodyta recepte). Bibliotekos nėra tik atskiri paketai ar net konkrečios SO versijos. HaikuPorter užtikrina, kad visa tai būtų laikomasi pačiuose receptuose, kad būtų išvengta klaidų vykdymo metu.

Iš principo toks griežtumo lygis yra pateisinamas kuriant operacinę sistemą, tačiau man tai atrodo nereikalinga „labas pasaulis“ programai. Nusprendžiau išbandyti ką nors kita.

Programų kūrimas hpkg formatu naudojant komandą „paketo kūrimas“.

Gal būt, tai Ar paprastos instrukcijos man tiks geriau?

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

Netikėtai greita, netikėtai paprasta, netikėtai efektyvu. Kaip man patinka, nuostabu!

Montavimas – kas ir kur?

Failas QtQuickApp.hpkg perkeltas į ~/config/packagesnaudojant failų tvarkyklę, po kurios stebuklingai pasirodė QtQuickApp ~/config/apps.
Vėlgi, netikėtai greitai, paprastai ir efektyviai. Nuostabu, neįtikėtina!

Bet... (kur mes būtume be jų!)

Programos vis dar nėra programų meniu sąraše ir „QuickLaunch“. Manau, kad jau žinau, kaip tai ištaisyti. Failų tvarkyklėje perkeliu QtQuickApp.hpkg iš ~/config/packages į /system/packages.

Ne, vis dar trūksta. Matyt, aš (na, ir instrukcijos) kažką praleidau.

Pažiūrėjęs į „HaikuDepot“ skirtuką „Turinys“, ar nėra kitų programų, pamačiau, kad yra tokių failų kaip /data/mimedb/application/x-vnd... kas dar nuostabiau yra /data/deskbar/menu/Applications/….

Na, ką man ten įdėti? Nagi...

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

Esu visiškai tikras, kad šis triukas pasiteisins, tačiau lieka klausimų: kam tai reikalinga, kam tai reikalinga? Manau, kad tai sugadina bendrą įspūdį, kad sistema yra tokia sudėtinga.

Kaip paaiškino p. waddlesplash:

Kartais yra programų, kurių reikia kitoms programoms, bet kurių meniu nėra. Pavyzdžiui, LegacyPackageInstaller ekrano kopijoje, apdoroja .pkg archyvus BeOS formatu. Norėčiau, kad vartotojai juos įdiegtų, tačiau jų buvimas meniu sukels painiavą.

Kažkodėl man atrodo, kad yra paprastesnis sprendimas, pvz Hidden=true failuose .desktop Linux sistemoje. Kodėl nepadarius „paslėptos“ informacijos failų sistemos šaltiniu ir atributu?

Tai, kas nėra subtilu, yra (kai kurios) programos, rodančios meniu, pavadinimas, deskbar, pakeliui standžiai surištas.

Ponas. waddlesplash paaiškina tai:

„Darbalaukio juosta“ šiuo atveju turėtų būti suprantama kaip tam tikras bendras terminas (panašiai kaip „užduočių juosta“, kuri reiškia ir „Windows“ programą, ir bendrą koncepciją). Na, nuo šito deskbar, o ne „Deskbar“, tai taip pat galima suprasti panašiai.

2 „beveik identiški“ katalogai su juose esančiomis programomis

Kodėl yra 2 katalogai su programomis ir kodėl viename yra mano QtQuickApplication, o kitame ne? (Juk čia ne vienos sisteminės, o antrojo vartotojo, kas man asmeniškai būtų suprantama).
Aš tikrai sutrikęs ir manau, kad tai turėtų būti vieninga.

komentaras p. vandens purslai

Programų kataloge yra programų, kurių meniu nereikia. Tačiau situaciją su meniu tikrai reikia pagerinti, padaryti jį labiau pritaikytą.

Paraiška, arba to nebus 😉

Susimąsčiau: ar tikrai reikia talpinti programas /system/apps, jei vartotojai juos mato, tai nepageidautina. Gal geriau juos patalpinti kitoje vietoje, kur vartotojas su jais nesusidurs? Lygiai taip pat, kaip tai daroma Mac OS X, kur paketų turinys .app, kurios vartotojas neturėtų matyti /Applications, slepiasi /System/Library/…“’ gilumoje.

O kaip su priklausomybėmis?

Manau, verta kažkaip patikslinti priklausomybes, tiesa? Ar Qt gali būti laikomas privaloma Haiku diegimo dalimi pagal numatytuosius nustatymus? Ne! Qt nėra įdiegtas pagal numatytuosius nustatymus. Ar paketų kūrėjas gali automatiškai aptikti priklausomybes tikrindamas ELF failus? Man buvo pasakyta, kad HaikuPorter iš tikrųjų tai daro, bet package Nr. Taip yra todėl, kad tai tik „paketų kūrėjas“, kuris tik pats kuria failus hpkg.

Ar Haiku reikėtų patobulinti pridedant politiką, kad paketas neturėtų priklausyti nuo paketų, nepriklausančių Haiku? haikuports? (Norėčiau, nes tokia politika viską labai palengvintų – sistema galėtų automatiškai išspręsti kiekvieno iš bet kur atsisiųsto paketo priklausomybes, nesimaišydama su papildomais paketų šaltiniais.)

Ponas. waddlesplash paaiškina:

Nenorėtume taip apriboti kūrėjų laisvės, nes akivaizdu, kad jei CompanyX norės palaikyti savo programinės įrangos rinkinį su priklausomybėmis (taigi ir saugykla), tai darys visiškai laisvai.

Tokiu atveju gali būti verta rekomenduoti, kad trečiųjų šalių paketai išvengtų priklausomybės nuo nieko, kas neįtraukta į haikuports, visiškai supakuojant viską, ko reikia su programa. Bet manau, kad tai yra būsimo šios serijos straipsnio tema. [Ar autorius eina link AppImage? - apytiksliai vertėjas]

Programos piktogramos pridėjimas

Ką daryti, jei noriu pridėti vieną iš tvarkingų integruotų piktogramų prie savo naujai sukurtos programos išteklių? Pasirodo, tai nuostabi tema, todėl tai bus kito straipsnio pagrindas.

Kaip organizuoti nuolatinį programų kūrimą?

Įsivaizduokite tokį projektą kaip „Inkscape“ (taip, žinau, kad Haiku jo dar nėra, bet patogu jame rodyti). Jie turi šaltinio kodo saugyklą https://gitlab.com/inkscape/inkscape.
Kiekvieną kartą, kai kas nors atlieka saugyklos pakeitimus, paleidžiami kūrimo konvejeriai, po kurių pakeitimai automatiškai testuojami, kuriami, o programa supakuojama į įvairius paketus, įskaitant „AppImage for Linux“ (atskiras programos paketas, kurį galima atsisiųsti vietiniam testavimui, nepaisant kas gali būti arba negali būti įdiegta sistemoje [Aš žinojau tai! - apytiksliai vertėjas]). Tas pats atsitinka su kiekviena filialo sujungimo užklausa, todėl prieš sujungdami galite atsisiųsti programą, sukurtą iš kodo, pasiūlyto sujungimo užklausoje.

Sujungti užklausas su kūrimo būsenomis ir galimybe atsisiųsti sukompiliuotus dvejetainius failus, jei kūrimas sėkmingas (pažymėtas žaliai)

Konstrukcija veikia Docker konteineriuose. „GitLab“ siūlo nemokamus „Linux“ bėgikus, ir manau, kad galbūt būtų įmanoma įtraukti savo bėgikus (beje, nesuprantu, kaip tai veiktų tokiose sistemose kaip „Haiku“, kurios, kaip žinau, neturi „Docker“ ar lygiavertės programos, bet taip pat FreeBSD nėra Docker, todėl ši problema būdinga ne tik Haiku).

Idealiu atveju „Haiku“ programas galima sukurti „Docker“ konteineryje, skirtame „Linux“. Esant tokiai situacijai, Haiku surinkimas gali būti įvestas į esamus vamzdynus. Ar yra kryžminių kompiliatorių? Ar turėčiau mėgdžioti visus Haiku „Docker“ konteineryje, naudodamas kažką panašaus į QEMU / KVM (darant prielaidą, kad tai veiks „Docker“ viduje)? Beje, daugelis projektų naudoja panašius principus. Pavyzdžiui, „Scribus“ tai daro – jis jau prieinamas Haiku. Vieną dieną ateis diena, kai galėsiu išsiųsti toks Ištraukite užklausas į kitus projektus, kad pridėtumėte Haiku paramą.

Vienas iš kūrėjų paaiškina:

Kitiems projektams, norintiems patys kurti paketus, palaikomas įprastas CMake/CPack metodas. Kitos kūrimo sistemos gali būti palaikomos tiesiogiai iškviečiant paketo kūrimo programą, o tai gerai, jei žmonės ja domisi. Patirtis rodo: kol kas didelio susidomėjimo nebuvo, todėl haikuporter veikė kaip mums patogu, bet galiausiai abu metodai turėtų veikti kartu. Turėtume pristatyti įrankių rinkinį kryžminiam programinės įrangos kūrimui iš Linux ar bet kurios kitos serverio operacinės sistemos (Haiku nėra skirtas veikti serveriuose).

Aš plojimais plojimais. Paprasti Linux vartotojai nešasi visą šį papildomą apkrovą ir papildomą bagažą (saugumas, griežta kontrolė ir pan.), kuris reikalingas serverio operacinei sistemai, bet ne asmeninei. Taigi aš visiškai sutinku, kad „Linux“ sistemoje galima kurti „Haiku“ programas.

išvada

POSIX programų perkėlimas į Haiku yra įmanomas, tačiau gali būti brangesnis nei įprastas atkūrimas. Man tai tikrai įstrigtų ilgam, jei ne žmonės iš #haiku kanalo irc.freenode.net tinkle. Tačiau net ir jie ne visada iš karto suprato, kas negerai.

Programos, parašytos Qt, yra lengva išimtis. Sukūriau paprastą demonstracinę programą be jokių problemų.

Sukurti paketą paprastoms programoms taip pat gana paprasta, tačiau tik „tradiciškai išleistoms“, t.y. turintys versijų šaltinio kodo archyvus, skirtus palaikyti haikuportuose. Atrodo, kad naudojant „GitHub“ nepertraukiamą kūrimą (kuriant kiekvieną pakeitimą), viskas nėra taip paprasta. Čia „Haiku“ labiau panašus į „Linux“ paskirstymą, o ne į „Mac“ rezultatą, kur „XCode“ spustelėję mygtuką „Sukurti“ gausite paketą .app, paruoštas įterpti į disko vaizdą .dmg, paruoštas atsisiųsti iš mano svetainės.
Nuolatinis programų kūrimas „serverio“ operacine sistema, pavyzdžiui, „Linux“, greičiausiai taps įmanomas, jei bus kūrėjų paklausa, tačiau šiuo metu „Haiku“ projektas turi kitų, svarbesnių užduočių.

Išbandykite patys! Galų gale, Haiku projektas pateikia vaizdus, ​​​​kuriuos galima paleisti iš DVD arba USB, sugeneruotus kasdien. Norėdami įdiegti, tiesiog atsisiųskite vaizdą ir įrašykite jį į „flash“ diską naudodami Etcher

Ar turite kokių nors klausimų? Kviečiame į rusakalbių telegramos kanalas.

Klaidų apžvalga: Kaip šaudyti sau į koją C ir C++ kalbomis. Haiku OS receptų rinkinys

Nuo autorius vertimas: tai penktasis straipsnis iš serijos apie Haiku.

Straipsnių sąrašas: pirmas Antrasis Третья Ketvirtasis

Šaltinis: www.habr.com