Re: merkel fs issues

[Joerg Jaspert]

On 11631 March 1977, Anthony Towns wrote:

> There seem to be some issues with the ftp mirror on merkel:

> $ pwd
> /srv/ftp.debian.org/ftp
> $ ls -l dists/sid/Contents-powerpc.diff/ | tail -n2
> -rw-rw-r-- 1 archvsync archvsync   2053 Jan 14 13:40 Index
> ?- ? ? ?  ?? 
> dists/sid/Contents-powerpc.diff/2008-11-08-0841.02.gz

> Though I guess that looks like it's over NFS to spohr now, so hopefully
> doesn't imply there's local corruption on merkel.

It is all fine on spohr:
jo...@spohr:/srv/mirrors/ftp.debian.org/ftp$ pwd
/srv/mirrors/ftp.debian.org/ftp
jo...@spohr:/srv/mirrors/ftp.debian.org/ftp$ ls -l 
dists/sid/Contents-powerpc.diff/
total 648
-rw-r--r-- 1 archvsync archvsync  43695 2008-11-14 20:51 2008-11-14-2050.13.gz
-rw-r--r-- 1 archvsync archvsync  24884 2008-11-21 08:29 2008-11-21-0827.57.gz
-rw-r--r-- 1 archvsync archvsync  25300 2008-11-27 20:54 2008-11-27-2052.35.gz
-rw-r--r-- 1 archvsync archvsync  32896 2008-12-03 20:47 2008-12-03-2046.04.gz
-rw-r--r-- 1 archvsync archvsync  77935 2008-12-10 08:37 2008-12-10-0836.31.gz
-rw-r--r-- 1 archvsync archvsync 152980 2008-12-16 08:48 2008-12-16-0846.29.gz
-rw-r--r-- 1 archvsync archvsync 100784 2008-12-22 08:39 2008-12-22-0839.13.gz
-rw-r--r-- 1 archvsync archvsync  11207 2008-12-25 14:30 2008-12-25-1428.54.gz
-rw-r--r-- 1 archvsync archvsync  23518 2008-12-29 02:34 2008-12-29-0233.11.gz
-rw-r--r-- 1 archvsync archvsync  49389 2009-01-01 08:31 2009-01-01-0831.17.gz
-rw-r--r-- 1 archvsync archvsync  14257 2009-01-04 20:25 2009-01-04-2024.37.gz
-rw-r--r-- 1 archvsync archvsync  13723 2009-01-08 02:36 2009-01-08-0234.37.gz
-rw-r--r-- 1 archvsync archvsync  21221 2009-01-11 14:26 2009-01-11-1425.23.gz
-rw-r--r-- 1 archvsync archvsync  13976 2009-01-14 20:40 2009-01-14-2039.26.gz
-rw-rw-r-- 1 archvsync archvsync   2053 2009-01-14 20:40 Index

So this seems to be broken NFS or something.

-- 
bye, Joerg
> I tried to make my own judgements all the time. And that involves
> reading the fscking graphviz license in full many times!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: merkel fs issues

[Joerg Jaspert]

> Umh... This might be the cause, then. Our mirror sync has died three
> days in a row - At 16:37, 15:49 and 17:36 (GMT-6):

>From where are you pulling?

-- 
bye, Joerg
Five exclamation marks, the sure sign of an insane mind.
-- Terry Pratchett, Reaper Man


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: merkel fs issues

[Peter Palfrader]

On Thu, 15 Jan 2009, Anthony Towns wrote:

> There seem to be some issues with the ftp mirror on merkel:
> 
> $ pwd
> /srv/ftp.debian.org/ftp
> $ ls -l dists/sid/Contents-powerpc.diff/ | tail -n2
> -rw-rw-r-- 1 archvsync archvsync   2053 Jan 14 13:40 Index
> ?- ? ? ?  ?? 
> dists/sid/Contents-powerpc.diff/2008-11-08-0841.02.gz
> 
> Though I guess that looks like it's over NFS to spohr now, so hopefully
> doesn't imply there's local corruption on merkel.

That issue wasn't present on spohr or gluck.  Re-mounting seems to have
"fixed" it.  Thanks.

Peter
-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Change user used by package

[Harald Braumann]

On Wed, 14 Jan 2009 13:49:22 -0500
"Jamin W. Collins"  wrote:

> Marvin Renich wrote:
> > * Harald Braumann  [090113 05:47]:
> >>
> >> AFAIK, there's no way for multiple independent packages for using
> >> the same user. So jabber-muc needs to create its own user. On
> >> update, that's no problem. The post-install script can chown the
> >> package's directories for the new user. But a downgrade would then
> >> not be possible. The old version couldn't access the directories.
> >>
> >> Is there precedence for such a situation? How can it be resolved?
> >>
> >> Cheers,
> >> harry
> > 
> > BTW, are you coordinating this with the current jabber-muc
> > maintainer (CC'ed in case he is not subscribed)?
> 
Sorry, I should have coordinated this with Jamin from the beginning,
but I needed the package quickly, so I built it my own.

> I'm not subscribed, haven't been following the lists for a while.  The
> old package should probably be removed completely in favor of the new.

I'll file a bug report with a pointer to my sources. There have been
very recent changes in upstream's source repository
(http://svn.gna.org/viewcvs/mu-conference/trunk/), so it seems it's not
dead, after all. 

Jamin: are you still willing to maintain that package? I can help with
packaging, but I'm not a DD myself. 

Cheers,
harry


signature.asc
Description: PGP signature

Bug#511522: general: Man pages should say what package a program belongs to

[Jack Grahl]

As several people have pointed out, there is already a good way (that I was not 
aware of) to find out this information, therefore I agree that this bug should 
be closed.

Jack







--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Change user used by package

[revuedelibre .]

On Thu, Jan 15, 2009 at 12:01 PM, Harald Braumann  wrote:

> On Wed, 14 Jan 2009 13:49:22 -0500
> "Jamin W. Collins"  wrote:
>
> > Marvin Renich wrote:
> > > * Harald Braumann  [090113 05:47]:
> > >>
> > >> AFAIK, there's no way for multiple independent packages for using
> > >> the same user. So jabber-muc needs to create its own user. On
> > >> update, that's no problem. The post-install script can chown the
> > >> package's directories for the new user. But a downgrade would then
> > >> not be possible. The old version couldn't access the directories.
> > >>
> > >> Is there precedence for such a situation? How can it be resolved?
> > >>
> > >> Cheers,
> > >> harry
> > >
> > > BTW, are you coordinating this with the current jabber-muc
> > > maintainer (CC'ed in case he is not subscribed)?
> >
> Sorry, I should have coordinated this with Jamin from the beginning,
> but I needed the package quickly, so I built it my own.
>
> > I'm not subscribed, haven't been following the lists for a while.  The
> > old package should probably be removed completely in favor of the new.
>
> I'll file a bug report with a pointer to my sources. There have been
> very recent changes in upstream's source repository
> (http://svn.gna.org/viewcvs/mu-conference/trunk/), so it seems it's not
> dead, after all.
>
> Jamin: are you still willing to maintain that package? I can help with
> packaging, but I'm not a DD myself.
>
> Cheers,
> harry


Hello,
You can join current maintainer of muc-conference by jabber on  : omega
AROBASE im.aping.org

Regards,

Julien

Re: Change user used by package

[revuedelibre .]

On Thu, Jan 15, 2009 at 1:20 PM, revuedelibre . wrote:

>
> On Thu, Jan 15, 2009 at 12:01 PM, Harald Braumann wrote:
>
>> On Wed, 14 Jan 2009 13:49:22 -0500
>> "Jamin W. Collins"  wrote:
>>
>> > Marvin Renich wrote:
>> > > * Harald Braumann  [090113 05:47]:
>> > >>
>> > >> AFAIK, there's no way for multiple independent packages for using
>> > >> the same user. So jabber-muc needs to create its own user. On
>> > >> update, that's no problem. The post-install script can chown the
>> > >> package's directories for the new user. But a downgrade would then
>> > >> not be possible. The old version couldn't access the directories.
>> > >>
>> > >> Is there precedence for such a situation? How can it be resolved?
>> > >>
>> > >> Cheers,
>> > >> harry
>> > >
>> > > BTW, are you coordinating this with the current jabber-muc
>> > > maintainer (CC'ed in case he is not subscribed)?
>> >
>> Sorry, I should have coordinated this with Jamin from the beginning,
>> but I needed the package quickly, so I built it my own.
>>
>> > I'm not subscribed, haven't been following the lists for a while.  The
>> > old package should probably be removed completely in favor of the new.
>>
>> I'll file a bug report with a pointer to my sources. There have been
>> very recent changes in upstream's source repository
>> (http://svn.gna.org/viewcvs/mu-conference/trunk/), so it seems it's not
>> dead, after all.
>>
>> Jamin: are you still willing to maintain that package? I can help with
>> packaging, but I'm not a DD myself.
>>
>> Cheers,
>> harry
>
>
> Hello,
> You can join current maintainer of muc-conference by jabber on  : omega
> AROBASE im.aping.org
>
> Regards,
>
> Julien
>


Hello,
I made a mistake :

omega AROBASE im.apinc.org

Julien

Re: merkel fs issues

[Sergio Mendoza]

On Thu, Jan 15, 2009 at 10:05:22AM +0100, Joerg Jaspert wrote:
> 
> > Umh... This might be the cause, then. Our mirror sync has died three
> > days in a row - At 16:37, 15:49 and 17:36 (GMT-6):
> 
> From where are you pulling?


syncproxy.wna.debian.org


Sergio.

--
Dr Sergio Mendoza   Tel: + 52 55 56223928 & 56223906 
Instituto de Astronomia UNAMFax: + 52 55 56160653
AP 70-264, Ciudad Universitaria http://www.mendozza.org/sergio
Distrito Federal CP 04510, Mexico
GNUpg Key: http://www.mendozza.org/sergio/gpg-public-key.asc
Key fingerprint = 9CC8 9F2C F685 806A B6C4  E444 5CA1 19A0 ECD1 DBB6



> 
> -- 
> bye, Joerg
> Five exclamation marks, the sure sign of an insane mind.
>   -- Terry Pratchett, Reaper Man
> 


signature.asc
Description: Digital signature

Re: Arch:all package depending on package that isn't Arch:any

[Julian Andres Klode]

On Wed, Jan 14, 2009 at 07:32:18PM +, Neil Williams wrote:
>
> Package: acpi-support-base
> Architecture: any
> Depends: acpid [i386|amd64]
>
I do not understand what you are proposing. The package would not be 
binary-indep
in your proposal (and the current syntax for depends is "acpid [i386 amd64]").


> That's simpler and easily supported by existing tools (AFAICT).
No, it's not really. Depends are parsed during the build-time, and dependencies
for non-matching architectures are removed from the binary package. But we are
talking about binary-indep packages, so this won't work.


This would be my other proposal, also known as Bug#436733:
  Package: acpi-support-base
  Architecture: all
  Depends: acpid [i386 amd64]

But in order to be correct, currently apt and co. do not support this. 
Therefore,
this could only be used in Squeeze+1 as well.


Summary


1. Architecture: all [arch1 arch2]
 This proposal is not backward compatible, but it would be very easy to
 do for the maintainer.
2. The one we discussed above.
 This is not backward compatible, but provides the most functionality of all
 proposals. And it can also be used to have an architecture independent packages
 depend on different packages (in case there is a package a on the one arch, and
 a package b on the other arch, but the package supports both); without 
half-broken
 dependencies.
 The disadvantage is that the packages still appear in the Packages files, 
without
 being of use on the architecture. They may even contain broken symlinks, etc.

3. Install-Architecture field
 Adding a new field is backwards-compatible. But it would introduce a new field,
 which some do not like that much. Only programs creating repositories would 
need
 to be adapted.
4. An external location
 This is backward compatible too. The problem with this proposal is that it puts
 to a small group of people (if it would be implemented like some stuff we have
 already). Programs creating repositories would need to be changed to accept
 such a file.
 It is also not really normal, as we have the architecture list for 
architecture-dependant
 packages also in the source package.

If we want to do it in a better way, we should choose option 1 or 2. Even if we 
want
something different, option 2 would still be good to implement, because it 
makes life
easier and gives architecture-independent packages the same flexibility like
architecture-dependent ones.

The best seems to be a combination of 1 and 2, giving a lot of flexibility. If 
we want
something which we could start using with Squeeze, we should choose option 3.

Option 4 is not really a good idea, as the data should be contained in the 
packages themselves,
so people do not install a package not meant for their architecture.

-- 
Julian Andres Klode  - Free Software Developer
   Debian Developer  - Contributing Member of SPI
   Ubuntu Member - Fellow of FSFE

Website: http://jak-linux.org/   XMPP: juli...@jabber.org
Debian:  http://www.debian.org/  SPI:  http://www.spi-inc.org/
Ubuntu:  http://www.ubuntu.com/  FSFE: http://www.fsfe.org/



signature.asc
Description: Digital signature

Bug#511899: ITP: coinor-csdp -- A software package for semidefinite programming

[Soeren Sonnenburg]

Package: wnpp
Severity: wishlist
Owner: Soeren Sonnenburg 

* Package name: coinor-csdp
  Version : 6.0.1
  Upstream Author : Brian Borchers 
* URL : https://projects.coin-or.org/Csdp
* License : CPL
  Programming Lang: C
  Description : A software package for semidefinite programming

 CSDP is a library of routines that implements a predictor corrector variant of
 the semidefinite programming algorithm of Helmberg, Rendl, Vanderbei, and
 Wolkowicz. The code runs in parallel on shared memory multi-processor systems,
 and it makes effective use of sparsity in the constraint matrices.
 .
 CSDP is part of the larger COIN-OR initiative (Computational Infrastructure
 for Operations Research).
 .
 This package contains the binaries and libraries.


-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#509685: ITP: hardlink -- Hardlink multiple copies of the same file

[Andrew Vaughan]

On Fri, 26 Dec 2008, John Goerzen wrote:
> Julian Andres Klode wrote:
> >  Hardlink is a tool which detects multiple copies of the same file and
> > replaces them with hardlinks.
> >  .
> >  The idea has been taken from http://code.google.com/p/hardlinkpy/, but
> > the code has been written from scratch and licensed under the MIT
> > license.
>
> Do we really need another tool like this?
>
> We already have these packages:
>
>   fdupes
>   perforate
>
Hi John

I think that's a little harsh.  There are lots of apps in Debian that 
provide similar functionality to other apps in Debian.  I do agree that iff 
hardlink is only duplicating functionality available in finddup, then there 
is no point in maintaining both.  

I wasn't aware of finddup before this thread.  Since faster-dupemerge [0]  
breaks with the upgrade to lenny I thought I'd give finddup a try.  However 
finddup is too limited for my use case.

My home server stores dirvish (think rsync --link-dest) backups for 2 other 
machines that dual boot windows and linux.  Each partition is backed up 
separately, with the windows partitions having separate backups from both 
windows and linux.  In addition the linux partitions sometimes contain  
chroots , and the Windows partitions have games installed, then copied to a 
different dir and modded.  That means there is a lot of duplicate files 
that rsync --link-dest doesn't hardlink.  Hardlinking files afterwards 
enables me to get over 1 TB of used disk space X 60 days onto a single 1 TB 
disk.

Finddup assumes that the file list will fit in memory.  This is a 
showstopper for me.  Attempting to run finddup on my home server over a 
partial backup set of a single day (1,898,219 files) resulted in 
unacceptable memory usage (739MB after 4 hours on a machine with 512MB 
physical ram.  This resulted in swap usage of over 600MB, and a 30 sec ssh 
login time).  

Findup lacks an option to require matching timestamps before hardlinking.  
This discards info that can be useful in a backup, and results in rsync 
thinking that the files have changed, and retransmitting them anyway.

Finddup's syntax for specifying directories to link is clumsy when what I 
really want to link is /srv/dirvish/*/2009.01.1*/tree.  

In addition faster-dupemerge's ability to pass options to find means that I 
can do a quick partial run by limiting find to files large than 1MB, 
something that is often enough to recover 10+ GB after installing a couple 
of games.

Cheers 
Andrew V.

[0] http://www.furryterror.org/~zblaxell/projects/dupemerge/dupemerge.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#509685: ITP: hardlink -- Hardlink multiple copies of the same file

[Didier Raboud]

Andrew Vaughan wrote:

> On Fri, 26 Dec 2008, John Goerzen wrote:
>> Julian Andres Klode wrote:
>> >  Hardlink is a tool which detects multiple copies of the same file and
>> > replaces them with hardlinks.
>> >  .
>> >  The idea has been taken from http://code.google.com/p/hardlinkpy/, but
>> > the code has been written from scratch and licensed under the MIT
>> > license.
>>
>> Do we really need another tool like this?
>>
>> We already have these packages:
>>
>>   fdupes
>>   perforate
>>
> Hi John
> 
> I think that's a little harsh.  There are lots of apps in Debian that
> provide similar functionality to other apps in Debian.  I do agree that
> iff hardlink is only duplicating functionality available in finddup, then
> there is no point in maintaining both.
>
> (...)
> 
> Andrew V.

Note that hardlink just hit Sid.

-- 
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Arch:all package depending on package that isn't Arch:any

[Adeodato Simó]

* Julian Andres Klode [Thu, 15 Jan 2009 15:07:55 +0100]:

Hello, Julian.

> This would be my other proposal, also known as Bug#436733:
>   Package: acpi-support-base
>   Architecture: all
>   Depends: acpid [i386 amd64]

> But in order to be correct, currently apt and co. do not support this.
> Therefore, this could only be used in Squeeze+1 as well.

> Summary
> 

> 2. The one we discussed above.
>  This is not backward compatible, but provides the most functionality
>  of all proposals. And it can also be used to have an architecture
>  independent packages depend on different packages (in case there is a
>  package a on the one arch, and a package b on the other arch, but the
>  package supports both); without half-broken dependencies.

Well...

>  The disadvantage is that the packages still appear in the Packages
>  files, without being of use on the architecture. They may even
>  contain broken symlinks, etc.

This disadvantage is not a disadvantage, but a sign that this proposal
of yours is solving a *different* problem.

What you want is arch-specific Dependencies to work for arch:all
packages. That *is* a worthwile goal IMHO, but a different one. And it's
indeed not backwards compatible, and requires changes in the
dpkg/apt/... toolchain.

What Neil and me are interested is in not letting uninstallable arch:all
packages tricle into the Packages files. (He wants it to make the
archive from Embdebian smaller; I may want it because it may improve
user experience.)

Do you see that? If so, let's continue. (If not, here's a further hint:
how does option #2 differentiate between "arch:all pkg1 can't work on
i386 and amd64 without pkg x, but is fine elsewhere without it" vs
"arch:all pkg2 depends on z, and can't function without it, but z is
only available on on i386 and amd64").

> 4. An external location
>  This is backward compatible too. The problem with this proposal is
>  that it puts to a small group of people (if it would be implemented
>  like some stuff we have already). Programs creating repositories
>  would need to be changed to accept such a file.

Programs creating repositories will need to be changed *no matter what
approach you take*, since the idea is precisely to modify their
behavior. They may have to be modified to grok "Architecture: all [i386
amd64]", or Install-Architecture, or a file.

(This is also why, btw, I don't get Neil's wish for a "generic
solution". Every solution is going to need modifications everywhere one
wants it implemented.)

But I already said in my other mail that a P-a-s like approach may not
be the best option, given the size of the problem. (Neil, I'm surprised
you haven't meet "P-a-s": 
http://buildd.debian.org/quinn-diff/Packages-arch-specific.)

Still, I don't agree with your final bits of reasoning:

> If we want to do it in a better way, we should choose option 1 or 2.
> Even if we want something different, option 2 would still be good to
> implement, because it makes life easier and gives
> architecture-independent packages the same flexibility like
> architecture-dependent ones.

(As said above, option #2 solves an orthogonal problem.)

> Option 4 is not really a good idea, as the data should be contained in
> the packages themselves, so people do not install a package not meant
> for their architecture.

What you are suggesting here is that apt and dpkg should refuse to
install an arch:all package if its control field says it's not supported
in that architecture. And I say that's bollocks^Wnot a reasonable thing
to do.

An arch:all package should be installable anywhere where its
dependencies can be satisfied. And if they can't be satisfied, dpkg/apt
will refuse to install it already.

No, the only use for "Architecture: all [i386 amd64]" or
"Install-Architecture: i368 amd64" would be as a hint to dak (and other
tools) that the package is known not to be installable anywhere else,
and hence should not be put in other Packages.gz files. That's *all*
that matters AIUI.

> The best seems to be a combination of 1 and 2, giving a lot of
> flexibility. If we want something which we could start using with
> Squeeze, we should choose option 3.

#2 is orthogonal, and I see no benefits of #1 over #3, given my
reasoning above that dpkg/apt have nothing to do with it (hence you'd be
adding support in them for something they are not going to use).

But I'm still very unconvinced that debian/control is the right place to
put this information. And ftpmaster should be involved in this
discussion anyway, and more people as well.

P.S.: May I ask, that lines in your mails don't get much longer than 72
characters? TIA.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Listening to: Radiohead - House Of Cards


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm

Re: Arch:all package depending on package that isn't Arch:any

[Matthew Johnson]

On Thu Jan 15 17:49, Adeodato Simó wrote:

> An arch:all package should be installable anywhere where its
> dependencies can be satisfied. And if they can't be satisfied, dpkg/apt
> will refuse to install it already.
> 
> No, the only use for "Architecture: all [i386 amd64]" or
> "Install-Architecture: i368 amd64" would be as a hint to dak (and other
> tools) that the package is known not to be installable anywhere else,
> and hence should not be put in other Packages.gz files. That's *all*
> that matters AIUI.

Can't dak work that out itself? (assuming that we are only considering
archives which are meant to be self-contained).

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Bug#509685: ITP: hardlink -- Hardlink multiple copies of the same file

[Sandro Tosi]

On Thu, Jan 15, 2009 at 15:10, Andrew Vaughan  wrote:
> On Fri, 26 Dec 2008, John Goerzen wrote:
>> Julian Andres Klode wrote:
>> >  Hardlink is a tool which detects multiple copies of the same file and
>> > replaces them with hardlinks.
>> >  .
>> >  The idea has been taken from http://code.google.com/p/hardlinkpy/, but
>> > the code has been written from scratch and licensed under the MIT
>> > license.
>>
>> Do we really need another tool like this?
>>
>> We already have these packages:
>>
>>   fdupes
>>   perforate
>>
> Hi John
>
> I think that's a little harsh.  There are lots of apps in Debian that
> provide similar functionality to other apps in Debian.  I do agree that iff
> hardlink is only duplicating functionality available in finddup, then there
> is no point in maintaining both.

are you mapping "finddup" (and all other way you call it in this
email) to "fdupes"? If so, read on, if not, drop.

> Finddup assumes that the file list will fit in memory.  This is a
> showstopper for me.  Attempting to run finddup on my home server over a
> partial backup set of a single day (1,898,219 files) resulted in
> unacceptable memory usage (739MB after 4 hours on a machine with 512MB
> physical ram.  This resulted in swap usage of over 600MB, and a 30 sec ssh
> login time).

Do you have a better algorithm to achieve the same task without having
in memory the whole file list? if yes, write a patch and make fdupes a
better tool. Only complaining is not an option.

> Findup lacks an option to require matching timestamps before hardlinking.
> This discards info that can be useful in a backup, and results in rsync
> thinking that the files have changed, and retransmitting them anyway.

Patches are welcome.

> Finddup's syntax for specifying directories to link is clumsy when what I
> really want to link is /srv/dirvish/*/2009.01.1*/tree.

If you know how to make it nicer, write a patch and send it.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#511924: ITP: php-gtk -- PHP-GTK is an extension for the PHP programming language that implements language bindings for GTK+. It provides an object-oriented interface to GTK+ classes and functions

[Atir Javid]

Package: wnpp
Severity: wishlist
Owner: Atir Javid 


  Package name: php-gtk
  Version : 2.0.1
  Upstream Author : php-gtk
  URL : http://gtk.php.net/
  License : (GPL)
  Programming Lang: (PHP, GTK+)
  Description : PHP-GTK is an extension for the PHP programming language 
that implements language bindings for GTK+. 
PHP-Gtk provides an object-oriented interface to GTK+ classes and functions and 
greatly simplifies writing client-side cross-platform GUI applications.  
PHP-GTK is not meant to be used in the Web environment. It is intended for 
creation of standalone applications (run via command-line, user's desktop, 
etc.).

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Arch:all package depending on package that isn't Arch:any

[Adeodato Simó]

* Matthew Johnson [Thu, 15 Jan 2009 17:21:03 +]:

> > No, the only use for "Architecture: all [i386 amd64]" or
> > "Install-Architecture: i368 amd64" would be as a hint to dak (and other
> > tools) that the package is known not to be installable anywhere else,
> > and hence should not be put in other Packages.gz files. That's *all*
> > that matters AIUI.

> Can't dak work that out itself? (assuming that we are only considering
> archives which are meant to be self-contained).

No. Not without becoming britney or edos-debcheck, or receiving input
from them.

Which is a reason for using an external source: you can have it
dd-writable, and see how that goes (equivalent to having it in
debian/control); you can have it maintained by several people, and see
how that goes; or you can have edos-debcheck/britney generate the list,
and see how that goes.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
To be nobody but yourself in a world which is doing its best night and
day to make you like everybody else means to fight the hardest battle
any human being can fight and never stop fighting.
-- e.e. cummings


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: merkel fs issues

[Joerg Jaspert]

>> > Umh... This might be the cause, then. Our mirror sync has died three
>> > days in a row - At 16:37, 15:49 and 17:36 (GMT-6):
>> From where are you pulling?
> syncproxy.wna.debian.org

Completly different machine, so not the cause for your trouble.

-- 
bye, Joerg
Linus: "Wenn Darl McBride die Macht hätte, würde er wahrscheinlich die
Ehe als Verletzung der Verfassung auslegen, weil sie ganz klar die
kommerzielle Natur der menschlichen Interaktion entwertet und damit ein
großes Hindernis für die kommerzielle Entwicklung der Prostitution darstellt."


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#511937: ITP: usbip -- USB device sharing system over IP network

[Max Vozeler]

Package: wnpp
Severity: wishlist
Owner: Max Vozeler 

* Package name: usbip
  Version : 0.1.7
  Upstream Author : Takahiro Hirofuchi
* URL : http://usbip.sourceforge.net/
* License : GPL2+
  Programming Lang: C
  Description : USB device sharing system over IP network

 USB/IP can share USB devices over the network. It encapsulates 
 "USB requests" into IP packets and transmits them between computers.
 Original USB device drivers and applications can be used for 
 remote USB devices without any modification of them.  A computer
 can use remote USB devices as if they were directly attached;



signature.asc
Description: Digital signature

Bug#511938: RFP: netlogo -- logo interpreter with several turtles

[Nick Shaforostoff]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---
please package it, if the license is ok for you.

   Package name: netlogo
Version: 
Upstream Author: [NAME ]
URL: [http://ccl.northwestern.edu/]
License: [GPL, LGPL, BSD, MIT/X, etc.]
Description: [NetLogo is a cross-platform multi-agent programmable modeling 
environment.]




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Arch:all package depending on package that isn't Arch:any

[Neil Williams]

On Thu, 15 Jan 2009 17:49:33 +0100
Adeodato Simó  wrote:

(Please drop me from CC: where possible, -devel is fine for me.
Keeping Julian in CC - not sure if he's subscribed to -devel but I'm
confident you are, Adeodato.)

> * Julian Andres Klode [Thu, 15 Jan 2009 15:07:55 +0100]:
> 
> > 4. An external location
> >  This is backward compatible too. The problem with this proposal is
> >  that it puts to a small group of people (if it would be implemented
> >  like some stuff we have already). Programs creating repositories
> >  would need to be changed to accept such a file.
> 
> Programs creating repositories will need to be changed *no matter what
> approach you take*, since the idea is precisely to modify their
> behavior. They may have to be modified to grok "Architecture: all [i386
> amd64]", or Install-Architecture, or a file.

True.

> (This is also why, btw, I don't get Neil's wish for a "generic
> solution". Every solution is going to need modifications everywhere one
> wants it implemented.)

Maybe - but if Debian decides on a standard method for how the solution
must work, (and/or the results it must achieve), then each tool is free
to implement the solution internally as suits the codebase. All I want
is that standard - something that says that all tools need to behave in
a particular manner or have support for acting in that manner. In that
sense, the solution (the standard) is generic but each implementation
varies without breaking compatibility.
 
> But I already said in my other mail that a P-a-s like approach may not
> be the best option, given the size of the problem. (Neil, I'm surprised
> you haven't meet "P-a-s": 
> http://buildd.debian.org/quinn-diff/Packages-arch-specific.)

I wasn't aware of that. Interesting. Is it documented somewhere in the
Developer Reference etc. or linked from the Developer's Corner on
www.debian.org ?

> An arch:all package should be installable anywhere where its
> dependencies can be satisfied. And if they can't be satisfied, dpkg/apt
> will refuse to install it already.

That is the problem I would like to solve - I don't want any packages
in the Packages.gz file that cannot be installed. As noted by Adeodato,
this involves tools like edos-debcheck.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpFFbpNHpWkF.pgp
Description: PGP signature

percentage of popcon submitters

[markus schnalke]

Hoi,

I know it is not possible to _know_ the real percentage of uses which
submit popcon stats of all users. But I want to ask for guesses,
because more oppinions do likely improve the result.

My current guess is between 1/3 and 2/3.

What do you think?


meillo


signature.asc
Description: Digital signature

Re: percentage of popcon submitters

[Michael Goetze]

Hi,


I know it is not possible to _know_ the real percentage of uses which
submit popcon stats of all users. But I want to ask for guesses,
because more oppinions do likely improve the result.

My current guess is between 1/3 and 2/3.

What do you think?


before wild speculations ensues, you might want to specify what you 
really want to know: the percentage of people installing debian systems 
who use popcon (always/sometimes), or the percentage of installed 
machines that submit popcon data?


For example, I'm pretty sure any hosting company offering Debian on 
dedicated servers will disable popcon by default...


Regards,
Michael


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: percentage of popcon submitters

[markus schnalke]

[2009-01-15 22:37] Michael Goetze 
> 
> before wild speculations ensues, you might want to specify what you 
> really want to know: the percentage of people installing debian systems 
> who use popcon (always/sometimes), or the percentage of installed 
> machines that submit popcon data?

Seems my wording was unclear.

I want to know the percentage of installed machines that submit popcon
data.


Maybe some words about the background of this question:
I want to estimate the number of users of some software. Thus I have a
look at Popcon which tells me the number of installations of the
package. Now I need a good multiplicator (the searched one) to receive
an estimated number of users within Debian. I'll do the same for
Ubuntu's popcon and add guessed numbers for usage on other GNU and
Unix systems. That should lead to a quite good estimation.


> For example, I'm pretty sure any hosting company offering Debian on 
> dedicated servers will disable popcon by default...

And there is a number of systems without online connection, they will
also not submit.


meillo


signature.asc
Description: Digital signature

Re: percentage of popcon submitters

[James Vega]

On Thu, Jan 15, 2009 at 4:55 PM, markus schnalke  wrote:
> [2009-01-15 22:37] Michael Goetze 
>>
>> before wild speculations ensues, you might want to specify what you
>> really want to know: the percentage of people installing debian systems
>> who use popcon (always/sometimes), or the percentage of installed
>> machines that submit popcon data?
>
> Seems my wording was unclear.
>
> I want to know the percentage of installed machines that submit popcon
> data.

That requires knowing the number of computers that have Debian installed
which, as has been discussed various times in the past on this list, is
difficult to determine.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: percentage of popcon submitters

[Michael Goetze]

James Vega wrote:

On Thu, Jan 15, 2009 at 4:55 PM, markus schnalke  wrote:

I want to know the percentage of installed machines that submit popcon
data.


That requires knowing the number of computers that have Debian installed
which, as has been discussed various times in the past on this list, is
difficult to determine.


And even then it might not help answer your question, for instance if 
you have a desktop application the percentage of popcon submitters might 
be higher than average among your users, whereas if you have some 
software mainly useful on classified military machines, the percentage 
of popcon submitters might be lower than average among your users.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: percentage of popcon submitters

[Patrick Matthäi]

Michael Goetze schrieb:
> Hi,
> 
>> I know it is not possible to _know_ the real percentage of uses which
>> submit popcon stats of all users. But I want to ask for guesses,
>> because more oppinions do likely improve the result.
>>
>> My current guess is between 1/3 and 2/3.
>>
>> What do you think?
> 
> before wild speculations ensues, you might want to specify what you
> really want to know: the percentage of people installing debian systems
> who use popcon (always/sometimes), or the percentage of installed
> machines that submit popcon data?
> 
> For example, I'm pretty sure any hosting company offering Debian on
> dedicated servers will disable popcon by default...
> 

Hello,

for myself I deactivated popcon on every machine.
Then I first installed and activated it on every server and some times
later also on my desktop.

For my case I do not think that it will be realy deactivated on
dedicated servers in most cases.
But yeah, it may differ from person to person :)


-- 
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi

E-Mail: patrick.matth...@web.de

Comment:
Always if we think we are right,
we were maybe wrong.
*/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: percentage of popcon submitters

[Luciano Bello]

El Jue 15 Ene 2009, markus schnalke escribió:
> My current guess is between 1/3 and 2/3.

that means that there is between 78055/(1/3)=234165 and 78055/(2/3)=117,082 of 
Debian installations. It doesn't look like a big number... I think that we are 
more.

Maybe your estimation is too high.

luciano


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: percentage of popcon submitters

[Bernd Eckenfels]

In article <20090115210004.gv21...@serveme.schnalke.local> you wrote:
> My current guess is between 1/3 and 2/3.

Machines or Users?

According to Linuxcounter there are estimated 29,000,000 users and debian has
18.36% which equals in 5m  debian users. Popcon lists 78k submissions,
which is less than 2%

Gruss
Bernd


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: percentage of popcon submitters

[Russ Allbery]

markus schnalke  writes:

> I know it is not possible to _know_ the real percentage of uses which
> submit popcon stats of all users. But I want to ask for guesses, because
> more oppinions do likely improve the result.
>
> My current guess is between 1/3 and 2/3.
>
> What do you think?

We run Debian or Ubuntu on around 500 machines and only submit popcon
results from about four of them.

It's hard to talk institutional computer security departments into the
idea that the minor risk of the information released by popcon (what
packages on your servers are missing security patches, basically) is worth
it for just the warm fuzzy feelings of contributing.  I suspect that
popcon is not running on most large institutional Debian installations.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

ITP: mbrola-{de6,es1,fr4,us1,us2} -- various voices for Mbrola

[Samuel Thibault]

Hello,

Here is a list of ITPs for various mbrola voices.

Samuel

Bug#511973 ITP: mbrola-de6 -- German male voice for Mbrola

Package: wnpp
Version: N/A; reported 2008-01-15
Severity: wishlist

* Package name: mbrola-de6
  Version : 0.0.20021125-1
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : German male voice for Mbrola
 This package contains a Germal diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 DE6 is a male German diphone voice created in the context of the EU project
 NECA (IST-2000-28580), with the aim of being particularly suitable for the
 flexible synthesis of expressive speech.
 .
 The main feature of DE6 is therefore that it contains a complete diphone 
 set for three different voice qualities defined by their vocal effort, low
 effort ("soft voice"), medium effort ("normal or modal voice"), and high
 effort ("loud voice").
 .
 This diphone database was recorded jointly by the Institute of Phonetics at
 Saarland University and by the Language Technology Department at DFKI,
 Saarbrücken.

Bug#511974: ITP: mbrola-es1 -- Spanish male voice for Mbrola

Package: wnpp
Version: N/A; reported 2008-01-15
Severity: wishlist

* Package name: mbrola-es1
  Version : 0.0.19980610-1
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Spanish male voice for Mbrola
 This package contains a Spanish diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Spanish male voice to be used with the MBROLA program.
 .
 Input files use the SAMPA (SAM Phonetic Alphabet) notation as
 recommended by the EEC-SAM Project, but with some minor changes.

Bug#511975: ITP: mbrola-fr4 -- French female voice for Mbrola

Package: wnpp
Version: N/A; reported 2008-01-15
Severity: wishlist

* Package name: mbrola-fr4
  Version : 0.0.19990521-1
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : French female voice for Mbrola
 This package contains a French diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a French female voice to be used with the MBROLA program.
 .
 Input files use the SAMPA (SAM Phonetic Alphabet) notation as
 recommended by the EEC-SAM Project. 

Bug#511976: ITP: mbrola-us1 -- American English female voice for Mbrola

Package: wnpp
Version: N/A; reported 2008-01-15
Severity: wishlist

* Package name: mbrola-us1
  Version : 0.3-1
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : American English female voice for Mbrola
 This package contains an English diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides an American English female voice to be used with the MBROLA
 program.

Bug#511977: ITP: mbrola-us2 -- American English male voice for Mbrola

Package: wnpp
Version: N/A; reported 2008-01-15
Severity: wishlist

* Package name: mbrola-us2
  Version : 0.1-1
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : American English male voice for Mbrola
 This package contains an English diphone database provided in t

Re: percentage of popcon submitters

[Romain Beauxis]

Le Thursday 15 January 2009 23:25:02 Bernd Eckenfels, vous avez écrit :
> In article <20090115210004.gv21...@serveme.schnalke.local> you wrote:
> > My current guess is between 1/3 and 2/3.
>
> Machines or Users?
>
> According to Linuxcounter there are estimated 29,000,000 users and debian
> has 18.36% which equals in 5m  debian users. Popcon lists 78k submissions,
> which is less than 2%

Thanks. Unless you setup some experimental method, any argument should reduce 
to handwaving or extension of various particular examples..

The big question (and the big troll) that's hidden behind this question is the 
total amount of installed debian systems.

Since this value is always and always discussed, I don't think there is any 
broadly accepted counting method, hence I don't think the original question 
can be answered...

Or, if you really want to troll, let's switch to the total amount of installed 
debian systems, since this is equivalent, but the de^C^Cbattle should be more 
fun... :-)


Romain


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#511980: ITP: Plumi -- Plumi is a Free Software video sharing Content Management System based on Plone.

[Andy Nicholson]

Package: wnpp
Severity: wishlist
Owner: Andy Nicholson 

* Package name: Plumi
  Version : 0.2.3
  Upstream Author : Andy Nicholson 
* URL : http://plumi.org/
* License : GPL
  Programming Lang: Python
  Description : Plumi is a Free Software video sharing Content Management 
System based on Plone.

Plumi is a Free Software video sharing Content Management System based on Plone 
and produced by 
the EngageMedia collective. Plumi enables you to create your own sophisticated 
video sharing site; 
by adding it to an existing Plone instance you can quickly have a wide array of 
functionality to 
facilitate video distribution and community creation.

In a net landscape where almost all video sharing sites keep their distribution 
platform under 
lock and key, Plumi is one contribution to creating a truly democratic media.

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



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#511981: ITP: liboggplay -- A library for playing OGG multimedia

[John Ferlito]

Package: wnpp
Severity: wishlist
Owner: John Ferlito 

* Package name: liboggplay
  Version : 0.0.2~svn3836
  Upstream Author : Shane Stephens (shans) 
  Upstream Author : Conrad Parker (kfish) 
* URL : http://annodex.net/software/liboggplay/index.html
* License : (see below)
  Programming Lang: C
  Description : A library for playing OGG multimedia

 A library designed to allow drop-in playback of Xiph.Org media in an
 application. liboggplay handles demuxing and decoding, generates timestamps for
 raw data, maintains synchronisation across multiple streams, and provides a
 lock-free buffer implementation for easy multithreading.

Copyright from the file COPYING in the source tarball:

   Copyright (C) 2003 CSIRO Australia

   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions
   are met:

   - Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.

   - Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.

   - Neither the name of the CSIRO nor the names of its
   contributors may be used to endorse or promote products derived from
   this software without specific prior written permission.

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
   ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
   PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE ORGANISATION OR
   CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
   EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
   PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
   PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
   LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
   NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
   SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

-- 
John
Bloghttp://www.inodes.org/blog
OLPC Friends http://olpcfriends.org




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

ITH: libotf Debian packages

[Harshula]

Hi,

I would like to update and maintain the libotf[1] Debian packages. I am
already maintaining the related m17n Debian packages[2].

The libotf (0.9.4) packages have been neglected by the current
maintainer for nearly 3 years. Upstream[3] have regularly released
updates. I'm also in regular contact with the upstream developers.

Already, there have been two bugs opened requesting the updating of the
Debian version[4][5]. There has been no response.

cya,
#

[1] http://packages.qa.debian.org/libo/libotf.html
[2] http://qa.debian.org/developer.php?login=harsh...@gmail.com
[3] http://www.m17n.org/libotf/
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466815
[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476625


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#511986: ITP: libkate -- Kate is a codec for karaoke and text encapsulation for Ogg

[John Ferlito]

Package: wnpp
Severity: wishlist
Owner: John Ferlito 

* Package name: libkate
  Version : 0.3.0
  Upstream Author : Vincent Penquerc'h 
* URL : http://code.google.com/p/libkate/
* License : New BSD License
  Programming Lang: C
  Description : Kate is a codec for karaoke and text encapsulation for Ogg

Kate is meant to be used for karaoke alongside audio/video streams (typically
Vorbis and Theora), movie subtitles, song lyrics, and anything that needs text
data at arbitrary time intervals.

-- 
John
Bloghttp://www.inodes.org/blog
OLPC Friends http://olpcfriends.org




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#511994: ITP: pacman-package-manager -- minimalist package manager using tarballs and scripts

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock 

* Package name: pacman-package-manager
  Version : 3.2.2
  Upstream Author : Judd Vinet 
* URL : http://www.archlinux.org/pacman
* License : GPL
  Programming Lang: C
  Description : minimalist package manager using tarballs and scripts
 Pacman is a package manager typically used by ArchLinux and similar
 distributions. It features a simple design which is easy for packagers
 to create functional packages with, and utilizes a simple tarball-based
 package format.
 .
 Using Pacman directly will bypass the Debian packaging system, and
 therefore is not recommended. The recommended use of this package is
 for bootstraping ArchLinux chroots.

This package is being packaged to facilitate support for ArchLinux and other
pacman-using distributions as ApplianceKit guests (for both vserver and xen
installations).

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



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#511997: ITP: libdownload -- library for downloading files from HTTP/FTP

[William Pitcock]

Package: wnpp
Severity: wishlist
Owner: William Pitcock 

* Package name: libdownload
  Version : 1.3
  Upstream Author : Aaron Griffin 
* URL : http://www.archlinux.org/pacman
* License : BSD
  Programming Lang: C
  Description : library for downloading files from HTTP/FTP
 Libdownload is a library for downloading files from HTTP/FTP servers.
 It is a fork of libfetch, used by FreeBSD and others, and supports a
 very simple interface for downloading files into memory buffers and
 file descriptors. Changes from libfetch include modification to improve
 portability, and proper use of select(2) timeouts.

This is being packaged because it is a dependency of pacman-package-manager
(see #511994).

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



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#511980: ITP: Plumi -- Plumi is a Free Software video sharing Content Management System based on Plone.

[William Pitcock]

On Fri, 2009-01-16 at 11:22 +1100, Andy Nicholson wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Andy Nicholson 
> 
> * Package name: Plumi

Package names need to be lowercase.

>   Version : 0.2.3
>   Upstream Author : Andy Nicholson 
> * URL : http://plumi.org/
> * License : GPL
>   Programming Lang: Python
>   Description : Plumi is a Free Software video sharing Content Management 
> System based on Plone.

The short description should be lowercase, also placing "free software"
here is redundant, as the Section: header will tell you if it is free or
not (foo vs non-free/foo).

The short description should not be a complete sentence.

Something like "video sharing CMS based on Plone" would be sufficient
here.

> 
> Plumi is a Free Software video sharing Content Management System based on 
> Plone and produced by 
> the EngageMedia collective. Plumi enables you to create your own 
> sophisticated video sharing site; 
> by adding it to an existing Plone instance you can quickly have a wide array 
> of functionality to 
> facilitate video distribution and community creation.

Please make sure your description is wrapped to 80 characters.

> 
> In a net landscape where almost all video sharing sites keep their 
> distribution platform under 
> lock and key, Plumi is one contribution to creating a truly democratic media.

The second paragraph does not add anything to the package description;
you should consider removing it.

William


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

Re: percentage of popcon submitters

[Noah Slater]

On Thu, Jan 15, 2009 at 10:00:04PM +0100, markus schnalke wrote:
> I know it is not possible to _know_ the real percentage of uses which
> submit popcon stats of all users. But I want to ask for guesses,
> because more oppinions do likely improve the result.

   This question of trying to figure out whether a book is good or bad by
  looking at it carefully or by taking the reports of a lot of people who
  looked at it carelessly is like this famous old problem: Nobody was
  permitted to see the Emperor of China, and the question was, What is the
  length of the Emperor of China's nose? To find out, you go all over the
  country asking people what they think the length of the Emperor of China's
  nose is, and you average it. And that would be very "accurate" because you
  averaged so many people. But it's no way to find anything out; when you have
  a very wide range of people who contribute without looking carefully at it,
  you don't improve your knowledge of the situation by averaging.

   -- Richard P. Feynman, Surely You're Joking, Mr. Feynman!

-- 
Noah Slater, http://tumbolia.org/nslater


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#511986: ITP: libkate -- Kate is a codec for karaoke and text encapsulation for Ogg

[Sune Vuorela]

On Friday 16 January 2009 03:00:38 John Ferlito wrote:
> Package: wnpp
> Severity: wishlist
> Owner: John Ferlito 
>
> * Package name: libkate
>   Version : 0.3.0
>   Upstream Author : Vincent Penquerc'h 
> * URL : http://code.google.com/p/libkate/
> * License : New BSD License
>   Programming Lang: C
>   Description : Kate is a codec for karaoke and text encapsulation for
> Ogg
>
> Kate is meant to be used for karaoke alongside audio/video streams
> (typically Vorbis and Theora), movie subtitles, song lyrics, and anything
> that needs text data at arbitrary time intervals.

Hi!

Please note that Kate is also a editor using kde libs and already ships some 
files called libkate* (Currently at least libkateinterfaces, libkateutils, 
libkatepartinterfaces )

I wonder if "libkate" is a name too close to this.

/Sune
-- 
How may I do for exploring the memory?

You either should cancel the software, or have to boot the ISA forward, so 
that you can never receive a port 8 of the coaxial POPmail head to a forward 
to log from the RW cable to a 59X DVD device.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Work-needing packages report for Jan 16, 2009

[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: 460 (new: 2)
Total number of packages offered up for adoption: 109 (new: 2)
Total number of packages requested help for: 47 (new: 0)

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



The following packages have been orphaned:

   ffcall (#511445), orphaned 5 days ago
 Description: Foreign Function Call Libraries
 Reverse Depends: clisp clisp-dev freemat gnustep-base-runtime
   libffcall1-dev libgnustep-base1.16 libmlpcap-ocaml
   libmlpcap-ocaml-dev xindy
 Installations reported by Popcon: 2605

   libpam-pwgen (#511613), orphaned 3 days ago
 Description: a password generator
 Installations reported by Popcon: 98

458 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:

   lprng (#511461), offered 4 days ago
 Description: lpr/lpd printer spooling system
 Reverse Depends: gpr lsb-core mseide rhinote xprintmon
 Installations reported by Popcon: 1084

   twiki-ldapcontrib (#511333), offered 6 days ago
 Description: LDAP services for TWiki
 Installations reported by Popcon: 2

107 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:

   apache2 (#470795), requested 308 days ago
 Description: Co-maintainer wanted
 Reverse Depends: ampache apache2 apache2-dbg apache2-mpm-event
   apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker
   apache2-prefork-dev apache2-suexec apache2-suexec-custom (153 more
   omitted)
 Installations reported by Popcon: 40187

   ara (#450876), requested 431 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 130

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

   bash-completion (#472468), requested 297 days ago
 Description: programmable completion for the bash shell
 Installations reported by Popcon: 20279

   boinc (#511243), requested 7 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc-app-seti boinc-dbg
 Installations reported by Popcon: 1497

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

   dctrl-tools (#448284), requested 446 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies dlocate haskell-devscripts
   hg-buildpackage ia32-archive ia32-libs-tools mlmmj sbuild simple-cdd
 Installations reported by Popcon: 9682

   dpkg (#282283), requested 1517 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   backuppc build-essential bzr-builddeb cacao-oj6-dbg cacao-oj6-jdk
   (118 more omitted)
 Installations reported by Popcon: 78528

   drscheme (#402589), requested 766 days ago
 Description: PLT scheme programming environment
 Reverse Depends: drscheme minlog proofgeneral-minlog
 Installations reported by Popcon: 333

   elvis (#432298), requested 556 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 381

   fglrx-driver (#454993), requested 404 days ago (non-free)
 Description: non-free AMD/ATI r5xx, r6xx display driver
 Reverse Depends: fglrx-amdcccle fglrx-atieventsd fglrx-control
   fglrx-driver fglrx-glx fglrx-glx-ia32 fglrx-kernel-src
 Installations reported by Popcon: 2135

   flightgear (#487388), requested 208 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 943

   gentoo (#422498), requested 620 days ago
 Description: a fully GUI-configurable, two-pane X file manager
 Installations reported by Popcon: 251

   gnat-4.3 (#475374), requested 280 days ago
 Description: help needed to execute test cases
 Reverse Depends: adabrowse adacontrol asis-programs ghdl gnade-bin
   gnat gnat-4.3 gnat-gps libadasockets-dev libahven13 (46 more
   omitted)
 Instal

Re: percentage of popcon submitters

[markus schnalke]

[2009-01-16 05:59] Noah Slater 
> On Thu, Jan 15, 2009 at 10:00:04PM +0100, markus schnalke wrote:
> > I know it is not possible to _know_ the real percentage of uses which
> > submit popcon stats of all users. But I want to ask for guesses,
> > because more oppinions do likely improve the result.
> 
>This question of trying to figure out whether a book is good or bad by
>   looking at it carefully or by taking the reports of a lot of people who
>   looked at it carelessly is like this famous old problem: Nobody was
>   permitted to see the Emperor of China, and the question was, What is the
>   length of the Emperor of China's nose? To find out, you go all over the
>   country asking people what they think the length of the Emperor of China's
>   nose is, and you average it. And that would be very "accurate" because you
>   averaged so many people. But it's no way to find anything out; when you have
>   a very wide range of people who contribute without looking carefully at it,
>   you don't improve your knowledge of the situation by averaging.
> 
>-- Richard P. Feynman, Surely You're Joking, Mr. 
> Feynman!

Good point, but one may refer to the Delphi method:
http://en.wikipedia.org/wiki/Delphi_method

However, the answers I received actually helped my. Not because they
were estimations, but because they were comments for what to keep in
mind.

In any way, I believe more oppinions do improve results, but not by
telling numbers one can average, but by showing how others see the
situation. This widens the own view.


meillo


signature.asc
Description: Digital signature

Re: percentage of popcon submitters

[markus schnalke]

[2009-01-15 23:25] Bernd Eckenfels 
> In article <20090115210004.gv21...@serveme.schnalke.local> you wrote:
> > My current guess is between 1/3 and 2/3.
> 
> Machines or Users?

Popcon focuses on machines. In the end I want users. But any number
would be good.


> According to Linuxcounter there are estimated 29,000,000 users and debian has
> 18.36% which equals in 5m  debian users. Popcon lists 78k submissions,
> which is less than 2%

That is really a good approach. Thanks for that!

I seems to be quite sure that the popcon submitters are less than 1/3
of all Debian users.

Luciano Bello's calculation pointed to a similar way.


meillo


signature.asc
Description: Digital signature

Re: percentage of popcon submitters

[Kjeldgaard Morten]

Thanks. Unless you setup some experimental method, any argument  
should reduce

to handwaving or extension of various particular examples..


Surely, it must be possible to get an estimate of the number of  
downloads of important packages and security updates? I know these  
downloads also are requested from mirror sites, but at least for the  
official mirror sites their relative activity must be known?


Cheers,
Morten

--
Morten Kjeldgaard 
Ubuntu MOTU Developer
GPG Key ID: 404825E7


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org