Re: udev vs ldap at startup

[Gabor Gombas]

On Fri, Aug 11, 2006 at 12:56:23PM +0200, Vincent Danjean wrote:

> Then, I've been unable to start the userspace. I mean, even
> with 'init=/bin/bash' on the kernel cmdline, it did not work
> (ie it hung up).

Next time try "init=/bin/dash". dash avoids the unneccessary NSS lookups
bash performs.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: Silly Packaging Problem

[Bruce Sass]

On Fri August 11 2006 04:51, Ian Jackson wrote:
> Bruce Sass writes ("Re: Silly Packaging Problem"):
> > "files" and "size" accommodate the desire to include generated or
> > packageless files and their size (if knowable) in the dpkg DB.
>
> This is a bad idea.  dpkg maintains these lists of files not
> primarily for the purpose of dpkg -S, but rather for making the
> package management operations (install, upgrade, remove, etc.) work
> properly.
>
> If you start editing these files (even with the relevant lock held
> and with regard to the package status), dpkg will behave differently
> afterwards: it will think the file in question was shipped in the
> currently installed package's .deb.

iow Hacking the DB may work while the system is static but not in the 
middle of (say) installing 2+ pkgs.

> This is almost certainly not what you want.  A good general principle
> is to practice ownership: dpkg should remove and update things it has
> installed; maintainer scripts and other programs should remove and
> update things they created.

It looks to be what is wanted, eventually anyways. Queueing the 
update-package commands and processing them after dpkg finishes could 
work?

I agree with that general principle, in this case dpkg already owns the 
data (list of files in the package and Installed-Size). ;-)

[insert "dpkg DB->.deb" vs. "dpkg DB->system" argument]
[insert ".deb->created files" vs. ".deb + created" argument]

> If the objective is to make dpkg -S more useful (a worthy goal) then
> you need a separate list for each package, of files which should be
> reported in -S but which dpkg should otherwise ignore.

It looks like ensure_packagefiles_available() in filesdb.c would be the 
place to do this (essentially duplicating most of the action in lines 
115-172 with a different filelistfile, maybe only if doing -L or -S?), 
afaict, but my C's pretty old and rusty.


- Bruce


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

Re: cdrtools

[Wouter Verhelst]

On Thu, Aug 10, 2006 at 11:25:11PM +0200, Joerg Schilling wrote:
> 1)Throw out Eduard Bloch.

rotflmao.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Buildds still not picking up new architectures, why?

[Wouter Verhelst]

On Wed, Aug 09, 2006 at 04:38:20PM -0400, Kevin Mark wrote:
> So there is ONE w-b for {i386,ppc,...) and there is one buildd for each
> arch that connects to that ONE w-b?

No. There is one system where wanna-build databases are stored. That
single one wanna-build system has, of course, multiple databases, but
there's only one version of wanna-build (the distinction is made with a
command-line parameter in the form of "-b /build-db"

There are a number of buildd machines for each arch that connect to that
one w-b machine and call it correctly, based on their local
configuration and other things. The number of buildd machines is not
limited, certainly not to just one (in fact, requirements for etch
include "having more than one buildd").

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Is inability to operate with root read-only (and separate /etc, /dev, etc) a bug or design decision?

[Daniel Dickinson]

A little while back I tried to setup a system that used a read-only
root filesystem during regular operation and ran into some problems
during boot.  The first is that /etc needs to be read-write but init
scripts break badly if /etc is not on the root filesystem (probably could
be fixed in initramfs-tools).
The second problem I had was that, before udev is ready, /dev needs to
be writable (this was with sarge; maybe initramfs-tools already solves
this).

I will do testing with etch if this is something that should work.

-- 
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C  http://gnupg.org
And that's my crabbing done for the day.  Got it out of the way early, 
now I have the rest of the afternoon to sniff fragrant tea-roses or 
strangle cute bunnies or something.   -- Michael Devore


signature.asc
Description: Digital signature

Re: Successful and unsuccessful Debian development tools

[Raphael Hertzog]

On Wed, 02 Aug 2006, David Nusinow wrote:
> On Wed, Aug 02, 2006 at 11:56:44PM +0200, Adeodato Simó wrote:
> > * David Nusinow [Wed, 02 Aug 2006 17:37:23 +]:
> > 
> > > (I'm seriously
> > > interested in setting up git.debian.org for XSF work, for example*),
> > 
> > > * If anyone else is interested in this, contact me and we'll talk
> > 
> > There is _something_ in costa:/srv/git.debian.org/git already.
> 
> Interesting... any idea if the git server is working? Also, if its
> permissions are hooked in the rest of alioth like svn? If so, I'll be a
> very happy boy.

I've installed git-core (IIRC) on request of maks. AFAICT, it's enough to
use git rsync method apparently. 

And yes permissions on costa are always hooked to alioth.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: package ownership in Debian

[Raphael Hertzog]

On Sat, 29 Jul 2006, Gustavo Franco wrote:
> >Another, perhaps more parseable format, would be:
> >
> >  X-VCS-Url: ${VCS}:${URL}
> >  X-Vcs-Url: bzr:http://people.debian.org/~adeodato/code/packages/taglib
> >
> >Though you'd had to wonder what you'd do with a svn:// url.
> >
> 
> Looks good, but i think we could write a proposal for new headers to
> address 'vcs' and 'homepage' needs, or add it somewhere else and sync
> (like we do with Tags). Thoughts?

My plan has always been to add this to a new (collaborative) database:
http://wiki.debian.org/CRMI

Why not in the control file? Because some maintainers don't want and it's
very important to have consistency across all packages so we must have the
possibility to add that information for packages where the maintainer is
not interested in providing it himself.

(But it's still vapourware at this stage.)

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Is inability to operate with root read-only (and separate /etc, /dev, etc) a bug or design decision?

[Marco d'Itri]

On Aug 12, Daniel Dickinson <[EMAIL PROTECTED]> wrote:

> A little while back I tried to setup a system that used a read-only
> root filesystem during regular operation and ran into some problems
> during boot.  The first is that /etc needs to be read-write but init
> scripts break badly if /etc is not on the root filesystem (probably could
> be fixed in initramfs-tools).
Most of this should have been fixed.

> The second problem I had was that, before udev is ready, /dev needs to
> be writable (this was with sarge; maybe initramfs-tools already solves
> this).
I do not remember this being true in sarge.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Remove cdrtools

[Bernd Schubert]

> The fork-team can look at http://www.arklinux.org/projects/dvdrtools, a
> 100% free fork of cdrtools.
> The SVN is inactive from 6 month, but the autotool-ization is already
> done and it can write on DVDs, and probably is better than starting
> another fork.

Btw, why always the autotools while there's this nice cmake? The cmake build
system might even get accepted by Joerg, as it can create makefiles for MS
compilers (I know, its not important to this list and also not to me, but
it seems to be important for Joerg).

Cheers,
Bernd


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

Re: md5 sum mismatches and mirror syncs

[Goswin von Brederlow]

martin f krafft <[EMAIL PROTECTED]> writes:

> also sprach Goswin von Brederlow <[EMAIL PROTECTED]> [2006.08.11.2326 +0100]:
>> The algorithm used is 2pass. First pass only mirrors pool while the
>> second pass mirrors the Release and Packages files. The time a mirror
>> is out of sync should always be limited to the time it takes to
>> download the Packages file after the Release file. All the index files
>> are done in one chunk file to file. A matter of minutes at most.
>
> Or almost 10 hours as was the case today.
>
> So if rsync dies, maybe this is the problem to fix? Is it?

I suspect as much.

Even if you just rsync the whole thing then all files and directories
are processed in alphanumerical order. That means that first all of
debian/dists is synced (Release and Packages files). With a single
pass you get lots of "File not found" errors while the sync is running
because debs (pool) are synced after the index file. But hitting the
right time when Release is synced but Packages not is somewhat
unlikely. Nothing that would remain for 10h.

I only see 3 possibilities of a longer mirror corruption:

1. rsync died

2. rsync made an error and corrupted the file
   Has anyone seen that ever?

3. the sync was started while upstream was out-of-sync
   With push mirroring that means upstream has the problem and
   ultimately some upstream had 1 or 2 happening.


I've seen 1 happening but not 2 personaly.

MfG
Goswin


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

Re: Is inability to operate with root read-only (and separate /etc, /dev, etc) a bug or design decision?

[Goswin von Brederlow]

Daniel Dickinson <[EMAIL PROTECTED]> writes:

> A little while back I tried to setup a system that used a read-only
> root filesystem during regular operation and ran into some problems
> during boot.  The first is that /etc needs to be read-write but init
> scripts break badly if /etc is not on the root filesystem (probably could
> be fixed in initramfs-tools).

Having /etc not on / is a problem becuase /etc/fstab is used to mount
things. You need a skeleton /etc on / with a minimal /etc/fstab and
any other files that are used before /etc is mounted. But I wouldn't
go there. That is the wrong approach.

Instead move the things in etc that need writing to other places:

1) link /etc/mtab to /proc/mounts and create a dummy /proc/mounts on /
   for when /proc isn't mounted (works with quota in current kernels).
2) Link /etc/resolv.conf to /var or install resolvconf package.
3) Link /etc/network/run to /dev/shm/

and so on.

A read-only / needs some configuring but it must be possible. If
anything blindly writes to /etc without provision of using some other
place or following a link then please file a bug.

MfG
Goswin


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

Re: Status of inetd for etch

[Petter Reinholdtsen]

[Roger Leigh]
> Any thoughts or comments?

For the LTSP thin client environment, I switched to openbsd-inetd
because I could not avoid an inetd, and the openbsd version didn't
start when no service was enabled in /etc/inetd.conf.  We do the same
in Debian-edu.  A minor problem is that we are unable to remove
netkit-inetd from the CD, because debootstrap claim it is a required
part of base and refuses to accept openbsd-inetd in its place.  The
latter might be because we use debootstrap from sarge.

I am all for replacing netkit-inetd with something less broken, and
preferably make it possible to install a minimal installation like the
diskless LTSP clients without such package.  We want these clients
booting on 32 MiB of ram, including the ramdisk, so every KiB of
memory saved counts.  :)

Friendly,
-- 
Petter Reinholdtsen


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

Re: Remove cdrtools

[Jon Dowland]

At 1155391794 past the epoch, Bernd Schubert wrote:
> Btw, why always the autotools while there's this nice
> cmake? 

I've never used cmake myself, so I can't speak for how nice
it is, but autotools (for all its problems) is very
widespread.

> The cmake build system might even get accepted by Joerg,
> as it can create makefiles for MS compilers (I know, its
> not important to this list and also not to me, but it
> seems to be important for Joerg).

I'd consider that points /against/ it's favour.

-- 
Jon Dowland
http://alcopop.org/


signature.asc
Description: Digital signature

Re: Remove cdrtools

[Francesco Pedrini]

Alle Saturday 12 August 2006 16:09, Jon Dowland ha scritto:
> At 1155391794 past the epoch, Bernd Schubert wrote:
> > Btw, why always the autotools while there's this nice
> > cmake?
>
> I've never used cmake myself, so I can't speak for how nice
> it is, but autotools (for all its problems) is very
> widespread.

the same for me.

> > The cmake build system might even get accepted by Joerg,
> > as it can create makefiles for MS compilers (I know, its
> > not important to this list and also not to me, but it
> > seems to be important for Joerg).
>
> I'd consider that points /against/ it's favour.

If a new free fork is started JS has nothing to do with it, IMHO.

-- 
:wq


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

Re: dh_python and python policy analysis

[Lars Wirzenius]

la, 2006-08-12 kello 18:10 +0200, Pierre Habouzit kirjoitti:
> > >/usr/share/pycentral
> > >/usr/share/python-support
> >
> > These location are tool specific and should not be referenced
> > explicitely in the packaging scripts (debian/rules)
> 
> agreed

python-support seems to require me to put something
into /usr/share/python-support (either the .py files, or a .dirs file
for a package with private modules). How should I put them there without
mentioning the location explicitly?

(Note that offering dh_anything is not a sufficient answer. The whole
point of Manoj's document is to get the Python policy away from
mandating debhelper, or any other helper package.)

-- 
I am a werehuman.


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

Re: Status of inetd for etch

[Steve Langasek]

On Fri, Aug 11, 2006 at 10:27:39AM +0100, Roger Leigh wrote:
> [EMAIL PROTECTED] (Marco d'Itri) writes:

> > On Aug 10, Roger Leigh <[EMAIL PROTECTED]> wrote:

> >>   installed, all using the same configuration file.  Is this a use
> >>   case we really want to support?  Are there really setups running
> >>   multiple inetds for a good reason?  Having a virtual
> > A good reason usually is using features not available in a single
> > package (especially inetd vs. inetd).
> > It's not hard to manage anyway, my scheme allowed this.

> We don't allow multiple mail-transport-agents, even though they have
> different features.

We don't allow multiple mtas because a mail-transport-agent is *required* to
provide /usr/sbin/sendmail.  There is no such file conflict for most of
these other network services.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: ITP: subtitleeditor -- Graphical subtitle editor with sound waves representation

[Peter Samuelson]

[Amaya Rodrigo Sastre]
> >  This program also shows soundwaves which makes it easier for
> >  subtitles synchronisation that most other subtitle editors like
>  
> >  ksubtile or gaupol.

This program also shows sound waves, which makes it easier to
synchronise subtitles to voices.

No need to mention the competitors, really.


signature.asc
Description: Digital signature

Re: Is inability to operate with root read-only (and separate /etc, /dev, etc) a bug or design decision?

[Peter Samuelson]

[Goswin von Brederlow]
> Instead move the things in etc that need writing to other places:
> 
> 1) link /etc/mtab to /proc/mounts and create a dummy /proc/mounts on /
>for when /proc isn't mounted (works with quota in current kernels).

Does the wrong thing with (a) user and (b) loop mounts.  [I just tested
2.6.16-1-k7.]  /etc/mtab needs to keep enough state for umount to know
(a) who mounted something, so the same user can unmount it, and (b)
that a loop device was set up automatically via 'mount -o loop', rather
than done separately, so that umount can 'losetup -d /dev/loopN'.  This
is information which cannot, at present, be put in /proc/mounts.

> 2) Link /etc/resolv.conf to /var or install resolvconf package.
> 3) Link /etc/network/run to /dev/shm/

Wait, didn't /run get created at some point?  Did that get reverted,
and if so, why?


signature.asc
Description: Digital signature

Re: cdrtools

[Joerg Schilling]

Jean Parpaillon <[EMAIL PROTECTED]> wrote:

> Beside the licensing issues, why do you care so much patched version of 
> your software to be distributed with big WARNINGS, a different name and 
> tutti quanti ?

Why do Linux distributions insist in applying patches that introduce bugs
into cdrtools?

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily


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

My take on the Python policy: draft

[Manoj Srivastava]

Hi,

Here comes draft 1.0.4, with suggestions from  Matthias Klose
 incorporated (well, most of them). The current and future updates,
 are to be found at
 http://www.golden-gryphon.com/software/manoj-policy/.

The sources are at:
 http://www.golden-gryphon.com/software/manoj-policy/python-policy.xml,
 and are now licensed under th GPL (for some reason, docbook article
 mode suppresses LegalNotice).

I am including a text version below.

manoj


  Packaging with the new Python policy

A package developers view

  Manoj Srivastava

   Developer
   The Debian Project

   Copyright (c) 2006 Manoj Srivastava

   Revision History
   Revision 1.0.4 12 Aug 2006
   Revision 1.0.3 10 Aug 2006
   Revision 1.0.2 8 Aug 2006
   Revision 1.0.1 07 Aug 2006
   Revision 1.0.0 31 Jul 2006

   Specification of the new Python policy. This article grew as an attempt to
   correct a gap in the concrete specification of the new Python policy, and
   has grown to be close to a formal specification of the proposed new
   policy.

   --

   Table of Contents

   1. [1]Introduction

1.1. [2]Acknowledgements

   2. [3]Goals of the new Python policy

   3. [4]Nomenclature and definitions

3.1. [5]Python versions

 3.1.1. [6]The Default Python version

3.2. [7]Categorization of Python software

   4. [8]General Notes

4.1. [9]Naming python module packages

4.2. [10]Python versions supported by the source

4.3. [11]Byte compilation

4.4. [12]Linking extention modules

4.5. [13]Depends:

4.6. [14]Provides

4.7. [15]Build-Depends:

4.8. [16]Deprecating "current" in versions supported

   5. [17]Recipe for developers

5.1. [18]Script

 5.1.1. [19]Supported versions

5.2. [20]Private Pure Python Modules

 5.2.1. [21]Byte compilation

 5.2.2. [22]Supported versions

5.3. [23]Private Extension

 5.3.1. [24]Supported versions

5.4. [25]Public pure Python Module

 5.4.1. [26]Byte compiling

 5.4.2. [27]Supported versions

 5.4.3. [28]Depends:

5.5. [29]Public Extension

 5.5.1. [30]Supported versions

 5.5.2. [31]Provides

   6. [32]Changing the default Python version

6.1. [33]Python rtupdate scripts

 6.1.1. [34]rtupdate script invocation

1. Introduction

 While trying to update SELinux packages, I ran across problems in trying
   to determine if my packages were complying with the new python policy: any
   practical tips for packaging generally devolved to the statement "Oh, just
   run dh_python". This is my attempt to offer more concrete tips for
   packaging. While this document started by reverse engineering dh_python,
   it has, thanks to help from various people more knowledgeable about Python
   than I, moved beyond that, and is closer to being a specification
   unfettered by the idiosyncrasies of current tools and implementations.

 So now this document is a draft formal specification of the proposed new
   Python packaging policy. While it draws upon earlier documents, notable
   [35]Debian Python Policy , and the [36]new policy Wiki, the [37]Debian
   Python FAQ, and the source code for dh_python, and debhelper scripts, it
   has essentially been written from scratch, with material reworded,
   reorganized, and rearranged, to the extent that it bears little
   resemblance to the original sources.

 Compiled Python modules are very dependent on the specific Python
   version they were compiled against, and may otherwise have restrictions on
   the versions of Python they are compatible with. Unless care is taken,
   introducing, or dropping, new versions of Python, or changing the default
   version, trigger long and often painful transitions where the archive is
   inconsistent, and the systems is ill-integrated for the duration. This new
   Python policy seeks to address these potential messy transitions, and
   minimize the pain.

   --

  1.1. Acknowledgements

 While this document draws upon the expertise of multiple people and
   various documents, it has benefited especially from the patience and
   gentle corrections of people on the Debian-devel mailing list, and
   specifically from Josselin Mouette, Loíc Minier, Pierre Habouzit, and
   Matthias Klose.

   -

Re: Status of inetd for etch

[Matthew R. Dempsky]

On Sat, Aug 12, 2006 at 10:21:50AM -0700, Steve Langasek wrote:
> We don't allow multiple mtas because a mail-transport-agent is *required* to
> provide /usr/sbin/sendmail.

Why can Debian's alternatives system not alleviate this conflict?


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

Re: cdrtools

[Florian Weimer]

* Daniel Schepler:

> And since dynamic linking is done at the time the program is run, this would 
> appear to me to be what applies.  In particular, it appears to me that you 
> could satisfy the GPL and still dynamically link against a non-free library, 
> and distribute both, by invoking the "mere aggregation" clause of section 2.  

As a countermeasure, the FSF tries to extend copyright to interfaces,
so that you do create a derivative work merely by programming to a
specific interface of a library written by someone else, without
copying their code.  I'm not sure if this is such a bright idea.


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

Re: cdrtools

[Joerg Schilling]

Gunnar Wolf <[EMAIL PROTECTED]> wrote:

> the author's official module). You say that I don't have the right to
> distribute this under the name PDF::API2 in Debian, do I understand
> correctly? Please tell me: This module is a Perl library. If I modify
> it to become PDF::API2::Debian, how will our users' code be portable?

You are a funny person.

You like to talk avout portabilitiy but the patches that Debian aplies to 
cdrtools are only from two categories:

-   Patches that introduce bugs that cannot be found in the original
software

-   Patches that make the Debian version incompatible to the official
version and thus prevent portability of scripts and GUI programs

What I request from distributors is only a result of the malicious ways well 
known distributors go. There was no need to add these requirements in case that
all distributors would be cooperative.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily


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

Re: cdrtools

[Thomas Bushnell BSG]

Florian Weimer <[EMAIL PROTECTED]> writes:

> * Daniel Schepler:
>
>> And since dynamic linking is done at the time the program is run,
>> this would appear to me to be what applies.  In particular, it
>> appears to me that you could satisfy the GPL and still dynamically
>> link against a non-free library, and distribute both, by invoking
>> the "mere aggregation" clause of section 2.
>
> As a countermeasure, the FSF tries to extend copyright to interfaces,
> so that you do create a derivative work merely by programming to a
> specific interface of a library written by someone else, without
> copying their code.  I'm not sure if this is such a bright idea.

Interface copyright attempts to prohibit making a second
implementation of the same interface.  That is not what is going on
here.  

Thomas


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

Re: Is inability to operate with root read-only (and separate /etc, /dev, etc) a bug or design decision?

[Goswin von Brederlow]

Peter Samuelson <[EMAIL PROTECTED]> writes:

> [Goswin von Brederlow]
>> Instead move the things in etc that need writing to other places:
>> 
>> 1) link /etc/mtab to /proc/mounts and create a dummy /proc/mounts on /
>>for when /proc isn't mounted (works with quota in current kernels).
>
> Does the wrong thing with (a) user and (b) loop mounts.  [I just tested
> 2.6.16-1-k7.]  /etc/mtab needs to keep enough state for umount to know
> (a) who mounted something, so the same user can unmount it, and (b)
> that a loop device was set up automatically via 'mount -o loop', rather
> than done separately, so that umount can 'losetup -d /dev/loopN'.  This
> is information which cannot, at present, be put in /proc/mounts.

Yes. If you need that feature help patching the kernel (like the new
quota support in /proc/mounts) or link it to somewhere else.

>> 2) Link /etc/resolv.conf to /var or install resolvconf package.
>> 3) Link /etc/network/run to /dev/shm/
>
> Wait, didn't /run get created at some point?  Did that get reverted,
> and if so, why?

I think it never finaly got created. Having a /run is imho the right
solution for early boot writable files. Easy enough to configure too
if one wants it.

MfG
Goswin


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

Re: cdrtools

[Goswin von Brederlow]

Joerg Schilling <[EMAIL PROTECTED]> writes:

> Jean Parpaillon <[EMAIL PROTECTED]> wrote:
>
>> Beside the licensing issues, why do you care so much patched version of 
>> your software to be distributed with big WARNINGS, a different name and 
>> tutti quanti ?
>
> Why do Linux distributions insist in applying patches that introduce bugs
> into cdrtools?
>
> Jörg

Why do you insist on programming bugs into cdrtools that linux
distributions have to fix by patching?

Why do you to typos? Why do you stumble sometimes or trip over
something?

Do you see how stupid your question is? Nobody intentionaly introduces
bugs here.

MfG
Goswin


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

Re: cdrtools

[Goswin von Brederlow]

Joerg Schilling <[EMAIL PROTECTED]> writes:

> Gunnar Wolf <[EMAIL PROTECTED]> wrote:
>
>> the author's official module). You say that I don't have the right to
>> distribute this under the name PDF::API2 in Debian, do I understand
>> correctly? Please tell me: This module is a Perl library. If I modify
>> it to become PDF::API2::Debian, how will our users' code be portable?
>
> You are a funny person.
>
> You like to talk avout portabilitiy but the patches that Debian aplies to 
> cdrtools are only from two categories:
>
> - Patches that introduce bugs that cannot be found in the original
>   software
>
> - Patches that make the Debian version incompatible to the official
>   version and thus prevent portability of scripts and GUI programs
>
> What I request from distributors is only a result of the malicious ways well 
> known distributors go. There was no need to add these requirements in case 
> that
> all distributors would be cooperative.
>
> Jörg


How is the weather today?

I told you, the grass is green.


Please try to read, understand and answere the question asked in a
mail. Hint: The question wasn't about cdrtools patches.

MfG
Goswin


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

Re: ITP: subtitleeditor -- Graphical subtitle editor with sound waves representation

[Marvin Renich]

* Peter Samuelson <[EMAIL PROTECTED]> [060812 14:00]:
> 
> No need to mention the competitors, really.

I strongly disagree.  While an individual upstream author may have
competitive feelings towards other software that provides similar
functionality, one of Debian's primary priorities is its users (as
opposed to its upstream authors).  The Debian community recognizes that
different software that provide the same basic functionality may each
have their own advantages and disadvantages, and providing more than one
package with similar functionality is usually a "Good Thing".

If you are going to provide two subtitle editors (for example), knowing
the pros and cons of each helps the users (me, for one!) decide which
one (or more) best suits my needs.  Listing specific (important)
differences from other specifically named packages in the package
description is extremely helpful to me (and, presumably, other users).

Also, it impresses me when a package description says something like "if
you need feature X, you are better off with package M, but this package
provides feature Y which package M doesn't have."

...Marvin


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

Re: cdrtools

[Joerg Schilling]

Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

> Why do you insist on programming bugs into cdrtools that linux
> distributions have to fix by patching?

You should inform yourself about reality

The original sources do not have such bugs and many Debian users that 
did write bug reports against the Debian version of cdrtools did already
switch to a self compiled original source in order to get a working cdrecord.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily


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

Re: cdrtools

[Hubert Chan]

Joerg Schilling wrote:

> Nice to see that this video clip verifies my statements in case you
> carefully listen to Simon Phipps:

> - Sun did not make the CDDL incompatible by intention to the GPL 

Are you talking about what he's saying at approx. minute 36?  That's the
closest thing I could find to what you're claiming he said, but he's
talking there about why they didn't release OpenSolaris under the GPL.
He's not saying anything about whether or not the CDDL is incompatible
with the GPL.

> - The only thing that prevents Linux to use the DTrace code in
>   Linux is the different threading model

Actually, what he's saying is that the different threading model
prevents you from cut-and-pasting code.  He's saying that in order to
port DTrace to Linux, due to the different architecture, you would have
to basically rewrite it, and so the CDDL would not cause any problems in
that case, since you are rewriting, and would not be creating a
derivative work.

What he's saying is that the technical problems are bigger than the
legal problems, and that the most sane way to get around the technical
problems are to do so in such a way that the legal problems no longer
apply.  He is not saying that there are no legal issues.

> - Eben Moglen tells you that what I do in cdrtools is OK:
>   "They" the FSF and Moglen have only be in fear that people
>   could interpret the GPL in a wrong way and for this reason
>   added the OS exception, but the GPL does allow to link a
>   GPLd project against libraries under other licenses.

He's specifically talking about the so-called "operating system
exception" in the GPL v2, and what the GPL v3 refers to as "System
Libraries".  He's not talking about any random library.

-- 
Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA   (Key available at wwwkeys.pgp.net)
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA


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

Re: ITP: subtitleeditor -- Graphical subtitle editor with sound waves representation

[Martijn van Oosterhout]

On 8/12/06, Marvin Renich <[EMAIL PROTECTED]> wrote:

Also, it impresses me when a package description says something like "if
you need feature X, you are better off with package M, but this package
provides feature Y which package M doesn't have."


There was, not so long ago, a complaint about "apt-cache search"
returning useless matches because descriptions tended to include stuff
not relevent to them. Like searches for "perl" would match php,
because they listed a "competitor".

If your package doesn't have feature X then you probably shouldn't be
mentioning it in the description.

What you say is nice to know, but the description is not the right place.

Have a nice day,
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/


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

Re: cdrtools

[Goswin von Brederlow]

Joerg Schilling <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>
>> Why do you insist on programming bugs into cdrtools that linux
>> distributions have to fix by patching?
>
> You should inform yourself about reality

Are you willing to put money where your mouth is and offer a reward
for finding a bug like the tex author does?

Every programm has bugs. Some more, some less. Tex being a the verry
end of less with very very few others.

MfG
Goswin


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

Re: dh_python and python policy analysis

[Bruce Sass]

On Sat August 12 2006 09:34, Matthias Klose wrote:

First time I've seen the design goals laid out like this. Thanks, and 
sorry if this is out of place.

> No, not the whole design goal.  Although the document is titled
> "developer's view", the other goals should be mentioned as well.
> These are meant to work around processes in debian which are
> currently suboptimal, but unlikely to change.
>
>  - The need to support more than one version of a python runtime or
>to support different implementations was seen.  It takes a while
>until applications support a new version.

What is needed now is a way to prevent all but the "default" modules and 
those selected by the admin from being built for all installed runtimes 
so Debian can re-step forward and properly support multiple runtimes.

The new policies all-or-nothing attitude wrt modules is too much. It 
effectively forces one Python only and unnecessarily discourages Python 
hackers and developers because the cost of carrying all modules for all 
installed versions, instead of just those modules needed for the work 
being done in the different versions, can be quite high for someone 
with a comprehensive installation of even one Python version.

>  - The old schema of using pythonX.Y-foo packages let's land packages
>in the NEW queue, when support for another python runtime is added
>to the package.  That certainly is a process, which could be
>addressed by FTP master (do not process a pythonX.Y+1-foo package
>manually, if pythonX.Y-foo is already in the archive).

If pythonX.Y+1-foo has a "-1" or "-0.x" Debian version then it is a NEW 
package...

>Having pythonX.Y-foo mentioned in the control file would disallow
>binary NMU's in situations where a python runtime is dropped or
>added (the control needs to be regenerated).  A solution would be
>to define an own target to regenerate the control file, which is
>not called during the normal package build.  Such source package
>would not be binNMUable, but could be the target of automated
>uploads.

...as are all packages built against a new runtime (see next paragraph), 
and if an X.Y runtime is dropped so are any X.Y-foo packages. So, what 
is the objective of this design goal? Pushing untested packages into 
the archive appears to be the result.

Python routinely spits out warnings about code breaking changes 
happenning at the minor version level, surely that requires better 
handling than blindly binNMUing packages (what else can mass binNMU's 
be?)... the package's metainfo looks good, but nobody familiar with the 
code has actually tried the combination (build, intalled, and at least 
some testing) to see how it works, with any arch?  That is 
un-Debian-like, even for unstable, and as a 10+ year Debian user I 
think I am within my rights to make such a judgement.

>  - Putting extension modules for more than one python version into
>a package eases transition of these packages to the testing
>distribution, provided that the package supports to default python
>version in testing and the default python version in unstable.
>The schema used before with python-foo depending on
>python-foo required an extra upload of every package
>containing an extension, adding new dependencies on new shared
>libraries in unstable, but not yet in testing. All packages having
>a python (<< X.Y) dependency had to be moved to testing at once.

This needed to be fixed, but more time should have been taken in the 
planning because the entirety of the solution is even more suboptimal 
than the previous (incomplete) policy, imo.

The thing that seems really telling in all this is that team maintenance 
promises to increase the quality of packages, yet Debian's Python team 
is explicitly using it to potentially decrease quality with mass 
binNMUs to speed up transitions to new runtime environments.

I really hope someone shows how I've just made a fool of myself but I 
don't have a lot of confidence that will happen because speed and 
quality are usually a trade-off.


- Bruce


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

New desktop features provided by new version of update-notifier

[Gustavo Noronha Silva]

Fellow Debianers,

I'm writing to you all in order to present some new features added to
the Debian Desktop, and to discuss how we could make use of them in
some of our subsystems.

I just uploaded update-notifier 0.42.12-1 to unstable. Unfortunately I
lost dinstall for the day, so we'll only see the results in unstable
many hours from now, though I've uploaded them to a public location[0].

update-notifier is a program made by the Ubuntu guys which puts a
notification icon in the notification area and warns the user about
updates being available, and allowing them to run update-manager (a
simple upgrade manager tool based on Synaptic).

This version of the Debian package brings some more robust utnubu work,
such as making the reboot required notification and Debian CD insertion
detection work.

The first feature is useful for those packages which are critical, and
which really want a reboot after upgrade, such as kernel, perhaps libc,
and any library or package fixing security problems. These simply need
to run /usr/share/update-notifier/notify-reboot-required (which will
touch /var/run/reboot-required) on postinst, and a notification will
appear to the user at his desktop telling them that a reboot is
required, and allowing them after the package manager is done "applying
changes".

This is done in Ubuntu by communicating with GDM through a nice program
called gdm-signal, which was built using code from gnome-panel and some
more written by Rob Taylor, and which is distributed in Ubuntu's
powermanagement-interface package; I included this work in
update-notifier as a private program, for now, but maybe we should add
it to our gdm package? Ubuntu does not seem to have provisions for KDE;
if our KDE guys know how we'd go about doing the same for KDM, let me
know; same goes for XFCE and other desktops which support the
notification area protocol, and would, thus, be able to run
update-notifier.

The second feature is quite cool; update-notifier uses hal to detect
that a new CD/DVD was inserted and tries to figure out whether that is
a Ubuntu CD; I patched the program to also look for Debian CDs, and to
avoid messing with translations, the messages have Ubuntu replaced by
Debian in runtime, after the translation is got from gettext if the CD
that was inserted is a Debian CD.

I'm writing to all of you so that you are aware that these nice desktop
features are now included in Debian, and so we can discuss whether and
how we'll make use of them to accomplish a nicer Debian Desktop. Please
follow up issues related to a specific "subteam" in the approppriate
mailing list, but please keep me CC'ed.

For coolness effect, here's the first time I saw a Debian CD being
detected in my desktop:

http://kov.eti.br/~kov/update-notifier-debian-cd.png

See you,

[0]: http://people.debian.org/~kov/stuff/

-- 
Gustavo Noronha Silva <[EMAIL PROTECTED]>
http://people.debian.org/~kov/


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

Re: cdrtools

[Michael Banck]

On Sat, Aug 12, 2006 at 09:48:55PM +0200, Goswin von Brederlow wrote:
> Joerg Schilling <[EMAIL PROTECTED]> writes:
> Please try to read, understand and answere the question asked in a
> mail. Hint: The question wasn't about cdrtools patches.

Please try to take off-topic threads to appropriate mailing lists or to
private mail exchange.  Consider it part of P&P.


Michael


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

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Sat, 2006-08-12 at 15:59 +1000, Brian May wrote:
> > "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
> 
> Robert> On Sun, 2006-08-06 at 12:01 +1000, Brian May wrote:
> >>  Curiously though, the problems continue even after the archive
> >> appears to be converted successfully - if I do a diff
> >> operation, it reports all files as deleted, but if I try to
> >> revert it, it slows to a grinding halt.
> 
> Robert> Could you please run 'bzr upgrade' while using bzr
> Robert> 0.9rc1. If my guess at your situation is right this will
> Robert> take a while to run, but correct your performance issues.
> 
> Are there any Debian packages of 0.9rc1 available?

0.9 has been released, I believe 'dato is working on an upload now.

Cheers,
Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

VMware packaging

[Peter Collingbourne]

Dear all,

I found there were no VMware-related packages in the official
repository, nor any way of creating them.  Thus I propose to create
a tool that will build (for example for VMware Server) vmware-server
and vmware-modules-source packages based on an installation tarball
(a la java-package).

Thanks,
-- 
Peter


pgpsXMcZQ1IO6.pgp
Description: PGP signature

Re: VMware packaging

[Pierre Habouzit]

Le dim 13 août 2006 02:06, Peter Collingbourne a écrit :
> Dear all,
>
> I found there were no VMware-related packages in the official
> repository, nor any way of creating them.  Thus I propose to create
> a tool that will build (for example for VMware Server) vmware-server
> and vmware-modules-source packages based on an installation tarball
> (a la java-package).

why would we need it when there is already quite plenty of good free 
alternatives (qemu, bochs e.g.) ?
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpg60wOF3UkG.pgp
Description: PGP signature

Re: New desktop features provided by new version of update-notifier

[John Goerzen]

On Sat, Aug 12, 2006 at 08:29:13PM -0300, Gustavo Noronha Silva wrote:
> 
> The first feature is useful for those packages which are critical, and
> which really want a reboot after upgrade, such as kernel, perhaps libc,
> and any library or package fixing security problems. These simply need
> to run /usr/share/update-notifier/notify-reboot-required (which will
> touch /var/run/reboot-required) on postinst, and a notification will
> appear to the user at his desktop telling them that a reboot is
> required, and allowing them after the package manager is done "applying
> changes".

I think this is, at best, misleading.  The kernel is really the only
thing that absolutely requires a reboot.  Users can deal with the rest
themselves, mostly.

I understand that this tool may be aimed at those that don't have a
great deal of experience, but I think that you are presenting misleading
information to everyone.

To say that any library fixing security problems will require a reboot
is outrageous.  It is quite possible to restart any impacted services
instead.  You're second-guessing the administrator's judgment.

If you were to call this a *suggested reboot*, with text that states
that a person could also achieve the desired effect by simply restarting
certain processes, I'd have no problem with it.

I like the idea of this program, but this particular thing gives me the
impression that Debian is regressing to something that's no better than
Windows Update under Windows 98.

-- John


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

Re: New desktop features provided by new version of update-notifier

[Gustavo Noronha Silva]

Em Sat, 12 Aug 2006 19:26:51 -0500
John Goerzen <[EMAIL PROTECTED]> escreveu:

> I understand that this tool may be aimed at those that don't have a
> great deal of experience, but I think that you are presenting
> misleading information to everyone.

Exactly.

> To say that any library fixing security problems will require a reboot
> is outrageous.  It is quite possible to restart any impacted services
> instead.  You're second-guessing the administrator's judgment.

Not really; if the machine does have an 'administrator':

 1) they would probably be using their own methods of keeping software
up-to-date
 2) they'd know when to reboot, and would ignore the message (that's
what I'd do)
 
> If you were to call this a *suggested reboot*, with text that states
> that a person could also achieve the desired effect by simply
> restarting certain processes, I'd have no problem with it.

Even with those arguments in mind, do you have a suggested text that
would still be good for beginners?

> I like the idea of this program, but this particular thing gives me
> the impression that Debian is regressing to something that's no
> better than Windows Update under Windows 98.

It will not be disturbing you every once in a while, like windows
update, heh.

So, again, notice that if a machine is on a network administered
centrally or has an 'administrator' for some other reason, there would
be no real need for update-notifier to be even installed, so I'd like to
focus here on end-user desktops, only.

See you,

-- 
Gustavo Noronha Silva <[EMAIL PROTECTED]>
http://people.debian.org/~kov/


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

Re: VMware packaging

[Peter Collingbourne]

On Sun, Aug 13, 2006 at 02:25:59AM +0200, Pierre Habouzit wrote:
> Le dim 13 août 2006 02:06, Peter Collingbourne a écrit :
> > Dear all,
> >
> > I found there were no VMware-related packages in the official
> > repository, nor any way of creating them.  Thus I propose to create
> > a tool that will build (for example for VMware Server) vmware-server
> > and vmware-modules-source packages based on an installation tarball
> > (a la java-package).
> 
> why would we need it when there is already quite plenty of good free 
> alternatives (qemu, bochs e.g.) ?

To provide choice to the user perhaps?  I myself use qemu but some may
need features such as suspend/resume.  Also, qemu is a bit slow without
the non-free accelerator module.

Thanks,
-- 
Peter


pgphQkAhtkacm.pgp
Description: PGP signature

Re: VMware packaging

[Francesco Pedrini]

Alle Sunday 13 August 2006 02:25, Pierre Habouzit ha scritto:
> Le dim 13 août 2006 02:06, Peter Collingbourne a écrit :
> > Dear all,
> >
> > I found there were no VMware-related packages in the official
> > repository, nor any way of creating them.  Thus I propose to create
> > a tool that will build (for example for VMware Server)
> > vmware-server and vmware-modules-source packages based on an
> > installation tarball (a la java-package).
>
> why would we need it when there is already quite plenty of good free
> alternatives (qemu, bochs e.g.) ?

For example because qemu isn't ready for large production environment 
like the ones that are the target of VmWare Enterprise or similar...

-- 
:wq

Re: VMware packaging

[Roberto C. Sanchez]

On Sun, Aug 13, 2006 at 02:25:59AM +0200, Pierre Habouzit wrote:
> Le dim 13 août 2006 02:06, Peter Collingbourne a écrit :
> > Dear all,
> >
> > I found there were no VMware-related packages in the official
> > repository, nor any way of creating them.  Thus I propose to create
> > a tool that will build (for example for VMware Server) vmware-server
> > and vmware-modules-source packages based on an installation tarball
> > (a la java-package).
> 
> why would we need it when there is already quite plenty of good free 
> alternatives (qemu, bochs e.g.) ?

Because the performance of qemu is quite bad without the non-free
accelerator module and bochs is generally very slow and targeted at
hobbyists.  I'm not trying to say anything bad about them, just that
their target markets are generally different than the target market of
VMWare.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


signature.asc
Description: Digital signature

Re: VMware packaging

[Goswin von Brederlow]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

> Le dim 13 août 2006 02:06, Peter Collingbourne a écrit :
>> Dear all,
>>
>> I found there were no VMware-related packages in the official
>> repository, nor any way of creating them.  Thus I propose to create
>> a tool that will build (for example for VMware Server) vmware-server
>> and vmware-modules-source packages based on an installation tarball
>> (a la java-package).
>
> why would we need it when there is already quite plenty of good free 
> alternatives (qemu, bochs e.g.) ?

Qemu and especialy bochs are not alternatives for vmware. They are
more emulators than VMs.

What you mean is vserver and even more so xen. I hear with the latest
versions you can even run windows in xen.

MfG
Goswin


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

Re: dh_python and python policy analysis

[Pierre Habouzit]

Le sam 12 août 2006 17:34, Matthias Klose a écrit :
> dh_pysupport doesn't
> use this information, but requires the developer to explicitely pass
> the directory containing the extension module.

that's not completely true, it only searches in /usr/lib/$pkg, 
/usr/share/$pkg, /usr/lib/games/$pkg and /usr/share/games/$pkg. If he 
finds a .so in there, he uses objdump to find out if the .so is python 
related or not, and acts accordingly.

It just dont need current/current_ext at all, and uses different 
implementations choices. that's all.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpfoLiO7xepj.pgp
Description: PGP signature

Re: dh_python and python policy analysis

[Matthias Klose]

Manoj Srivastava writes:
>  policy document. The current version, and future updates, are to be
>  found at http://www.golden-gryphon.com/software/manoj-policy/

unreachable, comments for the posted text follow

>   1.1. Categorization of Python software
> 
>Program/script
> 
>  This consists of software directly called by an end user of
>external program, and is independently interpreted by the Python
>interpreter. Usually starts with the magic bytes #!, with the
>interpreter being /usr/bin/python* or /usr/bin/env python*.
> 
>Modules
> 
>  This is code included in python "programs/scripts", and not
>invoked directly (serving as library modules in compiled
>languages).
> 
>  Modules can be categorized under two orthogonal criteria: firstly, based
>on the whether or not they are implemented purely in python, like so:
> 
>Pure Python Module
> 
>  These are python source code, to be interpreted by the Python
>interpreter just like program/script code is, and may work across
>many versions of Python.
> 
>Extension Module
> 
>  Extensions are C code compiled and linked against a specific
>version of the libpython library, and so can only be used by one
>version of Python.

There should be no reason to link the extension against the python
library.  Usually many extensions which are developed upstream on
Windows do link by default to libpython.  Other extensions linking
against libpython are those with build infrastructure maybe predating
distutils.  python-semanage is an example (and should not link using
-z defs).

Another thing to mention here is a "Python package", a directory
containing an __init__.py file plus modules and extensions.

>  Another way of categorizing modules is based on whether or not they are
>available for use by third party scripts/modules.
> 
>Public
> 
>  Public modules are available for use in other Python scripts or
>modules using the import directive. They are installed in one of
>the directories:
> 
> /usr/lib/pythonX.Y
> 
>   This directory is reserved for official python
> modules. No other package apart from upstream
> official Python modules should install modules in
> this directory.
> 
> /usr/lib/pythonX.Y/site-packages
> 
>   This is where most add-on modules live. Often,
> packages do not directly install modules here, but
> instead use utility packages like python-central and
> python-support to byte compile and install modules as
> needed.
> 
> /var/lib/python-support/pythonX.Y
> 
>   Packages using python-support actually have their
> packages linked in from this directory, but no
> package should directly install modules there
> directly. See the documentation for python-support
> for details.

maybe shorten that to "all directories in sys.path"; not sure if an
explicit list of directories is needed.

>  Packages may install public Python modules in directories
>specific to Python packaging utilities -- which specify the
>directories under which such modules should be droppped, and the
>the structure of these directories is defined by the utilities
>themselves. Please note that these directories are not in the path
>for Python, and are not available for modules to be imported from.
>At the time of writing, such uility specific directories include:
   ^^
> 
>/usr/share/pycentral
>/usr/share/python-support

These location are tool specific and should not be referenced
explicitely in the packaging scripts (debian/rules)

> 2. Goals of the new Python policy
> 
>  The new policy is designed to reduce the load on people packaging python
>modules when one of the following events occur, and, by the dint of doing
>so, ease the transition that occur as new Python versions are introduced,
>old ones removed, and as the default version of Python changes, with
>minimal impact on the target system. In case of the following events:

No, not the whole design goal.  Although the document is titled
"developer's view", the other goals should be mentioned as well.
These are meant to work around processes in debian which are currently
suboptimal, but unlikely to change.

 - The need to support more than one version of a python runtime or
   to support different implementations was seen.  It takes a while
   until applications 

Re: dh_python and python policy analysis

[Pierre Habouzit]

Le sam 12 août 2006 17:34, Matthias Klose a écrit :
> Manoj Srivastava writes:
> >  policy document. The current version, and future updates, are to
> > be found at http://www.golden-gryphon.com/software/manoj-policy/
>
> unreachable, comments for the posted text follow

doh, that works for me ?!



> >Extension Module
> >
> >  Extensions are C code compiled and linked against a
> > specific version of the libpython library, and so can only be used
> > by one version of Python.
>
> There should be no reason to link the extension against the python
> library.  Usually many extensions which are developed upstream on
> Windows do link by default to libpython.  Other extensions linking
> against libpython are those with build infrastructure maybe predating
> distutils.  python-semanage is an example (and should not link using
> -z defs).

> Another thing to mention here is a "Python package", a directory
> containing an __init__.py file plus modules and extensions.

yes, that's indeed a thing to add.

> >Public
> > […]
>
> maybe shorten that to "all directories in sys.path"; not sure if an
> explicit list of directories is needed.

I've no real opinion on that.

> >  Packages may install public Python modules in
> > directories specific to Python packaging utilities -- which specify
> > the directories under which such modules should be droppped, and
> > the the structure of these directories is defined by the utilities
> > themselves. Please note that these directories are not in the path
> > for Python, and are not available for modules to be imported from.
> > At the time of writing, such uility specific directories include:
>
>^^
>
> >/usr/share/pycentral
> >/usr/share/python-support
>
> These location are tool specific and should not be referenced
> explicitely in the packaging scripts (debian/rules)

agreed


> No, not the whole design goal.  Although the document is titled
> "developer's view", the other goals should be mentioned as well.
> These are meant to work around processes in debian which are
> currently suboptimal, but unlikely to change.
>
> […]
>
>The alternative of dropping the python-foo package and just
> keeping the pythonX.Y-foo packages was not followed anymore (ftp
> master intervention and rewriting of control files).
>
> These are design decisions made for the distribution.  There are
> concerns about some upstream developers that the design of dropping
> the pythonX.Y namespace for packages may not be rebust enough.
>
> Another consequence of the current design: the default python version
> *has* to be installed, other supported versions can be installed
> additionally, not as a replacement.

agreed, this also has to be mentionned.


> >  This can be a single version, or one or more of a list of
> >non-overlapping ranges. The lowest range may optionally omit a
> > low end, and the highest range may optionally omit an upper end. In
> > other words, the overall range may be open ended. The ranges are
> > often matched to the set of all known Python version that have
> > existed, and the supported set is the intersection of the known
> > versions of python and the range specification.
>
> XS-Python-Version can have the values "current" and "current_ext" as
> well (plus the list of ranges), which will expand to "current", if
> the package does not have any extensions and can be used with another
> python default version without a new upload. It's replaced by the
> version number of the current default version in the Python:Versions
> substitution variable. "current_ext" normally only needs to be used
> for packages having a private extension module. dh_pysupport doesn't
> use this information, but requires the developer to explicitely pass
> the directory containing the extension module.

IMHO current and current_ext are choices of implementations of 
pycentral, which your following explanations truly underline.

[snip]

> > 3.1.2. Depends:
> >
> >  The rules for calculating the dependencies a package has are
> > simple.
> >
> > 1.   If a script invokes /usr/bin/pythonX.Y, than the package
> > must depend on pythonX.Y. This is because no amount of automatic
> > byte compiling would ever get rid of the requirement that
> > /usr/bin/pythonX.Y has to be present for the script to function.
>
> I think, that is too strict.  The current behaviour is depending on
> the dh_python implementation scanning all files for that interpreter
> line.  Consider a package with scripts in /usr/bin: foo, foo2.3,
> foo2.4, calling python, python2.3 and python2.4, which would lead to
> a dependency on all supported python versions.  The scripts work for
> the default python version, for the non-default python versions only
> if the corresponding pythonX.Y package is installed.

then the packager can choose to make those script use /usr/bin/python. 
I've seen very few of those packages, a

Re: dh_python and python policy analysis

[Manoj Srivastava]

On Sat, 12 Aug 2006 17:34:06 +0200, Matthias Klose <[EMAIL PROTECTED]> said: 

> Manoj Srivastava writes:
>> policy document. The current version, and future updates, are to be
>> found at http://www.golden-gryphon.com/software/manoj-policy/

Unfortunately, you are commenting on an old version of the
 document, so some comments refer to issue that have already been
 addressed.

>> Extension Module
>> 
>> Extensions are C code compiled and linked against a specific
>> version of the libpython library, and so can only be used by one
>> version of Python.

> There should be no reason to link the extension against the python
> library.  Usually many extensions which are developed upstream on
> Windows do link by default to libpython.  Other extensions linking
> against libpython are those with build infrastructure maybe
> predating distutils.  python-semanage is an example (and should not
> link using -z defs).

I'll add these in general notes, or perhaps in the extension
 specific sections (since compilation rules do not belong in
 the classification section).

> Another thing to mention here is a "Python package", a directory
> containing an __init__.py file plus modules and extensions.

This is mentioned in general notes; I did not think it was a
 useful fifth classification, since  we do not actually treat it very
 differently.

>> Public
>> 
>> Public modules are available for use in other Python scripts or
>> modules using the import directive. They are installed in one of
>> the directories:
>> 
> maybe shorten that to "all directories in sys.path"; not sure if an
> explicit list of directories is needed.

Not all paths in sys.path are oermitted in packages (like the
 path ending in .zip).

>> Packages may install public Python modules in directories specific
>> to Python packaging utilities -- which specify the directories
>> under which such modules should be droppped, and the the structure
>> of these directories is defined by the utilities themselves. Please
>> note that these directories are not in the path for Python, and are
>> not available for modules to be imported from.  At the time of
>> writing, such uility specific directories include:
>^^
>> 
>> /usr/share/pycentral /usr/share/python-support

> These location are tool specific and should not be referenced
> explicitely in the packaging scripts (debian/rules)

You have just made all my selinux python packages violate this
 line :). I use update-python-modules in postinst and prerm, but I do
 not use any debhelper modules, and I should not be required to do
 so.

I don't think that implicitly mandating the use of the helper
 scripts dh_(pysupport|pycentral|python)  should belong in policy.

>> 2. Goals of the new Python policy
>> 
> No, not the whole design goal.  Although the document is titled
> "developer's view", the other goals should be mentioned as well.
> These are meant to work around processes in debian which are
> currently suboptimal, but unlikely to change.

[SNIP lots of good stuff]

I'll add these to the document.

>> New python version introduced
>> 
>> * Most pure Python modules with no restrictions on the
>> version of Python supported, and those pure Python modules that
>> only have a lower bound on the versions of python supported (for
>> example, "2.3-", or "all"), would require no

> "2.3-" -> ">= 2.3", not "all".  the range notation cannot express
> things like "2.2, >= 2.4". The use case for the latter is the jython
> package (now removed from testing) still at an implementation level
> of the corresponding cpython version, with i.e. 2.3 not a supported
> python version anymore.  So in the following text "set of versions",
> instead of "range of versions" should be used.


OK, done.

>> The new policy also reduces the numbers of packages in the archive,
>> by supporting multiple versions of Python in the same binary
>> package (at the cost of increased size of that one package, but it
>> should still result in space saving.)

> Maybe mention the two cases, where the package size increases:

>  - extension modules
>  - pure modules where different versions of the upstream package are
>shipped and are directly installed into /usr/lib/pythonX.Y/


OK.

>> 3. Recipe for developers

>> 3.1.1. Python versions supported by the source
>> 
>> The XS-Python-Version field in debian/control specifies the
>> versions of Python supported by the package [30][1]. While this is
>> a requirement only if using the utility package python-central
>> (python-support, for example, prefers debian/pyversions), setting
>> this is "appreciated" in any case, according to the [31]new policy
>> wiki[32][2]. This is used to track packages during Python
>> transitions.
>... and test rebuilds.

OK.

>> This can be a single version, or one or more of a list of
>> non-overlappin