Paket aus neuerer Version

[KP97]

Das Originalpaket hast Du nicht zusätzlich, das wird ja mit --force-overwrite überschrieben.
Aber wenn das jetzt so läuft, ist es ja gut.

[frankw]

mit den Dateien aus dem Ursprungspaket habe ich es in dem Web-Container laufen...

Code: Alles auswählen

root@stretch-web:~# systemctl status lighttpd.service
● lighttpd.service - LSB: Start the lighttpd web server.
   Loaded: loaded (/etc/init.d/lighttpd; generated; vendor preset: enabled)
   Active: active (running) since Tue 2018-10-30 17:22:22 CET; 6s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 21424 ExecStart=/etc/init.d/lighttpd start (code=exited, status=0/SUCCESS)
 Main PID: 111 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/lighttpd.service
           ├─21444 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
           ├─21445 /usr/bin/php-cgi
           ├─21446 /usr/bin/php-cgi
           ├─21447 /usr/bin/php-cgi
           ├─21448 /usr/bin/php-cgi
           └─21449 /usr/bin/php-cgi

Okt 30 17:22:22 stretch-web systemd[1]: Starting LSB: Start the lighttpd web server....
Okt 30 17:22:22 stretch-web lighttpd[21424]: 2018-10-30 17:22:22: (configfile.c.56) Warning: please add "mod_openssl" to server.modules list in lighttpd.conf.  A future release of lighttpd 1.4.x *will not
Okt 30 17:22:22 stretch-web lighttpd[21424]: Starting web server: lighttpd2018-10-30 17:22:22: (configfile.c.56) Warning: please add "mod_openssl" to server.modules list in lighttpd.conf.  A future releas
Okt 30 17:22:22 stretch-web lighttpd[21424]: 2018-10-30 17:22:22: (configfile.c.1601) server.upload-dirs doesn't exist: /var/cache/lighttpd/uploads
Okt 30 17:22:22 stretch-web lighttpd[21424]: .
Okt 30 17:22:22 stretch-web systemd[1]: Started LSB: Start the lighttpd web server..

root@stretch-web:~# ls -l /usr/sbin/lighttpd 
lrwxrwxrwx 1 root root 18 Okt 30 17:12 /usr/sbin/lighttpd -> /opt/sbin/lighttpd
root@stretch-web:~# lighttpd -v
lighttpd/1.4.51 (ssl) - a light and fast webserver

muss die 3 Perl-Dateien jetzt nur noch in meine Deb reinbekommen...nur wie? mhm...scheinbar werden die configs in conf-enabled nicht geladen...argh

mhm...den alias für phpmyadmin frisst er, aber er öffnet es nicht (bekomme nur weiße seite...html-code scheint da zu sein)...ssl scheint zu funktionieren

bei git sagt er erkennt das repo nicht

[KP97]

Sind das nur Dateien? Schau nach, wo genau die im Originalpaket liegen.
Dann nimmst Du Dein selbst kompiliertes Paket, ab besten in einem getrennten Testordner, führst als root auf der Konsole
dpkg-deb -R <Dein Paket> <nochmal der Paketname>
aus. Dabei wird das Paket entpackt und ein gleichnamiger Ordner erstellt. Jetzt fügst Du die Dateien an den richtigen Platz ein.
Dann
dpkg-deb -b <nochmal der Paketname> (der Ordnername)
und damit werden die Dateien sauber in das wieder gepackte Paket eingefügt.

Was man mit Paketen bzw. dem Paketmanager anstellen kann, weiß ich wohl.
Was der Webserver alles können soll/muß, weiß ich eher nicht, da ich sowas nicht einsetze.
Zum Serverbetrieb kann evtl. jemand anders mehr sagen.

[frankw]

jo das sind nur dateien...im original landen die unter /usr/share/lighttpd bei mir jetzt unter /opt/share/lighttpd...im deb landet der man-ordner in share...aber das ist irgendwo definiert...im sourceverzeichnis habe ich keinen share-ordner

das Problem mit phpmyadmin hat sich mit aktivierung von debug.log-request-handling = "enable" erledigt...warum auch immer...jetzt wird die login-maske angezeigt

bei git ist noch was faul...ich weis nur nciht was...es wird an git-http-backend weitergereicht

Code: Alles auswählen

2018-10-30 17:47:11: (response.c.657) Basedir      : /usr/lib/git-core/git-http-backend 
2018-10-30 17:47:11: (response.c.658) Rel-Path     : /git/web_brk/info/refs 
2018-10-30 17:47:11: (response.c.659) Path         : /usr/lib/git-core/git-http-backend/web_brk/info/refs 
2018-10-30 17:47:11: (response.c.671) -- handling physical path 
2018-10-30 17:47:11: (response.c.672) Path         : /usr/lib/git-core/git-http-backend/web_brk/info/refs 
2018-10-30 17:47:11: (response.c.679) -- handling subrequest 
2018-10-30 17:47:11: (response.c.680) Path         : /usr/lib/git-core/git-http-backend 
2018-10-30 17:47:11: (response.c.681) URI          : /git 
2018-10-30 17:47:11: (response.c.682) Pathinfo     : /web_brk/info/refs 

ich vermute, es wird die variable nicht verwendet, da der Pfad /mnt/vcs/git nicht auftaucht

Code: Alles auswählen

server.modules += (
  "mod_cgi",
#  "mod_alias",
#  "mod_auth",
  "mod_setenv")

alias.url += ( "/git" => "/usr/lib/git-core/git-http-backend" )
$HTTP["url"] =~ "^/git" {
        cgi.assign = ("" => "")
        setenv.add-environment = (
                "GIT_PROJECT_ROOT" => "/mnt/vcs/git",
                "GIT_HTTP_EXPORT_ALL" => ""
        )
}

wenn mod_setenv fehlen würde würde der Server eigentlich nicht starten, oder?

[KP97]

Durch meinen Zusatz haben sich unsere Beiträge überschnitten.
Ich hätte das Paket nicht nach /opt gepackt, obwohl es der empfohlene Weg ist.
Bei einem prefix=/usr landen die Libs und alles andere immer am richtigen Platz, ohne Symlinks. Daß es Dein Paket ist, siehst Du dann an der vergebenen Version.
So mache ich das immer, und habe noch nie Probleme damit gehabt.

[frankw]

ok, um das nicht zu vermischen müsste ich nur wissen, wie ich die 3 Perl-scripte in die deb mit reinbekomme....den rest mache ich lieber in nem separaten Thread

wie gesagt share gibt es im Quell-verzeichnis nicht

[KP97]

Hatte ich bereits vorher beschrieben, hatte sich überschnitten.

[frankw]

sorry, habs übersehen...

Code: Alles auswählen

dpkg-deb -R lighttpd_1.4.51-1_armhf.deb lighttpd
mkdir -p lighttpd/opt/share/lighttpd/
cp missing/* lighttpd/opt/share/lighttpd/
dpkg-deb -b lighttpd lighttpd_1.4.51-1_armhf.deb

hat scheinbar funktioniert

Code: Alles auswählen

dpkg -c lighttpd_1.4.51-1_armhf.deb
...
drwxr-xr-x root/root         0 2018-10-30 18:28 ./opt/share/
drwxr-xr-x root/root         0 2018-10-30 18:37 ./opt/share/lighttpd/
-rwxr-xr-x root/root       461 2018-10-30 18:37 ./opt/share/lighttpd/create-mime.assign.pl
-rwxr-xr-x root/root       241 2018-10-30 18:37 ./opt/share/lighttpd/include-conf-enabled.pl
-rwxr-xr-x root/root       247 2018-10-30 18:37 ./opt/share/lighttpd/use-ipv6.pl

das muss ich jedoch jedesmal machen nachdem checkinstall das packet gebat hat...kann ich das nicht gleich für checkinstall hinterlegen? aber da muss ich vermutlich an das makefile ran, oder?

müsste auch für /etc noch einiges hinzufügen, wie ich merke...das wird durch mein Paket auch nicht angelegt

[KP97]

Ich würde das Verzeichnis nach make und vor checkinstall einfügen. Checkinstall kann ja nur von dem Vorhandenen ein Paket bauen, weitere Funktionen hat das Programm nicht.
Läuft denn jetzt alles wie gewünscht?

[frankw]

git will nicht so recht...aber das mache ich über den anderen Thread viewtopic.php?f=8&t=171109&p=1187663#p1187663

ich weis nur nicht, wie ich nach make die verzeichnisse richtig anlege...die man-pages liegen ja auch nicht unter share...ich vermute das ist im makefile definiert, wo was landet (für die install-regel, die checkinstall aufruft)

[pferdefreund]

Man könnte das Makefile entsprechend anpassen. Hab ich bei einfachen Sachen auch schon gemacht. Beim install-Ziel die Copy-Befehle mit dabei und sollte funktionieren.
Das sollte von checkinstall entsprechend erkannt werden.
Versuch macht kluch.

[KP97]

Ich würde das Verzeichnis nach make und vor checkinstall einfügen.

Quatsch, ein Denkfehler meinerseits. Da bleibt nur das makefile, hat @pferdefreund aber schon gesagt.

[frankw]

Man könnte das Makefile entsprechend anpassen. Hab ich bei einfachen Sachen auch schon gemacht. Beim install-Ziel die Copy-Befehle mit dabei und sollte funktionieren.
Das sollte von checkinstall entsprechend erkannt werden.
Versuch macht kluch.

das Makefile ist leider nur riesig und ich finde die richtige lokation nicht...hochladen geht hier im forum scheinbar nicht und beim nopaste-service kommt nur ne php-Fehlermeldung

Code: Alles auswählen

[phpBB Debug] PHP Warning: in file [ROOT]/ext/phpbbde/pastebin/controller/main.php on line 279: include_once(./includes/functions_upload.php): failed to open stream: No such file or directory
[phpBB Debug] PHP Warning: in file [ROOT]/ext/phpbbde/pastebin/controller/main.php on line 279: include_once(): Failed opening './includes/functions_upload.php' for inclusion (include_path='.:/usr/share/php')

habs jetzt hier: https://pastebin.com/WBjDhcAJ

lighttpd.service scheint auch zu fehlen...also das script für systemd und ein dutzend verzeichnisse (var/log/lighttpd,/var/run/lighttpd)...

kann ich mit obiger Methode nicht einfach das offizielle Packet entpacken und meins drüberwerfen und wieder neu packen? oder doch ein anderer Weg?

[KP97]

Durch das makefile mußt Du Dich selbst wühlen...
aber ich hatte doch zuvor schon geschrieben, daß ich es so machen würde:
1. Das offizielle Stretchpaket installieren
Dann schaust Du, ob die services und der Rest vorhanden ist. Zur Sicherheit noch eine Kopie irgendwohin schieben.
2. Dein kompiliertes Paket drüber schieben mit dpkg -i --force-overwrite <paketname>
Das überschreibt das vorhandene Paket, es ist also nichts doppelt. Wieder prüfen, ob alles vorhanden ist.
Sollten wider Erwarten die services oder was anderes fehlen, brauchst Du nur die gesicherten Dateien wieder zurückkopieren.

[MSfree]

Durch das makefile mußt Du Dich selbst wühlen...

Es gibt in Makefiles zwar keine Pflichteinträge, aber per Konvention sind die Targets all, clean, install und uninstall praktisch immer vorhanden.

Mit make oder make all wird die Software kompiliert und gelinkt.
Mit make install wird die Software installiert
Mit make uninstall wird das installierte wieder entfernt
Mit make clean werden die bei der Kompilation entstehenden Zwischendateien (.o, .a etc) gelöscht.

Wenn man also mit dem selbst kompilierten nicht den Weg über ein Debianpaket gehen will, reicht es, make uninstall aufzurufen. Man geht dann natürlich am Debian Paketmanagement vorbei, aber man braucht keine Angst zu haben, sich das System zu versauen.

[KBDCALLS]

make help gibts auch noch häufig.

[DeletedUserReAsG]

Wenn man also mit dem selbst kompilierten nicht den Weg über ein Debianpaket gehen will, reicht es, make uninstall aufzurufen. Man geht dann natürlich am Debian Paketmanagement vorbei, aber man braucht keine Angst zu haben, sich das System zu versauen.

Vorher prüfen, ob es das Target „uninstall“ tatsächlich gibt. Erstaunlich viele Entwickler gehen davon aus, dass man ihren Kram nicht wieder deinstallieren will. Einen Prefix in ein eigenes Verzeichnis, das man im Ganzen löschen kann, ist aus meiner Erfahrung heraus die bessere Wahl, wenn man kein Paket bauen mag/kann.

[MSfree]

Vorher prüfen, ob es das Target „uninstall“ tatsächlich gibt.

OK, guter Punkt.

Erstaunlich viele Entwickler gehen davon aus, dass man ihren Kram nicht wieder deinstallieren will.

Ich habe schon sehr viel selbst gebaut und auch wieder deinstalliert. Ein Makefile ohne uninstall ist mir bisher nicht in Erinnerung geblieben. make ist allerdings "case sensitive", also abhängig von Groß- und Kleinschreibung, und es kommt schonmal vor, daß das Target UNINSTALL oder auch Uninstall heißt.

[KBDCALLS]

kannst du mir das für lighttpd mit dem Prefix erklären?

Welches Buildsystem nutzt lighttpd?

muss ich die module auch mit bauen

hängt von den modulen ab

kan ich lighttpd auch vom host-rechner aus für armhf bauen (also via CROSS_COMPILE)

grundsätzlich kan man das. ob du’s kanst weiß ich nicht. toolchain schon installiert und getestet?

Mit qemu-user-static und pbuilder ist das machbar. Aus irgendeinem Grunde mochte er aptitude nicht und dh_missing ist im debhelper von Stretch nicht vorhanden aber in den Stretch-backports. Nach der Controldateidatei sind die Sourcen aber mit debhelper 9.20130624~ zufrieden.

[frankw]

das help-target gibt es nicht, und das install-target ist scheinbar nur umgeleitet

Code: Alles auswählen

install: install-recursive

und das target gibts scheinbar nicht... ;(

ich probiere jetzt mal das offizielle Packet zu installieren und meins drüber...muss nur vorher den Prefix wieder ändern und den lighty in meiner test-vm komplett entfernen und wieder komplett neu einrichten

dpkg -i --force-overwrite <paket> löscht alle dateien des Ursprungspacketes, die nicht geändert wurden...somit fehlen mir wieder die perl-scripte...auch ohne das ---force-overwrite

@kbdcalls danke dir, ich versuche erstmal lokal zu compilieren und den neuen lighttpd zum laufen zu bekommen...aber da fehlt einiges in dem Packet...deswegen würde ich gerne das bestehende Packet verwenden (entpacken) und irgendwie die compilierten binaries zu integrieren und neu zu packen...vom Prinzip her wie von kp97 hier geschrieben viewtopic.php?p=1187650#p1187650

nur wie kann ich da make install in den Ordner durchführen, wo ich das offizielle Packet entpackt habe

https://packages.debian.org/stretch/arm ... d/download

Code: Alles auswählen

root@stretch-dev:/usr/local/src# wget http://ftp.de.debian.org/debian/pool/main/l/lighttpd/lighttpd_1.4.45-1_armhf.deb
root@stretch-dev:/usr/local/src# dpkg-deb -R lighttpd_1.4.45-1_armhf.deb lighttpd_1.4.45
root@stretch-dev:/usr/local/src# ls -l lighttpd_1.4.45
insgesamt 20
drwxr-xr-x 2 root root 4096 Jan 14  2017 DEBIAN
drwxr-xr-x 6 root root 4096 Jan 14  2017 etc
drwxr-xr-x 3 root root 4096 Jan 14  2017 lib
drwxr-xr-x 5 root root 4096 Jan 14  2017 usr
drwxr-xr-x 5 root root 4096 Jan 14  2017 var

könnte mittels checkinstall das make install in die deb lenken, diese wieder entpacken und die entpackten Dateien über die anderen werfen, Control anpassen (version) und wieder packen, aber vielleicht gehts auch einfacher...

Code: Alles auswählen

dlopen() failed for: /opt/lib/mod_indexfile.so /opt/lib/mod_indexfile.so: cannot open shared object file:

scheinbar hat das configure mit /usr und make nicht gereicht....ich probiere es mit make clean vorher....

[KBDCALLS]

Sie meinen ?

Code: Alles auswählen

/usr/src/0961-qemu/qemu-2.12+dfsg$ make help
Generic targets:
  all             - Build all
  dir/file.o      - Build specified target only
  install         - Install QEMU, documentation and tools
  ctags/TAGS      - Generate tags file for editors
  cscope          - Generate cscope index

Cleaning targets:
  clean           - Remove most generated files but keep the config
  distclean       - Remove all generated files
  dist            - Build a distributable tarball

Test targets:
  check           - Run all tests (check-help for details)
  docker          - Help about targets running tests inside Docker containers
  vm-test         - Help about targets running tests inside VM

Documentation targets:
  html info pdf txt
                  - Build documentation in specified format

  make [targets]      (quiet build, default)
  make V=1 [targets]  (verbose build)
matthias@hannelore:/usr/src/0961-qemu/qemu-2.12+dfsg$ 

und

Code: Alles auswählen

./configure --help

[frankw]

so lighttpd läuft und für git war noch eine Änderung nötig (obwohl es ohne die 1 unter 1.4.45 funktioniert hat):

https://stackoverflow.com/questions/528 ... tenv-issue

Code: Alles auswählen

"GIT_HTTP_EXPORT_ALL" => "1"

konnte mein Repo jetzt pushen

Zusammengefasst habe ich jetzt das gemacht:

Code: Alles auswählen

#originalpacket runterladen und entpacken
root@stretch-dev:/usr/local/src# wget http://ftp.de.debian.org/debian/pool/main/l/lighttpd/lighttpd_1.4.45-1_armhf.deb
root@stretch-dev:/usr/local/src# dpkg-deb -R lighttpd_1.4.45-1_armhf.deb lighttpd_1.4.51_test
root@stretch-dev:/usr/local/src# ls -l lighttpd_1.4.51_test
insgesamt 20
drwxr-xr-x 2 root root 4096 Jan 14  2017 DEBIAN
drwxr-xr-x 6 root root 4096 Jan 14  2017 etc
drwxr-xr-x 3 root root 4096 Jan 14  2017 lib
drwxr-xr-x 5 root root 4096 Jan 14  2017 usr
drwxr-xr-x 5 root root 4096 Jan 14  2017 var
#dort nun die Versionsnummer in der DEBIAN/control ändern
#Version: 1.4.51-1
#da auch php5-cgi nicht mehr existiert habe ich das auch angepasst (auf php-cgi)

#nun die neue Version
#quellen in /etc/apt/sources.list nochmal als deb-src hinzufügen (vorhandene Zeilen kopieren und das -src ergänzen)
apt-get update
apt-get build-dep lighttpd
apt-get install wget
wget https://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.51.tar.gz -P /usr/local/src/
cd /usr/local/src/
sha256sum lighttpd-1.4.51.tar.gz #optional
tar -xf lighttpd-1.4.51.tar.gz
cd lighttpd-1.4.51
./configure --prefix=/usr --with-openssl --with-openssl-libs=/usr/lib/arm-linux-gnueabihf/  --with-webdav-props --with-webdav-locks
make

#lief das fehlerfrei durch per checkinstall ein Packet bauen, damit es nicht lokal installiert werden muss
checkinstall
#alles auf default lassen, da damit nur make install ins Packet reinläuft
#dieses entpacken wir jetzt und kopieren den inhalt über das alte
dpkg-deb -R lighttpd_1.4.51-1_armhf.deb lighttpd_1.4.51_unpack
cp -r lighttpd_1.4.51_unpack/usr/* lighttpd_1.4.51_test/usr/
#zum Schluss wieder packen
dpkg-deb -b lighttpd_1.4.51_test lighttpd_1.4.51-2_armhf.deb

[KBDCALLS]

Dir ist hoffentlich klar das lighttpd 11 Paketen besteht. Und da checkinstall als in ein Paket klatscht hast du garantiert so nicht alles erwischt was dazu gehört. Auch ist mindestens ein neues Modul dabei. Hab ich bei einem Test festgestellt in dem ich die Orignalsourcen genommen habe und die geupdated habe und anschließend kompiliert. Und außerdem ist checkinstall von 2010. Da ist die 1.6.2 das erste mal in Debian aufgetaucht. Und seitdem hat sich daran nix mehr getan. Außer das neuere Paketversionen erschienen sind. Mittlerweile ist das in Buster auch nicht mehr vorhanden. Dürfte demnächst sogar aus Sid rausfliegen. Und ich gehe mal davon aus mit komplexeren Paketen dürfte das auch sowieso überfordert sein.

PS. auf der Home von checkinstall ist 1.6.2 die letzte Version und die ist von 2009.

[frankw]

Jo, in debian sind für die einzelnen module separate Packete...ich habe ein Packet wo alles drin ist,was ich bei ./config angebe

Ein saubereren Weg habe ich noch nicht hinbekommen...das pbuilder erscheint mir recht komplex...auch weil da erstmal so ein init-script gebaut werden muss und pbuilder selbst einen dev-container erzeugt (habe ich schon in lxc)

Checkinstall nutze ich aktuell nur,um das make install umzulenken (container,welchen ich wieder entpacke um an die Verzeichnisstruktur ranzukommen,die das makefile erzeugt)

[KBDCALLS]

Man kann ja auch mit dpkg-buildpackage -us -uc kompilieren.

pbuilder hat im Grunde den Vorteil das ein Log geschrieben wir und auch gleich signiert wenn man will. Auch das buildinfo erstellt pbuilder. Hat auch noch den Vorteil man braucht die ganzen Pakete nicht auf seinem Rechner zu installieren die zum Kompilieren notwendig sind. Sondern die werden ins Image installiert und sind anschließend wieder weg, so das nur das Image als tar.gz Archiv übrig bleibt so wie man es erstellt hat. Und macht im Prinzip auch nichts anderes als obiges. Intern wird auch dpkg-buildpackage benutzt.

Es gibt aber php7.0-cgi, php7.2-cgi und php7.3-cgi

php5 wird demnächst in Rente geschickt und wird dann auch nicht mehr unterstützt.

https://www.heise.de/newsticker/meldung ... 91009.html