Re: patch for versioned symbols in Heimdal shared library

[Russ Allbery]

Brian May <[EMAIL PROTECTED]> writes:
>> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:

> Russ> Out of curiosity, have you talked to Love about this issue
> Russ> already?  Given that MIT Kerberos supports symbol versions
> Russ> upstream, I'm a little surprised that Heimdal doesn't as
> Russ> well, and I'd think that Love would at least be happy to
> Russ> take a patch even if he doesn't have time to write it
> Russ> himself.

> Anyone here willing to write such a patch if upstream would accept it?

> The current patch may not be acceptable, it modifies libtool.

I have some code that I use for other projects that supports doing symbol
versioning on Linux without modifying libtool (it just passes the
appropriate flags through libtool with -Wl).  I don't have a lot of time
to work on this, but I'm happy to provide those details to start people
off.

I do this in configure.ac:

dnl If and only if we're on Linux, use a mapfile to do symbol versioning.
dnl We'd like to do this on all platforms, but the syntax is different
dnl everywhere and I don't feel like dealing with the differences.
case "$host" in
*-linux*)
VERSION_LDFLAGS="-Wl,--version-script=mapfile"
;;
*)
VERSION_LDFLAGS=""
;;
esac
AC_SUBST([VERSION_LDFLAGS])

and then put a mapfile that contains the symbol versioning information in
each directory with a shared library.  Then, in the Makefile, just include
$(VERSION_LDFLAGS) in the arguments passed to libtool for the link.
(Heimdal uses Automake, so this means adding them to the appropriate
_LDFLAGS variable for each library.

If I remember the Heimdal build system properly, it builds only one shared
library in each directory, so this should work.  If multiple shared
libraries are built in a particular directory, you have to do something
more complicated.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#432587: ITP: camlp4s -- Pre Processor Pretty Printer for OCaml - classical version

[Lionel Elie Mamane]

On Tue, Jul 10, 2007 at 08:56:02PM +0200, Stefano Zacchiroli wrote:

> * Package name: camlp4s
> * URL : http://cristal.inria.fr/~ddr/camlp4s/
> * License : BSD

> Question time: the license is BSD, but is not identical to the text
> I find in /usr/share/common-licenses/BSD as the Copyright is
> different (INRIA vs Universify of California). Can I point to our
> license file in debian/copyright nonetheless,

I wouldn't do that.

-- 
Lionel


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

Bug#432795: ITP: haskell-generic-xml -- Haskell library for marshalling values to/from XML

[Kari Pahula]

Package: wnpp
Severity: wishlist
Owner: Kari Pahula <[EMAIL PROTECTED]>


* Package name: haskell-generic-xml
  Version : 0.1
  Upstream Author : HAppS LLC
* URL : 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/generic-xml-0.1
* License : BSD
  Programming Lang: Haskell
  Description : Haskell library for marshalling values to/from XML

 Library for marshalling Haskell values to/from XML.

The upcoming HAppS version depends on this.


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

Re: Considerations for 'xmms' removal from Debian

[Lionel Elie Mamane]

On Wed, Jul 11, 2007 at 02:23:35PM +, William Pitcock wrote:
> José Miguel Parrella Romero  gmail.com> writes:

>> The maintainers of the xmms package in Debian are proposing the
>> removal of the aforementioned package. Please read on.

>> * Other distributions have already discussed XMMS removal. Gentoo
>> hardmasked the package based on the same rationale [1]

> Yes, and Gentoo's user committee fucked over the entire image and
> public view of Audacious' direction.

>> Other packages just depend on xmms as a mere multimedia player, and
>> therefore we recommend the maintainers to adjust their dependencies
>> to bmpx, xmms2 or audacious.

> That's fine as long as you respect our requests with regards to
> handling the PR of this.

Would a mention of the "different direction of audacious" in the
release notes of lenny, the next Debian release, fulfil your "PR
handling" request? Something like

 4.5 XMMS removal

 Due to concerns over its high number of bugs, unmaintained status
 (and hence bugs will not get fixed), usage of old, unmaintained
 libraries (gtk+ 1.2) and no UTF-8 support, xmms has been removed from
 Debian. We suggest users of xmms try 'bmpx' and/or 'audacious' for
 media players that may feel familiar to them. You may also want to
 give xmms2 a shot: it is by the same upstream than xmms, albeit feels
 very different.

 The developers of audacious would like you to know that the direction
 of audacious is very different than the direction xmms had when
 actively developed. See http://audacious-media-player.org/MANIFESTO
 for details.

This supposes you would create a manifesto on your website, I haven't
found any. (Or a an explanation to how you differ from xmms's
goals. All I found is a news item along the lines of "people who say
that audacious is just like xmms annoy us a lot, please don't do
that", but no articulation of your "absolutely different goals".)

I say that, because while I really don't intend to make you angry, as
a casual user of xmms, I don't see the difference. As far as I'm
concerned, xmms's goal was to be a sound player. And your goal, in
your FAQ is to develop a "media player". But from a cursory glance I
don't see audacious playing any other media than audio (no text, no
hypertext, no video, no images, ...), so I see it as an audio player,
not as a all-purpose all-around "media" player. (You handle only one
medium, sound.)

You know why I was using xmms as opposed to any other audio player?

 - it takes less screen estate
 - it plays any sound format I have thrown at it
 - doesn't crash / lockup / ...
 - no annoying bugs *I* run in

And, lo and behold, I launch audacious, it takes the same screen
estate. I'd be very surprised you wanted to voluntarily restrict sound
formats it supports, nor make it crash or buggy, so as far as my
criteria are concerned they are equivalent in their goals. I'm sorry
if this annoys you. Would you like me not to use audacious because of
that? I'm just a guy that wants sound-play to just work. I'm not
passionate about it, I never spent a lot of thought on how an audio
player should be designed to rock; for me the ideal sound player is
the one I don't need to think about. It is "infrastructure" to
me. But I'm very happy that other people are passionate about it, so
that they take the effort to develop one and I can use it. Thanks for
that.

All this respectfully of your efforts and "platform". I'm just saying
that if you want people to "have a new understanding of this project",
you need to explain them the project. People are not all psychic or
intimately familiar with the "audio player developers community" to
just know out of the blue what your goals are. Or interested enough to
analyse all features and design choices and reverse-engineer your
goals from that.


Best Regards,

-- 
Lionel


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

Bug#432794: ITP: haskell-syb-with-class -- Haskell library for generic programming

[Kari Pahula]

Package: wnpp
Severity: wishlist
Owner: Kari Pahula <[EMAIL PROTECTED]>


* Package name: haskell-syb-with-class
  Version : 0.1
  Upstream Author : Simon Peyton Jones, Ralf Laemmel
* URL : 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/syb-with-class-0.3
* License : BSD
  Programming Lang: Haskell
  Description : Haskell library for generic programming

 Classes, and Template Haskell code to generate instances, for the
 Scrap Your Boilerplate With Class system.

This is a dependency for generic-xml, which in turn is a dependency
for the upcoming HAppS version.


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

Re: patch for versioned symbols in Heimdal shared library

[Brian May]

> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:

Russ> Out of curiosity, have you talked to Love about this issue
Russ> already?  Given that MIT Kerberos supports symbol versions
Russ> upstream, I'm a little surprised that Heimdal doesn't as
Russ> well, and I'd think that Love would at least be happy to
Russ> take a patch even if he doesn't have time to write it
Russ> himself.

Anyone here willing to write such a patch if upstream would accept it?

The current patch may not be acceptable, it modifies libtool.
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: Re: Release team structure (was Release Team Meeting results (the Juelich Edition))

[Philippe Cloutier]

* Filipus Klutiero ([EMAIL PROTECTED]) [070616 20:46]:
> Le vendredi 15 juin 2007 19:19, Andreas Barth a écrit?:
> > Release team structure
> > ~~
> > Steve Langasek, who served as Release Manager for the past two cycles,
> > doesn't want to be on the hot seat anymore. As he is still an active member
> > of the release team, we decided to have him titled with "Release Wizard"
> > now. Luk will become a Release Manager, so that we have again two
> > Release Managers.
> Actually, it seems that Luk is already a Release Manager since a few days 
> according to intro/organization in CVS. I would appreciate if the release 
> team would start to announce changes in its membership.


What do you think this mail is?
If the mail was an announcement of Luk becoming RM, that was not 
clear...but in this case, best wishes to Luk with his new title 
(whatever it means, I guess).

And thanks to Steve for his great service as RM.


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

apt-transport-https: transfer closed with outstanding read data remaining during update

[Alan Ezust]

Hi, I have a strange problem with apt-get over https:// protocol

I built apt-0.7.2 from source, for debian etch, because
apt-transport-https was not included in the repository.

Most of the time, apt-get update and apt-get upgrade work fine over
HTTP://, but what I've noticed is that after I change the .debs on the
repository, rescan the Packages, etc, then my next apt-get updates
fail.

Sometimes it looks like this:


Get:1 https://update.presinet.com testing/ Release.gpg [189B]
Get:2 https://update.presinet.com testing/ Translation-en_US [189B]
Ign https://update.presinet.com testing/ Translation-en_US
Hit https://update.presinet.com testing/ Release [869B]
Err https://update.presinet.com testing/ Release
Get:3 https://update.presinet.com testing/ Release [869B]
Ign https://update.presinet.com testing/ Release
Ign https://update.presinet.com testing/ Packages/DiffIndex
Ign https://update.presinet.com testing/ Packages
Hit https://update.presinet.com testing/ Packages [17.4kB]
Fetched 18.5kB in 1s (10.6kB/s)
Reading package lists... Done

As you can see, it hits the source, tries to get, and shows Err,
and then Ign. If I run it a few more times, eventually it will show me
at the end:

transfer closed with outstanding read data remaining

It never gets the package list.

I do not have a workaround for this yet, because I don't understand
how apt-get update works well enough yet. The error message above is
from libcurl, I know that.

If I edit  my sources.list to get from another https:// source,
apt-get update, and switch back, update again, it works!

Which makes me think that apt keeps some sort of state information
that needs to be cleared for update to work again. Am I correct? Is
there a file or directory I can wipe out between updates to prevent
this from happening in the future?


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

Re: Improving the visibility of LowThresholdNMU

[Steve Langasek]

On Wed, Jul 11, 2007 at 11:23:07PM +0200, Pierre Habouzit wrote:
> On Wed, Jul 11, 2007 at 07:24:21AM +, Lucas Nussbaum wrote:

> > The LowThresholdNMU wiki page[0] lists maintainers (and packages) for
> > which NMUs are welcomed.

>   IMHO this should be the default for everyone without exception, and I
> feel sorry we need such a page.

The LowThresholdNMU procedure documented in the wiki is not something I
would be happy to see implemented "without exception" on my packages.

It says that maintainers don't need to be contacted beforehand.  I can
understand not wanting to require NMUers to wait for a reply, but why is
shooting an email to the maintainer a burden?

It does not say that NMU permissions are limited to RC bugfixes, or even
RC+important bugfixes.  Why should I be happy to have NMUers uploading fixes
for minor bugs without talking to me first?

It wrongly claims that NMUs take "at least two weeks".  There are many
exceptions to this; aside from the obvious case that it doesn't take two
weeks when 0-day NMUs are in effect, individual maintainers can and do
authorize NMUs of their packages in specific circumstances.  (As an RM/bug
submitter, I have had several maintainers give me permission to directly NMU
their packages for RC bugfixes; and as a maintainer I have authorized NMUs,
including for non-RC bugs, on packages that I knew I wouldn't have time to
work on very soon.)

>   I mean, there is two cases:
>   1- there is a co-maintenance team, known to be reactive, then contact
>  them on their list before, because the coordination of a team is
>  likely to be more complicated, hence a "rogue" NMU isn't a
>  brilliant idea.

If you're contacting the comaintenance team, you're not following the
procedure described on http://wiki.debian.org/LowThresholdNmu anyway, so why
do we need that procedure?

>   2- there is a bug open for 7+ days (if RC), or an important one that
>  counts for this or that migration/update/whatever for say 10+ days
>  without any answer from the Maintainer. Then just NMU.

Not every bug that is opened at RC severity is truly RC, and sometimes it's
not obvious why this is the case; nor is immediately uploading a fix for an
RC bug always the correct thing to do (consider large library transitions,
were the current version of the package needs to propagate to testing
together with 20 other RC bugfixes).  This, as much as wanting to reduce
unnecessary duplication of effort, is a reason why the release team has in
the past limited its 0-day NMU endorsement to RC bugs open 7 days or more,
and why I think the release team should continue to have such limits.

BTW, in the extreme case I have seen developers submit incorrect RC bugs,
file broken patches for them, and proceed straight to NMUing, all without
ever giving the maintainer an opportunity to comment.  I don't think we
should encourage NMUers to take it upon themselves to NMU for their own pet
bugs without review, and I think any changes to the default NMU policy
should take this possibility into account.

>   OTOH my experience with NMUs is that people that complain because of a
> NMU are in 95% of the cases (if not more) the people that have been the
> more warned that a NMU could happen, and people that are the more likely
> to "deserve" one, and those will never subscribe to a page like
> LowThresholdNMU anyway.

I'm actually hard pressed to recall enough examples of people complaining
about NMUs such that a single complaint constitutes a mere 5%.  And I think
complaining about an NMU done for a non-bug is always justified. :)

-- 
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]

Bug#432773: ITP: javahelp2 -- Java based help system

[Michael Koch]

Package: wnpp
Severity: wishlist
Owner: Michael Koch <[EMAIL PROTECTED]>

* Package name: javahelp2
  Version : 2.0.05
  Upstream Author : Sun Microsystems, Inc.
* URL : http://javahelp.dev.java.net
* License : GPL
  Programming Lang: Java
  Description : Java based help system

The JavaHelp system is an online help system that developers can use to add 
online help to their
Java platform applications. The JavaHelp system provides developers and authors 
with a standard,
fully featured, easy to use system for presenting online information to Java 
application users.
The JavaHelp system consists of a fully featured, extensible specification and 
API, and a reference
implementation of that specification and API that is written entirely in the 
Java programming language.
The JavaHelp system reference implementation, based on the Java Foundation 
Classes (JFC, also known
as Swing), provides a standard interface that enables both application 
developers and authors to add
online help to their applications.


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: Improving the visibility of LowThresholdNMU

[Pierre Habouzit]

On Wed, Jul 11, 2007 at 07:24:21AM +, Lucas Nussbaum wrote:
> Hi,
> 
> The LowThresholdNMU wiki page[0] lists maintainers (and packages) for
> which NMUs are welcomed.

  IMHO this should be the default for everyone without exception, and I
feel sorry we need such a page.

  I mean, there is two cases:
  1- there is a co-maintenance team, known to be reactive, then contact
 them on their list before, because the coordination of a team is
 likely to be more complicated, hence a "rogue" NMU isn't a
 brilliant idea.

  2- there is a bug open for 7+ days (if RC), or an important one that
 counts for this or that migration/update/whatever for say 10+ days
 without any answer from the Maintainer. Then just NMU.

  Migrations usually last way more than 10 days due to testing
transitions, so 7 to 10 days is not such a long time.


  OTOH my experience with NMUs is that people that complain because of a
NMU are in 95% of the cases (if not more) the people that have been the
more warned that a NMU could happen, and people that are the more likely
to "deserve" one, and those will never subscribe to a page like
LowThresholdNMU anyway.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpqUYMOOxJC9.pgp
Description: PGP signature

Re: Improving the visibility of LowThresholdNMU

[Lucas Nussbaum]

On 11/07/07 at 12:29 -0700, Don Armstrong wrote:
> On Wed, 11 Jul 2007, Lucas Nussbaum wrote:
> > I can't find how I can get the full history of LowThresholdNMU,
> > which could be a problem in case of abuse.
> 
> http://wiki.debian.org/LowThresholdNmu?action=info shows most of the
> history, and all of it is present and diffable.

Ah, I missed that.

> > Another problem is that having a complex format will make syntax
> > errors easy, and it would be better to be able to validate the
> > changes immediately. So I thought of a VCS with the list, and a
> > parser script.
> 
> You can easily hook up a validator to the e-mail notification from the
> wiki or similar, or just periodically check and validate the page.

Yeah, OK, I agree that the wiki solution is probably enough for now.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: Improving the visibility of LowThresholdNMU

[Don Armstrong]

On Wed, 11 Jul 2007, Lucas Nussbaum wrote:
> I can't find how I can get the full history of LowThresholdNMU,
> which could be a problem in case of abuse.

http://wiki.debian.org/LowThresholdNmu?action=info shows most of the
history, and all of it is present and diffable.

> Another problem is that having a complex format will make syntax
> errors easy, and it would be better to be able to validate the
> changes immediately. So I thought of a VCS with the list, and a
> parser script.

You can easily hook up a validator to the e-mail notification from the
wiki or similar, or just periodically check and validate the page.


Don Armstrong

-- 
CNN/Reuters: News reports have filtered out early this morning that US
forces have swooped on an Iraqi Primary School and detained 6th Grade 
teacher Mohammed Al-Hazar. Sources indicate that, when arrested,
Al-Hazar was in possession of a ruler, a protractor, a set square and
a calculator. US President George W Bush argued that this was clear
and overwhelming evidence that Iraq indeed possessed weapons of maths 
instruction.

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Bug#432751: ITP: python-pyip -- Python modules for assembling/disassembling of raw ip packets

[Bernd Zeimetz]

Package: wnpp
Severity: wishlist
Owner: Bernd Zeimetz <[EMAIL PROTECTED]>

* Package name: python-pyip
  Version : 0.7
  Upstream Author : Kenneth Jiang <[EMAIL PROTECTED]>
* URL : https://sourceforge.net/projects/pyip
* License : Python License
  Programming Lang: Python
  Description : Python modules for assembling/disassembling of raw ip 
packets

 pyip is a Python package offering modules to assemble/disassemble raw ip
 packets, including ip, udp, and icmp. The package comes with an
 implementation of ping and traceroute, using the raw ip modules.


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

Bug#432747: ITP: python-rabbyt -- sprite library for Python with game development in mind

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz  <[EMAIL PROTECTED]>


* Package name: python-rabbyt
  Version : 0.0.2
  Upstream Author : Matthew Marshall <[EMAIL PROTECTED]>
* URL : http://cheeseshop.python.org/pypi/Rabbyt/0.0.2
* License : LGPL 2.1 or any later version
  Programming Lang: C, Python
  Description : sprite library for Python with game development in mind

 Rabbyt is a sprite library for Python. It has two goals:
  - To be fast, without sacrificing ease of use.
  - To be easy to use, without sacrificing speed.
  Rabbyt makes it very easy to create lots of sprites very fast that
  run very fast with little code.


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

Re: Considerations for 'xmms' removal from Debian

[Steve Greenland]

On 11-Jul-07, 09:40 (CDT), William Pitcock <[EMAIL PROTECTED]>
wrote:
> We are not an XMMS clone. Would you like us to remove the Winamp2 UI
> to drive this point further? If this nonsense keeps happening, it's
> exactly what we will be doing.

Like it or not, your software fits very much into the role played
by XMMS, such that someone who likes XMMS is more likely to choose
Audacious than, say, Rythymbox. That's why it's being discussed as a
"replacement". If we remove XMMS from the distribution, we have some
obligation to point users at similar tools. 

Since you obviously modeled Audacious on XMMS (via BMP), I'm not sure
why you find such comparisons offensive.

Steve
-- 
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: Considerations for 'xmms' removal from Debian

[Frank Lichtenheld]

On Wed, Jul 11, 2007 at 02:40:53PM +, William Pitcock wrote:
> Andreas Tille  rki.de> writes:
> > I think xmms is to wide spread as that we just could wild guess how
> > many users are affected and how they could cope with this.
> 
> Somebody will just maintain their own repo with gtk1.2 and xmms if it's
> required. This already happens in gentoo.

This is a valid solution for experienced xmms users that don't ever want
to switch. But this is not Debian's concern and I think the thread is about
solutions for people that primarily use Debian and just happen to have
chosen xmms as their music player of choice. If xmms gets removed before
lenny and they upgrade to it I guess they would welcome a hint which new
program to switch to.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Re: Considerations for 'xmms' removal from Debian

[William Pitcock]

Andreas Tille  rki.de> writes:

> 
> On Sun, 8 Jul 2007, Thomas Viehmann wrote:
> 
> > Removing the package from Debian will not affect current users that
> > much,
> 
> While I perfectly agree that there are replacements for xmms that at
> first view look like a new version  (for instnce audacious) many user
> might have links form their desktops or other hooks that just call
> /usr/bin/xmms.  So this might affect a lot of users and especially
> those users that have no idea how to cope with a missing xmms in their
> PATH.  IMHO the only way to fix this is to provide a transitional
> package that for instance depends from audacious (or other clones),
> provides xmms and conflict with older xmms versions and install a
> symlink to the replacement.
> 

We are not an XMMS clone. Would you like us to remove the Winamp2 UI to drive
this point further? If this nonsense keeps happening, it's exactly what we will
be doing.

Architecturally, Audacious is much different than XMMS, it just sorta looks like
XMMS, which I think sends the wrong message, but whatever. The fact is that we
do not consider ourselves to be an XMMS clone or an XMMS replacement, and you
should strongly consider that before removing XMMS and providing a transitive
upgrade path to audacious.

I'm not asking much, just some sort of notification telling users that the
"replacement" they are installing is not really a replacement to XMMS, and as
such some "features" are implemented in a drastically different way.

Thanks,
William

> I think xmms is to wide spread as that we just could wild guess how
> many users are affected and how they could cope with this.

Somebody will just maintain their own repo with gtk1.2 and xmms if it's
required. This already happens in gentoo.


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

Re: Considerations for 'xmms' removal from Debian

[William Pitcock]

José Miguel Parrella Romero  gmail.com> writes:

> 
> The maintainers of the xmms package in Debian are proposing the removal
> of the aforementioned package. Please read on.
> 
> 1. Rationale
> 
> * Upstream has deprecated development and support for the current
> version of XMMS.
> * Several parts of the application are broken and no longer of Debian
> quality.
> 
> 2. Current status
> 
> * The BTS reports 231 bugs, most tagged 'important' or 'normal', and a
> couple of debugging was attempted with little success.
> * XMMS is broken in several aspects, one of the most important being
> it's dependence on GTK+ 1.2 and no UTF-8 support, which is standard in
> Debian Etch.
> * Other distributions have already discussed XMMS removal. Gentoo
> hardmasked the package based on the same rationale [1]

Yes, and Gentoo's user committee fucked over the entire image and public view of
Audacious' direction. Gentoo's (mis)handling of PR during this transitional time
has resulted in a lot of negativity towards audacious and several lame attempts
to find security holes in Audacious with the explicit purpose of trying to get
XMMS back.

I strongly suggest this doesn't happen in Debian, as upstream may not like the
result otherwise. The general consensus of our team is that we're not going
through this nightmare again.

> * 'bmpx' and 'audacious' are in Debian, ranks 8048 and 3649 in popcon.
> Both are very good and development-active substitutes to xmms.

At present, the only completely successful mainstream xmms->audacious to date
has been in Slackware, but that's because Pat didn't lie to the users about our
goals and project direction. Please respect our project and make sure it happens
this way in Debian if you provide an xmms->audacious upgrade path.

> * There's also in Debian the upstream-supported xmms2 package, 2598 in
> popcon rank.
> 
> 2.1 Reverse depends
> 
> The following packages depend on XMMS:
 
> Most of this packages are xmms plugins. Maintainers will need to port
> them to xmms2 or bmpx, or they should be removed.
> 

A large majority of these plugins have been ported to Audacious already.

> Other packages just depend on xmms as a mere multimedia player, and
> therefore we recommend the maintainers to adjust their dependencies to
> bmpx, xmms2 or audacious.
> 

That's fine as long as you respect our requests with regards to handling the PR
of this.

> 2.2 Popcon
> 
> xmms is now 1069 in the overall popcon rank, with 11029 installations,
> not counting the plugin users.
>
> Yours,
> the XMMS maintainers
> 
> [1] http://www.gentoo.org/proj/en/desktop/sound/xmms.xml
> 
> 





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

Re: Considerations for 'xmms' removal from Debian

[Daniel Jacobowitz]

On Tue, Jul 10, 2007 at 07:13:03PM -0500, David Moreno Garza wrote:
> Daniel Jacobowitz wrote:
> > When last I looked (some time ago), none of the different XMMS
> > successors were ready for prime time.  Are bmpx, audacious, and xmms2
> > all usable now?
> 
> What's exactly a XMMS successor?

All three of the ones I listed are descended from the XMMS code base,
the XMMS developers, or both.  As far as I can tell, anyway.

-- 
Daniel Jacobowitz
CodeSourcery


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

Re: Improving the visibility of LowThresholdNMU

[Nico Golde]

Hi,
* Lucas Nussbaum <[EMAIL PROTECTED]> [2007-07-11 15:22]:
> On 11/07/07 at 10:08 +0200, Reinhard Tartler wrote:
> > > (1) the list should move to a text file in a VCS. For example, we could
> > > use a special directory in the collab-maint alioth project, or simply a
> > > repository writable by all DDs on svn.d.o. This would improve the way
> > > history is kept too.
> > 
> > I feat that having 'simply a repository writable by all DDs' is not
> > simple at all. What about non-DD maintainers?
> 
> they could be proxy-added by DDs. It already works like that for
> planet.d.o, for example.

collab-maint/ext-maint is available for non-DDs afaik.
[...] 
Cheers
Nico
-- 
Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgps3iGbugkHL.pgp
Description: PGP signature

Re: Improving the visibility of LowThresholdNMU

[Mario Iseli]

On Wed, Jul 11, 2007 at 10:08:01AM +0200, Reinhard Tartler wrote:
> That's a good idea, perhaps the PTS maintainers could comment what the
> best way of integrating the information there would be? Would inventing
> a header called 'XS-NMUs-Welcome: yes' in debian/control help here? Does
> it make sense otherwise to expose this information in Sources.gz?

Hmmm, I think NMUs are more a "social" point in Debian than a technical.
My opinion is that only technical stuff belongs to the debian/ directory
in a package and this must be "kiss" (keep it simply stupid). To many of
those extra fields will make it unreadable. So I support the idea about
the VCS with access for all DDs.

Regards,
Mario

-- 
  .''`. Mario Iseli <[EMAIL PROTECTED]>
 : :'  :proud user of Debian unstable
 `. `'`
   `-  Debian - when you have better things to do than fixing a system


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

Re: Improving the visibility of LowThresholdNMU

[paddy]

On Wed, Jul 11, 2007 at 01:16:58PM +0200, Lucas Nussbaum wrote:
> 
> Another problem is that having a complex format will make syntax errors
> easy, and it would be better to be able to validate the changes
> immediately. So I thought of a VCS with the list, and a parser script.

would it be practical to hook that kind of 'continuous integration'
into the wiki, so that changes that do not pass the test(s) cannot be 
committed, but instead return an error ?

Regards,
Paddy


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

Re: Please all dependency info into your init.d script

[Petter Reinholdtsen]

[Vincent Danjean]
> What about circular dependencies that must be broken differently
> depending on the admin configuration ?

[Henrique de Moraes Holschuh]
> You have your answer right there: let the admin fix it.

Exactly.  And the insserv system provides a system where overrides are
read from /etc/insserv/overrides for such use (or the admin can just
edit the scripts directly).  Of course, circular dependencies are a
nasty problem already with the current ordering mechanism, and a
source of several of the bugs in the current boot sequencing.

So please add dependency information into all init.d scripts missing
them today, to make it possible to detect the current circular
dependencies that need to be solved before Lenny.  Without dependency
information, it is a lot harder to detect these problems.

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: Improving the visibility of LowThresholdNMU

[Lucas Nussbaum]

On 11/07/07 at 10:20 +0200, Stefano Zacchiroli wrote:
> > (1) the list should move to a text file in a VCS. For example, we could
> > use a special directory in the collab-maint alioth project, or simply a
> > repository writable by all DDs on svn.d.o. This would improve the way
> > history is kept too.
> 
> I fail to see the advantage of this, especially wrt the two problems
> above. The wiki is easier to access than a VCS (you don't have to
> checkout) and it already handles history, I don't think full-fledged
> history management for the LowThresholdNMU page is something we actually
> need.

I can't find how I can get the full history of LowThresholdNMU, which
could be a problem in case of abuse.

Another problem is that having a complex format will make syntax errors
easy, and it would be better to be able to validate the changes
immediately. So I thought of a VCS with the list, and a parser script.

But I have nothing against staying with the wiki for now, and we could
always switch later if the wiki becomes a problem.

> > (2) the list should be machine-readable. We could use the following
> > format:
> 
> Agreed, and I like the format you propose.
> 
> Why can't we simply change the wiki page to match that format? The wiki
> page won't be more error prone than a VCS file using the same format.
> What we need to achieve this is just a volunteer which reviews the
> current page and converts the current human-readable sentences in
> machine-readable strings matching your format.

Mmmh, maybe we could just convert all the "easy" entries (those with
"all packages" with no restriction) and let the developers convert the
other ones.

But in all cases, it would be better to write a parser first, just to
make sure the format is easy to parse, and we aren't losing important
information or making it too hard to write entries with that format.

> The only issue I see with the wiki is security, as anyone can currently
> edit pages just after the registration, but for the page we are
> discussing it won't be worst than the present situation.
> 
> > (3) make the state visible on the PTS (see #429883). For each package,
> > we could have an icon indicating if the package is NMU-friendly or not.
> > All packages would have an icon, so having the "NMU-hostile" icon by
> > default could help maintainers remember to add themselves to the list.
> 
> Agreed, this can be done even in the current state. The PTS can download
> the raw version of the page, consider only the lines that match your
> format and ignore the remaining stuff.

Ack

> Besides, I think we can still do more to improve visibility, as neither
> the wiki solution, nor the VCS based one would increase it above the
> current status. I would like to see LowThresholdNMU mentioned in the
> developer's reference (a quick check I made today shown that it's not
> there, but I may be wrong), anyone up to writing a section and submit a
> patch?

We should probably defer that until the PTS icons are implemented, so we
can document the final state.

> > Is anyone interested in working on that? I will have problems finding
> > the time in the near future
> 
> I'm willing to patch the PTS for this, assuming there's an agreement on
> doing this "the wiki way" as I proposed above.

As I said above, we can start with the wiki, and if we realize that it's
a problem, move to something else.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: Improving the visibility of LowThresholdNMU

[Lucas Nussbaum]

On 11/07/07 at 10:08 +0200, Reinhard Tartler wrote:
> > (1) the list should move to a text file in a VCS. For example, we could
> > use a special directory in the collab-maint alioth project, or simply a
> > repository writable by all DDs on svn.d.o. This would improve the way
> > history is kept too.
> 
> I feat that having 'simply a repository writable by all DDs' is not
> simple at all. What about non-DD maintainers?

they could be proxy-added by DDs. It already works like that for
planet.d.o, for example.

> > (3) make the state visible on the PTS (see #429883). For each package,
> > we could have an icon indicating if the package is NMU-friendly or not.
> > All packages would have an icon, so having the "NMU-hostile" icon by
> > default could help maintainers remember to add themselves to the list.
> 
> That's a good idea, perhaps the PTS maintainers could comment what the
> best way of integrating the information there would be? Would inventing
> a header called 'XS-NMUs-Welcome: yes' in debian/control help here? Does
> it make sense otherwise to expose this information in Sources.gz?

Gustavo proposed to add a debian/nmupolicy file in his DPL platform. I'm
not really sure this is better than the current solution.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: Improving the visibility of LowThresholdNMU

[Stefano Zacchiroli]

On Wed, Jul 11, 2007 at 07:24:21AM +, Lucas Nussbaum wrote:
> which NMUs are welcomed. However, in it's current form, it's quite
> useless: it's very difficult to check if a given package is
> NMU-friendly, since the page is not machine-parseable. Also, since it's
> not very useful and visible, it doesn't provide an incentive for
> maintainers to add themselves to the list: there are probably some
> NMU-friendly maintainers who aren't in that list.

So, summarizing, we have 2 problems: visibility, machine-readability.
I fully agree they are present issues which need to be solved.

> (1) the list should move to a text file in a VCS. For example, we could
> use a special directory in the collab-maint alioth project, or simply a
> repository writable by all DDs on svn.d.o. This would improve the way
> history is kept too.

I fail to see the advantage of this, especially wrt the two problems
above. The wiki is easier to access than a VCS (you don't have to
checkout) and it already handles history, I don't think full-fledged
history management for the LowThresholdNMU page is something we actually
need.

> (2) the list should be machine-readable. We could use the following
> format:

Agreed, and I like the format you propose.

Why can't we simply change the wiki page to match that format? The wiki
page won't be more error prone than a VCS file using the same format.
What we need to achieve this is just a volunteer which reviews the
current page and converts the current human-readable sentences in
machine-readable strings matching your format.

The only issue I see with the wiki is security, as anyone can currently
edit pages just after the registration, but for the page we are
discussing it won't be worst than the present situation.

> (3) make the state visible on the PTS (see #429883). For each package,
> we could have an icon indicating if the package is NMU-friendly or not.
> All packages would have an icon, so having the "NMU-hostile" icon by
> default could help maintainers remember to add themselves to the list.

Agreed, this can be done even in the current state. The PTS can download
the raw version of the page, consider only the lines that match your
format and ignore the remaining stuff.

Besides, I think we can still do more to improve visibility, as neither
the wiki solution, nor the VCS based one would increase it above the
current status. I would like to see LowThresholdNMU mentioned in the
developer's reference (a quick check I made today shown that it's not
there, but I may be wrong), anyone up to writing a section and submit a
patch?

> Is anyone interested in working on that? I will have problems finding
> the time in the near future

I'm willing to patch the PTS for this, assuming there's an agreement on
doing this "the wiki way" as I proposed above.

Thanks for this proposal Lucas,
Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Improving the visibility of LowThresholdNMU

[Reinhard Tartler]

Lucas Nussbaum <[EMAIL PROTECTED]> writes:

> Hi,
>
> The LowThresholdNMU wiki page[0] lists maintainers (and packages) for
> which NMUs are welcomed. However, in it's current form, it's quite
> useless: it's very difficult to check if a given package is
> NMU-friendly, since the page is not machine-parseable. Also, since it's
> not very useful and visible, it doesn't provide an incentive for
> maintainers to add themselves to the list: there are probably some
> NMU-friendly maintainers who aren't in that list.
>
> [0] http://wiki.debian.org/LowThresholdNmu
>
> I think that we should improve that:
>
> (1) the list should move to a text file in a VCS. For example, we could
> use a special directory in the collab-maint alioth project, or simply a
> repository writable by all DDs on svn.d.o. This would improve the way
> history is kept too.

I feat that having 'simply a repository writable by all DDs' is not
simple at all. What about non-DD maintainers?

> (2) the list should be machine-readable. 

http://wiki.debian.org/LowThresholdNmu?action=raw is close to machine
readable. Perhaps we can make it that?

> We could use the following
> format:
>   maintainer_email [!]package1, [!]package2, [!]package3
> So we would simply list which packages are NMU-friendly, and use a
> special package '*' to indicate that all packages are NMU-friendly. '!'
> would indicate that a package has to be excluded from the list.
> Example:
>   [EMAIL PROTECTED] *, !bash, !dash
> means that all of joe's packages are NMU-friendly, except bash and dash.
> This format could be extended later: we could use regexps, and maybe add
> comments, like:
>   [EMAIL PROTECTED] *, !/lib.*-perl$/ [those are team-maintained, please
> talk with the pkg-perl team], bash [only for important & RC issues]

Perhaps we could invent a syntax which is able to express the above and
fits in Moin? In doubt, we can make the list preformatted, and put
markers at the beginning and the end.

> (3) make the state visible on the PTS (see #429883). For each package,
> we could have an icon indicating if the package is NMU-friendly or not.
> All packages would have an icon, so having the "NMU-hostile" icon by
> default could help maintainers remember to add themselves to the list.

That's a good idea, perhaps the PTS maintainers could comment what the
best way of integrating the information there would be? Would inventing
a header called 'XS-NMUs-Welcome: yes' in debian/control help here? Does
it make sense otherwise to expose this information in Sources.gz?


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


pgpVoVWZbXl2C.pgp
Description: PGP signature

Improving the visibility of LowThresholdNMU

[Lucas Nussbaum]

Hi,

The LowThresholdNMU wiki page[0] lists maintainers (and packages) for
which NMUs are welcomed. However, in it's current form, it's quite
useless: it's very difficult to check if a given package is
NMU-friendly, since the page is not machine-parseable. Also, since it's
not very useful and visible, it doesn't provide an incentive for
maintainers to add themselves to the list: there are probably some
NMU-friendly maintainers who aren't in that list.

[0] http://wiki.debian.org/LowThresholdNmu

I think that we should improve that:

(1) the list should move to a text file in a VCS. For example, we could
use a special directory in the collab-maint alioth project, or simply a
repository writable by all DDs on svn.d.o. This would improve the way
history is kept too.

(2) the list should be machine-readable. We could use the following
format:
  maintainer_email [!]package1, [!]package2, [!]package3
So we would simply list which packages are NMU-friendly, and use a
special package '*' to indicate that all packages are NMU-friendly. '!'
would indicate that a package has to be excluded from the list.
Example:
  [EMAIL PROTECTED] *, !bash, !dash
means that all of joe's packages are NMU-friendly, except bash and dash.
This format could be extended later: we could use regexps, and maybe add
comments, like:
  [EMAIL PROTECTED] *, !/lib.*-perl$/ [those are team-maintained, please
talk with the pkg-perl team], bash [only for important & RC issues]

(3) make the state visible on the PTS (see #429883). For each package,
we could have an icon indicating if the package is NMU-friendly or not.
All packages would have an icon, so having the "NMU-hostile" icon by
default could help maintainers remember to add themselves to the list.

Comments?

Is anyone interested in working on that? I will have problems finding
the time in the near future.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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