ubuntuusers.de

schily schrieb:

Vor 23 Jahren wurde mit SunOS-4.0 eingeführt man Pages nach /usr/share/man statt /usr/man zu packen. Nachdem dies nun faktisch alle Betriebssysteme nachgemacht haben und viele Peketierungssysteme sich darüber beschweren wenn man pages noch nach /usr/man getan werden, habe ich das letztes WE angepaßt.

ok, danke für den Hinweis. Ich hab den Wald vor lauter Bäumen nicht mehr gesehen, ich sollte eben nach der Arbeit erstmal ausschlafen und nicht mehr Pakete bauen 😉

Ich hab ein paar Sachen anpassen müssen (nicht am Quellcode!!) und schon gings

Da ich ohne Probleme Debian Pakete bauen konnte, gehe ich davon aus, daß Du irgendwo ein Skript hast, daß versucht die Man pages zu verschieben.... Achja, bitte füge noch STRIPFLAGS=-s bei "make install ..." hinzu und beim Kompilieren RUNPATH=

wie baust du die *.deb? Ich benutze ja dpkg-buildpackage -rfakeroot mit einem Haufen Zeugs in einem debian-Ordner, den ich einfach in den Entpackten Quellcode von dir Verschiebe...

OK, jetzt aber zum wichtigen:

ich hab neue debs gebaut vom a79-Paket von Schily mit dieser rules-Datei:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

#!/usr/bin/make -f
# -*- makefile -*-

# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1

# This has to be exported to make some magic below work.
export DH_OPTIONS

# These are used for cross-compiling and for saving the configure script
# from having to guess our platform (since we know it already)
DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)

CFLAGS = -Wall -g

ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
	CFLAGS += -O0
else
	CFLAGS += -O2
endif


#Architecture
build: build-arch

build-arch: build-arch-stamp
build-arch-stamp:
	smake INS_BASE=/usr DESTDIR=$(CURDIR)/debian/tmp
	touch $@

install-arch:
	dh_testdir
	dh_testroot
	dh_clean -k -s
	rm -rf debian/tmp/
	dh_installdirs -s
	smake INS_BASE=/usr DESTDIR=$(CURDIR)/debian/tmp STRIPFLAGS=-s install CCOM=gcc RUNPATH=
	# cleanup after smake
	install cdda2wav/cdda2ogg debian/tmp/usr/bin
	install cdda2wav/cdda2mp3 debian/tmp/usr/bin
	dh_install -s

binary-indep:
	# nothing to be done for install-indep

binary: binary-arch

clean:
	dh_testdir
	dh_testroot
	rm -f build-arch-stamp
	./.clean
	dh_clean


binary-arch: build-arch install-arch
	dh_testdir
	dh_testroot
	dh_installchangelogs AN-2.01.01a35
	dh_installdocs
	dh_installexamples
	dh_installman
	dh_link
	dh_strip
	dh_compress
	dh_fixperms
	dh_installdeb
	# XXX Look for an more elegant way to install as suid
	chmod 4755 debian/cdrecord/usr/bin/cdrecord
	dh_shlibdeps
	dh_gencontrol
	dh_md5sums
	dh_builddeb

.PHONY: build clean binary-indep binary-arch binary install install-indep install-arch

im Anhang das tar.bz2 (das install-Script ist wieder an Board) mit den ungestesteten 32-Bit-DEBS und das Log des Builds

ich bau grade die 64-bit DEBS auf einem Ubuntu Karmic 9.10, 64-Bit, Kernel 2.6.31-21-generic, da kommt es zu einer Fehlermeldung.

checking if Linux include file linux/ext2_fs.h is broken... yes
checking if Linux include file /usr/src/linux/include/linux/ext2_fs.h is broken... yes
checking if Linux include file scsi/scsi.h is broken... no
checking if Linux include file /usr/src/linux/include/scsi/scsi.h is broken... no
checking if Linux include file scsi/sg.h is broken... no
checking if Linux include file /usr/src/linux/include/scsi/sg.h is broken... no

Warning: *** /usr/src/linux/include contains broken include files ***
Warning: *** /usr/src/linux/include is not used this reason ***
Warning: This may result in the inability to use recent Linux kernel interfaces


Warning: *** linux/ext2_fs.h is not usable at all ***
Warning: *** This makes it impossible to support Linux file flags ***
You may try to compile using 'make COPTX=-DTRY_EXT2_FS'

Was bedeutet das? Kann ich COPTX=-DTRY_EXT2_FS einfach an die smake-Zeile anhängen und was bewirkt das dann? Die DEBS werden allerdings trotz dieses Fehlers erstellt.

Im Anhang das ganze Log

Antiqua schrieb:

wie baust du die *.deb? Ich benutze ja dpkg-buildpackage -rfakeroot mit einem Haufen Zeugs in einem debian-Ordner, den ich einfach in den Entpackten Quellcode von dir Verschiebe...

Ich habe ftp://ftp.berlios.de/pub/schily/ (allerdings eine noch nicht veröffentlichte Version) genommen und dann:

smake INS_BASE=/usr INS_RBASE=/ DESTDIR=/home/schily/debian/packages/schilyutils-test/ STRIPFLAGS=-s install CCOM=gcc RUNPATH= cd ~/debian/packages/ fakeroot dpkg-deb --build schilyutils-test

gemacht

Da fehlen halt Deine Symlinks und diverses Andere und da sind auch nicht die richtigen Files suid root.

Übrigens: alle Executables die von smake 0711 "installiert" wurden, benötigen 04711

Antiqua schrieb:

ich bau grade die 64-bit DEBS auf einem Ubuntu Karmic 9.10, 64-Bit, Kernel 2.6.31-21-generic, da kommt es zu einer Fehlermeldung.

checking if Linux include file linux/ext2_fs.h is broken... yes

Warning: *** /usr/src/linux/include contains broken include files ***
Warning: *** /usr/src/linux/include is not used this reason ***
Warning: This may result in the inability to use recent Linux kernel interfaces


Warning: *** linux/ext2_fs.h is not usable at all ***
Warning: *** This makes it impossible to support Linux file flags ***
You may try to compile using 'make COPTX=-DTRY_EXT2_FS'

Was bedeutet das? Kann ich COPTX=-DTRY_EXT2_FS einfach an die smake-Zeile anhängen und was bewirkt das dann? Die DEBS werden allerdings trotz dieses Fehlers erstellt.

Das ist nur für Programme nötig die wie star Unterstützung für ext2 Schnittstellen bieten.

Leider liefern ja seit 6 Jahren die Linux Kernel Leute in sich inkonsistente Kernel Include Files, die es daher unmöglich machen Programme zu schreiben die diese Schnittstellen nutzen. Für dioe meisten dieser Files bauen die Distros daher bug-fixes bevor sie sie ausliefern. Bei der Datei ext2_fs.h ist dies wojhl hier nicht geschehen.....

Im Zweifelsfall würde star daher keine Unterstützung für Linux-spezifische Dinge anbieten können - nunja dann wäre es in diesem Punkt nicht schlechter als GNU tar 😉

@ schily

ich interpretiere deine Aussage (danke dafür) mal so, dass das für die cdrtools nicht essentiell ist, die DEBS also voll funktionstüchtig sein müssten.

Also sozusagen Update 7 und 7½:

im Anhang die 64-Bit DEBS der cdrtools-2.01.01a79 für Ubuntu Jaunty bis zur Luzzie.

Die 32-Bit DEBS gibts hier und ein paar Postings weiter oben.

Die übliche Warnung:

Hallo,

sehr tolle Arbeit, aber eine Kleinigkeit ist mir aufgefallen: Die Abhängigkeit in deinem Paket zu libscg1 ist überflüssig, da du statisch linkst. Nur wenn du die cdrtools mit LINKMODE=dynamic kompilierst, sind die Libs zwingend erforderlich. (Dabei werden dann auch die .so Dateien generiert)

Man kann die Abhängigkeiten zu dynamischen Libs mit ldd prüfen

Statisch gelinktes cdrecord:

sudo ldd /usr/local/bin/cdrecord 

linux-gate.so.1 =>  (0x009c4000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x006ba000)
/lib/ld-linux.so.2 (0x00583000)

Dynamisch gelinktes cdrecord:

sudo ldd /usr/local/bin/cdrecord

linux-gate.so.1 =>  (0x00be0000)
libscgcmd.so.1.0 => /usr/local/lib/libscgcmd.so.1.0 (0x00c08000)
librscg.so.1.0 => /usr/local/lib/librscg.so.1.0 (0x00b83000)
libscg.so.1.0 => /usr/local/lib/libscg.so.1.0 (0x0039e000)
libedc_ecc.so.1.0 => /usr/local/lib/libedc_ecc.so.1.0 (0x00bb4000)
libcdrdeflt.so.1.0 => /usr/local/lib/libcdrdeflt.so.1.0 (0x00443000)
libdeflt.so.1.0 => /usr/local/lib/libdeflt.so.1.0 (0x009cd000)
libschily.so.1.0 => /usr/local/lib/libschily.so.1.0 (0x00b46000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x003e6000)

//Edit

Gleiches gilt auch für smake.

der_alex1980 schrieb:

Hallo,

sehr tolle Arbeit, aber eine Kleinigkeit ist mir aufgefallen: Die Abhängigkeit in deinem Paket zu libscg1 ist überflüssig, da du statisch linkst. Nur wenn du die cdrtools mit LINKMODE=dynamic kompilierst, sind die Libs zwingend erforderlich. (Dabei werden dann auch die .so Dateien generiert)

Man kann die Abhängigkeiten zu dynamischen Libs mit ldd prüfen

Ich bin bei cdrtools-3.0 auch für statisches Linken gegen die eigenen Libs. In der nächsten Entwicklungszeit wird sich einiges tun (z.B. plane ich die inzwischen auch vom GNU linker unterstützten Mapfiles zu nuztzen. Dazu müßen aber Platformspezifische Map Files gebaut werden und meine aktuelles Map Files sind aus der Zeit wo das nur Solaris konnte Solaris spezifisch). Also mit dem was nach 3.0 kommt gerne auch dynamich aber jetzt bringt es keine Vorteile.

Wichtig ist viel mehr: alle Binaries, die (bei Aufbau eines Prototypischen Dateibaums als nicht root) mit 0711 installiert werden, müßen suid root werden. Zur Zeit ist das in dem Paket nur cdrecord, es müßen aber auch readcd, cdda2wav und rscsi suid root installiert werden.

Ich finds ja wirklich toll, wieviel Mühe ihr euch macht

Antiqua schrieb:

OK, jetzt aber zum wichtigen:

aber das bringt alles nur wenig, wenn die cdrtools in der Form nicht in die Distri kommen. Da Jörg offenbar wenig bis keine Lust hat, da noch tätig zu werden (Nase voll?), habe ich mir mal erlaubt sein Zitat von der Vorseite in den Bugreport zu schreiben. Ich weiß nicht was und ob es was bringt, aber besser als gar nichts.

So, weitermachen... 😉

schily schrieb:

Wichtig ist viel mehr: alle Binaries, die (bei Aufbau eines Prototypischen Dateibaums als nicht root) mit 0711 installiert werden, müßen suid root werden. Zur Zeit ist das in dem Paket nur cdrecord, es müßen aber auch readcd, cdda2wav und rscsi suid root installiert werden.

cdrecord, readcd, cdda2wav werden bei meinen DEBs 4754 installiert, geregelt über postinst-scripte:

antiqua@aegyptine:~$ ls -al /usr/bin/{cdda2wav,cdrecord,readcd} 
-rwsr-xr-- 1 root cdrom 276288 2010-05-18 19:20 /usr/bin/cdda2wav
-rwsr-xr-- 1 root cdrom 398496 2010-05-18 19:20 /usr/bin/cdrecord
-rwsr-xr-- 1 root cdrom 247168 2010-05-18 19:20 /usr/bin/readcd

Ich dachte rscsi wird nur bei remote-Geschichten benutzt, deshalb hab ich da die Finger von gelassen. Wer das braucht, wird vermutlich auch keine Probleme haben, das Binary suid-root zu chmoden. Oder liege ich da falsch? Zumindest unter Slackware wird ja rscsi nicht mal mitgeliefert, deine Tools brennen aber trotzdem problemlos.

Über weiterführende Infos/Hintergründe würde ich mich freuen. Ich könnte zwar in den Sourcen lesen, würde aber großteils nur Böhmische Dörfer sehen...

der_alex1980 schrieb:

sehr tolle Arbeit,

danke für die Blumen, aber die meiste Arbeit haben andere gemacht. 😬

aber eine Kleinigkeit ist mir aufgefallen: Die Abhängigkeit in deinem Paket zu libscg1 ist überflüssig, da du statisch linkst. Nur wenn du die cdrtools mit LINKMODE=dynamic kompilierst, sind die Libs zwingend erforderlich. (Dabei werden dann auch die .so Dateien generiert)

stimmt, alles statisch gelinkt. Momentan stört es ja nicht (solange man das smake-deb von B.Snider nicht installiert hat). Ich lass das im Moment so, behalte es aber im Hinterkopf für zukünftige Versuche 😉

Thorsten Reinbold schrieb:

Ich finds ja wirklich toll, wieviel Mühe ihr euch macht aber das bringt alles nur wenig, wenn die cdrtools in der Form nicht in die Distri kommen.

Das kann ich leider nicht ändern. Eine Möglichkeit wäre zwar ein ppa, aber darauf hab ich keine Lust. Die andere Möglichkeit wären nur Druck auf Canonical von der User-Basis. Da sehe ich momentan auch keine Chance.

Die User sehen eben nur "Brennen geht → passt alles" oder "Brennen geht nicht → Linux ist Müll". Warum das Brennen nicht geht ist der zweiten Gruppe nach ein paar einfachen Versuchen egal. Die weitaus meisten wissen noch nicht mal, woran es liegt 😉

Da Jörg offenbar wenig bis keine Lust hat, da noch tätig zu werden (Nase voll?), habe ich mir mal erlaubt sein Zitat von der Vorseite in den Bugreport zu schreiben. Ich weiß nicht was und ob es was bringt, aber besser als gar nichts.

Wieso sollte der Autor der Software sich darum Kümmern, wer was in welche Distrie packt (ausser vielleicht, er wird um Hilfe gebeten). Wie ich hier in diesem Thread sehen kann, ist er ja durchaus Hilfsbereit und selbst in meinem Dilletanten-Projekt bereit zum geben von Infos und Tips. Aber warum sollte er jemanden Nachlaufen, der nichts von ihm will?

So, weitermachen... 😉

Gerne, wie siehts bei dir aus, brennen die Dinger Ordentlich?

Soweit alles gut. Das war auch keineswegs als Angriff auf Jörg gemeint, ich meinte eher daß ich nach den Angriffen und Verleumndungen gut verstehen kann, daß er die Nase voll hat...

Hallo,

hab jetzt mal die 32Bit 79er debs von Antiqua installiert und ausprobiert. Unter Lucid und Debian Sid (mit Experimental-Kernel).

Als "Versuchsobjekt" dienten Verbatim DVD+R DL Rohlinge und mein LG HL-DT-ST DVDRAM GH22LS50. Davon konnte ich bisher meistens jede zweite wegen Brennfehlern wegschmeißen, dachte immer, das liegt an den Rohlingen oder am Brenner. 😳

Lief jedenfalls alles problemlos durch.

Vielen dank für die Pakete. Weiter so. 👍

Und natürlich auch herzlichen Dank an schily. Ohne deine Arbeit wäre das ja gar nicht möglich.

Falls es interessiert (nichts weiter interessantes drin):

Debian-Sid-Log

Ubuntu-Lucid-Log

Ich habe jetzt eine 2.01.01a80-pre rausgestellt, und die wird vermutlich Mitte nächster Woche zu der 3.0-final.

Ich denke, wenn die fehlenden Binaries: cdda2wav, readcd und rscsi auch noch suid root installiert werden, dann ist das auch für die 3.0 so OK.

schily schrieb:

Ich habe jetzt eine 2.01.01a80-pre rausgestellt, und die wird vermutlich Mitte nächster Woche zu der 3.0-final.

ich hab mir die mal geholt und neue 32-Bit-DEBS gebaut, dabei wurde eine neuere smake-Version (Smake release 1.2.1) benutzt (bei deren Bau ich hoffentlich nix falsch gemacht habe ☺)

Änderungen gegenüber den a79-debs:

• Abhängigkeit zu libscg1 entfernt, da ja nicht notwendig wegen statisch gelinkten Binarys

• deshalb auch das libscg1.deb nicht mehr dabei

• rscsi wird suid root installiert, wie auch schon cdrecord, cdda2wav und readcd

• der Ordner /etc/cdrecord wird nicht mehr angelegt, da nicht notwendig

im Anhang das build-Log und die gepackten 32-Bit-Debs (wie immer mit install-Script) mit der Bitte um Testung

Also ich kann keine Probleme mehr finden!

Installiert habe ich es allerdings nicht, sondern nur Dein Paket inspiziert.

Wie/wo hast Du das eigentlich gebaut? Hast Du das zu Hause getan oder innterhalb einer Buildfarm?

Du hattest mal cdrtools-2.01.01a78-b.w.smake.tar.bz2 mit Deinen Skripten rausgegeben. Hast Du davon eigentlich eine aktualisierte Version?

@ schily

ich hab jetzt einfach mal das fehlende Zeugs in ein Archiv gepackt und angehängt. Ich geh mal davon aus, es passt, daß ich die original Sourcen nicht mit reingepackt habe. debian.tar.bz2 ist der Ordner, den ich einfach in deinen Sourcecode kopiere (entpackt natürlich) und dann lass ich rödeln. 😉

Bauen tu ich das Zeugs zu Hause in einer VirtualBox, die auf einer Slackware 12.2 läuft. Die 32-Bit debs baut ein Ubuntu 9.04 Jaunty 32-Bit, die 64-Bit baut ein Ubuntu 9.10 Karmic 64-Bit. Bei beiden wird mit dpkg-buildpackage gebaut und fakeroot benutzt. dpgk-buildbackage greift auf debhelper zurück. Der Aufruf ist, wie weiter oben schon genannt dpkg-buildpackage -rfakeroot > ../blablubb.w.smake-log 2>&1 im Verzeichnis mit den Sourcen.

Im moment bau ich grade die 64-Bit Debs. Allerdings wirfts mir da zum Schluss einen Fehler, weil ein kopieren von debian/manpages/cdda2ogg.1 ins normale man-Verzeichnis nicht klappt. Anscheinend wird beim builden, so wie ich es mache, kein debin/manpages und dessen Inhalt erstsllt. Komischerweise wird das mit exact den gleichen Sourcen und Scripten beim 32-Bittigem System problemlos gemacht... ich such noch nach dem Problem. Wenn ich nix finde, häng ich später mal das Build-log von 64-Bit an.