Bug#745872: ITP: profanity -- a console based XMPP client

[Dariusz Dwornikowski]

Package: wnpp
Severity: wishlist
Owner: Dariusz Dwornikowski 

* Package name: profanity
  Version : 0.4.0
  Upstream Author :  James Booth 
* URL : http://www.profanity.im/
* License : GPL-3
  Programming Lang: C
  Description : a console based XMPP client

Profanity is a console based XMPP client written in C using ncurses and
libstrophe, inspired by Irssi. It supports:
* XMPP chat services, including GoogleTalk and Facebook,
* command driven interface,
* customizable functionality and user interface,
* Off the Record message encryption,
* chat room support,
* roster management,
* flexible resource and priority settings,
* desktop notifications,
* unicode support,
* integrated DuckDuckGo search,
* sending tiny URLs,
* plugin written in C, Python, Ruby and Lua.

Since I did not get a response from XMPP packaging team, I will strat packaging
it by myself with a possibility to move to XMPP team when they respond.
Profanity depends on a great XMPP library libstrophe, which is not in Debian
yet. I am currently working on providing a high quality package (ITP 511341),
for that reason I am working with upstream to adjust the source for Debian.


-- 
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/20140426073200.ga9...@blackstar.cs.put.poznan.pl

Re: concurrent installation of different pkg versions

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 26/04/14 07:11, Steve Langasek wrote:
> On Sat, Apr 26, 2014 at 02:07:22PM +0900, Charles Plessy wrote:
>> Le Sat, Apr 26, 2014 at 11:41:17AM +0800, Paul Wise a ￩crit :
>>> On Sat, Apr 26, 2014 at 1:39 AM, Daniel Pocock wrote:
> 
 a generalized approach is needed.
> 
>>> Multiple versions of a package seems undesirable to me, for the
>>> same reasons as static libraries and embedded code copies are
>>> undesirable.
> 
>> Hi Paul and everybody,
> 
>> it would be a great advantage for Debian over the other
>> distributions to have the capacity to install multiple versions
>> concurrently.
> 
> No, no it wouldn't.
> 
> This is how rpm handles library packages.  It's a horror show.
> 

There is a difference between doing this for "core" packages (e.g. C
libraries, system daemons, things that are sensitive to something in
/etc) and these independent eco-systems that exist around Python,
Java, JavaScript, etc.

Letting people install arbitrary versions of Python and then expect
all the Python scripts in a stable system to just work feels unreasonable.

However, letting them install additional versions of the Python
interpreter or some Python libraries that can be used on-demand, while
not impacting the default that is used would be less demanding on
Debian to support.  The same can be said for Java and JavaScript and
other things.

With JavaScript, the problem is particularly acute because the APIs
are more volatile.  It is harder to force all web packages to use a
single version of jQuery (or something else) if each upstream uses a
different version.  Debian either ends up dropping a lot of these web
packages or demanding that DDs who want to upload such things jump
through more hoops to patch their packages.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTW2TGAAoJEOm1uwJp1aqDJVwQAIXaaMRQtgkXxBE+3ZfOOGly
HFWQjJ+6sX1f2xfzUCok5wyhnhQNmSCSXQ5tknEvtvJAOC5Vmb4d3fhV8knIt6HZ
QEprwYDzPeOmpxtbLQpCrGOnsIG0WcJX3Sr5DUG9g6ObJvArNTX/7sZKYLdcDZWG
FVQCLFgD6BqCXC4b0MMO6GGmb8WvnM9qz7GVgwv3JaQdlwWHzkZZ5RNRGBrN7BGS
uLqVTMWblUa8qmmhGbSNbefaOOk8rjvuKlPH0mwctcZ03K44/fr0lkoRG41bGnx/
HztaOGmGG2xOOgSbKE5oOpCCy/J/5RK2VzcFAS4NQlry+vXdHt7A/3/4UFJPTCuS
OFnEnNu7+d8bC+YtoJgVOWGncQ587eOhGhGAVnNT4Jf3VLy6F15XGoOSQmUUgCjj
Avtpmz+lFjdCmv3zCji8yw4LV/2ZANHyAWwWQAIJSQtz0+B6kQCXtaRYtBmrpHKG
bp6OIhMKtRzfsx/1Vl27ZGvbFhC2ZpRflubyNasFBD1VXbIAvsAmwGCRG3863cWS
bWY4F7Kfq0HzzDPpgan9S3Tl3XEa/HEFfRzQBtsUDNQuO1rtvQwQufhjxpXvEp5o
NnNzPxfdQHj1d3MtxuYB+VAS30kwuE9jOd/ES8jdLhyrBzq0VnGEO9+QU/CJHzPq
DgEkOPG+e3Qp9ejVOs7N
=gLWq
-END PGP SIGNATURE-


-- 
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/535b64c6.3090...@pocock.pro

Re: Bug#745872: ITP: profanity -- a console based XMPP client

[Andrey Rahmatullin]

On Sat, Apr 26, 2014 at 09:32:00AM +0200, Dariusz Dwornikowski wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Dariusz Dwornikowski 
> 
> * Package name: profanity
>   Version : 0.4.0
>   Upstream Author :  James Booth 
> * URL : http://www.profanity.im/
> * License : GPL-3
PKG_CHECK_MODULES([openssl], [openssl], [],
[AC_MSG_ERROR([openssl is required for profanity])])

The resulting binary cannot be distributed.

-- 
WBR, wRAR


-- 
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/20140426081210.ga31...@belkar.wrar.name

Re: Bug#745854: ITP: phpunit-exporter -- export variables for visualization - PHPUnit component

[Thomas Koch]

On Friday, April 25, 2014 10:48:06 PM David Prévot wrote:
> * URL : https://github.com/sebastianbergmann/phpunit-exporter
404

correct: https://github.com/sebastianbergmann/exporter

After reading the description I still wasn't sure what the package was about.


--
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/201404261017.35872.tho...@koch.ro

Re: Registration open for DebConf14

[Daniel Baumann]

On 04/26/2014 08:11 AM, Steve Langasek wrote:
> If you want to attend DebConf14, please fill out the registration
> form .

this redirects to:
https://sso.debian.org/sso/acs_error?DACS_ERROR_CODE=902&;[...]

which shows a page requiring a login, either a debian SSO login or an
alioth one. i have neither. how should i register?

-- 
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:  daniel.baum...@progress-technologies.net
Internet:   http://people.progress-technologies.net/~daniel.baumann/


-- 
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/535b73d9.5030...@progress-technologies.net

Re: Registration open for DebConf14

[Rene Engelhard]

Hi,

On Sat, Apr 26, 2014 at 10:52:41AM +0200, Daniel Baumann wrote:
> On 04/26/2014 08:11 AM, Steve Langasek wrote:
> > If you want to attend DebConf14, please fill out the registration
> > form .
> 
> this redirects to:
> https://sso.debian.org/sso/acs_error?DACS_ERROR_CODE=902&;[...]
> 
> which shows a page requiring a login, either a debian SSO login or an
> alioth one. i have neither. how should i register?

TTBOMK DDs should login via Debian SSO anyway...

I think the page explained that, but you can set the SSO password in your
db.debian.org settings... Wait a bit unil it's synced and the login with
your debian username and that password.

Regards,

Rene


-- 
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/20140426091300.ga10...@rene-engelhard.de

Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

[Vincent Bernat]

 ❦ 26 avril 2014 01:31 CEST, Manuel A. Fernandez Montecelo 
 :

>>> Compared to that amount of work, stripping a few files from a tarball
>>> using uscan is utterly trivial and I don't see why it is a problem.
>>> It's quite a bit harder to do the right thing and persuade upstream to
>>> not include them.
>>
>>How to handle this with gbp?
>
> I guess that one of the best things that you can do is to filter the files, 
> like
> other cruft in the tarball coming from upstream, example:
>
> http://anonscm.debian.org/gitweb/?p=pkg-sdl/packages/libsdl2.git;a=blob;f=debian/gbp.conf;h=b3a5a0939feff4f6578c8d617059ac7e740b778b;hb=HEAD

Good to know. I was using a dedicated "dfsg" branch, but the workflow is
crappy in this case. But currently, nothing we can do with
debian/copyright?
-- 
panic("esp_handle: current_SC == penguin within interrupt!");
2.2.16 /usr/src/linux/drivers/scsi/esp.c


signature.asc
Description: PGP signature

Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

[Vincent Bernat]

 ❦ 26 avril 2014 08:12 CEST, "Steve M. Robbins"  :

> That sounds like you you're asking N developers to do a bunch of extra 
> busywork so that 1 person's job is made easier.  Here's an alternative: if 
> you 
> can indeed scan the archive for bad files, add that detector to the archive-
> rebuilding project and do this:
>
> 1. Unpack 
> 2. Remove bad files
> 3. Build
>
> If it still builds after removal, you have proved the bad file is not
> used.

In case of minified JS or stuff like that, the build process could just
be "copy all the files from this directory in this directory". So the
build will still be successful.
-- 
Don't sacrifice clarity for small gains in "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: concurrent installation of different pkg versions

[Vincent Bernat]

 ❦ 26 avril 2014 07:07 CEST, Charles Plessy  :

> it would be a great advantage for Debian over the other distributions to have
> the capacity to install multiple versions concurrently.
>
> That does not mean that it would be a good idea to install multiple versions 
> of
> core packages.  However, on multi-user systems, the ususal approach is that 
> the
> administrator tells the users to go compile their specialised programs
> themselves.  In Debian, these programs are typically in leaf packages that 
> have
> simple dependancy trees and tend to work well unmodified on multiple releases.
>
> If we could use APT to leverage resources like snapshot.debian.org, this would
> give Debian a strong momentum on that use case.  Of course, I understand that
> implementing this properly is a lot of work.

I would be a lot simpler to leverage containers.
-- 
panic("Fod fight!");
2.2.16 /usr/src/linux/drivers/scsi/aha1542.c


signature.asc
Description: PGP signature

Re: Registration open for DebConf14

[Adam D. Barratt]

On Sat, 2014-04-26 at 10:52 +0200, Daniel Baumann wrote:
> On 04/26/2014 08:11 AM, Steve Langasek wrote:
> > If you want to attend DebConf14, please fill out the registration
> > form .
> 
> this redirects to:
> https://sso.debian.org/sso/acs_error?DACS_ERROR_CODE=902&;[...]
> 
> which shows a page requiring a login, either a debian SSO login or an
> alioth one. i have neither. how should i register?

Steve's mail clearly says:

"This year, conference registration is integrated with the new Debian
SSO system.  If you are a Debian developer and have not previously used
the Debian SSO system, you will need to configure an SSO password on
db.debian.org."

Regards,

Adam


-- 
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/1398508901.15557.21.ca...@jacala.jungle.funky-badger.org

Re: Registration open for DebConf14

[Adam D. Barratt]

On Sat, 2014-04-26 at 11:41 +0100, Adam D. Barratt wrote:
[stuff]

Sorry, ignore that.

The correct answer would appear to be "register an alioth account".

Regards,

Adam


-- 
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/1398509382.15557.22.ca...@jacala.jungle.funky-badger.org

Bug#745886: ITP: gfbgraph -- GObject library for Facebook Graph API

[Laurent Bigonville]

Package: wnpp
Severity: wishlist
Owner: Laurent Bigonville 

* Package name: gfbgraph
  Version : 0.2.2
  Upstream Author : Álvaro Peña 
* URL : http://download.gnome.org/sources/gfbgraph/
* License : LGPL2.1+
  Programming Lang: C
  Description : GObject library for Facebook Graph API

GFBGraph is a GLib/GObject wrapper for the Facebook API.


-- 
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/20140426110905.11059.25222.report...@soldur.bigon.be

Re: concurrent installation of different pkg versions

[Russ Allbery]

Steve Langasek  writes:
> On Sat, Apr 26, 2014 at 02:07:22PM +0900, Charles Plessy wrote:

>> it would be a great advantage for Debian over the other distributions
>> to have the capacity to install multiple versions concurrently.

> No, no it wouldn't.

> This is how rpm handles library packages.  It's a horror show.

All of our research computing systems run Red Hat (or CentOS) because
that's where the people who care about concurrent installation of
different versions have gone, since no one in the Debian and Ubuntu world
with influence seems to care about their problems.  And simultaneous
installation of multiple versions of packages is simply a requirement for
many research computing scenarios, usually because there's a lot of
bespoke scientific code that accomplishes some specific goal but was not
written to the standards one would expect from professional programmers,
and therefore doesn't easily work with newer versions of libraries.

Just something to keep in mind.

-- 
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/87eh0kns4i@windlord.stanford.edu

New Cinnamon Maintainer, looking for help

[Maximiliano Curia]

Hi,

Cinnamon is a desktop environment based on GNOME, but with a different
shell and some other replaced parts (screensaver, file manager, system
settings, etc).  It was created by Linux Mint, but it's independent of
the distribution.

The cinnamon package and dependencies included in Debian are currently
uninstallable, and have been unmantained for a year.

I have prepared new packages, adding their sources to the collab-maint
alioth project.  There's still quite a lot of work to do in order to
bring these packages into Debian shape, so I encourage anyone who's
interested to contact me, so that we can work together.

-- 
"I decry the current tendency to seek patents on algorithms. There are better
ways to earn a living than to prevent other people from making use of one's
contributions to computer science."
-- Donald Knuth
Saludos /\/\ /\ >< `/


signature.asc
Description: Digital signature

Re: Non-source Javascript files in upstream source

[Manuel A . Fernandez Montecelo]

2014-04-26 07:51 Ben Finney:

"Steve M. Robbins"  writes:


On April 25, 2014 11:02:29 PM Ben Finney wrote:
> We promise the source for everything any recipient downloads as part
> of Debian. If non-source files are distributed in Debian source
> packages, without a way to confidently guarantee the corresponding
> source is what's already available in Debian, then that is a
> definite impact on the freedom of Debian recipients: it threatens
> the freedom promises in the Social Contract.

That is certainly not a universally held view. Some of us [1] regard
random trash littering the source distribution -- but not used in
generating the actual software (binary distribution) -- as merely a
nuisance that can be tolerated.


If it's in the Debian source package, it is distributed as part of
Debian.


What's your position on 'configure' scripts for which we don't know if they are
generated from the .ac?  (Is there a good method to even test this?).  Are they
also missing the source?

If the versions of autotools used by upstream generating code from the .ac into
'configure', not shipped in [almost?] any source packages, were not even ever
packaged in Debian (or patched in upstream's distributions or local systems), we
are missing the source (preferred form of modification) of 'configure' script as
well.  Svante explained in a previous e-mail of this thread a case with
Makefile/.in/.am.

This has important consequences, and IMO much more serious than the case of
minified JS.  If we regenerate 'configure' from the .ac for all packages, part
of the tests and compilation flags at build time will change, most likely
runtime behaviour will change as well.  I think that there were even security
problems reported recently related with this.


If you agree that "source-is-missing" also applies in those cases, do you also
think that we should immediately declare all source packages in Debian
containing a 'configure' script as somehow non free (unless we can check
unambigously that they were generated by the .ac), and emit lintian errors
asking all the source packages are repackaged stripping the 'configure' script
and regenerating from the .ac?  Or what alternative solutions are acceptable for
you?


(I'm in favour of regenerating 'configure' scripts automatically as expressed in
another recent thread, but because of ports and other practical purposes... and
because they actually are a central part of building every package in which they
are present.  But I would also be against requiring to strip source packages of
this file just because we don't know exactly where its source comes from -- that
would be Very Silly and counter-productive).



If it's distributed as part of Debian, it is subject to the promises in
the Debian Social Contract.

Those promises include the promise that anything in Debian has its
source in Debian.

[...]

What part are you saying is “not a universally held view”, and how do
you reconcile that with the Debian Social Contract?



My understanding is that SC and DFSG, similarly to the definition of Free
Software by FSF and other efforts, were devised to promote user freedom when
using and modifying software, etc.

If the consequence of following SC and DFS *Guidelines* (SC#1 refer to it) does
not further these goals, it is an exercise in futility, and thus not worth doing
in my opinion.  Interpreting SC or DFSG (or any law or guideline, for that
matter) without thinking of the utility, the costs or the consequences, does not
seem very wise to me.

"source-is-missing" is not important if we (or the users) don't need, or even
use or want, the source or the derived file.  And if they want to use/modify it,
they can easily get it, and in fact it is *better* if they get it from JQuery
upstream (or our canonical Debian package) than from the upstream project that
ships it (more recent fixes, etc).


Every person with knowledge about how to modify the minified JQuery, or to ask
some other person to do it for them, will know (the minified file tells them)
where to get the preferred form of modification, change them to their heart's
content, and replace it.  In principle most versions will work fine; and people
who want to modify it will generally just grab the latest one from upstream,
from another file their system or a Debian package, or elsewhere.  So I think
that not having the unminified file in the same source package doesn't have any
practical negative consequence for users.

I could be mistaken, though.  I asked in several emails of the thread for people
to provide realistic examples in which doing the huge *collective* work of
repackaging thousands of source packages improves user freedom in any way, but I
think that nobody provided an example.

So unless/until somebody does that, I consider all this issue a futile effort
(and by wasting time and energy of this, we are actually harming other aspects
of Debian, etc...).  I would wish it to stop before more maintainers spend time
on this; but I th

Re: lintian "source-is-missing" for jquery

[Manuel A . Fernandez Montecelo]

2014-04-26 02:30 Charles Plessy:

Le Fri, Apr 25, 2014 at 03:48:51PM +0200, Bas Wijnen a écrit :


Ignoring a bug because you set your priorities is understandable and
(in some cases) good.  Adding an override is not.


There are also benefits from using an override:

- It shows that the message has been received by the maintainer, not just
  skipped, missed or ignored.

- It gives an opportunity to write down why he decided to not take further
  action.


Agree, that's why we did it in the package that sparked this complaint:

#it is removed and symlinked when building
sdlgfx source: source-is-missing Docs/html/jquery.js



Overrides are a central place in which Lintian maintainers and other developers
doing distribution-wide developments and quality controls can try to unerstand
why a tag tends to be ignored by a large number of package maintainers.

For example, I am very tempted to start to override hyphen-used-as-minus-sign
tags with a justification such as “Never going to work; will not spend my time
on this; others may do as they wish”.


Also agree with both.

--
Manuel


--
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/20140426142925.gb9...@lugh.itsari.org

Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

[Manuel A . Fernandez Montecelo]

2014-04-26 11:00 Vincent Bernat:

❦ 26 avril 2014 01:31 CEST, Manuel A. Fernandez Montecelo 
 :


Compared to that amount of work, stripping a few files from a tarball
using uscan is utterly trivial and I don't see why it is a problem.
It's quite a bit harder to do the right thing and persuade upstream to
not include them.


How to handle this with gbp?


I guess that one of the best things that you can do is to filter the files, like
other cruft in the tarball coming from upstream, example:

http://anonscm.debian.org/gitweb/?p=pkg-sdl/packages/libsdl2.git;a=blob;f=debian/gbp.conf;h=b3a5a0939feff4f6578c8d617059ac7e740b778b;hb=HEAD


Good to know. I was using a dedicated "dfsg" branch, but the workflow is
crappy in this case. But currently, nothing we can do with
debian/copyright?


I am not sure of what you mean.

If you don't have it in the repackaged .orig.tar, you don't have to document it
in debian/copyright (you can document somewhere why you removed them from
orig.tar, though).

Other people mentioned other methods of solving these cases with uscan and other
tools, but I am not familiar with those so I don't know if there are better
methods.

--
Manuel


--
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/20140426143419.gc9...@lugh.itsari.org

Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

[Vincent Bernat]

 ❦ 26 avril 2014 16:34 CEST, Manuel A. Fernandez Montecelo 
 :

>>Good to know. I was using a dedicated "dfsg" branch, but the workflow is
>>crappy in this case. But currently, nothing we can do with
>>debian/copyright?
>
> I am not sure of what you mean.
>
> If you don't have it in the repackaged .orig.tar, you don't have to document 
> it
> in debian/copyright (you can document somewhere why you removed them from
> orig.tar, though).

I was speaking of the "File-Excluded" feature. It would be neat for gbp
to use that during git-import-orig (like uscan does).
-- 
Don't compare floating point numbers just for equality.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#745930: RFP: fbzx -- ZX Spectrum emulator

[Santiago Vila]

Package: wnpp
Severity: wishlist

* Package name: fbzx
  Version : 2.10.0
  Upstream Author : Raster Software Vigo (Sergio Costas)
* URL : http://www.rastersoft.com/fbzx.html
* License : GPL-3+
  Programming Lang: C
  Description : ZX Spectrum emulator for X or framebuffer

I actually started to package this, but I would prefer that someone
else maintains it. Preliminary package here:

http://people.debian.org/~sanvila/fbzx/


-- 
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/alpine.deb.2.02.1404261720001.27...@cantor.unex.es

Re: New Cinnamon Maintainer, looking for help

[Mateusz Łukasik]

On 26.04.2014 16:14, Maximiliano Curia wrote:

Hi,

Cinnamon is a desktop environment based on GNOME, but with a different
shell and some other replaced parts (screensaver, file manager, system
settings, etc).  It was created by Linux Mint, but it's independent of
the distribution.

The cinnamon package and dependencies included in Debian are currently
uninstallable, and have been unmantained for a year.

I have prepared new packages, adding their sources to the collab-maint
alioth project.  There's still quite a lot of work to do in order to
bring these packages into Debian shape, so I encourage anyone who's
interested to contact me, so that we can work together.


Hi Maximiliano,

I'm not Cinnamon user, but I have contact by the another users with that 
environment. I can help you.



--
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/535bca66.1090...@linuxmint.pl

Re: Bug#745872: ITP: profanity -- a console based XMPP client

[Dariusz Dwornikowski]

> PKG_CHECK_MODULES([openssl], [openssl], [],
> [AC_MSG_ERROR([openssl is required for profanity])])
> 
> The resulting binary cannot be distributed.
> 

Hey Andrey,

Could You elaborate on that ? Why would openssl ban the binary to be
distributable ?

-- 
Dariusz Dwornikowski, 
  Institute of Computing Science, Poznań University of Technology
  www.cs.put.poznan.pl/ddwornikowski/  
  room 2.7.2 BTiCW | tel. +48 61 665 29 41


-- 
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/20140426164451.ga9...@blackstar.cs.put.poznan.pl

Re: Bug#745872: ITP: profanity -- a console based XMPP client

[Russ Allbery]

Dariusz Dwornikowski  writes:

>> PKG_CHECK_MODULES([openssl], [openssl], [],
>> [AC_MSG_ERROR([openssl is required for profanity])])
>> 
>> The resulting binary cannot be distributed.

> Could You elaborate on that ? Why would openssl ban the binary to be
> distributable ?

The GPL and the OpenSSL license are incompatible.

-- 
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/87d2g4kp1b@windlord.stanford.edu

Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

[Manuel A . Fernandez Montecelo]

2014-04-25 23:32 Wookey:

+++ Manuel A. Fernandez Montecelo [2014-04-25 09:42 +0100]:


... a recent/ongoing thread, about using dh-autoreconf or something
similar ...



Nobody in the thread tried to apply the same logic with configure
script compared to minified .js.  The case of configure script is even
worse, in my opinion, because it is actually used to compile the
binary (unlike minified .js, which in virtually all cases is only
shipped to be used for documentation).  And it is at least as
difficult to check if a configure script actually came from that
source as to check if minified js came from another .js.

In that situation, nobody proposed that we should strip ./configure
from the source packages just because we don't know if it was
generated from the accompanying .in/.ac sources of that script (if
present there at all), or because any other consideration.

People attempt to deal with that sitation acknowledging the problem
and by using automatic tools to regenerate it at build time, before
starting the build.  Nobody is proposing repackaging orig.tar to
remove the "source-is-missing" configure script, and nobody argued
that this would improve user freedom or benefit our users in any way.


I see the point you are getting at, but don't agree that the
situations are equivalent. First I have never seen a package (and I've
looked at a lot) where the source (configure.in/ac) is missing.



From some hundreds of orig.tar that I have around, the following

examples are generated by autoconf but .ac/.in seems missing.  Few in my
survey, but some of them are important.

acl-2.2.52/configure
attr-2.4.47/configure
ccache-3.1.9/configure
(I stopped looking)



So the source is never missing, and re-generating it is thus
straightforward. Also the configure script, whilst not entirely
'preferred' is perfectly modifiable, comprehensible, with comments and
variables and so on, so again it's at least much further up the scale
of 'preferred/modifiable' than minified js. It's a much harder call to
say that it doesn't count as source for DFSG purposes. I'm not sure
that generation itself makes something 'not source'.

It is possible that the shipped configure is not what you'd get from
regenerating - i.e. it doesn't match the 'source' provided, and we
don't check for that. But this is just another argument for
re-autoconfing, which we have agreed is a good thing for other reasons
too, and as we have all the parts we need, there is no issue of source
availability.


I don't know if people agree, but if we accept the premise that the
source and preferred form of modification of 'configure' is
'configure.ac' (and, I would add, the code from autoconf expanding the
functions/macros in .ac is also source of 'configure'), then I don't
agree that the source code of 'configure' is never missing.  And other
people argue that not being the preferred form of modification, violates
the DFSG.

If we need to modify the '.ac' to support a new feature, the regenerated
'configure' is potentially very different (and fail to compile, be
buggy, whatever).  Once we need to modify the .ac and regenerate, parts
of the "source" of the old 'configure' is more or less effectively
"missing" and lost for any new builds.  Generally that's fine and we
don't care, but still, I would argue that conceptually the same is true
of well-known minified JS libs: you take the new unminified, substitute
it, and are done with it -- that the exact source code changes is not
important, as long as it works.  And we know that the canonical versions
usually work better than old copies, so good riddance.

If either 'configure' or minified JS were modified by hand (e.g., adding
extra non-minified functions to the minified .js, to provide unrelated
functionality to the original library), or for whatever reason does not
work with newer autoconf, and so regeneration from configure.ac or
unminified JS breaks the build, we have no option but use the original
'configure' and minified JS (not their preferred form of modification).
At that point they are their own preferred form of modification -- until
somebody fixes the project to be compatible with newer versions of the
libs.

So I think that the uses and problems that we have to deal with minified
JS have many parallels with 'configure', at least in the case of
well-known JS libraries.


As you say above, and it is one of the objections of people about
minified JS, in the same way that there is no easy way to say if
'configure' comes from '.ac', there is also no general/sure way to say
about minified JS and unminified source.  If that's an argument for
regenerating from .ac (I agree, again) and so we are ignoring the
'configure', I think that it's an argument for ignoring the minified JS
from upstream and linking to the canonical libjs-* (except in cases
where fails).

Crucially, and that's what I am arguing for, I think that nobody thinks
of asking upstream to remove their 'configure' file on the basis that it
migh

Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

[Jakub Wilk]

* Manuel A. Fernandez Montecelo , 2014-04-26, 19:13:
From some hundreds of orig.tar that I have around, the following 
examples are generated by autoconf but .ac/.in seems missing.  Few in 
my survey, but some of them are important.


acl-2.2.52/configure
attr-2.4.47/configure


$ ls {acl,attr}-*/configure.in
acl-2.2.52/configure.in
attr-2.4.47/configure.in


ccache-3.1.9/configure


This is true positive AFAICT, and I don't doubt there's more in the 
archive. You (or anybody else) are welcome to implement Lintian check to 
find such cases.


--
Jakub Wilk


--
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/20140426183905.ga5...@jwilk.net

Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

[Russ Allbery]

Jakub Wilk  writes:
> * Manuel A. Fernandez Montecelo , 2014-04-26, 
> 19:13:
>> From some hundreds of orig.tar that I have around, the following
>> examples are generated by autoconf but .ac/.in seems missing.  Few in my
>> survey, but some of them are important.
>>
>>acl-2.2.52/configure
>>attr-2.4.47/configure

> $ ls {acl,attr}-*/configure.in
> acl-2.2.52/configure.in
> attr-2.4.47/configure.in

They're added via a patch because upstream forgot to ship them, so they're
missing from the upstream tarball, which I suspect is what Manuel was
checking.

-- 
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/87lhushqz8@windlord.stanford.edu

Bug#745968: ITP: gcc-4.9-doc -- documentation for the GNU compilers

[郭溢譞]

Package: wnpp
Severity: wishlist
Owner: "Guo Yixuan (郭溢譞)" 

* Package name: gcc-4.9-doc
  Version : 4.9.0-1
  Upstream Author : FSF
* URL : http://gcc.gnu.org/
* License : GFDL-1.3+, with invariant sections
  Programming Lang: Texinfo
  Description : documentation for the GNU compilers

This package contains manual pages and documentation in info and
html format, for the GNU compilers.

This documentation is licensed under the terms of the GNU Free
Documentation License, and contains invariant sections, so it can't be
part of Debian main.

I'm maintaining gcc-4.4-doc-non-dfsg, gcc-4.6-doc, gcc-4.7-doc,
and gcc-4.8-doc now. All the packaging work is in available in
git[1].

[1] http://anonscm.debian.org/gitweb/?p=users/yixuan-guest/gcc-doc.git;a=summary

Cheers,

GUO Yixuan


-- 
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/20140426194242.15715.18062.report...@miz.etto

Re: DFSG : Really useful?

[Dimitri John Ledkov]

On 25 Apr 2014 15:15, "Solal"  wrote:
>
> Why not just take the Free Software Definition[0] instead lose a lot of
> time in specific guidelines.
> I think use the Free System Distribution Guidelines published by the
> FSF[1] is the best way. Use the FSDG instead of the DFSG will :
> -Be more efficient instead of lose a lot of time in the DFSG.
> -Be sure to be in the 100% free GNU/Linux distros list of the FSF.
>

One is not a superset of the other. The two documents are incompatible. As
one example each way - In debian, we consider GFDL license with invariant
texts to be non-free. Whilst FSDG, disqualifies providing compatible
archives of non-free software.

How are you measuring efficiency / loosing time here? Given the non-trivial
cost of switch and more restrictive terms of FSDG would require more audit
and ongoing work.

The FSF 100% free list is not a deal-breaker pretty much for everyone.

What specific aspects of FSDG do you find to not be met by DFSG?

I am not sure if DFSG predates FSDG or not, but DFSG was used as a basis
for free software definition as published by Opens Source Initiative (OSI)
thus many organisations, including the Linux Foundation, do recognise
Debian as a free operating system.

To answer the topic of your email - yes by large DFSG has been extremely
useful (especially in the early days of pleora of self-written licenses) to
current times with established license terms and non-trivial
compatibilities between them. It is concise and easy to read and
understand. Widely accepted by everyone else. Switching to a different
metric will not magically resolved all licensin issues (patents, trademark
violations, copyright assignments etc.) nor make upstream tarballs to be
magically correct and acceptable.

Regards,

Dimitri.

Re: Non-source Javascript files in upstream source

[Peter Samuelson]

[Manuel A. Fernandez Montecelo]
> If you agree that "source-is-missing" also applies in those cases, do
> you also think that we should immediately declare all source packages
> in Debian containing a 'configure' script as somehow non free (unless
> we can check unambigously that they were generated by the .ac)

There's 2 reasons to care if configure was built from the configure.ac
in the tarball.  The immediately practical reason is to ensure that if
we or our users need to patch it, we can patch the actual source, and
still be able to build correctly.  (These things do tend to bitrot if
you don't watch them.)  Basically that means always rebuilding from
source - which is already a best practice in Debian.  Not every package
does it, but IMO every package _should_.

The other reason to care is of course to comply with our free software
guidelines.  For that purpose, I think it's entirely reasonable to
assume good faith in upstream.  If we find out that some upstream
intentionally tricks us by shipping a mismatching configure, just so
they can point and laugh at the DFSG violation, the solution is very
simple: remove the package from Debian, because such upstreams clearly
can't be trusted not to trick us in more malicious ways.


-- 
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/20140426232014.gd4...@p12n.org

Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

[Bas Wijnen]

On Sat, Apr 26, 2014 at 07:13:33PM +0100, Manuel A. Fernandez Montecelo wrote:
> I would argue that conceptually the same is true of well-known
> minified JS libs: you take the new unminified, substitute it, and are
> done with it -- that the exact source code changes is not important,
> as long as it works.  And we know that the canonical versions usually
> work better than old copies, so good riddance.

But this is not a reason for a lintian override.  Your argument is that
the lintian check is incorrect, and it is triggered by many packages.
Those packages don't need overrides; lintian needs to be fixed instead.

Thanks,
Bas


signature.asc
Description: Digital signature

Re: Non-source Javascript files in upstream source

[Jose Luis Rivas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

El 26/04/14, 06:20pm, Peter Samuelson escribió:
> 
> [Manuel A. Fernandez Montecelo]
> > If you agree that "source-is-missing" also applies in those cases, do
> > you also think that we should immediately declare all source packages
> > in Debian containing a 'configure' script as somehow non free (unless
> > we can check unambigously that they were generated by the .ac)
> 
> There's 2 reasons to care if configure was built from the configure.ac
> in the tarball.  The immediately practical reason is to ensure that if
> we or our users need to patch it, we can patch the actual source, and
> still be able to build correctly.  (These things do tend to bitrot if
> you don't watch them.)  Basically that means always rebuilding from
> source - which is already a best practice in Debian.  Not every package
> does it, but IMO every package _should_.
> 
> The other reason to care is of course to comply with our free software
> guidelines.  For that purpose, I think it's entirely reasonable to
> assume good faith in upstream.  If we find out that some upstream
> intentionally tricks us by shipping a mismatching configure, just so
> they can point and laugh at the DFSG violation, the solution is very
> simple: remove the package from Debian, because such upstreams clearly
> can't be trusted not to trick us in more malicious ways.
> 

I think is unfair to compare `configure` files with minified JavaScript,
starting by the fact that you can't read the minified JavaScript and
distinguish if is doing something wrong compared with the source of the
same un-minified JavaScript.

I think is fine to ship these minified JS files as long as you have a
reproducible way to show that is the same as the source.

Maybe a dh script should be born for this and my head says the prototype
may look like `dh_js_minify_reproduc --source source.js --output min.js
- --rules-should-apply='--with-license --with-copyright' and throw an
error if it's a mismatch.

Kind regards.
> 
> -- 
> 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/20140426232014.gd4...@p12n.org
> 

- -- 
Jose Luis Rivas -- GPG: 0xB9AC8C43
http://www.joseluisrivas.net/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlNcQeUACgkQOKCtW8rKsRhndwCfWOT9rNfsvyf9A+wNRH3G1xJr
03IAoL8NazLacbwzqYqjIqQxLlKu2EIR
=z0qp
-END PGP SIGNATURE-


-- 
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/20140426233149.gc12...@arya.ghostbar.co

Re: Non-source Javascript files in upstream source

[Jose Luis Rivas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

El 26/04/14, 06:20pm, Peter Samuelson escribió:
> 
> [Manuel A. Fernandez Montecelo]
> > If you agree that "source-is-missing" also applies in those cases, do
> > you also think that we should immediately declare all source packages
> > in Debian containing a 'configure' script as somehow non free (unless
> > we can check unambigously that they were generated by the .ac)
> 
> There's 2 reasons to care if configure was built from the configure.ac
> in the tarball.  The immediately practical reason is to ensure that if
> we or our users need to patch it, we can patch the actual source, and
> still be able to build correctly.  (These things do tend to bitrot if
> you don't watch them.)  Basically that means always rebuilding from
> source - which is already a best practice in Debian.  Not every package
> does it, but IMO every package _should_.
> 
> The other reason to care is of course to comply with our free software
> guidelines.  For that purpose, I think it's entirely reasonable to
> assume good faith in upstream.  If we find out that some upstream
> intentionally tricks us by shipping a mismatching configure, just so
> they can point and laugh at the DFSG violation, the solution is very
> simple: remove the package from Debian, because such upstreams clearly
> can't be trusted not to trick us in more malicious ways.
> 

I think is unfair to compare `configure` files with minified JavaScript,
starting by the fact that you can't read the minified JavaScript and
distinguish if is doing something wrong compared with the source of the
same un-minified JavaScript.

I think is fine to ship these minified JS files as long as you have a
reproducible way to show that is the same as the source.

Maybe a dh script should be born for this and my head says the prototype
may look like `dh_js_minify_reproduc --source source.js --output min.js
- --rules-should-apply='--with-license --with-copyright' and throw an
error if it's a mismatch.

Kind regards.
> 
> -- 
> 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/20140426232014.gd4...@p12n.org
> 

- -- 
Jose Luis Rivas -- GPG: 0xB9AC8C43
http://www.joseluisrivas.net/


- -- 
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/20140426233149.gc12...@arya.ghostbar.co

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlNcVbEACgkQOKCtW8rKsRjmGQCfVPeh/hut08w4cnyIzmsNYi9W
LcoAoIc6H549oQNmsXcMvYXZNAlIauXZ
=Y5kV
-END PGP SIGNATURE-


-- 
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/20140427005617.ga27...@arya.ghostbar.co

Re: Bug#745872: ITP: profanity -- a console based XMPP client

[Dariusz Dwornikowski]

> Dariusz Dwornikowski  writes:
> 
> >> PKG_CHECK_MODULES([openssl], [openssl], [],
> >> [AC_MSG_ERROR([openssl is required for profanity])])
> >> 
> >> The resulting binary cannot be distributed.
> 
> > Could You elaborate on that ? Why would openssl ban the binary to be
> > distributable ?
> 
> The GPL and the OpenSSL license are incompatible.
> 

Thank You Russ,

Would it be ok if upstream adds the clause as explained in [1] ? The
upstream is very responsive and open to all suggestions, so it should
not be a problem. 


[1] https://lists.debian.org/debian-legal/2004/05/msg00595.html

-- 
Dariusz Dwornikowski, 
  Institute of Computing Science, Poznań University of Technology
  www.cs.put.poznan.pl/ddwornikowski/  
  room 2.7.2 BTiCW | tel. +48 61 665 29 41


-- 
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/20140427062258.ga1...@blackstar.cs.put.poznan.pl