Re: Bug#696429: ITP: jhc -- a haskell compiler.

[Joachim Breitner]

Hi,

Am Freitag, den 21.12.2012, 08:21 +0900 schrieb Kiwamu Okabe:
> Jhs is useful for me, now.
> I am trying to rewrite NetBSD bootloader with Haskell.
> 
> [..]

Great, just checking :-)

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Getting Intel Cedarview drivers into Debian

[Mikko Rasa]

Hi Debian developers,

I'm working as a consultant on a project to develop drivers for the 
PowerVR graphics processor in the Cedarview family of Intel Atom 
microprocessors in a Debian environment.  The current target is Wheezy, 
and Intel wishes to get the drivers into the official distribution.


What they've failed to take into account is that Wheezy is currently 
frozen in preparation of release, so I'm more than a bit skeptical of 
getting a new package in (I was only brought in to the project very 
recently).  However, I promised to ask you about this, so here we go.


It should be noted that due to licensing issues, the driver will be 
closed source.  The kernel component is under the GPL, so a dkms package 
will be made.


There's also one kernel patch that needs to be applied to Wheezy's 
kernel for the driver to function.  The patch has been accepted to the 
mainline kernel, and my understanding is that it's included in the 3.7 
release[1].


On to questions:

1. Is there any possibility of getting the drivers in the initial Wheezy 
release?  If so, what needs to happen on our end?


2. What about a subsequent update to Wheezy?  I wasn't able to find 
information on what kinds of changes are permitted.


3. Neither us nor Intel has any Debian developers on our respective 
payrolls.  What's the best approach for maintaining the package?  Should 
someone from Intel become a maintainer, or are there some existing 
developers or maintainers that can take responsibility of the package 
after the initial work is complete?


[1] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=ac207ed2471150e06af0afc76e4becc701fa2733


--
Mikko Rasa "The DataBeaver"


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50d462bd.8080...@movial.com

Re: Getting Intel Cedarview drivers into Debian

[Cyril Brulebois]

Hello Mikko,

Mikko Rasa  (21/12/2012):
> It should be noted that due to licensing issues, the driver will be
> closed source.

I should note: lol.

> There's also one kernel patch that needs to be applied to Wheezy's
> kernel for the driver to function.  The patch has been accepted to
> the mainline kernel, and my understanding is that it's included in
> the 3.7 release[1].

You may ask kernel maintainers whether they want/will consider
backporting that patch (if it even makes sense) to 3.2; Ben will
probably answer this point, otherwise you can reach kernel maintainers
at .

> 1. Is there any possibility of getting the drivers in the initial
> Wheezy release?  If so, what needs to happen on our end?

No.

> 2. What about a subsequent update to Wheezy?  I wasn't able to find
> information on what kinds of changes are permitted.

No. What you could try to achieve is getting your packages into
unstable; if they are in a good shape, they may migrate to testing
once the freeze is lifted. From there, they become candidates for
wheezy-backports. More information on:
  http://backports.debian.org/

> 3. Neither us nor Intel has any Debian developers on our respective
> payrolls.  What's the best approach for maintaining the package?
> Should someone from Intel become a maintainer, or are there some
> existing developers or maintainers that can take responsibility of
> the package after the initial work is complete?

For a regular (meaning FLOSS) X driver you could ask X maintainers
(debia...@lists.debian.org), but you should note they are not
interested in non-free drivers. You may try your luck by asking
maintainers of those blobby/non-free fglrx or nvidia drivers.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Getting Intel Cedarview drivers into Debian

[Lisandro Damián Nicanor Pérez Meyer]

Note: this is my personal POV, this is not endorsed by anyone except me ;-)

On Fri 21 Dec 2012 10:23:09 Mikko Rasa escribió:
> Hi Debian developers,
[snip]
> On to questions:
> 
> 1. Is there any possibility of getting the drivers in the initial Wheezy
> release?  If so, what needs to happen on our end?

If I'm not mistaken, this should go to the Release Team [0].

[0] 

> 3. Neither us nor Intel has any Debian developers on our respective
> payrolls.  What's the best approach for maintaining the package?  Should
> someone from Intel become a maintainer, or are there some existing
> developers or maintainers that can take responsibility of the package
> after the initial work is complete?

- One of you becomes the maintainer and gets sponsored by a DD (you need to 
find a DD willing to do that, of course), commiting to maintain the package as 
any other maintainer does.
- You find a Debian Developer who's interested in maintaining the package.
- You pay a DD to do the job, which includes maintaining the package for as 
long as you want to keep it alive.

Kinds regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

[Thorsten Glaser]

Petter Reinholdtsen dixit:

>When using NSS modules linked to libraries in /usr/ and bash (or any
>other shell loading user information at startup) as /bin/sh, the shell
>scripts being run to shut down the machine will block /usr/ from being
>umounted.  When /usr/ is a LVM partition, this block LVM from being

That’s just another argument for using /bin/mksh-static as /bin/sh.
(It’s also faster than /bin/dash which is dynamically linked.)

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/pine.bsm.4.64l.1212211429210...@herc.mirbsd.org

Re: RFA: jabberd2 -- Jabber instant messenger server

[W. van den Akker]

 

sorry, mistyped the 'un' ;) 

On 21-12-2012 07:07, Michael Tokarev
wrote: 

> On 21.12.2012 02:29, Willem van den Akker wrote:
> 
>> Thanks
for getting new [udns] version into stable.
> 
> FWIW, it is not stable,
it is unstable. This version
> will not hit stable before wheezy is
released.
> 
> /mjt

 

Re: Math Fonts for Iceweasel and MathJax

[Ian Jackson]

Frédéric WANG writes ("Math Fonts for Iceweasel and MathJax"):
> Dear Debian maintainers,
> 
> I raised this issue about math font dependency in Iceweasel a couple of 
> time ago but I still don't see any changes at 
> http://packages.debian.org/sid/iceweasel... The issue was discussed 
> again on the LaTeXML mailing list, so I'm going to report it again.
> 
> Basically, Iceweasel must not depend on ttf-lyx, ttf-mathematica4.1, 
> xfonts-mathml or any other font packages that would lead to the 
> installation of Computer Modern fonts or Mathematica fonts. These old 
> fonts were used a long time ago in Gecko's MathML engine but now they 
> may give weird rendering bugs if they are still installed.

I think by looking at the dependencies you are targeting the wrong
part of the problem.  Rather than trying to arrange for these
troublesome fonts not to be installed, you should probably instead
arrange for the fontconfig configuration to prefer other fonts even
when the troublesome ones are present.

Otherwise people who happen to install those troublesome fonts for
other reasons will still find that things break.

Thanks,
Ian.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20692.32966.638455.472...@chiark.greenend.org.uk

Re: Math Fonts for Iceweasel and MathJax

[Ian Jackson]

Frédéric WANG writes ("Re: Math Fonts for Iceweasel and MathJax"):
> Sorry, what I said was not accurate. There will be rendering bugs if 
> these old fonts are installed AND the user still has some old 
> preferences for these fonts in about:config. However, the support for 
> these fonts has been totally removed in the most recent versions of 
> Iceweasel, so that should not happen any more. So removing these 
> suggestions (which has already been done) was really because they are 
> totally useless now. My main concern was to add suggestion for newer 
> fonts to improve the MathML rendering. I'll open a bug when the 
> MathJax's maintainer has uploaded his change.

Ah, OK.  Thanks for clarifying.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20692.33899.413908.127...@chiark.greenend.org.uk

Re: Math Fonts for Iceweasel and MathJax

[Frédéric WANG]

On 21/12/2012 16:31, Ian Jackson wrote:
I think by looking at the dependencies you are targeting the wrong 
part of the problem. Rather than trying to arrange for these 
troublesome fonts not to be installed, you should probably instead 
arrange for the fontconfig configuration to prefer other fonts even 
when the troublesome ones are present. Otherwise people who happen to 
install those troublesome fonts for other reasons will still find that 
things break. Thanks, Ian. 
Sorry, what I said was not accurate. There will be rendering bugs if 
these old fonts are installed AND the user still has some old 
preferences for these fonts in about:config. However, the support for 
these fonts has been totally removed in the most recent versions of 
Iceweasel, so that should not happen any more. So removing these 
suggestions (which has already been done) was really because they are 
totally useless now. My main concern was to add suggestion for newer 
fonts to improve the MathML rendering. I'll open a bug when the 
MathJax's maintainer has uploaded his change.


--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50d48450.5090...@free.fr

Re: Getting Intel Cedarview drivers into Debian

[Ben Hutchings]

On Fri, 2012-12-21 at 15:03 +0100, Cyril Brulebois wrote:
> Hello Mikko,
> 
> Mikko Rasa  (21/12/2012):
> > It should be noted that due to licensing issues, the driver will be
> > closed source.
> 
> I should note: lol.
> 
> > There's also one kernel patch that needs to be applied to Wheezy's
> > kernel for the driver to function.  The patch has been accepted to
> > the mainline kernel, and my understanding is that it's included in
> > the 3.7 release[1].
> 
> You may ask kernel maintainers whether they want/will consider
> backporting that patch (if it even makes sense) to 3.2; Ben will
> probably answer this point, otherwise you can reach kernel maintainers
> at .
[...]

This went into 3.2.35.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.


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

Re: Getting Intel Cedarview drivers into Debian

[Thomas Goirand]

On 12/21/2012 09:23 PM, Mikko Rasa wrote:
> Hi Debian developers,
>
> I'm working as a consultant on a project to develop drivers for the
> PowerVR graphics processor in the Cedarview family of Intel Atom
> microprocessors in a Debian environment.  The current target is
> Wheezy, and Intel wishes to get the drivers into the official
> distribution.
>
> What they've failed to take into account is that Wheezy is currently
> frozen in preparation of release, so I'm more than a bit skeptical of
> getting a new package in (I was only brought in to the project very
> recently).  However, I promised to ask you about this, so here we go.
>
> It should be noted that due to licensing issues, the driver will be
> closed source.  The kernel component is under the GPL, so a dkms
> package will be made.

I'm surprised. Wasn't Intel committed to support Opensource for all if
their drivers? Are they changing their policy? If so, that's quite bad,
since both ATI and Nvidia have been annoying all the community,
insisting with non-free drivers. If we're stuck with no alternative,
with Intel also going closed source, what type of hardware can we buy
then? :(

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50d4b1d9.9030...@debian.org

Re: Getting Intel Cedarview drivers into Debian

[Ben Hutchings]

On Sat, 2012-12-22 at 03:00 +0800, Thomas Goirand wrote:
> On 12/21/2012 09:23 PM, Mikko Rasa wrote:
> > Hi Debian developers,
> >
> > I'm working as a consultant on a project to develop drivers for the
> > PowerVR graphics processor in the Cedarview family of Intel Atom
> > microprocessors in a Debian environment.  The current target is
> > Wheezy, and Intel wishes to get the drivers into the official
> > distribution.
> >
> > What they've failed to take into account is that Wheezy is currently
> > frozen in preparation of release, so I'm more than a bit skeptical of
> > getting a new package in (I was only brought in to the project very
> > recently).  However, I promised to ask you about this, so here we go.
> >
> > It should be noted that due to licensing issues, the driver will be
> > closed source.  The kernel component is under the GPL, so a dkms
> > package will be made.
> 
> I'm surprised. Wasn't Intel committed to support Opensource for all if
> their drivers? Are they changing their policy? If so, that's quite bad,
> since both ATI and Nvidia have been annoying all the community,
> insisting with non-free drivers. If we're stuck with no alternative,
> with Intel also going closed source, what type of hardware can we buy
> then? :(

This has nothing to do with the GPUs built into Intel's
Core/Xeon/Pentium processors, which continue to be supported by the
i915/intel kernel/Xorg/libdrm/Mesa drivers.

For Atom SoCs and chipsets, Intel has long used the PowerVR GPUs
designed by Imagination, which the latter considers to be Valuable
Intellectual Property.  However, I think everything aside from the
actual GPU is Intel-designed so we get documentation and free drivers
for 'dumb framebuffer' functionality.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.


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

Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

[Petter Reinholdtsen]

[Thorsten Glaser]
> That’s just another argument for using /bin/mksh-static as /bin/sh.
> (It’s also faster than /bin/dash which is dynamically linked.)

Does this mean that mksh-static isn't using NSS at all?

Do you have benchmarks showing that it is faster than dash?  How does it
affect the boot times?

-- 
Happy hacking
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2fl4njf5dd6@diskless.uio.no

Bug#696511: ITP: kazoo -- higher level API to Apache Zookeeper for Python clients.

[Neil Williams]

Package: wnpp
Severity: wishlist
Owner: Neil Williams 

* Package name: kazoo
  Version : 0.8.0
  Upstream Author : Kazoo Team 
* URL : https://kazoo.readthedocs.org
* License : Apache License 2.0
  Programming Lang: Python
  Description : higher level API to Apache Zookeeper for Python clients.

Kazoo features:

* Support for gevent 0.13 and gevent 1.0b
* Unified asynchronous API for use with greenlets or threads
* Lock, Party, Election, and Partitioner recipe implementations (more
  implementations are in development)
* Data and Children Watchers
* Integrated testing helpers for Zookeeper clusters
* Simplified Zookeeper connection state tracking
* Pure-Python based implementation of the wire protocol, avoiding all the
  memory leaks, lacking features, and debugging madness of the C library

Kazoo is heavily inspired by Netflix Curator simplifications and helpers.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121221232414.11779.46769.reportbug@farglehob