Bug#490907: ITP: openturns -- Open source initiative to Treat Uncertainties, Risks?N Statistics

[Christophe Prud'homme]

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

--- Please fill out the fields below. ---

   Package name: openturns
Version: 0.12.0
Upstream Author: 
  - Électricité de France (EDF), the main electricity generation and
   distribution company in France;  
  - European Aeronautic Defence and Space company (EADS), a large European 
aerospace corporation, 
  - Phimeca, an Engineering Consultancy company specialised in Structural 
Reliability analysis.
URL: http://trac.openturns.org/
License: LGPL
Description: 

OpenTURNS is an Open source initiative to Treat Uncertainties, Risks’N 
Statistics in a structured industrial approach. 
Since the beginning of 2005, a partnership of three companies has been working 
on building together a tool designed to perform uncertainty treatment and 
reliability analyses.

OpenTURNS is a Unix/Linux software with three main components : 

 - a scientific C++ library including an internal data model and algorithms 
dedicated to the treatment of uncertainties. The main function of that library 
is giving to specific applications all the functionalities needed to treat 
uncertainties in studies. Targeted users are all engineers who want to 
introduce the probabilistic dimension in their so far deterministic studies. 

 - an independent application with a graphical user interface. This 
application 
was built to become the work environment for the specialist of the treatment 
of uncertainties. Targeted users are once again industrial practitioners: 
those who identify the treatment of uncertainties as a full task, which can be 
spread to multiple engineering domains. 

- a python module with high level operators in the probabilistic and 
statistical 
field. The interest of this language is to be both a powerful scientific 
language (capable of using C++ libraries), and a user friendly interpreted 
language like Matlab(tm) one. This python module was designed to make the 
development of prototypes easier (in order to test new algorithms and methods 
for example), to become an easy-to-use support for educational works, … This 
module intends to become a natural environment capable of integrating new 
developments within the field of uncertainty and sensitivity analysis. The 
targeted users are here research centres and the academic community.

-- 
Debian Developer
Annecy - Grenoble
Scientific computing related software




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

Re: Changes detected by lintian on rebuilt packages

[Steve Langasek]

On Sun, Jul 13, 2008 at 09:53:30PM +0200, Lucas Nussbaum wrote:
> On 12/07/08 at 18:50 -0500, Raphael Geissert wrote:
> > Because some packages FTBFS, there are some missing build logs[3], and
> > because there are some manpage warnings that are/not found either on
> > lintian.d.o's results or the archive rebuild's results I can't even
> > estimate the number of affected packages.

> > [3] At least aboot's is missing, already notified Lucas.

> aboot is listed in Packages-arch-specific[1] as being for alpha only, so
> I'm not trying to build it.

The binary is listed in P-a-s.  The source package builds multiple binaries,
including some on archs other than alpha.

So your parsing of P-a-s does not match that used by wanna-build, which
understands this and successfully passes aboot to the autobuilders.

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


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

Re: Help: Strange 64bit issue

[Goswin von Brederlow]

Andreas Tille <[EMAIL PROTECTED]> writes:

> On Fri, 11 Jul 2008, Manuel Prinz wrote:
>
>> With these fixes it still did not build on my system. I needed to change
>> the Build-Depends on lib64z1-dev into zlib1g-dev to get it to build in a
>> clean pbuilder chroot.
>
> Well, I guess that lib64z1-dev will not exist for amd64 and that this
> whole mess is just caused by the multiarch stuff.  It's the first time
> that I have to deal with this and I have the impression that I try to
> add just problems with no real profit for the user of the program.
> Probably I should just exclude the -m64 switch when building for i386
> and everything will work fine.

Actually you sort of must. You can build two packages, one foo
and one foo-amd64 or libfoo and lib64foo if that is worth it. The
program should be available for pure 32bit systems in Debian i386 and
the 64bit flavour would be a bonus for those that run a 64bit kernel.

So think about it. Will a 64bit binary have any benefits that warants
the extra complexity of building and maintaining biarch packaging?

> BTW, how could I specify arch dependant Build-Depends (in case some
> hint might reveal a multiarch solution)?

Build-Depends: gcc-multilib, zlib1g-dev, lib64z1-dev [i386], ...

>> I cannot reproduce this on my amd64 machine. With the change mentioned
>> above it builds fine and I'm able to run /usr/bin/maq on both lenny and
>> sid. Some output:
>
> I expect this in 64bit machines - but Charles had problems on hie PowerPC
> as well ...

ldd runs the ld.so to get the libraries. That is bascially equivalent
to executing the binary and needs the full cpu and kernel support for
the binary format. So if you have a 32bit kernel you won't be able to
ldd a 64bit binary. Doesn't matter if it is amd64, sparc64, ppc64, ...

> Kind regards
>
> Andreas.

MfG
Goswin


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

Re: [Pkg-xen-devel] Xen status in lenny?

[Goswin von Brederlow]

Bastian Blank <[EMAIL PROTECTED]> writes:

> On Thu, Jul 10, 2008 at 09:53:25PM +0200, Lucas Nussbaum wrote:
>> What are the plans for Xen for lenny? Is this situation likely to change
>> before the release?
>
> It will ship the hypervisor and a domU kernel. For dom0 it will need
> either the etch or my own[1] kernel. This may be changed later if we can
> get a new kernel in the stable release.
>
> Bastian
>
> [1]:
> deb http://kernel-archive.buildserver.net/debian-kernel/waldi/xen-extra all 
> main

Could I suggest adding a linux-2.6.18 package to lenny that builds a
dom0 kernel?

Otherwise lenny XEN support would be limited to the lifetime of
old-stable unless a point release adds a xen dom0 kernel image later
on.

MfG
Goswin


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

Re: [Pkg-xen-devel] Xen status in lenny?

[Lucas Nussbaum]

On 12/07/08 at 19:39 -0700, Steve Langasek wrote:
> On Sun, Jul 13, 2008 at 12:10:28AM +0200, Lucas Nussbaum wrote:
> > We (Debian) should make a clear statement that users of Debian as dom0
> > will have at least one supported configuration at any time during the
> > lenny lifetime.
> 
> What I don't see you saying is that *you* are volunteering to step up and
> help provide security support for this kernel.  So it's "we" when we're
> making a statement, but it's still "they" who would have to provide the
> actual support, AFAICS.

How/if we will support Xen in lenny is more a policy decision than a
technical decision, even if it has important technical aspects.

Even if it's not optimal, I agree with do-ocracy for technical
decisions. However, using it for everything is dangerous. Instead, I
prefer to:
1/ understand the situation
2/ determine the possible solutions
3/ determine the best solutions, given external constraints (inc.
   manpower)
4/ try to find someone to do the work

Throwing "you are not going to do the work anyway, so you are
irrelevant" at everybody is not helpful at all, and just adds noise to
the discussion, because we are still between stages 2 and 3 here.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: Changes detected by lintian on rebuilt packages

[Lucas Nussbaum]

On 15/07/08 at 10:33 +0100, Steve Langasek wrote:
> On Sun, Jul 13, 2008 at 09:53:30PM +0200, Lucas Nussbaum wrote:
> > On 12/07/08 at 18:50 -0500, Raphael Geissert wrote:
> > > Because some packages FTBFS, there are some missing build logs[3], and
> > > because there are some manpage warnings that are/not found either on
> > > lintian.d.o's results or the archive rebuild's results I can't even
> > > estimate the number of affected packages.
> 
> > > [3] At least aboot's is missing, already notified Lucas.
> 
> > aboot is listed in Packages-arch-specific[1] as being for alpha only, so
> > I'm not trying to build it.
> 
> The binary is listed in P-a-s.  The source package builds multiple binaries,
> including some on archs other than alpha.
> 
> So your parsing of P-a-s does not match that used by wanna-build, which
> understands this and successfully passes aboot to the autobuilders.

Right, should be fixed now.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: [Pkg-xen-devel] Xen status in lenny?

[Thijs Kinkhorst]

On Tuesday 15 July 2008 13:08, Lucas Nussbaum wrote:
> How/if we will support Xen in lenny is more a policy decision than a
> technical decision, even if it has important technical aspects.
>
> Even if it's not optimal, I agree with do-ocracy for technical
> decisions. However, using it for everything is dangerous. Instead, I
> prefer to:
> 1/ understand the situation
> 2/ determine the possible solutions
> 3/ determine the best solutions, given external constraints (inc.
>manpower)
> 4/ try to find someone to do the work
>
> Throwing "you are not going to do the work anyway, so you are
> irrelevant" at everybody is not helpful at all, and just adds noise to
> the discussion, because we are still between stages 2 and 3 here.

I find it a pity that your mail doesn't contain any argumentation for your 
postulations. For a start, I don't think it's obvious that this is a policy 
decision, nor that a "do-ocracy is dangerous" in a general sense.

Xen is just one solution to virtualisation. I may agree that a general 
decision to support virtualisation on Debian could be a policy decision, but 
whether we'll support one specific technology, for which there are many 
alternatives, is very much a technical decision. Does it work, can we get it 
to work and do we have the people to keep it work after release?


Thijs


pgpauYcU0XOCG.pgp
Description: PGP signature

Re: [Pkg-xen-devel] Xen status in lenny?

[Lucas Nussbaum]

On 15/07/08 at 14:01 +0200, Thijs Kinkhorst wrote:
> Xen is just one solution to virtualisation. I may agree that a general 
> decision to support virtualisation on Debian could be a policy decision, but 
> whether we'll support one specific technology, for which there are many 
> alternatives, is very much a technical decision. Does it work, can we get it 
> to work and do we have the people to keep it work after release?

Debian supported Xen in etch. Which of the "many alternatives" should
Debian recommend to its users currently running a Debian dom0 in
paravirt mode?

I don't think that any of the alternatives are valid candidates yet:
- Linux-Vserver, OpenVZ: clearly not the same use case.
- Virtualbox, qemu: poor performance under some workloads.
- KVM: is very promising but is it really a valid alternative *now*
  for current Xen users?

This might change in a few months, of course, but in a few months lenny
will be released. ;-)
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: [Pkg-xen-devel] Xen status in lenny?

[Pasi Kärkkäinen]

On Tue, Jul 15, 2008 at 01:08:23PM +0200, Lucas Nussbaum wrote:
> On 12/07/08 at 19:39 -0700, Steve Langasek wrote:
> > On Sun, Jul 13, 2008 at 12:10:28AM +0200, Lucas Nussbaum wrote:
> > > We (Debian) should make a clear statement that users of Debian as dom0
> > > will have at least one supported configuration at any time during the
> > > lenny lifetime.
> > 
> > What I don't see you saying is that *you* are volunteering to step up and
> > help provide security support for this kernel.  So it's "we" when we're
> > making a statement, but it's still "they" who would have to provide the
> > actual support, AFAICS.
> 
> How/if we will support Xen in lenny is more a policy decision than a
> technical decision, even if it has important technical aspects.
> 
> Even if it's not optimal, I agree with do-ocracy for technical
> decisions. However, using it for everything is dangerous. Instead, I
> prefer to:
> 1/ understand the situation
> 2/ determine the possible solutions
> 3/ determine the best solutions, given external constraints (inc.
>manpower)
> 4/ try to find someone to do the work
> 
> Throwing "you are not going to do the work anyway, so you are
> irrelevant" at everybody is not helpful at all, and just adds noise to
> the discussion, because we are still between stages 2 and 3 here.

The situation is pretty much like this:

- Upstream vendor (Xensource) only develops 2.6.18 Xen dom0/domU kernel atm.

- paravirt_ops (pv_ops) Xen support in vanilla (v2.6.24+) Linux kernels is 
currently
  domU only. Also it's 32bit PAE only, no 64bit yet. Other features are
  missing too (compared to xensource 2.6.18 xen kernel).

- Xen kernel features from 2.6.18 are being ported and added slowly to 2.6.2x
  pv_ops kernels but it takes time and effort to get them ported and accepted 
  upstream (by linus). Currently Jeremy Fitzhardinge (from Xensource) is doing 
  this work. I think currently he's working on getting 64bit domU support 
ready/integrated.

- Redhat/Fedora has done some pv_ops xen dom0 support work, but it's not
  ready yet and it hasn't had much progress lately.. unfortunately.

- 2.6.22 and 2.6.24 (non pv_ops) kernels with forward ported patches from 
2.6.18 
  are a real pain for kernel maintainers.. 

- Fedora decided to drop dom0 xen kernel for Fedora 9. Fedora 9 only ships
  with xen pv_ops domU kernel. They're planning to add dom0 support back for 
  Fedora 10 if/when (pv_ops) dom0 support is included in the upstream 
  vanilla (linus) kernel. 

Some links:

http://wiki.xensource.com/xenwiki/XenParavirtOps
http://fedoraproject.org/wiki/Features/XenPvopsDom0

-- Pasi


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

Re: Xen status in lenny?

[Bastian Blank]

On Thu, Jul 10, 2008 at 09:53:25PM +0200, Lucas Nussbaum wrote:
> What are the plans for Xen for lenny? Is this situation likely to change
> before the release?

As we have seen, there is no real plan. So lets summarize the
possibilities:

Option 1: Use alternatives
==
Well, I don't know any real alternative.

There are some other virtualization techniques, but the decision which
one may be usable needs an evaluation of the actual usecase.

Option 2: Stick to Etch
===
Ask the users to stick to Etch until we can get a kernel into Lenny
which supports this type of operation. 

Contra:
- No new software for Xen users.
- May hit the end of the security support for Etch.
Needed work: Documentation.

Option 3: Lenny with Etch kernel

Ask the users to use the old Etch kernel with a Lenny userland.

Pro:
- New software.
Contra:
- May hit the end of the security support for Etch.
Needed work: Some documentation how to do this.

Option 4: 2.6.18 kernel in Lenny, until Lenny+1/2
=
Push a (Xen-only) 2.6.18 kernel into Lenny. Either with the Etch or
preferably a newer Xen patch. This kernel will be supported until
Lenny+1/2 hopefully pushs a kernel with the necessary support into the
stable release, but at most until the Lenny+1 release. It may be
possible that this will also need a Xen update to work with the new
kernels.

Pro:
- New software.
- Full support for the beginning.
Contra:
- We have to overwrite the decision to support only one Linux kernel in
  a stable release.
- Dropping support of a package during the lifetime of a stable release
  was always a last resort solution. So this needs a fat warning in the
  release notes.[1]
Needed work for kernel/security team[2]:
- Until end of Etch support: Push the same update in oldstable-security
  and stable-security.
- After end of Etch support: Continue the support for this old kernel.
  Lets hope that this will not take too long.
Needed work for other teams: Documentation.

Option 5: 2.6.18 kernel in Lenny

Push a (Xen-only) 2.6.18 kernel into Lenny. Either with the Etch or
preferably a newer Xen patch. This kernel will be supported until the
normal end of the normal support.

Pro:
- New software.
- Full support.
Contra:
- We have to overwrite the decision to support only one Linux kernel in
  a stable release.
Needed work for kernel/security team:
- Until end of Etch support: Push the same update in oldstable-security
  and stable-security.
- After end of Etch support: Continue the support for this old kernel.

For further, not applicable options, see
http://fedoraproject.org/wiki/Features/XenPvops.

Conclusion
==
Xen got a often used technique in the last two years. All of the large
distributions got some sort of support for it. Debian Etch have full
support for it. There was several requests of various people so I think
not providing at least a minimal support in Lenny is wrong.

I think option 4 would be the solution which produces the least amount
of extra work and provides our users with support for there systems. I
would provide the necessary packages but I want an okay for that
solution from the security and the release team.

Bastian, with his kernel and Xen hat on

[1]: Maybe it would be possible to replace the not-longer supported
packages with a critical warning in preinst. This package would never
allow themself to be configured.
[2]: Kernel security support is mostly done by Dann Frazier, who does it
as member of the kernel team.
-- 
Is truth not truth for all?
-- Natira, "For the World is Hollow and I have Touched
   the Sky", stardate 5476.4.


signature.asc
Description: Digital signature

Bug#490949: ITP: libpetal-utils-perl -- Useful template modifiers for Petal

[Damyan Ivanov]

Package: wnpp
Severity: wishlist
Owner: Damyan Ivanov <[EMAIL PROTECTED]>

* Package name: libpetal-utils-perl
  Version : 0.06
  Upstream Author : William McKee <[EMAIL PROTECTED]>
Steve Purkis <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Petal-Utils/
* License : same as Perl (GPL-1+|Artistic)
  Programming Lang: Perl
  Description : Useful template modifiers for Petal

The Petal::Utils package contains commonly used Petal modifiers (or
plugins), and bundles them with an easy-to-use installation interface.
By default, a set of modifiers are installed into Petal when you use
this module.

The module is needed by a new upstream release of
libtest-tap-htmlmatrix-perl and will be maintained under the umbrella of
the Debian Perl Group.



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

Re: [Pkg-xen-devel] Xen status in lenny?

[John Goerzen]

Lucas Nussbaum wrote:
> On 15/07/08 at 14:01 +0200, Thijs Kinkhorst wrote:
> - KVM: is very promising but is it really a valid alternative *now*
>   for current Xen users?

That is an interesting question.  We are doing some research on that
topic right now.  I've migrated some VMware and xen stuff on my own
workstation to KVM, with highly encouraging results.  That is, of
course, different than a server situation, but a data point nonetheless.

We have been happy with Xen in principle, but there have been enough
strange things happen over the past year or two that we're not entirely
comfortable with it anymore.  These things include the hypervisor
crashing on creation or removal of a domU, strange kernel oops in domUs,
and severe brokenness of pciback.

It should be noted that KVM does not include PCI backend support, though
with the degree of brokenness of it in Xen, that may not be an issue.
Also, KVM requires hardware virtualization support, which Xen does not.
 So it is not entirely a drop-in replacement.

The fact that Xensource is supporting 2.6.18 only, and that work on KVM
is integrated into the kernel upstream, is a strong argument to us for
converting to KVM.  Unless something changes drastically with Xen's
kernel support, I can't see us doing anything but KVM long term.

-- John


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

Re: [Pkg-xen-devel] Xen status in lenny?

[Pasi Kärkkäinen]

On Tue, Jul 15, 2008 at 02:54:09PM +0200, Lucas Nussbaum wrote:
> On 15/07/08 at 14:01 +0200, Thijs Kinkhorst wrote:
> > Xen is just one solution to virtualisation. I may agree that a general 
> > decision to support virtualisation on Debian could be a policy decision, 
> > but 
> > whether we'll support one specific technology, for which there are many 
> > alternatives, is very much a technical decision. Does it work, can we get 
> > it 
> > to work and do we have the people to keep it work after release?
> 
> Debian supported Xen in etch. Which of the "many alternatives" should
> Debian recommend to its users currently running a Debian dom0 in
> paravirt mode?
> 
> I don't think that any of the alternatives are valid candidates yet:
> - Linux-Vserver, OpenVZ: clearly not the same use case.
> - Virtualbox, qemu: poor performance under some workloads.
> - KVM: is very promising but is it really a valid alternative *now*
>   for current Xen users?
> 

One big difference between Xen and KVM is the fact that KVM always requires 
hardware virtualization (HVM) support from the CPU. 

Xen doesn't need that for paravirt guests (linux). 

Xen still is the most feature rich hypervisor.. that might change some day,
of course.

The biggest advantage of KVM is that it's included in vanilla kernel.. 

Hopefully Jeremy Fitzhardinge (from Xensource) and others can get the
important Xen kernel features ported to pv_ops framework and integrated 
into vanilla linus kernels soon.. 

Status/todo:
http://wiki.xensource.com/xenwiki/XenParavirtOps

Redhat/Fedora pv_ops Xen kernel dom0 support status:
http://fedoraproject.org/wiki/Features/XenPvopsDom0

-- Pasi


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

Bug#490953: ITP: lua-base64 -- base64 library for the lua language

[Enrico Tassi]

Package: wnpp
Severity: wishlist
Owner: Enrico Tassi <[EMAIL PROTECTED]>


* Package name: lua-base64
  Version : 1.0
  Upstream Author : Luiz Henrique de Figueiredo
* URL : http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/#lbase64
* License : Public Domain
  Programming Lang: C
  Description : base64 library for the lua language


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

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

-- 
Enrico Tassi



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

Re: [Pkg-xen-devel] Xen status in lenny?

[Bastian Blank]

On Tue, Jul 15, 2008 at 05:22:55PM +0300, Pasi Kärkkäinen wrote:
> One big difference between Xen and KVM is the fact that KVM always requires 
> hardware virtualization (HVM) support from the CPU. 

It uses the the qemu device emulation code, which is security wise one
large catastrophe. Okay, Xen uses it also for full virtualized guests,
which is the reason why I currently discurage anyone from using it.
However this will change in the near future.

> The biggest advantage of KVM is that it's included in vanilla kernel.. 

Sure. This is the confession that small patchsets are much more likely
to be accepted than large ones. Xen started long time ago and they drag
a huge patch through the last years without the perspective to get
anything in without much rework.

> Hopefully Jeremy Fitzhardinge (from Xensource) and others can get the
> important Xen kernel features ported to pv_ops framework and integrated 
> into vanilla linus kernels soon.. 

Yep.

Bastian

-- 
Witch!  Witch!  They'll burn ya!
-- Hag, "Tomorrow is Yesterday", stardate unknown


signature.asc
Description: Digital signature

Re: Bug#490857: ITP: watermelons -- watermelon bouncing game

[unifoundry]

> Date: Tue, 15 Jul 2008 14:56:47 +0800
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Bug#490857: ITP: watermelons -- watermelon bouncing game
> CC: debian-devel@lists.debian.org
> 
> On Tue, Jul 15, 2008 at 3:43 AM, Peter De Wachter <[EMAIL PROTECTED]> wrote:
> 
> > * URL : http://www.imitationpickles.org/melons/index.html
> 
> Source code contains a duplicated non-free font (HURRYUP.TTF from
> ttf-larabie-straight).
> 
The font might be duplicated, but I checked its licensing information
and it is free.  (I thought maybe if it were a simple font I could make
one up for the game.)  Here is the text information that the TrueType
font Hurryup.ttf contains:

===

Created by: Ray Larabie

Creation Year: 2004

Copyright: © 1998 Ray Larabie. This font is freeware. Read attached
text file for details. Info & updates visit www.larabiefonts.com.
Donations gratefully accepted at www.larabiefonts.com/donation.html.
Also visit my commercial type foundry at www.typodermic.com. This font
was updated in 2004.

Notice/Description: accents added in 2004. Larabie Fonts is able to
offer unique free fonts through the generous support of visitors to the
site. Making fonts is my full-time job and every donation, in any
amount, enables me to continue running the site and creating new fonts.
If you would like to support Larabie Fonts visit www.larabiefonts.com
for details.

===

This appears at http://www.larabiefonts.com/help.html -- "Embedding
Larabie Fonts in any format is free of charge and you don't need our
permission for embedding them in your software."  The site does state
that the use granted for his TrueType fonts don't apply to OpenType
fonts.  It could be that the font collection is non-free (I don't have
the package at hand) -- he does mention that he didn't create all the
fonts in his massive collection.

He says he'll accept donations, but states that the font is freeware
(not shareware).


Paul Hardy
[EMAIL PROTECTED]




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

Re: Bug#490857: ITP: watermelons -- watermelon bouncing game

[Evgeni Golov]

On Tue, 15 Jul 2008 08:05:21 -0700 [EMAIL PROTECTED] wrote:

> 
> > Date: Tue, 15 Jul 2008 14:56:47 +0800
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: Re: Bug#490857: ITP: watermelons -- watermelon bouncing game
> > CC: debian-devel@lists.debian.org
> > 
> > On Tue, Jul 15, 2008 at 3:43 AM, Peter De Wachter <[EMAIL PROTECTED]> wrote:
> > 
> > > * URL : http://www.imitationpickles.org/melons/index.html
> > 
> > Source code contains a duplicated non-free font (HURRYUP.TTF from
> > ttf-larabie-straight).
> > 
> The font might be duplicated, but I checked its licensing information
> and it is free.  (I thought maybe if it were a simple font I could make
> one up for the game.)  Here is the text information that the TrueType
> font Hurryup.ttf contains:
> 
> ===
> 
> Created by: Ray Larabie
> 
> Creation Year: 2004
> 
> Copyright: © 1998 Ray Larabie. This font is freeware. Read attached
> text file for details. Info & updates visit www.larabiefonts.com.
> Donations gratefully accepted at www.larabiefonts.com/donation.html.
> Also visit my commercial type foundry at www.typodermic.com. This font
> was updated in 2004.
> 
> Notice/Description: accents added in 2004. Larabie Fonts is able to
> offer unique free fonts through the generous support of visitors to the
> site. Making fonts is my full-time job and every donation, in any
> amount, enables me to continue running the site and creating new fonts.
> If you would like to support Larabie Fonts visit www.larabiefonts.com
> for details.
> 
> ===
> 
> This appears at http://www.larabiefonts.com/help.html -- "Embedding
> Larabie Fonts in any format is free of charge and you don't need our
> permission for embedding them in your software."  The site does state
> that the use granted for his TrueType fonts don't apply to OpenType
> fonts.  It could be that the font collection is non-free (I don't have
> the package at hand) -- he does mention that he didn't create all the
> fonts in his massive collection.
> 
> He says he'll accept donations, but states that the font is freeware
> (not shareware).

freeware is not DFSG-free, the same help page says:
Q: Your EULA (End User License Agreement) says I can’t alter your
fonts. Does that mean I can’t play with them in Photoshop, Illustrator
or Publisher?

A: Not at all. It means you can’t alter the font shape with software
like Fontographer or Fontlab. You are absolutely allowed to colour,
warp, texturize, link or bend the fonts to customize your artwork. In
fact, use the fonts creatively. That’s why I made them.

That violates DFSG §3 -> non-free

regards
Evgeni


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

Bug#490970: ITP: sunpinyin-slm -- Sunpinyin statistical language model training tools

[Kov Chai]

Package: wnpp
Severity: wishlist
Owner: Kov Chai <[EMAIL PROTECTED]>


* Package name: sunpinyin-slm
  Version : 1.0
  Upstream Author : Lei Zhang <[EMAIL PROTECTED]>
* URL : http://www.opensolaris.org/os/project/input-method
* License : LGPL/CDDL Dual license
  Programming Lang: C++
  Description : A statistical language model training tool suite

SunPinyin-SLM is suite of tools and necessary data file to train a
decent Chinese statistical language model.
.
With the tools provided by SunPinyin-SLM, user are allowed to train
their own language models and to segment raw corpus into words using
the provided lexicon. The language model can also used by sunpinyin 
input method engines.

Homepage: http://www.opensolaris.org/os/project/input-method

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

Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Policy restriction to depend on font packages

[Eugene V. Lyubimkin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi people.

Policy 11.8.5.1 says:

"If one or more of the fonts so packaged are
necessary for proper operation of the package with which they are
associated the font
package may be Recommended; if the fonts merely provide an
enhancement, a Suggests
relationship may be used. Packages must not Depend on font packages."

Annotation to this paragraph is :

"This is because the X server may retrieve fonts from the local file
system or over the network from an X font
server; the Debian package system is empowered to deal only with the
local file system."

Then I searched the Debian archive (in case of TrueType fonts):

$ grep-aptavail -F Depends "ttf-" -s Package | wc -l
93

$ grep-aptavail \( -F Recommends "ttf-" --or -F Suggests "ttf-" \)
- --and ! -F Depends "ttf-" -s Package | wc -l
101

So, there are 93 packages that violate "must" directive of policy.
Some of them: fontconfig-config, blender, openjdk-6-jre,
openoffice.org-core, vlc. And, as I understand, it leads to 93 bugs of
"serious" severity and yet another pain for release team.

Should I mass-file the bugs or this situation can be resolved through
different approach?

Regards,
- --
Eugene V. Lyubimkin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkh82RgACgkQchorMMFUmYymIQCgsQnmJ7pIIBJifTBebGYfx2QQ
8cgAnimYinZrpdlaIs12FkuEFVM0elrQ
=wG1l
-END PGP SIGNATURE-


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

Re: [Pkg-xen-devel] Xen status in lenny?

[Pasi Kärkkäinen]

On Tue, Jul 15, 2008 at 09:24:08AM -0500, John Goerzen wrote:
> Lucas Nussbaum wrote:
> > On 15/07/08 at 14:01 +0200, Thijs Kinkhorst wrote:
> > - KVM: is very promising but is it really a valid alternative *now*
> >   for current Xen users?
> 
> That is an interesting question.  We are doing some research on that
> topic right now.  I've migrated some VMware and xen stuff on my own
> workstation to KVM, with highly encouraging results.  That is, of
> course, different than a server situation, but a data point nonetheless.
> 
> We have been happy with Xen in principle, but there have been enough
> strange things happen over the past year or two that we're not entirely
> comfortable with it anymore.  These things include the hypervisor
> crashing on creation or removal of a domU, strange kernel oops in domUs,
> and severe brokenness of pciback.
> 
> It should be noted that KVM does not include PCI backend support, though
> with the degree of brokenness of it in Xen, that may not be an issue.
> Also, KVM requires hardware virtualization support, which Xen does not.
>  So it is not entirely a drop-in replacement.
> 
> The fact that Xensource is supporting 2.6.18 only, and that work on KVM
> is integrated into the kernel upstream, is a strong argument to us for
> converting to KVM.  Unless something changes drastically with Xen's
> kernel support, I can't see us doing anything but KVM long term.
> 

Xensource has a developer working on getting xen patches ported to Linux
pv_ops framework and integrated into upstream (vanilla) kernel.

Vanilla Linux v2.6.26 already contains 32bit (PAE) paravirtual domU support
with SMP, framebuffer, memory ballooning (contraction only) etc.. 

More features are being currently prepared for 2.6.27.. including 64bit domU
support, save/restore/migration etc.. 

Atm biggest (most important) missing feature from vanilla kernel is dom0 
support.. 

See: http://wiki.xensource.com/xenwiki/XenParavirtOps

So in short the situation is getting better slowly..

At the moment "full" Xen feature set is only available in xensource 2.6.18
kernel.

-- Pasi


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

Re: [Pkg-xen-devel] Xen status in lenny?

[John Goerzen]

Pasi Kärkkäinen wrote:
> On Tue, Jul 15, 2008 at 09:24:08AM -0500, John Goerzen wrote:

> 
> Xensource has a developer working on getting xen patches ported to Linux
> pv_ops framework and integrated into upstream (vanilla) kernel.

That is, to me, only mildly encouraging.  2.6.18 came out on Sept. 19,
2006, and there haven't been official Xen patches on anything else
since.  I don't know if that programmer hasn't been able to be very
productive, or if Xensource has just recently assigned someone to the
task.  But in any case, it does not speak well of the long-term
viability of Xen.

Not only that, but I like the KVM model of Linux as the hypervisor.  Xen
hypervisor is kinda finicky about hardware; I've had it refuse to boot
properly on Athlon64 machines for instance.

-- John


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

Re: Changes detected by lintian on rebuilt packages

[Raphael Geissert]

Thanks to everyone for their comments.

Thinking a little bit more, I believe writing some kind of report might be
of more use. Of course if I find something really relevant I might end up
filing a couple of bugs (I remember seeing something that looked like a
library name being changed in the rebuilt package).

Hope nobody will object if the report is sent in the next Misc Developer
News :).

Cheers,
Raphael



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

Re: Changes detected by lintian on rebuilt packages

[Raphael Geissert]

Lucas Nussbaum wrote:

> On 12/07/08 at 18:50 -0500, Raphael Geissert wrote:
>> Because some packages FTBFS, there are some missing build logs[3], and
>> because there are some manpage warnings that are/not found either on
>> lintian.d.o's results or the archive rebuild's results I can't even
>> estimate the number of affected packages.
>> 
>> [3] At least aboot's is missing, already notified Lucas.
> 
> aboot is listed in Packages-arch-specific[1] as being for alpha only, so
> I'm not trying to build it.
> 
> Some other packages might be missing, because:
> - they FTBFS

Yes, I noticed that and built a list of packages that FTBFS to ease the
examination of the results.

> - their build time out, so they are excluded from my rebuilds

Oh, good to know.

> - they are listed in P-a-s as not for i386

:)

Cheers,
Raphael


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

Re: Changes detected by lintian on rebuilt packages

[Julien Cristau]

On Tue, Jul 15, 2008 at 13:43:05 -0500, Raphael Geissert wrote:

> Hope nobody will object if the report is sent in the next Misc Developer
> News :).
> 
It doesn't need to be on -devel-announce.  Just send it here.

Cheers,
Julien


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

Re: Changes detected by lintian on rebuilt packages

[Raphael Geissert]

Russ Allbery wrote:

> Raphael Geissert <[EMAIL PROTECTED]> writes:
> 
>> Because some packages FTBFS, there are some missing build logs[3], and
>> because there are some manpage warnings that are/not found either on
>> lintian.d.o's results or the archive rebuild's results I can't even
>> estimate the number of affected packages.
> 
> Man page warnings unfortunately depend on the version of man that you have
> installed.  lintian.d.o's results therefore miss quite a few warnings,
> since lintian.d.o runs on stable and the man version there is too old to
> be able to meaningfully diagnose many problems.
> 

Why not backport the version in lenny and locally use it for lintian?
I don't mean replacing /usr/lib/man-db/man, but adding the dir where the
local backport is installed to $PATH.

Cheers,
Raphael


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

Re: [Pkg-xen-devel] Xen status in lenny?

[Pasi Kärkkäinen]

On Tue, Jul 15, 2008 at 12:49:07PM -0500, John Goerzen wrote:
> Pasi Kärkkäinen wrote:
> > On Tue, Jul 15, 2008 at 09:24:08AM -0500, John Goerzen wrote:
> 
> > 
> > Xensource has a developer working on getting xen patches ported to Linux
> > pv_ops framework and integrated into upstream (vanilla) kernel.
> 
> That is, to me, only mildly encouraging.  2.6.18 came out on Sept. 19,
> 2006, and there haven't been official Xen patches on anything else
> since.  I don't know if that programmer hasn't been able to be very
> productive, or if Xensource has just recently assigned someone to the
> task.  But in any case, it does not speak well of the long-term
> viability of Xen.
> 

Xensource is using 2.6.18 (RHEL5) in their own commercial product, so that's
why they're focusing xen kernel development on that version.. 

Xensource tried getting xen patches integrated into upstream linux earlier, 
but it didn't succeed (too big changes?) and kernel developers decided 
they need to create this common "pv_ops" framework for running paravirtual 
linux on hypervisors.. 

So that has taken some time.. and only recently (some) xen features have been 
ported to
this pv_ops framework and integrated into vanilla kernel.. more features are 
being ported.

So yeah.. atm the xen/dom0 kernel situation is a bit shitty.. 

pv_ops (VMI) paravirtual linux kernels are also supported by VMware. 

-- Pasi


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

sysklogd/rsyslog switch

[Joerg Jaspert]

Heya World,

I just did the requested switch, sysklogd/klogd are now priority extra,
rsyslog (not its -mysql -pgsql packages) are now priority important.

If something else, like Tasks or so, needs to be changed too: Whoever
needs to do that please do it. Thanks.

-- 
bye, Joerg
[ New Maintainer Prozess ]
 ein jahr ist ein bisschen zu optimistisch,
<_rene_> panthera: kommt auf den NM/AM an.
/* _rene_ ist pantheras AM und lässt sich mit pantheras 
   package check schon ein wenig Zeit ;) */


pgpzvZAUHfPfG.pgp
Description: PGP signature

Re: [Pkg-xen-devel] Xen status in lenny?

[Goswin von Brederlow]

Lucas Nussbaum <[EMAIL PROTECTED]> writes:

> On 15/07/08 at 14:01 +0200, Thijs Kinkhorst wrote:
>> Xen is just one solution to virtualisation. I may agree that a general 
>> decision to support virtualisation on Debian could be a policy decision, but 
>> whether we'll support one specific technology, for which there are many 
>> alternatives, is very much a technical decision. Does it work, can we get it 
>> to work and do we have the people to keep it work after release?
>
> Debian supported Xen in etch. Which of the "many alternatives" should
> Debian recommend to its users currently running a Debian dom0 in
> paravirt mode?

Isn't the policy decision in question here to only have one kernel
source in a release?

> I don't think that any of the alternatives are valid candidates yet:
> - Linux-Vserver, OpenVZ: clearly not the same use case.
> - Virtualbox, qemu: poor performance under some workloads.

Unusable for production work. Emulation is just too slow. The group of
people that can live with that much slow down compared to xen is
miniscule.

> - KVM: is very promising but is it really a valid alternative *now*
>   for current Xen users?

KVM needs hardware support and even then its I/O is slower. It also
deadlocks the I/O under I/O load from time to time.

I could live with the I/O slowdown but nothing will make hardware
magically appear.

> This might change in a few months, of course, but in a few months lenny
> will be released. ;-)


MfG
Goswin


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

Bug#490997: ITP: mayanna -- A fork of gimmie, an elegant desktop organizer

[Julian Andres Klode]

Package: wnpp
Severity: wishlist
Owner: Julian Andres Klode <[EMAIL PROTECTED]>

* Package name: mayanna
  Version : 0.2.8
  Upstream Author : Seif Lotfy <[EMAIL PROTECTED]> and others
* URL : http://code.google.com/p/mayanna/
* License : LGPL
  Programming Lang: Python
  Description : A fork of gimmie, an elegant desktop organizer

Please see the gimmie package for further information, as the
packaging will be almost the same.

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

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


pgpdTiMbIFu07.pgp
Description: PGP signature

Re: Policy restriction to depend on font packages

[Rene Engelhard]

Hi,

Eugene V. Lyubimkin wrote:
> Some of them: fontconfig-config, blender, openjdk-6-jre,
> openoffice.org-core, vlc. And, as I understand, it leads to 93 bugs of
> "serious" severity and yet another pain for release team.

ttf-opensymbol comes out of openoffice.org itself (easily checkable) and is
needed for basic operation. You won't get any bullet in OOos lists without it.

You don't really want that as a Recommends, do you?

> Should I mass-file the bugs or this situation can be resolved through
> different approach?

I'd first check why packages depend on font packages and where those
font packages come from...

Regards,

Rene


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

Re: Policy restriction to depend on font packages

[Petter Reinholdtsen]

[Eugene V. Lyubimkin]
> Should I mass-file the bugs or this situation can be resolved
> through different approach?

Your message was a bit short on exactly what problem you are trying to
solve.  How is the font dependency affecting users of the packages?  I
suspect fontconfig-config work on the fonts on disk, not the ones
available via the X server, and am thus unsure if the quoted policy
really is intended for the packages you talk about.

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: Policy restriction to depend on font packages

[Russ Allbery]

Rene Engelhard <[EMAIL PROTECTED]> writes:

> ttf-opensymbol comes out of openoffice.org itself (easily checkable) and
> is needed for basic operation. You won't get any bullet in OOos lists
> without it.

Even if you're running an X font server on a different host that is
providing that font?  Does that not work?  (I haven't tried to use one
since TTF fonts became possible, and don't know if it even works with
TTF.)

> You don't really want that as a Recommends, do you?

The reason for the Policy requirement for Recommends is to enable font
servers and not require all the fonts be installed locally when you're
running a font server.

It's possible that font servers are quaint bit of computer history that no
one cares about any more, though, in which case Policy should change.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Bug#491008: ITP: qutim -- new instant messenger written in C++ and Qt4

[Alexander Gerasiov]

Package: wnpp
Severity: wishlist
Owner: Alexander GQ Gerasiov <[EMAIL PROTECTED]>

* Package name: qutim
  Upstream Author : Rustam Chakin <[EMAIL PROTECTED]>
* URL : http://www.qutim.org/
* License : GPL v2 or later
  Programming Lang: C++
  Description : new instant messenger written in C++ and Qt4

qutIM - is new instant messenger. Project began at 2008 January and is
under development right now. Main goal is to create fast and user
friendly IM client for Linux OS.

- Tabbed and windowed messaging modes
- Fast and uses little memory
- Lots of smiles packs
- X-statuses
- Cross platform
- Open source
- Permanent development

-- System Information:
Debian Release: lenny/sid
  APT prefers testing-proposed-updates
  APT policy: (700, 'testing-proposed-updates'), (700, 'testing'), (670, 
'proposed-updates'), (670, 'stable'), (600, 'unstable'), (550, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/bash



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

Re: Policy restriction to depend on font packages

[Miriam Ruiz]

2008/7/15 Eugene V. Lyubimkin <[EMAIL PROTECTED]>:

> Then I searched the Debian archive (in case of TrueType fonts):
>
> $ grep-aptavail -F Depends "ttf-" -s Package | wc -l
> 93
>
> $ grep-aptavail \( -F Recommends "ttf-" --or -F Suggests "ttf-" \)
> - --and ! -F Depends "ttf-" -s Package | wc -l
> 101
>
> So, there are 93 packages that violate "must" directive of policy.
> Some of them: fontconfig-config, blender, openjdk-6-jre,
> openoffice.org-core, vlc. And, as I understand, it leads to 93 bugs of
> "serious" severity and yet another pain for release team.

Many games depend on ttf fonts being available, and they are a MUST
(without them, the game just won't work). Shall we remove the depend
on them and duplicate the fonts inside the game package?

Greetings,
Miry


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

Re: Policy restriction to depend on font packages

[Julien Cristau]

[dropping -release from Cc]

On Tue, Jul 15, 2008 at 15:11:44 -0700, Russ Allbery wrote:

> Rene Engelhard <[EMAIL PROTECTED]> writes:
> 
> > ttf-opensymbol comes out of openoffice.org itself (easily checkable) and
> > is needed for basic operation. You won't get any bullet in OOos lists
> > without it.
> 
> Even if you're running an X font server on a different host that is
> providing that font?  Does that not work?  (I haven't tried to use one
> since TTF fonts became possible, and don't know if it even works with
> TTF.)
> 
> > You don't really want that as a Recommends, do you?
> 
> The reason for the Policy requirement for Recommends is to enable font
> servers and not require all the fonts be installed locally when you're
> running a font server.
> 
> It's possible that font servers are quaint bit of computer history that no
> one cares about any more, though, in which case Policy should change.
> 
That section of policy is about "fonts for the X Window System", which a
footnote defines as fonts "accessed via X protocol requests" (a.k.a core
fonts, or server-side fonts).  Most apps nowadays use client-side fonts
(through Xft), not server-side fonts.

So policy 11.8.5 only talks about the xfonts-* packages, not the ttf-*
ones, at least as I understand it.

Cheers,
Julien


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

Re: Status of Emdebian {ARM}

[Loïc Minier]

On Tue, Jul 15, 2008, Neil Williams wrote:
> 1. gtk+2.0 fails to cross-build because the patches now try to build the
> udeb which comes up against a bug in dpkg-cross. I've uploaded the
> new version (including a couple of other bug fixes) today. (A late
> problem in apt-cross has delayed things slightly.) The Gtk package also
> needs some work to run /usr/lib/libgtk2.0-0/update-gdkpixbuf-loaders so
> that the icons can be read in the GUI.
> 
> 2. pango1.0 also needs a fix to update the pango modules. This is
> usually done at build time but it means running a cross-built binary. It
> is a minor task and not CPU intensive so I plan to do this in postinst.
> Without this fix, no text is rendered in the GUI, only empty glyphs.

 These used to be in the postinst, but were moved to build time as it
 caused issue for pango/gtk+ frontends during upgrades: if you're
 running a gtk+/pango debconf frontend, it needs these working at all
 times -- you can't allow it to break between unpack and new postinst's
 configure.

-- 
Loïc Minier


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

ITP: MUMPS -- MUltifrontal Massively Parallel sparse direct Solver

[Adam C Powell IV]

Package: wnpp
Severity: wishlist

Package name: mumps
Version: 4.7.3
Author: Patrick Amestoy et al.
License: public domain
URL: http://mumps.enseeiht.fr/
Description: MUltifrontal Massively Parallel sparse direct Solver

MUMPS implements a direct solver for large sparse linear systems, with a
particular focus on symmetric positive definite matrices.  It can
operate on distributed matrices e.g. over a cluster.  It has Fortran and
C interfaces, and can interface with ordering tools such as METIS.

Version 9.3 of Code_Aster (ITP 458812) uses MUMPS, so this package will
play a role in that packaging effort.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/



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

Bug#491025: ITP: biojava-live -- Java API to develop tools for bioinformatics research

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller <[EMAIL PROTECTED]>

* Package name: biojava-live
  Version : 1.6.0
* URL : http://www.biojava.org
* License : LGPL
  Programming Lang: Java
  Description : Java API to develop tools for bioinformatics research

 BioJava is an open-source project dedicated to providing a Java framework
 for processing biological data. It includes objects for manipulating
 sequences, file parsers, DAS client and server support, access to BioSQL
 and Ensembl databases, and powerful analysis and statistical routines
 including a dynamic programming toolkit.
 .
 BioJava is provided by a vibrant community which meets annually at
 the Bioinformatics Open Source Conference (BOSC) that traditionally
 accompanies the Intelligent Systems in Molecular Biology (ISMB)
 meeting. Much like BioPerl, the employment of this library is valuable
 for everybody active in the field because of the many tricks of the
 trade one learns just by communicating on the mailing list.



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

Re: [Pkg-xen-devel] Xen status in lenny?

[Ben Hutchings]

On Tue, Jul 15, 2008 at 05:22:55PM +0300, Pasi Kärkkäinen wrote:

> Hopefully Jeremy Fitzhardinge (from Xensource) and others can get the
> important Xen kernel features ported to pv_ops framework and integrated 
> into vanilla linus kernels soon.. 
> 
> Status/todo:
> http://wiki.xensource.com/xenwiki/XenParavirtOps
> 
> Redhat/Fedora pv_ops Xen kernel dom0 support status:
> http://fedoraproject.org/wiki/Features/XenPvopsDom0

SLES 11 will include Linux 2.6.26 with Xen patches - packages should be
available any day now from
.  Is it
possible that those patches will be usable in lenny, as I believe the
kernel team expects to release with Linux 2.6.26?

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth


signature.asc
Description: Digital signature