Re: Dropping GStreamer 0.8 for etch

[Loïc Minier]

On Wed, Dec 06, 2006, Helge Kreutzmann wrote:
>The main aim of
> goobox is to play CDs on those systems where no direct link between
> the CD drive and the audio hardware exists (like, e.g., on my ibook).

 Uh, I misparsed your email, on systems with *no* link.  Well, that's
 what sound-juicer, rhythmbox and gnome-cd do AFAICT.

-- 
Loïc Minier <[EMAIL PROTECTED]>
 "I have no strong feelings one way or the other." -- Neutral President


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

Re: Dropping GStreamer 0.8 for etch

[Loïc Minier]

On Wed, Dec 06, 2006, Josselin Mouette wrote:
> >  This is a separate issue, and the short status on the subject is that
> >  upstream thinks this is not possible, but they would accept help on
> >  this topic:
> > 
> The attached patch should be at least enough for Debian. Finally working
> h264 videos with totem-gstreamer, hear hear!
> That's just a hack, and for upstream, this requires of course some
> integration in the configure script, but that's definitely not
> impossible.

 Again, this is a separate issue.  I suggest you subscribe and/or
 comment in the upstream bug.  I was able to produce a hackish
 gst-ffmpeg built with Debian's ffmpeg source as well (though it would
 have required a ffmpeg-source package or equivalent), but it was not
 good enough to be included in Debian.

 I've forwarded your patch upstream for comments.  I rely on upstream
 for updates of gst-ffmpeg.  Applying such a patch to Debian only would
 put upstream in a situation where bugs coming from Debian might be seen
 as "tainted".

-- 
Loïc Minier <[EMAIL PROTECTED]>
 "I have no strong feelings one way or the other." -- Neutral President


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

Re: Dropping GStreamer 0.8 for etch

[Josselin Mouette]

Le jeudi 07 décembre 2006 à 09:53 +0100, Loïc Minier a écrit :
>  I've forwarded your patch upstream for comments.  I rely on upstream
>  for updates of gst-ffmpeg.  Applying such a patch to Debian only would
>  put upstream in a situation where bugs coming from Debian might be seen
>  as "tainted".

I don't think this justifies the extra burden on the security team, and
the bugs in some codecs that are fixed in the Debian ffmpeg package.
Given the growing number of h.264 videos out there, it doesn't make much
sense to ship a video player that can't read them, especially when it
can be so easily fixed.

As the situation is very similar in mplayer, mplayer is considered
RC-buggy by the security team. There was an exception for
gstreamer-ffmpeg because it was considered too difficult to fix, but I
don't think this is justified and this should be considered
release-critical as well.
-- 
Josselin Mouette/\./\

"Do you have any more insane proposals for me?"

Re: [RFH] migrating to cmake

[Eduard Bloch]

#include 
* Bastian Venthur [Wed, Dec 06 2006, 12:56:37PM]:
> Hi,
> 
> one of my packages moved to cmake and I wonder how the classic
> 
> ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE)
> --prefix=/usr --mandir=\$${prefix}/share/man
> --infodir=\$${prefix}/share/info CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs"
> 
> -line in debian/rules translates to cmake. The environment variables
> CFLAGS and LDFLAGS shouldn't be a problem, but how do I set the --host,
> --build, --prefix, --mandir and --infodir parameters?

You could rip some examples from 

http://svn.debian.org/wsvn/debburn/cdrkit/trunk/Makefile?op=file&rev=0&sc=0

Note that this is for an out-of-source build, in the "build" directory.

I don't know your package but you maybe could just throw this Makefile
into your directory and use it as-is... Maybe with reenabling the
wrapper rule (see below). Or just applying those cmake commands in
debian/rules.

AFAIK --host and --build are autoconfisms, do you really need them?

Eduard.

-- 
 Ich bin verwirrt, wenn ich tippe während meine Freundin mich knutscht.


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

Re: Dropping GStreamer 0.8 for etch

[Sebastian Dröge]

Am Mittwoch, den 06.12.2006, 22:47 +0100 schrieb Josselin Mouette:
> Le mercredi 06 décembre 2006 à 21:48 +0100, Loïc Minier a écrit :
> > On Wed, Dec 06, 2006, Josselin Mouette wrote:
> > > Maybe it is also not too late to rework the gstreamer0.10-ffmpeg package
> > > to link against the Debian libavcodec/libavformat packages. This would
> > > save a lot of trouble to the security team.
> > 
> >  This is a separate issue, and the short status on the subject is that
> >  upstream thinks this is not possible, but they would accept help on
> >  this topic:
> > 
> 
> The attached patch should be at least enough for Debian. Finally working
> h264 videos with totem-gstreamer, hear hear!

You can also get working h.264 decoding by taking latest gst-ffmpeg CVS
which will be released as 0.10.2 in a few days. As upstream does very
extensive tests that their current ffmpeg snapshot works as expected
with the gstreamer plugin I think it's far safer to stay with their
version unless we want bugs that are not reproducible with upstream's
gstreamer plugin and ffmpeg combination.

Also using a different ffmpeg version than upstream could lead to our
bugreports being rejected or at least being seen as less valid than
other bugreports with default builds...

Bye


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Dropping GStreamer 0.8 for etch

[Sebastian Dröge]

Am Mittwoch, den 06.12.2006, 21:27 +0100 schrieb Loïc Minier:
> Hi,
> 
>  This is to discuss dropping the 0.8 series of GStreamer for etch.
> 
>  Recently, a security bug affected gst-ffmpeg and needed an upload for
>  both the 0.8 and 0.10.  The security team wonders whether it will have
>  to support both sources for the etch lifetime.
>The number of packages which are still using the 0.8 series of
>  GStreamer has dropped significantly.  Remain as libgstreamer0.8-0
>  rdeps:
>  - teatime: Sebastian Dröge sent a patch for GStreamer 0.10 support in
>#401897

A new version of teatime including this patch (2.6.0-5) was already
uploaded today.


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Dropping GStreamer 0.8 for etch

[Ross Burton]

On Wed, 2006-12-06 at 22:05 +0100, Helge Kreutzmann wrote:
> Well, I haven't tried sound-juicer, but according to the (very brief)
> package description, it is a ripper, and not a player. The main aim of
> goobox is to play CDs on those systems where no direct link between
> the CD drive and the audio hardware exists (like, e.g., on my ibook). When I
> searched late 2004 for a good audio program to do this I ended up with
> goobox. If indeed sound-juicer *plays* audio CDs nice as well, I'll
> try it.

It's primary goal is to be a ripper, but it can play CDs too.  The
interface is designed around playback as a way of previewing what you
are about to rip, but it will happily play an entire CD.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



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

Re: Dropping GStreamer 0.8 for etch

[Loïc Minier]

On Thu, Dec 07, 2006, Josselin Mouette wrote:
> I don't think this justifies the extra burden on the security team, and
> the bugs in some codecs that are fixed in the Debian ffmpeg package.
> Given the growing number of h.264 videos out there, it doesn't make much
> sense to ship a video player that can't read them, especially when it
> can be so easily fixed.

 It's nice that you're concerned by this state of fact, but this is
 nothing new, and was already discussed multiple times.  I actually
 already discussed this since months with 1) Debian users 2) upstream 3)
 the ffmpeg maintainer 4) the security team.
   If you truly want to unlock this situation, subscribe to the upstream
 bug on the subject, and update your patch to be acceptable upstream.

> As the situation is very similar in mplayer, mplayer is considered
> RC-buggy by the security team. There was an exception for
> gstreamer-ffmpeg because it was considered too difficult to fix, but I
> don't think this is justified and this should be considered
> release-critical as well.

 Again, nothing new.  As you state yourself, this was already discussed
 and an exception was granted.  Beside, you miss the important point
 that gst-ffmpeg heavily patches (read: "replaces") the ffmpeg build
 system, wihle mplayer has a close-to-vanilla ffmpeg tree.


 "Dropping GStreamer 0.8 for etch" is not "building gst-ffmpeg against
 Debian's ffmpeg"; any of these changes can be achieved in whatever
 order, these are orthogonal, even if both would help security support
 (in a different way).  As I'm not considering building gst-ffmpeg
 against ffmpeg for etch, I kindly suggest we let this subthread die or
 be continued in the upstream bug report where it would be more useful.

-- 
Loïc Minier <[EMAIL PROTECTED]>
 "I have no strong feelings one way or the other." -- Neutral President


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

Re: Dropping GStreamer 0.8 for etch

[Romain Beauxis]

On Thursday 07 December 2006 11:06, Sebastian Dröge wrote:
> >    The number of packages which are still using the 0.8 series of
> >  GStreamer has dropped significantly.  Remain as libgstreamer0.8-0
> >  rdeps:

Seems that you do not include some other packages not directly depending on 
this lib.

For instance mine is built with ruby's bindings...
If you were to choose to remove it before etch, you better prospect for 
dependances on gstreamer0.8-foo packages, and as I fear, fill bugs quiclky 
since they may be more than this list..

Anyway, I'm gonne prepare a new release of my package using 0.10.

Romain

Re: Dropping GStreamer 0.8 for etch

[Ana Guerrero]

On Wed, Dec 06, 2006 at 09:27:52PM +0100, Loïc Minier wrote:
> Hi,
> 
>  This is to discuss dropping the 0.8 series of GStreamer for etch.
> 
>  Recently, a security bug affected gst-ffmpeg and needed an upload for
>  both the 0.8 and 0.10.  The security team wonders whether it will have
>  to support both sources for the etch lifetime.
>The number of packages which are still using the 0.8 series of
>  GStreamer has dropped significantly.  Remain as libgstreamer0.8-0
>  rdeps:

[...]

>  - kttsd: no idea about this one

This program is shipped inside kdeaccessibility. 
Build kttsd with support of GStreamer is optional, so in case it does not 
work with GStreamer 0.10, this dependency could be dropped.

Ana


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

Re: Dropping GStreamer 0.8 for etch

[Josselin Mouette]

Le jeudi 07 décembre 2006 à 11:30 +0100, Loïc Minier a écrit :
>  It's nice that you're concerned by this state of fact, but this is
>  nothing new, and was already discussed multiple times.  I actually
>  already discussed this since months with 1) Debian users 2) upstream 3)
>  the ffmpeg maintainer 4) the security team.
>If you truly want to unlock this situation, subscribe to the upstream
>  bug on the subject, and update your patch to be acceptable upstream.

By hiding behind upstream, you're simply refusing to fix the problem.
The patch is a hack that is only guaranteed to work on a Debian system,
and upstream will refuse it until it is done in a proper way. This is
not how things work. Forwarding fixes upstream is important but it
doesn't come before fixing the Debian bug.

> > As the situation is very similar in mplayer, mplayer is considered
> > RC-buggy by the security team. There was an exception for
> > gstreamer-ffmpeg because it was considered too difficult to fix, but I
> > don't think this is justified and this should be considered
> > release-critical as well.
> 
>  Again, nothing new.  As you state yourself, this was already discussed
>  and an exception was granted.  Beside, you miss the important point
>  that gst-ffmpeg heavily patches (read: "replaces") the ffmpeg build
>  system, wihle mplayer has a close-to-vanilla ffmpeg tree.

The exception was granted because of this assumption, which is *entirely
wrong*, as gst-ffmpeg ships a vanilla ffmpeg tree. It took me less than
one hour to figure it out and to build a working package with the Debian
ffmpeg library.

>  "Dropping GStreamer 0.8 for etch" is not "building gst-ffmpeg against
>  Debian's ffmpeg"; any of these changes can be achieved in whatever
>  order, these are orthogonal, even if both would help security support
>  (in a different way).  As I'm not considering building gst-ffmpeg
>  against ffmpeg for etch, I kindly suggest we let this subthread die or
>  be continued in the upstream bug report where it would be more useful.

As the security people are the ones being really affected, I would like
to have Moritz' input on this matter. Are you ready to grant an
exception to gstreamer-ffmpeg and not to mplayer while the situation of
both packages is strictly identical?

-- 
Josselin Mouette/\./\

"Do you have any more insane proposals for me?"

Re: Dropping GStreamer 0.8 for etch

[Loïc Minier]

On Thu, Dec 07, 2006, Romain Beauxis wrote:
> Seems that you do not include some other packages not directly depending on 
> this lib.

 Actually, I had a look when I sent this message, and saw:
bee% apt-cache rdepends libgstreamer0.8-ruby
libgstreamer0.8-ruby
Reverse Depends:
  ruby-gnome2

 and:
bee% apt-cache rdepends python-gst
python-gst
Reverse Depends:

 I should have looked closer at the ruby-gnome2 dependency on
 libgstreamer0.8-ruby; I'm a bit surprized it's a Depends, perhaps this
 is a legacy dependency because the package was split?

 Fortunately:
bee% apt-cache rdepends ruby-gnome2
ruby-gnome2
Reverse Depends:
  geekast-binary

> For instance mine is built with ruby's bindings...

 I'm afraid you lack a dependency on the ruby bindings for GStreamer
 then.

> If you were to choose to remove it before etch, you better prospect for 
> dependances on gstreamer0.8-foo packages, and as I fear, fill bugs quiclky 
> since they may be more than this list..

 Well, there's the risk of uncovering missing dependencies indeed.

> Anyway, I'm gonne prepare a new release of my package using 0.10.

 Great!

-- 
Loïc Minier <[EMAIL PROTECTED]>
 "I have no strong feelings one way or the other." -- Neutral President


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

SUMMARY: Re: Dropping GStreamer 0.8 for etch

[Loïc Minier]

On Wed, Dec 06, 2006, Loïc Minier wrote:
>  - teatime: Sebastian Dröge sent a patch for GStreamer 0.10 support in
>#401897

 Fixed package uploaded.

>  - muine: version 0.8.6 in experimental is built against GStreamer 0.10,
>see #381784

 Fixed package available.

>  - kttsd: no idea about this one

 GStreamer support can be switched to 0.10 or dropped.

>  - goobox

 Alternative programs available with a superset of the features, and an
 active upstream.  I'm waiting for a final ack of the maintainer that
 the alternatives are indeed okay and that we can proceed with removal.

 Initially missing from the list: geekast-binary.  The maintainer
 commented that he is now working on porting this package to GStreamer
 0.10.


 As soon as the above issues are cleared in testing, I'll request the
 removal of the GStreamer 0.8 suite of testing and unstable.

-- 
Loïc Minier <[EMAIL PROTECTED]>
 "I have no strong feelings one way or the other." -- Neutral President


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

Re: Dropping GStreamer 0.8 for etch

[Loïc Minier]

On Thu, Dec 07, 2006, Josselin Mouette wrote:
> By hiding behind upstream, you're simply refusing to fix the problem.

 Insulting.

> as gst-ffmpeg ships a vanilla ffmpeg tree

 Wrong.

> As the security people are the ones being really affected, I would like
> to have Moritz' input on this matter. Are you ready to grant an
> exception to gstreamer-ffmpeg and not to mplayer while the situation of
> both packages is strictly identical?

 Insulting.


 I don't intend to pursue discussion, especially not in these
 conditions.

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


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

Re: Dropping GStreamer 0.8 for etch

[Josselin Mouette]

Le jeudi 07 décembre 2006 à 13:17 +0100, Loïc Minier a écrit :
> On Thu, Dec 07, 2006, Josselin Mouette wrote:
> > By hiding behind upstream, you're simply refusing to fix the problem.
> 
>  Insulting.

Feel insulted if you want. This issue has been known for months and it
took me one hour to find a way around it. And that is a fact, not an
insult.

>  I don't intend to pursue discussion, especially not in these
>  conditions.

You know I can been convinced by good technical arguments. But if you
don't have anything better than « upstream doesn't do that », I will
have to ask the CTTE to settle this matter.

-- 
Josselin Mouette/\./\

"Do you have any more insane proposals for me?"

Re: Dropping GStreamer 0.8 for etch

[Greg Folkert]

On Wed, 2006-12-06 at 22:05 +0100, Helge Kreutzmann wrote:
> Hello,
> On Wed, Dec 06, 2006 at 09:41:11PM +0100, Daniel Baumann wrote:
> > Loïc Minier wrote:
> > >  - goobox: gnome.org module that did not see any new upstream release
> > >since november 2005 and seems to be completely superseded by
> > >sound-juicer; Daniel Baumann seems to continue maintenance of this
> > >source
> 
> Well, I haven't tried sound-juicer, but according to the (very brief)
> package description, it is a ripper, and not a player. The main aim of
> goobox is to play CDs on those systems where no direct link between
> the CD drive and the audio hardware exists (like, e.g., on my ibook). When I
> searched late 2004 for a good audio program to do this I ended up with
> goobox. If indeed sound-juicer *plays* audio CDs nice as well, I'll
> try it.

The Direct link (using ground, left and right) is typically called
"Redbook Audio" or at least that is what it was called around the time
the games "Descent" and the "Crusader" series (No Regrets and No Remorse
versions) were NEWLY released.
-- 
greg, [EMAIL PROTECTED]

The technology that is
Stronger, better, faster:  Linux


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

Re: SUMMARY: Re: Dropping GStreamer 0.8 for etch

[Romain Beauxis]

On Thursday 07 December 2006 12:03, Loïc Minier wrote:
>  Initially missing from the list: geekast-binary.  The maintainer
>  commented that he is now working on porting this package to GStreamer
>  0.10.

Ok, it seems that the issue is more complicated than that.
Indeed, the while ruby-gnome2 bindings pack is built upon gstreamer2, see:
http://packages.debian.org/unstable/libs/ruby-gnome2
and
http://packages.debian.org/unstable/libs/libgstreamer0.8-ruby

Now the big question now is: is it only a matter of recompiling against or is 
there some restriction for using gstreamer0.10 for ruby-gnome2. I CCed the 
maintainer to have his point on this.

Also, again, it seems important to indicate more precisely which packages 
depends on gstreamer2 since libgstreamer0.8-ruby was not on your list whereas 
it depends on libgstreamer0.8-0 (>= 0.8.11)

When ruby-gnome2 uses 0.10 changing my package will only be a matter of 
changing the dependencies I hope.



Romain

Re: Dropping GStreamer 0.8 for etch

[Michael Banck]

On Thu, Dec 07, 2006 at 01:57:46PM +0100, Josselin Mouette wrote:
> Feel insulted if you want. This issue has been known for months and it
> took me one hour to find a way around it. And that is a fact, not an
> insult.

Maybe start by adjusting the subject next time you start discussing
unrelated issues.


thanks,

Michael


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

Ondemand governor by default in etch

[John Goerzen]

Hi,

I believe that we should enable CPU frequency scaling, and the ondemand
governer, by default in etch.

By doing so, we:

 * Save our users money with their power bills

 * Reduce the contribution to pollution and global warming by machines
   running Debian, and thus help to save the planet.

Setting the ondemand governor:

 * Will cause negligible impact on system performance.  ondemand seems
   to have the philosophy of "max system speed unless I can be shown
   that the system is pretty much idle"

 * Requires no user-land tools to manage

 * Is compatible with almost all modern hardware, and just won't
   load on machines that don't support it

 * Requires only a 10K ondemand module and a 5-15K driver module to be
   loaded into the kernel

Why should it be the default?

Earlier this morning, I wrote up the procedure [1] to enable CPU
frequency scaling and the ondemand governor.  It's about 3 pages, and
not even newbie friendly at that.  So the first reason is that people
that don't know about this feature aren't prone to find it, and even if
they find it, they aren't prone to know how to enable it.

[1] 
http://changelog.complete.org/posts/572-Saving-Power-with-CPU-Frequency-Scaling.html

Secondly, the ondemand governor is very non-invasive.  It requires no
userspace daemon.  It makes a negligible impact on performance.  And if
people do wish to run a userspace daemon, this default will not
interfere with it.  I've tried it all over the place.  It is stable and
reliable.

Thirdly, it is ethically the right thing to do.  Think about all the
thousands (millons?) of machines that are running Debian.  If we save
even an average of 10W per machine, we could be talking about huge
energy savings worldwide.  We save our users money on their power and
cooling bills.  We reduce air pollution, which has been shown to have
negative health effects.  And we reduce greenhouse gas emissions.

I can't see any reason NOT to do it.

How would we turn it on by default?

1. Compile all the CPU frequency drivers (not the governors) into the
   kernel statically.  This should only add about 150K to the kernel
   size.  We don't currently have a way to autodetect which CPU
   frequency driver to use for a machine.  The alternative is to try to
   modprobe all of them, with ACPI last, at boot.

2. modprobe cpufreq_ondemand at boot (not necessary on 2.6.18)

3. Run something like:

   for CPU in /sys/devices/system/cpu/*; do
  echo ondemand > $CPU/cpufreq/scaling_governor
  cat $CPU/cpufreq/cpu_max_freq > $CPU/cpufreq/scaling_max_freq
   done

Very easy.

Thoughts?



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

Re: SUMMARY: Re: Dropping GStreamer 0.8 for etch

[Sjoerd Simons]

On Thu, Dec 07, 2006 at 02:53:59PM +0100, Romain Beauxis wrote:
> On Thursday 07 December 2006 12:03, Loïc Minier wrote:
> >  Initially missing from the list: geekast-binary.  The maintainer
> >  commented that he is now working on porting this package to GStreamer
> >  0.10.
> 
> Ok, it seems that the issue is more complicated than that.
> Indeed, the while ruby-gnome2 bindings pack is built upon gstreamer2, see:
> http://packages.debian.org/unstable/libs/ruby-gnome2
> and
> http://packages.debian.org/unstable/libs/libgstreamer0.8-ruby
> 
> Now the big question now is: is it only a matter of recompiling against or is 
> there some restriction for using gstreamer0.10 for ruby-gnome2. I CCed the 
> maintainer to have his point on this.

ruby-gnome2 only contains bindings for gstreamer 0.8. To use gstreamer 0.10 you
need the libgstreamer0.10-ruby1.8 package. Which works perfectly with the rest
of ruby-gnome2 :)

> When ruby-gnome2 uses 0.10 changing my package will only be a matter of 
> changing the dependencies I hope.

Note that your application will need some porting to gstreamer 0.10.  At least 
the current source in debian doesn't seem to support gstreamer 0.10

  Sjoerd
-- 
Of course you can't flap your arms and fly to the moon.  After a while you'd
run out of air to push against.


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

Re: debian-private and Gmail

[Joey Schulze]

Nelson A. de Oliveira wrote:
> I saw that it's possible to redirect my @debian.org email to an
> address and also redirect debian-private to another email. @debian.org
> is set to @gmail.com. Good. But what do I do with debian-private?
> Is it possible to redirect debian-private to @people.debian.org and
> read it at this machine?
> Can someone give me help on this, please?

You can always direct it to any of the debian.org hosts itself.
All of them have a running mail system and many have mutt installed,
for example.

See  for documentation.

You could also check if Batched SMTP still works on Debian machines:
http://lists.debian.org/debian-devel/2001/02/msg00965.html

Regards,

Joey

-- 
Long noun chains don't automatically imply security.  -- Bruce Schneier


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

Re: Ondemand governor by default in etch

[Evgeni Golov]

On Thu, 7 Dec 2006 09:36:29 -0600 John Goerzen wrote:

> I believe that we should enable CPU frequency scaling, and the
> ondemand governer, by default in etch.

s/ondemand/conservative/

But yes, auto-freq-scaling would be some good thing (even on servers,
my amd64 runs with 1GHz instead of 2GHz, when nothing is there to
crack ;))

Regards
Evgeni

-- 
   ^^^| Evgeni -SargentD- Golov ([EMAIL PROTECTED])
 d(O_o)b  | PGP-Key-ID: 0xAC15B50C
  >-|-<   | WWW: http://www.die-welt.net   ICQ: 54116744
   / \| IRC: #sod @ irc.german-freakz.net



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

Re: Ondemand governor by default in etch

[John Goerzen]

On Thu, Dec 07, 2006 at 05:03:42PM +0100, Evgeni Golov wrote:
> On Thu, 7 Dec 2006 09:36:29 -0600 John Goerzen wrote:
> 
> > I believe that we should enable CPU frequency scaling, and the
> > ondemand governer, by default in etch.
> 
> s/ondemand/conservative/

I personally wouldn't mind that.  My general impression -- and this is
just me -- is that conservative takes longer to raise the CPU frequency
when there is activity.  It therefore can produce a noticable
performance hit.  That is fine for some, but is less of a "conservative"
change from previous releases of Debian.  

Of course, you do save more power that way, so making it easy for the
user to change to conservative would be a positive thing as well.

With ondemand, for instance, I can see the CPU blip up to max speed when
I click on my icon to open a Konsole, when Iceweasel is rendering a web
page, etc.  It reacts very, very fast.  Conservative doesn't seem to
quite as much.

-- John


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

Re: Ondemand governor by default in etch

[Hendrik Sattler]

Am Donnerstag 07 Dezember 2006 16:36 schrieb John Goerzen:
> I believe that we should enable CPU frequency scaling, and the ondemand
> governer, by default in etch.

Did you read the kernel help for it?:
"The support for this governor depends on CPU capability to do fast frequency 
switching (i.e, very low latency frequency transitions)."
The most important word is "very".

>  * Is compatible with almost all modern hardware, and just won't
>load on machines that don't support it
>
>  * Requires only a 10K ondemand module and a 5-15K driver module to be
>loaded into the kernel
>
> Why should it be the default?

It shouldn't.

> Earlier this morning, I wrote up the procedure [1] to enable CPU
> frequency scaling and the ondemand governor.  It's about 3 pages, and
> not even newbie friendly at that.  So the first reason is that people
> that don't know about this feature aren't prone to find it, and even if
> they find it, they aren't prone to know how to enable it.

apt-get install cpufrequtils
cpufreq-set -g ondemand

Really hard ;)

> Secondly, the ondemand governor is very non-invasive.  It requires no
> userspace daemon.  It makes a negligible impact on performance.  And if
> people do wish to run a userspace daemon, this default will not
> interfere with it.  I've tried it all over the place.  It is stable and
> reliable.

I already had a system go off with it. Ok, it didn't have low latency 
switching.

> Thirdly, it is ethically the right thing to do.  Think about all the
> thousands (millons?) of machines that are running Debian.  If we save
> even an average of 10W per machine, we could be talking about huge
> energy savings worldwide.  We save our users money on their power and
> cooling bills.  We reduce air pollution, which has been shown to have
> negative health effects.  And we reduce greenhouse gas emissions.
>
> I can't see any reason NOT to do it.
>
> How would we turn it on by default?

You REALLY should take a look at laptop-mode-tools.
They can do this for you including loading the proper modules when needed and 
LOTS of other energy saving technics.

And you should take a look at the "conservative" governor, too.
And BTW, did you measure the power savings? My WLAN card and monitor backlight 
eat _all_ the savings and the kernel usually knows how to put the processor 
to a sleep state.

HS


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

Re: Ondemand governor by default in etch

[Marco d'Itri]

On Dec 07, John Goerzen <[EMAIL PROTECTED]> wrote:

> 1. Compile all the CPU frequency drivers (not the governors) into the
>kernel statically.  This should only add about 150K to the kernel
>size.  We don't currently have a way to autodetect which CPU
>frequency driver to use for a machine.  The alternative is to try to
>modprobe all of them, with ACPI last, at boot.
Totally unacceptable. The alternative is to use the autodetection script
which was posted last month to this mailing list.
I am strongly opposed to any plan which requires unnecessary built-in
kernel code.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Ondemand governor by default in etch

[Evgeni Golov]

Hi,

please don't CC me ;)

On Thu, 7 Dec 2006 10:31:38 -0600 John Goerzen wrote:

> On Thu, Dec 07, 2006 at 05:03:42PM +0100, Evgeni Golov wrote:
> > On Thu, 7 Dec 2006 09:36:29 -0600 John Goerzen wrote:
> > 
> > > I believe that we should enable CPU frequency scaling, and the
> > > ondemand governer, by default in etch.
> > 
> > s/ondemand/conservative/
> 
> I personally wouldn't mind that.  My general impression -- and this is
> just me -- is that conservative takes longer to raise the CPU
> frequency when there is activity.  It therefore can produce a
> noticable performance hit.  That is fine for some, but is less of a
> "conservative" change from previous releases of Debian.  

Yes you're right, consevative is a bit slower than ondemand. But from
my expirience it is not slow enough you would recognize while starting
a "monster" like iceweasel or openoffice.org

> Of course, you do save more power that way, so making it easy for the
> user to change to conservative would be a positive thing as well.

It is already very easy, just install cpufrequtils and
edit /etc/default/cpufrequtils and it will start your governor at
boottime.



-- 
   ^^^| Evgeni -SargentD- Golov ([EMAIL PROTECTED])
 d(O_o)b  | PGP-Key-ID: 0xAC15B50C
  >-|-<   | WWW: http://www.die-welt.net   ICQ: 54116744
   / \| IRC: #sod @ irc.german-freakz.net



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

Re: Ondemand governor by default in etch

[John Goerzen]

On Thu, Dec 07, 2006 at 05:23:51PM +0100, Hendrik Sattler wrote:
> Am Donnerstag 07 Dezember 2006 16:36 schrieb John Goerzen:
> > I believe that we should enable CPU frequency scaling, and the ondemand
> > governer, by default in etch.
> 
> Did you read the kernel help for it?:

So, broadly speaking, you support doing something like this by default,
just not the ondemand governor?

> "The support for this governor depends on CPU capability to do fast frequency 
> switching (i.e, very low latency frequency transitions)."
> The most important word is "very".

I have yet to see a machine with trouble with this, though that doesn't
say they couldn't exist.

See, for example, Novell's comments here:

http://forge.novell.com/pipermail/powersave-devel/2006-April/000478.html

> > Earlier this morning, I wrote up the procedure [1] to enable CPU
> > frequency scaling and the ondemand governor.  It's about 3 pages, and
> > not even newbie friendly at that.  So the first reason is that people
> > that don't know about this feature aren't prone to find it, and even if
> > they find it, they aren't prone to know how to enable it.
> 
> apt-get install cpufrequtils
> cpufreq-set -g ondemand
> 
> Really hard ;)

That is completely useless unless the user has already manually figured
out which cpufreq modules to load, and loaded them.

I tested that before I wrote my article.  It doesn't load modules for
you, and nothing else does by default, either.  I also grepped through
the source: not an insmod or a modprobe to be found.

That bit is the largest problem anyway.

> > interfere with it.  I've tried it all over the place.  It is stable and
> > reliable.
> 
> I already had a system go off with it. Ok, it didn't have low latency 
> switching.

If we tweak the parameters so it doesn't switch as fast, probably that
could be solved, yes?  Novell seems to believe that ondemand configured
that way is more stable than conservative.

> You REALLY should take a look at laptop-mode-tools.
> They can do this for you including loading the proper modules when needed and 
> LOTS of other energy saving technics.

I have.

It is also much more invasive than this simple switch, and doesn't
necessarily play nice with Gnome/KDE cpu frequency widgets, etc.  Plus
there are n favorite userspace daemons (laptop-mode-tools, powersaved,
powernowd, cpudyn, etc, etc.).

I suggested it this way because it is non-invasive and works with
anything.

> And you should take a look at the "conservative" governor, too.
> And BTW, did you measure the power savings? My WLAN card and monitor 
> backlight 
> eat _all_ the savings and the kernel usually knows how to put the processor 
> to a sleep state.

It makes a noticable difference on my Macbook Pro's battery life.  I
don't (yet) have the equipment to measure the power draw of my desktop.

Note that this is not the same as a sleep state.  This holds the CPU at
a lower frequency until CPU utilization hits 80% (by default).

-- John


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

Re: Ondemand governor by default in etch

[John Goerzen]

On Thu, Dec 07, 2006 at 05:43:07PM +0100, Marco d'Itri wrote:
> On Dec 07, John Goerzen <[EMAIL PROTECTED]> wrote:
> 
> > 1. Compile all the CPU frequency drivers (not the governors) into the
> >kernel statically.  This should only add about 150K to the kernel
> >size.  We don't currently have a way to autodetect which CPU
> >frequency driver to use for a machine.  The alternative is to try to
> >modprobe all of them, with ACPI last, at boot.
> Totally unacceptable. The alternative is to use the autodetection script
> which was posted last month to this mailing list.

If there is a working autodetection script, that would be just fine with
me.



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

Re: Removing sodipodi

[Daniel Baumann]

Daniel Baumann wrote:
> inkscape actually replaces sodipodi in every aspect. Is anybody against
> a removal of sodipodi?

ok, nobody against.. scheduling for removal now... thanks.

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


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

Re: SUMMARY: Re: Dropping GStreamer 0.8 for etch

[Romain Beauxis]

Le jeudi 7 décembre 2006 16:33, Sjoerd Simons a écrit :
> ruby-gnome2 only contains bindings for gstreamer 0.8. To use gstreamer 0.10
> you need the libgstreamer0.10-ruby1.8 package. Which works perfectly with
> the rest of ruby-gnome2 :)

Thanks forthis point, I did not knew it !

> > When ruby-gnome2 uses 0.10 changing my package will only be a matter of
> > changing the dependencies I hope.
>
> Note that your application will need some porting to gstreamer 0.10.  At
> least the current source in debian doesn't seem to support gstreamer 0.10

Hum..
Is the API different ?


Romain

Re: SUMMARY: Re: Dropping GStreamer 0.8 for etch

[Ana Guerrero]

On Thu, Dec 07, 2006 at 12:03:11PM +0100, Loïc Minier wrote:
> 
> >  - kttsd: no idea about this one
> 
>  GStreamer support can be switched to 0.10 or dropped.
>

Uploaded kttsd dropping gstreamer depends.

Ana


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

Re: Ondemand governor by default in etch

[Mattia Dongili]

On Thu, Dec 07, 2006 at 11:07:46AM -0600, John Goerzen wrote:
> On Thu, Dec 07, 2006 at 05:23:51PM +0100, Hendrik Sattler wrote:
[...]
> > "The support for this governor depends on CPU capability to do fast 
> > frequency 
> > switching (i.e, very low latency frequency transitions)."
> > The most important word is "very".
> 
> I have yet to see a machine with trouble with this, though that doesn't
> say they couldn't exist.

$ grep -r 'policy->cpuinfo.transition_latency' arch/*
arch/arm/mach-integrator/cpu.c: policy->cpuinfo.transition_latency = 100; 
/* 1 ms, assumed */
arch/arm/mach-sa1100/cpu-sa1100.c:  policy->cpuinfo.transition_latency = 
CPUFREQ_ETERNAL;
arch/arm/mach-sa1100/cpu-sa1110.c:  policy->cpuinfo.transition_latency = 
CPUFREQ_ETERNAL;
arch/arm/plat-omap/cpu-omap.c:  policy->cpuinfo.transition_latency = 
CPUFREQ_ETERNAL;
arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c:
policy->cpuinfo.transition_latency = 0;
arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c:
policy->cpuinfo.transition_latency)
arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c:
policy->cpuinfo.transition_latency =
arch/i386/kernel/cpu/cpufreq/cpufreq-nforce2.c: 
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
arch/i386/kernel/cpu/cpufreq/elanfreq.c:
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
arch/i386/kernel/cpu/cpufreq/gx-suspmod.c:  
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
arch/i386/kernel/cpu/cpufreq/longhaul.c:
policy->cpuinfo.transition_latency = 20;/* nsec */
arch/i386/kernel/cpu/cpufreq/longrun.c: policy->cpuinfo.transition_latency = 
CPUFREQ_ETERNAL;
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c: 
policy->cpuinfo.transition_latency = 100; /* assumed */
arch/i386/kernel/cpu/cpufreq/powernow-k6.c: 
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
arch/i386/kernel/cpu/cpufreq/powernow-k7.c: 
policy->cpuinfo.transition_latency = cpufreq_scale(200UL, fsb, latency);
arch/i386/kernel/cpu/cpufreq/sc520_freq.c:  
policy->cpuinfo.transition_latency = 100; /* 1ms */
arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:  
policy->cpuinfo.transition_latency = 1; /* 10uS transition latency */
arch/i386/kernel/cpu/cpufreq/speedstep-ich.c:
&policy->cpuinfo.transition_latency,
arch/i386/kernel/cpu/cpufreq/speedstep-smi.c:   
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
arch/ia64/kernel/cpufreq/acpi-cpufreq.c:
policy->cpuinfo.transition_latency = 0;
arch/ia64/kernel/cpufreq/acpi-cpufreq.c:
policy->cpuinfo.transition_latency) {
arch/ia64/kernel/cpufreq/acpi-cpufreq.c:
policy->cpuinfo.transition_latency =
arch/powerpc/platforms/cell/cbe_cpufreq.c:  
policy->cpuinfo.transition_latency = 25000;
arch/powerpc/platforms/powermac/cpufreq_32.c:   
policy->cpuinfo.transition_latency  = CPUFREQ_ETERNAL;
arch/powerpc/platforms/powermac/cpufreq_64.c:   
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
arch/sh/kernel/cpufreq.c:   policy->cpuinfo.transition_latency = 
CPUFREQ_ETERNAL;
arch/sparc64/kernel/us2e_cpufreq.c: policy->cpuinfo.transition_latency = 0;
arch/sparc64/kernel/us3_cpufreq.c:  policy->cpuinfo.transition_latency = 0;

I'd say half of the supported cpus haven't ondemand/conservative
available (CPUFREQ_ETERNAL automatically disqualifies the two
governors). :)

To automagically detect the thing you just have to load the proper cpu
driver (a script appeared here on the list), try to load all governors
and see what happens (AFAIR ondemand barfs if the transition latency is
too high, eventually just check /sys//scaling_available_governors).

I agree with others who said it's just unnecessary to force the whole
thing into the kernel.

-- 
mattia
:wq!


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

Bug#402041: ITP: libdanga-socket-perl -- Event loop and event-driven async socket base class

[Krzysztof Krzyzaniak (eloy)]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>


* Package name : libdanga-socket-perl
  Version  : 1.55
  Upstream Authors : 
- Brad Fitzpatrick <[EMAIL PROTECTED]> - author
- Michael Granger <[EMAIL PROTECTED]> - docs, testing
- Mark Smith <[EMAIL PROTECTED]> - contributor, heavy user, testing
- Matt Sergeant <[EMAIL PROTECTED]> - kqueue support, docs, timers, 
other bits.
* URL  : http://www.cpan.org/modules/by-module/Danga/
* License  : Perl: Artistic/GPL2
  Programming Lang : Perl
  Description  : Event loop and event-driven async socket base class

 Danga::Socket an abstract base class for objects backed by a socket which
 provides the basic framework for event-driven asynchronous IO,
 designed to be fast.  Danga::Socket is both a base class for objects,
 and an event loop.
 .
 Callers subclass Danga::Socket.  Danga::Socket's constructor registers
 itself with the Danga::Socket event loop, and invokes callbacks on the
 object for readability, writability, errors, and other conditions.
 .
 Because Danga::Socket uses the "fields" module, your subclasses must
 too.


-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-686
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) (ignored: LC_ALL set to 
pl_PL)


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

Re: Ondemand governor by default in etch

[John Goerzen]

On Thu, Dec 07, 2006 at 07:28:50PM +0100, Mattia Dongili wrote:
> arch/sparc64/kernel/us2e_cpufreq.c: policy->cpuinfo.transition_latency = 
> 0;
> arch/sparc64/kernel/us3_cpufreq.c:  policy->cpuinfo.transition_latency = 
> 0;
> 
> I'd say half of the supported cpus haven't ondemand/conservative
> available (CPUFREQ_ETERNAL automatically disqualifies the two
> governors). :)

Perhaps, but if 90% of people are running the half that do support it,
then it doesn't matter too much.

> To automagically detect the thing you just have to load the proper cpu
> driver (a script appeared here on the list), try to load all governors
> and see what happens (AFAIR ondemand barfs if the transition latency is
> too high, eventually just check /sys//scaling_available_governors).

Where would be the proper place to insert this logic?  A new package?
An existing one?

When you say that ondemand barfs, is that detectable at the point that
you try to echo something to scaling_governor?  (That is, echo would
return an error code?)

I'd volunteer to write it.

-- John


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

Re: Ondemand governor by default in etch

[Mattia Dongili]

On Thu, Dec 07, 2006 at 03:22:35PM -0600, John Goerzen wrote:
> On Thu, Dec 07, 2006 at 07:28:50PM +0100, Mattia Dongili wrote:
> > arch/sparc64/kernel/us2e_cpufreq.c: policy->cpuinfo.transition_latency 
> > = 0;
> > arch/sparc64/kernel/us3_cpufreq.c:  policy->cpuinfo.transition_latency 
> > = 0;
> > 
> > I'd say half of the supported cpus haven't ondemand/conservative
> > available (CPUFREQ_ETERNAL automatically disqualifies the two
> > governors). :)
> 
> Perhaps, but if 90% of people are running the half that do support it,
> then it doesn't matter too much.

eheh, I did expect this objection ;)

> > To automagically detect the thing you just have to load the proper cpu
> > driver (a script appeared here on the list), try to load all governors
> > and see what happens (AFAIR ondemand barfs if the transition latency is
> > too high, eventually just check /sys//scaling_available_governors).
> 
> Where would be the proper place to insert this logic?  A new package?
> An existing one?

Hummm, see #342014 and #396117 and #367307
and see also: http://lists.debian.org/debian-devel/2005/07/msg00026.html

> When you say that ondemand barfs, is that detectable at the point that
> you try to echo something to scaling_governor?  (That is, echo would
> return an error code?)

yes (should be EINVAL)
-- 
mattia
:wq!


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

Bug#402078: ITP: haskell-anydbm -- Generic DBM-type interface for Haskell

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen <[EMAIL PROTECTED]>

* Package name: haskell-anydbm
  Version : 1.0.0
  Upstream Author : John Goerzen <[EMAIL PROTECTED]>
* URL : http://software.complete.org/anydbm (coming soon)
* License : LGPL
  Programming Lang: Haskell
  Description : Generic DBM-type interface for Haskell
 This module provides a generic infrastructure for supporting storage
 of hash-like items with String-to-String mappings.  It can be used
 for in-memory or on-disk storage.
 .
 Two simple backend drivers are included with this package: one
 that is RAM-only, and one that is persistent and disk-backed.
 The hdbc-anydbm package provides another driver, which lets you use
 simple tables in any SQL database to provide a DBM-like interface.
 MissingPy also provides a Python driver which lets you use any 
 Python anydbm driver under Haskell AnyDBM.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-2-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Bug#402074: ITP: libsearch-xapian-perl -- Perl bindings for the Xapian C++ search library

[Frank Lichtenheld]

Subject: ITP: libsearch-xapian-perl -- Perl bindings for the Xapian C++ search 
library
Package: wnpp
Owner: Frank Lichtenheld <[EMAIL PROTECTED]>
Severity: wishlist

(CCed xapian-core maintainer for comments)

* Package name: libsearch-xapian-perl
  Version : 0.9.6.0
  Upstream Author : Alex Bowley / Olly Betts <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~kilinrax/Search-Xapian-0.9.6.0/
http://www.xapian.org/
* License : Perl (GPL+Artistic)
  Programming Lang: Perl (XS)
  Description : Perl bindings for the Xapian C++ search library

 This packages provides Perl bindings for Xapian.
 .
 The Xapian search engine library is a highly adaptable toolkit to allow
 developers to easily add advanced indexing and search facilities to their own
 applications.  It implements the probabilistic model of information retrieval,
 and provides facilities for performing ranked free-text searches, relevance
 feedback, phrase searching, boolean searching, stemming, and simultaneous
 update and searching.  It is highly scalable, and is capable of working with
 collections containing hundreds of millions of documents.
 .
  Homepage: http://www.xapian.org/

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-k7
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Bug#402076: ITP: blktrace -- block layer IO tracing

[Bas Zoetekouw]

Package: wnpp
Severity: wishlist
Owner: Bas Zoetekouw <[EMAIL PROTECTED]>

* Package name: blktrace
  Version : x.y.z
  Upstream Author : Jens Axboe <[EMAIL PROTECTED]>
* URL : http://brick.kernel.dk/snaps/
* License : GPL 2 or later
  Programming Lang: C
  Description : block layer IO tracing

blktrace is a block layer IO tracing mechanism which provides detailed
information about request queue operations up to user space. There are
three major components that are provided:

  \item[Kernel patch] A patch to the Linux kernel which includes the
  kernel event logging interfaces, and patches to areas within the block
  layer to emit event traces. If you run a 2.6.17-rc1 or newer kernel,
  you don't need to patch blktrace support as it is already included.

  \item[blktrace] A utility which transfers event traces from the kernel
  into either long-term on-disk storage, or provides direct formatted
  output (via blkparse).

  \item[blkparse] A utility which formats events stored in files, or when
  run in \emph{live} mode directly outputs data collected by blktrace.


-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18.3
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)


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

Bug#402080: ITP: haskell-configfile -- Parser and writer for handling sectioned config files in Haskell

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen <[EMAIL PROTECTED]>

* Package name: haskell-configfile
  Version : 1.0.0
  Upstream Author : John Goerzen <[EMAIL PROTECTED]>
* URL : http://software.complete.org/configfile (coming soon)
* License : LGPL
  Programming Lang: Haskell
  Description : Parser and writer for handling sectioned config files in 
Haskell
 The ConfigFile module works with configuration files in a standard
 format that is easy for the user to edit, easy for the programmer
 to work with, yet remains powerful and flexible.  It is inspired by,
 and compatible with, Python's ConfigParser module.  It uses files
 that resemble Windows .INI-style files, but with numerous 
 improvements.
 .
 ConfigFile provides simple calls to both read and write config files.
 It's possible to make a config file parsable by this module,
 the Unix shell, and make.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-2-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: dictd: no activity last 12 months

[Yauheni Kaliuta]

On 12/5/06, Helmut Wollmersdorfer <[EMAIL PROTECTED]> wrote:

Andreas Tille wrote:

> Hijacking the package?

My packaging skills are too poor.



I can take it if nobody wants since I use it (not too active, but) and
have goot contact with the current upstream maintainer.
But I do not like to ask people (to sponsor the package this case), so
it's better if there is somebody else.

Bye


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

update-inetd

[Brian May]

Hello,

Are there any good examples on the "correct way" of maintaining
inetd.conf entries in Debian maintainer scripts?

It appears Heimdal gets this wrong:

http://bugs.debian.org/401258

I strongly suspect the problem is the code (I copied elsewhere) that
disables the service on upgrades and then re-enables it again after
the upgrade is finished (hmmm seems broken just thinking about
it).

Anyway, in this case, the service is not re-enabled again because the
default for this service is not to enable it.

Comments?

Thanks.
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: dictd: no activity last 12 months

[Andreas Tille]

On Fri, 8 Dec 2006, Yauheni Kaliuta wrote:


I can take it if nobody wants since I use it (not too active, but) and
have goot contact with the current upstream maintainer.
But I do not like to ask people (to sponsor the package this case), so
it's better if there is somebody else.


If you are fail to find a sponsor my interest in dict is high enough
to invest some spare time.

Kind regards

   Andreas.

--
http://fam-tille.de


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

Work-needing packages report for Dec 8, 2006

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 331 (new: 3)
Total number of packages offered up for adoption: 88 (new: 1)
Total number of packages requested help for: 36 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   libapache-mod-gzip (#401682), orphaned 2 days ago
 Description: HTTP compression module for Apache
 Installations reported by Popcon: 296

   mailscanner (#401510), orphaned 4 days ago
 Description: email virus scanner and spam tagger
 Installations reported by Popcon: 160

   siege (#401680), orphaned 2 days ago
 Description: Http regression testing and benchmarking utility
 Installations reported by Popcon: 83

328 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   perl-tk (#401489), offered 4 days ago
 Description: Perl module providing the Tk graphics library.
 Reverse Depends: babygimp cd-circleprint clusterssh divxcomp horae
   libdevel-ptkdb-perl libtk-filedialog-perl libtk-gbarr-perl
   libtk-histentry-perl libtk-objscanner-perl (15 more omitted)
 Installations reported by Popcon: 4692

87 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] lighttpd (#401575), requested 3 days ago
 Description: A fast webserver with minimal memory footprint
 Reverse Depends: lighttpd-mod-cml lighttpd-mod-magnet
   lighttpd-mod-mysql-vhost lighttpd-mod-trigger-b4-dl
   lighttpd-mod-webdav
 Installations reported by Popcon: 308

   aboot (#315592), requested 532 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot aboot-cross dfsbuild ltsp-client
 Installations reported by Popcon: 50

   apt-build (#365427), requested 222 days ago
 Description: Need new developer(s)
 Installations reported by Popcon: 497

   apt-show-versions (#382026), requested 121 days ago
 Description: lists available package versions with distribution
 Installations reported by Popcon: 1986

   athcool (#278442), requested 772 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 222

   audacity (#397166), requested 32 days ago
 Description: looking for co-maintainer
 Installations reported by Popcon: 2087

   cdw (#398252), requested 25 days ago
 Description: Tool for burning CD's - console version
 Reverse Depends: cdw gcdw
 Installations reported by Popcon: 250

   cvs (#354176), requested 287 days ago
 Description: Concurrent Versions System
 Reverse Depends: bonsai crossvc cvs-autoreleasedeb cvs-buildpackage
   cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta (16
   more omitted)
 Installations reported by Popcon: 9227

   docbook (#358522), requested 260 days ago
 Description: standard SGML representation system for technical
   documents
 Reverse Depends: alcovebook-sgml docbook-dsssl docbook-to-man
   sgmltools-lite
 Installations reported by Popcon: 3509

   docbook-xml (#358520), requested 260 days ago
 Description: standard XML documentation system, for software and
   systems
 Reverse Depends: dblatex docbook-dsssl docbook-ebnf
   docbook-html-forms docbook-jrefentry docbook-mathml docbook-simple
   docbook-slides docbook-website docbook-xsl-stylesheets-ko (6 more
   omitted)
 Installations reported by Popcon: 12602

   dpkg (#282283), requested 747 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-src backuppc
   build-essential clamsmtp crosshurd cvs-autoreleasedeb
   cvs-buildpackage (82 more omitted)
 Installations reported by Popcon: 20307

   grub (#248397), requested 941 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: dfsbuild grub-splashimages grubconf replicator
 Installations reported by Popcon: 16768

   gtkpod (#319711), requested 501 days ago
 Description: manage songs and playlists on an Apple iPod
 Installations reported by Popcon: 472

   ispell-et (#391105), requested 64 days ago
 Description: Estonian dictionary for Aspell/Ispell/MySpell
 Installations reported by Popcon: 15

   loop-aes-modules (#385615), requested 98 days ago
 Description: loop-AES modules
 Reverse Depends: loop-