Re: Debian bugs #800000 and #1000000 contest

[Chris Bannister]

On Sat, Feb 09, 2013 at 05:16:06PM +, Neil Williams wrote:
> On Sat, 9 Feb 2013 08:23:57 -0800
> Tyler MacDonald  wrote:
> 
> > "An obscure french DD". Wow, what a way to describe a person. Did that
> > person kill your pet squirrel or something? :-)
> 
> Christian is referring to himself. He might have killed his own pet
> squirrel - he hasn't said - but he's more likely to have overfed it on
> cheese & then drowned it in wine (or is that a waste of good
> cheese)?

Does that improve their flavour?

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
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/20130210094343.GB21983@tal

Re: RFC declarative built-using field generation

[Matthias Klose]

Am 09.02.2013 19:01, schrieb Philipp Kern:
> On Sat, Feb 09, 2013 at 11:16:30PM +0800, Chow Loong Jin wrote:
>> On 09/02/2013 08:38, Russ Allbery wrote:
>>> The proposal made in the Policy bug, which seems quite reasonable to
>>> me, is that we should only annotate packages with Built-Using if there
>>> are license implications to the inclusion of the source.  Documenting
>>> things like libgcc.a that have explicit, open use licenses that don't
>>> place any further restrictions on the resulting binaries doesn't seem
>>> like a good use of anyone's time.  Even to annotate them on the gcc
>>> package side.
>> DFSG #2: Source Code
>> 
>> The program must include source code, and must allow distribution in
>> source code as well as compiled form.
>> 
>> IIRC, Built-Using is a hint to the archive to keep around the source of
>> packages that have binaries included in other packages. If Debian is to
>> remain DFSG-compliant, I don't think we should make a distinction between
>> things like libgcc.a and everything else.
> 
> The concrete version of libgcc.a being used to link your binary really 
> doesn't matter.

But it is ok to insist on using the exact binary version for build-depending
on source packages when it's not needed? This only seems to be driven by the
current dak implementation.

  Matthias


-- 
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/5117a831.1090...@debian.org

PIL/python-imaging becomes a python package and gets Python3 support

[Matthias Klose]

[ targeted for jessie, not for wheezy ]

PIL/python-imaging didn't see any updates for a long time; this
did now change with the "PIL friendly" Pillow fork, introducing
support for Python3.

Pillow is now installed as a python package, not using the PIL
approach anymore to install many toplevel modules.  To keep the
current packages working, python-imaging now depends on
python-imaging-compat which again provides the old toplevel modules
(at least those documented in the PIL reference manual).  When
packages will be fixed, the dependency will be dropped, and hopefully
before the jessie release the python-imaging-compat package can be
removed again.

The python-imaging-compat package is only available for Python2, not
for Python3.  If your source package builds a python- package,
please consider packaging a python3- package as well.  If PIL is
the missing Python3 bit for your application, please consider building
it using Python3.

Fixes should be easy and made in a way that works with both the old
PIL modules and the new Pillow egg/package:

  import Image

should become

  try:
from PIL import Image
  except ImportError:
import Image

As an alternative, add a dependency on python-imaging-compat, however
this will stop working once this compat package is removed again.

Packages were uploaded to experimental, currently waiting in
NEW. Until then, download these from

  deb http://people.debian.org/~doko/tmp/PIL ./

There are 126 source packages needing updates. The list of packages
and maintainers is attached below. I'll file bug reports later (user:
d...@debian.org, tag: pillow).

Please report any other issues to the python-imaging packages.

  Matthias


A Mennucc1 
   freevo (U)

Agustin Henze 
   nikola

Alberto Garcia 
   ocrfeeder (U)

Alexandre Fayolle 
   python-scipy (U)

Andreas Noteng 
   python-easygui

Andreas Putzo 
   gpsdrive (U)

Andreas Tille 
   dicompyler (U)
   last-align (U)

Andreas Wenning 
   python-uniconvertor (U)

Andreas Wenning 
   python-uniconvertor

Andres Mejia 
   xbmc (U)

Andrew O. Shadura 
   twms

Angel Abad 
   glue

Anton Gladky 
   yade (U)

Arnaud Quette 
   moovida-plugins-bad (U)
   pigment-python (U)

Barry deFreese 
   snowballz (U)

Barry deFreese 
   fretsonfire (U)
   tpclient-pywx (U)

Baruch Even 
   hocr (U)

Ben Finney 
   python-docutils (U)

Bernhard Reiter 
   ocrfeeder (U)
   pysolfc (U)

Carl Fürstenberg 
   plastex

Charles Plessy 
   last-align (U)

Chow Loong Jin 
   remuco

Chris Lamb 
   rst2pdf

Christian Hammers 
   fofix-dfsg

Christian Marillat 
   gourmet

Christoph Berg 
   pycocuma

Christopher Baines 
   fgo

Dafydd Harries 
   glitch
   numm

Daniel Kahn Gillmor 
   python-qrencode
   trac-odtexport

Daniel Leidert (dale) 
   bkchem (U)
   gausssum (U)

Daniel Stender 
   didjvu

Daniel Watkins 
   python-django-filebrowser

Daniele Tricoli 
   circuits (U)

David Andel 
   uligo

David Cournapeau 
   python-scipy (U)

David Martínez Martí (mainkey) 
   soya (U)

David Martínez Martí 
   fretsonfire (U)

David Paleino 
   tilecache (U)

Debian Games Team 
   fretsonfire
   pysolfc
   snowballz
   tpclient-pywx

Debian GIS Project 
   gpsdrive
   grass
   tilecache

Debian Hams group 
   wsjt

Debian Hebrew Packaging Team 
   hocr

Debian HPIJS and HPLIP maintainers 
   hplip

Debian Med Packaging Team 
   dicompyler
   last-align
   mobyle
   pylibtiff

Debian Multimedia Maintainers 

   advene
   python-pyo
   streamtuner2

Debian Python Modules Team 
   aafigure (U)
   basemap
   circuits
   gamera (U)
   pisa
   plastex (U)
   pycaptcha
   python-aalib
   python-django-feincms (U)
   python-django-filebrowser (U)
   python-docutils
   python-easygui (U)
   python-enable
   python-reportlab (U)
   python-scipy
   python-scrapy
   python-trml2pdf
   python-uniconvertor (U)
   sorl-thumbnail
   soya (U)
   sphinx (U)
   stepic (U)
   sympy

Debian QA Group 
   xmms2tray

Debian Science Maintainers 
   guiqwt
   yade

Debian Science Team 
   svgtoipe

Debian VoIP Team 
   mumble-django

Debichem Team 
   bkchem
   gausssum

Dmitry Nezhevenko 
   djblets

Dmitry Smirnov 
   xpra (U)

Emfox Zhou 
   comix
   mcomix (U)

Emilien Klein 
   nautilus-image-manipulator

Emilio Pozuelo Monfort 
   phatch (U)

Filip Chabik 
   gwibber (U)

Francesco Namuri 
   virtualbricks

Francesco Paolo Lovergine 
   gpsdrive (U)
   grass (U)

Freevo Debian Dream Team 
   freevo

Gabriel Falcão Gonçalves de Moura 
   python-sponge

Georg W. Leonhardt 
   freevo (U)

Georges Khaznadar 
   expeyes
   sympy (U)

Giovanni Mascellani 
   wotsap

Gürkan Sengün 
   photofilmstrip

Hubert Chathi 
   asymptote

Ignace Mouzannar 
   python-scrapy (U)

Igor Stroh 
   python-reportlab (U)

Jakub Wilk 
   aafigure
   gamera
   python-docutils (U)
   sphinx

Janos Guljas 
   python-django-feincms

Jari Aalto 
   oboinus

Jens Göpfert 
   photofilmstrip (U)

Jerome Alet 
   pkpgcounter (U)

Jerome Kieffer 
   pyfai
   python-fabio

John Goerzen 
   forg

John T. 

Bug#700275: ITP: hunspell-en-med -- English medical dictionary for hunspell

[Sukhbir Singh]

Package: wnpp
Severity: wishlist
Owner: Sukhbir Singh 

* Package name: hunspell-en-med
  Version : 1.0
  Upstream Author : R Robinson 
* URL : http://www.e-medtools.com/Hunspel_openmedspel.html
* License : GPL
  Description : English medical dictionary for hunspell

This package contains a list of English medical words for
use with the hunspell spell checker.

Initial packaging:
http://anonscm.debian.org/gitweb/?p=debian-med/hunspell-en-med.git;a=summary


-- 
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/20130210194926.8430.99383.report...@gerty.sukhbir.in

Re: RFC declarative built-using field generation

[Russ Allbery]

Matthias Klose  writes:

> But it is ok to insist on using the exact binary version for
> build-depending on source packages when it's not needed? This only seems
> to be driven by the current dak implementation.

That does matter if the included source is GPL, and I suspect part of the
problem is that DAK doesn't have any way of knowing *why* this is required
and not making the dependency tight would be a *very* common error.

I think that in any case where we want Built-Using, we probably also want
the exact same version of the source.  (But I think the current Policy
statement about when we want Built-Using is too broad.)

-- 
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
Archive: http://lists.debian.org/877gmgnd4u@windlord.stanford.edu

Re: bits from the DPL: January 2013

[Steve Langasek]

Hi Zack,

On Sun, Feb 10, 2013 at 06:28:29PM +0100, Stefano Zacchiroli wrote:
> - The long standing issue of writing a proper (outbound) trademark
>   policy for Debian marks has been completed. I've reviewed on -project
>   outstanding items from the last discussion, and documented how they've
>   been implemented in a new policy draft [5]. Later on, I've published
>   the updated policy draft on our website [6].



> [6]: http://www.debian.org/trademark

This policy states that the contact for trademark questions is
tradem...@debian.org.  Where does this address go?  I think it's important
for transparency that the responsible parties be listed on
; I can't tell if this is an alias
for leader@, or a team, or what.  (/etc/aliases on master mentions it going
to leader@, but this entry is commented out.)

Thanks,
-- 
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/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: RFC declarative built-using field generation

[Philipp Kern]

On Sun, Feb 10, 2013 at 03:01:21PM +0100, Matthias Klose wrote:
> But it is ok to insist on using the exact binary version for build-depending
> on source packages when it's not needed? This only seems to be driven by the
> current dak implementation.

That doesn't make sense to me. Where did somebody require this?

Kind regards
Philipp Kern 


signature.asc
Description: Digital signature

Re: bits from the DPL: January 2013

[Nikolaus Rath]

Stefano Zacchiroli  writes:
>
> - The long standing issue of writing a proper (outbound) trademark
>   policy for Debian marks has been completed. I've reviewed on -project
>   outstanding items from the last discussion, and documented how they've
>   been implemented in a new policy draft [5]. Later on, I've published
>   the updated policy draft on our website [6].
>
[...]
>
> [6]: http://www.debian.org/trademark


The "You can see a non-exhaustive list of Debian trademarks [...] at our
trademarks page" link just loops back to the page itself, but there
doesn't seem to be a list anywhere on it.


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
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/8738x3sqtm@vostro.rath.org

Re: RFC declarative built-using field generation

[Matthias Klose]

Am 10.02.2013 23:31, schrieb Philipp Kern:
> On Sun, Feb 10, 2013 at 03:01:21PM +0100, Matthias Klose wrote:
>> But it is ok to insist on using the exact binary version for
>> build-depending on source packages when it's not needed? This only seems
>> to be driven by the current dak implementation.
> 
> That doesn't make sense to me. Where did somebody require this?

https://lists.debian.org/debian-gcc/2013/01/msg00012.html
https://lists.debian.org/debian-devel/2013/01/msg00711.html

maybe it's a coincidence, however creduce was formerly rejected for not having
a Built-Using attribute, and gcj-4.8, gnat-4.7 and gnat-4.8 are still in NEW.

  Matthias


-- 
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/51183026.50...@debian.org

Re: multiarch dependency hell. build amd64, can't install without also building i386

[Dmitrijs Ledkovs]

On 24 January 2013 04:56, Paul Johnson  wrote:
> This is a multiarch issue I had not considered before. Have you seen
> it? I never wanted to be a "cross compiler", I really only want to
> build amd64.  But I have some i386 libraries for a particular program
> (acroread).
>

I recently had to build packages that only build on i386, while having
an amd64 host:
$ mk-sbuild --arch i386 sid
$ sbuild -d sid --arch i386 foo*.dsc

Since amd64 cpu's can execute i386, it's not cross compilation, but a
native one instead.
Yes, it's a second build, but it's fairly trivial to do.

Regards,

Dmitrijs.


-- 
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/CANBHLUhHHX_=laqq1mjewxhtw-ij+m+2770bbd3hhz2zygf...@mail.gmail.com

Re: bits from the DPL: January 2013

[Tollef Fog Heen]

]] Steve Langasek 

> (/etc/aliases on master mentions it going to leader@, but this entry
> is commented out.)

Use exim -bt $address on master to find out.  It goes to leader@ + an
archive.  (I agree it should probably go on the org page too.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87txpjuwuy@xoog.err.no