Bug#741640: ITP: vcmi -- Free implementation of the Heroes of Might and Magic 3 game engine

2014-03-14 Thread Johannes Schauer 
Package: wnpp
Severity: wishlist
Owner: Johannes Schauer 

* Package name: vcmi
  Version : 0.95
  Upstream Author : Micha³ Urbañczyk aka Tow 
Ivan Savenko 
Tom Zielinski aka Warmonger 
AVS
Benjamin Gentner aka beegee
* URL : http://forum.vcmi.eu/portal.php
* License : GPL2.0+
  Programming Lang: C++
  Description : Free implementation of the Heroes of Might and Magic 3 game 
engine

VCMI is a free implementation of the Heroes of Might and Magic 3 game
engine as well as a platform for mods. VCMI is a turn-based strategy
game where the player controls a number of heroes commanding an army of
creatures. It extends the original capabilities of the game by
supporting maps of any size, greater display resolutions.

Since the game requires the graphics, videos and music of the original
game, can only go into contrib.


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

Bug#741646: ITP: libcofoja-java -- Java API providing annotating code with contracts

2014-03-14 Thread Diane Trout 
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

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

   Package name: libcofoja-java
Version: 1.1-r150
Upstream Author: 2010-2011 Google, Inc.
 2010-2011, 2013 Nhat Minh Lê
 2007 Johannes Rieken
URL: https://code.google.com/p/cofoja/
License: LGPL-2.1+
Description: Java API providing annotating code with contracts
 Contracts for Java enables annotating code with contracts in the form of
 preconditions, postconditions and invariants.
 .
 These contract annotations are
  * easy to write and read,
  * and checked at runtime. 
 Annotating code with contracts helps you:
  * design,
  * document,
  * test, and
  * debug
 programs.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1439547.7QmZr4ERlI@myrada

Re: jquery debate with upstream

2014-03-14 Thread Paul Wise 
On Thu, Mar 13, 2014 at 8:02 PM, Craig Small wrote:

> FWIW, I think the concept of a graphic needing its source is also bogus.
> It means that the upstream have to hang onto some script they might of
> used once years ago for.. what reason?
> To give you a concrete example, I made the SPI logo (and I think it is
> the current one, it looks like it) using gimp and some sort of lisp script.
> I don't have that script anymore, does that make the logo non-free?
> Should that change the status of the graphic?
> If, instead of a script I manually typed/moused the commands, does that
> change the status?

You are conflating two issues:

What is the "source" as required by DFSG item 2. Under the scenario
you have described, the PNG of the SPI logo appears to be "source"
since if you/upstream were to modify the SPI logo you/upstream would
use the PNG since the XCF and Lisp script no longer exist.

What upstream should be doing with the forms of data that they have or
create. Under the scenario you have described, you threw away (or
lost) the more useful forms, which I think was a mistake. As the
upstream maintainer and the Debian maintainer for a bunch of games
where the original authors have thrown away the source for the
graphic/video data, preventing simple modifications like increasing
the resolution to modern screen sizes, let alone fixing visual
glitches or using different 3D models, I find it a bit sad that you
threw away this data. I assume you wouldn't compile your C code to
assembler, throw away the C code, ship the assembler and hope you
never have to fix bugs in it, optimise it or add new features. This is
essentially what you did with the SPI logo. I expect there are people
out there who might want to modify the SPI logo, for example see what
various artists have done for the Debian swirl for DebConf logos,
which were only possible because the vector formats where not thrown
away.

I would encourage anyone creating code, docs, fonts, graphics, audio,
video or other digital works to think carefully before throwing away
the higher-level forms in favour of lower-level forms. I would
encourage Debian folks to look at what upstream provides, evaluate
what the source might be and in cases of doubt ask upstream for
clarification. This page provides a guide for the sort of things
upstream should think about and for Debian folk to audit.

http://www.freedesktop.org/wiki/Games/Upstream/#source

Sometimes you will find that upstream's preferred form for
modification is available in a VCS repository but not the tarball,
sometimes possibly resulting in GPL violations on Debian's behalf (cf
FSF/Emacs or Warzone 2100) and that you simply need to ask them to
ship it in tarballs. Sometimes you will find that upstream relies on
artists who aren't willing to share their preferred form for
modification (such as the Blender/Povray source for a 3D scene).
Sometimes you will find that upstream's preferred form for
modification has been thrown away and they don't intend to modify it
again.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6GuA6M3PjjJhHfg6JEMSZNaP37rAEpaP=XrBmAjak=s...@mail.gmail.com

Bug#741658: ITP: tuskar-ui -- control how and where OpenStack services are deployed - horizon plugin

2014-03-14 Thread Thomas Goirand 
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: tuskar-ui
  Version : 0.0.9
  Upstream Author : OpenStack Development Mailing List 

* URL : https://github.com/openstack/tuskar-ui/
* License : Apache-2.0
  Programming Lang: Python
  Description : control how and where OpenStack services are deployed - 
horizon plugin

 Tuskar gives administrators the ability to control how and where OpenStack
 services are deployed across the datacenter. Using Tuskar, administrators
 divide hardware into "resource classes" that allow predictable elastic scaling
 as cloud demands grow. This resource orchestration allows Tuskar users to
 ensure SLAs, improve performance, and maximize utilization across the
 datacenter.
 .
 Tuskar services are available via a RESTful API and management console through
 which administrators are able to classify their hardware and define their 
 datacenters. In addition, Tuskar components provide administrators with  
 performance monitoring, health statistics, and usage metrics, aiding in
 capacity planning and hardware procurement decisions.
 .
 This package contains the OpenStack dashboard plugin.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140315021858.6731.97507.report...@buzig.gplhost.com

Re: jquery debate with upstream

2014-03-14 Thread Steve Langasek 
On Sat, Mar 15, 2014 at 10:07:22AM +0800, Paul Wise wrote:
> On Thu, Mar 13, 2014 at 8:02 PM, Craig Small wrote:

> > FWIW, I think the concept of a graphic needing its source is also bogus.
> > It means that the upstream have to hang onto some script they might of
> > used once years ago for.. what reason?
> > To give you a concrete example, I made the SPI logo (and I think it is
> > the current one, it looks like it) using gimp and some sort of lisp script.
> > I don't have that script anymore, does that make the logo non-free?
> > Should that change the status of the graphic?
> > If, instead of a script I manually typed/moused the commands, does that
> > change the status?

> You are conflating two issues:

> What is the "source" as required by DFSG item 2. Under the scenario
> you have described, the PNG of the SPI logo appears to be "source"
> since if you/upstream were to modify the SPI logo you/upstream would
> use the PNG since the XCF and Lisp script no longer exist.

A PNG is not a program.  There is no source required for a PNG under DFSG
#2, and anyone who says otherwise is engaging in (or a victim of) historical
revisionism.

-- 
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: jquery debate with upstream

2014-03-14 Thread Thomas Goirand 
On 03/13/2014 11:45 PM, Vincent Bernat wrote:
>  ❦ 12 mars 2014 22:26 CET, Ben Finney  :
> 
>>> The javascript world is difficult to deal with. They like embedded
>>> copies, they may not really care about API/ABI stability, even for big
>>> projects. Those are difficulties that we already have to deal with. We
>>> already work around them by using Debian package when possible but
>>> this makes the software we ship more buggy because we don't match the
>>> exact version that upstream uses.
>>
>> Right. This can only really improve by addressing the general problems
>> you describe in that paragraph, which itself requires collaborating with
>> upstream to join with us in expecting better interoperability from JS
>> library developers.
> 
> In the past, we have seen it is useless to try to convince an upstream
> they should do like we want to. We should wait for them to notice that
> this is the way to go or they will just start some hate campaign about
> how slow and deprecated we are.

In my experience, this really depends on upstream, and you shouldn't
generalize that much.

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5323bb98.8020...@debian.org

Re: jquery debate with upstream

2014-03-14 Thread Paul Wise 
On Sat, Mar 15, 2014 at 10:20 AM, Steve Langasek wrote:

> A PNG is not a program.

Depends on your definition of program. PNG files are programs that run
in a PNG decoder. ELF binaries aren't programs, they are just data
interpreted by CPUs.

> There is no source required for a PNG under DFSG #2

I disagree, I've always assumed the DFSG applied to all of Debian main
regardless of format.

> anyone who says otherwise is engaging in (or a victim of)
> historical revisionism.

I guess you are referring to the GR that clarified the Social Contract
to read "work" instead of "software".

https://www.debian.org/vote/2004/vote_003

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6GdzQJr7bW82wetPx3sfyn05O0_=__j=v6smumxt6a...@mail.gmail.com

Re: jquery debate with upstream

2014-03-14 Thread Steve Langasek 
On Sat, Mar 15, 2014 at 10:50:13AM +0800, Paul Wise wrote:
> On Sat, Mar 15, 2014 at 10:20 AM, Steve Langasek wrote:

> > A PNG is not a program.

> Depends on your definition of program.

Yes.  If you use the English definition of the word "program", then it's not
a program.  But I guess if you make up definitions for program to get the
result you want:

> PNG files are programs that run in a PNG decoder.  ELF binaries aren't
> programs, they are just data interpreted by CPUs.

... then you can claim that it's a program.

> > There is no source required for a PNG under DFSG #2

> I disagree, I've always assumed the DFSG applied to all of Debian main
> regardless of format.

You may have assumed that, but that is not what the DFSG says.

> > anyone who says otherwise is engaging in (or a victim of)
> > historical revisionism.

> I guess you are referring to the GR that clarified the Social Contract
> to read "work" instead of "software".

> https://www.debian.org/vote/2004/vote_003

That was a conscious decision on the part of the project to revise the text
of the Social Contract.  That vote did *not* replace the use of the word
"program" in DFSG#2 with the word "software".  It is incorrect to infer from
this vote that Debian decided to require source for all non-program works.

-- 
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: jquery debate with upstream

2014-03-14 Thread Russ Allbery 
Steve Langasek  writes:
> On Sat, Mar 15, 2014 at 10:50:13AM +0800, Paul Wise wrote:

>> I guess you are referring to the GR that clarified the Social Contract
>> to read "work" instead of "software".

>> https://www.debian.org/vote/2004/vote_003

> That was a conscious decision on the part of the project to revise the
> text of the Social Contract.  That vote did *not* replace the use of the
> word "program" in DFSG#2 with the word "software".  It is incorrect to
> infer from this vote that Debian decided to require source for all
> non-program works.

That matches my memory of the discussion as well.  The purpose was to
require that non-program content in the archive also be covered by a
DFSG-free license concerning such things as modification, redistribution,
and so on, partly because of the GFDL invariant section issues and related
problems (such as RFCs).  If there was much discussion of the
applicability of the source requirement to such works, I don't recall it,
and I'm pretty sure it didn't play a role in at least my vote.

That said, when there *is* source of some kind for a non-program work,
often we would want it.  I'm not sure I'd be particularly happy about,
say, documentation in the form of PDF files generated from some markup
language but where that source was not available.  I'm largely convinced
by the FSF argument that free software should also have free
documentation, since being able to modify the software but not the
documentation is quite annoying and frustrating.  (It's a shame the FSF
itself doesn't guarantee that its documentation is free in that fashion,
but that's a different argument.)

I'm less convinced that retaining the original Photoshop file with all the
layers and transparencies alongside any random PNG file is that important.
Particularly since I know graphic designers who routinely discard those
files for small works once they've gotten the final output they want,
since, if they're going to revise a small graphic, they don't use those
files anyway.  It also could create the ironic situation of adding files
to the archive that can only be used by non-free software as "source" for
images that can be edited fine in GIMP with fairly minimal loss of
functionality.

-- 
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: https://lists.debian.org/87eh24gn75@windlord.stanford.edu

Re: jquery debate with upstream

2014-03-14 Thread Paul Wise 
On Sat, Mar 15, 2014 at 11:02 AM, Steve Langasek wrote:

> That was a conscious decision on the part of the project to revise the text
> of the Social Contract.  That vote did *not* replace the use of the word
> "program" in DFSG#2 with the word "software".  It is incorrect to infer from
> this vote that Debian decided to require source for all non-program works.

As far as I can tell, not modifying the DSFG at the same time was an
oversight. Fixing that mistake was attempted in a later GR but that
was blocked with a narrow margin.

https://www.debian.org/vote/2006/vote_004

The DFSG mentions "program" in other sections too. Does that mean that
we can accept non-programs with licenses that:

Discriminate against fields of endeavour (item 6)?

Don't let Debian pass licenses on to users (item 7)?

Don't apply to entities other than Debian (item 8)?

I definitely can't agree with your interpretation here and think we
should amend the DFSG to replace all uses of the words "software" or
"program" with "work" or similar.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6Hz9q+Cpj1TWANrGGweTUHh9UD+q72iNbvm6ds5a-_g=a...@mail.gmail.com

Re: jquery debate with upstream

2014-03-14 Thread Russ Allbery 
Paul Wise  writes:

> As far as I can tell, not modifying the DSFG at the same time was an
> oversight. Fixing that mistake was attempted in a later GR but that was
> blocked with a narrow margin.

> https://www.debian.org/vote/2006/vote_004

That GR proposal does not require source for non-programmatic works.  It
only "strongly recommends" it, and says explicitly that such source
doesn't have to be in the archive.

-- 
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: https://lists.debian.org/878uscgmvx@windlord.stanford.edu

Re: jquery debate with upstream

2014-03-14 Thread Paul Wise 
On Sat, Mar 15, 2014 at 11:29 AM, Russ Allbery wrote:
> Paul Wise writes:
>
>> As far as I can tell, not modifying the DSFG at the same time was an
>> oversight. Fixing that mistake was attempted in a later GR but that was
>> blocked with a narrow margin.
>
>> https://www.debian.org/vote/2006/vote_004
>
> That GR proposal does not require source for non-programmatic works.  It
> only "strongly recommends" it, and says explicitly that such source
> doesn't have to be in the archive.

Interesting, I must have glossed over that as I was on VAC at the time.

I note that the ftpmasters currently reject packages that are missing
source for non-programmatic works (REJECT-FAQ explicitly mentions
PS/PDF documentation). So the current archive requirements are in
practice stricter than the DFSG and the attempted DFSG clarification
GR.

https://ftp-master.debian.org/REJECT-FAQ.html

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6hq2jbjazmi8j_gfgtpdq4t15l2-eg8vdysofvw3+f...@mail.gmail.com

Re: jquery debate with upstream

2014-03-14 Thread Steve Langasek 
On Sat, Mar 15, 2014 at 11:24:19AM +0800, Paul Wise wrote:
> On Sat, Mar 15, 2014 at 11:02 AM, Steve Langasek wrote:

> > That was a conscious decision on the part of the project to revise the text
> > of the Social Contract.  That vote did *not* replace the use of the word
> > "program" in DFSG#2 with the word "software".  It is incorrect to infer from
> > this vote that Debian decided to require source for all non-program works.

> As far as I can tell, not modifying the DSFG at the same time was an
> oversight. Fixing that mistake was attempted in a later GR but that
> was blocked with a narrow margin.

> https://www.debian.org/vote/2006/vote_004

I agree that it was an oversight to leave these ambiguities in the DFSG at
the time it was being amended.  I do not agree with your implied assumption
that an attempt to remove these ambiguities would have resulted in us
deciding to apply DFSG#2 to non-program works.  I would have voted against
that then and would vote against it now.

I was also among the majority who voted against the above GR, and that GR
didn't even go as far as you are proposing.  That it was blocked "by a
narrow margin" gives you no more moral authority than if it were defeated in
a landslide; the Debian project did not ratify this interpretation of the
DFSG, and it is inappropriate for anyone to make source a de facto
requirement for main by changing the facts on the ground.

We all agree that it is best to have source available for everything we ship
in main, including non-programs.  But there's a big difference between
agreeing that it's a best practice, and kicking it out of main for not
complying with this best-practice guideline.

> The DFSG mentions "program" in other sections too. Does that mean that
> we can accept non-programs with licenses that:

> Discriminate against fields of endeavour (item 6)?

> Don't let Debian pass licenses on to users (item 7)?

> Don't apply to entities other than Debian (item 8)?

> I definitely can't agree with your interpretation here and think we
> should amend the DFSG to replace all uses of the words "software" or
> "program" with "work" or similar.

It's fine for you to hold the position that we should amend it in this way.
It's not fine to demand that Debian behave as if this amendment *had already
been made*, because this is *not* the meaning the document had either at the
time it was adopted or at the time it was amended.

-- 
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: jquery debate with upstream

2014-03-14 Thread Charles Plessy 
Le Sat, Mar 15, 2014 at 11:47:44AM +0800, Paul Wise a écrit :
> 
> I note that the ftpmasters currently reject packages that are missing
> source for non-programmatic works (REJECT-FAQ explicitly mentions
> PS/PDF documentation). So the current archive requirements are in
> practice stricter than the DFSG and the attempted DFSG clarification
> GR.
> 
> https://ftp-master.debian.org/REJECT-FAQ.html

Hi Paul,

I think that this hard-line position is problematic at mutiple levels.  One of
them is that it is far more frequent for an upstream work to occasionally
receive additional documentation or artwork with missing source, compared with
receiving addtional source code under a non-DFSG-free license.  As a
consequence, it is quite common for packages in main to suddenly fall in a
limbo where they are DFSG-free and FTPmaster-rejectable.

With a best-effort approach, following the spirit and the letter of the DFSG,
one can engage in a constructive discussion with Upstream.  However, with a
hard-line approach it is hard to not sound like an ultimatum menacing to remove
the package from Debian (usually, nobody volunteers to maintain these packages
in non-free).

Personally, this is a reason why I have quitted R packaging.  This is far too
stressful for me as I beleive that as a packager it is my responsibiltiy to
keep a package in main if possible, but on the other hand the situation is out
of my control (to the extent being between the hammer and the anvil can be
considered having some control).

The take home message is that when Upstream starts to add documentation or
artwork in his documentation, it should be something positive for all, even if
it is started in a way that can be improved, and not a source of RC bugs as it
is now.  I think that the hard-line point of view does not motivate and rather
leads people to give up.

Have a nice week-end.

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140315042829.ga24...@falafel.plessy.net

Re: jquery debate with upstream

2014-03-14 Thread Thomas Goirand 
On 03/13/2014 04:57 AM, Jakub Wilk wrote:
> * Philipp Kern , 2014-03-12, 21:11:
>> I still think it should be acceptable given that it's an open source
>> project, it's clearly versioned from which source it comes and we
>> check by not using the file that no changes have been done to the
>> minification. I guess we could even go one step further and argue that
>> the source for this is in fact in Debian.
> 
> That would work only if the embedded copy was the same version as the
> packaged one. And there are lots of jQuery versions in the wild.
> 
> In <20120817111437.ga8...@jwilk.net> I suggested making a package that
> would bundle all the needed sources, but my proposal wasn't met with
> enthusiasm.

I think it's a good idea, however, instead of packaging all version
possible, would it be possible to identify which API is incompatible and
package just as much as needed only?

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5323ee7d.1010...@debian.org