Re: Jubiläum Angebot.

[Frank Küster]

"Izak Burger" <[EMAIL PROTECTED]> wrote:

> On 7/20/06, Barbara Bloch <[EMAIL PROTECTED]> wrote:
>> Streichen Sie mich unverzüglich aus Ihrer Liste!
>
> You can unsubscribe here:

I bet she isn't subscribed, she just received spam that claimed to
originate here...

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Configuration file shadowed?

[Frank Küster]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:

> What does this imply? Why are configuration files (I am
>  assuming that something called mktex.cnf is actually a configuration
>  file) being installed in /usr/share/? 

I didn't notice that this was Cc'ed to -devel, and already answered to
Manoj, opening bug report #379089.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

[MailServer Notification]Security Notification

[marcorisi]

WORM_NETSKY.DAM has been detected,and Replace has been taken on 21/07/2006 
9.36.56.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#379087: ITP: libcomplearn -- data-compression based intelligence lib in C for machine learning researchers

[Rudi Cilibrasi]

Package: wnpp
Severity: wishlist
Owner: Rudi Cilibrasi <[EMAIL PROTECTED]>


* Package name: libcomplearn
  Version : 0.9.3
  Upstream Author : Rudi Cilibrasi <[EMAIL PROTECTED]>
* URL : http://complearn.org/
* License : BSD
  Programming Lang: C
  Description : data-compression based intelligence lib in C for machine 
learning researchers

CompLearn is a suite of simple-to-use utilities that you can use to
apply compression techniques to the process of discovering and learning
patterns.  The compression-based approach used is powerful because it can mine
patterns in completely different domains. It can classify musical styles
of pieces of music and identify unknown composers. It can identify the
language of bodies of text. It can discover the relationships between
species of life and even the origin of new unknown viruses such as SARS.
Other uncharted areas are up to you to explore.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: orphaning gitweb

[Pierre Habouzit]

Le ven 21 juillet 2006 04:09, Andres Salomon a écrit :
> Hi,
>
> I'm going to orphan gitweb; I haven't used it in a long time, and
> I've been doing a poor job of keeping it up-to-date.  It doesn't have
> any bugs open on it; it just needs the occasional update (and the one
> patch I've done for it should be fed upstream if they're willing to
> take it).
>
> Who wants it?

I'm interested, but like said on IRC, I've not been able to find the 
upstream: copyright file mention a password-locked FTP, and 
git://kernel.org/./gitweb.git is now empty
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp4N3Bj70wxx.pgp
Description: PGP signature

Re: orphaning gitweb

[Thomas Girard]

Selon Pierre Habouzit <[EMAIL PROTECTED]>:

> I'm interested, but like said on IRC, I've not been able to find the
> upstream: copyright file mention a password-locked FTP, and
> git://kernel.org/./gitweb.git is now empty

According to [1], it has moved to git.git repo.  Indeed there's a gitweb
directory, see e.g.
http://www.kernel.org/git/gitweb.cgi?p=git/git.git;a=tree;h=d13532e6476eac282756e41673ba9d0035be7a9e;hb=e7a0f6714bdfa7e3a169cc756a05cbbf787997eb;f=gitweb

[1] http://marc.theaimsgroup.com/?l=git&m=115312507220972&w=2


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: orphaning gitweb

[Thomas Girard]

(sorry for CC:ing you Pierre)

Selon Thomas Girard <[EMAIL PROTECTED]>:

> According to [1], it has moved to git.git repo.

It was distributed along with git from release 1.4.0 on, see:
  http://lwn.net/Articles/187062/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Demande de renseignement

[konan elvis]

Bonjour,     je suis Monsieur KONAN ELVIS  Directeur  de CONTACT TRANS Distribution basée en Abidjan - Cote d'Ivoire.Je viens par ce message prendre contact avec vous dans le but d'effectuer une commande au sein de votre établissement, suite aux différents achats faits à Dubaï et Bankok qui n'ont produits que des articles défaillants trois mois après réception de ceux-ci.Etant donner l'importance et la rapidité des demandes, je voudrais bien savoir si vous disposer d'un TPE (Terminal de Prelevement Electronique) au sein de votre structure, pour faciliter le paiement par carte bancaire par habitude aux règlements de nos factures a distance (vpc).     Aussi, veuillez me signifier pareillement si vous accepter les paiement par virements bancaires (virements irrévocables et confirmés).  Nous travaillons avec les maisons d'expéditions express comme DHL, UPS, FEDEX et le Fret Aérien Normal.  En attente de votre message retour, je vous prie de bien vouloir recevoir mes salutations distinguées.E. B. DistributionDirecteur  KONAN ELVISmaracory- Rue
 de la Paix05 B.P. 402 Abidjan 05Tel.:+225.07.296.946Fax:+225.21.264.800 
		 
Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! 
Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. Cliquez ici. 

RE: Package Selection for Debian Live

[Mathieu JANIN]

Thx,
I know how to build a live CD or a pendrive with what I want on it (almost),
and I know some tweaks to squash down all things (I comme from embedded
developpment and even if it's far away now, this is always a concern for
me).
I was just thinking about your discussion on what kind of LiveCD debian Live
shoud be, and as Debian is some sort of "Mother" for a lot of distrib, I
just suggested that "Debian LIVE" could be the same for debian based
"LiveCD" (a work on genericization of liveCD building under debian).
But it is just a philosophical suggestion, I don't even know how far is
"Debian Live" devel.
(excuse me for my poor english if I didn't make it clear)
Matt.


> -Message d'origine-
> De : John Goerzen [mailto:[EMAIL PROTECTED]
> Envoyé : jeudi 20 juillet 2006 15:38
> À : Mathieu JANIN
> Cc : Debian Development
> Objet : Re: Package Selection for Debian Live
> 
> 
> On Thu, Jul 20, 2006 at 12:01:30PM +0200, Mathieu JANIN wrote:
> > Hi folks,
> > i could seem idiot, but wouldn't it be nice to have a 
> minimalistic bootstrap
> > CD with everything that is needed to compose your own 
> liveCD (perharps an
> > enhanced version of DFSbuild, with "cleaning/compressing" 
> feature like
> > localepurge and so ), and only a minimalistic set of what 
> is needed for
> > basic forensic.
> 
> You could probably do that with dfsbuild and a little bit of 
> scrubbing.
> You probably just would want to do things like rm -r /usr/share/doc
> /usr/share/man on the generated image.
> 
> -- John
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact 
> [EMAIL PROTECTED]
> 

Re: someone using apmd on ppc please test patch for #222635

[Alexander Schmehl]

Hi Aníbal!

* Aníbal Monsalve Salazar <[EMAIL PROTECTED]> [060721 01:42]:

> Someone using apmd on ppc please test patch for #222635 [0].

Works.  I could reproduce the bug with 3.2.2-6, I couldn't reproduce it
any longer with a patched 3.2.2-7:

=
[EMAIL PROTECTED]:/tmp/apmd-3.2.2$ apm -m
On-line, battery status high: 98%
=


Yours sincerely,
  Alexander


signature.asc
Description: Digital signature

Re: orphaning gitweb

[Jérôme Marant]

Selon Pierre Habouzit <[EMAIL PROTECTED]>:

> Le ven 21 juillet 2006 04:09, Andres Salomon a écrit :
> > Hi,
> >
> > I'm going to orphan gitweb; I haven't used it in a long time, and
> > I've been doing a poor job of keeping it up-to-date.  It doesn't have
> > any bugs open on it; it just needs the occasional update (and the one
> > patch I've done for it should be fed upstream if they're willing to
> > take it).
> >
> > Who wants it?
>
> I'm interested, but like said on IRC, I've not been able to find the
> upstream: copyright file mention a password-locked FTP, and
> git://kernel.org/./gitweb.git is now empty

It has been integrated into git since 1.4.x.

Cheers,

--
Jérôme Marant


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#379103: ITP: complearn-gui -- 3D drag-and-drop interface to CompLearn universal data mining system

[Rudi Cilibrasi]

Package: wnpp
Severity: wishlist
Owner: Rudi Cilibrasi <[EMAIL PROTECTED]>


* Package name: complearn-gui
  Version : 0.9.3
  Upstream Author : Rudi Cilibrasi <[EMAIL PROTECTED]>
* URL : http://complearn.org/
* License : BSD
  Programming Lang: C
  Description : 3D drag-and-drop interface to CompLearn universal data 
mining system

complearn-gui provides an easy-to-use GUI interface to try experimenting
with the CompLearn tree building system.  To use, simply run clfun and
drag and drop 4-20 files into the main window.  Then wait to see an
optimal tree built right before your eyes in a 3D virtual world.  As new
better trees are found, the tree will morph to reflect the new
organization.  You can drop text samples, genetic samples, or whatever
other (uncompressed) data you like to see hierarchical clustering in
action.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#379104: ITP: complearn-mpi -- parallel quartet tree search system for clusters / supercomputers using MPI

[Rudi Cilibrasi]

Package: wnpp
Severity: wishlist
Owner: Rudi Cilibrasi <[EMAIL PROTECTED]>


* Package name: complearn-mpi
  Version : 0.9.3
  Upstream Author : Rudi Cilibrasi <[EMAIL PROTECTED]>
* URL : http://complearn.org/
* License : BSD
  Programming Lang: C
  Description : parallel quartet tree search system for clusters / 
supercomputers using MPI

Trying to find optimal binary trees matching a given distance matrix is
an NP-hard problem in general.  For more than 100 objects this usually
makes it infeasible to solve exactly.  In practice it can be
approximated but a quartet tree search system can require a lot of CPU
time even using sophisticated heuristics because tree scoring is slow.
This package provides a quiescent parallel manager-worker quartet tree
search system with some amount of fault tolerance using MPI.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: lilypond and python

[Loïc Minier]

On Tue, Jul 18, 2006, Thomas Bushnell BSG wrote:
> So, let me make plain: I am entirely happy to accept a workaround
> patch for lilypond's current upstream stable release that will make it
> build and use python 2.4 even when that is not installed as "python".
> If such a functional patch appears and is mailed to the appropriate
> lilypond bug, it would immediately become a high priority matter for
> me to upload it.  I have wanted to do so for months.

 Here's a patch (which I couldn't test, see below).

 Please note that while writing this patch, I saw that:
 - "make install" is called with prefix=debian/tmp/..., this is usually
   wrong, DESTDIR= should be used instead because prefix is a runtime
   path;  this can cause important bugs such as #337616
 - you don't call dh_python; dh_python will typically create
   ${python:Depends} which will have "python2.4" if your scripts start
   with /usr/bin/python2.4
 - your package is not bin NMU safe due to = source-version dependencies
   on an arch: all package
 - your package fails to build in my pbuilder:
rm -f ./out/accidental-placement.dep; 
DEPENDENCIES_OUTPUT="./out/accidental-placement.dep 
./out/accidental-placement.o" g++ -c   -DHAVE_CONFIG_H  -DNDEBUG 
-DSTRING_UTILS_INLINED -Iinclude -I./out -I../flower/include -I../flower/./out 
-I../flower/include -DNDEBUG -I/usr/include/python2.3  -O2 -finline-functions 
-g -pipe  -I/usr/include/pango-1.0 -I/usr/include/freetype2 
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include-I/usr/include/freetype2 
  -DNDEBUG -I/usr/include/python2.3  -O2 -finline-functions -g -pipe  
-I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include-I/usr/include/freetype2   -W -Wall -Wconversion 
 -o out/accidental-placement.o accidental-placement.cc
include/accidental-interface.hh:24: error: extra qualification 
'Accidental_interface::' on member 'accurate_boxes'
make[2]: *** [out/accidental-placement.o] Error 1
make[2]: Leaving directory `/tmp/buildd/lilypond-2.6.3/lily'

 This is all *very* broken.

 Beside, the configure script uses:
STEPMAKE_PYTHON(REQUIRED, 2.1)
 which either means that you don't really need python 2.4, or that the
 configure test is broken.

-- 
Loïc Minier <[EMAIL PROTECTED]>
--- lilypond-2.6.3/debian/changelog
+++ lilypond-2.6.3/debian/changelog
@@ -1,3 +1,14 @@
+lilypond (2.6.3-11) UNRELEASED; urgency=low
+
+  * Call configure and $(MAKE) with PYTHON=/usr/bin/python2.4 by exporting
+PYTHON from debian/rules.
+  * Update build-deps and deps to use python2.4 instead of the default python
+version.
+  * Fix the shebang of scripts in /usr/bin to use /usr/bin/python2.4 instead
+of /usr/bin/python.
+
+ -- Loic Minier <[EMAIL PROTECTED]>  Fri, 21 Jul 2006 16:07:50 +0200
+
 lilypond (2.6.3-10) unstable; urgency=low
 
   * debian/control (Build-Depends): Drop explicit dependency on
--- lilypond-2.6.3/debian/control
+++ lilypond-2.6.3/debian/control
@@ -1,5 +1,5 @@
 Source: lilypond
-Build-Depends: debhelper (>= 4.0.0), python-dev, guile-1.6-dev (>= 1.6.7), 
flex (>= 2.5.4a-14) | flex-old, bison (<< 1:1.50) | bison (>> 1:1.75-1), 
texinfo (>= 4.6-1), groff, m4, gettext (>= 0.10.36-1), mftrace (>= 1.1.17-1), 
fontforge (>= 0.0.20050911-1), pkg-config (>= 0.9.0), libfreetype6-dev, 
libpango1.0-dev, libfontconfig-dev
+Build-Depends: debhelper (>= 4.0.0), python2.4-dev, guile-1.6-dev (>= 1.6.7), 
flex (>= 2.5.4a-14) | flex-old, bison (<< 1:1.50) | bison (>> 1:1.75-1), 
texinfo (>= 4.6-1), groff, m4, gettext (>= 0.10.36-1), mftrace (>= 1.1.17-1), 
fontforge (>= 0.0.20050911-1), pkg-config (>= 0.9.0), libfreetype6-dev, 
libpango1.0-dev, libfontconfig-dev
 Build-Depends-Indep: gs-gpl (>= 8.01-5) | gs-esp | gs (<= 7.07-1), netpbm (>= 
2:9.10-1), imagemagick, emacs-intl-fonts, xfonts-intl-arabic, 
xfonts-intl-asian, xfonts-intl-chinese, xfonts-intl-chinese-big, 
xfonts-intl-european, xfonts-intl-japanese, xfonts-intl-japanese-big, 
xfonts-intl-phonetic, ttf-kochi-gothic, ttf-kochi-mincho
 Build-Conflicts-Indep: gs-afpl | gs-gpl (= 8.01-1), gs-gpl (= 8.01-2), gs-gpl 
(= 8.01-3), gs-gpl (= 8.01-4) 
 Section: tex
@@ -11,7 +11,7 @@
 Architecture: any
 Replaces: lilypond1.3
 Provides: lilypond1.3
-Depends: ${shlibs:Depends}, python, guile-1.6 (>= 1.6.7), ${misc:Depends}, 
lilypond-data (= ${Source-Version})
+Depends: ${shlibs:Depends}, python2.4, guile-1.6 (>= 1.6.7), ${misc:Depends}, 
lilypond-data (= ${Source-Version})
 Recommends: lilypond-doc
 Description: A program for typesetting sheet music
  LilyPond is a music typesetter, an automated engraving system.  It
--- lilypond-2.6.3/debian/rules
+++ lilypond-2.6.3/debian/rules
@@ -37,6 +37,8 @@
 # This has to be exported to make some magic below work.
 export DH_OPTIONS
 
+export PYTHON=/usr/bin/python2.4
+
 build: build-stamp
 build-stamp:
dh_testdir
@@ -90,6 +92,15 @@
# Add here commands to install the package into debian/tmp.
$(MAKE) install prefix=$(CURDIR)/debian/tmp/usr
 

Re: orphaning gitweb

[Sebastian Harl]

Hi Andres,

> I'm going to orphan gitweb; I haven't used it in a long time, and I've
> been doing a poor job of keeping it up-to-date.  It doesn't have any
> bugs open on it; it just needs the occasional update (and the one patch
> I've done for it should be fed upstream if they're willing to take it).

I'm interested. However, it might make more sense to build gitweb from the 
git-core source package.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/



signature.asc
Description: Digital signature

Bug#379126: ITP: ccontrol -- Compilation controller

[Ted Percival]

Package: wnpp
Severity: wishlist
Owner: Ted Percival <[EMAIL PROTECTED]>


* Package name: ccontrol
  Version : 0.9.1
  Upstream Authors: Rusty Russell 
  : Michael Ellerman 
  : Michael Neuling 
* URL : http://ozlabs.org/~rusty/ccontrol/
* License : GPL
  Programming Lang: C
  Description : Compilation controller

The ccontrol program takes over the roles of the compiler, linker and
make, and reads a configuration file to decide what to do before
invoking them. This is particularly useful for centralized control over
commands and options, such as enabling distcc and ccache. It is also
great for controlling parallelism and which compiler versions to use,
based on the directory and make targets.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Getting rid of circular dependencies, stage 5

[Bill Allombert]

Dear Debian developers,

Here the list of packages involved in circular dependencies listed by
maintainers. 

This list is also available at

(update daily, courtesy of Robert Lemmen).

A list of dependencies including dependency graphs is available at
.

Daily changes are at
.

The list of bug I reported so far is there:


Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Adeodato Simó <[EMAIL PROTECTED]>
amarok
amarok-engines
amarok-xine

Alastair McKinstry <[EMAIL PROTECTED]>
console-common

Alioth Games Devel Team <[EMAIL PROTECTED]>
boson-data
boson-music

Andrew Mitchell <[EMAIL PROTECTED]>
phpgroupware
phpgroupware-admin
phpgroupware-phpgwapi
phpgroupware-preferences
phpgroupware-setup

Anthony Towns <[EMAIL PROTECTED]>
netbase

Bernd Schumacher <[EMAIL PROTECTED]>
bootcd
bootcd-hppa
bootcd-i386
bootcd-ia64

Brendan O'Dea <[EMAIL PROTECTED]>
perl
perl-modules

Carlo Contavalli <[EMAIL PROTECTED]>
wipl-client-exec
wipl-client-standard
wipl-daemon

Christian T. Steigies <[EMAIL PROTECTED]>
luola
luola-data
luola-levels

Console utilities maintainers <[EMAIL PROTECTED]>
kbd

Daniel Baumann <[EMAIL PROTECTED]>
lush
lush-library

Daniel Burrows <[EMAIL PROTECTED]>
heroes-common
heroes-ggi
heroes-sdl
lbreakout2
lbreakout2-data

David Coe <[EMAIL PROTECTED]>
iamerican
ispell

David Moreno Garza <[EMAIL PROTECTED]>
gxmms-bmp
gxmms-common
gxmms-xmms
liferea
liferea-gtkhtml
liferea-xulrunner
playground
playground-plugin-xmms

Debconf Developers <[EMAIL PROTECTED]>
debconf
debconf-english
debconf-i18n

Debian GCC Maintainers 
g++-3.3
g++-3.4
g++-4.0
g++-4.1
gcj-4.0
gcj-4.1
java-gcj-compat
libgcj6-dev
libgcj7-dev
libstdc++5-3.3-dev
libstdc++6-4.0-dev
libstdc++6-4.1-dev
libstdc++6-dev
g++-2.95
libstdc++2.10-dev

Debian GIS Project 
grass
libgrass

Debian GNOME Maintainers <[EMAIL PROTECTED]>
gamin
libgamin0

Debian GNUstep maintainers <[EMAIL PROTECTED]>
gnustep-back0.10
gnustep-base-common
gnustep-gpbs
gnustep-gui-common
libgnustep-base1.11
libgnustep-gui0.10

Debian Games Team <[EMAIL PROTECTED]>
abuse
abuse-frabs
abuse-lib
boson
boson-base

Debian Install System Team 
tasksel
tasksel-data

Debian Italian Maintainers Task Force <[EMAIL PROTECTED]>
festlex-ifd
festvox-italp16k
festvox-itapc16k

Debian Java Maintainers 
antlr
eclipse-jdt
eclipse-jdt-common
gjdoc
kaffe
kaffe-jthreads
kaffe-pthreads
libgnucrypto-java
libjessie-java
libswt3.1-gtk-java
libswt3.1-gtk-jni
libgnome-java
libgnome-jni
libgtk-java
libgtk-jni

Debian Mono Group <[EMAIL PROTECTED]>
libmono-security2.0-cil
libmono-system2.0-cil

Debian Qt/KDE Maintainers 
libkcal2b
libkdepim1a

Debian X Strike Force 
libx11-dev
libxext-dev
xserver-xorg-core
xserver-xorg-input-all
xserver-xorg-input-evdev
xserver-xorg-input-mouse
xserver-xorg-video-all
xserver-xorg-video-apm
xserver-xorg-video-ark
xserver-xorg-video-ati
xserver-xorg-video-chips
xserver-xorg-video-cirrus
xserver-xorg-video-cyrix
xserver-xorg-video-dummy
xserver-xorg-video-fbdev
xserver-xorg-video-glint
xserver-xorg-video-i128
xserver-xorg-video-i740
xserver-xorg-video-i810
xserver-xorg-video-imstt
xserver-xorg-video-mga
xserver-xorg-video-newport
xserver-xorg-video-nsc
xserver-xorg-video-nv
xserver-xorg-video-rendition
xserver-xorg-video-s3
xserver-xorg-video-s3virge
xserver-xorg-video-savage
xserver-xorg-video-sis
xserver-xorg-video-sisusb
xserver-xorg-video-tdfx
xserver-xorg-video-tga
xserver-xorg-video-trident
xserver-xorg-video-tseng
xserver-xorg-video-v4l
xserver-xorg-video-vesa
xserver-xorg-video-vga
xserver-xorg-video-via
xserver-xorg-video-vmware

Denis Barbier <[EMAIL PROTECTED]>
belocs-locales-bin
belocs-locales-data

Emmanuel Lacour <[EMAIL PROTECTED]>
liba

Re: Configuration file shadowed?

[Manoj Srivastava]

severity 379089 serious
thanks

Hi,
On Fri, 21 Jul 2006 09:57:20 +0200, Frank Küster <[EMAIL PROTECTED]> said: 
> Because of this paragraph from the TeX Policy Draft:

 , 4.1 Configuration files
 | In a TeX system, in principle every TeX input file can be changed to
 | change the behavior of the system, and thus be regarded as a
 | configuration file. To prevent inflation of configuration files,
 | packages should not install any TeX input files as conffiles or
 | configuration files. Instead, they should create an empty directory
 | below /etc/texmf/tex and advice users which files are likely places
 | for configuration. It is up to the local admin or individual user to
 | place changed copies in TEXMFSYSCONFIG or TEXMFCONFIG, respectively.
 `

While it is true any file can be changed to change behaviour
 for TeX (like things can be changed in /usr/include/foo.h to change
 behaviour of a -dev package), any file with a name *.cnf is meant to
 be a configuration file, and must, in order to meet policy
 requirements, live under /etc. This is no different from
 kernel-package having it's configuration file live in
 /etc/kernel-pkg.conf, even though editing _any_ file in
 /usr/share/kernel-package would change the behaviour of the program.
 By your argument, any interpreted language package is exempt from the
 "configuration in /etc rule", since one may edit the script directly
 in /usr/bin anyway.  I do not think it holds.

So, while editing /usr/bin/make with a hex editor can change
 behaviour, it is not designed to be a configuration file, but  a
 foo.cnf file is so designed, and these cases should not be conflated
 together. Please change TeX policy to move the configuration files
 (at the very least, files labelled configuration files by being named
 *.cnf) back to /etc.

I am raising the severity of this bug to serious, since it is
 a violation of a must directive in the Debian technical policy.

The contents of my  /etc/texmf/web2c/mktex.cnf file are below.

manoj

# The mktex.cnf file, if it exists, can be used to tailor a setup to
# local conditions.  If you use the mktex scripts, this file can contain
# generic bourne shell code.  However, the C emulations of the scripts
# do not handle anything beyond simple assignment of variables, and doing
# more is not exactly recommended.
#
# To assign variables, use constructs like the examples below, which only
# set unassigned variables.  The scripts may malfunction if you do
# otherwise.
#
# Some examples of what you can the mktex.cnf file for:
: ${MT_FEATURES=appendonlydir:varfonts}
: ${MODE=ljfivemp}
: ${BDPI=600}
# : ${ps_to_pk=gsftopk}

-- 
Save the whales.  Collect the whole set.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Getting rid of circular dependencies, stage 5

[Ian Jackson]

Bill Allombert writes ("Getting rid of circular dependencies, stage 5"):
> Here the list of packages involved in circular dependencies listed by
> maintainers. 

Didn't we already have the conversation where we explained that there
is nothing necessarily wrong with a circular dependency ?

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Configuration file shadowed?

[Jean-Christophe Dubacq]

Le 21 juil. 06 à 18:23, Manoj Srivastava a écrit :


While it is true any file can be changed to change behaviour
 for TeX (like things can be changed in /usr/include/foo.h to change
 behaviour of a -dev package), any file with a name *.cnf is meant to
 be a configuration file, and must, in order to meet policy
 requirements, live under /etc. This is no different from
 kernel-package having it's configuration file live in
 /etc/kernel-pkg.conf, even though editing _any_ file in
 /usr/share/kernel-package would change the behaviour of the program.
 By your argument, any interpreted language package is exempt from the
 "configuration in /etc rule", since one may edit the script directly
 in /usr/bin anyway.  I do not think it holds.


The way I see it, the /usr/share/texmf/mktex.cnf is a "default value  
file", used in the setup of the whole texmf hierarchy; the  
configuration is /etc/texmf/mktex.cnf, which, per web2c magic,  
overrides the default values, _if it does exist_. Good default values  
can be set by copying /usr/share/texmf/mktex.cnf, and return to  
default values can be done through the removal of /etc/texmf/mktex.cnf.


If anything setting default values must be moved under /etc, then  
most shell scripts should be moved to /etc. What of, let's say, uw- 
imapd (a well known package), that accepts a /etc/c-client.cf file  
that does configuration, empty by default (and needing the sentence  
"I accept the risk" as the first line to work). Should this file  
exist on all debian systems for the sake of being configuration files?


I think the web2c mechanism is really good, and is the way  
preferences should be set (source/distribution defaults in /usr,  
system defaults in /etc, user defaults in ~/texmf or by environment  
variables).

--
JCD

Re: Bug#379089: Configuration file shadowed?

[Frank Küster]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:

> severity 379089 serious
> thanks
>
> While it is true any file can be changed to change behaviour
>  for TeX (like things can be changed in /usr/include/foo.h to change
>  behaviour of a -dev package), any file with a name *.cnf is meant to
>  be a configuration file, and must, in order to meet policy
>  requirements, live under /etc. 

I am not convinced things are as clear-cut as you see them.  Please read
on.  

First of all, please note that the sentence in the TeX Policy talks
about "TeX input files", there are other files in a TeX system that are
clearly configuration files, and are installed in /etc/texmf, anyway.
In fact, in a sense (following the TeX Policy's spirit instead of its
letter, which may be suboptimal) the file in question is not a TeX input
file, so we should have installed it in /etc/texmf/web2c even with our
current Policy.

One point that is unclear to me is this phrase from the Debian Policy:

,
|Typically, configuration files are intended to be modified by the
|system administrator (if needed or desired) to conform to local policy
|or to provide more useful site-specific behavior.
`

Most of the files in question (not the one that raised this thread, I
admit) are rather meant to be changed by individual users to fit their
needs,  or even on a per-document basis.  A site-wide change on a real
multi-user system won't make sense.


Summary:

I believe that we need to rephrase the TeX Policy.  But this requires
not just to specifiy that each "cfg" file must be in /etc.  Instead, I
think we need to find a distinction between

- files that can be used to modify the behavior of programs, and/or
  files that make sense to customize site-wide behavior on a multiuser
  system (I just cannot find an example of a file that would only
  fulfill the second half of the sentence)

  => must go to /etc

- files that can be used to modifiy the typesetting of documents

  => should not go to /etc

What do you think?


Regards, Frank




-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Getting rid of circular dependencies, stage 5

[Joe Smith]

"Ian Jackson" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]



Bill Allombert writes ("Getting rid of circular dependencies, stage 5"):

Here the list of packages involved in circular dependencies listed by
maintainers.


Didn't we already have the conversation where we explained that there
is nothing necessarily wrong with a circular dependency ?



Well, strictly speaking all circular dependencies could be considered a 
policy violation because they

depend on dpkg not working as policy states it does.

They are also a pain to any person who is manually feeding packages to dpkg 
one at a time.
There seems to be no reason why that should not be able to work, but 
circular dependencies will
always break that. There are other issues with them as well. If there is a 
circular dependency your package
cannot rely on the fact that its dependecies are indeed installed and 
configured. That is not
good. 




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#379089: Configuration file shadowed?

[Christoph Berg]

Re: Frank Küster 2006-07-21 <[EMAIL PROTECTED]>
> I believe that we need to rephrase the TeX Policy.  But this requires
> not just to specifiy that each "cfg" file must be in /etc.  Instead, I
> think we need to find a distinction between
> 
> - files that can be used to modify the behavior of programs, and/or
>   files that make sense to customize site-wide behavior on a multiuser
>   system (I just cannot find an example of a file that would only
>   fulfill the second half of the sentence)
> 
>   => must go to /etc

I remeber that a tetex update last year (maybe even longer ago) had
prompted me and several others for about a dozen changed conffiles I
had never heard of before and I surely had never touched. Similarly, I
have seen some debconf prompts that asked me about tex settings I
wouldn't ever use. I might have run at the wrong debconf priority
there, but the point is: imho the vast majority of tetex users will
never touch any of the settings and be happy with the defaults, so
please make sure that any new conf(ig) file you introduce does not
prompt the user. Likewise, if you are going to overwrite a file
outside of /etc on upgrade that one out of 1000 users might have
touched, please don't prompt, but tell the users in README.Debian to
use dpkg-divert. Imho, in this case, customizing for the
might-have-changed case doesn't serve the (other) users who are just
confused by the questions.

> - files that can be used to modifiy the typesetting of documents
> 
>   => should not go to /etc

Users will probably copy these files to the directory where that
document lives, so there is no need to treat them specially.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: Configuration file shadowed?

[Steve Greenland]

On 21-Jul-06, 13:41 (CDT), Jean-Christophe Dubacq <[EMAIL PROTECTED]> wrote: 
> The way I see it, the /usr/share/texmf/mktex.cnf is a "default value  
> file", used in the setup of the whole texmf hierarchy; the  
> configuration is /etc/texmf/mktex.cnf, which, per web2c magic,  
> overrides the default values, _if it does exist_. Good default values  
> can be set by copying /usr/share/texmf/mktex.cnf, and return to  
> default values can be done through the removal of /etc/texmf/mktex.cnf.

I'd buy that except for the debconf message, which implies that the
visibility of certain default value (MT_FEATURES, right?) blocked by the
mere existence of /etc/texmf/mktex.cnf, even though it's unmentioned in
that file.

Standard behaviour is to allow "compiled in"[1] default values to change
unless explicitly overridden by a configuration file.

Steve

[1] Yes, I know that's not the right term technically, but it fits
conceptually. Anyway, the default value as specified by the package
builder.

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Configuration file shadowed?

[Manoj Srivastava]

On Fri, 21 Jul 2006 20:41:38 +0200, Jean-Christophe Dubacq <[EMAIL PROTECTED]> 
said: 

> Le 21 juil. 06 à 18:23, Manoj Srivastava a écrit :
>> 
>> While it is true any file can be changed to change behaviour for
>> TeX (like things can be changed in /usr/include/foo.h to change
>> behaviour of a -dev package), any file with a name *.cnf is meant
>> to be a configuration file, and must, in order to meet policy
>> requirements, live under /etc. This is no different from
>> kernel-package having it's configuration file live in
>> /etc/kernel-pkg.conf, even though editing _any_ file in
>> /usr/share/kernel-package would change the behaviour of the
>> program.  By your argument, any interpreted language package is
>> exempt from the "configuration in /etc rule", since one may edit
>> the script directly in /usr/bin anyway.  I do not think it holds.

> The way I see it, the /usr/share/texmf/mktex.cnf is a "default value
> file", used in the setup of the whole texmf hierarchy; the
> configuration is /etc/texmf/mktex.cnf, which, per web2c magic,
> overrides the default values, _if it does exist_. Good default
> values can be set by copying /usr/share/texmf/mktex.cnf, and return
> to default values can be done through the removal of
> /etc/texmf/mktex.cnf.

The difference here is that if you follow this path,  ad
 eschew the conffile mechanism, it is up to you to provide the benefit
 to users that conffile mechanisms provide:  namely, the user is
 informde when the maintainer changes default values, they can look at
 the diff at install time, and either accept or decline the new
 conffile -- and take action to reconcile differences, if any.

In this case, I just got a scary message that implies that tex
 font caching no longer works on my machine -- and the isntallation
 continued. This is not good.

> If anything setting default values must be moved under /etc, then
> most shell scripts should be moved to /etc.

Rubbish. This is intellectual laziness. Anything in /usr can
 be edited (hex editors, OD, etrc can handle binaries, scripts etc can
 also be modified.  That does not mean that the policy of
 configuration files in /etc can be bypassed at will. 

Look at cvs-buildpackage -- a script that takes configuration
 directives from the command line, env variable, config file, or built
 in default. There is a clean separation of sources of variable
 values -- and it even caters to system-wide and individual
 configuration.

> What of, let's say, uw- imapd (a well known package), that accepts a
> /etc/c-client.cf file that does configuration, empty by default (and
> needing the sentence "I accept the risk" as the first line to
> work). Should this file exist on all debian systems for the sake of
> being configuration files?

This sounds like dissembling to me. When you name a file
 foo.cnf in TeX, the .cnf does not stand for default values which
 happen to be kept in a file. It actually stands for conf, or
 configuration.  A whole lot of quick talking can help weasel out of
 policy compliance, but it would be easy enough to ship a symlink in
 /usr and have the real configuration file be in /etc.

> I think the web2c mechanism is really good, and is the way
> preferences should be set (source/distribution defaults in /usr,
> system defaults in /etc, user defaults in ~/texmf or by environment
> variables).

Debian policy states that distribution specified configuration
 files also live in /etc. and it is not as if correcting things is
 rocket science -- ship a symlink in /usr for *.cnf files, linking to
 real files under /etc, and you have policy compliance. 

-- 
I can relate to that.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Getting rid of circular dependencies, stage 5

[Manoj Srivastava]

On Fri, 21 Jul 2006 15:09:56 -0400, Joe Smith
<[EMAIL PROTECTED]> said:  

> Well, strictly speaking all circular dependencies could be
> considered a policy violation because they depend on dpkg not
> working as policy states it does.

Could you elaborate on this?

manoj
-- 
Do infants enjoy infancy as much as adults enjoy adultery? George
Carlin
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Configuration file shadowed?

[Frank Küster]

Steve Greenland <[EMAIL PROTECTED]> wrote:

> On 21-Jul-06, 13:41 (CDT), Jean-Christophe Dubacq <[EMAIL PROTECTED]> wrote: 
>> The way I see it, the /usr/share/texmf/mktex.cnf is a "default value  
>> file", used in the setup of the whole texmf hierarchy; the  
>> configuration is /etc/texmf/mktex.cnf, which, per web2c magic,  
>> overrides the default values, _if it does exist_. Good default values  
>> can be set by copying /usr/share/texmf/mktex.cnf, and return to  
>> default values can be done through the removal of /etc/texmf/mktex.cnf.
>
> I'd buy that except for the debconf message, which implies that the
> visibility of certain default value (MT_FEATURES, right?) blocked by the
> mere existence of /etc/texmf/mktex.cnf, even though it's unmentioned in
> that file.

Indeed, the TeX Policy needs rewording, and this particular file should
be a conffile, because it affects how the TeX programs and helper
scripts act.  In general, files that influence documents and are read
because they are somehow requested in TeX's input (or BibTeX's or
whatever) make no sense in /etc.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Bug#379089: Configuration file shadowed?

[Frank Küster]

Christoph Berg <[EMAIL PROTECTED]> wrote:

> Re: Frank Küster 2006-07-21 <[EMAIL PROTECTED]>
>> I believe that we need to rephrase the TeX Policy.  But this requires
>> not just to specifiy that each "cfg" file must be in /etc.  Instead, I
>> think we need to find a distinction between
>> 
>> - files that can be used to modify the behavior of programs, and/or
>>   files that make sense to customize site-wide behavior on a multiuser
>>   system (I just cannot find an example of a file that would only
>>   fulfill the second half of the sentence)
>> 
>>   => must go to /etc
>
> I remeber that a tetex update last year (maybe even longer ago) had
> prompted me and several others for about a dozen changed conffiles I
> had never heard of before and I surely had never touched. Similarly, I
> have seen some debconf prompts that asked me about tex settings I
> wouldn't ever use. I might have run at the wrong debconf priority
> there, but the point is: imho the vast majority of tetex users will
> never touch any of the settings and be happy with the defaults, so
> please make sure that any new conf(ig) file you introduce does not
> prompt the user. 

Exactly these things caused us to make the move.  I admit, it was also
caused by design errors we (or even former maintainers in the old times)
made, and it might be possible to have a package with 300 configuration
files in /etc.  I don't expect that we're going to manage it properly,
though, especially as long as ucf's functionality isn't integrated with
dpkg.  

> Likewise, if you are going to overwrite a file
> outside of /etc on upgrade that one out of 1000 users might have
> touched, please don't prompt, but tell the users in README.Debian to
> use dpkg-divert. Imho, in this case, customizing for the
> might-have-changed case doesn't serve the (other) users who are just
> confused by the questions.

In this case, as has been pointed out, we were wrong in treating the
file like any TeX input file, and it should have been a conffile.
Probably unchanged by 99.99% of the users.  

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Getting rid of circular dependencies, stage 5

[Loïc Minier]

On Fri, Jul 21, 2006, Manoj Srivastava wrote:
> > Well, strictly speaking all circular dependencies could be
> > considered a policy violation because they depend on dpkg not
> > working as policy states it does.
> Could you elaborate on this?

 I think he meant that dpkg breaks the loop, and installs packages
 despite their dependencies not being installed.

-- 
Loïc Minier <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Configuration file shadowed?

[Frank Küster]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:

> The difference here is that if you follow this path,  ad
>  eschew the conffile mechanism, it is up to you to provide the benefit
>  to users that conffile mechanisms provide:  namely, the user is
>  informde when the maintainer changes default values, they can look at
>  the diff at install time, and either accept or decline the new
>  conffile -- and take action to reconcile differences, if any.
>
> In this case, I just got a scary message that implies that tex
>  font caching no longer works on my machine -- and the isntallation
>  continued. This is not good.

This is not good, correct.  This particular file should have been a
conffile.  

I don't see how it makes sense, however, to ship files as conffiles that
could potentially be used for changing document appearance, while that
doesn't make any sense on a site-wide basis.  That's not how a TeX
system should be handled.  If you're on a single-user machine, you can
change your documents' appearance by putting files into /etc/, that's
why we offer TEXMFSYSCONFIG.  But that's just because on a single-user
machine there's no difference between TEXMFHOME and TEXMFSYSCONFIG.

> Look at cvs-buildpackage -- a script that takes configuration
>  directives from the command line, env variable, config file, or built
>  in default. There is a clean separation of sources of variable
>  values -- and it even caters to system-wide and individual
>  configuration.

There are many programs that read configuration files if they exist, but
usually do not need them.  Do you think that a package must ship every
configuration file that one of its components would possibly read?

>> What of, let's say, uw- imapd (a well known package), that accepts a
>> /etc/c-client.cf file that does configuration, empty by default (and
>> needing the sentence "I accept the risk" as the first line to
>> work). Should this file exist on all debian systems for the sake of
>> being configuration files?
>
> This sounds like dissembling to me. When you name a file
>  foo.cnf in TeX, the .cnf does not stand for default values which
>  happen to be kept in a file. It actually stands for conf, or
>  configuration.  

There's exactly one file in tetex that is not in /etc/ and has the name
.cnf.  Should have made us look closer - that's the file that prompted
this bug report and which I already have conceeded should have been in
/etc/ from the start.

The usual extension for "configuration" files in a TeX system is cfg, or
a file is put into a directory called "config.  However, I can show you
many examples of files that meet these criteria, but are not intended by
upstream to be used for configuration.  Some of these are just "default
values" as in the uw-imapd case, some are not even that - just modules
loaded by the main package (e.g. microtype's cfg files).

Don't judge a file by its name.

>> I think the web2c mechanism is really good, and is the way
>> preferences should be set (source/distribution defaults in /usr,
>> system defaults in /etc, user defaults in ~/texmf or by environment
>> variables).
> Debian policy states that distribution specified configuration
>  files also live in /etc. and it is not as if correcting things is
>  rocket science -- ship a symlink in /usr for *.cnf files, linking to
>  real files under /etc, and you have policy compliance. 

Symlinks are not necessary in a web2c system, since /etc/texmf is a
TEXMF tree, too, anyway.  So please read up on what you are discussing
before answering.  I think Jean-Christophe is right when he says the
web2c mechanism is really good.

It even allows customization of document appearance, not only keeping
configuration files.

Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

[Ping] Packages-arch-specific: please add architectures to Ada packages

[Ludovic Brenta]

It has been a week since I sent the request below, and I received no
answer.  I am resending to the three maintainers of
Packages-arch-specific, and CCing debian-devel.

I've restricted the list of supported architectures to those where
gnat-4.1 not only exists but also builds its shared libraries.  This
is because all other packages are, or depend on, shared libraries that
depend on libgnat.

> Hello,
>
> I am doing a transition of Ada packages from gnat 3.15p to GCC 4.1 as
> the default compiler.  The new compiler adds support for alpha, arm,
> hppa, ia64, mips, mipsel, and s390 to the existing i386, powerpc and
> sparc.
>
> Also, most packages support kfreebsd-i386, too (even before the
> compiler transition).  I don't know if there are autobuilders for
> kfreebsd-i386.
>
> The packages affected are:
>
> ## Depend: on gnat
> %gnat: i386 sparc powerpc   # [ANAIS] 
> upstream support list
> %adasockets: i386 sparc powerpc
> %adabrowse: i386 sparc
> %adacgi: i386 sparc powerpc
> %asis: i386 sparc powerpc
> %gch: i386 sparc powerpc
> %gnade: !arm !m68k
> %gnat-glade: i386 sparc powerpc
> gnat-gps: i386 sparc powerpc
> %gvd: !arm !m68k
> %libadabindx: i386 sparc powerpc
> %libaunit: i386 sparc powerpc
> %libaws: i386 sparc powerpc # b-d on 
> libxmlada1(-dev)
> %libcharles0: i386 sparc powerpc
> %libflorist-3.15p-1: i386 sparc powerpc
> %libgtkada: i386 sparc powerpc
> %libgtkada2: i386 sparc powerpc
> %libopentoken: i386 sparc powerpc
> %libtexttools2: i386 sparc powerpc
> %libxmlada1: i386 sparc powerpc
> %topal: i386 sparc powerpc
>
> I have just uploaded package libxmlada2.  I have not yet decided
> whether or not to remove libxmlada1, so for now libxmlada2 can coexist
> with it.  I will upload a new version of libaws that b-d on libxmlada2
> rather than libxmlada1.
>
> gcc-4.1 does not build libgnat-4.1, libgnatvsn-dev and libgnatprj-dev
> on some architectures, namely alpha, mips, mipsel, and s390.  Some
> package build-depend on these libraries.
>
> I have uploaded adacontrol, which build-depends on asis.
>
> gvd has been removed from the archive; it is not even in Sarge.
>
> I have requested removal of gch, gnat, and libcharles0.
>
> Here is a list which I believe is correct:
>
> ## Depend: on gnat-4.1
> adacontrol: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc# b-d on asis
> %adasockets: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc
> %adabrowse: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc# b-d on asis
> %adacgi: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc
> %asis: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc
> %gnade: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc
> %gnat-glade: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc
> gnat-gps: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc  # b-d on 
> libgnatprj-dev
> %libadabindx: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc
> %libaunit: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc
> %libaws: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc   # b-d on 
> asis, libxmlada2
> %libgtkada2: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc
> %libopentoken: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc
> %libtexttools2: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc
> %libxmlada1: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc
> %libxmlada2: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc
> %topal: amd64 hppa i386 ia64 kfreebsd-i386 sparc powerpc
>
> Finally, I request that you trigger building asis (=2005-3) on the
> architectures that are newly supported; I have uploaded i386, and only
> sparc and powerpc have been autobuilt.  I am waiting for this so I can
> re-upload adacontrol and fix #378160.  If a build cannot be triggered,
> please tell me when I should re-upload to have asis on all supported
> architectures.
>
> Thank you for your attention.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Getting rid of circular dependencies, stage 5

[Joe Smith]

"Manoj Srivastava" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Fri, 21 Jul 2006 15:09:56 -0400, Joe Smith
<[EMAIL PROTECTED]> said:


Well, strictly speaking all circular dependencies could be
considered a policy violation because they depend on dpkg not
working as policy states it does.


   Could you elaborate on this?

   manoj
In the sense that you are abusing the terms of policy. It is true that dpkg 
will install and configure with circular dependecies,
but Policy states "A package will not be configured unless all of the 
packages listed in its Depends field have been correctly configured."


Clearly if dpkg really enforeced that, no circular dependecy would ever work 
as the packages would be installed, but could not be configured because a 
depencency was not configured.


Depending on a package not acting in the manner in which policy states it 
will could be considered a type of policy violation.


Granted it would not be sensical to report this as a bug on dpkg because it 
is simply going beyond what policy states it will do.
I would say that no package is directly violating policy, but ther packages 
are abusing policy. In one sense policy itself is the buggy package because 
it asserts something that is not true.


Then again, that section of policy looks a bit dated anyway, mentioning 
"dselect" despite the fact that that package is now all but completely 
obsoleted by apt and the various apt-frontends.




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Configuration file shadowed?

[Manoj Srivastava]

On Fri, 21 Jul 2006 21:54:50 +0200, Frank Küster <[EMAIL PROTECTED]> said: 

> Steve Greenland <[EMAIL PROTECTED]> wrote:
>> On 21-Jul-06, 13:41 (CDT), Jean-Christophe Dubacq <[EMAIL PROTECTED]> wrote:
>>> The way I see it, the /usr/share/texmf/mktex.cnf is a "default
>>> value file", used in the setup of the whole texmf hierarchy; the
>>> configuration is /etc/texmf/mktex.cnf, which, per web2c magic,
>>> overrides the default values, _if it does exist_. Good default
>>> values can be set by copying /usr/share/texmf/mktex.cnf, and
>>> return to default values can be done through the removal of
>>> /etc/texmf/mktex.cnf.
>> 
>> I'd buy that except for the debconf message, which implies that the
>> visibility of certain default value (MT_FEATURES, right?) blocked
>> by the mere existence of /etc/texmf/mktex.cnf, even though it's
>> unmentioned in that file.

> Indeed, the TeX Policy needs rewording, and this particular file
> should be a conffile, because it affects how the TeX programs and
> helper scripts act.  In general, files that influence documents and
> are read because they are somehow requested in TeX's input (or
> BibTeX's or whatever) make no sense in /etc.

Yes, I agree: those are closer in sense to being library
 modules (\usepackage{foo} seems to indicate that foo.tex is a
 library-equivalent, not a configuration file)

manoj
-- 
Pecor's Health-Food Principle: Never eat rutabaga on any day of the
week that has a "y" in it.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Getting rid of circular dependencies, stage 5

[Manoj Srivastava]

On Fri, 21 Jul 2006 16:25:16 -0400, Joe Smith
<[EMAIL PROTECTED]> said:  

> "Manoj Srivastava" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> On Fri, 21 Jul 2006 15:09:56 -0400, Joe Smith
>> <[EMAIL PROTECTED]> said:
>> 
>>> Well, strictly speaking all circular dependencies could be
>>> considered a policy violation because they depend on dpkg not
>>> working as policy states it does.
>> 
>> Could you elaborate on this?
>> 
>> manoj
> In the sense that you are abusing the terms of policy. It is true
> that dpkg will install and configure with circular dependecies, but
> Policy states "A package will not be configured unless all of the
> packages listed in its Depends field have been correctly
> configured."

I see you have not fully followed through on reading policy
 here: 

,[ § 7.2 ]
|  In case of circular dependencies, since installation or removal order
|  honoring the dependency order can't be established, dependency loops
|  are broken at some random point, and some packages may not be able to
|  rely on their dependencies being present when being installed or
|  removed, depending on which side of the break of the circular dependcy
|  loop they happen to be on.
`


> Clearly if dpkg really enforeced that, no circular dependecy would
> ever work as the packages would be installed, but could not be
> configured because a depencency was not configured.

Clearly, dpkg authors have read all of policy, including the
 caveats about circular dependencies.


> Depending on a package not acting in the manner in which policy
> states it will could be considered a type of policy violation.

Except that that is not the case here.

On Fri, 21 Jul 2006 22:15:18 +0200, Loïc Minier
<[EMAIL PROTECTED]> said:  

>  I think he meant that dpkg breaks the loop, and installs packages
>  despite their dependencies not being installed.

Err, which is condoned by policy:

manoj
-- 
You will pioneer the first Martian colony.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Getting rid of circular dependencies, stage 5

[Joe Smith]

"Manoj Srivastava" <[EMAIL PROTECTED]> wrote:

   I see you have not fully followed through on reading policy
here:
,[ § 7.2 ]
|  In case of circular dependencies, since installation or removal 
order

|  honoring the dependency order can't be established, dependency loops
|  are broken at some random point, and some packages may not be able 
to

|  rely on their dependencies being present when being installed or
|  removed, depending on which side of the break of the circular 
dependcy

|  loop they happen to be on.
`



Well then policy contradicts iteself by failing to note this exception in 
the other location.




Clearly if dpkg really enforeced that, no circular dependecy would
ever work as the packages would be installed, but could not be
configured because a depencency was not configured.


   Clearly, dpkg authors have read all of policy, including the
caveats about circular dependencies.


Be that as it may, dpkg does not act as that part of policy indicates.
If there is an exception it really should be noted at that location, not 
someplace else.







--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: lilypond and python

[Thomas Bushnell BSG]

Matthias Klose <[EMAIL PROTECTED]> writes:

> well, there's curently only one person spreading lies and fud about
> python packaging, so please don't talk about "lies" as well. I'm still
> testing uprades and fixing upgrade issues. experimental has a
> python-defaults pointing to 2.4, so you can prepare your package and
> upload it to experimental. "pending" doesn't imply "will be fixed in x
> days".

What *does* pending mean?  You seemed to use it to mean "please stop
asking me the question I promise to ignore forever anyway."

All I have ever wanted from you is *some* clear indication of what
your plans are, and this is the one thing you have rudely and, IMO,
unacceptably refused to provide.

I'll try again, since you seem to be willing to reply at the moment.

When do you estimate python-defaults will point to 2.4 in unstable?

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: lilypond and python

[Thomas Bushnell BSG]

Loïc Minier <[EMAIL PROTECTED]> writes:

> On Tue, Jul 18, 2006, Thomas Bushnell BSG wrote:
>> So, let me make plain: I am entirely happy to accept a workaround
>> patch for lilypond's current upstream stable release that will make it
>> build and use python 2.4 even when that is not installed as "python".
>> If such a functional patch appears and is mailed to the appropriate
>> lilypond bug, it would immediately become a high priority matter for
>> me to upload it.  I have wanted to do so for months.
>
>  Here's a patch (which I couldn't test, see below).

Unfortunately, the patch is not against the new upstream lilypond.

Since Matthias Klose says that python-defaults points to 2.4 in
experimental, I can package lilypond and upload it to experimental;
that will probably happen this weekend unless an unexpected problem
arises.

Thomas

Re: lilypond and python

[Thomas Bushnell BSG]

Matthias Klose <[EMAIL PROTECTED]> writes:

> experimental has a python-defaults pointing to 2.4

When did this happen?  Is there some reason you didn't reply to my
status-requests with this information?  Why are you trying to keep
things secret from me?

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#379196: ITP: beaglefs -- implements a filesystem representing a live Beagle query

[Andrew Mitchell]

Package: wnpp
Severity: wishlist
Owner: Andrew Mitchell <[EMAIL PROTECTED]>

* Package name: beaglefs
  Version : 1.0.3
  Upstream Author : Robert Love <[EMAIL PROTECTED]>
* URL : 
http://www.kernel.org/pub/linux/kernel/people/rml/fuse/beaglefs/
* License : GPL
  Programming Lang: C
  Description : implements a filesystem representing a live Beagle query

 beaglefs implements a filesystem representing a live Beagle query. The
 filesystem represents query hit results as symlinks to the hit targets.
 .
 In addition, beaglefs provides the following features:
  - Live updating: The filesystem is updated on-the-fly as hits come and go.
  - Extended Attributes: Beagle hit metadata is exported as extended
attributes in the system.Beagle.* namespace.
  - Constant time operations: The backing data structure is a hash table,
providing O(1) best-case complexity for many operations.
  - Supported file operations: readdir, readlink, getxattr, listxattr, stat,
and statfs.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-25-amd64-k8
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]