Re: Bug#434651: debian-policy: New virtual package: wims-extra

[Russ Allbery]

José "L. Redrejo" <[EMAIL PROTECTED]> writes:

> However most of the "meat" is provided by the packages wims-extra-xx,
> which contain hundreds of educational modules (this number hopefully
> will grow quickly). In July 2007, the installed size of wims-extra-all
> is roughly 200 MBytes.  Some webmasters might want to install less rich
> sets of modules, for example only the modules localised in their
> language, or a set of modules targeted to a particular domain of study.
> There is already a package wims-extra-es with Spanish-only modules, and
> some other packages might be made available in the near future, like a
> French-only collection, or a collection dedicated to physics and
> chemistry, etc.

> The current wims maintainer (who is in the cc'ed list for this mail)
> asked me to sponsor this package, and, after some conversations with
> him, we both agree that wims package should have a recommends to a
> virtual package called "wims-extra", so people may provide packages for
> the "meat" with their particular flavor, while the package
> wims-extra-all providing wims-extra would be part of the official
> distribution.

I don't think I understand from this what the specification of a package
that would Provide wims-extra would be.

A virtual package exists to satisfy a dependency on a specific piece of
functionality.  For example, ispell needs a dictionary, packages need to
depend on a mail transport agent, and Emacs add-ons are only useful if
some version of Emacs is installed.

What dependency is wims-extra providing?  It seems like there is a general
server (wims) and a variety of different modules for it, but I'm not
seeing where anything needs to depend on the wims-extra virtual package.
Wouldn't people just install the wims server and then whatever modules
they want to use, sort of like installing an Apache server and whatever
Apache modules they wish to use?

The description, in particular, sounds like a grab bag of different
functionality:

> wims-extra - extra exercises, translations and modules that enhance wims
> functionalities.

so I don't know what would be guaranteed about a package that Provides
wims-extra.  It seems like all that would tell me is that it works with
wims, which isn't something one has to use a virtual package to do.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Current Policy change proposals

[Russ Allbery]

[ This mail is an experiment with regular reports on the status of open
  Policy change proposals, both as a status report to the project on
  Policy changes and as a request for input and review of proposals by
  interested parties.  If this experiment is successful, both in terms of
  interest and my ability to sustain it, I will start sending this message
  to debian-devel-announce on a regular basis, probably every two weeks. ]

Please direct replies to [EMAIL PROTECTED]

What follows is a list of the normative Policy bugs that are under
discussion or otherwise being tracked by the Policy maintainers.
Currently, I maintain this list manually.  Please contact
[EMAIL PROTECTED] if you see any errors or have any
questions.

I am currently roughly following the new proposed Policy procedure put
forward recently by Manoj, which means that wording proposals aren't
accepted until they've been reviewed and seconded by at least three people
even if completely uncontroversial.  (I'm counting the person proposing
the change as one of those people for right now.)  Proposals needing
additional review and seconds are noted below.

An experimental view of open Policy bugs divided into type of bug and
discussion stage is available at:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&[EMAIL 
PROTECTED]&ordering=policy&pend-exc=done

This may become the default view after further refinement.  Note that far
from all of the bugs currently open are listed below; below are only those
that I'm actively tracking.  If other Policy delegates are actively
tracking issues and will see them through to a resolution, please tell me
which ones and I'll add them to this list.


Blockers for Next Policy Release


402975: require internationalization of debconf templates

Since this is now a release goal, Policy should reflect it.  Given
that it's a release goal, must may be more appropriate than should
again.  Need to decide must vs. should and then get review and
seconds.

420701: GFDL is now in common-licenses

Wording proposed but needs additional work to clean up the language.
Then needs further review and seconds before it can be marked
accepted.

431109: Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks

Required change due to the GPLv3 release, since Policy currently
requires GPLv3 packages to point to a version in common-licenses but
base-files doesn't include the GPLv3.  There is some disagreement over
whether the generic GPL, LGPL, and GFDL symlinks should be deprecated
entirely or still used for packages that give the licensee a choice of
license versions.  A specific wording proposal should probably be
developed in conjunction with or after the resolution of 420701.
There have been several wording proposals, none of which have reached
consensus.

Major Issues


206684: require debconf for all prompting

There seems to be a general consensus that this is a good idea, with a
fallback clause for essential packages and their pre-dependencies, but
not many people have weighed in on the discussion.  Needs a specific
wording proposal, review, and seconds.

209008: common interface for parallel building in DEB_BUILD_OPTIONS

General consensus on Policy wording and a partial wording proposal
(which needs to note that in the absence of this option, packages
should not be built in parallel).  A complete wording proposal is
difficult until 430649 is resolved.

430649: please clarify splitting/syntax of DEB_BUILD_OPTIONS

Blocks 209008.  Policy is currently silent on the question of
delimiters for keywords in DEB_BUILD_OPTIONS and the parsing method
suggested in Policy some find counterintuitive.  It also doesn't deal
well with the proposed parallel=n syntax.  Discussion seems to be
converging on requiring space as a delimiter even though it makes
setting the variable from the command line slightly more annoying,
since make is very good at parsing space-delimited strings.  No
specific wording proposal yet.

Minor Issues


412634: 5.6.17 (Urgency) should list emergency, maybe a normative list?

Wording proposed that adds a normative list of urgency values to
Policy and reconciles the two lists currently present.  No discussion
to date.  Needs review and seconds to be accepted.

431813: support for wrapped Uploaders should now be mandatory

Wording proposed, needs review and seconds to be accepted.  No
discussion to date.

431814: source field of .changes files may contain a version number

Change brings Policy in line with dpkg and dak.  Wording proposed,
needs review and seconds to be accepted.  No discussion after the
wording proposal.

434651: new virtual package wims-extra

Question raised about the expected use of the virtual package, and
about whether it falls into the cooperating package 

Bug#436195: ITP: logapp -- supervise execution of applications producing heavy output

[Kumar Appaiah]

Package: wnpp
Severity: wishlist
Owner: Kumar Appaiah <[EMAIL PROTECTED]>


* Package name: logapp
  Version : 0.7
  Upstream Author : Michael Brunner <[EMAIL PROTECTED]>
* URL : http://logapp.sourceforge.net/
* License : GPL
  Programming Lang: C
  Description : supervise execution of applications producing heavy output

 Logapp is a wrapper utility that helps supervise the execution of
 applications that produce heavy console output (e.g. make, CVS, and
 Subversion). It does this by logging, trimming, and coloring each
 line of the output before displaying it. It can be called instead of
 the executable that should be monitored; it then starts the
 application and logs all of its console output to a file. The output
 shown in the terminal is preprocessed, e.g. to limit the length of
 printed lines and to show the stderr output in a different color. It
 is also possible to automatically highlight lines that match a
 certain regular expression. The output is therefore reduced to the
 necessary amount, and all important lines are easy to identify.
 .
  Homepage: http://logapp.sourceforge.net/

Kumar
-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.22.1 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to 
en_US)
Shell: /bin/sh linked to /bin/bash


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

Re: Symbol-based dependencies on shared libraries: some news

[Raphael Hertzog]

On Sat, 04 Aug 2007, Loïc Minier wrote:
> On Sat, Aug 04, 2007, Raphael Hertzog wrote:
> > Knowing those differences, I wonder if I should offer the possibility to 
> > have
> > debian/.symbols.common that would complement what can be found in
> > debian/.symbols. or if we need something more elaborated like
> > an include mechanism or a syntax to restrict a symbol on a set of 
> > architectures
> > (like for dependencies in Build-Depends). Please give me your opinion on 
> > this.
> 
>  I wish for an include mechanism!  :)

It probably makes sense however it's not always easy to define a
correct semantic:

Let's consider debian/symbols.i386:
| #include 
| libc.so.6 libc6 #MINVER#
|  symbol1 2.6-1

And debian/symbols.all-archs:
| libc.so.6 libc6 #MINVER#
|  symbolX 2.6-1
|  symbolY 2.6-1
[...]

1/ What should happen if the dependency template ("libc6 #MINVER#") is not
the same in both files? If one gets precedence over the other, which one?

2/ What should happen when a symbol is defined in both files? (Two cases:
the version differs or they are the same)

3/ Do we have to create a syntax to "remove" a symbol as part of an
include file ?

My first preference would be to detect all those cases (1/ and 2/) and fail.

You should also note that the build log provides a "diff" of the symbols
file in case there are inconsistencies, but the diff is not directly
applicable if you use an include mechanism. Duplication is bad, but it may
be easier to manage.

>  I think this also makes sense when you have multiple flavors of the
>  same lib (for example libgtk versus libgtk-directfb).

Right. Or curl. :)

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: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd

[Stig Sandbeck Mathisen]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

> The syslog daemon shall not eat anymore than 0.01% of your CPU.

That's just silly. :P

For a cluster of syslog servers, the syslog daemon shall use whatever
CPU time it needs.  If it needs more than one CPU, and more than one
CPU is available, then it's a good idea for the syslog daemon to use
more than one CPU.

You have multiple ways for logs to enter:

  514/udp - the good old standard.

  /tcp - tcp syslog, queued on the client side, ensured on
  the server side, possibly encrypted if data passes external
  networks.

  local sockets, doors, etc...

Logs may be filtered and classified according to priority, network,
server group, application, or facility.

You have several places where the log data will go:

  Disk

  Database

  Some analysis application

  Custom statistics software with realtime graphs.

  IDS (Big, horrible, expensive, java-thingy.  Prints Pretty Pictures)

  Local antispam-daemons.

> Why would you need to bloat it for god's sake?  It reminds me of so
> called network monitors that are so huge, that they mostly measure
> their own fat. A multi-foo syslog daemon is just plain silly.

Not if you run a large network, cluster, server group or if you're an
internet service provider.  If you get tens or hundreds of gigabytes
of logs every day, you need a good framework.  A mail service for just
1M users alone lots 1GB every few hours.  Some of that is interesting,
and everything must be kept for a while.

For your own laptop?  Naah, you can keep sysklogd, as it's probably
good enough for your needs.

Remember that Debian is used by more than just you, so calling the
needs of others "silly" may be perceived as short-sighted.

-- 
Stig Sandbeck Mathisen


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

Re: Symbol-based dependencies on shared libraries: some news

[Mark Brown]

On Mon, Aug 06, 2007 at 10:29:52AM +0200, Raphael Hertzog wrote:
> On Sat, 04 Aug 2007, Loïc Minier wrote:

> >  I wish for an include mechanism!  :)

...

> applicable if you use an include mechanism. Duplication is bad, but it may
> be easier to manage.

Realisitically I expect that if an include mechanism is not provided
then someone will become sufficiently annoyed by this to write a helper
tool and other people will think that this is a good idea and start
using it.  Once that happens any benefit from not having the include
mechanism is lost.  We could also end up with several different ways of
providing include files which would be worse than just having the one,
especially if they end up with different syntaxes.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd

[Pierre Habouzit]

On Mon, Aug 06, 2007 at 10:39:36AM +0200, Stig Sandbeck Mathisen wrote:
> You have multiple ways for logs to enter:
> 
>   514/udp - the good old standard.
> 
>   /tcp - tcp syslog, queued on the client side, ensured on
>   the server side, possibly encrypted if data passes external
>   networks.
> 
>   local sockets, doors, etc...

  and ? how does it takes more than a fragment of CPU time ?

> Logs may be filtered and classified according to priority, network,
> server group, application, or facility.
> 
> You have several places where the log data will go:
> 
>   Disk
> 
>   Database
> 
>   Some analysis application
> 
>   Custom statistics software with realtime graphs.
> 
>   IDS (Big, horrible, expensive, java-thingy.  Prints Pretty Pictures)
> 
>   Local antispam-daemons.

  That takes CPU time but not accounted for the syslog daemon.

> > Why would you need to bloat it for god's sake?  It reminds me of so
> > called network monitors that are so huge, that they mostly measure
> > their own fat. A multi-foo syslog daemon is just plain silly.
>
> Not if you run a large network, cluster, server group or if you're an
> internet service provider.  If you get tens or hundreds of gigabytes
> of logs every day, you need a good framework.  A mail service for just
> 1M users alone lots 1GB every few hours.  Some of that is interesting,
> and everything must be kept for a while.

  I totally fail to see why that would need any kind of CPU power to
deal with. 10Gb/hour is merely 3Mo/s, so even with 10Mo/s peaks you're
not even limited by your hard drive, and you don't even use a full
100Mbits link to get your datas. If you write applications that need
more than one CPU to deal with such an enrmous volume of data, then
well, that's very interesting.

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


pgpgPzbJH7t95.pgp
Description: PGP signature

Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd

[Josselin Mouette]

Le dimanche 05 août 2007 à 23:49 +0200, SZALAY Attila a écrit :
> Yes, you are right in a Desktop. You are right in a server too. But if
> you want to collect log messages from some hundred machine is an other
> question. And it's more easy to put another CPU into the machine than
> double the clock rate.

Some simple experiments we have done show a single CPU is more than
enough to handle 40 Mbit/s of logs (using syslog-ng, of course). There
are some systems where you may need more than one CPU, but you'll find
they are pretty rare.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Bug#434651: debian-policy: New virtual package: wims-extra

[L. Redrejo]

El lun, 06-08-2007 a las 00:17 -0700, Russ Allbery escribió:
> José "L. Redrejo" <[EMAIL PROTECTED]> writes:
> 
> > However most of the "meat" is provided by the packages wims-extra-xx,
> > which contain hundreds of educational modules (this number hopefully
> > will grow quickly). In July 2007, the installed size of wims-extra-all
> > is roughly 200 MBytes.  Some webmasters might want to install less rich
> > sets of modules, for example only the modules localised in their
> > language, or a set of modules targeted to a particular domain of study.
> > There is already a package wims-extra-es with Spanish-only modules, and
> > some other packages might be made available in the near future, like a
> > French-only collection, or a collection dedicated to physics and
> > chemistry, etc.
> 
> > The current wims maintainer (who is in the cc'ed list for this mail)
> > asked me to sponsor this package, and, after some conversations with
> > him, we both agree that wims package should have a recommends to a
> > virtual package called "wims-extra", so people may provide packages for
> > the "meat" with their particular flavor, while the package
> > wims-extra-all providing wims-extra would be part of the official
> > distribution.
> 
> I don't think I understand from this what the specification of a package
> that would Provide wims-extra would be.
> 


> A virtual package exists to satisfy a dependency on a specific piece of
> functionality.  For example, ispell needs a dictionary, packages need to
> depend on a mail transport agent, and Emacs add-ons are only useful if
> some version of Emacs is installed.
> 


I think I understand it perfectly. It just a problem of what you and me
can understand as a functionality. You use the ispell example and I can
use the openoffice.org-l10n-2.2 virtual package that works exactly as we
say wims-extra should work: providing a functionality to a metapackage.


Anyway, I don't care about it anymore, as Magnus Holmgren said in a
previous comment to this bug, we can use it "privately, amongst a
cooperating group of packages", and that's probably the rightest
solution to this issue.

Regards.
José L.



signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Re: /bin/sh diversions

[paddy]

On Sat, Aug 04, 2007 at 01:41:52PM +0200, Marco d'Itri wrote:
> On Aug 03, Thorsten Glaser <[EMAIL PROTECTED]> wrote:
> 
> > Give the user the tools to shoot himself into the foot. Besides, dash
> > is already using the debconf dance, so why discriminate other shells
> > that are fine to do it according to policy?
> To reduce complexity. Complexity is bad.

bear in mind that there is such a thing as too simple, 
and that a lack of diversity can make your system fragile.

Regards,
Paddy


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

[CMake] Producing deb package with 'ar'

[Mathieu Malaterre]

Hi,

  I am currently working on integrating debian packaging system in
cpack (part of CMake, see cmake.org). Basically cpack used to have a
simple tarball system for creating package on *NIX. I simply had to
encapsulate this tarball within an 'ar'ball, with a control and a
md5sums file (*)

  I am now wondering if I should also create some sort of debian
'source' package. As far as I understand there is no such thing, but
instead your are distributing a copy of the original tarball of the
package and a diff file. Is this correct ? If so I need to generate a
diff file wich contains a minial 'debian/rules' file, correct ?


thanks for comment,
-- 
Mathieu

(*) I have been searching quite a lot the web for creating binary
debian package using 'ar'. Since CMake is a cross platform tool, I
thought this would make sense to use the most common tool on *NIX:
'ar' instead of asking cmake user to install specific dpkg build tool.
In an ideal world I should be able to cross compile using cmake under
windows to generate debian package...


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

Re: [CMake] Producing deb package with 'ar'

[Antti-Juhani Kaijanaho]

On Mon, Aug 06, 2007 at 12:34:40PM +0200, Mathieu Malaterre wrote:
>   I am currently working on integrating debian packaging system in
> cpack (part of CMake, see cmake.org). Basically cpack used to have a
> simple tarball system for creating package on *NIX. I simply had to
> encapsulate this tarball within an 'ar'ball, with a control and a
> md5sums file (*)

I recommend reading the deb(5) man page; there may be surprises.

>   I am now wondering if I should also create some sort of debian
> 'source' package. As far as I understand there is no such thing, but
> instead your are distributing a copy of the original tarball of the
> package and a diff file. Is this correct ?

It's not.  A Debian source package consists of two to three files.  The
main file has the suffix .dsc; it specifies source package metadata and
what other files are needed.  The other files are a tarball and an
optional diff.  See
http://www.debian.org/doc/debian-policy/ap-pkg-sourcepkg.html#s-pkg-sourcearchives
.

Also note that packages intended for installation in a Debian system
should follow Debian policy.  This may be nontrivial to achieve using an
automated system like (I assume) cmake.
  See http://www.debian.org/doc/debian-policy/

-- 
Antti-Juhani Kaijanaho, Jyväskylä
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/


signature.asc
Description: Digital signature

Re: [CMake] Producing deb package with 'ar'

[Mathieu Malaterre]

Hi Antti-Juhani

On 8/6/07, Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 06, 2007 at 12:34:40PM +0200, Mathieu Malaterre wrote:
> >   I am currently working on integrating debian packaging system in
> > cpack (part of CMake, see cmake.org). Basically cpack used to have a
> > simple tarball system for creating package on *NIX. I simply had to
> > encapsulate this tarball within an 'ar'ball, with a control and a
> > md5sums file (*)
>
> I recommend reading the deb(5) man page; there may be surprises.

Hum... I don't see anything surprising (debian oldstable). I have been
listing the file in the correct order:

 $ ar -r bla.deb debian-binary control.tar.gz data.tar.gz


And the magic number seems to be ok (!)

>
> >   I am now wondering if I should also create some sort of debian
> > 'source' package. As far as I understand there is no such thing, but
> > instead your are distributing a copy of the original tarball of the
> > package and a diff file. Is this correct ?
>
> It's not.  A Debian source package consists of two to three files.  The
> main file has the suffix .dsc; it specifies source package metadata and
> what other files are needed.  The other files are a tarball and an
> optional diff.  See
> http://www.debian.org/doc/debian-policy/ap-pkg-sourcepkg.html#s-pkg-sourcearchives
> .
>
sweet !
thanks for the link. So according to this page I might even be able to
generate a single tarball:

If there is no original source code - for example, if the package is
specially prepared for Debian or the Debian maintainer is the same as
the upstream maintainer - the format is slightly different: then there
is no diff, and the tarfile is named package_version.tar.gz, and
preferably contains a directory named package-version


Thanks for the link.


> Also note that packages intended for installation in a Debian system
> should follow Debian policy.  This may be nontrivial to achieve using an
> automated system like (I assume) cmake.
>   See http://www.debian.org/doc/debian-policy/
>

That's a completely separate issue. I believe that once a package has
been approved, any minor modification will not impact this initial
decision. So this will be up to the maintainer to follow the debian
policy IMHO. My initial plan is simply to have the whole process of
generating a debian package of cmake using cmake...

Thanks
-Mathieu


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

Re: [CMake] Producing deb package with 'ar'

[Antti-Juhani Kaijanaho]

Please don't CC me, I read the list.

On Mon, Aug 06, 2007 at 01:38:33PM +0200, Mathieu Malaterre wrote:
> thanks for the link. So according to this page I might even be able to
> generate a single tarball:

You do need the .dsc too :)

-- 
Antti-Juhani Kaijanaho, Jyväskylä
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/


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

Re: [CMake] Producing deb package with 'ar'

[Marc 'HE' Brockschmidt]

"Mathieu Malaterre" <[EMAIL PROTECTED]> writes:
> On 8/6/07, Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote:
>> On Mon, Aug 06, 2007 at 12:34:40PM +0200, Mathieu Malaterre wrote:
>>>   I am currently working on integrating debian packaging system in
>>> cpack (part of CMake, see cmake.org). Basically cpack used to have a
>>> simple tarball system for creating package on *NIX. I simply had to
>>> encapsulate this tarball within an 'ar'ball, with a control and a
>>> md5sums file (*)
>> I recommend reading the deb(5) man page; there may be surprises.
> Hum... I don't see anything surprising (debian oldstable). I have been
> listing the file in the correct order:
>
>  $ ar -r bla.deb debian-binary control.tar.gz data.tar.gz

That will not work. ar(1) is GNU ar on most systems, while dpkg uses
ar-as-in-BSD-ar. The diffeences are subtle, but lead to problems in
some applications.

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
193: PHP
   People Hate Perl (Kristian Köhntopp)


pgpnPadtsQr3l.pgp
Description: PGP signature

Re: [CMake] Producing deb package with 'ar'

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/06/07 07:32, Marc 'HE' Brockschmidt wrote:
[snip]
> 
> That will not work. ar(1) is GNU ar on most systems, while dpkg uses
> ar-as-in-BSD-ar. The diffeences are subtle, but lead to problems in
> some applications.

That's interesting.  Why?

- --
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGtx1ES9HxQb37XmcRAor4AKC+jVZfxTAN5PRSL5a8UFqTEhZdCwCfS99D
XT91sSgOD7RE6i54lRGjYWY=
=UXSA
-END PGP SIGNATURE-


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

Packaging source code and Debian diffs (was: [CMake] Producing deb package with 'ar')

[Ben Finney]

"Mathieu Malaterre" <[EMAIL PROTECTED]> writes:

> If there is no original source code - for example, if the package is
> specially prepared for Debian or the Debian maintainer is the same
> as the upstream maintainer - the format is slightly different: then
> there is no diff, and the tarfile is named package_version.tar.gz,
> and preferably contains a directory named package-version

Even if the same person shares both "upstream author" and "Debian
packager" roles, it is highly recommended that you generate a
'foo_1.0.orig.tar.gz' containing the source code that is not
Debian-specific, and a 'foo_1.0-1.diff.gz' patch file that applies the
Debian-specific changes to make it a package.

This way, the source code can more easily be used and tracked on
non-Debian distributions, and transformed simply into a non-Debian
package.

The lack of a 'foo_1.0-1.diff.gz' implies that the package is *only*
ever of use on a Debian system, and is of no purpose outside a Debian
system. If that's not true for your package, you should make it like
any other non-native package.

http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#packaging>

-- 
 \  "Compulsory unification of opinion achieves only the unanimity |
  `\ of the graveyard."  -- Justice Roberts in 319 U.S. 624 (1943) |
_o__)  |
Ben Finney


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

GNU ar versus BSD ar (was: Re: Producing deb package with 'ar')

[mathieu]

On Aug 6, 3:10 pm, Ron Johnson <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/06/07 07:32, Marc 'HE' Brockschmidt wrote:
> [snip]
>
>
>
> > That will not work. ar(1) is GNU ar on most systems, while dpkg uses
> > ar-as-in-BSD-ar. The diffeences are subtle, but lead to problems in
> > some applications.
>
> That's interesting.  Why?

Could anyone please comment on issues when using GNU ar versus BSD
ar ?

As a side note I cannot see any 'ar' executable in the debhelper
package.

Thanks
-Mathieu


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

Re: Packaging source code and Debian diffs (was: [CMake] Producing deb package with 'ar')

[mathieu]

On Aug 6, 4:10 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> "Mathieu Malaterre" <[EMAIL PROTECTED]> writes:
> > If there is no original source code - for example, if the package is
> > specially prepared for Debian or the Debian maintainer is the same
> > as the upstream maintainer - the format is slightly different: then
> > there is no diff, and the tarfile is named package_version.tar.gz,
> > and preferably contains a directory named package-version
>
> Even if the same person shares both "upstream author" and "Debian
> packager" roles, it is highly recommended that you generate a
> 'foo_1.0.orig.tar.gz' containing the source code that is not
> Debian-specific, and a 'foo_1.0-1.diff.gz' patch file that applies the
> Debian-specific changes to make it a package.
>
> This way, the source code can more easily be used and tracked on
> non-Debian distributions, and transformed simply into a non-Debian
> package.
>
> The lack of a 'foo_1.0-1.diff.gz' implies that the package is *only*
> ever of use on a Debian system, and is of no purpose outside a Debian
> system. If that's not true for your package, you should make it like
> any other non-native package.
>
> http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#packaging>

Ok thanks !
This will require yet another dependency to create debia


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

Re: Packaging source code and Debian diffs (was: [CMake] Producing deb package with 'ar')

[mathieu]

On Aug 6, 4:10 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> "Mathieu Malaterre" <[EMAIL PROTECTED]> writes:
> > If there is no original source code - for example, if the package is
> > specially prepared for Debian or the Debian maintainer is the same
> > as the upstream maintainer - the format is slightly different: then
> > there is no diff, and the tarfile is named package_version.tar.gz,
> > and preferably contains a directory named package-version
>
> Even if the same person shares both "upstream author" and "Debian
> packager" roles, it is highly recommended that you generate a
> 'foo_1.0.orig.tar.gz' containing the source code that is not
> Debian-specific, and a 'foo_1.0-1.diff.gz' patch file that applies the
> Debian-specific changes to make it a package.
>
> This way, the source code can more easily be used and tracked on
> non-Debian distributions, and transformed simply into a non-Debian
> package.
>
> The lack of a 'foo_1.0-1.diff.gz' implies that the package is *only*
> ever of use on a Debian system, and is of no purpose outside a Debian
> system. If that's not true for your package, you should make it like
> any other non-native package.
>
> http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#packaging>

Ok thanks a bunch for the reference !
This will require yet another dependency to create debian: a diff
executable (hopefully this time there is no difference between GNU-
diff and BSD-diff)

-Mathieu


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

Re: New PAM in experimental needs testing

[Marc Haber]

On Sun, 05 Aug 2007 18:36:45 +0100, Roger Leigh <[EMAIL PROTECTED]>
wrote:
>A new version of PAM (0.99.7.1-1) has been packaged and uploaded to
>experimental.  This is intended to replace 0.79-4.  However, because
>there have been quite a number of upstream changes, and all the
>Debian-specific patches against the old one were painstakingly
>re-diffed and updated by hand, and because a broken PAM means a rather
>broken system, this new version needs some wider testing before it is
>suitable for unstable.

Does it help when I try installing unstable, upgrading to new pam and
then check whether login and ssh server still works? i canont do this
before tomorrow night, and can only do very basic testing.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: New PAM in experimental needs testing

[Jan Christoph Nordholz]

Hi Marc,

> Does it help when I try installing unstable, upgrading to new pam and
> then check whether login and ssh server still works? i canont do this
> before tomorrow night, and can only do very basic testing.

sure. On a side note, when you do so: pam upstream has introduced symbol
versioning in the meantime, so be sure to restart any running pam-depending
services after the upgrade (there is no postinst prompt that does this
automatically yet), including cron.


Regards,

Jan


signature.asc
Description: Digital signature

Re: Bug#434651: debian-policy: New virtual package: wims-extra

[Russ Allbery]

Magnus Holmgren <[EMAIL PROTECTED]> writes:
> On Wednesday 25 July 2007 17:35, José L. Redrejo wrote:

>> So, I propose to add this entry to the virtual package list:

>> wims-extra - extra exercises, translations and modules that enhance wims
>> functionalities.

> I don't think you need to have wims-extra added to the virtual package
> names list. There is an exception in policy for virtual package names
> used "privately, amongst a cooperating group of packages", which the
> wims and wims-related packages seem to be.

Hm.  I have no idea what the boundaries of that exception should be and
what constitutes "privately, amongst a cooperating group of packages."  At
what point should a virtual package be listed?  We already list several
packages that seem possibly equivalent, such as ispell-dictionary.  I
certainly don't want to get in the way of anyone doing work, and I'm happy
for this to be an exception, but it would be good to sort out just what
the exception is.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: [CMake] Producing deb package with 'ar'

[Hendrik Sattler]

Am Montag 06 August 2007 12:34 schrieb Mathieu Malaterre:
>   I am currently working on integrating debian packaging system in
> cpack (part of CMake, see cmake.org). Basically cpack used to have a
> simple tarball system for creating package on *NIX. I simply had to
> encapsulate this tarball within an 'ar'ball, with a control and a
> md5sums file (*)
>
>   I am now wondering if I should also create some sort of debian
> 'source' package. As far as I understand there is no such thing, but
> instead your are distributing a copy of the original tarball of the
> package and a diff file. Is this correct ? If so I need to generate a
> diff file wich contains a minial 'debian/rules' file, correct ?

I looked at it but didn't want to comment on that on the cmake mailing list. 
The debs created by CMake really cannot be used for inclusion in an official 
debian repository:

1. The "This package was created by CMake" is not really necessary.

2. If the prefix is set to something other than /usr, e.g. /usr/local, it is 
not made sure that the package is installed to /usr instead of to the prefix 
location, thus dpkg will write to /usr/local. Surely not wanted.

3. Different optimisation defaults.

4. The CMake default is to use rpath.

5. No automatic stripping of binaries.

6. Currently no split of big packages (e.g. lib, devel and bin packages) 
although the COMPONENT stuff may work as such but needs adjustment to 
properly name such packages.

7. Currently not possible to Provide Conflicts, Recommends, Suggests and 
Replaces. It is also rather hard as the Debian architecture is not filled in 
automatically. This should be provided by a CMake variable.

8. There is no equivalent for debian/copyright, /usr/share/doc/ is 
usually not populated by upstream packages.

It kind of reminds me of the difference between the formerly upstream "cups" 
package and the cupsys packages in Debian.
Currently, cpack's capability to create .deb packages is a possibility to 
install und uninstall program files in some way, and not more.

HS

PS: Definitely not meant as flaming!


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

Re: [CMake] Producing deb package with 'ar'

[Marc 'HE' Brockschmidt]

Ron Johnson <[EMAIL PROTECTED]> writes:
> On 08/06/07 07:32, Marc 'HE' Brockschmidt wrote:
> [snip]
>> That will not work. ar(1) is GNU ar on most systems, while dpkg uses
>> ar-as-in-BSD-ar. The diffeences are subtle, but lead to problems in
>> some applications.
> That's interesting.  Why?

Because of not using the ar binary but a local implementation, which
chokes on the different field delimiters. See for example
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593:

| a working deb:
| pippin[21:04] build% bin/apt-extracttemplates /tmp/locales_2.2.5-14.3_all.deb
| read name == debian-binary
| read name == control.tar.gz
| read name == data.tar.gz
| locales 2.2.5-14.3 /tmp/template.182200 /tmp/config.182201
|
| your mindterm deb:
| pippin[21:04] build% bin/apt-extracttemplates /tmp/mindterm_1.2.1-7_all.deb
| read name == debian-binary/
| read name == control.tar.gz/
| read name == data.tar.gz/
| read name == _gpgmaint/
| E: /tmp/mindterm_1.2.1-7_all.deb not a valid DEB package.

[The latter was repacked using GNU ar]

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
190: Cisco
   Protokolhure. (unbekannt)


pgpQcEecRfyYl.pgp
Description: PGP signature

Re: Packaging source code and Debian diffs (was: [CMake] Producing deb package with 'ar')

[Josselin Mouette]

Le lundi 06 août 2007 à 15:34 +, mathieu a écrit :
> This will require yet another dependency to create debian: a diff
> executable (hopefully this time there is no difference between GNU-
> diff and BSD-diff)

I don't understand what you are trying to do, but you are doing it the
very wrong way.

The one and only thing you need to create a Debian source package is to
call "dpkg-source -b", from the dpkg-dev package. Anything else is
doomed to produce ugly results.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Packaging source code and Debian diffs (was: [CMake] Producing deb package with 'ar')

[Lionel Elie Mamane]

On Mon, Aug 06, 2007 at 07:58:22PM +0200, Josselin Mouette wrote:
> Le lundi 06 août 2007 à 15:34 +, mathieu a écrit :

>> This will require yet another dependency to create debian: a diff
>> executable (hopefully this time there is no difference between GNU-
>> diff and BSD-diff)

> I don't understand what you are trying to do, but you are doing it
> the very wrong way.

> The one and only thing you need to create a Debian source package is
> to call "dpkg-source -b", from the dpkg-dev package. Anything else
> is doomed to produce ugly results.

I guess he wants to do it on a non-Debian machine without having to
install dpkg-dev, dpkg, ...

-- 
Lionel


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

Re: New PAM in experimental needs testing

[Roger Leigh]

Marc Haber <[EMAIL PROTECTED]> writes:

> On Sun, 05 Aug 2007 18:36:45 +0100, Roger Leigh <[EMAIL PROTECTED]>
> wrote:
>>A new version of PAM (0.99.7.1-1) has been packaged and uploaded to
>>experimental.  This is intended to replace 0.79-4.  However, because
>>there have been quite a number of upstream changes, and all the
>>Debian-specific patches against the old one were painstakingly
>>re-diffed and updated by hand, and because a broken PAM means a rather
>>broken system, this new version needs some wider testing before it is
>>suitable for unstable.
>
> Does it help when I try installing unstable, upgrading to new pam and
> then check whether login and ssh server still works? i canont do this
> before tomorrow night, and can only do very basic testing.

That would be super, thanks.  Just knowing if basic services work
after an upgrade is still valuable knowledge.  If would be useful to
know if the services work before and after a restart of the service
(due to the addition of symbol versioning in libpam).


Many thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


pgpbyHumCJsOH.pgp
Description: PGP signature

Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd

[SZALAY Attila]

Hi All!


I have no connection with rsyslog. I don't know anything about this
program.


On Mon, 2007-08-06 at 08:15 +1000, Hamish Moffatt wrote:
> 
> Since messages arrive on a single socket (usually connection-less)
> ultimately the messages enter through one process/thread. And they get 
> written to a file or database which is ultimately not parallelable
> either. Is there a huge amount of processing in between which justifies
> multithreading?

At first if you poll for an fd in more than one thread you can balance
the load. (When a thread handle a message another thread can read. Just
like in spamassassin :)

At second there may be more than one destionation or you can connect to
a database with more than one connection. So it can be parallelable too.

At third there _may_ be some processing between log reading and writing.

Below this I couldn't answer the questions so I delete it.


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

Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd

[SZALAY Attila]

Hi All!

On Mon, 2007-08-06 at 00:19 +0200, Pierre Habouzit wrote:
> 
>   please don't CC me, I read the list, and my M-F-T specifically ask you
> not to do so[0].

Ok.

>   You didn't answered, why is there any kind of gain to use another CPU
> where 1/100 of one is enough ?

Maybe that is not enough. maybe you want to do something with the log
message, not jast forward it.

>   I code daemons using epoll and such techniques (without threads or
> even multiple processes of course) for a living.

I code daemons with epoll and code program with a lot of threading too.

>   That's very blunt assertions, backed up with nothing. The bottleneck
> in any application that has big flows of data to write somwhere, is the
> hard drive (or you're a very crappy programmer). So please explain to me
> how using more CPU will make you able to write faster to your hard
> drive. I'm sure that would be enlightening.

Maybe there is someone outside the word who want to transform log
messages not just put it into a file. Even maybe rewrite it with regular
expression matching. And somebody maybe want this feature from the log
daemon too.

No I'm not suggesting that that the syslog daemon is the only place to
do this and I'm not saying that everyone need this feature. But this
feature _may_ be handsome for someone.


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

Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd

[Hamish Moffatt]

On Sat, Aug 04, 2007 at 02:18:29PM +1000, Hamish Moffatt wrote:
> On Sat, Aug 04, 2007 at 12:12:50AM +0200, Michael Biebl wrote:
> > * Package name: rsyslog
> >   Version : 1.18.0
> >   Upstream Author : Rainer Gerhards <[EMAIL PROTECTED]>
> > * URL : http://www.rsyslog.com
> > * License : GPL v2 or later
> >   Programming Lang: C
> >   Description : enhanced multi-threaded syslogd
> > 
> > Rsyslog is an enhanced multi-threaded syslogd supporting, amongst
> > others:
> 
> Why is rsyslog being multi-threaded interesting to our users?
> Isn't that an internal implementation decision?

Rainer has blogged about this at:
http://rgerhards.blogspot.com/2007/08/why-is-rsyslog-multi-threaded-and-is-it.html

If I may summarise, rsyslog is currently only actually using two
threads, one to collect messages from input sources and one to write
them out. This is intended to prevent slow output (eg MySQL) potentially
causing messages to be lost.

This seems quite reasonable.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: Packaging source code and Debian diffs (was: [CMake] Producing deb package with 'ar')

[Neil Williams]

On Mon, 6 Aug 2007 21:43:23 +0200
Lionel Elie Mamane <[EMAIL PROTECTED]> wrote:

> On Mon, Aug 06, 2007 at 07:58:22PM +0200, Josselin Mouette wrote:
> > Le lundi 06 août 2007 à 15:34 +, mathieu a écrit :
> 
> >> This will require yet another dependency to create debian: a diff
> >> executable (hopefully this time there is no difference between GNU-
> >> diff and BSD-diff)
> 
> > I don't understand what you are trying to do, but you are doing it
> > the very wrong way.
> 
> > The one and only thing you need to create a Debian source package is
> > to call "dpkg-source -b", from the dpkg-dev package. Anything else
> > is doomed to produce ugly results.
> 
> I guess he wants to do it on a non-Debian machine without having to
> install dpkg-dev, dpkg, ...

Isn't that just inviting problems with uninstallable dependencies?

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpIe0Yppn5Sv.pgp
Description: PGP signature

Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd

[Hamish Moffatt]

On Mon, Aug 06, 2007 at 10:22:22PM +0200, SZALAY Attila wrote:
> At first if you poll for an fd in more than one thread you can balance
> the load. (When a thread handle a message another thread can read. Just
> like in spamassassin :)

There's a risk of reordering the messages if subsequent messages may
take different routes within the application (ie a different receiving
thread); even subsequent messages from the same application, if it is 
not using TCP. 

I wonder if syslog is expected to preserve message order. It could be 
quite confusing...

> At second there may be more than one destionation or you can connect to
> a database with more than one connection. So it can be parallelable too.

Same potential for reordering here.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Bug#436320: ITP: tgt - Linux target framework user-space tools

[Frederik Schueler]

Package: wnpp
Severity: wishlist
Owner: Debian Kernel Team <[EMAIL PROTECTED]>


* Package name: tgt
  Version : 20070807.1
  Upstream Author : [EMAIL PROTECTED]
* URL : git://git.kernel.org/pub/scm/linux/kernel/git/tomo/tgt.git
* License : GPLv2
  Programming Lang: C
  Description : Linux target framework

 Linux target framework (tgt) aims to simplify various SCSI target
 driver (iSCSI, Fibre Channel, SRP, etc) creation and maintenance.

 Tgt consists of kernel modules, user-space daemon, and user-space
 tools. Some target drivers uses all of them and some use only
 user-space daemon and tools (i.e. they completely runs in user space).

 This package contains the user-space daemon and tools, a recent Linux
 kernel is required for the modules.

 Currently, tgt supports three target drivers:

 - IBM VIO server (ibmvstgt)
 - iSCSI
 - Xen vscsifront/back


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.21-2-vserver-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



signature.asc
Description: Digital signature

Re: Considerations for 'xmms' removal from Debian

[David Lopez Zajara (Er_Maqui)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Daniel Kobras wrote:
> On Wed, Jul 04, 2007 at 01:40:05AM -0400, Jordi Gutierrez Hermoso wrote:
>> On 03/07/07, Klaus Ethgen <[EMAIL PROTECTED]> wrote:
>>> I heard this crap only when using alsa.
>> which is a problem, since OSS is deprecated in favour of ALSA.
> 
> It's only OSS-the-kernel-drivers that are deprecated.
> OSS-the-programming-interface still works fine. Not sure, which part of
> ALSA actually gave rise to Klaus's problems, though.
> 
> Regards,
> 
> Daniel.
> 
> 

We can't give all the problem of the OS to xmms, because in this case,
the fail is from alsa system, makes and convenient bug-report to alsa
and try to solvent them. But, it isn't from xmms.


The "old-good" xmms, with our fails. Yes, it's possible if you are
playing files over nfs we can lock them, and the interface its gtk1 and
its outdated. But, its a consolidated program, very tested and debbuged,
and works fine. We are a kind of "noobs" on debian using xmms, and a
group of older users who uses xmms from long time ago. it's the same as
winamp on windows, there have their users and this is fine.

Personally i'm an xmms user, and now, with this, i have tested other
options. Audacious isn't an option at all. Yes, we have the same
winamp-style, and can read winamp & xmms skins, too. But, it's newer and
doesn't have some options interesting (For example, add directory to
playlist). It isn't a joke, this is a  option. Opening the
songs one-by-one or dir-by-dir without recursivety of the inside
directories isn't an option at all.

xmms2... Well, when we have a decent client, then can are an option.
Now, isn't it.


I think who xmms removal its maked in another distros, and i understand
who gtk1 its too outdated. But, debian its the system-for-all and if a
user really likes and older application, we can have this.

[QUOTE]
* 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]
* 'bmpx' and 'audacious' are in Debian, ranks 8048 and 3649 in popcon.
Both are very good and development-active substitutes to xmms.
* There's also in Debian the upstream-supported xmms2 package, 2598 in
popcon rank.

xmms is now 1069 in the overall popcon rank, with 11029 installations,
not counting the plugin users.
[/QUOTE]

If the BTS reports more than 200 bugs, feels free to send to real-xmms
mantainers (the programmers). xmms have an active development line (In
their CVS the last commit was from some weeks ago).

Xmms are broken in "several aspects". Comment out these aspects, the
solution its simply report this aspects, not makes a discursion from
this without planning any solution. If these aspects are know as long
ago, whats the reason for not report this?

Other distros have already removal xmms. Well, other distros aren't
debian. If gentoo gets the facto an hipotetic kernel on 2.7 branch...
(generally, unstable branch of kernel), debian will go to make this too?

bpmx and audacious are 8000+ and 3600+ reported installations, and xmms2
are 2500+ against the 11000+ of xmms. And, i can say who xmms have
already much more. xmms its a oldest package, who many users can have
installed and using them from potato distro or older. In this moment,
popcon isnt present. The popcon information are very unusable in this
case because the package can have a lot of users with this without
popcon. (I have an example on me, with an installation from long ago, i
have popcon because i've installed this manually).


Finally:

I think who xmms removal now isnt an option at all. We can have their
failures, but, isn't a reason for dropping out of mirrors. Debian have a
lot of packages, some of this unmantained, dead upstream and much more.
And, now, we are here talking of removal from the archive a
active-upstream and mantained package...? Please, consider to removal
these lot-of-stuff who are really buggy and unmantained, with RC bugs
and dead-upstreams.


- --
Note: Please doesnt go offtopic in this thread with "dependencies of
audacious" or another OT stuff. If we feels free to discurss these
themes, open a reply of "dependencies failures on sound-like programs",
or so, but doesn't contamine this thread. This discursion it's important
to be read with some people, and 200+ posts discursion its hard to read.
And, with some OT's in this, we can have more than 200+ posts.

- --
[EMAIL PROTECTED]  ||  http://maqui.darkbolt.net
Linux registered user number: #363219
PGP key avaliable at KeyServ. KeyID: 0x4233E9F2
- --
Los hombres somos esclavos de la historia
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGt

Re: Considerations for 'xmms' removal from Debian

[David Lopez Zajara (Er_Maqui)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I can comment out a point:

xmms have 11000+ popcon installations reported. The total reports of
popcon are 57000+. This is aprox 20% of users. Now, are talking for
removal an application for those users?...

I've read the buglist of xmms, and i think who more than one and two
bugs can be removed. Example of this can are #244984, #260754, #161702.
A lot of these bugs are already opened because the version doesn't have
changed (Are revised). I think who can be interesting revise the xmms
buglist and close the outdated bugs, for a real information of
application problems.


I've read in this thread, this is for a orphan package. If this is the
reason, doesnt have much more for talk, another mantainer will become.
xmms its a very popular package. I think who an orphan isn't a reason at
all for removal from arch.


- --
[EMAIL PROTECTED]  ||  http://maqui.darkbolt.net
Linux registered user number: #363219
PGP key avaliable at KeyServ. KeyID: 0x4233E9F2
- --
Los hombres somos esclavos de la historia
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGt+EufFjA4EIz6fIRAvw9AJ9ElMcjfEhMeRt6BTzcNfyIovv0JgCggpnb
YQ5ETkzF03+PUlXPFzqZXmo=
=LPMJ
-END PGP SIGNATURE-


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

Re: Considerations for 'xmms' removal from Debian

[Andrei Popescu]

On Tue, Aug 07, 2007 at 04:22:59AM +0200, David Lopez Zajara (Er_Maqui) wrote:
 
> Personally i'm an xmms user, and now, with this, i have tested other
> options. Audacious isn't an option at all. Yes, we have the same
> winamp-style, and can read winamp & xmms skins, too. But, it's newer and
> doesn't have some options interesting (For example, add directory to
> playlist). It isn't a joke, this is a  option. Opening the
> songs one-by-one or dir-by-dir without recursivety of the inside
> directories isn't an option at all.

Did you even try adding a directory? It might even work ;)

> xmms2... Well, when we have a decent client, then can are an option.
> Now, isn't it.

Same as with mpd :-/

Regards,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)


signature.asc
Description: Digital signature

Re: Considerations for 'xmms' removal from Debian

[Michal Čihař]

Hi

On Tue, 7 Aug 2007 09:25:21 +0300
Andrei Popescu <[EMAIL PROTECTED]> wrote:

> On Tue, Aug 07, 2007 at 04:22:59AM +0200, David Lopez Zajara (Er_Maqui) wrote:
> 
> > xmms2... Well, when we have a decent client, then can are an option.
> > Now, isn't it.
> 
> Same as with mpd :-/

Have you tried to report missing features to authors of some client? Eg.
Sonata upstream is usually very responsive on suggestions.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature