Debian, dist-upgrade: nul!

Kikou! sur #fr.comp.os.linux.debats, r3b3lz Michel Talon :))))) LOL!

Alors c'est -dvd 2 ou -dvd 3 etc. Oui c'est l'inconvénient de mplayer,
il faut faire des essais pour trouver le bon chiffre.

Tu m'a mal compris, je recommence : Sur le DVD que j'ai eu pour Noël,
MPlayer lit le bon chapitre (cad le film) avec la bande son du making-of
dés que je veux le mettre en VF.

En fait, lorsque je vois dans les menus de gmplayer : audio - français et
que je clique connement dessus j'estime avoir le droit légitime de croire
que je vais avoir du Français sans lire 10 pages de doc. Je suppose de même
que pour éviter les 30 secondes d'attente dues à l'éjection du DVD lors de
chaque changement de sous-titre, chapitre ou langue, (chaque fois que tu
clique sur >| tu attends 30 secondes - c'est trés chiant) il doit bien
exister une option genre --no-reread-dvd-when-option-change, mais dans la
mesure ou je n'ai pas eu ces problèmes avec xine, je m'estime fondé à dire
que xine est plus pratique pour lire un DVD que mplayer.

De plus l'avance rapide de xine est un régal de fluidité auquel je n'ai pas
trouvé d'équivalent sous mplayer dans lequel si tu cliques >> le film
avance de 5 secondes par saccades.


[libdvdread]

Je n'utilise pas cette librairie et mplayer marche parfaitement.

Les sources de MPlayer comprennent un répertoire libmpdvdkit dont le README
dit notamment:

What the hell is this?
===================== Nothing special, just a collection of sources and patches and fixes:

- dvdread 0.9.3 + static libdvdcss (removed dlopen code)
- libdvdcss 1.2.5

(etc .)

Or, soupconnant un bug bizarre, je voulais voir si libdvdread 0.9.4
fonctionnerait mieux, j'ai donc conformément à la doc, déplacé ce
répertoire pour utiliser la libdvdread du systéme.

Je l'ai
compilé avec le strict minimum, c'est à dire ce qui vient avec lui plus
gtk pour le GUI. J'ai rippé un certain nombre de dvd avec et obtenu des
résultats que je trouve excellents,

Je n'en doute pas et ce n'est pas mon propos.

en tout cas bien meilleurs que ce
qu'on trouve sur edonkey.

Une fois j'ai voulu charger Asterix sur edonkey, je me suis retrouvé avec
Sabrina et Ulla chez Marc Dorcel.

--
Phil. edonkey c'est bien.

Vincent Bernat <vince@khabale.org> wrote:

pkgname=modutils

Ah bah déjà, faut renseigner ça alors que c'est inutile chez Debian.

Renseigné dans debian/control.

pkgver=2.4.25

Pareil.

Renseigné dans debian/changelog.

source=(ftp://ftp.kernel.org/pub/linux/utils/kernel/$pkgname/v2.4/$pkgname-$pkgver.tar.bz2
modules.conf)

Pareil. Enfin bon, là, c'est un peu mauvaise foi car faut le
télécharger ! ;-)

Renseigné dans le fichier .dsc, relatif à l'archive Debian.

md5sums=('2c0cca3ef6330a187c6ef4fe41ecaa4d'
'35175bee593a7cc7d6205584a94d8625')

Là par contre, il calcule tout seul chez Debian.

Renseigné dans le .dsc et le .changes, générés automatiquement.

build() {
cd $startdir/src/$pkgname-$pkgver
./configure --prefix=/usr --enable-insmod-static
make || return 1
make prefix=$startdir/pkg/usr install
mv $startdir/pkg/usr/sbin $startdir/pkg
mkdir -p $startdir/pkg/etc
cp ../modules.conf $startdir/pkg/etc
}

La structure d'un debian/rules est un poil plus compliquée, mais les
étiquettes sont quand même assez claires. Avec en plus un peu de bruit
qu'on ne devrait pas modifier (tous les appels à debhelper).

debhelper c'est pas exactement du "bruit". On peut s'en passer aussi,
mais ça va nettement plus vite de l'utiliser, et ça simplifie
considérablement le debian/rules en plus de l'uniformiser quelques
peu.

C'est chez archlinux.

OK. Bref, ça se tient. le debian/rules contient des infos "inutiles"
et debian découpe en fichiers son répertoire debian plutôt que dans un

C'est la principale différence entre le deb et la plupart des autres
formats de packages, mine de rien...

seul fichier. Mais il gère alors pas mal de choses en plus comme la
localisation des fichiers de config et de la doc par exemple.

Mais c'est celle qui est à la base de toutes les autres différences :)

JB.

--
BOFH excuse #147:
Party-bug in the Aloha protocol.

OoO En cette matinée pluvieuse du mercredi 31 décembre 2003, vers
10:45, Julien BLACHE <jb@jblache.org> disait:

pkgname=modutils

Ah bah déjà, faut renseigner ça alors que c'est inutile chez Debian.

Renseigné dans debian/control.
[...]

Certes, mais dh-make le fait tout seul.

La structure d'un debian/rules est un poil plus compliquée, mais les
étiquettes sont quand même assez claires. Avec en plus un peu de bruit
qu'on ne devrait pas modifier (tous les appels à debhelper).

debhelper c'est pas exactement du "bruit". On peut s'en passer
aussi, mais ça va nettement plus vite de l'utiliser, et ça simplifie
considérablement le debian/rules en plus de l'uniformiser quelques
peu.

Certes, mais il est vrai que le debian/rules est un peu effrayant
quand on l'ouvre. Une approche avec une sorte de wrapper qui fait que
les choix non spécifiés sont ceux par défaut pourrait le rendre moins
abrupt. Cela dit, je le trouve très bien comme il est, il suffit de ne
pas se laisser impressionner.
--
BOFH excuse #353:
Second-sytem effect.

Julien BLACHE <jb@jblache.org> wrote:

talon@lpthe.jussieu.fr (Michel Talon) wrote:

De mon expérience, qui est loin d'être extensive, on arrive quand même
à obtenir un .deb aprés un nombre indéterminé de touillages du
debian/rules généré par dh_make.

Je me demande... tu as lu la doc, avant, ou pas ?

Tu veux me faire lire des docs le jour du réveillon?

JB.

--

Michel TALON

Dans article <3ff2bc11$0$6982$7a628cd7@news.club-internet.fr>,
abulmo@nospam.fr disait...

Gentoo est la solution aux problèmes rencontrés dans Debian. On peut
voir cela comme une forme de désenvoutement en effet.

C'est pas pour dire, mais ce que j'ai surtout entendu de gentoo, c'est
que c'est un peu léger, que portage est loin d'être à la hauteur des
ports freebsd et que d'ailleurs les ports freebsd sont dispo pour
linux...

--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?

OoO Vers la fin de l'après-midi du mercredi 31 décembre 2003, vers
16:18, Emmanuel Florac <eflorac@verisign.com> disait:

C'est pas pour dire, mais ce que j'ai surtout entendu de gentoo,
c'est que c'est un peu léger, que portage est loin d'être à la
hauteur des ports freebsd et que d'ailleurs les ports freebsd sont
dispo pour linux...

FreeBSD ? Ce sont plutôt les ports NetBSD qui sont dispos sur pas mal
d'OS.
--
BOFH excuse #67:
descramble code needed from software company

Dans article <m31xqkfn3d.fsf@neo.loria>, vincent.bernat@raysa.org
disait...

FreeBSD ? Ce sont plutôt les ports NetBSD qui sont dispos sur pas mal
d'OS.

Oui bon enfin tu m'as compris... Au fait bonne année les aminches.

--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?

talon@lpthe.jussieu.fr (Michel Talon) wrote:

Je me demande... tu as lu la doc, avant, ou pas ?

Tu veux me faire lire des docs le jour du réveillon?

Du moment que tu lis la doc *avant* de boire, je ne vois pas le
problème :-)

JB.

--
BOFH excuse #156:
Zombie processes haunting the computer

Vincent Bernat <vince@khabale.org> wrote:

pkgname=modutils

Ah bah déjà, faut renseigner ça alors que c'est inutile chez Debian.

Renseigné dans debian/control.

Certes, mais dh-make le fait tout seul.

Pour les cas simples, moui. Il reste toujours la description à
renseigner par contre.

dh_make est loin de tout faire tout seul, qu'est-ce qu'on s'ennuierait
si c'était le cas :-)

La structure d'un debian/rules est un poil plus compliquée, mais les
étiquettes sont quand même assez claires. Avec en plus un peu de bruit
qu'on ne devrait pas modifier (tous les appels à debhelper).

debhelper c'est pas exactement du "bruit". On peut s'en passer
aussi, mais ça va nettement plus vite de l'utiliser, et ça simplifie
considérablement le debian/rules en plus de l'uniformiser quelques
peu.

Certes, mais il est vrai que le debian/rules est un peu effrayant
quand on l'ouvre. Une approche avec une sorte de wrapper qui fait que

T'as déja ouvert un Makefile généré par automake/autoconf ? *ÇA* c'est
effrayant. Un debian/rules c'est un Makefile en peluche à côté :)

les choix non spécifiés sont ceux par défaut pourrait le rendre moins

CDBS permet de faire ça, on arrive à faire un package simple avec un
debian/rules de moins de 10 lignes.

abrupt. Cela dit, je le trouve très bien comme il est, il suffit de ne
pas se laisser impressionner.

Suffit d'avoir lu la Policy qui documente le contenu du fichier, après
ça n'a rien de difficile ou d'effrayant, vraiment.

JB.
--
BOFH excuse #157:
Incorrect time syncronization

OoO En ce milieu de nuit étoilée du mercredi 31 décembre 2003, vers
04:16, Richard Delorme <abulmo@nospam.fr> disait:

- On peut créer les siens sous /usr/local/portage/, ce qui consiste
en général à renommer le fichier /usr/portage/skel.ebuild

Et contrairement à ce qui se fait sous Debian, il devine de manière
magique les dépendances, la description, la façon dont le bidule se
compile (à l'aide d'une AI qui va lire le fichier INSTALL), etc,
etc.

Ce n'est pas magique, mais il suffit d'éditer le fichier .ebuild et
de compléter ces informations.

Vas-y colle nous le squelette par défaut. Je veux voir comment un
fichier texte Gentoo est différent d'un fichier texte Debian.

# Copyright 1999-2003 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# NOTE: The comments in this file are for instruction and documentation.
# They're not meant to appear with your final, production ebuild. Please
# remember to remove them before submitting or committing your ebuild. That
# doesn't mean you can't add your own comments though.

# The 'Header' on the third line should just be left alone. When your ebuild
# will be committed to cvs, the details on that line will be automatically
# generated to contain the correct data.

# Short one-line description of this package.
DESCRIPTION="This is a sample skeleton ebuild file"

# Homepage, not used by Portage directly but handy for developer reference
HOMEPAGE="http://foo.bar.com/"

# Point to any required sources; these will be automatically downloaded by
# Portage.
SRC_URI="ftp://foo.bar.com/${P}.tar.gz"

# License of the package. This must match the name of file(s) in
# /usr/portage/licenses/. For complex license combination see the developer
# docs on gentoo.org for details.
LICENSE=""

# The SLOT variable is used to tell Portage if it's OK to keep multiple
# versions of the same package installed at the same time. For example,
# if we have a libfoo-1.2.2 and libfoo-1.3.2 (which is not compatible
# with 1.2.2), it would be optimal to instruct Portage to not remove
# libfoo-1.2.2 if we decide to upgrade to libfoo-1.3.2. To do this,
# we specify SLOT="1.2" in libfoo-1.2.2 and SLOT="1.3" in libfoo-1.3.2.
# emerge clean understands SLOTs, and will keep the most recent version
# of each SLOT and remove everything else.
# Note that normal applications should use SLOT="0" if possible, since
# there should only be exactly one version installed at a time.
# DO NOT USE SLOT=""! This tells Portage to disable SLOTs for this package.
SLOT="0"

# Using KEYWORDS, we can record masking information *inside* an ebuild
# instead of relying on an external package.mask file. Right now, you
# should set the KEYWORDS variable for every ebuild so that it contains
# the names of all the architectures with which the ebuild works. We have
# 4 official architecture names right now: "~x86", "~ppc", "~sparc"
# and "~alpha". The ~ in front of the architecture indicates that the
# package is new and should be considered unstable until testing proves its
# stability. Once packages go stable the ~ prefix is removed.
# So, if you've confirmed that your ebuild works on x86 and ppc,
# you'd specify: KEYWORDS="~x86 ~ppc"
# For packages that are platform-independent (like Java, PHP or Perl
# applications) specify all keywords.
# For binary packages, use -* and then list the archs the bin package
# exists for. If the package was for an x86 binary package, then
# KEYWORDS would be set like this: KEYWORDS="-* x86"
# DO NOT USE KEYWORDS="*". This is deprecated and only for backward
# compatibility reasons.
KEYWORDS="~x86"

# Comprehensive list of any and all USE flags leveraged in the ebuild,
# with the exception of any ARCH specific flags, i.e. "ppc", "sparc",
# "x86" and "alpha". This is a required variable. If the
# ebuild doesn't use any USE flags, set to "".
IUSE="X gnome"

# Build-time dependencies, such as
# ssl? ( >Þv-libs/openssl-0.9.6b )
# >Þv-lang/perl-5.6.1-r1
# It is advisable to use the >= syntax show above, to reflect what you
# had installed on your system when you tested the package. Then
# other users hopefully won't be caught without the right version of
# a dependency.
DEPEND=""

# Run-time dependencies, same as DEPEND if RDEPEND isn't defined:
#RDEPEND=""

# Source directory; the dir where the sources can be found (automatically
# unpacked) inside ${WORKDIR}. S will get a default setting of ${WORKDIR}/${P}
# if you omit this line.
S=${WORKDIR}/${P}

src_compile() {
# Most open-source packages use GNU autoconf for configuration.
# You should use something similar to the following lines to
# configure your package before compilation. The "|| die" portion
# at the end will stop the build process if the command fails.
# You should use this at the end of critical commands in the build
# process. (Hint: Most commands are critical, that is, the build
# process should abort if they aren't successful.)
./configure
--host=${CHOST}
--prefix=/usr
--infodir=/usr/share/info
--mandir=/usr/share/man || die "./configure failed"
# Note the use of --infodir and --mandir, above. This is to make
# this package FHS 2.2-compliant. For more information, see
# http://www.pathname.com/fhs/

# Also note that it is cleaner and easier to use econf, which is the
# portage shortcut to the above ./configure statement:
#
# econf || die
# Note that econf will die on failure, but plase use econf || die
# for consistency.

# emake (previously known as pmake) is a script that calls the
# standard GNU make with parallel building options for speedier
# builds (especially on SMP systems). Try emake first. It might
# not work for some packages, in which case you'll have to resort
# to normal "make".
emake || die
#make || die
}

src_install() {
# You must *personally verify* that this trick doesn't install
# anything outside of DESTDIR; do this by reading and
# understanding the install part of the Makefiles.
make DESTDIR=${D} install || die
# For Makefiles that don't make proper use of DESTDIR, setting
# prefix is often an alternative. However if you do this, then
# you also need to specify mandir and infodir, since they were
# passed to ./configure as absolute paths (overriding the prefix
# setting).
#make
# prefix=${D}/usr
# mandir=${D}/usr/share/man
# infodir=${D}/usr/share/info
# install || die
# Again, verify the Makefiles! We don't want anything falling
# outside of ${D}.

# The portage shortcut to the above command is simply:
#
#einstall || die
# Note that einstall will die on failure, but please use einstall ||
die # for consistency.
}

--
Richard